The Payment Card Industry Data Security Standard is built around 12 requirements, grouped into six control objectives. They apply to any organisation that stores, processes or transmits cardholder data. This guide walks through all twelve in plain English so you can see what each one is really asking for.
The 12 requirements at a glance
| # | Requirement | In practice |
|---|---|---|
| 1 | Install and maintain network security controls | Firewalls and network segmentation around the cardholder data environment |
| 2 | Apply secure configurations | No vendor defaults; hardened, documented configuration baselines |
| 3 | Protect stored account data | Minimise storage; encrypt or tokenize what you must keep |
| 4 | Encrypt transmission across open networks | Strong cryptography for cardholder data in transit |
| 5 | Protect against malicious software | Anti-malware on systems at risk, kept current |
| 6 | Develop and maintain secure systems | Patching and a secure development lifecycle |
| 7 | Restrict access by business need-to-know | Least privilege for cardholder data |
| 8 | Identify users and authenticate access | Unique IDs and strong authentication, including MFA |
| 9 | Restrict physical access to data | Controls over facilities, media and devices |
| 10 | Log and monitor access | Audit trails across the environment, reviewed regularly |
| 11 | Test security regularly | Vulnerability scans and penetration testing |
| 12 | Maintain an information security policy | Governance, risk assessment and awareness |
Where teams usually get caught
The requirements are rarely the hard part — the hard part is scope and evidence. A few patterns account for most of the pain:
- Requirement 3 becomes expensive because cardholder data is stored out of habit. If you do not store it, most of this requirement falls away.
- Requirement 10 fails not because logging is absent, but because nobody can show the logs were reviewed.
- Requirement 11 slips when scans and penetration tests happen once for the assessment rather than on the expected cadence.
- Requirement 6 and 8 findings often trace back to inconsistent patching and incomplete MFA coverage.
Scope reduction beats control-building
Every requirement applies to your cardholder data environment and anything connected to it. So the highest-leverage move is shrinking that environment: avoid storing cardholder data, use tokenization, segment the network, and push handling to validated third-party payment pages or SDKs. Less scope means fewer systems each of the 12 requirements has to touch.
Turning requirements into continuous evidence
PCI DSS expects controls to operate all year, not just at assessment time. The teams that struggle are the ones reconstructing evidence the month before their SAQ or Report on Compliance is due. Mapping each requirement to the evidence that proves it — and keeping that link live — is what turns validation into a filtering exercise. It is also how Pelta approaches PCI DSS, reusing evidence across overlapping frameworks like ISO 27001 and SOC 2.
PCI DSS
- Controls mapped
- Evidence collected
- Policies & procedures in place
Adding ISO 27001
~55% carried overAuto-completed from your existing program
Overlap shown is illustrative — the actual carry-over depends on the maturity of your existing program.
Frequently asked questions
How many requirements does PCI DSS have?+
Twelve requirements, grouped into six control objectives spanning network security, data protection, vulnerability management, access control, monitoring and testing, and security policy.
Which PCI DSS requirement is hardest?+
It varies, but Requirement 3 (protecting stored account data) is often the most costly when data is stored unnecessarily, and Requirements 10 and 11 commonly generate findings because monitoring and testing are not sustained across the year.
Do all 12 requirements apply to every organisation?+
The requirements apply based on your cardholder data environment and how you handle payments. Reducing scope — through tokenization, segmentation and validated payment providers — reduces how much of each requirement applies to you.
Is MFA required for PCI DSS?+
Strong authentication, including multi-factor authentication for access into the cardholder data environment, is part of the access-control requirements. Confirm the current specifics against the standard for your environment.
How do I evidence PCI DSS requirements?+
Each requirement should be linked to concrete evidence — configurations, scan and test results, access reviews, logs and policies — kept current throughout the year so validation is a matter of filtering rather than collecting.