Determining and Reducing Your Cardholder Data Environment

What is Included in the Scope?

There are three main categories:

1. Systems that handle cardholder data

These are systems that store, process, or transmit cardholder data. They form the core of your cardholder data environment.

2. Systems connected to these systems

This includes systems that can connect to the cardholder data environment, such as systems on the same network or systems that have access to it.

3. Systems that can affect its security

Some systems may not directly handle card data but can still affect its security.

Examples include:

• Authentication and directory services

• Security and monitoring systems

• Name resolution services

• Virtualisation hosts

• Administrative or remote access systems

For example, a jump server used to manage card data systems may be in scope. The directory service used to authenticate users to those systems may also be in scope.

________________________________________

Step 1: Understand the Data Flow First

Before creating a list of systems, understand how card data moves through your organisation.

Map the complete payment process for each channel, such as:

• E-commerce

• Telephone payments

• Card-present transactions

• Recurring payments

• Refunds

• Chargebacks

Follow the card number from the moment the customer provides it until it reaches authorisation and settlement.

At each stage, identify:

• What receives the card data

• Where it is stored

• What systems process it

• Whether it appears in logs

• Which systems send it to the next stage

Do this separately for each payment channel because the process can be different. Telephone payments are often an area where organisations discover unexpected card data handling.

________________________________________

Step 2: Scan for Card Data

Do not depend only on your data-flow diagrams.

Perform discovery scans across:

• File systems

• Databases

• Email systems

• Shared folders

• Backups

• Spreadsheets

• Test environments

Look for patterns that indicate card numbers.

This can reveal card data that was not identified during the initial mapping—for example, card numbers stored in logs, exported reports, spreadsheets, backups, or testing systems.

________________________________________

Step 3: Talk to the People Doing the Work

Process owners can explain how the process is supposed to work. However, employees who handle payments, disputes, refunds, and chargebacks know how the process actually works.

Ask them:

• What happens when the normal system does not work?

• How are exceptions handled?

• Do they use spreadsheets or email as a workaround?

• Where is card information recorded during manual processes?

These conversations often uncover unofficial processes where card data is being handled without proper documentation.

________________________________________

Step 4: Remove Card Data Wherever Possible

Before trying to secure every system, first ask:

"Does this system really need to have card data?"

If the answer is no, remove it.

Stop storing card data in logs

Applications sometimes record complete transaction details in logs. Full card numbers are usually unnecessary and should not be logged.

Stop receiving card data through email

Create a process to reject, remove, and properly handle emails containing card information.

Review call recording

Make sure call recordings do not capture card numbers. Use properly configured pause/resume functions or another payment method where agents do not need to hear the card number.

Remove production card data from test systems

Do not use real card data for testing. Use synthetic, masked, or tokenised data instead.

Replace spreadsheets

If employees are using spreadsheets to manage card information, understand why they need them and fix the underlying process rather than simply creating another secure spreadsheet.

Every place where card data is completely removed can potentially reduce your PCI DSS scope.

________________________________________

Step 5: Reduce the Remaining Scope

Once unnecessary card data has been removed, look for ways to further reduce the environment.

Use a payment service provider

Where appropriate, redirect customers to a validated payment provider so card data goes directly to the provider instead of entering your systems.

Use tokenisation

Replace card numbers with tokens so other business systems do not need to handle actual card data.

Use point-to-point encryption

In card-present environments, use appropriate encryption technologies to protect card data during transmission.

Segment the network

Separate the cardholder data environment from the rest of the organisation's network. Proper segmentation can prevent unnecessary systems from being included in the PCI DSS scope.

________________________________________

Step 6: Test Your Network Segmentation

If you are relying on network segmentation to reduce your PCI DSS scope, do not simply document that the networks are separated—test it.

The testing should confirm that systems outside the cardholder data environment cannot access systems inside it.

Keep evidence of:

• How the segmentation was tested

• What was tested

• When it was tested

• The results of the testing

• Any issues identified and corrected

If segmentation is not properly tested, you may not be able to rely on it for reducing your PCI DSS scope.

________________________________________

Step 7: Document and Keep the Scope Updated

PCI DSS scope documentation should be maintained as a living document.

It should include:

• Data-flow diagrams

• Network diagrams

• System and application inventory

• Segmentation details

• Segmentation test results

• Card-data discovery scan results

Review the scope whenever there is a significant change, such as:

• A new payment channel

• A new payment provider

• A new application

• A network change

• A new business process involving payments

The scope should always reflect the current payment environment, not how it looked several months ago.

________________________________________

Common PCI DSS Scope Weaknesses

1. Scope is based only on the system inventory instead of actual card-data flows.

2. Card-data discovery scans are not performed, so the scope is based on assumptions.

3. Telephone payments, refunds, or chargebacks are overlooked.

4. Systems that can affect the security of the cardholder data environment are not considered.

5. Network segmentation is used to reduce scope but is not properly tested.

6. Real cardholder data is present in test or development environments.

7. The PCI DSS scope is not reviewed when the payment environment changes.

8. Card data is removed from live systems but remains in backups.

The Key Principle

The best way to reduce PCI DSS scope is not simply to secure more systems—it is to reduce the number of systems that need to handle cardholder data in the first place.

Map the data → Find where it exists → Remove unnecessary data → Reduce connectivity → Test segmentation → Document and review regularly.