Safeguard 8.4 time synchronization: evidence and audit

Safeguard 8.4 time synchronization: what the requirement asks for

If you are the compliance lead or engineer who must show that enterprise clocks agree, the short answer is this: Safeguard 8.4 asks for standardized time synchronization, with at least two synchronized time sources configured across enterprise assets where supported. It sits in Implementation Groups 2 and 3, not IG1, so organizations that only meet IG1 will not be measured against it. Its CIS function is Protect. The requirement looks minor, but almost every log-based investigation depends on it. When an incident spans a firewall, a domain controller, a cloud workload and an endpoint, responders line up events by timestamp. If one host runs five minutes fast, its events appear before the cause that produced them, and the timeline the responders build is wrong without anyone noticing. Clock drift does this quietly, because each system still shows a plausible time.

The same need appears in other frameworks, which is why assessors in several audits ask about it. The CIS Controls Navigator for v8.1 links Safeguard 8.4 to NIST SP 800-53 Rev. 5 AU-8 and AU-12(1), to ISO/IEC 27001:2022 Annex A 8.17, to SOC 2 CC4.1 and CC5.2, and to PCI DSS v4.0 requirements 10.6 through 10.6.3. Confirm the exact mapping text in the Navigator before you cite it in an audit response, since the mappings are CIS's and each framework's own wording governs. For planning, a practical first step is to ask who owns time configuration today. Many organizations find that a domain controller or hypervisor syncs correctly while network appliances, legacy servers and cloud images each use a different default source.

Three conditions usually make this hard. The first is an unknown asset inventory: you cannot show that every enterprise asset syncs to a source if you do not know which assets exist, so the measurement in the Assessment Specification relies on Safeguard 1.1 data. The second is mixed operating systems and devices, where Windows, Linux, network gear and appliances each configure time differently and report it differently. The third is devices that cannot take network time at all, such as some embedded or industrial units. For those, record the exception, the compensating method and the owner, and confirm with the vendor what time sources the device supports. Start by reconciling your asset inventory against a time-source report, and treat every gap as a decision you must document.

Which assets and teams fall under time synchronization scope

Safeguard 8.4 applies to every enterprise asset that produces or stores audit logs, so scope starts with what those assets are and who runs them. The cards below separate the asset classes that change the work and the ownership lines that decide who acts on each one.

Assets that generate or store audit logs

Start with the systems whose logs you rely on for investigation: servers, domain controllers, log collectors and the SIEM itself. These assets set the timestamps that every other log is compared against, so their clocks matter most. Check that each one points to the same approved time sources and that no log pipeline stamps events with a local, unsynchronized clock.

Network devices and appliances

Routers, switches, firewalls, load balancers and VPN concentrators often log events with their own clocks and sometimes ship logs in a format that omits time zone. Confirm each device supports NTP or the vendor's equivalent, and record which devices cannot take network time so they appear as exceptions rather than gaps. Network teams usually own these settings, so agree on the time source list with them early.

Cloud instances and containers

Cloud virtual machines usually inherit a provider time service, but custom images, hardened builds and self-managed Kubernetes nodes may not. Containers share the host clock, so measuring the host is often the practical check for container workloads. Ask the cloud team which images override the default time configuration and whether each one is covered by the measurement.

Endpoints and user workstations

Laptops and desktops are the largest and least stable population, and they often roam between networks that offer different time sources. Confirm the endpoint management tool enforces time settings, and decide how roaming devices reach the approved sources when they are off the corporate network. Endpoint teams should report the share of devices that fail the check, since that figure shows whether the policy holds.

Assets that cannot take network time

Some industrial controllers, embedded appliances, legacy systems and isolated segments cannot reach an NTP server or do not support it. Record each one as a documented exception with its owner, the reason it cannot synchronize, and any compensating step such as manual checks or a local reference clock. Assessors look for this record as evidence that the scope was considered rather than silently skipped.

Asset inventory as the prerequisite

