PCI DSS 11.5.2: A change-detection mechanism (for example, file integrity monitoring tools)
PCI DSS v4.0.1 control 11.5.2: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 11.5.
Requirement 11: Test Security of Systems and Networks Regularly › Section 11.5
A change-detection mechanism (for example, file integrity monitoring tools) is deployed as follows:
- To alert personnel to unauthorized modification (including changes, additions, and deletions) of critical files.
- To perform critical file comparisons at least once weekly.
Summary
Run something that watches critical files and tells you when one changes, and have it compare at least weekly.
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 | |
|---|---|
| 11.5.2.a | Examine system settings, monitored files, and results from monitoring activities to verify the use of a change-detection mechanism. |
| 11.5.2.b | Examine settings for the change-detection mechanism to verify it is configured in accordance with all elements specified in this requirement. |
Two elements, and the second is a specific number: critical file comparisons at least once weekly. Deploying a tool satisfies the first element only. The word doing the most work is critical, which the requirement leaves you to define, so scope is the real decision here and an over-broad scope is what kills these deployments: monitoring everything produces an alert volume nobody reads, which is indistinguishable from not monitoring. Note the pairing with 10.2.1.7: that logs objects being created and deleted, and this watches existing files being modified.
What to prepare
- The definition of critical files, written down, with the reasoning.
- The tool configuration showing what is monitored and how often it compares.
- Results from recent monitoring activity, since 11.5.2.a examines them.
- Who receives the alerts and what they do with them.
How to implement it
1. Define critical narrowly and defend it. System binaries, configuration files, and the files that make up the payment application are defensible. Whole filesystems are not, and they are how this becomes noise.
2. Check the comparison frequency, not just the deployment. Weekly is the floor and the second element is separately tested, so a tool installed and comparing monthly meets half the control.
3. Route alerts to someone who acts. The first element says alert personnel, and an alert into an unread mailbox does not.
4. Expect and suppress the legitimate changes. Patching changes system binaries by design. Tuning around the deployment pipeline is what keeps the remaining alerts meaningful.
Where this commonly fails
- A tool deployed with default scope, producing alert volumes that guarantee nothing is read.
- Comparison frequency slower than weekly, which fails the second element on its own.
- No written definition of critical files, so the scope cannot be assessed as adequate or otherwise.
- Alerts firing on every deployment, training the recipients to ignore them.
Related controls
Others in section 11.5:
| Control | What it requires |
|---|---|
| 11.5.1 | Intrusion-detection and/or intrusion-prevention techniques are used to detect and/or prevent… |
| 11.5.1.1 | Service providers: Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent… |
← 11.5.1.1 · All controls · 11.6.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.