FIM for PCI-DSS Requirement 11.5: Evidence That Critical Files Are Unaltered

Introduction: FIM Is a PCI-DSS Requirement, Not an Option

If your systems store, process or transmit cardholder data, file integrity monitoring is not a nice-to-have — it is something the PCI Data Security Standard expects you to do. PCI-DSS Requirement 11.5 calls for a change-detection mechanism on critical files in the cardholder data environment, so that unauthorized modification of those files is detected and personnel are alerted. Put plainly, the standard wants you to know — and be able to prove — that the files that matter have not been tampered with. This article looks at what the requirement actually expects, what a QSA wants to see at assessment time, and how cryptographic hashing plus signed file integrity monitoring (FIM) — explained here certificates can produce that evidence on your own machine.

What Requirement 11.5 Actually Expects

Stripped to its essentials, the requirement asks for three behaviours. First, detect unauthorized changes to critical files — system binaries, configuration files, content files and other assets whose modification would signal compromise. Second, alert the appropriate people when such a change is detected, rather than letting it pass silently. Third, review and respond to those alerts through a defined process, so a detected change is actually triaged instead of ignored. The mechanism is generally described as change detection or file integrity monitoring; the spirit of it is a closed loop — baseline, detect, alert, review. Always read the current text of the standard and confirm scope with your assessor, because the precise wording and sub-requirements are periodically updated.

What Evidence a QSA Wants to See

When a Qualified Security Assessor evaluates this control, they are not satisfied by a tool being installed — they look for evidence that the loop is working. In practice that means three artefacts. A documented baseline of the critical files in scope, capturing their known-good state (and, ideally, recorded hash values). A set of change-detection records spanning the assessment period, showing that the mechanism actually ran and what it found. And review records demonstrating that the detections were examined and dispositioned — who looked at the alert, when, and what they concluded. Without all three, an assessor cannot confirm the control is operating, only that it exists on paper.

Producing That Evidence With Hashing and Signed Certificates

Cryptographic hashing is a natural fit for the integrity half of this story. A cryptographic hash is a fixed-length fingerprint of a file's exact contents; change one byte and the fingerprint changes completely. To build a baseline you hash each critical file once and record the values. To detect change you re-hash later and compare: an identical hash is a clean MATCH, any difference is a MISMATCH that flags the file for review. Capturing each comparison in a signed, time-stamped certificate turns it into a dated, tamper-evident record — the baseline becomes a citable document, and every re-verification becomes a proof point with an explicit verdict. Modern algorithms such as SHA-256, SHA-512 and BLAKE3 give you collision-resistant comparisons you can defend.

A Lightweight Way to Baseline and Re-Verify

You do not need heavy infrastructure to start producing this evidence. The practical pattern is simple: select the critical files in scope, hash them to create a baseline certificate, store that certificate safely, and then on a defined cadence re-hash the same files and generate a fresh verification certificate. Each re-verification states, in one page, whether every file still matches its baseline. Those dated certificates slot neatly alongside your monitoring process documentation and your alert-review logs to form the three-part evidence package a QSA expects. Because the process is reproducible, anyone can re-run a check months later and arrive at the same MATCH or MISMATCH result.

Where e-Dex Fits — and Where It Does Not

e-Dex (formerly Hash Calculator) is a free, fully offline Windows tool that produces exactly this integrity evidence: multi-algorithm hash baselines, re-verifications, and signed, time-stamped integrity certificates, all generated locally so your files never leave your machine. To be clear and avoid overclaiming, e-Dex is not a full FIM platform. It does not provide continuous real-time monitoring, automated alerting, or centrally managed agents across a fleet of servers — capabilities a dedicated change-detection platform provides and that many cardholder data environments will require. e-Dex supports the integrity and documentation side of Requirement 11.5; it complements, rather than replaces, a monitoring solution where one is mandated. Use it to baseline, to re-verify, and to generate the dated certificates your assessor can hold in hand.

Frequently Asked Questions

What does PCI-DSS Requirement 11.5 expect for file integrity monitoring?
PCI-DSS Requirement 11.5 expects a change-detection mechanism (file integrity monitoring) deployed on critical files within the cardholder data environment, configured to alert personnel to unauthorized modification of those files, and a defined process to respond to and review the alerts. In practice that means you must establish a known-good baseline of critical files, detect changes against that baseline, generate alerts, and keep records showing the alerts were reviewed and dispositioned.

What file integrity evidence does a QSA want to see for PCI-DSS?
A QSA typically wants three things: a documented baseline of the critical files being monitored (including their recorded hash values), records of change detections over the assessment period, and records that those detections were reviewed and acted on. Cryptographic hashes per file and an explicit MATCH or MISMATCH verdict make the baseline-versus-current comparison concrete and reproducible, which strengthens the evidence.

Can hashing and signed certificates produce PCI-DSS file integrity evidence?
Yes, as supporting evidence. Computing cryptographic hashes (such as SHA-256, SHA-512 and BLAKE3) over critical files establishes a baseline, and re-hashing later and comparing to the baseline detects change. Capturing each comparison in a signed, time-stamped integrity certificate gives you a dated, tamper-evident record of the baseline and of each re-verification that you can present alongside your monitoring process documentation.

Is e-Dex a full FIM platform for PCI-DSS Requirement 11.5?
No. e-Dex is a free offline tool that produces file integrity evidence — baselines, re-verifications and signed certificates. It does not provide continuous real-time monitoring, automated alerting or centralized agents across a fleet, which a dedicated change-detection platform offers. e-Dex supports and documents the integrity side of Requirement 11.5; it is not a replacement for an enterprise FIM solution where one is required.

How often should critical files be re-verified for PCI-DSS?
PCI-DSS expects change detection to run at an appropriate frequency for the criticality of the files, with alerts reviewed under a defined process. Continuous or frequent automated checks suit a production cardholder data environment, while a hashing-based baseline and periodic re-verification can supplement that with dated, signed proof points. The exact cadence should be driven by your risk assessment and confirmed with your QSA.

Conclusion

For PCI-DSS Requirement 11.5, the goal is a working loop — baseline, detect, alert, review — backed by evidence an assessor can actually examine. Cryptographic hashing and signed integrity certificates give you the reproducible, dated, tamper-evident records at the heart of that evidence, and a lightweight baseline-and-re-verify routine makes them easy to keep current. To see how the pieces fit together across the standard, read our file integrity compliance guide, then download e-Dex free and start building defensible file integrity evidence on your own machine today.