What to Do in the First 48 Hours of a Cyber Incident

The first two days of a cyber incident rarely feel orderly. Teams are dealing with incomplete information, unexpected dependencies, and the pressure to act before they fully understand what has happened. In that environment, the goal is not instant certainty. The goal is controlled response, where each decision protects evidence, reduces damage, and preserves the ability to recover.

Stabilize before you optimize

One of the biggest mistakes during an early incident is assuming every action must be immediate and technical. In reality, the strongest teams begin by slowing the chaos. They establish an incident log, identify who is leading the response, and make sure communication does not fragment across email threads, chat channels, and hallway conversations. That discipline creates a stable operating rhythm for the technical work that follows.

Containment needs judgment

Aggressive containment can be necessary, but it can also create new problems if it is done without context. Disconnecting a system, disabling accounts, or shutting down services may interrupt the attacker, but it can also erase useful evidence or take critical business processes offline. The right response is usually deliberate rather than dramatic. Teams should aim to limit spread, preserve investigative options, and avoid decisions that make later recovery harder.

Coordination is part of the response

Technical responders should never have to carry the whole event alone. Leadership, legal, communications, operations, vendors, and external support partners all influence how the incident unfolds. When those groups are activated early, the organization makes better decisions about disclosure, business continuity, customer impact, and escalation. When they are brought in too late, the response becomes reactive and fragmented.

Recovery starts earlier than most teams expect

Many organizations treat recovery as something that happens after containment and eradication. In practice, recovery planning should begin as soon as the scope becomes clearer. Teams need to identify which services matter most, which backups are trustworthy, which credentials need rotation, and what monitoring must be in place before anything is brought back online. Waiting too long to think about recovery usually extends downtime.

Early lessons should be captured in real time

The first 48 hours reveal how the organization truly operates under stress. They show where approvals are unclear, which systems lack visibility, which dependencies were underestimated, and which communication paths fail when they are most needed. Capturing those lessons while the event is still unfolding creates a far more honest picture than any retrospective built from memory days later.