Free checker
PCI DSS scope checker
Find out which systems are genuinely in scope for PCI DSS v4, and which ones you can take out with segmentation.
Run it now
Answer the questions and you get the number, the working behind it and what we would do about it. The calculation itself runs in your browser, so your answers stay with you.
What you tell it
- How card data enters, moves through and leaves your environment
- Whether you store, process or only transmit cardholder data
- Payment channels: card present, e-commerce, telephone or in app
- Current network segmentation, if any
What you get back
- Systems in the cardholder data environment, connected to it, or out of scope
- The SAQ type you qualify for, or whether a full RoC is required
- Where segmentation would remove the most systems from scope
- Which v4 requirements apply given your channels
How the score is worked out
- 1
Scoping follows the PCI Security Standards Council guidance on scoping and network segmentation.
- 2
Connected to systems are treated as in scope, which is where most self assessments go wrong.
- 3
SAQ eligibility is decided by channel and by whether you touch card data, not by transaction volume alone.
- 4
Where v4 introduced a customised approach option, we flag it rather than assuming it.
Where this stops being useful
Scope is the single most expensive decision in a PCI programme and it is judged by your QSA, not by a form. Use this to prepare for that conversation, not to replace it.
Other tools
- Compliance effort estimatorWork out roughly how many person days a certification will take your team before you commit to a date.Open it
- Compliance cost estimatorA budget range for getting certified and staying certified, with the recurring costs people forget until year two.Open it
- VAPT and security testing cost estimatorPrice a penetration test properly, by counting the things that actually drive effort rather than by counting IP addresses.Open it
Scope is the whole game
The cardholder data environment includes every system that stores, processes or transmits account data, plus every system connected to or that could affect the security of those. That second clause is what expands scope beyond what people expect.
A jump host used to administer a payment server is in scope. A monitoring agent that runs on it is in scope. An authentication service that grants access to it is in scope. A flat network segment that can reach it puts everything on that segment in scope.
This is why two organisations processing identical volumes can face assessments that differ by a factor of five in cost. The difference is architecture, and it is decided long before anyone thinks about PCI.
The three ways to reduce scope, in order of effectiveness
Do not hold the data. Tokenisation and a properly integrated hosted payment page remove entire requirements from your assessment rather than helping you satisfy them. If the account data never touches your systems, those systems are out of scope. Note the word properly: an iframe implementation where your page can still read the fields does not achieve this.
Segment properly. Segmentation asserted in an architecture diagram and not enforced by a rule is not segmentation. Expect to demonstrate the rule and the change record behind it, and expect an annual independent segmentation test.
Consolidate. Fewer environments touching account data means fewer boundaries to evidence. Estates that grew organically frequently have two or three paths to the same data that nobody has removed because nobody has mapped them.
What this checker is doing
It walks your data flow and connectivity, and returns which categories of system fall in scope, which are connected-to, and where segmentation would remove the most.
It is deliberately conservative. Where an answer is ambiguous it counts the system in scope, because the expensive discovery is finding late that an assessor disagrees with an optimistic reading.
It does not replace an assessor's scope agreement. Get scope agreed in writing with your QSA before evidence collection begins; a scope disagreement discovered halfway through is the most expensive way to run an assessment.
What PCI DSS 4.0 changed here
The twelve requirements remain. What changed is how they can be satisfied, and two changes affect scoping decisions.
The customised approach lets you meet a security objective by another means, provided you document the objective, the control, the risk analysis and the testing. It is genuinely useful for architectures the defined controls do not fit, and it carries a heavier evidence burden. Choose it because the defined control does not fit, not because it is inconvenient.
Targeted risk analysis lets you set your own frequency for several requirements, which is an obligation to justify and review that frequency rather than a relaxation.
Neither changes the underlying economics: every hour spent reducing scope before an assessment saves considerably more during it.
Not sure where to start?
Book a 30-minute call with a senior engineer. We will walk through your current posture, the frameworks that bind you, and what a realistic programme looks like.