SOC 2, ISO 27001 and the EU AI Act — without doing the work three times

The direct answer first, because this question deserves one: you manage SOC 2, ISO 27001 and an AI framework — the EU AI Act, NIST AI RMF, ISO 42001, or all three — without duplicating work by mapping every framework to a single canonical control set, linking each piece of evidence to the controls it proves (never to a framework), and treating the AI framework as an extension of that set rather than a separate programme. Most of what an AI framework demands at the organisational level — risk management, logging, access control, incident handling, supplier oversight, documented governance — is work your security frameworks already require. The genuinely new obligations are a bounded, identifiable residue. Map the overlap, run it once, and spend your actual effort on the residue.

That is the whole method. The rest of this post is the evidence for it: where the three families overlap control-by-control, what is genuinely new in the AI frameworks, and the five-step way to structure the programme so the second and third frameworks cost a fraction of the first.

Why this feels like three times the work (and why it is not)

SOC 2, ISO 27001 and the EU AI Act were written by three different bodies, in three different registers, for three different audiences — an AICPA attestation framework, an international management-system standard, and an EU product regulation. Read side by side they look alien to each other. But frameworks describe obligations; your organisation operates safeguards. And at the safeguard level, the three families are demanding the same underlying machinery in different dialects.

The overlap, control by control

Here is where the same operational safeguard satisfies all three families at once. These are illustrative anchors, not an exhaustive crosswalk — but each row is a real mapping, not a vibe.

Risk management

• ISO 27001 — Clauses 6 and 8 (risk assessment and treatment, run on a cadence).
• SOC 2 — CC3 series (risk assessment, including fraud and change-related risk).
• EU AI Act — Article 9 requires a documented, iterative risk management system for high-risk AI systems, running across the lifecycle.
• NIST AI RMF — the MAP and MANAGE functions are a risk identification and treatment loop; ISO 42001 Clause 6 mirrors 27001’s almost verbatim.

One risk register, with AI systems as first-class entries carrying AI-specific impact dimensions, satisfies the machinery of all of them. What changes per framework is scope and vocabulary, not the loop itself.

Logging and record-keeping

• ISO 27001 — A.8.15 (logging) and A.8.16 (monitoring activities).
• SOC 2 — CC7.2 (monitoring for anomalies and security events).
• EU AI Act — Article 12 requires high-risk AI systems to log events automatically over their lifetime.
• NIST AI RMF — MEASURE expects tracked, documented system behaviour over time.

Access control

• ISO 27001 — A.5.15–A.5.18 (access control, identity, authentication, access rights).
• SOC 2 — CC6.1–CC6.3 (logical access).
• EU AI Act — Article 15’s cybersecurity requirement inherits your existing access regime; the training-data pipeline and model artefacts are assets your access policy already claims to govern.

Incident handling

• ISO 27001 — A.5.24–A.5.28 (incident management planning through evidence collection).
• SOC 2 — CC7.3–CC7.5 (evaluation, response, recovery).
• EU AI Act — Article 73 serious-incident reporting for high-risk systems rides on the same detection, triage and escalation pipeline — with a different notification target and clock.

Suppliers and third parties

• ISO 27001 — A.5.19–A.5.22 (supplier relationships and monitoring).
• SOC 2 — CC9.2 (vendor and business-partner risk).
• EU AI Act — the provider/deployer split means your AI vendors are now a regulated supply chain: a model or system you deploy carries obligations you must verify upstream, through the vendor-assessment process you already run.

Governance and management review

• ISO 27001 — Clauses 5, 9 and 10 (leadership, internal audit, management review, corrective action).
• SOC 2 — CC1 (control environment, board oversight, accountability).
• NIST AI RMF — GOVERN is explicitly this: policies, accountability, culture. ISO 42001 reuses 27001’s clause skeleton wholesale, which is why an existing ISMS is the single biggest head start an AI governance programme can have.

What is genuinely new in the AI frameworks

