PCI DSS file integrity monitoring: what Requirement 11.5.2 actually demands

Most of PCI DSS reads as good general hygiene, but a handful of requirements name a specific technical control - and file integrity monitoring is one of them. In PCI DSS v4.x it lives in Requirement 11.5.2 (it was 11.5 in the older v3.2.1 numbering): deploy a change-detection mechanism - file integrity monitoring is the named example - that alerts personnel to unauthorized modification of critical files, with comparisons performed at least weekly.

If you handle card data, this isn’t optional, and your QSA or SAQ will ask about it directly. Here’s what the requirement means in practice and the decisions hiding inside it.

What counts as a “critical file”?

The standard’s intent, and assessor practice, converges on the files whose modification would matter to the security of the cardholder data environment:

• System executables and libraries - a trojaned binary is the classic integrity failure.
• Configuration files - sshd_config, web server and firewall configs, /etc/passwd and friends.
• Launch points - cron directories, systemd units, init scripts: where persistence lives.
• Access control material - authorized_keys, sudoers.
• Application files that should be static in production - your deployed code and content, which change on deploys and at no other time.
• Log files themselves - covered separately in the standard (Requirement 10 expects logs protected from tampering), but the same mechanism often watches both.

The scoping judgement is yours to document: which hosts are in the CDE, which paths on them are critical, and why. “The FIM tool’s default list” is an acceptable start and a weak answer on its own - assessors respond well to a scoped list with reasoning.

”At least weekly” is a floor from another era

The weekly minimum dates from the assumption that FIM means scheduled scans - and it’s worth being clear-eyed about what weekly means: an attacker’s modification sits undetected for up to seven days while remaining fully compliant. Compliance floors are not security targets.

The requirement’s other clause is the one teams miss: the mechanism must alert personnel. A cron job that emails a diff nobody reads satisfies the letter right up until an assessor asks who reviews the reports (and 11.5.2 pairs with the expectation that alerts are responded to - unreviewed output is a finding waiting to be written). Detection without a notification path and a human on the end of it doesn’t pass the intent.

Event-driven FIM changes both halves: modifications are detected as they happen - comfortably inside any comparison window - and each event arrives attributed (which process, which user, which login session) so the “authorized or not?” judgement takes seconds. Deploys and package upgrades explain themselves; the write to authorized_keys at 3 AM doesn’t, and that’s the one that pages.

The part after detection: evidence

Requirement 11.5.2 doesn’t exist in isolation - at assessment time you’ll need to show it operating: the mechanism deployed on in-scope hosts, alerts firing on unauthorized change, and responses happening. That’s three kinds of evidence (coverage, detection, response) across the assessment period, and gathering them retroactively is the screenshot hunt that makes audit season miserable.

This is where AlertKick treats compliance as a byproduct rather than a project: the eBPF agent does event-driven FIM with full attribution on every monitored host, alerts route through real escalation to actual humans, and every detection lands in the compliance evidence timeline mapped to PCI DSS controls - so “show us 11.5.2 operating in March” is a report, not an excavation. AI triage handles the authorized-change noise that makes teams abandon FIM tools in the first place.

FIM is one of the few controls where the compliant choice and the secure choice can be the same tool. Start free, put the agent on a CDE host, modify a watched file, and see the whole chain - detection, attribution, alert, evidence entry - before your coffee cools.