Draft an internal security policy for [ORGANIZATION] covering [POLICY SCOPE]. Use the operating facts, existing rules, and requirements below; do not fill gaps with invented tooling, certifications, approvals, or legal conclusions. Organization and systems: [ORGANIZATION AND SYSTEMS] People and access model: [PEOPLE AND ACCESS] Existing policies and requirements: [EXISTING REQUIREMENTS] Incidents and risks to address: [RISKS AND INCIDENTS] Policy owner and constraints: [OWNER AND CONSTRAINTS] Write a policy in plain language for employees and contractors. Produce these sections: purpose; scope; definitions limited to terms used; policy statements; roles and responsibilities; required controls; reporting and escalation; exceptions; enforcement; training; records; and review cadence. For each required control, specify who performs it, what triggers it, the evidence retained, and the deadline or frequency. Address access provisioning and removal, MFA and credential handling, approved devices, data classification and sharing, vendor or SaaS access, secure remote work, vulnerability and patch management, incident reporting, and exception approval only when they apply to the stated scope. Distinguish mandatory requirements from guidance. Use “must” only for enforceable rules. Include a short implementation checklist with the first 10 actions, owners by role, and dependencies. Add a “decisions needed” list for any items that require leadership, security, HR, privacy, legal, or IT approval. Do not claim that following this policy guarantees compliance with a framework or law. Before answering, check that no control names a system we have not provided and that every obligation has an accountable role, evidence, and escalation route. Flag conflicts with the existing requirements. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [ORGANIZATION] | Enter the organization name, industry, size, and jurisdictions where it operates. | Harbor Health Analytics, a 72-person US healthcare analytics company serving hospital networks. |
| [POLICY SCOPE] | State the policy topic and the people, systems, data, and locations it covers. | Access control policy for employees, contractors, production systems, customer data, and company laptops. |
| [ORGANIZATION AND SYSTEMS] | Describe the devices, identity tools, cloud services, data types, and operational environment in scope. | Google Workspace, Okta, AWS, GitHub, Jira, managed macOS laptops, and de-identified claims data. |
| [PEOPLE AND ACCESS] | Describe employee and contractor roles, privileged access, remote-work arrangements, and onboarding process. | Engineering has production access through AWS roles; support contractors use Jira and a restricted customer portal; most staff work remotely. |
| [EXISTING REQUIREMENTS] | List current policies, contracts, frameworks, customer commitments, and legal requirements that apply. | HIPAA contractual obligations, customer security addendum, employee handbook, and annual SOC 2 readiness plan. |
| [RISKS AND INCIDENTS] | List known risks, audit findings, past incidents, and misuse patterns the policy should address. | A former contractor retained a shared-folder link after offboarding; audit found inconsistent quarterly access reviews. |
| [OWNER AND CONSTRAINTS] | Name the policy owner role, review cycle, implementation deadline, and resource constraints. | Security lead owns the policy; HR and IT execute controls; version needed in six weeks with no new identity platform. |
How to use
- Replace the inputs with your actual systems, roles, contracts, and unresolved risks.
- Read each “must” statement and confirm that the named owner can actually carry it out with current tools.
- Ask: “Create a control-to-evidence matrix from this policy for our next internal audit.”
- Have security, HR, privacy, and legal reviewers approve the version that will become binding policy.
Variations
Acceptable use
Use when setting employee rules for company systems, devices, and data.
Draft an acceptable-use policy for [ORGANIZATION] covering [SYSTEMS AND DATA]. Users are [USERS]; existing requirements are [REQUIREMENTS]; known misuse risks are [RISKS]. Create sections for permitted use, prohibited use, personal use, monitoring and privacy notice, data handling, approved software, remote work, reporting, exceptions, and enforcement. Use concrete examples that match the supplied environment. Do not claim a monitoring practice that has not been approved. Check that prohibitions are specific enough to enforce and that the policy does not conflict with employment or privacy rules; flag items for HR or legal review.
Incident response
Use when documenting who does what after a suspected security incident.
Create an incident-response policy for [ORGANIZATION] based on [SYSTEMS], [TEAM ROLES], and [REGULATORY OR CONTRACTUAL DUTIES]. Produce severity definitions, intake channels, triage steps, evidence-preservation rules, incident commander authority, internal updates, customer and regulator notification decision points, recovery, and post-incident review. Include a role-based 24-hour checklist without naming people or vendors not provided. Do not state legal notification deadlines unless supplied; flag them for counsel. Check that each severity has an escalation owner and that containment actions preserve evidence.
Vendor security
Use when establishing minimum checks before a vendor handles company data.
Draft a vendor-security policy for [ORGANIZATION] covering vendors that access [DATA OR SYSTEMS]. Procurement process is [PROCESS]; current contract requirements are [CONTRACT TERMS]; risk tolerance is [RISK TOLERANCE]. Produce vendor tiers, intake questions, due-diligence evidence, security-review owners, required contract clauses to refer to counsel, reassessment triggers, offboarding steps, and an exception process. Do not assert that a certification proves suitability. Check that higher-risk vendors receive deeper review and that contract, security, privacy, and procurement responsibilities do not overlap ambiguously.
Tips
- Write controls around observable actions and retained evidence, such as quarterly access-review records, rather than broad intentions such as “protect accounts.”
- Do not copy a framework wholesale; map only the controls that fit your systems and contractual obligations.
- An exception process needs an approver, expiration date, compensating control, and recorded rationale or it becomes a permanent bypass.
- Policy language should match actual practice first; if the desired control is not operating yet, make it an implementation action with an owner.
FAQ
Can AI create a compliant security policy?
It can draft and organize a policy, but compliance depends on your operations, contracts, jurisdictions, and professional review.
How detailed should a security policy be?
It should set enforceable requirements and ownership. Put tool-specific procedures in supporting runbooks so routine changes do not require rewriting the policy.
Who should approve a policy?
Typically the policy owner and leadership, with review from security, IT, HR, privacy, and legal where their responsibilities are affected.