SC-45 System time synchronization: requirements and evidence

What SC-45 system time synchronization asks for and why assessors check it

SC-45 requires you to keep system clocks synchronized, both within a system and between the systems and components that make it up. An assessor or customer asking for SC-45 evidence wants proof that the timestamps on your logs, alerts and transactions agree closely enough to be placed in a single sequence during an investigation. The control is a base control in the System and Communications Protection family of SP 800-53 Rev. 5, and it is written to be met through configuration and monitoring of time sources rather than through a single product. Its assessment in SP 800-53A focuses on system design documentation, configuration settings and the audit records themselves, so the evidence you prepare should show both how time is set and what the logs look like as a result. The underlying purpose is correlation. When a firewall, a database, a identity provider and an application server each keep their own clock, an analyst cannot reliably tell whether a failed login preceded a privilege change or followed it. Aligned clocks let audit records from different components be ordered and joined, which is why SC-45 sits close to the audit controls in practice. Note that SP 800-53B does not assign SC-45 to any security or privacy baseline. It applies when your organization or an authorizing body selects it through tailoring or an overlay, so the first decision is whether your system's boundary and authorization package include it. The Release 5.2.0 catalog lists two control enhancements, and FedRAMP's Rev5 baselines select the authoritative time source enhancement, SC-45(1), at Classes C and D. Confirm the enhancement wording in the OSCAL catalog before you write it into your plan. What makes SC-45 hard in practice is drift across heterogeneous infrastructure. Virtual machines can inherit clock behavior from hypervisors, containers usually depend on the host kernel clock, and appliances often ship with their own time settings that no one has reviewed. Each of these can drift or point at different sources. Before an assessment, inventory every class of component that produces audit records, record its time source and sync client, and check that none is left on a default or unmanaged setting. The open-source chrony project, which synchronizes clocks with NTP servers or reference clocks and can serve time to other hosts, is one way to create a consistent internal hierarchy, but you should confirm its fit with your own time sources and records.

Which systems, teams and providers fall under SC-45 scope

SC-45 applies to any system whose clock feeds audit records, security tools or authentication, but only once the organization selects it through tailoring or an overlay. The cards below cover the components that carry time, the teams that own them and the outside providers whose time sources you must document.

Scoping decision for SC-45

SP 800-53B does not place SC-45 in the low, moderate or high baseline, so it is in scope only when your system security plan selects it through tailoring or an overlay. Record that decision, the reason for it and the boundary it covers. FedRAMP is the notable exception: its Rev5 baselines require SC-45 and SC-45(1) at Classes C and D. Confirm which of your systems fall into those classes before you scope the control.

Servers and hypervisors

Physical servers, virtual machines and hypervisor hosts each keep their own clock, and drift on any of them makes events hard to order. Hypervisors also set the clocks of the guests they run, so a misconfigured host can skew many systems at once. List every host that runs an in-scope workload and confirm each one points at the approved time source.

Network and security appliances

Firewalls, load balancers, VPN gateways and intrusion detection sensors stamp their own log entries and often run their own time services. Their timestamps must match the rest of the environment or correlation across firewall and endpoint logs breaks down. Check each appliance's time settings during build and after every firmware upgrade, because upgrades sometimes reset them.

Containers and orchestration platforms

Containers share the host kernel, so they inherit the host clock rather than keeping one of their own. Orchestration control planes and their logs still depend on accurate host time for certificate validity, token expiry and event ordering. Confirm that container platform nodes are included in the time synchronization design and that no workload runs with a separately configured clock.

Cloud instances and managed services

Cloud virtual machines and managed platforms often rely on the provider's time service, which may differ from the NTP setup you run on premises. Document which provider source each instance uses, whether you have overridden it and how the provider's logs are timestamped. Ask the provider in writing to describe its time source, since you cannot inspect it directly.

Ownership and third-party providers

Infrastructure teams usually own the time service, but application, security operations and network teams each depend on it, so name one accountable owner in the system security plan. Hosting and managed service providers that operate in-scope components must also document their time sources. Put these duties in the contract and in the shared responsibility matrix so the assessor can see who maintains each clock.

How an assessor tests SC-45 against SP 800-53A

This table breaks down the single SP 800-53A determination statement for SC-45 by assessment method, object and typical finding. Read it as a preparation checklist: each row shows what the assessor looks at, asks or runs, and where clock synchronization programs usually fall short.

