The Problem
A prospective enterprise customer's security team sends over a vendor questionnaire before they'll sign: "Are you ISO 42001 certified? Can you provide your latest SOC 2 report covering your AI features?" Sales forwards it to engineering with a deadline. Nobody on the team has been through a certification audit before, and the instinct is to treat this as a brand-new project — write new policies, build new controls, hire a consultant, start from zero.
That instinct is usually wrong, and it's expensive when it's wrong. Most engineering orgs of any size already have SOC 2 Type II — auditors have already reviewed access controls, change management, and monitoring for the core product. The AI features didn't appear in a vacuum outside that program; they're new attack surface and new risk inside an org that already knows how to run a compliance program. The actual work is extending existing muscle to cover AI-specific evidence, and layering in the parts that are genuinely new — like proving an AI management system exists at all.
That's what ISO/IEC 42001 and SOC 2 are, functionally: certifiable proof, issued by an independent third party, that the governance NIST AI RMF describes and the risk classification the EU AI Act requires are actually implemented and operating. They're the audit layer sitting on top of the policy layer.
ISO/IEC 42001: certifying the management system, not the model
ISO/IEC 42001 (published in December 2023) is the first international standard for an AI management system (AIMS) — modeled on the same family of ISO management-system standards as ISO 27001 (information security) and ISO 9001 (quality). If your org has been through an ISO 27001 audit before, the shape will look familiar: clauses 4 through 10 cover context of the organization, leadership, planning, support, operation, performance evaluation, and continual improvement, plus an Annex A of AI-specific controls an org selects from and justifies via a Statement of Applicability.
The critical thing to internalize: certification applies to the organization's management system, not to any individual model. An accredited certification body audits whether the org has documented policies, assigned roles, a risk assessment process, and evidence that the process actually runs — not whether a specific model is bias-free or safe in every context. A company can hold a valid ISO 42001 certificate while one of its models has an active fairness bug, because certification means "we have a functioning system for identifying and addressing exactly that kind of problem," not "every problem has already been eliminated."
The Annex A control areas that matter most to an engineering org:
| Control area | What it requires |
|---|
| AI Policy & Governance | Leadership-approved policy defining risk tolerance, roles, acceptable use |
| AI System Impact Assessment | A completed assessment of affected stakeholders and potential harms before deployment |
| Data Management for AI | Training/RAG data classified, quality-checked, provenance-tracked |
| AI System Lifecycle Controls | Change management across design, development, deployment, monitoring, retirement |
| Third-Party & Customer Relationships | Vendor and third-party AI component risk assessed before use |
| Use and Monitoring of AI Systems | Deployed systems monitored, issues fed back into the management system |
| Resourcing and Competence | Defined competence requirements and training for AI-risk personnel |
| Transparency to Interested Parties | Capabilities and limitations communicated to users, auditors, and other stakeholders |
Certification itself follows the standard ISO pattern: a Stage 1 audit (documentation review — does the management system exist on paper), a Stage 2 audit (does it actually operate — interviews, evidence sampling), then a certificate valid for three years with annual surveillance audits.
How this differs from NIST AI RMF and the EU AI act
These three artifacts get confused constantly because their content overlaps heavily, but they sit in genuinely different categories:
- NIST AI RMF is voluntary guidance. There's no certifying body, no audit, no certificate — it's a shared vocabulary and a functional structure (Govern, Map, Measure, Manage) that an org can adopt however it likes, and NIST has published a crosswalk showing how RMF functions map onto ISO 42001 clauses.
- EU AI Act is binding law. Obligations attach by risk tier, apply whether or not you asked for them, and carry real penalties (up to €35 million or 7% of global turnover for the most serious violations).
- ISO/IEC 42001 is a certifiable management-system standard. Nobody is legally required to get certified — but a customer, a regulator building a conformity-assessment framework, or an insurer can require it as proof of a functioning governance program, and it comes with an actual certificate an accredited body puts its name behind.
In practice, an EU AI Act high-risk conformity assessment and an ISO 42001 audit will often ask for a lot of the same underlying evidence — but only one of them is optional.
Adapting SOC 2 controls for AI
SOC 2 is older and more familiar territory for most engineering orgs: an AICPA-defined framework, audited controls mapped to Trust Services Criteria, typically scoped to the Common Criteria (the security-related criteria every SOC 2 report includes) plus whichever of Availability, Confidentiality, Processing Integrity, or Privacy the org chooses to add. There is no AI-specific Trust Services Category — and there doesn't need to be. The Common Criteria are written generally enough that they extend to AI systems directly, once you know what AI-specific evidence satisfies them:
- Logical access controls (CC5–6): IAM restrictions on who can read or modify model weights, embeddings, and training data — not just database credentials
- Change management (CC8): PR review, staged rollout, and rollback plans for model and prompt deployments — the same discipline as any other production change, applied to a model version bump
- System operations / monitoring (CC7, CC4): inference logging sufficient to reconstruct what a model saw and returned, plus drift and anomaly monitoring that catches when a model's behavior has silently shifted
- Risk assessment (CC3): explicit AI-related risks — including fairness and bias — folded into the org's existing risk register, not tracked separately
- Risk mitigation / vendor risk (CC9): security review of foundation model providers and data-labeling vendors, the same way any subprocessor gets reviewed
The efficient move — and the one an experienced AI Governance & Compliance Engineer is hired to make — is treating this as extending one program, not building two. A single well-documented control, like "changes to models and prompts go through PR review and staged rollout," produces one set of evidence (CI config, approval records, a rollback plan) that gets submitted to a SOC 2 auditor as change-management evidence and to an ISO 42001 auditor as lifecycle-control evidence. That's the actual leverage: build the control once, document it once, reuse the evidence twice.
Dual-purpose controls are the whole game
Every hour spent finding a control that satisfies two frameworks at once is worth roughly two hours of separately-scoped audit prep. Before writing any new control, check whether an existing one — access control, change management, monitoring, vendor review — can be extended with AI-specific evidence rather than duplicated. The build-plan skill here isn't writing new policy; it's cross-referencing what already exists.
A team is preparing for both an ISO 42001 certification audit and a SOC 2 Type II examination in the same quarter. Which approach reflects the most efficient use of engineering time?
ISO 42001 and SOC 2 aren't sequential or mutually exclusive — the efficient path is identifying dual-purpose controls up front, so a single piece of evidence (like a change-management CI pipeline) gets submitted to both auditors instead of being built or documented twice. SOC 2's Common Criteria don't need an AI-specific category to apply to AI systems; they just need AI-specific evidence attached to existing criteria like access control and change management.
Where the gaps actually show up
The pattern that catches engineering-heavy orgs off guard: SOC 2's Common Criteria are weighted toward technical and operational controls — access, change management, monitoring — which engineering teams build naturally as a byproduct of running a production system well. ISO 42001's Transparency to Interested Parties control is different in kind: it requires actively communicating what an AI system does and doesn't do, to users, auditors, and other stakeholders, in the form of things like model cards or system cards. Nothing about shipping a well-engineered feature produces that documentation as a side effect — it has to be built as its own deliverable, and it's the control most commonly missing from an otherwise strong coverage matrix.
Finding that gap is exactly what a control-mapping tool is for: cross-reference every control an org has actually implemented against both frameworks' checklists, and see what's left uncovered.
Build
Build it
The code artifact lesson_07_03_iso42001_soc2.py builds a control-mapping tool: it defines the ISO/IEC 42001 Annex A control areas and the SOC 2 Common Criteria as structured checklists, cross-references a set of controls an org has actually implemented against both, and renders a coverage matrix showing which requirements are satisfied, which implemented controls double as evidence for both standards, and which requirements have no coverage at all — including a deliberately unmapped control that exposes a real transparency gap.
"""
lesson_07_03_iso42001_soc2.py
An ISO/IEC 42001 + SOC 2 control-mapping tool.
Cross-references a set of controls an engineering org has actually
implemented against two certifiable-standard checklists: ISO/IEC 42001
(the AI management system standard) and SOC 2's Common Criteria (the
trust-services controls most companies already have from a prior SOC 2
audit, adapted here for AI-specific evidence). The output is a coverage
matrix showing which framework requirements are satisfied, which
implemented controls double as evidence for both standards, and which
requirements have no coverage at all.
Reference: ISO/IEC 42001 (https://www.iso.org/standard/81230.html).
SOC 2 Trust Services Criteria are defined by the AICPA; this tool models
the "Common Criteria" (the security-related criteria every SOC 2 report
includes) rather than the optional Availability/Confidentiality/
Processing Integrity/Privacy categories, which are scoped in separately
per engagement.
Usage:
python lesson_07_03_iso42001_soc2.py
No external dependencies, no network calls, no API keys required.
"""
from __future__ import annotations
from dataclasses import dataclass, field
@dataclass(frozen=True)
class FrameworkControl:
framework: str # "ISO42001" | "SOC2"
control_id: str
category: str
description: str
# ── ISO/IEC 42001 — AI Management System (AIMS) control areas ────────────────
# ISO 42001 is structured like other ISO management-system standards
# (clauses 4-10: context, leadership, planning, support, operation,
# performance evaluation, improvement) plus an Annex A of AI-specific
# controls. These are the Annex A control *areas* relevant to an
# engineering org, described by theme rather than exact clause numbering
# (which an actual certification audit would cite precisely).
ISO_42001_CONTROLS = [
FrameworkControl("ISO42001", "ISO-GOV", "AI Policy & Governance",
"A documented, leadership-approved AI policy defining risk tolerance, roles, and acceptable use."),
FrameworkControl("ISO42001", "ISO-IMPACT", "AI System Impact Assessment",
"A completed impact assessment identifying affected stakeholders and potential harms before deployment."),
FrameworkControl("ISO42001", "ISO-DATA", "Data Management for AI",
"Data used to train, fine-tune, or retrieve for AI systems is classified, quality-checked, and provenance-tracked."),
FrameworkControl("ISO42001", "ISO-LIFECYCLE", "AI System Lifecycle Controls",
"Change management across the AI system lifecycle: design, development, deployment, monitoring, retirement."),
FrameworkControl("ISO42001", "ISO-THIRDPARTY", "Third-Party & Customer Relationships",
"Third-party AI component and vendor risk is assessed and documented before use."),
FrameworkControl("ISO42001", "ISO-MONITORING", "Use and Monitoring of AI Systems",
"Deployed AI systems are monitored for performance, and issues are fed back into the management system."),
FrameworkControl("ISO42001", "ISO-COMPETENCE", "Resourcing and Competence",
"Personnel responsible for AI risk management have defined competence requirements and receive training."),
FrameworkControl("ISO42001", "ISO-TRANSPARENCY", "Transparency to Interested Parties",
"Information about the AI system's capabilities and limitations is communicated to interested parties."),
]
# ── SOC 2 — Common Criteria (the security-related criteria in every SOC 2
# report, per the AICPA Trust Services Criteria), read with AI-specific
# evidence in mind.
SOC2_CONTROLS = [
FrameworkControl("SOC2", "SOC2-CC1", "Control Environment",
"Organizational structure, ethical values, and governance oversight of AI systems."),
FrameworkControl("SOC2", "SOC2-CC2", "Communication and Information",
"Personnel understand their AI-risk responsibilities through training and internal communication."),
FrameworkControl("SOC2", "SOC2-CC3", "Risk Assessment",
"The organization identifies and assesses risk from AI systems, including fairness/bias risk."),
FrameworkControl("SOC2", "SOC2-CC4", "Monitoring Activities",
"Ongoing evaluations verify that AI-related controls are present and functioning as designed."),
FrameworkControl("SOC2", "SOC2-CC5-6", "Logical & Physical Access Controls",
"Access to model weights, training data, and inference infrastructure is restricted and reviewed."),
FrameworkControl("SOC2", "SOC2-CC7", "System Operations",
"Production AI systems are monitored, with logging sufficient to detect and investigate anomalies."),
FrameworkControl("SOC2", "SOC2-CC8", "Change Management",
"Changes to models, prompts, and AI system configuration follow a controlled change-management process."),
FrameworkControl("SOC2", "SOC2-CC9", "Risk Mitigation",
"Vendor and third-party risk, including AI subprocessors, is assessed and mitigated."),
]
ALL_FRAMEWORK_CONTROLS = ISO_42001_CONTROLS + SOC2_CONTROLS
@dataclass
class ImplementedControl:
control_id: str
description: str
evidence: str
satisfies: list[str] = field(default_factory=list) # framework control_ids
# ── What the org has actually built ──────────────────────────────────────────
# Explicit cross-references, the way a real audit's control-mapping
# spreadsheet works — not fuzzy keyword matching. Each implemented control
# lists exactly which framework requirements it's being submitted as
# evidence for.
IMPLEMENTED_CONTROLS = [
ImplementedControl(
"ai-policy-doc",
"Board-approved AI policy defining acceptable use, risk tolerance, and roles",
evidence="RISK_POLICY.md, signed off by CTO and General Counsel, reviewed annually",
satisfies=["ISO-GOV", "SOC2-CC1"],
),
ImplementedControl(
"ai-impact-assessment",
"Impact assessment completed pre-launch for consequential AI features",
evidence="impact_assessment_2026Q1.pdf covering the support copilot launch",
satisfies=["ISO-IMPACT", "SOC2-CC3"],
),
ImplementedControl(
"data-classification",
"Training and RAG corpus data classified by sensitivity with handling rules per class",
evidence="data_classification_policy.md + automated tagging in the data pipeline",
satisfies=["ISO-DATA"],
),
ImplementedControl(
"change-management-deploys",
"All model/prompt deployments go through PR review, staged rollout, and a rollback plan",
evidence="CI pipeline config requiring 2 approvals + canary deploy stage",
satisfies=["ISO-LIFECYCLE", "SOC2-CC8"],
),
ImplementedControl(
"vendor-risk-mgmt",
"Third-party AI vendors undergo a security review before onboarding",
evidence="vendor_risk_register.xlsx with review dates for each foundation model / labeling vendor",
satisfies=["ISO-THIRDPARTY", "SOC2-CC9"],
),
ImplementedControl(
"monitoring-anomaly-detection",
"Production model behavior monitored for drift and anomalies with alerting",
evidence="Langfuse dashboards + PagerDuty alert policy for eval-score regressions",
satisfies=["ISO-MONITORING", "SOC2-CC7", "SOC2-CC4"],
),
ImplementedControl(
"employee-training",
"AI-specific risk training required for engineers building or operating AI systems",
evidence="Onboarding LMS completion records, gated before prod deploy access",
satisfies=["ISO-COMPETENCE", "SOC2-CC2"],
),
ImplementedControl(
"access-control-model-weights",
"Access to production model weights and embeddings restricted via IAM roles, reviewed quarterly",
evidence="IAM policy export + quarterly access review sign-off",
satisfies=["SOC2-CC5-6"],
),
ImplementedControl(
"audit-logging-inference",
"All inference requests logged with model version, prompt hash, and output, retained 90 days",
evidence="Structured logging pipeline + retention policy config",
satisfies=["SOC2-CC7"],
),
ImplementedControl(
"encryption-at-rest-transit",
"Model weights and training data encrypted at rest and in transit",
evidence="KMS-backed encryption config + TLS termination audit",
satisfies=["SOC2-CC5-6"],
),
ImplementedControl(
"bias-fairness-testing",
"Fairness metrics computed on every retrain (see Lesson 4)",
evidence="fairness_audit_report.md generated per model version",
satisfies=["SOC2-CC3"],
),
ImplementedControl(
"incident-response-plan",
"Documented AI incident response plan (see Lesson 5)",
evidence="INCIDENT_RESPONSE.md with severities and reporting triggers",
satisfies=[], # Deliberately unmapped — see the gap this exposes below.
),
]
@dataclass
class CoverageResult:
control: FrameworkControl
covered: bool
evidence: list[ImplementedControl]
def cross_reference() -> list[CoverageResult]:
results = []
for control in ALL_FRAMEWORK_CONTROLS:
matches = [ic for ic in IMPLEMENTED_CONTROLS if control.control_id in ic.satisfies]
results.append(CoverageResult(control, covered=len(matches) > 0, evidence=matches))
return results
def render_coverage_report(results: list[CoverageResult]) -> str:
lines = ["# ISO/IEC 42001 + SOC 2 Control Coverage Matrix", ""]
for framework, label in [("ISO42001", "ISO/IEC 42001"), ("SOC2", "SOC 2 Common Criteria")]:
subset = [r for r in results if r.control.framework == framework]
covered_count = sum(1 for r in subset if r.covered)
lines.append(f"## {label} — {covered_count}/{len(subset)} covered")
lines.append("")
lines.append("| Control | Category | Status | Evidence |")
lines.append("|---|---|---|---|")
for r in subset:
status = "Covered" if r.covered else "GAP"
evidence = ", ".join(ic.control_id for ic in r.evidence) if r.evidence else "—"
lines.append(f"| {r.control.control_id} | {r.control.category} | {status} | {evidence} |")
lines.append("")
# Dual-purpose evidence: implemented controls satisfying both frameworks
# at once are exactly the leverage a governance engineer should look for
# — one control, two frameworks satisfied, one piece of audit evidence.
dual_purpose = [
ic for ic in IMPLEMENTED_CONTROLS
if any(s.startswith("ISO") for s in ic.satisfies) and any(s.startswith("SOC2") for s in ic.satisfies)
]
lines.append("## Dual-purpose controls (satisfy both frameworks)")
lines.append("")
for ic in dual_purpose:
lines.append(f"- **{ic.control_id}** — {ic.description} -> {', '.join(ic.satisfies)}")
gaps = [r for r in results if not r.covered]
lines.append("")
lines.append("## Open gaps")
lines.append("")
if not gaps:
lines.append("No open gaps.")
else:
for r in gaps:
lines.append(f"- **[{r.control.framework}/{r.control.control_id}]** {r.control.description}")
return "\n".join(lines)
if __name__ == "__main__":
results = cross_reference()
print(render_coverage_report(results))
print()
print(
"Takeaway: six implemented controls each satisfy one requirement "
"in both frameworks simultaneously — that's the actual ROI of doing "
"ISO 42001 and SOC 2 together instead of sequentially. The one open "
"gap (ISO-TRANSPARENCY) shows a real failure mode: strong technical "
"controls with no corresponding communication to users/auditors "
"about what the AI system does and doesn't do."
)
Running the control-mapping tool shows every SOC 2 Common Criteria item covered, but ISO-TRANSPARENCY has no implemented control mapped to it. What does that gap most likely mean, and what closes it?
This is a realistic and common pattern, not a tooling bug: SOC 2's Common Criteria are weighted toward technical/operational controls that engineering teams build as a natural byproduct of running production systems, while ISO 42001's transparency control requires an explicit, separate deliverable — communicating what the system does and doesn't do to users, auditors, and other interested parties. The fix is a documentation and disclosure control, not a shutdown, and the absence of a SOC 2 equivalent doesn't make the ISO gap unimportant — it just means SOC 2 alone would never have caught it.