File Integrity Monitoring for PCI DSS Compliance

One of the most common areas where we see companies struggle during PCI DSS assessments is file integrity monitoring. It sounds straightforward — monitor your critical files for unauthorized changes — but in practice, the gap between having FIM installed and having FIM implemented in a way that satisfies assessors is where most organizations stumble. After working with dozens of companies through their PCI DSS assessments, we have seen every variety of FIM misconfiguration, and this guide captures what we have learned about getting it right.

File integrity monitoring (FIM) is a security control that detects changes to critical system files, configuration files, and content files. For PCI DSS compliance, FIM is not optional — it is an explicit requirement. When implemented correctly, FIM provides early detection of unauthorized modifications that could indicate a compromise, evidence of change management process adherence, and a baseline audit trail that assessors evaluate during every PCI DSS assessment.

This guide covers the PCI DSS requirements for FIM, what files you should monitor, how to select and implement FIM tools, how to manage alerts without drowning in noise, and what evidence your assessor expects.

PCI DSS Requirement 11.5: What the Standard Says

Under PCI DSS v4.0, file integrity monitoring falls under Requirement 11.5 (previously 11.5 in v3.2.1). The requirement states that change-detection mechanisms must be deployed to alert personnel to unauthorized modification of critical system files, configuration files, or content files, and that the tools must be configured to perform file comparisons at least weekly.

What we tell clients is that "at least weekly" is the minimum — not the target. In our experience, assessors increasingly expect real-time or near-real-time monitoring for critical systems within the cardholder data environment (CDE). Weekly comparisons were acceptable when PCI DSS was first published, but the threat landscape has evolved, and assessors' expectations have evolved with it.

The specific sub-requirements under 11.5 include deploying a change-detection mechanism (FIM) on systems within the CDE, configuring the mechanism to alert on unauthorized changes to critical files, performing comparisons at least weekly (with real-time monitoring being the recommended approach), implementing a process to respond to alerts generated by the change-detection mechanism, and ensuring that FIM output is reviewed and acted upon.

What PCI DSS v4.0 Changed

PCI DSS v4.0 introduced important clarifications for FIM. The standard now explicitly requires that organizations have a defined process for responding to FIM alerts and that they can demonstrate that alerts are actually reviewed and investigated. In our experience, this shift from "deploy a tool" to "operate a process" is the most significant change for organizations that previously treated FIM as a checkbox.

What we recommend is building your FIM program around three pillars: detection (the tool), response (the process), and evidence (the documentation). Assessors evaluate all three.

What Files to Monitor

One of the most common questions we get is: "Which files need to be in scope for FIM?" The answer depends on your cardholder data environment, but there are categories that apply to virtually every organization.

Critical System Files

These are operating system files whose modification could indicate a compromise or unauthorized system change:

Category	Examples	Why It Matters
OS kernel and boot files	/boot/vmlinuz, /boot/grub, bootloader files	Rootkit installation, boot-level persistence
System libraries	/lib, /usr/lib, .dll files in System32	Library injection, privilege escalation
System binaries	/bin, /sbin, /usr/bin, /usr/sbin	Backdoor installation, trojan replacement
System configuration	/etc/passwd, /etc/shadow, /etc/sudoers, registry hives	Unauthorized account creation, privilege changes
Scheduled tasks	/etc/crontab, /var/spool/cron, Windows Task Scheduler	Persistence mechanisms

Application Files

For systems within the CDE, application files that process, store, or transmit cardholder data should be monitored:

• Web application files: Application code, configuration files, and static content on payment pages or cardholder data processing systems.
• Payment application binaries: Executable files for any payment processing applications.
• Application configuration: Database connection strings, API endpoint configurations, and integration settings.
• Encryption-related files: Key files, certificate stores, and cryptographic configuration.

Configuration Files

Configuration files for security-relevant services within the CDE:

• Firewall and network device configurations: Rulesets and routing configurations.
• Web server configurations: Apache, Nginx, IIS configuration files.
• Database configurations: MySQL, PostgreSQL, SQL Server configuration files.
• Logging configurations: Syslog, audit daemon, and application logging configurations.

What we tell clients is that the most common FIM gap we see is under-monitoring. Organizations monitor OS system files but forget about application configurations, encryption key files, or web server settings. In our experience, building a comprehensive file scope requires input from both your security team and your infrastructure and application teams.

What Not to Monitor