Assessment element	What the assessor does	Evidence that passes	Where it usually fails
Determination statement	Confirms the organization synchronizes system clocks within and between systems and components, as SC-45 requires	Documented time sync design covering every in-scope system and component class	Clock sync described for servers only, leaving network devices, hypervisors and endpoints out
Examine: system design documentation	Reads the architecture for named time sources, hierarchy and which systems depend on them	Diagram or design note naming internal time servers, upstream sources and client systems	No design record; time sources exist but nobody can say where they are defined
Examine: configuration settings and documentation	Checks the configuration on sample systems against the documented design and tolerances	Exported settings showing the approved time servers and sync client status on each sampled system	Hosts point at a default public pool or a server that is not in the design
Examine: system audit records	Compares timestamps across logs from different systems for the same event	Logs from several systems that correlate within the tolerance the organization set	Timestamps differ by seconds or time zones are mixed, so events cannot be ordered
Interview: administrators	Asks who maintains time sources, how drift is detected and what happens when sync fails	Named owner, documented alert on sync loss, and a clear response step	Staff cannot say which servers are authoritative or whether anyone monitors offset
Test: compare clock offsets	Samples components and measures clock offset against the reference source at one point in time	Offsets within the organization's stated tolerance, with the method and timestamp recorded	Offsets outside tolerance, or the sampled hosts were chosen after the fact
Common finding: undocumented time source	Traces a system's sync source back to a source not listed in the design	Every source appears in the design and configuration record	Virtual machines or appliances sync to the hypervisor or vendor default without review
Common finding: drift outside tolerance	Records offset values and checks whether monitoring would have caught them	Monitoring that alerts when offset exceeds the stated limit, with tickets showing response	Drift noticed only during an incident investigation

What the FedRAMP authoritative time source enhancement adds at Classes C and D

The FedRAMP-specific point of SC-45 is enhancement (1), which concerns synchronizing system clocks to an authoritative time source. The base control already requires clocks to be synchronized within and between systems, but the enhancement asks the provider to say which source is authoritative and how the other clocks take their time from it. FedRAMP's Rev5 baselines require SC-45 and SC-45(1) at Classes C and D, so a provider operating at either class must treat the enhancement as a binding requirement, not an optional hardening step. The enhancement is also on FedRAMP's annual independent assessment list for Rev5 certifications, which means an assessor will test it at least once a year, not only during the initial authorization.

In practice, the enhancement turns a time setting into a documented design decision. The provider should name the authoritative source (for example, an internal stratum 1 or 2 server disciplined by GPS receivers, or a designated upstream NTP service), record its hierarchy from that source down to every server, firewall, hypervisor, database and log collector, and state which hosts are permitted to act as time servers. In a self-hosted environment, chronyc sources and chronyc tracking show whether a host is locked to its intended upstream, and the chrony configuration file records the server and allow entries that define the hierarchy. An assessor will compare that documented hierarchy with the live configuration, so the design document and the system configuration settings must agree. Confirm with your assessor which sources and configuration artifacts they expect, since the examine objects in SP 800-53A are a starting point, not a complete list.

Before you rely on this section, confirm the exact enhancement wording in the OSCAL catalog for SP 800-53 Release 5.2.0 and in the FedRAMP Full Rev5 Control Reference, not from this page. Check the current FedRAMP requirements for the authoritative source and any parameters your class adds, because the consolidated rules are updated and the wording governs what your assessor tests. Plan for two recurring costs: keeping the time hierarchy documented and current as hosts are added or retired, and producing the annual evidence. The independent assessor issues the report; the implementation partner or internal team prepares the configuration, diagrams and evidence that the assessor examines.

How to implement SC-45 in a self-hosted environment

This sequence takes an organization from an inventory of clock-bearing components to a documented, monitored and baselined time architecture, producing the evidence an assessor needs to see that system clocks stay aligned and that audit records can be correlated.

