PCI DSS
PCI DSS
Twelve requirements. One question: where does card data actually live?
Protecting payment card data if you store, process, or transmit it.
Who it's for. Merchants, processors, and anyone whose “we don’t store cards” statement is a little optimistic.
01
Scope first or suffer
Official-ish
PCI applies to the cardholder data environment (CDE) and connected systems.
Monday version
If card data leaks into logs, screenshots, or a helpful CRM, that system just joined the CDE. Segmentation is how you stay sane.
Do this
- Draw the data flow from swipe/key-entry to settlement.
- Kill card data you do not need. Tokenize the rest.
- Treat “connected to CDE” as in-scope until you prove isolation.
02
The twelve, without the binder
Official-ish
Requirements cover network security, hardening, protect stored data, encryption in transit, malware, secure systems, access control, unique IDs, physical, logging, tests, and policy.
Monday version
Firewall the CDE, don’t store PAN in Slack, encrypt, patch, unique users, log, scan, write it down. That is the hit parade.
Do this
- Never store the security code or full track data after authorization.
- MFA for all access into the CDE.
- Quarterly scans and an annual pentest that include the actual CDE.
03
Levels and evidence
Official-ish
Merchant/service-provider levels change whether you do a SAQ or a full ROC with a QSA.
Monday version
Volume and role decide how painful the paperwork is. The controls do not get optional just because you are “small.”
Do this
- Know your level and the correct SAQ type before audit week.
- Keep evidence as you operate, not as a scavenger hunt in March.
- If you outsource, read the responsibility matrix like it is a contract — because it is.
Friendly translation, not legal advice. Always read the official text before you tell an auditor you “basically already do this.”