ISO/IEC 27001:2022: documentation and compliance requirements

This is what ISO/IEC 27001:2022 requires you to have, clause by clause, and what an auditor will ask to see for each of it. It covers 142 requirements across 11 areas.

It is deliberately not a checklist. A checklist asks whether you have something; this says what is required and what counts as evidence, which is the question that matters when you are building a system rather than testing one. If you would rather find out where you stand first, the same ground is covered by our free ISO/IEC 27001:2022 readiness assessment, which scores you out of 100.

4 Your organisation and what you are protecting

Clauses 4.1, 4.2, 4.3, 4.4.

You must have written down the outside things that affect your information security — threats, customers, laws, technology, suppliers.

Evidence: A short list of these issues, with a note of when you last looked at it.

You must have written down the inside things — skills, systems, how you are organised, budget.

Evidence: The same list, covering internal issues.

You must have thought about whether climate change matters to your security — flooding a data centre, heat affecting kit, extreme weather.

Evidence: A recorded decision either way.

You must have listed everyone with an interest — customers, staff, regulators, suppliers, cloud providers, owners.

Evidence: A list of these groups and what each needs from you.

You must know your legal, regulatory and contractual security duties, in every country you operate in.

Evidence: A register by country. Customer security clauses. Sector rules.

You must have written down what the security system covers — which parts of the business, sites, services, systems and information.

Evidence: A scope statement. Network and data flow diagrams showing the boundary.

You must have identified where your scope touches things outside it, and what you depend on.

Evidence: The interfaces and dependencies — other parts of your group, suppliers, shared services.

You must know what your main processes are and how they fit together.

Evidence: A process map or a list with owners.

5 Leadership

Clauses 5.1, 5.2, 5.3.

Senior management must be able to point to security decisions they made in the last year.

Evidence: Management review notes. Security spend approved. Ask them directly.

Senior managers must make sure the system has the people, money and tools it needs.

Evidence: Budget. Staffing. Tooling bought.

You must have a written information security policy.

Evidence: The policy, signed and dated, promising to meet requirements and to keep improving.

It must be shared with your people and available to others who need it.

Evidence: Where it is published. Acknowledgement records.

It must be clear who is responsible for what in security.

Evidence: Organisation chart. Responsibility list.

There must be a named owner for each risk, each information asset and each control.

Evidence: Named risk owners, asset owners and control owners. Duties separated where they would conflict.

6 Planning — risk and the Statement of Applicability

Clauses 6.1.1, 6.1.2, 6.1.3, 6.2, 6.3.

You must have worked out what could stop the security system doing its job, and what opportunities there are.

Evidence: A risk and opportunity list at system level.

You must have a written way of assessing security risk, with the rules set out before you start.

Evidence: The method. Your rules for when a risk is acceptable, and when an assessment must be done. Scales for likelihood and impact with what each level means.

You must be able to answer: Would two different people using your method reach roughly the same answer?

Evidence: Definitions clear enough to be repeatable. Worked examples.

You must have actually assessed the risks to the confidentiality, integrity and availability of the information in scope.

Evidence: A risk register covering the scope, with likelihood, impact and a resulting level for each.

Each must risk have a named owner — a person who can accept it.

Evidence: Owner names against risks. An owner has to be someone with authority, not the security team acting on the business's behalf.

For each risk you are treating, you must have chosen what to do and which controls to use.

Evidence: A risk treatment plan naming the option, the controls, the owner, resources, timescale and the target residual risk.

You must be able to answer: Have the risk owners approved the treatment plan and accepted the residual risk, in writing?

Evidence: Documented approval by each risk owner. Approval by the security function on their behalf is a common and serious finding.

You must have a Statement of Applicability covering all 93 Annex A controls.

Evidence: The Statement of Applicability listing every control, saying whether it is in or out, why, whether it is implemented, and where. This is the first document an auditor will ask for.

The must be Statement of Applicability current, approved, and consistent with the risk treatment plan.

