ISO/IEC 27001:2022 Practitioner Reference – Cybersecurity Reference

SECURE IN SECURITY — ISO/IEC 27001:2022 Contact / About / Policy

ISO/IEC 27001:2022
Practitioner Reference

Information Security Management System / Practitioner’s Guide

By N. Craig

1. Introduction to ISO/IEC 27001:2022

Ask most security people what ISO 27001 is, and they will say “a certification.” That undersells it. At its heart, 27001 is a management system — a disciplined way of running security so that risk decisions get made, written down, reviewed, and improved on a cycle — and that idea is instantly familiar to anyone raised on the federal Risk Management Framework, as I was during my years as an ISSM. The vocabulary differs: a Statement of Applicability instead of a tailored control baseline, management review and internal audit where a federal program would talk about authorization and continuous monitoring. The discipline underneath is the same. My own background is federal rather than ISO certification work, so I approach this standard as a translator between the two worlds. The sections that follow explain the 2022 revision, the mandatory clauses, and the Annex A controls, with a practitioner’s note on what tends to make or break an ISMS.

ISO/IEC 27001:2022 is the internationally recognized standard for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS). Published jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), it is the gold standard for demonstrating information security program maturity to customers, regulators, auditors, and partners worldwide.

The 2022 revision — formally published on 25 October 2022 — supersedes ISO/IEC 27001:2013 and introduces significant structural changes to both the management clauses and, most visibly, the Annex A control set, which was completely restructured and updated via ISO/IEC 27002:2022. Organizations certified against the 2013 version were required to transition to the 2022 version by 31 October 2025.

What ISO 27001 Is — and Is Not

ISO 27001 is an outcome-based management standard, not a technical checklist. It specifies what an ISMS must achieve and how the organization must govern, risk-assess, and continually improve its information security program. It does not prescribe which specific technical controls must be implemented in every organization — Annex A controls are selected based on a risk assessment, and each organization’s Statement of Applicability (SoA) documents which controls apply and why.

Key Concept

ISO 27001 certification means an accredited third-party auditor has verified that the organization has a systematic, risk-driven ISMS that is documented, implemented, and operationally effective — not that it is immune to breaches. Certification reduces risk; it does not eliminate it.

Why ISO 27001 Matters to Practitioners

For security practitioners, ISO 27001 provides several concrete operational benefits beyond the compliance credential:

Risk Discipline:A structured risk management process (Clauses 6 and 8) that forces systematic identification and treatment of information security risks across the full asset and threat landscape.
Control Coverage:Annex A’s 93 controls across four themes provide a comprehensive reference set that maps to virtually every other security framework — NIST SP 800-53, CIS Controls, PCI DSS, HIPAA, NIST CSF, and GDPR Article 32.
Program Assurance:The management review and internal audit requirements (Clauses 9.1–9.3) create formal checkpoints that surface control failures before external auditors or threat actors do.
Regulatory Leverage:ISO 27001 certification is accepted as GDPR Article 32 compliance evidence by many EU supervisory authorities, streamlines SOC 2 audit preparation, and satisfies vendor security assessment requirements from enterprise customers globally.

Key Changes in ISO 27001:2022 vs. 2013

Area	ISO 27001:2013	ISO 27001:2022
Annex A Structure	14 control categories, 114 controls	4 themes (Organizational, People, Physical, Technological), 93 controls — 11 new, 24 merged, 58 updated
New Controls	No equivalents	11 new controls including Threat Intelligence, Cloud Security, ICT Continuity, Data Masking, Web Filtering, Secure Coding, Physical Security Monitoring, Configuration Management, Information Deletion, DLP, and Monitoring Activities
Attributes & Tagging	Not present	Each control tagged with 5 attribute types (Control Type, Security Properties, Cybersecurity Concepts, Operational Capabilities, Security Domains) enabling filtering and mapping
Clause 6.3	Not present	New sub-clause requiring planning for changes to the ISMS — formalizes change management in the management system
Clause 4.2	Interested parties’ needs and expectations	Expanded to require identification of which requirements will be addressed through the ISMS
Annex A Alignment	ISO 27002:2013 (114 controls)	ISO 27002:2022 (93 controls) — complete restructure; control objectives removed; implementation guidance expanded

From the Field — A Practitioner’s Take

The Statement of Applicability is where an ISMS shows whether it is real. A strong SoA ties every Annex A decision — included or excluded — back to a specific risk and a specific treatment choice. A weak one reads like a copy of Annex A with “Yes” typed down the column. Auditors, like federal assessors, can usually tell the difference within minutes. It is the same test I would apply to any federal tailoring decision: can you explain why, in writing, in terms of risk?

Second, take Clause 9 seriously. Internal audit and management review are not ceremonies to schedule the month before the certification body arrives; they are how the system notices its own drift. The organizations that keep their certification without a last-minute scramble are the ones whose leadership actually reads the review outputs and acts on them.

And do not let the certificate become the goal. A certificate says an auditor found a functioning management system on a given set of days. Whether that system keeps reducing risk afterward — the “continually improving” in the standard’s own definition of an ISMS — is entirely up to you.

2. Mandatory ISMS Clauses: 4 Through 10

ISO 27001:2022 Clauses 4 through 10 define the mandatory requirements for the ISMS. Every requirement in these clauses is audited during certification; there is no mechanism to exclude or substitute them (unlike Annex A controls, which are selected via risk assessment). A finding of non-conformance against any mandatory clause requirement will prevent certification or result in a Major Non-Conformity requiring corrective action before certification is granted.

Clause	Requirement
4 — Context of the Organization	The organization must define its internal and external context, identify interested parties and their requirements, determine the ISMS scope, and explicitly identify which interested-party requirements will be addressed by the ISMS (Clause 4.2 — new in 2022). This is the foundational clause that calibrates the entire program to the organization’s risk environment.
5 — Leadership	Top management must demonstrate commitment to the ISMS through policy establishment, role assignment, and resource provision. The information security policy must be appropriate to the organization’s purpose, include objectives or a framework for setting them, and be communicated throughout the organization. Critically, the standard does not require a dedicated CISO — but it does require documented accountabilities at the leadership level.
6 — Planning	Clause 6 drives the risk management engine of the ISMS. The organization must define a risk assessment process, perform risk assessments, select risk treatments from Annex A and other sources, produce a Statement of Applicability (SoA), and develop a risk treatment plan. Clause 6.2 requires measurable information security objectives. Clause 6.3 (new in 2022) requires that changes to the ISMS be planned — eliminating ad hoc modifications to the management system.
7 — Support	Defines resource requirements: competent personnel, awareness of the ISMS among relevant staff, documented communication plans (who communicates what, when, and to whom), and documentation control requirements. Documented information — what ISO calls the required records and documents — must be controlled with defined review, approval, and retention processes. This clause is frequently the source of minor non-conformities in first-time certifications.
8 — Operation	Clause 8 operationalizes the planning from Clause 6. The organization must implement the risk assessment and risk treatment plan, maintain documented evidence of results, and manage planned and unplanned changes. Clause 8.2 requires the risk assessment to be performed at planned intervals and whenever significant changes occur — confirming that the ISMS risk process is continuous, not annual.
9 — Performance Evaluation	Requires monitoring, measurement, analysis, and evaluation of ISMS performance against defined metrics (9.1), an internal audit program assessing conformance and effective implementation (9.2), and a formal management review of the ISMS at planned intervals (9.3). Management review inputs and outputs must be documented — this is a mandatory record, not a discretionary meeting note.
10 — Improvement	Clause 10 drives continual improvement. Clause 10.1 requires the organization to continually improve ISMS suitability, adequacy, and effectiveness. Clause 10.2 establishes the nonconformity and corrective action process: when a nonconformity occurs, the organization must react, investigate root cause, implement corrective action, and verify effectiveness — then document the entire process.

