PCI DSS assessment covers 40 systems and costs a fortune annually. How would you reduce that architecturally?

The principle

Scope follows the data. Any system that stores, processes or transmits cardholder data is in scope and inherits the full control set. Reducing scope is therefore an architecture problem, not a compliance one — and it is one of the clearest cases where an architectural decision has a directly measurable financial return.

The moves, in order of impact

1. Tokenise at the earliest possible point. The card number is captured and immediately exchanged for a token; nothing downstream ever sees the real value. Systems handling only tokens fall out of scope. This is the single largest reduction available and it is what most organisations do.

2. Never let the card number touch your systems at all. Hosted payment fields or an iframe from the payment provider mean the card goes directly from the customer's browser to the provider. Your application receives only a token, and your scope reduces dramatically — potentially to the simplest self-assessment level.

3. Segment the network so that in-scope systems are genuinely isolated. Without segmentation the entire flat network is in scope, which is how 40 systems becomes 400. Segmentation must be demonstrable, and it must be tested — an assessor will ask for evidence that the boundary holds.

4. Consolidate the remaining in-scope systems. If tokenisation leaves five systems handling real card data, consider whether they can become one.

5. Remove stored card data entirely where the business allows. Recurring billing can use provider-held tokens rather than stored numbers.

What must not be forgotten in the scope analysis

Systems that can affect the security of in-scope systems are also in scope. Directory services, monitoring, logging, backup, configuration management, and the deployment pipeline. Teams tokenise the application and are surprised that their CI system remains in scope because it can deploy to the cardholder environment.

Logs. A card number in an application log puts the logging platform in scope, which is expensive.

The wider point

The same reasoning applies to every regulated data type. GDPR, HIPAA and sector regimes all follow the data, so isolating regulated data behind a narrow boundary removes obligation from the rest of the estate. It is worth doing before the first assessment, because retrofitting it means changing the systems the assessor has already examined.

What a strong answer adds

Noting that the payoff is not only the assessment cost. A smaller scope means fewer systems carrying the full control set — fewer change-management constraints, fewer access restrictions, faster delivery — which is a continuing benefit to engineering velocity rather than an annual saving.