Evidence: Version and approval. Comparison against the treatment plan. Evidence it has been updated since the scope last changed.

You must have set security objectives, and they must be able to be measured.

Evidence: Objectives with targets and numbers, monitored and communicated.

For each objective, it must be clear what will be done, by whom, by when, with what, and how you will judge it.

Evidence: An action plan covering all five points.

When something significant changes, you must plan the change rather than absorbing it.

Evidence: Change records covering changes to the system, the scope, key systems or the organisation.

7 Support

Clauses 7.1, 7.2, 7.3, 7.4, 7.5.

You must provide the people, money and tools the security system needs.

Evidence: Budget. Staffing. Tooling.

You must know what competence security-relevant roles need, and you must be able to show your people have it.

Evidence: Competence criteria. Certifications, training records and experience for security, IT, development and audit staff.

You must be able to answer: Does everyone working for you know the policy, how they contribute, and what happens if they do not follow it?

Evidence: Awareness programme covering staff and relevant contractors. Completion records. Phishing test results. Ask people — this is how it is tested.

You must have decided what to communicate about security, to whom, when and how.

Evidence: A communication plan or table.

You must have the documents and records the standard asks for.

Evidence: A list including the scope, policy, risk method, risk assessment and treatment results, the Statement of Applicability, objectives, competence evidence, monitoring results, audit programme and results, management review results and nonconformity records.

When a document is created or changed, it must be checked and approved before use.

Evidence: Approval on the document.

The security documents themselves must be protected from unauthorised access or change.

Evidence: Access controls over the system documentation. Version control. Backups.

8 Running the system

Clauses 8.1, 8.2, 8.3.

You must have planned and put in place the processes needed to meet the security requirements.

Evidence: Documented processes and evidence they are performed.

You must control externally provided processes, products and services relevant to security.

Evidence: Contracts with security requirements. Monitoring of provider performance. Change control.

You must reassess security risk at set intervals and whenever something significant changes.

Evidence: A schedule with the interval. Assessment records with dates. Reassessments triggered by a new system, service, supplier, acquisition, major incident or law change.

You must be actually carrying out the risk treatment plan, and recording the results.

Evidence: Treatment plan status. Evidence of completed treatments. Overdue items with a reason and a new date. Residual risk re-checked after treatment.

9 Checking how you are doing

Clauses 9.1, 9.2, 9.3.

You must have decided what you will measure, how, when, and who evaluates it.

Evidence: A monitoring plan naming all four. Measures covering both control effectiveness and system performance.

You must analyse the results, rather than just producing dashboards.

Evidence: Analysis and evaluation records with actions arising.

You must audit the system and the applicable Annex A controls, covering everything over a cycle.

Evidence: An audit programme with frequency, methods and responsibilities. Audit plans and reports. Findings.

The auditors must be independent of the work they audit, and competent.

Evidence: Auditor training and independence records. Results reported to the relevant managers.

Senior management must review the system at planned intervals.

Evidence: Review dates and attendance.

The review must cover everything the standard asks for.

Evidence: An agenda covering: previous actions, changes in issues and in interested party needs, performance including nonconformities, monitoring and audit results, objectives met, feedback from interested parties, risk assessment results, the status of the treatment plan, and improvement.

The review must produce decisions and actions, not just minutes.

Evidence: Decisions and an action list with owners and dates.

10 Putting things right and getting better

Clauses 10.2, 10.1.

When something goes wrong, you must deal with it and work out why.

Evidence: Nonconformity and corrective action records with cause analysis.

You must check whether the same weakness exists on another system or in another team.

Evidence: Evidence you looked wider.

You must check later that the fix worked, and change the system where needed.

Evidence: A follow-up record with a date. Documents or controls revised.

You must keep records of what went wrong, what you did and the result.

Evidence: A corrective action log with all three.

You must be able to show the system is better than last year.

Evidence: Trends in incidents, vulnerabilities, patching times, audit findings and objectives met.