Statement of Applicability (SoA) — The Pivotal ISMS Document

The Statement of Applicability is the document that bridges the risk assessment (Clause 6.1) with the Annex A control set. It is one of the most scrutinized documents during a certification audit. A compliant SoA must:

List all 93 Annex A controls and state whether each is included or excluded from the ISMS scope.
Provide justification for every included control (typically: risk treatment requirement, legal/contractual obligation, or best practice adoption).
Provide justification for every excluded control — simply marking a control “not applicable” without explanation is a non-conformity finding.
Reference the risk treatment plan and document the current implementation status of each included control.
Be reviewed and updated whenever the risk assessment changes, a new control is adopted, or an existing control is removed.

Audit Reality

Certification auditors frequently begin their Stage 2 audit review with the SoA and risk treatment plan. If these two documents are inconsistent with each other, or if the SoA exclusion justifications are weak, the audit will stall immediately. Practitioners should treat the SoA as a living document maintained in version control, not a one-time deliverable.

3. Annex A Controls — ISO/IEC 27002:2022

Annex A of ISO 27001:2022 references the full control set defined in ISO/IEC 27002:2022. The 2022 revision restructured the controls from 14 categories and 114 controls into 4 themes and 93 controls. Each control is now tagged with five attributes that enable mapping to other frameworks and filtering by security domain. The four themes are:

Theme	Control Count	Scope
5 — Organizational	37 controls	Policies, roles, responsibilities, asset management, supplier relationships, incident management, compliance, and information security in project management
6 — People	8 controls	Human resource security: pre-employment screening, terms, awareness, disciplinary process, remote working, and information security event reporting
7 — Physical	14 controls	Physical security perimeters, entry controls, office security, monitoring, protecting equipment, clear desk/screen, equipment maintenance, and secure disposal
8 — Technological	34 controls	User endpoint devices, privileged access, access control, cryptography, secure development, vulnerability management, network security, logging, and cloud security

Theme 5 — Organizational Controls (37 Controls)

Control	Name	Description & Practitioner Notes
5.1	Policies for Information Security	A set of topic-specific policies must be defined, approved by management, communicated, and reviewed at planned intervals or when significant changes occur. Practitioners: the policy hierarchy (overarching IS policy + topic-specific policies for access control, cryptography, incident response, etc.) must be documented and version-controlled.
5.2	Information Security Roles and Responsibilities	All information security responsibilities must be defined and allocated. Does not mandate a CISO title but requires explicit accountability for each ISMS function. Gap: vague role descriptions without named owners are a frequent audit finding.
5.3	Segregation of Duties	Conflicting duties and areas of responsibility must be segregated to reduce risk of unauthorized or unintentional modification or misuse. Applies to privileged access, financial authorization workflows, and change management processes.
5.4	Management Responsibilities	Management must require all personnel to apply information security in accordance with established policies. Provides the authority structure for enforcement of the ISMS at the operational level.
5.5	Contact with Authorities	Contacts with relevant authorities (law enforcement, regulators, CERT/CSIRT) must be maintained. Practitioners: pre-establish the incident notification chain before an incident occurs. GDPR 72-hour clock makes this mandatory.
5.6	Contact with Special Interest Groups	Membership or participation in security special interest groups, forums, or professional associations to maintain currency on threat intelligence and best practices (e.g., ISACs, FIRST, (ISC)2).
5.7	Threat Intelligence	New 2022Information on information security threats must be collected, analyzed, and applied to inform risk assessments and protective decisions. Requires defined threat intel sources, analytic processes, and integration with risk management — not just passive subscription to a feed.
5.8	Information Security in Project Management	Information security must be integrated into the project management methodology. Security requirements must be identified at project initiation, not retrofitted after build. Applies to both IT and business change projects.
5.9	Inventory of Information and Other Associated Assets	An inventory of information and associated assets (hardware, software, services, people) must be maintained with ownership assigned. The asset inventory underpins virtually every other control — if you don’t know what you have, you cannot protect it.
5.10	Acceptable Use of Information and Other Assets	Rules for acceptable use must be defined, documented, and implemented. Covers BYOD policies, personal use of corporate assets, data handling procedures, and clean desk/clear screen requirements.
5.11	Return of Assets	Employees and third parties must return all organizational assets upon termination or change of employment. Requires defined off-boarding checklists that include physical and digital asset recovery.
5.12	Classification of Information	Information must be classified according to legal requirements, value, criticality, and sensitivity. Classification scheme drives handling, labeling, and access control decisions throughout the ISMS.
5.13	Labeling of Information	An appropriate set of procedures for labeling information in accordance with the classification scheme must be developed and implemented. Covers electronic documents, email, physical media, and printed output.
5.14	Information Transfer	Transfer policies, rules, and procedures must cover all transfer types: electronic, physical, and verbal. Includes acceptable use of external messaging platforms and encryption requirements for data in transit.
5.15	Access Control	Rules to control physical and logical access based on business and information security requirements must be established. Access control is a topic-specific policy requirement: the policy must address access request, provisioning, review, and revocation processes.
5.16	Identity Management	The full lifecycle of identities (human and non-human) must be managed. Includes provisioning, modification, suspension, and deletion of identities across all systems in scope.
5.17	Authentication Information	Management of authentication credentials must follow a formal process covering initial provisioning, temporary credentials, storage, and prohibitions on sharing. Practitioners: default and shared credentials are a direct violation of 5.17 and one of the most common breach enablers.
5.18	Access Rights	Access rights must be provisioned, reviewed, modified, and revoked based on the organization’s access control policy. Quarterly access reviews for privileged accounts and annual reviews for general users are the operational minimum.
5.19	Information Security in Supplier Relationships	Information security requirements must be established and agreed with suppliers. Third-party risk is first-party risk — 5.19 through 5.22 establish the supplier security program framework.
5.20	Addressing Information Security in Supplier Agreements	Agreements with suppliers must include information security requirements relevant to the information accessed, processed, or managed by the supplier. Security schedules to contracts are the primary implementation vehicle.
5.21	Managing Information Security in the ICT Supply Chain	Processes and procedures must manage information security risks associated with the ICT supply chain, including hardware and software components. Includes SBOM requirements and firmware integrity verification.
5.22	Monitoring, Review and Change Management of Supplier Services	The organization must regularly monitor, review, and manage changes to supplier services. Annual security reviews of Tier 1 suppliers; incident notification requirements in contracts.
5.23	Information Security for Use of Cloud Services	New 2022Processes for acquisition, use, management, and exit from cloud services must address information security. Covers shared responsibility model understanding, data residency, encryption key management, and exit strategy planning.
5.24	Information Security Incident Management Planning and Preparation	Incident management responsibilities and procedures must be established to enable a rapid, effective, and orderly response. Requires documented incident response plan with defined roles, escalation paths, and communication templates.
5.25	Assessment and Decision on Information Security Events	Events must be assessed to determine whether they qualify as incidents. Triage criteria and severity classification framework required. Undeclared incidents are a common audit finding.
5.26	Response to Information Security Incidents	Incidents must be responded to in accordance with documented procedures. IR plan must address containment, eradication, recovery, and stakeholder notification steps.
5.27	Learning from Information Security Incidents	Post-incident analysis must produce lessons learned that are applied to reduce the likelihood of recurrence. Requires documented post-incident review process with action tracking.
5.28	Collection of Evidence	Evidence collection procedures must ensure that evidence is legally admissible and defensible. Chain of custody documentation required. Relevant for regulatory investigations, litigation, and criminal referrals.
5.29	Information Security During Disruption	Information security must be maintained during disruption. Business continuity plans must address preservation of information security controls during crisis events — not just IT recovery.
5.30	ICT Readiness for Business Continuity	New 2022ICT readiness must be planned, implemented, maintained, and tested based on continuity objectives. Requires defined RTOs and RPOs, tested backup and recovery procedures, and failover capability validation.
5.31	Legal, Statutory, Regulatory and Contractual Requirements	All relevant legal, statutory, regulatory, and contractual requirements must be identified, documented, and kept up to date. Compliance register is the standard implementation artifact.
5.32	Intellectual Property Rights	Procedures for protecting intellectual property rights must be implemented. Covers software licensing compliance, copyright, and patent protection — frequently neglected in technical-focused ISMS programs.
5.33	Protection of Records	Records must be protected from loss, destruction, falsification, and unauthorized access in accordance with statutory, regulatory, and contractual requirements. Retention schedules and disposal procedures required.
5.34	Privacy and Protection of Personal Information	Personal information must be protected in accordance with applicable privacy and data protection laws. Maps directly to GDPR Article 5 principles and requires a privacy program integrated with the ISMS.
5.35	Independent Review of Information Security	The information security approach and its implementation must be reviewed independently at planned intervals. Internal audit satisfies this at the operational level; third-party penetration testing and external audit satisfy it at the independent assurance level.
5.36	Compliance with Policies, Rules and Standards	Managers must regularly review compliance of information processing and procedures within their area of responsibility. This is a management-layer compliance check, distinct from the technical audit in 5.35.
5.37	Documented Operating Procedures	Operating procedures for information processing facilities must be documented, maintained, and made available to users who need them. Run-books, standard operating procedures, and change management procedures all satisfy 5.37.

Theme 6 — People Controls (8 Controls)

Control	Name	Description & Practitioner Notes
6.1	Screening	Background verification checks must be carried out on all candidates for employment, consistent with applicable laws, regulations, and ethics, and proportional to the business requirements and the classification of information to be accessed. Practitioners: screening scope should be proportionate to role sensitivity — privileged users and those handling sensitive data require more rigorous checks.
6.2	Terms and Conditions of Employment	Contractual agreements must state the employee’s and the organization’s responsibilities for information security. Security obligations must be explicit in employment contracts, not implied. Includes confidentiality/NDA requirements, acceptable use, and consequences of violation.
6.3	Information Security Awareness, Education and Training	All personnel and relevant third parties must receive appropriate awareness education and training, and regular updates on organizational policies and procedures relevant to their job function. Annual compliance training alone is insufficient — role-specific training for high-risk functions (SOC, developers, administrators) is required.
6.4	Disciplinary Process	A formal and communicated disciplinary process must exist for personnel who have committed a breach of information security. The process must be proportionate and must not discriminate. Practitioners: document that the disciplinary process has been applied consistently — gaps here create legal exposure.
6.5	Responsibilities After Termination or Change of Employment	Information security responsibilities and duties that remain valid after termination or change of employment must be defined, communicated, and enforced. Includes ongoing confidentiality obligations, IP ownership, and revocation timelines for system access.
6.6	Confidentiality or Non-Disclosure Agreements	NDAs or confidentiality agreements reflecting the organization’s needs must be identified, regularly reviewed, and signed by personnel and third parties. Include information classification, handling requirements, permitted use, and consequences of breach.
6.7	Remote Working	Security measures must be implemented when personnel work remotely. Practitioners: remote working policy must address secure communication (VPN/ZTNA), equipment security, screen privacy, and restrictions on work in public locations. Home network security requirements need explicit documentation.
6.8	Information Security Event Reporting	Personnel must be required to report observed or suspected information security events through appropriate channels as quickly as possible. A low-friction reporting mechanism (hotline, SIEM-integrated alert, email alias) and a no-blame reporting culture are essential for this control to be effective.

Theme 7 — Physical Controls (14 Controls)

Control	Name	Description & Practitioner Notes
7.1	Physical Security Perimeters	Security perimeters must be defined and used to protect areas containing information and associated assets. Perimeters are defined by risk — not all areas require the same protection level. Tiered zones (public, office, restricted, secure) are the standard implementation model.
7.2	Physical Entry	Secure areas must be protected by appropriate entry controls to ensure only authorized personnel are allowed access. Includes badge readers, visitor logs, mantrap/airlocks for high-security zones, and anti-tailgating measures.
7.3	Securing Offices, Rooms and Facilities	Physical security for offices, rooms, and facilities must be designed and implemented. Threat modeling for physical access should consider insider threats, social engineering (tailgating), and physical media removal.
7.4	Physical Security Monitoring	New 2022Premises must be continuously monitored for unauthorized physical access. CCTV with defined retention periods, motion detection in secure areas, and alarm systems with response procedures are the standard implementation set.
7.5	Protecting Against Physical and Environmental Threats	Physical protection against natural disasters, malicious attacks, and accidents must be designed and implemented. Data center siting, flood and fire suppression, and power conditioning are primary implementation areas.
7.6	Working in Secure Areas	Security measures for working in secure areas must be designed and applied. Includes mobile device restrictions, visitor supervision requirements, and prohibition on unattended sensitive work.
7.7	Clear Desk and Clear Screen	Rules for clear desk for papers and removable storage media and clear screen for information processing facilities must be defined and appropriately enforced. Enforced at the organizational policy level; validated during internal audits and penetration tests (physical component).
7.8	Equipment Siting and Protection	Equipment must be sited and protected to reduce risks from environmental threats and hazards, and opportunities for unauthorized access. Covers server rack placement, UPS protection, cable management, and physical access to networking hardware.
7.9	Security of Assets Off-Premises	Off-premises assets must be protected, taking account of the different risks of working outside the organization’s premises. Laptop encryption (full disk), MDM for mobile devices, and asset tracking are primary implementations.
7.10	Storage Media	Storage media must be managed through their acquisition, use, transportation, and disposal lifecycle in accordance with the classification and handling scheme. Secure disposal (degaussing, cryptographic erasure, physical destruction) is a frequent audit focus area.
7.11	Supporting Utilities	Information processing facilities must be protected from power failures and other disruptions caused by failures in supporting utilities. UPS, generator backup, and utility monitoring with alerting are required for facilities hosting critical systems.
7.12	Cabling Security	Power and telecommunications cabling carrying data or supporting information services must be protected from interception, interference, or damage. Physical cable access controls, plenum-rated cabling in shared spaces, and conduit use in accessible areas.
7.13	Equipment Maintenance	Equipment must be correctly maintained to ensure continued availability and integrity. Maintenance must follow manufacturer specifications; maintenance by authorized personnel only; maintenance records retained.
7.14	Secure Disposal or Re-Use of Equipment	Items of equipment containing storage media must be verified to ensure that any sensitive information and licensed software has been removed or securely overwritten prior to disposal or re-use. Certificate of destruction from a certified vendor is the standard evidence artifact.

Theme 8 — Technological Controls (34 Controls)

Theme 8 contains the highest density of directly technical controls and is where most security practitioners spend the majority of ISMS implementation effort. The 11 new controls introduced in ISO 27002:2022 are concentrated here.

Control	Name	Description & Practitioner Notes
8.1	User Endpoint Devices	Information stored on, processed by, or accessible via user endpoint devices must be protected. Policy must address device registration, configuration baselines (CIS Benchmarks), MDM enrollment, encryption requirements, and acceptable use restrictions.
8.2	Privileged Access Rights	Allocation and use of privileged access rights must be restricted and managed. PAM (Privileged Access Management) solutions with session recording, just-in-time provisioning, and credential vaulting are the primary technical implementation. Quarterly review of privileged accounts required.
8.3	Information Access Restriction	Access to information and application system functions must be restricted in accordance with the access control policy. Role-based access control (RBAC) with least privilege principle applied across all in-scope systems.
8.4	Access to Source Code	Read and write access to source code, development tools, and software libraries must be managed appropriately. Separate development/production environments, code repository access controls, and branch protection policies are primary implementations.
8.5	Secure Authentication	Secure authentication technologies and procedures must be implemented based on information access restrictions. MFA is the expected baseline for all privileged access and all remote access; phishing-resistant MFA (FIDO2/WebAuthn) is best practice for high-risk access.
8.6	Capacity Management	The use of resources must be monitored and adjusted, and projections of future capacity requirements must be made to ensure the required system performance. Cloud auto-scaling policies and on-premises capacity monitoring with alerting implement this control.
8.7	Protection Against Malware	Protection against malware must be implemented and supported by appropriate user awareness. Modern EDR/XDR platforms providing behavioral detection go beyond traditional signature-based AV and are the expected implementation standard.
8.8	Management of Technical Vulnerabilities	Information about technical vulnerabilities of information systems in use must be obtained in a timely fashion, the organization’s exposure to such vulnerabilities evaluated, and appropriate measures taken. Requires defined patch SLAs based on CVSS severity: Critical — 14 days; High — 30 days; Medium — 90 days.
8.9	Configuration Management	New 2022Configurations of hardware, software, services, and networks must be established, documented, implemented, monitored, and reviewed. CIS Benchmarks or DISA STIGs provide the configuration baseline standards. SCCM, Ansible, or equivalent tools enforce and monitor configurations.
8.10	Information Deletion	New 2022Information stored in information systems, devices, or other storage media must be deleted when no longer required. Implements data minimization principles required by GDPR and supports 5.33 records protection. Automated retention policies in cloud platforms are the primary implementation.
8.11	Data Masking	New 2022Data masking must be used in accordance with the organization’s topic-specific policy on access control and business requirements. Tokenization of payment card data, PII pseudonymization in non-production environments, and dynamic data masking in analytics platforms are primary implementations.
8.12	Data Leakage Prevention	New 2022DLP measures must be applied to systems, networks, and endpoint devices that process, store, or transmit sensitive information. Requires data classification as a prerequisite — DLP policy cannot be effective without knowing what constitutes sensitive data.
8.13	Information Backup	Backup copies of information, software, and systems must be maintained and tested regularly. The 3-2-1 rule (three copies, two media types, one offsite) remains the baseline. Backup encryption and ransomware-resilient immutable backup targets are modern requirements.
8.14	Redundancy of Information Processing Facilities	Information processing facilities must be implemented with sufficient redundancy to meet availability requirements. Active-active and active-passive configurations based on defined RTO/RPO requirements. Cloud multi-region deployments satisfy this for cloud-hosted systems.
8.15	Logging	Logs that record activities, exceptions, faults, and other relevant events must be produced, stored, protected, and analyzed. Log retention must be defined by risk assessment and regulatory requirements. SIEM ingestion of all critical log sources is the operational minimum.
8.16	Monitoring Activities	New 2022Networks, systems, and applications must be monitored for anomalous behavior and appropriate action taken to evaluate potential information security incidents. IDS/IPS, SIEM with correlation rules, UEBA, and NDR tools all implement 8.16. This is the ISO 27001 anchor control for the detection function.
8.17	Clock Synchronization	The clocks of all relevant information processing systems must be synchronized to a single reference time source. NTP hierarchy synchronized to authoritative sources (NIST, GPS). Critical for log correlation, forensic investigation, and audit trail integrity.
8.18	Use of Privileged Utility Programs	The use of utility programs that might be capable of overriding system and application controls must be restricted and tightly controlled. Living-off-the-land (LotL) attack techniques frequently abuse legitimate utility programs — this control is a direct mitigation for that attack class.
8.19	Installation of Software on Operational Systems	Procedures must be implemented to control the installation of software on operational systems. Application whitelisting, software installation policies, and change management approval for production system changes are standard implementations.
8.20	Networks Security	Networks and network devices must be managed and controlled to protect information in systems and applications. Network segmentation, firewall policy management, and network device hardening implement this control. Zero Trust micro-segmentation is the modern architecture.
8.21	Security of Network Services	Security mechanisms, service levels, and management requirements of network services must be identified, implemented, and monitored. Covers both internal network services and externally provided connectivity services (ISP, SD-WAN, MPLS).
8.22	Segregation of Networks	Groups of information services, users, and information systems must be segregated in networks. VLAN segmentation, DMZ architecture, and micro-segmentation for workload isolation are primary implementations. Production/development/test environment segregation is the minimum baseline.
8.23	Web Filtering	New 2022Access to external websites must be managed to reduce exposure to malicious content. Secure web gateway (SWG), DNS filtering, and proxy-based URL categorization policies are standard implementations. Protects against drive-by downloads and phishing site access.
8.24	Use of Cryptography	Rules for the effective use of cryptography must be defined and implemented. Cryptographic policy must specify approved algorithms, key lengths, protocols (TLS 1.2+ minimum; TLS 1.3 preferred), key management lifecycle, and certificate management procedures.
8.25	Secure Development Lifecycle	Rules for the secure development of software and systems must be established and applied. SSDLC integrating security at each phase: threat modeling at design, SAST/DAST in build pipeline, dependency scanning, and security code review before release.
8.26	Application Security Requirements	Information security requirements must be identified, specified, and approved when developing or acquiring applications. Security requirements must appear in project briefs, procurement RFPs, and acceptance criteria — not as afterthoughts.
8.27	Secure System Architecture and Engineering Principles	New 2022Principles for engineering secure systems must be established, documented, maintained, and applied. NIST SP 800-160, Microsoft SDL, and OWASP SAMM all provide engineering principles frameworks. Zero Trust architecture principles apply here.
8.28	Secure Coding	New 2022Secure coding principles must be applied to software development. Requires defined secure coding standards (OWASP Top 10 compliance, language-specific guidelines), mandatory peer review, and evidence of training for all developers.
8.29	Security Testing in Development and Acceptance	Security testing processes must be defined and implemented. Covers SAST (static analysis), DAST (dynamic analysis), penetration testing before major releases, and security acceptance testing criteria. Test results must be documented.
8.30	Outsourced Development	The organization must direct, monitor, and review the activities related to outsourced system development. Security requirements must flow down to development partners; code review rights and security testing of deliverables must be contractually established.
8.31	Separation of Development, Test and Production Environments	Development, testing, and operational environments must be separated and secured. Strict separation enforces that no production data appears in test environments (without masking), and that no test/dev credentials work in production.
8.32	Change Management	Changes to information processing facilities and information systems must be controlled by formal change management procedures. Change Advisory Board (CAB) processes, rollback plans, and post-implementation review are standard implementations.
8.33	Test Information	Test information must be selected, protected, and managed appropriately. Production data must not be used in test environments without anonymization or masking. Direct mapping to GDPR data minimization principle.
8.34	Protection of Information Systems During Audit Testing	Audit tests and activities involving assessment of operational systems must be planned and agreed between the tester and appropriate management. Audit scope, tools, timing, and system impact must be documented and approved — prevents audit activity from causing unplanned outages or data exposure.

The 11 New Controls

