PCI DSS for US SaaS Companies: Scope, Roles and Buyer Requests

• 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.

The outcome. Done-for-you consulting, an attestation your US customers accept, and engineers who stay on the roadmap.

1. Scoping workshop with your engineering lead: we map every place card data could appear. 2. Free gap assessment against the current standard. 3. Scope reduction: we agree the design changes worth making. 4. Controls, policies and evidence: built and collected for you, then reviewed internally. 5. Validation: 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.

You deal with Sterling throughout, and the consultants who build your controls never assess them. Our record is 100% success and on-time completion, with experts bringing 30+ years of experience. A fixed quote follows the free gap assessment.

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. A clear yes or no on whether PCI DSS applies to your product, and a short path to the evidence US buyers need to sign.

The trigger is not whether you accept cards yourself. The PCI Security Standards Council says the standard is meant for entities that store, process or transmit cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment, service providers included^[1]. A US software company usually meets that description in one of three ways:

• You charge your own customers by card. You are a merchant, whatever you sell, and an SAQ normally applies.
• Your product handles customers' card data. Billing, support, order-management, call-recording and BPO-style platforms are typical. You are a service provider.
• Your product sits next to card data. Hosting, monitoring, identity and remote-access tools can affect someone else's environment, so a US enterprise customer may still want to see what you can show.

The third case causes most confusion, because the standard looks at what you could affect, not only what you hold. Who must validate is for the customer, its acquirer or the card brand to decide^[1].

Many US SaaS companies are both. The two roles lead to different paths, set side by side here.

The outcome. Less of the standard lands on your company, so validation comes sooner and costs less engineering time.

A card number that never enters your systems cannot be stolen from them. In order of impact:

1. Processor-hosted collection. Let the payment processor collect card details on a page it hosts and return only a token. Know the difference between a redirect and an embedded form, because they place different obligations on your own page^[2]. 2. Processor-served card fields. Choose an integration where your code never sees the card fields. 3. No accidental stores. Keep card data out of logs, error traces, analytics events, support tickets and chat. The unplanned store is how most software companies end up with a wider scope than intended. 4. Isolation. If you must handle card data, isolate that component and limit who and what can reach it.

The Council lists guidance on scoping and segmentation for modern network architectures in its v4.x resource hub^[6]. Cloud, containers and microservices blur boundaries, so expect an assessor to ask how you prove segmentation works.

The outcome. Two short tables that end scope arguments before they start.

A SaaS company runs on someone else's cloud and serves other companies' customers, so responsibility is shared both ways. Version 4.0.1 clarified applicability notes on relationships between customers and third-party service providers^[4]. Assessors want a responsibility matrix: each requirement area, and whether you, your cloud provider or your customer owns it.

• Upstream matrix. Hosting, payment processing, monitoring, support tools: does each handle card data, is it validated, to which version, and where is its attestation filed? The Council notes some providers may still be validated to an earlier version and recommends confirming details with them^[7].
• Customer-facing matrix. US enterprise buyers will want to know exactly what your validation covers for them and what stays with them. A vague 'we are PCI compliant' invites follow-up questions and scope disputes.

The outcome. A ready answer pack, so the PCI line in a US vendor review closes in days, not weeks.

In Sterling's experience the questions arrive in a predictable order:

1. Do you store, process or transmit our cardholder data? 2. Can you share your current attestation of compliance, and for which version? 3. What does the validation cover: services, locations, cloud regions? 4. Which requirements are yours and which are ours? 5. Which third parties handle our data? 6. How will you tell us about changes to your compliance status?

The Council's FAQ library features a question on whether the attestation of compliance is intended to be shared^[5]. Treat the attestation as the document you hand over: keep it current, and make sure the scope it describes matches the product the customer actually buys. A gap between attested scope and the live product is a common reason a US reviewer pushes back.

The outcome. One engineering backlog that covers PCI DSS and the security work you already run.

• Authentication. Multi-factor authentication now covers all access into the card data environment, with a 4.0.1 note for accounts using phishing-resistant factors^[4][2].
• Custom software. An inventory of bespoke software, developer training, code review, secure engineering and controlled production changes^[2].
• Web attacks. An automated technical defense for public-facing web applications^[2].
• Payment-page scripts. Pages embedding a payment form must manage and monitor the scripts that load^[2][4].
• System accounts. Owners, least privilege and reviews, as for people^[2].
• Logs. Automated review for specified events; other frequencies set by a targeted risk analysis^[2].
• Incidents. Named people on call around the clock in the larger scopes^[2].

Much of this mirrors work done for SOC 2 or ISO/IEC 27001, which is why Sterling often scopes PCI DSS alongside one of them.

The Council describes SAQ D for service providers as the only questionnaire open to eligible service providers, with added documentation on the assessed environment and descriptions of testing results^[2][3]. Whether a questionnaire is enough is for the party asking. In Sterling's experience, large US customers often want a Report on Compliance from a Qualified Security Assessor, because it adds independent testing. See SAQ versus ROC, and SAQ types explained for your own subscription checkout.

This is Sterling's recommendation, not a requirement of the PCI Security Standards Council.

• Treat PCI DSS as an architecture decision first and a compliance project second.
• Use processor-hosted pages or card fields so your systems handle only tokens.
• Write the responsibility matrix before the first US enterprise customer requests it.
• If your product handles customer card data, plan for an independent assessment and start the gap assessment well ahead of the first contract deadline.
• Run one control set across PCI DSS and SOC 2, so every piece of evidence works twice.
• Walk through the PCI DSS 4.0.1 requirements in plain English with your engineering lead, and see the PCI DSS hub.

Ready to clear the PCI line in your next US deal? Get started with a short scoping call.

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
• Clear US Enterprise Security Reviews and Questionnaires 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
• PCI DSS 4.0.1 Requirements in Plain English for US BusinessesUnited States
• Sterling in the United StatesUnited States

1. PCI Data Security Standard (PCI DSS). PCI Security Standards Council. accessed October 23, 2026.

2. PCI DSS v4: What's New with Self-Assessment Questionnaires. PCI Perspectives Blog, PCI Security Standards Council. accessed October 23, 2026.

3. Bulletin: SAQs for PCI DSS v4.0 are Now Available. PCI Security Standards Council. accessed October 23, 2026.

4. Just Published: PCI DSS v4.0.1. PCI Perspectives Blog, PCI Security Standards Council. accessed October 23, 2026.

5. Frequently Asked Questions. PCI Security Standards Council. accessed October 23, 2026.

6. PCI DSS v4.x Resource Hub. PCI Perspectives Blog, PCI Security Standards Council. accessed October 23, 2026.

7. PCI DSS v3.2.1 is Retiring on 31 March 2024 - Are You Ready?. PCI Perspectives Blog, 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.