EN FR Home

ISO 27001 NTP — Control 8.17
Clock Synchronization Audit Guide

Mapping Annex A.8.17 to authenticated NTP infrastructure

Published 12 May 2026 · By Richard DEMONGEOT, RDEM Systems · Target audience: ISMS owners, internal auditors, and CISOs preparing or maintaining ISO/IEC 27001:2022 certification.

1. The control text (ISO/IEC 27001:2022 Annex A.8.17)

ISO/IEC 27001:2022 publishes its full control set in Annex A. Control 8.17 — under the Technological controls theme — reads:

A.8.17 Clock synchronization. The clocks of information processing systems used by the organization shall be synchronized to approved time sources.

The implementation guidance lives in the companion standard ISO/IEC 27002:2022, which expands on what "approved time source" and "synchronized" mean in practice. The 27002 guidance does not name protocols, but the following requirements are explicit:

The phrase "approved time sources" is the load-bearing one. In 2026 — given documented attacks on unauthenticated NTP — auditors increasingly treat approved as implying authenticated.

2. Why 8.17 is the most under-evidenced control in real audits

Across 200+ ISO 27001 audits documented publicly by ENISA, BSI and ANSSI between 2022 and 2025, the clock-synchronization control is among the top-five most frequently flagged with a minor non-conformity. Three patterns dominate the findings:

Pattern 1 — "We use NTP" without a policy. The organization points to a chrony service running on each host and considers the control closed. The auditor asks for the time-source policy. There is none, the hosts use whatever the cloud provider injected, and the ISMS cannot demonstrate that the source is "approved" in any defensible sense.
Pattern 2 — Policy exists, configuration drifts. The policy lists 0.pool.ntp.org through 3.pool.ntp.org; production hosts actually point to a defunct internal stratum-2 that fell back to stratum 16 six months ago. The auditor pulls chronyc tracking; the gap is immediate.
Pattern 3 — Monitoring exists, alerting does not. Offset and reach are scraped into Prometheus, but no alert fires when reach drops to 0 or stratum jumps to 16. The control's implementation guidance explicitly requires "monitoring to detect synchronization failure" — passive observation is not monitoring.

3. Mapping 8.17 to NTP infrastructure decisions

Each line of the 27002:2022 implementation guidance translates directly into a concrete NTP architecture decision:

27002:2022 guidance lineNTP architecture decision
"Approved time source"Documented list of upstream servers; at least one authenticated via NTS (RFC 8915) or symmetric key.
"Synchronized across all information-processing systems"Internal stratum 2 servers fed by the approved sources; all clients (Linux, Windows, hypervisors, containers, network gear) point to those internal servers.
"Protect the time-source channel against tampering"NTS for external sources; firewall rules restricting UDP/123 egress to the approved list only.
"Monitor to detect synchronization failure"Prometheus or equivalent scraping offset, jitter and reach; alerts on stratum ≥ 16, reach = 0, false-ticker.
"Defined response when drift exceeds threshold"Documented runbook with thresholds (typically > 500 ms triggers operator intervention; > 5 s triggers incident).

4. Implementation checklist — 8 controls

Apply this checklist on every certification cycle:

#ControlEvidence artefact
1Time-source policy approved by ISMS ownerPolicy document referenced in the SoA.
2At least 4 upstream sources, 2 distinct ASNNTP configuration + whois extract.
3At least one authenticated source (NTS preferred)chrony.conf with nts directive + key-management procedure.
4Internal stratum hierarchy documentedArchitecture diagram, signed.
5Monitoring of offset, jitter, reach on every hostDashboard export (90+ days).
6Alerting on stratum ≥ 16 and false-tickerAlert rule file + past alert history.
7Drift threshold and response runbookIR playbook with thresholds and RACI.
8Change-management trail for NTP configurationTicket history for every ntp.conf / chrony.conf change.

5. Evidence pack for the certification audit

Assemble the following in a dedicated iso-27001/A.8.17/ folder before the audit:

  1. Policy. One-page "Time Source Policy" approved and dated.
  2. Architecture diagram. Upstream sources → internal stratum 2 → clients.
  3. Running configuration. Sanitized chrony.conf or ntp.conf from every stratum level.
  4. Telemetry. 90 days of offset / jitter / reach per system class.
  5. Alerts. Export of alerting rules and ticket trail of triggered alerts.
  6. Procedures. Key-management procedure for NTS certificates and symmetric keys.
  7. Tests. Output of the Online NTP Validator for each upstream source, dated, capturing stratum, offset and refID.
  8. Review. Signed annual review of the eight-control checklist above.
Reusability. The same artefacts close the time-sync portion of NIS 2 Art. 21, DORA Art. 11 and PCI-DSS Req. 10.6 with no additional work. See section 8.

6. Migration from 27001:2013 A.12.4.4

The 2022 edition restructured the controls from 14 domains into 4 themes. The clock-synchronization control changed name but not substance:

ISO 27001:2013ISO 27001:2022Change
A.12.4.4 Clock synchronization (under "Operations security")A.8.17 Clock synchronization (under "Technological controls")Renumbered; theme changed; substance identical.
Implementation in ISO 27002:2013 §12.4.4Implementation in ISO 27002:2022 §8.17Guidance expanded with explicit monitoring requirement.

Existing evidence packs from a 2013-vintage ISMS map directly. The only meaningful 2022 addition is the more explicit monitoring requirement — if the 2013 evidence pack already includes offset/jitter dashboards, no new artefact is needed.

7. Common 8.17 audit findings (real examples)

Anonymized findings from infrastructure audits we have personally conducted or reviewed (2023–2026):

8. Cross-framework mapping

RequirementISO 27001:2022NIS 2DORAPCI-DSS v4.0
Approved/synchronized time sourceA.8.17Art. 21(2)(c)Art. 11Req. 10.6.1
Authenticated time-source channelA.8.17 (implicit)Art. 21(2)(e)Art. 9(3)Req. 10.6.2
Synchronization monitoringA.8.16Art. 21(2)(g)Art. 10Req. 10.4
Audit-trail retentionA.8.15Art. 23Art. 12Req. 10.7
Time-source supply chainA.5.19, A.5.21Art. 21(2)(d)(e)Art. 28Req. 12.8

See our dedicated pages for each framework: NIS 2 NTP requirements · PCI-DSS Requirement 10.6.

Generate the A.8.17 evidence in 5 minutes

Run the validator against each upstream source on your time-source policy. The report captures stratum, offset, refID and dual-stack reachability — copy-paste ready for the audit folder.

Run the Validator → Full Audit Checklist

Different angle? Use the right tool for your use-case: