03.03.07 Time stamps: requirements and evidence

What 03.03.07 time stamps requires and why assessors check it

When an assessor asks how your audit records are time-stamped, they want to see that every system generates time stamps from its own internal clock, at a granularity your organization has defined, in UTC or with a fixed or recorded offset from UTC. Under 03.03.07, that is the whole requirement, and the hard part is making the answer consistent across every system that writes audit records. The requirement exists so that an investigator can line up an authentication event on one server with a firewall denial and an application error on another and know which happened first.

The organization-defined parameter (ODP) is the decision most teams skip. 03.03.07 has one ODP, the granularity of time measurement for audit record time stamps, and NIST does not assign a value. If no federal agency specifies one, you must, and SP 800-171A Rev. 3 includes a determination statement that checks the value is defined. Write the granularity into your audit and accountability policy or procedures, then confirm that each system's configuration actually produces time stamps at that precision. Common failure points are a clock that is correct to the second but logs to the minute, and a mix of local time zones with no recorded offset. Clock drift is the other risk: a system whose clock has wandered will produce records that look plausible and are wrong. Confirm with your platform team how clocks are synchronized and monitored, and what the synchronization source is.

This requirement carries forward Rev. 2's 3.3.7, which NIST's change analysis classifies as a significant change because Rev. 3 adds more detail and foundational tasks. CMMC Level 2 still uses Rev. 2, so a defense contractor will see the same expectation as AU.L2-3.3.7, worth 1 point under the 32 CFR 170.24 scoring methodology. Ask your assessor which revision governs your contract, since the answer determines which requirement text and assessment procedure they apply. Whatever the revision, the evidence is the same: documented time settings, configuration output from representative systems, and sample audit records showing consistent time stamps.

Which systems and log sources the time stamp rule covers

Requirement 03.03.07 applies to every system that generates or stores audit records for CUI, so the first job is an inventory of those systems. The cards below cover the sources most often missed and the scoping decisions that decide who must answer for their clocks.

Servers and endpoints in the CUI boundary

Every operating system that writes audit records about CUI systems needs a clock that the organization controls. This includes application servers, database servers, domain controllers and administrator workstations. Check that each host syncs to the same time source, that the time zone and offset are set in configuration, and that the audit subsystem stamps records from the system clock rather than from a log shipper's arrival time. Your system security plan should list these hosts by name.

Network devices and firewalls

Routers, switches, firewalls and VPN concentrators often produce the first evidence of a boundary event, and they are frequently configured separately from servers. Confirm that each device uses an NTP source, that its syslog output carries a time stamp in the granularity you defined, and that its offset from UTC is recorded. A firewall whose clock drifts by minutes can make its records impossible to line up with endpoint logs during an investigation.

Cloud services and managed platforms

Cloud control planes, managed databases and hosted identity services write audit logs with their own clocks, and you usually cannot configure the provider's infrastructure. Document which time stamps the provider supplies, in what time zone, and at what precision. Where the provider documents its time behavior, keep that document with your evidence, and ask the provider to confirm the granularity in writing if your ODP value depends on it.

SaaS clocks and shared responsibility

Whether a SaaS provider's clock is in scope depends on whether it generates audit records you rely on for CUI. If the provider's logs are your only record of access to CUI, its time stamps become part of your evidence, and you must be able to explain how they are generated and whether they are UTC or a recorded offset. Where the provider will not disclose this, record the gap in your plan of action and milestones and address it through your contract terms.

Enclave boundaries and log forwarding

When CUI lives in a separate enclave, audit records often leave it through a collector or SIEM, and the collector may sit inside or outside the boundary. Time stamps should be applied at the source, before forwarding, so that a relay delay does not change the recorded event time. Map which systems inside the enclave write records, which collectors carry them out, and where the clock for each collector is set, since a collector outside the enclave can still affect how records are correlated.

Third-party platforms that hold CUI logs

Managed log storage, backup services and outsourced security monitoring may hold copies of CUI audit records even when they do not generate them. Their clocks matter less for generation, but any re-stamping or re-indexing they perform can alter the time order of records. Ask each provider whether it preserves original time stamps on ingest, and confirm that your reduction tools keep the original values, as required for audit record reduction under 03.03.06.

How to implement time stamps for audit records step by step

This sequence turns the 03.03.07 requirement into working configuration: a written granularity, one reference time source, synchronized hosts, a fixed time format in audit records, and evidence that clocks stay aligned over time.

