PCI DSS 12.10.3: Specific personnel are designated to be available on a 24/7 basis to respond to suspected
PCI DSS v4.0.1 control 12.10.3: the requirement in full, the 1 testing procedure 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
Specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents.
Summary
Name the people who will answer at three in the morning, and make sure they are actually reachable.
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.3 | Examine documentation and interview responsible personnel occupying designated roles to verify that specific personnel are designated to be available on a 24/7 basis to respond to security incidents. |
Two words do the work: specific personnel, available 24/7. "The security team" is not specific and a business-hours rota is not 24/7. The procedure interviews responsible personnel occupying designated roles, so the assessor talks to the people named rather than reading the plan that names them, and the usual failure surfaces immediately: an on-call rota exists for infrastructure outages and the security incident path is "email the security mailbox". Note what this does not require. It does not require a staffed security operations centre. A documented rota with contactable people and a tested escalation route satisfies it, and for a small entity that may be three names.
What to prepare
- The rota, with names or roles and contact details, covering every hour.
- The escalation path when the first contact does not answer.
- Evidence the route works: a recent callout, or a test of the contact mechanism.
- Cover for holidays, illness and departures.
How to implement it
1. Write down actual names or a rota that resolves to them. A role with nobody currently in it is the state this control exists to prevent.
2. Test the contact route, not just the list. A phone number that reaches a desk nobody sits at is on the list and is not availability.
3. Give the first responder authority to act. Waking someone who then has to wake someone else is a rota that answers and cannot respond.
4. Cover the gaps deliberately. Holidays and departures are when this fails, and the fix is a named second rather than an assumption.
Where this commonly fails
- A rota for infrastructure incidents with no equivalent for security ones.
- A shared mailbox as the out-of-hours contact, which nobody reads out of hours.
- One person carrying the whole rota, which is not sustainable and fails the first time they are unavailable.
- Contact details in the plan that have not been checked since a reorganisation.
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.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.7 | Incident response procedures are in place, to be initiated upon the detection of stored PAN… |
← 12.10.2 · All controls · 12.10.4 →
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.