PCI DSS scope assessment: how to get Requirement 12.5.2 right
Scope is the first decision in a PCI DSS assessment and the most expensive one to get wrong. What Requirement 12.5.2 actually asks for, what counts as a significant change, and the worksheets an assessor will want.
Scope is the first decision in a PCI DSS assessment and the most expensive one to get wrong. It sets how many systems get tested, how many people get interviewed, how long the work takes and what it costs. Everything else follows from it.
Most businesses treat scoping as a stocktake. They open the asset register, tick the systems they think handle card payments, and call that the answer. It is the wrong place to start, and it leads to one of two outcomes that both cost money.
The two ways scope goes wrong
Scope that is too wide is the quiet one. If your network is flat, with nothing keeping payment systems apart from the rest, everything is in scope by default. You then secure, log, patch and test hundreds of machines that never see a card number, and you pay for it again every year.
Scope that is too narrow is the loud one. Systems that can reach the cardholder data environment, the CDE, were left off the list. They turn up during testing, usually in the second week, and the work stops while they are brought in and fixed. Dates move.
There is a third, and it is the most common of all. The scope was right two years ago. Since then you moved something to the cloud, added a payment channel or bought a company, and nobody looked again.
Checking your scope is a requirement of its own
PCI DSS v4.0.1 does not treat scoping as preparation. Requirement 12.5.2 says you have to write your scope down and confirm it yourself at least once every 12 months, and again after any significant change to the environment. If an assessor asks to see that and you hand over a network diagram from two years ago, that is a finding before testing has even started.
Service providers are on a six month cycle. Requirement 12.5.2.1 asks for the same confirmation at least once every six months, and it stopped being a best practice on 31 March 2025. It is a full requirement now, so a service provider working to an annual rhythm is already behind. Requirement 12.5.3 adds a second trigger for service providers: a significant change to your organisational structure has to be followed by a documented internal review of the effect on scope, with the result reported to executive management. That one became a full requirement on the same date.
The standard also closes a gap that catches people out. This check is something you are expected to do, and it is not the same as, and is not replaced by, the scoping your assessor does. Hiring a QSA does not take care of 12.5.2. You are expected to turn up already holding your own written confirmation, and the assessor then tests it.
What counts as a significant change
The standard lists these for you rather than leaving it to judgement. Any one of them resets the clock: new hardware, software or network equipment added to the CDE; replacing or seriously upgrading hardware or software already in it; any change to how card data moves or where it is stored; any change to the edge of the CDE or to what the assessment covers; any change to supporting systems, which explicitly includes directory services, time servers, logging and monitoring; and any change to the outside companies that support the CDE.
Set against an ordinary year of IT work, that list is wide. Most businesses trigger it more than once between assessments, which is why a scope record dated at the last assessment is so often out of date already.
What is actually in scope
Scope is not just a list of servers. It is three kinds of system, plus the people and the processes around them.
The card number is what starts it. Wherever a card number, called the PAN, is stored, handled or sent, you have a CDE and the standard applies. Name, expiry date and service code need protecting too when you hold them alongside the card number. Full track data, security codes and PINs are different: you must not keep any of them once the payment is authorised, not even encrypted. Keeping them is one of the most serious findings there is.
The CDE itself
The systems, people and processes that store, handle or send card data, plus anything with an open connection to them, even if it never touches a card number.
Connected-to systems
Anything that can reach the CDE across the network. Jump hosts, admin machines, patching and monitoring tools, directory services.
Security-impacting
Anything that could affect how safe the CDE is without connecting to it. DNS, the redirect that sends shoppers to a payment page, login servers, deployment pipelines.
A system is out of scope only if all four of these are true: it does not store, handle or send card data; it is not on the same segment or VLAN as anything that does; it cannot connect to anything in the CDE; and it is not a connected-to or security-affecting system. Fail any one and it is back in.
A method that stands up
Scoping works when you start from the money rather than the asset register.
Card present, mail order and telephone order, e-commerce, recurring billing, refunds and chargebacks. Each is a separate flow with its own systems. Channels nobody owns, such as a sales team taking card numbers over the phone, are found here or not at all.
Follow the card data. Where it comes in, what it passes through, where it sits, where it goes out. Write down what form it is in at each step and who can see it. You want one diagram per channel, not one for the whole company.
Log files, error traces, email archives, call recordings, scanned paper, backups, reporting tools, and test systems built from live data. Storage nobody declared is the most common reason scope grows halfway through an assessment.
A call centre agent reading a card number aloud is in scope. So is the change process for the firewall that keeps your CDE apart.
Now is the time to design the separation, because now you know what you are separating.
Write down what you decided, why you left anything out, and who signed it off. That is the record Requirement 12.5.2 expects you to keep, annually for most entities and every six months if you are a service provider.
Segmentation is the only reliable way to shrink scope
PCI DSS does not require segmentation. It is simply the difference between assessing your payment environment and assessing your whole network. Without it your network is flat and everything is in scope, which is where an assessor has to stay if you cannot show the separation working.
An assessor tests four things. That the control is really there and really blocking, not a VLAN on paper with a permissive rule between segments. That somebody has tested it from the outside, proving that out-of-scope networks genuinely cannot reach the CDE. That it holds on every route, including admin, backup, monitoring, wireless and remote access. And that every exclusion has a written reason, rather than simply going unmentioned.
The controls doing that job are in scope themselves. That surprises people, and leaving them out undermines the very saving they give you.
None of this is a one-off exercise. Requirement 11.4.5 asks for penetration testing of the segmentation controls at least every 12 months and after any change to them, and Requirement 11.4.6 makes that every six months for service providers. The tester has to be organisationally independent of the people who run the controls, although the standard does not require a QSA or an ASV.
Eight mistakes we see over and over
An asset register tells you what you own, not where the money moves. Start from the payment channels and the register becomes a way to check your work instead of the source of it.
Payments over the phone put the agents, handsets, desktops and call recordings in scope. A recorded security code is a retention finding.
Test and development systems built from live data hold real card numbers, and are rarely built to the same standard.
Separate subscriptions are a boundary on the invoice, not on the network. Shared logins, peering and transit gateways all create routes in.
The firewall that holds your boundary is in scope, and so is the change process for it.
Directory services, patching, monitoring and backup nearly always reach into the CDE. Reaching in puts them in scope.
A provider’s status only helps you if you hold a current Attestation of Compliance for the service you actually use, and Requirement 12.8.4 expects you to check that status at least once every 12 months.
Scope describes a changing environment. Twelve months is the maximum interval for most entities and six months for service providers, and any significant change resets the clock.
Get the scope assessment worksheets
A ten page working guide built directly on Requirement 12.5.2, with the worksheets an assessor will ask you to complete: payment channels and data flows, account data storage including how access to it is logged, system inventory by category, segmentation position and the validation record itself. Enter your work email and we will send the download link. Free webmail (Gmail, Yahoo, Outlook and similar) is not accepted.
Where to start
If you are getting ready for an assessment, the most useful thing you can do before anyone arrives is fill in the channel and data flow worksheets honestly, including the flows you suspect nobody has written down. Scope conversations go quickly when that work is done, and slowly when it is not.
Cianaa is a PCI Qualified Security Assessor company, listed on the PCI Security Standards Council register since 2014, assessing across New Zealand, Australia, APAC, Europe and North America. If you would like your scope reviewed against what an assessor will actually test, book a scoping call.
Talk to Cianaa
Talk to our QSA team about scoping, gap remediation, and Report on Compliance under PCI DSS 4.0.1.
Book a discovery callGet the next one in your inbox
One email when we publish. Written by named auditors, never by a marketing robot. Unsubscribe anytime with one click.