Safeguard 1.1, the enterprise asset inventory, lets you see which assets must be measured and which teams own them. The CIS assessment specification treats it as a prerequisite for measuring Safeguard 8.4. Without a current inventory, the time synchronization metric covers only the assets someone remembered, so reconcile the inventory against log sources before reporting coverage.

How an assessor measures NTP compliance coverage under Safeguard 8.4

This table compares the four measures the CIS Controls Assessment Specification defines for Safeguard 8.4 and combines into the NTP compliance coverage metric. Read each row as a question the assessor asks, the evidence they expect, and where organizations usually fall short. The main takeaway is that the population of assets and the reporting method should be agreed before the assessment starts.

Measure	What the assessor tests	Evidence requested	Common finding
Asset population	Which enterprise assets are in scope, taken from the asset inventory under Safeguard 1.1	Current asset inventory export, with the date it was produced and the filter used to define in-scope assets	Inventory is stale or omits virtual machines, containers, network devices or cloud instances, so coverage is overstated
Configured time sources	Whether each in-scope asset points to at least two synchronized time sources where the platform supports it	Configuration files or management-tool output showing NTP or chrony server lists per asset class, with sample hosts checked by hand	Only one time source is configured, or two entries point to the same upstream server
Synchronization status	Whether each asset is actually synchronized to its sources at the time of testing, not just configured	Sync status output such as offset and source selection captured from a sample of assets, plus monitoring history if available	Virtual machines or hosts drift after resume or migration, and nobody notices because status is never collected
Documented exceptions	Whether assets that cannot use two sources or cannot synchronize have a recorded reason, owner and compensating step	Exception register with asset identifier, justification, approver, review date and any alternate control	Exceptions are undocumented, or exception lists exist but do not match the assets that actually fail
Combined metric	How the four measures roll up into the NTP compliance coverage figure reported for the enterprise	Calculation worksheet showing numerator, denominator and the sample method used	Coverage is reported as a single percentage without a stated method, so it cannot be reproduced

How to implement time synchronization across enterprise assets

This sequence turns Safeguard 8.4 into a repeatable process: it starts from the asset inventory, sets two or more authoritative time sources, configures every supported asset, proves synchronization, records exceptions and keeps the setup under review, so each step leaves evidence an assessor can test.

Confirm the asset population from the inventory
Start from the enterprise asset inventory produced under Safeguard 1.1, which the CIS Controls Assessment Specification lists as a prerequisite for measuring Safeguard 8.4. The owner of the asset inventory, usually IT operations with input from platform engineering, filters it to devices, servers, network equipment, virtual machines and cloud workloads that generate or store logs. Output: a dated list of in-scope assets with the platform and time configuration method for each, which becomes the denominator for every later coverage figure.
Choose and document at least two time sources
Select at least two authoritative time sources, internal or external, and record why each was chosen, including its accuracy, availability and independence from the other source. Many organizations pair an internal NTP tier with an upstream reference, while others use cloud provider or national time services. Output: a time source standard that names each source, its role, the reasoning and the owner, approved through the change process so an assessor can see the decision and its date.
Configure supported assets to use the sources
Point every supported asset at the approved time sources through its native mechanism, such as the operating system time service, a network time daemon, or the platform settings for network devices, hypervisors and cloud instances. Where a Linux host runs chrony, the configuration file lists the approved servers and the host can also act as a local NTP server for other systems. Output: a configuration baseline per asset class, plus the change records showing that each asset was updated.
Verify synchronization and monitor offset
Confirm that each configured asset reports synchronization with its sources and that the measured offset stays within the tolerance the organization sets. Automate this with the time daemon's status output or a monitoring agent that collects offset, stratum and source reachability, and alert when an asset drifts or loses all sources. Output: a verification report or dashboard showing per-asset sync state, which forms the raw data for the NTP compliance coverage metric.
Record exceptions for assets that cannot sync
Some devices, embedded systems or legacy platforms cannot use the approved sources or do not support time configuration. List each one in an exception register with the reason, the compensating measure (for example, correlating its logs against a synchronized neighbor or collecting its events at a synchronized collector), the risk owner and a review date. Output: an approved exception register that explains every asset outside the coverage numerator, so the gap is documented rather than hidden.
Document the process and assessor evidence
Write the time synchronization procedure so it names the sources, configuration baselines, monitoring method, exception handling and responsible roles, and link it to the audit log management process from Safeguard 8.1. Assemble a single evidence pack with the source standard, baselines, a sample of sync reports, the exception register and the coverage calculation. Output: a versioned procedure and evidence folder that an assessor can trace from the Safeguard to the logs they sample.
Set a review cadence and retest
Set a recurring review of time sources, configurations, monitoring alerts and the exception register, and rerun the coverage check after changes to the asset inventory, cloud accounts or network design. Ask the team responsible for logging and the assessor which review frequency they expect, because the assessment specification defines what to measure but not the cadence. Output: review records that show each cycle, its findings and the corrective actions, which keep the Safeguard current over time.

