What Happens in the First 72 Hours
After You File a Cyber Claim

Most business owners who file a cyber claim have no idea what's happening on the other side of that phone call. They know they've had an incident. They know they have a policy. And they assume that once they report it, the insurer goes to work on their behalf.

That assumption is mostly true, but incomplete in ways that matter. I spent years on the carrier side investigating cyber claims, and what I saw in those first 72 hours is not what most policyholders picture. Understanding this window (what happens, in what order, and why it matters) is one of the most practically useful things a business owner can know before they ever need to use their policy.

The Clock Starts Before You Hang Up

The moment you report a cyber incident, documentation begins. The intake call itself is logged. What you describe (when you noticed it, what systems are affected, what you've done so far) becomes part of the claims record. This isn't adversarial; it's procedural. But it means the framing of that first conversation carries real weight.

If you've already begun recovery efforts before reporting (which is common, panic sets in, someone starts wiping and reinstalling), that information matters. It can affect the forensic investigation, the evidence available, and ultimately the scope of covered losses. The best practice is to notify your insurer as early as possible, even before you fully understand the scope of what happened.

What the Insurer Is Doing While You're in Crisis Mode

While your team is scrambling, the insurer has its own parallel process running. Here's what typically happens in roughly the order it happens:

1. A forensic investigator is assigned

Most cyber policies include access to a panel of pre-approved forensic vendors. Within hours of your report, one of those vendors is assigned to your claim. Their job is to determine the scope of the breach, how the attacker got in, what data was accessed or exfiltrated, and when the intrusion actually began. That last point matters more than most people expect, attackers are frequently inside a network for weeks or months before the incident becomes visible. If the breach predates your policy's retroactive date, coverage may be limited or excluded.

2. Your policy language is reviewed against the incident

A coverage analyst is simultaneously reviewing your policy to determine whether this specific incident falls within the covered triggers. Cyber policies are not blanket "something bad happened to our computers" coverage. They have defined triggers (data breach, ransomware, business interruption, social engineering) and the incident has to map to one of them. The analyst is also reviewing your sublimits, retention amounts, and any endorsements or exclusions that may apply.

3. Your application representations are pulled

This is the part most policyholders don't anticipate. The insurer pulls the application you submitted when you bought or renewed the policy and compares what you attested to against what the forensic investigator finds. Did you say MFA was enforced on all remote access? They'll verify it. Did you indicate you had endpoint detection in place? They'll check. A gap between what you said and what was actually deployed is one of the most common reasons claims get reduced or denied, not fraud, just optimistic paperwork that didn't reflect operational reality.

4. Ransomware response is evaluated separately

If ransomware is involved, there's an additional track running in parallel. The insurer (often through a specialized negotiation vendor) is assessing the threat actor, the ransom demand, and whether negotiation or payment is even warranted. If you have verified, restorable backups, that changes the calculus significantly. If your backups were also encrypted or destroyed (extremely common), the path forward looks very different. This assessment moves fast because ransomware attackers operate on their own timeline.

5. Legal and notification obligations are identified

Depending on what data was accessed, your insurer's legal panel will begin assessing your notification obligations. Every state has breach notification laws with specific timelines. If you handle health information, HIPAA applies. If you process payment cards, PCI DSS has its own requirements. The clock on some of these notifications starts running from the moment the breach is discovered, not from when you file the claim. Missing a notification deadline is a separate liability problem on top of the incident itself.

What Can Go Wrong in This Window

The 72-hour period is where I saw the most consequential mistakes made, not by bad actors, but by well-meaning businesses doing the wrong thing under pressure.

Overwriting evidence during recovery. When a server is wiped and rebuilt, the forensic evidence of how the attacker got in and what they accessed goes with it. Insurers need that evidence to validate the claim. IT teams that move straight to remediation without forensic preservation create a gap that's very hard to close later.

Communicating externally before notifying legal. Sending an email to customers, posting on social media, or even discussing the incident with vendors before your insurer's legal panel is involved can create additional liability or conflict with their guidance on what to disclose and when.

Using a vendor outside the insurer's panel. Many policies require that you use approved incident response vendors for costs to be covered. If you hire someone outside the panel without prior authorization, you may be personally responsible for those costs. Always confirm vendor approval before engaging anyone.

What Separates the Claims That Go Smoothly From the Ones That Don't

After reviewing a lot of claims files, the pattern is consistent. The businesses that moved through the process cleanly shared a few things in common: they had documented controls that matched what they'd represented on their application; they had a written incident response plan that included who to call and in what order; and they notified their insurer early, before taking significant remediation steps.

The businesses that struggled either had a gap between their documented posture and operational reality, had no incident response plan (or one that had never been tested), or began remediation before preserving evidence or notifying their carrier.

None of the struggling businesses were negligent in a legal sense. Most of them genuinely believed they were adequately prepared. The problem was that "adequately prepared" and "documented as adequately prepared" are two different things, and in a claims investigation, only the second one is verifiable.

The Preparation That Makes the 72 Hours Manageable

You can't prevent every incident. But you can do a significant amount of work right now that makes the claims process far less painful if one occurs. Specifically:

• Know your insurer's incident response hotline number and have it accessible outside your email system (which may be compromised)
• Have a written incident response plan that names who declares an incident, who calls the insurer, who contacts legal, and who manages communications, with actual names and phone numbers, not just job titles
• Document the controls you have in place so that what you attested to on your application can be verified if questioned
• Understand your forensic vendor, many policies name specific panels; know who yours is before you need them
• Know your retroactive date and confirm it covers your current policy period

The 72-hour window is not where a claim is won or lost, that happens in the months of preparation before the incident. But it is where preparation becomes visible, and where its absence becomes expensive.