In this guide you will learn how to implement ISO 27001 Annex A 8.17 Clock Synchronisation and pass your audit from ISO 27001 Lead Auditor Stuart Barker – author of the ultimate ISO 27001 Toolkit.
ISO 27001 Annex A 8.17 Clock Synchronisation is an ISO 27001 control that requires us to ensure the all the clocks of all systems are synchronised to an approved time source.
Table of contents
Key Takeaways
- ISO 27001 Annex A 8.17 requires that the clocks of all relevant information processing systems (servers, laptops, firewalls, databases) are synchronised to a single, consistent time source.
- This ensures that timestamps in your system logs are accurate, which is vital for incident investigation, forensic evidence, and meeting legal or regulatory requirements.
Purpose & Definition
ISO 27001 Annex A 8.17 is a detective control to enable the correlation and analysis of security-related events and other recorded data, and to support investigations into information security incidents.
The ISO 27001 standard defines ISO 27001 Annex A 8.17 as:
The clocks of information processing systems used by the organisation should be synchronised to approved time sources.
ISO27001:2022 Annex A 8.17 Clock Synchronisation
White Label
ISO 27001 for Consultants
Custom-brandable ISO 27001 documentation for consultants. Easily rebrand, reduce project time, and deliver professional, high-value security systems. Focus on delivery, not drafting.
FREE ISO 27001 Annex A 8.17 Training Video
In this free training video you will learn How to implement ISO 27001 Clock Synchronisation (Annex A 8.17) and Pass Your Audit
ISO 27001 Annex A 8.17 Requirements and Guidance
The whole point of this control is so that everything is synchronised and that it is reporting and recording and using the same time. This information is used in information security incidents and at the most extreme case in investigations. It is part of evidence gathering and would need to be in place for criminal investigations.
The advice here would be to speak with your technical teams on the best approach and best technology to use.
The need may arise from legal, regulatory, statutory, contractual, standards and internal monitoring needs. So this would be the first place to look to see if there is anything specific that you need to do.
The basic premise is to get all clocks of all devices on the same page. This includes things you might not consider such as building entry systems or surveillance systems.
It is probably more practical to have all devices of a type synced to the same source rather than every device of every type connected to the same source. Some systems may use there own time source for example. A clock for each service is acceptable with any difference recorded in order to mitigate the risk of discrepancies.
The advice of the standard talks of linking to a radio time broadcast from a national atomic clock or global positioning system (GPS) and protocols such as networking time protocol ( NTP ) or precision time protocol (PTP) to keep all networked systems in synchronisation with a reference clock.
For small organisations a lot of this can be overkill and it would be the advice to pursue the most technically simple option available.
Recommended NTP Sources
- Public Internet:
pool.ntp.org - AWS Cloud:
169.254.169.123(Amazon Time Sync) - Google Cloud:
time.google.com - Azure:
time.windows.com
Logging and Monitoring Policy Template
The logging and monitoring policy sets out the approach to clock synchronisation.
Logging and Monitoring Policy Example
An example of the ISO 27001 Logging and Monitoring Policy.
How to implement ISO 27001 Annex A 8.17
Accurate clock synchronisation is a fundamental technical requirement for ensuring the integrity of audit logs, facilitating forensic investigations, and maintaining the reliability of time-sensitive transactions. By following these technical steps, your organisation can establish a unified time source across all operational systems to satisfy ISO 27001 Annex A 8.17 requirements.
1. Formalise a Time Synchronisation Policy
- Document a formal policy that defines the primary and secondary time sources for the organisation, such as Stratum 1 or Stratum 2 atomic clocks.
- Establish the “Rules of Engagement” (ROE) for time deviations, specifying the maximum allowable drift before an automated alert is triggered.
- Result: A documented governance standard that ensures consistent timekeeping across all geographic locations and cloud regions.
2. Provision a Centralised NTP or PTP Infrastructure
- Deploy a hierarchical Network Time Protocol (NTP) or Precision Time Protocol (PTP) architecture to distribute time from a trusted reference to all internal hosts.
- Configure internal “Master” time servers to synchronise with reputable external sources, such as the National Physical Laboratory (NPL) or NIST.
- Result: Elimination of time discrepancies between disparate systems, ensuring that logs from multiple sources can be accurately correlated.
3. Restrict Management Access via IAM and MFA
- Enforce the Principle of Least Privilege by assigning specific Identity and Access Management (IAM) roles to the administrators of time-serving infrastructure.
- Mandate Multi-Factor Authentication (MFA) for any configuration changes to NTP servers or hardware clocks to prevent unauthorised time manipulation.
- Result: Protection against “Time Shifting” attacks where an adversary modifies system clocks to bypass certificate expirations or obscure log entries.
4. Secure Time Distribution via Autokey or Symmetric Keys
- Implement cryptographic authentication for NTP traffic using symmetric keys or Autokey to prevent Man-in-the-Middle (MITM) or spoofing attacks.
- Configure firewalls to permit NTP traffic (UDP port 123) only from authorised internal servers and trusted external IP ranges.
- Result: Assurance that time signals received by client devices are authentic and have not been tampered with during transit.
5. Execute Continuous Drift Monitoring and SIEM Logging
- Configure all operational systems to export clock synchronisation status and drift logs to a centralised SIEM platform.
- Establish automated alerts for “Sync Failure” or “Unauthorised Time Source” events to detect potential hardware failures or malicious activity in real time.
- Result: Enhanced situational awareness and a verifiable audit trail demonstrating continuous compliance with synchronisation standards.
6. Perform Periodic Verification and Compliance Audits
- Conduct quarterly technical audits to verify that system clocks remain within the tolerance levels defined in your organisation’s security policy.
- Revoke access for any unauthorised time sources discovered during the audit and remediate systems that have drifted beyond the permitted threshold.
- Result: Sustained accuracy of the forensic roadmap, ensuring that time-stamped evidence remains admissible in legal or regulatory proceedings.
Check Your Work?
You built it yourself. Maybe with AI. But will it pass the audit?
Don’t gamble – let an ISO 27001 Lead Auditor check your work.
What will an auditor check?
The audit is going to check a number of areas. Lets go through the main ones
1. That you have documentation
What this means is that you need to show that you have documented your clock synchronisation. This may be just recording what you do but be sure to understand how your clocks are synchronised and be able to show it.
2. That you have have implemented clock synchronisation appropriately
They will look at systems to seek evidence of clock synchronisation. They want to see evidence of clock synchronisation and the process in operation. It maybe that they look for evidence that you have used it as part of information security incident management.
3. That you have conducted internal audits
The audit will want to see that you have tested the controls and evidenced that they are operating. This is usually in the form of the required internal audits. They will check the records and outputs of those internal audits.
ISO 27001 Annex A 8.17 FAQ
An approved source is a time reference that is traceable to a national or international standard, such as UTC (Coordinated Universal Time).
You do not need to buy an atomic clock. You simply need to configure your systems to pull time from a reputable external Stratum 1 or Stratum 2 NTP server.
Common examples include:
pool.ntp.org: The standard public pool of time servers.
Cloud Providers: AWS Time Sync Service, Azure Time Sync, or Google Public NTP.
National Institutes: NIST (time.nist.gov) in the USA or NPL in the UK.
Clock drift is a minor technical failure that can lead to a major non-conformity.
“Drift” occurs when a computer’s internal clock runs slightly faster or slower than real time. If an auditor sees that your Domain Controller is 5 minutes ahead of your Web Server, it proves you are not actively managing Control 8.17.
Auditor checks typically involve:
Comparing the time on your workstation against your server logs during a live demo.
Reviewing configurations to see if devices check for time updates frequently (e.g., every 15 minutes vs. once a day).
Asking for evidence of alerts when a server drifts beyond a set threshold (e.g., >1 second).
Yes, and hybrid environments are where most mistakes happen.
In a cloud environment (SaaS/PaaS), the provider (like Microsoft or Amazon) manages the hardware clock. However, your virtual machines (IaaS) and on-premise servers are your responsibility. A common failure is having on-premise servers sync to a local radio clock while cloud servers sync to AWS time, resulting in slight discrepancies.
Best Practice: Point all internal on-premise NTP servers and all cloud instances to the same external reference authority (e.g., the same public NTP pool) to ensure consistency across the board.
Many security protocols rely on “time-stamped tickets” to prevent replay attacks (where a hacker intercepts and reuses a login credential). If the time difference between the client and the server is too large, the ticket is rejected.
Critical dependencies include:
Kerberos / Active Directory: Usually fails if clocks differ by more than 5 minutes.
MFA Tokens (TOTP): Google Authenticator codes are time-based; drift causes valid codes to be rejected.
SSL/TLS Certificates: If a clock is reset to a past date, valid website security certificates may appear “not yet valid,” breaking encrypted connections.
Related ISO 27001 Controls
ISO 27001 Templates
Further Reading
- ISO27001:2022 Reference Guide
- ISO 27001 Logging and Monitoring Policy Beginner’s Guide
- How To Create an ISO 27001 Threat Intelligence Process and Report
About the author
