What Is Breach Response?

Breach response is the legal, regulatory and communications track that runs when personal or regulated data has been exposed. It runs alongside technical incident response and operates on a different clock.

The distinction matters because the deadlines start from awareness, not from resolution. An organisation still investigating may already be inside a notification window.

Incident and breach are not the same thing

An incident is a security event. A breach is an incident meeting a legal definition, which varies by jurisdiction and by sector but generally involves unauthorised access to, or acquisition of, personal information.

Most incidents are not breaches. Determining which category applies is a legal assessment informed by forensic findings, and it is the determination that starts the clock — which is why counsel is usually involved early rather than after the technical work.

The deadlines, and what they run from

Many privacy regimes require notification to a regulator within seventy-two hours of becoming aware. Sector rules add their own windows, and requirements differ by province, state and country for the same dataset.

Because obligations follow where the affected people are rather than where the organisation is, a single incident can trigger several regimes with different definitions, thresholds and timeframes simultaneously.

Establishing scope is the hard part

Notification requires knowing whose data was affected and what was exposed. Answering that depends on logging and forensic evidence, and where log retention is shorter than the intrusion, the honest answer becomes unknowable.

Organisations in that position frequently notify more broadly than necessary, because they cannot rule people out. Retention is therefore a breach-cost decision as much as a detection one.

Communication quality drives the reputational outcome

Notifications that are late, vague or minimising cause more lasting damage than the incident. People respond to being told clearly what happened, what it means for them, and what is being done.

Early statements made under pressure are the risk. Saying that no data was affected before the investigation supports it, then correcting it later, converts a security failure into a credibility failure. Holding statements that commit to updates without asserting unverified facts are the safer position.

Who needs to be in the room

Legal counsel, because the determinations are legal. Communications, because the external messaging shapes the reputational outcome. The insurer, because notice is usually a policy condition and coverage can be affected by delay or by engaging unapproved vendors.

Executive leadership, because the decisions are theirs. The technical team supplies findings, and should not be the function deciding what gets disclosed.

Documenting a decision not to notify

Where the assessment concludes that a threshold was not met and notification is not required, that conclusion needs recording with the reasoning and the evidence it rested on. Regulators reviewing an incident later will ask how the determination was reached.

An undocumented decision not to notify is indistinguishable from a failure to consider the question. The record is short to produce at the time and cannot be reconstructed convincingly afterwards, which makes it one of the cheaper protections available.

Where to start

Establish which notification regimes apply to your data and what their deadlines are, before an incident. That research takes days in calm conditions and is not achievable inside a seventy-two-hour window.

See the first 72 hours, notification requirements by province and incident communications. GuardsArm delivers incident response.