What PCI DSS covers
The Payment Card Industry Data Security Standard applies to any organisation that stores, processes or transmits cardholder data. Unlike a government regulation, it is enforced contractually — by the card brands through your acquiring bank or payment processor — but the consequences of non-compliance, including fines and increased transaction costs, are real.
The standard is organised around twelve requirements grouped into six control objectives. They span network security, data protection, vulnerability management, access control, monitoring and security policy.
| Objective | Requirements |
|---|---|
| Build and maintain a secure network | Install and maintain network security controls; apply secure configurations |
| Protect account data | Protect stored account data; encrypt transmission across open networks |
| Maintain a vulnerability management programme | Protect against malicious software; develop and maintain secure systems |
| Implement strong access control | Restrict access by business need-to-know; authenticate users; restrict physical access |
| Regularly monitor and test networks | Log and monitor access to system components; test security regularly |
| Maintain an information security policy | Support information security with organisational policies and programmes |
Scope is the single biggest lever
Everything in PCI DSS begins with scope: the systems that store, process or transmit cardholder data, plus anything connected to them. The most effective compliance strategy is usually not implementing more controls — it is reducing what falls in scope in the first place.
- Do not store cardholder data unless you genuinely need it.
- Use tokenization so systems handle tokens rather than card numbers.
- Segment your network so the cardholder data environment is isolated from the rest.
- Use validated third-party payment pages or SDKs to shift handling to a compliant provider.
Validation levels and how you demonstrate compliance
How you validate depends on your role — merchant or service provider — and your annual transaction volume. Higher volumes require a Report on Compliance produced with a Qualified Security Assessor; lower volumes may permit a Self-Assessment Questionnaire. The specific SAQ type also depends on how you handle payments.
Define scope
Map data flows
Reduce scope
Tokenize & segment
Gap assess
Against 12 requirements
Remediate
Close gaps
Validate
SAQ or RoC
Maintain
Continuous, not annual
Common pitfalls to avoid
- Treating compliance as an annual event, when the standard expects controls to operate continuously.
- Underestimating scope by overlooking connected systems that can reach the cardholder data environment.
- Storing cardholder data out of habit rather than necessity, expanding scope for no business reason.
- Assuming a compliant payment provider makes you compliant — responsibility is shared, and your own obligations remain.