Define the granularity parameter in writing
Start by setting the organization-defined granularity of time measurement for audit record time stamps, the one parameter 03.03.07 leaves to you. The system security plan owner, with the information security lead, records the chosen granularity, the reason it suits your event correlation needs, and who approved it. NIST does not assign this value, so if your federal customer has not specified one, you must. The step is done when the value appears in the policy or procedure document and the assessor can trace it to the requirement.
Select a single authoritative reference time source
Choose one reference time source that every in-scope system will trust, such as an internal NTP server fed by an approved external reference. Document its address, its upstream sources and who administers it. Using one authoritative source keeps timestamps comparable across hosts, firewalls, databases and applications. Confirm with your platform and network teams that the source is reachable from every enclave and that its ownership is written down. The step is complete when the source and its owner appear in the system design documentation.
Synchronize every in-scope host to the source
Configure each in-scope host, including servers, virtual machines, containers' host systems, network devices and logging collectors, to synchronize its internal system clock with the reference source. For Linux hosts that is often chrony, which is licensed under GPL-2.0-only and can act as a client or an NTPv4 server. Apply the configuration through your standard hardening baseline so new hosts inherit it. Verify each host's sync state with the tool's status output and save the results as configuration evidence.
Set audit records to UTC or a fixed offset
Configure each logging component so audit records use Coordinated Universal Time, carry a fixed local offset from UTC, or include the local offset in the time stamp. Examples include application log timezone settings, database timezone parameters and SIEM ingestion rules. Where a platform writes local time without an offset, change it or document an approved conversion. Record the chosen format in the audit record standard so every team applies the same rule. The step is done when configuration exports show the chosen format for each in-scope source.
Verify time stamps with sample audit records
Generate test events on several representative systems, such as a login, a configuration change and a privileged command, then pull the resulting audit records. Check that each record uses the agreed granularity, the agreed time format and an accurate time compared with the reference source. Test an application that writes its own audit log, for example Nextcloud's admin_audit output to audit.log, and an OpenBao audit device, which writes JSON entries for each API request. Keep the sample records and the test results as evidence. Repeat the check after major changes.
Document the time synchronization configuration
Write down the time architecture: the reference source, the hosts in scope, the synchronization software and version, the granularity value, the time format and the owner of each component. Include the procedure for adding a new host and the exception process for systems that cannot sync. Store this with the system security plan and the audit procedures so an assessor interviewing system administrators gets consistent answers. The step is complete when the document matches the configuration you tested.
Monitor clock drift and respond to exceptions
Set up ongoing monitoring of each host's synchronization status and offset from the reference source, and alert the responsible team when a host falls out of sync or drifts beyond the tolerance you documented. Review the results on the schedule your monitoring procedure defines, and log each drift event with its cause and fix. Ask your monitoring vendor or tool owner to confirm which metrics are available. The step closes when alerts are tested, a sample drift report exists and the procedure names who responds.

How an assessor tests 03.03.07 with examine, interview and test methods

The examine method reviews documents, settings and records to confirm that time stamping is defined and configured. For 03.03.07, the assessor reads the audit and accountability policy and procedures, the procedures for timestamp generation, the system design documentation, the system configuration settings, and a sample of system audit records. The question is whether the written design matches what the systems actually produce.

Policy and procedures: Look for a statement that audit records use system clock time stamps, the granularity chosen, and who owns the clock configuration.
Design documentation: Confirm the architecture names the authoritative time source and how each component synchronizes to it.
Configuration settings: Check the time source, synchronization service and time zone or UTC settings on in-scope hosts and devices.
Sample audit records: Compare time stamps across several systems for the same event and confirm they use the documented format and offset.
Consistency: Flag any system whose records show a different format, offset or precision than the documentation states.

Before an assessment, confirm that each document names the granularity value your organization assigned to the parameter and that the sampled records match it.

Evidence that passes a 03.03.07 time stamp review

An assessor testing 03.03.07 Time stamps checks the written decision, the clock configuration, the live status of that configuration, and the audit records it produced. Each artifact below proves a different part of the requirement, so keep them together and refresh them on a regular cycle rather than rebuilding them before each assessment.

Written granularity ODP

