After-action review and unavailable-approver branch

Week 4, day 2. Work through the teaching and the worked checkpoint before attempting the assigned exercise(s). Compare your artifact with the final worked result only afterward.

4.6 After-action review

Close the tabletop with three questions: What helped us decide? What slowed us down? What will we change and how will we check it? Separate a one-time case correction from a reusable program improvement. For example, correcting B19 and B20 fixes two bookings; naming the booking service owner and rehearsing the approval path improves readiness for the next event. A good improvement ticket has an owner, a deadline and an observable test.

For this case, the team can turn the V1 audit failure into a testable improvement: assign the application and audit owner to find why the synthetic change lacks an actor identifier; require a new controlled test that produces the correct actor and UTC time; and have the response lead review the evidence before retiring any compensating monitoring. The ticket should also state what staff should do while attribution is incomplete. This is a program control improvement, distinct from correcting individual bookings. Another ticket could require the recovery lead to repeat an isolated restore and record its duration, source timestamp and booking comparison. An empty “review backups” task is not measurable.

The team should not call the case “resolved” merely because the tabletop ends. In the fictional facts, identity attribution and root cause remain open. The course ends when the learner can hand off that uncertainty safely, describe what evidence would close it and show how the organization will review its response process.

4.7 What this exercise can measure

An exercise can produce an excellent discussion while leaving a technical control untested. NIST SP 800-84, sections 4–6 distinguishes tabletop exercises, functional exercises and tests. Its 2006 examples need local review before use in a contemporary environment; the distinction between talking through a plan and measuring a system remains useful here. The Harbor Library tabletop asks participants to reason from supplied records. It does not contact an identity provider, pause writes or restore a database. Its score is evidence about a learner's reasoning in this classroom, not a measurement of a real organization's recovery capability.

Before the first inject, write a measurement contract: objective, observable participant behavior, evidence to collect, success threshold and a claim the exercise cannot establish. This prevents a facilitator from deciding after the fact that an engaging discussion must have met every objective. The contract below is specific to the fictional case. Its thresholds are OpenCyber Academy classroom choices, not NIST requirements.

Lesson table; scroll horizontally to read all columns →

The first two rows are primarily process evidence. The last row points toward a separate technical test plan. A useful learner answer names the boundary: “We rehearsed who would request a restore and what its acceptance conditions would be; we did not execute or time a restore.” This sentence can be true even if every participant completed the tabletop successfully. Its honesty makes the next test easier to design.

To turn an untested recovery claim into an authorized test, the recovery lead would need a named isolated environment, a specific approved copy, a measured start and end time, expected booking values, an operator, a verifier and a safe stop rule. A service owner would then compare that test result with an approved business target. If the test failed, the evidence belongs in the improvement plan. If it passed, it would support only the tested copy and configuration; it would not identify the earlier desk-a operator or establish that a later production return would behave identically. The present classroom supplies none of those measured values. R23 is a backup-job statement, and V1 is an isolated-copy access and audit trial with a failed actor field.

An observer must record what participants did, not only what they said they would do. For this discussion exercise, the record is the frozen Round A–D notes, the facilitator's release ledger and the six submitted artifacts. If a participant says “we preserved R9,” but the only artifact is a request with no collected copy, record the request as observed and preservation as unverified. If the facilitator accidentally reveals P1 before Round C, record that deviation: the learner's later containment choice may be informed by evidence that the intended exercise withheld. Do not hide a compromised exercise run behind a high numerical score; repeat the affected decision checkpoint under correct release conditions.

A two-minute review: for each of the six artifacts, draw two columns labeled observed in exercise and requires another test or source. Put the approved-action record in the first column if its fictional approvals are recorded. Put restore time, production audit coverage and a real customer impact measurement in the second. If an item appears in both columns, narrow the claim until the columns no longer conflict. This review is optional practice and is not one of EX039–EX050.

4.8 A worked after-action report and improvement plan

