PCI DSS 10.3.3: Audit log files, including those for external-facing technologies
PCI DSS v4.0.1 control 10.3.3: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 10.3.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data › Section 10.3
Audit log files, including those for external-facing technologies, are promptly backed up to a secure, central, internal log server(s) or other media that is difficult to modify.
Summary
Get the logs off the machine that made them, promptly, onto something central and hard to modify.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 10.3.3 | Examine backup configurations or log files to verify that current audit log files, including those for external-facing technologies, are promptly backed up to a secure, central, internal log server(s) or other media that is difficult to modify. |
The phrase that carries this is including those for external-facing technologies, and it is there because those systems are both the most likely to be compromised and the most likely to have their local logs edited afterwards. The word promptly defines the exposure: the interval between an event being logged and the log leaving the host is the window in which an attacker who owns that host can remove the evidence. It is the practical mechanism behind 10.3.2, because a copy the source system's administrator cannot reach is what makes "protected from modification" real rather than a permission setting. The requirement offers two destinations: a secure, central, internal log server or other media that is difficult to modify, which is where write-once storage qualifies.
What to prepare
- The list of log sources, with which are external-facing.
- Backup or forwarding configuration for each, showing the destination and the interval.
- Evidence of the interval in practice, not just the setting.
- What makes the destination difficult to modify.
How to implement it
1. Stream continuously rather than batching. Near real-time forwarding makes the exposure window seconds instead of hours, and it is what "promptly" means in practice.
2. Start with the external-facing systems. They are named in the requirement and they are the ones where a local log is least trustworthy.
3. Alert on a source that stops sending. Forwarding that fails silently leaves a gap that looks identical to a quiet period, which is also the mechanism behind 10.2.1.6.
4. Make the destination genuinely hard to modify. Immutable or write-once storage satisfies the second option and removes the argument about permissions.
Where this commonly fails
- Daily batch forwarding, leaving a day of logs on a host an attacker may control.
- External-facing systems excluded because they sit outside the internal network.
- Forwarding that stopped weeks ago with nothing detecting it.
- A central server administered by the same team and credentials as the sources.
Related controls
Others in section 10.3:
| Control | What it requires |
|---|---|
| 10.3.1 | Read access to audit logs files is limited to those with a job-related need |
| 10.3.2 | Audit log files are protected to prevent modifications by individuals |
| 10.3.4 | File integrity monitoring or change-detection mechanisms is used on audit logs to ensure… |
← 10.3.2 · All controls · 10.3.4 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.