Inventory every clock-bearing component
Start by listing every component that keeps its own clock and writes time-stamped records: servers, hypervisors, network devices, firewalls, storage arrays, databases, application servers, container hosts, endpoints that produce logs, and any OT or appliance that reports events. The platform team usually builds this list from the CMDB, cloud account inventories and network scans, then checks it against the audit logging sources the organization has already documented. The output is a register with the component, owner, operating system or firmware, current time source and whether it writes to a central log store. The step is complete when someone who did not build the list can name a component that is missing and the owner confirms the register matches the running estate.
Select and document authoritative time sources
Decide which sources the environment trusts. Common choices are a GPS-disciplined reference clock inside the organization's own facility, or a small internal NTP hierarchy that draws from upstream servers chosen by policy. Document the selected sources, the stratum layers, which servers may act as upstream references, and who approves changes. The owner of this decision is usually the security or infrastructure architect, with the system owner signing off. Confirm the choice with the hardware and upstream providers, because accuracy and available protocols depend on the device and network path. The output is a time source standard, referenced by SC-45 and SC-45(1), that names the authoritative sources and the reason each was chosen. The step closes when the document is approved and placed under configuration control.
Configure internal time distribution
Deploy the internal time servers and point every clock-bearing component at them, using a daemon such as chrony (GPL-2.0-only), which can synchronize the system clock with NTP servers or reference clocks such as GPS receivers and can serve NTPv4 to other computers. Restrict which hosts may query the time servers, lock down the upstream sources, and make sure firewall rules permit only the intended NTP paths through the boundary. Network devices and appliances may need vendor-specific settings, so confirm their supported protocols before assuming compatibility. The output is a working distribution tier with configuration files kept in version control. The step closes when a sample of hosts from each component class reports the designated server as its source and the offset is within the threshold the organization has set.
Set drift monitoring and alerting
Clocks drift, and a server that loses its source will quietly fall out of alignment. Configure monitoring that collects offset, stratum, reachability and source status from the time servers and sampled clients, then alerts the operations team when a component exceeds the tolerance in the time source standard or stops reaching its source. Feed these alerts into the same ticketing and on-call process used for other infrastructure events. The owner is the operations or monitoring team, and the tolerance value should come from the organization's own risk decision rather than a vendor default. The output is a dashboard, a set of alert rules and a record of test alerts. The step closes when a deliberately disconnected test host triggers an alert that reaches the responsible queue and is logged.
Tie time settings to configuration baselines
Make time settings part of the approved configuration baseline for each component class, so that a change to the NTP server, a disabled service or a manually set clock is treated as a configuration deviation. Write the expected time configuration into the baseline templates, include it in configuration scanning or compliance-as-code checks, and route deviations through the normal change control process. This connects SC-45 to the configuration management family, where baseline configurations and change control are assessed. The output is baseline entries for time settings and a scan rule that reports drift from them. The step closes when a deliberately altered test host is flagged by the scan and the finding is handled through the change or incident workflow.
Record evidence for assessors
Assemble the artifacts an independent assessor will examine: the approved time source standard, system design documentation showing the time architecture, configuration files for time servers and sampled clients, the component register, monitoring screenshots or exported reports, alert test records, and samples of audit records showing consistent time stamps across sources. These map to the examine objects that SP 800-53A lists for SC-45, including system design documentation, configuration settings and audit records. Store the package with a date and an owner, and schedule its refresh whenever the register or time architecture changes. For FedRAMP Class C and D, also prepare evidence for the authoritative time source enhancement, SC-45(1), which the independent assessment must include at least once a year. The output is a versioned evidence set. The step closes when the system owner confirms the package matches the running environment and an assessor can trace each claim to a file, a report or a record.

Evidence that passes an SC-45 assessment

SC-45 is tested by examining design documentation, configuration, audit records and change history, so the evidence has to show both how clocks are meant to be aligned and that they actually are. The cards below cover the artifacts an assessor typically requests and how to keep them current between assessments.

System design documentation naming time sources

The design document should name the authoritative time sources, the hierarchy from upstream references to internal clients, and which systems sync to which servers. Assessors use it to confirm the design matches what they see in the environment. Check that the document lists every in-scope component, including virtual machines, containers hosts, network devices and appliances, and that it names an owner and a review date. A diagram alone rarely satisfies the examine method without the accompanying text.

Configuration files and settings exports

Export the time daemon configuration from each class of system, for example the chrony configuration file, and retain the exports with a timestamp and hostname. The files should show the approved upstream servers, the allowed clients and any restrictions on who can query the local server. Compare exports against the design document, since a mismatch is a common finding. Store the exports in version control so every change has an author and a reason.

Sync status snapshots showing offsets

