File Integrity Monitoring for PCI DSS 4.0.1

Is real-time FIM required?

No. PCI DSS 11.5.2 sets a minimum of one comparison each week and does not require real-time monitoring. The PCI DSS Guide states it directly: no universal real-time monitoring requirement appears in 11.5.2, and the explicit minimum is that critical-file comparisons are performed at least once weekly.

The same source calls the weekly comparison a floor, not an alert-response target. It recommends faster detection for internet-facing systems and payment applications, based on risk. Its tool selection page says faster detection can be justified by exposure and impact, but real time is not a universal product-selection condition. PCI DSS Guide tool selection page.

This matters when you buy a tool. A tool that checks every few hours meets the weekly minimum. A tool that reports each change within seconds meets it as well. Pick the speed from your own risk. A payment page that a visitor can reach from the internet needs a faster check than a build server that no customer touches.

Use a simple rule to set your own speed. The table below is a suggestion for your targeted risk decision. It is not text from the standard.

Tools differ in how fast they work. OSSEC runs its integrity check every 6 hours by default and lists a near real-time mode for Windows and for Linux with inotify. Wazuh documents both real-time and scheduled scans. Microsoft Defender for Cloud sends changes from its endpoint agent in near real time, and from agentless scanning every 24 hours. In each case, the setting you choose decides whether you meet your own risk target.

Which systems and files are in scope

Every system that holds, processes or protects cardholder data is a candidate, and the files that must not change without approval are the critical files. The PCI DSS Guide lists the systems that FIM typically covers.

• Payment applications, web servers, API services, databases, middleware and supporting operating systems.
• Authentication, privileged access and administrator-access systems.
• Network security controls, web application firewalls and proxies.
• Logging and SIEM infrastructure.
• Virtualization hosts, container nodes and CI/CD components.
• Cloud workloads and infrastructure-as-code.

The same source says critical files include system executables, security configuration, application code, certificates and container artifacts. It states that active logs are not critical files for this purpose. That point links to requirement 10.3.4, which is a separate control with its own rule.

Microsoft publishes a list of items it recommends for FIM, based on known attack patterns. It makes a useful start for a monitored-object standard. Microsoft Learn. The list includes these items.

Log files. Requirement 10.3.4 asks that existing log data cannot change without an alert. New data added to a log must not cause an alert. The Qualys document gives this guidance for Qualys FIM: because log files change almost in real time, content monitoring of log files is not recommended, since it creates noise. It suggests monitoring logs for changes to permissions and ownership, and alerting in real time when a log file is deleted. Check with your QSA that this approach fits your assessment.

Custom applications. The standard puts the burden on you here. The tool vendor cannot know your own application folders. Write them down, with the owner and the reason each one is critical.

Software you install. A critical file can also arrive through an update. The file is then new, and it has no baseline entry. A plain comparison against a baseline treats it as a normal addition. This is why many teams also check each update before it lands. Vigilance does this with vigi diff, and the attack library lists real updates that carried one bad file inside a normal release.

How to build and protect a trusted baseline

Build the baseline from a system you know is clean, and protect it from the people who run the system. The PCI DSS Guide sets two rules. Protect baseline records and the FIM policy from unauthorized modification, with separation from ordinary system administration where feasible. Re-baseline only after an approved change has been validated, and never automatically whenever a difference appears.

The tool selection page gives a short definition of a trusted baseline. It must establish a known-good state, record who approved it and prevent ordinary administrators from silently replacing or suppressing it. PCI DSS Guide tool selection page.

Use these steps.

1. List the critical files for each system type and record the owner of each list.
2. Build the baseline on a clean system, after patching and before the system joins the cardholder data environment.
3. Store the baseline and the FIM policy where ordinary administrators cannot edit them.
4. Tie each approved change to a ticket. Re-baseline only after the ticket closes and someone has validated the change.
5. Record who approved the baseline and when.

A clean baseline needs a clean source. If you take the baseline after an attacker has changed a file, the tool records the bad file as normal. Vigilance helps here, because it compares a new version with the version you trust and reports each file that gained a capability. Run it on the new version before you take that version as the baseline.

vigi diff --old ./approved-release --new ./candidate-release

What evidence a QSA expects

A QSA expects proof that the control runs, that it alerts, and that people act on the alert. The PCI DSS Guide lists the evidence. It expects a controlled test showing that a change is detected, an alert reaches the intended personnel and the event is investigated. It also names coverage matrices, policy exports, representative alerts and health-monitoring evidence.

The tool selection page lists a longer set. It names a system-to-policy coverage export, monitored-object standards, baseline approvals, a role matrix, scan schedules and an agent-health dashboard. For testing, it names controlled test results, change tickets, investigation records and an exception register. PCI DSS Guide tool selection page.

Run the controlled test yourself before the assessment. Change a file on a test system, wait for the alert, and keep the screen output and the ticket. A QSA often asks for exactly that.

Four failures appear often in the sources above. First, a team assumes another product covers 11.5.2. Second, the baseline resets itself each time a difference appears, so no alert stays open. Third, the tool stops on a few systems and nobody sees it, which is the case 10.7.2 targets. Fourth, a team monitors live log content, so the alerts are too noisy to read and people ignore them. Check for each of the four before the assessment.

Keep the guidance about tools in mind. The tool selection page warns against assuming that EDR, a SIEM, source control or a cloud provider service automatically satisfies 11.5.2. Show the QSA the alert, the file list and the schedule instead of a product name.

How to choose a tool for 11.5.2

Choose a change-detection capability that fits your workload, and test it against your own evidence list. The PCI DSS Guide tool selection page makes the same point: choose a capability, not a product logo. It names five criteria: coverage, baseline protection, alert operations, cloud workload fit, and testing and evidence. PCI DSS Guide tool selection page.

The same page describes two ways to collect data. A host agent suits persistent operating systems, where kernel, package, service, application and configuration changes must be attributed quickly. Agentless collection is useful where an authenticated scanner or management plane can enumerate the required objects. A short-lived container or a managed cloud service often fits the second way better than the first.

Ask each vendor five questions. Which files does the default profile cover? Who can edit the baseline? Where do alerts go, and who answers them? How does the tool show that it stopped? Which export proves coverage to a QSA? A vendor who answers all five has thought about the assessment, not only the demo.

Where Vigilance fits

Vigilance records a folder, reads it again on a schedule and reports what changed. The schedule can run as often as every 15 minutes. After it finds a changed file, it reports the capability the file gained, such as running a command or reaching the network. This page does not claim that Vigilance alone satisfies 11.5.2. Ask your QSA whether it fits your scope.

Three parts of Vigilance relate to the evidence above. vigi status shows when each folder was last checked and lists any check that is overdue, which supports the health question in 10.7.2. A fleet of machines can write one signed line each into a folder you own, and vigi fleet can write a CSV export for an audit. The Pro plan opens no network connection, so it works on an air-gapped machine.

vigi ./the-folder
vigi setup
vigi status

Many teams keep a full FIM for the live machine and run Vigilance next to it. The FIM watches the machine all week. Vigilance checks the update before it lands. See the file integrity monitoring overview, the Linux guide and the Windows guide.