A.8.17 Clock synchronization: requirements and evidence

What A.8.17 clock synchronization asks for and why auditors check it

When an auditor or customer asks how timestamps are kept consistent, the answer is that every information processing system in scope must have its clock synchronized to approved time sources. A.8.17 Clock synchronization asks the organization to define which time sources are approved, to make sure the clocks of its systems follow them, and to be able to show that this is true across the estate. The control is short, but auditors check it because logs, alerts and incident timelines are only useful when the events they describe can be placed in the same order. If one server runs two minutes behind another, a login on one host and a file transfer on the next can appear in the wrong sequence, and an investigator may draw the wrong conclusion about how an intrusion unfolded.

The difficulty is rarely the configuration itself. It is proving coverage. A mid-sized estate can include physical servers, virtual machines, cloud instances that are created and destroyed automatically, containers that inherit the host clock, network appliances, and legacy devices whose time settings were never reviewed. Drift tends to go unnoticed because a system with a slow clock still runs normally and still writes plausible log lines. The organization should confirm which system types are in scope, which time source each one uses, how often offset is measured, and who receives an alert when a clock falls outside tolerance. Those answers, backed by configuration records and a sample of drift reports, are the evidence an assessor will ask for.

A.8.17 is closely tied to A.8.15 Logging and A.8.16 Monitoring activities. Logs and monitoring rules assume that timestamps are trustworthy, so weak time synchronization undermines the evidence those controls are meant to produce. When preparing for an assessment, review the logging scope and the monitoring rules together with time sources, and confirm that the time zone and timestamp format are consistent across log platforms. A clock problem found during a review of A.8.15 or A.8.16 is often an A.8.17 finding, so treating the three as one body of evidence avoids gaps between them.

Which systems, sources and teams fall inside A.8.17 scope

A.8.17 applies to every information processing system the organization uses, so scope starts with an inventory of clock-dependent systems and the people who own them. The cards below cover the decisions that most often change the amount of work: which device classes count, where time comes from, and how to handle systems the organization does not run itself.

Servers and virtual machines

Physical servers and virtual machines are the core of A.8.17 scope, since their logs, authentication records and transaction timestamps are what investigators line up later. Check that every host, including build servers and jump hosts, has a configured time client and that the configuration is recorded in the asset inventory. Hosts that were built from an old image often carry a stale time setting that nobody reviewed.

Hypervisors and container hosts

Hypervisors and container orchestrators sit between hardware and workloads, so drift at this layer affects every guest or pod above it. Confirm how guests take their time (from the host, from the network or from a hardware clock) and whether containers inherit the host clock. Document which layer is authoritative so that a guest reboot or live migration does not introduce a second, conflicting time source.

Network devices and firewalls

Routers, switches, firewalls and load balancers write security events with their own clocks, and these are often the first records examined in an intrusion. Many appliances are managed by a vendor console and ship with a default time server that may not match the organization's approved sources. Confirm each device's time setting during commissioning and after firmware upgrades, since upgrades can reset configuration.

Cloud instances and managed services

Cloud instances usually receive time from the provider's own time service, which the organization does not configure directly. The organization still owns the decision to accept that source as approved, and it should record the provider's time documentation as the evidence. Managed databases, queues and SaaS platforms may stamp events with their own clock, so ask each provider which time source it uses and whether event timestamps can be exported in a known time zone.

Endpoints, OT and industrial devices

Laptops, phones and industrial controllers have very different time behavior. Laptops often sleep or roam between networks, while programmable logic controllers and other operational technology may run isolated networks with no route to a public source. Decide whether each class syncs to an internal source, syncs only when connected, or relies on a locally maintained reference, and record the exception where synchronization is not possible.

SIEM, log collectors and time owners

The SIEM and log collectors are where timestamps from every source meet, so their clocks and their parsing of time zones determine whether correlation works at all. Name one owner for the internal time infrastructure, usually the infrastructure or platform team, and make the security operations team responsible for checking that log sources arrive with consistent time. Ask who approves a new time source and who reviews drift reports.

How an assessor tests clock synchronization

This table sets out the steps an assessor typically takes to test A.8.17 Clock synchronization, the evidence each step produces and the findings that most often appear. Read it as a test plan you can rehearse internally before the audit, since each row maps a question the assessor will ask to the records you should already have.

