ISO 27001 A.8.17: Align system clocks for reliable event analysis
Clock synchronisation helps records from different systems form a reliable account of events. ISO 27001 Annex A.8.17 concerns aligning information-processing system clocks with approved time sources. Without a suitable arrangement, an investigation can confuse cause and effect because two systems describe the same period using inconsistent time.
What A.8.17 requires in practice
A.8.17 requires the clocks on the organisation's information processing systems to be synchronised to approved time sources. When different systems record events with different times, it becomes difficult or impossible to reconstruct what happened in what order.
In practice the organisation decides which time sources it trusts, configures its systems to follow them and keeps track of any system that cannot. The scope reaches beyond servers: network equipment, security devices, cloud services, applications and specialised equipment all produce records that may need to be compared. Where a provider controls the clock, the organisation needs to understand what the provider does and what remains its own responsibility.
Outputs include approved time sources, systems configured to use them and a way of noticing drift. The control sets no accuracy figure; the organisation decides what accuracy its investigations and obligations need. Comparing a sample of records from different systems is a method Sterling's teams use to confirm the timeline holds together.
Define the accuracy the organisation actually needs
Consider why timestamps matter in the environment. Correlating routine access records may have different precision needs from a specialised transaction process. Applicable contractual, legal or technical requirements can also influence the decision. Identify relevant requirements rather than assuming that a clock displaying approximately the correct time is sufficient.
Agree the reference and representation used for analysis. Time zones and display formats can differ even when underlying clocks are aligned. Records should contain or preserve enough context to interpret their timestamps. A local display choice should not create ambiguity when the same event is reviewed by teams in different locations.
Identify sources, settings and ownership
Use approved sources appropriate to the systems and their connectivity. Relevant protocols and technical arrangements should be selected and configured by competent personnel. Document responsibilities for the time service and the systems that rely on it, including what happens when the normal source becomes unavailable.
Include less obvious information sources where they support investigations, such as entry systems or building-management records. Connect the arrangement with logging and physical security monitoring. A well-aligned server estate does not automatically make a separate access-control appliance's timestamps reliable.
Why clock synchronisation matters to the business
Time is the thread that ties records together. During an investigation, a few minutes of difference between systems can reverse apparent cause and effect, point suspicion at the wrong person or leave a gap that cannot be explained. Regulators, clients and courts may rely on timestamps when assessing what happened and when the business knew. Accurate time also helps ordinary operations, such as diagnosing faults across several systems or reconciling transactions. The control costs little to run and yet underpins the value of logging, monitoring and incident evidence. Auditors often use it as a quick check on the quality of the wider evidence trail: if the clocks disagree, confidence in the logs falls.
How to implement A.8.17
Treat time as shared infrastructure with an owner, a standard and a way of checking it. The effort is small compared with the investigation problems it prevents.
- Decide what accuracy your investigations, contracts and obligations need, and note any system with stricter needs.
- Choose the approved time sources, including a fallback, and record who maintains that choice and how it is communicated to administrators.
- List the systems that keep time, including network equipment, security tools, cloud services and specialised devices, not only servers.
- Configure each to follow the approved sources and record those that cannot, with the compensating arrangement.
- Understand provider-controlled clocks, and confirm what the provider's own records reflect.
- Check for drift on a sample by comparing records from different systems for the same event, and follow up any system whose clock is repeatedly out of line.
- Review the arrangement when systems or providers change, and make time configuration part of the build standard for new equipment so it is not forgotten.
Illustrative IT example: cloud and local records appear out of order
A fictional IT provider investigates a support action involving a cloud application and a local identity system. An exported report appears to show the application action before the relevant login. The team initially assumes that the order proves an unexplained access route.
Review establishes that the reports use different time representations and that one local source also has an unexpected clock difference. The team preserves the original records, documents the interpretation and corrects the operational setting through an authorised process. The example shows why analysts should establish time context before drawing a conclusion from apparent event order.
Illustrative construction example: a site access appliance
A hypothetical construction project uses a local entry-recording appliance at a temporary office. After a connectivity change, it no longer reaches its approved time source. A later review compares its records with a project document system and finds a discrepancy that makes the sequence difficult to interpret.
The organisation checks the appliance's configuration, assigns responsibility for its time status and establishes a suitable way to recognise loss of synchronisation. An authorised sample event is compared with the relevant system record. The correction improves future evidence, while the limitations of older records remain documented rather than retrospectively disguised.
Check drift and provider limitations
A configured time source does not prove continuing synchronisation. Review actual status and meaningful differences, with an appropriate response to failed updates or excessive drift. Choose checks according to the required accuracy and the consequences of losing it. Avoid imposing a precise numerical tolerance without a justified purpose.
For cloud or supplier systems, understand which settings the organisation can control and what information the provider supplies. Where direct alignment is difficult, record relevant differences and their implications for analysis. The organisation should be able to explain the limitation and how it handles it, rather than claim uniform precision it cannot demonstrate.
Evidence and tests for a dependable timeline
Useful evidence includes approved sources, relevant accuracy requirements, implemented settings, status observations and investigation notes describing material differences. These are practical ways to support the selected control, not a required collection of separate forms. Protect operational details appropriately when sharing evidence outside the responsible team.
A safe test can compare representative records for one authorised event across the systems involved. Check both their clock alignment and their interpretation, including time-zone context. This exercise can expose a misleading display format even where synchronisation itself is working. Repeat relevant checks after changes to infrastructure or supplier arrangements.
Common failures include manually correcting clocks without understanding why they drift, overlooking isolated appliances and changing historical records to make a timeline appear consistent. Preserve original evidence and explain any analytical adjustment separately. Coordinate configuration changes with configuration management and review the control through ISMS evaluation.
Common nonconformities with A.8.17
Time findings usually appear when records from several systems are put side by side.
- Servers synchronised, but network, security or specialised devices keeping their own time.
- Several different time sources in use, with no decision on which is approved.
- Cloud and on-premises records that cannot be lined up in a single timeline during an investigation, because nobody had checked the offsets.
- No process to detect a clock that has drifted or failed to synchronise.
- Time zones or daylight settings inconsistent across systems, with no record of the convention.
Frequently asked questions
Does ISO 27001 specify one permitted clock difference?
No universal tolerance is given by this control. Determine suitable accuracy using the organisation's analysis needs and applicable requirements, then verify that the arrangement meets them.
Do all systems need to display the same local time?
Not necessarily. Different displays can represent the same underlying time. The important points are appropriate synchronisation and enough context to interpret and compare records correctly.
Should we edit old logs after finding clock drift?
Preserve original evidence. Document the known difference and any interpretation separately, while correcting the operational cause through an authorised process.
Improve the reliability of security evidence
Discuss event-evidence reliability with Sterling, including scoped ISMS documentation, implementation support, employee learning and agreed Effivity ISO & GRC automation software. The wider programme can include authorised vulnerability scanning and findings review, with continuing support through defined preparation; certification is decided independently. Enrol in ISO/IEC 27002 Information Security Controls to connect time accuracy with the technological controls.