ISO framework group: ISO 27001, 27002, 27017, 27018, 27701, 22301, 31000, 42001 and more

ISO/IEC 27001:2022

Any organisation that wants a certifiable, internationally recognised information security management system. Applies across all industries and sizes. Most commonly pursued by technology companies, financial services firms, healthcare providers, and government contractors where customers or regulators require it as a baseline qualification.

The Statement of Applicability becomes a documentation exercise disconnected from operational controls. Controls are listed as implemented because they exist somewhere in the organisation, not because they are effective. Risk treatment decisions are not revisited when the threat landscape or business context changes. The ISMS exists on paper; the security programme exists in IT.

A documented ISMS scope, a risk assessment methodology that is defined and repeatable, a Statement of Applicability mapping Annex A controls to risk treatment decisions with justification for exclusions, evidence of top management involvement in security decisions, an internal audit programme, and management review meetings with documented outputs. The 2022 revision added requirements around planning for changes, attributes on controls aligned to ISO 27002:2022, and a stronger emphasis on demonstrating that controls are effective, not just implemented.

Certification is voluntary but commercially enforced through procurement requirements. Loss of certification triggers customer notification obligations under many enterprise contracts. Surveillance audits occur annually; full recertification every three years. Nonconformities identified during surveillance can result in certification suspension.

ISO 27001 is the certifiable management system that gives the rest of the group its authority. ISO 27002 is its control catalogue. ISO 27017, 27018, 27701, and 42001 are all implemented as extensions of or alongside an ISO 27001 ISMS. ISO 22301 uses the same High Level Structure. ISO 31000 informs the risk assessment methodology. ISO/SAE 21434 borrows the management system concept but operates in a separate regulatory context.

ISO/IEC 27002:2022

Security architects, control owners, and assessors implementing or evaluating controls within an ISO 27001 ISMS. Not certifiable independently — used as a reference standard during implementation and audit. Also used by anyone mapping controls across multiple frameworks.

The 11 new controls in the 2022 revision — threat intelligence, data masking, data leakage prevention, secure coding, web filtering, cloud service security, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, and monitoring activities — are the ones most commonly excluded without adequate justification. They were added because they became critical in the decade since 2013. Excluding them requires documented rationale tied to the organisation''s risk context, not a generic ''not applicable'' statement.

The 2022 edition provides 93 controls across four themes: 37 organisational, 8 people, 14 physical, and 34 technological. Each control entry includes purpose, the control statement, implementation guidance, and other information. The attribute system tags each control with cybersecurity concept (aligned to NIST CSF Identify-Protect-Detect-Respond-Recover), control type, information security properties, operational capability, and security domain — enabling multi-dimensional filtering and cross-framework mapping.

No direct enforcement. ISO 27001 auditors use ISO 27002 as the reference when assessing whether Annex A controls are adequately implemented. Inadequate implementation guidance in the Statement of Applicability, where controls are listed without substance, produces audit findings against ISO 27001.

ISO 27002 is the implementation specification for ISO 27001 Annex A controls. ISO 27017 extends 37 of those controls with cloud-specific guidance and adds 7 cloud-only controls. ISO 27018 extends the control set with PII-specific requirements. ISO 27701 adds a privacy layer to the control environment. The attribute system in ISO 27002:2022 is the most practical tool available for mapping controls to NIST CSF, CIS Controls, or other frameworks.

ISO/IEC 27017:2015

Cloud service providers (IaaS, PaaS, SaaS) demonstrating security assurance to enterprise customers, and cloud service customers defining and managing provider security obligations. Both perspectives are addressed explicitly within the standard.

The shared responsibility documentation required by the seven cloud-only controls is rarely maintained at the granularity the standard intends. Providers produce a generic shared responsibility matrix covering IaaS, PaaS, and SaaS in aggregate — not the customer-specific, service-specific allocation of responsibilities that a genuine ISO 27017 implementation requires. Customers accept the generic matrix without verifying it applies to their actual service configuration.