NIST SP 800-84, section 4.5 and Appendix A describes evaluation that records exercise background, observations and recommendations. The following original classroom report applies that general structure to the Harbor Library model path; it is not a copied NIST template and is not a report from an actual organization. It shows a learner how to connect each proposed improvement to an observation and to a later verification activity. In a real exercise, the report author must obtain the actual facilitator notes and participant feedback rather than infer that the model path occurred.

Report identity and boundary. Case HL-IR-001; exercise type: facilitated, discussion-only tabletop; scenario: fictional room-booking edits and uncertain use of desk-a; rounds A–D; model path: Branch S. Participants are roles—incident lead, analyst, service owner, recovery lead, identity administrator and communications contact—rather than named real people. R1–R24, Branch S, P1/C1 and V1 are classroom cards. No production identity action, database correction or customer notice was performed. The report does not estimate actual business loss, compromise probability or restoration duration.

Predeclared objectives. O1: open an evidence-bounded case record by the Round A checkpoint. O2: make a narrow preservation request before the Round C response choice. O3: document the authority and verification plan for a reversible containment action. O4: refuse an unconditional normal-service declaration when the later booking comparison or audit test fails. Each objective has an artifact in section 4.7. The six-output score from section 4.5 supplements, but does not replace, these four objective checks.

Observed model trace. The worked Round A intake cites R1, R3 and R4 and leaves the service-owner answer pending; that supports O1 for this model, not for an unseen student submission. In Round B, the model requests a narrow audit copy before choosing a containment option; R15 makes the retention question urgent, but the record has no collector receipt, so O2 is met as a request and preservation remains unverified. At Round C, the model recommends session revocation, names the fictional incident lead and identity owner as approvers, and leaves service-owner authority for a write pause separate; this supports the decision-record part of O3. Branch S later reports revocation at 09:45, but the query covers only its stated range. A learner who writes “all unauthorized access stopped” would fail the verification portion of O3. In Round D, P1/C1 shows two mismatches and V1's actor field is blank, so the model withholds unconditional recovery; O4 is met for the model path. The model does not supply an actual restore-time measurement.

Lesson table; scroll horizontally to read all columns →

The table does not claim these improvements have been implemented. A recommendation becomes an assigned action only when a named owner accepts it, a due date is recorded and the acceptance evidence is agreed. In the model's improvement plan, the response lead owns the first follow-up meeting; the service manager owns the contact and authority record; the evidence custodian owns the export receipt procedure; and the application/audit owner owns the V1 attribution investigation. Set dates from an actual exercise calendar. A classroom learner can propose “within 30 days of the tabletop” but must label it a proposed deadline until the fictional owner accepts it.

Independent closure rule. The person who implements a change should supply the test artifact; a different reviewer should decide whether it meets the predeclared criterion. For the audit issue, a configuration change or a filled ticket is not closure. The reviewer needs a controlled edit with the expected test actor and UTC time, a pointer to the resulting log and a statement of the tested scope. A pass in one isolated environment does not automatically cover every production path. If the test fails or the owner cannot produce the artifact, keep the ticket open and keep any approved interim monitoring in place. This is a classroom quality rule for the plan, not a universal legal or regulatory closure standard.

What to report to management. A concise summary can state that the model discussion surfaced a missing initial owner contact, a preservation request without a copy receipt, and two failed recovery acceptance criteria; it can name the proposed owners and next tests. It should also state that no live system was exercised. The report should not say “the incident was contained,” “the backup worked,” “no personal data was affected” or “the cause was found.” Those sentences exceed the supplied cards. The after-action report's function is to guide a better next exercise and test, not to manufacture a resolved case.

4.9 Optional replay lab: the service owner cannot be reached

This separate replay variant starts from the Round C decision point; it does not alter R1–R24 or the reference Branch S/P cards. Keep your original Round C note, then make a fresh copy labeled HL-IR-001-REPLAY-F1. The purpose is to test whether a learner can continue evidence work while withholding an action whose required approver is unavailable. The replay is a discussion only. It does not authorize a real session change, write pause or data collection.

