PCI DSS — practitioner guides.
43 articles on PCI DSS, ordered newest first. From the SentinelPanda team.
PCI DSS Requirement 1: network security controls
v4.0 stopped saying "firewall" and started saying "network security control" — a deliberate change that finally lets cloud security groups count as what they always were.
PCI DSS Requirement 2: secure configurations
Every default password shipped by a vendor is public knowledge. Requirement 2 starts there and ends up somewhere more useful: a configuration standard you can actually audit against.
PCI DSS Requirement 3: protect stored account data
The cheapest way to satisfy Requirement 3 is to not store account data at all. Everything else in this requirement is the price of deciding otherwise.
PCI DSS Requirement 4: encryption in transit
Requirement 4 is short and mostly uncontroversial, with one clause that catches organisations repeatedly: nobody may send a PAN over chat, SMS, or email.
PCI DSS Requirement 5: anti-malware
The old "install antivirus on Windows machines" requirement grew up in v4.0 — it now expects a reasoned argument about every system you chose not to protect.
PCI DSS Requirement 6: secure systems and software
Requirement 6 is where PCI DSS meets your software delivery process — and where v4.0 added the anti-skimming controls that came out of a decade of Magecart attacks.
PCI DSS Requirement 7: need-to-know access
Requirement 7 is about who should have access. Requirement 8 is about proving they are who they claim. Conflating the two is the most common structural mistake in PCI access control.
PCI DSS Requirement 8: identity and authentication
Two v4.0 changes here have caught more organisations than anything else in the standard: 12-character passwords, and MFA for all access into the cardholder data environment.
PCI DSS Requirement 9: physical access
Cloud-hosted teams assume Requirement 9 is inherited from their provider. Most of it is. The parts that are not — media, offices, and card-reading devices — are the parts that fail.
PCI DSS Requirement 10: logging and monitoring
v4.0 quietly ended the era of the daily manual log review. Automated mechanisms are now required — which is an acknowledgement that nobody was reading them anyway.
PCI DSS Requirement 11: security testing
Requirement 11 is the one with the most external dependencies and the least forgiving calendar. Four passing ASV scans a year cannot be assembled retroactively.
PCI DSS Requirement 12: policies and programs
The requirement people skim because it looks like paperwork. It contains the targeted risk analysis machinery the rest of v4.0 depends on, and the scope validation everything else rests on.
PCI DSS vs ISO 42001
These are orthogonal standards, and for most organisations only one applies. The exception is worth understanding: AI models trained on payment data.
PCI DSS vs ISO 27001
One is a prescriptive control list scoped to card data and imposed by contract. The other is a risk-based management system you scope yourself and get certified against. They are not alternatives.
PCI DSS vs SOC 2
One you must do because a contract says so. The other you do because your buyers ask. Fintechs typically discover they need both, in that order.
PCI DSS vs HIPAA
A clinic that takes card payments is subject to both — a prescriptive card-brand contract and a flexible federal statute, over two different data types, at the same time.
PCI DSS vs the NIST CSF
PCI DSS is a compliance obligation with a deadline. The NIST CSF is a way of organising your whole security program. The second is where the first should live.
PCI DSS vs COBIT 2019
COBIT decides how IT gets governed. PCI DSS decides what happens to card data. One is the operating model, the other an obligation running inside it.
Network segmentation to shrink PCI scope
Everything that can reach the cardholder data environment is in scope. Segmentation draws the boundary — done well, it can take dozens of systems out of your SAQ.
PCI compensating controls, done right
A compensating control is not an excuse to skip a requirement. It is a different control that meets the intent and rigour of the original — and it has to be justified in writing.
Tokenization for PCI scope reduction
If your systems only ever hold tokens, most of them fall out of PCI scope — because a token, on its own, is worthless to an attacker.
PCI DSS penetration testing requirements
A penetration test is not the same as an ASV scan, and not every merchant needs one. Here is what PCI actually requires and when.
PCI DSS multi-factor authentication requirements
PCI DSS 4.0 pushed MFA well beyond remote admin access. If card data is involved, the bar is now "MFA for all access into the CDE."
Inside the PCI Attestation of Compliance (AOC)
The SAQ is the work. The AOC is the one signed page that proves you did it — and the document your acquirer actually files.
The complete PCI DSS SAQ walkthrough: a step-by-step guide
Most SAQ guides stop at "pick the right type." This one walks the entire cycle end-to-end — what to gather before you start, how to read each requirement, what evidence actually satisfies it, and what happens after you submit.
SAQ A walkthrough: fully outsourced e-commerce
SAQ A is among the shortest PCI SAQs but the easiest to misuse. The eligibility bar is strict; the 4.0.1 script controls trip up almost everyone the first year.
SAQ A-EP walkthrough: e-commerce that partly controls the payment
SAQ A-EP is what you actually need when your payment page is "mostly outsourced." Substantially heavier than A; substantially shorter than D.
SAQ B walkthrough: standalone dial-out terminals
SAQ B is the smallest PCI SAQ. It assumes a very narrow setup — and the moment your terminal touches IP, you switch to SAQ B-IP.
SAQ B-IP walkthrough: standalone IP-connected terminals
SAQ B-IP sits between SAQ B and SAQ C. The terminal is "smart" (IP-connected) but standalone (not integrated into a POS system).
SAQ C walkthrough: payment application on an internet-connected POS
SAQ C is for the integrated POS case: a payment application on a system you operate, connected to the internet, no card storage. Heavier than B-IP, lighter than D.
SAQ C-VT walkthrough: virtual terminal on a dedicated computer
SAQ C-VT is narrow: a virtual terminal in a browser, one computer, one transaction at a time, no storage. The "isolated computer" requirement is the hard bit.
SAQ P2PE walkthrough: validated point-to-point encryption
SAQ P2PE is the shortest SAQ and the most attractive — but only if you use a PCI-listed P2PE solution. Self-built "encryption" does not qualify.
SAQ D-Merchant walkthrough: when none of the others fit
SAQ D-Merchant is the comprehensive SAQ. If you do not qualify for A through P2PE, this is where you land — closest to a full ROC in coverage.
SAQ D-Service Provider walkthrough
Service providers carry obligations merchants do not. SAQ D-Service Provider is the eligible self-assessment route for service providers below the Level 1 threshold.
PCI DSS non-compliance: fines, fees, and downstream costs
PCI is enforced through contracts, not statutes. That makes the penalties less visible than a regulatory fine — and often more expensive once you add them up.
PCI DSS scope reduction: how to shrink your CDE
Every system in your cardholder data environment is a system you have to secure and assess. The cheapest control is the one you remove from scope entirely.
PCI DSS quarterly ASV scans: what they cover and how to pass
ASV scans are the most visible recurring PCI obligation: four passing attestations a year on every internet-facing system in scope. Knowing how the scan thinks is how you stop them from owning your quarter-end.
PCI scoping: identifying your cardholder data environment
The PCI requirements only apply to systems in scope. Defining scope is the first and most consequential decision in any assessment, and the easiest one to get wrong.
PCI DSS service provider levels and what SaaS owes
If your software handles card data on behalf of your customers, you are a service provider in the PCI DSS sense. The customer-facing AOC you owe is one of the most common compliance artifacts you will be asked for.
Which PCI SAQ type applies to you?
The right SAQ depends entirely on how you handle card data. Pick the wrong one and you either over-report or, worse, under-scope.
Completing a PCI DSS Self-Assessment Questionnaire, step by step
The SAQ is short next to a full Report on Compliance, but it is still an annual evidentiary document with real legal weight. Treating it like a form-filling exercise is how programs end up missing things.
PCI DSS 4.0.1: what changed and how to prepare
PCI DSS 4.0 (refined as 4.0.1) is the largest revision of the standard in a decade. Here is what actually changed, and a pragmatic order to tackle it.
PCI DSS merchant levels (1 through 4), explained
Your merchant level decides the validation path. Knowing where you sit, and what triggers a promotion, is the difference between a quarter of self-assessment work and a year of ROC fieldwork.