Cloud-specific implementation guidance for 37 ISO 27002 controls, covering how those controls differ in cloud contexts — virtual resource inventory, cloud management plane access controls, API call logging, split key management. Seven additional controls with no ISO 27002 equivalent: shared roles and responsibilities documentation, asset return on contract termination, virtual environment segregation, virtual machine hardening, monitoring of administrative operations, security policy alignment between customer and provider, and virtual network security.

No standalone certification. Implemented as a scope extension of ISO 27001 certification. Enterprise procurement increasingly references ISO 27017 alongside ISO 27001 as a cloud supplier baseline. Absence of alignment is frequently raised as a finding in cloud security assessments.

Extends ISO 27002 with cloud-specific control guidance. Typically implemented alongside ISO 27018 for cloud providers serving regulated industries. The split key management and provider administrative access monitoring controls directly address risks that ISO 27001 alone does not adequately cover in cloud environments.

ISO/IEC 27018:2014

Public cloud service providers acting as PII processors — organisations that process personal data on behalf of enterprise customers but do not determine the purposes of that processing. Does not apply to controllers.

The prohibition on using customer PII for the provider''s own purposes is commercially significant and frequently misunderstood. Providers with analytics products built on aggregated customer data have faced the question of whether anonymisation is sufficient to satisfy this requirement — the answer depends on whether re-identification is technically feasible, and that determination is rarely made with the rigour the standard contemplates.

Purpose limitation: PII processed only for purposes specified in the contract, with no use for the provider''s own advertising, analytics, or marketing without explicit customer consent. Transparency: disclosure of sub-processor locations, notification of law enforcement requests to the extent legally permitted, breach notification to customers within defined timeframes. Data subject rights support: mechanisms for locating, retrieving, correcting, and deleting PII on customer request. PII-specific security: need-to-know access restriction, logging of all PII system access, encryption in transit and at rest, staff confidentiality obligations.

Available as a scope extension of ISO 27001 certification. Major cloud providers including Microsoft Azure, AWS, and Google Cloud hold ISO 27018 certification. Procurement teams in regulated industries use it as a qualifier for processing contracts involving personal data. Failure to maintain certification creates audit exposure under GDPR processor agreements.

Extends ISO 27002 from the processor privacy perspective. Complements ISO 27017 (which covers the security split) by covering what cannot be done with the data at all. ISO 27701 covers the controller-and-processor privacy management system; ISO 27018 covers the processor-specific operational controls. ISO 29100 provides the principled foundation that 27018 operationalises.

ISO/IEC 27701:2025

Any organisation that processes personal data — controllers who determine processing purposes and processors who handle data on behalf of others. Requires an existing ISO 27001-compatible ISMS as a prerequisite. Particularly relevant for organisations subject to GDPR, CCPA, Thailand PDPA, Singapore PDPA, and similar privacy regulations.

Organisations treat ISO 27701 as an add-on to an existing ISO 27001 programme without revisiting the ISMS scope. If the ISO 27001 scope excludes certain processing activities or business units, the ISO 27701 extension inherits those exclusions — creating a PIMS that certifiably covers the wrong scope for the actual privacy risk.

A Privacy Information Management System built on the ISO 27001 ISMS foundation, adding privacy-specific controls for both controllers and processors. Controller requirements cover lawful basis for processing, consent management, privacy notices, data subject rights (access, erasure, portability), and privacy by design. Processor requirements cover contracts, sub-processor management, data breach notification, and demonstrating compliance to customers. The 2025 revision aligns with ISO 27001:2022 and updates guidance for cloud computing, AI systems, and complex data sharing arrangements.

Certifiable through accredited bodies, typically conducted alongside an ISO 27001 audit. ISO 27701 certification does not constitute GDPR compliance but provides strong, independently verified evidence that privacy obligations are systematically implemented. Increasingly referenced in DPA enforcement actions as evidence of accountability under GDPR Article 5(2).

The management system layer that ISO 27018 and ISO 27017 operate within. ISO 27018 provides processor-specific operational controls; ISO 27701 provides the management system governance for both controllers and processors. ISO 29100 is the principled foundation. ISO 27002:2022 controls are extended with privacy-specific implementation guidance through ISO 27701.

