What does PCI scope actually mean?
Most teams find out their scope is wrong during a security questionnaire, when the deal is already on the table.
The short answer
5 things that decide this
- 01PCI scope is the set of systems that store, process or transmit cardholder data, plus anything that can affect the security of those systems.
- 02Your scope is decided by how you embed the payment form, not by which processor you chose.
- 03A hosted redirect or an iframe served by the processor keeps you in the lightest questionnaire, SAQ A. Capturing card fields on your own page and posting them onward pushes you toward SAQ A-EP, which is much longer.
- 04Since 31 March 2025, qualifying for SAQ A means confirming that your site is not susceptible to attacks from scripts that could affect your e-commerce systems, which is a statement about the site and not only the payment page.
- 05Using Stripe does not make you PCI compliant. It can make your scope small, which is a different and better thing.
Why "we use Stripe" is not an answer
A processor takes on the hard part: storing card numbers. What it cannot do is take on your page. If your checkout renders a form the processor hosts, the card number never reaches your servers. If your checkout collects the number in your own fields first, it does, and everything that touches it comes into scope with it.
That is one architectural choice, usually made in an afternoon, and it sets how much of PCI you answer for years. It is worth making on purpose.
How the integration shape picks your questionnaire
Three common ways to take a card, and what each does to your scope. Your acquirer and your assessor confirm the final answer, but this is the shape of it.
| How you take the card | Where the number goes | Usual questionnaire | What it costs you |
|---|---|---|---|
| Redirect to the processor's page | Never touches you. | SAQ A | Least to answer. You give up control of the checkout look and the customer leaves your site. |
| Processor-hosted fields in an iframe | Never touches you. | SAQ A | Least to answer, and the customer stays on your page. This is the default we reach for. |
| Your own fields, posted onward | Passes through your page. | SAQ A-EP | A much longer questionnaire and real engineering work on script control and change detection. |
The 2025 change to SAQ A that catches people out
The PCI Security Standards Council removed two payment page security requirements from SAQ A. It also dropped the risk analysis that supported one of them. That reads like a simplification. It is not quite.
In their place came an eligibility criterion. To use SAQ A a merchant confirms their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce systems. The removed items were narrow and testable. The replacement is broader and rests on your judgement about your whole site.
The Council's FAQ gives two routes to make that confirmation. Deploy the protection techniques yourself, including the ones from those removed requirements. Or obtain confirmation from your PCI DSS compliant processor that the embedded payment page solution includes techniques protecting your payment page from script attacks. The second route is a document you have to actually go and get.
- 01The January 2025 SAQ A took effect on 31 March 2025, when the October 2024 version was retired.
- 02Ask your processor in writing whether their embedded form covers you, and keep the reply.
- 03Keep a list of every script on the checkout page, with a reason each one is there.
- LaunchHosted fields, small scope.
- MeasureMarketing adds a tag.
- DebugLogger captures request bodies.
- SupportCard number pasted into a ticket.
- AuditYou answer for all of it.
Nobody makes a decision at any step. The compliance position you attested to is gone by the fourth one.
What people ask next
01We were told we need SAQ A. How do we check that is right?
Look at where the card number is typed. If every payment field is served by your processor, through a redirect or an iframe, SAQ A is usually correct. If your own page renders the input the customer types into, it usually is not, whatever you were told. Your acquirer decides, so put the question to them in writing with a description of the integration.
02Does adding an analytics tag to checkout change anything?
It can, and this is the quiet one. Scripts on a payment page are exactly what the current SAQ A eligibility criterion asks you to confirm about. A tag added by someone outside engineering does not announce itself, which is why a maintained script inventory is worth more than it sounds.
03Do we need a QSA?
Most software buyers validate with a self-assessment questionnaire rather than a full assessment, and the level depends on your transaction volume and channel. Your acquirer tells you which applies to you. Ask them before assuming, because the answer changes what you build.
04Is PCI scope a compliance job or an engineering job?
Engineering, decided at design time. The integration shape, the logging, and the scripts on the checkout page are all code choices. Compliance can tell you the rule and cannot undo an architecture that put card data somewhere it should not be.
