Treat ISO/IEC 42001 as separate as soon as AI systems influence decisions, customer outcomes or regulated workflows. SOC 2 and ISO/IEC 27001 can show operational and security maturity, but they do not fully prove AI oversight, lifecycle control or responsible use. If AI changes behaviour over time, it needs its own governance evidence.
How ISO/IEC 42001 differs from SOC 2 and ISO/IEC 27001 in practice
ISO/IEC 42001 becomes a separate governance track when AI is not just another system in the stack, but a decision-making capability that can affect outputs, recommendations, customer treatment or regulated operations. SOC 2 and ISO/IEC 27001 can support trust, security and control discipline, but they do not by themselves show that AI has been assessed, governed and monitored as an AI system.
That distinction matters because a company can be strong on general security hygiene and still have no evidence for model purpose, human oversight, bias review, change control or decommissioning of AI use cases. NHIMG’s ISO/IEC 42001 Guide is useful here because it frames the standard as an AI management system, not a replacement for broader security certification.
When one framework can support another, and when it cannot
SOC 2 and ISO/IEC 27001 often provide the control foundation that auditors and customers expect: access control, logging, supplier management, incident handling and formal governance. But once AI influences decisions or customer outcomes, the question shifts from “is the environment controlled?” to “is the AI use case controlled as an AI use case?” That is where SOC 2 Guide and ISO 27001 Certification Guide become supporting evidence rather than complete coverage.
In practical terms, the overlap is useful but incomplete. General controls may show that the company can operate securely, but they do not automatically prove that AI outputs are reviewed, that model updates are approved, or that training and inference changes are tracked through a defined lifecycle. If the AI system can change behaviour over time, ISO/IEC 42001 should be treated as the primary governance lens for that part of the risk.
What evidence auditors and customers will still expect for AI-specific governance
When ISO/IEC 42001 is treated separately, the evidence set should go beyond generic policies and technical controls. Teams should be able to show use case registration, role ownership, impact assessment, review cadence, exception handling and a clear path for retirement or rollback when the AI system no longer meets policy or performance expectations. NHIMG’s AI Governance Guide is a good companion because it emphasises oversight structures, use case registers and decommissioning.
For companies that want a control crosswalk rather than a one-framework answer, Control Mapping Guide helps explain why some evidence can be reused across frameworks while other evidence must be AI-specific. The useful test is simple: if removing the AI system would make the control evidence look complete, then the evidence is probably too generic to stand alone for ISO/IEC 42001.
Risk and Threat Considerations
AI creates a governance gap when organisations assume that security certification also proves responsible AI use. The common failure mode is not a lack of security controls, but a lack of proof that AI decisions are understood, reviewed and constrained as the system evolves.
Failure mechanism: A company relies on SOC 2 or ISO/IEC 27001 evidence for platform security, but does not maintain AI-specific oversight for model change, output quality, human review or drift, so decision risk accumulates outside the existing control set.
Impact: Customer harm, regulatory exposure, inconsistent decisions and weak accountability can follow, especially where AI affects pricing, eligibility, content moderation, support or other regulated workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
ISO/IEC 42001:2023, SOC 2 (AICPA) and ISO/IEC 27001:2022 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 42001:2023 | A.4 — Context of the organization | AI governance depends on defining scope and context for the AI management system. |
| A.5 — Leadership | Separate AI governance needs accountable leadership and assigned responsibility. | |
| A.6 — Planning | AI use cases need planned risk treatment, objectives and lifecycle controls. | |
| Recommendation — Define the AI management system scope around impacted use cases and decision contexts. Assign leadership accountability for AI policy, oversight and exception decisions. Plan AI objectives, risk treatment and review cadence for each material use case. | ||
| SOC 2 (AICPA) | CC6.1 — Logical and Physical Access Controls | SOC 2 supports the security environment around AI platforms and data. |
| CC7.2 — Detective Controls | SOC 2 evidence often includes monitoring that supports AI operational oversight. | |
| Recommendation — Use access controls to restrict who can operate and change AI systems. Monitor AI-related events and exceptions so changes and anomalies are detected promptly. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | ISO 27001 supports the surrounding access governance, but not AI governance by itself. |
| A.5.24 — Information security incident management planning and preparation | AI systems still need incident handling for harmful outputs, misuse and failures. | |
| Recommendation — Apply access control to the systems, data and tooling that support AI operations. Prepare incident handling for AI misuse, harmful outputs and control failures. | ||
Practitioner Guidance
What to verify: Check whether each AI use case has an owner, a documented purpose, an approval path and an explicit review point for behavioural change. If the answer is “the model is covered by our SOC 2,” the governance model is not yet specific enough.
Decision rule: Use SOC 2 and ISO/IEC 27001 for the security and operating environment, but require ISO/IEC 42001 when AI output can influence a decision, a customer outcome or a regulated process. If the AI system learns, updates or is retrained regularly, treat lifecycle control as mandatory rather than optional.
Practitioner takeaway: The right test is not whether AI lives inside an audited company, but whether the AI itself is governed with evidence that matches its decision impact.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities for ISO 27001?
- Who is accountable for ISO/IEC 42001 evidence and AI access control?
- How should security teams decide whether to pursue SOC 2, ISO 27001, or both for a B2B SaaS company?
- What breaks when organisations treat SOC 2 and ISO 27001 as a paperwork exercise instead of an operating model?