03.03.07 has one organization-defined parameter: the granularity of time measurement for audit record time stamps. NIST does not assign this value, so the organization must set it and record it in the audit and accountability policy or the system security plan. Write the chosen granularity, the reason for it, and the approver. Assessors check that the value is defined, because the requirement cannot be met with a blank parameter. Review it whenever the logging scope or correlation needs change.

Time-sync configuration files

Keep the configuration files for each time source under version control, such as the chrony configuration that lists NTP servers or reference clocks and defines the allowed sources. Show that every system that writes audit records points to the approved sources. Assessors will compare these files with the design documentation and the system inventory, so any system missing from the file set is a finding. Record the owner of each file and the date of the last approved change.

Synchronization status output

Capture live output from the time daemon, such as the sources list and tracking report, on a schedule and on demand before an assessment. The output shows which source is selected, the measured offset, and whether the clock is synchronized. Attach a timestamped capture from each audit-producing system class, not one sample from a single host. Stale captures weaken the evidence, so rerun the collection on a fixed cycle and keep the history.

Audit record samples with time format

Export sample audit records from each log source and show the time stamp field. Assessors check that the format matches the approved approach: UTC, a fixed local offset, or an offset recorded in the stamp. Pull records from different systems covering the same event, so correlation across systems can be demonstrated. Use records from the production logging pipeline, not hand-built examples, and note the date each sample was taken.

Drift and offset records

Maintain a log of measured offsets and any alerts raised when a clock drifted beyond the tolerance set in the granularity decision. This record shows that time accuracy is monitored, not assumed. Document each excursion, the cause, and the corrective action, such as a change to a source or a host repair. A clean history with no record of checks is harder to defend than a history that shows detected and resolved drift.

Time-related change records

Retain change tickets for every edit to time sources, time daemon configuration, host images, and logging pipelines that affect time stamps. Each ticket should state the change, the approver, the test performed, and the rollback plan. Assessors use these records to confirm that the configuration shown in the files is the one that has been running. Link tickets to the affected systems so an assessor can trace a single host from change to output.

What meeting 03.03.07 costs in effort and tooling

This table breaks down the cost components of meeting 03.03.07 Time stamps, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to shape a written scope and to know what to request in a quote, since no DeployOpen price is implied.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it
Clock-sync tooling licensing	No license fee for chrony (GPL-2.0-only); cost is staff time to deploy it	One-time setup, recurring patching	Open-source licensing may be zero, so budget goes to engineering and support
Clock source design	Internal engineers or an implementation partner selecting NTP servers or reference clocks such as GPS receivers	One-time	Whether hosts can reach trusted internal or GPS-based time sources, or must rely on external servers
Host configuration across the estate	Platform or systems engineers applying chrony settings to each host and VM image	One-time, then recurring for new hosts	Number of hosts, container base images, and how many OS builds are in use
Log source timestamp verification	Engineers confirming each log source writes UTC or a fixed offset at the defined granularity	One-time per source type, recurring on upgrades	Number of log sources such as Nextcloud audit.log or OpenBao audit devices, and their vendor settings
Defining the granularity ODP	Security or compliance lead, with input from the assessor's expectations	One-time, reviewed periodically	How many systems share one standard versus need separate values
Evidence upkeep	Compliance or operations staff keeping configuration exports, drift reports and sample audit records current	Recurring	Change frequency, drift monitoring, and how often records are sampled
External review and gap check	Independent consultant or partner, if engaged	One-time readiness review, optional repeats	Scope size, number of systems in the boundary, and prior documentation quality
Assessor sampling time	Assessor's time, paid by the organization under the assessment engagement	Per assessment cycle	Number of hosts and log sources the assessor samples, and how easily evidence is produced

Who owns, implements and assesses the time stamp control

Your organization owns requirement 03.03.07 and every decision inside it. Your team has to set the organization-defined parameter for the granularity of time measurement, since NIST does not assign that value and, if a federal agency does not specify it, the nonfederal organization must assign it. Your team also decides whether audit timestamps use UTC or a fixed, recorded offset from UTC, approves the system configuration, and keeps the policy and procedures that govern timestamp generation.

Set the granularity ODP: Record the value you chose, the reason for it, and the agreement or contract that drove it.
Own the clock design: Name the authoritative time sources, the systems that synchronize to them, and who approves changes to that design.
Keep the configuration current: Maintain the configuration baseline for NTP or chrony settings on each in-scope system.
Maintain the evidence: Keep dated configuration exports, time-source status and sample audit records that show the chosen format.
Assign named people: Identify the administrators and information security staff who will be interviewed.

