How to integrate ISO 42001 with ISO 27001 without rebuilding your ISMS
ISO 42001 was published in December 2023. For B2B SaaS companies that already hold ISO 27001 certification, the question is operational: how to integrate ISO 42001 with ISO 27001 without running two parallel management systems. The decision sounds technical but it is structural. Done correctly, an existing ISMS extends to cover ISO 42001 with a single management review, a single internal audit cycle, and a single consolidated statement of applicability. Done incorrectly, you end up with two systems that drift apart, audit findings on inconsistency, and a budget catastrophe at recertification.
This post walks the clause-by-clause overlap between the two standards, the controls that genuinely differ, and what certification bodies actually look for when an organization claims dual scope. The audience is the CISO, Head of Compliance, or DPO who already runs an ISO 27001 ISMS and is now scoping ISO 42001 readiness against an enterprise sales requirement or an internal AI governance commitment.
Quick answer
ISO 42001 and ISO 27001 share the high-level structure of all ISO management system standards under Annex SL, which means Clauses 4 through 10 align almost one-to-one. The integration work concentrates in two places: the AI-specific risk language in Clause 6.1, particularly the new requirement for an AI System Impact Assessment in Clause 6.1.4, and the 38 Annex A controls in ISO 42001:2023, some of which extend ISO 27001:2022 controls and some of which have no analog. Treat the existing ISMS as the spine and extend it. A single management review covers both standards, a single integrated risk process covers both with AI risk types added, and a single consolidated SoA lists controls from both Annex A catalogs.
Why integration is a binary decision
Most companies do not realize the integration choice is binary until they are already on the wrong side of it. There are two patterns. The first is structural extension: the existing ISO 27001 ISMS is widened to cover AI management, with one set of integrated procedures, one risk methodology, one audit calendar, and one set of policies that explicitly reference both standards. The second is bolt-on: ISO 42001 gets implemented as a separate management system that runs in parallel, with its own AI policy, its own risk register, its own audit program, and its own evidence collection.
The bolt-on pattern looks faster early but produces predictable failures. Certification bodies auditing dual scope expect to see procedural integration. When they see two policies on document control, two procedures on internal audit, and two risk assessments that classify the same asset differently, they raise findings. The team running the systems pays the cost twice: writing duplicate documents, attending duplicate review meetings, training new hires on both systems separately.
Structural extension takes longer in the planning phase but produces a system that can be audited as one. The same management review covers ISMS objectives and AIMS objectives. The same internal audit covers both standards in a single cycle. The same statement of applicability lists ISO 27001:2022 Annex A controls and ISO 42001:2023 Annex A controls in one consolidated table.
The bolt-on pattern usually emerges from a project assignment problem. ISO 27001 is owned by the security team. ISO 42001 gets handed to the AI/ML team or to a separate AI governance lead. Each team builds the system they understand. The integration only gets attempted later, often after the first surveillance audit reveals the divergence. By then, both systems have evidence, audit logs, and operational rhythms that resist consolidation.
The right call is to make the integration decision before either system is built, or before the second system gets stood up. Pick the structural extension path on day one. Name a single owner who covers both standards or who has explicit authority across both teams.
Where Clauses 4 through 10 align
Both ISO 27001 and ISO 42001 follow Annex SL, the harmonized structure that ISO uses for all management system standards published since 2012. The result is that Clauses 4 through 10 carry through with nearly identical language and intent.
Clause 4 (Context of the organization) requires the same activity in both: identify internal and external issues, identify interested parties and their requirements, define the scope of the management system. The scope statement in an integrated system simply lists both AI management and information security management. One context analysis exercise covers both standards.
Clause 5 (Leadership) requires top management commitment, a published policy, defined roles. The integrated approach is one policy document with explicit sections for information security and AI management, signed by the same management team. The roles are defined in a single matrix that includes both ISMS responsibilities and AIMS responsibilities.
Clause 6 (Planning) is where the standards begin to diverge, and the divergence is significant enough to warrant its own section below.
Clauses 7 (Support), 8 (Operation), 9 (Performance evaluation), and 10 (Improvement) realign closely. Documented procedures for resource management, awareness, communication, document control, internal audit, management review, nonconformity, and continual improvement carry through both standards. The same procedure can satisfy both, provided it explicitly references AI management scope as well as information security scope.
The practical outcome: a documented procedure on document control written for ISO 27001 needs perhaps a single sentence added to bring it into ISO 42001 scope. A procedure on management review needs the agenda template extended to include AI-specific KPIs. A procedure on internal audit needs the auditor competence requirements extended to cover AI management knowledge. None of this is rebuild work. It is extension.
The Clause 6.1 fork: information security risk versus AI risk
Clause 6.1 is where the standards meaningfully separate. ISO 27001 Clause 6.1.2 requires an information security risk assessment process. ISO 42001 Clause 6.1.2 requires an AI risk assessment process. These are not the same risk assessment.
ISO 27001's risk model is asset-focused and CIA-oriented. The risks under assessment are threats to confidentiality, integrity, and availability of information assets. The risk register lists assets, threats, vulnerabilities, likelihood, impact, and a treatment decision.
ISO 42001's risk model is broader. The standard requires consideration of AI-specific risk types: harm to individuals, harm to groups, harm to society, fairness and bias, safety, security, transparency and explainability, accountability, environmental impact, and effects on human rights. The risk register schema must extend to capture risk type as a field, and the assessment methodology must adapt based on type. A bias risk on a hiring model is not assessed with a CVSS score.
ISO 42001 also introduces Clause 6.1.4 AI System Impact Assessment, a requirement that has no direct analog in ISO 27001. The AI System Impact Assessment is a parallel artifact to the risk assessment, focused on the consequences of an AI system to individuals, groups, and society. It is closer in shape to a GDPR Article 35 Data Protection Impact Assessment than to an ISO 27001 risk assessment, but distinct from both. The output is documented evaluation of impacts, not just risks, with consideration of intended use, foreseeable misuse, and stakeholder views.
The integration mistake here is using the existing ISO 27001 risk methodology to cover AI risks. It produces a risk register that misses bias, fairness, transparency, and societal impact entirely. Auditors examining ISO 42001 Clause 6.1 evidence will read this as Clause 6.1.4 not implemented, regardless of how well the security risks are documented. The fix is to extend the risk methodology with AI-specific risk types as a structural part of the schema and to build the AI System Impact Assessment as a separate documented artifact, repeatable per AI system in scope.
How the Annex A controls overlap and diverge
ISO 27001:2022 Annex A has 93 controls organized into four themes: organizational, people, physical, and technological. ISO 42001:2023 Annex A has 38 controls organized into nine areas: AI policies (A.2), internal organization (A.3), resources for AI systems (A.4), assessing impacts of AI systems (A.5), AI system lifecycle (A.6), data for AI systems (A.7), information for interested parties of AI systems (A.8), use of AI systems (A.9), and third-party and customer relationships (A.10).
The overlap with ISO 27001 is real but partial. ISO 42001 A.2.2 requires an AI policy. ISO 27001 A.5.1 requires an information security policy. These can be merged into a single integrated policy document with distinct sections, but they cannot be a single shared policy that pretends to cover both. ISO 42001 A.10.2 covers third-party and customer relationships for AI. ISO 27001 A.5.19 covers supplier relationships. The AI version adds AI-specific due diligence: model provenance, training data origin, performance claims, intellectual property in AI outputs, and AI-specific contractual terms. The integrated approach extends the existing supplier procedure with AI-specific assessment criteria, applied when the supplier relationship involves AI.
The genuinely new controls have no ISO 27001 analog. AI System Impact Assessment under A.5 is the operational implementation of Clause 6.1.4 and requires evidence of impact analysis per AI system, not per asset. AI system lifecycle controls under A.6 cover objectives, design and development, verification and validation, deployment, operation and monitoring, technical documentation, event logging, and decommissioning of AI systems. The evidence type is different from anything in ISO 27001: model cards, evaluation reports, deployment runbooks, monitoring dashboards, decommissioning procedures. Data controls under A.7 cover data acquisition, data quality, data provenance, and data preparation specific to AI training and inference, which extends but does not duplicate ISO 27001 A.8.10 (information deletion) and A.8.11 (data masking).
The Statement of Applicability in an integrated system lists both control catalogs in one consolidated table, with applicability and justification recorded for each. Notified bodies and certification auditors examining dual scope expect this consolidated artifact, not two separate SoAs that may contradict each other. A control that is applicable in one system but not the other should be marked accordingly with explicit justification.
Where teams get this wrong
Four patterns recur in the engagements where the integration has been attempted poorly.
The first is treating ISO 42001 as a parallel ISMS. Two policies, two risk assessments, two SoAs, two audit programs. This produces the predictable certification audit finding that procedures are inconsistent across the two systems. Auditors reading dual scope look for integration. They punish duplication.
The second is applying ISO 27001 risk thinking to AI risks. The risk register lists confidentiality, integrity, and availability against AI assets and stops there. Bias, fairness, transparency, and societal impact never appear. ISO 42001 Clause 6.1.4 is not implemented. The auditor records a major nonconformity on Clause 6.1.
The third is copying the ISO 27001 SoA structure for ISO 42001 controls without adapting to the AI-specific control statements. ISO 42001 A.5 (AI System Impact Assessment) is not a security control and cannot be evidenced with a vulnerability scan log or a penetration test report. Each ISO 42001 control needs its own evidence type appropriate to AI system management. Where the SoA says "applicable" but the evidence repository points to security artifacts, the gap is visible at audit.
The fourth is failing to negotiate the combined audit window with the certification body in advance. Many B2B SaaS companies hold ISO 27001 certification with a body that has not yet been accredited for ISO 42001. They learn this six weeks before the planned dual audit, when the cert body confirms it cannot offer ISO 42001 audits. The result is a delayed certification timeline or a fragmented audit calendar with one body for each standard, which loses the integration savings entirely.
How to do it right
1.) Decide the integration model on day one. Structural extension of the existing ISMS, not a parallel system. Document the decision with rationale and circulate to both the security team and whoever owns AI governance.
2.) Map ISO 42001 Clauses 4 through 10 onto the existing ISO 27001 ISMS Clauses 4 through 10. Most procedural documentation extends in place with single-sentence scope additions. Track each clause in a mapping table that becomes part of the integrated management system manual.
3.) Extend the existing risk methodology with AI-specific risk types as a schema field, not a separate process. The risk register becomes wider, not duplicated. Adopt ISO 42001 Annex B and the AI risk management process as the methodology baseline for AI risks.
4.) Build the AI System Impact Assessment as a separate documented artifact, repeatable per AI system in scope. Use Clause 6.1.4 and Annex A.5 as the requirement floor. Treat each AI system as an instance, with documented impacts, foreseeable misuse, and stakeholder considerations.
5.) Consolidate the Statement of Applicability. One document, two control catalogs, applicability and justification per control, signed by the same approving authority that signs the existing ISMS SoA.
6.) Train the internal audit team on ISO 42001 before the integrated audit cycle runs. A single auditor needs demonstrable competence on both standards, or the audit findings are not defensible. Document training records against Clause 7.2 (competence), which applies to both standards.
7.) Open the certification body conversation early. Confirm they audit ISO 42001, confirm they accept a combined audit window, and confirm the auditor team has both competencies. Build this into the project timeline, not at the end.
FAQ
Can I get ISO 42001 certified without ISO 27001?
Yes. ISO 42001 is a standalone management system standard and can be certified independently. In practice it is rare. Most organizations pursuing ISO 42001 either already hold ISO 27001 or pursue both simultaneously, because most ISO 42001 controls assume an underlying information security management system that ISO 27001 provides. A standalone ISO 42001 certification often ends up rebuilding ISO 27001 controls under a different label.
How long does ISO 42001 implementation take if we already have ISO 27001?
For an organization with a mature ISO 27001 ISMS, expect four to six months of additional work to reach ISO 42001 readiness, plus the certification audit timeline. Procedural extensions take four to eight weeks. New artifacts (AI policy, AI risk register schema extension, AI System Impact Assessment process, AI lifecycle controls) take two to four months. Internal audit and management review cycles add another month before the cert audit can run.
Does ISO 42001 satisfy the EU AI Act?
ISO 42001 supports EU AI Act compliance but does not satisfy it on its own. The EU AI Act requires conformity assessment for high-risk systems under Article 43, which is a regulatory process distinct from ISO 42001 certification. ISO 42001 evidence can support a conformity assessment and most internal documentation overlaps, but a certification body audit is not a conformity assessment. Treat ISO 42001 as a strong baseline that demonstrably reduces the gap to AI Act readiness, not as a substitute for it.
What auditors are qualified to audit ISO 42001?
A growing number of certification bodies have accredited ISO 42001 schemes, but accreditation status varies by national accreditation body and by cert body. Confirm with your existing ISO 27001 certification body whether they offer ISO 42001 audits, whether their auditors carry both competencies, and whether they can run a combined audit window. If your current cert body is not yet accredited, decide early whether to wait or to switch.
Do we need separate management review meetings for each standard?
No. An integrated management system runs one management review meeting that covers both standards. The agenda template extends to include both ISMS-specific items (information security objectives, security incidents, security audit findings) and AIMS-specific items (AI management objectives, AI system performance, AI risks, AI System Impact Assessment outcomes). Minutes record both. This is one of the larger time savings of the integrated approach.
What is the difference between ISO 42001 and the EU AI Act conformity assessment?
ISO 42001 is a voluntary management system certification. The EU AI Act conformity assessment is a regulatory compliance process required for high-risk AI systems under Articles 16, 43, and Annex VI. The two address overlapping concerns from different angles. ISO 42001 evidence can populate parts of the conformity assessment file, but the conformity assessment requires specific deliverables (technical documentation under Annex IV, declaration of conformity, CE marking for in-scope products) that ISO 42001 certification does not produce.
Where to go from here
If you are scoping ISO 42001 readiness alongside an existing ISO 27001 ISMS and the certification timeline is being driven by an enterprise sales requirement or an investor commitment, the integration decisions in the first two weeks shape the next six months. The structural choices look low-stakes early and become expensive to undo once evidence starts accumulating. If you want a sober view of what your integration plan should look like before you commit budget or appoint an owner, book a scoping call with our experts. Security Consultants OÜ has worked with B2B SaaS organizations through this exact decision and there are a handful of structural calls worth getting right at the start. Also, for similar deep dives follow us on LinkedIn.
