OpenCyber AcademyDay 15 — Hand over a bounded request with an observable next state
Mechanism. An escalation transfers a decision and its evidence boundary to a role that can accept it. A useful message specifies checkpoint, present observations, priority rationale, pending authority, a bounded request and what receipt would change the record. A request-state row then separates drafted → submitted → approved → executed/reported → received → checked. Not every organization uses those labels, and an operator report may precede independent receipt. The important property is that one state never substitutes for evidence of another.
Assumptions and evidence. At the C08 checkpoint, no detailed export is in the case and no restriction is approved or executed. The incident lead coordinates; the identity/data custodian must approve and perform permitted source access under local rules. The application owner separately checks authoritative S42 state/version. C01's missing after-hours alternate is a documented fallback gap, not proof that the daytime custodian is currently unreachable. A 10:00 expiry statement creates urgency; it does not authorize a broad export or establish that the records have already vanished.
Worked contrast. “Please investigate the compromised account; data secured” asserts two unsupported outcomes and leaves scope open. A bounded alternative asks for svc-enroll IdP records over proposed 08:50–09:05 UTC, source and query metadata, an identified approver/operator and an execution/receipt plan before the reported expiry. The custodian must validate the window against source clock and ingestion semantics. If the relevant event lies outside that scope, revise the request explicitly; do not silently claim the initial scope was exhaustive.
Keep the operational states reviewable with a small sidecar in the case, not another manuscript:
Lesson table; scroll horizontally to read all columns →
| Request | Current status at 09:14 | Evidence needed for the next state |
|---|---|---|
| Narrow IdP preservation | Draft/proposed; C08 supplies an expiry statement | Actual authorized acceptance, followed by operator/copy receipt and later integrity/provenance checks |
| S42 authoritative-state comparison | Proposed to application owner | Permitted read with source, version, read time, comparison criterion and owner interpretation |
| Account-wide restriction | Not approved or executed | Separate impact, scope, permission, operator, rollback and verification gates |
The table is an authored plan, not a set of newly observed CTN events. Chapter 4 explains why receipt and byte verification remain distinct. Neither a hash alone nor a screenshot will prove that an export is complete or authentic.
Decision. Send the fictional handoff for review with a specific checkpoint and an immediate-change trigger. An analyst-proposed 09:25 review can expose a blocked preservation path early. Major verified service harm meeting the local P1 threshold warrants earlier reprioritization; receipt of one export primarily changes preservation status and knowledge, not necessarily severity. State what kind of new result would justify a downgrade instead of making “before expiry” the only instruction.
Practice. Complete EX015: a 90–150-word escalation plus the separate request-state row. Preserve the original task's C01 gap and all C02–C08 limits. Compare the worked answer, checking that neither proposed approval nor a hypothetical example is narrated as an accomplished action. Limit: a clear message can make a blocked decision visible; only actual authorized action and checked evidence can resolve it.
Continue studying — course Day 15: Previous: Day 14 · Week 3 index · Course index · Next: Week 4, Day 16.
Exercise for this lesson
EX015 — Shift escalation. Objective: hand over an actionable decision without overstating progress. Input: C01's owner-gap context and C02–C08 at 09:14; no later receipts. Compose a 90–150-word message to the incident lead with source-bounded observations, provisional priority, a narrow IdP preservation request, separate S42 state check, the C01 fallback gap and a concrete review checkpoint. Name a verified condition that would change priority. Outside the word-limited message add a request-state row naming current status, accepting role and evidence required for the next state. Rubric: 0 = invented join, permission or completed preservation/restriction; 1 = accurate message but missing scope, owner, priority-change condition or request-state evidence; 2 = actionable bounded message and row, correct checkpoint/release limits, explicit pending authority and justified reprioritization trigger. The message is a classroom artifact; do not contact real people. Worked answer.