Each Clock Starts at Its Own Trigger

In AI Assurance — a separate training in this series — the clock is one you set: the valid-through date on a decision you signed. This one someone else started. The applicable authority defines the binding party and trigger, and the applicable party records that trigger’s instant. It may be a determination, discovery, materiality decision, completed evaluation, awareness, payment, identification, or the event itself.

Before the detail — Artifact: the record’s determination entries, sourced from a calculator that refuses to run on a fact it cannot source. Status: binding where the cited regime applies; reusable guidance elsewhere.

Prompt first: draft the determination entry, not the deadline

Here is what we know so far [paste: what happened, when detected,
what has and has not been decided]. Here is our reporting-obligation
profile [paste the facts block counsel maintains].

Draft ONE determination-entry row for record section 5, question:
"{{the specific determination, e.g. is this a reportable cyber
security incident}}"
  - trigger family: determination | discovery | materiality |
    evaluation | awareness | payment | identification | other
  - instant: has this actually happened yet, or not
  - made by: who is authorized to decide, not who is paged
  - facts relied on: quote only what I pasted
  - outcome: yes, no, or NOT YET DECIDED - never guess "probably no"

If the instant has not happened, write "not yet" and compute no
deadline - a different finding from not-yet-due, and from silence.

One event, several clocks, none of them starting where you’d guess

Three deadlines, two trigger instants: the one-hour and seven-day major-incident duties run from the agency’s determination; the 72-hour uncharacterized-event escalation runs from when the investigation opened. Detection starts none of them — miscounting which instant a clock shares is how a team finds a blown federal clock only in an audit.

Trigger families, not one clock

The calculator groups obligations by trigger family because the start instant is load-bearing; binding party, applicability, modality, recipient, and required content remain separate fields. The locked families are determination, discovery, materiality, evaluation, awareness, payment, and identification; an other row must name its own timestamp key.

• determination — FISMA (the federal major-incident reporting regime), per M-25-04’s footnote 42: the hour runs from determination, “not just the detection.” fisma-major-cisa-1h (1 hour, CISA and OMB) and fisma-major-congress (7 days, Congress) share that determined_at instant; root cause is not required in the seven-day report. NERC CIP-008’s Reportable Cyber Security Incident clocks share this family.
• discovery — DFARS 252.204-7012 (Defense contract clause, 72 hours, only if present) and HIPAA (health-privacy law, 60-day breach duty)
• materiality — the SEC’s Item 1.05 disclosure, from a determination about investors, not systems
• evaluation — a completed reportability evaluation under FedRAMP’s RFC-0031 (the federal cloud-authorization program’s incident-communications rules, effective 2026-07-04), neither detection, determination, nor discovery
• awareness — the EU NIS2 early-warning row, shown only as published; does not apply to Meridian
• payment — the pending critical-infrastructure rule’s proposed ransom-payment clock, not in force
• identification — the California Public Utilities Commission’s outage-notification clock

Meridian can be compliant and late on one event: meeting a discovery-triggered clock does not meet a determination-triggered one on a different instant.

Here is the calculator’s own table for a meter-data exposure scenario, regenerated verbatim:

$ python3 clocks/reporting_clocks.py --scenario meter-data --include-unverified --md

> **4 of 11 rows below are NOT verified.** They are printed because `--include-unverified` was passed. Their confidence is in the last column and their source entry in `sources.json` says why. Do not put an unverified row in front of a regulator, a customer, or a learner.

| Due (UTC) | Clock | Window | Trigger family | The authority's trigger | Modality | Owner | Recipient | Source | Confidence |
|---|---|---|---|---|---|---|---|---|---|
| 2026-10-29T07:14:00Z | Electric emergency incident report (Normal Report) | 6 hours | `other` -> `occurred_at` | Normal Report criteria 10-13, due within 6 hours of the incident | must | system_operations_duty_manager | DOE | `doe-oe-417` Normal Report schedule, criteria 10-13 (criterion 12: loss of electric service to more than 50,000 customers for one hour or more) | verified |
| 2026-11-03T09:47:00Z | Major incident notification to CISA and OMB OFCIO | 1 hour | `determination` -> `determined_at` | notify CISA and the OMB Office of the Federal Chief Information Officer within one hour of the DETERMINATION that an incident is a major incident | must | agency_soc_duty_officer | CISA and OMB OFCIO | `omb-m-25-04` p.16, fn.42: the hour runs from the determination, 'not just the detection' | verified |
| 2026-11-03T09:47:00Z | Reportable cyber security incident (initial) | 1 hour | `determination` -> `determined_at` | One hour after the determination of a Reportable Cyber Security Incident | shall | compliance_duty_officer | E-ISAC and the CISA successor organisation | `nerc-cip-008-6` R4 Part 4.2 | verified |
| 2026-11-06T07:15:00Z | Uncharacterized event escalation to CISA | 72 hours | `other` -> `investigation_started_at` | events that have been under investigation for 72 hours without successful determination of the event's root cause or nature (i.e., malicious, suspicious, benign) | must | agency_soc_duty_officer | CISA | `omb-m-25-04` p.16 | verified |
| 2026-11-09T11:20:00Z | Material cybersecurity incident disclosure | 4 business days | `materiality` -> `materiality_at` | within four business days after the registrant determines that it has experienced a material cybersecurity incident | must | general_counsel | SEC (Form 8-K Item 1.05) | `sec-8k-item-105` 17 CFR 229.106; Form 8-K Item 1.05; Rel. 33-11216 | secondary |
| 2026-11-10T08:47:00Z | Major incident report to Congress | 7 days | `determination` -> `determined_at` | a reasonable basis to conclude that a major incident has occurred | must | agency_cio | named Congressional committees, OMB and the agency Inspector General | `omb-m-25-04` Reporting Major Incidents, pp.19-20; 44 U.S.C. 3554(b)(7)(C)(iii)(III) | verified |
| 2026-11-10T08:47:00Z | Reportable cyber security incident (supplement) | 7 days | `determination` -> `determined_at` | Provide updates, if any, within 7 calendar days of determination of new or changed attribute information required in Part 4.1 | shall | compliance_duty_officer | E-ISAC | `nerc-cip-008-6` R4 Part 4.3 | verified |
| 2026-12-03T07:25:00Z | State breach notification, example state A | 30 days | `discovery` -> `discovered_at` | as soon as practicable and not later than 30 days after discovery (stylised) | shall | privacy_officer | state attorney general | `tx-bus-com-521-053` modelled loosely on Tex. Bus. & Com. Code 521.053 as amended by SB 768 | secondary |
| 2026-12-18T07:25:00Z | State breach notification, example state B | 45 days | `discovery` -> `discovered_at` | within 45 days of discovery (stylised, mid-range) | shall | privacy_officer | state attorney general | `iapp-state-breach-chart` chart updated 2026-05-27; state clocks range roughly 30 to 90 days | secondary |
| **NOT IN EFFECT** | Covered cyber incident report | 72 hours | `other` -> `reasonable_belief_at` | reasonable belief that a covered cyber incident has occurred (proposed) | must | compliance_duty_officer | CISA | *(the pending critical-infrastructure rule's 2024 NPRM, RIN 1670-AA04 - named in 4.2)* | pending |
| **NOT STARTED** | CISA report (federal civilian agency incident) | 1 hour | `identification` -> `identification_at` | incident identified by the agency CSIRT, SOC or IT department | must | agency_soc_duty_officer | CISA Central | `cisa-fing` Federal Incident Notification Guidelines; duty incorporated by reference at OMB M-25-04 p.16 | unverified |

The SEC row is secondary, shown only as published. The first row is a deliberate applicability challenge, not an overdue filing: it surfaces for any electric utility, while the real form needs criteria 10-13 the facts here do not establish — argue it off before treating its date as a duty. Two rows share 2026-11-10T08:47:00Z from one determined_at instant but answer different regimes; a shared deadline is not one obligation.

The determination entry: a decision, not a state

1.4’s record — one document, ten sections — stores a determination as a section-5 entry: criteria, instant, decider, evidence, outcome, source — never a status the incident passes through. A negative determination is load-bearing: it records the triggering condition was not met, so the clock never started; it does not stop one already running, and “we considered it and it did not apply” is a finding a regulator can read where silence is not.

The substrate’s worked example makes three such calls on one event, all negative, all dated, all made by someone not mitigating anything: reportable cyber security incident (no — no compromised system in scope), covered under the pending critical-infrastructure rule (not applicable, and not in force), material for the Securities and Exchange Commission (no — one workflow, a working fallback). Each names its trigger family, so a reviewer checks the entry against the calculator rather than a memory of the meeting.

The calculator refuses to guess

Verified and pending rows print by default; secondary and unverified rows require --include-unverified. An unresolved rule_source fails --lint; a pending row prints NOT IN EFFECT with no deadline, which the next lesson names. An unsourced deadline is a rumor with a number in it.

The test suite proves what one --detected timestamp could not: one event, discovery at 02:25 and determination 82 minutes later at 03:47, land on different deadlines, as they must. Move only the determination timestamp six hours later and the discovery-triggered deadline does not move, while the determination-triggered one shifts exactly six hours.

Stop and escalate when a trigger instant is MISSING or CONTESTED. Do not compute from a guess, and do not infer the legal trigger never occurred just because its timestamp is absent. The clock desk routes it to counsel or the named risk acceptor, who bounds risk from the earliest defensible instant until resolved.

Key takeaway

A reporting clock starts at the instant its own authority names — determination, discovery, materiality, evaluation, awareness, identification, or a still-pending payment trigger — never at detection. A determination is a dated, attributed decision entry, not a state the incident passes through; a negative one is worth recording as carefully as a positive one. Next: which of these clocks reaches a vendor that is not an agency.

LEADERSHIP DECISION   name a clock owner, separate from whoever
                      is mitigating, before the first page
PRACTITIONER ACTION   record every determination as a dated entry
                      with trigger family, decider, evidence; run
                      the calculator before drafting any notice
SUCCESS MEASURE       zero deadlines computed from a guessed or
                      unsourced trigger - calendar time held