How chrony produces time evidence on self-hosted Linux systems

chrony is an open-source implementation under GPL-2.0-only that keeps the system clock of a Linux host aligned with NTP servers or reference clocks such as GPS receivers, and it can also act as an NTPv4 server for other computers on the network. For Safeguard 8.4, that dual role matters: a central chrony host can discipline a small set of internal clocks, and every other asset in scope can point at it as one of its sources. The project describes its accuracy as typically within milliseconds over the Internet and tens of microseconds on a LAN. For log correlation, the practical point is that millisecond-level agreement is usually enough to order events across a firewall, a directory server and an application host, while a LAN deployment gives far more headroom than a WAN path. Confirm the accuracy your own network actually achieves by measuring offsets, not by relying on the project's typical figures.

The evidence an assessor will want is the configuration and the observed state. The configuration shows which sources each host uses, normally set in the chrony configuration file, and the state shows whether those sources are reachable, selected and synchronized. chrony provides a command-line client for reporting sources and tracking status, and those outputs can be captured on a schedule and stored with the asset inventory from Safeguard 1.1 so that each in-scope host has a dated record. Before you rely on any specific command, flag, or export format, confirm it in your own environment and chrony version, because reporting options and output layouts can change between releases. Retain the captured output alongside the configuration files under version control so changes are traceable.

Scope is the limit to plan for. chrony runs on Linux and similar Unix-like systems, but it does not configure Windows hosts, which typically use their own time service, and it does not manage the clocks inside network appliances, storage arrays, printers or many vendor devices. Each of those needs its own time settings, and the organization must confirm which NTP or time sources each one supports and document them separately. An assessor testing Safeguard 8.4 will look at every enterprise asset where time is configurable, so an inventory that lists only Linux servers will leave a gap. Ask your implementation partner or internal team to produce a per-platform time source register as part of the evidence package.

Evidence that shows time synchronization is working

An assessor testing Safeguard 8.4 looks for proof that every in-scope asset is pointed at approved time sources and stays close to them over time. The artifacts below connect the asset inventory to configuration, measured behavior, documented exceptions and controlled changes to the time servers themselves.

Asset inventory cross-referenced to time configuration

Start from the enterprise asset inventory that Safeguard 1.1 produces, because the assessment specification treats it as a prerequisite for measuring Safeguard 8.4. Add a column for each asset's configured time sources and the date that setting was last verified. The gap between the inventory and the time column is the first thing an assessor will check, so every in-scope device, including network appliances, virtual machines and cloud instances, should have a value. Refresh the cross-reference on the same schedule as the inventory, and flag any asset where the time source field is empty.

Exported time source configuration for sample assets

Keep configuration exports for a sample of assets across each device class, such as Linux servers, Windows endpoints, hypervisors and firewalls. For Linux hosts running chrony, the export usually includes the chrony.conf file and the output of chronyc sources, showing at least two reachable sources. Store exports with a timestamp and the name of the person who collected them. Schedule a script that pulls these files from a sample on a fixed cadence so the evidence does not depend on someone remembering to export it before an audit.