Assessor step	What the assessor checks	Common findings
Review the time source policy	Whether the organization has defined approved time sources (internal stratum servers, GNSS receivers or named external pools), who owns them and how the policy is reviewed	No written policy, or a policy that names sources nobody actually uses
Check the approved source list	Whether the list matches the sources configured on real systems, including which internal servers feed which networks	Public time servers configured on production hosts that are absent from the approved list
Sample systems across the estate	A selection spanning servers, cloud instances, network devices, endpoints and security tools, checking sync status and measured offset against the policy tolerance	Systems missing from the inventory, appliances with no clock configuration, virtual machines that drift after snapshots
Review drift alerting	Whether offset or sync loss is monitored centrally, what thresholds trigger an alert, and who responds	No drift monitoring at all, alerts sent to an unmonitored mailbox, thresholds never reviewed
Review exception handling	How out-of-tolerance systems are logged, investigated, corrected and approved if an exception is accepted for a period	Exceptions with no owner, no expiry date or no record of the fix
Trace a sample incident	Following one security event across two or more systems to confirm that log timestamps line up after correction for time zone and offset	Event sequences that cannot be reconstructed, or logs in mixed time zones with no reference
Check for stopped time daemons	Whether the synchronization service is running, enabled at boot and configured to restart if it fails	Time daemons stopped or disabled after patching, or left on an unsupported version
Cross-reference related controls	Whether timestamps are consistent with the logging (A.8.15) and monitoring (A.8.16) evidence the assessor is also reviewing	Logging systems each using a different clock source, so correlation fails across the stack

How to implement clock synchronization step by step

This sequence moves a team from an unknown set of timestamp sources to a documented, monitored time architecture, so that logs from every system can be ordered and correlated when an assessor or incident responder asks for them.

Inventory every system that generates timestamps
List all information processing systems that create or record time-bearing data: servers, virtual machines, containers, network devices, firewalls, endpoints, application servers, databases, log collectors, SIEM components and cloud services that you operate or configure. For each one, record the owner, the operating system or firmware, the current time configuration and whether the system writes logs or audit records that will be correlated with others. Shared responsibility matters here: for managed cloud and SaaS services, note what the provider documents about its time source and what you can only request. The output is a timestamp inventory that the control owner signs off, and it becomes the scope boundary for every later step.
Define the approved time source standard
Write a short standard that names the approved time sources and the hierarchy between them. A common pattern is a small set of internal time servers that synchronize to external references, such as public NTP pools, a national metrology service or a GPS-fed reference clock, with every other system pointing only at the internal servers. Record which upstream sources are trusted, how many are configured for redundancy, which protocol is used, and who may change the list. Have the information security owner approve the standard and the IT operations owner accept the operating commitments. The output is an approved time source document that the Statement of Applicability can cite for A.8.17.
Build the internal time servers
Deploy at least the internal reference servers described in the standard on hardened hosts with restricted administrative access. chrony, which is licensed under GPL-2.0-only, can synchronize the system clock to NTP servers or to reference clocks such as GPS receivers and can serve NTPv4 to other computers on your network. Configure the upstream sources, the allowed client networks, access controls on the NTP port and logging of synchronization events. Test that the servers select a source and report stable offsets before any client is pointed at them. The output is a tested server build with a recorded configuration file and a log of initial synchronization.
Configure clients and document a baseline
Point each inventoried system at the approved internal servers and remove conflicting time settings, such as hard-coded public servers or unmanaged hypervisor clocks that override guest settings. Apply the configuration through your standard build or configuration management process so that new systems inherit it. Write a configuration baseline for each operating system family and virtualization platform, covering the time daemon, the server list, the polling interval and any access restrictions. The output is a set of versioned baselines and a list of systems confirmed to use them, with exceptions recorded for any device that cannot be configured.
Verify offsets across the estate
Measure how far each system's clock differs from the approved reference and compare the results against the tolerance you set in the standard. Use the time daemon's own status commands, such as chrony tracking and source reports, on Linux hosts, and the equivalent status views on other platforms, and sample representative devices from each baseline. Record the measured offsets, the date of measurement and the person who ran the check. Any system outside tolerance goes back to step four or into the exceptions register. The output is a verification record that shows the estate was tested, not just configured, and it gives an assessor concrete evidence to sample.
Add drift monitoring and alerting
Feed time status into your monitoring platform so that a server losing its upstream source, a client drifting beyond tolerance or a time daemon stopping raises an alert to a named responder. Chrony and most network devices can export status through SNMP, syslog or metrics endpoints that open-source collectors can scrape. Define the alert thresholds in the standard, route them to the on-call process and test one alert end to end by simulating a lost source in a non-production environment. The output is an alert rule set, a notification route and a test record that show the monitoring works, which supports the logging and monitoring controls that depend on consistent timestamps.
Document exceptions and approve the register
Some systems will not accept the approved configuration, such as certain appliances, legacy platforms or managed services that set their own time source. For each one, record the system, the reason it cannot comply, the time source it uses, the compensating measure (for example, monitoring its offset or restricting it to logging-only use) and the risk owner who accepted the exception. Review the register with the risk owner so that accepted risk is visible and tied to the risk treatment process. The output is an exceptions register that stays current as the inventory changes.
Review the time architecture on a schedule
Set a recurring review, at an interval the organization defines and documents, that repeats the inventory check, reviews upstream source health, samples offsets, reviews drift alerts and closes out exceptions. Update the inventory and baselines after major infrastructure changes, such as new cloud regions, hardware refreshes or migrations, and feed findings into the internal audit and management review process. The output is dated review records and updated documents that show the control operates over time. An assessor will look for evidence from this cycle, not only the first deployment.

How chrony and NTP sources support the control

The control is met by pointing every system at approved time sources and proving that the clocks stay in step, and chrony is a widely used open-source daemon for doing that. chrony (GPL-2.0-only) disciplines the system clock against NTP servers or reference clocks such as GPS receivers, and it can also act as an NTPv4 server so that other hosts on the network draw their time from a single, controlled point. In a self-hosted estate, the usual pattern is a small set of internal chrony servers that sync to approved upstream sources, with every other host, container host and network device pointed at those internal servers rather than at arbitrary public pools.

The first decision is the accuracy the organization actually needs. The typical figures for chrony are milliseconds over the Internet and tens of microseconds on a LAN. Those figures are a starting point, not a requirement. Log correlation for incident investigation may tolerate millisecond offsets, while transaction ordering, distributed tracing or intrusion detection across hosts may not. Document the tolerance you choose, state which time sources are approved and why, and make that statement the basis for the drift threshold you monitor.

Confirm the details in your own environment before you rely on them: the configuration keys and their syntax for your chrony version, which upstream servers or hardware references your policy permits, whether your distribution packages chrony under a different service name or default configuration file, and whether the NTP port is reachable only from the networks you intend. Keep the resulting configuration under version control, and capture chronyc tracking and chronyc sources output on a schedule so that an assessor can see offsets, stratum and source selection over time. The chrony project home page at chrony-project.org is the natural starting point for the current documentation.

Evidence that passes A.8.17 and how to keep it current

An assessor testing A.8.17 wants to see which time sources were approved, that every in-scope system actually follows them, and that deviations were caught and handled. The cards below cover the artifacts that prove each step and the routine checks that keep them current between audits.

Approved time source register

A controlled list of the authoritative time sources the organization has approved, such as named NTP servers, pool members, GPS or radio reference clocks, and any internal stratum servers that relay them. For each entry, record the owner, the reason it was approved, the network path, and the review date. Assessors usually ask who can add a source and how a rogue source would be detected, so the register should also name the approver. Confirm with your own environment which sources are actually in use before the audit.

Configuration baselines from change management

Captured configuration files for the time daemon on each system class, such as the chrony configuration on servers, endpoints and network devices. Store them in version control so that every change has an author, a reason and a change record. Assessors compare the running state against these baselines, so drift between the baseline and a live host is itself a finding to explain. Tie each baseline to the configuration management process so that changes follow the same approval path as other system changes.

Sync status and offset reports over time

Time series of synchronization state and measured offset from each approved source, exported from the monitoring platform on a fixed schedule. A single snapshot shows little, but a trend over several months shows whether the clocks stayed within the tolerance the organization set. Record which tool produced each report, the host list it covered, and any gaps in collection. Chrony's status output can be scripted into this export, but confirm the retention settings for the monitoring store so the history is not lost before the assessment window.

