Live PANs Not in Pre-Production

“Live PANs not in pre-production” sounds simple until you map it to how engineering teams actually work: ad-hoc database copies, “temporary” troubleshooting dumps, integrated QA environments, and third-party tools that quietly ingest data. The compliance intent is to prevent real cardholder data from spreading into less-controlled environments where logging, access, patching, and monitoring are weaker.

For a CCO, compliance officer, or GRC lead, the fastest path is to (1) define what counts as “pre-production” across your SDLC, (2) implement technical controls that stop live PANs from entering those environments, (3) create an exception path that forces CDE inclusion if live PANs are truly required, and (4) retain evidence that you enforce the rule, not just document it.

This page breaks Requirement 6.5.5 into practical steps you can assign to Engineering, Security, and IT Ops, plus the artifacts your QSA or internal audit team will ask for. It’s written for operators who need to close the gap quickly without guessing what “good” looks like under PCI DSS 4.0.1.

Regulatory text

Requirement statement (verbatim): “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.” (PCI DSS v4.0.1 Requirement 6.5.5)

Operator meaning:

• Default rule: no live PANs in dev, test, QA, staging, UAT, performance, or sandbox environments.
• Only allowed exception: if you insist on live PANs in pre-production, you must treat that environment as CDE and apply all applicable PCI DSS controls to it, with the same rigor as production (PCI DSS v4.0.1 Requirement 6.5.5).

Plain-English interpretation (what the requirement really asks)

You must prevent real card numbers from appearing in pre-production systems because those systems are commonly less locked down and more broadly accessed. “Pre-production” includes any environment used to build, integrate, test, validate, troubleshoot, or demonstrate changes prior to production release.

The key compliance fork is:

Scenario	Live PAN appears in pre-prod?	What PCI expects
Normal, preferred	No	Use synthetic/test data, tokenized values, or masked datasets. Keep pre-prod out of CDE scope.
Exception path	Yes	Bring the environment into the CDE and meet all applicable PCI DSS requirements for it. Document the scope change and controls.

If your teams routinely refresh staging from production, this requirement is aimed directly at that practice unless you have strong data transformation that removes live PANs before the copy lands.

Who it applies to (entity + operational context)

Entities: Merchants, service providers, and payment processors that store, process, or transmit cardholder data and are in scope for PCI DSS assessments (PCI DSS v4.0.1 Requirement 6.5.5).

Operational contexts where it shows up:

• Engineering teams cloning production databases to QA/staging for bug reproduction.
• Data/analytics teams piping transaction data into test warehouses or BI sandboxes.
• Customer support or fraud teams exporting datasets for “testing rules.”
• Third parties (e.g., APM, logging, test automation, CI/CD plugins) receiving payloads containing PANs from lower environments.
• Performance testing where engineers want “realistic” data patterns.

What you actually need to do (step-by-step)

1) Define and inventory “pre-production” environments (make it auditable)

Create a single inventory that includes:

• Environment name, purpose, owner, and location (cloud account/subscription, VPC/VNet, cluster).
• Data sources feeding the environment (DB refresh jobs, ETL, message queues, object storage).
• Tooling connected to it (logging, APM, CI/CD, ticketing integrations, third parties).

Practical tip: If you cannot confidently list all non-prod environments, you cannot credibly claim live PANs are not there.

2) Set a policy rule that is enforceable, not aspirational

Your policy should state:

• Live PANs are prohibited in all pre-production environments.
• Allowed test data types (synthetic PANs, PCI test card numbers, tokens that cannot be reversed outside the CDE, masked values).
• The only exception: pre-production environments that are explicitly included in the CDE and protected under applicable PCI DSS requirements (PCI DSS v4.0.1 Requirement 6.5.5).
• Roles authorized to approve exceptions, and the required compensating controls (or scope inclusion) before any data moves.

3) Stop production-to-nonprod copying unless PAN is removed before landing

Implement at least one preventative mechanism (preferably several):