Capture periodic output from the time client that shows the selected source, stratum and measured offset to the reference. A single snapshot proves little, so keep a series over the assessment period. Define an acceptable offset in your own documented policy and confirm it with your assessor, since the control does not fix one. Record snapshots from representative systems rather than only the domain controller or the monitoring server.

Audit records with consistent timestamps

Audit records from several systems should carry timestamps that line up when an event is traced across a boundary, a directory and an application. Pull a sample of records for one transaction from each component and check the ordering. Where timestamps disagree, the record is evidence that time synchronization is failing, not only a logging defect. Keep these samples with the audit review evidence so the two controls can be read together.

Change records for time source changes

Every change to an upstream source, client list or time daemon version needs a ticket with the reason, the approver, the test performed and the rollback plan. Assessors look for changes made outside the change process, such as a host manually pointed at a public pool. Reconcile the change log against the configuration exports at each review to confirm that the running state matches approved changes.

FedRAMP independent assessment report for SC-45(1)

At FedRAMP Classes C and D, the authoritative time source enhancement must appear in an independent assessment at least once a year. The assessor, not the organization or the implementation partner, produces that report. Your job is to make the artifacts above available, current and traceable to the enhancement. Ask the assessor early which evidence they expect for the authoritative source and whether they need a live demonstration.

What meeting SC-45 costs in money and effort

This table breaks down the cost components of meeting SC-45 System time synchronization, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request and to compare scoped proposals on equal terms. No price or duration is given because none is supplied for this control.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it
Design of the time architecture	Internal engineers or an implementation partner	One-time, revisited on change	Number of hosting environments, network zones and clock sources to plan
Configuration of time clients and servers	Platform or systems engineers	One-time per component, then recurring on rebuilds	Number of clock-bearing components, including hosts, containers, network devices and appliances
Tooling and software licensing	No license fee for chrony, which is GPL-2.0-only; cost falls on hardware and operations	One-time for hardware, recurring for hosting and support	Need for GPS receivers or other reference clock hardware in each site
Monitoring of offset and source health	Operations or security operations staff	Recurring	Alert thresholds, number of sites and whether alerts route to an existing monitoring stack
Evidence collection and upkeep	Compliance lead, engineers or a partner preparing evidence	Recurring, typically at each assessment cycle	Frequency of configuration change and how much evidence is generated automatically
Independent assessment and assessor sampling	Independent assessor, paid by the organization	Recurring, at the assessment cycle	Number of systems in scope and how many components the assessor samples; FedRAMP Rev5 Class C and D providers must include SC-45(1) in an annual independent assessment
Remediation of findings	Engineering staff or partner	Recurring when findings arise	Quality of configuration baselines and how often drift is detected

Open-source tooling that produces SC-45 evidence

chrony is a free, GPL-2.0-only implementation that keeps a system clock aligned with reference time. It disciplines the local clock against Network Time Protocol (NTP) servers or against reference clocks such as GPS receivers, and it can also act as an NTPv4 server for other computers on the network. That second role matters for SC-45 because it lets one hardened time service feed every host in a boundary, so clocks inside and between systems are synchronized from the same source. The project reports typical accuracy within milliseconds over the Internet and tens of microseconds on a local area network. Those are general figures from the project, and your own measured accuracy depends on network path, hardware and load.

Source selection: chrony can be pointed at several upstream NTP servers or at a local reference clock, so the design can avoid depending on a single source.
Serving internal hosts: One chrony instance can serve NTPv4 to internal clients, which concentrates the synchronization design in a few reviewed hosts.
Local accuracy: On a LAN, the project's typical figure of tens of microseconds is the more relevant number for correlating audit records between internal systems.
Hardware references: Where a GPS receiver or similar reference clock is available, chrony can use it as a source, which removes dependence on external network time.
Open license: GPL-2.0-only means the code can be inspected and modified, which helps with supply chain review under the SR family.

Confirm with your platform team which time sources are approved, whether they are internal or external, and whether the design matches the boundary defined in your system security plan.

Assessors testing SC-45 look for evidence that clocks are configured to a defined source and that they actually track it. chrony provides both. Its configuration file records the time sources and access rules, which can be examined against the documented design. Its tracking command reports the current reference source, the offset from that source and related statistics, which an assessor can use to test whether systems are in fact synchronized. Because the examine objects for SC-45 include system configuration settings and system audit records, those two artifacts should be kept together: the configuration shows intent, and the tracking output and audit timestamps show results.

