ISO 27001 Annex A 8.17: clock synchronisation without a policy

The due-diligence questionnaire asks how you keep system clocks consistent. Your cloud instances sync themselves, but nobody can say what the firewall, the door controller and the CCTV recorder follow, and no document names a time source. This guide covers ISO 27001 Annex A 8.17 for UK regulated firms and B2B SaaS teams of 25–250 people: what the control asks, which sources to name, what an auditor samples and how to automate the evidence.

The short version is reassuring. ISO 27001 clock synchronisation is a platform property you engineer in once, not a policy you maintain. Standardise on your cloud provider's time service, log in UTC, sweep the forgotten devices and alert on drift.

What does ISO 27001:2022 Annex A 8.17 clock synchronization require?

ISO 27001:2022 Annex A 8.17 requires every system whose records might matter to keep its clock tied to a trusted, agreed time reference. The goal is simple: events from a firewall, laptop, server and badge reader can be laid side by side and trusted as one timeline.

The wording is short, and the reach is wider than it first looks. Servers and laptops are the obvious cases. Door entry systems and CCTV count too, because investigations lean on them to place a person or a device at a moment in time. If a record might matter later, the clock behind it is in scope.

A.8.17 exists to serve its neighbours. The log data you collect under A.8.15 is only useful if entries from different systems can be correlated. The anomaly detection in A.8.16 needs to sequence what it sees. Time is the join key between every log source you own.

The control descends from A.12.4.4 in ISO 27001:2013 and keeps the same intent. We classify it in three ways:

• Detective. Accurate time doesn't stop an attack. It makes detection and reconstruction possible, so its value arrives when you work out what happened and in what order.
• Protects integrity. The property at stake is the trustworthiness of timestamps and the records built on them, including their credibility as legal evidence.
• Engineered in once. It is a property of how the platform is designed, built once rather than run as a daily operational process.

Read together, the three describe one job: build reliable time into the platform once, then prove it held.

What does sync time mean across networked systems, logs and forensics?

Sync time means every networked system holds the same clock reading, within a tolerance you choose, by regularly checking against a trusted external source. Without it, internal quartz oscillators drift by several seconds a day, so logs from different systems stop agreeing and forensic timelines become unreliable.

Drift is physical, not a configuration mistake. Most computer clocks rely on inexpensive quartz oscillators, and errors of many minutes accumulate over time. The National Physical Laboratory Network Time Protocol service exists because computers need regular synchronisation against a trusted external source.

Setting a clock correctly at installation therefore proves nothing a month later. The control wants a mechanism that keeps checking. In practice that is a time client on each system, pointed at a named source and correcting the clock continuously.

Three terms keep the conversation with an auditor straight:

• Reference time: the trusted source your estate agrees on, such as a cloud provider's time service or a national standards body.
• Tolerance: how far a clock may stray before you treat it as a fault. You choose it, you write it down and you alert on it.
• Synchronisation: the regular check that pulls each clock back to the reference. NTP does this for almost every system at your scale.

The forensic angle explains why tolerance matters. When you reconstruct an incident, you are ordering events across a firewall, an identity provider and an endpoint. A tight, stated tolerance keeps that ordering honest. A tolerance nobody has defined means nobody can say how far to trust the sequence.

Why does clock synchronisation matter for investigations and uptime?

Skewed clocks bite twice. During an incident, a few minutes of drift can make an attack sequence impossible to reconstruct and weaken records as legal evidence. Day to day, drift quietly breaks Windows domain sign-ins past about five minutes, time-based MFA codes and certificate validation; A.8.15 logging and A.8.16 monitoring both depend on it.

The incident side is the one auditors imagine. A phishing victim's laptop, your identity provider and a cloud console each log part of an intrusion. If their clocks disagree by several minutes, the order of events flips, and the account you give an insurer or regulator has gaps you cannot explain.

A timeline built from clocks that disagree is fiction.

