Payment Card Industry Data Security Standard (PCI-DSS)
The Payment Card Industry Data Security Standard (PCI-DSS) is the security standard for anyone who touches payment card data, enforced contractually through the card brands and your acquiring bank rather than by a government. Every organization that accepts payment cards carries PCI-DSS obligations; the applicable requirement set depends on how much cardholder data your systems store, process, or transmit.
Who Needs It
Any organization that stores, processes, or transmits cardholder data, or that could affect the security of a cardholder data environment. That covers merchants of every size, payment processors, gateways, and service providers hosting payment infrastructure for others.
Fully outsourcing payments to a provider like Stripe shrinks your obligations dramatically, but doesn't eliminate them: you still validate annually against a reduced questionnaire, and you're still responsible for the pieces you control, like the page that embeds the payment form.
The Twelve Requirements
PCI-DSS organizes twelve requirements under six control objectives:
| Objective | Requirements |
|---|---|
| Build and maintain a secure network | 1. Network security controls · 2. Secure configurations |
| Protect account data | 3. Protect stored data · 4. Strong cryptography in transmission |
| Maintain a vulnerability management program | 5. Anti-malware · 6. Secure systems and software |
| Implement strong access control | 7. Need-to-know access · 8. Identify and authenticate users · 9. Physical access |
| Monitor and test networks | 10. Log and monitor access · 11. Test security regularly |
| Maintain a security policy | 12. Organizational policies and programs |
Underneath these sit several hundred detailed sub-requirements and testing procedures, all scoped to your cardholder data environment (CDE): the systems that handle card data plus anything connected to them. That's why we recommend prioritizing scope reduction over any other PCI work: segment the CDE from the rest of your network, tokenize where possible, and never store data you don't need. Minimizing storage, where Requirement 3 itself begins, is also the most effective of these. Whatever scope you settle on must be documented and confirmed at least every twelve months; service providers confirm scope every six months.
Beyond the core requirements, appendices add controls for specific situations: multi-tenant service providers (Appendix A1), entities still relying on SSL or early TLS for card-present POI terminals (Appendix A2), and entities a payment brand or acquirer designates for additional validation (Appendix A3).
Validation Levels
How you prove compliance depends on transaction volume. Merchant levels are set by the card brands (thresholds below are Visa's):
| Level | Annual volume | Validation |
|---|---|---|
| 1 | Over 6 million transactions | Annual on-site assessment by a Qualified Security Assessor (QSA), producing a Report on Compliance (ROC) |
| 2 | 1 to 6 million transactions | Annual Self-Assessment Questionnaire (SAQ) |
| 3 | 20,000 to 1 million e-commerce transactions | Annual SAQ |
| 4 | Under 20,000 e-commerce transactions | Annual SAQ; some acquirers set their own expectations |
All levels also run quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) where applicable, and produce an Attestation of Compliance (AOC), the document your customers and acquirer will actually ask to see. Service providers have their own two-level scheme, with Level 1 (over 300,000 transactions) requiring a QSA assessment; Level 2 providers complete SAQ D, though some acquirers and customers ask for a ROC regardless.
Which SAQ you fill out depends on how you accept payments: SAQ A for fully outsourced e-commerce is a few dozen requirements; SAQ D for merchants who store card data is essentially the full standard.
Validation Approaches
Every requirement can be met through one of two paths. The defined approach implements the requirement as written. The customized approach meets the requirement's stated security objective with alternative controls, validated by an assessor and supported by a targeted risk analysis demonstrating equivalent protection. The standard also requires documented roles and responsibilities for the activities under each of the twelve requirements, and all requirements are fully in effect (the last future-dated set became mandatory on March 31, 2025).
Notable current provisions: the 30-day patching window applies specifically to critical vulnerabilities, certain multi-factor authentication (MFA) requirements do not apply to accounts authenticating with phishing-resistant factors, and e-commerce payment pages carry script integrity and management requirements.
Targeted Risk Analysis
Several v4.0 requirements let you set the frequency of a periodic activity yourself, including malware evaluations for systems considered low risk, log reviews for non-critical systems, point-of-interaction device inspections, and password rotation for system and application accounts. Each entity-defined frequency must be supported by a targeted risk analysis (TRA): a short, documented assessment identifying the assets involved, the threats the requirement addresses, the factors affecting likelihood and impact, and the reasoning behind the frequency you chose. TRAs must be reviewed at least once every twelve months and after significant changes to the environment. A separate TRA is also required for every control implemented through the customized approach, where it must demonstrate that the alternative provides protection at least equivalent to the defined requirement. Fixed-frequency requirements, such as quarterly vulnerability scans and the annual organization-wide risk assessment, cannot be rescheduled through a TRA. We recommend maintaining one TRA per requirement rather than a single combined analysis, because assessors evaluate each frequency decision on its own.
Shared Responsibility with Service Providers
Most organizations rely on third parties for parts of their CDE, such as hosting providers, payment gateways, and managed security services. Requirement 12.8 expects you to keep an inventory of these providers, hold written agreements in which each acknowledges its security responsibilities, monitor each provider's PCI-DSS status at least annually, and maintain a documented breakdown of which requirements you manage, which the provider manages, and which are shared. The conventional artifact is a responsibility matrix that walks through all twelve requirements and assigns each to you, the provider, or both, with any not-applicable entries justified. Service providers carry the matching obligation under Requirement 12.9: they must acknowledge their responsibilities in writing and supply compliance status and responsibility information when customers request it. We recommend verifying each entry a provider claims against its AOC and your contract, because any requirement the AOC does not actually cover remains yours to implement and evidence.
For the artifacts that typically satisfy manually evidenced control areas, see Example Evidence.
FAQ
Is PCI-DSS a law?
No. It's a contractual requirement flowing from the card brands through your acquiring bank. Non-compliance brings fines from the brands, higher processing fees, and ultimately loss of the ability to accept cards. A few US states reference it in statute, but enforcement is overwhelmingly contractual.
How long is validation good for?
Twelve months. Compliance is validated annually (ROC or SAQ plus AOC), with quarterly ASV scans in between, and you're expected to be compliant continuously, not just at assessment time.
Can we avoid PCI scope entirely by using Stripe or a hosted payment page?
You can shrink it to the minimum, but you cannot eliminate it. Fully outsourced card handling typically qualifies you for SAQ A, the lightest validation. But you still validate, and you're still on the hook for the security of your site's integration with the payment provider.
Do we need a QSA?
Only Level 1 merchants and Level 1 service providers require QSA assessments. Everyone else self-assesses, though many organizations hire a QSA for a readiness review anyway when the SAQ is non-trivial.