Scope analysis
Mapping cardholder data flows end to end and identifying every system that stores, processes, transmits, or can affect the security of that data. Usually the point at which the real scope becomes visible for the first time.
Card data
PCI DSS Readiness
Most of the cost is decided by how much of your environment is in scope. Reducing that is the work that saves the most money.
Who this applies to. Any organization that stores, processes, or transmits cardholder data, or that can affect the security of a transaction.
What PCI DSS actually asks of you
PCI DSS applies to the cardholder data environment, and the boundary of that environment is drawn by how your systems connect rather than by how your org chart looks. Systems that can reach the environment are usually in scope too, which is how a small payments feature ends up dragging a corporate network with it.
That makes scoping the highest-value work in a PCI engagement by a wide margin. Tokenisation, redirect or iframe payment flows, and network segmentation can move whole classes of system out of scope, and each one removed is a system you no longer have to secure, evidence, and re-evidence every year.
How you validate depends on how you accept payments and your transaction volume, which your acquirer determines. Getting that answer before designing the program avoids building for the wrong target.
The engagement
What readiness covers
Scope reduction
Segmentation, tokenisation, and payment flow changes that take systems out of the environment permanently. This work pays for itself across every subsequent year of validation.
Gap assessment
Measuring the in-scope environment against the requirements and producing findings tied to specific requirements rather than a maturity score.
Remediation support
Closing gaps, with the requirements that need a period of operating evidence started first.
Validation preparation
Preparing for the self-assessment questionnaire or the assessor-led report your acquirer requires, including the evidence each requirement expects.
What you are left holding
Deliverables
- Cardholder data flow diagrams
- Documented scope boundary with segmentation rationale
- Scope reduction plan with the systems each change removes
- Gap register mapped to requirements
- Evidence pack aligned to your validation route
FAQ
PCI DSS questions we get asked
- How do we know which validation route applies?
Your acquirer determines it, based on how you accept payments and your annual transaction volume. Ask them before you design the program, because building toward the wrong validation route is expensive and common.
- Can we reduce scope enough to make this small?
Often, yes, and it is the first thing worth investigating. Moving to a hosted payment page or a tokenisation provider can remove most systems from the environment. The work is not free, but it is paid once and it reduces every future year of validation.
- Do you perform the assessment?
No. Where an assessor-led report is required it is performed by a Qualified Security Assessor. We prepare you for it and can support you during it.
Reviewed July 31, 2026. Primary sources: PCI Security Standards Council, document library .
Start with scope, not with a proposal
The first conversation is about what is actually in scope, because that governs the cost of everything after it.