Incident response lifecycle — how do we set this up for a small business?

Don't let BSI standards intimidate you; it's mostly common sense. The most common mistake small businesses make is not knowing who owns the decision. In a crisis, does the office manager call the shots, external IT, or the business owner? If you don't define that authority on paper right now, you'll waste critical hours playing phone tag during an attack.

For containment, the only thing staff should do is physically disconnect the network. Rebooting or yanking the power plug destroys malware artifacts living in RAM. The moment the network cable is pulled, the outside expert has a much better shot at dumping memory and tracing the threat actor's entry point.

First thing tomorrow morning do these three things: 1) Print your external IT support's emergency number and stick it on a physical board. 2) Run a weekly backup to an external hard drive and lock it in the safe. 3) Tell your team that if anything looks fishy, cut the internet connection without turning off the machine. That's half your preparation done right there.

We got caught flat-footed in a similar ransomware incident two years ago. We had to pay an external incident response team 6,500 EUR just to recover the server and run digital forensics. If we had put together a simple emergency protocol three months earlier, we wouldn't have spent even half of that.

one thing I don't get, why is turning off the computer bad? tbh doesn't cuting the power stop the virus in its tracks, wouldn't pulling the plug make more sense?

Do not buy those massive framework templates consultants push. They try to make a small shop fill out 100-point checklists; when things go south nobody even cracks that binder open. Anything beyond a straightforward checklist is a waste of time.

In short, the cycle boils down to four steps: Prep your comms tree and offline backups before anything happens, isolate the machine from the network at the first red flag, clean up with an IT pro, and afterward, document where the hole was and harden the system.

I've been down this road, let me tell you. If the notification path is long, notifications don't arrive; missing notifications mean delayed incident detection.

Taking notes for two weeks yields better results than a six-month estimate. Of course, it varies if your situation is different.

I disagree with you on this point. Processes without records never improve, because you don't know what to fix.

If you post the result here, it will help others too.

I've been dealing with this for a long time. Taking notes for two weeks yields better results than a six-month estimate.

If it's your first time, start small; scaling comes later. Hope this helps.

Let me share my experience. Everything goes well for the first three months; problems arise in the fourth.

This is my opinion, I'm not claiming it's absolute truth.

Let me summarize the topic, since several different answers were given. The harder it is to reverse a decision, the slower you should make it.

If you post the result here, it will help others too.

The discussion got scattered, let me summarize. The harder it is to reverse a decision, the slower you should make it.

If you post the result here, it will help others too.

I think it's hard to be that definitive about incident response lifecycle. If the notification path is long, notifications don't arrive; missing notifications mean delayed incident detection.

If I were you, I'd go this route.

Saved.

Let me speak from the other side; I'm on the supplier side. Most incidents start with a leaked password, not a vulnerability.

If I were you, I'd go this route.

I went through the same thing two years ago. An untested backup is not a backup.

Having backups accessible on the same network and with the same identity makes them part of the target. Correct me if I'm wrong.

Let me write how it's done in practice. The harder it is to reverse a decision, the slower you should make it.

Proven by experience.