Does your PCI DSS scope need file integrity monitoring under 10.3.4 and 11.5.2?
Yes, if your cardholder data environment (CDE) is in scope, both requirements apply. Requirement 10.3.4 calls for file integrity monitoring or change detection on audit logs, and Requirement 11.5.2 calls for a change-detection mechanism that alerts on unauthorized changes to critical files and performs critical file comparisons at least once weekly. When a payment brand, acquirer or customer asks for PCI DSS validation, expect the QSA to ask for evidence of both on day one of the assessment. Your scope determines which systems, log locations and critical files must be covered, so the first task is to confirm what sits inside the CDE and what your scoping documentation says about it.
Cost and effort depend on three things: the number of in-scope systems, where your audit logs and critical files actually live, and whether your monitoring already produces the evidence an assessor will sample. A team with a centralized log server and a documented list of critical files has a much shorter path than one with logs spread across hosts and containers. Ask your QSA which files and directories they consider critical in your environment, and ask any implementation partner for a written quote that lists the systems, file paths and alert workflows in scope. Tooling such as Wazuh's file integrity monitoring documentation and osquery's file integrity monitoring guide can produce baselines, alerts and change records, but the organization still owns the baseline decisions, the review of alerts and the proof that the weekly comparisons ran.
Which evidence an assessor expects to see for file integrity monitoring
An assessor testing 10.3.4 and 11.5.2 wants proof that the monitored scope is defined, that monitoring runs as configured, and that alerts lead to action. The cards below cover the records that show each of those points, who produces them, and what the assessor checks in each one.
Defined list of monitored files
The assessor starts with a written list of the audit log files and critical files under monitoring, with the directories and paths each covers. Your team owns this list and should tie every entry to a system in the cardholder data environment. Check that the list matches what the tool actually watches, since a list that drifts from the configuration is a common finding. Review it after each new system or log source is added.
Baseline records
A baseline captures the known-good state of each monitored file, usually as checksums and attributes taken at a point you trust. Your operations team produces it when the tool is deployed and after each approved change. The assessor checks that the baseline date is recorded, that it was taken from a verified build, and that later baselines follow an approved change request.
Alert samples for unauthorized change
Show a real alert, not just a rule. Ask your team to produce a test change on a monitored file in a non-production system and keep the alert that the tool raised, with the file path, the action, the time and the user or process involved. The assessor uses these samples to confirm that detection works end to end, not only that a rule exists.
Weekly comparison records
Requirement 11.5.2 expects critical file comparisons at least once a week, so the assessor will ask for dated records of those comparisons. Your security or operations team produces them from scheduled scans or reports. Check that each week has an entry, that failed or skipped runs are recorded, and that any differences found were investigated.
Response tickets for detected changes
Each alert that flags an unauthorized change should open a ticket that shows who reviewed it, what they found and how it was resolved. The assessor samples these tickets to see that alerts are acted on, not just logged. Confirm that tickets link back to the alert sample and to any change record that explains an authorized change.
Monitoring tool configuration
The assessor will ask for the configuration that defines what the tool watches, how often it checks and where alerts go. For open-source tools such as Wazuh or osquery, this means exported configuration files, such as the file_paths entries in osquery or the monitoring rules in Wazuh, kept under version control. Your platform engineers produce and version these files, and the assessor checks that the running configuration matches the approved copy.
How Wazuh and osquery produce FIM evidence
Wazuh's file integrity monitoring module records a baseline of checksums and file attributes for the files and directories you choose to monitor. After the baseline exists, the agent compares current state against it and raises an alert when a user or process creates, modifies or deletes a monitored file. Scans can run on a schedule or in real time, so you can match the frequency to the weekly comparison expected by 11.5.2 or to a tighter interval for audit logs under 10.3.4. Each alert records how and when the file changed and who made the change, which is the detail an assessor usually asks to see.
- Baseline checksums and attributes: The module stores a reference state for each monitored path, so every later change is measured against a known starting point.
- Create, modify and delete alerts: Each event identifies the action, the time, and the responsible user or process.
- Scheduled or real-time operation: Choose the mode per directory, for example real time for log directories and scheduled comparison for system binaries.
- Central alert handling: Events reach the Wazuh manager, where you can retain them and produce reports for review.
- Licensing: Wazuh is distributed under GPL-2.0-only, which your legal team should review against your own distribution and internal-use model.
Confirm that the monitored paths cover every audit log location and critical file in your CDE scope, and that alert retention meets your log retention policy. The tool produces records, but your QSA decides whether they satisfy the requirement.
osquery treats the operating system as a queryable database. For file integrity monitoring, you list the files and directories to watch under file_paths in the configuration, and osquery writes changes to the file_events table. Each row records the action, the time and the path. Where possible, osquery also calculates MD5, SHA1 and SHA256 hashes of changed files, which lets you show what content changed, not just that something did. Because results are queryable, teams often pair the change feed with scheduled queries and forward results to a central log system.
- file_paths configuration: Monitored locations are declared in the osquery configuration, so the same definition can be version controlled and deployed to every endpoint.
- file_events fields: Action, time and path are the core fields to retain and review for each change.
- Hash values: MD5, SHA1 and SHA256 are calculated where possible. Confirm which algorithm your assessor accepts as the reference, and avoid relying on MD5 alone.
- Licensing: osquery is available under Apache-2.0 OR GPL-2.0-only, so you may choose the license that fits your distribution model.
- No built-in alert workflow: Alerting, retention and review are built by you from query results and log forwarding, so document the pipeline.
Confirm that the file_paths list matches your CDE inventory, that hash events are retained, and that someone is assigned to review the output. The configuration is evidence only if it is the version actually running in production.
The two tools suit different operating models. Wazuh bundles collection, alerting and a manager into one platform, which reduces the number of components you need to build and document. osquery is a lighter query layer that fits teams already running fleet-wide inventory or who want to write their own detection logic. Neither choice changes the requirement: both must cover the same critical files, produce the same kind of record, and generate alerts that someone reviews and acts on.
- Operating burden: Wazuh needs a manager and its own maintenance. osquery needs a configuration pipeline and a log destination that you run.
- Alerting: Wazuh provides alert generation out of the box. With osquery you design alert rules around query results.
- Evidence format: Both produce timestamped change records. Decide which fields your QSA will expect in a sample and test that the export contains them.
- Coverage of 10.3.4 and 11.5.2: Audit log protection and critical file comparison can use one tool or both, provided every in-scope system is covered.
- Failure detection: Requirement 10.7.2 expects failures of change detection itself to be noticed, so monitor the agent and the pipeline.
Confirm with your QSA which tool, configuration and retention evidence will be sampled, and whether a tool-level overview or a per-system test is expected. Scope and licensing questions should go to legal and your assessor, not inferred from this page.
What file integrity monitoring work costs and who is paid for each part
This table compares each cost component of meeting PCI DSS 10.3.4 and 11.5.2 with file integrity monitoring, who is paid for it, and whether it is one-time or recurring. Use it to build a quote request and to see which costs stay in your own budget regardless of who you hire. No fee or duration figures are given because none were supplied for this topic.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Qualified Security Assessor or Internal Security Assessor fees | Independent assessor (QSA or ISA firm) | One-time per validation cycle, repeated each year | Scope size, number of monitored systems, and how much evidence the assessor must sample |
| Implementation partner fees for deployment and evidence preparation | Implementation partner, under a written fixed scope | One-time for the initial build | Number of log servers and critical file sets, number of hosting platforms, and integration with existing SIEM or ticketing |
| Open-source tool licenses (Wazuh, osquery) | No license fee for the open-source tools themselves | Recurring for hosting and support if you buy it | Hosting footprint, retention period for logs, and whether you use a support retainer |
| Hosting and infrastructure for the monitoring server | Your cloud provider or data center | Recurring | Agent count, event volume, and log retention set by your policy |
| Internal staff time for alert review | Your own staff (no external invoice) | Recurring | Alert volume, quality of the baseline, and clear rules for what counts as an authorized change |
| Internal staff time for change tickets and reconciliation | Your own staff | Recurring, with spikes around releases | Change management maturity and how well change tickets link to detected file changes |
| Ongoing monitoring, tuning and upgrades | Your team, or an implementation partner under a retainer | Recurring | Frequency of platform upgrades, number of new systems added to scope, and the test cycle for weekly critical file comparisons |
How a FIM project moves from scoping to assessor evidence
This sequence takes file integrity monitoring from an agreed cardholder data environment boundary to a set of dated records that a QSA can test against requirements 10.3.4, 11.5.2 and 10.7.2. Each phase produces a named artifact, so the organization and its assessor can see what was decided, what was configured and what was proven.
Confirm CDE scope and critical file list
The organization confirms which systems sit inside the cardholder data environment and which files matter to security, including audit log directories, system binaries, security tool configurations and any payment page components. The team owns this decision, and the output is a signed scope statement with a critical file inventory that lists each monitored path, its system owner and the reason it is monitored. The step is complete when the QSA has reviewed the list and it matches the network and data-flow diagrams.
Select the tool and design the baseline
The team chooses the monitoring product, such as Wazuh or osquery for open-source options, and confirms it can record checksums and attributes, alert on changes and retain its own records. The partner prepares the baseline design: which hashes and attributes are captured, how the initial snapshot is taken from a known-good state, and where baseline data is stored. The output is a tool decision record and a baseline specification that the organization approves before deployment.
Deploy and tune alerts
Agents or queries are deployed to the in-scope systems, and the baseline is captured. Operators then run the monitor through expected maintenance such as patching and deployments, and tune exclusions so that approved changes are recorded differently from unexplained ones. Every exclusion needs a written reason and an approver. The output is a deployment record per system and a tuning log, and the step is complete when routine changes produce expected alerts and no monitored path is silently missing.
Run the weekly comparison and alert workflow
The monitor performs critical file comparisons at least once weekly and sends alerts on unauthorized changes to the security team. Analysts triage each alert against change records, classify it as approved or unauthorized, and open an incident for anything unexplained. The output is a dated comparison history and a triage log showing who reviewed each alert, what was decided and how it was resolved. Ask the tool vendor or your own administrator to confirm how comparison runs are scheduled and logged.
Test control failure alerts under 10.7.2
The team deliberately stops or disables the monitoring agent on a test system, or breaks a monitored query, and confirms that the failure is detected, alerted and handled under the process defined for requirement 10.7.2. The test is run in a non-production environment, with its date, method and result recorded. The output is a test record that shows the alert fired, who responded and how the outage was closed, which the QSA can review directly.
Collect evidence samples
The team gathers representative evidence for the period under review: baseline records, scope and inventory documents, configuration exports, weekly comparison reports, sample alerts with their triage notes, exclusion approvals and the 10.7.2 test record. Samples are taken across multiple weeks and systems rather than from one good day. The output is an evidence index that maps each artifact to the sub-requirement it supports. Confirm with the QSA which sampling approach they will apply.
Hand off to the QSA
The organization presents the scope statement, evidence index and access to the monitoring console to the Qualified Security Assessor, who decides what to test and how. The QSA owns the assessment conclusions and any report on compliance. The partner's role ends at preparing systems, documentation and evidence, and the handoff is complete when the QSA confirms the requests received and lists any open questions. Any gap found during testing returns to the owning team for correction.
What usually delays FIM validation and how to avoid it
Most delays in a PCI DSS file integrity monitoring review come from a few predictable gaps: an undefined list of critical files, alerts nobody can show were reviewed, log directories left out of scope, and tamper detection or control failure alerts that cannot be demonstrated. Closing each one before the assessor arrives keeps the evidence trail short and the testing simple.
Undefined critical file list
Requirement 11.5.2 asks for alerts on unauthorized changes to critical files, but the standard leaves the definition of critical to you. Assessors will ask for the list and check that monitored paths match it. Write the list down with the reason each file matters, such as system binaries, web server configuration, and payment application files, and link each entry to an owner. Review it at least when the environment changes.
Alerts with no review record
A FIM tool that alerts correctly still fails review if nobody can show who looked at each alert and what they decided. Assessors look for tickets or log entries that record the change, the investigation and the outcome, including changes approved through change management. Route alerts into your ticketing or SIEM workflow so that every alert carries a disposition. Confirm with your QSA how often they expect that evidence to be sampled.
Log directories missed in scope
Requirement 10.3.4 covers audit logs, but teams often monitor the operating system and application directories while missing the log paths for external-facing technologies, container hosts or cloud agents. Build a log inventory from your data flow and logging configuration, then compare it against the FIM paths. Include backup copies of logs under requirement 10.3.3, since those are also files that must not change silently.
Payment page tamper detection without evidence
Requirement 11.6.1 covers detection of unauthorized changes to payment page contents and security-impacting HTTP headers as the consumer browser receives them, and a third-party script or service often provides this. Outsourcing the tool does not outsource the obligation. Ask the provider for alert samples, the scope of what is monitored, and the escalation record. Confirm that your own team receives and acts on the alerts.
Control failure alerts never tested
Requirement 10.7.2 requires failures of critical security controls, including change detection and audit logging, to be detected, alerted and addressed promptly. Many teams configure a health alert for their FIM agent but never test it. Stop the agent or disable a monitored path in a test environment, confirm the alert fires and reaches a person, and keep the test record. Repeat the test after upgrades.
Who owns the controls, who prepares evidence and who issues the opinion
Your organization owns requirements 10.3.4 and 11.5.2 in full. That means it decides which files and directories are critical, approves the monitoring policy, reviews alerts, investigates unauthorized changes and keeps the records that show this happened. An implementation partner can build the monitoring, but it cannot accept the risk of a missed change or decide that an alert is acceptable. The organization also remains accountable for the outcome of every assessment, including any finding raised against the monitoring.
- Scope decisions: Naming the critical files, log directories and payment page resources that the mechanism must watch, and documenting why each one is included.
- Alert handling: Assigning people to review alerts, set response timelines and record the disposition of each unauthorized change.
- Weekly comparison oversight: Confirming that the weekly critical file comparison ran, and retaining the output.
- Policy and procedure: Writing and approving the procedures that describe monitoring, exceptions and tuning changes.
- Access to the monitoring system: Controlling who can change rules, suppress alerts or disable the agent.
Before engaging anyone, confirm internally who will sign off on the critical file list and who will own the alert queue after the project ends.
An implementation partner such as DeployOpen prepares the systems that perform file integrity monitoring and the evidence that shows they work. In a typical engagement, that means deploying an open-source tool such as Wazuh or osquery inside your own infrastructure, writing the monitoring configuration, setting the baseline, integrating alerts with your ticketing or messaging tools and documenting how the system operates. The partner does not decide whether your controls meet the requirement and does not issue any report, attestation or certificate. Engagements are fixed-scope, so the deliverables and boundaries are written down before work starts.
- Configuration and deployment: Installing the agents or manager, setting monitored paths and comparison schedules, and documenting the configuration as code.
- Evidence preparation: Producing configuration exports, alert samples and test records that your team and assessor can review.
- Control failure tests: Helping design tests that confirm a stopped agent or disabled monitor produces an alert, which supports requirement 10.7.2.
- Documentation: Writing system descriptions, runbooks and operating procedures for your own staff to maintain.
- Handover: Training your operators and transferring administrative access so the partner is not a hidden dependency.
Ask for the written scope to list every deliverable, and confirm that it excludes any assessment, attestation or opinion.
A Qualified Security Assessor (QSA) or other assessor tests whether the file integrity monitoring meets requirements 10.3.4, 11.5.2 and 11.6.1 as they apply to your environment. The assessor examines configurations, interviews staff, observes alerts and samples evidence over the assessment period, then records the results in a Report on Compliance (ROC) or, where a Self-Assessment Questionnaire applies, the assessor's role is limited to the entity's own answers. Only the assessor's signed Attestation of Compliance or ROC represents validation. Certificates issued by others are not recognized as validation.
- Independent testing: Selecting samples, reviewing alert logs and checking that weekly comparisons actually ran.
- Reliance on evidence: Deciding what it can rely on from your team, the partner and any system vendor documentation.
- Issuing the opinion: Completing the ROC or Attestation of Compliance under PCI SSC templates.
- Compensating or customized approaches: Evaluating any alternative method against the stated objective, with your documented justification.
- Independence: Remaining separate from the team that configured the monitoring, which is why a partner that also performs the assessment creates a conflict.
Confirm early which PCI DSS validation type applies to your organization and which assessor will be engaged, and make sure the assessor agrees to the evidence plan before implementation begins.
How to choose a QSA or implementation partner for FIM work
File integrity monitoring touches both the assessment and the build, so the people who configure your change detection should not be the only people who judge it. The cards below set out the checks that keep the QSA independent, the scope clear and the evidence usable when the assessor arrives.
Confirm the QSA listing
Before you sign anything, check that the assessor appears on the PCI SSC's current list of Qualified Security Assessor companies and that the individual performing your Report on Compliance is a listed QSA employee. The Council does not certify FIM products or vendors, so the assessor is the party whose judgment counts for requirements 10.3.4 and 11.5.2. Ask for the name of the QSA who will sign the Report on Compliance, not only the firm name.
Ask for acceptable references
Ask the QSA how they test file integrity monitoring on audit logs and critical files, and which evidence they have accepted from similar environments in the past. Request references the QSA is permitted to share, such as a sanitized description of the sampling approach and the artifacts they reviewed. Do not ask a QSA to name clients, since confidentiality rules prevent it. What you want is a clear account of what they will sample, not a testimonial.
Separate implementation from assessment
The firm that designs and deploys your FIM stack should not also be the firm that validates it for the Attestation of Compliance. If the same team builds the baseline and then judges whether it works, the assessor's independence is weakened. Ask any implementation partner to document what they configured, and keep the QSA responsible for testing the result. DeployOpen prepares systems and evidence for assessment but does not issue reports or attestations.
Require a written fixed scope
Put the monitored paths, log directories, payment page files, alert destinations and handover deliverables in a written scope before work starts. Name the environments covered, such as the audit log server and the production payment page hosts, and state what is excluded. A fixed scope lets you compare quotes on the same basis and gives the QSA a clear boundary when they confirm which systems fall under 10.3.4 and 11.5.2.
Check open-source licensing and support
Tools such as Wazuh (GPL-2.0-only) and osquery (Apache-2.0 OR GPL-2.0-only) carry different licenses and obligations, so have your legal team confirm how each applies to your deployment. Ask who supports the stack after go-live, how upgrades are tested, and whether the support terms cover the components you actually run. Open-source licensing does not transfer compliance responsibility, and support terms should state who fixes a failed alert pipeline.
Agree how evidence is handed over
Decide before go-live what the assessor will receive: baseline snapshots, weekly comparison reports, alert records, and the tickets showing how each unauthorized change was investigated. Agree the format, the retention period and who holds the copies. Evidence that exists only in a vendor console is hard to present during the assessment, so ask for exports the QSA can review without special access.
Questions buyers ask about file integrity monitoring for PCI DSS
Does requirement 10.3.4 still apply if our logs are shipped to a central server?
Yes. Requirement 10.3.4 asks for file integrity monitoring or change detection on audit logs, and it is separate from the centralized backup asked for under 10.3.3. Shipping logs to a central server protects them in a different way, but it does not replace detecting changes to the log files themselves. Your assessor will look for a mechanism that alerts on modification of existing audit logs, so confirm with your QSA which log locations and collectors are in scope. Your team owns this control, and the choice of tool should follow from the log paths you actually run.
Can open-source file integrity monitoring satisfy requirement 11.5.2?
Open-source tools can produce the evidence 11.5.2 expects, but the tool does not make you compliant on its own. Requirement 11.5.2 calls for a change-detection mechanism that alerts on unauthorized changes to critical files and performs critical file comparisons at least once weekly. Wazuh records a baseline of checksums and attributes and alerts on creation, modification or deletion, in real time or on a schedule. osquery watches paths listed under file_paths in its configuration and records changes to the file_events table with hashes where possible. You still define which files are critical, configure the schedule, and retain alert records for your assessor.
What does file integrity monitoring for PCI DSS cost, and what drives it?
The software license is often the smaller cost, because Wazuh and osquery are open source. The larger costs are the people who define critical files, tune alerts, route alerts to someone who acts on them, and document the process. Those costs scale with the number of systems, the number of monitored paths, the alert volume, and whether monitoring runs in your own cloud accounts or in a data center. Infrastructure to run the manager and storage for retained records also recurs. Ask any provider for a written scope listing systems, paths, alert routing, testing and handover, and separate one-time setup from recurring operation. DeployOpen does not publish prices and quotes follow from that written scope.
How long does it take to get file integrity monitoring ready for an assessment?
The timeline depends on how many systems are in scope, how well your critical files are already known, and how quickly your team can review alerts. A single log host with a clear file list is much faster to prepare than a fleet of payment servers with unclear ownership. Readiness work usually covers defining critical files, deploying agents, setting the weekly comparison schedule, testing an alert end to end, and collecting records for the assessor. No duration is supplied here, so ask your implementation partner for a milestone plan in the written scope and confirm with your QSA which evidence they will sample.
What does the work need from our own team?
Your team owns the control, so it needs people who understand which files and logs matter for the cardholder data environment. Typically that means a system owner who approves the list of critical files, an engineer who can deploy and maintain agents, and a person who triages alerts and records what was done. Requirement 10.7.2 also asks that failures of change detection itself are detected and addressed, so someone must watch the monitoring tool's health. Ask a partner to name these roles in the scope and to hand over runbooks so that the knowledge stays inside your organization.
Can we set up file integrity monitoring ourselves?
Yes, many teams deploy Wazuh or osquery in-house, especially if they already run a security operations function. The harder parts are usually not the installation but the judgment calls: deciding what counts as critical, keeping the configuration current as systems change, and proving to an assessor that alerts were reviewed and acted on. If your team lacks time or experience with these areas, an implementation partner can prepare the systems and evidence while you keep ownership. Either way, the independent QSA decides whether the controls meet the requirement, and no partner issues the report.
Does a certificate prove we are PCI DSS compliant?
No. A certificate is not recognized as validation of PCI DSS compliance. Validation is documented on official PCI SSC templates: a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire, each with an Attestation of Compliance. Whether file integrity monitoring is required, and which validation type applies, is decided by your payment brands and acquirer, not by the PCI SSC. Ask your acquirer which validation they accept, and keep the FIM alert records and weekly comparison results ready for whichever assessor reviews your environment.
How DeployOpen prepares FIM systems and evidence for your assessor
DeployOpen helps you build the file integrity monitoring (FIM) and change detection that 10.3.4 and 11.5.2 call for, and then assembles the evidence your Qualified Security Assessor (QSA) will ask to see. Everything is built inside your own cloud accounts, data centers or air-gapped network, under a written fixed scope that names the monitored systems, the audit log paths, the critical file lists, the alert destinations and the deliverables before work starts. Your organization still owns the controls, decides what counts as a critical file, and approves the final design. DeployOpen does not issue reports, attestations or certificates. Only your QSA can assess the environment and sign the Report on Compliance, and no outcome of any engagement is guaranteed.
In practice, the implementation work covers the components that matter to a QSA: a baseline of the monitored files and directories, the schedule for the weekly critical file comparisons, alert rules for unauthorized changes, and a documented workflow for who receives each alert and how it is closed. For the open-source options, this means configuring Wazuh file integrity monitoring or osquery file_paths entries against your own lists, tuning exclusions so routine changes do not bury real alerts, and testing that a deliberate change to a monitored log file produces a record. Because 10.7.2 also requires failures of change detection to be found and addressed promptly, DeployOpen can include a check that the monitoring agents themselves report their health and that a silent failure triggers an alert.
The evidence pack is where many assessments slow down. DeployOpen can document the system design, the baseline and change records, sample alert tickets with their resolution, and the test results for the monitoring stack, mapped to each sub-requirement in your own words. Ask any provider to confirm in writing which artifacts they will hand over, who keeps the logs long enough to cover the assessment period, and whether security testing of the monitoring stack is included or sold separately as a retainer. Confirm with your QSA early which evidence they expect and how they want it stored, so the work is shaped to their testing procedures rather than assumed.