Honesty matters here, because the overlap pitch gets oversold. The AI frameworks are not a subset of your security frameworks. The residue — the obligations with no security-framework equivalent — is real, and it is where your actual new effort goes:

• Data governance for training, validation and test data (EU AI Act Article 10) — provenance, representativeness, bias examination. Nothing in SOC 2 or ISO 27001 does this.
• Human oversight design (Article 14) — the requirement that a human can meaningfully intervene is a product-design obligation, not an IT control.
• Accuracy and robustness (Article 15) — model performance thresholds and resilience to adversarial inputs are ML engineering work.
• Transparency and technical documentation (Articles 11 and 13, Annex IV) — a living technical file per high-risk system, and disclosure duties to deployers and affected people.
• An AI system inventory with role classification — provider or deployer, risk tier per system. This register is the spine of the whole AI programme and has no security-framework ancestor.
• Prohibited-practice screening (Article 5) — a legal gate, not a control: certain practices are simply banned, and you need a documented check that none of your systems crosses the line.

A reasonable planning posture: the management machinery of an AI framework is largely inherited from a working ISMS; the AI-specific residue above is net-new. Teams with a real ISO 27001 or SOC 2 programme are much closer to EU AI Act readiness than they fear — and much further than vendors claiming "you’re already 90% done" imply.

The method: five steps, in order

1. Define one canonical control set — the safeguards your organisation actually operates. Frameworks map TO it; never map frameworks to each other, or you build an unmaintainable web that rots at the first version bump.
2. Map each framework’s requirements to that set, and mark the AI-specific residue as new canonical controls rather than forcing them into security controls they do not fit. Over-mapping is the fastest way to lose an assessor’s trust.
3. Link every piece of evidence to controls, not frameworks. One access-review export then satisfies ISO A.5.18, SOC 2 CC6.2 and the AI Act’s cybersecurity expectations simultaneously — collected once, shown everywhere.
4. Automate the recurring evidence (access state, logging config, backup runs, MFA posture) so it collects continuously; a Type II window and the AI Act’s lifetime-logging duty both punish evidence you only gather at audit time.
5. Run one governance loop — one risk register, one internal-audit cadence, one management review, one CAPA process — with AI systems, AI risks and AI incidents as first-class citizens inside it, not a parallel shadow programme.

A worked example: one lapse, three frameworks, one fix

Your identity-provider connector flags that the quarterly access review covering the ML pipeline’s service accounts has lapsed. Framework-first, that is three findings in three tools, discovered at three different audits. Control-first, it is one status change that propagates automatically: ISO 27001 A.5.18 flips to attention-needed, SOC 2 CC6.2’s evidence goes stale, and the access-control leg of your EU AI Act Article 15 cybersecurity posture inherits the same flag — because all three point at the same canonical control. One remediation (run the review) clears all three, and the corrective action is logged once in the same CAPA loop your ISO internal audit already uses.

Where Raize Orion fits

This architecture is what Raize Orion is: fifteen frameworks — ISO 27001, SOC 2, NIST 800-53, GDPR, HIPAA, PCI DSS, ISO 22301, NIS2, Cyber Essentials, IASME and DORA, plus an AI-governance line of ISO 42001, the EU AI Act, NIST AI RMF and CBN AI/AML — cross-mapped over one canonical control catalogue, fed by one evidence base with 22 native connectors, one risk register that treats AI systems as first-class, and an AI system register with impact assessments wired into the same risk-promotion flow as everything else. Add the EU AI Act to an existing ISO 27001 programme and the overlap arrives pre-mapped; what remains is the genuine residue, clearly marked. And because framework catalogues change — the AI Act’s obligations are still being amended — the catalogue carries per-framework verification dates rather than silently going stale.

We would give you the same architecture advice if we sold nothing: map once to a canonical set, bind evidence to controls, run one governance loop. That is the entire difference between three compliance programmes and one programme with three outputs.