Configuration files: The chrony.conf file lists upstream sources and any server or allow directives, and it should be version controlled with change records.
Tracking output: Running chronyc tracking shows the reference source, stratum and system time offset, which can be captured on a schedule.
Source status: Running chronyc sources shows which configured sources are reachable and which one is selected, which supports reviewing source health.
Audit record correlation: Sampled timestamps from audit logs on several hosts, checked against tracking output at the same time, show that records line up.
Change history: Dated changes to time source configuration tie the evidence to the authorized design over the assessment period.

Before relying on this evidence, confirm that your logging pipeline preserves these timestamps and that your assessor accepts the captured outputs as suitable for their test method.

SC-45 has two enhancements in Release 5.2.0, and FedRAMP selects SC-45(1), the authoritative time source enhancement, at Classes C and D. chrony can help meet the synchronization requirement, but it does not decide on its own whether a source counts as authoritative for your program. That judgment depends on how your organization or authorizing body defines an authoritative time source, and on whether the source is documented, controlled and monitored. Before you claim the enhancement, read its current wording in the NIST catalog and in the FedRAMP rules that apply to your class, then document how your chosen sources satisfy each requirement. Your independent assessor will decide whether the evidence is sufficient.

Authoritative source definition: Record which upstream sources you treat as authoritative and why, with the reasoning kept in the system security plan.
Source control: Restrict who can change chrony.conf and log every change, since an unexpected source change is a time integrity risk.
Monitoring: Alert on loss of selected sources or large offsets, and keep those alerts as evidence of ongoing operation.
Coverage across hosts: Show that every in-scope system is configured to the approved design, not only the reference servers.
Assessor review: Walk the assessor through the design before testing so the test scope and evidence match.

Confirm with your authorizing body or assessor whether chrony with your chosen sources satisfies SC-45(1) for your system class.

Where SC-45 implementations usually fall short

SC-45 looks simple on paper: keep clocks aligned. In practice, the gaps tend to sit in the layers that inherit time from somewhere else, such as virtual machines, containers and appliances. Each card below names one gap an assessor is likely to find and the check that closes it before the assessment starts.

Virtual machines inheriting drifting host clocks

Guest operating systems often assume the hypervisor keeps time correctly, and some hypervisor configurations let guest clocks drift or jump after a host pause or migration. Audit records from different guests then cannot be lined up reliably. Check that each guest runs its own time client against your internal source, and that the hypervisor's time integration settings are documented and tested after a host reboot or live migration.

Containers without a documented time source

Containers share the host kernel clock, so they have no independent time configuration of their own. Teams often build images without naming which host or service supplies time, and nobody can say where container logs get their timestamps. Check that the platform documentation names the time source for each cluster and that node time synchronization is included in the baseline configuration.

Appliances left on default NTP pools

Firewalls, load balancers, storage arrays and network switches frequently ship pointing at public pool servers. Those devices may log events against a time source the organization never approved, and the setting rarely appears in the system inventory. Check every appliance's time configuration against the approved internal servers, and record the result in the configuration baseline.

No drift alerting

A time source can be configured correctly and still lose sync after a firewall change blocks UDP port 123 or a server is replaced. Without monitoring, the gap appears only when someone tries to correlate an incident and finds timestamps that disagree. Check that each host reports its offset from the authoritative source, and that alerts fire when the offset exceeds a threshold your team defines and documents.

Undocumented authoritative source choice

SC-45(1) requires an authoritative time source where it is selected, and the choice itself must be justified and recorded. Many organizations point clients at a server without writing down why it is authoritative, what it synchronizes to, or who approved it. Check that the system security plan names the source, its upstream references and its owner, and that the description matches the live configuration.

Evidence that is a single screenshot

A screenshot of one server showing synchronized time proves little about the whole system at the moment of assessment. Assessors examine configuration settings, design documentation and audit records, so they expect evidence that covers every component and shows results over time. Check that you can export current configuration and offset data for all in-scope components, and keep the export with the date it was taken.

Questions buyers ask about SC-45 cost, effort and scope

Is SC-45 required if we are not pursuing FedRAMP?

