PCI DSS gap analysis: what it covers, what you get and how it differs from the QSA's assessment

What a PCI DSS gap analysis is for

Most organisations arrive with an acquirer deadline, a contract clause or a questionnaire they no longer want to sign. The gap analysis gives them an accurate picture of the distance to the standard. It is the first stage of a Sterling engagement, and it turns a twelve-requirement standard into specific pieces of work, ranked by risk.

It is tested against PCI DSS v4.0.1, the only active version, including the requirements that were future-dated under v4.0 and became mandatory on 31 March 2025. Those items, such as MFA for all access into the cardholder data environment and payment page script controls, are where older programmes most often fall short. Our guide to what changed in v4.0.1 covers them in detail; the gap analysis simply checks whether you meet them.

Scope and data flows come first

An assessment of controls is worthless if it assesses the wrong systems. So the first days of the gap analysis are spent confirming where account data enters the business, every place it is processed, stored or transmitted, and where it leaves. That means walking each payment channel with the people who run it, from checkout and call-centre payments to refunds, chargebacks and batch files exchanged with processors.

The output of this step is a validated set of data-flow diagrams and a proposed boundary for the cardholder data environment, with the systems connected to it. Three things often emerge. Card numbers turn up in e-mail, ticketing tools, call recordings or spreadsheets. Networks described as segmented turn out not to be. And some channels could be taken out of scope entirely through a hosted payment page, tokenisation or point-to-point encryption. We note those opportunities in the report; designing the reduction belongs to our guide on scoping and segmentation.

Requirement by requirement: four lenses on every control

Each of the twelve requirements, and the sub-requirements beneath them, is examined the way an assessor would approach it. A policy alone satisfies nothing, and neither does a sound firewall with no record that its rules are reviewed. We therefore look at every control through four lenses and record a finding only when we can say which lens failed.

Each finding is rated: met with evidence, partly met, not met, or not applicable with a justification the assessor is likely to accept. Where a requirement cannot be met as written, we note whether a compensating control or the customised approach might be appropriate, and point to our guide on those options rather than settling it in the gap analysis.

The third-party responsibility matrix

Few organisations handle card data entirely on their own. Gateways, hosting and cloud providers, managed security services and software vendors each carry part of the burden, and PCI DSS expects you to know which part. A provider's Attestation of Compliance rarely covers everything it touches.

During the gap analysis we list every third party that stores, processes or transmits account data for you, or that could affect the security of the environment. For each one we record whether a current AOC is available, which requirements the provider manages, which it shares with you and which remain entirely yours. The result is a responsibility matrix, requirement by requirement, that the QSA will expect to see and that your contracts should reflect. These gaps are often contractual and slow to close, so we flag them early.

How it differs from the readiness check and the QSA's assessment

Three activities look at readiness from different distances, and confusing them leads to questionnaires signed on self-assessments that were never tested.

Because Sterling helps you build the controls, Sterling does not validate them. The QSA assesses and attests; for organisations eligible for self-assessment, an executive of your company signs the SAQ and its AOC and your acquirer accepts it. The full sequence is set out in our guide to validation step by step.

What you receive at the end

• The gap report. Validated scope and data-flow diagrams, the findings for every requirement with the lens that failed, and the evidence reviewed.
• A prioritised remediation plan. Actions ranked by risk to card data and by what would stop an assessment, with scope-reduction options first, then controls, then the periodic tasks that must run before validation. Each action has an owner and a date.
• An effort estimate. Internal time by function, technology likely to be needed (logging, MFA, segmentation, tokenisation and the like) and external testing still to be commissioned.
• A route recommendation. Whether your situation points to a self-assessment questionnaire, and which type, or to a Report on Compliance. The final word on level and route rests with the acquirer and the card brands; our guide to SAQ eligibility explains the types.
• The third-party responsibility matrix, ready to be reflected in contracts and in your provider register.

Who needs to be in the room, how long it takes, and what follows

The gap analysis is only as good as the access it gets. Plan for a sponsor with authority over budget; a coordinator who books sessions and chases evidence; network, systems and cloud administrators; the development lead where payment pages or software are involved; the heads of each payment channel; finance for refunds and chargebacks; HR for joiners, leavers and screening; and whoever manages supplier contracts.

Duration depends on the number of payment channels and sites, how complete your current network and data-flow documentation is, the number of third parties, whether you are a merchant or a service provider, and how quickly people and evidence are made available. We confirm the schedule in the proposal once these are known.

Afterwards the work moves into scope reduction and remediation, then an internal assessment before the QSA arrives. Our implementation plan guide describes those phases and owners.

PCI DSS gap analysis: questions buyers ask