The first hours of a suspected breach determine much of what follows — whether you can establish what happened, whether your insurance responds, and whether you meet notification deadlines that have already started running.
This is what to do, in order. It assumes you are discovering something now rather than planning in advance; if you are planning, the companion piece on building an incident response plan is the better starting point.
Hour one — contain without destroying
The instinct is to shut everything down. Resist it.
- Isolate affected systems from the network — unplug the network cable, disable the wireless adapter, or disable the switch port. Do not power off. System memory holds evidence about what was running, what connections existed, and occasionally encryption keys. That evidence is destroyed on shutdown.
- Disable compromised accounts rather than deleting them, and terminate their active sessions. Disabling alone does not always end sessions already authenticated.
- Preserve logs immediately. Many systems overwrite logs on a rolling basis, and the evidence you need may have days rather than weeks of life.
- Start a written timeline. Time, action, who did it. This becomes essential for the insurer, potentially for regulators, and for establishing what was accessed.
Do not begin remediating or rebuilding yet. Systems altered before they are examined can make it impossible to establish what happened, which matters because notification obligations depend on knowing what was accessed.
Hour two — the calls that must happen early
Two calls, in this order.
Your cyber insurer first. Most policies require prompt notification and the use of the carrier's approved incident response vendors and counsel. Engaging your own forensics firm before notifying the carrier can jeopardise coverage, and this is one of the most expensive mistakes available at this stage.
Legal counsel second, ideally through the carrier's panel. Engaging counsel early can bring the forensic investigation under privilege, which affects how the findings can be used later. It also matters because notification obligations are legal determinations, not technical ones.
Then assemble the internal team: whoever leads the response, IT or your provider, legal, communications, and someone senior enough to authorise spending without delay.
Day one — establish scope
The central question is not how they got in. It is what they reached, because that drives every obligation that follows.
- Which systems were accessed, and when
- What data those systems hold
- Whether data was exfiltrated, or only accessible
- Whose data — how many individuals, in which states or jurisdictions
- Whether the categories involved trigger specific regimes: health information, payment card data, Social Security numbers, financial account details
- Whether the attacker still has access anywhere
That last point matters enormously. Restoring systems while an attacker retains persistence simply provides them clean data to attack again, and re-encryption after a premature restore is a documented pattern.
Notification obligations
Deadlines run from discovery, not from resolution, and several may apply simultaneously.
- HIPAA — affected individuals without unreasonable delay and no later than 60 days from discovery. Breaches affecting 500 or more also require notification to HHS and prominent media in the affected area within the same window.
- FTC Safeguards Rule — non-banking financial institutions must notify the FTC within 30 days of discovering an event involving unencrypted information of 500 or more consumers. The notification becomes public.
- New York SHIELD Act — notification to affected New York residents, with obligations to state authorities depending on scale.
- Connecticut — its own notification statute with its own timeline.
- Contractual — client agreements and outside counsel guidelines frequently impose windows far shorter than any statute, sometimes 24 or 48 hours.
- PCI-DSS — your acquiring bank and the card brands, if cardholder data is involved.
Two practical points. Encryption often matters: under several regimes, properly encrypted data that is lost may not constitute a reportable breach. And you notify based on the residence of affected individuals, not your own location, so a business in New Rochelle with clients across several states may face several regimes at once.
Communicating
Notification content is usually prescribed by statute — what happened, what information was involved, what you are doing, what recipients should do, and how to contact you.
Beyond the legal minimum, the principles that hold up:
- Do not speculate publicly before the investigation concludes. Early statements that later prove wrong cause more damage than the delay would have.
- Do not minimise. If the scope expands later, the correction is far worse than accurate initial disclosure.
- Brief your staff before external notification. They will be asked, and they should not learn about it from a client.
- Prepare for the questions rather than only the statement — clients will ask what specifically of theirs was involved.
Recovery and afterwards
Restore only once the environment is confirmed clean and persistence is removed. Rotate every credential, including service accounts and any provider access. Rebuild rather than clean where compromise is suspected but unproven.
Then do the part most organisations skip: a written post-incident review covering what happened, how it was detected, how long the attacker had access, what worked in the response, and what did not.
Two questions are worth answering honestly in that review. Should monitoring have caught this earlier? And would the notification deadlines have been achievable if this had happened on a Friday before a holiday? The answers usually produce more improvement than the technical remediation does.