Check that your team can show the ODP value, the policy that references it and a current configuration record for every in-scope system before any assessor arrives.

Common gaps that fail 03.03.07 and how to close them

Assessors who test 03.03.07 usually find the same few gaps: an undefined granularity, clocks that drift unnoticed, mixed time zones with no recorded offset, virtual machines with bad time sources, and cloud services whose time settings are undocumented. Each gap is easy to fix once it is named, and each fix produces evidence an assessor can examine.

No written granularity parameter

The requirement leaves the granularity of time measurement to the organization, so the value must be assigned and written down. Without a defined value, an assessor cannot confirm that the ODP is defined, and the test of whether audit time stamps meet it has nothing to measure against. Record the chosen granularity in the system security plan or the audit policy, name the owner who approved it, and configure the systems to match. Confirm the value with the assessing body if your contract sets one.

Hosts drifting unmonitored

A system clock can drift from its time source for weeks before anyone notices, and audit records from that host then cannot be correlated with others. Check that each host synchronizes with a named time source, that the synchronization daemon is running, and that offset and last-sync status are collected centrally. Alert when a host loses synchronization or exceeds the tolerance in your granularity definition. Keep the alert history, since it is evidence that the clock was checked.

Mixed time zones without a recorded offset

Servers in different regions often log in local time with no offset in the record, so events from two systems cannot be placed in order. The simplest fix is to set the system clock and the logging pipeline to UTC. Where local time must remain, the offset from UTC has to be fixed or included in every time stamp. Test a sample of records from each system and confirm the time zone is visible, so an investigator can reconstruct the sequence.

Virtual machines inheriting bad clocks

Virtual machines can run on hosts whose clocks have drifted, and some hypervisors sync guest clocks with the host instead of a trusted source. Snapshots and restores can also move a guest clock backward. Decide which time source each virtual machine uses, verify it against the hypervisor settings, and check the guest clock after restoring from a backup. Document this in the configuration baseline so that a new virtual machine does not silently inherit a different setting.

Cloud services without documented time settings

Managed cloud services and software as a service products often timestamp events on their own clocks, and their time settings may not appear in your configuration records. Ask each provider how it synchronizes time, which time zone its logs use, and what precision it guarantees. Record the answers in your third-party inventory and your audit record content documentation. Where a provider cannot answer, note the gap in your plan of action and milestones rather than assuming the time is correct.

Time sync service not in the baseline

A time synchronization service that is installed but not configured, or that a hardening change disables, leaves audit time stamps unmanaged. Chrony is one common option that can synchronize from NTP servers or reference clocks and act as a time server for other machines. Whichever service you use, list it in the configuration baseline, check it during change control, and verify its state with a scheduled check. Confirm each product's supported time sources in its own documentation.

Questions buyers ask about 03.03.07 time stamps

Does NIST SP 800-171 require UTC for audit time stamps?

No. The requirement lets you use Coordinated Universal Time (UTC), a fixed local offset from UTC, or a local offset included in each time stamp. What matters is that every system you correlate uses one of these approaches consistently, so an assessor can line up events across hosts, applications and cloud services. Most teams choose UTC because it removes offset arithmetic during investigations, but a documented fixed offset is equally acceptable if your systems and tools already handle it correctly. Record your choice in the system security plan and in the configuration baseline so the assessor can verify it on every audited system.

What does the granularity ODP for 03.03.07 mean, and who sets it?

The organization-defined parameter is the granularity of time measurement for audit record time stamps, such as the smallest unit your records must carry. NIST does not assign the value. When a federal agency or contract does not specify it, the nonfederal organization must define it to complete the requirement, and the assessment checks that the value is defined. The organization sets it through its policy and system security plan, and the value should match what your logging and correlation tools can actually record. A granularity you cannot produce on every system will fail in practice, even if the document looks complete. Ask the contracting agency whether it has published a value before you choose one.

Can we implement 03.03.07 ourselves without outside help?

Often yes, if your team already administers the systems that generate audit records and has time synchronization in place. The technical change is usually small: configure each host and application to use the internal system clock, point it at trusted time sources, and confirm the time zone handling. The harder part is evidence. You need documented procedures, configuration settings that an assessor can examine, and proof that records show the approved format across the whole boundary. Teams without an assessment background often miss how the assessor will test each determination statement. DeployOpen can plan, configure and document the scope in writing before work begins, but it does not issue assessment results. An independent assessor or DCMA DIBCAC determines compliance.

