What does a vendor's SOC 2 report leave unanswered about access to AI answers for banks?

A vendor's SOC 2 report leaves AI answers largely unexamined: it shows that baseline controls worked during a past audit period, but says little about permission enforcement, inference data handling, model governance, or answer accuracy unless the vendor explicitly scoped those areas in.

Those open questions are the core SOC 2 limitations for AI vendors in banking. A Type II opinion covers only the system and criteria the vendor chose to describe.

This guide explains what the report covers, where AI-specific risk starts, what bank regulators expect, and which questions to add to your vendor risk assessment.

What a SOC 2 report actually covers — and where its scope ends

A SOC 2 report is a CPA firm's attestation on a vendor's controls, measured against the AICPA Trust Services Criteria. Security's common criteria apply to every report, while Availability, Processing Integrity, Confidentiality, and Privacy are optional categories the vendor selects. None of the criteria contain AI-specific language, and each one is judged against the vendor's own commitments.

A Type II report tests whether controls operated over a period, which CPA firm Linford & Co. says typically runs three to 12 months. A Type I report assesses design as of one date. Both types look backward, so a management bridge letter covers the time since the period ended.

The system description also lists subservice organizations, such as cloud hosts or large language model (LLM) providers. Check whether their controls were tested or only assumed, because that's often where AI processing happens. For banks evaluating an AI for banking service, a clean opinion confirms control hygiene, and AI coverage depends on what the vendor put in scope.

How AI-generated answers introduce risks SOC 2 was never designed to assess

Most SOC 2 testing assumes a system behaves the same way each time it runs, and AI answers break that assumption. Linford & Co. notes in its analysis of AI and SOC 2 that AI outputs "are not generally deterministic." The same input can return a different response.

Processing Integrity asks whether systems "achieve the aim or purpose for which they exist," measured against the vendor's own processing specifications. A vendor that never defined answer-quality commitments gives auditors nothing to test on accuracy. The OWASP Top 10 for LLM Applications (2025 edition) describes hallucination as content that "seems accurate but is fabricated."

Say a branch operations assistant gets asked for the international wire cutoff time. A wrong but confident answer wouldn't trip a single access or encryption control in the report. Ask the vendor about these AI behaviors directly:

• OWASP says it's unclear whether any fool-proof prevention for prompt injection exists, and retrieval-augmented generation doesn't fully mitigate it.
• Restrictions written into a system prompt can be bypassed through prompt injection, OWASP warns.
• Linford & Co. notes that new model versions with different weights produce different outcomes.
• A Type II window is fixed, so ask how the vendor controls and communicates model-version changes between audits.

Where SOC 2 falls short on permission-aware access to enterprise data

Banks layer access by role, department, and document across core banking, loan origination, HR, and shared drives. A SOC 2 report usually shows that the vendor's application enforces logical access. The report won't necessarily show whether the AI checks the requesting user's rights each time it pulls a document into an answer.

Consider a loan officer who asks about an upcoming reorganization and gets an answer quoting a restricted HR memo. OWASP flags this exposure path, warning that "inadequate or misaligned access controls" around embeddings can reveal sensitive information, and recommends permission-aware vector and embedding stores. Permission-aware retrieval also inherits source-system access as it stands, so an overshared folder stays overshared in AI answers.

Some vendors publish their SOC 2 compliance on a security page. In a SOC 2, the Security criteria cover logical access, and encryption and logging are among the points of focus an auditor may test, but what a given report attests to depends on the controls the vendor described. Ask whether those controls extend to the retrieval-augmented generation (RAG) pipeline, which fetches documents and passes them to an LLM to write the answer. Then read the complementary user entity controls (CUECs), the duties the vendor assigns to you, and give each one an internal owner:

• Identity federation and single sign-on (SSO) configuration
• Mapping of source-system groups into the AI tool
• Access removal when employees change roles or leave
• Periodic cleanup of overshared sites and folders

What SOC 2 reports omit about data handling inside AI pipelines

A SOC 2 report can confirm encryption at rest and in transit. Inside an inference pipeline, prompts can also be logged, cached, retained by an LLM provider, or used for training. OWASP's 2025 list advises clear "data retention, usage, and deletion" policies and cautions that unclear provider terms can expose data to model training.

The interagency third-party guidance asks banks to weigh privacy laws and cross-border information flows when a provider operates abroad. A data center list won't trace one query through retrieval, the LLM provider, and logging, so request a data-flow description. Treasury's 2024 AI cybersecurity report notes that adopting AI through multiple intermediaries and service providers complicates oversight. The criteria already list "data and data flows" as a point of focus for the vendor's own risk assessment.

Zero-day retention and no-training commitments usually live in contracts and subprocessor terms, and may sit outside the auditor's opinion. Linford & Co.'s guide to SOC 2 reports walks through the auditor's opinion, test results, bridge letters, and CUECs. Tenant isolation at the model layer still needs its own question. Send the vendor these:

• Which prompts and answers get logged, and for how long?
• Which LLM providers process bank data, and in which regions?
• Do provider contracts bar training on bank data?
• How does the vendor return or destroy data at termination?

Why banking regulators expect more than SOC 2 for AI vendor oversight

