PCI DSS v4.0.1
PCI DSS v4.0.1 logging and change detection for Windows, with evidence for your QSA.
DPLens supports Requirement 10 audit logging, the 11.5.2 change-detection mechanism and the protection of PAN in logs on Windows systems in your cardholder data environment. It is one control among several.
- Requirement 10
- 11.5.2 change detection
- PAN masking
- Windows Server 2016–2025
In short
DPLens supports PCI DSS v4.0.1 logging on Windows: it collects the event logs and files Requirement 10 depends on and sends them promptly to your central log server over TLS, with a per-destination disk cache that holds events through an outage. Its scheduled file integrity monitoring (every 15 minutes, hourly or daily) supports the at-least-weekly comparison in 11.5.2, and it can mask card numbers before they leave the host. Your SIEM retains and reviews the logs, and you agree scope with your QSA.
This page maps DPLens features to PCI DSS v4.0.1 as we read it. It is not a Report on Compliance or a QSA opinion; your QSA or ISA decides whether your controls are in place. DPLens Ltd holds no PCI DSS validation, and using DPLens does not make you compliant.
The standard
What PCI DSS v4.0.1 asks for
A paraphrase of the requirements this page covers. The standard has the exact wording and testing procedures.
10.2
Audit logs capture the right events
Audit logs are active on all system components and record defined events, such as access to cardholder data, administrative actions and invalid access attempts, with who, what, when, where and the outcome.
10.3
Logs are protected
Access is limited, logs are protected from modification, promptly backed up to a central log server, and watched by change detection.
10.4–10.5
Logs are reviewed and retained
Logs are reviewed at least daily, with automated mechanisms, and kept for 12 months, the latest three immediately available.
10.6–10.7
Time is consistent and failures are caught
Clocks are synchronised, and failures of critical security controls, including audit logging and change detection, are detected and handled promptly.
11.5.2
A change-detection mechanism
A mechanism such as file integrity monitoring alerts personnel to unauthorised changes to critical files and compares them at least once weekly.
3.4.1, 3.5.1
PAN is masked and unreadable where stored
PAN is masked when displayed (3.4.1) and unreadable wherever stored, logs included, by truncation, keyed hashing, tokens or strong cryptography (3.5.1).
Requirement 10
How DPLens supports audit logging and log protection
DPLens gets the right events off each Windows host to your central log server, and counts anything that stops them.
01
Collect what 10.2 needs
Any Windows Event Log channel, including Security, System, Sysmon and custom channels, plus log files by path or wildcard. Collection coverage shows a channel that is empty or a path that matches nothing.
02
Get it off the host promptly
Delivered as collected, over TLS with certificate validation on by default. Each destination has its own disk cache (1 GiB by default) and failover; Splunk destinations add optional indexer acknowledgement.
03
Count every loss
Nothing is dropped silently. A full cache pauses collection by default (or drops oldest or newest), and every drop is counted against its cause.
04
Protect the agent's own data
The agent's cache, state and stored secrets are protected on the host, so the data in transit through it stays out of reach of ordinary users.
05
Log the logger
The agent's tamper-evident audit trail records sign-ins, configuration applies and rollbacks, and certificate, licence and masking-policy changes, with account and UTC time.
06
Make failure visible
Component health, delivery state and losses by cause are the signals to alert on for 10.7, on each host and across the fleet in DPLens Manager; service start and stop records go to the System log.
Requirement 11.5.2
Change detection on critical files
DPLens Windows file integrity monitoring watches files, folders and wildcards. Each watch item has its own schedule: every 15 minutes, hourly or daily. Even the least frequent option, daily, compares critical files more often than the weekly minimum in 11.5.2.
Each scan is compared with a recorded baseline, and changes travel as events through the same pipeline to your SIEM, where a rule you write raises the alert 11.5.2 requires. After a planned change you re-baseline one watch item or all of them, and the audit log records who did it and when.
You choose a size threshold above which files are tracked by their properties (size, timestamps, permissions) rather than contents; set it high enough that critical executables and configuration files are compared in full.
Requirement 3
Keeping PAN out of your logs
Card numbers turn up in application and debug logs, and once they reach a SIEM, it holds stored PAN. DPLens masks on the host before anything is cached or sent. Card-number masking finds valid card numbers, and for each match you choose to:
- keep only the last few digits, such as the last four;
- substitute a keyed hash, with the key held as a protected secret, so you can still correlate;
- redact or tokenise it outright.
Treat hashed card numbers as pseudonymised, not anonymised, as the DPLens docs advise. If truncated and hashed forms of the same PAN could be correlated, agree additional controls with your QSA, who also decides whether masking at source changes your scope.
Control map
PCI DSS v4.0.1 control mapping
| Requirement | How DPLens supports it | Evidence | What you do |
|---|---|---|---|
| 10.2.1 Audit logs enabled and active | Collects any Windows Event Log channel and log files; collection coverage flags empty channels and unmatched paths | Source list in the agent configuration; collection coverage on Overview | Set Windows audit policy; log every other in-scope component |
| 10.2.1.1–10.2.1.7, 10.2.2 Events and details | Forwards events with their original fields; optional normalisation to CIM or OCSF; timestamps held in UTC | Events as received by your SIEM | Decide which event IDs you need; never filter out events these requirements call for |
| 10.2.1.2 Administrative actions (on the agent) | Audit log records sign-ins, failures, applies, rollbacks and security-setting changes, with account and UTC time | The audit trail; Settings → Audit | Ship the audit log to your SIEM and review it |
| 10.3.1–10.3.2 Logs protected from access and modification | Agent state and cache protected on the host | Settings → Security | Control administrator access to hosts; protect the central log store |
| 10.3.3 Prompt backup to a central log server | Delivers as collected over TLS or TCP; per-destination disk cache; failover; fan-out to a second destination | Delivery state and cache depth per destination | Run and secure the central log server; size the cache for your outage window; deliver over TLS or TCP |
| 10.3.4 Change detection on logs | Agent's own audit trail is tamper-evident and the console reports whether it verifies | Verification status in Settings → Audit | Integrity controls on logs held in your SIEM or archive |
| 10.4 Log review | Delivers to your SIEM; aggregation and normalisation make review practical | Delivery state per destination | Daily review and automated review mechanisms in your SIEM |
| 10.5.1 Retention | Delivers to your SIEM and, in parallel, a copy to a lower-cost archive destination | Destination list | Keep 12 months, with three immediately available |
| 10.6 Time synchronisation | Normalises timestamps to UTC at collection | Settings → General → Timestamps | Synchronise host clocks |
| 10.7.2–10.7.3 Failures of critical security controls | Component health, quarantine, delivery states, losses by cause; service events in the System log | Overview; Destinations; fleet health in DPLens Manager; System log | Alert on these signals and respond promptly |
| 11.5.2 Change detection | FIM every 15 minutes, hourly or daily; changes delivered as events; re-baselines audited | FIM events in SIEM; re-baseline entries in the audit log | Choose critical files; alert on changes; investigate and document |
| 3.4.1, 3.5.1 PAN masked and unreadable | Card-number masking (last digits only, keyed hash, redact or token), applied before the cache and the network | Mask rules; per-rule counts; masking policy changes in the audit log | Confirm coverage of every log that may hold PAN; manage the hash key; agree scope with your QSA |
Configuration example
A cardholder-environment host, described
A typical payment-application server collects the Security, System and Sysmon event logs; watches the application's program and configuration folders for change; and forwards DPLens's own audit trail. Application logs pass a card-number mask rule, and delivery is RFC 5424 syslog over TLS on port 6514 with failover, pausing collection rather than dropping events if the cache ever fills. Define it once in DPLens Manager and apply it to every host in scope. The docs have step-by-step versions: watching files for change, masking sensitive data and syslog over TLS with failover.
Evidence
Evidence artefacts for your assessment
- The configuration for each host or group: sources, filters, mask rules and TLS destinations
- The audit trail, and Settings → Audit showing it verifies
- FIM change events and re-baseline records, matched to change tickets
- The Overview page: collection coverage, the pipeline funnel and losses by cause; fleet health in DPLens Manager
- Release checksums, signatures and SBOMs for the deployed version
FAQ
Questions QSAs and engineers ask
Does a daily FIM scan satisfy 11.5.2?
On frequency, yes: 11.5.2 asks for at least weekly, and the least frequent console schedule is daily. You still choose the files and raise the alerts in your SIEM.
Can we filter Windows events to cut SIEM cost without failing Requirement 10?
Yes, if you keep every event type 10.2.1.1–10.2.1.7 needs and record why you drop the rest. Every filtered event is counted against its rule. See the noisy Event IDs guide.
Is DPLens a system component in PCI scope?
If it runs on or connects to systems in your cardholder data environment, expect your QSA to treat it as one. The Trust Centre covers what that review needs.
How does DPLens protect logs through an outage?
DPLens provides disk-backed delivery with optional Splunk indexer acknowledgement, and nothing is dropped silently: every drop is counted. Deliver over TLS or TCP for any log you rely on as evidence.
See it on your own logs
Try DPLens on one Windows server before you talk to anyone.
Book a demo, or request an evaluation licence and install it on a test host. The documentation covers everything from requirements to Group Policy rollout.