Auditing ISO 27001 Annex A 8.17 Clock Synchronisation is the technical verification of chronological alignment across all information processing systems. The Primary Implementation Requirement is the enforcement of a single reference time source, providing the Business Benefit of ensuring accurate log correlation for forensic investigations and incident response.
ISO 27001 Annex A 8.17 Clock Synchronisation Audit Checklist
This technical verification tool is designed for lead auditors to establish the chronological integrity of event logs and forensic data. Use this checklist to validate compliance with ISO 27001 Annex A 8.17.
1. Master Reference Time Source Accuracy Verified
Verification Criteria: A reliable, external master time source (e.g. Stratum 0 or 1 source via GPS or atomic clock) is defined as the authoritative reference for the entire network.
Required Evidence: NTP (Network Time Protocol) configuration files or PTP (Precision Time Protocol) settings identifying the external upstream time servers.
Pass/Fail Test: If the organisation uses an internal, non-synchronised hardware clock as the master time source for the domain, mark as Non-Compliant.
2. Hierarchical Time Distribution Integrity Confirmed
Verification Criteria: A hierarchical distribution of time exists where internal “Stratum 2” servers synchronise with the master source and subsequently provide time to all clients.
Required Evidence: Network architecture diagram showing the flow of NTP traffic from master servers to domain controllers and end-user endpoints.
Pass/Fail Test: If endpoints are found synchronising directly with various disparate internet time sources rather than the internal master source, mark as Non-Compliant.
3. Cross-Platform Synchronisation Uniformity Validated
Verification Criteria: Clock synchronisation is enforced across all operating systems (Windows, Linux, macOS) and hardware appliances (Firewalls, Switches, IoT).
Required Evidence: Sampled configuration outputs (e.g., ntpq -p, w32tm /query /status, or show ntp status) from at least five different asset classes.
Pass/Fail Test: If network appliances (e.g. firewalls) are found with a time drift exceeding 5 seconds relative to the domain controller, mark as Non-Compliant.
4. Automated Synchronisation Enforcement Confirmed
Verification Criteria: Technical controls (e.g. Group Policy Objects or Configuration Management scripts) are utilised to prevent users or local admins from manually altering system time.
Required Evidence: GPO settings or MDM profiles showing the “Change the system time” user right is restricted to authorised service accounts only.
Pass/Fail Test: If a standard user can manually change the system clock on their corporate workstation, mark as Non-Compliant.
5. Time Drift Monitoring and Alerting Verified
Verification Criteria: Active monitoring is in place to detect and alert on significant time drift or synchronisation failure between critical infrastructure nodes.
Required Evidence: SIEM or monitoring dashboard (e.g. Zabbix, SolarWinds) showing active alerts for “NTP Synchronisation Lost” or “Time Drift Out of Bounds.”
Pass/Fail Test: If a server stops synchronising and drifts by minutes without triggering an automated alert to the IT operations team, mark as Non-Compliant.
6. Cloud-Native Time Source Alignment Validated
Verification Criteria: For cloud-hosted assets, instances are configured to use the cloud provider’s internal, high-precision time service (e.g. Amazon Time Sync Service).
Required Evidence: Cloud metadata or instance configuration logs showing synchronisation with the provider’s internal 169.254.169.123 (or equivalent) IP.
Pass/Fail Test: If cloud instances are defaulting to unverified public pools (e.g. pool.ntp.org) rather than the provider’s precision service, mark as Non-Compliant.
7. Log Timestamp Precision Consistency Confirmed
Verification Criteria: Log timestamps across all systems are configured to a consistent precision level (e.g. milliseconds) and a unified time zone (typically UTC).
Required Evidence: Raw log samples from the SIEM or central log repository demonstrating uniform timestamp formatting and UTC alignment.
Pass/Fail Test: If logs in the central repository show multiple time zones (e.g. some in GMT, some in PST) without automated normalization, mark as Non-Compliant.
8. NTP Traffic Security and Authentication Verified
Verification Criteria: Where supported, NTP authentication or secure tunnels are used to prevent “Time Shifting” attacks or unauthorised NTP spoofing.
Required Evidence: NTP configuration showing MD5/SHA keys or firewall rules restricting NTP (UDP 123) traffic to authorised sources only.
Pass/Fail Test: If the internal NTP server accepts time updates from any unauthenticated external source on the internet, mark as Non-Compliant.
9. Critical Utility Time Synchronisation Validated
Verification Criteria: Supporting utilities (CCTV, Physical Access Control Systems, UPS) are synchronised to the same master source to enable forensic correlation.
Required Evidence: Configuration screenshots from the Physical Security system (e.g. Gallagher, Lenel) showing NTP client settings.
Pass/Fail Test: If a physical door breach at 10:00:00 appears in the digital log at 10:05:00 due to clock drift in the access control panel, mark as Non-Compliant.
10. Periodic Synchronisation Audit Records Present
Verification Criteria: The organisation performs periodic checks of the synchronisation status across the estate as part of its technical compliance monitoring.
Required Evidence: Monthly health check reports or automated compliance scan results showing NTP status across all inventoried assets.
Pass/Fail Test: If there is no record of a technical time-sync audit being performed in the last 12 months, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Authoritative Source | Tool records “Yes” because a policy says “Use UTC.” | Verify the IP. Auditor must see the upstream NTP server address (e.g. uk.pool.ntp.org) in the actual config. |
| Drift Control | GRC dashboard reports “NTP: Enabled” via a static API check. | Verify Offset. A tool might see the service is “Running” even if the offset is 10 minutes. Check ntpq -p jitter/offset values. |
| Log Correlation | Platform assumes cloud logs are automatically synced. | Check Normalization. If SaaS app logs are in UTC but local server logs are in BST, the correlation is broken for an auditor. |
| Security Resilience | Tool identifies “Firewall Active” as evidence of protection. | Check the ACL. Can any rogue device on the network act as an NTP server? Verify internal NTP server restrictions. |
| Scope Coverage | Tool checks Windows servers only via GPO integration. | Check the Switches. Physical network hardware is often ignored by GRC tools but is critical for forensic packet tracing. |
| User Restrictions | Tool identifies a “Policy” prohibiting time changes. | Verify Privileges. GRC tools don’t check if the ‘Local Admin’ group is over-populated, allowing manual time overrides. |
| Physical Security | SaaS tool ignores the CCTV system entirely. | Verify Integrity. If the CCTV clock isn’t synced to the IT master clock, your physical evidence is inadmissible. |
About the author