Controls 5.7 (Threat Intelligence), 5.23 (Cloud Services), 5.30 (ICT Continuity), 7.4 (Physical Monitoring), 8.9 (Configuration Management), 8.10 (Information Deletion), 8.11 (Data Masking), 8.12 (DLP), 8.16 (Monitoring Activities), 8.23 (Web Filtering), 8.27 (Secure System Architecture), and 8.28 (Secure Coding) were added in the 2022 revision to address cloud security, DevSecOps, and modern threat management gaps in the 2013 control set.

4. ISO 27001 Certification: The Full Audit Lifecycle

ISO 27001 certification is awarded by an accredited certification body (CB) following a formal assessment process. Accreditation — the credential that authorizes the CB to issue ISO 27001 certificates — is granted by a national accreditation body (e.g., UKAS in the UK, DAkkS in Germany, ANAB in the USA) that is a member of the International Accreditation Forum (IAF). Only certificates from accredited CBs are internationally recognized.

Pre-Certification: ISMS Implementation

Before engaging a certification body, practitioners must complete the full ISMS implementation. Attempting Stage 1 audit with an immature ISMS is a costly mistake — auditors will issue a Stage 1 “not ready” determination, requiring a reassessment fee. The pre-certification checklist:

Clause 4:Context document, interested parties register, ISMS scope document finalized and approved.
Clause 5:Information security policy signed by top management; roles and responsibilities documented with named individuals.
Clause 6:Risk assessment completed using documented methodology; risk treatment plan approved; Statement of Applicability version-controlled and signed off.
Clause 7:Competence records for all ISMS roles; awareness training evidence; all required documented information created and in document control.
Clause 8:Risk treatment controls implemented and operational — not just documented as planned.
Clause 9:At least one complete internal audit cycle completed; management review meeting held and documented with minutes and action tracking.
Clause 10:Nonconformity and corrective action procedure operational; at least one corrective action completed end-to-end.

Stage 1 Audit — Documentation Review

The Stage 1 audit is typically conducted remotely or on-site and focuses on reviewing the ISMS documentation to assess whether the organization is ready for the Stage 2 audit. The auditor evaluates:

Stage 1 Focus Area	Common Findings
ISMS Scope Document	Scope is too narrow (excludes key systems), too broad (unmanageable), or fails to justify exclusions. Scope must clearly describe the boundaries of the ISMS and the interfaces with other parts of the organization.
Risk Assessment Methodology	No documented methodology; methodology does not produce consistent results; risk scoring criteria not defined. The methodology must be documented, repeatable, and applied consistently across the asset inventory.
Statement of Applicability	Controls marked “not applicable” without justification; SoA not cross-referenced to risk treatment plan; excluded controls have no documented rationale. Every exclusion requires explicit justification.
Information Security Policy	Policy not approved by top management; policy does not reference objectives or a framework for setting them; policy not communicated to relevant parties. A policy signed by IT management alone is insufficient.
Internal Audit Evidence	Internal audit not completed before Stage 1; audit did not cover the full ISMS scope; no documented audit program; auditors lacked independence from the areas they audited.
Management Review Records	No formal management review meeting documented; review inputs (audit results, incident data, risk status, objectives performance) not all addressed; review outputs (decisions and actions) not recorded.

Following Stage 1, the auditor issues a Stage 1 report identifying any major issues (“not ready” areas) and minor observations. The organization must address major issues before Stage 2 can proceed. Stage 2 is typically scheduled 1–4 months after Stage 1.

Stage 2 Audit — Implementation Effectiveness

The Stage 2 audit is the definitive certification assessment. Conducted on-site (or in hybrid format for distributed organizations), it verifies that ISMS controls are not just documented but are implemented and operating effectively. Auditors will:

Interview personnel across multiple departments to verify that information security responsibilities are understood and actioned — not just documented in a policy nobody has read.
Sample evidence for Annex A controls: access review records, vulnerability scan results, patch records, backup test logs, incident reports, training completion records, supplier security assessment evidence.
Walk through the risk assessment and treatment plan to verify that identified risks have been treated and that the SoA accurately reflects the current control environment.
Review nonconformity and corrective action records to confirm the continual improvement process is operational, not just documented.
Assess whether security objectives have been measured and whether performance data is reviewed in management reviews.

Finding Type	Definition	Certification Impact
Major Non-Conformity	Absence of a required process, systematic failure of an implemented process, or failure that raises significant doubt about the ISMS’s ability to achieve its intended outcomes.	Certification cannot be issued until corrective action is verified. A follow-up audit visit is typically required.
Minor Non-Conformity	A single observed lapse in an otherwise functioning process, or a failure that does not represent a systematic or significant risk to the ISMS.	Corrective action plan required within 90 days. Evidence of correction submitted to auditor for desk review — no additional site visit required in most cases.
Opportunity for Improvement (OFI)	Observation that a process could be improved but is not a non-conformity. The organization is not obligated to act.	No impact on certification. Document in the improvement register for consideration.

Surveillance Audits — Years 1 and 2

ISO 27001 certificates are valid for three years, subject to annual surveillance audits. Surveillance audits are smaller in scope than the Stage 2 audit — typically covering one-third of the ISMS scope per year, prioritized based on risk, performance issues, and findings from previous audits.

Surveillance Audit Year 1 (SA1): Typically focuses on any areas of concern from Stage 2, progress on minor non-conformities, internal audit results, and management review effectiveness.
Surveillance Audit Year 2 (SA2): Covers remaining scope areas, any significant changes to the ISMS, and continual improvement evidence. Begins preparation review for recertification.
Between audits, the organization must notify the certification body of significant changes (mergers, major system changes, new high-risk activities) that may affect the ISMS scope or risk profile.

Recertification Audit — Year 3

At the end of the three-year certification cycle, a recertification audit is conducted. This is a full assessment comparable in scope to the original Stage 2 audit. It reviews the entire ISMS for continued conformance, evaluates the effectiveness of the continual improvement process across the three-year cycle, and renews the certificate for a further three years upon successful completion.

Practitioner Tip — Audit Readiness

Maintain a running evidence file throughout the year, not just in the weeks before an audit. For each Annex A control in scope, keep a folder of current evidence: access review records, patch reports, training logs, supplier assessments. Scrambling to reconstruct evidence post-audit is the primary driver of minor non-conformities that could have been avoided.

Real-World Context: When ISMS Controls Fail

Several high-profile breaches in recent years directly map to specific ISO 27001 control failures, illustrating what happens when the ISMS becomes a documentation exercise rather than an operational program:

Incident	ISO 27001 Controls Failed	What the ISMS Should Have Prevented
Salt Typhoon Telecom Breach (2024–2025)	8.8 (Vulnerability Management), 8.16 (Monitoring Activities), 5.19/5.22 (Supplier/ICT Supply Chain), 8.20 (Network Security)	Cisco IOS XE vulnerabilities with available patches for 7 years should have been remediated under any functional 8.8 control. CALEA systems outside monitoring scope violate 8.16. An operational ISMS would have detected lateral movement within the 1–2 year dwell time.
MOVEit Transfer (2023)	8.8 (Technical Vulnerability Management), 8.25 (Secure Development Lifecycle), 8.29 (Security Testing)	The SQL injection vulnerability in MOVEit Transfer was exploitable at the application layer. Organizations with functional 8.8 controls that patch web-facing systems promptly contained the impact; those without were fully compromised.
Okta Support Breach (2023)	5.19 (Supplier Relationships), 8.2 (Privileged Access Rights), 8.15 (Logging)	Access by a support contractor to production customer data highlights 5.19 supplier access control failures. Proper scoping of contractor access (8.2, 8.3) and monitoring of that access (8.15, 8.16) would have detected the intrusion immediately.
NHS WannaCry (2017)	8.8 (Vulnerability Management), 8.20 (Network Security), 8.22 (Segregation of Networks)	WannaCry exploited MS17-010 — a vulnerability patched two months before the attack. NHS trusts running unpatched Windows XP/7 systems with no network segmentation suffered catastrophic disruption. Both failures are direct violations of foundational ISO 27001 controls.