Drift alert records and tickets

Records showing that an alert fired when a host lost synchronization or drifted beyond the defined threshold, and that someone investigated and closed it. Each alert should link to a ticket with the timestamp, affected host, root cause and corrective action. Assessors often sample a few alerts and trace them to closure, so missing ticket linkage is a common gap. Test the alert path periodically with a controlled fault on a non-production host and keep that test record as evidence.

Exception register for unsynchronized systems

A documented list of any system that cannot reach an approved source, such as an air-gapped segment, an isolated industrial controller, or a legacy appliance with a fixed clock. Each exception needs an owner, a compensating measure such as a local reference clock or manual verification, a risk acceptance, and a review date. Keep the register short and specific, because a broad exception that covers many hosts will draw more scrutiny than a narrow one with clear compensating controls.

Sample log entries showing consistent time

Extracts from central logs that show the same event recorded across several systems with timestamps that agree within the tolerance set in the policy. Choose events that cross hosts, such as an authentication on a server followed by a firewall entry, because they demonstrate correlation in practice. Store the samples with the host, time zone setting and query used to retrieve them. Refresh them each quarter, since a sample from years ago does not show current behavior.

Scheduled exports and periodic sampling

A routine that pulls the register, baselines, offset history, alert tickets and exception list into a dated evidence folder without waiting for the audit. Assign an owner, set a calendar cadence, and sample a set of hosts from each system class to check that the reported state matches reality. Record each sampling run with the result and any corrective action. This routine is what keeps evidence current between certification audits, and it is where an implementation partner can build and document the export jobs.

What meeting A.8.17 costs in money and effort

This table breaks the cost of meeting A.8.17 into its components, showing who is paid, whether each cost is one-time or recurring, what moves it up or down, and what to request in a quote. Read it as a checklist for scoping, since no price is given here and the largest variables are estate size and device mix. The main takeaway is that the control itself is usually modest next to the wider ISMS, and that most of the spend lies in configuring and evidencing many heterogeneous systems.

Cost component	Who is paid and for what	One-time or recurring, and what drives it	What to ask for in a quote
Time source design	Internal architects or an implementation partner decide which approved sources to use and how they are arranged	One-time. Grows with the number of network zones, cloud regions and any sites that need local or GPS-based references	A written time source hierarchy, the named approved sources, and who approves changes to them
Configuration across systems	Engineers or partner staff set up the sync daemon on servers, endpoints, network devices and containers	One-time, engineering-heavy. Rises with heterogeneity, legacy operating systems and devices that cannot run a standard daemon	A per-system-type inventory, the configuration baseline, and how exceptions for devices without a daemon are handled
Monitoring integration	Platform or security engineers add drift and sync-status alerts to existing monitoring	One-time setup, then recurring upkeep as systems are added or retired. Driven by the number of alert rules and the tooling already in place	Alert thresholds for drift, who receives alerts, and the expected handling of an out-of-sync system
Evidence collection	Internal staff, or automation built by a partner, export sync status and configuration records for the auditor	Recurring. Grows with estate size and with how often sampling is expected; automated exports lower the effort per cycle	Which records are produced, how often, where they are stored, and how they map to the Statement of Applicability entry
External review or testing	An independent tester or consultant checks time configuration or verifies drift on sample systems (optional)	Optional and occasional. Driven by scope, the number of sites and whether the review is pre-audit or part of wider technical testing	Sample size, the systems covered, and whether results are delivered as a written report with remediation notes
Auditor sampling time	The certification body's auditors sample systems and review evidence during each audit	Recurring per audit cycle. Driven by the number of sampled systems and the clarity of evidence; the certification body sets its own fees	Ask the certification body how it samples and what evidence it expects, and confirm the audit fee basis in writing
Sync software licensing	No licence fee for the daemon itself when an open-source tool is used, such as chrony (GPL-2.0-only)	Recurring support only if a vendor support contract is chosen; otherwise staff time for upgrades	Confirm the licence terms with the vendor or your legal team and the support model for upgrades

Who does what for clock synchronization

