Mapping Annex A.8.17 to authenticated NTP infrastructure
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 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.
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:
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.
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). |
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. |
Assemble the following in a dedicated iso-27001/A.8.17/ folder before the audit:
chrony.conf or ntp.conf from every stratum level.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.
Anonymized findings from infrastructure audits we have personally conducted or reviewed (2023–2026):
169.254.169.123 (the AWS metadata time service) with no policy document. Finding: minor non-conformity, opened the policy in 48 h.| 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.
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 ChecklistDifferent angle? Use the right tool for your use-case: