Discuss Ransomware Recovery Through the Customer Workflow

Ransomware readiness conversations lose value when a seller predicts outcomes or turns a hypothetical discussion into an incident diagnosis. An MDR consultant should begin with the customer workflow. Ask which part of recovery they want to examine: detection, isolation, restoration, communications, or a decision handoff. One focused path leads to better questions than a wide fear driven conversation.

State scope at the start. Say, “We are discussing a fictional practice situation, not reviewing an active event. Which recovery decision would your team want to make with less confusion?” This wording gives the customer control over depth. A consultant does not need confidential logs, names, system details, or prior incident material to learn where a workflow needs clearer ownership.

Choose one business service rather than an entire environment. Ask which business activity depends on the service and which team owns normal operations. Then ask which first decision starts the recovery path. A customer might say a security lead decides whether to begin a formal review, or an infrastructure lead decides when a service moves from investigation toward restoration. Record their words without adding a technical judgment.

Move through the workflow as actions and owners. Ask who notices a concern, who reviews available evidence, who contacts another team, who decides whether a service stays unavailable, who confirms a restoration action, and who tells staff or leaders about a status change. Those questions expose handoffs without demanding sensitive detail. Names are useful only when a customer chooses to share them. Roles often work better for a practice discussion.

Suppose a fictional publishing company runs a subscriber portal. Niko, a fictional MDR consultant, asks the security manager, Rhea, which recovery decision feels unclear. Rhea says her team knows who reviews an alert, yet no shared understanding exists around who confirms the portal is ready for normal use after restoration work. Niko does not offer a timetable or a recovery claim. He asks who would need to agree before normal service resumes.

Rhea names an infrastructure lead, a portal owner, and a business operations manager. Niko asks each role which information would support a decision. The infrastructure lead wants confirmation from the team doing restoration work. The portal owner wants a basic functional check from an internal colleague. The business operations manager wants a status update suitable for subscriber support staff. Those answers identify decision inputs. They do not prove a future outcome.

Write the fictional workflow in neutral language. “A security review raises a recovery discussion. Infrastructure coordinates restoration work. The portal owner requests a functional check. Business operations prepares a staff update after named owners agree on service status.” Then mark uncertain steps. In Rhea’s situation, no role owns the moment when input from all three people becomes a final service status decision. This open handoff becomes the subject for a later practice session.

Keep prevention and recovery separate. A customer often shifts from recovery coordination into questions about reducing future risk. Acknowledge the question, then return to the chosen workflow or set a distinct discussion. Mixing both topics encourages loose claims and makes notes hard to follow. Say, “For today, we are mapping who decides service status. Would you prefer a separate session for future prevention questions with your security owner?”

Urgent language deserves an immediate boundary. When a customer describes a current concern, do not interview them for a sales exercise or attempt diagnosis from partial details. Encourage use of their established incident process and approved contacts. Ask whether they need to end the conversation so attention stays with those channels. Keep commercial claims and hypothetical advice out of an urgent response. An MDR consultant should not compete with the customer’s own active response process.

For a planned tabletop conversation, agree on participants before sending an invitation. Invite roles needed for one handoff. A security representative explains how a review begins. An infrastructure representative describes who coordinates restoration work. A service owner describes how normal use receives confirmation. A business representative explains who needs a status update. Do not force every role into every discussion. The selected handoff decides who belongs.

Set a narrow practice situation using fictional details. Niko says, “At 9:15 a.m., an internal review raises concern about the subscriber portal. By 10:00 a.m., recovery work starts. At 11:30 a.m., infrastructure asks who decides whether staff should treat the portal as ready for normal use.” Ask participants to speak only from their assigned role. The group practices ownership, information needs, and handoff language rather than technical speculation.

Watch for vague verbs. Phrases such as “security handles” or “operations communicates” hide decisions. Ask for a clearer sentence. “Which security role starts the discussion?” “Who in operations receives a status message?” “Who gives the final status message to support staff?” A customer might choose to leave an answer open. Record an open answer rather than filling a gap with an assumption.

Use a decision record after the session. Include the fictional trigger, roles present, decision needing clarity, information each role requested, unassigned handoff, and agreed next conversation. Add source notes when participants disagree. Do not label the record an incident plan or state a requirement. The record supports customer owned discussion. Sensitive recovery planning stays with the customer and authorized specialists.

Ask one timing question for every decision. “When does this role need an answer?” A security representative needs a response during an initial review. A portal owner needs confirmation before announcing normal service. Business operations needs a status message before support staff respond to subscribers. Timing questions show whether a handoff happens early enough for each person to act. If one role needs an answer before another role normally provides input, record the conflict and ask the customer which owner should resolve the conflict.

Do not grade customer answers against an assumed model. A small team often uses one person for several roles. A larger organization often needs an additional approval point. Your responsibility is to reflect the stated workflow, show unanswered decisions, and help the customer choose who should continue discussion. Different structures need different records, even when the fictional service sounds similar. A conversation gains value when every participant leaves with a question or ownership decision written in their own terms.

Before a tabletop ends, read back the fictional trigger, the decision under discussion, each input owner, and every unassigned handoff. Ask whether any line incorrectly describes an owner’s work. Send only neutral notes agreed by participants. Avoid language suggesting readiness, coverage, prevention, or technical performance. Ask the designated customer contact which open decision should shape the next practice situation. Their choice decides the next scenario and keeps the conversation within customer priorities.

Return to Niko and Rhea’s fictional portal session for practice. Rhea assigns the infrastructure lead to gather restoration confirmation before next Wednesday. The portal owner writes the exact functional check requested before normal use resumes. At the next meeting, Niko places both notes beside the open final status decision, asks Rhea who will combine the inputs, and records the name selected by the group before they move to another scenario.