What stays in scope when a Level 1 merchant outsources everything

Picture a Level 1 merchant doing eight million transactions a year through a hosted payment page or iframe. E-commerce only, no face-to-face. The shopper never leaves the merchant's site, but the checkout form itself is hosted by a third-party processor, such as a payment gateway, orchestrator, or vaulting provider. The merchant has no direct control over how cardholder data is captured. Their own servers never receive, process, or store a PAN. Any card data they retain is on paper. That's the setup: all processing outsourced to validated providers, nothing electronic left on their side.

They still cross the Level 1 threshold by volume, so a self-assessment questionnaire was never an option. A QSA shows up. So what's actually left to assess?

More than most expect. Far less than the full standard. And PCI SSC has published exactly how that works.

Level 1 doesn't get a self-assessment, but it can still use one as a map

SAQ A applies to card-not-present merchants, e-commerce and mail/telephone-order, where all processing is outsourced to PCI DSS validated third parties, no cardholder data is electronically stored, processed, or transmitted on the merchant's own systems, the merchant has no direct control over how cardholder data is captured, every third party handling that data is confirmed compliant, and for e-commerce: all payment page elements originate directly from a PCI DSS compliant processor, and the merchant has confirmed their site is not susceptible to script-based attacks. Twenty-seven requirements. The shortest form PCI SSC publishes. Level 1 merchants don't have that option. Above the volume threshold set by the card brands, generally six million transactions a year, you don't self-assess. You get a Report on Compliance (ROC), performed on-site by a Qualified Security Assessor.

Here's the part that surprises people on both sides of this. PCI SSC has an official FAQ, article number 1331, published May 2025, that directly answers whether a ROC has to cover the full standard even when a merchant's environment is identical to a self-assessment-eligible one. The answer: no.

The FAQ states that if a merchant's QSA agrees that applying only the requirements included in a specific SAQ is an acceptable approach to securing that merchant's environment, that SAQ may be used as a relevant guide for which PCI DSS requirements actually apply, even though the merchant is completing a ROC, not the SAQ itself. For a fully outsourced Level 1 merchant, that SAQ is SAQ A.

Three conditions follow from this, all of them explicit in the FAQ. First, the environment must fully meet every SAQ A eligibility criterion. If it meets some but not all, SAQ A should not be used as a guide at all. Second, the QSA must perform appropriate validation to confirm that any requirements falling outside the SAQ genuinely don't apply. This is an active step, not a passive assumption, and the QSA documents both the approach and the outcome in section 3.1 of the ROC. Any requirement confirmed as not applicable is recorded as Not Applicable in the ROC, not left blank and not marked Not Tested. Third, the merchant must confirm with the relevant payment brands and acquirer that this scoping approach is acceptable for their compliance program. FAQ 1331 is explicit that merchants should always verify this directly.

All 12 requirements, at a glance

Here's the same answer, organized the way the standard itself is structured: all 12 PCI DSS requirement areas, and where each one lands once a Level 1 merchant fully meets SAQ A's eligibility criteria.

‍

Five of the twelve, Requirements 1, 4, 5, 7, and 10, don't appear in SAQ A at all. They cover network segmentation, encrypted transmission, anti-malware, role-based access restriction, and detailed audit logging, all things that only matter if the merchant's own systems actually touch account data. A fully outsourced merchant has nothing in those categories for a QSA to evaluate, because there's no cardholder data environment left on the merchant's side to apply them to.

In the ROC, those five requirements are documented as Not Applicable, not as Not Tested. That distinction matters. Not Tested means a requirement does apply to the environment but the assessor didn't cover it. That's what triggers a Partial Assessment designation, which card brands including Mastercard will not accept. Not Applicable means the requirement genuinely doesn't apply because there's nothing in scope to apply it to, the assessor confirmed that judgment, and it's documented with a reason. A ROC can carry multiple Not Applicable entries and still be a Full Assessment. For a fully outsourced Level 1 merchant, Requirements 1, 4, 5, 7, and 10 fall into that category, and the QSA's job is to confirm and document why, not to skip them silently.

