What Is File Integrity Monitoring? A Plain-English Guide

File integrity monitoring is a real, specific term, not marketing language, and it’s worth explaining properly instead of assuming everyone already knows what it means. In short: file integrity monitoring is the practice of tracking a file’s contents over time so you can tell, with certainty, whether it has changed since you last knew it was good.

That’s the whole idea. Everything else, the software, the compliance frameworks, the alerting systems, is built on top of that one simple check.

How it actually works

File integrity monitoring runs on a pretty consistent pattern, whether it’s protecting a bank’s servers or a photographer’s archive:

1. Establish a baseline. The first time a file is seen, it gets fingerprinted, usually with a cryptographic or fast collision-resistant hash, a short value calculated from the file’s actual contents. That fingerprint gets stored somewhere the software controls, not the file itself.
2. Recheck later. On a schedule, or sometimes continuously, the file gets fingerprinted again and the new value is compared against the stored baseline.
3. Flag a mismatch. If the fingerprint changed, the file’s contents changed. The software doesn’t need to know what the file “should” contain to catch this, only whether it’s still the same as it was.

That’s genuinely the whole mechanism. A file that still opens fine, still has the right name, still shows the right size, can still have quietly different contents than it used to, and a hash comparison is one of the few ways to actually catch that instead of assuming everything’s fine because nothing looks obviously wrong.

Where the term comes from

“File integrity monitoring” (often shortened to FIM) is, historically, an enterprise security and compliance term more than a consumer one. NIST’s own security controls catalog (SP 800-53, control SI-7) requires organizations to use “automated tools that provide notification to appropriate individuals upon discovering discrepancies during integrity verification,” which is the formal version of exactly the baseline-and-recheck process above. PCI DSS, the standard that governs how businesses handle credit card data, has its own requirement (11.5) that specifically calls for file integrity monitoring on critical system and configuration files, so that an attacker who tampers with a server can’t do it quietly.

That history is why searching “file integrity monitoring” mostly surfaces enterprise security vendors: Tripwire, CrowdStrike, and similar tools built to watch system binaries, configuration files, and logs for unauthorized changes, usually as part of detecting an intrusion or satisfying an auditor. That’s a legitimate and important use case. It’s also not the only one, and it’s worth being upfront that it’s not FileGriffon’s use case either.

The other reason files change: not an attack, just entropy

Enterprise FIM tools are almost entirely built around one threat model: someone with malicious access tampering with a file they shouldn’t have touched. That’s a real threat, but it’s not the only reason a file’s contents can quietly diverge from what they used to be.

Hard drives and SSDs both degrade in ways that can silently corrupt data with no attacker involved at all: magnetic bit decay on platters, electrical charge leakage in flash memory, a bad cable, a failing controller. We wrote a longer piece on the actual physics of this, commonly called bit rot or silent data corruption. The failure mode looks identical to a tampered file from the outside, the fingerprint no longer matches, but nobody broke in. The drive just quietly got a little less honest over time.

This is the gap that matters for anyone with a personal archive, a photo library, a video project, a long-term backup, rather than a fleet of production servers: the same core mechanism that catches an intruder also catches a drive quietly failing, and almost nothing marketed as “file integrity monitoring” is actually built with that second case in mind.

What to actually look for in file integrity monitoring software

Whether you’re evaluating an enterprise tool or something built for personal use, a few things separate a good implementation from a superficial one:

• A real hash, not just size and modified-date checks. File size and timestamps can both stay identical while the actual bytes change; only a content hash reliably catches that.
• A baseline you can trust. If the software can’t tell you when and how a file’s known-good state was recorded, you can’t trust what a later mismatch actually means.
• A sane way to handle legitimate changes. You edit files on purpose. Software that can’t distinguish “I told it about the change” from “the file just showed up different” turns into constant, ignorable noise.
• Detection versus repair. Most FIM tools stop at telling you something changed. Some pair detection with actual recovery, using redundancy or parity data to fix a limited amount of damage instead of just reporting it.
• Where the baseline data actually lives. If the tool’s own database can be tampered with as easily as the files it’s watching, the whole system is only as trustworthy as its weakest link.

How FileGriffon applies this to a personal drive

FileGriffon takes that same baseline-and-recheck mechanism and builds it for an individual’s drive or folder rather than a server fleet. Every file in a “vault” (a drive, folder, or single file you point it at) gets hashed with XXH3-64, fast enough to run across a large photo or video archive without turning a scan into an overnight job. A two-pass approach keeps it efficient day to day: a quick partial hash on routine scans, and a full-file hash when something needs a closer look.

On whatever schedule you set, FileGriffon rescans and compares. A file that still matches its baseline is marked VERIFIED. One that doesn’t is flagged CORRUPT, right there on the dashboard, not discovered by accident months later. If a change was actually intentional, an edit, a re-export, you Accept it, and that becomes the new baseline going forward, so legitimate changes don’t turn into permanent false alarms. Where PAR2 parity protection is enabled for a vault, some corruption can be repaired automatically instead of just reported.

None of that requires a security team, an auditor, or a compliance framework. It requires a drive with files on it you’d rather not lose without knowing.

A few common questions

Is file integrity monitoring only useful for businesses? No. The mechanism, hash it, remember it, check it again, is exactly as useful for a personal archive as it is for a server, it’s just rarely marketed that way.

Doesn’t antivirus already do this? Antivirus looks for known-bad patterns in files, malware signatures, suspicious behavior. It has no concept of “this specific file used to look different,” which is exactly what file integrity monitoring is built to catch. The two solve different problems and don’t overlap much in practice.

Is this the same as a backup? No. A backup gives you another copy of a file. File integrity monitoring tells you whether the copies you already have are still good, which matters, since a backup of an already-corrupted file is just a second copy of the same problem.

File integrity monitoring isn’t a niche enterprise concept once you strip away the compliance framing. It’s a straightforward answer to a question every backup and every drive eventually asks, quietly, without telling you: is this file actually still what you think it is?