For every candidate source, preserve the raw event time and the receipt time. Keep the original timezone or UTC offset, record what clock produced the value and note any known skew. Add a separate UTC-normalised value instead of replacing the original. Then link the chosen awareness instant to the evidence rows, decision owner and any dissent.
That record answers a narrow question: where did this time come from? It doesn’t decide the legal threshold or calculate the reporting windows. The clock-start guide owns those decisions. If the underlying facts are still disputed, use the conflicting-signals workflow first.
Build a source-clock ledger
Create one ledger row for every artefact that supplies a candidate time. Keep each raw event time beside the later receipt or ingestion time, and don’t reduce several timestamps to one value during intake. The row should preserve enough source and clock context to explain every later conversion or correction. It contains:
- a source name and immutable evidence locator
- the event time generated by the source
- the time your system received or ingested it
- the original format, timezone and numeric UTC offset
- a separate UTC-normalised value
- the clock source, synchronisation status, precision and any known skew
- the artefact custodian and collection time
- any conversion, correction or other transformation
Security logs can carry an event time and a later logging or receipt time. OWASP’s logging guidance names both. Google Cloud’s LogEntry schema likewise separates the event timestamp from the receiveTimestamp. NIST warns that inaccurate clocks can make events from different hosts appear in the wrong order.
An alert may be created on one system, relayed by another and turned into a ticket by a third. Those systems answer different timing questions, so compare the raw source time with the later receipt or ingestion time before selecting a value.
| Artefact | Raw event time | Receipt or ingestion time | What the row establishes |
|---|---|---|---|
| Saved email | 2027-03-03T14:05:12+02:00 | 2027-03-03T12:05:19Z | The message’s stated time and the receiving system’s time |
| Support ticket | none supplied | 2027-03-03T12:07:03Z | When the ticket system accepted the item |
| SIEM event | 2027-03-03T12:04:58Z | 2027-03-03T12:06:11Z | The source event time and later ingestion time |
These are sample values, not a rule for choosing awareness. Keep each value with its meaning. A ticket creation time shouldn’t overwrite an earlier email-header time. A source event time shouldn’t be treated as exact when its clock quality is unknown.
Keep raw and UTC values
Keep the source value unchanged and add a separate UTC value rather than substituting one for the other. RFC 3339 gives a standard form for Internet timestamps and uses numeric offsets from UTC. OWASP recommends ISO 8601 dates with a UTC offset, while NIST accepts UTC, a fixed local offset or an included local offset.
For example, 2027-03-03T14:05:12+02:00 converts to 2027-03-03T12:05:12Z. The first value preserves what the artefact said. Use the second value when comparing sources on one scale.
If the offset is missing, don’t infer one silently. Mark the value as unqualified, record the basis for any later interpretation and keep the unmodified source. When a source supplies only a timezone name, preserve that value and document any conversion separately.
Record clock quality first
Record clock quality before using two logs to order events. Capture enough detail to show which reference clock the source used and whether its timestamp can be compared with another system’s time. The row should state the following five fields whenever they’re available:
- the reference clock or time service
- the last known synchronisation status
- a measured offset, if one is available
- the timestamp’s precision
- a confidence note when synchronisation can’t be verified
NIST describes how an inaccurate host clock can reverse the apparent order of events across logs. OWASP therefore recommends measuring the offset or recording confidence when devices cannot be synchronised. RFC 3339 also requires systems with unqualified local time to use a mechanism that ensures correct synchronisation with UTC when they depend on Internet time exchange.
Suppose a source log says 14:07:05Z, while a gateway says it received the event at 14:06:52Z. Don’t delete either value to make the sequence look tidy. Record any verified source-clock offset and add a derived, corrected value with the method and reviewer. If the skew can’t be established, preserve the conflict and lower the confidence instead.
Reconcile without rewriting
Put the approved awareness instant in its own decision field instead of rewriting any ledger row. Link the selection to exact evidence rows, preserve the approval-action time separately, and record every competing value or dissent. The decision field should show:
- the chosen UTC instant
- the legal trigger and reporting track
- the reviewer and approval-action time
- why those evidence rows support the instant
- any competing value and the reason it was not selected
- any reviewer dissent or unresolved clock issue
The approval action may happen after the chosen instant. Preserve both. A later button press is an administrative event; it shouldn’t replace the earlier awareness time established by the evidence.
When a reviewer changes the selected time, append a correction. State the old value, new value, reason, evidence and author. The original ledger rows and earlier decision remain available.
Preserve each source artefact
For each timestamp, preserve the artefact that produced it. Keep the original source, the native export or saved message, an integrity hash where appropriate, the custodian, the collection time and every transfer. When possible, use a working copy for analysis so the recorded source stays unchanged.
NIST says to document the original source and protect its integrity. Its guidance includes hashes as one way to do that. CISA describes chain of custody as a record of who handled an asset, when it was collected or transferred and why. AWS says to keep evidence in read-only stores. It also recommends automatic collection records and analysis on exact copies.
Apply those controls in proportion to the case and your legal obligations. Don’t place secrets or personal data in a broadly visible ledger merely to make the timestamp complete. The ledger can point to protected evidence rather than copying it.
Pass the approved instant forward
After approval, pass the selected UTC instant and its decision reference into the separate deadline control. Don’t recalculate a reporting window inside the source-clock ledger. This handoff should carry only the approved input and traceable reference, leaving deadline logic to the workflow that owns it.
ActLume keeps the documented awareness instant separate from the declaration action time. It preserves awareness history as append-only entries and passes the approved UTC value into deadline controls. The same record feeds copy-assist for the ENISA Single Reporting Platform. It sends one value at a time while a human signs in, reviews it and submits it in the portal.
For continuity after the clock decision, use the reporting evidence trail and the stage-handoff packet. If Article 14 isn’t triggered, use the separate negative reporting-decision record.
Legal counsel should review difficult cases. This article explains an evidence-recording method; it isn’t legal advice.