Annex A.5 Organisational controls (37)

Clauses A.5.1, A.5.2, A.5.3, A.5.4, A.5.5, A.5.6, A.5.7, A.5.8, A.5.9, A.5.10, A.5.11, A.5.12, A.5.13, A.5.14, A.5.15, A.5.16, A.5.17, A.5.18, A.5.19, A.5.20, A.5.21, A.5.22, A.5.23, A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.5.29, A.5.30, A.5.31, A.5.32, A.5.33, A.5.34, A.5.35, A.5.36, A.5.37.

You must have a set of security policies, approved and reviewed at set intervals.

Evidence: The policy set with approval, owner and review dates.

It must be clear who does what in security.

Evidence: Defined security roles and responsibilities.

You must be able to answer: Are conflicting duties split between different people?

Evidence: A separation of duties analysis. Where a small team makes this impossible, the compensating checks.

You must require staff to follow the security policies, and act if they do not.

Evidence: Management expectations set out. Evidence of enforcement.

You must know when and how to contact the authorities.

Evidence: Contact details for police, regulator and national cyber body, held ready.

You must keep in touch with security groups or forums.

Evidence: Memberships, subscriptions or feeds used.

You must gather and use information about current threats.

Evidence: Threat intelligence sources and evidence the output changed something. NEW in 2022.

You must be able to answer: Is security built into how you run projects?

Evidence: Security requirements in project stages and sign-offs.

You must have an inventory of your information and the things that hold it, with owners.

Evidence: An asset inventory with named owners.

There must be rules for acceptable use and handling of information and assets.

Evidence: An acceptable use policy, acknowledged by staff.

People must return equipment and data when they leave.

Evidence: A leaver checklist with returns recorded.

Information must be classified according to how sensitive it is.

Evidence: A classification scheme and evidence it is applied in practice.

Classified information must be labelled so people know how to treat it.

Evidence: Labelling in documents, emails and systems.

Information must be transferred securely, inside and outside the organisation.

Evidence: Transfer rules and the secure methods used.

Access rules must be based on the business and security need.

Evidence: An access control policy setting the rules.

Each must be person's identity managed through their whole time with you.

Evidence: Identity records. Unique identities. No shared accounts, or justification and control where there are.

Passwords, keys and tokens must be issued and managed securely.

Evidence: Authentication information handling. Secure issue and reset processes.

Access rights must be granted, reviewed and removed properly.

Evidence: Provisioning, review and revocation records.

You must manage the security risks that come with your suppliers.

Evidence: A supplier register with security requirements and how they are assessed.

Security requirements must be written into supplier agreements.

Evidence: Security clauses in contracts.

You must manage security risk in your technology supply chain.

Evidence: Assessment of the products and components you buy, and their own suppliers.

You must monitor supplier security, review their service, and manage changes.

Evidence: Supplier review meetings and records. Change notifications received and assessed.

You must manage the security of the cloud services you use.

Evidence: Cloud service agreements, security settings, and the exit arrangements. NEW in 2022.

You must have planned how you will respond to a security incident.

Evidence: An incident plan with roles, reporting routes and escalation.

You must assess events and decide which are actual incidents.

Evidence: Classification criteria and the assessment recorded.

You must respond to incidents according to the plan.

Evidence: Incident records showing the response taken.

You must learn from incidents and change your controls.

Evidence: Post-incident reviews and the changes that followed.

You must collect and preserve evidence properly during an incident.

Evidence: Evidence handling procedure. Chain of custody where used.

You must keep security going during a disruption.

Evidence: Security arrangements in your continuity plans. Tested.

Your must be IT ready to support business continuity — with recovery objectives and tests.

Evidence: ICT continuity plans with recovery targets, and test records. NEW in 2022.

You must know your legal, regulatory and contractual security duties, and meet them.

Evidence: The register and evidence of compliance.

You must protect intellectual property rights, including software licensing.

Evidence: Licence records. Controls on unlicensed software.