ISO/IEC 29100:2024

Technology architects, software developers, product managers, and compliance professionals designing systems that handle personal data. Standards bodies and policymakers developing sector-specific privacy requirements. Organisations establishing a shared privacy vocabulary across functions. Not certifiable.

Treated as a theoretical document rather than a practical design tool. Engineering teams who have never read it produce systems that violate its principles through architectural decisions made early in the design phase — decisions that are expensive to reverse once the system is in production. Purpose limitation violations in particular are almost always architectural, not operational.

Adherence to eleven privacy principles: Consent and Choice, Purpose Legitimacy and Specification, Collection Limitation, Data Minimisation, Use/Retention/Disclosure Limitation, Accuracy and Quality, Openness/Transparency/Notice, Individual Participation and Access, Accountability, Information Security, and Privacy Compliance. The 2024 revision updates the framework for cloud computing, AI, and IoT environments that have emerged since the 2011 original. Defines roles: PII Principal (the individual), PII Controller, PII Processor.

No enforcement mechanism and no certification. Used as a design reference and as the foundational layer for other ISO privacy standards. Referenced by regulators and policymakers developing privacy requirements. Organisations that design systems against ISO 29100 principles build compliance foundations for GDPR and similar frameworks without duplicating effort.

The foundational principles document that ISO 27018, ISO 27701, and other privacy standards operationalise. The eleven principles map closely to GDPR requirements. Reading ISO 29100 first provides the conceptual framework that makes the control requirements in ISO 27701 and ISO 27018 legible.

ISO/IEC 22301:2019

Organisations of any size or sector requiring a structured business continuity management system. Heavily adopted in financial services, healthcare, critical infrastructure, and government under regulatory requirements. Executive leadership carries explicit accountability under the standard.

The BIA is conducted at the application or IT tier without mapping to actual business functions and their owners. RTOs and RPOs are set based on technical feasibility rather than business tolerance — IT says they can restore in four hours, nobody asked the business what four hours of outage actually costs. Exercise programmes become annual tabletop exercises that do not test the assumption that actual recovery is achievable within the stated objectives.

A formal Business Impact Analysis identifying critical functions, their maximum tolerable period of disruption, and minimum resource requirements for resumption. Recovery Time Objectives and Recovery Point Objectives defined per function, driving all continuity strategy and plan design. Documented plans covering activation triggers, roles, communication procedures, and step-by-step recovery procedures. A programme of exercises validating plan effectiveness — tabletop through live failover — with results fed back into plan improvement. Ongoing monitoring of BCMS performance against stated objectives.

Certifiable through accredited bodies. Two-stage audit: Stage 1 assesses documentation; Stage 2 assesses implementation and effectiveness. Annual surveillance audits, full recertification every three years. Required or strongly preferred by financial regulators, government procurement frameworks, and enterprise customers in critical supply chains. Certification suspension for unresolved nonconformities.

Shares the ISO High Level Structure with ISO 27001, enabling integrated BCMS and ISMS implementation with a single governance structure. ISO 27001 Annex A control 5.30 (ICT readiness for business continuity, new in 2022) requires the ISO 27001 programme to address continuity of information security functions — ISO 22301 provides the full continuity management system that gives that control substance. ISO 31000 underpins the risk assessment component.

ISO 31000:2009

Risk managers, chief risk officers, governance professionals, and executive leadership across any industry and any risk domain. Applicable to financial, operational, strategic, reputational, information security, and safety risk. Not certifiable.

Cited as the methodological basis for ISO 27001 risk assessments while the actual assessment process is a qualitative heat map completed in a spreadsheet with no defined criteria for consequence assessment, no documented likelihood basis, and no connection between the risk register and the treatment decisions recorded in the Statement of Applicability. ISO 31000 is in the methodology documentation; the methodology described in ISO 31000 is not in the assessment.

Eleven principles of effective risk management including that risk management creates value, is integral to decision-making, is dynamic and responsive to change, and is based on the best available information. A framework covering mandate and commitment, framework design, implementation, monitoring and review, and continual improvement. A risk management process: establish context, identify risks, analyse risks, evaluate risks, treat risks, communicate and consult throughout, monitor and review.

