AU-8 Time stamps

AU-8 requires the organization to define the granularity at which audit time stamps are recorded, so the granularity is a value you choose and document, not one NIST fixes. The common failure is leaving it undefined, which means different components write seconds, milliseconds or minutes with no agreed standard. The remedy is to write one granularity into the audit policy and system configuration, for example whole seconds for every host, and then confirm each source writes that precision. Assessors will check that the defined value appears in the audit records they sample. Ask your implementation partner to list every log source and its actual precision during the readiness review.

Logs mix local time without offsets when some systems write local wall-clock time and never record the offset from UTC. AU-8 requires time stamps in Coordinated Universal Time, with a fixed offset from it, or with the local offset included. A bare local time fails all three options because nobody reading the record can tell what moment it describes, especially after a daylight saving change. The remedy is to set every system to UTC for the operating system and log formatting, then verify that application logs use the same format. Where a legacy application can only write local time, record its offset in the configuration and document it as an exception.

Appliance and SaaS logs often arrive with time stamps whose zone is undocumented, so the organization cannot prove they meet AU-8 even when the platform looks correct. The first step is to inventory each third-party source and record its time format in the vendor documentation or a test event, since the vendor's default settings may differ from what you assume. Where a source cannot write UTC or include an offset, normalize the time at ingestion into the central log store and keep the original value. Confirm the behavior with the vendor in writing, because the vendor, not the organization, controls the device's clock settings.

Drift goes unnoticed when hosts synchronize once at build time and nothing checks them afterward, so audit time stamps slowly become wrong. AU-8 depends on internal clocks that are accurate enough to support the defined granularity, which means the program needs a way to see offset problems. Tools such as chrony can report tracking status and offsets from its sources, and those reports can be sent to the central log platform and alerted on. Set a documented threshold for acceptable offset, review alerts on a defined schedule, and keep the query output as evidence that the check ran.

Ownership is often unclear because the network team runs the NTP servers, the platform team runs the hosts, and the security team assumes both are correct. The gap is a missing record naming who operates each time source, who can change it and who responds when it fails. Write that record into the system security plan or the audit policy, listing primary and secondary sources, the responsible role for each, and the escalation path. Assessors interview system administrators about this, so answers should match the written record. Your partner can draft the record, but the organization must assign the roles and approve them.

A time change becomes a problem when someone edits a clock or time server setting directly, outside the change record, so later investigators cannot explain a jump in the logs. Treat time configuration as part of the baseline: keep time server settings in version-controlled configuration, require a change ticket for edits, and log administrative changes to the clock itself. Alert when the system clock is stepped or the time source changes unexpectedly, and compare the alert against open changes. This ties AU-8 to configuration management, so the evidence for both controls can come from the same change records.

Yes. SP 800-53B Release 5.2.0 selects AU-8 for the low, moderate and high security control baselines, so any system categorized at those impact levels needs it. It is not selected for the privacy baseline. Confirm the selection against your system's impact categorization and the current SP 800-53B profiles in OSCAL, because your assessor will check the baseline you claim, not the one you remember. Tailoring can change what is in scope, but the decision and its justification belong in your system security plan.

No. Both numbered enhancements, AU-8(1) and AU-8(2), are withdrawn in SP 800-53 Release 5.2.0, so the base control stands alone. The older clock synchronization requirements no longer appear as separate items to test. Time synchronization still matters, though. Accurate clocks are what make the base requirement credible, and the related control SC-45 covers system time synchronization. Keep your time source design documented so an assessor can connect the two without reading withdrawn text into the current control.

No public figure exists for AU-8 alone, and NIST does not estimate compliance costs. The cost comes from a few components: internal engineering time to configure clocks and log formats, any licensed time or log products, and the independent assessment you commission. Most of the spend is one-time configuration and documentation, with small recurring effort for monitoring clock drift and reviewing settings after changes. Costs rise with the number of systems, heterogeneous platforms and the need for documented evidence across environments. Ask any partner for a written, scope-based quote that separates configuration, evidence preparation and retesting.

Often yes, if your engineers can configure time sources, define the granularity and offset format, and document the result. Open-source components such as chrony can synchronize system clocks and serve time to other hosts, and applications like Nextcloud write audit entries you can inspect. The harder part is evidence: an assessor will examine policy, configuration and design documents, interview administrators and developers, and test the timestamp mechanisms. A partner can prepare systems and evidence in a fixed scope, but only an independent assessor issues the findings. Your team owns the control either way.

No duration is supplied for AU-8, so confirm timing with your assessor and any implementation partner before committing. The main variables are how many systems and log sources need time configuration, whether clock sources are already standardized, how mature the existing audit policy is, and how quickly your team can gather configuration evidence. A single well-documented environment usually moves faster than a mixed estate with several applications, each producing timestamps in its own format. Build a written schedule that includes a retest window after configuration changes.

The work needs named owners, access and information. Identify who administers time services, the platforms that generate audit records, and the policy owner for audit and accountability. Provide system design documentation, current configuration files, your system security plan and the list of systems in scope. Engineers should be available to explain how each application stamps records and how drift is detected. Expect to decide the granularity and time zone format (UTC, a fixed offset or a recorded local offset) and to record that decision. Gaps in these inputs are the most common reason an assessment takes longer than planned.

They usually appear as records that cannot be ordered across systems, as gaps where one host's clock drifted, or as mixed formats that break correlation. Check that every component uses an internal clock source, that the chosen time source is reachable and trusted, and that records state UTC or a stated offset. For example, in an illustrative environment, a firewall logging in local time while an application logs in UTC will make an investigation slow and an assessor's test fail. Verify these behaviors in your own logs rather than assuming they are correct.