Your organization owns the control. That means deciding which time sources are approved, who is accountable for the clock configuration on each class of system, and how exceptions are recorded and closed. A.8.17 asks that the clocks of information processing systems are synchronized to approved time sources, so the approval decision is a management decision, not a technical default that an engineer picks on a Friday afternoon. Your team also signs off on the Statement of Applicability entry for the control and answers for it when the auditor asks.

Approved time sources: Name the internal and external sources, record why each was chosen, and state which systems must use which source.
Ownership: Assign a named role for clock configuration on servers, network devices, cloud accounts, endpoints and applications.
Exceptions: Decide which systems cannot follow the standard setup, such as isolated or legacy equipment, and document the compensating checks.
Review: Schedule periodic checks of the approved source list and the drift thresholds that trigger action.
Operations: Keep the people who run systems responsible for acting on drift alerts and recording the outcome.

Before any audit, confirm that someone internal can explain the approved sources, the exception list and the last review without referring the auditor to a consultant.

Common gaps in clock synchronization and how to close them

Clock synchronization usually fails quietly. Clocks drift, sources change, and new systems appear without anyone configuring time, so log timestamps stop lining up when an incident needs them most. The gaps below are the ones assessors and engineers most often find, each with a closing action that produces evidence an auditor can test.

Ephemeral instances without time configuration

Containers, autoscaling groups and short-lived virtual machines often inherit a base image that never points at the approved time sources, or they rely on the host clock without documenting that choice. Check the base image, the container runtime and the node pool templates for the time service configuration. Close the gap by baking the approved time source settings into the golden image and infrastructure as code module, then confirm a newly launched instance reports synchronized status before it receives production traffic.

Public time sources used without approval

Teams often point systems at public pool servers because the defaults work, yet the control asks for approved time sources. Public pools may be fine for some environments, but the choice should be a documented decision, not an accident of the operating system default. Review the configured sources on each system group, compare them with the approved list, and record the owner and rationale for any exception. Close the gap by approving named internal or external sources in the policy and removing defaults that are not on the list.

No alerting on clock drift

A clock can drift for weeks before anyone notices, and the first sign is often a log correlation that fails during an investigation. Monitoring should treat a loss of synchronization or an offset above the threshold the organization sets as an event. Check whether your monitoring platform collects time service status, such as the offset and sync state reported by the client daemon. Close the gap by defining the offset threshold in writing, routing alerts to an owner, and keeping the alert history as evidence that the check operates.

Devices outside the asset inventory

Network appliances, IoT sensors, building systems and legacy servers are often missing from the asset inventory, which means nobody tracks whether their clocks are synchronized. An assessor who samples devices from the network may find systems that no one can account for. Compare the discovered network population with the inventory and the time-sync configuration report. Close the gap by adding time settings as a required field for each inventory record and by checking devices that cannot run an agent through their own management interface.

Timezone and NTP misconfiguration in logs

Systems can have correct time but inconsistent timezones, daylight saving settings or log formats, so events from different sources appear out of order. Such errors often surface only when someone correlates logs across a hybrid environment. Check the system timezone, the log shipper timestamp parsing and the format of time fields in each source. Close the gap by standardizing on UTC for storage and display, then testing a known event end to end to confirm it appears at the correct time in the central log platform.

No evidence of periodic review

Many organizations configure time synchronization once and never review it again, so the control cannot show it still operates. An assessor will ask for records that show the configuration was checked, and for how exceptions were handled. Schedule a recurring review of approved sources, sync status across the population and open exceptions, and keep the output with its date and reviewer. Close the gap by linking the review to the change management and asset inventory processes so that new systems and source changes trigger a record automatically.

Questions buyers ask about A.8.17 cost, effort and outside help

How much effort does A.8.17 clock synchronization take to meet?

For most organizations the control itself is small, but the effort depends on how many systems need to be covered and how well they are already documented. Synchronizing a few servers to a documented time source is a short configuration task. The larger effort is building an inventory of every information processing system, including cloud instances, network devices, firewalls, hypervisors, containers and endpoints, and showing that each one points to an approved source. Effort rises with heterogeneity, with the number of network segments that cannot reach public time servers, and with the number of teams who own systems. Ask any partner to base its estimate on a written inventory of systems, not on a headcount guess.

