PCI DSS logging and file integrity monitoring
Businesses that handle payment card data are asked to log activity on systems in scope, protect those logs, keep them in sync with a reliable clock and watch critical files for unexpected change. In the PCI DSS these ideas sit mainly in requirement 10 (logging and monitoring) and requirement 11.5 (change detection). This group covers how our team maps those requirements to tools that produce real evidence.
What we do
- Requirement 10 and 11.5 mapping
- Audit policy design
- Central log collection
- File integrity baselines
- Alert rules for key events
- Time source checks
- Evidence pack for assessors
- Periodic control testing
Our team works with Wazuh and its PCI DSS documentation, AIDE, the Linux Audit daemon with a community best-practice rule set, osquery, Sysmon and Windows Event Forwarding through the Windows Event Collector, and chrony for time sync. We decide which files and events matter in the cardholder data environment, send events to a central store, alert on change and keep the settings and test records an assessor can read.
This works alongside our log pipeline, log retention and configuration auditing groups, and links to our Cybersecurity and Managed IT services. Which systems are in scope and how the requirements apply is for the business, its assessor and the PCI Security Standards Council documents to decide, and this is not legal advice. These are tools our team has experience with, not partnerships, and not a statement that any tool makes a business compliant.
Leading platforms we work with
- Wazuh
- AIDE
- Linux Audit (auditd)
- osquery
- Sysmon
- Windows Event Forwarding
- chrony
- Tripwire
- Graylog
Platforms and practices
- Scope list of systems in the cardholder data environment
- Audit event selection per system type
- Central log collection with access limits
- Log protection against change and deletion
- Time synchronization on all in-scope systems
- Daily review and alert rules for key events
- Critical file list for change detection
- File integrity baseline and approved-change process
- Alert triage records
- Evidence pack of settings and test results
References
- PCI Security Standards Council: PCI DSS standard page
- Wazuh documentation: Using Wazuh for PCI DSS compliance
- Wazuh documentation: File integrity monitoring
- AIDE: Advanced Intrusion Detection Environment
- Linux manual page: auditd(8)
- Neo23x0/auditd: best-practice auditd configuration (community project)
- osquery
- Microsoft Learn: Sysmon (Sysinternals)
- Microsoft Learn: Windows Event Collector
- chrony: NTP implementation
Sources last checked .
Product names are trademarks of their owners and are listed to describe our experience; they do not imply endorsement or partnership.
How we use PCI DSS logging and file integrity monitoring for clients
Cybersecurity
We find out whether everything you run is safe from attackers, then we fix it.
Learn moreManaged IT Services
We run your IT day to day so it stays secure: help desk, devices, Microsoft 365, Exchange, Active Directory, backups, networks and monitoring.
Learn moreCyber Automation
Custom AI agents that do repetitive work around the clock, with human review where it matters.
Learn moreFrequently asked questions
Direct answers to the questions we hear most. Something else on your mind?
Send us a messageHow long must we keep logs for PCI DSS?
Retention and review periods are set by the PCI DSS text and your assessor's reading of it, so we do not quote numbers here. Check with your QSA or the PCI Security Standards Council documents. We set up collection and storage so the period you are told to meet can be applied and shown.
Does installing a file integrity tool make us PCI compliant?
No. A tool only produces evidence. Compliance depends on which systems are in scope, how the requirements apply to you, and your assessor's judgment. Our team picks the files and events that matter, sets baselines and alerts, and keeps the settings and test records an assessor can read.
Which systems need logging and file integrity monitoring?
The systems in your cardholder data environment, and those connected to it, as defined by your scope. Scope is decided by the business with its QSA, not by a tool. We help build the scope list and map each system type to the right audit events and critical files.
Do you only work with Wazuh?
No. We have experience with Wazuh, AIDE, Linux auditd, osquery, Sysmon and Windows Event Forwarding, and use what fits your systems. These are tools we know, not partnerships, and we do not claim any one of them makes a business compliant.