ISO 27001 is the global benchmark for information security management, and in 2026 it is increasingly non-optional. Enterprise clients demand it as a vendor qualification criterion. Government contracts require it. Cyber insurance underwriters use it as a risk indicator, and in some sectors it now determines whether coverage is available at all.
The scale of the challenge is real: 93 Annex A controls, mandatory documented procedures, a formal risk assessment, a Statement of Applicability, internal audits, and two stages of external audit before a certificate is issued. For an IT manager who has just been told "we need ISO 27001," that can feel like an impenetrable wall of requirements.
This guide cuts through the complexity with a practical, phase-by-phase checklist — from initial gap assessment through certification and beyond. It covers the structure of the standard, what every mandatory document actually needs to say, how the risk assessment process works, what auditors look for, the most common nonconformities and how to avoid them, and the recurring tasks that keep your ISMS alive and audit-ready between certification cycles.
What Is ISO 27001?
ISO/IEC 27001 is the international standard for Information Security Management Systems (ISMS). Published jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), it specifies the requirements for establishing, implementing, maintaining, and continually improving a systematic approach to managing information security risks. It applies to organisations of any size and in any industry.
What certification proves. ISO 27001 certification — issued by an accredited external certification body after a formal audit — demonstrates that an organisation has a functioning ISMS that meets the requirements of the standard. It does not certify that you have zero security incidents or zero vulnerabilities. It certifies that you have a systematic, documented, and verified approach to identifying security risks and managing them. That distinction matters: certification is evidence of a process, not a guarantee of a state.
Why it matters in 2026. IT companies hold the highest number of ISO 27001 certificates globally — almost one in five valid certificates is held by an IT organisation. Enterprise procurement increasingly includes ISO 27001 as a vendor selection criterion. Government contracts often require it. Enterprise cyber insurance underwriters use it as a risk indicator. For MSPs and IT service providers, ISO 27001 has moved from "nice to have" to a competitive necessity in many market segments.
ISO 27001 in numbers: 93 Annex A controls. 4 control domains. Mandatory requirements in clauses 4–10. One internationally recognised certificate. Three-year certification cycle with annual surveillance audits.
ISO 27001:2022 — What Changed from the 2013 Version
Many guides still reference the 2013 structure. Since all new certifications are now issued against the 2022 standard — and the transition deadline for existing certificates was October 2025 — IT teams need to know what is current.
Control restructuring. The 2013 version had 114 controls organised across 14 domains. ISO 27001:2022 restructured these into 93 controls across 4 thematic domains: Organisational (A.5 — 37 controls), People (A.6 — 8 controls), Physical (A.7 — 14 controls), and Technological (A.8 — 34 controls). Most of the 2013 controls were consolidated or merged rather than removed — the reduction reflects rationalisation, not a weakening of requirements.
The 11 new controls. ISO 27001:2022 introduced 11 new controls that did not exist in the 2013 version, reflecting the evolution of the threat landscape and the technology environment: A.5.7 (Threat intelligence), A.5.23 (Information security for use of cloud services), A.5.30 (ICT readiness for business continuity), A.7.4 (Physical security monitoring), A.8.9 (Configuration management), A.8.10 (Information deletion), A.8.11 (Data masking), A.8.12 (Data leakage prevention), A.8.16 (Monitoring activities), A.8.23 (Web filtering), and A.8.28 (Secure coding).
Clause changes. The core clauses (4–10) were updated to align with the ISO Harmonized Structure used by ISO 9001, ISO 14001, and other management standards — primarily to make integrated management system implementation easier. There were no major structural changes to the underlying requirements.
Transition. All organisations certified under ISO 27001:2013 were required to transition to the 2022 standard by October 2025. New certifications are issued only against the 2022 standard.
Key numbers: 2013: 114 controls, 14 domains. 2022: 93 controls, 4 domains, 11 new controls. Transition deadline: October 2025.
The Structure of ISO 27001
ISO 27001 has two main components. Clauses 4–10 contain the mandatory requirements for the ISMS management system itself — how it must be set up, governed, monitored, and improved. Annex A contains the reference control set — 93 security controls that organisations select from (based on their risk assessment) to address the risks they have identified.
Clause 4 (Context) requires you to understand the organisation, its interested parties (customers, regulators, staff), and the internal and external factors that affect information security. You define the scope of the ISMS here.
Clause 5 (Leadership) requires top management to demonstrate commitment to the ISMS, establish an information security policy, and assign roles and responsibilities. Senior sign-off is mandatory, not optional.
Clause 6 (Planning) is where you conduct the risk assessment, determine how to treat risks, produce the Statement of Applicability, and set measurable information security objectives. The risk assessment drives everything that follows.
Clause 7 (Support) covers the resources, competence, awareness, and communication required to run the ISMS. Managing documented information — the full ISMS document set — is a Clause 7 requirement.
Clause 8 (Operation) is the implementation clause: execute the risk treatment plan, deploy controls, manage operational processes. This is where the documented ISMS becomes a functioning system.
Clause 9 (Performance Evaluation) requires you to monitor, measure, and evaluate the ISMS. Conduct internal audits. Perform management review. Produce evidence that the ISMS is working.
Clause 10 (Improvement) requires you to address nonconformities with root cause analysis and corrective action, and to continually improve the ISMS.
Unlike the clauses — which are mandatory in their entirety — Annex A controls are applied selectively. You implement the controls relevant to the risks you have identified. However, any exclusion must be justified in the Statement of Applicability. In practice, the vast majority of controls apply to most organisations.
Who Needs ISO 27001 Certification?
ISO 27001 is voluntary — there is no law in most jurisdictions that mandates it. But it becomes effectively mandatory through four routes.
Contractual requirements. Enterprise clients increasingly require ISO 27001 certification from IT suppliers, SaaS providers, and MSPs as part of vendor risk management. If you supply services to a large financial services firm, healthcare organisation, or government department, you may find ISO 27001 on the shortlist or disqualification criteria for their procurement process.
Supply chain pressure. If your customers are themselves ISO 27001 certified, they are required under Annex A control A.5.19 (Supplier Relationship Management) to assess and manage the security of their suppliers. Holding your own ISO 27001 certificate is often the most efficient way to satisfy that requirement.
Regulatory overlap. While ISO 27001 is not the same as regulatory compliance, organisations subject to GDPR, NIS2, DORA (financial sector), or sector-specific regulations often use ISO 27001 as the framework for demonstrating the "technical and organisational measures" those regulations require.
Cyber insurance. Cyber insurers are increasingly using ISO 27001 certification — or alignment with its requirements — as a risk assessment factor. Certification may result in lower premiums or improve your ability to obtain coverage above certain thresholds.
Industries with the highest adoption include IT services (the largest sector by certificate count), financial services, healthcare, telecommunications, defence supply chains, and government contractors. Mid-market IT services companies and MSPs are among the fastest-growing certification segments.
If you are a small team with no enterprise clients requiring certification, no regulatory obligations, and no near-term plans to pursue formal audit, ISO 27001 compliance without certification may be a more proportionate goal — implementing the framework's controls without incurring external audit costs.
The ISO 27001 Implementation Checklist
Implementation follows eight phases, from initial gap assessment to certification audit. Each phase builds on the one before it — skipping or rushing an early phase creates problems that surface later, usually at the worst possible moment.
Gap Assessment
Before committing resources, assess where you actually stand. A gap assessment compares your current information security practices against the requirements of ISO 27001:2022 — clauses 4–10 and all 93 Annex A controls — and produces a prioritised list of what needs to be built, fixed, or documented. A structured gap assessment tool or template maps each requirement to your current state: in place, partially in place, or missing. Most organisations find they have informal security practices already in place but lack the documentation, structure, and evidence that ISO 27001 demands. The gap is usually not as large as it looks — but it must be quantified before you can plan realistically. The output of the gap assessment becomes your project plan.
Define the ISMS Scope
The scope defines what is covered by your ISMS — which systems, locations, processes, and business units are included. This is a critical decision: too broad and the certification effort becomes unmanageable; too narrow and it lacks credibility with clients and auditors. Document the scope statement formally (Clause 4.3). It must describe the boundaries of the ISMS in terms of the information it protects, the systems it covers, and the interfaces with external parties outside the scope. A common first-certification strategy for larger organisations is to scope tightly — the IT services business unit, for example — and expand in subsequent recertification cycles.
Risk Assessment
The risk assessment is the analytical core of ISO 27001 — everything else flows from it. Your risk assessment methodology must be documented: what assets are in scope, how threats and vulnerabilities are identified, how risk is scored, and what the acceptance criteria are. Conduct the assessment: inventory your information assets, identify the threats and vulnerabilities applicable to each, score each risk for likelihood and impact, and produce a risk register. ISO 27001 does not prescribe a specific scoring method, but whatever method you choose must be applied consistently across all assets. The risk register drives your Statement of Applicability and risk treatment plan — treat it as a living document that is reviewed at least annually or whenever significant changes occur.
Statement of Applicability (SoA)
The Statement of Applicability is your formal declaration of which Annex A controls apply to your organisation, which do not, and why. For each of the 93 controls, document: applicable or not applicable, the justification for the decision, and (for applicable controls) how the control is implemented. The SoA must link to your risk treatment plan — controls that mitigate identified risks should be clearly connected. Controls can also be included for legal, regulatory, or contractual reasons, not just risk reasons. A weak SoA — missing justifications, controls marked not applicable without credible reasoning, or controls listed as implemented without evidence — is one of the most common causes of major audit nonconformities.
Develop Your Mandatory Documentation
ISO 27001 requires a specific set of documented policies, procedures, and records. The core mandatory documents are the ISMS scope, information security policy, risk assessment methodology, risk assessment results, Statement of Applicability, risk treatment plan, information security objectives, and competence records. Beyond these explicitly required documents, you will need supporting policies covering the controls you have identified as applicable — typically access control, change management, incident management, backup, cryptography, supplier security, and business continuity. These policies do not need to be long or complex — they need to clearly describe the requirements, assign ownership, and be actively followed. A two-page access control policy that is consistently enforced beats a twenty-page policy that nobody reads.
Implement Controls
Deploy the Annex A controls identified in your SoA. This phase involves technical implementation (configuring systems, enabling logging, deploying access controls, vulnerability scanning) and organisational implementation (training staff, establishing procedures, formalising supplier agreements). Start with your highest-risk items from the risk register — these are the controls that will have the most impact on your security posture and are most likely to be scrutinised in audit. Keep an evidence trail as you implement: screenshot configurations, save training completion records, log supplier security assessments. The audit will ask you to demonstrate that controls are implemented, not just documented.
Conduct Internal Audit and Management Review
Before the external certification audit, you must complete at least one internal audit (Clause 9.2) and one management review (Clause 9.3). The internal audit should cover all clauses and controls in scope, be conducted by someone independent of the areas being audited, and produce a formal audit report with findings. Management review requires top management to formally assess the ISMS — reviewing audit results, risk assessment outputs, security incidents, and objectives performance — and produce documented minutes. Both are mandatory, and evidence of both will be requested in Stage 1. Many certification failures trace back to organisations that skipped or rushed these steps.
Certification Audit — Stage 1 and Stage 2
Stage 1 is a documentary review: the auditor assesses your ISMS documentation for completeness, checks your scope, reviews your SoA, and determines whether your ISMS is sufficiently developed to proceed to Stage 2. This typically takes 0.5–1.5 days and is often conducted remotely. If significant gaps are found, Stage 2 is delayed while you address them. Stage 2 is the implementation audit: the auditor verifies that your documented controls are actually working — interviewing staff, reviewing evidence, testing processes. This typically takes twice as long as Stage 1. Minor nonconformities identified in Stage 2 can typically be addressed with a corrective action plan; major nonconformities require re-audit of the affected areas before the certificate can be issued.
Run Your ISO 27001 Controls on Schedule
CheckFlow's recurring compliance templates schedule the key ISO 27001 recurring tasks automatically — access reviews, patch checks, training verification, incident reviews — with task assignment, completion tracking, and an audit-ready evidence trail.
Browse Compliance TemplatesAnnex A Controls: A Guide to All Four Domains
ISO 27001:2022 Annex A organises its 93 controls into four thematic domains. Understanding what each domain covers — and which controls within each domain are most commonly scrutinised — is essential groundwork before you can build a credible SoA.
Organisational Controls (A.5 — 37 controls)
The organisational domain is the broadest, covering policies, procedures, and management practices — everything that doesn't fit neatly into people, physical, or technology. It directly reflects whether information security is embedded into how the organisation operates. Key controls include A.5.1 (Policies for information security — the ISMS policy and the supporting policy set), A.5.9 (Inventory of information and other associated assets — the asset register that underpins your risk assessment), A.5.19 (Information security in supplier relationships — formal assessment and contractual obligations for third parties), A.5.23 (Information security for use of cloud services — new in 2022, requires explicit security requirements for cloud providers including AWS, Azure, and SaaS vendors), and A.5.24 (Information security incident management planning — a formalised incident detection, response, and reporting procedure).
People Controls (A.6 — 8 controls)
The people domain is the smallest by control count but represents some of the most significant security risk in practice. Human error, social engineering, and insider threat are consistently among the leading causes of security incidents — and people controls are how you manage that exposure. Key controls include A.6.1 (Screening — background checks appropriate to role sensitivity), A.6.2 (Terms and conditions of employment — security responsibilities formally included in employment contracts), A.6.3 (Information security awareness, education, and training — a structured, regularly updated training programme with documented completion records), and A.6.5 (Responsibilities after termination or change of employment — ensuring security obligations survive the employment relationship, and that access is revoked systematically on departure).
Physical Controls (A.7 — 14 controls)
Physical controls govern the security of the environments where information is processed and stored — offices, data centres, server rooms, and remote working locations. A.7.1 (Physical security perimeters — defined boundaries for secure areas), A.7.2 (Physical entry — access controls to secure areas including visitor management), A.7.4 (Physical security monitoring — new in 2022, requiring monitored oversight of physical premises), and A.7.9 (Security of assets off-premises — laptops, mobile devices, and removable media used outside secure perimeters) are the most commonly assessed. For fully remote organisations, the physical domain typically has fewer applicable controls, but those that do apply — particularly around endpoint device security — must still be formally addressed in the SoA.
Technological Controls (A.8 — 34 controls)
The largest and most technically detailed domain, covering the full range of IT security measures. Particularly important controls include A.8.2 (Privileged access rights — management of admin and elevated privileges, including review and recertification), A.8.7 (Protection against malware — anti-malware controls with detection, response, and awareness components), A.8.8 (Management of technical vulnerabilities — regular scanning and patching with defined remediation SLAs), A.8.15 (Logging — event logging, retention periods, and protection against tampering), A.8.24 (Use of cryptography — policy covering encryption standards, key management, and applicable use cases), and A.8.28 (Secure coding — new in 2022, applicable to any organisation that develops or customises software). This domain is where most technical gap assessments find the largest number of partially-implemented controls.
ISO 27001 Mandatory Documentation
ISO 27001 is more document-intensive than it needs to be if you approach it wrong, and less document-intensive than people expect if you approach it right. The standard requires specific documented information — not long, complex documents, but clear, current, owned documents that prove your ISMS is real and operating.
| Document | ISO 27001 Reference |
|---|---|
| ISMS Scope | Clause 4.3 |
| Information Security Policy | Clause 5.2 |
| Information Security Objectives | Clause 6.2 |
| Risk Assessment Methodology | Clause 6.1.2 |
| Risk Assessment Results / Risk Register | Clause 6.1.2 |
| Statement of Applicability (SoA) | Clause 6.1.3(d) |
| Risk Treatment Plan | Clause 6.1.3(e) |
| Competence Records / Training Records | Clause 7.2 |
| Internal Audit Programme and Reports | Clause 9.2 |
| Management Review Minutes | Clause 9.3 |
| Evidence of Monitoring and Measurement | Clause 9.1 |
| Corrective Action Records | Clause 10.2 |
Beyond these explicitly required documents, most organisations also maintain supporting policies — access control, incident management, change management, backup, supplier security, business continuity — because these are expected by auditors as evidence that Annex A controls are implemented. The critical principle applies to all of them: every document must have a named owner, a version number, a review date, and an actual reader. Policies that exist only as files in a shared drive do not satisfy the requirement. The standard requires documented information to be controlled, maintained, and available to the people who need it.
The ISO 27001 Risk Assessment Process
ISO 27001 does not prescribe a specific risk assessment methodology — it requires that you define and document your own. That methodology must specify how you identify risks, how you score them, what your risk acceptance criteria are, and how you decide on treatment. The key requirement is consistency: whatever approach you choose must be applied systematically across all in-scope assets. The five-stage process below covers everything the standard requires.
Stage 1 — Asset inventory. Document all information assets in scope — hardware (servers, endpoints, network devices), software systems, data assets (databases, file stores, cloud data), people with privileged access, and service dependencies (third-party providers, cloud platforms). For each asset, record what information it holds or processes, who owns it, and what would happen to the business if it were compromised, unavailable, or disclosed without authorisation. This asset register is also required as a control (A.5.9) and forms the foundation of your risk assessment — every subsequent step references it.
Stage 2 — Threat and vulnerability identification. For each asset, identify the realistic threats (unauthorised access, ransomware, misconfiguration, hardware failure, insider misuse, third-party breach) and the vulnerabilities those threats could exploit (unpatched software, weak access controls, absence of MFA, lack of encryption, inadequate logging). You don't need to catalogue every theoretical threat — focus on those that are plausible given your specific environment, sector, and asset profile.
Stage 3 — Risk scoring. Score each identified risk using a consistent matrix — typically likelihood (1–5) × impact (1–5) = risk score (1–25). Assign a risk rating category (low, medium, high, critical) to each score range. Document the scoring criteria so the scale is applied consistently across all assets. ISO 27001 does not require a quantitative monetary approach — a well-documented qualitative assessment is acceptable and often more practical for SMEs.
Stage 4 — Risk treatment decision. For each risk above your acceptance threshold, decide how to treat it. Mitigate — implement a control from Annex A or an equivalent measure. Accept — formally acknowledge and document the residual risk, with sign-off from an appropriate level of management. Transfer — insurance or contractual allocation of risk. Avoid — change the process or activity that generates the risk. Record the treatment decision, the selected controls, the responsible owner, and the target completion date in the risk treatment plan.
Stage 5 — Risk register and ongoing review. The risk register is a living document. Review it at least annually, and whenever significant changes occur — new systems, new services, significant incidents, changes in the threat landscape. ISO 27001 requires that risk assessment results and risk treatment plans are documented and retained. The retention of previous versions is also good practice — it demonstrates the ISMS is actively managed over time, not just refreshed before audit.
The ISO 27001 Certification Audit Process
Choosing a certification body. Choose an accredited certification body — accredited by a national accreditation body (UKAS in the UK, DAkkS in Germany, ANAB in the US). Accreditation is what makes the certificate internationally recognised. Get quotes from two or three bodies — audit day rates and scope interpretations vary more than most organisations expect.
Stage 1 — Documentary review. The Stage 1 audit is primarily a desk review. The auditor assesses your ISMS documentation: is the scope clearly defined, does the SoA cover all 93 controls with justifications, is the risk assessment documented and complete, are mandatory policies in place? Stage 1 typically takes 0.5–1.5 days depending on scope complexity and is frequently conducted remotely. The auditor produces a Stage 1 report identifying any issues that must be resolved before Stage 2 can proceed. Fundamental gaps may require Stage 2 to be rescheduled; areas where documentation is weak are noted as observations.
Stage 2 — Implementation audit. Stage 2 verifies that the ISMS documented in Stage 1 is actually operating as described. Auditors interview staff at various levels, review evidence of control implementation, test processes, and look for the gap between what is documented and what is happening in practice. Stage 2 typically lasts twice as long as Stage 1. Findings are classified as major nonconformities (must be resolved and verified before the certificate is issued), minor nonconformities (a corrective action plan is required, verified at the next surveillance audit), or observations (recommendations without a formal requirement to act).
Certification, surveillance, and recertification. If no major nonconformities remain unresolved, the certificate is issued. ISO 27001 certificates are valid for three years. Surveillance audits are conducted in Year 1 and Year 2 — typically a one-day review of a subset of your ISMS to verify continued compliance. Year 3 brings a full recertification audit, similar in scope to the original certification audit. The cycle then restarts. Each surveillance audit will ask for evidence of ongoing control operation since the previous audit — which is exactly why the recurring tasks in Section 11 of this guide are critical.
Common ISO 27001 Audit Failures — and How to Avoid Them
Mistake 1: No clearly defined risk management procedure (Clause 6.1.2). The most common nonconformity across certification audits. Organisations document a risk register but cannot produce a written risk management procedure explaining how they identify assets, score threats, set acceptance criteria, and decide on treatment. Without the procedure, the auditor cannot verify that the risk assessment is systematic rather than ad-hoc. Fix: Write a short (2–4 page) risk management procedure before your internal audit. It does not need to be complex — it needs to be documented, actively followed, and reviewed on a defined schedule.
Mistake 2: Statement of Applicability lacking justifications (Clause 6.1.3(d)). The SoA is present, but controls are marked "not applicable" without credible written justification, or applicable controls are listed without explaining how they are implemented. Fix: For every excluded control, write a clear business or risk-based justification. For example: "A.7.4 Physical security monitoring: not applicable — organisation operates fully remotely with no physical server infrastructure." For applicable controls, link to the implementing policy, procedure, or technical configuration.
Mistake 3: No completed internal audit or management review (Clauses 9.2, 9.3). The certification audit finds no evidence that an internal audit was completed in the past 12 months, or that management formally reviewed the ISMS. These are not optional activities — they are mandatory requirements. Fix: Schedule and complete both before the certification audit. The internal audit must produce a written report with findings. The management review must produce written minutes with attendance, topics reviewed, and decisions reached.
Mistake 4: No measurable ISMS performance metrics (Clause 9.1). The ISMS has no defined KPIs, making it impossible to demonstrate that it is effective or improving. The standard explicitly requires that you determine what needs to be monitored and measured, and when results will be analysed. Fix: Define at least four to six measurable security objectives and metrics: percentage of staff completing annual security awareness training, number of security incidents per quarter, number of open risk treatment items past their due date, percentage of high and critical vulnerabilities remediated within SLA, and mean time to detect and contain incidents.
Mistake 5: Poor incident management documentation (Control A.5.24). Incidents are handled informally, with no written procedure for detection, classification, reporting, escalation, and post-incident review. Previous incidents are not documented, making trend analysis impossible. Fix: Write an incident management procedure with clearly defined roles, escalation paths, and severity classifications. Log all security events — even minor ones. Conduct and document post-incident reviews for all significant incidents. The recurring checklist pattern works well here: a structured incident response checklist that runs every time an incident is declared ensures the procedure is followed and the record is created automatically.
Mistake 6: Access rights not reviewed (Controls A.8.2, A.8.3). Access rights have never been formally reviewed, privileged access has expanded without approval, and former employees or contractors still have active accounts. Fix: Conduct a full access review before the certification audit. Establish a quarterly recurring access review process with named owners per system. Document the review outcome, the changes made, and the sign-off. Access reviews are one of the items surveillance auditors check every year — if the quarterly cadence has not been maintained, nonconformities will follow.
Mistake 7: Supplier security not managed (Control A.5.19). Key third-party suppliers — cloud providers, IT vendors, subcontractors with access to client data — have no formal security assessment, no security clauses in contracts, and no offboarding process when the relationship ends. Fix: Create a supplier register that categorises suppliers by risk level. For high-risk suppliers (those with access to sensitive data or systems), require evidence of ISO 27001, SOC 2, or equivalent. Include security requirements in all supplier contracts. Conduct and document annual supplier security reviews.
Mistake 8: Documentation-reality gap (general — affects all clauses). The ISMS documentation is excellent; the actual practice bears little resemblance to what is documented. Controls are "implemented" on paper but not operating in practice. Fix: Design your ISMS to reflect what you actually do, not what you aspire to do. If you cannot commit to monthly vulnerability scans, do not document a monthly vulnerability scanning procedure. Under-promise and over-deliver — an ISMS that actually works at a simpler scope beats an ambitious ISMS that exists only in policies.
Ongoing ISO 27001 Compliance: The Recurring Tasks
Many organisations invest heavily in achieving ISO 27001 certification and then allow the ISMS to atrophy between audits. Controls that were working at certification gradually degrade. The risk register goes unreviewed. Access reviews are skipped. Training completion rates fall. By the time the surveillance audit arrives, there is a scramble to reconstruct evidence that was never properly captured. ISO 27001 is not a point-in-time achievement — it is an operating system for security management that must run continuously.
| Frequency | Task | ISO 27001 Reference | Output / Evidence Required |
|---|---|---|---|
| Monthly | Vulnerability scan and patch review | A.8.8 | Scan report, patch log, exception register |
| Monthly | Security event log review | A.8.15, A.8.16 | Review record, anomalies investigated |
| Monthly | Backup verification check | A.8.13 | Backup completion log, test restoration record |
| Quarterly | User access rights review | A.8.2, A.8.3 | Access review report, changes logged |
| Quarterly | Supplier security review (high-risk suppliers) | A.5.19 | Review record, any required actions |
| Quarterly | Risk register review | Clause 6.1.2 | Updated risk register with review date |
| Quarterly | ISMS performance metrics review | Clause 9.1 | Metrics report, management communication |
| Annually | Full risk assessment | Clause 6.1.2 | Risk assessment report, updated risk register |
| Annually | Internal audit | Clause 9.2 | Audit programme, audit report, findings log |
| Annually | Management review | Clause 9.3 | Management review minutes |
| Annually | Policy review (all ISMS policies) | Clause 7.5 | Updated policies with version and review date |
| Annually | Security awareness training | A.6.3 | Training completion records for all staff |
| Annually | Business continuity test | A.5.30 | Test report, lessons learned |
| Annually | Statement of Applicability review | Clause 6.1.3 | Updated SoA with review date |
The evidence column is the critical column. Each of these tasks must not only be completed — it must produce a documented record that can be retrieved on demand when an auditor asks for it. Manual tracking of 14 or more recurring compliance tasks across a team is the single point where ongoing ISO 27001 compliance most commonly breaks down. Recurring checklists — scheduled workflows that assign each task to a named individual, enforce completion, and generate an audit-ready record — are the practical solution to this problem.
How ISO 27001 Maps to Other Frameworks
ISO 27001 does not exist in isolation. Most organisations implementing it are also subject to GDPR, increasingly to NIS2, and may face customer requirements for SOC 2. Understanding where these frameworks overlap — and where they diverge — allows you to build a single control library that satisfies multiple obligations rather than running parallel compliance programmes.
ISO 27001 and SOC 2
Significant control overlap, different audiences. ISO 27001 is an international management system standard applicable to any organisation; SOC 2 is a US auditing standard focused specifically on service organisations. An ISO 27001 ISMS addresses most of the SOC 2 Trust Service Criteria control requirements, particularly for the Security TSC. However, SOC 2 Type II requires an auditor to test controls over a defined observation period — typically six to twelve months — whereas ISO 27001 certification is a point-in-time verification of system maturity. Holding ISO 27001 certification dramatically reduces the effort required to achieve SOC 2 compliance but does not eliminate it.
ISO 27001 and GDPR
ISO 27001 is not a GDPR compliance framework, but it directly addresses GDPR's requirement for "appropriate technical and organisational measures" to protect personal data. Annex A controls covering access management, encryption, incident management, and supplier security align closely with GDPR obligations under Articles 25 and 32. ISO 27001 certification is not evidence of GDPR compliance — GDPR compliance also covers lawful basis, data subject rights, and records of processing that are outside ISO 27001's scope — but it substantially demonstrates that the organisation has a systematic approach to information security that data protection authorities regard favourably.
ISO 27001 and NIS2
NIS2 (the EU Network and Information Security Directive 2) requires essential and important entities in critical sectors to implement risk management measures, security policies, access control, incident reporting, and supply chain security measures. ISO 27001:2022 covers most of these requirements, particularly through its risk management framework and the Annex A controls for incident management (A.5.24), supplier relationships (A.5.19), and access control (A.8.2–A.8.5). However, NIS2 compliance is a legal obligation with its own enforcement mechanism and specific incident reporting timelines — ISO 27001 certification evidences the underlying security programme but does not constitute NIS2 compliance by itself.
ISO 27001 and Cyber Essentials
Cyber Essentials is a UK government-backed scheme focusing on five basic technical controls: firewalls, secure configuration, user access control, malware protection, and patch management. ISO 27001 is broader and more comprehensive in scope. For organisations on a compliance journey, Cyber Essentials is an effective entry point — it addresses a well-defined subset of ISO 27001 Annex A technological controls and builds the technical hygiene baseline that ISO 27001 requires. Many UK organisations pursue Cyber Essentials or Cyber Essentials Plus first, then ISO 27001. The two are complementary rather than competing.
Free ISO 27001 Compliance Checklist Templates
Running ISO 27001 compliance manually is how teams fall behind between audits. CheckFlow includes ready-to-use compliance checklist templates — covering ISO 27001, ISO 9001, HIPAA, FISMA, FedRAMP, and ICD-705 — that schedule recurring control tasks automatically, assign them to named individuals, and produce a timestamped audit trail. Click any card to explore the full template.
How CheckFlow Supports Ongoing ISO 27001 Compliance
ISO 27001 certification is achieved at a point in time. The ISMS must then be operated continuously until the next surveillance audit — which means executing a calendar of recurring tasks, generating evidence for each one, and maintaining it in a form that can be presented on demand. This is where most organisations struggle: not the initial build, but the ongoing run.
CheckFlow converts recurring ISO 27001 compliance tasks into structured, scheduled workflows. Each task is a checklist that triggers automatically on the correct schedule — monthly vulnerability review, quarterly access audit, annual policy review — is assigned to the named person responsible for that control, requires specific evidence to be captured (scan results entered, access lists reviewed, exceptions documented), and produces a timestamped completion record for every run.
The result is an automated evidence trail that covers the recurring tasks listed in the ongoing compliance table above. When the surveillance auditor arrives and asks for evidence of the last four quarterly access reviews, CheckFlow generates a retrieval in seconds: four completion records, each showing who reviewed what, when, and what actions were taken. The question "can you prove this control ran?" has an immediate, documentable answer.
CheckFlow is not a GRC platform — it does not replace your risk register, SoA, or policy documentation. It is the execution layer: the tool that ensures the controls documented in your ISMS are actually running, on schedule, by the right people, with evidence. That distinction — between a control existing on paper and a control executing in practice — is exactly what ISO 27001 auditors are testing for. For a deeper look at how recurring checklist software supports a continuous compliance programme, see our guide to recurring checklists for IT teams.
Automate Your ISO 27001 Evidence Trail
Stop scrambling for audit evidence. CheckFlow turns your recurring ISO 27001 tasks into scheduled, tracked, evidence-producing workflows — so every control run is documented automatically.
Start Free Trial Book a DemoFrequently Asked Questions
For most organisations, ISO 27001 implementation takes 6–18 months from starting work to receiving a certificate. The wide range reflects significant differences in starting point (existing security maturity), scope size, team capacity, and whether you use external consultants. A focused SME with dedicated resources and a clear scope can reach audit readiness in 4–6 months. A large enterprise with a broad scope, complex supply chains, and multiple sites will typically need 12–18 months.
The certification audit itself — Stage 1 plus Stage 2 — adds roughly 3–6 months on top of implementation work, depending on the certification body's scheduling availability and how quickly you can resolve any Stage 1 observations before Stage 2 proceeds.
Costs vary significantly based on organisation size and scope. For smaller companies, external certification audit fees start from around $7,500 USD, with total project investment typically ranging from $15,000 to $60,000 when consultant fees, staff time, tooling, and audit fees are included. Enterprise certifications — with wider scope, multiple sites, and larger audit teams — typically cost $50,000 to $200,000 or more.
Internal staff time is consistently the largest cost component and the most underestimated. The gap assessment, policy documentation, risk assessment, control implementation, and internal audit all require significant time from people who have other jobs. Building that cost into your project plan before you start avoids the common problem of running out of capacity halfway through implementation.
The Statement of Applicability is one of the most important documents in your ISO 27001 ISMS. It lists all 93 Annex A controls, states whether each is applicable or not applicable to your organisation, and provides justification for any excluded controls. For applicable controls, it documents how they are implemented and links to the relevant policy or technical control.
The SoA must align with your risk treatment plan and must be kept current — it is one of the first documents an auditor will review. A weak SoA is one of the most common causes of major nonconformities at both Stage 1 and surveillance audits. Review the SoA at least annually and update it whenever your risk profile, technology environment, or business scope changes.
ISO 27001 compliance means your security practices align with the standard's requirements. Certification means an accredited external auditor has verified that alignment. Which you need depends on your situation: if clients, contracts, or procurement requirements specifically demand a certificate, you need certification. If you are implementing ISO 27001 to improve your security posture and demonstrate due diligence internally, compliance without formal certification may be sufficient.
Many organisations use ISO 27001 as a framework without pursuing certification, particularly in earlier stages of their security programme. The framework's value — systematic risk management, documented controls, recurring compliance tasks — is independent of whether a certificate is issued. The certificate is required when external stakeholders specifically ask for it.
There is significant overlap between ISO 27001 and other major frameworks. ISO 27001 implementation substantially reduces the additional effort required for SOC 2 Type II, GDPR technical measures, and NIS2 risk management obligations, because many of the underlying controls are the same. An organisation with a mature ISO 27001 ISMS is already doing much of the work that those other frameworks require.
However, ISO 27001 certification does not automatically satisfy the requirements of any other framework — each has its own scope, enforcement mechanism, and specific requirements that go beyond ISO 27001's coverage. The most efficient compliance strategy treats ISO 27001 as the backbone and maps other frameworks onto it, rather than building separate compliance programmes for each obligation. See Section 12 of this guide for a detailed breakdown of each framework's relationship to ISO 27001.