What follows is invented, a teaching device that describes no real firm. Imagine a small independent market-research desk of fourteen people that publishes daily commentary and sells a subscriber newsletter. Its workday revolves around a shared analytics server, a subscriber database and a publishing tool. One Tuesday night, an intruder gets in. What follows shows why practitioners talk about ResponseOps, the practice of keeping the handling of security incidents rehearsed and ready all year. Consider it general information about operations; it offers no investment guidance and discusses no securities.
A short note on terms. The Ops Atlas, which the facts here come from, treats ResponseOps as a descriptive label of its own, not an official standard. Insurers and regulators say “incident response”, so use that wording whenever you write it into a contract or policy.
Tuesday, late evening: the quiet start
In our story the intruder’s first action is invisible. They use a stolen login to reach the analytics server at 21:52 UTC. Nobody notices; the desk’s alerting only flags unusual subscriber-database queries, and this intruder is not touching that yet. For almost eleven and a half hours, nothing visible happens.
The number that matters here is what the Atlas calls dwell time: the stretch from the intruder’s first move until somebody spots it. In the story it is a little over eleven hours, a tiny figure next to the global medians the Atlas quotes from a 2025 industry report: about two weeks overall, and well over three months for espionage-style intrusions. The desk was lucky only in that the intruder moved slowly.
Wednesday, 09:10: the alert and the first mistake
An analyst notices a failed script and an odd scheduled task. The alert is real. The first mistake is a natural one: the head of operations wants the machine wiped immediately so the morning newsletter can go out. A junior engineer, who happens to have read the checklist taped beside the server, asks for twenty minutes first.
Those twenty minutes matter. The engineer copies the server’s memory, then its logs, fingerprints each file with a hash, notes the UTC time and signs the custody sheet. She follows the order recommended by an internet standard for evidence handling: the most perishable data first. When the server is eventually rebuilt, the desk keeps a trustworthy record of what was on it.
Wednesday, 09:55: declaring the incident
The head of operations formally declares an incident at 09:55, three quarters of an hour after the alert. In the Atlas’s worked example, a delay of that kind is a measurable quantity, time to declare, and one a team can shrink with a rehearsal. The desk’s lead notes the time, opens the emergency conference line and tells the staff to stop discussing the matter in the office chat tool, as the intruder may be reading it.
It is also the moment to start the legal clock thinking. The desk has subscribers across several countries, so counsel is called. The desk does not have a deadline table, which will cost it a frantic hour later. Rules vary widely: the Atlas lists everything from a few hours to two months depending on jurisdiction and sector, and it adds that deadlines tend to be missed because no individual was responsible for the call that the organisation is aware. In this story, the lead takes that decision herself and logs the time.
Wednesday, mid-afternoon: containment, with a hitch
After 5 hours and 45 minutes of work the team has the intrusion contained, which is the time-to-contain figure the Atlas’s example uses. Notice what they did not do. They did not power off every machine in the building. They isolated the affected server, rotated the exposed credentials and then verified the effect, because some actions look finished while leaving a connection open or a short-lived access key valid until its own expiry.
The scope also grew. At first the team believed six systems were involved; by the end of the day, fifteen were. That is a factor of 2.5, which the example calls scope growth. The lesson the desk writes down is to treat the first number as a floor.
The desk’s culture helps. Its own contributors write regularly about calm preparation; a post on starting the trading day with a steady routine is a good example of a mindset that translates well. In the story, the same steadiness shows up in the incident room: no heroics, a written timeline, and breaks every few hours.
Thursday: eviction without haste
The temptation is to declare victory once the server is rebuilt. The lead resists it. One of the recurring mistakes the Atlas catalogues, pushing the intruder out before the full extent is known, is a classic route to a second intrusion, and US federal guidance asks teams to account for every persistent access method first. The desk reviews every account created in the past month, every scheduled task and every API key. They find a forgotten test login with administrator rights. Had they rebuilt the server and moved on, that account would have let the intruder return.
Recovery follows. The desk restores from a backup taken before 21:52 UTC on Tuesday, because a backup from after that time might carry the intruder’s tools. It also notes that the subscriber list may have been viewed, so exposure to data-protection rules is treated as live until counsel says otherwise. Restoring files does not undo a copy that has already left, a point the Atlas makes under the heading of double extortion.
Friday: the numbers that matter
On the quiet Friday after, the team meets for a review without blame. They record dwell time (just over eleven hours), time to declare (three quarters of an hour), time to contain (5 hours 45 minutes) and scope growth (2.5 times). The desk adopts three quarterly measures: how often an intruder returns after a clean-up, what share of required notices go out on time, and how many saved evidence files still match their original fingerprints. In the Atlas’s illustrative quarter, those readings were one in four, eighty percent and 97.4 percent; the desk sets its own targets using that as a rough guide.
It also decides not to count incidents as a score. Numbers of events mostly track workload, and the desk would rather measure how quickly and cleanly it responds. A guide to turning discipline into a sequence of small steps frames the same principle for a different domain: process, not luck, produces repeatable outcomes.
What the desk changed
By the end of the quarter the fictional desk has done the following: named a response lead and an executive sponsor, written a one-page plan, set up an out-of-band conference line, sealed two emergency administrator accounts offline, drafted a deadline table with counsel, written short playbooks for ransomware, taken-over staff logins and leaked cloud keys, and held a half-day executive tabletop. That is more or less the thirty, sixty and ninety day rhythm the Atlas proposes. None of it needed a large budget.
The Atlas also reminds readers that one decision, whether to build an internal team, keep a specialist on call or buy a managed service, is mostly a question of weights, and it offers a scoring example for a mid-sized company. A rising desk of fourteen would likely begin with a part-time internal lead plus a call-out arrangement, then revisit annually.
Readers who want the source material can browse the Ops Atlas entry covering ResponseOps. If you work in a finance-adjacent business, ask your own counsel which regimes apply to you, and remember that the story above is a teaching device, not a forecast. The most useful preparation is also the least dramatic: a plan on paper, a call line that works and a rehearsal on the calendar. For a deeper look at the mental side of staying composed under pressure, a piece on the mindset that keeps market participants steady is a fitting follow-up.