PCI DSS — practitioner guides.
25 articles on PCI DSS, ordered newest first. From the SentinelPanda team.
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.