Multi-Clock Incidents

A serious AI incident at a German Landesbank in 2026 triggers five regulator clocks at the same instant the incident is detected. The GDPR Article 33 clock starts ticking toward a 72-hour deadline. The EU AI Act Article 73 clock starts ticking toward a 2-day initial notification. The DORA Article 19 clock starts ticking toward a 4-hour initial filing. The NIS2 Article 23 clock starts ticking toward a 24-hour early warning. The CRA Article 11 clock, if a vulnerability is implicated, starts ticking toward a 24-hour vulnerability notification. Five different deadlines, five different regulators, five different report formats — running in parallel from the same detectedAt timestamp.

Most compliance tools treat an incident as a ticket with a single deadline field. Adjudon does not. The Multi-Clock Hub treats each regulator's deadline as its own first-class object — an IncidentClock — with its own staged checkpoints, its own applicability reason, and its own status independent of the others. This page explains why the model is shaped that way, how the five standard clocks are computed, and what the dashboard does with them.

The integration surface is documented at POST /incidents; the regulator-specific deep-dives live at compliance/dora, compliance/eu-ai-act, and compliance/medtech.

Why one clock isn't enough

The 72-hour GDPR clock and the 4-hour DORA clock are not substitutable. The AI Act 2-day initial notification and the NIS2 24-hour early warning are not the same artifact — the recipient is different, the format is different, the legal consequence of missing one is different. A single "incident deadline" field forces the operator to either pick the strictest clock and stress everyone, or pick the average and miss something. Both are wrong.

The Multi-Clock Hub solves the modelling problem by storing each regulator deadline as a separate document. One incident document owns up to five IncidentClock documents. Each clock owns an array of checkpoints — the staged sub-deadlines a regulator imposes — with deadlineAt, completedAt, completedBy, and an evidenceTraceId cross-link. The dashboard reads the clocks side-by-side and shows the operator a single Hub view of every breath-holding deadline against the same wall clock.

A clock has four states: active — ticking; paused — operator-suspended (e.g. a regulator has acknowledged an extension); completed — every checkpoint is completedAt-stamped; breached — one or more deadlineAt passed without a completion. A breached clock does not auto-resolve; the regulator must be notified out-of-band and the operator records the breach in the audit log.

The five standard clocks

Every clock is created from a regulator template. The templates are not editable per-org — they are the regulators' deadlines, not the customer's policy.

Regulator	Article	Checkpoints (offset from `clockStartedAt`)
GDPR	Art. 33	72 h — Notify supervisory authority
EU AI Act	Art. 73	2 d initial provider/market notification · 10 d authority notification · 15 d final root-cause report
DORA	Art. 19	4 h initial notification · 72 h intermediate report · 30 d final report
NIS2	Art. 23	24 h early warning · 72 h incident notification · 30 d final report
CRA	Art. 11	24 h vulnerability notification · 72 h advisory publication · 14 d patch availability

The offsets are exact and ship with the engine (incidentClockService.js:17-56). The clockStartedAt is by default the incident's detectedAt timestamp; an operator filing late can pass an earlier value to start the clocks at the actual detection moment, which is what the regulator counts. Falsifying detectedAt to dodge a deadline is a separate audit-log offence — the createdAt on the audit entry preserves the truth of when the operator told Adjudon the incident existed.

Anatomy of a clock

   ┌─────────────────────────────────────────────────────────────┐
   │  IncidentClock                                              │
   ├─────────────────────────────────────────────────────────────┤
   │  regulator:        'dora'                                   │
   │  articleRef:       'Art. 19'                                │
   │  clockStartedAt:   2026-05-06T08:42:11Z   ← detectedAt      │
   │  applicabilityReason:                                       │
   │    "ICT incident affecting trading-pricing model;           │
   │     critical-or-important function under DORA Annex II"     │
   │                                                             │
   │  checkpoints[]:                                             │
   │    [0]  Initial notification    +4h   completed 11:01Z     │
   │    [1]  Intermediate report    +72h   ──── deadline ⏰     │
   │    [2]  Final report           +30d   pending             │
   │                                                             │
   │  nextCheckpointAt: 2026-05-09T08:42:11Z   ← live UI badge   │
   │  finalDeadlineAt:  2026-06-05T08:42:11Z                     │
   │  status:           'active'                                 │
   └─────────────────────────────────────────────────────────────┘

