Confirming your PCI scope every twelve months

PCI DSS 4.x asks you to confirm the scope of your cardholder data environment at least once a year. Last year's diagram with a new date on it does not meet it.

Scope is the foundation of everything else in PCI DSS. Every requirement applies to the cardholder data environment, so if the boundary is wrong, the assessment is measuring the wrong thing thoroughly.

Requirement 12.5.2 in PCI DSS v4.0.1 puts it plainly: PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment. Service providers have a shorter cycle - Requirement 12.5.2.1 asks them to do the same at least once every six months.

What the exercise is actually asking

Not "is the diagram still accurate". The question is whether anything has changed that moves the boundary, and the honest answer requires looking rather than remembering.

Things that move it, all of which happen without anyone filing a change request:

• A new payment channel, including a temporary one taken for an event or a campaign.
• A support process where staff read card numbers over the phone.
• A finance report that started including an unmasked column.
• A supplier change that alters how card data reaches you.
• Home working moving processing onto machines that never touch the office network.
• A shared drive or mailbox accumulating attachments over the year.

Why the paper exercise fails

The usual approach is to reconvene the people who drew the boundary last year and ask whether anything changed. They answer from what they know about the systems they run, which is accurate and incomplete in a specific way: it covers designed flows and misses accumulated ones.

Card data that arrives by accident is invisible to that method by definition. Nobody remembers the email a customer sent in March, and the person who screenshotted a payment confirmation did not think of it as changing the scope of an audit.

The standard also notes that this confirmation is expected to be performed by the entity, and that it is not the same as, nor intended to be replaced by, the scoping confirmation an assessor performs. Your QSA checking your scope does not discharge 12.5.2.

Running it so the evidence holds

1. 1Start from the previous boundary and the previous data flows, as the thing you are testing rather than the answer.
2. 2Search the estate for stored card data, including machines and shares that are not in the defined environment.
3. 3Investigate anything found outside the boundary: how it got there, whether the channel is still open, whether it is cardholder data or sensitive authentication data.
4. 4Remediate, and record what you removed and when.
5. 5Update the diagrams and the data flows to match what you found, not what you expected.
6. 6Keep the dated output. The search result is the evidence that the confirmation happened.

Step six is the one that turns this from an activity into evidence. A signed statement that scope was confirmed is weaker than a dated scan result showing what was searched and what was found.

How EmberHound fits

EmberHound scans enrolled company devices for stored card data and reports what it finds by location, with scan history retained. That gives the annual confirmation an observed answer to its central question, and gives the assessor a dated artefact rather than an assertion.

Scanning covers enrolled company devices wherever they are, which matters for the home-working case where a network boundary control cannot see the machine. Mailbox scanning is an add-on for the email channel.

This article is general information, not assessment advice. Your acquirer and your QSA determine what applies to you.