10.6 Time synchronization: PCI DSS requirements and evidence

What PCI DSS 10.6 asks for when logs must line up

When an assessor or incident responder pulls logs from a payment gateway, a database, a firewall and a cloud load balancer, the question is whether the timestamps can be lined up into one sequence of events. Requirement 10.6 exists to make that possible. It asks that system clocks are synchronized, that time comes from designated central time servers fed from International Atomic Time or UTC, and that the time settings themselves are protected from unauthorized change. The organization owns this control. An implementation partner can build and document the time architecture, but only the independent assessor reaches a conclusion about it.

Requirement 10.6 has three sub-requirements. 10.6.1 asks that system clocks and times are synchronized using time-synchronization technology. 10.6.2 asks that the correct and consistent time is received from designated time servers, that only those servers take time from external sources, that multiple time servers peer with each other, and that internal systems take time only from them. 10.6.3 asks that access to time data is limited to personnel with a business need, and that changes to time settings on critical systems are logged, monitored and reviewed. Without a consistent clock, a sequence such as a failed login followed by a configuration change can appear reversed, which slows investigation and weakens the evidence an assessor relies on under Requirement 10.4 and the other Requirement 10 controls.

The hard part is rarely the software. Legacy hosts often run unmaintained time clients or were never pointed at internal servers. Virtual machines can drift when the hypervisor and guest both adjust time. Cloud instances may already receive time from a provider service, and teams need to decide whether that source is acceptable or whether it must feed an internal designated server. Confirm with your assessor which time sources and hierarchy they will accept, and build an inventory of every system that reports timestamps. A tool such as chrony can act as an NTP client or server, but the design and the evidence of its configuration remain the organization's responsibility.

Which systems and teams 10.6 applies to in scope

Requirement 10.6 applies wherever a clock feeds an audit log that could be needed for cardholder data investigations. The cards below cover the systems in scope and the scoping decisions that change who does the work, so the scope agreed with your assessor matches the systems that actually produce logs.

Cardholder data environment systems

Every system component in the cardholder data environment that writes audit logs falls under 10.6, including servers, databases, application hosts, network devices and containers. Build a clock inventory from your CDE system list and record each host's time source. A host that logs with a drifting clock weakens the correlation of events across systems, so check each one, not only the domain controllers.

Connected security systems

Firewalls, intrusion detection tools, anti-malware consoles, file integrity monitoring and log collectors feed the same timeline as CDE systems. Their clocks must agree with the rest of the environment or alerts cannot be ordered during an investigation. Confirm with your assessor whether each security platform is inside the CDE or connected to it, because connected systems are commonly assessed in the same way.

Any device that produces or stores audit logs

The test is whether a device writes log entries, not whether it stores cardholder data. Include log forwarders, SIEM nodes, log archives and workstations that record administrator actions. Ask each team to name the devices they own that generate logs, because endpoints and appliances are often missed when the scope is drawn only from network diagrams.

Cloud provider time services

Whether a cloud provider's managed time service counts depends on your responsibility matrix and on whether your instances use it or run their own time sources. Document which time source each instance uses and retain the provider's description of its time service. Your assessor will ask who controls the upstream source, so agree that answer before the assessment starts.

Shared service providers and time ownership

When a service provider runs systems that handle your logs or sit in your CDE, agree in writing which party operates the designated time servers and which party operates endpoints. The provider's responsibility matrix should state this split. Where the provider runs the time servers, request evidence of its synchronization and protection controls rather than assuming they match your own.

Who owns time servers versus endpoints

Platform or infrastructure teams usually own the designated time servers, while system administrators own endpoint configuration and application teams own their hosts' settings. Assign one named owner to the time server tier and one to endpoint compliance, and record both in the 10.1 roles documentation. Unclear ownership is a common reason time drift persists unnoticed between audits.

How a QSA tests time synchronization

This table maps each Requirement 10.6 sub-requirement to the test an assessor typically runs, the evidence they request and the findings that most often appear. Read it as a checklist for preparing evidence before fieldwork begins, since assessors test the configuration and the records behind it, not just whether a clock looks correct.

