PCI DSS 10.7.3: Failures of any critical security control systems are responded to promptly
PCI DSS v4.0.1 control 10.7.3: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 10.7.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data › Section 10.7
Failures of any critical security control systems are responded to promptly, including but not limited to:
- Restoring security functions.
- Identifying and documenting the duration (date and time from start to end) of the security failure.
- Identifying and documenting the cause(s) of failure and documenting required remediation.
- Identifying and addressing any security issues that arose during the failure.
- Determining whether further actions are required as a result of the security failure.
- Implementing controls to prevent the cause of failure from reoccurring.
- Resuming monitoring of security controls.
Summary
When a security control fails, restore it and then record the whole story: how long, why, what happened while it was down, and what stops it recurring.
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 | |
|---|---|
| 10.7.3.a | Examine documentation and interview personnel to verify that processes are defined and implemented to respond to a failure of any critical security control system and include at least all elements specified in this requirement. |
| 10.7.3.b | Examine records to verify that failures of critical security control systems are documented to include: • Identification of cause(s) of the failure. • Duration (date and time start and end) of the security failure. • Details of the remediation required to address the root cause. |
Seven elements, and most entities do the first. Restoring the control is the obvious response; the rest is what turns an outage into something that does not happen again. Two elements are the ones records almost never contain. The first is duration, date and time from start to end, which requires knowing when it failed rather than when it was noticed, and those are different times that only detection under 10.7.2 can separate. The second is identifying and addressing any security issues that arose during the failure, which asks you to consider what happened while you were blind: if intrusion detection was down for six hours, the question is what passed unmonitored, not just whether it is back. 10.7.3.b examines records for exactly these, so the control is evidenced by what you wrote the last time something failed.
What to prepare
- The documented response process, checked element by element against the seven.
- Records from actual failures, showing all seven worked through.
- How start time is determined, which decides whether duration can be recorded.
- Evidence of the preventive change made after a failure.
How to implement it
1. Capture the start time from the detection, not from the ticket. The ticket records when someone noticed. The monitoring records when it stopped, and the requirement asks for the latter.
2. Ask what happened during the gap, every time. It is the element that turns this into a security process rather than an availability one, and it may need a retrospective look at whatever data survived.
3. Close with a preventive control, not just a fix. "Implementing controls to prevent the cause of failure from reoccurring" is a named element, so a restart is a restoration and not a response.
4. Use one template covering all seven. The elements are easy to satisfy and easy to forget under pressure, and a form is what makes the record complete when it is written in a hurry.
Where this commonly fails
- Restoration recorded and nothing else, satisfying one element of seven.
- Duration recorded from when it was noticed, which is not the start.
- No consideration of what happened while the control was down.
- Recurring failures with no preventive control, so the same record is written repeatedly.
Related controls
Others in section 10.7:
| Control | What it requires |
|---|---|
| 10.7.1 | Service providers: Failures of critical security control systems are detected, alerted, and addressed promptly… |
| 10.7.2 | Failures of critical security control systems are detected, alerted, and addressed promptly… |
← 10.7.2 · All controls · 11.1.1 →
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.