A SOC 2 Type II report is an independent audit of a vendor's operating controls across a multi-month observation window, distinct from SOC 2 Type I (a point-in-time design review) and SOC 1 (financial reporting controls). For an AI vendor inside a commercial underwriting workflow, Type II is the report your vendor-management team should ask for, because it shows whether the controls held up over a real period rather than on the day of the test.
Most coverage of SOC 2 in commercial lending AI stops at one of two places. Vendor marketing treats the badge as the headline. Generalist compliance content describes the framework without naming what to read inside the actual report. Neither helps the analyst with a 60-page PDF on the desk and three weeks to write a recommendation. The job here is to name the four things that matter, the regulatory boundary the report sits inside, and the questions SOC 2 was never built to answer.
Aloan is SOC 2 Type II certified covering Security, Availability, and Confidentiality, so we have been through the audit and read the reports the other way around. The guidance below is written for any community bank evaluating any AI underwriting vendor. For the broader third-party risk lifecycle this report sits inside, the OCC 2023-17 guide for AI underwriting vendors is the right next read.
What Is SOC 2 Type II and How Does It Differ From Type I and SOC 1?
SOC 2 is a System and Organization Controls framework from the AICPA, built around five Trust Services Criteria: Security, Availability, Confidentiality, Processing Integrity, and Privacy. A SOC 2 audit is an opinion issued by an independent CPA firm against the criteria the vendor selected.
The Type I and Type II distinction is about time. Type I is the design review: at a single moment, are the controls described correctly and in place? Type II is the operating review: across an observation window of typically 6 to 12 months, did those controls operate consistently? Type I is the cheaper artifact a vendor can produce on the way to Type II. Type II is the one your bank's vendor-management team should require for any vendor doing material work inside the underwriting flow.
SOC 1 is a different report covering Internal Controls over Financial Reporting, built for auditors of customer financial statements. An AI underwriting vendor that hands you a SOC 1 in response to a SOC 2 request has answered a different question. Push back and ask for the right report.
| Report | What it tests | Time horizon | Right ask for AI lending vendors? |
|---|---|---|---|
| SOC 1 | Internal controls over financial reporting | Type I or Type II | No, unless the vendor touches ICFR |
| SOC 2 Type I | Design of security and trust-services controls | Point in time | Acceptable bridge while Type II is in flight |
| SOC 2 Type II | Operating effectiveness of those same controls | Observation window, usually 6 to 12 months | Yes, this is the standard ask |
What Should a Vendor-Management Team Verify Inside the Report?
Once the report is in front of you, four sections do most of the work. None of them are hidden. They are just the ones marketing slides skip.
1. Observation period length
The first page of the auditor's opinion states the window the report covers. Look for a 12-month observation period if the vendor has been operating long enough to produce one. A 6-month window is common for a first Type II report, particularly right after a vendor bridges from Type I, and is acceptable as long as the trajectory is toward an annual cycle. Note the gap between the end of the window and today, too. A report that ended nine months ago should be paired with a current bridge letter.
2. Trust Services Criteria in scope
Security is mandatory in every SOC 2 report. For a commercial lending AI vendor, you want Availability and Confidentiality on top of Security. Availability tests that the platform is reachable when banks need it. Confidentiality tests that designated information stays protected from unauthorized disclosure, which is where the contractual zero-training language for AI inference providers anchors. Processing Integrity is rare in this category, and Privacy is uncommon unless the vendor processes consumer data directly. If the in-scope criteria do not include Confidentiality, ask why before going further.
3. Exceptions and management responses
Section IV lists every control the auditor tested and the result. An exception means the control did not operate as designed during the window. Exceptions are not automatic disqualifications, and mature vendors usually have one or two minor ones per audit. What matters is the management response: did the vendor explain root cause, remediate, and demonstrate the fix? Repeated exceptions across consecutive years on the same control are a flag. A single access-review exception with a documented remediation is the normal texture of an operating control environment.
4. Subservice organization carve-outs
This is the question that matters most for AI vendors. Every AI underwriting platform depends on inference providers, usually Gemini Enterprise, AWS Bedrock, Azure OpenAI, or a similar hyperscaler. The report has to declare whether those providers are carved out (excluded from the audit, with the provider's separate SOC 2 referenced) or carved in (their relevant controls tested inside the vendor's audit). Neither is automatically right. Carved-in means the vendor takes a shared accountability posture for the AI provider's controls. Carved-out means the bank is reading two SOC 2 reports back-to-back. The vendor-management team has to know which model applies, because their reliance shifts accordingly.
Worked example: Aloan's SOC 2 Type II carves Google Cloud (Gemini Enterprise) and AWS Bedrock into the security boundary. Both providers separately maintain SOC 2 Type II, ISO 27001, FedRAMP, HIPAA eligibility, and GDPR. The architecture and the data handling that sit behind that carve-in are documented on the AI data security page.
Why Is SOC 2 Necessary but Not Sufficient?
A SOC 2 Type II report is a real, well-scoped artifact. It also does not answer every question the diligence file needs. The regulatory frame around an AI underwriting vendor sits on top of the SOC 2 review, and parts of it have nothing to do with controls.
The third-party risk lifecycle in OCC Bulletin 2023-17 tells banks to scale diligence to the risk of the activity. The SOC 2 review maps cleanly into the due diligence and ongoing monitoring stages of that lifecycle. It does nothing for the contract terms (zero-training data use, model-change notification, data residency, termination egress) or the planning question of whether you should buy this kind of vendor at all.
The model risk frame is separate again. SR 11-7 defined model risk management as an enterprise discipline. The revised guidance issued in April 2026 as SR 26-2 and OCC Bulletin 2026-13 carried that forward with AI-relevant clarifications, and OCC Bulletin 2025-26 still operates as the community-bank proportionality lens. SOC 2 does not validate model accuracy, output quality, or bias. A vendor that points to its SOC 2 to answer a model-validation question has misunderstood the question.
Translated to the desk: a clean Type II gets the vendor into the room. It does not finish the diligence. The room still has the bank's credit policy, its document mix, its workflow, and its model risk owner in it. The examiner readiness guide covers the model-side review; the AI underwriting governance frameworks guide covers the four artifacts the program needs internally.
What Should You Ask the Vendor That the Report Does Not Answer?
Four AI-specific questions are not addressed by a typical SOC 2 report, even a thorough one. Get them in writing as part of the diligence file.
- Model-output retention. How long are AI outputs stored, and what is the deletion path on contract termination or customer request? SOC 2 confirms that data retention controls exist. It does not state the retention window in days. Get the number in the data processing agreement.
- Prompt and response logging cadence. Are every model input and output captured in an audit log with timestamp, user, and source-document reference? If not, an examiner cannot trace an output back to its input, and the bank cannot defend an override the way SR 11-7 and SR 26-2 expect.
- Override audit-trail surface. When an analyst overrides an AI output, is the original output preserved, attributed, and timestamped alongside the corrected value? SOC 2 confirms that change-management controls exist. It does not confirm that the underwriting workflow itself maintains the override trail your auditor will want to read.
- Third-party AI zero-training posture. Each AI inference provider the vendor uses has its own data-handling contract. Google Cloud (Gemini Enterprise) and AWS Bedrock both contractually guarantee that customer inputs and outputs are never used to train, improve, or fine-tune foundation models. Other providers may differ. Ask the vendor to enumerate every model provider and produce the contractual language for each.
These are the items most banks want documented when an exam team starts pulling files. Asking at diligence is cheaper than answering under deadline pressure later.
What Does Aloan's SOC 2 Posture Cover?
For the reader who wants the worked example, here is what Aloan ships into a community-bank TPRM file.
- SOC 2 Type II report. Independent audit covering Security, Availability, and Confidentiality. Available under NDA through the Trust Center, along with penetration test results, the data processing agreement, and the information security policies.
- Carve-in posture for inference providers. Gemini Enterprise and Bedrock are carved into the security boundary. Each provider separately maintains SOC 2 Type II, ISO 27001, FedRAMP, HIPAA eligibility, and GDPR. The architecture and data flow live on the AI data security page.
- Regulatory alignment. The platform is built against FFIEC technology risk guidance, OCC 2023-17 third-party risk management, and the current model risk frame (SR 26-2 and OCC Bulletin 2026-13, with OCC Bulletin 2025-26 as the community-bank proportionality lens). The AI-Assisted Underwriting Playbook walks the program-level rollout.
- Override and audit-trail surface. Every AI output ties back to its source page in the underlying document. Overrides preserve the original value, the corrected value, the user, and the timestamp.
Other vendors will have other answers. The point of this page is to give the analyst on the other side of the table a way to ask.
Six-Question Vendor Checklist
A short list to send the vendor before the diligence meeting. Each answer should be a paragraph, not a yes.
Send before the diligence call
- What observation period does your current SOC 2 Type II report cover, and when does the next audit window close?
- Which Trust Services Criteria are in scope, and why those?
- List every exception in the current report, the root cause, and the remediation status.
- For every AI inference provider you use, state whether they are carved out or carved in, and produce the zero-training contractual language for each.
- Describe model-output retention, prompt and response logging cadence, and the override audit-trail surface as they live in the product today.
- Do you issue quarterly SOC 2 bridge letters between annual Type II audits, and can you commit to that cadence in writing?
Six questions is short on purpose. If the vendor cannot answer any of them in a paragraph each, the SOC 2 report is doing more work than the operating posture behind it can support.
Frequently Asked Questions About SOC 2 Type II for Commercial Lending AI
Is a SOC 2 Type II report enough on its own?
No. It satisfies a chunk of the OCC 2023-17 due diligence and ongoing monitoring stages. It does not address model risk, contract terms, or the workflow questions a vendor-management team is responsible for. Treat it as one document inside a larger file.
How short an observation window is acceptable?
Six months is reasonable for a first Type II report after bridging from Type I. Twelve months is the standard for established vendors. Always ask when the next audit window closes so you know how long the current report stays current.
What does it mean if exceptions show up in the report?
Exceptions are normal at low counts. Look for a stated root cause, a remediation plan, and evidence the same exception did not repeat in the next audit. Repeated exceptions on the same control across years are a flag worth surfacing in your write-up.
Does the bank need to read the subservice provider's SOC 2 too?
If the provider is carved out, yes, the hyperscaler's SOC 2 sits in the file as a complementary report. If carved in, the vendor's own audit already tested the relevant controls. Either way, document the reliance posture so an examiner can see how the chain hangs together.
How this works in practice: Aloan ships a documentation pack built to slot into a community-bank TPRM file under OCC 2023-17 and 2024-11: the SOC 2 Type II report under NDA, the data processing agreement with zero-training language, architecture documentation that shows the Gemini Enterprise and Bedrock carve-in, model documentation, and the override audit-trail surface. Get a demo and bring the questions above. We will walk the pack with you.
Go deeper: For the third-party risk lifecycle this report fits inside, read the OCC 2023-17 guide for AI underwriting vendors. For the architecture behind the carve-in, see the AI data security page. For the model-risk review that lives parallel to this third-party file, read the examiner readiness guide and the AI underwriting governance frameworks guide. For the rollout sequencing across the full AI underwriting program, go back to the AI-Assisted Underwriting Playbook.