Synchronization status reports over a period

A point-in-time configuration export shows intent, but assessors also want evidence that synchronization held across weeks or months. Export status reports that show each asset's selected source, stratum, reachability and last successful poll. Confirm that a reasonable share of the reporting window is covered, and check that the reports are retained under the same policy as other audit records. Ask your platform team to confirm which of these fields your monitoring stack can export without custom work.

Offset monitoring records

Offset records show how far each asset's clock drifts from its selected source, which is the measurement that makes log timestamps correlatable. Collect offset values from the time daemon on a regular interval and send them to the same monitoring platform that holds system metrics. Define an alert threshold that matches your correlation needs, and keep the alert history as evidence that deviations were noticed and handled. Confirm with your security team how much skew they can tolerate before an investigation timeline becomes unreliable.

Documented exception register with compensating controls

Some assets cannot reach two time sources, such as isolated industrial controllers or air-gapped segments, and the Safeguard applies only where supported. Record each exception with the asset, the reason the second source is unavailable, the owner, the approval date and the review date. Pair every exception with a compensating control, for example a local reference clock, periodic manual time checks logged to a register, or log forwarding that stamps events at a synchronized collector. Review the register at least once a year.

Change records for time server updates

Time servers are a dependency for every log source, so changes to their configuration need the same change control as firewall or identity changes. Keep change tickets for updates to upstream sources, server allow lists, stratum settings or software versions, with approvals and before-and-after configuration. After each change, attach a post-change offset check to the ticket. Ask your change board to confirm whether time server changes already fall under its standard process or need a separate workflow.

What meeting Safeguard 8.4 costs in money and effort

This table lists each cost component of standardizing time synchronization, who is paid for it, whether it is one-time or recurring, and what moves it up or down. No figures are given because none were supplied, so use the drivers to scope a quote. The main takeaway is that most of the cost sits in engineering and evidence upkeep across heterogeneous assets, not in the software.

Cost component	One-time or recurring	What drives it up	What drives it down
Time server hardware or virtual machines	One-time purchase or provisioning, then recurring hosting	Number of sites and network segments needing local time sources, hardware reference clocks such as GPS receivers, redundancy requirements	Reusing existing virtual infrastructure, a small number of central time servers, cloud-native time services where the platform supports them
Open-source software licenses (chrony, GPL-2.0-only)	No license fee identified, confirm GPL terms with counsel	Embedding or redistributing modified builds, bundling with proprietary appliances	Using packaged builds from the operating system vendor, unmodified distribution packages
Engineering time to configure and verify assets	One-time per platform, with recurring work on new assets	Mixed operating systems, network devices and appliances with limited time settings, legacy devices, manual configuration	Standard images and configuration management, a current asset inventory under Safeguard 1.1, reusable configuration templates
Monitoring integration	One-time setup, then recurring alert handling	Number of assets reporting offset or sync status, alerts on every minor drift, separate tools per platform	Central collection of time status into existing logging or monitoring, thresholds tuned to agreed tolerances
Exception handling	Recurring	Devices that cannot reach two time sources, isolated or air-gapped networks, vendor appliances without configurable time, undocumented exceptions	Documented exception register with owners and review dates, a single approved fallback design for isolated segments
Evidence upkeep	Recurring	Frequent configuration changes, no single record of time sources per asset, evidence gathered by hand for each audit	Scripted exports of configuration and sync status, stored configuration baselines, a periodic review cycle
Auditor sampling or external review	Recurring per assessment cycle	Number of assets sampled, unclear scope, missing exception records, inconsistent time sources across samples	Clear scope statement, consistent configuration across asset classes, ready evidence for each sampled asset

Where time synchronization programs usually fall short

Most time synchronization failures are not dramatic. They are quiet gaps: one source that nobody checks, assets nobody counted, and clocks that drift after the build is signed off. Each card below names a gap, how to close it, and the evidence that shows the fix holds for Safeguard 8.4.

Only one time source configured

