How do you find stored card data for PCI DSS scoping?
Your organization must confirm its own PCI DSS scope at least every 12 months and whenever a significant change occurs, under requirement 12.5.2. This confirmation is separate from the scoping your assessor performs during the annual assessment, and it does not replace it. Whether your scope has grown, a retention rule is unclear, or an assessor has asked how you ruled out stored PAN, the answer starts with a documented search that you can show to the QSA. PAN discovery means searching every location where account data may sit, not only the production database. That includes databases, file shares, cloud storage, backups, audit and troubleshooting logs, support tickets, chat and email archives, spreadsheets, and paper such as receipts and reports, which the SSC confirms fall under the standard in its FAQ 1069. For each location, record whether card data was found, whether it was deleted or rendered unrecoverable, and whether the location is now inside the cardholder data environment and protected as such. The data flows and connected components identified in this search also feed the scope confirmation itself. You own the search, its method, and its results. An implementation partner can prepare discovery tooling, pattern-matching rules, log collection and the evidence folder, but the partner does not decide what is in scope. Confirm with your QSA early which evidence format they expect for the scope confirmation and which locations they will sample independently. Only the QSA issues the Report on Compliance, and only the Attestation of Compliance records the result of the assessment.
Where stored PAN turns up when nobody expected it
Stored card numbers rarely sit in one obvious database. They accumulate in copies, logs, paper and conversations that were never designed to hold account data. Each location below needs its own search method, its own owner and a clear outcome, because a card number left in any one of them keeps that system inside PCI DSS scope.
Production databases and file stores
Start with the systems that were built to hold card data, then check the ones that were not. Look at columns that hold free text, notes, attachments, document imports and legacy tables that a migration copied forward. Search for PAN patterns and confirm which fields are supposed to hold account data at all. The outcome should be a documented list of every confirmed location, each mapped to a business owner, a retention rule and a protection method that meets Requirement 3.
Retention-sensitive archives
Archives often outlive the business reason for keeping them. Old exports, closed-account records and compliance folders may hold PAN long after the defined retention period has passed. Requirement 3.2.1 expects a process that checks at least every three months that expired account data has been securely deleted or made unrecoverable. The outcome is a dated register of archive locations, with each deletion verified and recorded.
Backups and audit or troubleshooting logs
Backups, audit logs and troubleshooting logs are non-primary storage, and the SAQ D notes to Requirement 3.5.1 place them within the scope of stored account data protection. Debug dumps and application traces commonly capture full request bodies. Confirm what each backup set and log source contains, who can restore or read it, and how long copies persist in each geographic location. The outcome is a list of backup and log sources with their content and retention, and a plan to remove PAN from logs at the source.
Paper receipts and reports
PCI DSS applies to paper that contains cardholder data, including receipts and printed reports, as PCI SSC FAQ 1069 confirms. Check back offices, store drawers, mailrooms, call center desks and filing cabinets, and review printed reports that finance or operations teams circulate. The outcome should be a defined handling rule for each paper type, secure storage until disposal, and a shredding or destruction record that an assessor can trace.
Support tickets and exports
Support staff often receive card numbers in tickets, chat transcripts, screenshots and spreadsheets exported for customer service. Review ticketing systems, shared drives and CSV exports for PAN patterns, and check whether attachments and free-text fields are indexed or retained. Where card data arrives through a channel the business did not design, follow the unintended channel procedure instead of replying with the number. The outcome is a clean ticket history, a redaction step, and a documented decision for each channel that still receives PAN.
Developer and test copies
Production data is frequently copied into development, test, staging and analytics environments to reproduce defects or build reports. Those copies rarely receive production controls. Confirm whether any non-production environment holds real PAN, including data sets restored for debugging and sandboxes shared with contractors. The outcome should be a policy that bars live PAN outside the CDE, masked or synthetic test data, and a record of any copies that were found and destroyed.
Running retention reviews that prove deletion
Requirement 3.2.1 asks for two things that assessors test separately: a documented retention and disposal policy that covers every location where stored account data resides, and a recurring process that verifies, at least once every three months, that account data past its defined retention period has been securely deleted or made unrecoverable. The policy alone does not satisfy the requirement. A reviewer will expect to see that the periodic check actually ran, what it looked at, and what it found. Start by listing each location your discovery work has identified, including databases, file shares, backups, audit and troubleshooting logs, exports and paper archives, then assign each one a retention period and a disposal method. Where a location has no defined retention, the review will have nothing to test against, so that gap comes first.
Frequent questions about how long cardholder data may be kept are addressed in PCI SSC FAQ 1318, which is the right starting point for setting the retention period itself. Confirm the position with your acquirer or the relevant payment brand if your business case depends on a longer period, and record the justification in the policy so the assessor can trace it. The FAQ answers the question of duration, not the question of whether a particular copy is still needed, so each retention decision should name a business or legal reason. Consider whether the requirement also covers copies held by third parties, such as a hosted backup provider or a managed log platform, and make sure your contracts give you the ability to run the same deletion check there.
The evidence an assessor expects is specific. Keep the approved retention and disposal policy with its version history and owner, a verification record for every quarterly review showing the date, the reviewer, the locations checked and the query, file listing or job output used, and the results, and deletion logs or certificates showing that expired data was removed or rendered unrecoverable, with the exceptions and remediation tickets for anything found late. Ask your QSA which format they accept for records of backup expiry, since backup platforms often expire data on a schedule rather than deleting it on request. Plan for this as a recurring task with a named owner, because a review that is skipped in one quarter becomes a finding that is hard to explain after the fact.
Handling card data that arrives through unintended channels
When a customer sends a card number by email, a support ticket or a chat window, the organization has two options under the PCI SSC's guidance on card data received through an unintended channel. It can bring that channel into the cardholder data environment and protect it to the standard applied elsewhere in scope, or it can remove the data immediately and add controls that stop the channel being used for card data again. Either way, the first staff action is the same: do not reply to the message containing the number, because a reply quotes the PAN back and copies it into another mailbox or chat log.
- Do not reply or forward: Staff should not reply to the message or forward it to colleagues, since each copy extends the storage footprint.
- Delete at source: Remove the message from the mailbox, chat transcript and any attachments once the required record of the incident is made without the card number.
- Clean backups and archives: Confirm whether the mail server, archive or chat platform keeps copies, and document when those copies expire or are purged.
- Add a blocking control: Publish a customer notice, add a web form or automated reply warning customers not to send card data, and configure mail filters to flag likely PANs.
- Keep: The incident ticket showing the time, channel, actions taken, who handled it, and the deletion confirmation, plus the change record for any new control.
Check that the decision between protecting the channel and removing the data is written down and approved, not left to individual staff.
Paper that carries cardholder data is in scope for PCI DSS, and the SSC's FAQ on paper with cardholder data confirms this for items such as receipts and reports. Card data on paper often arrives by post, from a branch, or from a printer that produced a report nobody expected to contain full card numbers. The staff action is to stop the paper from moving further, secure it, and dispose of it under the organization's retention and destruction rules once the record of the incident is complete.
- Secure the item: Place the paper in a locked container or restricted area until it is destroyed, and limit who can see it.
- Destroy by approved method: Use cross-cut shredding or an approved disposal service with a certificate of destruction, not a general waste bin.
- Find the source: Check whether a report, printout or form design is outputting full PANs, and correct it at the system level.
- Record the disposal: Log the date, item count, method and the person who witnessed destruction.
- Keep: The incident record, the destruction certificate or log, and the corrected report or form change.
Confirm that the destruction log is kept for the period your retention policy sets, and that the printer or report fix is tested before the paper process is closed.
Card numbers spoken on calls are captured in call recordings, voicemail, transcripts and voice notes sent through messaging apps. Recordings are often retained longer than staff expect and copied to quality-assurance platforms, so an unexpected PAN can sit in several places at once. The first step is to find out where recordings and transcripts go, then decide whether the recording is pause-and-resume protected, deleted, or redacted under the procedure the organization has approved.
- Pause or mask recording: Where the telephony platform supports it, pause recording during payment card entry or use DTMF masking, and confirm this in testing.
- Locate copies: Map the call recording store, transcription service, quality-assurance tools and any mobile apps that hold voice notes.
- Redact or delete: Remove or redact the affected recordings and transcripts, and check whether backups hold copies that need the same handling.
- Review sensitive authentication data: Check whether any recording or transcript holds the security code or other sensitive authentication data, which must not be retained after authorization.
- Keep: Logs of the recordings reviewed, the deletion or redaction evidence, and the configuration change for pause-and-resume or masking.
Confirm with the telephony vendor whether masking and deletion are supported in your deployment before you rely on them in the procedure.
What the 12.10.7 procedure should do when unexpected PAN is found
The 12.10.7 procedure turns an unexpected card number into a documented decision: contain it, find out how it arrived, decide what changes, and record it in the scope record. Each step produces a record that an assessor can follow from discovery to closure. Requirements 12.10.7 and 12.10.4.1 became mandatory on 31 March 2025, and the entity sets the procedure and training frequency itself.
Detect and log the unexpected PAN
A finding can come from discovery scans, a support ticket, a staff report, a log review or a backup check. The person who finds it records the location (system, file, mailbox, paper or log), the date, how it was found and who was notified, and avoids copying the number into tickets or chat. The output is an incident record with a unique reference that points to the location without repeating the card number. You know this step is done when the record exists and the data owner has been notified.
Contain the exposure and remove the data
The incident owner restricts access to the location, stops any automated process that copies or forwards the data, and removes the stored PAN where it is not needed. For paper, this means securing and destroying the item under your disposal process. For email, staff should not reply to the message containing the number. Before deletion, the team preserves a minimal forensic copy only if your policy requires it, and keeps it under the same access controls. The output is a containment note with timestamps and the removal method. Confirm with the system owner that the location now holds no PAN.
Determine how the data arrived and where it went
The response team traces the source, such as a customer sending a card number by email or chat, a web form that captures fields it should not, a misconfigured integration, a manual export or an unmasked report. It also checks copies: backups, logs, replicas, downstream systems and any third party that received the data. This is the step that tells you whether the data crossed into systems you did not know were connected. The output is a data-flow finding listing every location the PAN reached, with the channel and the period it was present.
Assess whether scope or controls change
Using the findings, the compliance lead decides whether the location was previously in scope, whether it now becomes part of the cardholder data environment, and whether any connected system must be protected or segmented. If the channel is a route for card data that you must keep, the entity either brings it into the CDE and protects it or removes the data and adds controls to stop the channel. The output is a scope impact assessment that names each system added, removed or kept out of scope, with the controls that apply to each.
Document the decision and root cause
The compliance lead writes the decision record: what was found, the root cause, the containment and removal actions, the scope conclusion and any corrective control, such as input validation, a masking rule or staff guidance. The record also states who approved it and whether the event needs notice to the acquirer or payment brands under your contracts or the applicable payment brand rules, which you should confirm with them. The output is a signed incident report that an assessor can read without interviewing the responders.
Update the scope record and discovery scope
The scope confirmation for the entity is updated to reflect the new finding, including data flows, account data locations, connected components and segmentation controls. The discovery scans and retention checks are extended to cover the channel or system that failed, so the same gap is tested again. The output is a revised scope document with a change note and a dated entry in the discovery schedule. This record stands alone: the annual scope confirmation under 12.5.2 is the entity's own work and is not replaced by the assessor's scoping during the annual assessment.
Review the procedure and training
After closure, the team reviews whether the procedure worked, whether responders knew the steps, and whether the incident response training frequency set under 12.10.4.1 still fits the risk. The training frequency is set by the entity through a targeted risk analysis, so a repeated finding may justify more frequent training for the teams that handle the channel. The output is a lessons-learned note and, where needed, an updated procedure or training plan with a version and approval date. Confirm that the procedure itself is reviewed under your own governance cycle.
Who owns discovery, who helps, and who attests
Your organization owns PAN discovery from start to finish. Your staff decide what counts as cardholder data in your environment, approve the search scope, judge every hit, and sign off the scope record. The annual scope confirmation required under Requirement 12.5.2 is an obligation of the entity itself, and it is separate from the assessor's scoping work during the annual assessment. No partner or assessor can take that obligation over for you.
- Search ownership: Named staff decide which systems, file shares, mailboxes, backups, logs and paper stores are searched and how often.
- Retention decisions: Your policies set retention periods and disposal methods for every location where stored account data is found.
- Incident decisions: Your incident response team decides how to handle unexpected PAN under Requirement 12.10.7.
- Scope record: Your team maintains the data flow, account data location and connected component records that the scope confirmation must cover.
- Sign-off: An accountable owner reviews findings and approves changes to the scope record.
Check that each of these duties has a named owner and a backup owner, and that the people involved understand what they are attesting to internally.
An implementation partner helps prepare the tools and paperwork your team uses to run discovery. DeployOpen, for example, works inside your own infrastructure to build and document this support. That work makes discovery repeatable and keeps evidence organized. It does not give the partner authority to decide scope, approve retention exceptions, or certify anything. DeployOpen prepares systems and evidence and does not issue reports or certificates.
- Discovery tooling: Scripts and scanning configurations that search agreed locations for card number patterns, run within your accounts or data centers.
- Evidence folders: Structured records of scan scope, run dates, results, and the disposition of each finding.
- Procedures: Written runbooks for the quarterly deletion verification, the unexpected PAN response and the annual scope review.
- Documentation: Diagrams and inventories that your team reviews and adopts as its own records.
- Handover: Training so your staff can run and interpret the tooling without the partner present.
Ask any partner to put its deliverables, its limits and its non-certifying role in writing before work begins.
A Qualified Security Assessor (QSA) or other assessor tests your scope claims and the evidence behind them during the annual assessment. Only the assessor issues the Report on Compliance (ROC) or the Attestation of Compliance (AOC) for an assessment that requires one. Certificates are not recognized as validation. The assessor's view is independent, so the assessor should not have designed the discovery process it is testing.
- Scope testing: The assessor checks whether the scope record matches what it finds in your environment, including data flows and connected components.
- Evidence sampling: The assessor reviews discovery results, deletion verification records and incident records for completeness.
- Independent judgment: The assessor decides whether the evidence supports each requirement.
- Reporting: The QSA completes the ROC or the AOC on official PCI SSC templates.
- Engagement terms: Confirm with the assessor how it will test your discovery process and what evidence it expects before the assessment starts.
Before you hire an assessor, confirm its QSA company status with the PCI SSC and agree its evidence request list in writing.
Frequently asked questions about PAN discovery
How often must PAN discovery be repeated for PCI DSS scoping?
At least every 12 months, and again whenever a significant change occurs. Requirement 12.5.2 requires the entity to confirm its PCI DSS scope, including where account data is located, at that interval and on significant change. Service providers must do this every six months under 12.5.2.1. The annual confirmation is your own obligation and is separate from the scoping the assessor performs during the annual assessment, so an assessor's review does not replace it. A significant change could be a new payment channel, a new storage location, a migration to new infrastructure or a new backup target. Check how your assessor defines significant change, since the PCI SSC FAQ on significant change is the place to start.
Must an outside party perform PAN discovery for PCI DSS?
No. The entity owns its scope, so your team can run discovery, and no outside party is required by PCI DSS for this activity. Outside help is common, though, especially for large or unfamiliar environments. If you hire a consultant to find card data and that same firm later helps you prepare for the assessment, check independence before you sign. A firm that designs your remediation and then also tests it for the assessor can create a conflict that the assessor will question. Keep the discovery record, the methods used and the sign-off within your organization so that ownership is clear. Independent assessments and certifications are issued only by a QSA or other authorized assessor, not by the firm that helped you prepare.
Does encrypting a PAN found in a stray location take it out of scope?
Usually not on its own. Encryption protects the data, but a system that still holds encrypted cardholder data generally remains in scope because the keys and the systems that use them are part of the environment. Whether a found, encrypted PAN can be removed from scope depends on the storage, the key management and the way the data is handled, and the position is set out in our guide on whether encryption takes cardholder data out of scope. Do not treat encryption as the first response to an unexpected PAN. The first step is to establish where the data came from, whether it must be kept, and whether it can be deleted.
What effort drives the cost and time of PAN discovery?
The main drivers are the number of places where account data might be held and how hard each one is to search. Count the production databases, file shares, email systems, log platforms, ticketing and call recording tools, endpoints, backups and archives, cloud storage buckets, and any paper records. Each location adds time for searching, validating matches and documenting the result. Backups and archives often take the longest because they are large and span several copies. Paper volume matters in call centers and retail back offices, where receipts and reports can be stored in many places. Ask any provider for a quote that lists the locations in scope, the search method for each, how false positives will be handled and what evidence will be delivered. Costs are one-time for the first full sweep and recurring for the annual or significant change confirmation.
Can our internal team run PAN discovery without outside help?
Often yes, if the team has the access, tools and time to do it properly and the people involved understand both cardholder data and the systems that store it. The work requires access to databases, logs, backups and file systems, a method for finding PAN patterns and a process for confirming matches. Teams that lack the database or storage skills, or that cannot reach backup and archive systems, usually need help. Before you decide, confirm who will approve the results, who will handle any card data found, and how the findings will be documented for the annual confirmation. An implementation partner can prepare tooling and procedures inside your environment, but the organization keeps ownership of its controls and the scope decision.
What will a QSA ask to see from our PAN discovery work?
A QSA will usually ask for a scope record that shows where account data is located, the data flows that move it and the systems connected to the cardholder data environment. Expect to show the method used to search each location, the list of locations searched and any that were excluded with a reason. Evidence of the retention and disposal process, including the quarterly check that expired data has been removed or made unrecoverable, will also be requested. For any unexpected PAN found, the assessor will want the incident record, the response steps, who was notified and the proof that the data was deleted or brought into scope. The record should show when the discovery was performed, by whom and when the next confirmation is due. Ask your assessor early which format they prefer, since expectations vary between organizations.
What to have in place before the first discovery sweep
A discovery sweep finds card numbers, but it only means something against a known baseline. The six items below tell you what the sweep should be compared against, who acts on the results, and where the search must reach. Check each one before the first run so that findings can be sorted quickly into expected and unexpected.
Current data-flow diagram and scope record
Start from a dated data-flow diagram showing how account data enters, moves through and leaves your environment, with every account data location and connected component listed. Requirement 12.5.2 expects you to confirm scope yourself at least every 12 months and on significant change, so the sweep should test that record rather than replace it. Check that the diagram names each system a sweep will search and that the last scope confirmation is dated after your most recent significant change.
Written retention and disposal policy
Requirement 3.2.1 expects a documented retention and disposal policy that covers every location where stored account data may sit. The sweep will generate findings that are only actionable if the policy states how long each data type may be kept and how it is deleted. Check that the policy lists each store by name, sets a defined retention period per data type, and includes the quarterly verification that expired data has been securely deleted or made unrecoverable.
Named owners for each data store
Every database, file share, backup set, log store and paper archive needs one accountable owner who can approve deletion and explain why data is held. Without owners, a finding has nobody to assign it to, and the sweep stalls. Check your inventory for each store and confirm that the named person can be reached, understands the retention rule for their store, and has authority to remove data or request its removal.
Access to backup and log systems
Card numbers often persist in backups, audit logs and troubleshooting logs, which Requirement 3.5 covers as non-primary storage. A sweep that cannot read these systems will report a clean result that is not clean. Confirm in advance that the sweep team holds read access to backup catalogs, restore points, log aggregators and debug output, through a documented and approved route. Record who granted access, for what period, and how it is revoked.
Documented route for reporting unexpected card data
Card data appears in unexpected places through staff, customers and tools, and Requirement 12.10.7 expects procedures for stored PAN found where it is not expected. Before the sweep, define how a person reports a suspected card number, who triages it, and when it becomes an incident. Check that the route is written, that staff know it, and that a test report reaches the triage owner within the time your incident procedure sets.
Baseline list of prior findings
A baseline of earlier findings lets you separate new exposure from known items still awaiting deletion or remediation. Compile the list from previous sweeps, assessor observations, incident records and any card data found through unintended channels such as email. For each entry, record the location, the action taken and the closure date. Check that every open item has an owner and a target, so the new sweep reports change rather than repeating old results.
How DeployOpen prepares discovery evidence for your assessor
DeployOpen helps organizations find where stored card data sits in self-hosted open-source platforms running in their own infrastructure, then prepares the systems and records that show the result. The organization keeps ownership of its scope confirmation, and an independent QSA or assessor makes the scoping determination.
How we scope
- Written scope agreed before work starts, naming the systems, backups, logs and retention stores to be searched
- Fixed-scope engagements list the discovery methods, locations and deliverables in advance
- Scope covers paper records, email archives and unintended channels when your written scope includes them
How we build
- Discovery tooling configured inside your own cloud accounts, data centers or air-gapped networks
- Search rules tuned to PAN patterns with documented false-positive review by your staff
- Retention and deletion jobs set up so stored data past its defined period is verified at least quarterly
How we hand over
- Discovery reports listing each location, data type, owner and remediation status for your records
- Data-flow and account data location updates prepared for your annual scope confirmation
- Incident procedure for unexpected PAN documented, with the organization approving its final wording
How we support
- Ongoing retainers can repeat discovery scans on your schedule and after significant changes
- Post-engagement questions from your assessor answered with records we prepared
- Confirm with us in writing which evidence your assessor will accept before the scope is signed