applicabilityReason is the field that earns the clock's existence. A blanket "spawn five clocks for every incident" policy would create false-alarm fatigue and would itself be evidence of bad governance — the regulator wants to see why DORA applied to this incident, not just that DORA was checked. The dashboard exposes a free-text applicabilityReason per clock; the Incident Hub renders it inline next to the regulator badge.

evidenceTraceId (per checkpoint) is the cross-link to the DecisionTrace or filing artefact that completed the checkpoint. On the Hash Chain, the trace's chainHash and the incident checkpoint's completion together form a tamper-evident record: "checkpoint X was completed at time Y by user Z and the work product is permanently anchored at sequence N."

What the Hub does with parallel clocks

The Multi-Clock Hub UI is a single view of every active clock across the org, sorted by nextCheckpointAt ascending. The soonest-due deadline lights up red. A clock entering breached state stays at the top of the list until the operator records the breach narrative; a clock entering completed falls to a collapsed-by-default lower section. The dashboard never silently hides a clock; an operator who asks "how many open regulator deadlines do we have right now?" gets an exact integer.

The compound index (organizationId, status, nextCheckpointAt) is what makes the Hub view sub-100ms even for orgs with hundreds of historical incidents; the active clocks are an O(active) read, not an O(historical) one.

What this is NOT

Not a single deadline field. Each regulator clock is a first-class object with its own checkpoints, its own status, and its own audit trail. Forcing five regulators into one incidentDeadline field is a category error this model refuses.
Not auto-filing. The Hub computes deadlines and tracks completions; it does not transmit reports to regulators. Filing the GDPR Article 33 notice with the supervisory authority, the DORA Article 19 notification with the lead competent authority, or the NIS2 Article 23 early warning with the CSIRT remains the operator's responsibility — with a regulator-specific format, recipient address, and authentication mechanism that Adjudon does not impersonate.
Not a SIEM replacement. The incident is created from a SIEM ticket reference (externalRef), a manual operator entry, or a cross-link from a flagged trace. Adjudon does not replace detection; it manages the clocks that start once detection has happened.
Not configurable offsets. A customer cannot edit the GDPR Article 33 clock to "96 hours" because that is not what the regulation says. The regulator templates are read-only; the applicability decision is the configurable part.
Not regulator advice. The applicability checklist on the Incident Hub is a structured prompt to help the operator decide whether DORA / NIS2 / CRA apply to this incident; it is not a legal opinion. Mis-classifying an incident's applicability remains the operator's exposure.

Regulator mapping

Regulator surface	What this concept satisfies
GDPR Art. 33	Personal-data breach notification — 72-hour clock with completion evidence cross-linked to the originating trace
EU AI Act Art. 73	Serious-incident reporting for high-risk AI systems — staged 2 d / 10 d / 15 d cadence with provider, authority, and root-cause artefacts
DORA Art. 19	ICT-related incident reporting for financial entities — 4 h / 72 h / 30 d cadence; particularly load-bearing for DACH banks
NIS2 Art. 23	Significant-incident notification for essential and important entities — 24 h / 72 h / 30 d cadence with CSIRT addressee
CRA Art. 11	Active-exploit and vulnerability-disclosure obligations for products with digital elements — 24 h / 72 h / 14 d cadence
ISO 42001 §9.2	Internal audit — the breached/completed clock history feeds the management-review evidence pack

How a clock is started in practice

When an Incident is created with regulators: ['gdpr', 'dora'] and detectedAt: 2026-05-06T08:42Z, the engine fires createClocksForIncident() and writes two IncidentClock documents back-to-back. The GDPR clock has one checkpoint at +72h. The DORA clock has three checkpoints at +4h, +72h, +30d. The Hub UI badge reads nextCheckpointAt — the soonest of the two clocks' soonest-open checkpoints — which on this incident is the DORA 4-hour initial notification at 12:42Z the same day. Three hours and fifty-eight minutes later, the badge is red.

That is the entire point of the Multi-Clock Hub: a Compliance Officer opens the dashboard at 11:30Z, sees a red 4-hour DORA badge, files the initial notification at 12:00Z, and stamps the checkpoint completedAt: 12:00Z with the filing reference in evidenceTraceId. The next badge becomes the GDPR 72-hour clock, which is now the ranking deadline. The clocks shift, the work shifts; nothing is forgotten.

Why one clock isn't enough​

The five standard clocks​

Anatomy of a clock​

What the Hub does with parallel clocks​

What this is NOT​

Regulator mapping​

How a clock is started in practice​

See also​