New card F1, revealed at simulated 09:35 UTC: the booking service owner is temporarily unreachable, and the response plan lists no confirmed alternate for approving a staff-write pause. The incident lead and identity owner remain reachable for a narrowly scoped session decision under the fictional rules already stated in section 3.3. R21 still describes the owner's tolerance for a fifteen-minute pause; it does not become an approval because the owner is absent. R17/R18 are available at this Round C point. Branch S/P results, P1/C1 and V1 remain withheld until the ordinary Round D sequence.

Task: write two decision records at 09:37. Record A is a bounded recommendation that the reachable incident lead and identity owner could approve or reject for the current desk-a session. Record B is a proposed staff-write pause marked approval pending, with a reason it might be needed, its service cost, who is being contacted, what evidence can still be reviewed meanwhile and a stop or escalation trigger. Then prepare a one-sentence handoff for the next response lead that says which action, if any, was reported executed at 09:37. No execution card exists at this point, so the answer must say none is reported. The objective is not to force Record A to be approved; a learner may defer it with an explicit risk and review time.

Inputs and authority check: use R17, R18, R21, the option matrix in section 3.3 and the Module 1 role boundary. The incident lead can coordinate an escalation and request a contact check; the identity owner can approve or reject the scoped session action with the incident lead in this fictional exercise. Neither role has been given authority to approve the booking-service write pause alone. The analyst may prepare a reversible option and examine already supplied records; a production audit export would still require its own collection authority and custody record. Do not call a missing reply consent.

Expected artifacts and rubric: submit Records A and B plus the one-sentence handoff. Award one point each for (1) preserving the distinction between R21 tolerance and approval, (2) recording the two reachable approvers and a bounded verification for Record A, (3) leaving Record B pending and documenting the affected queue/service cost, (4) naming an allowed next evidence or escalation step with a review trigger, and (5) stating that no 09:37 execution has been reported. A 5/5 response can choose a different defensible risk tradeoff; it cannot invent an alternate owner, use a later branch result or claim that a write pause was already enacted. A model answer appears after the 50 numbered worked results.

Why replay matters: if two students choose different proposals yet both respect the same approval boundary, the exercise can distinguish justified decisions from lucky outcomes. If F1 changes the decision, compare the original and replay records field by field: which observation changed, which authority became unavailable, which action was held and which review trigger became more urgent? Only the authority fact changed; the underlying R17/R18 evidence did not. That comparison teaches a reusable response habit without treating a fictional facilitator card as real incident evidence.

4.10 Optional communication replay: a request for reassurance and an unverified claim

An incident can have a technically careful case record and still cause harm if its updates promise more than the evidence supports. The operational team may need details about a specific account and booking IDs; patrons need a useful description of the affected service and where to get help. A privacy contact may need the exact origin of a new exposure claim. These audiences do not need identical messages, and an internal coordination note is not automatically a public statement or a formal notification. NIST SP 800-61 Rev. 3, RS.CO and RC.CO discusses incident reporting, coordination and approved recovery communications. The message cards, word limits and scoring rule here are original teaching devices, not prescribed NIST wording or a determination of any notification duty.

This separate after-Round-D replay uses Branch S unless a learner clearly marks a Branch P alternative. The canonical R1–R24, Branch S/P, P1/C1 and V1 retain their meanings. No new card may be used to justify the earlier 09:37 choice. Write only in a local Markdown exercise file; do not send a message to a real person or publish one. The fictional organization has not supplied its legal jurisdictions, contracts, notification thresholds or approved external spokesperson, so the exercise cannot decide that a statutory notice is or is not required. It can identify who must assess that question.

Card M1, released at simulated 09:50 UTC. A front-desk supervisor asks the communications contact: “May we tell patrons that bookings are restored and the problem is over?” The request is a question, not evidence that service has returned. Branch S reports a session revocation at 09:45 and a quiet bounded booking query. P1/C1 still shows B19 and B20 inconsistent with the approved target, while V1's isolated test has a blank actor field. The record has no owner-approved production correction, no full-service acceptance and no production audit pass. A reassuring sentence would be easy to write and hard to defend.

