Run an Account Recovery Tabletop: A Facilitator's Guide

What should an account recovery tabletop produce?

A decision record that connects each proposed action to evidence, authority, and an expected result. Use fictional injects to test handoffs, then assign up to three improvements with concrete retest conditions.

This exercise tests whether the help desk, identity team, incident responders, and application owner can act together when an employee disputes account recovery. It builds on the verification decision guide and the TAP enrollment example. Bring the current recovery procedure so participants can test the process they would actually follow.

The exercise takes 90 minutes. Every persona, record, and outcome below is fictional. It is discussion only: no live account changes, employee calls, or production queries. Record any proposed technical validation as follow-up work.

The 90-minute agenda

Start with scope and roles, then release five injects: unavailable verification, ambiguous account change, unfamiliar enrollment, employee dispute, and incomplete closure. Reserve minutes 68–80 for the evidence review and 80–90 for up to three owned improvements. The agenda table gives each interval and output. — Release one inject at a time. Keep the last 22 minutes for reviewing the decisions and defining follow-up tests. Open full-size diagram.

Minutes	Focus	Required output
0–10	Scope and roles	Two objectives and decision authority
10–20	Verification route unavailable	Proceed, pause, or escalate
20–32	Ambiguous account change	Exact administrative operation requested
32–44	Unfamiliar enrollment	Plan to establish method control
44–56	Employee disputes recovery	Response proposal and authority
56–68	Closure evidence missing	Application verification task
68–80	Review the record	Separate facts, assumptions, and proposals
80–90	Choose improvements	Up to three owners, dates, and retests

Prepare a small evidence pack

Use the fictional employee Jordan Lee and a project portal. The first caller claims to be Jordan and reports a lost phone. Later, Jordan disputes the request. Give participants one inject at a time so that later facts do not justify earlier decisions retrospectively.

Prepare the recovery procedure and escalation directory with version dates. Add the five read-aloud prompts below to a facilitator-only sheet. Mark each prompt as exercise material. When someone requests information the case does not supply, answer “not provided” and record the request. Do not invent a favorable result.

NIST’s recovery guidance provides background on recovery methods and authenticator binding. Use your organization’s applicable assurance requirements when selecting the real procedure. A tabletop does not demonstrate compliance. NIST: account recovery

Decide who can approve each action

Role	Decision or output
Facilitator	Releases injects and keeps the exercise within scope
Recorder	Retains decisions and the information available at that time
Help desk	Selects the approved verification and escalation route
Identity engineer	Identifies the account change and enrollment questions
Incident lead	Authorizes and coordinates the proposed response
Application owner	Defines the portal-session verification task
Business representative	Identifies a workable temporary arrangement for Jordan

Keep a separate facilitator and recorder. Before the first inject, ask each participant which decision they can make and which requires someone else. If the decision maker is absent, record that gap. Nobody in the room inherits their authority.

Use a decision record throughout

Field	Entry to capture
Inject and time	Information available when the decision was made
Decision	Exact action proposed or approved
Basis	Procedure section or supplied case record
Assumption	Unconfirmed fact the decision relies on
Authority	Role permitted to approve or perform the action
Verification	Observation that would establish the intended result
Follow-up	Unresolved question, receiving role, and checkpoint

A useful entry names a task: “Identity engineer to identify the added method and reconcile it with Jordan’s approved replacement.” “Investigate account” is not enough to run a handoff. Keep earlier entries if later evidence changes the decision.

Minutes 0–10: establish the rules and expected outcome

Choose two objectives, such as handling an unavailable verification route and coordinating application-session review. Confirm discussion-only boundaries. If real credentials or a real incident appear, pause and route that issue through the normal operational process.

Minutes 10–20: inject one, the unavailable verification route

Read aloud: “The caller says Jordan’s phone is lost. The normal verification route is unavailable. The caller offers a new contact number.”

Require the help desk to identify its procedure branch and select proceed, pending, or escalation. Ask where the callback destination comes from and who may authorize a contact change. Before advancing, capture the receiving role and what Jordan would be told next. Watch for participants discussing how to reset the account before establishing authority to do it.

Minutes 20–32: inject two, an account change is reported

Read aloud: “An administrative summary says ‘MFA reset completed at 09:18.’ It gives no exact operation or verification reference.”

Ask the identity engineer to specify the record needed to distinguish a password reset, method change, or session action. Ask the help desk for the verification reference separately. The output is a precise evidence request, not a guess at what “reset” meant.

Minutes 32–44: inject three, an unfamiliar enrollment

Read aloud: “A method was added after recovery. Its controller is not established. Jordan’s manager cannot confirm that recovery was requested.”

Ask which record identifies the method, how the intended employee will be contacted through an approved route, and what would justify escalation. If removal is proposed, ask what it would change and which application questions would remain. The method’s presence alone does not establish a data read.

Minutes 44–56: inject four, the employee disputes recovery

Read aloud: “Reached through the approved contact process, Jordan denies requesting recovery and does not recognize the method. A project deadline is approaching.”

The incident lead must name the objects in the response proposal and the authority for each action. The business representative should identify the function Jordan needs to continue, rather than merely approve disruption. Capture the proposed temporary arrangement and who would authorize it.

Minutes 56–68: inject five, closure evidence is incomplete

Read aloud: “The unexpected method was removed. The portal-session state has not been checked, and no application operation result is available.”

Require a status update that distinguishes completed work from pending verification. Ask the application owner to name the protected operation, approved test context, expected result, and recipient of a failed check. The correct exercise output is a defined task; no technical result has been demonstrated in this room.

Minutes 68–80: compare decisions with evidence

Read the decision record in order. Mark each entry as supported by supplied evidence, a proposal awaiting evidence, contradicted, or not addressed. These are exercise labels, not platform statuses or a security score.

Ask where one function needed information another could not provide. A missing escalation destination, inaccessible enrollment record, and undefined application check are different problems. Keep them separate in the debrief.

Minutes 80–90: assign three improvements

Select at most three gaps that changed a decision. This illustrative action register shows the level of specificity needed:

Exercise gap	Improvement	Retest condition
No recipient for an unavailable verification route	Approve a named escalation destination	Repeated request reaches that role while the change remains pending
“MFA reset” hides the operation	Record the exact change and audit reference	Reviewer can identify the operation without interviewing the original agent
Portal closure cannot be verified	Define an application-specific protected request	Authorized test records the expected post-response result

Add a named owner and due date to each selected action. Use the containment review when designing the last test. It separates application sessions, tokens, methods, devices, and grants so that one completed action does not close five different questions.

Check that the fix works

Confirm that an escalation reaches its owner, that an enrollment review identifies the disputed method, or that an application test establishes the post-response session state. Report that result alongside the original finding.

Facilitator files

The CSV files reproduce the tables above for editing. Fictional case entries are examples to replace, not collected evidence.