Generally no. PCI DSS 6.5.5 says live PANs are not used in pre-production environments, except where those environments are included in the cardholder data environment and protected in line with every applicable PCI DSS requirement. For testing, use test card numbers or synthetic data instead. This is not legal advice.
Definitions
PAN: primary account number, the card number. It is part of cardholder data.
Live PAN: a real card number, as opposed to a number issued for testing.
Pre-production environment: development, test or staging systems that are not serving production traffic.
What the text says
6.5.5: "Live PANs are not used in pre-production environments, except where those environments are included in the CDE and protected in accordance with all applicable PCI DSS requirements." The expected testing includes observing testing processes and examining pre-production test data.
Related: 6.5.6 says test data and test accounts are removed from system components before they go into production. And 6.5.3 says pre-production is separated from production with access controls.
Options for test data
| Option | Live PAN involved | Effort | Note |
|---|---|---|---|
| Payment provider test numbers | No | Low | Provided for sandbox testing |
| Synthetic generated numbers | No | Low | Make sure they cannot collide with real cards |
| Tokens from a sandbox | No | Low | Test token flows end to end |
| Masked production copy | Risk of leftovers | High | Verify masking, and check logs and backups |
| Live PANs in a staging CDE | Yes | Highest | Whole environment must meet PCI DSS |
The last two rows carry the most risk. Copying production data to test is a common way cardholder data ends up where it should not be, including in logs and backups.
Steps
- Ban production database restores into test unless data is scrubbed and verified.
- Document which test numbers are approved.
- Scan test databases and logs for patterns that look like card numbers.
- Delete test accounts and data before go live (6.5.6).
- Record the checks so you can show an assessor.
Quick check
Is a masked copy of production data allowed?
If it contains no live PANs, 6.5.5 is not triggered. You need to be able to show the masking is irreversible and complete.
What if a developer pastes a real card into a bug ticket?
That is a cardholder data handling issue outside 6.5.5 alone. Treat it as an incident under your procedures and remove it.
On Safeguard: policies and gates run configured checks on pull requests, and compliance and evidence automation keeps records of those checks. Neither detects card numbers for you, so pair them with your own data scanning. Try the free scan at gold.safeguard.sh/scan.
Sources
Wording is from v4.0. Confirm in the current version.
Last reviewed: 19 October 2026.