Six out of twelve, Requirements 2, 3, 6, 8, 9, and 11, are partially applicable, and the conditions are specific. For e-commerce merchants using a redirect or embedded iframe, Requirements 2, 6, 8, and 11 apply specifically to the merchant webpage that hosts the redirect mechanism or the embedded payment page, because those pages impact how account data is transmitted even though they don't receive it directly. That's the official basis in SAQ A. Requirement 3 and 9 apply on narrower grounds tied to the merchant's own environment.

Requirement 12 is the one exception that's fully applicable, not partially. Information security policy, the full third-party service provider management program, and incident response planning aren't conditional on outsourcing at all. They survive in full regardless of how the merchant accepts payments.

To get a full overview of the relevant SAQ A requirements, click here.

The actual number: an 88% reduction in scope

Add requirement 12.5.2 to SAQ A's 27 items and the real total a fully outsourced Level 1 merchant has to demonstrate is 28. The FAQ is explicit that this requirement applies in all cases, so it belongs in the count even though it doesn't appear on the SAQ A form itself.

Counting every numbered sub-requirement across the full standard, from 1.1.1 through 12.10.7, excluding items explicitly labeled "Additional requirement for service providers only" and including only the appendix sections that apply to merchants, gives a total of 234 merchant-applicable requirements. Set against 28, that's a reduction of 88.0%. Put differently, a fully outsourced merchant retains roughly one in eight and a half of the requirements that would otherwise apply.

This is the number worth holding onto if you're trying to communicate the actual scale of what outsourcing buys you, not "most of it goes away," but a specific, countable 88%. It's also a useful sanity check in the other direction: if a QSA's scoping for a fully outsourced Level 1 merchant looks dramatically different from this ratio, either the environment doesn't actually meet SAQ A's criteria as cleanly as assumed, or there's a documented risk-based reason for the difference, both of which are worth asking about directly.

For a practical look at what this assessment covers, read PCI Audits Made Easy.

The table is a floor, not a ceiling

Everything above describes what the standard requires as a minimum once a merchant genuinely meets SAQ A's criteria. It isn't a description of what every QSA will actually test in practice, and the gap between the two is worth naming directly.

A QSA can, and sometimes should, treat requirements outside this table as still warranting attention, even when the SAQ A mapping technically makes them Not Applicable. This isn't padding an engagement. PCI DSS itself builds room for this kind of judgment into how risk gets assessed. A merchant's environment is never quite as clean as a checklist assumes: a webserver hosting a redirect might sit on shared infrastructure with other systems, a support tool might surface partial card numbers in ways the standard form doesn't anticipate, or a TPSP integration might have a failure mode that pulls more of the merchant's environment into the blast radius than the redirect mechanism alone suggests.

When a QSA sees something like that, the professional move is to scope it in, document why, and test it, rather than wave it through as Not Applicable because a form says so. That's not the QSA second-guessing the standard. It's the standard working as intended, since PCI DSS explicitly expects assessors to apply their own risk judgment on top of the baseline requirements, not just follow a template mechanically.

For a merchant, the practical takeaway is to expect this table to describe the floor of a fully outsourced Level 1 assessment, not a guarantee of exactly where it lands. If your QSA asks for something beyond it, the right first question is what specific risk in your environment prompted it, not whether the standard technically requires it. Most of the time, there's a real answer.

What this means in practice

If you're a Level 1 merchant moving toward full outsourcing and budgeting for cost savings and a lighter audit, the framing in this article is the accurate one to plan against. Full outsourcing genuinely buys an 88% reduction in the raw count of applicable requirements, provided your setup meets every SAQ A criterion exactly, your vendor management program can stand up to testing, and your QSA's own risk judgment doesn't surface something the standard form doesn't capture.

The technical scope genuinely shrinks. Network segmentation, encryption, access logging, and most of the system-hardening requirements fall away when there's no cardholder data environment left on your side to apply them to. One area that warrants specific attention is the vendors you've handed everything to. The scoping obligations for those providers are real and must be justified and documented. For a Level 1 merchant, verifying that those providers meet their own applicable requirements is part of what Requirement 12 is actually measuring. What doesn't shrink is the organizational half of the standard: policy, incident response, scope confirmation, and above all, proving you're actually managing the vendors you've handed everything to. That's where a Level 1 ROC concentrates once the card data itself is gone, and it's the part worth budgeting time for, not the part that disappears.

‍