Records must be protected from loss, destruction, falsification and unauthorised access.

Evidence: Records protection and retention arrangements.

You must protect personal data as the law requires.

Evidence: Privacy arrangements. Link to your privacy system if you have one.

Your must be security independently reviewed at planned intervals.

Evidence: Independent review records — internal audit, external assessment or penetration test.

You must check that your own policies and standards are being followed.

Evidence: Compliance checks by managers, and the results.

Your operating procedures must be documented and available to those who need them.

Evidence: Documented procedures for the operational tasks that matter.

Annex A.6 People controls (8)

Clauses A.6.1, A.6.2, A.6.3, A.6.4, A.6.5, A.6.6, A.6.7, A.6.8.

You must screen candidates before they start, where the law allows.

Evidence: Background check records proportionate to the role.

You must be able to answer: Do employment contracts set out security responsibilities?

Evidence: Contract terms. Signed acknowledgements.

Staff must and relevant contractors get security awareness training, and updates.

Evidence: Training records at induction and regularly afterwards.

There must be a disciplinary process for security breaches, and people must know about it.

Evidence: The documented process, communicated. Evidence of use where relevant.

You must be able to answer: Do security responsibilities continue after someone leaves or changes role?

Evidence: Terms covering continuing obligations. Communicated at exit.

You must have confidentiality or non-disclosure agreements, reviewed regularly.

Evidence: Signed agreements for staff and third parties.

You must have security rules for remote working.

Evidence: A remote working policy and the controls that go with it.

People must be able to report security events quickly, and they must know how.

Evidence: A reporting route. Records of use. Ask staff whether they know it.

Annex A.7 Physical controls (14)

Clauses A.7.1, A.7.2, A.7.3, A.7.4, A.7.5, A.7.6, A.7.7, A.7.8, A.7.9, A.7.10, A.7.11, A.7.12, A.7.13, A.7.14.

The boundaries of areas holding sensitive information or systems must be defined and protected.

Evidence: Physical perimeter definition. Barriers and controls.

Entry controls must be in place so only authorised people get in.

Evidence: Access control records. Visitor logs and escorting.

Offices, rooms and facilities must be physically secured.

Evidence: Security arrangements for each type of area.

You must monitor your premises for unauthorised physical access.

Evidence: CCTV, alarms or guards, with monitoring evidence. NEW in 2022.

You must be protected against physical and environmental threats — fire, flood, power, heat.

Evidence: Protection measures and their test records.

There must be rules for working in secure areas.

Evidence: Rules communicated and enforced.

There must be a clear desk and clear screen rule, and it must be followed.

Evidence: The policy plus evidence from spot checks.

Equipment must be sited and protected properly.

Evidence: Siting arrangements. Protection from environmental hazards and from being overlooked.

Equipment must be protected when it is off site — laptops, phones, home working kit.

Evidence: Off-site asset controls. Encryption. Loss reporting.

Storage media must be managed through its life — issue, use, transport and disposal.

Evidence: Media handling and disposal records.

Supporting utilities must be protected — power, cooling, network.

Evidence: Uninterruptible power, generators, redundancy, and their test records.

Cabling must be protected from interception and damage.

Evidence: Cable routing and protection arrangements.

Equipment must be maintained so it stays secure and available.

Evidence: Maintenance records. Controls over maintenance engineers' access.

Equipment must be securely wiped or destroyed before disposal or re-use.

Evidence: Sanitisation records. Certificates of destruction.

Annex A.8 Technological controls (34)

Clauses A.8.1, A.8.2, A.8.3, A.8.4, A.8.5, A.8.6, A.8.7, A.8.8, A.8.9, A.8.10, A.8.11, A.8.12, A.8.13, A.8.14, A.8.15, A.8.16, A.8.17, A.8.18, A.8.19, A.8.20, A.8.21, A.8.22, A.8.23, A.8.24, A.8.25, A.8.26, A.8.27, A.8.28, A.8.29, A.8.30, A.8.31, A.8.32, A.8.33, A.8.34.

