ISO/IEC 27001, SOC 2 and ISO/IEC 42001 are different trust layers

At a glance

What this is: This is a comparison of three assurance standards for AI companies, with the key finding that SOC 2, ISO/IEC 27001 and ISO/IEC 42001 address different trust layers rather than substituting for one another.

Why it matters: It matters because IAM, security and governance teams increasingly need to show not only access and security control maturity, but also evidence for AI oversight, risk management and operating discipline.

Context

AI assurance is no longer judged on security controls alone. Buyers and regulators now look for evidence that the organisation can govern data, security, and AI behaviour across development and operations.

ISO/IEC 27001 and SOC 2 have become familiar trust artefacts, but they do not automatically answer questions about AI lifecycle control, model misuse, or oversight. That is why AI governance has become a separate assurance problem, not just an extension of information security.

Key questions

Q: When should an AI company treat ISO/IEC 42001 as separate from SOC 2 and ISO/IEC 27001?

A: 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.

Q: Why do SOC 2 and ISO/IEC 27001 not fully cover AI governance?

A: Because they were designed to evidence security, reliability and control maturity, not the specific risks created by AI systems. AI introduces concerns such as model drift, fairness, explainability, misuse and human oversight, which require lifecycle controls and monitoring evidence. Security certification helps, but it does not close the AI governance gap.

Q: How should teams prove responsible AI maturity to enterprise buyers?

A: Use a distinct evidence set for AI governance that includes policies, model inventories, approval records, monitoring results and incident handling. Buyers usually want to know how AI is designed, supervised, changed and retired, not only whether the company has general security controls. Evidence should show governance in operation, not just intent.

Q: What is the difference between AI model security and AI governance?

A: Model security focuses on protecting the model itself from attack or misuse. AI governance is broader and asks who can use the system, what it can access, how policy is applied, and what evidence exists after the interaction. In regulated environments, governance must include runtime enforcement and auditability, not just technical hardening.

Technical breakdown

How the three standards split security, operations and AI governance

SOC 2 is an attestation framework focused on trust services criteria, while ISO/IEC 27001 is a management system standard for information security governance. ISO/IEC 42001 extends the pattern into AI by requiring an artificial intelligence management system that addresses AI risk across design, deployment and monitoring. The practical distinction is that the first two are primarily about protecting information and proving operational reliability, whereas the third is about proving that AI is governed as a distinct risk domain. See the ISO/IEC 42001 Guide. See the ISO/IEC 42001 Guide.

Practical implication: Treat AI assurance as a separate governance stream, not as a side effect of existing security certification.

Why AI lifecycle control sits outside traditional security certification

Traditional security certifications are strong on policy, control evidence and auditability, but they do not fully cover AI-specific failure modes such as bias, drift, unsafe use cases, explainability gaps and human oversight breakdowns. Those issues emerge after model development and continue through deployment, monitoring and retraining. In practice, AI governance has to track how the system changes over time, not just whether a control existed at audit time. That is the structural reason ISO/IEC 42001 exists. See the AI Risk Assessment Guide. See the AI Risk Assessment Guide.

Practical implication: Map model development, monitoring and retraining into an AI-specific control lifecycle instead of reusing only security audit evidence.

Why access control evidence is not enough for AI trust claims

Identity and access controls still matter because AI systems depend on users, services, data pipelines and privileged operational access. But proving that access is controlled does not prove that the AI system is safe, explainable or suitable for a regulated use case. In other words, access governance is necessary but not sufficient. For AI companies, the assurance gap appears when buyer questions move from who can access the system to how the system behaves, learns and is supervised. See the Data Security Guide. See the Data Security Guide.

Practical implication: Use IAM and data control evidence as one input to AI assurance, not as the full trust argument.

NHI Mgmt Group analysis

AI companies are being asked to prove governance, not just security. SOC 2 and ISO/IEC 27001 remain useful, but they do not by themselves answer whether AI decisions are explainable, monitored or bounded by policy. That changes the assurance problem from information security maturity to multi-layer trust governance. Practitioners should treat AI governance as a distinct control plane, not an audit footnote.

ISO/IEC 42001 fills the assurance gap that security frameworks leave open. The standard exists because AI systems create lifecycle risks that classic security programmes were never designed to evidence, including drift, misuse and human oversight failure. That is especially important when AI influences hiring, finance, healthcare or enterprise workflow decisions. Practitioners should expect buyers to ask for AI-specific operating evidence, not just security certificates.

AI governance debt: organisations that postpone formal AI management controls accumulate a proof problem as quickly as a risk problem. The longer AI systems operate without lifecycle governance, the harder it becomes to reconstruct oversight, justify use cases, and answer regulator or customer questions with evidence. Practitioners should build AI governance while deployment is still small enough to govern.

What this signals

AI governance will increasingly be judged as a programme discipline, not a document set. As buyers ask how models are approved, monitored and retired, evidence quality will matter more than certificate count. Teams that can show lifecycle control will have a stronger trust position than teams relying on general security claims alone.

Identity and access evidence still matters, but it now sits inside a broader AI assurance stack. The practical shift is from asking who can reach the system to asking how the system is governed after access is granted. That is where security, data handling and AI oversight must converge.

Governance teams should expect certification conversations to split by risk layer. Security assurance, operational assurance and AI assurance are no longer interchangeable, and each will be assessed by different questions from buyers, auditors and regulators.

For practitioners

• Define separate assurance scopes for security and AI governance Map SOC 2 to operational trust, ISO/IEC 27001 to security management, and ISO/IEC 42001 to AI lifecycle control so the same evidence is not stretched across unrelated claims.
• Inventory where AI affects people or regulated decisions Document every system that influences hiring, finance, healthcare, customer support or enterprise workflows, then assign an owner for model oversight and change approval.
• Collect evidence for oversight, not only access Retain policies, review records, monitoring outputs and incident response records that show how AI systems are supervised after deployment, not just who can log in.
• Align assurance artefacts to buyer expectations Prepare different evidence packs for US enterprise buyers, global enterprise buyers and regulated buyers so security governance and AI governance are addressed separately.

Key takeaways

• SOC 2, ISO/IEC 27001 and ISO/IEC 42001 address different assurance layers, so one standard cannot stand in for the others.
• For AI companies, the main gap is not access control alone but lifecycle evidence for oversight, monitoring and change management.
• Practitioners should separate security evidence from AI governance evidence before buyers, auditors or regulators ask for both.

Related NHI Mgmt Group resources: ISO/IEC 42001 Guide · AI Risk Assessment Guide · Data Security Guide · Agentic AI Compliance Guide

Key terms

• Artificial Intelligence Management System: An Artificial Intelligence Management System is the operating structure an organisation uses to govern AI across scope, policy, monitoring, and improvement. In ISO 42001 terms, it is the certifiable system of records, controls, and reviews that proves AI risk is being managed continuously, not only documented.
• Trust Service Criteria: The five SOC 2 control categories used to evaluate a service organisation's security posture: security, availability, processing integrity, confidentiality, and privacy. They translate broad assurance goals into a testable control framework that auditors can assess against real evidence.
• Information Security Management System: An information security management system is the operating structure an organisation uses to manage security policies, controls, responsibilities, and evidence. Under ISO 27001, it is the framework auditors assess, but its real strength depends on whether access, logging, and remediation work consistently in practice.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.