Card M2, released at simulated 09:52 UTC. The communications contact receives a forwarded internal chat sentence: “Someone said the newsletter list was stolen.” It contains no original author, time of alleged access, source system, export record or case reference. It establishes that an unverified statement was received, not that data was accessed or exported. R24, recorded at 09:36, says that no record then established access to the newsletter list or another personal-data store. R24 is not a permanent all-clear; M2 is not proof that R24 was wrong. The privacy contact and incident lead should receive a narrowly framed verification request through the fictional approval route, with the original forwarded item preserved as a report of a claim and its provenance gap stated.

Decide which communication you are drafting

An incident coordination update tells the response roles which action was reported, what test failed, who is doing the next check and when the next decision is due. It can include restricted case identifiers if sent through an approved internal channel. A service status draft gives patrons a useful description of a booking discrepancy and a safe way to check their own booking, without revealing an account label, unsupported root cause or another patron's information. A formal incident or privacy notification is a separate, approval-dependent decision made under applicable procedure by designated roles; the sparse classroom record cannot resolve it. A rumor should be routed for assessment, not quietly appended to a patron message as if verified.

Versioning matters because evidence changes. A 09:37 proposal, a 09:45 reported action and a 09:54 communication draft are three different states. If a team previously sent “all bookings restored,” it should not erase the old version and pretend the assurance was never made. Keep the issued wording, audience, time and approving role; issue a clearly linked correction through the same approved route with the new evidence and a next update. In this exercise there is no issued earlier message. A learner may practice correcting an explicitly hypothetical flawed draft, but must not claim that Harbor Library actually made it public.

Use this small claim-to-message ledger before drafting:

Lesson table; scroll horizontally to read all columns →

The ledger deliberately distinguishes false or contradicted, unverified, and conditionally useful claims. A sentence may be accurate for one restricted audience but inappropriate in a public draft because it exposes unnecessary operational detail. A status note should tell its reader what to do with the information. “Investigating” alone does not tell a front-desk worker how to handle a disputed booking; “all clear” would be worse. The correct short update states the present limit and the next responsible check.

Practice: produce a versioned communication packet

Write four Markdown artifacts, all marked draft, not sent. First, a five-row claim ledger based on the table above, adding the record or card ID and the earliest round in which each claim became assessable. Second, a restricted 09:54 internal update of 80–120 words for the incident lead, service owner, front-desk supervisor and privacy contact. State what Branch S reported, which booking and audit criteria remain open, the status of M2 and who will check each issue. Give a fictional next review at 10:05 UTC; it is a planned checkpoint, not a guaranteed restoration time.

Third, write a patron-facing holding draft of 45–80 words for approval by the service and communications owners. It may say that the library is reviewing discrepancies affecting room bookings and will provide an update after verification. It should offer a practical contact route only as a proposed, owner-confirmed route. It should not name desk-a, claim that a breach occurred, declare the booking service fully restored or say that no personal data was affected. The student is drafting a possible message, not deciding to publish it.

Fourth, write a privacy assessment request of three to five sentences: identify M2 as an unattributed report, mention R24's earlier limited finding, ask what authorized source or custodian could verify newsletter-list access in a bounded period, and name the incident lead/privacy contact as decision partners. Preserve the forwarded wording only in the restricted exercise record; do not copy a real person's message. If the result later supports a breach, route notification assessment to designated decision makers under the organization's actual procedure. If the result does not, record the tested scope and residual gaps rather than announcing universal absence of exposure.

Branch P variation: replace the Branch S line in the internal update with the 09:45 service-owner report of a fifteen-minute staff-write pause and two manual-queue requests. At 09:54, the planned pause has not reached its 10:00 end; do not say writes resumed. The service owner must reconcile the queue and approve the next state. The patron draft should not promise that ordinary booking writes are available. Keep M2's evidence status unchanged: a different containment branch does not make an unattributed claim true or false.

Optional correction drill: suppose a fictional earlier draft, not an issued statement, read “All bookings are restored and no customer information was affected.” Mark both clauses unsupported or contradicted, retain it in a version log as draft-v0, and produce draft-v1 linked to P1/C1, V1 and M2. If the sentence had already been sent in a real organization, an authorized communications lead would need to assess and issue a correction through the proper channel; the learner cannot decide that process from these synthetic cards.

