NovaMind reframes breach disclosure as system design

1. Straight Answer

A thousand breaches in, and the gap between compromise and disclosure is widening, not closing. The median time to detect a breach sits around 200 days. The median time to disclose it, once detected, has stretched further - often 60 to 90 days beyond what regulation technically allows, and sometimes longer when legal counsel runs the clock. The breach is no longer the failure event. The disclosure lag is.

This matters because the damage curve has shifted. Stolen credentials get sold within hours. Attacker dwell time inside connected systems compounds while internal teams are still drafting the first version of a holding statement. Customers learn from a journalist, a Have I Been Pwned email, or a regulator’s filing - not from the company holding their data. By the time disclosure happens, the operational window to actually protect anyone has closed.

The fix is not another SIEM, another EDR, or another threat intel feed. The fix is treating incident disclosure as a system you design before the incident, not a crisis you negotiate during one. Most organisations have invested heavily in detection and almost nothing in the structured pipeline that turns a confirmed incident into clear, timely, accurate communication. That imbalance is the actual vulnerability.

2. What’s Actually Going On

Incident response, as it exists in most companies, is a coordination problem dressed up as a security problem. When something hits, the work splits across security, legal, comms, executive leadership, customer support, regulators, and often a board sub-committee. Each function has different incentives, different risk tolerances, and different definitions of what “confirmed” means. Security wants to contain. Legal wants to limit exposure. Comms wants control of the narrative. Executives want to know what to say to the board on Monday. Nobody owns the disclosure pipeline end-to-end, because it cuts across all of them.

The result is a serial process where every stage waits on the previous one. Forensics writes a draft timeline. Legal redlines it. Comms rewrites it for tone. An executive holds it for another 48 hours pending a board call. Then regulatory filings get drafted against the now-stale facts, and customer notification waits behind the regulatory clock. Each handoff is a manual reformatting of the same underlying facts into a different audience’s language. There is no shared source of truth, no structured schema for what an incident actually is, and no pipeline that propagates updates as the picture changes. Everything is a Word document and a Slack thread.

Layer on top of that the operational reality that most incident response runbooks were written for a single, contained breach - one system, one attacker, one disclosure window. Modern incidents do not behave that way. A compromised vendor cascades into twelve downstream notifications. A misconfigured bucket exposes data across three regulatory jurisdictions with conflicting timelines. An LLM integration leaks training data through prompt injection, and nobody has a category in the runbook for what that even is. The disclosure machinery is built for a world that stopped existing around 2018, and the lag is the symptom of that mismatch.

3. Where People Get It Wrong

The first misconception is that disclosure lag is a legal problem. It is not. Legal review is a constraint on the pipeline, not the pipeline itself. Treating it as the bottleneck means every improvement effort gets routed into hiring more privacy counsel or buying breach-response retainer hours, which addresses throughput at one stage while leaving the rest of the process untouched. The actual bottleneck is almost always the absence of a structured, machine-readable incident record that every function can draw from. Without that, legal is reviewing prose written by comms based on a summary written by an engineer based on a Jira ticket that was last updated four hours ago. The lag is baked into the format.

The second misconception is that more automation, specifically more AI, will fix this. It will not, if the automation is bolted onto the same broken pipeline. Dropping an LLM into the comms drafting stage produces faster bad drafts. Using an agent to summarise forensic findings produces confident summaries that hallucinate severity. The problem is not that humans are slow at writing - it is that there is no canonical incident state for anything, human or model, to write from. Automation amplifies whatever structure exists underneath it. Where there is no structure, automation amplifies the chaos and gives leadership false confidence that something is being handled.

The third misconception, and the most damaging, is that disclosure is fundamentally a communications exercise - a question of tone, framing, and reputation management. This framing is why the lag exists. When disclosure is treated as a narrative to be crafted rather than a factual obligation to be discharged, the incentive structure pushes every stakeholder toward delay. Another day of review is another day to refine the message. Another week of investigation is another week before anyone has to commit to a public statement. The organisations that disclose fastest are the ones that have stopped treating disclosure as a story and started treating it as a data product: structured, versioned, updated as facts change, and routed to each audience through a defined interface. That reframing is what closes the lag. Everything else is decoration.

4. Mechanism of Failure or Drift

The mechanism is shape-shifting of the incident record. At T+0, when a security analyst flags suspicious behaviour, the incident exists as a few timestamps and IPs in a SIEM alert. By T+6 hours it is a Slack thread with screenshots. By T+24 hours it is a Jira ticket with a forensic narrative. By T+72 hours it is a Google Doc with severity scoring. By T+10 days it is a legal memo. By T+30 days it is a regulator filing. Each transformation is lossy. Facts get summarised, qualifications get dropped, severity gets recalibrated to match the audience. Nobody is lying. They are just rewriting, and every rewrite is a translation loss that the next stage cannot recover.

