SOC 2: evidence that holds up across the whole period
A SOC 2 report is unusual among the frameworks here: it samples behaviour across months. That changes the evidence you need. Not a screenshot of today's configuration, but a record showing the control operated every day the auditor is looking at.
- The instrument
- AICPA Trust Services Criteria (2017, revised 2022), with Security as the mandatory common criteria
- Status
- In force; Type I (design) and Type II (operating effectiveness)
- Who it applies to
- Service organisations preparing for or renewing a SOC 2 engagement where AI sits inside the system boundary.
Where AI-FW fits
A SOC 2 report describes your controls over a period, and AI-FW is a system inside the report's scope boundary and a source of Type II evidence. The auditor samples behaviour across months, so a control that was disabled for two weeks in March is a finding even if it is enabled today. What the product contributes is continuous, timestamped, reproducible evidence of what the AI path did and who changed it.
What stays with you
Read this list first. It is the boundary of what a product can do for you, and it is where the remaining work sits.
- Defining the system boundary and choosing the trust services criteria in scope
- Complementary user entity controls, and complementary subservice organisation controls if you rely on a hosting provider
- Organisation-level controls: people, training, risk assessment, vendor management, continuity, incident response runbooks, vulnerability management and penetration testing
- The readiness work and the engagement itself, which belong to your CPA firm
- The opinion in the report
What the framework asks, and what the product does
The obligations that touch the AI path, paired with the capability that answers each one. Everything else in this framework is organisational work, listed above.
Provision access on a need basis, and keep it least-privilege
Role policies, per-agent identity, owner-scoped views and key lifecycle, with access changes recorded against an actor
Protect the system boundary and the data in transit
A single ingress point, TLS throughout, and a model allow-list enforced by the inventory rather than by convention
Detect configuration change and unusual activity
An audit trail of every rule and setting change, drift detection when a control is switched off, and an approval queue for sensitive actions
Evaluate, respond to and recover from incidents
Error and violation telemetry with attribution and timestamps, enough to build a defensible incident timeline
Authorise and record changes to the system
Every enforcement change recorded with actor, intent and timestamp, and the control set version recorded per release
Assess and monitor the vendors inside the boundary
A model inventory enumerating every provider in the AI path, ready for vendor risk assessment and contract review
Communicate control objectives and responsibilities
In-product documentation of controls and owners, and attestations that name an accountable person rather than a team
Meet confidentiality commitments, and dispose of data properly
Masking rules, retention settings with recorded purge, and evidence packs that exclude payloads so the artefacts are safe in themselves
Process completely, accurately and on time
Input and output guard rules, upstream error capture, and a parameter policy that prevents a silent model substitution
Handle personal information according to your commitments
Category telemetry and retention settings supporting your privacy programme, with deletion executed in your source systems
Monitor controls, and evaluate them over time
Scheduled assessment, a posture score that trends, and a gap list with owners and expiry dates
A rule pack to start from
The enforcement that makes the controls real. Severity runs 1 to 5, and a rule that is switched off reports as a gap, so these are meant to be live from day one.
Confidentiality commitments, enforced at the boundary of the system
Reduces the population of data the system has to protect
Boundary protection, and keeps the vendor inventory true
Processing integrity for the AI path
The output-integrity signal, observed before it is enforced
What the evidence pack contains
Per period, and without prompt or response content, which is what makes it safe to hand over.
- Per-period control statusesComparable across months, not a single snapshot
- Change logComplete for the period: gaps in telemetry are themselves findings
- Drift findings and resolutionsEach one showing an investigation, not just a closure
- Access and retention configurationNo shared accounts, and retention at least the audit period
- Vendor inventoryEvery provider in the AI path, with the control set version and manifest hash
Customer responsibilities and sources
- Define the system boundary and choose the trust services criteria in scope: Security is mandatory, the others optional.
- Document complementary user entity and subservice organisation controls where you rely on another party.
- Run the organisation-level controls: people, training, risk assessment, vendor management, continuity, incident response, vulnerability management and penetration testing.
- Complete the readiness work, then the Type I and Type II engagements, with your CPA firm.
- Keep an export cadence across the observation window, and treat each pack as immutable once generated.
Common questions
No. This page is about how AI-FW helps you evidence the AI part of your own report. Our own certifications and compliance posture are described on the trust page, and if you need to know what we can share, and under what terms, ask us directly.
Type I looks at design at a point in time, which a configuration screenshot can often satisfy. Type II looks at operating effectiveness across months, so it asks whether the control was working on the days the auditor samples. A guard rule that was disabled for two weeks in March fails the period even if it is enabled today, which is exactly what drift detection exists to catch.
Control statuses for the period, the complete change log, drift findings with their resolutions, role and access configuration, retention and purge records, and the vendor inventory, with the control set version and a manifest hash tying the pack to what produced it. No prompt or response content, which is what makes it safe to hand to an auditor directly.
Validate it yourself with our Technical Plan
Ask us to run this framework against your own environment: the rules that would be created, what the assessment reports, and what the evidence pack contains for a real period.
This page maps product capabilities to published expectations. It is not legal, audit or certification advice, and it creates no compliance representation. Applicability and sufficiency are judgements for your counsel and, where relevant, your auditor, assessor or certification body. Framework details are current as reviewed; check the primary sources above, and the page itself, before relying on a date or a threshold.