Assessment rubric (six points): one point for a ledger that dates and classifies all five claims; one for an internal update that distinguishes Branch S's narrow action from the unresolved booking and audit checks; one for a patron draft that is useful without premature restoration or breach claims; one for routing M2 to a bounded privacy assessment without treating R24 as a permanent all-clear; one for naming approvals, audience and a 10:05 checkpoint; and one for retaining version history and correctly handling the Branch P or correction variation. A perfect classroom score demonstrates careful wording under these supplied facts. It does not establish that the communications route works in a real incident or that a legal notice is unnecessary. A model packet follows the F1 replay result in the final appendix.

Worked checkpoint

An unavailable service owner creates an approval gap. The team may preserve facts and seek the documented alternate, but neither an unanswered message nor an exercise role-play grants permission for an unapproved service change.

Practice — Lesson 17

EX043 — Preservation request

Objective: request time-sensitive evidence without a fabricated deadline. Inputs: Round B, R9, R14–R15 and Module 2's preservation fields. Output: a request naming source, booking IDs or bounded event interval, necessary fields, policy-clock question, approving role, collector, restricted storage/access and actual collection status. R15 says detailed audit records are deleted after 24 hours unless copied; ask the custodian what starts that clock rather than calculating an exact expiry from R9 alone. A score of 2 says requested until a copy and collection time are documented.

DEL4 extension: Separate a preservation request drafted, its receipt by the authorized custodian, and a collected and checked copy. State the escalation when receipt is unconfirmed; none of these stages supplies R15’s missing policy-clock anchor.

Worked answer: EX043 in the final appendix.

EX044 — Decision checkpoint

Objective: make a reversible 09:37 recommendation. Inputs: Round C, R17–R21 and the section 3.3 option matrix. Output: a decision card with current evidence and uncertainty, chosen proposal, approver and executor, intended benefit, uncovered path, service cost, preservation note, fallback, verification plan and 09:45 review. Give separate proposed, approved, executed and verified states; mark any state without a receipt pending. Include one check for the protective effect and a different check for legitimate staff service. A score of 2 treats R21 as tolerance rather than approval or execution and does not cite the Branch S/P result before Round D.

DEL4 extension: Add a separate coordination-message field for proposed, authorized-to-send, attempted, delivered and current-version role acknowledgement. A recipient’s read-back of the proposal is not action approval or evidence that a control was executed.

Worked answer: EX044 in the final appendix.

EX045 — Branch S review

Objective: bound what a successful session action actually demonstrates. Inputs: Round D Branch S only, before P1/C1 or V1; earlier R1–R24 remain available. Output: a four-row claim ledger with two supported claims and two unestablished claims, each with branch pointer and limit, plus one authorized next check with scope and owner. A score of 2 limits the “no later edit” observation to the branch query's range and does not claim eradication or correct booking state.

BH4 blind-receiver check: For each existing row, verify that a cold receiver can locate the Branch S pointer and explain its limit without asking the sender. A missing pointer is a packet defect, not proof that a booking check passed or that revocation failed. Keep this answer at the branch-only checkpoint.

Worked answer: EX045 in the final appendix.

EX046 — Branch P review

Objective: account for operational effects of the pause. Inputs: Round D Branch P only, before P1/C1 or V1; R21's tolerance. Output: a queue-and-return note with the two pending requests, who holds them, a verification that writes were blocked, an owner-approved resume condition, a signal to keep the restriction, and the next checkpoint. A score of 2 does not mark the two requests fulfilled or the cause resolved and gives an explicit reconciliation step before resumption.

DEL4 extension: In Branch P only, add a proposed instruction envelope for the front-desk receiving role: the two requests stay pending until owner-approved reconciliation. Version, authorized route and read-back are required in a future test; mark all actual dispatch and receipt fields not supplied here.

BH4 blind-receiver check: Have a receiver state what is known about the two unnamed pending requests, who may approve resumption, and what current write state remains unverified. Do not import MQ3 or the later P1/C1/V1 cards, and do not infer automatic return from the fifteen-minute plan.

Worked answer: EX046 in the final appendix.