PCI DSS v4.0.1
PCI DSS compliance, requirement by requirement
If you store, process or transmit cardholder data, PCI DSS applies. This page covers what each requirement asks for, how validation works, who enforces it, and how to plan the work so engineering can keep shipping.
In short
PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements maintained by the PCI Security Standards Council. Any organisation that stores, processes or transmits cardholder data must comply. Validation ranges from a Self-Assessment Questionnaire for smaller merchants to a full on-site audit by a Qualified Security Assessor for service providers and large merchants. Version 4.0 introduces the customised approach, letting organisations meet each objective with controls that fit their environment.
What PCI DSS is
PCI DSS is an industry security standard rather than a law. The card brands (Visa, Mastercard, American Express, Discover, JCB) require it through their operating rules, and your acquiring bank enforces it. A regulator will not fine you for non-compliance. Instead you face escalating assessments, higher processing fees and, in the worst case, the loss of your ability to accept cards.
The standard applies to every entity that stores, processes or transmits cardholder data, and to every system that can affect the security of that data. Cutting down the number of systems that touch card data (segmentation) is usually the most effective way to reduce scope, cost and risk.
Who needs PCI DSS compliance
If your systems touch cardholder data at any point, PCI DSS applies. That includes SaaS platforms that process payments, e-commerce merchants, payment processors, managed service providers that host cardholder environments, and any company that stores card numbers even temporarily.
The validation level depends on your transaction volume and role in the payment chain. Most SaaS companies that integrate Stripe or Adyen and never see raw card data can self-assess with SAQ A. Companies that handle card data directly need a fuller questionnaire or a QSA audit.
- Merchants processing card-not-present transactions (e-commerce)
- Service providers that store, process or transmit cardholder data on behalf of others
- SaaS platforms that integrate payment processing
- Companies hosting or managing cardholder data environments
The 12 requirements at a glance
PCI DSS groups its requirements into six goals. Each requirement contains detailed sub-requirements (over 250 in v4.0) that specify the controls you need.
| Goal | Requirement | What it covers |
|---|---|---|
| Build and maintain a secure network | Req 1. Network security controls | Firewalls, segmentation and network access rules |
| Build and maintain a secure network | Req 2. Secure configurations | No vendor defaults, hardened system components |
| Protect account data | Req 3. Protect stored account data | Encryption at rest, key management, data retention |
| Protect account data | Req 4. Protect data in transit | Strong cryptography over open, public networks |
| Maintain a vulnerability management programme | Req 5. Malware protection | Anti-malware, regularly updated |
| Maintain a vulnerability management programme | Req 6. Secure development | Patching, secure SDLC, web application protection |
| Implement strong access control | Req 7. Restrict access by need to know | Role-based access, least privilege |
| Implement strong access control | Req 8. Identify users and authenticate | Unique IDs, MFA, password policies |
| Implement strong access control | Req 9. Restrict physical access | Physical controls for systems storing card data |
| Monitor and test networks | Req 10. Log and monitor access | Audit trails, log review, time synchronisation |
| Monitor and test networks | Req 11. Test security regularly | Vulnerability scans, penetration tests, IDS/IPS |
| Maintain an information security policy | Req 12. Security policies | Policies, risk assessment, security awareness, incident response |
How validation works
Validation type depends on your role and transaction volume. The card brands place merchants in levels 1 to 4. Level 1 merchants and most service providers need an on-site audit by a Qualified Security Assessor (QSA). Smaller merchants and service providers can self-assess using the appropriate SAQ.
A Report on Compliance (ROC) is the output of a QSA audit. An Attestation of Compliance (AOC) is a summary that confirms you passed. Your acquiring bank and the card brands accept one or both, depending on your level.
- SAQ
- Self-Assessment Questionnaire: a self-validated checklist, with variants such as A, A-EP and D depending on how you handle card data
- ROC
- Report on Compliance: the detailed output of an on-site QSA audit
- AOC
- Attestation of Compliance: a signed summary confirming your compliance status
- QSA
- Qualified Security Assessor: a firm certified by PCI SSC to conduct on-site assessments
Scope reduction through segmentation
The cardholder data environment (CDE) is every system that stores, processes or transmits cardholder data, plus every system connected to it. Without segmentation, your entire network is in scope.
PCI DSS does not require segmentation, but it is the most effective way to reduce audit scope and cost. If the CDE sits in a clearly bounded network segment, there are fewer systems to harden, monitor and test.
What PCI DSS v4.0 changes
Version 4.0 replaced v3.2.1 and puts more weight on security outcomes. Its limited revision, v4.0.1, published in June 2024, clarified wording without adding requirements, and v4.0 was retired at the end of 2024. The customised approach lets organisations meet each requirement's stated objective with controls that fit their environment, instead of following the defined approach to the letter. Either approach satisfies the standard.
The main changes are targeted risk analyses in place of fixed frequencies, wider multi-factor authentication requirements, and new requirements for e-commerce (client-side script management, anti-phishing). Several future-dated requirements became mandatory on 31 March 2025.
PCI DSS alongside SOC 2, ISO 27001 and HIPAA
Many PCI DSS requirements overlap with SOC 2 and ISO 27001: access control, logging, vulnerability management, incident response, change management and security policies. If you already hold a SOC 2 report or an ISO 27001 certificate, much of that evidence applies.
The PCI-specific work is in the cardholder data protections (encryption at rest and in transit with specific key management), network segmentation validation, quarterly ASV scans, and the physical security requirements for systems in the CDE.
The path to compliance
The decisions that matter most are about scope and segmentation. Once those are settled, the remaining work is a matter of going through each requirement.
-
01
Scope and segment
Identify every system that touches cardholder data. Segment the CDE from the rest of the network to reduce what is in scope.
Your network and platform engineers, with our implementation support if you want it
-
02
Gap assessment
Walk through each requirement against your current state. Prioritise by risk and by what your assessor will test first.
Your security lead
-
03
Remediate and evidence
Implement missing controls, harden configurations, and collect the evidence your SAQ or QSA will need.
Control owners, collecting evidence in Certifyi
-
04
Validate
Complete the SAQ or engage a QSA for the on-site audit. Submit the AOC to your acquirer.
QSA or self-assessment
Who does what
Software, implementation support and the independent assessor are different jobs. This is how they divide.
| Task | Your team | Certifyi | QSA (on-site) or self-assessment |
|---|---|---|---|
| Scope and segmentation | Define the CDE boundary | Records scope and segmentation decisions | Validates segmentation controls |
| Controls | Implement and operate them | Holds controls and policies | Not involved until testing |
| Evidence | Upload it or request it | Ties it to the requirement and records each action on it | Samples it during assessment |
| Testing | Answers the assessor's questions | Opens the evidence to the QSA through scoped, read-only access | Tests each requirement (SAQ or on-site) |
| The report | Submits the AOC to the acquirer | Does not issue reports | Issues ROC and AOC |
How Certifyi helps
Run PCI DSS alongside your other frameworks
Your controls, policies and evidence live in Certifyi, and your assessor reviews the same record you work from. The ROC and AOC still come from the assessor.
-
PCI DSS in the framework catalogue
Adopt PCI DSS with the requirements in your scope and track readiness per requirement.
-
Tamper-evident activity log
Evidence sits on the requirement it supports, and when a QSA asks who updated the segmentation test results and when, the tamper-evident activity log answers it.
-
Requests for missing evidence
When evidence for a requirement is missing, send a request tied to that requirement to the colleague or supplier who holds it.
-
Policies with review cycles
Keep the Requirement 12 policies your assessor reads, and review each one on a set cycle.
From the blog
PCI DSS articles
Longer answers to the questions teams ask while they work on PCI DSS.
Questions
PCI DSS, answered
Does PCI DSS apply if we use Stripe?
Yes, but your scope is usually much smaller. If you use Stripe's hosted payment fields (Stripe.js, Checkout or Elements) and never see raw card numbers, SAQ A typically applies: a short self-assessment rather than a full audit.
What is the difference between SAQ A and SAQ D?
SAQ A is for merchants that fully outsource cardholder data handling to a PCI-compliant provider. SAQ D covers merchants and service providers that store, process or transmit cardholder data themselves. SAQ D is substantially longer.
How often do we need to validate?
Annually for the SAQ or ROC, plus quarterly ASV scans if your environment is internet-facing. Penetration tests are required at least annually and after significant changes.
What are ASV scans?
Approved Scanning Vendor scans are quarterly external vulnerability scans of your internet-facing systems, conducted by a PCI SSC-approved scanning vendor. They check for known vulnerabilities and misconfigurations.
Can we reuse SOC 2 evidence for PCI DSS?
Much of it. Access control, logging, change management, incident response and vulnerability management evidence applies to both. The PCI-specific additions are cardholder data encryption, segmentation validation, ASV scans, and physical security of the CDE.
What happens if we are not compliant?
Your acquiring bank may impose escalating assessment requirements, higher transaction fees, or restrictions on your ability to process cards. In the event of a breach involving cardholder data, non-compliance significantly increases liability.
Scope your PCI DSS programme in a 30-minute call.
Bring your payment flow and the SAQ type your acquirer expects. Scope decides most of the PCI effort, so we start there, then look at how the controls you already run for SOC 2 or ISO 27001 carry into your PCI evidence.
- Each customer workspace has its own database
- Every change written to a tamper-evident activity log
- Auditors get scoped, read-only access
- AI suggestions wait for a person to accept them