Unexpected PAN Discovery Procedures

PCI DSS 4.0.1 Requirement 12.10.7 requires you to have incident-response-ready procedures that trigger the moment stored PAN is found where it should not be, especially outside the CDE, and to drive containment, secure deletion or migration, sensitive authentication data checks, root-cause analysis, and remediation to prevent recurrence. (PCI DSS v4.0.1 Requirement 12.10.7)

Key takeaways:

• Treat “unexpected PAN discovered” as an incident category with defined triage, containment, and closure criteria. (PCI DSS v4.0.1 Requirement 12.10.7)
• Your procedure must explicitly cover retrieval, secure deletion and/or migration into the defined CDE, plus an assessment for sensitive authentication data. (PCI DSS v4.0.1 Requirement 12.10.7)
• Auditors will expect both approved documentation and operating evidence (tickets, logs, scans, deletion attestations, RCA) that proves the procedure runs in real life. (PCI DSS v4.0.1 Requirement 12.10.7)

Unexpected PAN discovery is a predictable failure mode: a developer turns on verbose logging, a support team exports a report, a third party sends a spreadsheet, or a backup job quietly captures data from an endpoint that was never meant to hold payment data. PCI DSS 4.0.1 Requirement 12.10.7 is aimed at that moment: you find stored PAN “anywhere it is not expected,” and you must respond with a defined, repeatable playbook that includes containment, disposition (retrieve, delete, and/or migrate into the CDE), a check for sensitive authentication data stored with the PAN, a root-cause explanation for how it got there, and fixes that prevent it from happening again. (PCI DSS v4.0.1 Requirement 12.10.7)

For a CCO, compliance officer, or GRC lead, the operational challenge is less about writing a policy and more about making it executable across Security, IT, Engineering, and any third party workflows that touch payment data. You need clean decision points, named owners, evidence that matches assessor expectations, and a process that doesn’t accidentally spread PAN further while investigating. This page translates the requirement into a procedure you can stand up quickly and run consistently.

Regulatory text

PCI DSS 4.0.1 Requirement 12.10.7 states that incident response procedures must be initiated upon detection of stored PAN anywhere it is not expected, and must include: what to do if PAN is discovered outside the CDE (including retrieval, secure deletion, and/or migration into the currently defined CDE), identifying any sensitive authentication data stored with the PAN, determining how the PAN ended up where it was not expected, and remediating the issue to prevent recurrence. (PCI DSS v4.0.1 Requirement 12.10.7)

Operator translation: you need a pre-approved runbook that triggers on a specific condition (“PAN stored in an unexpected location”), routes the event through incident response, produces a safe data-handling outcome (delete/migrate/retrieve), and closes the loop with root cause and prevention. The requirement is about readiness and repeatability, not improvised cleanup. (PCI DSS v4.0.1 Requirement 12.10.7)

Plain-English interpretation (what this requirement really expects)

1. You will find PAN outside your intended payment data footprint. The standard assumes this happens. Your job is to be ready. (PCI DSS v4.0.1 Requirement 12.10.7)
2. You must respond like an incident, not like housekeeping. That means triage, containment, controlled handling, approvals, and documented outcomes. (PCI DSS v4.0.1 Requirement 12.10.7)
3. You must decide the correct disposition for the data. Retrieve it (if needed for investigation), securely delete it, and/or migrate it into the defined CDE if there is a legitimate business need to store it there. (PCI DSS v4.0.1 Requirement 12.10.7)
4. You must check for sensitive authentication data (SAD). If SAD is present with PAN, your risk and response escalate because SAD storage is tightly restricted under PCI DSS. The requirement explicitly tells you to identify SAD stored with PAN. (PCI DSS v4.0.1 Requirement 12.10.7)
5. You must explain “how” and prevent recurrence. Root cause and remediation are not optional; they are part of the required procedure. (PCI DSS v4.0.1 Requirement 12.10.7)

Who it applies to

Entities: Merchants and service providers that store, process, or transmit account data, plus service providers whose people, processes, or systems can affect the security of the CDE. (PCI DSS v4.0.1)

Operational contexts where this shows up:

• Outside the CDE: endpoints, shared drives, collaboration tools, email inboxes, ticket attachments, data warehouses, analytics platforms, and log aggregation systems. The requirement explicitly calls out PAN discovered outside the CDE. (PCI DSS v4.0.1 Requirement 12.10.7)
• Inside your environment but “unexpected”: a non-payment application database table, debug logs, APM traces, crash dumps, backups, or test environments that accidentally contain production-like data.
• Third party workflows: outsourced support, BPOs, developers/consultants, marketing agencies handling lead forms, or any third party receiving exports or screenshots that include PAN (intentionally or not).

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

Below is a practical runbook structure you can implement and map directly to assessor testing.

1) Define the trigger conditions (so teams don’t argue at discovery time)

Create a short list of events that mandate invoking the procedure:

• PAN found by DLP, file scans, SIEM alerts, code scanning, database discovery tooling, or manual report by staff/third party. (PCI DSS v4.0.1 Requirement 12.10.7)
• PAN found stored outside the defined CDE boundary, regardless of volume. (PCI DSS v4.0.1 Requirement 12.10.7)