ISMS vs. Compliance Theatre

ISO 27001 certification does not guarantee immunity from breaches. What it does guarantee — when implemented operationally rather than as a documentation exercise — is that the organization has systematic processes for identifying and treating risks before attackers exploit them. The organizations above were, in many cases, not ISO 27001 certified. Those that were certified but still suffered similar failures had implemented the standard as a paper exercise, not an operational program.

══ SECTION 5 ══

5. ISO 27001:2022 and Regulatory Compliance Alignment

One of ISO 27001’s most powerful attributes is its function as a multi-framework compliance hub. Organizations that implement ISO 27001 comprehensively satisfy the security requirements of most applicable regulatory frameworks as a natural byproduct. This is the principle of reciprocity — accepted equivalence across frameworks — that makes ISO 27001 the most cost-efficient anchor framework for multi-regulatory environments.

GDPR — General Data Protection Regulation

ISO 27001 is the most widely used mechanism for demonstrating GDPR Article 32 compliance — the requirement to implement “appropriate technical and organizational measures” for data security. Many EU supervisory authorities explicitly accept ISO 27001 certification as evidence of Article 32 compliance.

GDPR Requirement	ISO 27001:2022 Controls	Implementation Notes
Article 5 — Data processing principles (integrity & confidentiality)	5.1 (Policies), 8.24 (Cryptography), 8.15 (Logging), 5.12 (Classification)	Data classification policy (5.12) must reflect personal data as a category requiring specific technical protections. Encryption at rest and in transit (8.24) are the primary technical safeguards.
Article 25 — Privacy by design and by default	8.25 (Secure Development), 8.27 (Secure Architecture), 5.8 (Security in Projects)	Privacy requirements must be integrated into the SSDLC (8.25) and system architecture (8.27) from the start. Security in project management (5.8) requires privacy impact assessment at project initiation.
Article 32 — Security of processing	Full ISMS — all Annex A controls as applicable	ISO 27001 certification is the primary mechanism for demonstrating Article 32 compliance. The SoA documents which controls are applied to protect personal data processing.
Article 33/34 — Breach notification	5.24/5.25/5.26 (Incident Management), 5.5 (Contact with Authorities)	72-hour notification to supervisory authority requires a pre-established incident classification process (5.25) and authority contact list (5.5). Incident response plan (5.24) must include GDPR notification criteria and timelines.
Article 28 — Data processor requirements	5.19/5.20 (Supplier Relationships and Agreements)	Data Processing Agreements (DPAs) with processors must include security requirements — implement through supplier security schedule templates covering the applicable Annex A controls.

NIST Cybersecurity Framework 2.0

ISO 27001 and NIST CSF 2.0 are highly complementary. ISO 27001 provides the management system structure (the “how to run the program”), while NIST CSF 2.0 provides the outcome framework (the “what the program must achieve”). NIST maintains official cross-reference mappings between ISO 27001:2022 and CSF 2.0.

NIST CSF 2.0 Function	Primary ISO 27001:2022 Controls	Integration Notes
GOVERN	Clauses 5 & 6 (Leadership, Planning), 5.1 (Policies), 5.2 (Roles), 5.31 (Legal Requirements)	ISO 27001 Clauses 5 and 6 directly satisfy CSF 2.0’s GOVERN function. The ISMS risk management process (Clause 6) maps to GV.RM; roles and responsibilities (5.2, Clause 5.3) map to GV.RR.
IDENTIFY	5.9 (Asset Inventory), Clause 6.1 (Risk Assessment), 5.7 (Threat Intelligence)	ISO 27001’s mandatory risk assessment (Clause 6.1) and asset inventory (5.9) directly satisfy NIST ID.AM and ID.RA. Threat intelligence (5.7) maps to ID.RA-02.
PROTECT	8.2 (Privileged Access), 8.5 (Authentication), 8.24 (Cryptography), 8.20/8.22 (Networks), 6.3 (Training)	Strong alignment. ISO 27001 Annex A Theme 8 technological controls implement NIST PROTECT subcategories at the control level.
DETECT	8.15 (Logging), 8.16 (Monitoring), 8.8 (Vulnerability Management)	8.16 Monitoring Activities is the ISO 27001 anchor for NIST DE.CM. IDS/IPS implementation satisfies both 8.16 and NIST DE.CM-01.
RESPOND	5.24/5.25/5.26 (Incident Management), 5.5 (Authority Contacts), 5.28 (Evidence Collection)	ISO 27001 incident management controls (5.24–5.28) map directly to NIST RS function categories. The incident response plan satisfies RS.MA-01.
RECOVER	5.29/5.30 (Continuity), 8.13 (Backup), 8.14 (Redundancy)	ISO 27001 business continuity controls (5.29, 5.30) and availability controls (8.13, 8.14) implement NIST RC.RP and RC.CO outcomes.

PCI DSS v4.0

ISO 27001 certification is accepted by many QSAs and merchant banks as evidence of a mature security program supporting PCI DSS compliance, but does not replace PCI DSS assessment for in-scope cardholder data environments. The frameworks are complementary: implement PCI DSS for cardholder data environments and use ISO 27001 as the overarching ISMS framework that drives governance, risk management, and security culture across the wider organization.

PCI DSS Requirement	ISO 27001:2022 Control Mapping	Gap Notes
Req. 1-2: Network Security Controls	8.20 (Network Security), 8.21 (Network Services), 8.22 (Segregation)	Strong mapping. PCI DSS Req. 1.2 (network diagram) maps to 5.9 (asset inventory) and 8.20. PCI’s specific firewall rule review cadence (every 6 months) is more prescriptive than ISO 27001’s risk-based approach.
Req. 3-4: Protect Cardholder Data	5.12 (Classification), 8.24 (Cryptography), 8.11 (Data Masking), 8.10 (Data Deletion)	ISO 27001 cryptography policy (8.24) must explicitly address PCI DSS cipher requirements (TLS 1.2+, no SSL). PAN masking in logs and displays maps to 8.11 Data Masking.
Req. 6: Secure Systems and Applications	8.8 (Vulnerability Management), 8.25 (SSDLC), 8.28 (Secure Coding), 8.29 (Security Testing)	Strong alignment. PCI DSS 6.3.3 requires all software components protected from known vulnerabilities — directly implementing 8.8. PCI’s OWASP requirement for web apps maps to 8.28.
Req. 7-8: Access Control and Identity Management	5.15/5.16/5.17/5.18 (Access Control), 8.2 (Privileged Access), 8.5 (Authentication)	PCI DSS 8.4 (MFA for all CDE access) is more prescriptive than ISO 27001’s risk-based MFA requirements. ISO 27001 organizations must ensure their authentication policy explicitly meets PCI MFA requirements for in-scope systems.
Req. 10-11: Logging and Testing	8.15 (Logging), 8.16 (Monitoring), 5.35 (Independent Review), 8.8 (Vulnerability Management)	PCI DSS 11.4 mandates IDS/IPS deployment with signature updates at least every 6 months — more prescriptive than ISO 27001’s risk-based monitoring requirement (8.16). ISO 27001 organizations must ensure 8.16 implementation explicitly satisfies the IDS/IPS requirement.

NIST SP 800-53 Rev. 5

NIST SP 800-53 Rev. 5 is the most comprehensive security control catalog available and is mandatory for US federal agencies. ISO 27001 organizations operating in the federal space or serving US government agencies frequently map their Annex A controls to 800-53 families using the NIST cross-reference tool to demonstrate equivalence.

