Picture a Tuesday morning in the administration office of a mid-sized heart clinic. This is a made-up scene, a generic composite rather than any real facility. The appointment system hangs, a receptionist mentions an odd message on her screen, and within ten minutes three people are giving three different instructions. Nobody is being foolish. They simply never agreed in advance who decides what. That gap is exactly what ResponseOps tries to close, and this guide walks through it as eight steps you can follow in your own office. It deals only with non-clinical operations, such as records access, scheduling and billing, and it contains no medical content.
A quick note on the word. The Ops Atlas calls ResponseOps an editorial label for the habit of staying prepared to handle security incidents, and it stresses that the term is not part of any formal standard. In legal paperwork, say “incident response”. In staff meetings, use whichever phrase helps colleagues remember that preparation happens before the bad Tuesday, not during it.
Step 1: Give the morning an owner
In our imaginary clinic, the first change is a name on a card. One person, say the operations manager, becomes the response lead, and one senior sponsor agrees to back her decisions. When the screens freeze next time, nobody argues about who speaks first. This is the cheapest improvement on the whole list, and the Atlas places it first in its opening month for good reason: unclear ownership is behind many of the missed deadlines and muddled instructions it describes.
Step 2: Find a channel the clinic’s own systems cannot take down
On that Tuesday, the team’s first instinct was to email each other. If an intruder is reading mail, that is the same as reading the plan aloud to them. The Atlas lists “keeping response messages on compromised email or chat” among its recurring anti-patterns. So the office agrees on an out-of-band bridge, perhaps a plain conference line and a printed phone list kept in the lead’s drawer and in the sponsor’s briefcase.
Step 3: Keep a pair of emergency accounts offline
The second thing that went wrong was that the administrators could not sign in, because the thing that approves sign-ins was itself affected. The fix is a pair of emergency administrator accounts, with long unique passwords, sealed on paper and stored in a safe. They are used only in emergencies, and each use is recorded. The Atlas calls these break-glass accounts and puts them in the first thirty days of its suggested plan.
Step 4: Prepare an evidence kit before you need one
It is tempting, when a workstation misbehaves, to restart it. In the story, a well-meaning technician did exactly that, and the machine’s working memory, which could have shown what was running, was gone. Preparing a kit solves this. It includes labelled storage that cannot be overwritten, a custody form with a column for the time in a single agreed time zone, and a short instruction that says: collect the fastest-fading information first, which means memory before disk; fingerprint every item with a hash when you collect it; and work only from duplicates. The Atlas bases this order on a decades-old internet guideline for evidence handling.
Technical staff may later reach for open-source collection and analysis tools, and that is fine, but the kit works at the level of habit first. A card with five lines beats an unused program.
Step 5: Draw the map of deadlines with counsel
Once the clinic realised personal data might be involved, someone asked “how long do we have to tell people?” and the answer was a shrug. Rules differ by country and sector: some count in hours, some in days, some from the moment of awareness and some from a formal determination. The Atlas, summarising the position in October 2026, shows how widely they differ. A reasonable practice is to sit with your lawyer for an hour and build a one-page table: event type on the left, the rule that applies in the middle, and a named owner on the right.
Most important is who owns the “we are now aware” decision. The Atlas names a missed deadline caused by an unowned awareness decision as a classic failure, and fixing it costs nothing.
A small side benefit appears here. When the clinic’s vendors and partners see a written contact sheet and a named lead, they know whom to call as well, and the awkward first half hour of “who is in charge over there?” shrinks. Many offices find that this courtesy alone repays the time spent writing the page, since external parties such as software suppliers and billing partners often hold part of the picture and respond faster when they reach a decision-maker directly.
Step 6: Write three short playbooks
The Atlas suggests starting with ransomware, a taken-over staff login and an exposed cloud access key. A playbook here is not a thick binder. It is a page of numbered decisions: what to preserve, what to isolate, what to leave running for a defined period, who to call. For containment choices the Atlas recommends time-boxing any delay, so waiting is a conscious, recorded choice and not a drift. It also warns that some malware reacts to being isolated or powered off, so the playbook should say who decides before anyone pulls a plug.
An accessible companion read on this theme is a walkthrough on gaining visibility into what running systems are doing, because you cannot contain what you cannot see.
Step 7: Rehearse once, out loud
Our fictional clinic holds a ninety-minute desk exercise. The facilitator reads a scenario card: “At 8:40 the scheduling system will not open and a message demands payment.” Participants say what they would do, in order, and the facilitator keeps a list of every moment someone says “I thought you were doing that.” By the end the list has eleven entries. That list is the real product of the session. The Atlas recommends an executive-level tabletop in the third month, with the most serious gaps fixed immediately afterwards.
Step 8: Pick a few numbers, and keep them honest
After a real or practice event, the office records a handful of timings: how long the intruder had been active before the first alert, the delay before anyone formally declared an incident, and the hours containment needed. It compares the first guess of how many systems were touched with the final count, since the Atlas’s example shows a jump from six to fifteen. And each quarter, the office checks how many times an intruder returned, what share of notices went out on time and how many stored evidence items still matched their original fingerprints.
None of these figures should be used to blame people. They are there to show where the next hour of practice is best spent. Readers who want to see how an organisation might manage the pipeline that produces such figures can browse a guide to keeping data workflows reliable and tidy.
What happens on the next Tuesday
Return to the opening scene with the eight steps in place. The receptionist mentions the odd message. She knows the number to call, the operations manager declares an incident within minutes, and the team joins the bridge. Nobody restarts the machine. A technician copies memory first, the lead opens the deadline table, and the sponsor knows she may approve a short, recorded pause before cutting anything off. The day is still stressful, yet it has an order.
The ambition is modest, and the Atlas does not oversell it: it describes a ladder from improvised to adaptive and encourages teams to climb one rung at a time. For the full discussion, including standards, traps and a scoring example for choosing between an internal team, a retainer and a managed service, see the Ops Atlas page that explains ResponseOps in depth. Start with step one this week, and add the rest over a quarter. Your future Tuesday will thank you.