No certification, no enforcement. Referenced by ISO 27001, ISO 22301, and numerous sector-specific frameworks as the foundational risk management methodology. Organisations claiming ISO 31000 alignment in their risk documentation are rarely assessed against its principles in any rigorous way.

The parent risk framework for the ISO standards family. ISO 27001''s risk assessment requirements are designed to be compatible with ISO 31000. ISO 22301 applies ISO 31000 principles to continuity risk. ISO 31010 provides the technical toolkit for the risk assessment step of the ISO 31000 process. ISO 42001 applies the same risk process to AI-specific risks.

ISO/IEC 31010:2009

Risk practitioners, safety engineers, information security professionals, and any practitioner selecting and applying risk assessment techniques. Used by ISO 27001 implementers justifying their risk assessment methodology, by ISO 22301 implementers conducting Business Impact Analyses, and by safety-critical industries requiring documented technique selection rationale. Not certifiable.

The technique catalogue is consulted during ISMS documentation creation and then ignored in practice. The organisation selects a likelihood-consequence matrix for its ISO 27001 risk assessment — a reasonable default — but applies it without defining the scale anchors, without calibrating likelihood estimates against historical data, and without revisiting whether the technique is appropriate as the risk environment changes. The method is documented; the discipline of applying it is not.

Structured guidance on selecting appropriate techniques based on: which phase of risk assessment is being performed (identification, analysis, evaluation); whether qualitative, semi-quantitative, or quantitative outputs are needed; data availability; resource constraints; and regulatory requirements. A catalogue covering 30-plus techniques including brainstorming, SWIFT, fault tree analysis, bow-tie analysis, FMEA, Monte Carlo simulation, and scenario analysis, with strengths, limitations, inputs, and outputs for each.

No certification, no direct enforcement. ISO 27001 auditors may question the basis for technique selection if an organisation''s risk assessment methodology documentation references ISO 31010 but the actual technique applied is demonstrably inappropriate for the risk context.

The technical implementation layer for ISO 31000''s risk assessment step. Referenced by ISO 27001 practitioners selecting risk assessment methods. The bow-tie analysis technique in the catalogue is particularly useful for ISO 22301 threat and consequence modelling and for ISO/SAE 21434 TARA analysis — a connection that is rarely made explicit but produces significantly better outputs when it is.

ISO/IEC 42001:2023

Organisations that develop AI systems, organisations that deploy AI systems in their operations, and organisations that provide AI as a service. Compliance officers, AI governance teams, and risk managers navigating AI regulation including the EU AI Act. Applies at any scale — from a single AI-powered internal tool to a full AI development programme.

AI impact assessments are scoped to the organisation''s risk of regulatory exposure rather than the actual societal impact of the AI system. A system with significant potential to produce discriminatory outcomes in hiring or credit decisions is assessed against the probability that a regulator investigates, not against the actual harm caused. This is the opposite of what the standard requires.

An Artificial Intelligence Management System: documented AI policy, AI impact assessments evaluating effects on individuals and society, systematic AI risk assessment covering algorithmic bias, model performance drift, opacity, misuse, and accountability gaps. Lifecycle controls across data acquisition, model development, validation, deployment, monitoring, and decommissioning. Human oversight mechanisms with documented accountability for AI-influenced decisions. Transparency obligations for affected parties. Supply chain assessment for third-party AI systems.

Certifiable against the standard through accredited bodies. No current mandatory regulation directly mandates ISO 42001, but the EU AI Act''s requirements for high-risk AI systems — risk management systems, data governance, transparency, human oversight, accuracy — map closely to the standard''s requirements. ISO 42001 certification provides structured evidence of AI governance maturity relevant to regulatory compliance, though formal harmonisation with the EU AI Act is still developing.