NIST 800-53 Family	Primary ISO 27001 Mapping	Coverage Notes
AC — Access Control	5.15, 5.16, 5.17, 5.18, 8.2, 8.3, 8.5	Strong alignment. ISO 27001 access control controls cover the primary AC control family requirements. NIST AC-17 (Remote Access) maps to 6.7 (Remote Working).
AU — Audit and Accountability	8.15 (Logging), 8.16 (Monitoring), 8.17 (Clock Sync)	Good alignment. NIST AU-12 (Audit Record Generation) and AU-2 (Event Logging) map directly to 8.15. Clock synchronization (8.17) is a direct mapping to AU-8.
CM — Configuration Management	8.9 (Configuration Management), 8.19 (Software Installation), 8.32 (Change Management)	8.9 is a new 2022 control that directly addresses NIST CM family requirements. Change management (8.32) maps to CM-3.
IA — Identification and Authentication	5.16, 5.17, 8.5	Direct alignment. NIST IA-5 (Authenticator Management) maps to 5.17; IA-2 (Identification and Authentication) maps to 8.5. NIST’s more prescriptive MFA requirements (IA-2(1)) require explicit inclusion in the ISO 27001 authentication policy.
IR — Incident Response	5.24, 5.25, 5.26, 5.27, 5.28	Strong alignment. ISO 27001 incident management controls map directly to NIST IR-4 (Incident Handling), IR-5 (Incident Monitoring), IR-6 (Incident Reporting), and IR-8 (Incident Response Plan).
RA — Risk Assessment	Clause 6.1 (Risk Assessment), 5.7 (Threat Intelligence), 8.8 (Vulnerability Management)	ISO 27001’s mandatory risk assessment methodology (Clause 6.1) maps to NIST RA-3. Threat intelligence (5.7) maps to RA-3(1).
SC — System and Communications Protection	8.20, 8.21, 8.22, 8.24	Good alignment. NIST SC-7 (Boundary Protection) maps to 8.20 and 8.22. SC-8 (Transmission Confidentiality) maps to 8.24 (Cryptography).
SI — System and Information Integrity	8.7 (Anti-malware), 8.8 (Vulnerability Management), 8.16 (Monitoring)	NIST SI-3 (Malicious Code Protection) maps to 8.7. SI-5 (Security Alerts) and SI-4 (System Monitoring) map to 8.16.

HIPAA Security Rule

Healthcare organizations implementing ISO 27001 can leverage their Annex A controls to satisfy HIPAA Security Rule requirements for ePHI protection. ISO 27001 provides the systematic program structure that HIPAA requires but does not fully prescribe.

HIPAA Safeguard Category	ISO 27001 Control Mapping	Notes
Administrative Safeguards (§164.308)	Clause 6 (Risk Assessment), 5.24 (Incident Management), 5.1 (Policies), 6.3 (Training), 5.31 (Compliance)	HIPAA’s Risk Analysis requirement (§164.308(a)(1)) is directly satisfied by ISO 27001 Clause 6.1 risk assessment. The ISO ISMS management framework covers all HIPAA administrative safeguard requirements.
Physical Safeguards (§164.310)	Theme 7 (Physical Controls), 7.1–7.14	All 14 physical controls in Theme 7 directly address HIPAA’s physical safeguard requirements. Workstation security (7.8) and device disposal (7.14) directly map to §164.310(b) and (d).
Technical Safeguards (§164.312)	8.3 (Access Restriction), 8.5 (Authentication), 8.15 (Logging/Audit), 8.24 (Cryptography/Transmission Security)	HIPAA technical safeguards map directly to ISO 27001 Theme 8 technological controls. Encryption in transit (8.24) satisfies §164.312(e)(2)(ii). Audit controls (8.15) satisfy §164.312(b).
Breach Notification (§164.400)	5.25 (Assessment of Events), 5.26 (Incident Response), 5.5 (Authority Contacts)	HIPAA’s 60-day breach notification requirement requires a pre-established process for classifying events as breaches (5.25) and notifying HHS and affected individuals (5.5, 5.26). The ISO incident management framework provides this structure.

══ SECTION 6 ══

6. Implementing ISO 27001:2022: A Practitioner’s Approach

Successful ISO 27001 implementation is a program management challenge as much as a technical one. The most common failure mode is not technical inadequacy but organizational — insufficient executive sponsorship, scope that is too broad for available resources, or treating the standard as a documentation exercise rather than an operational program. The following phased approach reflects lessons from organizations that have achieved and maintained certification effectively.

Phase 1 — Scoping and Context (Clause 4)

Scope definition is the single most consequential decision in ISMS implementation. The scope must be specific enough to be auditable and defensible, but comprehensive enough to cover the organization’s critical information assets and the risks that matter to stakeholders.

Scope Dimensions:Define the ISMS boundary using a combination of organizational (which business units), physical (which locations), and system (which applications and infrastructure) dimensions.
Interested Parties:Identify all interested parties: customers, regulators, shareholders, partners, and employees. Document their security requirements. This is mandatory for Clause 4.2 and shapes the entire risk landscape.
Context Analysis:Conduct a context analysis covering: the organization’s strategic objectives, the threat environment relevant to the industry sector, regulatory obligations, and competitive or reputational dependencies on information security.
Scope Advice:For organizations new to ISO 27001, a narrower initial scope — covering a single business unit, data center, or product line — is vastly preferable to a maximal scope that cannot be implemented effectively before the certification deadline.

Phase 2 — Risk Assessment (Clause 6.1)

The risk assessment is the engine of the ISMS. Its quality directly determines the relevance and proportionality of the entire control set. A risk assessment that is too shallow produces generic, checkbox controls; one that is too granular becomes unmanageable.

Risk Assessment Step	Requirement	Common Failure Mode
Define the methodology	Document the risk assessment approach: asset-based or scenario-based, scoring criteria, risk appetite thresholds. Must be documented and produce consistent, comparable results.	Using a spreadsheet with no methodology documentation. Risk ratings that are subjective and inconsistent across assessors.
Identify assets and risks	Identify all information assets in scope. For each, identify threats, vulnerabilities, and potential impacts on confidentiality, integrity, and availability.	Incomplete asset inventory means unassessed risks. Listing generic risks without mapping to specific assets or processes.
Assess and prioritize risks	Rate each risk by likelihood and impact to produce a risk score. Map scores against the risk appetite to determine which risks require treatment.	Risk scoring that clusters all risks in the medium band, making prioritization impossible. Risk appetite not explicitly defined, so treatment decisions have no objective basis.
Select risk treatment	For each risk exceeding appetite, select: Modify (implement controls), Avoid, Transfer (insurance, contracts), or Retain. Document treatment rationale.	Defaulting to “implement controls” for every risk without evaluating avoid, transfer, or retain options. Risk treatment plan not linked to specific Annex A controls.
Produce the Risk Treatment Plan and SoA	The RTP and SoA must be consistent with each other and must be reviewed and re-approved whenever a significant risk change occurs.	SoA produced once and never updated. RTP milestones not tracked. Controls marked “implemented” in the SoA that are still in planning.

Phase 3 — Control Implementation Priorities

Not all 93 Annex A controls have equal operational impact. The following prioritization reflects both the risk reduction value of each control and its frequency as a root cause of security incidents:

Priority Tier 1 — Foundational Controls (Implement First)

