Does PCI DSS actually require file integrity monitoring?

Requirement 11.5 covers detection of unauthorised modification of critical files, and Requirement 10 covers logging and retaining access to system components. Which self-assessment questionnaire you fall under determines exactly how these apply to you, so confirm your SAQ with your acquirer. But if your own server touches the payment flow at all, you are generally not exempt from server-side controls.

I use Shopify or Stripe. Am I out of scope?

Your scope is reduced, not necessarily eliminated. If your server serves the page that loads the payment script, redirects to the processor, or hosts anything in the payment flow, it is typically in scope for server-side requirements under SAQ A-EP. A fully hosted checkout on the provider domain is a different situation. Ask your acquirer which SAQ they expect from you. It is the single most useful question available to you and it is free.

Will this generate constant alerts?

It will if you monitor everything equally, which is why most small deployments get switched off within a month. The fix is scoping: alert on any change in code, system and configuration paths, and alert only on executable content appearing in directories that are supposed to change. A monitor nobody reads is worth less than no monitor, because it also creates the false belief that you are covered.

Can I do this myself?

Yes. Wazuh is open source and free to run, and its documentation maps its capabilities to PCI DSS, GDPR, HIPAA, NIST 800-53 and TSC. The work is not installing it; it is tuning the ruleset so alerts stay meaningful, and having someone who reads them. That ongoing attention, rather than the software, is what people are actually buying when they outsource this.

Compliance

File integrity monitoring for a small online store

If you take card payments, you are probably already required to detect unauthorised changes to files on your server. Most small merchants do not, and most do not know they should.

By David Kabel · Updated 2026-09-01 · 3 min read

The short answer

File integrity monitoring watches a defined set of paths and alerts when their contents change unexpectedly. For an online store the paths that matter are the web root, the payment page and its scripts, system binaries, /etc configuration and authentication files. PCI DSS Requirement 11.5 asks for exactly this, and Requirement 10 asks you to retain the logs. The hard part is not installing it; it is scoping it so the alerts stay meaningful enough that someone still reads them in month three.

Why card skimming is the reason this rule exists

The characteristic attack on a small store is not a dramatic breach. Someone modifies the checkout page, or a script it loads, so that card details are copied to a third party as the customer types them. Everything keeps working. Orders still complete. Nothing looks wrong from the outside, sometimes for months, and the first sign is your acquirer telling you that fraud has been traced back to your store.

File integrity monitoring exists because that change to that file is the earliest detectable moment in the whole sequence.

What to watch, and how hard

Path	Why	Sensitivity
Web root and application code	Where a web shell or a skimmer lands. Any change here that you did not deploy is an incident until proven otherwise.	High
The payment page and its scripts	Card skimming works by modifying the page or the scripts it loads. This is the specific thing PCI DSS is worried about.	High
System binaries and libraries	Changes here mean something with root has modified the system. Rare, and serious when it happens.	High
Configuration under /etc	SSH config, firewall rules, cron, scheduled tasks, web server config. Persistence is usually established here.	High
Authentication files	Users, groups, sudoers, authorized_keys. A new key you did not add is the clearest possible signal.	High
Uploads and cache directories	Change constantly by design. Monitor for executable content, not for change itself, or you will drown.	Tuned

The noise problem, which is the real problem

Most small FIM deployments are abandoned, and they are abandoned for the same reason: the default configuration alerts on every change everywhere, a cache directory generates two hundred events an hour, and within a fortnight nobody is reading any of it. At that point you are worse off than before, because you now believe you are covered.

Getting this right means treating directories differently. Code, system and configuration paths should alert on any unexpected change. Directories that are supposed to change (uploads, caches, session storage) should alert only on executable content appearing, which is the thing you actually care about there. And deployments need to be a known event, so your own releases do not look like intrusions.

What this does not do

It does not make you PCI DSS compliant. Compliance covers your policies, your people, your payment flow and your systems, and it is assessed against the scope your acquirer sets. FIM is one technical control inside that. It happens to be one of the ones small merchants most often lack entirely, but implementing a control and certifying compliance are different things, and anyone conflating them for you is selling something. More on where that line sits.

Not sure what your server would detect today?

A free review tells you what is monitored, what is exposed and what your logs would show after an incident. Pricing.

Free server review