Many hosts point at a single NTP server, so one outage or misconfiguration leaves every log timestamp unverified. Safeguard 8.4 asks for at least two synchronized time sources where supported. Close the gap by configuring at least two independent upstream sources in the time daemon, such as chrony with a server or pool directive for each source, and confirm the daemon reports more than one reachable source. Evidence: the sanitized configuration files and a sample of source status output from representative hosts.

Virtual machines inheriting host clocks

Guests often assume their clock is correct because the hypervisor provides it, but guest clocks can drift or be paused during host load, and some guests run their own time daemon in addition to host synchronization. Check each virtual machine and container image for its own time configuration and verify its offset against the reference sources rather than trusting the host. Evidence: a list of guest and image time settings and offset readings taken from inside the guest, not only from the host.

Appliances and network devices left out of scope

Firewalls, load balancers, switches and storage arrays generate security-relevant logs but are often excluded from time configuration because they sit outside the server team's tooling. Safeguard 8.4 applies across enterprise assets, so these devices belong in the asset inventory from Safeguard 1.1 and in the measurement population. Confirm each appliance supports network time protocol, configure it, and record any device that cannot be configured as an exception. Evidence: an inventory extract showing time settings for every device class.

No offset monitoring

Configuring time once tells you nothing about whether clocks stayed correct. Without monitoring, drift caused by unreachable sources, firewall changes or failed daemons goes unnoticed until a log investigation fails to line up. Collect synchronization status and offset from each asset into the same logging or monitoring platform used for audit logs, and alert when an asset loses sources or exceeds an agreed offset threshold. Evidence: alert rules, sample alert records and the dashboard that shows coverage across the population.

Undocumented exceptions

Legacy systems, isolated networks and vendor appliances often run with unique time settings or none at all. When these exceptions are never written down, the coverage figure looks higher than the real position and assessors cannot tell an accepted risk from an oversight. Maintain a register that names each exception, the reason, the compensating measure such as manual checks or a local reference, the owner and a review date. Evidence: the signed exception register and the review records for each entry.

Clocks checked only at build time

Hardened images and baseline builds are often verified once and then cloned for years. Systems that are later moved, re-imaged, placed on a new network or restored from backup can inherit stale or wrong time settings without anyone noticing. Add time checks to change management, rebuild procedures and post-restore tests, and repeat the offset measurement on a schedule. Evidence: change tickets or build checklists that include a time check, and dated offset records from periodic re-measurement.

Who does what: your team, an implementation partner and the auditor

The organization owns Safeguard 8.4 as a control, so the decisions behind it must be made internally, even when a partner builds the configuration. Someone accountable has to decide what consistent time means for the environment, which sources are trusted and which assets are exempt. That decision is what the auditor will test against, so it must exist in writing before any measurement starts. The CIS Controls Assessment Specification describes what gets measured for this Safeguard, and your team should read it before agreeing the design.

Policy and standard: Write the time synchronization requirement into the documented audit log management process and name the owner who approves changes to it.
Authoritative sources: Decide which upstream sources are trusted, whether an internal hierarchy or an external pool, and record who may change them.
Asset inventory: Keep the enterprise asset inventory current. Safeguard 1.1 is a prerequisite for measuring 8.4, and a host missing from the inventory is a host nobody measures.
Exception decisions: Approve, time-limit and document assets that cannot take two sources, such as some embedded or appliance devices, and set the compensating checks for each.
Evidence ownership: Own the recurring measurement report, its review cycle and the record of who acted on each finding.

Confirm that a named person can list the time sources for every asset class and explain each exception without asking the partner.

Questions buyers ask about Safeguard 8.4

Does Safeguard 8.4 apply to IG1 organizations?

No. CIS assigns Safeguard 8.4 to Implementation Groups 2 and 3, not IG1, so an organization that only works through IG1 does not have to meet it to claim that baseline. It still makes sense to keep clocks accurate on every system, because logs from unsynchronized hosts are hard to correlate during an investigation. Confirm the current Implementation Group assignments on the CIS Controls v8.1 pages before you scope the work, since your target group determines which Safeguards are in scope.

