Clock synchronization
The clocks of the organization's information processing systems are to be kept in step with approved time sources.
What the requirement asks
The clocks of the organization's information processing systems are to be kept in step with approved time sources. Purpose: allow security events and other recorded data to be correlated and analysed, and support incident investigations. Guidance: document and implement external and internal requirements for how time is represented, how reliably it is synchronized and how accurate it must be, which may come from law, regulation, contracts, standards or internal monitoring. Define one standard reference time for the organization and apply it to all systems, including building management, entry and exit and other systems that may help investigations. Use a reference clock for logging systems tied to a national atomic clock radio broadcast or GPS, giving a consistent, trusted source for accurate timestamps, and keep networked systems aligned with it through protocols such as NTP or PTP. Two external time sources can be used together to improve reliability, with any difference between them managed. Where several cloud services, or cloud and on-premises services, are combined, synchronization is harder, so monitor each service's clock and record the difference to limit the risk of discrepancies. Other information: correct clocks keep event logs accurate, which matters for investigations and for evidence in legal or disciplinary cases; wrong timestamps hamper investigations and weaken evidence. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.
What the guidance adds
Clock synchronisation makes the timeline reliable. The guidance asks for the source, the scope, the drift check and the exception.
Status of the guidance. The guidance lens for 8.17 reads the draft, which is at stage 40.00 and is not published, against the published ISO/IEC 27001:2022 requirement above. It is our reading, not a quotation, and it is not a requirement.
What good looks like
Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep documented time requirements (representation, accuracy, synchronization) and the defined organizational reference time and one live sample together.
Evidence an assessor asks for
- Time synchronizationDocumented time requirements (representation, accuracy, synchronization) and the defined organizational reference time
- Time synchronizationNTP or PTP configuration showing systems synchronized to the approved reference clocks, including building management and physical access systems
- Time synchronizationEvidence of a trusted reference source such as GPS or national time service, and use of two external sources where adopted
- Time synchronizationMonitoring of clock drift across systems, with alerts on deviation
- Time synchronizationRecords of time offsets for cloud services where direct synchronization is not possible
The question an assessor will ask
An assessor will ask for documented time requirements (representation, accuracy, synchronization) and the defined organizational reference time, then trace it to the system it protects. For A.8.17 the test is whether that record ties to a live sample, not whether the control is named in a policy.
Common gaps
- Physical access and CCTV systems run on unsynchronized clocks, breaking correlation with IT logs
- Systems synchronize to arbitrary internet time servers not approved by the organization
- Time zones are mixed across logs without a standard representation
- Clock drift is not monitored, so failures of the time service go unnoticed
Before the next audit
Before the next audit, check one live sample for this gap: physical access and cctv systems run on unsynchronized clocks, breaking correlation with it logs.