ISO/IEC 27001

ISO/IEC 27001: An Auditor's Deep-Dive Guide to the Information Security Management System Standard

ISO/IEC 27001 is the world's most widely adopted international standard for establishing, implementing, maintaining and continually improving an Information Security Management System (ISMS). Unlike a prescriptive control catalogue, ISO 27001 is a management-system standard: it defines a governance framework built around risk, leadership commitment, measurable objectives and the Plan-Do-Check-Act (PDCA) cycle of continual improvement. Certification against ISO 27001 provides independent, accredited assurance to customers, regulators, partners and boards that an organisation manages information security in a systematic, risk-driven manner. This guide is written from the perspective of a lead auditor and QSA-grade assessor, and walks through every clause of the management system, the full Annex A control set, scoping, phased implementation, maturity scoring, the audit lifecycle, evidence expectations, roles, KPIs, common gaps and cross-framework mappings.

The current edition is ISO/IEC 27001:2022, which superseded ISO/IEC 27001:2013. The 2022 revision retained the High-Level Structure (Harmonised Structure, formerly Annex SL) used across all ISO management-system standards, made minor clarifications to Clauses 4 to 10, and — most significantly — restructured Annex A to align with ISO/IEC 27002:2022, reducing the number of controls from 114 (across 14 domains) to 93 controls grouped into four themes, and introducing 11 genuinely new controls. Organisations certified against the 2013 edition were required to transition to the 2022 edition by 31 October 2025.

What is ISO/IEC 27001?

ISO/IEC 27001 specifies the requirements for an Information Security Management System — a coordinated set of policies, processes, roles, technologies and governance mechanisms through which an organisation systematically manages risks to the confidentiality, integrity and availability (the CIA triad) of its information assets. The standard is deliberately technology-neutral and sector-agnostic: it applies equally to a two-person fintech startup and a multinational bank, because it mandates outcomes (risk-based decision-making, documented objectives, monitoring, improvement) rather than specific technical implementations.

The standard is divided into two structural parts. First, the mandatory management-system clauses — Clause 4 (Context of the organisation), Clause 5 (Leadership), Clause 6 (Planning), Clause 7 (Support), Clause 8 (Operation), Clause 9 (Performance evaluation) and Clause 10 (Improvement). These clauses are non-negotiable: every requirement in Clauses 4 to 10 must be met to achieve certification. Second, Annex A, a reference set of information security controls. Annex A controls are selected on the basis of risk assessment and risk treatment; controls may be excluded only with documented justification, and the selection is recorded in a Statement of Applicability (SoA), which is the single most scrutinised document in any ISO 27001 audit.

Certification is granted by an accredited certification body following a two-stage external audit and is valid for a three-year cycle, punctuated by annual surveillance audits and a full recertification audit at the end of the cycle. ISO 27001 sits at the head of the ISO/IEC 27000 family, which includes ISO/IEC 27002 (implementation guidance for the controls), ISO/IEC 27005 (information security risk management), ISO/IEC 27017 (cloud security), ISO/IEC 27018 (PII in public clouds) and ISO/IEC 27701 (privacy information management extension).

Who Must Comply with ISO 27001?

ISO 27001 certification is voluntary in the sense that no single global law mandates it; however, it has become a de facto commercial and regulatory expectation across a wide range of sectors. Organisations pursue certification because customers require it in procurement, regulators reference it as evidence of adequate controls, and it materially reduces the friction of security questionnaires and audits. The following table summarises the primary drivers by organisation type.

• Contractual mandate — the most common trigger; a named customer requires certification within a fixed window.
• Regulatory alignment — sector regulators cite ISO 27001 as evidence of appropriate technical and organisational measures.
• Competitive differentiation — certification shortens sales cycles by pre-answering security due-diligence.
• Risk reduction and board assurance — provides directors with independent evidence that information security is governed, not ad hoc.
• Insurance — cyber-insurers increasingly offer improved terms to certified organisations.

Structure of ISO/IEC 27001:2022

ISO 27001 comprises the mandatory management-system clauses (Clauses 4 to 10) plus Annex A. Clauses 0 to 3 (Introduction, Scope, Normative references, Terms and definitions) are informative and set context but contain no auditable requirements. The auditable requirements begin at Clause 4. Annex A restates, in summary form, the 93 controls detailed in ISO/IEC 27002:2022, organised under four themes: Organisational, People, Physical and Technological. The table below maps the complete structure.

Master Assessment Checklist

This is the core of the guide. It enumerates every mandatory clause requirement (Clauses 4 to 10) and every Annex A control theme, with, for each, what an auditor verifies and the typical evidence expected. Use it as a self-assessment tool before booking a Stage 1 audit. Every group is presented as an h3 with a dedicated table so that no control area is skipped.

Clause 4 — Context of the Organisation

Clause 5 — Leadership

Clause 6 — Planning

Clause 7 — Support

Clause 8 — Operation

Clause 9 — Performance Evaluation

Clause 10 — Improvement

Annex A.5 — Organisational Controls (37 controls)

Annex A.6 — People Controls (8 controls)

Annex A.7 — Physical Controls (14 controls)

Annex A.8 — Technological Controls (34 controls)

Scoping the ISMS

Scope definition (Clause 4.3) is the most consequential early decision in an ISO 27001 programme. The scope determines which parts of the organisation the certificate covers, and — critically — customers read the scope statement on the certificate to confirm it covers the service they are buying. A scope that is drawn too narrowly may be commercially worthless; one drawn too broadly may be unaffordable to certify and maintain. The scope must consider internal and external issues (4.1), the requirements of interested parties (4.2), and the interfaces and dependencies between activities performed by the organisation and those performed by others.

• Define scope by business services, locations, organisational units, information systems and technologies — not vaguely by 'the company'.
• State inclusions and exclusions explicitly; any Annex A control excluded must be justified in the Statement of Applicability, never in the scope statement.
• Map interfaces and dependencies — cloud providers, data centres, shared services and group functions that sit outside the boundary but affect it.
• Ensure the scope wording that will appear on the certificate matches what customers expect to see (name the service/product).
• Avoid 'scope gaming' — carving out risky functions purely to ease certification will be challenged by a competent auditor and erodes trust.
• Revisit scope at every management review and whenever the business changes materially (new product, acquisition, new region).

Implementation Approach

A first-time ISO 27001 implementation for a mid-sized organisation typically runs six to twelve months. The following phased approach mirrors the PDCA cycle and sequences activities so that each phase produces the deliverables the next depends upon.

Phase 1 — Initiation and Gap Analysis (Weeks 1–4)

Activities: secure top-management sponsorship and budget; appoint an ISMS manager and steering committee; conduct a gap analysis against Clauses 4–10 and Annex A; determine internal/external issues and interested parties; draft the initial scope. Deliverables: signed project mandate, gap-analysis report with a prioritised remediation backlog, draft scope statement, interested-parties register.

Phase 2 — Risk Assessment and Treatment (Weeks 4–10)

Activities: define the risk assessment methodology and acceptance criteria; build the asset/risk inventory; assess risks by likelihood and impact; determine risk treatment options; select Annex A controls; draft the Statement of Applicability and risk treatment plan. Deliverables: documented risk methodology, risk register with owners, risk treatment plan, first version of the SoA.

Phase 3 — Control Design and Documentation (Weeks 8–18)

Activities: write the information security policy and supporting topic-specific policies; document mandatory procedures; design and deploy technical and organisational controls identified in the treatment plan; establish document control. Deliverables: approved policy suite, documented procedures, deployed controls, control-ownership assignments.

Phase 4 — Operation and Awareness (Weeks 14–24)

Activities: operate the ISMS in production; deliver awareness and role-based training; run incident-management, access-review and change processes; begin collecting records and metrics. Deliverables: training records, operating evidence, populated metrics dashboards, incident log.

Phase 5 — Internal Audit and Management Review (Weeks 22–28)

Activities: conduct an independent internal audit across all clauses and applicable controls; log nonconformities and corrective actions; hold the first formal management review. Deliverables: internal audit report, corrective action records, management-review minutes with improvement decisions.

Phase 6 — Certification Audit (Weeks 26–36)

Activities: engage an accredited certification body; undergo the Stage 1 (documentation readiness) audit; remediate Stage 1 findings; undergo the Stage 2 (implementation effectiveness) audit; close any nonconformities. Deliverables: Stage 1 report, Stage 2 report, closure evidence, ISO 27001 certificate.

Maturity / Capability Scoring Model

While ISO 27001 certification is binary (conformant or not), organisations benefit from scoring the maturity of each control area to prioritise investment and demonstrate improvement over time. A five-level capability model adapted from CMMI is widely used in ISO 27001 programmes.

For certification, most controls should reach at least Level 3 (Defined). Levels 4 and 5 signal a mature ISMS and align with the Clause 9 (measurement) and Clause 10 (continual improvement) requirements that auditors increasingly probe.

Assessment and Audit Approach

The ISO 27001 certification audit follows a defined lifecycle. Internal audits (Clause 9.2) precede external certification and use the same techniques. The steps below describe an end-to-end assessment engagement.

1. Confirm scope, objectives and criteria — agree the ISMS boundary, the applicable edition (2022) and the audit standard (ISO 19011 / ISO 17021).
2. Stage 1 audit (documentation review) — the certification body reviews the ISMS documentation, scope, SoA, risk assessment and readiness, and identifies areas of concern for Stage 2.
3. Remediate Stage 1 findings — close documentation gaps and confirm the ISMS is ready for effectiveness testing.
4. Stage 2 audit (implementation and effectiveness) — auditors sample evidence, interview staff, walk through processes and test whether controls operate as documented across the scope.
5. Classify findings — record major nonconformities (systemic failures), minor nonconformities (isolated lapses) and opportunities for improvement.
6. Corrective action — the organisation performs root-cause analysis and submits corrective action plans; major nonconformities must be closed before certification.
7. Certification decision — an independent reviewer at the certification body grants the certificate (valid three years) once nonconformities are resolved.
8. Surveillance audits — conducted at least annually to confirm the ISMS continues to operate and improve.
9. Recertification audit — a full reassessment at the end of the three-year cycle to renew the certificate.