How long does it take to standardize time synchronization?

No supplied figure gives a duration, so treat any number you hear as a claim to verify. The work is usually short on a small estate and grows with the number of asset types, operating systems, network segments and devices that cannot run a standard time client. The main drivers are how many enterprise assets you must inventory first, whether you have a reliable internal time source, and how many systems need configuration changes that require a maintenance window. Ask the provider to break the schedule into inventory, design, configuration, verification and evidence collection.

Can our own team implement Safeguard 8.4 without outside help?

Yes, if your team can inventory assets, configure a time client on each supported system and check the results. The CIS Controls Assessment Specification lists Safeguard 1.1, the enterprise asset inventory, as a prerequisite for measuring Safeguard 8.4, so your asset inventory is the first thing an internal team needs to get right. Open-source tooling such as chrony can act as an NTP client or a server for other computers, which keeps the technical side simple. The harder part is usually consistent evidence across teams, so write down the configuration standard and keep records of what each system reports.

What does the internal team need to provide?

The team needs an accurate enterprise asset inventory, administrative access to the systems being configured, and someone who owns the time source design. Without an inventory, you cannot show that every in-scope asset is covered, which is the core of the measurement. Network and platform engineers should confirm which systems can reach the chosen time sources, and security staff should define what a compliant result looks like. Record who approved the design and who reviews the monitoring output, because assessors ask for ownership as well as configuration.

Can an external provider certify that we comply with Safeguard 8.4?

No. An external provider can help configure systems, prepare evidence and document the design, but only an independent auditor, assessor or certification body issues reports or certificates. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports, attestations or certifications. Your organization owns its controls and decides which assessor, if any, will test them. Ask any provider to state its role in writing so that the distinction is clear in the contract.

How does Safeguard 8.4 relate to Safeguards 8.5 and 8.9?

Safeguard 8.4 makes timestamps comparable across systems, which is what lets Safeguard 8.5 detailed logs and Safeguard 8.9 centralized logs be correlated in one place. Detailed logging records fields such as dates and timestamps, and centralization gathers those records in a SIEM or similar tool. If the clocks disagree, the sequence of events in the central store can look wrong, even when every individual log is complete. Verify time sources on each source before you rely on the central platform for investigations.

What should we ask for in a quote for this work?

Ask for a written scope that names the in-scope assets, operating systems, time sources and the Safeguards covered, along with the deliverables, such as a configuration standard, configuration records and verification output. The quote should separate one-time work, like design and initial configuration, from any recurring monitoring or support. Ask which items depend on your inventory being complete and what the provider needs from your team in hours and access. Confirm how the provider handles evidence handover and whether the scope excludes any independent assessment. DeployOpen does not publish a price list, and a quote follows from the written scope.

How DeployOpen scopes, implements and prepares time synchronization evidence

DeployOpen treats Safeguard 8.4 as a clock configuration task that feeds your audit logging, so we start from which enterprise assets produce logs and which time sources they should use. We deliver a fixed-scope implementation inside your own infrastructure, and we prepare the configuration and measurement evidence while your organization and its independent assessor decide whether the Safeguard is met.

How we scope

Confirm the asset list from Safeguard 1.1 that defines which devices need time synchronization
Record which assets support two or more time sources and which need documented exceptions
Agree in writing which time sources, network paths and systems are in and out of scope

How we build

Configure chrony or the platform's native time service on in-scope systems against your chosen sources
Set up at least two synchronized time sources where supported, with clear fallback behavior
Test drift and synchronization status on sample assets before rollout across the scoped estate

How we hand over

Document the time architecture, configuration standards and exception register for your records
Provide the measurement outputs needed for the four measures in the assessment specification
Walk your team through the evidence set so your assessor can trace each measure to a system

How we support

Offer ongoing support and upgrades for the time infrastructure as a retainer, if you want it
Review new assets added to the estate so they join the synchronized configuration
Confirm with your assessor and your own environment which evidence formats they will accept