Evidence value follows the same logic. If a matter ends up in a dispute, a tribunal or a regulatory investigation, records with indefensible timestamps lose their force. The NCSC guidance on introduction to logging for security purposes makes synchronisation to an accurate time source part of configuring log sources properly.

The daily outages are quieter, and they cost whole mornings:

• Windows domain sign-ins fail once skew passes the Kerberos default tolerance of five minutes between client and domain controller.
• Time-based MFA codes are rejected when the phone and the server disagree about the current time window.
• Certificate validation misfires when a clock sits outside a certificate's validity period, so a healthy service looks broken.

These failures look like mysteries until someone checks the clock. That makes time an availability issue as well as a forensic one, which helps when the person funding the fix cares about uptime rather than audit.

For the price of a configuration setting, this is the cheapest audit finding a firm can avoid.

Which reference time sources should a 50-person firm use?

Use well-known references: your cloud provider's time service, a national standards body such as NPL in the UK or NIST in the US, or the public NTP pool. Configure two sources where the platform allows it, name them once, and verify that systems actually point at them.

For a cloud-first estate, most of the work is already done. AWS, Azure and Google feed their instances from their own authoritative time services, and modern endpoints sync out of the box. Your job is to verify rather than build: confirm each platform is on its provider's source and that nothing has been pointed somewhere odd.

A verification pass for a 50-person firm runs in this order:

1. List the platforms. Cloud accounts, the identity provider, endpoint management, network kit and any on-premises servers.
2. Record the configured source for each, from console settings or a configuration export.
3. Flag outliers. A virtual machine pointed at an unfamiliar hostname is the usual find.
4. Add a second source wherever the platform allows it.
5. Write the result into your IT operating procedures, so sources and owner sit in one place.

Device-level guidance points the same way. The NCSC device security principles for reliable time sources expect a device to use reliable time sources so security logging and investigation stay accurate. Hold the kit you configure to the standard you would ask of kit you buy.

Two sources matter because a single reference can go quiet unnoticed. One source, no fallback and no alerting means an unreachable reference becomes months of silent drift. Two sources plus a drift alert turn the same failure into a ticket.

How do you keep hybrid and multi-cloud estates on one timeline?

Log everything in UTC and convert for display, then check your cloud and on-premises halves against each other periodically, noting any variance. Two estates each syncing perfectly to different references still leave a split timeline, and mixed local-time logging is the biggest single cause of investigation confusion.

UTC logging is free and removes the argument. The same NCSC logging guidance recommends recording events in UTC. Convert for display, never for storage: dashboards and tickets can show local time to the people reading them, while the stored record stays in UTC.

Hybrid estates need one more step because two halves can each be healthy and still disagree. A cloud provider's time service and an on-premises domain controller syncing to a different pool may sit apart, and a small gap becomes minutes if either drifts.

A periodic cross-check is light work:

1. Pick a sample of cloud instances and on-premises servers, plus one network device.
2. Read each clock's offset against the reference at the same moment.
3. Compare the results with the tolerance in your procedures.
4. Record the variance, even when it is within tolerance, with the date and who ran the check.

A cadence matching your internal audit rhythm works well. A drift monitor, covered in the automation section, removes the manual step altogether.

The mixed time-zone estate is the classic failure: half the logs in UTC, half in local time, and the mismatch surfacing only when someone lines them up under pressure. A UK office paired with a cloud region configured elsewhere meets the problem twice a year when the clocks change.

Do CCTV, door controllers and network kit need clock sync too?

Yes. Firewalls, switches, printers, CCTV recorders, door controllers and any pre-cloud on-prem box fall inside A.8.17, because investigations reach for exactly these devices. Servers and endpoints mostly sync themselves; network and physical security kit mostly doesn't, so sweep them once and put them on the approved source.

A firewall with the wrong time is the worst case, because its logs are the first thing an investigator asks for. A door controller is a close second when you need to place a person on site against a login.

Sweep these once and record the result:

• Firewalls and switches.
• Printers and multifunction devices.
• CCTV recorders and door controllers.
• Any on-premises box that predates the cloud migration.

