What is SOC 2 Type II?
SOC 2 Type II is an independent audit report in which a licensed CPA firm examines a service organization's controls against the AICPA's Trust Services Criteria and tests whether those controls actually operated as described across a continuous observation window, typically six to twelve months.
The report is the document enterprise procurement asks for by name. Buyers in financial services, healthcare, and public-sector-adjacent markets commonly treat a current Type II report as a gate, and without one a vendor rarely reaches the security review stage at all.
How a SOC 2 Type II audit works
A Type II engagement runs through five stages: scope, control design, readiness, the observation window, and testing.
Scope comes first and decides everything downstream. The organization defines which systems, products, subprocessors, and data flows sit inside the boundary, and which Trust Services Criteria categories the report will cover. Control design follows, since the criteria describe objectives and leave the specific control set to the organization to write and commit to. Readiness is the internal dress rehearsal, usually a gap assessment against those written controls.
Then the observation window opens, and for its full length the organization accumulates evidence: access reviews, vulnerability scan output, training records, change approvals, incident tickets, and backup verifications. For an AI support vendor that pool now includes retrieval logs showing which AI contextual evidence a model was given, reasoning traces from agents built on the ReAct agent pattern, and the sampled conversation reviews a customer service QA program already produces.
Testing closes the loop. The auditor samples from that evidence, tests each control, and issues an opinion with any exceptions written into the report.
What SOC 2 Type II covers: the five Trust Services Criteria
The criteria describe objectives and the organization writes the controls that meet them, which is why two vendors holding the same report can operate materially different control sets.
Security (Common Criteria): Present in every SOC 2 engagement, covering access control, change management, monitoring, and incident response across the audited systems.
Availability: Covers whether the system was available for operation and use as committed, usually mapped to uptime commitments and recovery testing.
Processing integrity: Covers whether processing was complete, valid, accurate, and timely, which matters most where a system calculates or moves something.
Confidentiality: Covers information the organization agreed to restrict, such as contracts and support transcripts, through its retention and disposal path.
Privacy: Covers personal information handling against a stated privacy notice, and it is the category vendors most often leave out of scope.
SOC 2 Type II vs SOC 2 Type I vs ISO 27001
Buyers routinely ask for "the SOC 2" and mean three different documents. SOC 2 Type II reports on whether defined controls operated effectively across a continuous window. SOC 2 Type I reports on whether those controls were suitably designed at a single date. ISO 27001 certifies that an information security management system meets an international standard, issued by an accredited certification body. All three describe security posture; only the Type II report describes behaviour sustained over time, which is what a procurement team is actually trying to verify.
Who it binds | What it requires | How it is evidenced | |
|---|---|---|---|
SOC 2 Type II | Service organizations handling customer data, usually audited under buyer pressure | Controls the organization defines against the Trust Services Criteria, operating throughout a window | A CPA firm's report with an opinion, the tests performed, and every exception noted |
SOC 2 Type I | The same service organizations, typically first-time filers or fast-moving startups | Control design judged suitable at one specified date, with no operating history examined | A CPA firm's report on design only, often superseded once a window closes |
ISO 27001 | Organizations seeking international recognition, common with European and Asian buyers | A documented information security management system with risk assessment and treatment | A certificate from an accredited body, maintained through surveillance audits |
If you are buying software that touches customer data, ask for the Type II report and the bridge letter covering the months since the window closed. Ask for a Type I only when the vendor is young and the alternative on the table is nothing.
Why SOC 2 Type II matters for customer experience
The absence shows up as delay. A vendor without a current report enters every enterprise deal through a bespoke questionnaire, a call with the buyer's security team, and a redlined exception process, which adds weeks to a support automation project the operations team wanted live this quarter. Deals that stall in security review rarely fail loudly; they move to the next budget cycle.
There is a second failure mode. Without an audited boundary, decisions about which customer data reaches which system get made informally by whoever wired the integration, and nobody can reconstruct them a year later.
The tradeoff is real: controls that make an audit clean also slow the support floor down. Restricted production access means an agent needs a second approval to pull the record a customer is asking about, and that lands in handle time. As agentic support becomes default, the same friction moves into the AI agent's permissions.
How is SOC 2 Type II measured?
The report itself is the measurement, and it carries several readable signals. Window length tells you how much behaviour was observed. The opinion tells you whether the auditor found the description fairly presented and the controls effective. The exceptions section tells you where a control failed during the window and what management said about it. Scope tells you which systems the other signals apply to.
Individual controls are measured against the deadlines they commit to. Where an external rule sets that deadline, the test becomes objective: a support platform placing outbound calls must honor a consumer's revocation of consent under 47 CFR 64.1200 as soon as practicable and no later than 10 business days, so an auditor can sample revocation requests and count how many were handled inside that bound.
How AI agents change SOC 2 Type II
An AI support agent moves the audit boundary. When software reads customer records and takes actions like issuing refunds or updating an address, the model provider becomes a subprocessor inside scope, the vector store holding help content becomes a system holding customer data, and prompts and responses become logs someone has to retain, protect, and eventually delete.
The consequence is that evidence shifts from infrastructure toward output. Access logs and change tickets still matter, and the auditor now also samples what the agent said and did, because the control under test is often "responses are reviewed against policy" rather than "servers are patched." A walkthrough of AI agents in regulated support covers how those review loops get built.
Nondeterminism is the harder part. A deterministic control either fired or it did not; a generative one operates within a distribution, so demonstrating effectiveness means showing a sampling and review program with stated coverage and outcomes, running continuously through the window.
What to look for in a SOC 2 Type II report
Read the scope section before the opinion. It names the systems and services covered, and a report covering a company's marketing infrastructure while the product handling tickets sits outside it answers nothing useful. For automated support, check whether the agent and its subprocessors sit inside that boundary, which is what SOC 2 AI support describes.
Then check which criteria categories were included, how long the window ran, when it closed, and what the exceptions section says next to management's response. A report with two documented exceptions and a credible remediation note is often more informative than a spotless one.
Regulated buyers ask for more than the report. Healthcare teams ask for a signed BAA covering HIPAA obligations, and EU teams ask for the data processing agreement and the subprocessor list that GDPR conversations turn on.
One constraint catches everyone: adding a newly shipped product to scope takes a full observation window, so a vendor that launched an AI agent this quarter cannot show audited coverage of it for the better part of a year.
SOC 2 Type II and AI compliance
A Type II report answers one question well: did the security controls this organization described actually operate. The broader AI compliance program answers different ones, covering how models are governed under GDPR, ISO 42001, and the EU AI Act, and a CPA opinion speaks to none of them.
EU financial institutions layer another regime on top. Their supervisors examine ICT third-party risk, incident reporting, and resilience testing, so DORA compliance questionnaires arrive alongside the SOC 2 request and ask about failover and exit plans the report never mentions.
What does SOC 2 Type II mean in plain terms?
SOC stands for System and Organization Controls, a reporting framework published by the AICPA. The 2 identifies the report series about security-related controls at service providers, and Type II identifies the version that covers a stretch of time.
Think of it as a season of kitchen inspection logs kept by an outside inspector who was present on ordinary days, recording what the staff did when nobody was preparing for a visit. One visit tells you the kitchen can be clean; a season tells you whether it usually is.
One clarification saves a lot of confused email: SOC 2 is an attestation, not a certification. No certificate exists and no body issues one, so "SOC 2 certified" is shorthand people use for holding a clean report.
The cost is time. Evidence accumulates at the speed of the calendar, so no company can produce a Type II in a hurry, whatever it spends.
Common SOC 2 Type II mistakes
Four patterns account for most of the damage, on both sides of the table.
The first is scoping to the easy answer. Because the organization defines its own boundary, a report can cover the corporate environment while the product being evaluated sits outside it, and the cover page looks identical either way.
The second is reading the opinion and stopping. Exceptions and management responses carry the information a security reviewer needs, and a year with zero exceptions often means the controls were written narrowly enough to always pass.
The third is letting the report go stale. A window that closed a year ago describes a company that may have re-platformed since, and only a bridge letter speaks to the gap.
The fourth is writing controls the frontline cannot execute. A control adding three approvals to a refund gets worked around inside a week, and the workaround becomes next year's exception, which is why voice of the employee signals reach compliance teams before auditors do.
Is SOC 2 Type II a certification?
SOC 2 Type II is an attestation report, so no certificate exists and no body issues one. A licensed CPA firm examines the controls a service organization described and publishes an opinion alongside the tests performed and any exceptions found. Buyers should request the report itself under NDA, together with a current bridge letter.
What is the difference between SOC 2 Type I and Type II?
SOC 2 Type I and Type II differ on time. A Type I report evaluates whether controls were suitably designed at one specified date. A Type II report tests whether those same controls operated effectively across a continuous window, typically six to twelve months, which is why enterprise procurement teams generally ask for the Type II.
SOC 2 Type II vs ISO 27001: which do enterprise buyers ask for?
SOC 2 Type II and ISO 27001 answer overlapping questions for different audiences. North American buyers usually ask for the SOC 2 report because it details tested controls and exceptions in readable form. International procurement often asks for the ISO certificate, showing an accredited body assessed the security management system. Many vendors maintain both.
How long does a SOC 2 Type II audit take?
A SOC 2 Type II audit takes as long as its observation window plus the auditor's fieldwork and reporting. Windows commonly run six to twelve months, and first-time efforts add a readiness assessment and a remediation period before the window opens. Elapsed time from decision to issued report frequently exceeds a year.
What is a SOC 2 bridge letter?
A SOC 2 bridge letter, sometimes called a gap letter, is a short statement from the vendor's management covering the period between the end of the audited window and today. It asserts that the controls described in the report continue to operate and that no material changes occurred. Auditors do not test it.
Does a SOC 2 Type II report cover an AI support agent?
A SOC 2 Type II report covers an AI support agent only when the scope section says so. Scope is defined by the audited organization, so the AI product, its model providers, and its data stores can all sit outside a report that still says SOC 2 on the cover. Read the system description first.