PCI DSS Compliance in Practice: Scope, SAQ Selection, and Cost Control
PCI DSS is an industry standard enforced by the card schemes through contract and maintained by the PCI Security Standards Council. It does not care how large your company is. It cares about two things: whether you touch cardholder data, and whether your systems are capable of affecting the security of that data. This article runs through eight parts: scope, levels, questionnaires, architecture, requirements, tokenization, anti-patterns, and rollout. Specific clauses and validation expectations should be confirmed against the current version of PCI DSS, predominantly v4.0.x, and the latest requirements of your acquiring bank.
Many teams treat compliance as a procurement question about whether to buy a penetration test. It is really an architecture question. Pick the wrong checkout shape and scope gets inflated for no reason, after which the annual cost of forms, audits, and remediation multiplies. Pick the right one and much of the work never needs to happen at all.
1. What PCI DSS Actually Governs
The standard does not apply only to payment companies. It applies to every entity that stores, processes, or transmits cardholder data, plus entities that never touch card data directly but whose systems, if compromised, would affect the security of that data.
The operative word is affect. A product site with a fully hosted checkout that redirects to the provider domain never sees a card number on its own servers, so its scope is small. But if the checkout page is rendered by your own server, then even when the card number is submitted straight to the provider by browser script, your page still has the ability to be tampered with in order to steal or substitute card numbers, and your scope grows accordingly.
The correct order of reasoning is therefore to draw the data flow first, identify which systems card data passes through and which systems are capable of influencing the integrity of that data, and only then look at volume. Volume determines your compliance level and validation route. It does not determine scope. Conflating the two is the most common conceptual error in this field.
2. The Four Compliance Levels and Their Scope
PCI DSS sorts constrained entities into four levels. Three dimensions drive the classification: annual transaction volume, acceptance channel (online or in person), and whether you act as a merchant or a service provider. The exact banding is agreed between the card schemes and the acquirer in the merchant contract, and details differ slightly between acquirers. This article does not list specific numbers; rely on the current merchant manual from the institution you signed with.
| Level | Primary classification dimension | Typical entity | Validation route |
|---|---|---|---|
| 1 | Largest annual volume, prior data breach, or designated by a scheme | Large merchants, acquirers, payment service providers | Compliance report from a QSA, usually with an on-site assessment |
| 2 | Next tier of annual volume | Mid-size merchants | Self-assessment questionnaire, with QSA involvement required by some acquirers |
| 3 | Mostly online, moderate to small volume | Small and mid-size e-commerce | Self-assessment questionnaire |
| 4 | Smallest volume | Micro merchants | Self-assessment questionnaire, specifics set by the acquirer |
Level affects two things: how strict the validation route is, and whether an external assessor must be involved. For most website teams the practical landing zone is level three or four, which means the self-assessment route and a cost base dominated by architecture changes and paperwork rather than audit fees. That is also why changing the architecture saves more than hiring another consultant: level and scope are both consequences of architecture, and architecture is the variable you actually control.
3. Choosing the Right SAQ
The SAQ is a self-assessment questionnaire with several variants by business model. Card-accepting businesses most often meet SAQ A, SAQ A-EP, and SAQ D. Choosing the wrong tier has direct consequences: too low is a misrepresentation, too high means carrying controls you never needed.
3.1 When SAQ A Applies
The precondition is that card data never enters, passes through, or resides in your systems or environment, and the payment step is performed entirely by a PCI DSS compliant provider page, typically a full-page redirect or a fully hosted form. When that holds, the questionnaire has the fewest items, and the main work is a security policy, oversight of outsourced providers, and making sure the payment page is not polluted by scripts you injected yourself. Note that provider oversight is not a formality: keep the provider's compliance attestation on file and confirm its scope covers the product you use.
3.2 When SAQ A-EP Applies
This covers e-commerce scenarios where your site does not receive card numbers but your page interacts with the provider interface through script or iframe, so a compromised page could alter the transaction or hijack card entry. The questionnaire grows substantially, with emphasis on integrity monitoring of the payment page, script inventory, change control, and third-party script review. Many teams assume they are on A because they never touch card numbers, then discover they are on A-EP because their own form posts to the provider API.
3.3 Where SAQ D Begins
If a card number appears in any form on your servers, database, cache, logs, or memory, you are outside A and A-EP and inside SAQ D territory, with separate merchant and service provider variants. SAQ D carries the fullest set of items and spans all twelve requirements, and the effort is not on the same scale as A. Runaway compliance cost is almost always the result of sliding from A to D.
There is one test: did the card number land anywhere you control. If it did, you are on D. If it did not, ask whether your page can affect transaction integrity. If it can, you are on A-EP. Only if it cannot are you on A.
4. Four Checkout Architectures Compared
Architecture sets scope, scope sets the questionnaire, and the questionnaire sets how many person-days you spend each year. The table below puts four common shapes side by side, and the card data touchpoint column is the deciding factor.
| Architecture | Card data touchpoint | Typical SAQ | Compliance burden |
|---|---|---|---|
| Full-page redirect to a hosted checkout | Card number only appears under the provider domain | SAQ A | Lowest, limited frontend work |
| Iframe embedding a hosted checkout | Card number lives inside the iframe, parent page never touches it | SAQ A when script management and integrity are in place | Low, requires styling and callback work |
| Self-built form calling the provider API from the browser | Browser submits directly to the provider, nothing lands on the server | Usually SAQ A-EP | Medium, requires page integrity monitoring |
| Self-built form proxying card data through your server | Card number passes through and may reside on your own servers | SAQ D | Highest, close to the full requirement set |
4.1 Hosted Checkout Redirect
A full-page redirect is the least demanding option: the user leaves your domain, completes payment on the provider page, and returns with a result. The card number never touches your systems, the SAQ stays at A, and annual review is minimal. The tradeoff is brand continuity and conversion: some users hesitate when sent to an unfamiliar domain, and mobile redirect flows can lose the return leg. Custom domains and prefilled fields mitigate this, with support varying by provider.
4.2 Embedded iframe
An embedded iframe preserves the look of your page while isolating the card number inside the provider domain. It can still sit within SAQ A, provided you have an inventory and integrity control over every script loaded by the parent page, because parent scripts can in principle observe iframe behaviour and even redirect input focus. In practice, avoid mounting analytics, chat widgets, or experimentation scripts on the checkout page at all.
4.3 Self-Built Form Calling the Provider API Directly
Using the provider's tokenized field component, where provider script renders the inputs and the card number posts straight to the provider, is the most common compromise today: full visual control, no card data at rest. The page can still affect the transaction, so this is usually treated as A-EP and requires script integrity monitoring plus change approval. If the team lacks frontend security maintenance capacity, this tier is in fact the one most likely to be flagged in an assessment.
4.4 Card Data Landing on Your Own Servers
Posting the card number to your own backend and forwarding it, or decrypting, logging, and running risk checks locally before submitting, is the most expensive choice: full SAQ D with encrypted transmission, key management, access control, log masking, segmentation, quarterly scanning, and annual penetration testing. Unless there is a clear business reason such as in-person acceptance or a special direct acquiring arrangement, do not choose this path. Teams already on it should prioritize moving the card number out rather than filling SAQ D more attractively.
5. Which of the Twelve Requirements Actually Affect Website Teams
The twelve requirements span network security controls, secure configuration, protection of stored cardholder data, encrypted transmission, malware protection, secure development, access control, identification, physical security, logging and monitoring, security testing, and security policy. For website teams, the recurring and error-prone work clusters in the two areas below.
5.1 Network Segmentation and Minimizing Exposure
The point of segmentation is not tidy network diagrams. It is to separate the card data environment from everything else so that scope shrinks. Practical moves include deploying the card-receiving service on a minimal, hardened host, restricting inbound and outbound connections, and avoiding shared hosts or databases with content management, marketing, and analytics systems. Teams on fully hosted checkout satisfy this almost automatically. Teams proxying card data themselves find it the hardest gap to close.
5.2 Logging, Change Control, and Annual Re-validation
Logging has three concerns: record the relevant events, protect logs from tampering, and retain them for the required period. Change control means every modification touching the card data environment has an approval record and test evidence. The most overlooked item is re-validation: certification does not equal ongoing compliance, the standard requires renewed validation on an annual cycle, and architectural changes, provider switches, or new payment methods can each force a fresh assessment of scope and questionnaire.
6. How Tokenization Shrinks Scope
Tokenization replaces the card number with a meaningless token. Tokens can be stored long term and used for subscription charges and refunds, yet carry no recoverable card data, unless you build a reversible mapping in your own system, which turns it back into sensitive data. Gateway tokens are usually bound to a single provider, so migrating means re-collecting the card. Network tokens are issued within the card scheme ecosystem, work across acquirers, and can refresh when a card is reissued, which suits subscription businesses.
The real value of tokenization for compliance is that your database, support console, and reconciliation systems never need to hold a card number, which peels those systems out of scope. It does not remove every obligation. If you received and processed card numbers before tokenization, that flow is still in scope. If your page can influence the tokenization process, A-EP requirements still apply. Tokenization is a scope reduction tool, not an exemption tool.
7. Five Common Non-Compliant Practices
Practice one is writing card numbers into logs or databases for debugging. This is the most common self-inflicted wound. A single debugging session can pull an entire data flow into SAQ D, and logs usually lack encryption and access control.
Practice two is collecting the card number in your own form and then forwarding it to the provider. It looks like a thin proxy, but the card number fully traverses your own server memory and network, and scope expands instantly.
Practice three is outsourcing the payment page to third-party scripts without integrity monitoring. Nobody knows what gets injected, and the core A-EP control becomes decorative.
Practice four is treating compliance as a one-time project. Redesigns, provider switches, and added payment methods can all change scope, so skipping re-assessment means the compliant state has already lapsed.
Practice five is using shared accounts or personal devices for refunds and card data lookups. Access control and identification are hard clauses in the twelve requirements, and shared credentials are almost always judged non-compliant in an assessment.
8. Implementation Path and Launch Checklist
8.1 A Phased Implementation Path
Phase one is documenting the data flow: list every payment-related system, provider, and third-party script, and annotate every hop the card number takes. Phase two is shrinking scope: redirect where you can, embed where you can, tokenize where you can, and push card numbers out of your own systems. Phase three is closing controls: work through the selected SAQ tier item by item, prioritizing encryption, access control, logging, and change control. Phase four is completing the questionnaire with evidence, so that each control has something you can produce rather than a claim that it is done. Phase five is standing up annual re-validation and folding scope changes into the requirements review process.
Self-check before launch, line by line:
- Has the checkout architecture and its SAQ tier been confirmed with a written conclusion?
- Has the card number been kept out of your own logs, databases, caches, and monitoring systems?
- Do you have a complete inventory of third-party scripts loaded on the payment page, with stated purposes?
- Is the provider attestation current, and does its scope cover the product you use?
- Do production and test environments use different credentials, and is test data masked?
- Are secrets and sensitive configuration stored separately from code with access records?
- Are refunds, lookups, and reconciliation actions authorized under least privilege?
- Is there a trigger mechanism for scope changes, such as a new payment method, a provider switch, or a checkout redesign?
- Are the owner and date of annual re-validation on the calendar?
- Does the incident response plan include the notification path for a card data breach?
For fraud control strategy, see payment fraud prevention strategies. For chargeback evidence and reason codes, see the chargeback reason code and evidence playbook. For pre-launch integration testing, see payment gateway sandbox testing. For licensing and filing requirements, see the payment compliance and filing guide. Common checkout providers include Stripe, Adyen, Checkout.com, and Braintree; for European localization see Mollie, and for the domestic market see Alipay. More options are collected under the Payment category.
Source: 16IDC original. Product capabilities, pricing and eligibility requirements follow the relevant providers’ official documentation and contract terms.