Shares the ISO High Level Structure with ISO 27001 and ISO 22301, enabling integrated implementation for organisations already operating ISO management systems. AI data governance overlaps significantly with ISO 27001 information security controls, ISO 27701 privacy controls, and ISO 29100 privacy principles — particularly around data quality, data minimisation, and purpose limitation. An organisation with a mature ISO 27001 and ISO 27701 programme can implement ISO 42001 with substantially less additional governance infrastructure than one starting from scratch.

ISO/SAE 21434:2021

Automotive OEMs, Tier 1 and Tier 2 suppliers, and engineering service providers developing vehicle systems and components with electronic or software elements. Cybersecurity engineers, systems architects, and homologation teams responsible for UN R155 compliance.

The TARA is treated as a documentation deliverable rather than an engineering input. Attack feasibility assessments are completed at the item level using generic threat scenarios rather than being informed by vehicle-specific attack surface analysis and component-level threat intelligence. The result is a TARA that passes documentation review but does not inform cybersecurity requirement derivation in any meaningful way — and the gap becomes visible when penetration testers identify attack paths that the TARA rated as low feasibility.

A Cybersecurity Management System as an organisational capability demonstrated to type approval authorities. Threat Analysis and Risk Assessment (TARA) as the core engineering methodology — identifying vehicle assets, enumerating damage scenarios and threat scenarios, assessing attack path feasibility using defined criteria (elapsed time, expertise, knowledge, opportunity, equipment), and determining risk values that drive treatment decisions. Cybersecurity requirements derived from TARA outputs and allocated to system, hardware, and software levels. Supply chain management with documented cybersecurity interfaces and supplier capability assessments. Post-production cybersecurity monitoring, incident response, and over-the-air update capability where applicable.

ISO 21434 itself does not mandate certification, but UN Regulation 155 requires OEMs to have an approved Cybersecurity Management System as a condition of vehicle type approval in UNECE member states. UN R155 became mandatory for new vehicle type approvals from July 2022 and for all new vehicles from July 2024. Type approval withdrawal for non-compliance is commercially equivalent to a market ban.

Sits apart from the rest of the ISO group in its regulatory context and automotive specificity. The TARA methodology applies the same risk identification-analysis-evaluation-treatment logic as ISO 31000 and ISO 31010 — bow-tie analysis from the ISO 31010 catalogue is directly applicable to TARA threat scenario and damage scenario modelling. The CSMS organisational requirements parallel the management system requirements in ISO 27001 but are implemented within the automotive type approval process rather than the ISO certification ecosystem.

ISO 27001 risk treatment focuses on protecting information assets — the question is whether a control reduces the likelihood or impact of a security event. ISO 22301 continuity strategy focuses on restoring critical functions — the question is whether a recovery capability meets the RTO and RPO defined in the BIA. These are related but distinct questions, and organisations that merge the risk registers without separating the objectives end up with a document that answers neither question well.

Risk assessment and risk treatment. Both standards require identifying threats to critical assets or functions, assessing likelihood and consequence, and selecting treatments. ISO 27001 Annex A control 5.30 (ICT readiness for business continuity) explicitly requires the information security programme to address continuity scenarios. ISO 22301 requires a BIA that identifies critical IT systems and their recovery dependencies.

ISO 27018 is more operationally specific about what a cloud processor cannot do — using customer PII for its own purposes without consent is explicitly prohibited in a way that ISO 27701''s processor controls do not state with equivalent directness. ISO 27701 covers the management system infrastructure; ISO 27018 covers the specific prohibitions on data use that arise from the processor role. A cloud provider needs both to cover the full scope.

Processor obligations. Both standards address organisations that process personal data on behalf of others. ISO 27018 specifies operational controls for PII handling in public cloud environments. ISO 27701 specifies the management system governance for processors broadly.

ISO 27001 governs security of information assets — confidentiality, integrity, availability. ISO 42001 governs the safety and ethics of AI decision-making — bias, transparency, accountability, societal impact. A system can be perfectly secure against external attack and still violate ISO 42001 requirements through opaque decision-making that produces discriminatory outcomes. These are different failure modes requiring different governance.