U.S. bank supervisors treat a vendor's audit report as one piece of due diligence, and a May 2025 GAO report flagged concentration risk from reliance on a small group of third-party AI service providers. That makes SOC 2 limitations for AI vendors in banking an exam issue for the bank. As of October 2026, the main sources are guidance, not law, and the 2023 third-party guidance faces a pending proposal to replace it.

Regulatory frameworks that go beyond SOC 2

OCC Bulletin 2023-17, issued June 6, 2023, rescinded OCC Bulletin 2013-29 and adopted the interagency guidance on third-party relationships. That guidance asks banks to consider whether a SOC report's scope and results "are relevant to the activity to be performed." In September 2026 the OCC, Federal Reserve, FDIC, and NCUA proposed new third-party risk management guidance that would replace the 2023 guidance if finalized, with comments due November 16, 2026.

The FFIEC Information Security booklet (September 2016) says oversight of a third-party provider should be "commensurate with the sensitivity and criticality of the information and business processes" it supports, and it calls for "independent review of the third party's security through appropriate reports from audits and tests." For model risk, Federal Reserve SR 26-2 replaced SR 11-7 on April 17, 2026. SR 26-2 places generative and agentic AI outside its scope, so each bank's own governance has to set those controls.

Banks with EU exposure have one more reference point. Annex III of the EU AI Act lists AI used to evaluate the creditworthiness of natural persons as high-risk, with fraud detection excepted. Classification follows intended purpose, so an internal knowledge assistant doesn't land in that category by default.

Gaps between SOC 2 and banking-specific AI audit requirements

The Trust Services Criteria have no category for model governance or fairness, and Treasury's December 2024 report on AI in financial services highlighted smaller institutions' dependency on third-party providers. Your AI governance program has to fill those gaps:

• Model governance reviews should cover how the vendor selects, validates, updates, and retires models.
• Fair lending reviews should stay with the bank whenever AI touches credit workflows.
• Incident plans should name AI failure modes, such as prompt injection and permission bypass bugs.
• Response plans should also cover widespread inaccurate answers after a model update.

How banks can close the gap between SOC 2 and AI-specific vendor risk

Sound SOC 2 report analysis treats the report as the first document in the vendor file. That matters because Verizon's 2025 Data Breach Investigations Report found the share of breaches involving a third party doubled to 30%. The interagency guidance describes audit rights, penetration test results, and data-use terms as due diligence considerations. Extend each one to the AI stack:

1. Confirm the AI product sits inside the system description, and note which criteria were tested.
2. Ask for an architecture diagram of the full inference pipeline that names every LLM subprocessor.
3. Run a live permission test where two users with different access ask the same question.
4. Request the penetration test summary, and ask whether testing covered prompt injection.
5. Review the vendor's AI governance, including output monitoring and rollback when a model update hurts accuracy.
6. Write audit rights that reach the AI stack into the contract, next to the retention and training terms.
7. Start with a standardized questionnaire such as the Shared Assessments SIG, then add AI-specific questions.

Step four matters because the criteria list penetration testing as a point of focus, yet auditors aren't required to address every point. In the permission test, the restricted user should get nothing drawn from documents they can't open in the source system.

Good vendor documentation answers these questions without a follow-up call. Glean, for example, enforces permissions upstream of the LLM and holds contractual zero-day data retention with its LLM providers. Your team can confirm both during contract review.

Frequently asked questions

What specific areas of risk are not covered by a SOC 2 report for AI vendors?

Six areas often go untested unless the vendor defined commitments for them. Those are answer accuracy, hallucination rates, model governance, bias in outputs, permission checks at retrieval time, and data handling inside third-party LLM inference. Each one needs a direct question in your vendor risk assessment.

How can banks assess the adequacy of a vendor's SOC 2 report for AI solutions?

Start with scope by confirming the AI product appears in the system description and noting which criteria were tested. Review exceptions and management responses, list every subservice organization, and map each CUEC to an owner. Linford & Co. notes that user auditors may not rely on a bridge letter covering more than six months.

What additional compliance frameworks should banks consider alongside SOC 2 for AI vendors?

Pair SOC 2 with the FFIEC IT Examination Handbook, the interagency third-party guidance, and the NIST AI Risk Management Framework plus its generative AI profile. ISO 27001 sets requirements for an information security management system, and ISO/IEC 42001 sets requirements for an AI management system, which governs how an organization manages AI risk across the business rather than the details of specific AI applications. A vendor can be certified against either by an independent certification body, but certification speaks to the management system, not the accuracy of any given answer.

What are the implications of relying solely on a SOC 2 report for AI vendor selection?

Sole reliance leaves four exposures open: restricted content surfacing through retrieval, quality drifting after model changes, unnegotiated LLM retention terms, and a thin exam record. The interagency guidance is risk-based, so one attestation report gives examiners little evidence for an AI system that reaches customer records.

How does SOC 2 address data privacy concerns in AI applications for banks?

Privacy is an optional Trust Services Criteria category, so first check whether the report includes it at all. When included, auditors test it against the vendor's own privacy commitments. Those commitments may never mention prompts, retrieval, or generated answers, which leaves data privacy in AI queries, including data minimization, for your team to verify.

Your SOC 2 review gives you a solid starting file, and the questions above cover what it leaves open about AI answers. We built our platform around permission-aware retrieval and cited answers grounded in company knowledge, so your team can test each question against a live environment. Request a demo to see how we handle permissions, data retention, and governance for your bank.