PCI DSS 10.4.3: Exceptions and anomalies identified during the review process are addressed
PCI DSS v4.0.1 control 10.4.3: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 10.4.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data › Section 10.4
Exceptions and anomalies identified during the review process are addressed.
Summary
When a log review turns something up, do something about it, and be able to show what you did.
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.4.3.a | Examine security policies and procedures to verify that processes are defined for addressing exceptions and anomalies identified during the review process. |
| 10.4.3.b | Observe processes and interview personnel to verify that, when exceptions and anomalies are identified, they are addressed. |
10.4.1 and 10.4.2 make you look. 10.4.3 is what makes looking count, and it is the shortest control in the section and the one most often failed. The usual failure is not that anomalies are ignored: it is that they are handled informally, so the review is evidenced by a sign-off with no record of what was found or what happened next. Procedure 10.4.3.b observes the process and interviews people, so "we address them" without artefacts does not survive. Note that both procedures are needed: a defined process with nothing to show fails 10.4.3.b, and diligent handling with no documented process fails 10.4.3.a.
What to prepare
- The documented process for handling exceptions and anomalies found in review, naming who decides and what the outcomes can be.
- Recent examples end to end: what was found, what was concluded, what changed, when it closed.
- The link into incident response for anything that escalated.
How to implement it
1. Raise a ticket for every anomaly, including the ones you dismiss. "Investigated, benign, here is why" is evidence. A review with nothing recorded looks identical to a review nobody did.
2. Give the process an owner and an outcome set. Assessors ask what happens next, and the answer needs to be a named path rather than a person's judgement.
3. Connect it to incident response rather than duplicating it. This control asks that anomalies are addressed, not that you build a second process alongside the one you already have.
4. Feed the result back into what you monitor. A recurring benign anomaly is a tuning job, and tuning it is the most defensible evidence that the review is real.
Where this commonly fails
- Reviews signed off with no record of findings, so there is nothing to show was addressed.
- Anomalies handled verbally by whoever noticed, leaving no trail and no owner.
- A documented process that describes an escalation path nobody has ever used.
- Alert fatigue, where the same benign anomaly is dismissed every week and never tuned out.
Related controls
Others in section 10.4:
| Control | What it requires |
|---|---|
| 10.4.1 | The following audit logs are reviewed at least once daily… |
| 10.4.1.1 | Automated mechanisms are used to perform audit log reviews |
| 10.4.2 | Logs of all other system components (those not specified in Requirement 10.4.1) are reviewed… |
| 10.4.2.1 | The frequency of periodic log reviews for all other system components… |
← 10.4.2.1 · All controls · 10.5.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.