What a bank third party risk review actually asks for

A bank or fintech asks for your SOC 2 report. You send it. Three weeks later a spreadsheet arrives with several hundred questions, a request for your penetration test, your business continuity plan, evidence of your last access review, and a security contact who will get on a call with their risk team. This is normal, it is not a sign anything is wrong, and it is the heaviest vendor diligence in commercial software. Here is what it consists of and what a SOC 2 report does and does not settle.

Why bank diligence is different

Banks do not assess vendors purely because they want to. In June 2023 the Federal Reserve, the FDIC and the OCC issued joint interagency guidance on third party relationships, replacing three separate agency positions with one. It sets expectations across the whole life cycle of a vendor relationship: planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination.

The practical consequence for you is that your buyer’s diligence is not a formality they can waive because they like your product. Their own examiners will look at how they assessed you. That is why the questions keep coming after you have sent the report, and why “we have a SOC 2” ends the conversation with a startup buyer and begins it with a bank.

What the review is actually made of

A questionnaire, usually large. Often the Shared Assessments SIG, sometimes the institution’s own workbook, occasionally both. Hundreds of questions covering areas a SOC 2 report addresses at a summary level and the questionnaire addresses one control at a time.

Your SOC 2 report, read properly. A bank reviewer is one of the few readers who genuinely reads it. They will look at the scope, whether it is Type I or Type II, the observation period, any exceptions in the testing results, the subservice organizations you carved out, and the complementary user entity controls the report says you rely on your own customers to perform.

Artifacts by name. The most recent penetration test, evidence that findings were remediated, your business continuity and disaster recovery plans with evidence of a test, your incident response plan, and proof your access reviews actually run.

Contractual terms. Notification windows after an incident, audit rights, subcontractor approval, data location and return or destruction at termination. These are frequently tighter than anything a regulation imposes on you, and they are negotiated by people who negotiate them constantly.

Continuing obligations. Bank relationships include ongoing monitoring, so the report is not a one time gate. Expect an annual refresh, and expect them to notice if the next report shows a gap in coverage between observation periods.

What a SOC 2 report settles, and what it does not

It settles whether an independent CPA firm examined your controls and what they concluded. That is genuinely valuable and it is the single artifact that shortens the review most.

It does not settle the questionnaire. The workbook still arrives. What changes is whether the answers already exist in a form you can send, or whether somebody reconstructs them under deal pressure while the buyer waits. That difference is usually weeks.

It does not settle the complementary user entity controls. This is the one that catches people. Your report lists controls you assume your customers operate. A bank reviewer reads that list and checks whether their own environment covers it. Separately, every vendor report you collect lists controls that vendor assumes you operate, and if nobody has mapped those to your controls, a reviewer who asks the question will find nothing behind it.

It does not settle a Type I versus Type II expectation. Financial services buyers ask for Type II by name more often than any other sector, because operating effectiveness over a period is what their own examiners expect them to have assessed. A Type I is a legitimate first step and a real checkpoint, but going in expecting it to be the destination is how a deal stalls late.

The order that works

1. Get the questionnaire answers into a reusable form. One well maintained answer set, cross referenced to the evidence behind each answer, beats a heroic effort per deal. This is the single highest return piece of work for a company selling into banks.
2. Map every complementary user entity control from every vendor report you hold to a control on your side, and write down the ones you cannot cover. That map is asked for by name and almost nobody has it.
3. Run the penetration test early enough to remediate. A recent test with open critical findings is worse than an older test with a clean remediation trail.
4. Read your own contractual notification windows and confirm your incident plan can meet the shortest one you have signed.
5. Sequence Type I then Type II deliberately, and tell the buyer the plan rather than letting them discover the report is Type I when they open it.

One honest limit

This is about information security diligence, which is what we do. Financial services firms also carry consumer protection and regulatory obligations that have nothing to do with SOC 2 and everything to do with counsel and compliance specialists in your own sector. We do not advise on those and we will say so plainly rather than guess. Where a security control exists to satisfy one of them, we will build the control around the decision your counsel has already made.

Where we fit

Control and Function runs SOC 2 readiness as a fixed-fee engagement. We are not an audit firm and we do not issue SOC 2 reports: we build the program, prepare the evidence, refer you to a licensed CPA firm, and manage the audit through report issuance. We never assess our own preparation work, and we take nothing from any firm we introduce.

If you are somewhere between “a buyer just sent us a security review” and “we need a report by a deadline,” a 30-minute call will tell you where you actually stand. Book a readiness call or email hello@controlandfunction.com.