Use Incident Readiness Reviews to Find Operational Gaps

Incident readiness conversations require care. A customer sometimes seeks help improving response work while keeping details of past events private. Respecting this limit does not end discovery. A consultant still has useful process questions about coordination, decision rights, communications, handoffs, and evidence people need during a response.

Start by explaining a boundary in plain language. Say, “We do not need details from a recent event. We will use a fictional or customer approved practice situation and examine how people coordinate.” This gives a customer control over discussion content. Do not pressure anyone to name systems, affected parties, alert content, or timelines from a real incident.

Ask, “Which part of response creates the most coordination work?” An answer might concern alert routing, reaching an administrator, deciding who authorizes a containment step, or updating a business leader. Follow with questions about process rather than an event. Who receives a first notice? What tells them whom to contact? Where does a group record decisions? What does each person need before taking a next action?

For a fictional professional services firm, use a scenario involving unusual account activity found late on a Tuesday afternoon. A security lead receives an internal notice and needs an administrator with access to a business system. During a tabletop discussion, participants say a usual administrator works in another time zone. Contact details sit in an old folder. Nobody knows who handles coverage when a usual person is unavailable. This is an operational gap, not a diagnosis of an active event.

Keep fictional scenarios clearly fictional from start through finish. Use invented names, dates, and roles. Say “practice situation” or “fictional scenario” before asking people to respond. Do not blend a customer’s private story into an example, even after removing names. If someone volunteers a real detail, acknowledge the information and ask whether they prefer a higher level process description instead.

Agree on a narrow start and finish for a response map. In the fictional scenario, begin when a security lead receives an internal notice. End when a team reaches an administrator and records an assigned action. This boundary avoids a sprawling review of every security function. Write each step in ordinary language: receive notice, confirm contact path, locate coverage owner, request action, record handoff. Leave technical analysis outside the exercise unless a customer selects such scope.

Ask who holds decision rights at each point. A response delay often grows from uncertain authority rather than lack of effort. One person needs approval for an action, another operates a system, and a third communicates with leadership. Ask participants how they know who has each role. If an answer relies on memory or a private chat thread, record the dependency without criticism.

Ask participants to name an alternate for each role only when their process already uses alternates. Do not invent a staffing model. Instead, learn how coverage is currently determined. A customer might point to a schedule, manager, contact list, or informal practice. Each answer tells you where a new person would search during a fictional exercise. A useful review checks whether people reach a shared source without private knowledge.

Communication deserves equal attention. Ask where a response team receives updates, who sends a status message, and what information belongs in an early update. Do not write an executive message without customer input. Ask which audience needs status, who owns each update, and how often people expect one during a fictional exercise. A clear update path reduces repeated requests for identical information.

Distinguish a documented process from a process people follow under pressure. A folder often contains a contact list, yet a list sometimes lacks coverage information. A runbook often names an approval owner, yet nobody knows how to reach a person after normal hours. Ask participants to find a resource during an exercise. Observe where they search, where they hesitate, and what they need from another person. The exercise tests working access to information rather than document existence.

Use careful notes. Record what participants said, which resource they checked, and which question stayed unresolved. Avoid sensitive details unnecessary for a readiness review. A note such as “coverage contact for business system needs confirmation” helps a customer assign follow up without exposing a real event narrative. Ask where exercise notes should live and who should receive them.

Separate an observed gap from a proposed improvement. Suppose participants search two folders before finding an outdated contact list. Write down the observed sequence first. Then ask what change they want to test. They might choose one shared list, a named owner for list upkeep, or a prompt in an existing response record. Do not represent your preferred process as a required answer. The customer needs an improvement suited to their own working habits.

Select one improvement small enough for a real practice. In the fictional firm, a group chooses a coverage list for a business system administrator. The security lead owns a first draft by Thursday. An operations manager checks names with team leads on Friday. On the following Tuesday, two chosen participants run the same contact step from a fresh meeting invitation. Their goal is to see whether they reach an assigned coverage person using an agreed resource.

Ask what a useful result would look like before a practice begins. A customer might want a documented owner, a reachable contact, or a record of one unresolved gap. Keep a result tied to the selected handoff. A practice involving a coverage list does not answer every question about response coordination. This limit strengthens a conversation because people know exactly what they examined.

When a customer says, “I cannot talk about what happened,” respond without hesitation. Say, “Understood. We will stay with a fictional situation and focus on roles, handoffs, and information people use.” Then offer a process question. “For a late afternoon notice, where would a team look first for a coverage owner?” The reply respects a boundary and keeps work moving.

Avoid language implying a readiness review finds every weakness or prevents future harm. Describe an activity accurately: a structured review of a selected workflow chosen by a customer. Do not predict incident outcomes. Do not label an organization prepared or unprepared after one exercise. A customer and relevant internal specialists retain decisions about their process, response actions, and follow up priorities.

Practice with a fictional customer who begins, “We had an issue, but I cannot share details.” A consultant replies, “Thank you for setting a limit. Would a fictional late afternoon notice work for a coordination exercise?” When a customer agrees, ask who receives notice first and how they locate a needed administrator. If a customer says “someone knows,” ask where a new on call person would find identical information.

During coaching, review whether a consultant obtained approval for a scenario, stayed inside a stated boundary, named an observable gap, and proposed a small owner led practice. Do not score someone for collecting private technical detail. Precision matters more than volume. A consultant should leave a customer with a clear record of what people examined and what they agreed to test next.

For the fictional firm, place a thirty minute Tuesday practice on a calendar. Put a coverage list link in an invitation. Invite a security lead and one administrator, then ask each person to begin from an invitation rather than private notes. After the exercise, an operations manager records whether both people reached a listed coverage owner. If a contact is missing, the manager assigns a named person to correct the list before Friday and schedules a follow up practice for the next Tuesday.