ISO 27001 Annex A 8.17 is a security control that mandates the synchronization of all information processing system clocks to a single, consistent time source. This ensures accurate timestamps for logs, which are vital for incident investigation, forensic analysis, and proving the sequence of events during legal or regulatory reviews.
In this guide, I will show you exactly how to implement ISO 27001 Annex A 8.17 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.
I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.
Key Takeaways: ISO 27001 Annex A 8.17 Clock Synchronisation
ISO 27001 Annex A 8.17 requires that the clocks of all relevant information processing systems (servers, laptops, firewalls, databases) are synchronized 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.
Core requirements for compliance include:
- Single Trusted Source: You must use an authoritative time source (e.g., an atomic clock or a trusted provider like Google, Microsoft, or a national laboratory). All your devices should sync to this central “Golden Clock.”
- Network Time Protocol (NTP): This is the industry-standard method for syncing clocks over a network. You should prove that NTP is configured on all servers and network hardware.
- Consistency in Logs: If an incident occurs, you need to be able to correlate events. If your firewall says an attack happened at 10:00 AM, but your database says it was 10:05 AM, your “forensic trail” is broken.
- Legal Admissibility: Accurate timestamps are required if you ever need to use logs as evidence in a court of law or for a regulatory filing.
Audit Focus: Auditors will look for “The Time Drift”:
- Configuration Check: They will ask to see the NTP settings on a random server.
- The Proof: “Show me that your server time matches the actual current time in your region.”
- The Chain: If you operate globally, how do you handle Time Zones? (Usually, systems should be set to UTC to maintain a universal baseline).
Clock Sync Best Practices:
| Setting | Recommendation | Why it matters |
|---|---|---|
| Protocol | Use NTP or SNTP. | It is the automated standard for time sync. |
| Time Source | Use a trusted external source (e.g., pool.ntp.org). | Ensures your company isn’t drifting away from real-world time. |
| Standard Time | Set server clocks to UTC. | Prevents confusion during Daylight Savings or across global offices. |
| Monitoring | Check for sync failures. | Alerts you if a server stops receiving time updates and starts to “drift.” |
Table of contents
- Key Takeaways: ISO 27001 Annex A 8.17 Clock Synchronisation
- What is ISO 27001 Annex A 8.17?
- ISO 27001 Annex A 8.17 Free Training Video
- ISO 27001 Annex A 8.17 Explainer Video
- ISO 27001 Annex A 8.17 Podcast
- ISO 27001 Annex A 8.17 Implementation Guidance
- How to implement ISO 27001 Annex A 8.17
- Recommended NTP Sources
- What will an auditor check?
- Applicability of ISO 27001 Annex A 8.17 across different business models.
- Fast Track ISO 27001 Annex A 8.17 Compliance with the ISO 27001 Toolkit
- ISO 27001 Annex A 8.17 FAQ
- Related ISO 27001 Controls
- Further Reading
What is ISO 27001 Annex A 8.17?
ISO 27001 Annex A 8.17 is about clock synchronisation which means that the time on all your devices should be exactly the same and centrally managed.
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.
ISO 27001 Annex A 8.17 Purpose
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.
ISO 27001 Annex A 8.17 Definition
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
ISO 27001 Annex A 8.17 Free Training Video
In the video ISO 27001 Clock Synchronisation Explained – ISO27001:2022 Annex A 8.17 I show you how to implement it and how to pass the audit.
ISO 27001 Annex A 8.17 Explainer Video
In this beginner’s guide to ISO 27001 Annex A 8.17 Clock Synchronisation, ISO 27001 Lead Auditor Stuart Barker and his team talk you through what it is, how to implement in and how to pass the audit. Free ISO 27001 training.
ISO 27001 Annex A 8.17 Podcast
In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001:2022 Annex A 8.17 Clock Synchronisation. The podcast explores what it is, why it is important and the path to compliance.
ISO 27001 Annex A 8.17 Implementation 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.
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.
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
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.
Applicability of ISO 27001 Annex A 8.17 across different business models.
| Business Type | Applicability | Examples of Control Implementation |
|---|---|---|
| Small Businesses | Applies to ensuring that office hardware, such as laptops and routers, all follow a consistent time source. The goal is to make sure that if a security incident occurs, logs from different devices can be compared accurately. |
|
| Tech Startups | Critical for cloud-native infrastructure. All servers, databases, and microservices must share a unified time baseline (usually UTC) to maintain the integrity of audit trails and distributed systems. |
|
| AI Companies | Vital for high-speed data ingestion and training cycles. Accurate timestamps are required to ensure data integrity during model training and to correlate access logs for proprietary datasets. |
|
Fast Track ISO 27001 Annex A 8.17 Compliance with the ISO 27001 Toolkit
For ISO 27001 Annex A 8.17 (Clock synchronisation), the requirement is to ensure that the clocks of all information processing systems are synchronised to approved time sources. This is a critical detective control – without unified time, correlating logs during an incident investigation is nearly impossible.
| Compliance Feature | SaaS Compliance Platforms | High Table ISO 27001 Toolkit | Audit Evidence Example |
|---|---|---|---|
| Data Ownership | Rents your standards back to you via a proprietary web interface. | Permanent Assets: Fully editable Word/Excel policies that you own forever. | Policy specifying use of pool.ntp.org or AWS Time Sync stored on your internal wiki. |
| Technical Integration | Requires complex “continuous monitoring” modules and API hooks. | Zero Friction: Formalizes your existing NTP/PTP setups with professional governance. | Server configuration screenshots showing active sync to an approved stratum 1 source. |
| Cost Efficiency | Monthly “per-device” or “infrastructure health” subscription fees. | One-Off Fee: A single payment covers 5 servers or 500 across your entire estate. | Documented clock sync procedures that don’t add to your monthly OpEx budget. |
| Infrastructure Freedom | Mandates specific integrations; often fails to reflect hybrid or specialized hardware. | Tech-Agnostic: Works with GPS-linked atomic clocks, cloud-native sync, or radio broadcasts. | Custom procedures tailored to specialized local radio time broadcasts or air-gapped systems. |
Summary: For Annex A 8.17, the auditor wants to see that you have a policy for clock synchronisation and that you follow it. The High Table ISO 27001 Toolkit provides the governance framework to do exactly that. It is the most direct, cost-effective way to satisfy the requirement with professional, permanent documentation that you own and control.
ISO 27001 Annex A 8.17 FAQ
What is ISO 27001 Annex A 8.17 Clock Synchronisation?
It is the requirement that all systems within your organization agree on the exact same time, down to the second.
Think of this control like a team of bank robbers in a movie synchronising their watches before a heist. If one robber is 30 seconds late, the plan fails. In cybersecurity, if your firewall, server, and authentication logs don’t have the exact same time, you cannot reconstruct the “scene of the crime” during an investigation.
Key requirements include:
- Single Source of Truth: All internal systems must sync to a reliable external time source (like an atomic clock via NTP).
- Cross-System Consistency: Servers, laptops, and network gear must all display the same time.
- Drift Management: Systems must be monitored to ensure they don’t slowly deviate from the correct time.
Why is clock synchronisation considered a “Detective Control”?
Because without accurate time, you cannot solve the mystery of a security breach.
Annex A 8.17 doesn’t prevent an attack; it ensures you can investigate it. When a hacker moves through your network, they leave footprints (logs) on multiple devices. If your Firewall says an attack happened at 10:00 AM, but your Database says 10:05 AM due to a clock error, you cannot correlate those events. The “detective” (your security analyst) will fail to see the pattern.
What is an “approved time source” for ISO 27001 compliance?
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.
How does clock drift affect my ISO 27001 audit?
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).
Does this control apply to cloud and hybrid environments?
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.
Can incorrect time settings break security features other than logs?
Yes, incorrect time can cause critical authentication systems to fail, effectively locking you out of your own network.
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.
What documentation is required for Annex A 8.17?
You need to prove that you have a policy, a configuration, and a monitoring process.
It is not enough to just “switch on” NTP. You must document your approach to show it is intentional and managed.
Essential evidence includes:
- Topic Specific Policy: A statement defining your “Standard Reference Time” (e.g., UTC).
- Asset Inventory: A list of critical systems and their defined time sources.
- Configuration Screenshots: Evidence showing NTP settings on firewalls, servers, and switches.
- Drift Logs: Records showing that time is checked and corrected automatically.