Hand over a time-bounded decision, not a success story | Professional Incident response and cyber resilience

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Day 5 — Hand over a time-bounded decision, not a success story

Learning decision. Can a new shift reconstruct what was known, proposed, decided and done at that time? Keep event time, receipt/release time, decision time, operator time and verification time in different fields. A source event with an earlier timestamp cannot justify a decision made before the source was available to the responder. The Chapter 3 release sequence will test this explicitly. At Chapter 2's C02-only checkpoint, 09:04 is a support receipt, approximately 09:00 is a reporter's estimate, and no change, approval or source export has a documented execution timestamp.

Make the decision log append-only in meaning: preserve v1 when a new observation prompts v2, even if the medium stores them as revisions. A correction should identify what changed and when it became known. Otherwise a later analyst might read a polished final narrative as if earlier responders already had all the evidence. This is particularly dangerous when assessing why a protective action was delayed. A versioned log must let a reviewer reproduce the decision basis at the cutoff, not merely the final outcome.

Lesson table; scroll horizontally to read all columns →

Field at the 09:04 CTN checkpoint	Defensible entry	Unsupported promotion to reject
Observation and source	C02 received 09:04; S42 reportedly unavailable, first noticed around 09:00	“S42 database state confirmed at 09:00”
Inference and alternatives	Cause, actor and current authoritative state unknown	“Compromised service account caused it”
Action state	Case intake and bounded state/owner questions proposed	“Account disabled and containment effective”
Next review	Service-owner response, permitted source receipt or verified evidence-loss warning	A fictional fixed deadline derived from “24 hours”

Worked example. An incoming shift sees a note: “09:04: approve S42 export; disable if needed.” It cannot tell whether “approve” is a request, decision or action, nor what “if needed” means. Rewrite as four lines: “Observation: 09:04 C02 received; reporter noticed a possible S42 issue around 09:00. Inference: current S42 state and cause unverified. Action state: case opened; request for owner-authorized, limited S42 check proposed; no source export, restriction or notice recorded. Trigger: review on owner result, valid source receipt or verified short retention warning.” This does not decide the incident in advance. It gives a second responder a precise next question without changing the historical C02 record.

In the separate W2 rehearsal, a later SIM-DEC-01 can be recorded only after its fictional role, exact tuple and time have been checked. If the operator never acted, state “approved, not executed”; if an operator reports action but the bounded effect was not measured, state “reported executed, unverified.” The first state must not be rewritten as the second because a calendar slot for work was booked. A handoff needs both a decision ledger and an operation/effect ledger, even if one is empty. NIST SP 800-61 Rev. 3 supports improving coordination and response; these specific log fields and scoring are this book's teaching design.

Practice. Submit EX010 as four source-linked lines, then add the record version, knowledge cutoff and one condition that would falsify your current inference. Compare with the worked answer and its Week 2 result. Limit: a well-formed decision record is not evidence that a proposed query or control was carried out. Previous: Day 4 · Week index · Next: Chapter 3.

Exercise for this lesson

EX010 — Decision record. Input: C01, C02 and your EX006–EX009 work. Write a four-line decision log with observation, inference, action status and next review trigger. A 2-point result distinguishes a proposed preservation request from an approved export.

EX010 — Model four-line log. Observation: “09:04 support received C02; S42 reportedly unavailable, first noticed around 09:00.” Inference: “Potential enrollment issue; cause and authoritative state unknown.” Action status: “Case opened, service/identity owner contact and bounded preservation request proposed; no export, restriction or notification recorded.” Trigger: “Revisit after owner state check, relevant source receipt, new reports or a verified retention deadline.” This preserves what the analyst knew at 09:04.

Additional worked reasoning (EX010 — Decision record at the correct time.): Four lines: (1) observed C02 receipt 09:04 and estimated symptom noticed 09:00; (2) current S42 state/cause unknown, no justified compromise finding; (3) case opened, limited state/owner questions proposed, no approved export/account change; (4) review when a permitted authoritative state response, corroborating event or verified evidence-loss warning arrives. A later C03 sign-in is forbidden at this checkpoint even though its event time is earlier. A concise source-linked four-line answer is preferable to a long confident story unsupported by C02.

Week 2 applied result (EX010). Header: CTN-IR-014 / decision v1 / knowledge cutoff 09:04 UTC. Four lines: (1) Observation — C02 received at 09:04; reporter estimates S42 unavailable since about 09:00; authoritative state not checked. (2) Inference — possible enrollment issue, with cause and actor unknown; a benign state/report mismatch remains possible. (3) Action state — case opened, limited owner-authorized state question proposed; no export, restriction, account change or learner notice recorded. (4) Review trigger — permitted authoritative response, a corroborating source receipt or a verified loss window. A falsifier for the tentative “current issue” inference would be an approved authoritative S42 state/version showing normal availability at the relevant time, interpreted with the reporter's viewing context. A later C03 release belongs to a new version; an earlier event timestamp alone cannot enter v1.

C2 worked action-state rehearsal for EX007/EX009. Executing the exact Chapter 2 Python fixture prints:

C2|v0=PROPOSED_ONLY
C2|v1=APPROVED_NOT_EXECUTED
C2|v2=EXECUTED_UNVERIFIED
C2|v3=VERIFIED_WITHIN_SCOPE

These are toy Boolean states, not CTN action receipts. At C02, the actual account-disablement proposal is still pending with no scoped approval, execution or effect check. The action tuple must name target, environment, method, accepted service cost, authorizers, operator, duration, verification and rollback; “OK to act” in V2 lacks these fields. Removing scope from the fixture after setting approved=True returns PROPOSED_ONLY. Setting checked=True without an execution receipt leaves APPROVED_NOT_EXECUTED. The script cannot authenticate an approver, and V2 never becomes a main-case authorization.