A Consulting Story: Building ResponseOps After a Repeat Intrusion

The following account is an invented illustration, not a record of a real client. It follows a hypothetical mid-sized software company and the consulting engagement that helped it build a standing ResponseOps capability after a rough first encounter with an intruder. Every figure that appears below as a fact about the discipline comes from a published reference; the company, its people and its timeline are composites made up for teaching.

The Monday that went sideways

Our fictional company ran a few hundred cloud workloads and a directory service inherited from a decade of growth. On a Monday morning, an alert flagged an unfamiliar login on a build server. The on-call engineer did what felt natural: reimaged the machine, rotated one password and wrote “resolved” in the ticket. Four days later the same pattern surfaced on a different host.

The team had fallen into the first myth the Ops Atlas lists in its entry on ResponseOps as a standing capability: that wiping and reimaging closes the matter. In the Atlas’s account, a rebuild removes the evidence and one foothold, but not the actor. Worse, because nobody had mapped how far the access reached, the cleanup had alerted the intruder without evicting them. This is the textbook version of the failure the Atlas calls re-entry, and it is why the discipline treats scoping as its own step before eviction.

Why a consultant was called in

The company’s leadership asked an outside advisory team to assess the situation. The engagement followed the usual shape of good consulting work: a short assessment, a plan and then hands-on enablement, much like the sequence described in the article on what a good advisory project looks like, from the first assessment to handing skills over. The advisors began by asking a deliberately dull question: who is in charge when something like this happens? The honest answer was “whoever notices”.

That answer maps to the first rung of the maturity ladder the Atlas proposes: ad hoc, then defined, practised, measured and adaptive. The advisors told the leadership that the realistic goal for a quarter was to climb from ad hoc to practised, not to reach adaptive. Ambition was bounded by calendar.

Week one to four: ownership and a safe channel

The first month looked unglamorous. The company named an incident lead and an executive sponsor, drafted a plan that fit on one page and created a conferencing bridge that did not rely on corporate email or chat. That last item mattered because one of the anti-patterns in the Atlas is running response communications over systems an intruder may be reading. The team also created a small number of break-glass accounts, stored offline, so that responders could still get in if the primary identity service was part of the problem.

The advisors also ran a one-hour conversation with the company’s counsel about notification duties. In the Atlas’s October 2026 table, an organisation operating in Europe might face a 72-hour clock under the data-protection rule, a 24-hour early warning under NIS2 and, for financial entities, four hours from classification under the resilience regulation. Because the fictional company sold to customers in several regions, the output was a clocks map: a single page listing which rules might apply to which kinds of data, who decides that the organisation has become aware, and who calls whom. The advisors did not interpret the rules; they made sure the people who could do so were in the room.

Week five to eight: playbooks and an evidence store

In the second month, the team wrote three playbooks for the scenarios it considered most likely: file-encrypting malware, a hijacked identity and an exposed cloud access key. Each playbook followed the Atlas’s verbs of declaring, preserving, scoping, containing, evicting, recovering, notifying and learning, with a named owner for every step.

The identity playbook was the most instructive. After a compromise of a Windows directory, the Atlas says the account that signs Kerberos tickets must have its secret reset twice, about ten hours apart, because the previous value stays valid for a while. The playbook captured that as a calendar entry with an owner instead of a line in someone’s memory. The cloud-key playbook carried a different reminder: temporary credentials remain usable until they expire, so rotating the long-lived key is necessary but not sufficient.

The containment sections borrowed the criteria the Atlas attributes to the 2012 US guidance: potential for damage or theft, what happens to the evidence, whether services stay up, the effort required, how well the step works and how long it holds. The advisors added a rule of their own, in line with the Atlas’s caution that “contain everything immediately” can tip off an attacker: any decision to delay containment gets a time limit and a named approver.

The evidence store was a modest bucket with write-once settings, a naming convention and a custody log template. Collections followed the order of volatility, memory ahead of disk, with a hash taken at collection and a UTC timestamp on every custody row. Analysts worked from copies.

For the security-engineering side of the plan, the team leaned on the practices discussed in weaving security checks into delivery pipelines, since preventive controls reduce how often the playbooks are needed.

Week nine to twelve: the tabletop

In the final month, the executive team sat through a scripted exercise. The scenario began with an encrypted file server and a ransom note, then added a twist: logs showed that data had left the building before the encryption started. The facilitators used it to test a belief that appears in the Atlas’s myth list, “we have backups, so it’s a restore job”. Stolen data persists after a restore, so the exercise forced a conversation about notification and external communication, not only recovery.

The exercise surfaced three gaps. Nobody was sure who could authorise a call to law enforcement; the Atlas observes that a US sanctions authority discourages paying ransoms and regards a prompt approach to the police as weighing in an organisation’s favour, which is why the company decided the question needed an owner before a crisis. The second gap was an unclear rule about when a restore could begin relative to scoping. The third was that the clocks map had no entry for the fictional company’s newest customer region. Each gap went into the backlog with a name and a date.

Measuring the result

The advisors set up a small scorecard modelled on the Atlas’s measures, covering how long the intruder stayed unseen, how fast the team declared and contained, how much the affected set grew, whether anyone came back, whether notices went out on time and whether evidence stayed intact. They refused to report a raw incident count, again following the Atlas, which says counts show workload rather than quality. The first quarter’s numbers were poor, as expected, which was acceptable, since a baseline exists to be beaten.

Lessons a consulting team can reuse

1. Start with ownership. A plan with no named owner is a document, not a capability.
2. Sequence matters: scope before eviction, preserve before cleanup.
3. Build the out-of-band channel first, before anything sensitive is said on a compromised system.
4. Translate regulations into a clocks map with counsel instead of paraphrasing them yourself.
5. Rehearse with executives; the gaps that matter most tend to sit above the engineering layer.
6. Use the standard phrase “incident response” in contracts, and keep ResponseOps as team shorthand.

The invented company ended its quarter with a lead, a sponsor, three playbooks, an evidence store, a clocks map and a rehearsed leadership team. It had not become flawless. It had become practised, which is the honest milestone a consulting engagement can promise.

Kabir Malhotra