The incident clock needs a submission path

Incident reporting plans often begin with a deadline and a template. The clock actually depends on when the organization detects an event, recognizes its relevance, gathers enough facts to classify it, finds an authorized reporter, protects sensitive material, reaches the receiving authority, and confirms receipt. Failure in any link can consume the reporting window while the incident team believes someone else owns the submission.

The Commission's GPAI guidance page identifies serious-incident reports among documents providers can submit to the AI Office through EU SEND. The AI Act establishes additional duties for providers of general-purpose AI models with systemic risk. The operating lesson is to connect incident response to the actual protected submission route before an event.

Define the clock trigger and evidence threshold with the responsible legal owner. Security telemetry can indicate an anomaly without establishing reportability. Legal review can clarify scope without delaying containment. The system should preserve both times: first relevant observation and the later classification decision, including why the organization did or did not treat the event as reportable.

Rehearse the whole route

The exercise should begin with a realistic signal, not a completed report. Route it through triage, model and release identification, consequence assessment, executive and legal escalation, evidence minimization, document preparation, identity verification, submission, acknowledgement, and follow-up. Measure handoffs and waiting time, not only writing speed.

Prepare for partial facts. Early reports may contain uncertainty, changing impact, or competing explanations. Use explicit confidence and evidence cutoffs. Preserve updates as linked versions rather than replacing the initial account. The receiving authority and the organization should be able to see what changed and why.

The reporting clock is governed by the slowest unowned handoff, not the speed of the incident template.

Confidentiality and integrity need engineered handling. Identify approved storage, access roles, redaction rules, signing or authentication requirements, transmission limits, and retention. Do not copy sensitive model, vulnerability, or customer information into an ordinary ticket merely because the incident bridge needs a checklist.

Fallbacks matter. The primary submitter may be unavailable, credentials may expire, the platform may fail, or the incident may occur outside business hours. Define alternates, protected contact information, and an evidence-preserving queue. Test the fallback without sending a false report to the authority.

Close the exercise with acknowledgement and obligations. Confirm that the submission was received, identify requested follow-up, preserve the exact transmitted artifact, and maintain a schedule for updates and corrective actions. A sent email or uploaded file is not yet a completed reporting process.

Make the obligation operational

Begin with the detection-to-classification-to-protected-submission route, clock triggers, authorized reporters, fallbacks, and acknowledgement state for serious incidents. Express it as a control object rather than a policy summary: scope, triggering condition, applicable system or model version, permitted exception, effective time, evidence source, and the consequence when the control cannot establish compliance. This lets engineering, product, legal, and operations examine the same boundary without pretending their responsibilities are interchangeable.

The minimum receipt should retain first observation, model and release identity, classification rationale, evidence cutoff, approvals, transmitted artifact hash, channel receipt, follow-up, and corrective-action links. Keep the record proportionate and protect confidential information, but make it possible to determine which rule, artifact, system version, and accountable decision governed the event. A folder of undated screenshots may show that work occurred; it rarely proves that the operative control held for the affected release.

Test the implementation by starting from ambiguous after-hours signals, unavailable approvers, partial facts, sensitive attachments, expired credentials, and a simulated platform outage without transmitting a real report. Include ordinary cases, boundary cases, degraded dependencies, and known exceptions. Preserve the starting state, observed output, machine-readable evidence, user-visible result, and any human intervention. Re-run the test after changing a model, content pipeline, interface, standard, provider, or policy interpretation.

The serious-incident reporting owner with security response and legal should decide whether the evidence supports continued operation, a narrower scope, a compensating control, or a hold. The owner needs authority over the affected release and access to the evidence. Record unresolved interpretation separately from a technical defect so an engineering patch does not masquerade as a legal conclusion.

Monitor both presence and effectiveness. A marker can exist but be stripped downstream. A disclosure can render but arrive after exposure. A document can be submitted but refer to an obsolete model. Pair a control-presence measure with a consequence or comprehension test, give the claim a review date, and reopen it when a dependency changes.

Maintain a dependency register for the control. Model endpoints, editing pipelines, content formats, user interfaces, identity services, submission portals, vendors, and external standards can change the evidence without changing the policy text. Name which changes invalidate the last test and which monitoring signal proves that the dependency remains inside the reviewed state.

Exercise the exception path as carefully as the ordinary path. Record who can invoke it, which facts they must supply, how long it lasts, what capability or distribution is reduced, and which compensating evidence remains. An exception without expiry and re-entry criteria becomes a second operating model that can silently outlive the reason it was approved.

Keep public and executive claims no broader than the tested boundary. Say which systems, releases, formats, routes, and dates the evidence covers, and identify material exclusions. When a control fails or a dependency moves, update the claim and the remediation record together. A transparent limitation protects more credibility than a universal statement built from a narrow passing test.

— Dispatches · Summit Cognitive