• Data masking/tokenization at export: Transform PANs before leaving production/CDE-controlled systems.
• Controlled refresh pipeline: A single approved job for DB refreshes that applies transformations and logs evidence.
• DLP gates on storage endpoints: Block writes of PAN-like patterns to non-prod buckets, shares, or databases where feasible.
• CI/CD secrets and config checks: Prevent non-prod apps from pointing at production payment services or production databases.

Your goal is to make “copy prod to staging” fail by default unless the approved sanitization path is used.

4) Reduce accidental collection: logging, tracing, and test tooling

Live PANs often land in places nobody considers “data stores”:

• App logs and exception traces
• APM payload capture
• Message queue replays
• Debug endpoints
• Test automation screenshots or HAR files

Add engineering requirements:

• Never log PAN fields (including partials beyond what your standards allow elsewhere).
• Redact sensitive fields at the logger/middleware layer.
• Disable verbose request/response capture in non-prod by default.
• Treat “debug dumps” as prohibited if they can contain PAN.

5) Put detective controls in place (prove it stays clean)

Even strong controls fail. You need detection plus response:

• Scheduled scans of non-prod databases and object stores for PAN patterns.
• Alerts when suspected PAN is detected in non-prod.
• An incident workflow: triage, containment, deletion, root cause, and control fix.
• A recurring attestation by environment owners that their environment does not contain live PAN.

This is where many programs fall down: they have policy and masking “in theory,” but no ongoing verification.

6) Build a strict exception path (and treat it like a scope decision)

If a team claims they “need” live PANs in pre-prod (common for payment integration testing), force a structured decision:

• Business justification and duration.
• Confirmation that the environment will be added to CDE scope.
• Security architecture review and QSA/internal approval as appropriate.
• Evidence that all applicable PCI DSS requirements are implemented for that environment (PCI DSS v4.0.1 Requirement 6.5.5).

If you cannot or will not bring the environment into CDE compliance, the answer must be “no.”

7) Manage third parties that touch pre-production

Pre-production frequently connects to third-party services (test tooling, APM, CI/CD add-ons). You need contract and configuration controls that prevent live PAN transmission to those third parties, unless they are in scope and protected appropriately.

Where Daydream fits: Daydream can centralize third-party due diligence workflows for tools connected to non-prod (APM/logging/QA platforms), track whether they may receive sensitive fields, and keep the evidence package aligned to your PCI control narrative without chasing spreadsheets.

Required evidence and artifacts to retain

Aim for evidence that shows prevention + detection + response:

Governance

• Policy/standard banning live PAN in pre-prod and defining exception rules (PCI DSS v4.0.1 Requirement 6.5.5).
• Data classification/handling standard that covers non-prod.

Environment and data flow proof

• Environment inventory (non-prod list) with owners and diagrams.
• Data flow diagrams showing where PAN can enter/exit.

Technical controls

• Masking/tokenization design and implementation records (config snippets, job definitions).
• DLP rules or storage controls relevant to non-prod endpoints.
• Logging redaction configuration and code review checkpoints.

Monitoring and validation

• Scan schedules, scan outputs, and remediation tickets.
• Sample alerts and incident records for any findings (even “false positives” should show handling).
• Exception register: approvals, scope decision, and closure evidence.

Common exam/audit questions and hangups

Expect assessors to probe these areas:

• “Show me how you prevent production DB refreshes into staging with PAN intact.”
• “What environments do you classify as pre-production, and how do you know you found them all?”
• “How do you detect PAN in object storage, logs, and APM?”
• “If you ever used live PAN in pre-prod, show the evidence that environment is in the CDE and meets applicable PCI DSS requirements.” (PCI DSS v4.0.1 Requirement 6.5.5)
• “What about third parties connected to non-prod? Could they ingest PAN?”

Hangup to preempt: teams often argue “it’s encrypted.” Encryption alone does not satisfy the requirement if live PAN is present in pre-prod unless the environment is treated as CDE and protected accordingly (PCI DSS v4.0.1 Requirement 6.5.5).

Frequent implementation mistakes (and how to avoid them)

