PCI DSS 12.10.4.1: The frequency of periodic training for incident response personnel is defined in the entity’s
PCI DSS v4.0.1 control 12.10.4.1: 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
The frequency of periodic training for incident response personnel is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
Summary
You choose how often responders are retrained, and you have to justify the number with a risk analysis.
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.4.1.a | Examine the entity’s targeted risk analysis for the frequency of training for incident response personnel to verify the risk analysis was performed in accordance with all elements specified in Requirement 12.3.1. |
| 12.10.4.1.b | Examine documented results of periodic training of incident response personnel and interview personnel to verify training is performed at the frequency defined in the entity’s targeted risk analysis performed for this requirement. |
The same pattern as 8.6.3 and 10.4.2.1: the standard hands you the frequency and takes back the freedom to pick it casually. The frequency is defined in a targeted risk analysis performed according to all elements specified in 12.3.1, and 12.10.4.1.a examines that analysis against those elements. Without it there is no defensible frequency and the control fails however sensible the interval happens to be. 12.10.4.1.b then checks the training actually happened at the frequency you set, so an ambitious number is worse than a modest one you meet.
What to prepare
- The targeted risk analysis for this specific frequency, not a general one.
- The frequency it concluded, stated plainly.
- Training records showing the interval was met.
- The 12-month review of the analysis that 12.3.1 requires.
How to implement it
1. Write the analysis before choosing the number. It is the artefact being examined, and one written to justify a decision already made usually reads that way.
2. Set an interval you will meet. 12.10.4.1.b compares records to your own number, so annual and honoured beats six-monthly and skipped.
3. Consider turnover in the analysis. A rota that changes often argues for more frequent training, and saying so is the kind of reasoning that makes the analysis real.
4. Keep it with the other targeted risk analyses. Several controls now require one, and a single register makes the 12.3.1 review manageable.
Where this commonly fails
- A sensible frequency with no analysis behind it, which fails on the evidence rather than the decision.
- One generic risk analysis cited for every control that needs one, without addressing this frequency specifically.
- A frequency defined and missed, which fails 12.10.4.1.b while 12.10.4.1.a passes.
- The analysis never reviewed at 12 months, failing an element it inherits from 12.3.1.
Related controls
This control refers to 12.3.1.
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.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.7 | Incident response procedures are in place, to be initiated upon the detection of stored PAN… |
← 12.10.4 · All controls · 12.10.5 →
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.