PCI DSS 10.3.2: Audit log files are protected to prevent modifications by individuals
PCI DSS v4.0.1 control 10.3.2: 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 are protected to prevent modifications by individuals.
Summary
Nobody can alter the audit logs, including the people who administer the systems that write them.
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.2 | Examine system configurations and privileges and interview system administrators to verify that current audit log files are protected from modifications by individuals via access control mechanisms, physical segregation, and/or network segregation. |
The phrase is "modifications by individuals", and the individuals it has in mind are the privileged ones. A log an administrator can edit is a log that proves nothing about an administrator, which is the case audit logs exist for. The procedure names the acceptable means in its own text: access control mechanisms, physical segregation and network segregation. That is a hint about what satisfies it. Permissions alone, applied by the same person who could change them, is the arrangement this control is written against, which is why forwarding to a store the source cannot reach back into is the usual answer.
What to prepare
- Where logs are written and where they are retained, which should not be the same place.
- Who can modify or delete at each location, including administrators of the source system.
- The mechanism preventing modification: append-only storage, write-once retention, or a separate trust boundary.
- Evidence that an administrator of the source cannot alter the retained copy.
How to implement it
1. Forward off the host immediately. It is the single most effective step, because the copy that matters ends up somewhere the source system's administrator has no rights over.
2. Use immutable retention where the platform offers it. Object storage with an object-lock or write-once policy makes modification impossible rather than merely disallowed.
3. Separate the trust boundary, not just the permissions. A different account, tenancy or credential set is what makes the segregation real; different folders under the same administrator are not.
4. Include deletion. Retention policies that let an administrator shorten the window are a modification path that looks like configuration.
Where this commonly fails
- Logs retained on the machine that produced them, where the local administrator is unconstrained.
- Collector administered by the same team and credentials as the sources it collects from.
- File permissions treated as the whole control, changeable by anyone who can change permissions.
- Retention settings adjustable without review, which deletes evidence without editing a single record.
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.3 | Audit log files, including those for external-facing technologies… |
| 10.3.4 | File integrity monitoring or change-detection mechanisms is used on audit logs to ensure… |
← 10.3.1 · All controls · 10.3.3 →
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.