Most failed or delayed ISO 27001 certifications are not caused by missing controls, but by an ISMS that exists on paper and has never run a full cycle before the auditor arrives. Certification bodies audit against ISO/IEC 27001:2022 (including Amendment 1:2024 on climate change), following ISO/IEC 17021-1 and ISO/IEC 27006-1:2024, in two stages: a Stage 1 review of documentation and readiness, then a Stage 2 audit of whether the ISMS actually operates. This template gives [Organisation] eight numbered sections of checks to complete before each stage, plus guidance on sequencing, evidence and common reasons auditors raise nonconformities. It is written for ISMS managers, GRC leads and security engineers preparing a first certification or a recertification, and for executives who need to know what "ready" means before signing a contract with a certification body.
How to use this template
- Replace text in square brackets, such as [Organisation], [ISMS manager], [Top management] and [Certification body], with your own terms.
- Work through the sections in order. Scope (section 1) and risk treatment (section 3) drive everything else, and an error there propagates into the Statement of Applicability and every later check.
- Mark each check as Met, Partly met or Not met, record where the evidence lives, and assign an owner and due date to every gap. Sections 1 to 5 must be Met before Stage 1; sections 6 to 8 must be Met before Stage 2.
- Clause references (4.1 to 10.2) and Annex A control numbers (5.1 to 8.34) refer to ISO/IEC 27001:2022. Confirm wording against your licensed copy of the standard; this template paraphrases and does not reproduce it.
- Always state the edition: ISO advises that organisations refer to certification as "certified to ISO/IEC 27001:2022" rather than "ISO 27001". The 2013 edition can no longer be certified to: accreditation bodies required certification bodies to finish moving their clients to the 2022 edition by 31 October 2025.
1. Scope, context and leadership (clauses 4 and 5)
- Internal and external issues relevant to the ISMS are documented (4.1), including a recorded decision on whether climate change is a relevant issue, as Amendment 1:2024 requires.
- Interested parties and their requirements are listed (4.2), including customers, regulators, cloud providers and any interested party with climate-related requirements, and the requirements the ISMS will address are identified.
- The ISMS scope is documented (4.3), naming the organisational units, locations, services and technology in and out of scope, and the interfaces and dependencies with activities performed by others, such as cloud platforms and managed service providers.
- The scope statement matches what will appear on the certificate and what sales teams tell customers.
- [Top management] has approved an information security policy (5.2) that includes objectives or a framework for setting them and commitments to meet requirements and to continual improvement.
- Roles and authorities are assigned and communicated (5.3), including a named [ISMS manager] responsible for reporting ISMS performance to top management.
- Top management can explain, in interview, why the ISMS exists, what it covers and how resources were provided (5.1).
2. Risk assessment methodology (clauses 6.1.1, 6.1.2 and 8.2)
- A documented risk assessment process defines risk acceptance criteria and criteria for performing assessments, so that repeated assessments produce consistent, valid and comparable results (6.1.2). See the Risk Register Template.
- Risks to confidentiality, integrity and availability within scope are identified, each with a named risk owner.
- Likelihood and consequence are assessed and the resulting risk level is compared with the acceptance criteria.
- Risk assets include identities and credentials, not only servers and data: service accounts, cloud IAM roles, API keys, OAuth integrations, CI/CD pipeline identities and certificates. See the Service Account Inventory Template.
- At least one complete risk assessment has been performed under the documented process, and its results are retained as documented information (8.2).
- The trigger for reassessment is defined: planned intervals and significant changes (new product, acquisition, cloud migration, adoption of AI agents).
3. Risk treatment and Statement of Applicability (clauses 6.1.3 and 8.3)
- A risk treatment plan selects options (modify, retain, avoid, share) and the controls needed for each risk, with owners and dates (6.1.3).
- Selected controls have been compared with Annex A (93 controls in four themes: organisational, people, physical, technological) to confirm no necessary control has been omitted.
- The Statement of Applicability lists every Annex A control with: whether it is necessary, the justification for inclusion, whether it is implemented, and the justification for any exclusion.
- SoA justifications trace to risks, legal or contractual requirements, not to "not applicable" with no reason. Exclusions of identity controls (5.15 Access control, 5.16 Identity management, 5.17 Authentication information, 5.18 Access rights, 8.2 Privileged access rights, 8.5 Secure authentication) are rarely defensible.
- Risk owners have approved the risk treatment plan and formally accepted residual risks; the approval is recorded and dated.
- Controls marked "implemented" in the SoA have evidence today. Controls still in progress are marked as planned, with dates, and are consistent with the treatment plan.
4. Objectives, resources and competence (clauses 6.2, 6.3, 7.1 to 7.5)
- Information security objectives are measurable where practicable, monitored, and have owners, resources, deadlines and an evaluation method (6.2). Example: "100% of production service accounts have a named owner and a rotation date by [date]".
- Changes to the ISMS are planned and recorded (6.3).
- Competence requirements for ISMS roles are defined and evidenced by training records, qualifications or experience (7.2). See the ISO 27001 Lead Auditor and Lead Implementer Guide.
- Staff and contractors are aware of the policy, their contribution and the consequences of not conforming (7.3); awareness training completion is recorded (Annex A 6.3).
- Documented information is controlled (7.5): version, owner, approval, review date, access and retention. Auditors will sample documents for out-of-date versions.
5. Annex A control evidence
- An asset inventory (5.9) covers information, hardware, software, cloud services and non-human identities, each with an owner.
- Access control (5.15) and access rights (5.18) are defined in policy and evidenced by joiner, mover and leaver tickets and completed access reviews covering human and non-human accounts. See the Access Review Checklist.
- Authentication information (5.17) is managed: secrets are stored in a secrets manager, rotated on schedule and after exposure, and repositories are scanned for leaked credentials. See the Secrets Management Guide.
- Privileged access (8.2) is restricted to named roles, approved, time-bound where possible and logged. See the Privileged Access Management Guide.
- Supplier controls (5.19 to 5.23) cover supplier agreements, ICT supply chain and cloud services, with suppliers ranked by criticality and reviewed. See the Vendor Security Assessment Template.
- Incident management controls (5.24 to 5.28) are documented and tested, including evidence collection and learning from incidents. See the Incident Response Plan Template.
- ICT readiness for business continuity (5.30) and backups (8.13) are tested, with restore results recorded.
- Technical vulnerability management (8.8), configuration management (8.9), logging (8.15), monitoring activities (8.16), cryptography (8.24) and change management (8.32) each have a procedure, an owner and at least one recent operating record.
6. Operation and records of the ISMS running (clause 8)
- Processes needed to meet requirements are planned and controlled (8.1), including outsourced processes such as managed detection and response.
- Risk assessments and treatment plans have been executed at least once under the documented process, with dated outputs (8.2, 8.3).
- The ISMS has operated long enough to produce records: most certification bodies want to see several months of operation before Stage 2, so that monitoring, access reviews and incidents have generated evidence.
- Control operating records can be produced as complete populations with timestamps (leavers, changes, incidents, service accounts created), because auditors sample from them.
7. Performance evaluation and improvement (clauses 9 and 10)
- Monitoring and measurement (9.1) define what is measured, how, when, by whom and when results are analysed; results are retained.
- An internal audit programme (9.2) is planned and at least one internal audit covering all ISMS clauses and the applicable Annex A controls is complete, performed by auditors who did not audit their own work.
- Internal audit findings are recorded with nonconformities, root cause and corrective actions (10.2), and the corrective actions are progressing or closed.
- A management review (9.3) has been held with documented inputs (status of previous actions, changes in issues, interested party feedback, nonconformities, monitoring results, audit results, risk assessment results, improvement opportunities) and decisions.
- Continual improvement (10.1) is visible in at least one change made because of measurement, audit or incident.
8. Certification body, audit logistics and Stage 2 readiness
- [Certification body] is accredited for ISO/IEC 27001 by a national accreditation body that is an IAF signatory, and its accreditation scope covers your sector.
- Independence is confirmed: an accredited certification body will not certify a management system that its own group consulted on, so readiness help and certification come from separate organisations.
- Scope, number of sites, headcount and audit duration are agreed in the contract; the scope on the application matches section 1.
- Stage 1 findings, including any areas of concern that could become nonconformities at Stage 2, are closed or have a plan agreed with the auditor.
- Interviewees (top management, risk owners, control owners, ISMS manager) are briefed and available on the audit dates; system access for live demonstrations is arranged.
- An evidence index maps each clause and SoA control to its evidence location. See the Compliance Automation Guide.
- A process exists to respond to nonconformities within the period [Certification body] sets: correction and corrective action plans for minor findings, and evidence of closure for major findings, which must be resolved before the certificate is issued.
Implementation guidance
What each audit stage tests. The table summarises the certification cycle. Exact durations and response deadlines are set by your certification body.
| Stage | What the auditor does | What must be ready | Typical outcome |
|---|---|---|---|
| Stage 1 | Reviews documented information and readiness, scope and site specifics; decides whether to proceed | Sections 1 to 5: scope, policy, risk method, risk assessment, treatment plan, SoA, evidence plan | Report of concerns to resolve; Stage 2 date confirmed or a further Stage 1 needed (rare) |
| Stage 2 | Tests conformity and effectiveness by interview, record review and observation, sampling SoA controls | Sections 6 to 8: operating records, internal audit, management review, corrective actions | Recommendation for certification, subject to closing nonconformities |
| Surveillance | Annual audits in years two and three, sampling a subset of clauses and controls | Continued operation, closed findings, updated risk assessment | Certificate maintained |
| Recertification | Full system audit before the three-year certificate expires | Evidence of continual improvement over the cycle | New three-year certificate |
Sequencing for a first certification:
- Months 1 to 2: sections 1 and 2. Agree scope with [Top management], write the risk method, and build the asset and identity inventory.
- Months 2 to 4: section 3. Run the risk assessment, write the treatment plan and SoA, and start remediating the gaps that carry the highest risk.
- Months 3 to 6: sections 4 and 5. Write policies and procedures, deploy tooling, start collecting records. Select and contract the certification body.
- Months 5 to 7: sections 6 and 7. Let controls operate, then run the internal audit and the management review.
- Stage 1, then Stage 2 after the gap the certification body proposes. If Stage 1 raises concerns, fix them rather than pushing Stage 2 forward.
Common reasons for nonconformities (from practitioner experience, NHI Mgmt Group interpretation):
| Finding | Clause or control | Prevention |
|---|---|---|
| SoA exclusions without justification, or "implemented" with no evidence | 6.1.3 | Section 3 checks; tie every line to a risk or requirement |
| Internal audit incomplete or auditing own work | 9.2 | Use an independent internal or external auditor; cover every clause |
| Management review missing required inputs | 9.3 | Use a fixed agenda listing every input |
| Access reviews exclude service accounts and API keys | 5.18, 8.2 | Include non-human identities in the same review population |
| Climate change not considered | 4.1 (Amd 1:2024) | Record the decision and rationale in the context document |
| Uncontrolled documents (old versions, no owner) | 7.5 | One document register with version and review date |
Small versus large organisations. A small organisation with one cloud platform can often be ready in six to nine months with a narrow, honest scope and a lightweight document set. Where SOC 2, PCI DSS or NIST CSF programmes already exist, map their evidence to Annex A to avoid collecting it twice. See the NIST CSF to ISO 27001 Mapping Guide, the PCI DSS 4.0 to ISO 27001 Mapping Guide and the SOC 2 Readiness Checklist.
Metrics to track readiness: percentage of checks Met per section; open gaps by owner and age; SoA controls with current evidence; non-human identities with an owner and rotation date; internal audit nonconformities closed on time; and days since the last management review.
References: ISO: ISO/IEC 27001:2022 Information security management systems, Requirements · ISO and IAF: Joint Communiqué on climate change amendments · ISO: ISO/IEC 27006-1:2024 Requirements for ISMS certification bodies · ISO: ISO/IEC 17021-1:2015 Conformity assessment · UKAS: Transition arrangements for ISO/IEC 27001:2022 · INAB: Transition requirements for ISO/IEC 27001:2022 · A-LIGN: ISO 27001 certification process
This template is provided for guidance and must be adapted to your organisation; it does not replace the judgement of your certification body. Related NHI Mgmt Group resources: ISO 27001 Certification Guide · ISO 27002 Controls Guide · Information Security Policy Template · Control Mapping Guide · Service Account Security Guide