ISO 27001 names one policy, the information security policy in clause 5.2, and requires topic-specific policies through Annex A control A.5.1 without listing them. In practice an ISMS ends up with a set of around fifteen documents: the scope and the top-level policy, the risk method and the Statement of Applicability, topic policies for access, assets, operations, networks, development, suppliers, people, incidents and continuity, and procedures for internal audit, management review and corrective action. Each should say who owns it, what it requires, how compliance is checked and which clauses or controls it serves. Auditors test that a policy is approved, communicated, followed and reviewed, not that it is long.
"Which policies does ISO 27001 require?" has a short answer and a useful one. The short answer is one. The useful answer is the set an auditor expects to find because the clauses and the Annex A controls you selected cannot be operated without written rules. This article gives that set, what each document has to cover, and how auditors test policies.
The one policy the standard names
Clause 5.2 requires top management to establish an information security policy that fits the organisation's purpose, includes the security objectives or a framework for setting them, commits to meeting applicable requirements and to continual improvement, is kept as documented information, is communicated inside the organisation and is available to interested parties as appropriate. It is short by design, often two pages, and signed by the chief executive or equivalent. Annex A control A.5.1 then requires topic-specific policies, approved by management, published, acknowledged by the people they apply to, and reviewed at planned intervals and when something significant changes.
The set most ISMSs end up with
The table lists the documents a cloud-hosted company of a few dozen to a few hundred people typically needs, with the clauses or controls each one serves. Smaller organisations merge rows; larger ones split them.
| Document | Serves | What it has to cover |
|---|---|---|
| ISMS scope and context | Clauses 4.1 to 4.3 | Internal and external issues, interested parties and their requirements, the scope boundary and its interfaces |
| Information security policy | Clause 5.2 | Purpose, objectives or how they are set, commitment to requirements and improvement, who approves and when it is reviewed |
| Roles and responsibilities | Clause 5.3, A.5.2, A.5.4 | Who owns the ISMS, risks, controls and evidence, who reports to top management, and management's own duties |
| Risk management method | Clauses 6.1.2, 6.1.3, 8.2 | Risk criteria and acceptance levels, the assessment method, treatment options, who approves residual risk, how often it runs |
| Statement of Applicability governance | Clause 6.1.3 | How controls are selected from the treatment plan, how justifications are written, versioning and approval |
| Access control | A.5.15 to A.5.18, A.8.2, A.8.3, A.8.5 | Joiner, mover and leaver rules, least privilege, privileged access, authentication requirements, review frequency |
| Asset management and information handling | A.5.9 to A.5.13, A.5.34, A.8.1, A.8.10 | The inventory and its owners, acceptable use, return of assets, classification levels and labelling, personal data handling, deletion |
| Operations security | A.8.7, A.8.8, A.8.9, A.8.12, A.8.13, A.8.15, A.8.16, A.8.24 | Malware protection, vulnerability management and patch timelines, configuration baselines, data leakage, backups and restore tests, logging and monitoring, cryptography |
| Network and communications | A.8.20 to A.8.23, A.5.14 | Network controls and segregation, network services, web filtering, rules for transferring information |
| Secure development and change management | A.8.25 to A.8.29, A.8.31 to A.8.33 | The development life cycle, security requirements, secure coding, testing, separated environments, change approval, test data |
| Supplier security | A.5.19 to A.5.23, A.8.30 | Supplier risk assessment, contract requirements, ICT supply-chain controls, monitoring and review, cloud service rules, outsourced development |
| People security and awareness | Clauses 7.2, 7.3, A.6.1 to A.6.7 | Screening, terms of employment, awareness and training, disciplinary process, leavers, confidentiality agreements, remote working |
| Incident response | A.5.24 to A.5.28, A.6.8 | How events are reported, assessed and classified, who responds, communication, evidence collection, lessons learned |
| Business continuity and ICT readiness | A.5.29, A.5.30, A.8.14, A.8.6 | Security during disruption, recovery objectives, redundancy, capacity, how plans are tested |
| Internal audit procedure | Clause 9.2 | The programme, frequency, auditor independence, methods, reporting and record keeping |
| Management review procedure | Clause 9.3 | Frequency, attendees, the inputs the clause lists, the decisions and records the review produces |
| Nonconformity and corrective action procedure | Clause 10.2 | How nonconformities are recorded, root cause analysed, actions taken, effectiveness checked and the ISMS updated |
Two more documents are often expected though not strictly policies: legal, regulatory and contractual requirements (A.5.31), usually a register, and the documented operating procedures A.5.37 asks for where a task would otherwise be done from memory.
What the auditor tests about policies
- Approval: who approved it, when, and whether that person has the authority the policy claims.
- Communication and acknowledgement: that the people it applies to have it and have confirmed they read it, including contractors where the policy covers them.
- Operation: that what the policy says happens does happen. A policy requiring quarterly access reviews is tested by asking for the last four.
- Review: that it has been reviewed at the interval it states and after significant changes, with a record of the review even when nothing changed.
- Consistency: that the policy, the Statement of Applicability and the controls agree, and that no two policies contradict each other.
Writing policies that are followed
- Say what you do, not what ISO 27002 suggests. Copying guidance text produces promises the auditor will test and you will fail.
- Name the systems and the roles. "Access is reviewed quarterly by the engineering manager in the identity provider" is testable; "access is reviewed periodically by management" is not.
- Keep each document short enough to read at onboarding. Detail goes in procedures and runbooks that the policy refers to.
- Put the control references in the document, so the mapping survives staff changes.
- Date the next review when you approve the current version.
Approval, communication and acknowledgement
A policy becomes evidence only once it is approved by someone with the authority to bind the organisation, published where the people it covers can find it, and acknowledged by them. Acknowledgement records are sampled: the auditor picks names from the staff list and asks for each one's acknowledgement of the policies that apply. New joiners acknowledge during onboarding; everyone re-acknowledges when a policy changes materially. The checklist places the policies among the other clause 4 to 10 records.
How Noru drafts the policy set
Cortex, Noru's AI layer, drafts the policies from the controls selected in the Statement of Applicability, so each document is linked to the ISO 27001 clauses and Annex A controls it serves and describes the controls as they are configured rather than in generic terms. People review and approve the drafts, versions are kept, and acknowledgements are requested from everyone in scope and tracked per person, which is the record the auditor samples.