What does ISO/IEC 27001:2022 control 8.17 require for NTP?

Control 8.17 (formerly A.12.4.4 in ISO 27001:2013) is titled 'Clock synchronization'. It requires that the clocks of information-processing systems used by the organization be synchronized to approved time sources. ISO/IEC 27002:2022 expands the implementation guidance: select an authoritative source, document the synchronization hierarchy, monitor drift, and protect the time-source channel from tampering. In practice this means authenticated NTP (NTS), redundant upstreams and offset monitoring.

Is the 8.17 control mandatory for ISO 27001 certification?

Annex A controls are not strictly mandatory — the organization may declare a control as not applicable in its Statement of Applicability (SoA). However, excluding 8.17 is almost never defensible: audit-trail integrity, incident-response correlation, MFA token validity and certificate validation all depend on synchronized clocks. Most certified organizations apply 8.17; the auditor will challenge any SoA that excludes it.

What evidence does an ISO 27001 auditor expect for 8.17?

Auditors expect six artefacts: (1) a documented time-source policy stating the approved sources and stratum hierarchy, (2) NTP / chrony configuration files showing those sources, (3) at least 90 days of offset and reach metrics demonstrating actual synchronization, (4) alerting rules for stratum 16 and false-ticker conditions, (5) a change-management record for the NTP configuration, (6) an incident-response playbook for time-source failure. Our downloadable checklist enumerates all six.

How does 8.17 relate to the old 27001:2013 A.12.4.4 control?

ISO/IEC 27002:2022 restructured the controls from 14 domains into 4 themes. The former A.12.4.4 (Clock synchronization) under 'Operations security' is now 8.17 under 'Technological controls'. The substance is identical: a single approved time source per organization, with documented synchronization across all information-processing systems. Organizations with a 2013-vintage ISMS can re-map their evidence directly without producing new artefacts.

Does ISO 27001 require NTS or just NTP?

ISO 27001 does not name a specific protocol. It requires that the time-source channel be protected against tampering (8.17 implementation guidance). In 2026, NTS (Network Time Security, RFC 8915) is the only standardized way to authenticate NTP at the packet level. An auditor reading 8.17 alongside the threat-modeling control (8.8) will treat unauthenticated NTP from a public pool as a control gap — especially for organizations that already process sensitive data.

ISO 27001 NTP | Control 8.17 Clock Synchronization Audit Guide

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:

A documented, organization-wide reference time-source policy;
Synchronization across all information-processing systems — including network devices, hypervisors, virtual machines, containers, and managed services;
Protection of the time-source channel against tampering;
Monitoring to detect synchronization failure;
A defined response when a system clock drifts beyond an acceptable threshold.

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 line	NTP 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:

#	Control	Evidence artefact
1	Time-source policy approved by ISMS owner	Policy document referenced in the SoA.
2	At least 4 upstream sources, 2 distinct ASN	NTP configuration + whois extract.
3	At least one authenticated source (NTS preferred)	chrony.conf with `nts` directive + key-management procedure.
4	Internal stratum hierarchy documented	Architecture diagram, signed.
5	Monitoring of offset, jitter, reach on every host	Dashboard export (90+ days).
6	Alerting on stratum ≥ 16 and false-ticker	Alert rule file + past alert history.
7	Drift threshold and response runbook	IR playbook with thresholds and RACI.
8	Change-management trail for NTP configuration	Ticket 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:

Policy. One-page "Time Source Policy" approved and dated.
Architecture diagram. Upstream sources → internal stratum 2 → clients.
Running configuration. Sanitized chrony.conf or ntp.conf from every stratum level.
Telemetry. 90 days of offset / jitter / reach per system class.
Alerts. Export of alerting rules and ticket trail of triggered alerts.
Procedures. Key-management procedure for NTS certificates and symmetric keys.
Tests. Output of the Online NTP Validator for each upstream source, dated, capturing stratum, offset and refID.
Review. Signed annual review of the eight-control checklist above.

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:2013	ISO 27001:2022	Change
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.4	Implementation in ISO 27002:2022 §8.17	Guidance 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):

SaaS in cloud, no policy. 6 VMs in AWS pointing to 169.254.169.123 (the AWS metadata time service) with no policy document. Finding: minor non-conformity, opened the policy in 48 h.
Three sources, one ASN. All three "redundant" upstreams resolved to the same operator (AS3320). Finding: supply-chain risk under 8.17 + A.5.19. Remediation: add Cloudflare NTS + Netnod.
Stratum 16 in production. The dashboard showed reach = 0 for 47 days on an internal stratum-2 because its upstream firewall rule was withdrawn during a network refactor. No alert fired. Finding: monitoring gap, the control was "operating but not effective".
Symmetric key in plain-text. NTP authentication keys committed to the configuration repository in clear. Finding: cross-control failure with A.8.24 (key management).

8. Cross-framework mapping

Requirement	ISO 27001:2022	NIS 2	DORA	PCI-DSS v4.0
Approved/synchronized time source	A.8.17	Art. 21(2)(c)	Art. 11	Req. 10.6.1
Authenticated time-source channel	A.8.17 (implicit)	Art. 21(2)(e)	Art. 9(3)	Req. 10.6.2
Synchronization monitoring	A.8.16	Art. 21(2)(g)	Art. 10	Req. 10.4
Audit-trail retention	A.8.15	Art. 23	Art. 12	Req. 10.7
Time-source supply chain	A.5.19, A.5.21	Art. 21(2)(d)(e)	Art. 28	Req. 12.8

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

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

Measure jitter, offset, latency → ntp-tester.eu
Diagnose firewall / port 123 / daemon → check-ntp.net
Enterprise reference architecture → ntp.rdem-systems.com