The Breach Playbook: What the Best Companies Do in the First 72 Hours

Srikanth
By
Srikanth
Srikanth is the founder and editor-in-chief of TechStoriess.com — India's emerging platform for verified AI implementation intelligence from practitioners who are actually building at the frontier....

There is a specific moment every CISO dreads more than the breach itself: the moment someone has to decide, with incomplete information, whether what just happened is a false alarm or the start of the worst week of their career. What separates the organizations that come through a breach intact from the ones still explaining themselves in court eighteen months later usually isn’t the sophistication of the attack. It’s what happened in the first three days after someone noticed.

That 72-hour window isn’t an arbitrary number security teams invented to sound disciplined. It’s a legal deadline. Under GDPR Article 33, organizations must notify their supervisory authority within 72 hours of becoming aware of a breach involving EU residents’ personal data – and the clock starts at awareness, not at the moment the investigation concludes. The US equivalent, the Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA), imposes the same 72-hour window for covered critical-infrastructure entities, with an even tighter 24-hour requirement if a ransom gets paid. PCI-DSS gives card processors the same 72 hours to notify acquirers and card brands. The regulatory environment, in other words, has converged on the same brutal timeline from multiple directions, which is why “the first 72 hours” has become the de facto unit of measurement for breach competence.

What good looks like, hour by hour

The organizations that handle this well treat the first hour as the most consequential hour of the entire incident. Security teams preserve volatile evidence – memory dumps, active network connections, authentication logs – before anyone touches a keyboard to fix anything, because remediation that happens before evidence is preserved can destroy the forensic trail investigators need later. Systems get isolated, not powered off, since a shutdown can wipe exactly the data a forensics team needs to reconstruct what happened.

Aura, the identity-protection company, offers a useful recent example of this discipline in practice. When the company discovered a breach caused by a targeted phishing attack that exposed marketing data lists, it identified the incident within an hour and activated its incident response plan immediately – fast enough that the response itself became part of the story, rather than a footnote explaining a months-long delay.

The next 24 hours are where the scope of the damage actually gets defined. Legal counsel gets looped in immediately, not after the technical team has formed a complete picture, because privilege and notification obligations both depend on decisions made early. Forensics teams get engaged to determine the attack vector. Compromised credentials get reset. And – this is the part organizations consistently underestimate – executive leadership gets briefed in enough detail to make real decisions, not a sanitized summary that leaves the board guessing.

By hour 72, a well-run response has completed its initial forensic assessment, determined which notification regimes actually apply, and either filed or drafted the required regulatory notifications. Crucially, GDPR explicitly allows for phased disclosure: an initial notification with whatever is known at hour 72, followed by supplemental updates as the investigation continues. The regulation does not expect certainty in three days. It expects honesty about what you know and don’t know yet.

What the slow cases have in common

The contrast with organizations that get this wrong is stark, and it’s rarely about technical sophistication. It’s about speed and candor.

Carnival Corporation identified unauthorized activity involving an employee account on April 14, 2026. It took until April 22 to determine that personal information had actually been copied. Notification letters to affected customers didn’t go out until May 27 – more than six weeks after the initial detection. SM Energy, a Denver-based oil and gas producer, discovered unauthorized access around May 15, 2026, but didn’t mail breach notifications until July 30 – a 76-day gap between discovery and disclosure. DentaQuest confirmed an incident in June 2026 after the ransomware group ShinyHunters listed it on a leak site, but didn’t begin notifying affected individuals until July.

These delays rarely come from incompetence alone. They come from an understandable but costly instinct: wanting certainty before saying anything. Legal teams want to confirm scope before drafting a notice. Executives want a clean narrative before going public. But every regulatory framework built around the 72-hour window has already anticipated and rejected that instinct. The clock starts at awareness, specifically because regulators learned, across a decade of slow-walked disclosures, that “we wanted to be sure before we said anything” is indistinguishable in practice from “we hoped this would go away quietly.”

Under Armour’s experience in early 2026 shows what happens at the far end of that instinct. After the ransomware group Everest listed the company on its leak site in November 2025 with a seven-day ransom deadline, Under Armour didn’t engage publicly. When the deadline passed, Everest published the customer dataset – 72 million email addresses – in January 2026. As of mid-2026, the company still hadn’t published its own confirmed victim count. Silence, in this case, didn’t buy time. It ceded the entire narrative to the attacker.

The decision map, not the document

The organizations that consistently perform well share one structural trait that has nothing to do with technology: they treat the incident response plan as a decision map rather than a reference document. The plan doesn’t just list phases – detect, contain, eradicate, recover – it specifies who is actually authorized to disconnect production systems, who can engage outside forensics without a procurement cycle, and who has the authority to call a regulator without waiting for a board vote. Writing those authorizations down in advance, before anyone is under pressure, is what allows an organization to move at hour one instead of hour twelve.

It also matters who’s in the room, and who isn’t directing things who shouldn’t be. Security, IT, legal, communications, HR, and the relevant business unit all typically have a role in a serious incident, but the best-run responses are explicit that not everyone gets to steer. A security incident commanded by a committee moves at the speed of its slowest member – exactly the opposite of what a 72-hour clock demands.

What this means heading into next year

Breach notification deadlines aren’t converging by accident. Regulators across GDPR, CIRCIA, HIPAA, and state-level frameworks in the US have independently arrived at the same conclusion: the real risk isn’t that a company got breached – virtually every large organization eventually does – it’s that a company knew and didn’t say so in time for people to protect themselves.

For any CXO building or revisiting an incident response plan heading into 2027, the lesson from this year’s breach log isn’t really about firewalls or endpoint detection. It’s about whether the organization has already decided, before the crisis, who gets to act without waiting for permission. The companies that handled 2026’s breaches well didn’t have better luck. They had already answered, in writing, the questions that panic makes impossible to answer well.

Follow:
Srikanth is the founder and editor-in-chief of TechStoriess.com — India's emerging platform for verified AI implementation intelligence from practitioners who are actually building at the frontier. Based in Bengaluru, he has spent 5 years at the intersection of enterprise technology, emerging markets, and the human stories behind AI adoption across India and beyond.
Leave a Comment