The drift compounds because each rewrite introduces a different threat model of who is reading it. Engineers write for engineers. Lawyers write for plaintiffs. Comms writes for journalists. By the time the same incident reaches the customer, it has been translated through four audiences who never spoke to each other, and the original technical detail that would have let a customer actually protect themselves - rotate these specific tokens, monitor these specific endpoints, revoke these specific sessions - has been smoothed into we take security seriously. The lag is partly the time those translations take, and partly the time spent reconciling them when they disagree, which they always do.

There is a second-order failure embedded in this. Because the record never stabilises into a canonical form, every new fact discovered during investigation forces a regression through all the prior stages. Forensics finds an additional affected system on day 14. Now the legal memo needs revising, comms needs to reissue the holding statement, regulators need an amendment, and the executive briefing needs a fresh round of pre-reads. Each amendment costs another two to five days. Most disclosure timelines are not slow because investigation is slow. They are slow because the pipeline cannot absorb new information without rewriting everything downstream. The architecture is serial where it should be event-sourced, narrative where it should be schematic, and human-mediated where the volume long ago outgrew human bandwidth.

5. Expansion into Parallel Pattern

This is the same pattern that breaks AI deployment in enterprises, which is why it matters here. Anyone who has tried to ship an LLM-based system into production has met this dynamic: a probabilistic component is dropped into a workflow that expects deterministic state, with no canonical schema for what the system produces, and every downstream consumer reshapes the output to fit their own assumptions. The model outputs prose. One team parses it. Another team summarises it. A third team uses the summary for a decision. The original signal is unrecognisable by the time it lands somewhere consequential. The failure mode is identical to incident disclosure - uncontrolled translation across uncoordinated consumers, with no shared definition of what the record actually says.

The pattern shows up in compliance reporting, financial reconciliation, vendor risk management, customer escalations, and increasingly in agent-based automation. In each case, the architectural mistake is the same: treating the artefact - the report, the disclosure, the agent output - as the deliverable, when the actual deliverable is the underlying structured state that every artefact gets generated from. Organisations that get this right build a single, versioned, machine-readable record of truth, and then generate downstream views as projections from that record. The regulator filing, the customer email, the executive brief, the journalist statement - each one is a rendering of the same source. Organisations that get it wrong write each view by hand and then spend most of their operational capacity keeping the views consistent with each other.

The transferable lesson is that the disclosure lag and the agent reliability problem are both symptoms of the same missing layer: a structured state representation that survives translation. Whether you are notifying ten million customers about a credential breach or routing an LLM agent’s output to three downstream services, the pipeline only works if there is a canonical artefact that all consumers reference, with explicit versioning when it changes. Without that layer, you are managing N-squared inconsistency by hand, and humans burn out before the work stabilises. With it, the incident response runbook, the regulatory filing pipeline, and the customer notification system become consumers of the same record - and the lag collapses because there is nothing to reconcile. Every domain where AI is being introduced into operational workflows will run into this same wall. Incident disclosure is just the one where the cost of getting it wrong is now showing up on the front page.

6. Hard Closing Truth

A thousand breaches in, the data is clear. The companies that disclosed within seventy-two hours did not do it because they had better lawyers or faster forensics. They did it because they had pre-built the pipeline. The runbook was a workflow, not a Word document. The incident record was a schema, not a narrative. The disclosure templates were already routed and approved against that schema, conditional on severity. When the alert fired, the machinery was already pointing at the right artefacts. The remaining work was filling in the variable fields and confirming the facts. Everyone else was still in a room asking each other what the timeline should say.

The harder truth is that this is no longer optional. Regulatory windows are tightening - SEC four-day rules, DORA, NIS2, state-level breach laws that overlap with incompatible timelines - and customer expectations have collapsed from weeks to hours. The legal exposure of slow disclosure is now greater than the reputational exposure of fast disclosure, which is the inverse of what executives were trained on a decade ago. Organisations still operating under the old model, where every incident is a bespoke crisis to be hand-crafted, are accumulating risk every day the pipeline stays manual. The breach itself is rarely the lawsuit. The disclosure failure almost always is. The class action is built on the lag, not the compromise.

What this means for anyone responsible for security, risk, or operations: stop investing the next dollar in detection. Invest it in the pipeline that takes a confirmed incident from detection to disclosure, end to end, as a structured system with defined inputs, versioned state, and automated routing to each downstream audience. Treat disclosure as a data product. Build the schema before you need it. Pre-route the templates. Pre-negotiate the legal review thresholds. Pre-stage the customer notification infrastructure and the regulator submission endpoints. When the next breach hits - and it will - the question is not whether you detected it fast enough. It is whether the rest of the system is built to keep up with what detection found. For almost everyone, right now, the answer is no. That is the real failure, and it is fixable, but only when it stops being treated as a crisis communications problem and starts being treated as the engineering problem it actually is.