The short version
- PCI DSS protects cardholder data anywhere it is stored, processed, or transmitted.
- Twelve requirement categories covering network security, access control, monitoring, and more.
- Compliance level depends on volume and how card data is handled (SAQ A through D, or full ROC).
- Scoping the CDE narrowly is the single most effective compliance lever.
The longer explanation
Who has to comply
Any organization that stores, processes, or transmits payment card data is subject to PCI DSS. This includes:
- Merchants accepting card payments (online and physical).
- Service providers processing payments on behalf of merchants.
- Any third party that touches cardholder data as part of its service to another covered entity.
The card brands contractually require compliance through acquiring banks. Non-compliance can result in fines, restriction of payment processing, and (in the event of a breach) substantially increased costs.
The twelve requirements
Organized into six control objectives:
Build and Maintain a Secure Network and Systems
- Install and maintain network security controls.
- Apply secure configurations to all system components.
Protect Account Data 3. Protect stored account data. 4. Protect cardholder data with strong cryptography during transmission over open, public networks.
Maintain a Vulnerability Management Program 5. Protect all systems and networks from malicious software. 6. Develop and maintain secure systems and software.
Implement Strong Access Control Measures 7. Restrict access to system components and cardholder data by business need to know. 8. Identify users and authenticate access to system components. 9. Restrict physical access to cardholder data.
Regularly Monitor and Test Networks 10. Log and monitor all access to system components and cardholder data. 11. Test security of systems and networks regularly.
Maintain an Information Security Policy 12. Support information security with organizational policies and programs.
Compliance levels
For merchants, the card brands define levels 1-4 based on annual transaction volume. Service providers use levels 1-2 based on volume of transactions processed on behalf of merchants. The practical compliance artifact varies:
- SAQ A. The lightest self-assessment questionnaire; applies when the merchant outsources card data entirely (hosted payment page, iframe, redirect).
- SAQ A-EP. Merchants whose website affects security of the payment page but who do not touch card data.
- SAQ B, B-IP, C, C-VT, D. Progressively broader scope.
- Report on Compliance (ROC). Level 1 merchants and service providers — a full external audit by a Qualified Security Assessor (QSA).
Most SaaS businesses aim for SAQ A by design. Traditional retail and anyone processing card data server-side typically needs SAQ D or a full ROC.
Scoping matters more than control choice
The single largest lever on PCI compliance cost is scope. Every system in the CDE must meet every applicable PCI requirement. Every system connected to the CDE (even indirectly) is considered in-scope.
Good scoping means:
- Network segmentation. The CDE is on a dedicated network segment with strictly controlled ingress and egress.
- Tokenization and encryption. Card data is replaced with tokens at the edge; raw PAN never lives in application databases.
- Outsourced payment processing. For merchants where it makes sense, the payment flow is handled entirely by a PCI-compliant processor, keeping the merchant's own systems out of scope.
Organizations that do not scope aggressively end up treating their entire infrastructure as CDE — which is a massively larger compliance burden.
PCI DSS 4.0 changes
Key differences from 3.2.1:
- MFA required for all access into the CDE.
- Expanded authentication requirements — password rotation every 90 days is still required for non-MFA access; rotation is allowed to be dynamic when MFA is in place.
- Targeted risk analyses replace some prescriptive requirements.
- Customized approach option for meeting control objectives with compensating controls.
- More prescriptive requirements around security monitoring and anomaly detection.
Future-dated requirements took full effect March 2025.
How Thoughtwave approaches this
Our cybersecurity practice runs PCI DSS readiness, scope-reduction, and ongoing-compliance engagements. We work alongside the client's QSA (or help select one) and focus on the design decisions that reduce scope before they become compliance burden.
For deeper context, see our Cybersecurity Solutions service.