Point each at the approved source, or at an internal relay where the network segment cannot reach out, and note the date you checked.

If you run your own time infrastructure, protect it as the security dependency it is. Restrict who can reach and reconfigure it, and use authenticated time protocols where supported. Unauthenticated, unwatched time traffic on a network where tampering is credible turns a spoofed clock into an attack on your evidence.

Over-engineering is the opposite failure. A 40-person SaaS firm does not need its own GPS-disciplined time servers. Name your sources, verify the settings, add a drift alert and move on.

Do you need a standalone clock synchronisation policy?

No. At 25–250 people, a single paragraph in your IT operating procedures naming your reference time sources and the drift you will tolerate is enough. A standalone clock policy adds paperwork without adding assurance; the evidence an auditor samples is system configuration, not prose.

The paragraph belongs in the IT operating procedures you already keep for logging and monitoring. It needs four parts:

• the approved reference sources;
• the drift you tolerate;
• the person who checks it;
• a statement that logs are stored in UTC.

A workable version reads:

“All systems synchronise to our cloud providers' time services, with the public NTP pool as secondary. Logs are stored in UTC. Offsets beyond the agreed tolerance raise an alert to IT, who review the alert history quarterly.”

A separate policy also creates a maintenance liability. A document naming sources your estate no longer uses is a finding waiting for a sampler, while the settings in configuration stay current on their own.

What does an auditor check for ISO 27001 Annex A 8.17?

Auditors usually test A.8.17 in passing: they check time settings on a couple of systems during other reviews, compare timestamps across two systems' logs for the same event, and read incident records for a timeline that holds together. Certification bodies typically grade clocks too unmanaged to rebuild a timeline as major, and an unsynced firewall as minor.

Questions to expect in the room:

• "What time source do your systems use, and where is that decided?"
• "How would you spot a server whose clock had drifted?"
• "Are your logs in UTC or local time, and is that consistent everywhere?"
• "What about the CCTV and door systems? Same time reference?"
• "If a source went down, what stops clocks drifting silently?"

Each question maps to something you can show. The first needs the procedure paragraph, the second a drift alert or spot-check record, and the third a UTC setting. The fourth needs the device sweep, and the fifth your second source plus alerting.

Sampling is light, which is why gaps get found by accident. Incident records are read for a coherent timeline across sources, and a report saying "timestamps approximate due to clock differences" hands the auditor the finding.

Minor findings here include local-time logs on one platform or no documented time source. Several of them across the logging and monitoring estate can aggregate into a major, so treat a single gap as a pattern risk.

The pre-emptive check takes two minutes. Pick one event, such as a login, find it in two systems' logs and compare the timestamps. If they match within tolerance and both are in UTC, you have answered the most likely test before it is asked.

How do you automate drift monitoring and audit evidence?

Treat clock sync as a monitored metric and configuration as code. A scheduled check compares each system's clock to reference and alerts past your threshold; baseline images and MDM profiles carry the time settings; the auditor's sample becomes an export of every asset, its time source and last measured offset.

A clock you never measure is a setting, not a control.

In practice, three pieces carry the automation:

• Drift check. An agent or scheduled job reads each system's offset, compares it with the tolerance in your procedures and routes breaches to the same queue as other infrastructure tickets.
• Time settings in baselines. Golden images, MDM profiles and infrastructure code all carry the approved source, so a machine with the wrong one becomes a compliance-scan hit rather than a manual discovery.
• Evidence on demand. Your configuration-management or monitoring platform exports every asset, its time source and its last measured offset when the auditor asks.

Sequencing is modest. Allow half a day to verify a cloud-native estate and a day or two where on-premises network kit and physical security devices need bringing into line. Do it alongside your logging build-out under A.8.15, because synchronised time is what makes that investment usable, and before any monitoring maturity work that assumes it.

This is a textbook small win for GRC engineering: a control most firms evidence by hand becomes fully automated. Once the checks run, the audit sample is an export and the control stops costing attention.

Frequently asked questions