ISO 27001 Control 8.17: Why Clock Synchronisation Is Critical for Security and Conformance

Control 8.17 states that clocks of all relevant information processing systems should be synchronised to a single reference time source.  This may sound simple, but it’s one of the controls that supports the integrity and reliability of almost every other aspect of a security management system.  It ensures that timestamps across logs, systems, and applications are consistent, meaning that events can be correctly ordered and correlated.

For example, if you’re investigating a potential intrusion, perhaps the firewall logs show a connection attempt at 10:02:15, the intrusion detection system flags suspicious traffic at 10:02:45, and the application server reports an unexpected login at 10:03:00.  If each of these systems’ clocks are even a minute out of sync, the analyst may misinterpret the timeline and fail to correlate the events.  What might have been a coordinated attack could appear as unrelated noise, or worse, the root cause might never be identified.

Log correlation is the most obvious reason why clock synchronisation matters, but it is important in other areas as well.  Authentication protocols such as Kerberos depend on time-sensitive tokens.  If a system’s clock drifts outside the acceptable tolerance compared to the domain controller, legitimate users may be locked out.  In rare cases, this can escalate into widespread outages that resemble security incidents, when in reality they are caused by simple clock inaccuracies.

Cryptographic operations also depend on accurate time.  Digital certificates, used in Hypertext Transfer Protocol Secure (HTTPS) and other secure communications, include validity periods that are defined by timestamps.  If a server’s clock is behind or ahead of the actual time, certificates may appear expired or not yet valid, leading to failed connections or weakened trust chains.  Similarly, security tokens, multi-factor authentication (MFA) systems, and even blockchain transactions depend on correct timing to validate authenticity and sequence.

In a forensic or compliance context, synchronised clocks are vital.  Legal or regulatory investigations depend on the ability to prove when certain actions occurred.  If timestamps from multiple systems don’t align, evidence can be questioned or dismissed.  In extreme cases, this can compromise an organisation’s ability to defend itself or demonstrate due diligence under standards and regulations such as ISO 27001, the General Data Protection Regulation (GDPR), or the Payment Card Industry Data Security Standard (PCI DSS).

From a broader perspective, accurate timekeeping on information systems is not only a technical necessity, but also a governance issue, demonstrating control over infrastructure and supporting the integrity of security monitoring.  For organisations seeking ISO 27001 certification, appropriate implementation of Control 8.17 effectively contributes to demonstrating conformance with other controls on logging, incident management, and evidence handling.

The intention of Control 8.17 is to ensure that organisations treat time as a managed asset.  ISO 27002 recommends the use of approved, trusted time sources and internal mechanisms to distribute time consistently across systems.  This usually involves the network time protocol (NTP) or precision time protocol (PTP), configured to synchronise all devices with one or more internal time servers.  These internal servers should, in turn, synchronise with external authoritative sources such as national time authorities or Global Positioning System (GPS) signals.  Redundancy is critical here: relying on a single external NTP source introduces a single point of failure and increases risk if that source is tampered with or unavailable.

Securing the time source is just as important as setting it up.  Attackers can exploit unsecured NTP configurations to manipulate time, disrupting logs or bypassing security controls.  For example, by shifting timestamps, an attacker could make an intrusion appear to have happened earlier or later than it did, obscuring traces in log files.  For this reason, NTP traffic should be restricted, authenticated where possible, and monitored for anomalies.

Organisations should also define policies for clock management.  This includes specifying which systems must synchronise, how often synchronisation occurs, acceptable levels of drift, and what happens when drift exceeds thresholds. However, this always depends on the size of the organisation and the necessary maturity of that particular control.  Monitoring tools can automatically alert administrators if time deviations are detected, allowing them to correct issues before they impact operations.

In complex environments, especially those with virtualisation, cloud workloads, or distributed applications, time synchronisation becomes even more crucial.  Virtual machines can experience clock drift due to host system performance, and cloud-based services might rely on external time sources with different reference points.  As such, ensuring time is consistent across hybrid or multi-cloud environments is essential to maintaining trust and operational continuity.

In practice, a robust approach to Control 8.17 includes:

• Using internal NTP servers synchronised to trusted external sources
• Authenticating NTP communications
• Enforcing synchronisation across all servers, network devices, and endpoints
• Monitoring for clock drift and out-of-sync systems
• Documenting and reviewing synchronisation policies regularly.

‍

Despite receiving limited attention, clock synchronisation sits at the core of operational integrity.  It ensures that in the event of an incident, security teams can trust the data they are presented with.  Without clock synchronisation, logs lose meaning, alerts lose sequence, and evidence loses credibility.  Ultimately, synchronised clocks are a cornerstone of trust in every security and operational decision.