Chapter 1 — Incident lifecycle and organizational readiness

Lesson map

Lesson 01 published. Map, example, EX001.

flowchart TD
  N0["Learning outcomes"]
  N1["1.1 Start with a service, not an alert product"]
  N2["1.2 Case card C01: an incomplete readiness inventory"]
  N3["1.3 A worked readiness handoff"]
  N4["1.4 The service boundary precedes the telemetry boun"]
  N5["1.5 Build a graph whose edges can fail"]
  N6["1.6 Separate readiness assurance from incident asser"]
  N7["1.7 A reproducible offline coverage rehearsal"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX001"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["1.1 Start with a service, not an alert product"]
  N2["1.2 Case card C01: an incomplete readiness inventory"]
  N3["1.3 A worked readiness handoff"]
  N4["1.4 The service boundary precedes the telemetry boun"]
  N5["1.5 Build a graph whose edges can fail"]
  N6["1.6 Separate readiness assurance from incident asser"]
  N7["1.7 A reproducible offline coverage rehearsal"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX001"]

[Learning outcomes]
    |
    v
[1.1 Start with a service, not an alert product]
    |
    v
[1.2 Case card C01: an incomplete readiness inventory]
    |
    v
[1.3 A worked readiness handoff]
    |
    v
[1.4 The service boundary precedes the telemetry boun]
    |
    v
[1.5 Build a graph whose edges can fail]
    |
    v
[1.6 Separate readiness assurance from incident asser]
    |
    v
[1.7 A reproducible offline coverage rehearsal]
    |
    v
[Worked example] --> [Exercise EX001]

Learning outcomes

After this subject, the learner can map a service's dependencies and owners, distinguish preparation from live case actions, write a falsifiable evidence-readiness check, and hand off a bounded gap list. The task is operational: a colleague should be able to use the map during an alert without guessing who owns a log, an approval or a restore.

1.1 Start with a service, not an alert product

An alert says that a sensor noticed a condition. A response plan must begin earlier: which service could be harmed, which business outcome matters, where relevant records originate, who may obtain them, who can authorize disruption, and what would make recovery acceptable. The NIST SP 800-61 Rev. 3 recommendations are organized within cybersecurity risk management, so preparation and improvement belong alongside case handling. For CTN, the service outcome is that a learner can find and enroll in an available class; an identity alert is relevant only through a plausible path to that outcome or to another protected asset.

CTN's invented service map has an enrollment front end, an API that writes slot records, an identity provider (IdP) for staff and automation, a notification queue, a support desk and an object-storage backup. A service map is an inventory hypothesis until an owner verifies it. The same warning applies to a diagram's arrows: an arrow labelled “logs to audit store” does not establish that all write paths produce a record, that timestamps use UTC or that a responder can obtain a copy before expiry. At professional depth, the learner is expected to name a proposed test for each such claim and record the result as untested until run.

Lesson table; scroll horizontally to read all columns →

The owner map needs a primary, alternate, contact channel and decision right for each row. “IT” is not a decision right. An identity custodian may export a bounded log but may lack authority to disable an account; a service owner may approve a short pause but may not personally execute it. If the owner is unavailable, an escalation path must say when to use the alternate. No employee name or contact is required in this public fictional exercise; use role names.

1.2 Case card C01: an incomplete readiness inventory

At 08:40 UTC, CTN's fictional preparation worksheet C01 lists the six dependencies above. It names the application and recovery leads, but the after-hours identity alternate is blank. It asserts “API audit: 24 hours” without specifying whether that means event age, rolling availability, export queue age or a contract claim. The support desk can open an incident ticket, but the escalation contact for an unavailable service owner is missing. C01 is a worksheet discovered before the exercise, not proof that the controls work. At this chapter checkpoint, no alert, compromise or patron harm has been established.

An evidence-readiness contract turns a source name into a testable question. For example: “If a synthetic change to slot S41 is made through the scheduled job, will an authorized analyst retrieve a record with slot ID, request ID, source event time and collection metadata within 20 minutes?” The test requires a permitted training tenant, a specific input, an expected event and a negative control: an unrelated slot S40 should not appear in the selection. Record the result only after a custodian runs it. If the selected export lacks a request ID, the next action is to revise the proposed correlation method; it is not to join by account name and nearby time as if the key existed.

A minimal contract has six fields: decision question; expected producer and fields; time basis and retention; authorized custodian and access path; positive and negative rehearsal; failure signal and fallback. Apply data minimization: if the question concerns slot S41, a full enrollment database export is usually unnecessary. Record whether a copy is proposed, approved, collected or verified. This is a teaching format, not a required NIST form.

1.3 A worked readiness handoff

Suppose the learner is the CTN analyst at 08:45 UTC. A defensible handoff says: “Enrollment is the service at risk. The application owner should confirm whether scheduled and manual changes are audited. The identity alternate and service-owner escalation are unknown. The claimed 24-hour audit retention has no verified anchor. No incident is inferred from C01. Before the next drill, the application custodian and identity custodian should run two bounded training events, record collection latency and compare an unrelated-slot control.” This identifies what to do, who can do it, and what remains unknown. “All logs are ready” would be unsupported.

Readiness priorities are based on decision value and failure consequence, not an arbitrary count of missing boxes. The missing after-hours identity route matters because a short retention window could close before the owner is reachable. The backup row matters because a completed backup job cannot answer whether slot state is correct or usable. The learner should preserve this distinction when later chapters introduce a live signal and an export deadline.

1.4 The service boundary precedes the telemetry boundary

At the C01 checkpoint, Cedar Training Network (CTN) has only a fictional readiness worksheet, not a live security event. The enrollment service's intended behavior is more useful than a list of security tools: a learner selects a class, the front end requests availability, the API checks and changes a slot, the identity layer authenticates privileged calls, a queue may send a notification, and the recovery path must reconstruct a consistent enrollment state. This is an intended service model, not an observed trace. It must not be narrated as if the system has been inspected.

A dependency is anything whose failure could change a meaningful service outcome. Distinguish four kinds. A functional dependency moves or validates enrollment data; an administrative dependency provides decision rights and access; an observability dependency produces evidence about those transactions; a recovery dependency permits a tested return to an acceptable state. One element may belong to several classes. For example, an identity provider can be necessary for staff sign-in and for the audit record that would later explain a privileged edit.

Service owners need a definition of normal behavior that is precise enough to test. "Enrollment works" is vague. An operational criterion might be: "For an authorized synthetic class with one available seat, a reservation request either commits one reservation and returns its new version, or fails without consuming the seat." This proposed invariant is a new teaching test definition, not a fact about CTN's implemented transaction model. A responder should ask the API owner whether partial writes, retries, and queue delays change the invariant.

Consider two incorrect inventories:

• "SIEM, firewall, IdP, backup" names technologies but cannot identify which one supplies the authoritative S42 state, who can access a relevant time range, or which business action it supports.
• "API → database → backup" adds direction but omits decision owners, authorization, evidence retention, scheduled-job write paths and the ability to verify a restore.

A stronger inventory contains a decision question on each edge. "API audit → request correlation" is useful only if the application actually emits a stable request identifier. "Backup → safe restoration" requires a known restore procedure, recovery owner, comparison baseline and isolated acceptance test. A completed backup job is evidence that a backup operation reported success, not proof that reconstructed S40, S41 and S42 values are correct.

1.5 Build a graph whose edges can fail

A service graph must distinguish data flow from evidence flow. A slot change may travel from scheduled job to API to data store. The corresponding evidence may instead travel from API audit to a logging collector to a retention tier, and from IdP to a different collector. The responder's correlation plan depends on whether those paths share fields such as request ID or session ID. C01 supplies no executed end-to-end correlation proof.

A practical five-column source card asks:

Lesson table; scroll horizontally to read all columns →

Treat each edge as claimed, test planned, tested-pass, tested-fail, or not observable. Those statuses cannot be collapsed into a reassuring check mark. A source can pass one test and still lack another route. A supported, well-scoped statement is: "The known-good scheduled-path event was retrieved with slot and request identifiers within 20 minutes during training rehearsal R1." The unsupported extension is: "All enrollment writes are always logged." Even R1 requires a date, dataset, permitted tenant, operator, baseline, selection query and evidence receipt before that statement can be used.

Dependency criticality is contextual. An after-hours identity contact gap may be urgent not because identity always dominates the case, but because the source might become irretrievable while the only known custodian is unreachable. A backup-restore test may be important for resilience but may not be the first response to a short retention gap. Explain the decision affected, not just a red/yellow/green category.

1.6 Separate readiness assurance from incident assertions

C01 is a worksheet discovered at 08:40 UTC. Its missing after-hours identity alternate and service-owner fallback are readiness defects; they do not indicate a compromise. Its "API audit: 24 hours" entry is an unverified statement. The first task is to preserve these unknowns.

There are at least four plausible anchors behind the 24-hour phrase: source event age before deletion, time available in a query interface, lifetime of a queued export, or a published service/contract objective. A rolling retention period could also differ by dataset or ingestion delay. C01 does not tell us which interpretation applies, and a professional responder must not calculate a hard evidence-loss time from it. Ask the custodian which exact dataset, clocks, query filters, delays and deletion mechanism support the claim. Then design a permitted test near the edge, if organizational policy allows it.

An operational readiness measure should pair an objective with a failure mode. For example:

• Objective: retrieve a synthetic S41 scheduled-job edit with source event timestamp, slot ID and request ID within twenty minutes.
• Input and condition: authorized nonproduction tenant, preapproved test identity, known synthetic S41 record and one scheduled write.
• Negative control: S40 has no matching S41 request and must be absent from the S41-specific result.
• Measurements: job trigger time, API acknowledgement, producer event time, collection start and completion, field presence and number of selected rows.
• Failure criterion: missing audit event, missing stable request ID, unrelated S40 included, collection outside the agreed window, or undocumented clock relation.
• Remediation proposal: ask the application custodian to repair field coverage, source routing, or query semantics; do not rewrite the data or claim that coverage was repaired.

A negative control guards against a dangerously broad query. It does not prove that every unrelated change is excluded. Use an explicit field equality predicate for a slot and request when possible, rather than a timestamp-only proximity filter that may accidentally mix concurrent operations.

1.7 A reproducible offline coverage rehearsal

The following new synthetic fixture tests whether a trainee can preserve missing states rather than interpret every inventory row as operationally verified. It is not the CTN production inventory, and no source collection is carried out. It uses Python 3 standard library features only, makes no network request, writes no files and needs no credentials.

dependencies = [
    ("api_audit", "app_owner", "request_id", "yes"),
    ("idp_detail", "identity_custodian", "session_id", "unknown"),
    ("support_ticket", "support_lead", "received_at", "yes"),
    ("backup_copy", "recovery_lead", "restore_test", "no"),
    ("change_ledger", "service_owner", "scope_id", "unknown"),
]
for source, owner, key, status in dependencies:
    print(f"C1|{source}|{owner}|{key}|{status}")
gaps = [source for source, _, _, status in dependencies if status != "yes"]
verified = sum(status == "yes" for *_, status in dependencies)
print("C1|gaps=" + ",".join(gaps))
print(f"C1|verified_sources={verified}/{len(dependencies)}")

Executed output (Python 3, against the exact fixture above):

C1|api_audit|app_owner|request_id|yes
C1|idp_detail|identity_custodian|session_id|unknown
C1|support_ticket|support_lead|received_at|yes
C1|backup_copy|recovery_lead|restore_test|no
C1|change_ledger|service_owner|scope_id|unknown
C1|gaps=idp_detail,backup_copy,change_ledger
C1|verified_sources=2/5

Here, "yes" is fixture status, not actual verification of a CTN source. The denominator is five listed records, not all service components or all telemetry paths. Never report "40% ready" as an institutional maturity finding. The measurement only says two of the five classroom rows are marked yes. Change "idp_detail" to yes and run again; the gap list should shrink by one, but that still would not demonstrate an approved identity export route or a named after-hours alternate.

Use a second, manual fault-injection exercise: pretend the support contact is unavailable, then attempt to follow the map to an alternate. If the alternate field is blank, the test fails as a contact path, even though the script still prints that the ticket source is marked yes. This contrast demonstrates why automated coverage arithmetic cannot replace operational ownership tests.

1.8 Runbooks need decision rights as well as contact addresses

A contact is a place to ask a question, not necessarily the person authorized to answer it. Draft an owner card with four independent slots: data custodian, service decision owner, execution operator and incident coordinator. The same real person might occupy multiple slots under a local policy; keep their function at each decision visible. For a read-only IdP export, record who grants access to protected log data and who produces the receipt. For disabling an account, record who accepts enrollment disruption and who can implement a reversible control. Do not assume the custodian is the change approver.

An alternate must be established before the primary becomes unavailable. An invented escalation contact would conceal a readiness defect. C01's blank entries therefore remain "not supplied." A supervisor should be given an explicit choice: confirm an authorized alternate under the organization's actual policy, or record that a requested action cannot proceed via this route. The practitioner may prepare an escalation draft but cannot grant themselves privileges because a source might expire.

Use the following owner unavailability test: ask an alternate to identify the approved export pathway and the exact decision they can make. Stop if the contact is unknown or cannot explain the required scope. Log the attempted rehearsal as not performed until it actually occurs. This is a legitimate negative finding in a readiness review; it is not evidence of breach, negligence, or authorization to use an emergency override.

1.9 Compare a quick inventory with a defensible readiness contract

A spreadsheet listing systems can be assembled rapidly and is useful for orientation, but its failure is false completeness. A decision-centered contract costs more effort: each source has a bounded question, selectors, clock semantics, route coverage, owner, approval condition and a verification receipt. The trade-off is worth making for high-impact decisions such as "who changed S42?" and "can a clean version be restored without erasing valid changes?"

There is a similar choice between a single rehearsal and stratified tests. One scheduled-path edit can verify a narrow happy path. Distinct scheduled, manual and emergency write routes may emit different audit fields, use different identities or bypass different collection components. Separate tests avoid extrapolation. Negative tests matter, too: deliberately query S40 under the S41 selector and inspect whether false matches appear. A test that cannot fail in a defined way is a demonstration, not an assurance check.

Do not stage these tests in the production environment on the strength of a learning exercise. A permitted training tenant, synthetic classes, nonpersonal identifiers, documented owner approval and a bounded cleanup plan are prerequisites. If a local laboratory cannot simulate one dependency, write "not evaluated" and design a tabletop substitute instead of fabricating an output.

1.10 Review the readiness pack before handing it to Chapter 02

A reviewer should ask whether every statement can be labeled as model, proposed test, observed test result, or unverified assumption. For C01, only the fact that a worksheet was supplied at 08:40 and its recorded omissions are scenario observations. The proposed S41/S40 tests have no observed outcome. The reviewer also checks accessibility: column headings should identify the decision being made; file paths and role abbreviations should be expanded on first use; the handoff should remain intelligible without a diagram.

A defensible shift handoff gives the next responder a useful action even when nothing dramatic happened: "Before any S42 live case, obtain the authorized identity alternative, confirm the service-owner decision route and test whether source/collector clocks and retention anchors are understood. Use a limited synthetic S41 edit with S40 as negative control to check request-ID fields and retrieval latency. No CTN incident has been observed at C01." This is readiness work. Chapter 02 uses these unresolved ownership gaps when C02 later reports an S42 symptom; the next chapter must not retroactively treat C01 as an incident alert.

Readiness is a set of independently testable decisions

C01 is a synthetic inventory, not an alert or proof that its listed capabilities function. The service owner must state what an acceptable enrollment does before the analyst chooses which logs to inspect. For a proposed isolated enrollment test, the business invariant might be: one authorized reservation consumes no more than one available place, returns a stable operation reference, and leaves the slot unchanged after a rejected request. This is a proposed test condition; the current CTN cards do not prove the implementation honors it.

Separate four planes. The business/data plane contains the front end, enrollment API, scheduled and manual write routes, and authoritative slot state. The observation plane contains application audit, identity telemetry, collector, index and restricted export. The authority plane contains the service owner, identity custodian, incident lead, delegated alternates and their separate rights. The recovery plane contains an identified copy, isolated restore method, accepted slot targets and tested return conditions. A green signal in one plane does not certify the others. A healthy collector can omit a manual write route; a working backup job can produce an unusable restore; a reachable custodian may be unable to authorize an account restriction.

A responder's dependency graph should have typed edges, not just boxes. “Scheduled writer → API” is a proposed data path. “API → audit store” is a proposed observation path. “Audit store → case copy” requires separate selection, custody and permission. “Service owner → approval record” is a decision path, not a technical event. Each edge should have a producer, consumer, time basis, failure signal and an accountable source to ask. Unless tested with a known synthetic event and a reviewed source receipt, mark it claimed, not verified or failed, never “all logs available.”

The distinction is central to NIST SP 800-61 Rev. 3, which places incident response within cybersecurity risk management, and NIST CSF 2.0, which describes outcomes without prescribing CTN's invented workflow. The graph and test rubric here are original teaching methods, not NIST requirements.

A concrete failure investigation without inventing a breach

Synthetic preparation variation, not a new C-series card. Suppose the application owner proposes a harmless scheduled S41 write in an approved training tenant. The source audit returns a stable request ID, but the manual write route returns only an account label. The first observation can support a scheduled-route test, while the second prevents reliable manual-route request correlation. It is unsafe to declare that the entire enrollment API has complete audit coverage.

Meanwhile, C01's “API audit: 24 hours” has no retention anchor. It could refer to source-event age, collector visibility, query-horizon constraints or export-artifact lifetime. The last safe retrieval time differs across these interpretations. The proper next question is: which producer and dataset, which timestamp anchors the policy, what happens with ingestion lag, and what oldest expected marker can be retrieved by an authorized custodian? Adding twenty-four hours to a selected event time does not answer any of these source questions.

Finally, C01 names no after-hours identity alternate or service-owner fallback. That is a capability gap, not evidence of malicious activity or negligence by a specific person. Record the primary role, attempted contact, missing authority path, event that should trigger escalation and which non-disruptive work may continue. An analyst may draft a limited request; neither urgency nor access to a dashboard grants permission to use substitute credentials.

Supervisor handoff: evidence, not assurances

Each proposed readiness test needs: decision question; exact synthetic input and producer; permitted route and approval; a positive expected row with original UTC time, slot and request ID; an unrelated S40 negative control; a collection clock and twenty-minute acceptance window; an independent reviewer; and a failure/rollback rule. The test authorization, executed rehearsal receipt, and service readiness acceptance are separate states. A supervisor can approve one while declining the others. The output should tell the next responder exactly which missing field, unreachable custodian or unverified route could invalidate a future incident claim.

Offline laboratory C1X — distinguish source coverage from collector appearance

Purpose: Test the logic of a four-row declaration, not a live CTN environment. This exercise is separate from C01, from the original C1 coverage fixture, and from any production collection. Run Python 3.10+ in a local isolated interpreter; it creates no files, changes no service and makes no network calls.

The invented entries deliberately separate four failure modes. A scheduled-path declaration has the expected slot and key within the twenty-minute goal. A manual-path declaration lacks a join key even though it appears to have returned quickly. An identity-detail declaration has an identifier but no retrieval measurement. A negative-control event belongs to S40 while the requested scope is S41. Predict each state before running.

from dataclasses import dataclass

@dataclass(frozen=True)
class Probe:
    route: str
    slot: str
    wanted_slot: str
    key: str | None
    latency_min: int | None

def assess(p):
    if p.slot != p.wanted_slot:
        return "FAIL_WRONG_SLOT"
    if p.key is None:
        return "FAIL_MISSING_JOIN_KEY"
    if p.latency_min is None:
        return "UNKNOWN_NOT_RETRIEVED"
    if p.latency_min > 20:
        return "FAIL_WINDOW"
    return "PASS_DECLARED_FIXTURE"

probes = [
    Probe("scheduled_api", "S41", "S41", "req-demo-01", 9),
    Probe("manual_api", "S41", "S41", None, 4),
    Probe("identity_detail", "S41", "S41", "sid-demo-01", None),
    Probe("negative_S40", "S40", "S41", "req-demo-02", 7),
]
for p in probes:
    print(f"{p.route}: {assess(p)}")
assert assess(probes[0]) == "PASS_DECLARED_FIXTURE"

Executed output:

scheduled_api: PASS_DECLARED_FIXTURE
manual_api: FAIL_MISSING_JOIN_KEY
identity_detail: UNKNOWN_NOT_RETRIEVED
negative_S40: FAIL_WRONG_SLOT

A useful interpretation states why no “overall ready” flag is produced. The scheduled test is only logically consistent if its fields were authentic. The manual test cannot establish a request-to-audit join. The identity test has no measured availability. The S40 control exposes a scope mismatch; silently expanding the selection to include S40 would defeat the control. Neither a plausible ID string nor a small latency number independently authenticates a log.

Adversarial control: Replace the first probe's slot with S40 and predict FAIL_WRONG_SLOT despite an unchanged key and latency. Then restore it and replace the manual probe's missing key with "invented": the code would return PASS_DECLARED_FIXTURE, demonstrating why a passing Boolean classifier is not a producer receipt. Do not insert these variants into the C01 case facts.

Submission and scoring: Produce a four-row comparison, two explicit falsifiers, a proposed request to the application custodian and a short distinction between the executed offline code and an unexecuted authorized route rehearsal. Six local points: four correct classifications, one for identifying how the S40 negative control detects scope broadening, and one for preserving the authority/provenance limitations. An “all CTN logs verified” conclusion fails regardless of the numeric score.

Prioritize by decision harm, not by a readiness percentage

An entry marked yes in the original C1 fixture is a declared teaching value. Even “2/5” is not an organizational readiness score: sources differ in criticality, time horizon and relation to safety. A source needed to preserve a short-lived identity trail may matter more to an immediate escalation than several low-value inventory cells. Conversely, a restore check may be foundational for continuity but not answer a narrow identity-attribution question. Assign each gap an affected decision, failure consequence, last defensible decision point if known, safe evidence to request, authorizing role, and retest criterion.

Compare two synthetic backlog items. Item A is missing an after-hours identity alternate; its failure mode is permission unavailable during short retention. Item B is missing the last isolated backup restore; its failure mode is copy existence without verified service correctness. Neither is “complete” just because a contact number or backup job is supplied. Item A closes when an approved delegated role has been reached during a timed rehearsal and the data-owner rule is checked. Item B closes only for the tested copy, environment and target when an authorized restore has been executed, measured, compared with approved state and accepted by the service owner. Neither criterion is a generic compliance certificate.

Synthesis and next chapter boundary: Chapter 1's C01 describes preparedness before an incident. The S41 training experiments here remain proposals and invented offline exercises. When C02 appears at 09:04 in Chapter 2, do not import the synthetic PASS state as evidence that CTN actually audited anything. Instead, carry the gaps forward as explicit owner/authority questions.

Week 1 — five applied daily lessons

The sections above supply the chapter's reference explanation and two offline classifiers. The following five lessons turn that reference into a supervised practice sequence. W1 below is a separate, wholly invented training-tenant design; its rows are neither new CTN case cards nor claims about a working CTN deployment. The sequence deliberately moves from service behavior to evidence, authority, time and handoff. Complete one day's artifact and compare it with the existing numbered exercise answer before continuing. The five exercises remain EX001–EX005; the lessons do not inflate the exercise count.

Lesson table; scroll horizontally to read all columns →

Day 1 — Model a service transaction before a security signal

Learning decision. Given a reported change to a class slot, decide which state transition would be acceptable and which dependency could explain a deviation. An event feed cannot answer this until the expected business behavior is written down. NIST CSF 2.0 provides high-level risk-management outcomes, while NIST SP 800-61 Rev. 3 places response within that wider process. The transaction model below is OpenCyber Academy's teaching construction, not a NIST-prescribed schema or a verified CTN implementation.

For the separate W1 rehearsal, suppose a training class has one seat remaining. A client sends reservation request q-A; an unreliable network makes the client retry the same request; another client sends q-B. Specify the intended behavior before seeing logs: exactly one successful reservation may consume the remaining seat, a retry of q-A must not consume it twice if the service promises idempotency, and a rejected request must not decrement availability. Whether CTN has an idempotency key, a serial transaction or a version check is unknown. The model is a question for the application owner, not a reason to assert that CTN satisfies it.

The write path and the observation path have different failure points:

flowchart LR
  C["Client request q-A"] --> A["Enrollment API"] --> D["Authoritative slot state"]
  A -. "proposed audit event" .-> P["Source audit producer"] --> K["Collector"] --> X["Scoped export"]
  I["Identity service"] -. "session evidence, if emitted" .-> K
  O["Service owner"] -. "defines acceptable transition" .-> D

The solid path represents the proposed business transaction; dotted paths represent claims to test. Even a complete export from X would not, by itself, establish that D committed a valid result. A reservation receipt might be returned before a delayed write, and a notification could be queued before a rollback. Ask the service owner which record is authoritative, which request or version key joins client and write records, and how an authorized isolated test would distinguish a duplicate retry from a second successful booking. If no stable key exists, do not substitute a shared minute or account label for identity of an operation.

Worked example. Under the hypothetical contract, start at one available seat. If q-A succeeds, availability becomes zero and its retry returns the same reservation reference without another decrement. q-B then fails with an unchanged zero. A displayed success for both requests would violate the contract or indicate that the assumed contract is wrong; a single application log line cannot choose between those explanations. The first supervisor question is therefore “Is idempotency promised on this route, and which authoritative state/version verifies it?” rather than “Which attacker booked twice?” This is an example of deriving a testable question from an invariant, not an observation about C01.

Practice. Complete EX001 using C01, but add to its five-row map one proposed W1 invariant and label every graph edge data, evidence, authority or recovery. Give one possible falsifier for the API-audit edge and one for the backup-to-restore edge. The existing worked answer supplies the decision/owner pattern; your extra W1 contract may differ if it states its assumptions and does not assert deployment facts. Limit: a diagram documents what to verify; it cannot verify it. Previous: chapter start · Week index · Next: Day 2.

Day 2 — Test coverage by write route and by evidence layer

Learning decision. Decide whether a planned evidence source can support a particular decision, not whether “logging is on.” An audit producer may record scheduled jobs but omit manual edits; a collector may receive both but lose a join field; an export may filter out the correct source. NIST SP 800-92 describes log management as an enterprise process rather than a guarantee that every individual route is captured. This book's route matrix is a local rehearsal method, not a control requirement quoted from that publication.

Design separate, permitted training inputs: a scheduled S41 change with request train-17, a manual S41 change with request train-18, and an unrelated S40 change with request train-19. For each input, define what the producer should emit, what the collector should retain, and what the bounded export should return. A successful S41 selector must include the intended route's event and exclude S40; it must also preserve enough source metadata to explain why that row was selected. A missing event, absent request key and overbroad selection are three different defects, each with a different custodian question.

Lesson table; scroll horizontally to read all columns →

Worked example. Suppose a fictional rehearsal result shows train-17 at the producer and collector, but the export drops the request_id column. “Scheduled events are emitted” may be supported by the producer receipt; “the exported record can be joined to the reservation request” is not. If S40 also appears in the S41 export, narrowing the predicate is a query repair to test, not evidence that source logging was repaired. Conversely, an empty export cannot prove absence of a write until producer coverage, collector path, query semantics, clock conversion and permissions have been checked. Never fabricate these receipts for C01, whose training test remains only proposed.

Practice. Work EX002: write the six contract fields, state the authorized training tenant, exact start of a 20-minute clock, positive S41 event and S40 negative control, and name the evidence that would fail each layer. Compare with its worked answer. A test plan is complete when another authorized person could run it and recognize failure; a “green logging dashboard” is insufficient. Limit: even a passed trial samples one route, time and configuration. Previous: Day 1 · Week index · Next: Day 3.

Day 3 — Separate availability of a person from authority to decide

Learning decision. A contact directory is useful only if the contacted role can make the required decision for this scope and time. Split four powers: request an action; approve access to evidence; approve disruption to service; perform the approved action. A single person may hold several powers under a real policy, but the case record must say which power was exercised and under which rule. C01 names neither an after-hours identity alternate nor a service-owner fallback. A learner cannot fill those blanks by guessing who is on call.

Use a minimal decision gate before any controlled rehearsal: (action, target, environment, window, purpose, approver role, operator role, evidence to record, stop condition). The tuple is a teaching aid. A right to view an IdP dashboard does not imply permission to export detailed events, and an export permission does not imply permission to revoke a session. The same separation applies when urgency rises later in Chapter 2. The NIST incident-response recommendations support planned response capability; they do not issue tenant-specific delegations to a learner.

Worked example. In W1 at a synthetic 02:00 shift, suppose the analyst needs to confirm whether detailed IdP session fields can be obtained before a hypothetical source becomes unavailable. The primary identity custodian is unreachable; C01 has no alternate. The analyst may prepare a bounded request and record the contact failure. They may not ask a convenient administrator to use their credential, infer permission from read-only access, or perform a disruptive session reset. The incident lead can route the missing authority question to the organization's actual escalation mechanism if one exists; where no route is documented, status remains awaiting authorized path. This records a service-readiness defect without accusing anyone of causing an incident.

Make the negative path explicit. If an approved alternate exists but can only authorize data collection, that still leaves session revocation gated. If the service owner can approve a pause but no operator is available, the pause is approved but not executed. If an operator reports execution, the next record is verification of effect and service impact; do not convert the operator's statement into measured containment. Separating these states prevents a generic “handled” label from hiding missing evidence.

Practice. Complete EX003 as a role and alternate matrix. For identity export, session restriction and service-outage tolerance, name the distinct requested decision, approval source, operator and exact unknown if the primary is absent. Compare with its worked answer. Limit: this public example supplies no real organization policy or emergency delegation. Previous: Day 2 · Week index · Next: Day 4.

Day 4 — Reason about clocks without inventing a deletion deadline

Learning decision. A retention claim is not a deadline until its dataset, anchor event, configuration and observed behavior are known. The phrase “24 hours” in C01 might describe source event age, collector query visibility or export artifact life. An analyst who adds 24 hours to the time C01 was read has chosen an anchor unsupported by the worksheet. NIST SP 800-92 motivates planned log-management processes; it does not determine CTN's storage policy or the safety of waiting until a calculated minute.

For a separate W1 arithmetic illustration, suppose a synthetic event has event time 08:00, collector receipt 08:07 and export creation 08:10 UTC on day D. Under three different hypothetical 24-hour policies, nominal cutoffs would be D+1 at 08:00, 08:07 and 08:10 respectively. Those values are conditional calculations, not confirmed expiry times: clock error, ingestion delay, policy exceptions and query lag remain unmeasured. A fourth possibility is that “24 hours” is a contractual objective not implemented by any of those components. Ask the application and logging custodians which dataset and clock each rule covers, and test retrieval in an approved nonproduction environment before scheduling any edge-of-window exercise.

Now separate retrieval latency from retention. In the proposed S41 rehearsal, if an authorized training event occurs at 09:00 and the verified matching producer/export receipt is obtained at 09:19, the 20-minute goal passes for that test. A query submitted at 09:19 but a usable, checked record obtained at 09:23 fails that goal. An analyst's screen showing “found one result” is not yet a verified receipt if the slot, request key, source and time basis were not checked. Conversely, missing evidence from a broad query is not a measured expiration. State precisely where measurement starts and ends.

Worked example. A supervisor asks, “Can we defer the rehearsal until tomorrow at 08:40?” The correct answer is “C01 cannot support that decision.” If the source-event policy from the illustration applies, a day-D 08:00 event would reach its nominal D+1 08:00 boundary before the proposed meeting. If the export-artifact rule applies instead, the meeting may still be too late or irrelevant because no export was created. The conservative action is to obtain the custodian's policy and a permitted earlier test, not to declare that a 24-hour deadline has been proven.

Practice. Complete EX004 with three plausible interpretations of “24 hours,” a different required owner record for each, and a cautious next action. Use the worked answer to check the reasoning. Limit: simulated arithmetic does not measure clock skew or prove actual retention. Previous: Day 3 · Week index · Next: Day 5.

Day 5 — Hand over a readiness decision that another shift can falsify

Learning decision. A professional handoff is a decision instrument, not a narrative of everything the analyst read. Carry forward the service outcome, two highest-consequence unknowns, the authorized owner for each next check, the proposed negative control, and the exact point at which a claim can be revised. Organize each statement by status: worksheet observation, inference, proposed test, authorized test, executed result, or owner acceptance. In C01, only the worksheet and its omissions are case observations. The W1 transaction, matrix and clock examples are teaching variants; importing their apparent passes into the main CTN case would corrupt the later investigation.

Use an operational priority rule: ask which missing fact could close a decision window and what harmless action is possible now. The undocumented identity alternate may affect access to short-lived detail; the unverified restore may affect later recovery acceptance. Neither is a percentage. Rank by the decision harmed and the evidence needed, then assign a check to an actual role. An issue is not closed because a named person has been contacted; closure requires the specified proof, reviewer and retest when the relevant condition changes. NIST SP 800-84 discusses designing and evaluating training and exercises; the exact CTN scoring and handoff fields here are original teaching choices, not mandated NIST paperwork.

Worked example. The reviewer receives two candidate handoffs. “CTN is ready: logs show the scheduled job is fine, and IT will restore if needed” fails: C01 supplies no executed log test, “IT” is not an owner, and a backup job is not a verified restore. A defensible alternative is: “C01 lists enrollment dependencies but leaves the identity alternate and service-owner fallback blank. The API-audit 24-hour claim lacks an anchor. The application custodian should seek approval for a training S41 scheduled write and S40 exclusion control, then record request fields and verified retrieval time. The identity owner should confirm a delegated after-hours export route; the recovery lead should propose an isolated acceptance check. All tests are pending; no incident is inferred.” This record is short because its boundaries are explicit, not because the situation is resolved.

Review the draft as if you were the next shift. Can you identify who will do the S41 test, what would falsify it, which clock they will use and which decision remains blocked if the identity route is unavailable? If any answer is missing, send it back for revision. Keep the classification of test proposed distinct from test run; the event time and actual execution record must be added only after a permitted rehearsal occurs. This allows the next shift to check progress without pretending that a plan is a result.

Practice. Submit EX005 using your EX001–EX004 artifacts; write the required 90–140-word handoff and a two-row owner/retest table. Compare its worked answer, which is one defensible example rather than a unique script. Limit: another organization may allocate roles differently under its own approved policy; never infer local authority from this fictional handoff. Previous: Day 4 · Week index · Next: Chapter 2.

Common mistakes and limits

• Treating a planned log source as a collected record. Corrective action: write a rehearsal result or mark coverage unknown.
• Treating a role name as an approval. Corrective action: identify the approving role, specific action, scope and timestamp.
• Assuming every application write path has the same audit fields. Corrective action: test scheduled, manual and alternate routes separately in an authorized lab.
• Claiming a backup can restore service from a job-status screen. Corrective action: require an isolated restore and owner-defined acceptance test.

Practice: readiness workshop

In a synthetic worksheet, build the five-row map, mark unverified fields and write two tests that could fail. Do not run a production test. Exchange the worksheet with a partner who must tell you which owner to contact and what question to ask without asking for an unbounded data export. The deliverable is an owner-and-evidence handoff, not a speculative incident diagnosis. The next chapter will use this map to decide what the analyst may request when a signal arrives.

Exercises — subject 1

EX001 — Service dependency map. Input: C01 and the six CTN dependencies above. Produce a table with at least five dependencies, a decision each might support, custodian role and one unverified assumption. Assessment: 0 = missing decision/owner; 1 = map with vague assumptions; 2 = actionable, bounded map that does not claim the source is already verified.

EX002 — Evidence-readiness contract. Input: the proposed S41 scheduled-job change and unrelated S40 control. Produce all six contract fields, including expected fields, a 20-minute collection window and a falsifiable failure signal. State that the rehearsal requires a permitted training tenant. Use the EX001 rubric, with 2 requiring a negative control.

C1 extension for EX002: Identify the approved custodian, the request-ID coverage question, the precise start and end of the 20-minute test, and what a missing scheduled-path field would invalidate. Run the separate C1 offline fixture only to practice interpreting unknown statuses; its output is not a real collection receipt.

EX003 — Owner escalation. Input: C01 has no after-hours identity alternate or service-owner fallback. Write a role-based primary/alternate matrix and the exact unanswered decision if each is unavailable. No personal contacts may be invented. A 2-point result distinguishes collection permission from disruptive-action approval.

EX004 — Retention ambiguity. Input: “API audit: 24 hours” in C01. Give three plausible meanings, one question to the custodian and a conservative readiness action. A 2-point result does not calculate a deletion deadline from an unanchored claim.

C1 extension for EX004: For each proposed retention anchor, name a different measurement or record that the application custodian would need to supply. An edge-of-window rehearsal is a proposal until authorized and executed.

EX005 — Readiness handoff. Input: your EX001–EX004 artifacts. Write a 90–140-word shift handoff with service outcome, top two gaps, owners, proposed tests and no incident conclusion. A 2-point result labels tests as proposed and assigns owners.

Subject synthesis

Readiness is a set of checked service, authority and evidence assumptions. C01 alone cannot prove either preparedness or an incident. Carry its owner gaps and retention question into Chapter 2; do not silently fill them when the scenario becomes urgent.