PCI DSS: the complete guide

PCI DSS is unusual among security standards: your obligations are driven almost entirely by how you handle card data, and you can reduce them dramatically by handling less of it. That makes scope the first and most valuable decision — worth more than any control you could implement.

Who it applies to

Anyone who stores, processes or transmits cardholder data, plus anyone who could affect its security. It is a contractual obligation flowing from the card brands through your acquirer, not a law — but the commercial consequences of non-compliance are real, including fines passed down and, after a breach, liability for forensic costs.

Levels and validation routes

Your merchant level depends on annual transaction volume, and it determines how you validate: larger merchants undergo an on-site assessment producing a Report on Compliance, smaller ones complete a Self-Assessment Questionnaire.

The SAQ type matters as much as the level, and it depends on exactly how payments are captured — a fully outsourced payment page, an embedded iframe, a direct post, or your own servers handling card data each map to a different questionnaire with very different requirement counts. Confirm your level and SAQ type before scoping anything; getting this wrong means assessing against the wrong requirement set entirely.

Scope reduction: the whole game

• Do not store card data. Tokenisation replaces the number with a token useless to an attacker and removes the largest category of obligation.
• Point-to-point encryption at the terminal so in-store systems never see readable card data.
• Hosted or embedded payment fields online, so details go to the provider rather than through your servers.
• Segment whatever remains, so the cardholder data environment is a handful of systems rather than your whole network.

Segmentation is one of the few security controls with a return a finance function recognises: it makes the recurring annual assessment smaller, every year. That argument funds work the security case alone often cannot.

The twelve requirements, in plain terms

Install and maintain network security controls; apply secure configurations; protect stored account data; encrypt transmission across public networks; protect against malware; develop and maintain secure systems; restrict access by business need to know; identify users and authenticate access; restrict physical access; log and monitor all access; test security regularly; and maintain an information security policy.

Nothing there is exotic. The difficulty is evidencing all of it, continuously, across a defined environment.

What version 4 changed

Structurally, the customised approach lets you meet a requirement's objective by another means — demanding to evidence, and intended for mature organisations whose architecture conflicts with the prescribed control, not as an easier path. Several requirements now defer frequency to a documented targeted risk analysis, which must exist on file.

The changes that cost real engineering effort: payment-page script inventory and tamper detection (the response to digital skimming, where the attack never touches your servers), MFA extended to all access into the cardholder data environment including internal console access, automated log review, and authenticated internal vulnerability scanning.

Where organisations get caught

• Scope drawn too narrowly — forgetting systems that can reach the cardholder data environment.
• Segmentation asserted but never tested, despite testing being explicitly expected.
• Firewall rule sprawl — a temporary any-any rule from an incident years ago still connecting two zones the diagram shows as separate.
• Compliance treated as annual when the requirements are continuous.

Detailed guidance

Key takeaways

• Confirm merchant level and SAQ type before scoping — they drive everything.
• Scope reduction beats any control you could implement.
• Segmentation must be tested, not asserted.
• v4's real cost is script controls, expanded MFA and automated log review.