Information Security Policy Writing: A Practical Guide for Teams That Have None
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Security policies exist on a spectrum from honest documentation of current practices to aspirational fiction that describes controls the organization does not actually have. The honest end of the spectrum is what survives an audit — an auditor who interviews your access management team and finds they do not run the quarterly reviews the policy says they run has a finding, regardless of how well-written the policy is.
The goal of security policies is threefold: to establish clear expectations for employees about security behavior, to provide evidence to auditors that the organization has formal controls, and to create a reference document for new team members learning how the organization manages security. All three goals are undermined by template-based policies that describe controls the organization does not have. This guide covers how to write policies that serve all three purposes.
The minimum viable policy set: what to write first
Not all security policies are equally urgent. Auditors reviewing SOC 2 and ISO 27001 follow a consistent pattern, starting with the overarching information security policy and then testing the control-specific policies for access control, change management, and incident response. This section covers the two policies that should be written first: the foundation document that frames your entire program, and the access control policy that is most frequently tested with operational evidence. Getting these two right before writing the remaining six to ten policies ensures your highest-scrutiny control areas are covered by accurate, auditor-ready documentation.
The information security policy: your foundation document
The overarching information security policy sets the scope and intent of your security program. Required content: the organization's commitment to information security (2-3 sentences), the scope of the policy (all employees, contractors, systems, and data), the security objectives (protect confidentiality, integrity, and availability of data), high-level roles and responsibilities (CISO responsible for program, all employees responsible for compliance), a statement that all employees are required to comply, and the consequence of non-compliance (HR disciplinary process). This policy is 1-2 pages. It does not contain specific controls — those are in the control-specific policies. The information security policy is the anchor document that auditors read first to understand your security program's structure.
Writing the access control policy accurately
Access control is the most scrutinized policy area in SOC 2 and ISO 27001 audits. For each element of your access control process: name the specific tool used (Okta for identity, Jira Service Management for access requests, BambooHR for offboarding triggers), specify the exact timeline (access provisioned within 1 business day, revoked within 4 hours of termination notification), name the reviewer role (engineering manager reviews quarterly, CISO reviews privileged access). Resist the temptation to write 'access is reviewed regularly' — if your review schedule is quarterly, write 'quarterly access reviews are conducted in January, April, July, and October.' The specificity makes the policy a useful operational reference and makes audit testing against it unambiguous.
Policy maintenance: keeping documents accurate over time
A policy written accurately today becomes a compliance liability the moment your organization changes and the policy does not reflect that change. The most common audit finding in organizations with established policy programs is not missing policies but stale ones: policies that reference tools no longer in use, timelines that no longer match current practice, or roles that have been reorganized. This section covers the policy review calendar and update workflow that prevents policies from drifting from operational reality. The goal is a system where no policy can reach its annual review date without a designated owner initiating a review and attestation process.
Build a policy review calendar before any policy expires
After completing each policy: set a calendar event 11 months from the policy's approval date, owned by the policy owner, titled '[Policy Name] — Annual Review Due.' The 11-month trigger gives one month to complete the review before the annual anniversary. Review agenda: read the policy line by line and compare each statement to current practice. Mark any statement that is no longer accurate (the tool changed, the process changed, the timeframe changed). Draft updates for inaccurate statements. Have the updated policy reviewed by the relevant technical owner and signed off by the CISO or security manager. Publish with updated version number and review date. A policy reviewed and found still accurate should still receive an updated 'last reviewed' date — auditors look for this date, not just a change history.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Security policy writing has one cardinal rule: write what you do, not what you wish you did. Auditors test policies against operational evidence — if the policy says quarterly access reviews and the evidence shows annual reviews, that is a finding regardless of how good the policy reads in isolation. Start with the 8-10 policies that cover your compliance framework's primary control areas, write them from interviews with the people who actually do the work, and build a review calendar before the ink is dry on the first version. The output is not a compliance checkbox — it is documentation that new employees use to learn how security works at your organization, that auditors use to confirm controls exist, and that your team uses during incidents to confirm what the expected procedure is.
Frequently asked questions
What security policies do I need for a SOC 2 audit?
SOC 2 does not mandate a specific list of policies, but auditors reviewing the Common Criteria expect evidence of formal policies for each control area. Policies most commonly required: (1) Information Security Policy (overarching policy, covers scope, objectives, roles). (2) Acceptable Use Policy (how employees may use company systems and data). (3) Access Control Policy (how access is provisioned, reviewed, and revoked). (4) Change Management Policy (how changes to production systems are approved and deployed). (5) Incident Response Policy (how security incidents are identified, escalated, and resolved). (6) Vendor Management Policy (how third-party vendors with data access are assessed and monitored). (7) Business Continuity and Disaster Recovery Policy (how the organization maintains operations during disruptions). (8) Data Classification Policy (how data types are classified and handled). (9) Encryption Policy (when encryption is required and what standards apply). (10) Password and Authentication Policy. This set covers the primary SOC 2 Common Criteria control areas.
How long should a security policy be and what structure should it follow?
Security policies should be as short as they can be while covering the required content — a 3-page policy that is read and followed is more valuable than a 30-page policy that no one reads. Recommended structure: (1) Purpose (1-2 sentences: what this policy governs and why it exists). (2) Scope (who and what this policy applies to — all employees, specific systems, specific data types). (3) Policy statement (the actual requirements — numbered or bulleted for easy reference). (4) Roles and responsibilities (who is responsible for implementing and monitoring compliance). (5) Exceptions process (how exceptions to the policy are requested and approved). (6) Related documents (links to related policies, standards, or procedures). (7) Review schedule (when the policy is next reviewed, who is responsible for review). (8) Approval (who approved this version and when). Most policies should be 2-5 pages. If a policy requires 15 pages to describe the requirements, it is likely covering multiple distinct topics that should be split into separate policies.
How do I write security policies that reflect what we actually do instead of what we should do?
Policy accuracy requires documenting your current practices, then identifying gaps, rather than starting with a template of best practices. Process: (1) Interview the people who do the work: who provisions access? What is the actual approval process? How are access reviews conducted? What does change management actually look like in your deployment pipeline? (2) Document what you observe, not what you wish was true. If access reviews happen annually, the policy should say annually — not quarterly, because quarterly sounds better. (3) For gaps between current practice and what your compliance framework requires: document the current practice accurately and add a planned improvement with a timeline in a separate gap remediation plan. (4) Have the policy reviewed by the people who will be audited against it — if your engineering lead reads the change management policy and says 'this is not how we do it,' the policy needs to be updated before the audit. Policies that no one in the organization recognizes as describing their actual work fail audits regardless of how well-written they are.
What should an Access Control Policy actually say?
An Access Control Policy should specify: (1) How access is requested (ticketing system, email approval, manager approval in HR system — name the specific tool and workflow). (2) Who can approve access requests (direct manager for standard access, CISO or CTO for privileged access). (3) Maximum timeframe for provisioning approved access (within 1 business day, within 1 week for specialized systems). (4) How access is reviewed (quarterly for privileged access, annually for standard access, by what process — a specific review meeting with documented output). (5) How access is revoked (within how many hours of employment termination, who is responsible for initiating revocation, what systems are included). (6) Minimum privilege requirement (access should be limited to what is required for the role). (7) MFA requirements (which systems require MFA, what authenticator types are acceptable). Write the names of your actual systems: 'Access to AWS, GitHub, Okta, and Salesforce is provisioned within 1 business day of manager approval via an IT request ticket in Jira' is more useful than 'Access to systems will be provisioned within a reasonable timeframe following appropriate approval.'
How do I handle the policy review process and keep policies up to date?
Policy review governance: (1) Assign a policy owner for each policy — the person responsible for keeping the policy accurate and initiating reviews. For most organizations, the CISO or Head of Security owns all security policies, with technical reviewers for specific domains. (2) Schedule annual reviews for all policies as calendar events a year in advance, owned by the policy owner. (3) Trigger ad hoc reviews when: there is a security incident that the current policy did not adequately address, a significant infrastructure change makes the policy inaccurate, or a compliance assessment identifies a gap. (4) Policy update workflow: policy owner drafts updates, technical reviewers confirm accuracy, CISO and any required executive sign-off, publish to the policy repository with updated version number and date. (5) Communicate changes to all employees when policy requirements change (annual security training covers the updated policy; an email notice for significant changes).
Do I need separate policies for each topic or can I combine them into one document?
Start with a combined information security policy document and split only when the topics require it. A combined document has advantages: easier to maintain, easier to read, and fewer gaps from policies that should reference each other but do not. When to split: a section has grown to more than 5-7 pages (it has enough content to be self-contained and easier to navigate as a separate document), when a specific section has a different audience (the Acceptable Use Policy is read by all employees; the Encryption Policy is primarily for engineers — having a separate document for each makes distributing the relevant policy easier), or when a compliance framework specifically requires a standalone policy for a control area (PCI DSS requires a standalone information security policy document addressing specific elements). Most organizations under 200 people can manage with 5-8 focused policies; most above 500 people benefit from 10-15 more specific policies.
How do I get security policies signed off and acknowledged by all employees?
Policy acknowledgment tracks which employees have read and agreed to comply with security policies, creating an evidence trail for auditors and establishing explicit employee awareness of their security obligations. Implementation options: (1) HR onboarding workflow: add policy acknowledgment to the new-hire onboarding checklist in your HR system (BambooHR, Workday, Gusto) — employees acknowledge on day one. (2) Annual recertification: use the same HR system or a dedicated GRC tool (Drata, Vanta, Secureframe) to send annual acknowledgment requests to all employees, with automated reminders and tracking of completion rates. (3) Policy management tools: dedicated policy management platforms (Confluence with acknowledgment tracking, PolicyStat, or compliance platforms) allow version-specific acknowledgment tracking — when you update a policy, the system can require re-acknowledgment of the updated version. Completion rate (what percentage of employees have acknowledged each policy) is a metric auditors may request.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.