Equally important is excluding files that change frequently as part of normal operations and would generate excessive noise. These typically include log files (monitor the logging configuration, not the logs themselves), temporary files and cache directories, database data files (monitor the configuration, not the data), and application session files.

What we recommend is starting with a broad monitoring scope and then systematically excluding noisy paths after you have baseline data — rather than starting narrow and hoping you have not missed something critical.

FIM Tools and Vendors

The FIM market ranges from open-source tools to enterprise platforms. What we recommend depends on your environment size, existing security stack, and budget.

Open Source Options

OSSEC/Wazuh: OSSEC is the foundational open-source FIM tool, and Wazuh is its actively maintained fork. Both provide file integrity monitoring, log analysis, and intrusion detection. In our experience, Wazuh is the strongest open-source option for organizations that want FIM, host-based intrusion detection, and log management in a single agent. It integrates well with Elasticsearch for visualization and alerting.

Tripwire Open Source: The open-source version of Tripwire provides baseline-and-compare FIM functionality. It is well-suited for organizations that want a lightweight, focused FIM tool without the broader HIDS capabilities. However, it lacks real-time monitoring — comparisons are run on a scheduled basis.

AIDE (Advanced Intrusion Detection Environment): AIDE is a lightweight file integrity checker commonly used on Linux systems. It generates a database of file attributes and compares against it on subsequent runs. Like Tripwire Open Source, it operates on a scheduled comparison model.

Commercial Platforms

Tripwire Enterprise: The commercial version adds real-time monitoring, policy-based configuration assessment, centralized management, and integration with change management workflows. In our experience, Tripwire Enterprise is the most commonly deployed commercial FIM tool in PCI DSS environments.

Qualys FIM: Part of the Qualys Cloud Platform, it provides cloud-managed FIM with real-time monitoring and integrates with other Qualys security modules. What we recommend for organizations already using the Qualys platform is leveraging their FIM module for consolidated management.

CrowdStrike Falcon FileVantage: CrowdStrike's FIM module integrates with their endpoint detection and response (EDR) platform. For organizations that have CrowdStrike deployed, adding FileVantage provides FIM without deploying an additional agent.

SolarWinds Security Event Manager: Provides FIM as part of a broader SIEM capability. Suitable for organizations that want to consolidate security monitoring tools.

What we tell clients is that tool selection should consider three factors: does it support real-time monitoring (not just scheduled comparisons), does it integrate with your change management and alerting workflows, and can it demonstrate evidence in a format your assessor will accept?

Implementation Best Practices

Based on our experience across dozens of FIM implementations, here are the practices that separate compliant deployments from audit findings:

Establish Baselines Carefully

Your FIM tool works by comparing current file states against a known-good baseline. What we recommend is establishing your initial baseline after a fresh, validated system deployment — not on a production system that may already contain unauthorized modifications. Document the baseline creation date and the verification steps you performed.

Implement Real-Time Where It Matters

While PCI DSS requires comparisons "at least weekly," what we recommend is implementing real-time monitoring for critical systems within the CDE and reserving scheduled comparisons for lower-risk systems. Real-time monitoring detects changes within seconds, while weekly scans leave a window of up to seven days where an unauthorized change could go undetected.

Integrate with Change Management

This is the integration point that separates mature FIM programs from checkbox deployments. When a legitimate change is planned, your change management process should create a change ticket before the change occurs, the FIM alert generated by the change should be correlated with the ticket, and the alert should be marked as expected or authorized with a reference to the change ticket.

In our experience, assessors consistently check whether FIM alerts can be correlated to approved change tickets. If your FIM tool generates alerts and your change management system tracks changes, but there is no connection between them, that is a finding.

Tune Alert Thresholds

A FIM deployment that generates thousands of alerts per day is not a security control — it is noise. What we recommend is a structured tuning process over the first 30 to 60 days of deployment. During the tuning period, identify files that change frequently as part of normal operations and add them to exclusion lists (with documentation of why), establish severity levels so that changes to critical system binaries generate high-priority alerts while changes to less sensitive files generate informational events, and set up automated categorization rules that separate expected changes from unexpected ones.

Alert Management and Response

Having FIM alerts is only half the requirement. PCI DSS v4.0 explicitly requires that you have a defined process for responding to alerts and evidence that alerts are reviewed.

Response Workflow

What we recommend is a tiered response model:

