Does a SOC 2 report cover PCI DSS?

No. PCI DSS is a standard from the PCI Security Standards Council for protecting payment card data, validated through a self-assessment questionnaire or a Qualified Security Assessor's assessment. SOC 2 is an attestation report by a CPA firm against the AICPA Trust Services Criteria. Some evidence overlaps, such as access reviews, logging and vulnerability management, so a company doing both can reuse work, but one does not substitute for the other.

We use a payment processor for all card handling. Do we still need to think about PCI DSS?

Generally yes, although the scope can be much smaller. A business that accepts cards still has a PCI DSS validation obligation when a processor handles the card data, and the effort depends on how cards are captured in your website or app. Your acquirer or payment processor can tell you which self-assessment questionnaire applies.

Our bank partner asked for SOC 2. Is a Type I report enough?

Ask the bank. Some partners accept a Type I report for a new relationship and expect a Type II report later; others ask for Type II from the start. A Type I report describes your controls as of a single date. A Type II report also tests whether they operated over a period, such as six or twelve months.

Which Trust Services Categories should a fintech include?

Security is always included. Beyond that it depends on what your partners and customers ask for and what your contracts promise. Processing Integrity is commonly requested when the product moves money or calculates figures customers rely on, Availability when customers depend on you to run on schedule, and Privacy for consumer-facing products. Agree on the scope with your auditor before the examination period starts.

Does SOC 2 satisfy the FTC Safeguards Rule?

Not by itself. Whether the rule applies to you depends on what your company does, which is a question for counsel. If it applies, it has specific elements of its own. A SOC 2 program covers many of the same areas, so the policies and evidence can support both, but the rule's text is what you check against.

SOC 2 for fintech startups

Updated 23 October 2026

Fintech companies often meet SOC 2 through a partnership or a sale: a sponsor bank, a payments partner or an enterprise finance team runs a security review and asks for the report. This page covers what those reviewers look at, where PCI DSS and bank due diligence sit next to SOC 2, which of the 22 Policyseed policies to get right first, and what to select in the free generator.

Why bank partners and finance teams ask for SOC 2

Sponsor banks and other regulated partners are expected by their own regulators to manage the risk of the companies they rely on. A SOC 2 report is one of the documents they commonly request during due diligence and at periodic reviews.
Enterprise finance, treasury and procurement teams review a vendor's security before connecting bank accounts, ledgers or payment flows to it, and a SOC 2 report answers many of their questions at once.
Fintech products can hold account credentials, transaction histories, bank account numbers and identity documents, which customers treat as among their most sensitive data.
Investors and acquirers in financial services commonly ask about the security program during diligence, and an existing report shortens that conversation.

Trust Services Categories commonly requested

Security is in every SOC 2 report. The other categories are optional and are added when customers ask for them or your contracts make commitments they cover. What follows is what bank partners and finance teams commonly request, not a rule; agree on the scope with your auditor before the examination period starts.

Category	Why it comes up	In the generator
Security	Included in every SOC 2 examination. The common criteria cover governance, risk assessment, access, change management, monitoring, incident response and vendor risk.	Always
Processing Integrity	Commonly requested when the product moves money, calculates balances, reconciles ledgers or produces figures customers rely on, because it addresses whether processing is complete, valid, accurate, timely and authorized.	No
Availability A1.1, A1.2, A1.3	Commonly added when customers depend on the service to move money or close their books on schedule, or when contracts include uptime commitments.	Yes
Privacy	Commonly requested for consumer-facing products that collect personal and financial information, since it covers notice, choice, collection, use, retention and disclosure of personal information.	No
Confidentiality C1.1, C1.2	Commonly added for business-facing products where contracts define customer financial data as confidential and set rules for its protection and disposal.	Yes

The generator’s scope question offers Security, Availability and Confidentiality. If your auditor scopes Processing Integrity or Privacy, the 22 policies are still a starting point (the Privacy and Data Protection Policy covers notice, use, retention and data subject requests), but those criteria need controls and evidence beyond what the policies describe.

Other frameworks that come up, and how they relate to SOC 2

Each framework below is published by its own standards body or regulator; the links go to them. This is a general description, not legal advice: whether a law or contract applies to you is a question for counsel.

PCI DSS, if you handle payment card data

The Payment Card Industry Data Security Standard applies to businesses that store, process or transmit payment card data, or that can affect its security. It is a separate standard with its own validation: a self-assessment questionnaire or an assessment by a Qualified Security Assessor, depending on how you accept cards and your volume. Many startups reduce their PCI DSS scope by having a payment processor capture card data through hosted fields, redirects or SDKs, so card numbers never reach their own systems. Some evidence overlaps with SOC 2, such as access reviews, logging and vulnerability management.

Keep in mind: A SOC 2 report does not replace PCI DSS validation. The card brands and your acquirer or payment processor decide which validation applies to you, not your SOC 2 auditor.

Sources: PCI DSS (PCI Security Standards Council)

Bank partner due diligence

If you work with a sponsor bank, for example for accounts, cards or lending, the bank's regulators expect it to manage the risks of its third-party relationships. In June 2023 the Federal Reserve, the FDIC and the OCC issued joint Interagency Guidance on Third-Party Relationships: Risk Management. Banks commonly ask for your SOC 2 report together with your information security, business continuity and incident response policies, incident notification commitments, financial information and evidence of how you manage consumer protection obligations.

Keep in mind: A SOC 2 report answers part of a bank's due diligence, not all of it. Consumer protection, anti-money-laundering and licensing questions are outside SOC 2.