Sub-requirement	What the assessor tests	Evidence requested	Common findings
10.6.1 Clock synchronization	Every in-scope system uses time-synchronization technology and its clock stays synchronized	Service configuration files, service status output on sampled systems, list of in-scope hosts with their time source	Systems with no time service, hosts left on local clocks, virtual or container images that inherit an unverified clock
10.6.2 Correct and consistent time	Only designated internal servers receive external time, those servers use UTC or International Atomic Time sources, they peer with each other, and other systems take time only from them	Time source list, peer status output, firewall or access rules showing which hosts may query external sources, internal client configuration samples	A single unmonitored time server, internal clients pointing at public pools, no peering between time servers, time sources not documented
10.6.3 Protected time settings	Access to time data is limited to people with a business need, and changes to time settings on critical systems are logged, monitored and reviewed	Access lists for time servers and configuration files, change tickets and audit log entries for time changes, evidence of review	Broad administrative access to time servers, time changes made without a ticket, time-change events not forwarded to the central log platform
Scope of in-scope systems	Assessor builds a list of systems in the cardholder data environment and checks each against the time design	Asset inventory, network diagram, sample of hosts across each system type	Containers, appliances or cloud instances missing from the inventory, so their clocks were never tested
Time source documentation	Assessor confirms the documented source of time and how it reaches each designated server	Written design showing upstream sources, reference clocks and failover, plus the change history of that design	Source described only verbally, or design documents that do not match the running configuration
Monitoring of time health	Assessor checks whether drift, loss of sync or source failure is visible to the team	Alert rules or monitoring dashboards, sample alerts with follow-up records	Time offset not monitored, so drift stays unnoticed until logs fail to correlate during an investigation

How to implement designated time servers step by step

This sequence turns the clock requirements of 10.6 into a documented time architecture: every log-producing system is inventoried, a small set of designated internal servers is built on approved UTC-based sources, and all other systems take their time from those servers alone. Each step leaves a record an assessor can check.

Inventory every system that generates logs
Start with a complete list of the systems that write audit logs, including cardholder data environment servers, network devices, security tools, cloud services, containers and any system that stores or forwards log data. Record the hostname, IP address, operating system or platform, owner and whether it sits in the CDE or connects to it. Your infrastructure team usually owns this list, and a security engineer should review it for gaps such as hypervisors, appliances and cloud-managed resources that never appear in a normal server inventory. The step is complete when the inventory is reconciled against your CMDB or asset register and every system that logs has a named owner and a recorded clock source. This inventory becomes the baseline you check the rest of the sequence against.
Choose and document the designated time servers
Select one or more internal systems to act as designated time servers and record them in a time source register. Give each server a purpose, an owner, a location and a justification for why it was chosen, such as network placement, hardening status or resilience. Keep the number small enough to manage and large enough that a single failure does not stop time distribution, and confirm with your team that the chosen hosts meet the hardening expectations of the requirements that cover secure configuration. The output is a signed or approved time server register that names each designated server and explains its role. Assessors will ask for this record first, so keep it under change control.
Configure external time sources from approved UTC-based references
Configure only the designated time servers to receive time from external sources. The requirement points to International Atomic Time or UTC as the basis for those sources, so document which upstream servers, reference clocks or GPS receivers you use and confirm each one is traceable to UTC. Software such as chrony can synchronize the system clock with NTP servers or reference clocks and can act as an NTPv4 server for other computers. Ask your vendor or your upstream provider to confirm how their sources are traceable, and do not assume a public pool member is appropriate for a regulated environment without review. The output is a time source record listing each external source, its traceability statement and the configuration file that references it.
Configure peering between the designated servers
Set the designated time servers to peer with each other so that they cross-check their clocks and continue to agree if one upstream source fails. Peering keeps the internal time hierarchy consistent and reduces the chance that one server drifts without detection. Verify that each designated server reports its peers and its selected source, and record the results from a status query at the time of testing. The output is a configuration baseline for each designated server that shows the external sources, the peer relationships and the access controls on the time service. Store the baseline in version control so later changes can be compared against it.
Point internal systems at the designated servers only
Configure every system in the inventory to take its time only from the designated internal servers. Block or remove any other time source on those systems, including public pools that were set during default installation, so that no system receives time from an unapproved path. Use your configuration management tool to push the setting and reconcile it against the inventory from the first step. Test a sample from each system category, such as Linux servers, Windows hosts, network devices and cloud instances, and record the results. The output is a configuration compliance report showing each in-scope system, its configured time source and the date of the check. Any system that cannot be pointed at an approved source should be recorded as an exception with an owner and a remediation plan.
Restrict and log changes to time settings
Limit access to time data and time configuration to personnel with a business need, and make changes to time settings on critical systems subject to logging, monitoring and review. Define which roles can read or modify the time servers, the peering configuration and the client settings, and confirm the access is granted through your normal identity and access process. Route time configuration changes through your change management workflow, and forward the resulting logs to your central logging platform so that a reviewer can see who changed a clock source and when. The output is an access list for time configuration, a sample of logged change events and a documented review task that reviewers complete on a schedule your policy sets.
Verify the sequence and keep the evidence current
Run a final check that connects the earlier outputs: the inventory, the time source register, the configuration baselines, the compliance report, the access list and the change logs. Confirm that every in-scope system points to a designated server, that the designated servers agree with their peers and that the change logging is reaching your central log store. Repeat the verification after major infrastructure changes and on the schedule set in your policies. The output is a time synchronization evidence pack that a QSA or internal assessor can sample. Independent assessors test this evidence and decide whether it meets the requirement, so prepare the pack for their review rather than presenting it as a compliance determination.

