Proofpoint Security Awareness, 2024
ISO 27001:2022
Verizon DBIR 2024
Why Most Security Policies Fail
A security policy is only effective if the people it applies to read it, understand it, and change their behaviour because of it. Most policies achieve none of these three things. They are written in dense legalese by security professionals, published to an intranet folder nobody visits, acknowledged by a checkbox click that takes three seconds, and never thought about again until the next audit.
"The most dangerous security policy is the one that was written to satisfy an auditor's checklist — because it gives the organisation the false confidence of compliance without any of the actual risk reduction."
The failure modes are consistent across organisations of every size. Policies are written for the wrong audience. Obligations are stated vaguely. There are no consequences for non-compliance. Leadership endorsement is nominal rather than visible. And once the ISO 27001 or SOC 2 audit is complete, policies are filed and forgotten until the next certification cycle — by which point they're describing a technology environment that no longer exists.
Auditors check whether policies exist, whether they cover the required topics, and whether they have been reviewed recently. They typically cannot check whether employees actually follow them. An organisation can pass an ISO 27001 audit with a complete set of policies that nobody reads — and be breached six months later because of a behaviour the policy explicitly prohibited.
The Policies Your Organisation Actually Needs
Before writing, be clear on what you need. Most organisations pursuing ISO 27001 or SOC 2 require a core set of policies. Here are the ones that matter most — and the compliance frameworks that require them.
Information Security Policy
The overarching policy that states the organisation's commitment to security, sets the scope of the ISMS, and establishes top-level obligations. Must be signed by leadership. This is Clause 5.2 — every other policy flows from it.
Acceptable Use Policy
What employees can and cannot do with company systems, devices, and data. The most read policy in any organisation — and the one most directly responsible for preventing insider threats and accidental data exposure.
Access Control Policy
Who gets access to what systems and data, how access is granted and revoked, and the principle of least privilege. Directly maps to ISO 27001 Annex A.5.15 and SOC 2 CC6.1. One of the most frequently cited gaps in audits.
Data Classification Policy
How your organisation categorises data by sensitivity — typically Public, Internal, Confidential, Restricted — and the handling requirements for each tier. Essential for DPDP compliance and the foundation of most other data protection controls.
Incident Response Policy
What constitutes a security incident, how it is reported, who responds, and what the escalation path looks like. Directly satisfies ISO 27001 A.5.26 and SOC 2 CC7.3/CC7.4. Must include regulatory notification obligations.
Cryptography Policy
Which encryption algorithms are approved, where encryption is required (at rest, in transit), and how keys are managed. Satisfies ISO 27001 A.8.24. Prevents the "we use encryption" assertion that covers DES and MD5 as much as AES-256.
Supplier Security Policy
Security requirements for third-party vendors, onboarding and offboarding procedures, and minimum standards for suppliers with access to your systems or data. ISO 27001 A.5.19 and A.5.21. Directly addresses the third-party risk gap.
Remote Working Policy
Security requirements for employees working outside the office — device encryption, VPN usage, public Wi-Fi restrictions, screen locking. More relevant than ever post-2020 and increasingly expected by enterprise customers in vendor questionnaires.
The 6-Step Policy Writing Process
- 1Define the purpose, scope, and consequence before writing anything elseEvery policy must answer three questions upfront: what does this policy protect, who does it apply to, and what happens if it is not followed. Without clear answers to all three, the policy cannot be enforced. State these in the first section — not buried in an appendix.
- 2Identify your actual audience and write for themAn acceptable use policy applies to every employee — including the sales executive who has never opened a security document. Write at the literacy level of the least technical person in scope. If the policy requires a glossary, it's too technical. If it requires a law degree to interpret, it will not be followed.
- 3State obligations, not aspirationsThe most common writing failure in security policies is the use of aspirational language that sounds like an obligation but isn't. "Should," "may," and "is encouraged to" are not enforceable. Replace every instance with "must," "is required to," or "will." Every obligation must be specific enough to be audited.
- 4Get genuine leadership sign-off — not just a signatureA policy signed by the CEO and communicated in a company-wide message is a different object from a policy signed by the CISO and published to the intranet. Visible leadership endorsement signals to every employee that this is taken seriously at the top. Without it, the policy is treated as an IT department document — optional and ignorable.
- 5Build a real acknowledgement and training processEvery employee must read, understand, and formally acknowledge each policy they are subject to — not just tick a box that the document exists. For high-risk roles (finance, IT, senior leadership), require role-specific training that goes beyond reading. Track acknowledgement rates by department and follow up on gaps.
- 6Set a review schedule and own itBuild the review date into the policy document itself. Assign a named owner who is accountable for initiating the annual review. Trigger reviews immediately after any significant incident, technology change, or regulatory update. An outdated policy is worse than no policy — it creates documented evidence of controls that no longer exist.
The Language That Actually Works
Policy language determines whether obligations are enforceable. Here are the most common rewrites that transform vague aspirations into auditable requirements:
"Employees should use strong passwords and are encouraged to enable multi-factor authentication where available."
"All employees must use passwords of at least 14 characters. Multi-factor authentication is mandatory for all corporate systems. Non-compliance will result in access suspension."
"Sensitive data should be handled with care and employees are expected to use good judgement when sharing information."
"Data classified as Confidential or Restricted must only be shared via encrypted channels. Sharing via personal email or unencrypted messaging services is prohibited and subject to disciplinary action."
"IT incidents should be reported to the security team as soon as possible."
"All suspected security incidents must be reported to security@seccomply.net within 2 hours of discovery. Failure to report a known incident is a policy violation subject to disciplinary review."
After drafting a policy, ask a non-technical employee in the target audience to read it and explain back to you what they are required to do. If they cannot, the policy needs to be rewritten — not the employee trained. Clarity is the responsibility of the writer, not the reader.
Effective security policies are written for the people who must follow them, not the auditors who review them. The two requirements are not mutually exclusive — but most organisations optimise for only one.
Enforcement, Acknowledgement, and Consequence
A policy without enforcement is a recommendation. For a policy to be a genuine control — one that satisfies ISO 27001 or SOC 2 auditors and actually changes behaviour — it needs three things: a documented acknowledgement process, visible consequences for non-compliance, and a mechanism for tracking and following up on gaps.
- 📝Formal acknowledgement at onboarding and annuallyEvery new employee signs an acknowledgement that they have read and understood relevant policies as part of onboarding. Annual re-acknowledgement is required — not optional. Track completion rates in your HRIS or GRC tool and report gaps to management. Below 90% acknowledgement for any policy is a finding.
- ⚠️State consequences explicitly in the documentThe consequence section must appear in the policy body itself — not just in the employee handbook. Options range from formal warning to termination depending on severity. The specificity matters: "subject to disciplinary action up to and including termination of employment" is enforceable. "May face consequences" is not.
- 📊Track acknowledgement rates by department and report themAcknowledgement rates below 80% in any department are a risk signal — they mean a significant portion of that team either doesn't know the policy exists or actively avoided reading it. Report these rates quarterly to leadership. Departments with consistently low rates need targeted intervention, not just another email reminder.
- 🔄Enforce consistently — exceptions undermine everythingA single publicly known exception to a policy — an executive who ignored the password policy and faced no consequence — destroys the policy's authority across the entire organisation. Enforcement must be consistent regardless of seniority. If a control cannot be applied to leadership, it should not be in the policy.
Security Policy and Compliance Requirements
| Framework | Policy Requirement | What Auditors Look For |
|---|---|---|
| ISO 27001 | Clause 5.2 — Information security policy; Annex A policies across 93 controls | Top-level policy signed by leadership, documented review history, evidence of communication to all relevant parties |
| SOC 2 | CC1.3 — Policies and procedures to support the achievement of commitments | Written policies covering the five Trust Service Criteria, acknowledgement records, evidence of enforcement |
| GDPR / DPDP | Article 24 (GDPR) / Section 8(5) DPDP — Technical and organisational measures | Data classification policy, data handling procedures, evidence that employees are trained on data protection obligations |
| HIPAA | 164.308(a)(1) — Security management process; includes written policies and procedures | Written policies covering all required administrative safeguards, workforce training records, sanctions policy |
| PCI DSS | Req 12.1 — Comprehensive information security policy | Annual review of the security policy, documented approval, distribution to all relevant personnel |
Keeping Policies Current
An outdated policy is not a neutral document — it actively creates risk. It tells auditors that your controls were reviewed at a certain date and found adequate, when they may now be entirely inadequate for your current environment. It also creates an enforcement problem: you cannot discipline an employee for violating a policy that references systems you decommissioned two years ago.
Build policy reviews into your security calendar the same way you schedule penetration tests and audits. Every policy should have a named owner and a review date in the document header. The CISO or equivalent should receive a monthly report of policies approaching their review date. Reviews triggered by incidents or regulatory changes should be completed within 30 days of the trigger event.
Trigger an immediate policy review when any of the following occurs: a security incident reveals a gap in existing policy coverage, a new technology or system is deployed that the current policy doesn't address, a regulatory requirement changes that affects your obligations, or a significant organisational change occurs such as a merger, acquisition, or major headcount change.
Frequently Asked Questions
ISO 27001 requires an overarching Information Security Policy (Clause 5.2) plus supporting policies covering access control, cryptography, physical security, supplier relationships, incident management, and business continuity. The exact set depends on scope and risk assessment, but most organisations need 10-15 policies to achieve full Annex A coverage.
The overarching information security policy should be 2-4 pages. Supporting policies covering specific topics can be longer but should never exceed what an employee in that role would reasonably read and retain. If a policy is longer than 10 pages, it should be split into a policy and a separate procedure document.
A security policy states what must be done and why — it sets the obligation. A security procedure states how to do it — the step-by-step implementation. Policies are written for all relevant employees and signed off at the executive level. Procedures are operational documents written for the people who carry out the specific task.
ISO 27001 requires policies to be reviewed at planned intervals and when significant changes occur. Annual reviews are the minimum. Policies should also be reviewed immediately after a security incident that reveals a gap, after a significant technology or organisational change, and when a new regulatory requirement takes effect.
An enforceable security policy has four characteristics: specific measurable obligations rather than vague aspirations, a clear consequence for non-compliance stated in the document, an acknowledgement process that creates a documented record that each employee has read it, and visible leadership endorsement that signals the organisation takes it seriously. Without all four, a policy is a document, not a control.