PCI DSS 10.6.3: Time synchronization settings and data are protected
PCI DSS v4.0.1 control 10.6.3: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 10.6.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data › Section 10.6
Time synchronization settings and data are protected as follows:
- Access to time data is restricted to only personnel with a business need.
- Any changes to time settings on critical systems are logged, monitored, and reviewed.
Summary
Restrict who can change the clock, and log and review any change on critical systems.
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.6.3.a | Examine system configurations and time-synchronization settings to verify that access to time data is restricted to only personnel with a business need. |
| 10.6.3.b | Examine system configurations and time synchronization settings and logs and observe processes to verify that any changes to time settings on critical systems are logged, monitored, and reviewed. |
Time is treated here as a security control rather than a convenience, and the reason is direct: an attacker who can move a clock can reorder or invalidate a log timeline, which undermines every other control in Requirement 10 without touching a single log file. That is why access to time data is restricted at all, and why changes on critical systems must be logged, monitored and reviewed, which is three things and not one. Note that reviewed is a separate word from logged: a time change recorded in a stream nobody reads satisfies the first and not the third. Because time changes are rare and consequential, this is one of the few events genuinely worth alerting on individually rather than batching into a periodic review.
What to prepare
- Who can change time settings on each system class, and their business need.
- Configuration showing time change events are logged.
- Evidence of monitoring and review, not just logging.
- Which systems you count as critical, since the second element depends on it.
How to implement it
1. Alert on time changes rather than reviewing them later. They are rare enough to make individual alerting practical and consequential enough to justify it.
2. Restrict the ability, not just the intention. On most platforms time is changeable by any administrator, so this is a permissions question with an answer you can point at.
3. Define critical systems in writing. The element applies to them specifically, and an undefined scope cannot be assessed as adequate.
4. Include the time servers themselves. They are the highest-value target for this attack and are sometimes managed outside the normal process.
Where this commonly fails
- Time changes logged into a stream nobody reviews, meeting one element of three.
- Any administrator able to change the clock, with no restriction to a business need.
- No definition of critical systems, so the second element has no scope.
- The designated time servers themselves excluded from the controls.
Related controls
Others in section 10.6:
| Control | What it requires |
|---|---|
| 10.6.1 | System clocks and time are synchronized using time-synchronization technology |
| 10.6.2 | Systems are configured to the correct and consistent time… |
← 10.6.2 · All controls · 10.7.1 →
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.