ISO/IEC 27001:2022 — Information Security Management

ISO/IEC 27001:2022 — Information Security Management

Issuing body: ISO and IEC, developed by subcommittee ISO/IEC JTC 1/SC 27. Certification is performed by accredited certification bodies (registrars), not by ISO itself. Jurisdiction: International — voluntary, but contractually mandatory across enterprise IT, cloud, SaaS, finance, and government procurement worldwide.

1. What it is

ISO/IEC 27001 is the international standard for an Information Security Management System (ISMS) — the management framework (risk assessment, policies, controls, measurement, continual improvement) by which an organization protects the confidentiality, integrity, and availability of information. The 2022 edition (published October 2022, replacing the 2013 edition) restructured the control catalogue and aligned fully with the Harmonized Structure used across modern ISO management standards (Annex SL), making integrated ISO 9001/27001/27701 audits cleaner.

2. Scope, triggers, thresholds

• Applies to any organization; the Statement of Applicability (SoA) defines which of the 93 Annex A controls apply and justifies every inclusion and exclusion.
• Annex A 2022 restructure — 93 controls in 4 themes (down from 114 controls in 14 clauses in 2013):
  • A.5 Organizational (37 controls): policies, roles, supplier security, incident management, threat intelligence (new: 5.7), ICT readiness for business continuity.
  • A.6 People (8 controls): screening, employment terms, awareness training, disciplinary process.
  • A.7 Physical (14 controls): perimeters, entry controls, equipment protection, clear-desk.
  • A.8 Technological (34 controls): access control, cryptography, operations security, network security, secure coding (8.28, new), web filtering (8.23, new), data masking (8.11, new), data leakage prevention (8.12, new), monitoring, and — new and heavily audited — cloud-services security (5.23) and ICT supply-chain security (5.19–5.23).
• New or materially reworked controls vs. 2013: threat intelligence (5.7), cloud services security (5.23), ICT readiness for business continuity (5.30), physical security monitoring (7.4), configuration management (8.9), information deletion (8.10), data masking (8.11), data leakage prevention (8.12), monitoring activities (8.16), web filtering (8.23), secure coding (8.28).
• Trigger: customer contract, RFP requirement, regulatory expectation (e.g., DORA in EU finance, NIS2 essential-entity supply-chain pressure), or board-level risk decision.

3. Key requirements and compliance obligations

1. Clauses 4–10 (the auditable management system): context, leadership, planning (risk assessment methodology is the organization's choice, but it must be defined and applied), support, operation, performance evaluation, improvement. The risk assessment and risk treatment plan are the heart of the audit.
2. Statement of Applicability: must list every Annex A control, its applicability decision, and justification; exclusions need documented rationale, not silence.
3. Certification mechanics: accredited certification body (accreditation via IAF-member bodies, e.g., UKAS, ANAB, DAkkS) conducts a Stage 1 (documentation/readiness) and Stage 2 (implementation effectiveness) audit; certification is valid 3 years with annual surveillance audits and a recertification audit at cycle end. Major nonconformities block or suspend certification.
4. Continual improvement: internal audits, management review, metrics, and corrective action are not paperwork — auditors sample their effectiveness.
5. Supply-chain flow-down: 5.19–5.23 push security requirements into supplier agreements and cloud procurement — the control set most enterprise customers now probe first.

4. Penalties and consequences

No statutory penalties — 27001 is voluntary. Consequences are commercial: loss of certification (or failure to achieve it) kills enterprise deals, removes the organization from approved-vendor lists, and can breach customer contracts that require a certified ISMS. In regulated sectors, a lapsed or failed certification can trigger regulatory findings under regimes that expect it (DORA, NIS2, financial-sector outsourcing rules). Misrepresenting certification status is a contractual and reputational exposure.

5. Version status and live changes (verified 2026-09-30)

• Current edition: ISO/IEC 27001:2022 (with Amendment 1, 2024, adding climate-change considerations to Clauses 4.1/4.2 — [Flag: minor amendment; confirm scope before citing in audits]).
• The 2013→2022 transition ended October 31, 2025. All certificates to the 2013 edition are now expired or withdrawn; any organization still claiming "ISO 27001 certified" must hold a 2022-edition certificate. If a vendor's certificate references 2013, treat it as lapsed.
• 2022-edition audit reality: certification bodies are now fully auditing the new controls — threat intelligence (5.7), cloud security (5.23), secure coding (8.28), and data leakage prevention (8.12) are frequent sources of minor nonconformities in first-cycle 2022 audits, per practitioner reports — [Flag: practitioner consensus, not a published statistic.]
• Adjacent movement: ISO/IEC 27002:2022 (control implementation guidance) is the companion auditors actually read; ISO/IEC 27701 (privacy) extends the ISMS for GDPR-heavy organizations.

6. Related certifications

• CISSP (Computer flagship): the premier individual credential in this space; its Security and Risk Management and Security Architecture domains map directly onto ISMS design, and CISSP holders commonly lead 27001 implementations and audits.
• Note the division of labor: 27001 certifies the organization (via a certification body); CISSP certifies the person. Employers hiring ISMS managers typically want both the organizational certificate and CISSP-qualified staff.

7. Practical notes

• Start with the risk assessment, not the controls: organizations that buy a 93-control checklist and work backward produce a brittle ISMS that fails Stage 2.
• The SoA is a legal-grade document in enterprise sales — customers' security teams read it. Write justifications as if opposing counsel will read them.
• For SaaS/computer-engineering teams: 8.28 (secure coding), 8.25 (secure development lifecycle), and 5.23 (cloud security) are where engineering practice meets the audit — own them in the SDLC tooling, not in a policy PDF.

Original ETS reference writing, verified against public sources on 2026-09-30. Thin sourcing is flagged inline. Not legal advice — confirm current editions with the issuing body.