A.8.17
Clock synchronization
Technological controlsCheckpoints 5Evidence 6Cases 6
Control objective
This control manages in-scope systems and network devices against a trustworthy common time basis. Multiple approved sources may be used, with accuracy, availability, and consistency considered together. Distinguishing timestamp time zones from clock error supports reliable event ordering and correlation. Monitor synchronization and preserve relevant offset information to support incident investigation and evidence interpretation.
Key checkpoints
- Is a trustworthy reference time source designated (for example, an internal NTP server synchronized to a reliable external reference such as national standard time) and is a synchronization policy established?
- Do servers, devices, endpoints, applications, and cloud resources use an approved common time basis, with UTC or explicit time-zone offsets in logs?
- Is synchronization status monitored, and are clock drift, synchronization failures, and anomalies detected and remediated?
- Is the time source protected against tampering/spoofing (for example, restricting which sources may be queried, and NTP authentication)?
- Do logs record consistent and accurate time that can be used for cross-system correlation?
Implementation guidance
- Approve internal time servers, trusted external references, or provider time services appropriate to the environment and define distribution arrangements. Verify consistent baselines and tolerances across sources and assess dependence on a single server.
- Make records comparable through UTC or explicit time-zone offsets, and define clock-error tolerances and synchronization policy. Different time-zone representations do not necessarily mean different clock times; distinguish format conversion from clock-error correction during analysis.
- Configure servers, network/security devices, endpoints, and virtual machines for suitable time services. For containers sharing the host clock, verify host synchronization and application time representation instead of requiring NTP in each container. Verify provider capabilities for managed cloud services.
- Protect the time source: restrict which sources devices may query, use authenticated NTP where supported, place time servers in protected segments, and monitor for spoofing.
- Continuously monitor synchronization health (offset/drift alerts), remediate devices that fall out of sync, and provide time source redundancy where availability needs call for it.
- Verify that logging layers record system time correctly and handle time zones and known clock offsets in the SIEM. Retain original timestamps and conversion/correction records so analysis remains traceable.
Evidence
- Clock synchronization policy/standard (reference source, time baseline, synchronization interval, allowed drift)
- NTP architecture diagram and time server configuration values
- Synchronization configuration captures on servers/network/security devices/endpoints
- Synchronization status monitoring/alert records and drift remediation history
- Log samples showing consistent time across systems
- Access control/authentication settings for the time source
Nonconformity examples
- Missing time-zone/offset information or an unclear time basis prevents reliable comparison of log timestamps.
- Some devices (network/security appliances, legacy servers) are not synchronized and are left with significant clock drift.
- The internal time server itself is not synchronized to a reliable external reference, or dependence on a single time server has not been assessed and no fallback source exists if it fails.
- Synchronization status is not monitored, so drift/failures go unnoticed for extended periods.
- Devices or internal time servers are configured to reference arbitrary external NTP with no restriction or authentication, exposing them to time source spoofing.
- Log timestamps are inaccurate, weakening incident investigation and the evidential value of the logs.