Does a fintech need SOC 2 when selling to banks?
When a bank or a contract asks for a SOC 2 report, the honest answer is that SOC 2 is a voluntary attestation, not a legal license or a mandate from the FTC. The bank may use the report during third-party due diligence, and US banking agencies' 2023 interagency guidance on third-party relationships says a bank may consider reviewing a third party's SOC reports as part of that work (Federal Register notice on the 2023 interagency guidance). An independent CPA firm issues the report, while your company owns and operates its controls. An implementation partner can prepare systems, configurations and evidence, but it cannot sign or issue the report. Cost, timeline and scope depend on what is actually examined: which Trust Services Categories you include beyond security, which systems hold or touch customer data, which regulated activities your products perform, and whether the report is Type 1 or Type 2. Ask the bank exactly which report type and categories it wants, and whether it needs a bridge letter for the gap between the report period and today. Confirm these with the bank and the CPA firm before anyone prices the work, because a broader scope changes the sampling, the evidence volume and the fees. A SOC 2 does not discharge your own regulatory duties. If your company is a non-bank financial company under FTC jurisdiction, the FTC Safeguards Rule requires you to run multi-factor authentication for anyone accessing customer information, encrypt that information, complete annual penetration testing and maintain the other safeguards in the rule, and the auditor will not test those duties for you (FTC Safeguards Rule guidance). If you accept or process card data, PCI DSS may also apply to you as a service provider, even when you never store card numbers. Map each obligation to its own evidence before you decide what the SOC 2 must cover.
What a fintech SOC 2 costs and who is paid
This table compares each cost component of a fintech SOC 2 by who is paid, whether the cost is one-time or recurring, and what moves it up or down. Use it to build a request for quote, since no fixed prices are published and each figure depends on the written scope. The main takeaway is that the CPA firm's fee is only one line, and the Safeguards Rule testing and staff time often matter as much.
| Cost component | Who is paid | One-time or recurring, and what drives it |
|---|---|---|
| CPA firm readiness assessment (optional) | The CPA firm | One-time. Drivers: number of systems in scope, whether the firm reviews policies before the observation period starts, and how many control gaps need remediation. |
| CPA firm Type 2 examination | The CPA firm | Recurring, usually annually. Drivers: number of trust services categories, number of subservice organizations, sample sizes and the length of the observation period. Ask for the fee basis in writing. |
| Implementation partner work on systems and evidence | The implementation partner | One-time for setup, with possible recurring retainer for upkeep. Drivers: number of environments, degree of existing automation and the number of controls needing new evidence pipelines. Require a fixed-scope written statement of work. |
| Security tooling and hosting | Software vendors, cloud providers or the company's own infrastructure | Recurring. Drivers: user counts, log retention periods, and whether tools are self-hosted or subscribed. Confirm which tools the auditor will accept as evidence sources. |
| Penetration testing required by the Safeguards Rule | Independent testing firm or internal qualified testers | Recurring. Drivers: scope of applications and networks, number of test cycles per year and remediation retesting. Confirm scope matches the Safeguards Rule testing duties. |
| Internal staff time for policies, access reviews and vendor oversight | The company's own payroll | Recurring. Drivers: headcount, number of vendors under review, frequency of access reviews and how well evidence is collected automatically. |
| Bridge letters and interim updates | The company's own staff, sometimes with the CPA firm | Recurring when needed. Drivers: gap between report period end and the date a bank or customer asks for coverage, and how many customers request letters. |
| Bank and customer due diligence support | The company's own staff and sales or legal teams | Recurring. Drivers: number of bank customers, depth of security questionnaires and contract negotiations on provider oversight duties. |
What makes a fintech SOC 2 more expensive or longer
Most of the cost and calendar time in a fintech SOC 2 comes from how much is in scope, how many parties touch customer data, and how ready the evidence is when the observation period starts. The cards below cover the decisions that move those three factors, and each one is something a company can narrow, document or settle before paying for fieldwork.
Systems and cloud accounts in scope
Every production system, cloud account, database and admin console that stores, processes or can reach customer data is generally part of the system description and must be tested. Each extra account adds configuration samples, access reviews and change records for the auditor to pull. Before fieldwork, list every account, mark which ones touch customer data, and separate shared services such as logging from products that handle money. A narrower, well-documented boundary is usually cheaper to test than a broad one left vague.
Regulated products and data flows
Each product line, such as payments, lending or a card program, adds its own flows of customer data, its own approvals and its own exceptions to explain. A data flow diagram that shows where account numbers, identity documents and transaction records enter, move and leave the environment is the first thing an assessor will ask for. Companies that launch products mid-period should expect the auditor to test the new product from its launch date, so timing product releases against the observation window matters.
Adding Confidentiality or Availability
Security is always in scope, but adding Confidentiality or Availability brings criteria for identifying and disposing of confidential information (C1) or for capacity, backup and recovery testing (A1). Bank customers often ask for these categories because they care about outages and data disposal. Each category adds its own control set and evidence, such as disposal certificates or recovery test results. Decide on categories with the customers who will read the report, and add them before the period starts rather than midway through it.
Third-party processors and subservice organizations
Payment rails, KYC and identity vendors, cloud providers and fraud tools can each be carved out of the report or included through their own SOC reports. Carving out a vendor means the auditor does not test it, but customers will still expect you to monitor it under the vendor management criteria in CC9. Collect each provider's current SOC report or bridge letter early, record the complementary user entity controls you depend on, and note any gaps in those reports before the auditor finds them.
Evidence maturity from tickets and logs
Auditors test controls by sampling evidence from the period, so a team that already runs access reviews, change tickets and vulnerability scans in a ticketing or logging system spends far less time reconstructing records. Teams that rely on chat messages, spreadsheets or memory tend to pay for extra sampling, longer fieldwork and more exceptions. Before the period starts, run each control once in the way it will be evidenced, confirm that the records are complete and retained, and check that the same people approve and review consistently.
Multiple locations and jurisdictions
Operations spread across entities, offices or countries can add controls for each location, separate access reviews, local data residency rules and different personnel records. Multiple jurisdictions also raise questions about which regulations customers and regulators expect the report to address, such as GDPR for European customers. Confirm early which entities and locations are inside the boundary of the system description, whether each has its own controls or relies on a central team, and how personnel and access records are kept for each.
How banks review a fintech vendor's SOC 2
The 2023 interagency guidance on third-party relationships says a bank may consider reviewing a third party's SOC reports and independent certifications during due diligence, as part of a broader risk assessment (Federal Register notice). A SOC 2 is one input. The bank still decides whether the fintech's controls fit the risk of the service it provides, and it documents that decision.
- Report period: Confirm the Type 2 observation window covers recent months and that the report date is current. A Type 1 shows design as of one date and does not show operation over time.
- Exceptions: Read every exception in the auditor's test results, its root cause and the remediation date. Repeated exceptions in access reviews or change management matter more than a single isolated one.
- Complementary user entity controls: Map each listed control to what the bank must do itself, such as reviewing its own user access or approving its own configuration choices.
- Subservice carve-outs: Identify which cloud, hosting or payment providers were carved out and whether their own SOC reports are available for review.
- Bridge letter: Ask for one when the report period ends well before the bank's review date, so the fintech can attest to controls in the gap.
Before signing, check that the scope covers the specific product and environment the bank will use, not only the company name.
A proposed Federal Reserve guide for community banks, dated September 2026 and published at 91 FR 58438, suggests reviewing independent assessment reports such as SOC 2 and ISO reports when assessing a cybersecurity vendor (Federal Register notice). Because the guide is proposed, the community bank should confirm its status before relying on it. Smaller banks often have few staff for technical review, so the report often carries more weight than it would at a larger institution.
- Scope match: Confirm the systems in the report are the ones that will hold or touch the bank's data, including any hosting environment.
- Security and availability criteria: Check whether the report includes the criteria that matter for the service, such as availability for a service the bank depends on operationally.
- Issuing firm: Confirm the report was issued by an independent CPA firm and that the auditor's name and report date are on the document.
- Gap analysis: Compare the report against the bank's own questionnaire, and send targeted follow-up questions for topics the report does not cover.
- Ongoing review: Calendar the next report date and request it when it is issued rather than waiting for the contract to renew.
Before relying on the report, confirm with the bank's regulator or examiner how the proposed guide will apply to the bank's own program.
The fintech's own team builds the trust package that banks and community banks will review. The package should make the report easy to read and show where the report stops. Good preparation reduces back-and-forth during due diligence and shows the bank that management understands its own controls. The organization owns its controls. An implementation partner can help assemble evidence, and only the independent CPA firm issues the report.
- Report summary: Provide a short description of the system, its boundaries and the report period, so reviewers do not infer scope.
- Exception log: Prepare a written explanation for each exception, including the corrective action and its status, before the bank asks.
- Complementary controls list: Publish the controls the bank must operate itself, with an owner for each in your customer documentation.
- Subservice provider list: Name each carved-out provider, its service and where its own SOC report can be obtained.
- Bridge letter process: Agree with your CPA firm in advance how a bridge letter will be requested, who signs it and what period it covers.
Before sending the package, confirm with your auditor that every statement in it matches the report wording exactly.
When PCI DSS applies alongside SOC 2
PCI DSS applies to a service provider that can affect the security of payment account data, even if it never stores, processes or transmits that data. The PCI Security Standards Council's guidance covers providers with access to a customer's cardholder data environment (CDE) and providers that meet a PCI DSS requirement on a customer's behalf. For a fintech that hosts a payment flow, manages tokenization, administers the CDE's identity provider or runs logging for a merchant's card systems, the question is not whether the company touches card numbers but whether its access could affect them. Start by listing every system, administrator account and integration that reaches the CDE, then check each against the PCI SSC FAQ on service providers that can affect security and the PCI SSC FAQ on scope for those providers.
Scoping decides the size of the PCI effort. A provider in scope needs its own PCI validation, separate from the SOC 2 examination. That validation produces its own evidence and report, and for many service providers it is completed through the PCI DSS v4.0 Self-Assessment Questionnaire D for Service Providers. SOC 2 and PCI DSS overlap on access control, multi-factor authentication for administrators, logging and monitoring, vulnerability management and change control, so one set of evidence can often serve both. They are not interchangeable, though. A SOC 2 report judges controls against the Trust Services Criteria chosen for the engagement, while PCI validation tests specific PCI DSS requirements against cardholder data. A clean SOC 2 does not show that a provider meets a PCI requirement, and a PCI attestation does not satisfy a SOC 2 criterion that was never tested.
Validation levels and the reporting route are set by the card brands and the acquiring bank, not by the PCI Standards Council or the SOC 2 auditor. Ask your acquirer or each card brand in writing which validation applies to your company as a service provider, what the deadline and submission path are, and whether a qualified security assessor is required. Ask your CPA firm to map its SOC 2 testing against the PCI requirements you are scoped for so that duplicated sampling is avoided, but confirm with the acquirer that the mapping is accepted before relying on it.
How a fintech moves from readiness to a SOC 2 report
The sequence runs from agreeing scope with the bank or customer to a CPA firm issuing the report, with each phase closing on a named output. Timing for each phase depends on the CPA firm and the customer's deadline, so confirm both before work starts.
Confirm report type and scope with the customer
Before any engineering work, agree with the bank or fintech customer which report they need, whether a Type 1 or Type 2, and which Trust Services Criteria categories belong in scope. Security is always covered by the common criteria CC1 to CC9, while availability, confidentiality, processing integrity and privacy are added only when the customer or the business case requires them. Confirm also whether the customer expects a SOC 2 alone or a SOC 2 read alongside its own third-party due diligence. The output is a written scope note signed off by the customer and the CPA firm, which becomes the reference for every later decision.
Set the system description boundary
Define the system the report covers: the production services, the cloud accounts and regions, the people and teams who operate them, the data flows that carry customer information, and the subservice organizations such as cloud hosts and payment or identity providers. The management description of the system is prepared against the AICPA's description criteria, so the boundary must be specific enough for an assessor to test. The output is a draft system description and a list of subservice organizations, reviewed by the CPA firm before controls are mapped to it.
Close control and FTC Safeguards gaps
Map each in-scope criterion to a control the company operates, then compare the current state with what the FTC Safeguards Rule expects where it applies: multi-factor authentication for anyone accessing customer information, encryption of customer information at rest and in transit, annual penetration testing, vulnerability assessments, service provider selection and monitoring, and a designated Qualified Individual. Remediate gaps in the self-hosted platforms, identity, logging and change processes, and record each fix with a date and an owner. The output is a control matrix with every gap closed or accepted in writing by management.
Collect evidence across the observation period
For a Type 2 report, controls must run over the observation period, so evidence accumulates from the first day of that period rather than being assembled at the end. Typical evidence includes access reviews, joiner and leaver records, change tickets with approvals, vulnerability scan results, backup restore tests, incident records and vendor reviews. Self-hosted tools such as log platforms, configuration baselines and infrastructure code can generate much of this automatically. The output is an evidence library indexed by control and period, checked periodically so gaps appear while they can still be fixed.
Complete the CPA firm's fieldwork and sampling
The CPA firm tests the design of each control and, for a Type 2, its operating effectiveness across the period. Expect requests for populations, such as a complete list of users with production access, and the firm will select samples from them and examine the underlying records. Exceptions found during sampling are documented and discussed with management, and each one may need a root cause, a remediation and sometimes a qualified or modified opinion. The output is the auditor's working papers and a list of exceptions that management has reviewed and responded to in writing.
Sign the management representation letter
Management provides written representations to the service auditor, confirming the accuracy of the system description, the completeness of the information provided, the design and operation of controls, and the disclosure of known instances of noncompliance, incidents and subservice organization matters. Because a SOC 2 is an assertion-based examination, these representations are part of the engagement and must be signed by an accountable executive. The output is a signed representation letter dated to match the report period end, which the CPA firm relies on before issuing its opinion.
Receive the report issued by the CPA firm
Only the independent CPA firm issues the SOC 2 report and its opinion. Once fieldwork and the representation letter are complete, the firm issues the report containing the system description, the criteria, the controls, the tests performed and the opinion. The company, and any implementation partner that prepared the systems and evidence, does not issue or alter the report. The output is the final report, which the company can then share under the restrictions that apply to SOC 2 use, with a bridge letter if the customer's review date falls after the report period end.
Who owns controls, evidence and the report
A SOC 2 for a fintech is only as credible as the division of labor behind it. The fintech owns its controls and risk decisions, the implementation partner prepares systems and evidence, and an independent CPA firm alone performs the examination and issues the report.
The fintech owns its controls
Management decides which controls protect customer information, who is the Qualified Individual under the Safeguards program, and which risks are accepted. Those decisions are management's to make and to defend, and a partner cannot make them on the company's behalf. Before work starts, confirm in writing who signs policies, approves exceptions and signs the management assertion.
The FTC Safeguards program
The written information security program required for non-bank financial companies under the FTC Safeguards Rule is the company's document, reflecting its own activities and customer data flows. A partner can help draft and test it, but the fintech must own its scope, its MFA and encryption decisions, and its annual penetration testing. Ask who maintains the program after go-live and who reviews it each year.
Systems, configurations and evidence
An implementation partner can configure self-hosted identity, logging, backup and vulnerability tooling inside the client's cloud accounts or data centers, and prepare the records an examiner samples, such as access reviews and change tickets. This work is delivered within a written, fixed scope with agreed deliverables. Confirm which systems are in scope, who holds administrator credentials and where evidence is stored.
The CPA firm issues the report
Only an independent CPA firm performs the SOC 2 examination and issues the report or opinion. DeployOpen does not issue audit reports, attestations or certifications, and a readiness engagement does not create or imply one. Ask the auditor to confirm its engagement letter, its independence from the readiness work and the report type, Type 1 or Type 2, it will issue.
The bank decides what it accepts
A bank or other customer decides whether a fintech's SOC 2 report, bridge letter or questionnaire answers satisfy its third-party due diligence. US banking agencies say a bank may consider reviewing a provider's SOC reports during due diligence, but acceptance is the bank's call. Ask early which report type, period and complementary controls it expects, and whether PCI DSS evidence is also required.
Questions fintechs ask about SOC 2 and the Safeguards Rule
Does a SOC 2 report satisfy the FTC Safeguards Rule?
No. A SOC 2 report does not satisfy the Safeguards Rule on its own, but it can support parts of it. The Rule is a set of duties the covered company must carry out itself, including a designated Qualified Individual, a written information security program, multi-factor authentication, encryption, and penetration testing and vulnerability scans. A SOC 2 examines whether a service organization's controls meet the Trust Services Criteria over a defined system and period, so it can give evidence for controls such as access management and monitoring. Ask the examiner which Rule duties the report's controls touch and which remain outside the report's scope, and document that mapping yourself.
Is a SOC 2 Type 1 enough for a bank that is reviewing us?
It depends on what the bank asks for, and a Type 1 is often the weaker answer. A Type 1 describes the system and states whether controls were suitably designed as of one date. A Type 2 adds an opinion on operating effectiveness over a period, which is what most due diligence reviews look for because it shows controls worked over time. The US banking agencies' 2023 interagency guidance says a bank may consider a third party's SOC reports during due diligence, and the bank decides what is sufficient. Confirm the report type, period and scope with the bank before you start the examination.
How is the work split between our own staff and outside help?
Your staff owns the controls and the evidence, and outside parties provide the examination and, optionally, preparation support. Internal work includes setting policies, running access reviews, approving changes, responding to incidents and operating the systems day to day. Outside help may include a consultant who prepares the control matrix and evidence, and a CPA firm that performs the examination and issues the report. The largest cost drivers are the number of systems in scope, the number of controls to be tested, the length of the observation period and how much evidence already exists. Ask each vendor for a written scope that lists deliverables, responsibilities and assumptions, and compare quotes against the same scope.
Can a fintech prepare for SOC 2 without an outside consultant?
Often yes, if someone on the team has time, security knowledge and authority to change processes. The work includes writing policies, defining system boundaries, mapping controls to the criteria, collecting evidence on a schedule and fixing gaps before the auditor arrives. Teams that struggle usually lack a single owner, rely on manual screenshots, or start evidence collection late. A consultant or fractional security lead can shorten that path, but the auditor cannot prepare the company and remain independent. Use a readiness review or gap assessment to decide what to do in-house. Confirm the scope and any fees in writing before work starts.
How often do we need penetration testing and vulnerability scans?
The Safeguards Rule requires annual penetration testing and vulnerability assessments at least every six months, including system-wide scans, unless continuous monitoring is in place. Those are the FTC's stated minimums for covered companies, and your bank partner may ask for more. Under SOC 2, the examiner tests whether your vulnerability and configuration monitoring operates as you describe, so the frequency you commit to in policy becomes the standard you must meet. Engineers should check which systems are in scope, how findings are tracked to closure, and how exceptions are approved. Test scope and cadence should be written into the statement of work.
When does PCI DSS apply alongside SOC 2 for a payments product?
PCI DSS applies when your product stores, processes or transmits cardholder data, or when it can affect the security of payment account data even if it does not handle that data directly. The PCI Security Standards Council says service providers can fall in scope through access to a customer's cardholder data environment or by performing a PCI DSS requirement on a customer's behalf. SOC 2 does not replace a PCI DSS assessment, and a PCI report does not replace SOC 2. Map your data flows first, then decide which assessment applies to each product. Confirm the validation level and scope with your acquiring bank or a qualified assessor.
How DeployOpen prepares fintech systems and evidence
DeployOpen plans, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the systems that handle customer financial data are ones your organization controls and can show an auditor. For a fintech, the work usually covers the platforms behind the controls a CPA firm will test: identity and access management with multi-factor authentication for anyone reaching customer information, role-based permissions with documented approvals, centralized logging with retention settings that match your policy, encryption for data at rest and in transit, and backup and restore procedures that have been tested rather than assumed. Each setting is recorded as configuration, so the evidence can be exported in the form an examiner asks for.
Engagements are fixed-scope. Before any work starts, you and DeployOpen agree in writing on the systems in scope, the deliverables (such as hardened build baselines, configuration records, runbooks and an evidence index mapped to your control matrix) and the timeline. Decisions that shape the audit, including which trust services categories are in scope and which controls are your own versus a provider's, stay with your management team and your CPA firm. Ongoing vulnerability scanning, penetration testing, platform upgrades and evidence refreshes between examination periods can be added as retainers that run alongside the examination cycle.
DeployOpen does not issue SOC 2 reports, attestations or certifications. Only an independent CPA firm performing the examination can do that, and your organization owns its controls and its management assertion. Hiring DeployOpen does not guarantee a clean opinion, a particular number of exceptions or a set date for the report. Before you sign, ask the CPA firm which evidence formats it accepts and confirm with them that the scope of DeployOpen's work matches the controls you plan to describe in your system description.
