SOC 2 and ISO 27001: The Two Frameworks Map One-to-One Onto the Architecture
One team has already cleared this bar in public: Intercom ran AI-approved pull requests past its auditors, Schellman, and confirmed the evidence meets SOC 2, HIPAA, ISO 27001, ISO 42001, and AIUC-1 at once (Intercom). SOC 2's change-management (CC8.1) and logical-access (CC6.x) criteria, and ISO 27001
's Annex A technology controls, map almost one-to-one onto the seven properties, and every row below resolves to an artifact the environment or workflow already emits on every task. You are not assembling evidence for the audit, you are reading it off a system that produced it by running normally.SOC 2 (AICPA Trust Services Criteria, 2017) is where AI-driven code change gets tested hardest, because change management and logical access are exactly what an autonomous committer stresses.
One scope caveat before the tables. These mappings assume the reference architecture is actually deployed: agents under their own identities, in isolated environments, with humans at declared gates. If agents run on laptops with borrowed human tokens, the rows below have no evidence behind them, and the gap is the whole story.
CC8.1, change management, is the load-bearing SOC 2 criterion
CC8.1 asks that changes are authorized, designed, developed, tested, approved, and deployed under a defined process. The session log plus gate-approval records answer it more completely than most human processes do, because the evidence is generated by the system rather than reconstructed for the audit.
| Criterion | What it asks | Evidence artifact |
|---|---|---|
| CC8.1 (change management) | Changes follow a defined, approved process | Encoded workflow definition; per-task session log showing write → review → approve → ship in order; gate-approval records; test results in the event log |
| CC6.1 (logical access security) | Access restricted to authorized users via identity architecture | AI-identity records; per-task access-scope records showing what each environment could reach |
| CC6.2 (registration and authorization) | Credentials issued to authorized entities, removed when invalid | Per-session token issuance records; scrub-gate logs showing credentials removed before any snapshot |
| CC6.3 (access modification and removal) | Least privilege, granted and revoked per role | Per-task scoping records; absence of ambient credentials demonstrable from provisioning records |
| CC7.2 (system monitoring) | Anomalous activity detected and evaluated | Session event log queryable per task, actor, and time window |
| CC7.3 / CC7.4 (incident evaluation and response) | Events evaluated, incidents responded to | The log supports investigation; the response process is organizational |
The pattern is evidence as a byproduct. "We follow our change policy" stops being an interview answer and becomes a query.
Segregation of duties becomes structural, not procedural
CC8.1 expects the entity making a change not to be its sole approver. The workflow makes this structural through review as a gate: the AI author identity and the gate approver are never the same actor, and the gate-approval record proves it per change. Intercom's data is the existence proof that the gate can itself be automated without weakening the control: 19% of PRs auto-approved with zero reverts in the 100-PR pilot (Intercom). The full argument is in segregation of duties.
ISO 27001's Annex A technology controls map almost one-to-one
ISO 27001
certifies an information security management system (ISMS), not a product, but Annex A is where AI code change lands. The credential-isolation pattern, tokens never in the sandbox and scrub-before-snapshot as a hard gate, is a direct implementation of A.8.2 through A.8.4, and it is the control laptop setups fail by construction. The configuration controls (A.8.9) trace the same way: environments built only from versioned, known-good images carry a documented, monitored configuration as a fact of how they boot.| Annex A control | What it asks | Evidence artifact |
|---|---|---|
| A.5.15 / A.5.16 (access control, identity management) | Managed identity lifecycle, access on business need | Distinct AI identities bound to humans; per-session token records |
| A.5.18 (access rights) | Rights provisioned, reviewed, revoked | Per-task scoping records; tokens expire with the session |
| A.8.2 (privileged access rights) | Privileged access restricted and managed | Provisioning records showing no ambient or standing privilege in task environments |
| A.8.3 / A.8.4 (information access restriction, source code access) | Read/write access to code restricted | Scoped repo access per task; AI-identity commit metadata distinguishing who, and what, touched source |
| A.8.9 (configuration management) | Configurations established, documented, monitored | Versioned image IDs; environments built only from known-good snapshots |
| A.8.15 / A.8.16 (logging, monitoring) | Event logs produced, protected, reviewed | Append-only external session log; access-controlled retention |
| A.8.31 (separation of dev, test, production) | Environments separated to reduce risk | One isolated environment per task; no cross-environment communication |
| A.8.32 (change management) | Changes under change-management procedures | Same artifacts as SOC 2 CC8.1 above |
The frameworks and the market are converging on this shape independently. Vanta reports 70% of companies have AI tools accessing their environment outside procurement channels (Vanta), and Microsoft now ships agent identity as a product category, first-class directory objects with sign-in logs and conditional access (Entra Agent ID). Treating agents as identities with defined permissions and named owners is what the A.5.15/A.5.16 and CC6.x rows above already demand; the architecture delivers it by binding each agent identity to the human who initiated the task.
What neither framework gets from the architecture
Both frameworks are roughly half organizational, and the architecture does not touch that half. For SOC 2: CC1.x (control environment, board oversight, competence) is policy and HR; CC2.x and CC3.x are documents you write; CC1.4 wants training records, which no event log produces; CC9.2 (vendor risk) is your management of the model provider and platform vendor, including their SOC 2 reports. For ISO 27001: clauses 4 through 10, the ISMS itself, are mandatory and organizational, as are A.6.3 (awareness training) and A.5.19 through A.5.23 (supplier relationships and cloud services).
Note the recursion in that last item: the platform that gives you the seven properties is itself a vendor on the supplier list. If you buy rather than build, demand isolation guarantees and audit-data export in writing.
The technical half, though, is the expensive half to retrofit and the cheap half to get by construction. How one evidence set serves both frameworks at once, plus ISO 42001 and AIUC-1, is the subject of one audit, many frameworks; what the auditor actually asks across both is in the four-axis audit query.