Can a small team handle A.8.17 without outside help?

Often yes, provided one person owns the time configuration and the team can prove it works. A small team needs to pick its approved time sources, configure a time daemon such as chrony on each system, set alerts for drift and document the decision in its information security policy or a supporting procedure. The skills needed are ordinary Linux or Windows administration and network knowledge, plus the discipline to review the configuration after changes. Outside help is most useful when the environment is air-gapped, when there are several legacy platforms, or when the team has no time to collect evidence before an audit.

What does an implementation partner need from our team?

A partner needs access and decisions, not just documents. In practice that means read access to the systems in scope, the network paths to any internal time servers, the name of the person who approves time sources, and the change process that will govern future configuration. The partner also needs to know which systems are regulated, which are owned by suppliers, and where logs are stored, because those choices affect how the evidence is collected. The organization keeps ownership of the control and of its risk decisions; the partner prepares the configuration, the checks and the records.

What does an assessor sample when checking A.8.17?

An assessor usually asks which time sources the organization has approved, then selects a sample of systems and checks that each one synchronizes to an approved source. Typical evidence includes the approved source list, configuration files or policy settings from representative hosts, output showing the synchronization status, and records of how drift or failures were handled. The assessor will also test whether the sample is complete by comparing it with the asset inventory. Expect questions about systems that were missed, about devices that cannot reach the internet and about how logs from different systems are aligned during an investigation.

Do cloud providers' time services satisfy A.8.17 on their own?

A cloud provider's time service can be an approved time source, but it does not settle the control by itself. The organization still has to decide that the provider's source is acceptable, configure its own instances or services to use it, and check that they stay synchronized. Managed services, serverless platforms and third-party SaaS may not expose their clock settings at all, so the organization should record what it can verify and what it must accept from the supplier. Ask the provider for documentation of its time source and confirm the setting on your own systems.

How do we check that a partner's clock synchronization work is sound?

Check the work against your own systems rather than accepting a summary. Ask for the approved source list, the configuration applied to each system class, the drift monitoring rules and a sample of current synchronization status output. Then pick several systems at random and verify them yourself, including one that was hard to configure. Confirm that changes to time settings go through change management and that logs record them. Any partner's claims about compliance should be treated as preparation only, because only an independent auditor or certification body can issue a certification.

How DeployOpen prepares clock synchronization evidence

DeployOpen starts by agreeing in writing which systems fall inside the clock synchronization scope: servers, hypervisors, firewalls, load balancers, container hosts, databases, logging pipelines and the SIEM collectors that receive their events. The output of this step is an inventory that lists each system, its operating system, its current time source and the owner who answers for it. That inventory is the basis for the Statement of Applicability entry for A.8.17 that the organization writes and owns. Where the client has already chosen approved time sources, DeployOpen records them. Where it has not, the decision is the client's to make, and it should be documented before any configuration begins, because the assessor will ask who approved the sources and why.

Where the client agrees to self-hosted time, DeployOpen implements an internal NTP hierarchy with chrony, the open-source implementation licensed under GPL-2.0-only. A small set of internal servers syncs to the approved upstream sources, which may be external NTP pools, a GPS receiver or another reference the client has approved, and every other system points at those internal servers. The configuration lives in version control as chrony.conf files with the server lines, makestep behavior and access restrictions reviewed like any other change. DeployOpen also sets up drift monitoring using chrony's tracking output, with alerts when offset grows beyond a threshold the client sets, and it tests a failover so the loss of one time source does not stop logging. The client should confirm whether its platform permits this design, and whether any system, such as a managed cloud service, must keep its provider's time source instead.

For the assessor, DeployOpen packages the evidence the client needs to show that the control operates over time, not just on the day of the audit. This includes the approved source list, the version-controlled configuration, a sample of tracking output from each tier, drift alert history and records of corrective action when a system fell out of tolerance. DeployOpen prepares these artifacts, but it does not issue audit reports, attestations or certificates. An independent auditor or certification body performs the assessment and makes the judgment, and the organization remains responsible for the control, its ownership and its ongoing operation. Because logs and monitoring under A.8.15 and A.8.16 depend on consistent timestamps, the clock evidence should be reviewed together with those controls.