Evidence Request List

Auditors sample evidence across the following categories. Preparing a well-organised evidence library dramatically shortens the audit and reduces the risk of nonconformities.

Governance and management-system evidence

• ISMS scope statement and context/interested-parties analysis
• Information security policy and topic-specific policies with approval and review records
• Statement of Applicability (all 93 controls with applicability and justification)
• Risk assessment methodology, risk register and risk treatment plan
• Information security objectives with measurement evidence
• Management-review minutes and internal audit reports

People and awareness evidence

• Background verification / screening records
• Employment contracts, NDAs and security clauses
• Awareness training records and phishing-simulation results
• Joiner-mover-leaver and access-revocation records
• Disciplinary process documentation

Operational and technical evidence

• Asset inventory and information classification records
• Access-control matrices and periodic access-review evidence
• Vulnerability scan and penetration test reports with remediation tracking
• Patch and configuration/hardening records
• Backup schedules and restore-test evidence
• SIEM/log retention and monitoring evidence
• Change management and incident-management records
• Cryptography/key-management configuration

Third-party, physical and continuity evidence

• Supplier security clauses, due-diligence and cloud-service agreements
• Physical access logs, CCTV and visitor records
• Media handling and secure-disposal certificates
• Business continuity and disaster recovery plans with test results

Roles and Responsibilities

KPIs to Track

• Percentage of Annex A applicable controls implemented and at Level 3+ maturity
• Number of open nonconformities and mean time to closure
• Percentage of staff completing security awareness training on schedule
• Phishing-simulation click and report rates over time
• Mean time to detect (MTTD) and mean time to respond (MTTR) to incidents
• Number of security incidents by severity and trend
• Percentage of critical/high vulnerabilities remediated within SLA
• Patch compliance rate across in-scope systems
• Percentage of access reviews completed on schedule
• Backup restore-test success rate
• Percentage of suppliers with completed security due-diligence
• Number of overdue risk-treatment actions
• Internal audit coverage against the audit programme
• Number of management reviews held versus planned

Readiness Checklist

• Top-management sponsorship and ISMS budget are secured and documented
• ISMS scope is defined, documented and aligned to customer expectations
• Internal/external issues and interested parties are identified and recorded
• Information security policy is approved, communicated and acknowledged
• Risk assessment methodology is defined with acceptance criteria
• Risk register is populated with owners and treatment decisions
• Statement of Applicability covers all 93 controls with justification
• Risk treatment plan is being executed and tracked
• All applicable Annex A controls are implemented and operating
• Measurable information security objectives are set and being measured
• Awareness training is delivered and completion is recorded
• Documented information is version-controlled and access-restricted
• Incident-management process is defined and an incident log exists
• Business continuity and DR plans exist and have been tested
• At least one full internal audit has been completed with findings closed
• At least one management review has been held with documented outputs
• Corrective action process is operating with root-cause analysis
• An accredited certification body has been selected and Stage 1 booked

Common Gaps

• Statement of Applicability out of sync with the risk assessment or listing controls as implemented when they are not.
• Risk assessment treated as a one-off spreadsheet exercise rather than a living, repeatable process reviewed on change.
• Scope drawn too narrowly to be commercially credible, or exclusions justified in the scope rather than the SoA.
• Information security objectives that are vague and unmeasurable, failing Clause 6.2.
• Management review held as a tick-box meeting without the mandated inputs or documented improvement decisions.
• Internal audit performed by someone lacking independence from the area audited.
• Awareness training delivered once at induction but never refreshed, with no completion tracking.
• The 2022 new controls (threat intelligence, cloud security, DLP, secure coding, configuration management) implemented on paper only.
• Supplier security clauses absent from contracts, with no due-diligence evidence for critical vendors.
• Access reviews not performed regularly, leaving orphaned and over-privileged accounts.
• Backups scheduled but restores never tested, so recoverability is unproven.
• Nonconformities closed without genuine root-cause analysis, so the same issues recur.
• Documentation that describes an idealised ISMS the organisation does not actually operate — the classic paper-vs-practice gap.

ISO 27001 Mapped to Other Frameworks

ISO 27001 is frequently operated alongside other frameworks. A single control environment can satisfy multiple requirements when mappings are understood. The table below shows indicative alignment; it is a planning aid, not a substitute for a formal crosswalk.

Frequently asked questions

Need help with ISO 27001?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.