ISO 27001:2022 checklist

A complete ISO 27001 checklist verifies two things: that the management system meets the requirements of clauses 4 to 10, and that the Annex A controls, 93 in the 2022 version, are assessed one by one in the Statement of Applicability. In between come the risk assessment, the mandatory documents, at least one internal audit and a management review before the certification audit.

ISO/IEC 27001 does not ask you to buy technology or to write a set number of procedures. It asks for an information security management system (ISMS) that works and that you can demonstrate. This guide turns the standard into a practical checklist. For an overview of who needs it and why, start from the ISO/IEC 27001 page.

How ISO/IEC 27001:2022 is structured

The standard has two parts. Clauses 4 to 10 contain the management system requirements and follow the structure common to ISO management system standards, the same as ISO 9001: if you already have a quality management system, you will recognise the layout. Annex A lists the reference security controls, which ISO/IEC 27002 explains in detail. Clauses 0 to 3 are introductory and contain no requirements.

In 2024 an amendment on climate was published (Amd 1:2024): in clause 4.1 it asks you to determine whether climate change is a relevant issue for the organisation, and in 4.2 it adds a note that interested parties can have climate-related requirements. Take it into account in your analysis of the context.

Checklist for clauses 4–10

For each item, ask yourself two questions: have we done it? And can we prove it to an external auditor?

Clause 4 – Context of the organisation

• Relevant internal and external issues identified, climate included (4.1)
• Interested parties and their requirements, including those the ISMS will address (4.2)
• Scope defined with boundaries, interfaces and dependencies, and documented (4.3)
• ISMS processes and their interactions established (4.4)

Clause 5 – Leadership

• Visible top management commitment: resources, communication, integration into processes (5.1)
• Information security policy approved, documented and communicated (5.2)
• Roles, responsibilities and authorities assigned and communicated (5.3)

Clause 6 – Planning

• Risk assessment process defined, with acceptance criteria (6.1.2)
• Risk treatment process and treatment plan (6.1.3)
• Statement of Applicability drawn up (6.1.3 d)
• Residual risks accepted by the risk owners, plan approved
• Measurable security objectives, with owners and deadlines (6.2)
• Changes to the ISMS planned (6.3, new in the 2022 version)

Clause 7 – Support

• Necessary resources determined and provided (7.1)
• Competences defined, with evidence of training and experience (7.2)
• Staff awareness of the policy and of their own role (7.3)
• Internal and external communication planned (7.4)
• Documented information controlled: approval, versions, distribution, retention (7.5)

Clause 8 – Operation

• Processes planned and controlled, including those that are outsourced (8.1)
• Risk assessment repeated at planned intervals and after significant changes (8.2)
• Treatment plan implemented, with documented results (8.3)

Clause 9 – Performance evaluation

• What to measure, how, when and who analyses the results (9.1)
• Internal audit programme implemented (9.2)
• Management review carried out at planned intervals (9.3)

Clause 10 – Improvement

• Continual improvement of the ISMS (10.1)
• Nonconformities handled: correction, root cause analysis, corrective actions, check of effectiveness (10.2)

Annex A: the 93 controls in four themes

The 2022 version reorganised the controls: from 114 in the 2013 version, split into 14 domains, to 93 controls in four themes. Many controls were merged, and 11 are new.

The 11 new controls deserve attention, because they are often the ones missing for organisations coming from the 2013 version:

• 5.7 Threat intelligence, that is, collecting and analysing information about threats: see Threat Intelligence
• 5.23 Information security for use of cloud services
• 5.30 ICT readiness for business continuity: see Business continuity
• 7.4 Physical security monitoring
• 8.9 Configuration management
• 8.10 Information deletion
• 8.11 Data masking
• 8.12 Data leakage prevention
• 8.16 Monitoring activities
• 8.23 Web filtering
• 8.28 Secure coding

The technological controls are the ones where evidence is best produced with automated tools: asset inventory, vulnerability management, access logging. For privileged access logs, see the guide on system administrator logs.

Risk assessment and the Statement of Applicability

Risk management is at the heart of the standard. Clause 6.1.2 asks for a risk assessment process that produces consistent, valid and comparable results when it is repeated: risk acceptance criteria and criteria for performing assessments, identification of risks to confidentiality, integrity and availability, an owner for every risk, analysis of consequences and likelihood, and evaluation against the criteria.

Clause 6.1.3 asks you to choose the treatment options and the controls needed, to compare them with Annex A so that none are overlooked, to draw up the treatment plan, and to obtain from the risk owners approval of the plan and acceptance of the residual risk. Risk Assessment is the tool you use to do this work and to repeat it.

The Statement of Applicability (SoA) is the document that links risks to controls. Under 6.1.3 d it contains:

• The necessary controls
• The justification for including them
• Whether or not the necessary controls are implemented
• The justification for excluding any Annex A controls

It is the first document the auditor opens, and the hardest to keep up to date: every time a risk or the status of a control changes, the SoA has to follow.

ISO 27001 mandatory documents

The standard uses the term "documented information". Some is explicitly required by the clauses; the rest you decide on yourself, when you consider it necessary for the effectiveness of the system (7.5.1 b). Here are the explicit ones.

Several Annex A controls, if you declare them applicable, bring further documents with them: for example topic-specific policies (5.1), the asset inventory (5.9), acceptable use rules (5.10), documented operating procedures (5.37), the incident response plan (5.24–5.26). For incident management you can start from the Incident Response module and the guide data breach: what to do in the 72 hours.

Internal audit and management review

These are the two requirements that set a management system apart from a collection of documents, and without them you cannot reach certification.

Internal audit (9.2)

• Audits at planned intervals, to check that the ISMS conforms to the requirements of the standard and to the organisation's own requirements, and that it is effectively implemented
• An audit programme with frequency, methods, responsibilities, planning requirements and reporting
• Criteria and scope defined for every audit
• Auditors chosen so as to ensure objectivity and impartiality
• Results reported to the relevant management

ISO 19011 is the reference guideline for conducting audits. The findings give rise to the nonconformities of clause 10.2.

Management review (9.3)

The inputs required by the standard are:

• The status of actions from previous management reviews
• Changes in internal and external issues
• Changes in the needs and expectations of interested parties
• Information security performance: nonconformities and corrective actions, monitoring and measurement results, audit results, fulfilment of objectives
• Feedback from interested parties
• The results of risk assessment and the status of the treatment plan
• Opportunities for continual improvement

As output, the review produces decisions on improvement opportunities and on any changes to the ISMS, which must be documented.

The transition from ISO 27001:2013

The three-year transition period from the 2013 version to the 2022 version ended on 31 October 2025. Since that date, certificates issued against the 2013 version are no longer valid. An organisation that did not complete the transition in time cannot simply update it: it has to go through a new initial certification against the 2022 version.

If someone still shows you an ISO 27001:2013 certificate, for example in a supplier's documentation, that certificate is no longer valid today. It is a check to include in your supplier qualification.

The certification path, stage by stage

Certification is issued by an accredited certification body; in Italy the accreditation body is Accredia. The typical path has these stages:

1. Gap analysis

   You measure the distance between the current situation and the requirements. That is what the self-assessment is for.

2. Design and implementation

   You define the scope, assess the risks, write policies and procedures, implement the controls and prepare the SoA.

3. Operation and internal check

   The system runs long enough to produce evidence. You carry out at least one full internal audit and one management review.

4. Stage 1 audit

   The body examines the documentation and checks that the system is ready: scope, risks, SoA, internal audit and management review.

5. Stage 2 audit

   The body checks on site that the system is implemented and effective, with interviews and evidence. For any nonconformities found, the body asks for corrections and corrective actions before deciding.

6. Certificate and maintenance

   The certificate is valid for three years, with periodic surveillance audits, usually annual, and a recertification audit when it expires.

Common mistakes

• Procedures copied from a template. The auditor asks people how they work: if the answer does not match the document, that is a nonconformity.
• An SoA written once and never updated. Controls declared "implemented" that nobody can show any more.
• Exclusions without justification. Every excluded control needs a reason, and the reason has to stand up against the risks.
• Risks without an owner. The standard asks for an owner for every risk, who formally accepts the residual risk.
• Internal audit carried out by whoever built the system. Auditors must be objective and impartial.
• A review that decides nothing. Minutes with no decisions as output do not satisfy 9.3.
• A scope that is too narrow. Certifying a perimeter that leaves out the services your customers buy makes the certificate of little use in customer security questionnaires.
• Evidence that goes out of date. Last year's training or a backup tested once do not prove that the control works today.

How Dottor Box helps

The Compliance and GRC module is modelled on ISO 27001: a catalogue of requirements and controls, procedures written in the platform with their revision history, audit cycles following ISO 19011 with a checklist generated from the standard, nonconformities with a cycle that does not close if the action proves ineffective, and management review minutes following 9.3 that become unchangeable once approved. The SoA is built from the status of the linked tasks, and your decision on an individual control always takes precedence; it exports to PDF along with the other compliance documents.

Risk Assessment covers clauses 6.1 and 8.2 with the comparison between inherent and residual risk, Training provides the course record for 7.2, and technical modules such as Vulnerability Assessment and Asset Management produce evidence for the technological controls. Dottor Marc, which develops the platform, is ISO/IEC 27001 certified: we have been through the same process ourselves.