Critical alerts (changes to system binaries, kernel files, payment application code with no corresponding change ticket): Immediate investigation — security team notified within 15 minutes. Investigate and document findings within 4 hours.

High alerts (changes to configuration files, security tool settings with no corresponding change ticket): Investigation within 4 hours. Document findings and remediation within 24 hours.

Medium alerts (changes to monitored files with a corresponding change ticket but requiring verification): Review within 24 hours. Confirm alignment with approved change request.

Informational alerts (known authorized changes, OS patch-related changes with corresponding patch management records): Batch review weekly. Confirm all changes align with authorized activities.

What we tell clients is that the response process must be documented and the documentation must be retained. Assessors request specific evidence that alerts were reviewed, investigated, and resolved — typically by sampling alert records from the assessment period.

Evidence Documentation

For each alert that requires investigation, what we recommend documenting is the alert timestamp and file(s) affected, the investigation steps performed, the determination (authorized change, unauthorized change, or false positive), the corresponding change ticket reference (if applicable), the investigator name and investigation completion timestamp, and any remediation actions taken for unauthorized changes.

Evidence for Assessors

During a PCI DSS assessment, your Qualified Security Assessor (QSA) will request specific evidence related to FIM. Based on our experience, here is what you should be prepared to provide:

FIM deployment evidence. Screenshots or configuration exports showing FIM is deployed on all in-scope systems. The assessor will compare your FIM deployment inventory against your CDE asset inventory — any gaps will be flagged.

Monitoring scope documentation. A list of monitored file paths and directories for each system type, with rationale for the monitoring scope.

Baseline documentation. Evidence of when baselines were established and the verification process used.

Alert and response records. A sample of FIM alerts from the assessment period, showing the alert, the investigation, and the resolution. What we recommend is maintaining a FIM alert log or integrating FIM alerts into your SIEM with investigation notes attached.

Change management correlation. Evidence that FIM alerts for authorized changes can be traced to approved change management tickets. Assessors typically sample 10 to 25 changes and verify bidirectional traceability.

Weekly comparison evidence (if not using real-time). If you are using scheduled comparisons rather than real-time monitoring, evidence that comparisons are performed at least weekly without gaps.

In our experience, the organizations that breeze through the FIM portion of their assessment are those that maintain a continuous evidence trail throughout the year rather than assembling evidence retroactively before the assessment. Integrating FIM into your SIEM and your change management workflow creates the evidence automatically.

Integration with Change Management

The connection between FIM and change management is so critical to PCI DSS compliance that it deserves dedicated attention. In our experience, this integration is the differentiator between organizations that treat FIM as a security control and those that treat it as a compliance checkbox.

The ideal workflow operates as follows: a change request is submitted and approved through your change management process, the change is implemented during the approved window, FIM detects the file modification and generates an alert, the alert is automatically or manually correlated with the approved change request, and the alert is closed as "authorized — change ticket reference number."

When FIM detects a change with no corresponding change request, the alert triggers investigation as an unauthorized modification. This is the detection value of FIM — it identifies changes that occurred outside your approved process, which could indicate a compromise, an unauthorized administrative action, or a change management process failure.

What we tell clients is that this integration creates a positive feedback loop. FIM validates that your change management process is being followed, and your change management process provides context for FIM alerts. Together, they demonstrate to assessors that you have operational control over modifications to systems in your CDE.

Key Takeaways

• FIM is an explicit PCI DSS requirement under Requirement 11.5, and PCI DSS v4.0 raised the bar from "deploy a tool" to "operate a monitored, responsive process."
• What we recommend is real-time monitoring for critical CDE systems rather than the minimum weekly comparison — assessors increasingly expect this, and the detection value is significantly higher.
• In our experience, the most common FIM gaps are under-scoped monitoring (missing application configs and encryption-related files), untuned alerting (too much noise, so alerts are ignored), and missing integration between FIM alerts and change management tickets.
• Tool selection matters less than implementation quality — whether you use Wazuh, Tripwire Enterprise, or CrowdStrike FileVantage, the assessor evaluates your process, your alert response, and your evidence, not your vendor choice.
• What we tell clients is that FIM evidence should be a continuous byproduct of your operations, not a pre-assessment assembly project — integrate FIM into your SIEM and change management workflow from day one.
• The integration between FIM and change management is the single most important success factor for PCI DSS compliance — it proves operational control over your CDE and is the evidence assessors scrutinize most carefully.