File Integrity Monitoring (FIM): How It Works and Why Compliance Requires It

File integrity monitoring (FIM) detects unauthorized changes to the files that define how your systems behave: operating system binaries, configuration files, application code, and sensitive data stores. It works by establishing a trusted baseline, typically a cryptographic hash of each monitored file, and alerting when reality drifts from it. A changed system binary that no patch explains, a modified web server config at 2am, a new file in a payment application's directory: FIM is how those changes surface while they are still leads instead of postmortem findings.

FIM is also one of the few controls that compliance frameworks require by name, which is why most organizations meet it first as an audit obligation. Done properly, it earns its place as a detection control too. This guide covers how FIM works, what to monitor, the compliance mapping, and how to run it without drowning in noise.

How file integrity monitoring works

Every FIM implementation follows the same cycle:

1. Baseline. The tool records a known-good state for each monitored file: content hash, permissions, ownership, size, and modification time. On Windows this extends to registry keys.
2. Monitor. Changes are detected either in near real time, via file system hooks and an agent, or by scheduled comparison scans that rehash files and diff against the baseline.
3. Evaluate. Each change is judged against expectations: was there an approved change window, a patch cycle, a deployment? Change without explanation is the signal.
4. Alert and record. Unexpected changes raise alerts; all changes land in an audit trail that shows what changed, when, and by which account.

Real-time agent-based monitoring catches changes as they happen and captures who made them; scheduled scanning is lighter but can miss short-lived changes and tells you less about the actor. Most mature deployments use real-time monitoring on the systems that matter most and scheduled checks elsewhere.

What to monitor (and what not to)

FIM fails most often through overreach: monitor everything and every alert becomes wallpaper. The high-value targets are the files that should change rarely and deliberately:

• Operating system binaries and libraries (/bin, /sbin, System32)
• Configuration files: web server, database, SSH, firewall rules, scheduled tasks
• Application executables and web roots, especially anything that handles payments or authentication
• Windows registry keys governing startup, services, and security policy
• Certificate and key stores
• Boot loaders and startup scripts

Leave out log files, caches, user documents, and anything that changes constantly by design. The goal is a monitored set where change is the exception, so every alert deserves a look.

The compliance mapping

FIM shows up, explicitly or functionally, across the major frameworks:

• PCI DSS requires it by name: a change-detection mechanism on critical files with comparisons at least weekly (Requirement 11.5.2 in version 4), plus FIM on audit logs themselves. If you handle cardholder data, FIM is not optional.
• HIPAA requires integrity controls for electronic PHI: mechanisms to confirm ePHI has not been altered or destroyed improperly. FIM over the systems storing PHI is the standard way to evidence it.
• ISO 27001 expects change management and integrity protections across its Annex A controls; FIM output is the audit evidence that configuration drift is actually detected, not just prohibited on paper.
• SOX auditors look for change controls over financial reporting systems; FIM provides the independent record of what changed outside approved windows.
• NIST 800-53 calls it out directly (SI-7, software and information integrity), which flows into FedRAMP, CMMC, and any framework derived from the 800-53 catalog.

The practical challenge is that each framework asks for the same control in different words, and auditors want it evidenced per framework. That mapping burden is what a controls platform removes: in Sable, FIM sits as one control mapped once across every framework you assess against, with its alert and audit-trail evidence attached in one place rather than re-collected for each audit.

FIM as a detection control, not just a checkbox

Attackers change files: they drop web shells, modify startup scripts for persistence, replace binaries, and tamper with logs to cover the trail. Ransomware staging, defacements, and supply-chain implants all leave file-change fingerprints. FIM catches this class of activity cheaply, and its audit trail answers the first incident-response question, what changed and when, before anyone starts imaging disks.

Its limits are equally real. FIM tells you that a file changed, not why, and it says nothing about attacks that never touch monitored files: credential abuse, mailbox rules, cloud identity misuse. It belongs alongside endpoint detection and log analytics, not in place of them; see our EDR vs XDR guide for that layer.

Tooling options

• Dedicated FIM platforms (Tripwire is the long-standing name) offer the deepest change intelligence and policy content, at enterprise pricing.
• Open source: Wazuh includes capable FIM alongside its SIEM features (our Wazuh guide covers it), and OSSEC remains a lightweight classic. Free to license, yours to tune and operate.
• EDR and cloud-native features: many endpoint platforms and cloud providers ship FIM capabilities that are adequate for core compliance scope without a separate product; verify the reporting satisfies your auditor before assuming.

Whichever tool, the output belongs in your SIEM or detection pipeline so file changes correlate with the rest of your telemetry; a FIM console nobody opens is the checkbox version of the control.

Running FIM without the noise

• Scope deliberately. Start with the systems in audit scope and the files above; expand only when the alert stream is clean.
• Integrate change management. Approved deployments and patch windows should auto-annotate their changes, so the queue contains only the unexplained.
• Rebaseline on every approved change, or drift makes the baseline meaningless within a quarter.
• Route alerts to people who investigate. A weekly digest satisfies the auditor; a monitored queue satisfies the control's actual purpose.
• Protect the FIM system itself. Its baseline store and audit trail are exactly what an attacker wants to tamper with; restrict and monitor access to them.