How chrony and audit logging support the time evidence

chrony keeps each system clock aligned with NTP servers or reference clocks such as GPS receivers, and it can also act as an NTPv4 server for other hosts. That combination is what makes the 10.6.1 and 10.6.2 designs practical: the designated internal time servers take their time from approved external sources, and every other system in the cardholder data environment (CDE) takes its time only from those internal servers. The project describes typical accuracy as milliseconds over the Internet and tens of microseconds on a LAN. Treat those figures as the tool's general description, not as a target your environment must meet. Confirm with your own design and your QSA what offset tolerance you will set and how you will monitor it.

Audit logs depend on the same clocks. The admin_audit app in Nextcloud writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. OpenBao audit devices write a detailed JSON record of each API request and response, with most sensitive values hashed using HMAC-SHA256. Both record timestamps taken from the host clock. If a server drifts or its time is changed, events from different systems can appear out of order or fall outside the window you are reviewing. Review time settings and log timestamps together, so that a clock change on a critical system is visible in both the 10.6.3 change log and the audit trail. Check which timezone and format each application writes, and confirm that the logs reach your central store with the original timestamps intact.

chrony, Nextcloud and OpenBao generate configuration and status evidence, such as tracking output, server configuration files, audit log entries and log forwarding settings. That evidence supports the requirement, but the tools do not satisfy it by themselves. The organization must decide which servers are designated, which external sources they use, how peering is arranged, who may read or change time settings, and how alerts for offset or clock change are handled. Document those decisions, then have your assessor review the actual design. Confirm the current capabilities and configuration options in the chrony and OpenBao documentation before you rely on them for a specific design.

Evidence that passes 10.6 and how to keep it current

An assessor testing 10.6 wants proof of three things: which servers are the authoritative time source, that every other system actually syncs to them, and that nobody changes the clocks without a record. The cards below cover those artifacts and the routine that keeps them accurate between assessments.

Designated time server register

Keep a controlled list of the designated internal time servers, their upstream external sources (based on International Atomic Time or UTC), and the owner of each server. The register should match what is actually configured on the hosts, so an assessor can compare the document with a live configuration. Record the date of each change and who approved it. Confirm with your auditor which format of inventory they accept, since many accept an export from configuration management.

Peering and upstream configuration

Export the configuration showing that multiple designated time servers peer with each other and that only those designated servers reach external sources. For chrony, this means the server and peer directives on each host, which are kept in /etc/chrony/chrony.conf on many Linux distributions. Store the configuration under version control so each change has a commit history. Check that internal systems list only the designated servers and no public pool addresses.

Synchronization status output

Capture the synchronization state from each in-scope system on a schedule, not just once before the assessment. For chrony, the chronyc tracking and chronyc sources output shows the reference, stratum, and offset, which an assessor can read directly. Retain the captures with timestamps and host names. Flag any system that is unsynchronized, reports a large offset, or drops out of the source list, and record how the exception was resolved.

Time settings access list

Document who can read and change time settings, and restrict that group to people with a business need. Export the group membership or sudo rules for the time service and the host files that hold it. Review the list at the same cadence as other access reviews, and remove leavers promptly. An assessor will ask for this list alongside the change records, so the two should reconcile.

Logged and reviewed time changes

