Timestamps in audit logs are evidence. If your firewall logs an event at 2:15 PM and your endpoint logs malware execution at 2:14 PM, those are clearly related. If the firewall clock is 15 minutes fast and the endpoint is correct, you misread the sequence. Time synchronization is boring but critical. Without it, your entire audit timeline becomes suspect.
AU.L2-3.3.7 requires you to designate an authoritative time source and configure all systems to keep their clocks synchronized to it. This is typically an NTP (Network Time Protocol) server. Your choice of time source matters less than consistency and verification that synchronization is actually happening. This is the foundation for AU.L2-3.3.5 (correlation). Misaligned timestamps make correlation impossible.
What the assessor is actually evaluating
The assessor is checking three things. First: “Do you have a defined authoritative time source?” You should name it. “We use [server name/IP address]” or “We use the U.S. National Institute of Standards and Technology time server at time.nist.gov.” Either is fine as long as it’s documented.
Second: “Are your systems configured to synchronize to that source?” They’ll ask for your time synchronization configuration. This might be a GPO for Windows endpoints, NTP configuration on servers, or a network-wide NTP deployment. Document it.
Third: “How do you verify it’s working?” This is where many organizations fail. They configure time sync once and never check it again. The assessor wants evidence that you monitor or verify synchronization on an ongoing basis. This might be a quarterly check, a monitoring alert if time drift exceeds a threshold, or a log review that confirms recent synchronization.
What a realistic SSP definition looks like
Configuration and synchronization:
- Windows domain-joined endpoints and servers synchronize via Active Directory domain controller, which synchronizes to the authoritative NTP source [specify details]
- Network devices (firewalls, switches, routers) are configured to synchronize to [NTP server IP/hostname]
- Non-domain systems and cloud-based services are configured to use [NTP server/pool]
Time synchronization status is verified [quarterly/semi-annually] by checking system time settings on a sampling of endpoints and confirming that time drift does not exceed [X minutes]. [Specify responsible party] maintains a log of these verification activities. If a system’s time drift exceeds the acceptable threshold, it is immediately resynchronized and investigated for causes.
Audit logs include timestamps with sufficient resolution [specify: to the second, to the minute] to allow accurate event correlation and investigation. All systems use the same time format [specify: UTC with timezone offset, local time with timezone indicator, etc.] for consistency across logs."
The specifics matter: the source is named, configuration method is documented, verification process is defined.
How to present your evidence
- Authoritative time source documentation (NTP server address/details)
- System configuration showing time sync (GPO, NTP configs, cloud settings)
- Verification records from current assessment period
- NTP status reports showing recent synchronization
Prepare three straightforward elements:
Time source documentation. Identify your authoritative time source. Document it. If it’s internal, provide details on the server, its configuration, and how it maintains accuracy. If it’s external (public NTP pool, NIST server), document the address and your rationale for choosing it.
System configuration showing time sync. This varies by environment but should include documentation like:
- Active Directory Group Policy Object settings for Windows domain sync
- NTP configuration files for servers (/etc/ntp.conf on Linux, for example)
- Network device configurations (firewall, switch settings)
- Cloud service time zone and NTP settings if applicable Screenshots of time settings from a few representative systems work.
Verification records. Show that you’ve checked time synchronization. This might be a log of quarterly checks, NTP status commands run on key systems showing recent synchronization, or a monitoring report showing time drift metrics over time. Include at least one verification from the current assessment period.
Common failures
No defined authoritative source. You configure systems to sync but don't identify what they're syncing to. Or different systems sync to different sources, creating inconsistency. Define one authoritative source and synchronize everything to it.
Time sync configured but never verified. You set up NTP configuration months ago and never checked if it's working. Systems could have drifted significantly. Verify at least quarterly that synchronization is active and drift is acceptable.
Clear time format and resolution across logs. All audit logs use the same time format (UTC with timezone offset is preferred for clarity). Timestamp resolution is fine enough for correlation (to the second, not to the minute).
Monitoring for time drift. You have an alert that fires if a system's time drifts too far from the authoritative source. When the alert fires, you investigate and resynchronize.
If you use an MSSP
Your MSSP should synchronize their own systems and monitoring infrastructure to a reliable time source. If they’re collecting logs from your systems, they need to preserve your timestamps (not overwrite them) so that correlation between your logs and their analysis is accurate. Ask your MSSP how they handle timestamp preservation and time synchronization in their infrastructure.
Your MSSP’s responsibility is to maintain accurate time in their systems and preserve the timestamps from your logs. You remain responsible for ensuring your own systems are synchronized to your authoritative time source. Both must be in sync for correlation and investigation to work properly. A good MSSP documents their time source and can demonstrate that timestamps are preserved during log ingestion.
Request confirmation that your MSSP has defined an authoritative time source and configured their infrastructure to use it. Ask specifically how they handle timestamps when ingesting logs from your systems. They should preserve original timestamps and only add their own metadata timestamps. In the assessment room, you can reference your MSSP's time synchronization if they're collecting logs on your behalf.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Q&A: What the assessor asks
Disclaimer: This guide is educational and not official CMMC documentation. Always refer to NIST SP 800-171 and the official CMMC Assessment Guide for authoritative requirements. Individual assessment results depend on implementation details specific to your organization.