8.5 Secure Authentication:Deploy MFA across all administrative and remote access. This single control eliminates the credential stuffing and password spray attack vectors that initiate the majority of intrusions.
8.8 Vulnerability Management:Establish patch SLAs and automated scanning. Unpatched known vulnerabilities are the most common exploitation vector — Salt Typhoon, WannaCry, MOVEit, and the vast majority of ransomware attacks all exploited known, patchable vulnerabilities.
8.16 Monitoring Activities:Deploy SIEM with log ingestion from all critical sources. Blind environments cannot detect intrusions, rendering every other control unable to trigger a response.
5.9 Asset Inventory:Maintain a complete, current inventory. Unknown assets are unmanaged attack surface.
8.13 Backup:Implement and test backup and recovery. The only effective ransomware recovery mechanism is a tested, isolated, immutable backup.

Priority Tier 2 — Program Controls (Implement Within 90 Days)

5.24/5.26 Incident Response:Document and test the IR plan before an incident occurs, not during one.
8.2 Privileged Access:Deploy PAM with session recording; conduct quarterly privileged account reviews.
8.22 Network Segregation:Segment production from development, and isolate high-value systems from general user networks.
6.3 Security Awareness Training:Conduct role-specific training, not just annual compliance click-through modules.
8.9 Configuration Management:Baseline all systems against CIS Benchmarks; detect and alert on configuration drift.

Priority Tier 3 — Maturity Controls (Implement Within 12 Months)

5.7 Threat Intelligence:Subscribe to and operationalize sector-specific threat feeds; integrate with the risk assessment process.
8.25/8.28 Secure Development:Integrate SAST/DAST into the CI/CD pipeline; adopt secure coding standards.
8.12 Data Leakage Prevention:Deploy DLP after data classification is mature enough to define what “sensitive” means.
5.23 Cloud Security:Implement cloud security posture management (CSPM) for all cloud tenants.

Phase 4 — Internal Audit Program

The internal audit program (Clause 9.2) is the primary quality assurance mechanism for the ISMS. A well-designed audit program provides the evidence that controls are operating effectively — not just implemented — and surfaces issues before the external certification auditor does.

Program Design:Design the audit program to cover the entire ISMS scope over a defined cycle (typically annual), with higher-risk areas audited more frequently.
Independence:Internal auditors must be independent of the area they audit. This does not require external auditors — a security analyst auditing the network team’s controls satisfies independence. However, small organizations may need to engage an external party for internal audit.
Evidence Documentation:Audit evidence must be documented: interviews recorded in notes, documents reviewed listed, tests performed with results captured. An audit that produces no evidence is not an audit.
Non-Conformity Handling:Non-conformities found during internal audit must be entered into the corrective action process (Clause 10.2) with root cause analysis, corrective action, and effectiveness verification.

Phase 5 — Continual Improvement

ISO 27001 is explicitly designed for continual improvement, not point-in-time certification. The ISMS must evolve as the threat landscape, the organization, and the regulatory environment change. The following improvement triggers should be built into the program’s operating rhythm:

Trigger	Required Response	ISO 27001 Clauses
Security incident	Post-incident review with root cause analysis; update risk register; implement corrective action; review SoA for control gaps; notify certification body if significant.	5.27, 10.2, Clause 8.2
New vulnerability disclosure (Critical)	Emergency patch process invoked; risk assessed if unpatched; compensating controls documented; communication to stakeholders if data at risk.	8.8, 6.1, Clause 8
Significant business change	Re-scope ISMS if necessary; update context and interested parties analysis; re-run risk assessment for changed areas; update SoA if new systems in scope.	Clauses 4, 6, Clause 6.3
Regulatory change	Update compliance register (5.31); assess impact on existing controls; update risk treatment plan if new obligations require new controls.	5.31, 5.34, Clause 6.1
Failed audit finding	Root cause analysis; corrective action plan with named owner and deadline; effectiveness verification; management review agenda item.	10.2, Clause 9.3
Threat intelligence update	Assess whether new threat patterns affect the organization’s risk profile; update risk register if significant; consider new controls or control tuning.	5.7, 6.1, Clause 8.2
Annual management review	Review all ISMS performance data; assess achievement of objectives; adjust objectives and risk appetite if required; approve resource allocations for improvement program.	Clause 9.3, 6.2

The PDCA Engine

ISO 27001’s structure is built on the Plan-Do-Check-Act (PDCA) cycle: Clause 6 Plans the ISMS, Clause 8 Does the implementation, Clause 9 Checks performance, and Clause 10 Acts on improvements. Practitioners who understand this architecture treat the management review (9.3) not as a bureaucratic compliance requirement but as the governing board meeting of the ISMS — the place where strategic decisions about risk appetite, resource investment, and program direction are made and documented.

Common Implementation Mistakes to Avoid

Mistake	Consequence	Correct Approach
Scope too broad for resources available	Controls are documented but not implemented across the full scope. Stage 2 audit finds systematic gaps.	Start with a narrower scope that can be fully implemented. Expand scope progressively after certification.
Risk assessment not linked to controls	Controls selected from a generic list rather than from risk treatment decisions. SoA cannot be justified to the auditor.	Every included Annex A control must trace to a risk treatment decision or regulatory obligation in the SoA.
Policies created for audit, not for operations	Policies describe ideal states that do not reflect actual operations. Auditor interviews reveal staff are unaware of or do not follow documented policies.	Develop policies collaboratively with the operational teams who must implement them. Test awareness before the audit.
Internal audit conducted by the ISMS team	Lack of independence means the internal audit does not challenge the program and produces no useful findings.	Internal auditors must be independent of the area audited. Use cross-functional auditors or engage external support.
Management review treated as a box-tick	Decisions made outside the review, not within it. Meeting minutes are thin, inputs incomplete, outputs not tracked.	Management review must produce documented decisions on resources, objectives, and risk. Track actions to completion.
Corrective actions closed without verification	Root causes not eliminated; issues recur at next audit.	Clause 10.2 requires verification of effectiveness. Define how you will verify before closing the action.

7. References and Further Reading

ISO/IEC Standards

ISO/IEC 27001:2022 — Information Security, Cybersecurity and Privacy Protection — Information Security Management Systems — Requirements
ISO/IEC 27002:2022 — Information Security, Cybersecurity and Privacy Protection — Information Security Controls
ISO/IEC 27005:2022 — Information Security, Cybersecurity and Privacy Protection — Guidance on Managing Information Security Risks
ISO/IEC 27701:2019 — Security Techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for Privacy Information Management
ISO/IEC 27017:2015 — Code of Practice for Information Security Controls for Cloud Services

Regulatory and Government Publications

NIST Cybersecurity Framework 2.0 (2024) — https://www.nist.gov/cyberframework
NIST SP 800-53 Rev. 5: Security and Privacy Controls — National Institute of Standards and Technology
NIST SP 800-37 Rev. 2: Risk Management Framework — NIST
GDPR (Regulation EU 2016/679) — EUR-Lex: https://eur-lex.europa.eu
CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
CISA/NSA/FBI Joint Advisory on Salt Typhoon TTPs (August 2025) — Telecommunications Infrastructure Hardening Guidance
PCI DSS v4.0 — PCI Security Standards Council: https://www.pcisecuritystandards.org
HIPAA Security Rule — HHS Office for Civil Rights: https://www.hhs.gov/hipaa/for-professionals/security

Practitioner Resources

MITRE ATT&CK Framework: https://attack.mitre.org — adversary TTPs for threat modeling and control gap analysis
CIS Controls v8 and CIS Benchmarks: https://www.cisecurity.org — technical configuration baselines for 8.9 Configuration Management
OWASP Top 10 and OWASP SAMM: https://owasp.org — secure development standards supporting 8.25 and 8.28
ISO 27001 Security: https://www.iso27001security.com — practitioner templates, checklists, and SoA examples
IAPP (International Association of Privacy Professionals): https://iapp.org — privacy-ISMS integration guidance