A data breach is an incident in which information is accessed, disclosed, altered, lost or taken without authorisation. The definition is simple; the operational reality is not. A stolen password, an exposed cloud folder, a compromised supplier and a lost unlocked phone can all become breaches, yet each demands a different response.
The immediate executive task is therefore not to announce a conclusion. It is to establish what is known, contain further exposure, preserve evidence and put accountable specialists in charge. This guide explains the distinction between an event and a confirmed breach, then turns the first 72 hours into a practical decision sequence.
Why data breaches are suddenly back in focus
The subject moved sharply into public search interest after IBM published its 2026 Cost of a Data Breach report announcement. IBM said that one in four malicious breaches in its study were AI-enabled and that those incidents cost an average of $6 million. Those figures describe IBM's research sample; they should not be treated as a universal forecast for every organisation.
The useful implication is narrower and more urgent. Attackers can use automation to scale reconnaissance, phishing and exploitation, while defenders still lose time deciding who owns the response. Faster tools do not remove the need for disciplined governance. They make disciplined governance more valuable.
A breach is not the same as a security event
A security event is an observable occurrence: a failed login burst, an alert from an endpoint tool, or an employee reporting a suspicious document. An incident is an event, or group of events, that threatens confidentiality, integrity or availability. A breach is reached when protected information has actually been exposed, accessed or lost without authority.
That sequence matters. Calling every alert a breach creates unnecessary alarm and may distort legal reporting. Calling a genuine breach a minor event delays containment and notification. The incident lead should maintain a working classification that can change as evidence arrives: event, suspected incident, confirmed incident, confirmed breach. Every change should record who made it, when, and on what evidence.
The four questions an executive must answer first
The first briefing should answer four questions, even if the answer is “not yet known”.
What system, identity or supplier is affected?
Is unauthorised access still active?
What data could be involved, and whose data is it?
Who has authority to contain, investigate, notify and communicate?
This is more useful than asking for a premature estimate of total damage. A credible executive update separates measured facts from hypotheses and decisions. “A privileged account authenticated from an unusual location” is a fact. “The attacker copied customer records” is a hypothesis until logs or other evidence support it.
First 72 hours: exposure-to-action matrix
| Time window | Primary objective | Evidence to preserve | Executive decision | Avoid |
|---|---|---|---|---|
| 0–2 hours | Stop continuing exposure | Identity, endpoint, network and cloud logs | Appoint incident lead and legal contact | Public speculation |
| 2–8 hours | Define affected systems and identities | Access histories, snapshots, supplier notices | Isolate assets and revoke high-risk sessions | Destroying evidence through rushed resets |
| 8–24 hours | Establish data and jurisdiction scope | Data maps, contracts, residency and ownership | Engage regulators, insurers or law enforcement where required | Assuming one country's rule applies globally |
| 24–48 hours | Validate containment and impact | Forensic timeline and independent checks | Approve factual stakeholder communications | Overpromising that the issue is “fully resolved” |
| 48–72 hours | Move from emergency to controlled recovery | Clean restoration evidence and monitoring plan | Authorise phased return and lessons review | Restoring trust solely because systems are online |
The matrix is not a legal deadline calculator. Notification obligations vary by jurisdiction, contract, industry and the type of information involved. Use qualified counsel and the relevant authority. The UK Information Commissioner's Office provides a practical personal data breach reporting route for organisations within its scope.
Hours 0–2: contain without erasing the story
Containment should be decisive but forensic. Disable or restrict compromised accounts, revoke active sessions, isolate affected endpoints and block known malicious infrastructure. At the same time, preserve logs, volatile data and system snapshots. Reimaging a laptop before collecting evidence may remove the very artefacts needed to understand entry, persistence and scope.
Create a separate communication channel for the response team if the normal environment may be compromised. Record decisions in a timestamped incident log. Limit access to people with a defined role, but include legal, privacy, communications and business-continuity leaders early enough that technical actions do not create regulatory or operational surprises.
For personal devices, do not assume a remote wipe is always the first action. If the device is recoverable and could contain evidence, security and legal leads should decide whether to lock, locate, disconnect or wipe it.
Hours 2–8: identify the blast radius
The “blast radius” is not simply the number of machines showing alerts. It includes identities, permissions, connected applications, suppliers and data flows. A single compromised administrator can reach many systems; a compromised low-privilege account may reach little. Map what the identity could access, what it actually accessed and what it attempted to access.
Check for persistence: new accounts, forwarding rules, API keys, OAuth grants, scheduled tasks and altered recovery methods. Review data exports and unusual queries. Ask suppliers to preserve their logs rather than accepting a short reassurance. If the incident began in a third party, contractual rights, evidence quality and notification timing become part of the response.
Use the organisation's existing asset and data inventories. An incident is a poor moment to discover that no one owns the customer database or knows which jurisdictions it serves.
Hours 8–24: determine data, people and legal scope
Classify the potentially affected information: credentials, financial details, health data, confidential communications, intellectual property or ordinary operational records. Then identify the people and organisations connected to it. Sensitivity and likely harm matter more than raw record count.
Legal and privacy teams should determine applicable notification obligations. That work depends on where the organisation operates, where affected people are located, what contracts promise and whether critical infrastructure or regulated sectors are involved. The NIST Cybersecurity Framework is useful for organising governance, identification, protection, detection, response and recovery, but it does not replace local law.
Prepare a factual holding statement internally. It should state what has happened, what is being done, what employees or customers should do now, and when the next verified update will arrive.
Hours 24–48: communicate facts, not confidence theatre
Good breach communication is specific about uncertainty. State what is confirmed, what is still being investigated and what protective action recipients can take. Avoid saying “no data was accessed” when the truthful statement is “we have not yet found evidence of access”. The difference is material.
Customer guidance should be proportionate. If credentials may be exposed, explain password resets, session revocation and phishing risk. If payment data is affected, provide the relevant monitoring or card-replacement route. Do not bury practical actions beneath corporate language.
Executives also need an internal decision log: why containment choices were made, who approved communications, and which evidence supported the assessment. This protects the integrity of the response and makes later review possible.
Hours 48–72: recover in stages and verify independently
Recovery is not the moment systems switch back on. It is the controlled restoration of trusted identities, configurations, data and business processes. Rotate credentials according to dependency, rebuild affected systems from known-good sources and monitor for recurrence. High-risk services should return in stages with explicit rollback conditions.
Ask a person or team not responsible for the original containment to challenge the evidence. Can the attacker still authenticate? Are all persistence mechanisms removed? Are supplier connections clean? Did restored data come from a point before compromise? Independent challenge is particularly valuable when the response team is tired and eager to declare success.
Schedule the post-incident review while the timeline is fresh, but do not turn it into a search for one person to blame. The durable questions concern controls, ownership, detection, evidence and decision latency.
The executive mobile-risk layer
Executives concentrate risk because their devices carry sensitive correspondence, travel plans, authentication prompts and access to assistants. A resilient mobile posture separates device unlock from account recovery, minimises standing privileges, protects backups and keeps a clean route for incident communication.
No phone can guarantee immunity from a data breach. The relevant buying questions are whether the device receives dependable security updates, whether sensitive processing can remain local, how permissions are controlled, and how the organisation handles loss, recovery and delegated access. VERTU's confidential mobile communication guide expands that decision from a device feature list into an operating model. Selected VERTU services may support authorised coordination, but they do not replace an organisation's incident-response team, counsel or forensic provider.
The account layer matters as much as the handset. The passkey guide for executive travel explains how phishing-resistant sign-in, recovery and device loss should be planned together.
A board-ready breach briefing
A concise board briefing should cover: current classification; affected services; confirmed and potential data; containment state; legal and regulatory actions; business interruption; customer protection; financial exposure range; and the next decision point. Add confidence levels and evidence dates.
The board should not receive an unfiltered technical log. It should receive a traceable decision picture. Equally, it should not receive a polished summary that removes uncertainty. The most trustworthy phrase in an early breach response may be “unknown, with this test underway and a result due at 16:00”.