Changes to time settings on critical systems must be logged, monitored and reviewed. Route clock and time-service changes into the same audit trail as other administrative actions, and confirm that the log entries include the actor, host, previous value and new value. Pair each logged change with a change ticket that explains the reason. A reviewer should sign off on these entries during the regular log review cycle, and the sign-off should be retained.

Periodic review and change tickets

Schedule a recurring review of the time server register, peering configuration, access list and a sample of synchronization captures, then record the reviewer, date and findings. Use change tickets for every planned adjustment, such as replacing a time server or moving to a new upstream source. Between audits, these tickets and review records are the evidence that the control kept operating. Ask your assessor how many months of review history they expect to see for a continuous assessment.

What meeting 10.6 costs in money and effort

This table breaks down the money and effort behind requirement 10.6, separating one-time setup from recurring upkeep and naming who is paid for each part. Use it to build a quote request, because the largest drivers are the number of systems, how varied those systems are, and what monitoring you already run.

Cost component	Who is paid	One-time or recurring	What drives it
Time server hardware or virtual machines	Your infrastructure team or cloud provider	One-time build, then recurring hosting	Number of designated time servers, redundancy design, and whether they run on-premises or in cloud accounts
Open-source time software (chrony)	No license fee; labor only	One-time configuration, then recurring patching	Chrony is GPL-2.0-only, so licensing spend is removed; cost shifts to engineering and maintenance hours
Engineering time to configure and document	Implementation partner or internal engineers	One-time	Heterogeneity of operating systems, number of clock sources, and how many systems must point to the internal servers
Monitoring and review of time settings	Your security or operations staff	Recurring	Whether time-setting changes already feed your existing log pipeline, and how many people hold access to time data
Evidence upkeep	Your compliance team, sometimes with a consultant	Recurring, at each assessment cycle	Number of diagrams, configuration exports and change records the assessor samples, and how current they stay
External testing or QSA sampling	Qualified Security Assessor (assessor fee) and any testing firm	Recurring, per assessment	Size of the in-scope environment, sample volume the assessor selects, and how cleanly evidence is organized
Remediation of drift or exceptions	Your operations team, or a retainer partner	Irregular, triggered by findings	Clock drift history, unmanaged systems, and cloud instances that bypass the standard time source

Who does what for 10.6: your team, a partner and the assessor

Your organization owns Requirement 10.6. Someone accountable must decide how clocks are kept consistent across the cardholder data environment and in-scope systems, and must be able to show that decision to an assessor. Ownership does not transfer when a partner builds the servers, and it does not transfer when a QSA tests them.

Design the time architecture: Decide which systems are in scope, which internal servers act as designated time servers, which external sources they use, and how the servers peer with each other.
Approve configuration: Sign off on the time server settings and the client settings that internal systems use, and keep them under change control.
Restrict access to time settings: Define who may change time data and time configuration, and confirm that these personnel have a business need.
Review changes: Assign someone to review logged changes to time settings on critical systems, with documented follow-up.
Keep the evidence current: Maintain the architecture diagram, the server inventory and the review records so they match the live environment.

Before an assessment, confirm that a named owner can explain the design end to end without relying on the partner.

Where organizations fall short on time synchronization

Time synchronization gaps rarely look like failures on their own. A host with a drifting clock or an unlogged time change only becomes a problem when an assessor tries to line up events across systems and finds the timestamps disagree. The cards below cover the gaps assessors most often find under Requirement 10.6 and the check that closes each one.

Unmanaged local clocks

Some systems keep their own clock with no synchronization service running, so the time drifts quietly until someone notices a log entry out of order. This matters for 10.6.1 because every system that produces audit logs needs time-synchronization technology active. Check each in-scope host, virtual machine and network device for a running time client, and confirm it reports a recent sync. Close the gap by inventorying every clock source and enabling a single time client on each host.

Internal hosts querying public servers

Many teams point each server directly at public time pools, which means dozens of systems reach outside the network on their own schedules. Under 10.6.2, internal systems should take time only from designated internal servers, and only those designated servers should receive time from external sources. Review the time configuration on workstations, servers and appliances for external pool names. Close the gap by pointing internal hosts at the designated internal servers and blocking direct outbound time traffic.

A single time server without peers

