What a SOC 2 Type II report actually is
A SOC 2 report is an independent auditor's examination of a service organization's controls, performed under AICPA attestation standards and measured against the Trust Services Criteria. It is produced for the benefit of the vendor's customers and their auditors, which is why it usually arrives under NDA.
Three things about it are commonly misunderstood, and each one changes how much weight the report deserves.
It is not a certification
There is no certifying body and no pass mark. There is a report, a stated scope, a stated period, and an opinion. "SOC 2 certified" is not a thing, and hearing it is a small signal about how carefully the vendor uses these terms.
The scope is chosen by the vendor
The vendor decides which Trust Services Categories are included and which systems are covered. A clean report on a narrow scope is a narrow assurance.
It is about controls, not outcomes
The examination tests whether stated controls operated. It does not evaluate whether the product works well, whether the model is accurate, or whether the service is a good fit for regulated credit decisions.
SOC 1 and SOC 3 are different animals
SOC 1 covers controls relevant to a customer's financial reporting. SOC 3 is a short, general-use summary with no detailed testing. Neither substitutes for SOC 2 Type II.
Type I, Type II, and the period tested
The distinction is worth being precise about, because vendors are not always precise about it in sales conversations.
| Type I | Type II | |
|---|---|---|
| What is assessed | Whether controls were suitably designed | Whether they were also operating effectively |
| Time covered | A single date | A period, typically three to twelve months |
| Testing performed | Design only | Design plus operating effectiveness, with samples |
| What it is worth | Evidence a program exists | Evidence the program is actually followed |
Two practical points. A first Type II report often covers a short window — three or six months — because that is the shortest period an auditor will examine. That is normal for a company reaching its first report, but a three-month window over a quiet quarter is meaningfully weaker evidence than twelve months, and the difference is worth noting in your file rather than glossing.
Second, check the report period end date against today. If it closed eight months ago, ask for a bridge letter covering the interval. A bridge letter is a management representation, not an audited document, so treat it as a statement of intent rather than assurance.
How to read the report, in order
Most reports run well over a hundred pages, and most reviewers read the opinion and stop. A better order takes perhaps forty minutes and produces a genuinely different picture.
| Read this | What you are looking for | What should concern you |
|---|---|---|
| The opinion | Unqualified, qualified, adverse, or a disclaimer | Anything other than unqualified, unexplained |
| The scope statement | Which categories and which systems are covered | The product you are buying is not the system described |
| The period | Start and end dates, and length | A short window, or a stale end date with no bridge letter |
| The system description | How the vendor describes what it actually does | A description that does not match the demo you saw |
| Test results and exceptions | Deviations found, and management's response | Repeated exceptions, or responses that do not commit to a fix |
| Complementary user entity controls | What the report assumes you are doing | Controls you have no plan to perform |
| Subservice organizations | Carve-out or inclusive method | Carve-outs with no reports obtained for those providers |
On exceptions specifically: a report can contain deviations and still carry an unqualified opinion, which surprises people. Exceptions are not automatically disqualifying — an auditor noting that one of twenty-five sampled access reviews was completed late is different from systemic failure. What matters is the pattern, the severity, and whether management's response describes a remediation or merely disagrees.
The section almost everyone skips
Every SOC 2 report contains a list of complementary user entity controls: things the report assumes you are doing, without which the vendor's controls do not achieve their objectives.
Typical examples include provisioning and deprovisioning your own users promptly, configuring role-based permissions appropriately, enforcing your own authentication standards, reviewing access reports the vendor makes available, and notifying the vendor of terminations.
This section matters for two reasons. It is a list of your obligations, and failing to perform them is your finding, not the vendor's. And it is diagnostic: a report that pushes an unusually large share of the control environment onto the customer is describing a thinner service than the marketing suggests.
The related section is subservice organizations. Most AI vendors run on cloud infrastructure, and most reports use the carve-out method, which excludes that provider's controls from the examination entirely. That is standard practice and not a problem in itself — but it does mean the assurance is incomplete until you have the subservice provider's report too, and it means the vendor should be able to tell you which controls they rely on that provider to perform.
What SOC 2 does not cover for AI
Here is the part that matters most for an AI system in a credit workflow, and it is straightforward: none of the Trust Services Criteria address model behavior.
A vendor can hold a clean, twelve-month, unqualified SOC 2 Type II report covering Security, Availability, and Confidentiality, and have no controls whatsoever around whether the model extracts figures correctly, whether its accuracy has degraded since deployment, whether it behaves differently on scanned documents than clean ones, or whether your borrowers' financial statements are being used to train it.
Those are not audit failures. They are simply outside what the framework asks about.
The one category that gets close is Processing Integrity — the criteria concerned with whether system processing is complete, valid, accurate, timely, and authorized. For a system that produces numbers used in credit decisions, that is the relevant category. It is also optional, and in practice it is frequently scoped out. Checking whether it was included is one of the highest-value thirty seconds you can spend on the report.
Even where Processing Integrity is in scope, it tests the vendor's stated controls over processing — not the statistical accuracy of a model against a benchmark. It is closer to the question, but it is not the answer.
The AI questions to ask instead
Because the report will not answer them, these belong in a separate section of your diligence, with written responses.
How is output accuracy measured?
Against what benchmark, on what document set, how often, and can we see the methodology? An accuracy figure with no stated basis is marketing.
Is every figure traceable to a source?
Can a reviewer click a number and land on the page it came from? Without this, verification costs as much as doing the work manually.
Can a human override any output?
And is the override captured with the prior value, the new value, the reason, and the user? This is what makes the output defensible in a credit file.
Is our data used for training?
By default, and can it be contractually excluded? Borrower financial data is not the institution's to donate.
How are model changes governed?
Are versions pinned, are changes announced in advance, and can we test before a change reaches production? Silent model updates are a model risk problem.
What monitoring exists for drift?
How would the vendor know accuracy had degraded, and how would we know?
What documentation supports model risk review?
What can the vendor provide to your model risk function, and what will they support during an examination?
What happens on exit?
What form does our data come back in, on what timeline, and what is deleted — including from backups and any derived artifacts?
A useful test of the answers: ask for them in writing and see whether the responses survive contact with your own procurement and model risk teams. Vendors comfortable with regulated buyers will have these documented already.
Where the other frameworks fit
SOC 2 is one input among several, and the others cover different ground.
| Framework | What it addresses | When to ask |
|---|---|---|
| SOC 2 Type II | Security and related controls, tested over a period | Always, for any vendor holding borrower data |
| SOC 1 | Controls relevant to your financial reporting | Where the vendor's processing feeds your financial statements |
| ISO/IEC 27001 | An information security management system, certified | Common with international vendors; complementary to SOC 2 |
| ISO/IEC 42001 | An AI management system — governance over AI specifically | Emerging; a meaningful signal that AI governance is being taken seriously |
| NIST AI Risk Management Framework | Voluntary guidance for identifying and managing AI risk | Ask how the vendor maps to it, rather than for a certificate |
| Penetration test summary | Point-in-time technical testing by a third party | Annually, with remediation status for findings |
Note the asymmetry: the security frameworks are mature and there are clear artifacts to request. The AI governance frameworks are newer, adoption is uneven, and there is no equivalent of "show us the report" yet. That gap is exactly why the written questions in the previous section carry so much of the weight right now.
Your own third-party risk program and interagency guidance on managing third-party relationships will govern how all of this is documented and how deep the diligence goes based on criticality. Nothing here replaces that.
A due diligence request list
A request list you can send more or less as written, once an NDA is in place.
- Current SOC 2 Type II report, with the examination period stated, plus a bridge letter if the period ended more than three months ago.
- Confirmation of which Trust Services Categories were in scope, and specifically whether Processing Integrity was included.
- The complementary user entity controls list, extracted so your team can confirm it can perform them.
- Subservice organizations relied upon, the method used, and their reports where carved out.
- Most recent penetration test summary and the remediation status of any findings.
- Written answers to the eight AI questions above.
- Data processing terms covering training use, retention, deletion, and sub-processors.
- Business continuity and incident response summaries, including notification timelines.
- Evidence of how model versions are managed and how changes are communicated.
Where Uptiq stands on this
We would rather be asked these questions than not. The design decisions that matter for the AI half of the list are ones we can demonstrate rather than assert: every extracted figure carries a citation back to the page of the source document, any figure or classification can be overridden by an analyst with the change and its reason retained, discretionary adjustments are surfaced for a decision rather than applied silently, and the platform runs alongside the core and origination systems already in place across 150+ financial institutions.
For the security and compliance artifacts, including current report scope and periods, ask us directly — that is a conversation with documents attached, not a marketing claim. The same standard should apply to every vendor on your list.
For the operational side of trusting AI output, see how to review AI-generated financial spreads for accuracy, which covers the review discipline that should sit on top of any vendor's controls.
Frequently asked questions
What is a SOC 2 Type II report?
A SOC 2 Type II report is an independent auditor's examination of a service organization's controls, performed under AICPA attestation standards against the Trust Services Criteria. Type II tests whether those controls operated effectively across a defined period rather than existing at a single point in time. The report contains the auditor's opinion, management's assertion, a description of the system, and the controls tested with the results of each test.
Is SOC 2 a certification?
No. SOC 2 is an attestation report, not a certification, and there is no certifying body. A vendor claiming to be "SOC 2 certified" is using the term loosely at best. What exists is a report, covering a stated scope and a stated period, with an opinion attached — which is why asking for the report matters more than accepting the claim.
What is the difference between SOC 2 Type I and Type II?
Type I assesses whether controls were suitably designed as of a specific date. Type II assesses whether they also operated effectively throughout a period, typically three to twelve months. For a vendor handling borrower financial data, Type II over a twelve-month period is the more meaningful evidence; a Type I is a reasonable interim answer from a young company but should not be treated as equivalent.
Does SOC 2 cover AI model accuracy or bias?
No. The Trust Services Criteria address security, availability, processing integrity, confidentiality, and privacy of a system — not whether a model produces correct outputs, how it was trained, whether it drifts, or whether its results are explainable or fair. A vendor can hold a clean SOC 2 Type II report and have no controls at all around model behavior.
What should a lender ask an AI vendor beyond SOC 2?
How outputs are validated and against what benchmark, whether every generated figure is traceable to a source document, whether a human can override any output and whether the override is recorded, whether customer data is used for training and whether that can be contractually excluded, how model changes are versioned and communicated, and what happens to the institution's data on exit.
How recent does a SOC 2 report need to be?
The examination period should be current enough that it has not left a material gap. Where the report period ended some months ago, ask for a bridge letter — a management representation covering the interval between the report end date and today, confirming no material changes to the control environment. A bridge letter is not audited, so it carries less weight than the report itself.
This is general information for vendor due diligence, not legal, audit, or compliance advice. Third-party risk requirements, model risk expectations, and approval processes are set by your own program, your regulators, and your counsel. Framework contents change; verify current requirements with the issuing body.
Ask us the hard half of the questionnaire
Security artifacts and the AI questions both. We would rather work through them properly with your risk and model governance teams than have them skipped.
