The argument
Build a Defensible PCI DSS Scope Story
A defensible scope story connects account-data flows, system connectivity, administrative influence, security dependencies, segmentation controls, third-party services, and testing populations into one coherent explanation that can be challenged and updated.
The field pattern
The official inventory lists the payment application, database, and several network devices. The access-control narrative depends on an enterprise identity platform. Deployment uses a shared automation service. Logs flow to a central platform. A vendor tunnel crosses a segmented boundary. None of those supporting systems appears in the inventory because the inventory was built by searching for stored cardholder data.
Why it matters
The exact scope conclusion remains fact-specific. The practical failure is internal contradiction: one model explains data, another explains administration, and a third drives evidence collection. When those models disagree, exclusions become difficult to defend and testing populations lose context.
A scope story is durable when each conclusion points to current facts, an owner, and a verification method. It should survive a new assessor, a platform migration, and the departure of the person who remembers why the boundary was drawn.
Questions that expose the Wack
- Where does account data enter, move, rest, transform, and leave the environment?
- Which systems connect to or can affect the security of the CDE, including through administrative and control-plane paths?
- What controls support every segmentation claim, and how is their effectiveness verified?
- Do the diagrams, inventories, narratives, TPSP records, and evidence populations describe the same boundary?