User endpoints must be protected — laptops, desktops, phones, tablets.

Evidence: Endpoint protection, encryption and configuration standards, with coverage figures.

Privileged access must be restricted and controlled.

Evidence: A register of privileged accounts with justification. Monitoring of their use.

Access must be to information and systems restricted according to the access policy.

Evidence: Access rules configured in systems. Evidence of least privilege.

Access must be to source code controlled.

Evidence: Repository access controls and branch protection.

You must be able to answer: Is authentication secure — including multi-factor where the risk warrants it?

Evidence: Authentication configuration. Multi-factor coverage.

You must manage capacity so systems stay available.

Evidence: Capacity monitoring and forecasts.

You must be protected against malware.

Evidence: Anti-malware deployment and coverage. Awareness training.

You must find and fix technical vulnerabilities in good time.

Evidence: Scanning schedule. Patching records with times to fix by severity.

System configurations must be defined, applied and checked against a baseline.

Evidence: Configuration baselines and drift monitoring. NEW in 2022.

Information must be deleted when it is no longer needed.

Evidence: Deletion arrangements covering systems, backups and archives. NEW in 2022.

Sensitive data must be masked where full visibility is not needed.

Evidence: Masking in test environments, support tools and reports. NEW in 2022.

You must prevent data leaking out.

Evidence: Data loss prevention arrangements and the alerts they raise. NEW in 2022.

Backups taken, must be protected and tested.

Evidence: Backup schedule, encryption, and restore test records.

Your must be processing redundant enough to meet your availability needs.

Evidence: Redundancy arrangements and failover tests.

Logs must be produced, protected and reviewed.

Evidence: Logging configuration. Log protection from alteration. Evidence of review.

You must monitor systems and networks for unusual behaviour.

Evidence: Monitoring and alerting arrangements, and evidence alerts reach a person. NEW in 2022.

System clocks must be synchronised.

Evidence: Time source configuration.

Powerful utility programs must be restricted.

Evidence: Controls over tools that can bypass system controls.

Software installation on operational systems must be controlled.

Evidence: Rules on who can install software and how.

Networks must be secured and managed.

Evidence: Network security controls and management arrangements.

Network services must be secured, with their security features agreed.

Evidence: Service agreements stating the security features provided.

Networks must be segregated by group, service or sensitivity.

Evidence: Segmentation design and firewall rules.

Access must be to external websites filtered where it needs to be.

Evidence: Web filtering arrangements. NEW in 2022.

Encryption must be used properly, with keys managed.

Evidence: A cryptography policy. Key management arrangements.

You must be able to answer: Is security built into how you develop software, from the start?

Evidence: A secure development lifecycle.

Security requirements must be defined for each application.

Evidence: Application security requirements recorded.

Secure architecture and engineering principles must be applied.

Evidence: Design principles documented and applied.

You must be able to answer: Do developers follow secure coding practices?

Evidence: Coding standards, training and code review evidence. NEW in 2022.

You must be able to answer: Is security testing done during development and before release?

Evidence: Test plans and results, including security testing.

Outsourced development must be supervised and checked.

Evidence: Oversight arrangements for outsourced development.

Development, test and production environments must be kept separate.

Evidence: Environment separation. Controls on moving between them.

Changes to systems must be controlled.

Evidence: Change records with assessment, testing and approval.

Test data must be selected and protected carefully.

Evidence: Controls over using real data in test. Masking or synthetic data.

Systems must be protected during audit testing so live operations are not disrupted.

Evidence: Agreed arrangements for audit access and testing windows.

Using this document

Nothing above asks for a manual, a template pack, or a filing system. It asks for decisions that have been taken deliberately and can be shown to have been taken — which is a far smaller job than most organisations expect, and a different one.

Length is not compliance. A procedure nobody follows is worse than no procedure, because an auditor finds the gap between the two. The test we apply is whether the person who has to do the job recognises their own work in what is written down.