How Banks Review a Vendor's SOC 2 Report, Section by Section

How do banks review a vendor's SOC 2 report? A bank's vendor risk analyst rarely reads the whole thing. They check the report type and period, the auditor's opinion, the scope and carved-out subservice organizations, the exceptions in the testing section, and the user entity controls the bank must run. Then they ask for a bridge letter if the period has ended. Any gap becomes a follow-up question or a contract clause.

Why a bank partner is asking for SOC 2 at all

Banks do not buy software on trust. A federally regulated bank in Canada must run a third-party risk programme under OSFI's Guideline B-10, in effect since May 1, 2024. That programme expects due diligence before signing, ongoing monitoring afterwards, and a contractual right to evaluate the vendor's risk management. B-10 names "independent reports provided by third parties" as one of the accepted ways to do that.

A SOC 2 report is that independent report. It is issued by a licensed CPA firm under the AICPA's SOC 2 framework, and it lets the bank rely on someone else's testing instead of auditing you itself. Banks in the US and partner banks behind many fintech programmes follow the same logic under their own regulators.

For an early-stage fintech, this is why the request feels abrupt. The bank is not judging your product. It is filling a file that its own examiners will read.

What a vendor risk analyst reads first

A SOC 2 report is often a hundred pages or more. Analysts who review dozens a quarter go straight to a short list of sections, in roughly this order.

Section	What they check	What triggers a follow-up
Report cover and opinion	Type I or Type II, the review period, the CPA firm, and whether the opinion is unqualified	A qualified or adverse opinion, a Type I where they expected Type II, or a period that ended long ago
Management's assertion	That management signed it and the description matches the service being bought	A different product name or entity than the one on the contract
System description	Scope: which product, infrastructure, locations and Trust Services Criteria are covered	The service the bank is buying is not in scope, or only Security is covered when they expected Availability or Confidentiality
Subservice organizations	Who is carved out, such as the cloud provider, and what controls the vendor expects of them	A critical subservice organization with no evidence the vendor reviews its report
Complementary user entity controls	What the bank itself must do for the controls to work	CUECs the bank cannot or will not perform
Tests of controls and results	Exceptions, how many, in which controls, and management's response	Exceptions in access, change management or monitoring with no remediation

If you want your own report to survive this review, write the system description and CUECs as if you were the analyst. Our SOC 2 system description example shows what a reviewer expects to find there.

The opinion and the period

The opinion paragraph is the first stop. An unqualified opinion means the auditor concluded the description is fairly presented and the controls were suitably designed, and for a Type II, operated effectively through the period. A qualified opinion means at least one criterion was not met. It does not automatically end a deal, but it guarantees a conversation.

The period matters almost as much. Most banks want a Type II report, because it covers how controls operated over months rather than how they looked on one day. A Type I is often accepted for a first engagement if the vendor shows a Type II is under way. The difference is explained in SOC 2 Type 1 vs Type 2.

A Type II period that ended more than a few months ago creates a gap the bank cannot see into. That is where the bridge letter comes in.

Bridge letters: covering the gap

A bridge letter, sometimes called a gap letter, is a short statement from the vendor's management. It covers the time between the end of the last report period and today, and it says whether there have been material changes to the system or its controls. It is not audited and it carries management's signature, not the CPA firm's.

Banks generally accept a bridge letter for a gap of a few months. Beyond that, they start asking when the next report will be issued. Have the letter ready before the request arrives, dated and signed, and refresh it quarterly. Our guide to writing a SOC 2 bridge letter includes what to put in it.

Subservice organizations and the carve-out method

Almost every SaaS vendor relies on a cloud provider, and most SOC 2 reports use the carve-out method for it. That means the cloud provider's controls are excluded from your report, and the report lists the controls you expect the provider to operate, called complementary subservice organization controls.

