PCI DSS 12.10.7: Incident response procedures are in place, to be initiated upon the detection of stored PAN
PCI DSS v4.0.1 control 12.10.7: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 12.10.
Requirement 12: Support Information Security with Organizational Policies and Programs › Section 12.10
Incident response procedures are in place, to be initiated upon the detection of stored PAN anywhere it is not expected, and include:
- 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.
Summary
Have a procedure ready for finding a card number somewhere it should not be, and follow it through to why it got there.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 12.10.7.a | Examine documented incident response procedures to verify that procedures for responding to the detection of stored PAN anywhere it is not expected to exist, ready to be initiated, and include all elements specified in this requirement. |
| 12.10.7.b | Interview personnel and examine records of response actions to verify that incident response procedures are performed upon detection of stored PAN anywhere it is not expected. |
Four elements, and most entities do the first and stop. Deleting the data addresses what to do with it. The control also asks you to identify whether sensitive authentication data is stored alongside it, to determine where it came from and how it ended up there, and to remediate the leak or process gap that put it there. The third and fourth are what turn a cleanup into a fix, and without them the same discovery recurs. Procedure 12.10.7.b examines records of response actions, so this is evidenced by what you did the last time PAN turned up, not by the document alone. It leans on work done elsewhere: the data-flow diagram in 1.2.4 and the retention rules in 3.2.1 are what let you answer the third element at all.
What to prepare
- The procedure, checked element by element against the four.
- Records from any actual discovery, showing all four elements were worked through.
- How PAN outside the CDE is discovered in the first place, since a procedure that never triggers is untested.
- The data-flow diagram, which the origin question depends on.
How to implement it
1. Check for sensitive authentication data before deleting anything. It is a named element and it changes the severity considerably, and deleting first destroys the answer.
2. Answer the origin question every time. A log export, a support ticket attachment, a developer test file and a misconfigured backup are different failures with different fixes.
3. Close the process gap, not just the file. The fourth element is the one that stops the recurrence, and an entity that only ever deletes will keep finding the same thing.
4. Decide the retrieve, delete or migrate question in advance. The first element offers all three, and choosing under pressure with the data in front of you is how it gets deleted before it is understood.
Where this commonly fails
- Deletion treated as the whole response, satisfying one element of four.
- No check for sensitive authentication data, so the severity is never established.
- The origin unanswerable because nothing documents where account data is supposed to flow.
- A procedure that exists and has never run, with no records for 12.10.7.b to examine.
Related controls
Others in section 12.10:
| Control | What it requires |
|---|---|
| 12.10.1 | An incident response plan exists and is ready to be activated in the event of a suspected… |
| 12.10.2 | At least once every 12 months, the security incident response plan… |
| 12.10.3 | Specific personnel are designated to be available on a 24/7 basis to respond to suspected… |
| 12.10.4 | Personnel responsible for responding to suspected and confirmed security incidents… |
| 12.10.4.1 | The frequency of periodic training for incident response personnel is defined in the entity’s… |
| 12.10.5 | The security incident response plan includes monitoring and responding to alerts from security… |
| 12.10.6 | The security incident response plan is modified and evolved according to lessons learned… |
← 12.10.6 · All controls
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.