A lone internal time server is a single point of failure, and if it drifts or goes offline, every correlated log timeline inherits the error. Requirement 10.6.2 expects peering between multiple time servers so that one source can be checked against another. Ask whether the designated servers peer with each other and whether a failed upstream source would be noticed. Close the gap by deploying at least two designated servers that peer with each other. Confirm the redundancy design with your assessor before you rely on it.

No documented list of designated servers

Teams often know which time servers they use but cannot show a current, approved list with their upstream sources. Assessors look for that list because 10.6.2 depends on knowing exactly which servers are designated and which external sources feed them, including confirmation that those sources are based on International Atomic Time or UTC. Without the list, the time configuration cannot be tested. Close the gap by maintaining a controlled inventory of designated servers, their upstream sources and their owners.

Unlogged time setting changes

Changes to system time are rarely recorded, so a manual clock adjustment on a critical system can hide the window in which events were logged. Under 10.6.3, access to time data should be limited to people with a business need, and changes to time settings on critical systems must be logged, monitored and reviewed. Pull the access list for time configuration and check whether a change to time settings produces an alert or review entry. Close the gap by restricting time configuration rights and forwarding time change events to the central log.

Virtual and container hosts inheriting host time

Containers and virtual machines usually share the clock of their host, so a drifting or misconfigured hypervisor can shift the time of every guest at once. Teams often assume the guests are synchronized because they run on a synchronized host, and nobody checks the guest configuration. Under 10.6.1, each system in scope needs a verified time source, which includes guests and containers that may have their own time settings. Compare the reported time on guests with the designated servers. Close the gap by testing guest and container time against the designated servers and documenting the source for each.

Questions buyers ask about 10.6 cost, effort and outside help

How much effort does requirement 10.6 take to meet?

For most environments, the effort sits in the design and evidence work rather than in installing a time client. Requirement 10.6 needs system clocks synchronized through time-synchronization technology, one or more designated central time servers that take time from external sources based on International Atomic Time or UTC, peering between those servers, and internal systems that take time only from them. Effort rises with the number of systems in scope, the number of network zones, and how many clock sources already exist, such as hypervisors, cloud instances, network devices and appliances that each keep their own time. No figure for hours is supplied here, so ask your implementation partner to estimate effort from an inventory of systems and time sources in your own environment.

Can we meet 10.6 with our own team?

Yes, many organizations do, provided the team has network and systems skills and someone owns the design and the evidence. The work breaks into four parts: choosing the time-synchronization software (for example, chrony, which is GPL-2.0-only and can act as an NTP server for other computers), configuring designated servers, configuring every other in-scope system, and producing evidence. Teams that already run directory or infrastructure services often find the configuration routine but underestimate the inventory and the review of exceptions. The organization always owns its controls. An assessor, not a consultant, decides whether the evidence is sufficient.

What does the work need from our team?

The work needs a named owner for time configuration, access to an accurate inventory of in-scope systems, and change control that can record edits to time settings. Requirement 10.6.3 limits access to time data to personnel with a business need and requires changes to time settings on critical systems to be logged, monitored and reviewed, so your security operations team must be able to receive and review those logs. Network staff must confirm firewall rules allow traffic to the designated servers. Ask your team to confirm which systems are in scope before any configuration begins, because undocumented devices are the most common source of unplanned effort.

How long does 10.6 take to implement?

No duration is supplied for this requirement, so treat any timeline as something to confirm, not something to assume. The main drivers are the number of time sources that need to be reconfigured, whether external time sources must be approved through a change window, whether the environment is on-premises, cloud or air-gapped, and how long it takes to collect and review evidence for an assessment. Ask your implementation partner to show the sequence of tasks, the dependencies on other teams, and the dates that depend on your change calendar.

Will a QSA accept our cloud provider's time service for 10.6?

The assessor decides, based on the evidence, so confirm this with your QSA before you rely on it. A cloud provider's time service can be a reasonable source for system clocks, but requirement 10.6.2 still expects designated internal time servers, with only those servers receiving time from external sources based on International Atomic Time or UTC, and with internal systems taking time from them. Ask the QSA how they expect that structure to be shown in a cloud or hybrid environment, and document the provider's time source, the designated servers and the peering arrangement. Where the provider is outside your control, record how you verified the time source.

What should we ask for in a fixed-scope quote for 10.6?

