Chapter 2 — Authority, scope and response roles

Chapter 2 — Authority, scope and response roles

Lesson map

Lesson 02 published. Map, example, EX006.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Why a role is not a blanket permission"]
  N2["2.2 Case card C02: a report arrives before diagnosis"]
  N3["2.3 Write a decision request that can be approved"]
  N4["2.4 Compare actions by effect and reversibility"]
  N5["2.5 An incident plan does not confer powers"]
  N6["2.6 A bounded action is a tuple, not a verb"]
  N7["2.7 Model the action lifecycle as a state machine"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX006"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Why a role is not a blanket permission"]
  N2["2.2 Case card C02: a report arrives before diagnosis"]
  N3["2.3 Write a decision request that can be approved"]
  N4["2.4 Compare actions by effect and reversibility"]
  N5["2.5 An incident plan does not confer powers"]
  N6["2.6 A bounded action is a tuple, not a verb"]
  N7["2.7 Model the action lifecycle as a state machine"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX006"]

[Learning outcomes]
    |
    v
[2.1 Why a role is not a blanket permission]
    |
    v
[2.2 Case card C02: a report arrives before diagnosis]
    |
    v
[2.3 Write a decision request that can be approved]
    |
    v
[2.4 Compare actions by effect and reversibility]
    |
    v
[2.5 An incident plan does not confer powers]
    |
    v
[2.6 A bounded action is a tuple, not a verb]
    |
    v
[2.7 Model the action lifecycle as a state machine]
    |
    v
[Worked example] --> [Exercise EX006]

Learning outcomes

The learner can translate an incident charter into action-specific permissions; separate an analyst's recommendation from an approver's decision and an operator's execution; and build a reversible, time-bounded escalation proposal. This chapter does not teach unsupervised tenant administration. Its practical product is a record that lets a supervisor say yes, no or not yet to a named action.

2.1 Why a role is not a blanket permission

The response lead coordinates priorities and records decisions. A service owner accepts service risk and defines a usable outcome. A custodian may retrieve a source record. An operator may execute a change after the required approval. A privacy or legal contact may advise on notice and handling where needed. One person may hold multiple roles in a small organization, but the case record still needs to say which decision right that person exercised. An incident severity label does not grant extra access or authority by itself.

In a cloud environment, actions vary enormously in blast radius. Exporting a bounded sign-in interval, revoking one session, disabling a shared automation account and changing tenant-wide access policy are different decisions. Some preserve service; others can interrupt enrollment for every learner. Before an action is approved, write its target, purpose, expected effect, maximum duration, dependencies, rollback, verification and owner. A proposed action becomes executed only when an operator records what actually happened and an independent observer checks the intended result. An approval record is not an execution receipt.

The classroom charter below is an original CTN teaching policy. It is not an authorization in any real tenant. In practice, the organization's approved emergency-change process, contractual constraints and jurisdictional duties control. NIST SP 800-61 Rev. 3 emphasizes coordination in risk management, while the precise approval matrix must be established locally.

2.2 Case card C02: a report arrives before diagnosis

At 09:04 UTC the fictional support desk receives C02: “Slot S42 appears unavailable in the enrollment portal; reporter first noticed it around 09:00.” The receipt time is known; the reporter's first-noticed time is approximate. There is no verified authoritative slot state, no record of a change and no evidence of who made one. A message from a cloud operations colleague asks, “Should we disable svc-enroll now?” The account name does not establish whether a person or scheduled job used it, and C02 does not even connect the account to the symptom. The professional response is to open a case, preserve the report as a report, identify the service and decision owners, and ask for a bounded investigation. Do not present disabling the account as an accomplished containment.

The C01 map makes the gap visible: the after-hours identity alternate and unavailable-service-owner route are blank. The analyst should not invent a substitute approval. Instead, record the owner gap and activate the organization's actual escalation route if one exists. In this synthetic exercise, the escalation status is “route not supplied; supervisor to determine.” That answer may feel unsatisfying, but it preserves the boundary. A real team should repair that readiness gap before depending on urgent account action.

2.3 Write a decision request that can be approved

Imagine a supervisor later considers a single-session revocation. A usable request has two parts. Evidence basis: which observed card supports the concern, what remains unknown, and what alternative explanation matters? At the current checkpoint, only C02 exists, so there is insufficient evidence to name a session. Proposed control: which session, who owns the service, expected disruption, duration, monitoring, fallback and independent success check? A blanket “revoke suspicious sessions” lacks a target and a test. Chapter 3 will provide a candidate session field; it still will not identify a malicious human.

The request should be versioned when evidence changes. At 09:04 the recommendation may be “investigate and preserve.” At 09:14 new signals may justify a higher priority and an approval request, but the case record should retain the earlier rationale. This distinction protects decision quality: an analyst can explain why a reversible action was reasonable at a particular checkpoint, even if a later finding changes the plan.

A simple action record contains: case ID; proposed action ID; target; initiating observation; intended effect; prerequisite evidence or condition; authorizer and scope; operator; start and expiry; expected observable result; rollback owner; actual execution receipt; verification; and any unresolved effect. Fields for approval and execution start blank. Filling them with a suggested name or assumed outcome would falsify the record.

2.4 Compare actions by effect and reversibility

At the C02 checkpoint, consider three choices. A: bounded read-only triage checks the service report and seeks the relevant owner. It is proportionate and keeps service available, but it may be too slow if a short retention window is later confirmed. B: targeted session restriction might limit ongoing misuse if a specific session is established and approved; it may also interrupt automation and requires a success check. C: disable the whole account or change tenant policy can affect all enrollment writes, has a larger rollback burden and is not justified from C02 alone. The ranking is not a universal algorithm: if later evidence shows an imminent high-impact action, the authorized owners may choose a different option. The point is that impact, evidence, scope and authority must be named before the choice.

One way to compare options is a four-cell note: expected harm avoided, service harm introduced, remaining uncertainty and falsifiable verification. Do not reduce these to an unexplained numeric score. “Targeted” describes an intended scope; the operator still has to confirm the platform implements the target at that scope. If the platform only supports account-wide disablement, the team must reassess the plan rather than silently broadening it.

2.5 An incident plan does not confer powers

At 09:04 UTC, CTN support receives fictional card C02: S42 appears unavailable, noticed around 09:00. There is no authoritative state check, cause, confirmed scope or actor. A colleague asks whether to disable the shared-sounding account svc-enroll. This request is a question, not an approval. The readiness gaps from C01 remain open. No later identity, endpoint or API cards are available at this point. An ethical and operationally competent responder must resist importing facts from future chapters.

Response roles answer different questions. The analyst decides what to recommend and what questions to ask. The incident lead prioritizes coordination and keeps a record. The source custodian knows the permitted way to obtain a particular dataset. The service owner decides what business interruption is tolerable. The identity owner controls identity-specific risk. The change authority interprets the approved emergency-change procedure. The operator performs only the permitted act; an independent verifier checks the observable effect. These are functions, not job titles. In a small organization, one person may hold several roles, but the record must retain which decision they exercised, on what basis and within which scope.

A source custodian's ability to read the IdP console does not mean they can lawfully export all sign-ins. An identity operator's ability to disable an account does not mean they have the service owner's acceptance of enrollment disruption. An incident lead may ask for rapid response without independently owning every cloud or privacy decision. The technical ability to invoke a command, organizational permission to do so, and evidence sufficiency for choosing the action are three separate gates.

This distinction is aligned with the integrated, cross-organizational response approach described in NIST SP 800-61 Rev. 3. NIST does not prescribe CTN's fictional approval roles or convert a severity label into tenant administration privileges. Local policy, law, contracts and approved emergency processes remain binding.

2.6 A bounded action is a tuple, not a verb

"Disable" is not an action specification. A useful action request contains: case identifier; action identifier and revision; observed trigger with source; exact target and environment; method/class of operation; intended effect; accepted service side effect; limits on time and objects; approving roles; operator; prerequisites; stop condition; rollback method and owner; independent observable checks; preservation obligations; expiry and review trigger.

For CTN, the target could hypothetically be one known session, one slot's write route, the svc-enroll account, or a tenant-wide policy. Those are radically different scopes. If a tool cannot perform the intended narrow restriction and instead defaults to account-wide disablement, the operator must reject and resubmit the request for renewed impact assessment. A software interface is not authorized to silently substitute broader behavior. The case manager should record the reason for mismatch and which approval would be necessary; no action has occurred.

Write the precondition as a testable statement. "Bad activity detected" is not reproducible. "An approved source contains a live session identifier tied to a documented continuing prohibited action" is closer, but at C02 the needed session and join do not exist. Therefore a recommendation to revoke a session must remain conditional. A retention-risk preservation request can still proceed through a different, read-only approval route once its data and timing have been defined.

An expiry is not automatically a restoration guarantee. After the maximum duration, the specified control may require an operator to restore settings, reconcile queued work, verify dependent services or await a second decision. A rollback plan should address the concrete configuration or session state and name how to detect incomplete recovery. Disabling a shared automation identity may cancel jobs or invalidate tokens that do not simply resume when re-enabled.

2.7 Model the action lifecycle as a state machine

The most consequential documentation error is to use "done" for approval, execution and verification. Keep the four states separate:

1. Proposed: analyst has a recommended object, evidence rationale and request for review; approval and operation fields remain empty.
2. Approved, not executed: named authority has granted the precise scope and limit, but the operator has not produced a receipt.
3. Executed, unverified: the operator reports a method, target, change version and time; intended effects have not been independently observed.
4. Verified within scope: a separate authorized check supports a particular result, with test method, observation window and residual gaps. It never licenses claims about untested routes.

These states are not an incident lifecycle. They describe the evidentiary status of one named action. Reject an "approved" transition if the authorizer is unidentified or the scope is ambiguous; a chat message "OK" can be logged but is not automatically a valid control decision. Reject "executed" if the only evidence is a recommendation or a scheduled change. Reject "verified" if a command returned success but no independent observation of its intended effect exists.

Consider a synthetic nonproduction action TRAIN-A01 that is not a CTN main-case action. This lab demonstrates the state labels without contacting identity systems.

action = {
    "id": "TRAIN-A01",
    "target": "svc-enroll",
    "scope": None,
    "approved": False,
    "receipt": False,
    "checked": False,
}
def status(a):
    if not a["scope"] or not a["approved"]:
        return "PROPOSED_ONLY"
    if not a["receipt"]:
        return "APPROVED_NOT_EXECUTED"
    if not a["checked"]:
        return "EXECUTED_UNVERIFIED"
    return "VERIFIED_WITHIN_SCOPE"
print("C2|v0=" + status(action))
action.update(scope="S42 only", approved=True)
print("C2|v1=" + status(action))
action["receipt"] = True
print("C2|v2=" + status(action))
action["checked"] = True
print("C2|v3=" + status(action))

Executed output for this exact local fixture:

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

The function validates presence of flags, not whether an actual approver is legitimate, an operator was authorized or a check tested every route. It is deliberately insufficient as a production authorization engine. In particular, the example sets approved=True without a signature; this represents a classroom state transition, not a real decision. A sound production workflow would validate decision references, signed identities, allowed targets, expiry, separation of duties and immutable audit records. Students must not treat a passing string from this script as permission to touch any tenant.

Fault injection: remove the scope after setting approved=True. The function returns PROPOSED_ONLY because a flag without a defined target is not an actionable authorization. Now set checked=True without a receipt: the state remains APPROVED_NOT_EXECUTED. These two counterexamples show why the requested sequence matters even during operational pressure.

2.8 Build an authorization matrix for the actual decision

Construct the matrix per action rather than per department:

C01 does not name an after-hours identity alternate or a fallback for an absent service owner. A matrix that assigns "supervisor" to every cell without a charter supporting that person's delegated authority is noncompliant with the exercise. The appropriate status is unknown route, escalation pending. A responder may use the organization's real escalation process if known; the course does not invent an emergency delegation.

If normal approvers are unavailable and there is an imminent safety or availability issue, the responder should check the locally documented emergency authority and its evidence-recording requirements. The word emergency does not waive privacy constraints, legal obligations or least privilege by itself. The professional exercise ends at the authorization boundary, not at an imaginary break-glass action. Record urgency separately from permission.

2.9 Compare interventions against a concrete loss model

At C02, compare A: read-only validation and owner contact; B: one-session restriction; C: broad svc-enroll or tenant-policy change. Evaluate four dimensions, not just "fast/slow."

Expected harm avoided. A prevents evidence-free disruption and can clarify service scope, but may leave a damaging action running if one exists. B could terminate an identified active session, but C02 has not identified one. C could block a much larger set of actions, including legitimate enrollment operations, yet the necessary causal link is absent.

Harm introduced. A consumes analyst time and could cause a time-sensitive source to expire if preservation is neglected. B may interrupt scheduled work or fail if a different session is used. C may stop writes across multiple dependencies, queue failures or legitimate operator recovery. The broader the control, the larger the planned verification and rollback surface.

Uncertainty. For A, authoritative slot state and incident scope remain unknown; its purpose is to reduce precisely those unknowns. For B, session identity and cause are not established. For C, whether the account caused the symptom and whether disabling it would protect S42 are not established.

Verification. A can be verified by an owner-approved state result and documented intake; B needs a check of the specific session and enrollment behavior after proper authorization; C needs full dependency acceptance, evidence of scope and a rollback decision. "Console returned success" alone is not verification of user-visible outcomes.

At 09:04, A is the defensible first step. It does not imply that later protective controls will never be warranted. New evidence may alter urgency and the acceptable risk of inaction; each decision should have a new timestamp and evidence basis rather than replacing the earlier record.

2.10 Two worked decision records: one correct, one defective

Defective example: "09:04 high severity breach, shared account hacked. Supervisor says disable; account contained successfully." This sentence invents compromise, severity, approval, execution and success. No C02 source supports those assertions. It also hides who accepted service consequences or how the account scope was verified.

Defensible example: "09:04 C02 support report received: S42 appears unavailable, first noticed approximately 09:00. Current authoritative S42 state and cause unknown. Analyst proposes bounded read-only verification by application owner, identifies missing service-owner alternate from C01, and requests incident-lead coordination. Broad account restriction was raised by a colleague but remains unapproved and unexecuted; no containment effectiveness claim. Reassess upon owner state evidence or newly validated source signals."

The second statement can be acted on by a supervisor even though it is less dramatic. It distinguishes an observation from an action proposal and does not hide the very gap the organization needs to repair.

When a new evidence card arrives, make a new version. V1 is the 09:04 decision. V2 would include the new source and its release time; it must not modify V1 as if future knowledge were always available. Keep the original source reference and earlier scope decision for review. The C02 chapter itself does not release C03–C08, so do not use their data to justify V1.

2.11 Handling the V2 ambiguous approval specimen

The exercise's variant V2 contains the phrase "OK to act." Treat that phrase as a communication artifact in a separate simulated branch, not as a fact about the main C02 incident. It lacks target, operation, environment, duration, affected service acceptance, operator and verification. A clarifying message should ask which object, method, conditions and maximum time the supervisor authorizes, how the identity and service owners have approved the effects, who will execute, and who will verify or roll back.

Correct case status: "V2 approval wording insufficient for a scoped disruptive change; approval unresolved, no action executed, no verified effect." If an analyst asks "Does this cover a bounded read-only preservation request?" that can narrow the exchange, but it does not turn the original sentence into blanket permission. If the scenario later produces a clear approval, retain both messages with timestamps and record the later decision as a distinct event.

An incorrectly designed training system might accept any affirmative message and silently populate the approved flag. This is why the simple Python fixture is instructional only. A real workflow must independently check identity, delegated authority, scope, expiry and conflict of duties. The essential human question remains: who owns the potential service harm, and what precisely have they approved?

2.E1 Three permissions, three different forms of evidence

When C02 reaches the CTN support desk at 09:04, the visible fact is a reported S42 availability problem, not a security compromise. The cloud colleague's proposed account disablement is a question. The practitioner should distinguish three kinds of permission.

Permission to look concerns read-only case collection. It may still expose staff identifiers, sensitive tenant events or unrelated enrollment data, so the source custodian and relevant data owner must authorize exact source, selectors, access method and retention. Permission to interrupt concerns an operation changing a session, account, API route or service. It requires the owner of the affected function to accept disruption and the identity/change owner to authorize the precise effect. Permission to publish concerns an audience and a message; it does not follow from either technical permission. A colleague who can read a console does not thereby gain all three.

Each action therefore has its own authorization envelope: the case and purpose, source of the trigger, named operation, smallest target and environment, start/end or lease semantics, approving role and valid delegation, executing role, service impact accepted, safeguards to preserve, success and failure observations, rollback owner, and next review. This is not a ceremonial form. If an operator discovers the cloud interface lacks session-level scope and offers account-wide disablement instead, the envelope has changed: the operator should stop and obtain a new authorized decision. The old decision cannot be stretched.

The NIST SP 800-61 Rev. 3 integration of incident response with organizational risk management supports this separation of analysis and business decisions. It does not confer statutory authority or prescribe CTN's fictional signatories.

2.E2 A decision's lifecycle is not its control's lifecycle

A proposed restriction and an executed restriction are different artifacts. A useful professional case record keeps two ledgers:

A signed request with no operator event must remain approved, not executed. An operator's success message without a reliable state or audit observation is reported executed, effect unverified. A narrow test showing a session rejected on one route is not proof that every token, account or integration was restricted. A refused approval also needs its own record; do not erase the proposal simply because the decision was “no.”

Contrastive example: At 09:04, “We recommend disabling svc-enroll because S42 might be unavailable; service owner not contacted; no action taken” is a weak technical remedy but an honest action-state record. “svc-enroll contained” would falsely assert both the actor/cause and operation. A stronger proposal asks for an authorized S42 state check, names the source and minimal fields, preserves the unresolved owner route in C01, and gives the incident lead a review trigger. The improvement is in controllability and evidentiary discipline, not in dramatic language.

In a supervised response, time pressure changes escalation priority, not the logical meaning of a receipt. An urgent decision might require the organization's documented emergency procedure; that procedure must still name what is authorized and how it is reviewed. “Emergency” alone cannot be treated as a wildcard on an account, scope or personal data.

2.E3 Design a rollback before deciding to risk service continuity

A rollback is not simply the inverse string of a command. Revoking a session can require a verified new login rather than un-revoking the original session; disabling a shared account may break an automation secret, integration queue or recovery job. Returning an earlier configuration can also reintroduce the same risk the intervention was meant to reduce.

At approval time, record a measurable protective goal (for instance, the named session cannot perform further prohibited work) separately from permitted service goals (staff can use approved alternative workflows; confirmed enrollment requests remain consistent). Define a trigger for intervention failure, a trigger for unacceptable business harm, a new owner decision required for reversal, and the records to preserve before changes. The controlling service owner accepts the potential business loss; the source/identity custodian defines permitted evidence handling and technology scope; the operator has no power to rewrite these decisions.

At C02 the action is still only under consideration: no target session has been supplied, so no test can yet prove a session-specific outcome. A practitioner can still prepare the shape of the verification: one request-linked negative test against the prohibited operation, a positive test of legitimate access, independent source/clock metadata, and a rollback checkpoint. This is preparation for Chapter 6, not a result available at 09:04.

2.E4 A miniature authority-validation lab

Classification: Entirely synthetic offline fixture C2X. Its positive flag is invented, not a signed decision, an account operation or a CTN source card. Python 3 standard library, read-only in memory, no environment access. The approval is bound to one named operation, environment and target.

REQUEST = {"target": "S42", "action": "read_export", "environment": "training"}

def decide(card):
    if card.get("target") != REQUEST["target"] or card.get("action") != REQUEST["action"]:
        return "HOLD_SCOPE_MISMATCH"
    if card.get("environment") != REQUEST["environment"]:
        return "HOLD_ENVIRONMENT"
    if not card.get("approved_by_owner"):
        return "HOLD_APPROVAL"
    if not card.get("operator_receipt"):
        return "APPROVED_NOT_EXECUTED"
    if not card.get("independent_check"):
        return "REPORTED_NOT_VERIFIED"
    return "FIXTURE_GATES_DECLARED_NOT_AUTHENTICATED"

cases = [
    ("correct_scope_no_approval", {"target":"S42","action":"read_export","environment":"training","approved_by_owner":False}),
    ("wrong_action", {"target":"S42","action":"disable_account","environment":"training","approved_by_owner":True}),
    ("approval_only", {"target":"S42","action":"read_export","environment":"training","approved_by_owner":True}),
    ("operator_report_only", {"target":"S42","action":"read_export","environment":"training","approved_by_owner":True,"operator_receipt":"sim-1"}),
    ("all_flags", {"target":"S42","action":"read_export","environment":"training","approved_by_owner":True,"operator_receipt":"sim-1","independent_check":"declared"}),
]
for label, card in cases:
    print(label + ": " + decide(card))

Executed output:

correct_scope_no_approval: HOLD_APPROVAL
wrong_action: HOLD_SCOPE_MISMATCH
approval_only: APPROVED_NOT_EXECUTED
operator_report_only: REPORTED_NOT_VERIFIED
all_flags: FIXTURE_GATES_DECLARED_NOT_AUTHENTICATED

The wrong-action adversarial control is especially important: an approval for a narrow read-only S42 export cannot be recycled to disable the account. The final “pass” does not authenticate the owner or source. A production process must validate the owner identity, delegation, approved request digest/target, applicable rules, independent receipt and actual effect. These invented strings are not sufficient security controls.

Learner task: For every line, name the first blocking evidence; then replace “training” with “production” in the last card and predict HOLD_ENVIRONMENT. Write a two-sentence supervisor request for the narrowly authorized read-only S42 question. Keep an alternative, broader account action separately proposed and unapproved. Five points: correct five classifications, with one point reserved for explaining why a copied favorable flag cannot authenticate approval (score each classification within the other four points). The output is reasoning on simulated fields only.

2.E5 Decision meeting and independent handoff

A useful exercise role-play has three rounds. First the analyst writes a C02-only decision note: symptom, alternative benign explanations, required service owner and proposed state check. Next a supervisor challenges the proposed account disablement: which exact new evidence would raise expected harm enough to reconsider it, which dependency could be interrupted, and what legitimate function must be preserved? Finally an independent recorder writes the current action state, making missing owner contact and absent execution receipts explicit. The second participant should be able to identify, without asking the author, which source request may be submitted and which disruptive option remains blocked.

A supervisor should reject “approve all controls necessary” even if the analyst is well intentioned. Such language cannot be audited for target, duration, business cost or rollback. An acceptable decision says “approved to prepare a request,” “authorized to retrieve this selected interval,” or “approved this identified control until this time with these safeguards,” followed by a separate operator/effect record as applicable.

Chapter synthesis: C02 justifies case intake, a bounded decision question and escalation. It does not justify an account-wide restriction. Later identity and endpoint cards can strengthen or weaken the action rationale, but they cannot retroactively fill a missing 09:04 approval. Chapter 3 adds those signals; Chapter 2 contributes the authority test through which any resulting proposal must pass.

Week 2 — five applied daily lessons

The chapter above supplies the reference explanation and the C2/C2X offline classifiers. These five lessons apply that explanation to separate decisions: identify a decision right, bind an approval to an exact request, compare controls, resolve ambiguous wording, and hand over the resulting record. W2 is an invented training-only rehearsal dated 1 May 2026 UTC. Its lab-42 service and SIM-DEC-01 approval specimen are not CTN evidence, real delegations or proof that a change occurred. The main CTN case remains at the C02-only 09:04 checkpoint. Each day uses one existing EX006–EX010 prompt and its worked answer; the sequence does not create five extra exercise IDs.

Day 1 — Allocate a decision right, not just a job title

Learning decision. Before routing a proposed act, identify what kind of permission it needs. A role may recommend a control, approve limited access to a source, accept interruption of a service, perform the operation, or independently check its effect. These are distinct rights. The separation-of-duties and least-privilege controls in NIST SP 800-53 Rev. 5 are useful design context; they do not supply a named approver for CTN. An incident lead's coordination role does not by itself grant permission to export identity data or disable an account.

Start with a five-column record: proposed action, decision right, authority source and scope, operator, and receipt needed before the next claim. Fill a cell with unknown when the charter omits an alternate. Do not write “approved” merely because someone is available by chat. If one person legitimately holds several roles, make separate entries for each decision they exercised. That allows an independent reviewer to see whether the person accepted the business loss, authorized source access, performed the change, or observed the effect. It also prevents a broad “IT handled it” entry from hiding a missing service-owner decision.

For the CTN C02-only checkpoint, a case can be opened and the S42 report preserved as a report. A selected IdP interval would need a permitted source/data decision before collection. A single-session restriction would need a specific session, identity and service-risk decisions, and an authorized operator; C02 names no such session. A shared-account disablement adds broad enrollment impact and change authority. A learner notification is a separate publication decision. Even if all five rows refer to the same incident, no row inherits another row's permission. The response recommendations in NIST SP 800-61 Rev. 3 integrate response with organizational risk management; the matrix here is an original teaching instrument for making local authority visible.

Worked example. In W2, an identity steward is reachable and may approve a bounded training log export, but the service owner is absent and no alternate is documented. The analyst may draft the selected source request; a training custodian may collect only after its data-access approval. The steward's presence does not approve the separate proposed account interruption. If the only on-call administrator can press “disable,” record technical capability, not permission. The unresolved service-owner route remains an escalation item. This is not a failed incident response: it is an accurately exposed readiness defect. The correct operational next step is to consult the organization's actual documented alternate or emergency route, if one exists, and preserve who made that decision.

Practice. Complete EX006. For each of its five actions, attach one source of approval and one receipt that would justify moving from proposed to the next state. Mark the missing C01 identity and service alternates as unresolved. Compare with the worked answer, including its Week 2 application. Limit: the W2 roles are fictional and cannot authorize a real tenant. Previous: Chapter 1, Day 5 · Week index · Next: Day 2.

Day 2 — Bind approval to one versioned action envelope

Learning decision. Decide whether a favorable approval record still applies to the operation the operator is about to perform. An action envelope is a tuple, not a verb: case / revision / purpose / operation / target / environment / selected fields or affected objects / time range / operator / service consequence / expiry / verification / rollback owner. A changed target, environment, operator or method is a changed request. The safe transition is new review, even when the button label has the same English verb. A reference number records the decision; it does not authenticate the sender or prove that the operator acted.

In W2 only, suppose SIM-DEC-01 declares approval of revision 1 for a read-only export of selected S42 fields in a training environment, covering 13:50–14:10 UTC, with a training custodian as operator and a 14:20 UTC expiry. It says nothing about production, S40, all identity events, a session restriction, or svc-training-enroll disablement. An operator proposal that expands the object set to ALL_SLOTS must be returned for a new scope and business-impact decision. Editing the old request in place would make the approval receipt appear to cover a decision never made. Store the original proposal and the new revision separately.

The following Python 3 standard-library, offline, read-only fixture tests tuple matching and an expiry boundary. It is a classroom classifier; its invented approval reference, role name and timestamp are not a signature, identity proof, collection receipt or production authorization. Predict the five lines before running it in a local Python interpreter.

from datetime import datetime

approved = {
    "revision": 1, "action": "read_export", "target": "S42",
    "environment": "training", "fields": ("slot", "event_time", "request_id"),
    "range": "13:50..14:10 UTC", "operator_role": "training_custodian",
    "valid_until": "2026-05-01T14:20:00+00:00", "reference": "SIM-DEC-01",
}
bound = ("revision", "action", "target", "environment", "fields", "range", "operator_role")
request = {key: approved[key] for key in bound}

def gate(proposal, decision, at):
    if decision is None or not decision.get("reference"):
        return "NO_DECISION_RECORD"
    if any(proposal.get(key) != decision[key] for key in bound):
        return "REAPPROVAL_REQUIRED"
    if datetime.fromisoformat(at) >= datetime.fromisoformat(decision["valid_until"]):
        return "EXPIRED"
    return "MATCHES_DECLARED_TUPLE_ONLY"

print("original:", gate(request, approved, "2026-05-01T14:10:00+00:00"))
print("wider_target:", gate({**request, "target": "ALL_SLOTS"}, approved, "2026-05-01T14:10:00+00:00"))
print("new_revision:", gate({**request, "revision": 2}, approved, "2026-05-01T14:10:00+00:00"))
print("at_boundary:", gate(request, approved, "2026-05-01T14:20:00+00:00"))
print("missing_record:", gate(request, None, "2026-05-01T14:10:00+00:00"))

Expected exact output, reproduced for this fixture:

original: MATCHES_DECLARED_TUPLE_ONLY
wider_target: REAPPROVAL_REQUIRED
new_revision: REAPPROVAL_REQUIRED
at_boundary: EXPIRED
missing_record: NO_DECISION_RECORD

The output is deliberately not AUTHORIZED_TO_EXECUTE. This small function cannot validate delegation, approved service impact, the authenticity of SIM-DEC-01, the operator's identity, an execution receipt or effect. The at_boundary line makes the comparison inclusive: at 14:20, the declaration is expired. That expiry is an approval limit, unrelated to C01's ambiguous data-retention “24 hours.” A real procedure must also handle clock source, revocation and concurrent revisions. A passing fixture result is never a reason to perform a tenant action.

Worked example. The cloud tool offers a checkbox labeled “include all slots” while the W2 approval names only S42. Selecting it changes target to ALL_SLOTS; the classifier returns REAPPROVAL_REQUIRED. The operator should stop, record the mismatch, and ask whether a wider, separately assessed request is appropriate. They must not claim that the selected S42 export was collected. If the original narrow export later runs, an independent source receipt and selection check are still needed before calling its result verified.

Practice. Work EX007 with the main C02 checkpoint, keeping approval, operator, execution and verification pending. Add a new revision column for a hypothetical scope expansion and state exactly why the old revision does not cover it. Compare with the worked answer and its Week 2 application. Limit: the W2 code checks declared fields only, and C02 has no approval specimen at all. Previous: Day 1 · Week index · Next: Day 3.

Day 3 — Choose a proportionate control with a falsifier

Learning decision. Compare what a control might prevent with what it might break, given the evidence available now. A narrow control is not automatically harmless, and a broad control is not automatically more effective. At C02's 09:04 checkpoint, S42 is reported unavailable; cause, actor and authoritative state are unknown. It would be logically invalid to justify a session restriction using cards released in Chapter 3. Start with A, a bounded read-only state and owner question. Keep B and C as conditional alternatives. Escalate promptly if retention or ongoing harm is credibly time-sensitive, but do not convert urgency into authority.

For every option, write harm potentially avoided, legitimate harm introduced, precondition missing, and two falsifiable observations: one for the protective goal and one for legitimate service. The second observation matters because a control could block the suspected action while also blocking enrollment for all learners. State the measurement route. A tool's success response can confirm an API call returned; it cannot establish that the business effect occurred on every route. The later containment chapter will test route coverage, but Chapter 2's task is to demand an acceptable evidence and authorization plan before proposing that intervention.

Worked contrast. With only C02, a proposal to disable svc-enroll because its name sounds related to enrollment has no established causal path and threatens the shared write dependency. Select A and name the review trigger: a verified authoritative S42 state, relevant source receipts, or a confirmed imminent loss window. In a different W2 training branch, imagine a permitted audit actually joins lab-session-7 to repeated prohibited writes and the service owner confirms a safe alternative for scheduled work. B may then become a candidate, but it is still only a proposal until the exact session, expiry, identity/service approvals, operator and independent checks are recorded. The W2 evidence cannot be transferred into CTN's 09:04 decision.

There is no reliable single-number score here. If harm probabilities or dependencies are unknown, an unexplained “risk 7/10” disguises assumptions. Record the unknowns and a test that could change the choice. If the platform cannot restrict only the selected session, that is a new option, with new potential harm and approval scope; do not silently execute C under the label B. This follows the risk-management framing of NIST SP 800-61 Rev. 3, while the specific A/B/C analysis is OpenCyber Academy's fictional case work.

Practice. Complete EX008. Produce a four-cell comparison for each choice and add a protective and a legitimate-service check that could fail. Select an option for C02-only evidence, then name one new observation that would require a fresh comparison. Use the worked answer and its Week 2 result. Limit: a proposed test is not a pass, and one route does not establish whole-service protection. Previous: Day 2 · Week index · Next: Day 4.

Day 4 — Treat ambiguous approval as an unanswered question

Learning decision. Determine whether a message states a real decision or merely conveys willingness to discuss one. The fictional V2 variant says “OK to act.” That phrase has no object, operation, environment, time bound, accepted service effect or approving role. Save it as a communication artifact, not as approval for account disablement. A responder must ask which request revision is being approved and which rights the sender actually holds. The main CTN branch contains C02 but does not contain V2; never insert this message into the 09:04 main-case record.

Use the following gate as a review checklist, not as software authorization logic:

flowchart TD
  M["Message received"] --> I{"Sender and delegation verified?"}
  I -- No --> Q["Record and seek authority route"]
  I -- Yes --> T{"Exact request revision, target and effect named?"}
  T -- No --> C["Ask for clarification; no disruptive change"]
  T -- Yes --> E{"Environment, time and service risk accepted?"}
  E -- No --> C
  E -- Yes --> D["Record bounded decision; operator still separate"]
  D --> R["Wait for execution receipt and independent effect check"]

Notice the final two nodes. Even a complete approval does not prove execution; an operator's receipt does not prove the protective or service outcome. A “yes” to a read-only source request is not permission to interrupt an account. If the decision owner is unavailable, follow the organization's documented escalation path; do not manufacture an emergency exception. NIST SP 800-53 Rev. 5 provides least-privilege and separation-of-duties design context, while actual delegation is organization-specific.

Worked example. Poor clarification: “Please confirm we can fix this quickly.” It repeats the ambiguity and gives no candidate for rejection. Better: “For simulated case V2, do you approve request A-01 revision 1, read-only retrieval of S42 audit fields in the training environment from 13:50 to 14:10 UTC by the training custodian, ending at 14:20, with no account or session change? If not, which field should be revised? Who holds this decision right under the approved charter?” This is a question, not a fabricated approval. A later precise response must be preserved beside the original, with its own timestamp and validity check. If the reply broadens the scope, submit a new request rather than editing the approved record behind the approver's back.

For an adversarial control, take Day 2's favorable original fixture row and substitute action disable_account; it must produce REAPPROVAL_REQUIRED, regardless of the invented reference string. If a team instead records “V2 approved; account contained,” it has made two unsupported jumps: message to approval and approval to verified execution. The correct case status is “clarification requested; no disruptive action approved, executed or verified.” This status can coexist with a separately approved read-only collection request only when that separate approval has actually been documented.

Practice. Work EX009: write the exact clarification, identify each missing tuple field, and give a one-sentence action state. Run the Day 2 fixture with a mismatched operation if desired; then explain why its strings authenticate nothing. Compare with the worked answer. Limit: neither V2 nor the offline output is a real authority record. Previous: Day 3 · Week index · Next: Day 5.

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.

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.

Common mistakes and limits

• Confusing an urgent question with permission to execute. Record a recommendation and the approval gate separately.
• Writing “service owner approved containment” without the exact account, action, duration or acceptable service effect. Ask for bounded approval and retain the decision receipt.
• Treating an account label as an actor. Shared accounts and automation require additional records; even detailed logs can leave human attribution unresolved.
• Planning a rollback as “undo change.” Specify who can perform it and which observable condition triggers it. A rollback might not restore data that was changed while access was restricted.

Practice: supervised decision meeting

In groups, assign analyst, service owner, identity custodian and recorder roles. Give everyone C01 and C02 only. The analyst presents the symptom and three candidate actions. The custodian describes which restricted source could be requested; the service owner states which enrollment disruption would be tolerable if supported; the recorder notes what was decided, what remains pending and the next review trigger. The exercise stops before any change or access to real data. Swap roles and compare the records: disagreement over evidence is useful if each claim names a source and time.

Exercises — subject 2

EX006 — Role-and-right matrix. Input: C01 and C02. For case opening, bounded log retrieval, session revocation, account disablement and learner notification, name the recommending, approving and executing role; mark unknown escalation routes. A 2-point result keeps those responsibilities distinct.

EX007 — Action request. Input: the cloud colleague's “disable now” question at 09:04. Draft a proposed action record with target, trigger, service risk, approval, operator, expiry and verification. Fields unsupported by C02 must say pending, not contain invented receipts. A 2-point result recommends a bounded first step rather than asserting account misuse.

C2 extension for EX007: Give the action a revision and list which precise tuple fields are still blank. Compare its status with the four states in the offline TRAIN-A01 fixture; do not transfer that fixture's simulated approval to CTN.

EX008 — Option comparison. Input: choices A, B and C in §2.4. Produce the four-cell comparison for each and select the most defensible first step at 09:04. A 2-point result explains why a later checkpoint might change the selection.

EX009 — Approval ambiguity. Fictional variant V2: a supervisor writes “OK to act,” without target or duration. Compose the precise clarification request and a one-sentence case status. Do not import V2 into the main C02 decision. A 2-point result leaves action unexecuted and names missing scope.

C2 extension for EX009: State which missing action-tuple fields prevent the phrase from crossing the approval gate. In a copy of TRAIN-A01, remove scope after setting its Boolean approval flag; explain the resulting state and why even that script cannot authenticate an approver.

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.

Subject synthesis

The decision right belongs to a role and a bounded action, not to the incident label. C02 supports intake and owner escalation, not a tenant-wide change. Chapter 3 will add identity and application signals; revisit the options with the new cards while preserving the 09:04 record as it was.

Continue studying — chapter 02 of 12

← Chapter 01 · Course chapter index · Chapter 03 →

Continue to the next authored lesson.