Your AI agents entered your SOC 2 scope the moment they started touching systems your controls govern. Nobody sent a memo about it — but your auditor will notice, because access management, change control, and monitoring criteria don't exempt actors for being automated. The question is what evidence you'll have when they ask.
What a Type II audit actually asks
A Type II report isn't about whether your controls exist — it's about whether they operated effectively over a period, typically six to twelve months. That distinction is the whole game. A Type I can be satisfied with screenshots and policy documents; a Type II wants proof that the control ran in March, and in April, and every month since — including on the systems nobody was watching closely.
For human-driven activity, organisations have years of practice producing that evidence. For agent-driven activity, most have a pile of application logs and a hopeful attitude. The awkward conversations are predictable: who reviewed the agent's access? Where's the record of what it changed? How do you know this log wasn't edited after the incident? The gap is exactly the kind of thing that turns into a finding, or into weeks of engineering time reconstructing history the recorder would have simply kept.
What the Evidence Pack contributes
A SOC 2 Evidence Pack assembles the agent-activity side of the audit: agent inventories, role-and-access snapshots, anomaly history with resolutions, signed event samples per control, and a control-by-control narrative mapped to the Common Criteria that your CPA firm can read straight into their working papers. The period defaults to the trailing twelve months — matching the audit window rather than making you stitch quarters together.
The working-papers detail matters more than it sounds. Auditors don't grade your dashboard; they assemble a file. Evidence that arrives already structured — this control, this period, these sampled events, this attestation of integrity — goes into that file with minimal translation, and minimal translation is what keeps audit hours (and fees) down. The pack is designed around how the audit is actually conducted, not around how the product looks best.
Why signed evidence fits Type II so well
Period-coverage evidence has a quiet weakness: most of it is assembled after the fact, from systems that could have been edited in between. A tamper-evident record inverts that. Every sampled event verifies against your key; the chain shows the record ran continuously rather than being reconstructed for audit season. "The control operated all year, and here's a record that couldn't have been quietly rewritten" is the strongest form of the sentence a Type II exists to produce — and your auditor can check the crypto themselves rather than trusting the vendor who printed the report.
The boundaries, plainly
Three things we say on the SOC 2 page and will repeat anywhere: Wytness covers the AI-agent subset of your scope — HR controls, vendor management, and physical security remain your own evidence problem. The audit itself is done by a CPA firm; we support it, we don't replace it. And Wytness is not itself SOC 2 certified — the vendor attestations we do hold are listed on our Security page, and we'd rather state that plainly than let you discover it in procurement.
When to start
Type II evidence has a property that punishes procrastination: it can't be backfilled. If your audit window opens in January and you start recording in March, the report can only speak to ten months, and the auditor will ask about the missing two. The record of the next twelve months starts existing when the recorder starts running — which is the practical argument for instrumenting agents before your audit window opens, not during it. Teams that wire this up early get the quieter version of audit season: the agent section arrives as the cleanest evidence in the file, because it was never assembled — it accumulated.
Questions about your control mapping? Ask us.