PCI DSS for US Fintechs: What Acquirers and Card Programs Require

• Done for you, end to end

  We write the policies, set up the controls and evidence, run the internal audit and coordinate the independent audit. You deal with one team from first call to final report.

• Simple and quick

  A free gap assessment, then one plan with dates from day one. Effivity, our GRC automation platform, is included to keep the evidence moving.

• 8,100+ client engagements

  In 60+ countries over 20+ years, with experts who bring 30+ years of experience.

• A fixed quote

  A fixed quote follows a free gap assessment, so you know the full cost before you commit.

Every Sterling consulting engagement comes with the following, so you are not buying extras to get to the finish line:

• Effivity, Sterling's GRC automation platform, with a full-year subscription, to run your controls, evidence, tasks and audits in one place.
• Sterling Academy: preferential course access, with complimentary awareness training for your people.
• Internal auditor training for your audit team, as applicable to your standard.
• For information-security engagements, a vulnerability assessment.

These are part of the engagement, not a separate purchase. The details depend on the standard you are working toward, which we confirm during the free gap assessment.

Consulting and auditing are always separated: the people who consult never audit you. That keeps your internal audit objective and protects the independence of the CPA firm, Qualified Security Assessor or certification body that performs the final step.

Behind this are 8,100+ client engagements in 60+ countries over 20+ years, led by experts with 30+ years of experience.

The outcome: an Attestation of Compliance your US acquirer or program manager accepts the first time, on the right validation route, with the smallest card-data footprint your product allows. We do the groundwork for you; a Qualified Security Assessor (QSA) performs the assessment where one is required.

PCI DSS is not a federal or state statute. It is the Payment Card Industry Data Security Standard, and the current version in the PCI Security Standards Council's library is v4.0.1^[1]. It reaches a US fintech by contract, usually from three directions.

• US acquirers and processors. The merchant agreement behind your card repayments, top-ups or fees names PCI DSS.
• Card programs and sponsor banks. If you run a card product, a wallet or embedded payments, the program manager and the bank behind it pass their own card obligations down to you.
• US enterprise customers. In Sterling's experience, a platform that touches card data for other businesses gets a PCI DSS line in every large customer's vendor review.

What they want in hand is the Attestation of Compliance. The Council states that this document is intended to be shared externally with requesting entities, in line with payment brand rules^[3].

The outcome: no wasted month on the wrong form. We confirm the route in writing with the entity that asked before any evidence is gathered.

The Council is clear that compliance-accepting entities, typically payment brands and acquirers, set the validation and reporting method for their merchants and service providers, including whether you submit a Report on Compliance (ROC) or a Self-Assessment Questionnaire (SAQ)^[2].

• Report on Compliance. A QSA, a firm the Council qualifies to assess compliance to PCI DSS^[4], tests your environment and documents the result.
• Self-Assessment Questionnaire. The Council's FAQ index lists SAQ A, A-EP, B, B-IP, C, C-VT and P2PE among the forms^[5]. Each fits a defined payment set-up and carries eligibility criteria you must meet before you may use it.

One caution from the Council: SAQ eligibility criteria should not guide which requirements apply in a ROC assessment unless that has been reviewed and agreed with the compliance-accepting entity^[6].

The outcome: fewer systems to evidence, a smaller assessment and a faster attestation. Scope reduction comes first, because every system taken out of scope is one nobody has to prove.

In a scoping session we trace card data through:

1. Capture. Checkout, card-on-file and repayment flows, and which component actually receives the number. 2. Service-to-service traffic. Webhooks, queues and callbacks that may carry card data downstream. 3. Observability tools. Logs, error trackers, analytics tags and session replay that may record payment fields. 4. Support channels. Tickets, chat and call recordings where agents see numbers. 5. Data stores and exports. Warehouses and old exports where a field once held a full card number. 6. Neighbors. Systems on the same network segment, which usually come into scope with them.

Hosted fields, early tokenization, clean logs and segmentation do most of the work; we tell you which pay off for your product.

The outcome: the controls your QSA or SAQ will test, built around how your engineers already work. Sterling's plain-English view of where the effort goes:

• Network rules. Documented, reviewed boundaries between card-data systems and everything else.
• Stored data. What card data you keep, why and for how long, and unreadable where you must keep it.
• Secure development. Code review, separated test and production, and third-party library control. For payment pages, the Council's SAQ A script guidance points to techniques in requirements 6.4.3 and 11.6.1^[7].
• Access. Least privilege, unique identities and strong authentication for anyone who can reach card data.
• Logging and testing. Records that let you reconstruct events, plus regular vulnerability scans and penetration tests.
• Policies and incident response. Written, owned and rehearsed.
• Service providers. Which providers touch card data, what each is responsible for and the evidence behind it. A compliant processor reduces what you prove; it does not remove your duty for how you connect to it.

The outcome: we clear these before your acquirer or assessor finds them.

