Picture a Friday evening. You are a freelance infrastructure engineer, laptop half closed, when a long-standing client messages: “Something odd is happening with our servers. Can you jump on?” Nothing in your contract mentions security emergencies, and you are suddenly the nearest technical adult in the room. This primer is for that moment. It introduces ResponseOps, a name some people give to running security incident response as an ongoing capability, so a solo practitioner knows what is worth doing, what is not their job and how to talk about it with a client.

First, what is it, and is the name official?

It is a friendly label, not a standard. The Ops Atlas page for ResponseOps says so itself: no incident response standard uses the word, and an international standard describes the same activity as “ICT incident response operations”. That matters for freelancers in a very practical way. If you ever put something in a statement of work, write “incident response” and define the scope in plain sentences. Fancy shorthand in a contract invites confusion.

What the label points at is a way of working: you decide in advance who declares an incident, how evidence is kept, how far you look before you act, and who talks to whom when the clock is running. A client with that in place is easy to help. A client without it will pull you in six directions at once.

A mini-glossary for your first call

Expect to hear these words on the call, so here they are in everyday language.

• Declare. Formally saying “this is an incident”. It starts the clocks and the paperwork, so someone has to own the decision.
• Preserve. Keeping evidence intact. Capture short-lived things such as memory before long-lived ones such as disks, record a fingerprint (hash) at capture, log who handled what in UTC, and work on copies.
• Scope. Working out how far the intruder got, which accounts, machines and data they touched.
• Contain. Stopping the spread, for example by cutting a machine off the network or revoking a credential.
• Evict. Removing the intruder completely. The Atlas insists this comes after scoping, otherwise you remove one foothold and miss the rest.
• Dwell time. How long an intruder was active before anyone noticed.
• Chain of custody. The written trail showing who held a piece of evidence and when.
• Tabletop. A talk-through rehearsal of an incident, no keyboards needed.
• Out-of-band. A channel that does not depend on the systems under attack, such as a phone bridge separate from company email.

The three things a freelancer should do first

When I picture the best version of that Friday message, it goes something like this. The client has a phone number to call, the freelancer knows who is allowed to say “this is an incident”, and the first twenty minutes are spent preserving, not fixing.

Here is a small order of operations you can keep on a sticky note.

1. Ask who owns the decision. Not “who is most senior” but “who can declare, and who do they need to consult?” The Atlas notes that missed notification deadlines often come from an unowned awareness decision.
2. Move the conversation off the suspect systems. Using the compromised mail or chat to plan the response is one of the listed anti-patterns, because the intruder may be reading along.
3. Preserve before you fix. Take the snapshot, grab the logs, note the time in UTC. Reimaging a server wipes the evidence and a single access point while the actor stays free.

Notice what is missing from that list: heroics. You do not need to be the one who finds the attacker. You need to be the calm one who keeps the evidence usable and keeps the client’s decision-makers informed.

Knowing where your job ends

Solo professionals often drift into duties they never agreed to. The Atlas draws a useful boundary around the discipline: legal advice on privilege and obligations sits outside it, as do the running of detection rules, long-term threat hunting and the bulk of the restore engineering. Your client’s lawyers handle the legal questions. You can say, honestly, “I can help with the technical steps; the notification question needs your counsel.”

That boundary is also a defence for you. The Atlas lists several clocks that regulators apply, and as of October 2026 they vary a great deal: 72 hours for Europe’s personal-data rule from awareness, a 24-hour early warning under the network-security directive NIS2, four hours from classification for financial firms under the resilience regulation, a six-hour window in India, and four business days for a US-listed company after it decides an incident is material. A freelancer is not expected to interpret any of that. A freelancer is expected to say that the clocks exist and ask who is tracking them.

Traps that catch beginners

Here are some hard-won lessons from the Atlas’s list of technical traps, and they are the kind of thing you would only learn by being burned:

• In one major cloud, editing a security group does not cut connections that are already tracked, so your “block” can look effective while the intruder’s session carries on.
• Switching off a user in a large identity service is not instant; the entry gives roughly a quarter of an hour for clients that check continuously and up to an hour for the rest.
• Temporary cloud credentials are valid until they expire, so you need to think about their lifetime, not only the key that issued them.
• After a domain-controller compromise in a Windows directory, one specific account secret has to be reset twice, about ten hours apart.
• Some malware wipes data when a host is isolated or powered off. Before you pull a plug, ask what the machine is doing.

If any of that is unfamiliar, good. It is the reason to practise on a lab before a client’s data is on the line.

Talking to a client about readiness before anything happens

The hardest part is selling the idea without sounding like you are cashing in on fear. Trust grows when you offer something small, concrete and honest. If you want a refresher on that, the piece on winning the confidence of a client you have just met is a good companion, and the beginner questions answered in our newcomer FAQ for independent engineers cover the contractual basics.

A small, honest offer might be a half-day readiness workshop following the Atlas’s 30-60-90 sketch. In the first block, the client names a lead, writes a one-page plan, sets up an out-of-band bridge and creates emergency access that lives outside the main identity system. Later blocks add playbooks for three scenarios (ransomware, a hijacked identity and a leaked cloud key), an evidence store and a clocks map prepared with their counsel. At ninety days you run a tabletop with the executives and fix what it reveals.

How to tell whether you are helping

Avoid counting incidents. The Atlas points out that such counts measure workload, not quality. Instead, ask better questions: how long between the first sign of trouble and the moment someone noticed, how fast did the client declare, did the intruder come back after being removed, were deadlines met. The Atlas’s worked example gives a dwell time of 11 hours 17 minutes and a declaration 45 minutes after the alert, and it puts them in a quarterly table with a one-in-four re-entry rate. Those numbers are teaching aids, but the habit of writing them down is what a freelancer can bring.

The Atlas also puts a global median dwell time from a 2025 industry report at 14 days, which is a humbling number to carry into a client meeting. Speed is a service you can sell honestly.

A closing thought

You will not be the hero of every incident, and you should not try. The most valuable freelancers in these moments are the ones who arrive with a checklist, ask who owns the decisions, preserve what others would overwrite and know when to hand a question to a lawyer. That Friday message will come eventually. Be the person who already knows what to do with the first twenty minutes.