Why banks ask for a SOC 2 and what it does not settle
When a bank prospect asks for a SOC 2 report during due diligence, the vendor should understand that the 2023 US interagency guidance on third-party relationships (88 FR 37920) says a bank may consider reviewing a third party's SOC reports as part of that review. The report is one input the bank weighs, not a pass or fail result. Banks do not certify vendors, and a clean report does not decide whether a relationship is acceptable. The bank still assesses the activity the vendor performs, the data involved and the risk that the vendor's controls leave open.
How much weight a report carries depends on its details. The same guidance says a bank may consider whether the scope and results of the SOC reports are relevant to the activity performed, and may decide that more scrutiny is needed when they are not. Before sending a report, check the report type (Type 1 describes control design at a point in time, Type 2 adds operating effectiveness over a period), whether the system in scope matches the service the bank is buying, the period covered, and every exception the auditor noted. A bank reviewer will read those exceptions first, so the vendor should be ready to explain each one, including what changed afterward.
The roles also need to stay clear in this conversation. The vendor owns its controls and the statements it makes about them. An implementation partner such as DeployOpen can prepare systems, controls and evidence for the examination, but it does not issue reports or opinions. Only an independent CPA firm can issue a SOC 2 report. Vendors should avoid promising a bank an outcome before the auditor's fieldwork is finished, and should confirm with the CPA firm which system description and trust services categories the report will carry.
Which SOC 2 report type a bank will expect to see
When a bank onboards a new SaaS vendor, its due diligence team typically asks what independent assurance exists and how current it is. The US interagency guidance on third-party relationships says a bank may consider reviewing a third party's SOC reports during due diligence and may consider whether the scope and results of those reports are relevant to the activity the vendor performs. A Type 1 report describes the system and the design of controls as of a date, so it shows what the vendor built but not whether the controls worked over time. A Type 2 report adds an opinion on operating effectiveness over a period, which is usually the stronger signal for a bank.
- Report on file: The bank will ask for the most recent SOC 2 report and the date and period it covers.
- Scope match: Reviewers check whether the in-scope systems and categories match the service the bank will use.
- Exceptions: Any deviations the auditor noted are read closely, along with management's responses.
- Subservice organizations: Reviewers look at how cloud and other providers are carved out and whether their reports were reviewed.
- Contract terms: The bank may ask the vendor to commit in writing to delivering future reports.
Check whether the report's scope, period and categories match the exact product and hosting model the bank will buy.
A vendor in its first year may have a Type 1 report and no completed observation period. Banks often accept this as a starting point, but they will treat it as a snapshot rather than evidence of sustained control operation. The vendor's job is to be clear about what the report covers, what it does not cover, and when the Type 2 work will start. The timing of the Type 2 observation period is a decision the vendor makes with its auditor, and the bank will want to see that the date is committed in writing rather than implied.
- Type 1 as a snapshot: The bank will read the report as proof of design as of a date, and will likely ask how the vendor's controls have run since then.
- Bridge documentation: Banks may ask for a bridge letter or management statement covering the gap between the report date and the request date.
- Interim evidence: Vulnerability scan results, penetration test reports and access review records can help show control activity while the observation period runs.
- Remediation plan: Any open design gaps identified in the Type 1 should have owners and target dates.
- Compensating assurances: Some banks accept independent certifications, such as ISO-based reports, in the interim. Confirm acceptance with each bank's third-party risk team.
Before sending a Type 1 to a bank, confirm what the bank's policy accepts for a vendor without a completed Type 2.
At renewal, the bank usually expects a current Type 2 report that covers the most recent period, with the next report scheduled. Banks commonly ask that contracts specify the types and frequency of audit reports the bank is entitled to receive, so renewal is often when the vendor learns whether its existing report schedule satisfies the contract. A late or missing report can trigger extra scrutiny, and changes in scope or systems since the last period may require the bank to reassess relevance.
- Current period: The bank will check that the report period ends recently enough to satisfy its own review cycle.
- Change disclosure: Material changes to hosting, subservice providers, or the in-scope product since the last report should be explained.
- Exceptions trend: Reviewers compare exceptions to the prior report to see whether issues were resolved.
- Report delivery: Confirm the contract's delivery deadline and who receives the report.
- Other assessments: Penetration test reports and other independent assessments may be requested alongside the SOC 2.
Confirm the report period, scope changes and delivery dates against the renewal clauses before the bank's review begins.
Contract clauses on report types and frequency
The 2023 interagency guidance suggests that a bank's contract with a third party specify which audit reports, such as SOC reports, the bank is entitled to receive and how often. The cards below cover the clauses a SaaS vendor should expect to negotiate and the facts to confirm before signing.
Report type and scope
The contract should name the report the bank expects, such as a SOC 2 Type 2 covering the Security category and any additional categories in scope, rather than a generic promise of 'a SOC report.' Confirm whether the bank wants the full report, a SOC 3 general use report, or both. Check that the system described in the report matches the service the bank actually buys, including hosted components and support access. Ask whether the auditor is an independent CPA firm and whether the report period covers the bank's contract term.
Delivery frequency
Frequency clauses set how often the vendor must deliver a new report after each examination period. A SOC 2 Type 2 is issued for a period of operating effectiveness, so the contract should tie delivery to the issuance of each report, not to a calendar date the audit firm cannot control. Agree a deadline for delivery after the report is issued, and confirm who pays for extra copies or interim reviews. Vendors should check that their audit calendar can meet the bank's required cadence.
Bridge letters for gaps
A bridge letter covers the period between the end of the last report's examination window and the date the bank is reviewing the vendor. Without one, a bank may hold a gap in its third-party review. The contract should say whether the vendor provides a bridge letter, how far it must extend, and who signs it. Confirm that management, not the auditor, prepares and signs the bridge letter, and that the vendor can state any known changes to controls during the gap.
Notice of qualified opinions
A qualified opinion or a set of exceptions in a SOC 2 report can change how a bank reads the vendor's controls. The contract should require prompt written notice when an exception is found, when the auditor issues a qualified opinion, or when the vendor expects one. Define the notice window and the remediation plan the vendor must provide. Ask whether the bank can require a corrective action plan with dates, since the 2023 guidance suggests the bank may consider whether the scope and results of SOC reports call for more scrutiny of the third party.
Scope and system changes
A report describes a system as it existed during the examination. Acquisitions, new hosting regions, a changed subservice provider or a new product module can make the report less relevant to the activity the bank buys. The contract should require notice of material scope or system changes and say whether the vendor must extend the report scope or commission a new examination. Confirm how the vendor will tell the bank whether the existing report still reflects the service in use.
Subservice organization reports
Most SaaS vendors run on a cloud provider, a database host or an identity service, and those providers' controls form part of the vendor's own control environment. The contract should state whether the bank receives the subservice organizations' SOC reports, how the vendor carves them out or includes them, and how the vendor monitors their results. Vendors should confirm they hold current reports from each material subservice provider and can pass them on, subject to the provider's own distribution terms.
What the September 2026 proposed guidance changes
The most important change for a SaaS vendor is that the September 2026 proposals would replace the 2023 interagency guidance on third-party relationships. In September 2026 the OCC, Federal Reserve, FDIC and NCUA proposed third-party risk management guidance that would supersede the 2023 version, with comments due November 16, 2026 (Federal Register proposal for the interagency guidance). Until a final version is issued, the 2023 text still describes how banks are expected to assess you. Vendors should not assume the proposal's wording will carry over unchanged, so the first step is to read both documents side by side and note any change to how reports, audit rights or due diligence are described.
The Federal Reserve also proposed a separate guide for traditional community banks in the same month. It suggests that a bank review independent assessment reports such as SOC 2 and ISO reports when it assesses a cybersecurity vendor, and it lists SSAE 18 SOC reports among the assessments a bank may rely on for operational resilience. It also lists penetration testing reports alongside SOC reports, audit reports and industry assessments such as PCI DSS, NIST and ISO as independent evidence a bank may use. For a vendor, this means your SOC 2 may be read next to a penetration test and an ISO certificate, so the scope and dates of each should line up. Check whether your report's system description covers the services a community bank would actually use, and be ready to explain any gap in the penetration test scope.
Neither proposal is final, and the text may change before adoption. Do not amend contracts, promise specific report types or timelines, or redraw your trust page based on the proposals alone. Confirm the final wording with the bank's third-party risk team, and with your own counsel, once the agencies publish their final guidance. Until then, keep the 2023 contract clauses on report types and frequency as your working baseline and record which version of the guidance your bank customers say they follow.
Other assessments banks accept alongside SOC 2
A SOC 2 report is one of several independent assessments a bank may review. The proposed community bank guide lists penetration test reports, SSAE 18 SOC reports, audit reports and industry assessments such as PCI DSS, NIST and ISO as evidence a bank may rely on. Each one answers a different question, and the bank decides which ones are relevant to the service it buys.
Penetration test reports
A penetration test report shows that an independent tester attempted to break into the systems a vendor operates, within a defined scope and date range. It answers a narrower question than SOC 2: whether known weaknesses in the tested assets could be exploited at that time. Check the scope, the test date, whether the tested application matches the product the bank will use, and whether the findings were retested. Ask the vendor whether the report covers the production environment or a staging copy.
SSAE 18 SOC reports
SSAE 18 is the attestation standard under which SOC 1 and SOC 2 reports are issued, so a SOC 2 report is one kind of SSAE 18 SOC report. Banks may ask for a SOC 1 when a vendor's services affect financial reporting, which SOC 2 does not cover. A vendor should confirm which report types it holds, whether a Type 1 or Type 2 applies, and whether the period covered matches the bank's review cycle.
Audit reports
Audit reports are reviews performed by an independent party against a defined standard or internal objective, and they can cover areas a SOC 2 does not address, such as financial controls or specific contractual obligations. Banks look at who performed the audit, its scope, and whether its findings were closed. A vendor should confirm whether the audit was performed by an independent auditor or by an internal team, since the bank's policy may treat the two differently.
PCI DSS assessments
A PCI DSS assessment is relevant when a vendor's service stores, processes or transmits cardholder data, or could affect the security of the cardholder data environment. It is validated by a qualified assessor and tied to a defined scope of systems. Banks use it to judge payment-related exposure, but it does not cover the rest of the vendor's environment. Ask whether the vendor's attestation of compliance covers the service the bank will use and whether it is current.
NIST and ISO assessments
NIST-aligned and ISO/IEC 27001 assessments show that a vendor's security program was reviewed against a recognized control set. An ISO 27001 certificate comes from an accredited certification body and is limited to the scope stated on the certificate. A NIST-based assessment may be a self-assessment or third-party review, so the bank will ask who performed it. Confirm the certificate scope, the issuing body and the certificate expiry date before relying on either.
SOC 2 or SOC 3: which document to share with a bank
This table compares a SOC 2 report and a SOC 3 report on audience, level of detail and distribution. Read it as a sharing decision: the bank's due diligence team usually needs the SOC 2 under NDA, while the SOC 3 suits public-facing trust material.
| Attribute | SOC 2 report | SOC 3 report |
|---|---|---|
| Primary audience | Customers, prospects and their auditors who need detail on controls and testing | General public, prospects in early evaluation and anyone checking the trust page |
| Level of detail | Full system description, control criteria, tests performed and results, including exceptions | Covers the same Trust Services Criteria categories in less detail, without the test results |
| Distribution | Use is generally restricted, so share it under NDA with the bank | Use and distribution are not restricted, so it can be published |
| Typical use with a bank | Due diligence, contract review and assessing whether scope fits the activity | Public trust page or early-stage reassurance before the NDA stage |
| Can it replace the other? | Does not replace a SOC 3 for public posting | Does not give a bank enough detail for third-party risk review |
| What to confirm with the bank | Which report type, period and categories the bank expects under the contract | Whether the bank accepts a SOC 3 as an interim document at all |
How a SaaS vendor prepares for bank due diligence
This sequence turns a bank's third-party questionnaire and contract demands into a SOC 2 package the bank can review, with the scope, system description, control evidence and renewal plan agreed before the report is shared.
Confirm the bank's third-party requirements
Start by asking the bank's vendor management or third-party risk team which reports it expects, which services and systems it wants covered, and how often it wants updated reports. The 2023 US interagency guidance says a bank may consider SOC reports during due diligence and may suggest that contracts specify the types and frequency of audit reports a bank is entitled to receive. Ask for the contract clause or security addendum in writing. The output is a short requirements list that names the report type, the in-scope service, the delivery frequency and any other assessments the bank will accept. Confirm the list with your legal and sales owners before you pick a report type.
Choose the report type and scope
Decide whether the bank needs a Type 1 or Type 2 report, which trust services categories the scope includes, and which hosted components, support processes and subservice organizations sit inside the boundary. A Type 2 report covers operating effectiveness over a period, so banks often ask for it when they assess ongoing controls. Record the decision and the reason for it in a scope memo that your CPA firm reviews. The output is an agreed scope statement that matches the systems the bank will actually use, so the report does not leave a gap the bank has to chase.
Prepare the system description and control matrix
Work with your examination partner to write the system description under the AICPA description criteria and to map each in-scope control to the relevant common criteria and any additional criteria. The control matrix should name the owner, the frequency and the evidence for each control so the auditor can test it. Your partner can prepare systems, controls and evidence, but management owns the description and the controls, and the independent CPA firm issues the report. The output is a reviewed system description and control matrix that a bank reviewer can follow without a call to your engineering team.
Arrange the NDA and report delivery
SOC 2 reports are generally restricted in use, so most vendors require the bank to sign a non-disclosure agreement before receiving the full report. Agree on the delivery route, the named recipients and whether the bank may share the report with its examiners or other parties. If the bank only needs a broad overview for a first review, a SOC 3 report is a general use report that can be freely distributed, and it can be posted publicly. The output is a signed NDA on file, a delivery record that shows who received the report and when, and a clear answer on what the bank may share internally.
Prepare the bridge letter and exception responses
When the report period ends before the bank's review date, prepare a bridge letter from management covering the gap between the period end and the letter date, and confirm with the bank whether it accepts that approach. Read the auditor's exceptions carefully, then write a management response for each one that states the root cause, the corrective action, the owner and the evidence that the fix works. Ask the auditor to confirm wording that you plan to use publicly. The output is a bridge letter and a set of exception responses that the bank's reviewer can read alongside the report without finding unexplained issues.
Assess other assessments the bank may accept
Recent proposed Federal Reserve guidance for community banks lists independent assessments a bank may rely on, including penetration test reports and industry assessments such as ISO and NIST-based reviews. Compare these with the bank's requirements and decide which additional evidence you can provide without overstating what the SOC 2 covers. Confirm with the bank which items it will accept. The output is a documented list of supplementary evidence, such as penetration test reports from an independent tester, each with its date and scope, so the bank can see where the SOC 2 stops and other evidence begins.
Track renewal dates and contract obligations
Enter the report period end, the bridge letter cut-off, the date each updated report is due under the contract, and any notice requirement for changes to the system or to subservice organizations. Assign an owner for each date and review the calendar at least once a quarter with your compliance lead. When the platform, hosting provider or scope changes, tell the bank as your contract requires and check whether the report needs an update. The output is a renewal register that shows when each report is due, who sends it, and which changes must be disclosed to the bank before the next review.
Questions vendors ask before a bank's security review
Will a bank accept a SOC 2 Type 1 while the Type 2 observation period is still running?
Sometimes, but it depends on the bank's own third-party risk program, and you should not assume it. A Type 1 report describes your system and the suitability of your control design as of a single date. It does not test whether those controls worked over a period, so a bank reviewing a higher-risk activity will usually ask for the Type 2 as well. The US interagency guidance on third-party relationships says a bank may consider the scope and results of SOC reports and may ask for more scrutiny where they are not relevant to the activity. Ask the bank early which report type it needs, and confirm with your CPA firm when the observation period will end and what the Type 1 will and will not show.
- Confirm the report type and period the bank's contract template expects.
- Confirm the report date and the controls covered in the Type 1.
- Agree a bridge letter approach with the bank in writing.
Does a SOC 2 report alone satisfy a bank's third-party due diligence?
No. A SOC 2 is one input to due diligence, not a replacement for it. The 2023 interagency guidance says a bank may consider reviewing SOC reports and independent certifications, but it also expects the bank to judge whether the scope of the report matches the service it buys. Banks commonly also ask for penetration test results, security questionnaire answers, contract terms on audit rights and breach notification, and information about subcontractors. A report that excludes the system or services the bank uses will not answer the question, so check the system description and carved-out vendors before you send it.
Who pays for the SOC 2 audit when a bank asks for one?
The vendor pays for the examination, because the examined organization engages the CPA firm and owns the report. The bank does not normally fund it, although it may ask for report access as a contract term. Cost components usually include the CPA firm's examination fees, readiness work, tooling, and internal staff time. The one-time work is the first readiness effort and the first examination. Recurring costs are the annual or periodic examination, control monitoring, and evidence collection. Ask any CPA firm for a written engagement letter that separates examination fees from readiness services, and ask how the scope of Type 1 and Type 2 changes the price.
What does a DeployOpen engagement cover for a SOC 2 vendor?
DeployOpen prepares systems, controls and evidence for the examination. It can plan and implement self-hosted open-source platforms inside your own infrastructure, configure access, logging, backup and change controls, and document how they run. It can also help you assemble the control matrix and evidence packs the CPA firm requests. DeployOpen does not issue SOC 2 reports, opinions or attestations; only the independent CPA firm does that. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, so confirm which systems and criteria are in scope before you sign.
How long does the work take, and what must the vendor supply?
The timeline depends on how many systems are in scope, how mature your current controls are, and how quickly the CPA firm can test them. There is no supplied figure to quote here, so ask your CPA firm and implementation partner for a schedule tied to the defined scope. On your side, expect to supply an accurate system description, asset and user inventories, policies, access review records, change tickets, vendor lists, and access to the systems being tested. Banks also ask for the report, bridge letter, penetration test results and your answers to their questionnaire, so plan those deliverables in the same schedule.
What should we confirm with the bank and the CPA firm before we start?
Confirm three things in writing before work starts. First, ask the bank which report type, period, and scope its contract and due diligence require, including whether it accepts a Type 1 in the interim. Second, ask the CPA firm which criteria the examination will cover, whether the bank's requirements are within that scope, and how it will handle carved-out subservice organizations. Third, check whether the bank will accept a SOC 3 for general distribution, noting that use of a SOC 2 report is generally restricted while a SOC 3 can be freely distributed. Proposed September 2026 guidance from the federal banking agencies would replace the 2023 guidance, so confirm which version applies to the bank's review.
How DeployOpen prepares your systems and evidence for a bank review
DeployOpen works as an implementation partner for organizations that run self-hosted open-source platforms in their own infrastructure, including the cloud accounts, data centers or air-gapped networks the platform lives in. Before any work starts, we agree the system boundary in writing: which components the bank's data touches, which parts are operated by the vendor, which are operated by the customer, and which sit with a cloud provider whose own SOC reports may be carved out. A boundary agreed on paper is the input a CPA firm will test against, so it is the first thing to settle.
Once the boundary is set, DeployOpen prepares the controls and the evidence that show them operating. That typically means configuring access management, logging, change records and backup settings in the environment, mapping each control to the criteria it supports, and collecting the artifacts an examiner will ask for. We hand over the control documentation, runbooks and evidence folders so the vendor's own team can keep them current between reports. DeployOpen does not issue SOC 2 reports, attestations or certifications. Only an independent CPA firm can examine the system and issue an opinion, and the vendor should confirm the firm's independence and its engagement terms directly.
Engagements are fixed-scope. The scope, deliverables and timeline are agreed in writing before work begins, and any change to the boundary or the platform is handled as a written variation. When you request a quote, ask for the components in scope, which controls DeployOpen will prepare versus which the vendor's staff must run, what documentation is handed over, and what support is included after the examination. Ongoing support and retainers are available separately, so you can decide whether to keep the evidence pipeline running between audit periods.