1. Relying on policy without enforcement.
   Fix: add gating controls (sanitized refresh pipeline, DLP checks) and monitoring scans with tickets.

2. Forgetting non-prod logs and observability tools.
   Fix: add redaction at the application boundary and configure APM/logging to avoid payload capture.

3. Assuming “staging is production-like” is acceptable.
   Fix: either keep it PAN-free or formally include it in CDE and apply PCI controls (PCI DSS v4.0.1 Requirement 6.5.5).

4. No exception register.
   Fix: maintain a living exception log tied to architecture approval and scope management.

5. Third parties connected to non-prod get ignored.
   Fix: treat test and monitoring vendors as third parties in your risk process; confirm data handling and restrict fields sent.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog, so this page does not list specific cases. Practically, this control exists because non-prod commonly has broader access, weaker monitoring, and more “temporary” workflows that become permanent. If live PAN shows up there, your breach surface expands and your PCI scope can expand overnight.

Practical 30/60/90-day execution plan

First 30 days (containment and visibility)

• Publish the “no live PAN in pre-prod” standard with an exception path tied to CDE inclusion (PCI DSS v4.0.1 Requirement 6.5.5).
• Build an environment inventory: dev/test/QA/staging/UAT/perf sandboxes plus connected tools and third parties.
• Freeze uncontrolled production-to-nonprod refreshes until a sanitized pipeline exists.
• Implement quick-win log redaction defaults for known PAN fields.

By 60 days (prevention + detection)

• Stand up a single approved data refresh mechanism that masks/tokenizes PAN before it lands in non-prod.
• Add scanning/detection over likely sinks (databases, object storage, log stores) and route findings into a tracked remediation workflow.
• Create an exception register and require architecture/security sign-off for any request that would introduce live PAN into pre-prod.

By 90 days (audit-ready operations)

• Run a repeatable evidence pack: inventory, diagrams, scan outputs, and remediation records.
• Validate third-party connections to non-prod and document data-sharing restrictions.
• Conduct an internal control test: attempt to move a dataset with PAN into non-prod and verify prevention/detection triggers.
• If any pre-prod environment must contain live PAN, formally include it in CDE scope and document how it meets applicable PCI DSS requirements (PCI DSS v4.0.1 Requirement 6.5.5).

Frequently Asked Questions

Does tokenized PAN count as “live PAN” in pre-production?

The requirement is explicit about “live PANs” (PCI DSS v4.0.1 Requirement 6.5.5). If your token cannot be used to reconstruct PAN outside controlled systems and pre-prod never handles the real PAN, teams commonly treat that as an acceptable approach, but document your design and keep the real PAN out of pre-prod.

What if we mask PAN in the UI but store the full PAN in the staging database?

That still means live PAN exists in pre-production storage. Requirement 6.5.5 prohibits that unless the environment is included in the CDE and protected under all applicable PCI DSS requirements (PCI DSS v4.0.1 Requirement 6.5.5).

Can we copy production data to QA if we encrypt the QA database?

Encryption does not change the fact that live PAN is present in pre-prod. You either remove/replace PAN before it reaches QA, or you include QA in the CDE and protect it under applicable PCI DSS controls (PCI DSS v4.0.1 Requirement 6.5.5).

What evidence will a QSA expect to see for this requirement?

Expect to show (1) a policy and exception process, (2) how production-to-nonprod refreshes are sanitized or blocked, and (3) monitoring/scanning results demonstrating PAN is not present in pre-prod.

Are logs and APM tools in pre-production in scope for this requirement?

Yes if they can receive live PAN from pre-prod systems. Redact at the application boundary and configure observability tooling to avoid capturing sensitive payloads; keep evidence of the configuration and validation scans.

How do we handle third-party QA tools connected to staging?

Treat them as third parties that may receive sensitive data. Contractually and technically restrict sending PAN to them; if PAN must be present, the environment and connected systems may drive CDE scope decisions under Requirement 6.5.5 (PCI DSS v4.0.1 Requirement 6.5.5).