ISO 27001 NTP — Control 8.17
Clock Synchronization Audit Guide
Mapping Annex A.8.17 to authenticated NTP infrastructure
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:
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 guidance cites NTP and PTP as examples; it mandates neither. What it covers:
- Documented requirements for time representation, synchronization and accuracy;
- A standard reference time for all systems, including building management and entry/exit systems;
- A radio or GPS reference clock as the source, synchronized over NTP or PTP, possibly with two external sources;
- In its other information: monitoring the clock of each cloud service and recording the difference.
Beyond the text, we recommend:
- An organization-wide time-source policy;
- Explicit coverage of network devices, hypervisors, virtual machines, containers and managed services;
- Protection of the time-source channel against tampering;
- Alerting that detects synchronization failure;
- A defined response when a system clock drifts beyond an acceptable threshold.
The phrase "approved time sources" is the load-bearing one. Given documented attacks on unauthenticated NTP, in our experience some auditors read approved as implying authenticated; the standard does not require it.
2. Why 8.17 is often under-evidenced in audits
What fails on 8.17 is rarely the NTP daemon; it is the evidence. A finding on it is often treated as minor — which understates the operational risks of NTP desynchronization. Three cases come up most often:
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.
3. Mapping 8.17 to NTP infrastructure decisions
Each point — from the control, the 27002:2022 guidance or our own recommendations — translates into a concrete NTP architecture decision:
| Point and origin | NTP architecture decision |
|---|---|
| "Approved time sources" (control text) | Documented list of upstream servers; at least one authenticated via NTS (RFC 8915) or symmetric key. |
| Standard reference time for all systems (guidance) | Internal stratum 2 servers fed by the approved sources; all clients (Linux, Windows, hypervisors, containers, network gear) point to those internal servers. |
| Channel protected against tampering (our recommendation) | NTS for external sources; firewall rules restricting UDP/123 egress to the approved list only. |
| Monitoring of clock differences (guidance); alerting on failure (our recommendation) | Prometheus or equivalent scraping offset, jitter and reach; alerts on stratum ≥ 16, reach = 0, false-ticker. |
| Defined response beyond a drift threshold (our recommendation) | 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.conforntp.conffrom every stratum level. - Telemetry. 90 days of offset / jitter / reach per system class. If that history comes from the servers being audited, the auditor has to take it on trust; the monthly sealed NTP compliance report (Time Evidence) from RDEM Systems measures it from outside and seals it when issued.
- 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 the NTP and NTS verdicts.
- Review. Signed annual review of the eight-control checklist above.
6. What changes for NTP: ISO 27001:2013 (A.12.4.4) → 2022 (A.8.17)
The 2022 edition restructured the controls from 14 domains into 4 themes. The clock-synchronization control kept its title; its text changed. The transition period ended on 31 October 2025 (IAF MD 26): certificates issued against ISO 27001:2013 are no longer valid, but auditors and CISOs still quote A.12.4.4.
| 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. The title is kept; the text moves from 'a single reference time source' to 'approved time sources' (plural). |
| Implementation in ISO 27002:2013 §12.4.4 | Implementation in ISO 27002:2022 §8.17 | Guidance expanded: PTP, two external sources, a note on monitoring clocks across cloud services. |
Existing evidence packs from a 2013-vintage ISMS map directly. The 2022 guidance expands on PTP, two external sources and a note on monitoring clocks across cloud services — if the 2013 evidence pack already covers the approved sources and 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.1 |
|---|---|---|---|---|
| Approved/synchronized time source | A.8.17 | Art. 21(2)(b) | Delegated Reg. 2024/1774 Art. 12(2)(f) | Req. 10.6.1 |
| Authenticated time-source channel (RDEM interpretation — no text requires it) | Not required | Art. 21(2)(h) | Art. 9(3) | Req. 10.6.3 (protection of time settings; does not require channel authentication) |
| Synchronization monitoring | A.8.16 | Art. 21(2)(b) | Art. 10 | No dedicated requirement |
| Audit-trail retention | A.8.15 | Art. 21(2)(b); 2024/2690 Annex 3.2.5 | 2024/1774 Art. 12(2)(a) | Req. 10.5.1 (10.7 in v3.2.1) |
| Time-source supply chain | A.5.19, A.5.21 | Art. 21(2)(d) | Art. 28 | Req. 12.8 |
See our dedicated pages for each framework: NIS 2 NTP requirements · PCI-DSS Requirement 10.6. Financial-sector firms face a stricter, metrology-grade bar — see MiFID II RTS 25 clock synchronization.
Where the A.8.17 evidence is kept as a managed deliverable, RDEM Systems produces the documented traceability chain to UTC and the periodic review — the UTC time traceability audit.
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