Incident Response for Individuals: What to Do in the First Hour

The backup strategy article covers how to make sure your data survives a ransomware event — immutable copies, an offline rotation, the restore test nobody actually does. What it doesn’t cover is the messier, more immediate question: what do you actually do in the first hour after you notice something is wrong, before you even know whether your backups are going to matter. That’s a different problem, and most consumer security advice skips straight past it to “restore from backup” as if the hour before that decision doesn’t exist.

Why the First Hour Is Different From Everything After It

Once you’re in incident response mode proper — scoping the damage, restoring from backup, rotating credentials — there’s a reasonably well-understood playbook, and this site covers pieces of it elsewhere. The first hour is different because you usually don’t know yet what you’re actually dealing with. A slow computer, a strange login alert, a friend saying they got a weird email “from you,” a ransom note on the desktop — these arrive with wildly different severity and require different first moves, and the instinct to do something immediately is exactly the moment people make the response worse instead of better.

The two most common mistakes in that first hour are opposite failures: panicking and wiping/reinstalling before anyone’s figured out what actually happened (destroying the evidence you’d need to know how bad it was or how it got in), or freezing and doing nothing while a live compromise continues. Neither is a strategy. What actually works is a short, boring sequence, done in order.

Step One: Contain, Don’t Panic-Wipe

Disconnect the affected device from the network — pull the ethernet cable or turn off Wi-Fi — before doing anything else. This stops active exfiltration or lateral movement without destroying anything you might need to look at later. Do not reboot, do not run a “cleanup” tool, and do not reinstall the OS yet. All three of those can overwrite the evidence that would tell you what actually happened, and none of them are urgent enough to justify losing that information before you’ve had a chance to look at it.

If it’s a ransomware note specifically: do not pay, and do not delete the note or any encrypted files, even ones that look useless. Some ransomware families have had decryptors released after the fact (No More Ransom, a joint law enforcement/industry project, is the legitimate place to check), and paying funds the same criminal ecosystem while offering no guarantee of actually getting your data back.

Step Two: Figure Out What Actually Happened

Before touching credentials or restoring anything, spend a few minutes establishing scope. What’s the actual evidence — a specific alert, a specific symptom, a specific file? When did it start, as best you can tell? Is this one device or does it look like it’s spread (other devices behaving strangely, accounts you didn’t touch showing activity)? This is the step most people skip entirely, jumping straight to “change all my passwords,” which is reasonable eventually but premature if you don’t yet know which accounts were actually touched — you can waste real time re-securing things that were never involved while missing the one that was.

If you have any logging in place — a router’s connection log, a NAS’s access log, anything from a home SIEM setup — this is where it earns its keep. A specific timestamp and a specific unusual connection turns “something feels wrong” into an actual, boundable incident.

Step Three: Change Credentials, in the Right Order

Once you have a rough idea of scope, rotate credentials starting with the accounts that would do the most damage if still compromised, not the ones that are most convenient to change first. Primary email first — it’s usually the recovery path for everything else, so a still-compromised email account means every other password change is provisional. Then financial accounts. Then anything using a password shared with the compromised account (which is itself the underlying problem a password manager solves — see the password managers comparison if you’re not already using one).

Change these from a device you’re confident is clean, not the device you suspect is compromised — entering a new password on a still-infected machine can hand the new credential straight back to whatever’s watching. A phone on cellular data, not the same Wi-Fi network, is a reasonable clean channel if you don’t have another computer available.

What Actually Needs Professional Help vs. What You Can Handle Yourself

A single personal device with a confirmed, contained infection is usually within reach of a careful individual working through the steps above. Anything involving a small business, any indication of ongoing data exfiltration you can’t stop by disconnecting the device, or genuine ransomware encrypting files you can’t afford to lose is a point to bring in professional incident response rather than improvising — the cost of a professional response is real, but it’s smaller than the cost of a self-inflicted mistake made under stress that destroys the evidence a professional would have needed, or that mishandles a legal disclosure obligation you didn’t know applied.

What I Actually Do When Something Looks Wrong

The sequence above is the one I actually follow, in the actual order, and the discipline that took me longest to build wasn’t any individual step — it was resisting the urge to skip straight to “fix it” before I’d actually confirmed what “it” was. Early in my career I responded to a suspicious login alert by immediately resetting every credential I could think of, in no particular order, which felt productive and burned close to an hour before I’d actually confirmed the alert was tied to a real compromise rather than a legitimate login from a new location I’d simply forgotten to expect. The fix that actually worked wasn’t a better tool, it was forcing myself to do step two — actually establish scope — before doing anything that felt like “fixing” it.

The other habit I’d underweighted for years: keeping a written note of what I actually observed, with timestamps, the moment I notice something’s off, before my memory of the sequence gets reshaped by the stress of dealing with it. A messy real-time note beats a clean reconstructed memory every time, and it’s the single cheapest thing in this entire list to actually do.

Common Mistakes

Reinstalling or wiping before establishing scope. Destroys the evidence that would tell you what actually happened and whether it’s really contained.

Changing passwords from the compromised device. Can hand the new credential straight to whatever’s already watching.

Paying a ransom. No guarantee of recovery, funds the same ecosystem, and skips checking whether a free decryptor already exists for that ransomware family.

Treating every alert as a five-alarm fire. Most “suspicious login” alerts turn out to be your own legitimate activity from a new device or location. Establishing scope first prevents burning an hour re-securing things that were never actually touched.

Sources:

1. CISA, incident response and reporting guidance for individuals and small organizations
2. No More Ransom Project (nomoreransom.org) — free ransomware decryptors
3. NIST Special Publication 800-61, computer security incident handling guide