The scope decides the cost of the assessment, the number of findings and whether the report describes something real. This is how it works, with the examples we meet most, mostly in the cloud.
Three places a system can be
In the cardholder data environment. Anything that stores, processes or transmits card data, and anything on the same network segment as something that does. The payment page, the database with the card numbers, the terminal, the switch they share.
Connected to it, or able to affect its security. Systems that do not touch card data but can reach the environment, or shape what reaches it. The directory that authenticates the administrators. The key vault. The firewall and the rules engine in front of the environment. The identity service. The administrators’ laptops. The deployment pipeline that pushes code into it. The monitoring platform that reads its logs. These are in scope. Most requirements apply to them.
Out of scope. Systems that cannot reach the environment, cannot affect its security, and have been proven not to, by a segmentation test. Nothing is out of scope by declaration.
In scope
Cardholder data environment
Stores, processes or transmits account data.
- Payment applications
- Databases holding card data
- Networks that carry it
Connected and security-impacting
Can reach the CDE, or affects its security.
- Directory services
- Logging and monitoring
- Jump hosts
- Patch management
Segmentation, tested
Every 12 months, every 6 for service providers, and after changes.
Out of scope
Isolated systems
No path to the CDE, and the segmentation proves it.
- Corporate office network
- HR and finance
- Guest Wi-Fi
The mistake we see most
“It does not carry card data, so it is out of scope.” A payments company’s cloud scope document declared only the cluster networks in scope. Its hub and landing-zone subscriptions were marked out, even though they hosted the key vault, the edge service, the firewall and the identity service, all of which the company had itself listed as security-impacting. The inventory also left out the administrators’ laptops and the cluster worker nodes. A document store that held card numbers did not appear in the data flows at all, and the answer to “who can read it?” was “no access”, with nothing to say how privileged administrators were technically prevented from granting themselves that access.
None of these systems carried card data. Every one of them could decide what happened to it.
Write the scope by system, not by component type
“Virtual machines, databases, firewalls” is a list of categories. It cannot be checked against a configuration. A scope that can be checked names each system, puts it in one of the three places, says why, and names the control that keeps it there. The same company’s confirmed scope, when it finally arrived, had twenty-two systems, eleven zones, twenty-one flows and seven named segmentation controls. The report was written on that scope, and the company stood behind it, which is the test a scope has to pass.
Name the controls that actually do the segmenting. A private endpoint service was cited as the segmentation control; the network security groups and the firewall that actually filtered the traffic were not mentioned. Claims in the document, such as “the security groups only allow web ports”, were later contradicted by the configuration. Write what the configuration says, then make the configuration say what you want.
Write what the configuration says, then make the configuration say what you want.
The security group that pulls a system in
A cache instance in a start-up’s cloud environment had a security group that accepted traffic from the whole production network. The team wanted to class it as “connected”. It could not be, while that rule existed: if everything can reach it and it can reach the cardholder environment, it is a path into the environment, and it is in. Narrow the group, and it moves. Scope follows configuration, not intent.
Who can read the card data
“No access” is a claim about a technical control. The questions that turn it into evidence: how is a privileged administrator prevented from granting themselves access to the data plane, and if they did, where would it be logged, and who would read the log? If the honest answer is “they could, and it would not be”, then the administrators are in scope and the data is less protected than the document says.