PCI DSS 10.3.3: Get the logs off the machine that made them, promptly, onto something central and hard to modify.
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.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
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 writing logs from those systems to a secure internal store reduces the risk of the logs being lost or altered. 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 supports 10.3.2: a copy the source system's administrator cannot reach is harder to alter than one guarded by permissions alone, although 10.3.2 accepts access control mechanisms, physical segregation and/or network segregation. 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. The standard does not define "promptly" and leaves the method to each entity, so streaming is the strongest answer rather than the only one.
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. Detecting and alerting on a failed audit logging mechanism is 10.7.2; 10.2.1.6 requires the stopping or pausing of audit logs to be recorded.
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… |
Terms
Glossary entries that name this control, each with its own example, limits and sources:
← 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.