• "The processor's page means zero scope." It shrinks scope; it rarely ends it. Embedded forms bring script duties of their own^[7].
• Choosing the form before calling the acquirer. The wrong SAQ, or an SAQ where a ROC is demanded, delays the contract.
• Two roles, one set of evidence. A platform that serves other businesses and also collects its own fees by card is both merchant and service provider.
• Counting SOC 2 or ISO 27001 as PCI DSS. The subject matter overlaps, but payment brands and acquirers set PCI DSS validation^[2].
• Shadow data and old environments. A dispute spreadsheet or a retired service still holding card numbers puts systems back in scope.

The outcome: a validation your acquirer accepts, delivered on schedule with the work done for you. Sterling's record is 100% success and on-time completion across 8,100+ client engagements in 60+ countries over 20+ years, led by experts with 30+ years of experience. A Qualified Security Assessor (QSA) performs the assessment and Report on Compliance where one is required; for SAQ-eligible merchants and service providers we prepare and support the SAQ. The people who consult never assess you.

1. Free gap assessment. We confirm your role, trace card data and agree the validation route with your acquirer or requesting entity. 2. Scope reduction. We recommend changes that shrink your footprint. 3. Controls. We prepare policies and procedures and guide the technical fixes. 4. Evidence and internal review. Effivity, our GRC automation platform, holds the evidence; we test it before anyone external does. 5. Assessment or SAQ. We coordinate the QSA, or complete the SAQ with you, through to your Attestation of Compliance.

A fixed quote follows a free gap assessment, and PCI DSS is quoted separately from any other standard. Ready to move? Use Get a proposal and a Sterling expert will respond.

PCI DSS is validated in one of two ways, depending on how you handle card data and what your acquirer or card brand requires. A Qualified Security Assessor (QSA) performs the assessment and Report on Compliance where one is required^[1]; for SAQ-eligible merchants and service providers we prepare and support the SAQ.

Either way, you work with Sterling from first scoping call to final submission. We coordinate:

• scoping: where card data is stored, processed or transmitted, and how to shrink that footprint;
• a gap assessment against the current version of the standard;
• the policies, procedures and technical control improvements needed to close the gaps;
• evidence collection and an internal review before anyone external looks at your environment;
• the assessment itself, including scheduling, evidence requests and follow-up questions.

What you receive is a validation of compliance, documented in the form your acquirer or card brand accepts. Our experts bring 30+ years of experience, and Sterling has completed 8,100+ client engagements in 60+ countries over 20+ years.

^[1] Become a Qualified Security Assessor (QSA). PCI Security Standards Council. accessed October 23, 2026.

• PCI DSS: standard overviewStandard overview
• SOC 2: standard overviewStandard overview
• Meet US Contract, MSA and RFP Compliance Clauses FastUnited States
• PCI DSS SAQ vs ROC: Which Route Your US Business NeedsUnited States
• PCI DSS SAQ Types Explained: Which One Your US Business NeedsUnited States
• SOC 2 for US Fintech Companies: What Banks and Buyers RequireUnited States
• PCI DSS for US Online Sellers and Payment BusinessesUnited States
• Sterling in the United StatesUnited States

1. Document Library (PCI DSS v4.0.1 listed as a featured document). PCI Security Standards Council. accessed October 23, 2026.

2. FAQ 1473: What is the role of compliance-accepting entities and assessors in determining the applicability of PCI DSS requirements for merchant and service provider PCI DSS assessments?. PCI Security Standards Council. accessed October 23, 2026.

3. FAQ 1568: Is the PCI DSS Attestation of Compliance intended to be shared?. PCI Security Standards Council. accessed October 23, 2026.

4. Become a Qualified Security Assessor (QSA). PCI Security Standards Council. accessed October 23, 2026.

5. Frequently Asked Questions (category index: SAQ A, SAQ A-EP, SAQ B, SAQ B-IP, SAQ C, SAQ C-VT, SAQ P2PE, Reports on Compliance, Attestation of Compliance). PCI Security Standards Council. accessed October 23, 2026.

6. FAQ 1331: Can SAQ eligibility criteria be used as a guide for determining applicability of PCI DSS requirements for merchant assessments documented in a Report on Compliance?. PCI Security Standards Council. accessed October 23, 2026.

7. FAQ: How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts?. PCI Security Standards Council. accessed October 23, 2026.

The information on this page is provided for general informational purposes only. It is not legal advice, and it is not a substitute for advice from a qualified attorney about your own situation.

Requirements depend on your scope, your customers' contracts, your industry and the regulations that apply to you. Two companies asking for the same standard can have very different obligations. We confirm yours during a gap assessment, and we update our content as standards change, but you should check the current text of any standard or rule that matters to you.

Sterling consults and prepares. It does not decide whether you meet a standard. That decision belongs to the independent party that performs the final step: the US-licensed CPA firm for a SOC 2 report, the Qualified Security Assessor or acquirer for PCI DSS, and the accredited certification body for ISO certificates. Timelines and outcomes depend on your readiness and on those parties.

Standards and marks named on this site belong to their respective owners.