Sources: Interagency Guidance on Third-Party Relationships (Federal Reserve announcement, June 2023) · OCC Bulletin 2023-17: Third-Party Relationships

The FTC Safeguards Rule

The FTC's Safeguards Rule, issued under the Gramm-Leach-Bliley Act, requires financial institutions within the FTC's jurisdiction to maintain an information security program with specific elements. The SOC 2 policies cover many of the same topics, such as risk assessment, access control, encryption, vendor oversight and incident response, so the same work can support both.

Keep in mind: Whether the Safeguards Rule applies to your company depends on what you do and is a question for counsel. If it applies, check its specific elements against the rule's text; a SOC 2 report is not a finding that they are met.

Sources: FTC Safeguards Rule, 16 CFR Part 314 (eCFR)

The 6 policies that matter most

All 22 policies apply to every company that uses them. These are the ones bank partners and finance teams read most closely, so review them first and make sure every statement matches how you actually operate. The template index lists the full set.

P22 Privacy and Data Protection Policy: Sets out how personal and financial information is collected, used, retained and disclosed. With payment data selected, it states that card data is handled through a payment processor assessed against PCI DSS and that full card numbers and security codes are never stored.
P06 Data Classification and Handling Policy: Classifies payment card data as Restricted and sets the handling rules reviewers check for account and transaction data.
P08 Encryption and Key Management Policy: Bank partners and enterprise reviewers ask how account data and credentials are encrypted and who controls the keys.
P09 Change Management Policy: Changes to code that moves money or calculates balances are where reviewers look for peer review, approval before release and separation of duties.
P16 Vendor and Third-Party Risk Management Policy: You depend on processors, banking partners and data aggregators. This policy is how you show you review them, and a bank reads it next to its own review of you.
P13 Incident Response Policy: Partner and customer agreements commonly set incident notification timelines; this policy holds the steps for assessing and meeting them.

What to select in the generator

These answers change the policy text for fintech companies. The other questions (company, product, tools, owners, review cadence) are the same for everyone.

Question	Answer	What it changes
Sensitive data handled	Payment card data	Select it when your product accepts or handles card payments, even through a processor. Several policies then add card data rules, including delegating card capture to a payment processor and keeping full card numbers and security codes out of storage and logs.
Sensitive data handled	Personal data (PII)	Account holders' names, addresses, identity documents and bank details are personal data. Selecting it adds personal data rules to the vendor, retention, privacy and incident response policies.
Trust services categories in scope	Availability	Add it if your auditor has scoped it, for example because contracts promise uptime or customers rely on you to move money on schedule. The business continuity, logging and monitoring, and network policies, among others, then gain availability wording.
Key vendors and subprocessors	Your payment processor, banking partner and any account data aggregator	Named vendors appear in the vendor, incident response and privacy policies, so the documents describe the partners a bank or customer will ask about.

Questions an auditor may ask

Walkthrough questions in a SOC 2 examination follow the criteria, but the examples an auditor picks depend on what your product does. These are the kind that come up for fintech companies; the auditor interview prep sheet lists the questions per criterion with the sentences in your policies that answer them.

How do you make sure full card numbers never reach your logs, databases or support tools?
Who can change production code that moves money or calculates balances, and how is each change approved before release?
How are transactions reconciled, and what happens when a reconciliation does not match?
How do you review your payment processor, banking partner and data aggregators, and where are their assurance reports?
Who can access production databases that hold account data, and when was that access last reviewed?
How would you notify your bank partner and customers of an incident, and within what time frame?

Free tools for this

SOC 2 readiness self-assessment: Find the gaps before a bank partner's review does.
Security questionnaire answers: Draft answers to a partner's or customer's questionnaire from your own policies.
Vendor security questionnaire template: Review your own processors and aggregators the way a bank reviews you.
Incident response plan template: Severity levels, roles and notification templates for partner and customer notices.
Business continuity plan template: Recovery objectives and playbooks for the services customers rely on to move money.
Trust page generator: A public page that answers the first round of partner questions.

Other industries

Frequently asked questions

Does a SOC 2 report cover PCI DSS?: No. PCI DSS is a standard from the PCI Security Standards Council for protecting payment card data, validated through a self-assessment questionnaire or a Qualified Security Assessor's assessment. SOC 2 is an attestation report by a CPA firm against the AICPA Trust Services Criteria. Some evidence overlaps, such as access reviews, logging and vulnerability management, so a company doing both can reuse work, but one does not substitute for the other.
We use a payment processor for all card handling. Do we still need to think about PCI DSS?: Generally yes, although the scope can be much smaller. A business that accepts cards still has a PCI DSS validation obligation when a processor handles the card data, and the effort depends on how cards are captured in your website or app. Your acquirer or payment processor can tell you which self-assessment questionnaire applies.
Our bank partner asked for SOC 2. Is a Type I report enough?: Ask the bank. Some partners accept a Type I report for a new relationship and expect a Type II report later; others ask for Type II from the start. A Type I report describes your controls as of a single date. A Type II report also tests whether they operated over a period, such as six or twelve months.
Which Trust Services Categories should a fintech include?: Security is always included. Beyond that it depends on what your partners and customers ask for and what your contracts promise. Processing Integrity is commonly requested when the product moves money or calculates figures customers rely on, Availability when customers depend on you to run on schedule, and Privacy for consumer-facing products. Agree on the scope with your auditor before the examination period starts.
Does SOC 2 satisfy the FTC Safeguards Rule?: Not by itself. Whether the rule applies to you depends on what your company does, which is a question for counsel. If it applies, it has specific elements of its own. A SOC 2 program covers many of the same areas, so the policies and evidence can support both, but the rule's text is what you check against.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.