Incident response

If it is happening now, call. Then read this.

The first hour decides how bad the rest of it gets. Most of the damage we are called in to undo was done by the response, not the attacker.

Do this now

Write down what you noticed, when, and who noticed it. Timestamps matter later.
Isolate affected machines from the network — unplug the cable or disable the adapter.
Leave affected machines powered ON. Memory holds evidence that a shutdown destroys.
Assume email and chat may be readable by the attacker; move coordination to a channel they cannot see.
Preserve logs now, before retention windows roll them off.

Do not wipe, reimage or restore from backup yet — you will destroy how it happened and may restore the way back in.
Do not delete files the attacker left. They are evidence.
Do not change passwords everywhere at once before you know the extent, or you will tip them off mid-investigation.
Do not tell customers anything specific until you know what is true. A wrong first statement is very hard to walk back.
Do not pay a ransom before taking advice. It is a legal question as much as a technical one.

01
Contain without destroying
Stop the spread while preserving the record of how it started. These two goals conflict and the order matters — this is the step most in-house responses get wrong.
02
Establish the facts
How they got in, when, what they reached, what left the building. Evidence-based answers, because you will have to repeat them to a board, an insurer or a regulator.
03
Recover cleanly
Back to operating on infrastructure where the foothold is verified gone, not assumed gone. Reinfection from an unclean restore is common.
04
Close it out
A written timeline, a scope-of-compromise statement, support with NDPA notification duties, and the specific changes that stop a repeat.

Agreeing terms with a responder in advance costs nothing and removes a day of procurement from the worst day of your year.