If you have been working within the world of information security for a while, you probably know that ISO 27001 underwent a significant facelift recently. Moving from the 2013 version to the 2022 version felt a bit like reorganising a massive library; the books are mostly the same, but the shelves have been moved, and the indexing system is much sharper. One area that often gets overlooked but is vital for forensic integrity is Annex A 8.17, which covers Clock Synchronisation.
Table of contents
The Shift from Annex A 12.4.4 to Annex A 8.17
In the older ISO 27001:2013 standard, you would find the requirements for clock synchronisation tucked away under control 12.4.4. It sat within the “Logging and Monitoring” section. In the 2022 update, this has been reclassified as Annex A 8.17.
The transition isn’t just about a change in numbering. The 2022 version of the standard introduced “Attributes,” which allow organisations to categorise controls by type (like Preventive or Detective) or operational capability. According to Hightable.io, Annex A 8.17 is now firmly categorised as a “Technical” control. This shift reflects a more modern approach to how we view security infrastructure, it’s not just a box to tick for an audit; it’s a functional technical requirement for the modern digital estate.
What Actually Changed in the Requirement?
The core objective remains the same: ensuring that the clocks of all relevant information processing systems within an organisation are synchronised to a single reference time source. However, the 2022 version is more concise and aligned with the new structure of the ISO 27002:2022 guidance.
In the 2013 version, the focus was heavily on the “protection” of the logs and the clocks. In the 2022 version, while protection is still key, the emphasis is placed on the consistency of the time source. If your servers, firewalls, and applications are all singing from different hymn sheets regarding time, your ability to track a security incident becomes almost impossible. Annex A 8.17 ensures that when you are investigating a breach, the sequence of events is accurate across all platforms.
Why Does Annex A 8.17 Matter for Your Audit?
When transitioning to the 2022 version, auditors will look for more than just a mention of Network Time Protocol (NTP). They want to see that you have a documented, consistent approach. As noted by Hightable.io, the primary goal here is to support forensic investigations and meet legal or regulatory requirements that might require timestamped evidence.
If you are still operating on a 2013 mindset, you might only be thinking about your internal servers. The 2022 update encourages you to think about your entire “Physical” and “Technical” landscape, including cloud services and mobile devices that interact with your network.
Practical Steps for Implementing the 2022 Changes
To meet the updated expectations for Annex A 8.17, there are a few practical steps you should take:
- Identify a Reference Source: Ensure you are using an external, reliable time source (like an atomic clock or GPS-based time) rather than just relying on a random server’s internal clock.
- Monitor for Deviations: It isn’t enough to set it and forget it. You should have a way to detect if a system’s clock begins to drift significantly.
- Document the Settings: Your Statement of Applicability (SoA) should clearly reflect the transition from 12.4.4 to 8.17, and your internal policies should be updated to match the new numbering.
The Bottom Line
While Annex A 8.17 Clock Synchronisation might seem like a minor technical detail, it is a foundational element of a robust Information Security Management System (ISMS). The move from the 2013 version to the 2022 version simplifies the control but demands a more integrated, technical application. By aligning your systems to a single time source, you aren’t just passing an audit; you are ensuring that if the worst happens, you have the data needed to understand exactly what happened and when.