No federal rule makes SC-45 mandatory for every organization. SP 800-53B does not assign SC-45 to the low, moderate, high or privacy baseline, so it applies only when your organization or an authorizing body selects it through tailoring or an overlay. Your contract, regulator or internal risk assessment decides whether it is in scope. Check the requirement language in your agreement, and if a customer or regulator names SC-45 or the SC family, ask them which control version and which enhancements they expect. The control is still a reasonable practice for any system where audit records must line up across components.

Does SC-45 require FedRAMP Class C or D enhancements?

Yes, for FedRAMP Rev5 Classes C and D. FedRAMP's Rev5 baselines require SC-45 and SC-45(1) at those classes, and its annual independent assessment rule requires providers to include SC-45(1) at Classes C and D at least once a year. SC-45(1) concerns selecting an authoritative time source. If you are outside FedRAMP, you choose whether to adopt the enhancement based on your own risk and audit needs. Confirm the current class and rule text in the FedRAMP documents before you scope the work.

How much effort does SC-45 take for an in-house team?

The effort for the base control is usually modest, but it is not zero. Your team must choose time sources, configure every system and device to use them, document the design, and collect evidence that clocks stay synchronized. Effort rises with the number of hosts, network devices, hypervisors, containers, cloud services and applications that write audit records. NIST does not publish a per-control effort estimate, so ask your team to inventory time-dependent components and size the work from that list. A fixed-scope implementation partner can quote the work once the inventory and written scope are agreed.

How long does it take to implement SC-45?

NIST does not set implementation timelines for SC-45 or any other control. It leaves timing to OMB Circular A-130 and to the authorizing or contracting body. Duration depends on how many systems use time, whether a reliable internal or external time source already exists, how much configuration drift you find, and how long evidence must cover before an assessor reviews it. Ask any partner for a written schedule tied to a defined scope, and confirm with your assessor how much evidence history they expect.

Is chrony enough to meet SC-45?

chrony can synchronize a system clock with NTP servers or reference clocks such as GPS receivers, and it can serve time to other computers. It is a strong technical building block, but it does not satisfy the control by itself. An assessor will look at your system design documentation, time configuration settings and audit records, so you still need to document which sources are authoritative, how each system is pointed at them, how drift is monitored, and who owns the configuration. Confirm the behavior and supported platforms for your environment with the chrony project before you rely on it, and check whether your audit platform and cloud services also use the same source.

What does the team need to deliver SC-45 evidence?

You need named owners for the time architecture, the systems that consume time, and the monitoring that detects drift. Platform or infrastructure engineers configure the clients and servers, security staff confirm that audit records carry consistent time stamps, and the compliance lead maps the design to the control and keeps the evidence current. Plan for a reviewer who can explain the design in writing. In a quote, ask the partner to list which roles it covers and which steps your staff must complete.

Can DeployOpen issue a SC-45 certification or audit report?

No. DeployOpen plans, implements, configures and documents self-hosted open-source platforms inside your own infrastructure, and it can prepare systems and evidence for SC-45. Only an independent auditor, assessor or certification body issues assessment reports or certificates. Your organization owns its controls. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope.

How DeployOpen scopes and prepares SC-45 evidence

DeployOpen plans and implements time synchronization inside the client's own infrastructure under a fixed written scope, and it prepares the configuration and evidence an assessor will review. The written scope should name every system whose clocks must align, the time sources they will use, the hosts that serve time to others, and the audit platforms that depend on those timestamps. It should also state who owns each component. DeployOpen does not issue audit reports, attestations or certifications. The organization owns its SC-45 control, and an independent assessor decides whether the evidence supports it.

In practice, the build work usually centers on a small number of hosts running chrony, for example internal NTP servers that synchronize with upstream sources and serve the rest of the estate. The scope should specify the upstream sources, the allowed clients, the firewall rules that permit NTP traffic, and how time settings are kept under configuration management. Whether the client needs the authoritative time source enhancement, SC-45(1), depends on the impact level and any FedRAMP class that applies. Confirm that selection with your assessor and the FedRAMP baseline before work starts, because it changes the design, not only the paperwork.

Evidence is the part teams most often underestimate. Ask the implementation partner to deliver the chrony configuration files, the host inventory showing which systems use which servers, and sample output from synchronization status checks taken at a stated point in time. Log timestamps from the audit platform should also be sampled to show correlation across systems. Each deliverable should be listed in the written scope with an owner and a acceptance check, so the client can confirm, before the assessment, that the evidence matches the configuration that is actually running.

SC-45 System time synchronization