What drives the effort and cost of meeting 03.03.07?

Effort depends mainly on how many systems fall inside the assessment boundary, how many different logging sources feed your audit records, and how much of the environment is already configured to a consistent clock and time zone. Systems that use one time source and one format need little change. Mixed estates, legacy appliances, SaaS platforms with fixed time settings and applications that write their own timestamps add work. Cost components include internal staff time for configuration and testing, any consulting or implementation fee, and recurring checks after patches or new deployments. Ask any provider for a quote that lists the systems in scope, the granularity you have defined, the evidence to be produced and who performs each step.

How does the Rev. 2 requirement 3.3.7 mapping affect CMMC?

CMMC Level 2 still uses the Rev. 2 requirements, so the 03.03.07 requirement appears there as 3.3.7, which CMMC identifies as AU.L2-3.3.7. Under the 32 CFR 170.24 scoring methodology, that practice carries 1 point. NIST's change analysis classifies the Rev. 2 to Rev. 3 change for this requirement as significant because the Rev. 3 wording asks for more detail and foundational tasks. For a defense contractor, your readiness work must satisfy the Rev. 2 practice for CMMC, and it should also address the Rev. 3 wording and the organization-defined granularity if a contract moves to Rev. 3. Confirm which revision your current contract and the DFARS clause name before you scope the work.

What does our internal team need to provide for this work?

Your team needs to supply the people and information that only you hold. That includes a list of systems and applications that generate audit records, administrator access to configure them, the current time sources and time zone settings, your audit and accountability policy and procedures, and the system security plan. You also need an owner who can approve the granularity value and the time source design, and staff who will review the resulting configuration before it changes production. Expect system administrators and developers to be interviewed during assessment, so they should be able to explain how timestamps are generated. Agree these responsibilities in writing before work starts, so that evidence is produced by the people who will maintain it afterward.

Which open-source tools help produce time stamp evidence for 03.03.07?

chrony is a GPL-2.0-only implementation that synchronizes a system clock with NTP servers or reference clocks such as GPS receivers, and it can act as an NTP server for other computers. Its configuration and synchronization status give an assessor examinable evidence that the clock is disciplined to a trusted source. Application logs also matter. Nextcloud's admin_audit app writes additional event information to audit.log, and OpenBao audit devices keep JSON logs of API requests with timestamps. Confirm each product's current time formatting options and granularity in its own documentation before you rely on it, because the assessor will test the records your deployment actually produces.

How DeployOpen prepares time stamp evidence for 03.03.07

DeployOpen works on 03.03.07 Time stamps as part of a self-hosted implementation inside the client's own infrastructure. We prepare the clock configuration, time stamp settings and evidence that an independent assessor can examine, while the organization keeps ownership of its controls and the assessment outcome.

How we scope

Confirm which systems generate audit records and must use the same clock source and time stamp format.
Agree in writing the granularity of time measurement the organization defines for the 03.03.07 parameter.
Record which time zone convention (UTC or a fixed offset) each in-scope platform will use, and who approves it.
Engagements are fixed-scope, with scope, deliverables and timelines agreed before work starts.

How we build

Configure chrony on in-scope hosts to synchronize with the organization's chosen NTP servers or reference clocks.
Set application audit logging, such as Nextcloud admin_audit output, to produce time stamps that match the agreed granularity and offset.
Verify time stamps in sample audit records from each platform and document any deviations found during testing.
Document clock drift monitoring and the steps taken when a host falls outside the defined tolerance.

How we hand over

Deliver system configuration baselines, clock settings and audit configuration files as documented evidence for assessors.
Provide procedures for timestamp generation that explain how the configuration is maintained and reviewed.
Give the organization test records showing sample time stamps, the parameter values in use and the verification method.
Walk the organization's security and operations staff through the evidence so they can answer interview questions.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Re-verify clock synchronization and time stamp output after platform upgrades or changes to the NTP architecture.
Ask your assessor which evidence format they expect before handover, since DeployOpen prepares evidence but does not issue assessment results.
Confirm with the organization's own assessor or contracting agency how the granularity parameter must be defined for its scope.