ISO 42001 AI Governance, SOC 2, and NIST: Standards MSPs Must Deliver

If your clients are deploying AI systems, they are almost certainly operating under at least one of three frameworks: ISO 42001, SOC 2, or the NIST AI Risk Management Framework. ISO 42001 AI governance is the most comprehensive of the three — a certifiable management system standard purpose-built for AI. The problem most MSPs run into is not understanding what these standards require in isolation — it is figuring out how to deliver them together without rebuilding the compliance stack from scratch for every client. This post maps the specific AI governance obligations each framework creates, shows where controls overlap, and gives you a practical structure for turning multi-standard compliance into a packaged, repeatable service.

What ISO 42001, SOC 2, and NIST Actually Require for AI Governance

These three AI governance compliance standards operate at different levels of specificity, and conflating them creates real delivery problems.

• ISO 42001 is the first international standard purpose-built for AI management systems. Published by ISO/IEC in late 2023, it follows the familiar Annex SL high-level structure used by ISO 27001 and ISO 9001, which means organizations already certified under those standards have a structural head start. The core requirement is an AI Management System (AIMS) — a documented, auditable system that governs how AI is developed, deployed, and monitored across the organization. ISO 42001 requires organizations to define their AI policy, establish roles and responsibilities, conduct AI-specific risk assessments, and implement controls drawn from ISO/IEC 42001:2023 Annex A (38 controls organized under 9 control objectives covering areas like data governance, transparency, and human oversight). Certification is third-party audited.
• SOC 2 is not an AI-specific standard. It is an attestation framework built around the AICPA Trust Services Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. However, as AI systems become part of client infrastructure, SOC 2 auditors are increasingly scrutinizing AI-related controls under existing criteria — particularly Processing Integrity and Confidentiality. SOC 2 AI governance controls are not codified in a separate annex; they are evaluated against the same TSC criteria applied to any in-scope system. If an AI model is processing client data, it is in scope for SOC 2, and the MSP needs to demonstrate controls over model inputs, outputs, and access.
• NIST AI RMF (AI Risk Management Framework, released January 2023) is a voluntary framework organized around four functions: Govern, Map, Measure, and Manage. The NIST AI governance framework is not a certification standard — there is no audit or attestation. Its value is structural: it gives organizations a common language and process for identifying, assessing, and treating AI risks. For MSPs, NIST is most useful as the underlying risk methodology that feeds into ISO 42001 and SOC 2 control design.

ISO 42001 is the management system standard with certification. SOC 2 is the attestation that AI systems meet trust criteria. NIST is the risk framework that informs both.

How ISO 42001 and SOC 2 AI Controls Overlap (and Where They Diverge)

Understanding the overlap is where MSPs recover significant delivery efficiency. Building separate control sets for each framework is unnecessary work.

• Where they converge:
• Access control and authorization. ISO 42001 Annex A.6 and SOC 2 CC6 both require documented controls over who can interact with AI systems. A single access control policy tied to identity management tooling satisfies both.
• Incident response. ISO 42001 requires procedures for responding to AI system failures. SOC 2 CC7 requires incident detection and response. The same incident response runbook, scoped to include AI-specific failure modes, covers both.
• Vendor and third-party risk. ISO 42001 Annex A.10 addresses supply chain and third-party AI providers. SOC 2 CC9 covers vendor risk management. A unified third-party AI vendor assessment process satisfies both frameworks simultaneously.
• Monitoring and logging. Both frameworks require evidence that AI systems are being monitored for performance, anomalies, and policy compliance. A continuous monitoring program with structured logging feeds both the ISO 42001 operational control requirements and SOC 2’s CC7 and PI criteria.
• Where they diverge:

ISO 42001 requires an explicit AI policy statement, defined AI objectives, and a formal management review process — governance artifacts that SOC 2 does not specifically mandate. SOC 2 requires a formal opinion from a licensed CPA firm and produces an attestation report clients can share with their own auditors. ISO 42001 produces a certificate. These are different outputs serving different stakeholder needs. NIST diverges from both in that it produces no external-facing artifact. The Govern and Map functions help organizations define AI risk appetite and identify which AI systems require what level of control — which then informs which ISO 42001 controls to prioritize and which SOC 2 criteria are most relevant for a given AI deployment. For MSPs managing multi-framework engagements, the practical approach is to build a unified control library mapped to all three frameworks, then generate framework-specific evidence packages from the same underlying controls. See AI Governance for Managed Service Providers: The Complete Framework Guide for a broader treatment of how these frameworks fit into an MSP’s overall governance delivery model.

AI Governance Audit Requirements: What Each Standard Demands MSPs Document

Audit readiness is where abstract framework requirements become concrete deliverables. Here is what each standard actually requires MSPs to produce.

• ISO 42001 audit evidence:
• AI policy document — a formal, board-approved statement of the organization’s AI governance objectives, scope, and principles.
• AI risk assessment records — documented identification and evaluation of risks associated with each AI system in scope, including likelihood, impact, and treatment decisions.
• Annex A control implementation statements — for each applicable control, a record of how it is implemented and evidence of its operation.
• Competence records — evidence that personnel responsible for AI systems have the required training and qualifications.
• Internal audit reports — periodic internal audits of the AIMS, with documented findings and corrective actions.
• Management review minutes — formal records of leadership review of AI governance performance.
• Corrective action records — documented nonconformities and the actions taken to address them.
• SOC 2 AI governance audit evidence:

SOC 2 auditors will request evidence mapped to the Trust Services Criteria. For AI systems, this typically includes:

• System description — a narrative description of the AI system, its inputs, processing logic, outputs, and the controls in place.
• Change management records — evidence that changes to AI models or pipelines go through a formal change control process (CC8).
• Access logs — records demonstrating that access to AI systems is restricted to authorized personnel (CC6).
• Monitoring logs and alerting records — evidence that AI system outputs and performance are monitored and that anomalies trigger defined responses (CC7).
• Incident records — documentation of AI-related incidents, their classification, and resolution.
• Vendor contracts and assessments — evidence of due diligence on third-party AI providers (CC9).
• NIST AI RMF documentation:

Because NIST is voluntary and non-certifiable, there is no formal audit. However, when used as the risk methodology underpinning an ISO 42001 or SOC 2 engagement, the relevant documentation includes:

• AI system inventory — a catalog of all AI systems in scope, their risk tier, and their intended use.
• Risk assessment outputs — documented outputs from the Map and Measure functions, including identified harms, likelihood ratings, and control mappings.
• Governance policies — documented accountability structures, risk tolerance statements, and policies for AI system oversight.

The AI governance audit requirements across all three frameworks share a common thread: documented evidence of intentional, ongoing control. Assertions are not sufficient. Auditors want records.

Ready to assess your clients’ audit readiness? Use a structured AI governance checklist to identify documentation gaps before an auditor does. A pre-audit gap assessment is one of the highest-value deliverables an MSP can offer — and it creates a natural on-ramp to remediation work.

For a deeper look at the ongoing monitoring and reporting obligations that feed these audit requirements, see AI Governance Monitoring, Auditing, and Reporting: What MSPs Need to Deliver.

Building a Reusable AI Governance Policy Template Across ISO, SOC 2, and NIST

The fastest way to scale AI governance delivery across multiple clients is a policy template architecture that maps to all three frameworks simultaneously. The goal is a modular set of policy components that can be assembled and tailored per client.

Core policy components and their framework mappings:

Each component should include: purpose statement, scope, roles and responsibilities, procedure steps, evidence requirements, and review frequency. This structure satisfies the documentation requirements for ISO 42001 certification audits, SOC 2 Type II evidence requests, and NIST AI RMF governance documentation simultaneously. Start with the ISO 42001 AIMS structure as the backbone — it is the most comprehensive and maps cleanly to the others. Layer in SOC 2 Trust Services Criteria references as annotations within each policy section, and add NIST AI RMF function references as a secondary mapping column. The result is a single policy set that an auditor for any of the three frameworks can navigate without requiring you to maintain three separate documentation stacks. An AI governance policy template built this way also becomes a sales asset — something concrete to show prospects rather than describe abstractly. For MSPs working with clients in regulated industries, the EU AI Act adds additional obligations on top of these three frameworks. See EU AI Act Compliance for MSPs: What Managed Service Providers Need to Know for how to layer Act requirements into this policy architecture. For clients deploying large language models or generative AI specifically, the control requirements go beyond what standard ISO 42001 and SOC 2 templates cover. See LLM and Generative AI Governance: Controls, Risk Assessment, and Audit Trails for the additional controls those deployments require.

Delivering Multi-Standard AI Governance as a Managed Service

Packaging ISO 42001, SOC 2, and NIST compliance into a repeatable service offering requires solving three problems: scoping, delivery, and ongoing management.

Scoping the engagement:

Not every client needs all three frameworks. A useful scoping heuristic:

• ISO 42001 is relevant for any client that wants a certifiable AI management system — typically organizations in regulated industries, enterprise clients with procurement requirements, or clients preparing for EU AI Act compliance.
• SOC 2 AI governance controls are relevant for any client that already has a SOC 2 program and is deploying AI systems in scope — most SaaS companies and technology-forward enterprises.
• NIST AI RMF is relevant as the underlying methodology for any client that needs a structured risk assessment process. It is rarely a standalone deliverable but is almost always part of the underlying work.

A tiered service model works well here:

• Tier 1 (Foundation): AI system inventory, risk classification, and NIST-based risk assessment. Deliverable: AI risk register and governance policy set.
• Tier 2 (Compliance): ISO 42001 AIMS implementation or SOC 2 AI control integration, depending on client need. Deliverable: audit-ready documentation package.
• Tier 3 (Managed): Ongoing monitoring, quarterly management reviews, incident response support, and annual audit preparation. Deliverable: continuous compliance posture with evidence packages on demand.
• Making it repeatable:

The policy template architecture described above is the core IP that makes this scalable. Pair it with a client onboarding workflow covering: AI system discovery, risk assessment, policy customization, control implementation, and evidence collection setup. Each step should have defined outputs that feed the next. A platform that supports multi-tenant AI governance — with separate client workspaces, shared policy templates, and centralized audit evidence collection — is what separates a scalable managed service from a consulting engagement rebuilt from scratch each time. The regulatory pressure driving demand for ISO 42001 AI governance services is increasing. The EU AI Act’s conformity assessment requirements for high-risk AI systems create a direct pipeline to ISO 42001 certification work. SOC 2 AI governance controls are becoming standard audit scope as AI systems proliferate in client environments. MSPs that build this capability now — with reusable templates, documented delivery workflows, and multi-tenant tooling — are positioned to capture a compliance services category that is still early enough to establish a differentiated position.

For the full framework for building an AI governance practice as an MSP, including how these compliance standards fit into a broader service architecture, see the pillar guide: AI Governance for Managed Service Providers: The Complete Guide.

• Ready to build your AI governance service offering? Brine’s platform is built for MSPs delivering multi-standard AI governance across client environments — with multi-tenant workspaces, pre-mapped policy templates, and audit evidence collection built in. Talk to the team about MSP partner options.