Incident Response - Unexpected PAN Identified

By Mark Hannah on April, 21 2022

Get latest articles directly in your inbox, stay up to date

Back to main Blog
Mark Hannah

As a key member of Online’s Risk, Security & Privacy Practice for the last 8 years, Mark has contributed to building and growing a risk-based, business-minded security consulting practice. Mark first takes each client’s business model into consideration before applying a risk based and common sense approach to information security, resulting in compliance with the applicable security framework. Mark has an extensive background in Cyber Security including time as a Network Security Engineer, and as a HITRUST CSF Assessor. Mark has been a CISSP since 2003 and a QSA since 2006, and has performed hundreds of PCI DSS assessments over the years including a variety of complex assessments for Fortune 100 merchants, and service providers. Mark currently leads Online’s PCI Steering Committee and enjoys his role as an Associate QSA mentor and as a PCI subject matter expert to his clients.

Mistakes with PAN happen! Data leaks, memory dumps, or debug logs can accidentally contain sensitive information and can leak data into unexpected places in your environment. It is now a requirement to incorporate into your Incident Response Plan the locating, managing, and protecting of PAN outside of its defined area.

On March 31st, 2022 PCI DSS v4.0 was released. Today’s post is part of series of pieces we are publishing that explore the changes to the PCI standard and provide insight into what the changes will mean for your organization. All of our posts can be found here.

As we travel down this road to PCI v4.0 compliance, the final stop in the new Report on Compliance (RoC) Template is a new requirement related to your Incident Response Plan (IRP), 12.10.7.


In a nutshell, IRPs will need to be updated to incorporate procedures for an incident involving the discovery of any Primary Account Number (PAN) stored outside of known locations Online QSAs have come across this scenario many times over the years. We believe this to be a good addition to the DSS as it requires companies to be prepared for this somewhat inevitable occurrence. 


The PCI DSS v4.0 outlines these specific elements which must be included in your IR Plan: 


  • Determining what to do if PAN is discovered outside the CDE, including its retrieval, secure deletion, and/or migration into the currently defined CDE, as applicable. 
  • Identifying whether sensitive authentication data is stored with PAN.  
  • Determining where the account data came from and how it ended up where it was not expected. 
  • Remediating data leaks or process gaps that resulted in the account data being where it was not expected. 


It is still clear in v4.0 that unless the entity is an issuer or supports issuing services, Sensitive Authentication Data (SAD), cannot be stored after authorization. This is the reason behind the specific step called out within the v4.0 Defined Approach Requirements to verify SAD was not stored inadvertently along with the newly discovered PAN. If you do find Account Data, (SAD or PAN), you must securely delete or redact that element of the Account Data as part of the remediation and document it as part of your incident. While not specifically called out within v4.0 in the Defined Approach Testing Procedures for this requirement, it is specified in the last bullet point in the Requirement that the intent is for leaked data or process gaps involving Account Data to be remediated.   


An Example 

Throughout the years, the most common occurrence has been the discovery of unexpected PAN data identified in log files. Let’s explore this requirement using an example to see why it’s important to be prepared and why documenting it as part of the IR plan makes sense.  


For the sake of simplicity, let’s say the log files contained encrypted PAN. The compliance manager and the developer both thought there was only truncated PAN in the logs.  The good news is that it’s encrypted; but what are the ramifications?  Doesn’t sound like it’s a big deal because it’s encrypted--but looks can be deceiving. The compliance manager states they may just decide to protect the logs as if they store cardholder data and according to PCI DSS requirements and document the location, but the impact requires a deeper dive.   


Let’s step through the required analysis: 

The first step of the procedure would be to do an analysis of the current state to gather more information in order to determine next steps. Some key questions to ask include:  


1. Where did this PAN and/or SAD come from?  How did it end up here?

2. Where are the logs stored?   

3. Who had access to the logs containing the PAN and/or SAD?  Did they also have access to decryption keys?  

4. Who accessed those logs over the prior year?   

5. What is the current retention for those logs; how far back does the storage go?     

6. Have the logs been backed up or moved to tape or the cloud?  Follow the bouncing ball…

7. If they were stored on a network or SIEM that had only connected systems, did our CDE expand as a result of this new repository? 


If later they determine they do not want to continue to store the data in the logs and go down the path of remediation, then additional questions come into play: 


8. Can we redact this data from the logs or our SIEM?  Or do we need to delete?

9. How can we demonstrate they were securely deleted? 


And finally, these questions need to be answered and documented within the incident regardless of the pending decision whether to continue to store encrypted PAN and/or SAD or securely delete: 


10. Is it possible we inadvertently logged sensitive authentication data along with the PAN?

11. How did this even happen?  Perform a root cause analysis.

12. How can we prevent this from happening in the future?  


Documenting the discovery of unexpected storage of PAN through the incident response process allows for a thorough analysis to be performed, documented, and reviewed. It also provides for responsible personnel, such as the CISO, to be aware of the incident so proper steps can be put in place to minimize the likelihood of it happening again. 


Debug Log: A related thought  

This topic reminds me of other discussions around the age-old “debug log” dilemma. Debug log levels are typically not turned on in a production environment.  But what if it needed to be turned on during a catastrophic outage?  Knowing what elements of Account Data would be logged and having a plan to address the fallout seems like a good idea.  


Many times, I find that organizations are not entirely sure what would be included and state it would probably contain PAN and/or track data if enabled.  I usually recommend enabling this in development so a sample can be obtained safely and then they know what exactly is logged; advance knowledge is key to preparedness.   

If the debug logs contain unencrypted PAN and/or SAD, then having procedures to contain the incident, manage and protect that data during issue resolution will minimize the possibility of a worse incident involving a data breach.  




Mistakes happen, we are all human. If they didn’t then security incidents would be few and far between. The integration of this requirement is a continuation of emphasis on the PCI Security Council’s desire to integrate requirements as part of a Business-as-Usual approach.  Documenting a thorough procedure will allow the Incident Response team to respond immediately and effectively without missing a beat.  


To summarize: 

1. Analyze how Account Data, PAN, or SAD landed in the wrong place.

2. Plug the leak.

3. Delete sensitive data (if required).

4. Determine root cause and prevent future occurrences. 


Requirement 12.10.7 is a future-dated requirement and won’t be mandatory until March 31, 2025. That said, in the real-world mistakes happen… get prepared sooner than later by integrating these improved procedures into your Incident Response Plan. Online’s team of Information Security Consultants is standing by to help with updating, creating, or even testing  your Incident Response Plan if needed.

Online is ready to assist you in developing your PCI program, helping unpack what the v4.0 changes will mean for your organization, and then designing a compliance roadmap to get you there. For additional insight and guidance from Online’s QSA team, explore our digital PCI DSS v4.0 Resource Center, where we have identified and dissected many of the significant changes and new requirements in the latest release of the PCI Standard.

Submit a Comment

Get latest articles directly in your inbox, stay up to date