Treat ambiguous approval as an unanswered question | Professional Incident response and cyber resilience

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

Day 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.

Exercise for this lesson

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.

EX009 — Model clarification for V2. “Please identify the exact account or session, permitted action, environment, maximum duration, service impact accepted, operator, rollback owner and approval reference; does your ‘OK’ cover a bounded log request or a disruptive tenant change?” Case status: “V2 supervisor message received; scope insufficient for action; no production change approved or executed.” V2 is separate from C02. “OK to act” should not be stretched to authorize an unspecified tenant-wide edit.

Additional worked reasoning (EX009 — Why V2 fails.): “OK to act” lacks object, environment, allowed operation, service effect accepted, time bounds, operator, verification, rollback and authoritative delegation. The request for clarification must identify those fields and preserve the original message as an ambiguous version. Correct case state is clarification requested; disruptive action not approved or executed. C2X can return a favorable fixture label with invented flags; neither fixture proves the sender's authorization.

Week 2 applied result (EX009). A precise follow-up names request ID and revision, proposed operation, exact target/environment, fields or affected objects, interval and expiry, operator, service risk, verifier and rollback owner; it asks which right the sender holds and whether their answer covers only read-only retrieval or a disruptive change. Preserve V2's original text as an unresolved communication artifact. The resulting status line is “V2 clarification requested; no disruptive action approved, executed or verified.” In the separate W2 offline gate, replacing read_export with disable_account must return REAPPROVAL_REQUIRED even if the invented SIM-DEC-01 string is present. A code result cannot authenticate the sender or fill an absent delegation.