SekitCrosswalk
ISO/IEC 27001:2022 · derived mapping target

A.8.17Clock synchronization

Synchronize the clocks of your systems to a reliable time source, so logs and events line up and investigations can reconstruct what happened.

Mapped from the Sekit CSF

The Sekit controls that cover this requirement, lens by lens.

NIST CSF 2.0 counterparts

Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.

Evidence that proves this control

What an auditor, or Sekit's evidence engine, asks for.

Time synchronization configuration
The proof that all systems have their clocks synchronised to a trusted source, which is key for investigating incidents.
From the Sekit evidence catalog

In practice

Clock sync sounds trivial until an investigation needs to line up a firewall log with an endpoint alert and the two timestamps do not match, because each device kept its own idea of the current time. What works: point every server, workstation and network device at the same NTP source, and alert automatically when a clock drifts past a defined threshold instead of discovering it during an incident. Cloud services usually sync themselves, but self-managed servers and network gear are where drift happens. Auditors rarely dig deep here; they check one server's clock against the reference source and ask what the alert threshold is.

Common gaps

NTP is configured on servers but a handful of network devices were left on their default internal clock, drifting minutes out of sync with the rest.
There is no alert when a clock drifts, so the only way drift gets noticed is when an investigation fails to correlate two log sources.
The time synchronization policy names a trusted source, but nobody has verified that every device points to it rather than an old default.

Questions your auditor will ask

Are all systems synchronized to the same trusted time source?
Yes, every server, workstation and network device points to the approved NTP source named in the time synchronization policy.
What happens if a system's clock starts to drift?
An alert fires automatically when drift crosses the defined threshold, so it is caught before it interferes with correlating events during an investigation.
How is time synchronization verified across the environment, beyond the initial configuration?
A recurring check confirms clocks across servers, endpoints and network devices still match the approved source, not only at initial setup.

Where regulation demands it

NIS2 art. 3.2 requires monitoring and logging capable of reconstructing events, which depends on clocks staying synchronized across all systems.

Related controls

Via the shared Sekit CSF topic, not the framework's own index.

Ask Sekura: “What evidence proves A.8.17?”
Also via MCP, free with account