Ask for a written scope that names the systems and network zones covered, the designated time servers, the external sources to be used, and the configuration baseline for each system type. The quote should list each deliverable, such as the time-server design, configuration files, a monitoring rule for changes to time settings, and an evidence pack mapped to 10.6.1, 10.6.2 and 10.6.3. Confirm which tasks are one-time (design, initial configuration, documentation) and which recur (monitoring, periodic review, support). Ask how exceptions and out-of-scope systems are handled, and confirm that the partner prepares evidence without issuing any audit report or attestation, which only an independent QSA can do.

Does DeployOpen issue a 10.6 compliance report?

No. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and prepares the systems and evidence that support requirement 10.6. Only an independent Qualified Security Assessor can assess the requirement and issue the Report on Compliance or Self-Assessment Questionnaire with its Attestation of Compliance, and PCI DSS certificates are not recognized as validation. Your organization remains responsible for its controls. Where the assessment scope includes time services you run, the implementation partner can help you produce the configuration baseline and the logs that show changes are reviewed.

What evidence will an assessor ask to see for 10.6?

Assessors usually ask for the list of designated time servers, the configuration of each server and client, the external time sources in use, the peering setup between servers, and a record of who can change time settings. They also look for logs showing changes to time settings on critical systems and evidence that those logs are reviewed. Confirm the exact evidence expected with your QSA before collecting it, because the assessment procedures govern what is tested and the assessor decides what is sufficient.

What to confirm with your assessor and environment

Start by agreeing with your QSA which time sources your environment will use, because that choice determines most of the evidence for 10.6.2. Only the designated time servers should take time from external sources, and those sources must be based on International Atomic Time or UTC. Confirm the exact upstream sources (public NTP pools, GPS or other reference clocks, or a provider's time service) and ask the QSA to confirm in writing that each one meets that basis. Also confirm how many designated servers you run, how they peer with each other, and which internal systems are configured to take time only from them. Document these decisions in your network and data-flow diagrams before the assessment begins, so the QSA can trace every system that touches cardholder data to its time source.

Next, decide with the QSA whether 10.6 will be met through the defined approach or the customized approach. The defined approach is the default and the simplest to evidence: configuration files, service status output and a list of synchronized hosts. A customized approach requires a documented, targeted risk analysis, a stated objective and evidence that the objective is met in a different way, and the QSA must test that design. Compensating controls are a separate route, used only where a requirement cannot be met as written because of a documented technical or business constraint. Ask which route the QSA expects for any legacy system, appliance or cloud service that cannot run the time client you normally use, and get that decision recorded before you build the evidence.

Finally, confirm which version of PCI DSS the assessment will use and how revisions affect your evidence. PCI DSS v4.0.1 is the only active version, and v4.0 was retired on 31 December 2024. The PCI SSC announced a request for comments on v4.0.1 in 2026, but it has announced no release date for a new version, so ask your QSA how a future revision would be handled for your next assessment cycle. Remember that the PCI SSC does not issue validation. Your QSA issues the Report on Compliance and your Attestation of Compliance, or you complete the applicable Self-Assessment Questionnaire and its Attestation of Compliance, and the payment brands decide which of these you must submit. Ask your assessor which evidence they will sample and how they will test time-setting change logs under 10.6.3.

How DeployOpen prepares time synchronization evidence

DeployOpen plans, builds and documents the time synchronization setup for systems inside your own infrastructure, so your logs line up under 10.6 Time synchronization. We prepare the systems and evidence, while your organization owns the control and an independent assessor reaches the conclusion.

How we scope

We list every in-scope system that generates audit logs and confirm which clock source each one uses today.
We agree on which hosts will act as designated internal time servers and which external sources they may query.
The written scope names the systems, deliverables, responsibilities and handover dates before any work starts.

How we build

We configure chrony on designated time servers to pull from approved upstream sources and peer with each other.
We point all other in-scope systems only at the designated internal servers and remove conflicting time sources.
We restrict who can read or change time settings and set alerts so changes to critical systems are logged and reviewed.

How we hand over

We deliver configuration files, a network diagram of time flows, and a record of who holds access to time settings.
We provide a verification runbook so your team can check offsets and sync status on a schedule and keep the results.
We document the change-review process for time settings so your assessor can trace each change to an owner.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and periodic checks of time synchronization are available as a retainer.
Your QSA or assessor reviews the evidence; DeployOpen prepares it but does not issue reports or attestations.