Data governance, access control, and supplier management. AI systems process data — often sensitive data — and the governance of that data overlaps substantially with ISO 27001 information security controls. AI supplier and third-party AI system assessment requirements in ISO 42001 parallel ISO 27001 supplier security requirements.

ISO 31000 defines risk as ''the effect of uncertainty on objectives'' — positive and negative. ISO 27001 risk assessment focuses on threats to confidentiality, integrity, and availability — an inherently negative framing. Organisations implementing ISO 27001 using ISO 31000 as their methodology sometimes struggle to reconcile the positive-risk dimension of ISO 31000 with the threat-focused scope of ISO 27001 risk assessment.

Risk management process. ISO 27001 requires a defined, repeatable risk assessment process compatible with ISO 31000. The identification, analysis, and evaluation steps in both frameworks are aligned.

ISO 29100 is technology-neutral and non-certifiable — it defines what privacy should look like. ISO 27701 is implementation-specific and certifiable — it defines what controls must exist and how the management system must be operated. An organisation can align with ISO 29100 principles without implementing ISO 27701 controls; the reverse is theoretically possible but would produce a PIMS that implements procedures without understanding the privacy intent they serve.

Privacy principles including consent, purpose limitation, data minimisation, and accountability. ISO 29100 defines the principles; ISO 27701 operationalises them in management system controls.

Pursuing standards sequentially rather than architecturally

Compliance milestones are commercially driven — a customer requires ISO 27001, then another requires ISO 27701, then a cloud procurement requires ISO 27017. Each certification is scoped and delivered to satisfy the immediate commercial requirement. Nobody designs the overall architecture first because there is no single moment when the full set of requirements is visible at once.

Each successive certification inherits the scope limitations and architectural decisions of the previous one. By the time an organisation holds four or five ISO certifications, they have four or five overlapping but misaligned control environments, multiple inconsistent risk registers, and a compliance programme that consumes significant resource while producing coverage gaps that are invisible to any single certification auditor.

Treating ISO 31000 and ISO 31010 as methodology documentation rather than working tools

Risk methodology documentation is written to satisfy the ISO 27001 requirement for a defined, repeatable assessment process. Once written, it is filed. The actual risk assessment process continues to be whatever the security team was doing before — typically, a subjective likelihood-consequence matrix completed annually with no documented basis for any individual estimate.

Risk treatment decisions — which controls to implement, which to exclude, which to accept as residual risk — are not traceable to documented risk analysis. When an auditor or a regulator asks why a specific control was excluded, the organisation can point to the SoA entry but cannot demonstrate the risk reasoning behind it. This is a documentation failure in good times and a liability in bad ones.

Implementing ISO 42001 as an IT governance extension rather than an organisational governance requirement

AI systems are built and operated by technical teams. When ISO 42001 lands on the compliance agenda, it is assigned to the ISMS team or the IT department because ''it is a technical standard.'' The result is an AI management system that covers technical controls — model validation, data quality, access controls on AI infrastructure — without addressing the accountability, transparency, and impact assessment requirements that operate at the organisational and product level.

An AI management system that satisfies the technical controls of ISO 42001 while leaving the human oversight, accountability, and societal impact assessment requirements unimplemented is not an AI management system — it is a collection of AI security controls. The EU AI Act requirements that ISO 42001 is positioned to address are governance requirements, not security requirements. Missing the governance layer leaves the regulatory exposure in place.

Confusing ISO/SAE 21434 documentation with TARA validity

The TARA is a documentation deliverable that type approval authorities review. The incentive structure for automotive suppliers is to produce TARA documentation that passes review, not TARA analysis that accurately reflects the attack surface. Under time pressure and cost constraints, feasibility assessments use generic templates rather than component-specific analysis. The TARA is completed; the engineering question it was supposed to answer is not.

Cybersecurity requirements derived from an underestimated TARA are systematically insufficient. Countermeasures are selected against the feasibility rating in the TARA, not against the actual difficulty of exploitation. When security researchers or hostile actors perform their own assessment of the vehicle, they routinely identify attack paths with higher feasibility than the TARA recorded. The gap between documented and actual security posture can span years of the vehicle''s production lifetime before it is identified.