A careful analyst then asks two questions. Has the vendor obtained and reviewed the subservice organization's own report? And are there other subservice organizations, such as a payment processor, a support platform or a data warehouse, that touch bank data but were not listed? A missing entry here is a common finding in bank reviews. The mechanics are covered in our guide to SOC 2 subservice organizations.

CUECs: what the bank has to do

Complementary user entity controls are the controls the vendor expects its customers to operate. Typical examples are managing their own user accounts, enforcing single sign-on on their side, reviewing their users' access, and protecting their API credentials.

Banks read this section closely because each CUEC becomes an internal task for them. A short, specific list that describes reality is easy to accept. A long list that shifts security work onto the customer gets pushed back during contract negotiation. The guide to complementary user entity controls shows how to write them so a reviewer can act on them.

Exceptions: how banks read them

An exception is a test where the auditor found a control did not operate as described for one or more samples. Exceptions are normal. Many reports have a few, and a clean opinion can still contain them.

What an analyst wants to know is where the exception sits and what happened next:

• Location. Exceptions in logical access, change management or security monitoring weigh more than one in, say, a training record.
• Pattern. One missed sample out of forty reads as a lapse. Repeated exceptions in the same control read as a control that does not work.
• Management's response. A response that names the cause, the fix and the date reads as a functioning programme. A response that says nothing reads as indifference.

Expect the bank to send a question for every exception that matters to them, and sometimes to write a remediation commitment into the contract. For how exceptions are classified and described, see SOC 2 exceptions: what they mean.

What else comes with the SOC 2 request

The SOC 2 report is rarely the only document. A bank reviewing a fintech vendor commonly asks for:

• A recent independent penetration test with remediation status.
• A security questionnaire, often the bank's own, sometimes a standard one.
• Business continuity and disaster recovery plans with evidence of a test.
• An incident notification commitment in the contract, with a clock you can meet.
• A list of subcontractors and where data is stored.
• Proof of cyber insurance.

Sending the report, bridge letter, pentest summary and subprocessor list together, before they are requested one by one, can take weeks off a bank review. For what fintechs in particular need to prepare, our step-by-step guide on how to get SOC 2 for a fintech company covers sector-specific gaps.

What to do if you do not have a SOC 2 report yet

Bank partners will sometimes proceed without one, with conditions. The usual package is a completed security questionnaire, a penetration test report, a documented readiness assessment showing where you stand, and a contractual commitment to deliver a report by a stated date. Be honest about the date. A Type I report commonly takes a few months to reach, and a Type II adds an observation window of three to twelve months on top.

Common questions about how banks review SOC 2 reports

Do banks accept a SOC 2 Type I report from a vendor?

Some do, usually for a first contract and only alongside a plan to deliver a Type II. A Type I shows controls were designed properly on one date, while a Type II shows they operated over a period, which is what most bank third-party risk teams want for anything handling customer or transaction data.

What is a bridge letter and when does a bank ask for one?

A bridge letter is a signed statement from the vendor's management covering the time between the end of the last SOC 2 period and today, confirming whether there were material changes to the system or controls. Banks ask for it whenever the report period ended before the review date. It is not audited.

Will exceptions in a SOC 2 report stop a bank from signing?

Usually not on their own. Analysts look at which controls the exceptions affect, whether they repeat, and how management responded. Exceptions in access control, change management or monitoring with no stated fix generate follow-up questions and sometimes a contractual remediation commitment, but a clean opinion with minor, explained exceptions is common.

What are CUECs in a SOC 2 report?

Complementary user entity controls are controls the vendor's customers must operate for the vendor's controls to achieve their objectives, such as managing their own users or protecting API keys. A bank reads them as a list of tasks it will inherit, so specific, realistic CUECs are accepted far more easily than broad ones.

Why does the bank want the cloud provider's SOC 2 report as well?

If your report carves out the cloud provider as a subservice organization, its controls are not covered by your auditor's testing. The bank wants evidence that you obtain and review that provider's own report each year, and that every subservice organization handling its data is listed.