Decision rule: If there is credible evidence of stored PAN in an unexpected location, open an incident ticket and follow the procedure. (PCI DSS v4.0.1 Requirement 12.10.7)

2) Triage and containment (stop the spread first)

• Assign an incident owner (Security/IR) and a compliance liaison (GRC) to manage evidence and communications.
• Restrict access to the discovered location (permissions lockdown) to reduce further exposure.
• Preserve evidence safely: capture metadata (system name, path, timestamps, access logs) without copying PAN broadly. If you must copy, store it only in approved secure IR storage under least privilege. (PCI DSS v4.0.1 Requirement 12.10.7)

Common hangup: teams “email the file around” to ask what it is. Train responders to share references (hashes, file paths, screenshots with PAN masked) rather than the raw data.

3) Scope the discovery (what else is impacted)

• Identify where the PAN resides (files, database rows, logs, backups, object storage, SaaS).
• Identify systems/users that accessed it (authentication logs, SaaS audit logs).
• Determine whether the PAN is still being generated into that location (active logging, export jobs, integrations). Pause the job or disable the logging path to prevent recontamination. (PCI DSS v4.0.1 Requirement 12.10.7)

4) Determine disposition: retrieval, secure deletion, and/or migration into the CDE

Your procedure must explicitly cover these options. (PCI DSS v4.0.1 Requirement 12.10.7)

Use a simple decision matrix:

Condition	Required action	Notes
No business need to store PAN in that location	Secure deletion	Include backups and downstream replicas where feasible; document exceptions and compensating actions.
Business need exists, but location is outside CDE	Migrate into defined CDE (or redesign flow)	Treat this as a scoping/design issue; update data flow diagrams and CDE boundaries as needed.
Evidence needed for investigation	Controlled retrieval to approved IR evidence store	Minimize copies; log chain-of-custody.

5) Identify whether sensitive authentication data (SAD) is present

The requirement calls this out directly. (PCI DSS v4.0.1 Requirement 12.10.7)

Operationally:

• Inspect samples in a controlled way to determine if SAD fields appear (for example: full track data, CVV2/CVC2, PIN data).
• If SAD is present, escalate severity, expand containment, and involve PCI stakeholders promptly. Document exactly what was found and where.

6) Root cause: how did PAN end up there?

Your closure package must answer “how.” (PCI DSS v4.0.1 Requirement 12.10.7)

Common root causes you can design for:

• Application logging captured request/response bodies containing PAN.
• Debug mode or tracing enabled in production.
• A report/export function allowed PAN extraction to spreadsheets.
• A third party sent PAN through an unapproved channel.
• Test data management failure: production data copied into non-CDE environments.

Root cause should tie to a specific control gap (configuration, process, training, access, SDLC).

7) Remediate to prevent recurrence (and prove it)

The requirement requires remediation to prevent recurrence. (PCI DSS v4.0.1 Requirement 12.10.7)

Your remediation set should include:

• Technical fix: mask/redact PAN in logs; disable sensitive logging; tokenization; field-level controls; DLP rules; egress controls.
• Process fix: change support workflows; ban PAN in tickets; approved secure upload channel; third party contractual handling requirements.
• Detection enhancement: expand scanning patterns and coverage to the locations where the event occurred.

8) Closeout: document and attest

Close the incident only when you have:

• Disposition completed (deleted/migrated/retrieved) with verification.
• SAD assessment completed.
• Root cause documented.
• Remediation implemented and validated. (PCI DSS v4.0.1 Requirement 12.10.7)

Required evidence and artifacts to retain

Auditors test both design and operation. Keep artifacts that show the procedure exists, is approved, and is used. (PCI DSS v4.0.1 Requirement 12.10.7)

Policy/procedure evidence (design):

• Approved “Unexpected PAN Discovery” runbook with: owner, roles, escalation contacts, disposition decision matrix, and review/approval history.
• Training/awareness materials for staff and relevant third parties on “what to do if you find PAN.”

Operational evidence (run instances):

• Incident ticket(s) with timestamps, assignee, and classification as unexpected PAN discovery.
• Containment actions (access changes, job pauses, config changes) with change records.
• Data location inventory: where PAN was found, how much (qualitative), and affected systems.
• Deletion/migration evidence: deletion logs, scripts output, storage lifecycle actions, or migration tickets, plus verification steps.
• SAD assessment notes.
• Root cause analysis document.
• Remediation validation (screenshots/config diffs, test results, updated logging settings).

Daydream note: teams often struggle to assemble “operating evidence” quickly across security tooling, tickets, and approvals. Daydream can help you standardize the procedure template, enforce required fields in the workflow, and keep artifacts linked to the control for assessor-ready retrieval.

Common exam/audit questions and hangups

Expect assessors and internal audit to ask:

• “Show me the written procedure and who approved it.” (PCI DSS v4.0.1 Requirement 12.10.7)
• “Walk me through the last time PAN was found outside the CDE. Where is the ticket?” (PCI DSS v4.0.1 Requirement 12.10.7)
• “How did you confirm secure deletion, including copies/backups?” (PCI DSS v4.0.1 Requirement 12.10.7)
• “How did you determine whether sensitive authentication data was present?” (PCI DSS v4.0.1 Requirement 12.10.7)
• “What changed to prevent recurrence? Show evidence.” (PCI DSS v4.0.1 Requirement 12.10.7)
• “Did this discovery change your PCI scope or data flow diagrams?” (PCI DSS v4.0.1)

Hangup to preempt: “We deleted it” without verification. Your procedure should require a verification step and evidence capture.

Frequent implementation mistakes (and how to avoid them)

1. Treating it as a one-off cleanup. Fix: require an incident ticket, RCA, and remediation for closure. (PCI DSS v4.0.1 Requirement 12.10.7)
2. Copying PAN widely during investigation. Fix: restrict handling to named responders and approved evidence locations; mask screenshots.
3. No explicit SAD check. Fix: add a mandatory step and a required field in the incident form for SAD determination. (PCI DSS v4.0.1 Requirement 12.10.7)
4. No clarity on “migrate into CDE.” Fix: define who can authorize migration vs deletion, and what “defined CDE” means in your environment (tie to scoping documentation). (PCI DSS v4.0.1 Requirement 12.10.7)
5. Weak preventive remediation. Fix: remediation must address the ingestion path (logging/export/integration), not only the found artifact. (PCI DSS v4.0.1 Requirement 12.10.7)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific requirement, so this page does not list case citations.

Risk is still concrete: stored PAN outside the CDE expands your effective cardholder data footprint, complicates scoping, and raises the likelihood that PAN is present in systems without CDE-level controls. Requirement 12.10.7 pushes you to detect, contain, and eliminate that condition quickly, with traceable evidence. (PCI DSS v4.0.1 Requirement 12.10.7)

Practical execution plan (30/60/90)

Use this phased plan to operationalize fast without guessing timelines.

First 30 days (stand up the minimum viable procedure)

• Publish the runbook mapped to the required elements: outside-CDE handling, retrieval/deletion/migration, SAD identification, RCA, recurrence prevention. (PCI DSS v4.0.1 Requirement 12.10.7)
• Assign owners: IR lead, GRC control owner, IT/storage owner, Engineering liaison, third party manager.
• Implement the incident intake form (ticket template) with required fields: location, system owner, disposition decision, SAD check, root cause, remediation.
• Train likely discoverers (IT ops, support, data/BI, engineering on-call) on “stop, contain, ticket.”

By 60 days (prove it operates and close the evidence gaps)

• Run a tabletop exercise for “PAN found on shared drive outside CDE” and “PAN found in logs.” Capture artifacts as if for an assessor.
• Add targeted discovery scans/DLP rules for the specific repositories that commonly hold exports and logs.
• Integrate change management: require a change ticket for deletion scripts, logging config changes, and migration decisions.

By 90 days (make it durable across teams and third parties)

• Bake requirements into SDLC and support workflows: logging standards, redaction libraries, prohibited ticket content rules.
• Add third party expectations: prohibit PAN via email; require approved transfer channels; define notification duty for accidental PAN receipt.
• Centralize evidence: link incidents, approvals, and remediation validation to the control record in your GRC system (or Daydream) so audit requests are fast and complete.

Frequently Asked Questions

What counts as “unexpected” PAN storage?

Any stored PAN in a location not explicitly intended and controlled for cardholder data, especially outside your defined CDE boundary. The trigger is “stored PAN anywhere it is not expected,” not whether a breach occurred. (PCI DSS v4.0.1 Requirement 12.10.7)

Do we have to delete the PAN every time?

No. The procedure must cover retrieval, secure deletion, and/or migration into the defined CDE “as applicable.” Your runbook should define who decides, based on business need and scope impact. (PCI DSS v4.0.1 Requirement 12.10.7)

What if PAN is found in application logs?

Treat it as an unexpected PAN discovery incident: contain access to the log store, stop further logging of PAN, securely delete or migrate as appropriate, and document root cause (logging config or code) plus remediation (redaction/masking). (PCI DSS v4.0.1 Requirement 12.10.7)

How do we “identify sensitive authentication data stored with the PAN” without spreading it further?

Limit review to a small, authorized responder group and use controlled access in an approved evidence location. Document the determination and keep handling steps in the ticket so you can show due care. (PCI DSS v4.0.1 Requirement 12.10.7)

If PAN is discovered outside the CDE, does that automatically expand PCI scope?

It can, depending on where it was stored, how it got there, and whether that system becomes part of cardholder data storage/processing. Your procedure should include an explicit scoping impact review and updates to your defined CDE if needed. (PCI DSS v4.0.1)

What evidence will an assessor expect if we’ve never had an incident?

You still need an approved procedure that includes the required elements and proof it is operationally ready (for example: training records and a tabletop with captured artifacts). The requirement is about having procedures “in place” to initiate on detection. (PCI DSS v4.0.1 Requirement 12.10.7)