Chapter 8 — Recovery, continuity and return to service

Lesson map

Lesson 08 published. Map, example, EX036.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["8.1 Recovery objectives are observable conditions"]
  N2["8.2 C25–C30: identity, data, test and return"]
  N3["8.3 Choose the least destructive data path"]
  N4["8.4 An acceptance gate with a deliberate failure"]
  N5["8.5 A backup is an artifact; the recovery target is"]
  N6["8.6 Construct a state-difference argument with a los"]
  N7["8.7 Identity readiness and service readiness are cou"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX036"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["8.1 Recovery objectives are observable conditions"]
  N2["8.2 C25–C30: identity, data, test and return"]
  N3["8.3 Choose the least destructive data path"]
  N4["8.4 An acceptance gate with a deliberate failure"]
  N5["8.5 A backup is an artifact; the recovery target is"]
  N6["8.6 Construct a state-difference argument with a los"]
  N7["8.7 Identity readiness and service readiness are cou"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX036"]

[Learning outcomes and connection]
    |
    v
[8.1 Recovery objectives are observable conditions]
    |
    v
[8.2 C25–C30: identity, data, test and return]
    |
    v
[8.3 Choose the least destructive data path]
    |
    v
[8.4 An acceptance gate with a deliberate failure]
    |
    v
[8.5 A backup is an artifact; the recovery target is]
    |
    v
[8.6 Construct a state-difference argument with a los]
    |
    v
[8.7 Identity readiness and service readiness are cou]
    |
    v
[Worked example] --> [Exercise EX036]

Learning outcomes and connection

The learner can compare restoration options against approved target data, select a minimal correction, run an isolated acceptance gate, stage a production change and state what monitoring does and does not prove. The case still has an unavailable S42 slot, a disabled unapproved task, a recently expired hold and an unresolved identity configuration change. Recovery must maintain the legitimate S40/S41 work; a backup that predates all changes is not automatically “good.” NIST SP 800-184 treats recovery planning, testing and improvement as part of resilience; CTN's exact acceptance sheet is an original case exercise.

8.1 Recovery objectives are observable conditions

Before restoring, define data correctness, service behavior, identity safety, audit quality, rollback and monitoring. A backup job's “completed” flag does not answer whether its slot values are correct, how old the data is, or whether a restored application can enroll learners. A single successful login does not validate the enrollment API or audit trail. Conversely, demanding zero residual uncertainty would prevent a reasonable return under monitored conditions. The service owner should state which criteria are mandatory at release and which gaps remain assigned for later investigation.

For CTN, a sensible classroom target at 10:12 is: S42 open under the approved enrollment schedule; S40 and S41 remain reserved according to the authorized 08:50 change; both manual and scheduled routes can operate under their intended credentials; new edits have useful request and actor fields; a rollback can restore the pre-change version; and the service owner accepts the result after a timed observation. The target values are owner-approved case assumptions, not inferred from the backup alone. No learner should carry these values into a real production system.

The containment hold from C21 expires at 10:07. At that time C24 shows sync-override disabled, but C22's recovery method is still unresolved. The service owner elects bounded read-only monitoring rather than another hold, documenting a stop condition for any new S42 edit. That choice does not mean the incident is over. It creates a residual-risk interval until the identity change and service correction are verified. Keep this interval in the recovery handoff; do not tell the story as if the hold stayed active indefinitely.

8.2 C25–C30: identity, data, test and return

The next fictional cards have separate approvals, actions and observations:

Lesson table; scroll horizontally to read all columns →

C25's verification is scoped: it says s-77 is inactive at 10:11, not that every prior session or copy is gone. C26's digest is about the snapshot bytes; its data-point age and business correctness require separate checks. C27 is a failed acceptance test even though the slot values look right. C28's second pass is an isolated rehearsal; C29 is the production action with its own approval, execution and verification. C30 is an owner decision after a stated window. This chain is the difference between “we restored something” and an evidence-based service return.

8.3 Choose the least destructive data path

Compare three candidates before requesting C29 approval. Whole snapshot restore would set S42 open but also put S40/S41 back to open, undoing approved reservations. It fails the business target despite a valid hash. Do nothing preserves S40/S41 but leaves S42 unavailable. Targeted reconciliation of S42 can preserve the legitimate S40/S41 state if the team first records current version, approved target, expected API/audit behavior and rollback. The targeted option is still not automatically safe: it needs the C27/C28 isolated gate and owner approval. This comparison is a data correctness argument, not a blanket rule that targeted writes are always best.

The following in-memory Python 3 fixture reproduces the value comparison. It reads no files, services or personal data. The sorted output is part of the exercise answer, not proof of a live state:

target = {"S40": "reserved", "S41": "reserved", "S42": "open"}
snapshot = {"S40": "open", "S41": "open", "S42": "open"}
current = {"S40": "reserved", "S41": "reserved", "S42": "unavailable"}

for label, state in (("08:30 snapshot", snapshot), ("10:12 current", current)):
    gaps = [f"{slot}:{state[slot]}->{target[slot]}"
            for slot in sorted(target) if state[slot] != target[slot]]
    print(f"{label}: {', '.join(gaps) or 'none'}")

08:30 snapshot: S40:open->reserved, S41:open->reserved
10:12 current: S42:unavailable->open

The first line shows why a whole restore would lose approved changes. The second identifies the one value that the provided current-state fixture differs on. Neither line proves that the source of truth has only three slots, that a correction is authorized, or that the application will behave correctly after it. Those claims need the source, owner and functional tests above.

8.4 An acceptance gate with a deliberate failure

Preannounce the gate before seeing C27: (1) slot values match the owner-approved target; (2) both manual and scheduled routes work without a new out-of-scope write; (3) new audit records retain actor and request fields; (4) the original evidence is preserved; (5) rollback copy and owner are known. The third criterion deliberately fails in C27. It is tempting to say “four out of five is good enough” because the visible enrollment page works. That reasoning hides a control regression: the next incident might lose the attribution field entirely. In this classroom acceptance contract, C27 is no-go. The owner can revise a criterion only through a documented decision, not by rewriting the result after the test.

C28 improves the isolated candidate and passes the listed local checks. For production, C29 must state how the operator will verify the same conditions and when to stop. If S42 is wrong, S40/S41 change unexpectedly, batch-17 fails, or the new audit actor field is blank, stop the staged restart and use the named rollback owner. A rollback might restore availability but does not recreate lost historical data or undo messages already sent. It is a planned recovery path with its own verification, not a magic inverse command.

The time from the 09:04 ticket receipt to the 10:45 limited acceptance is 101 minutes in this synthetic record. That is a measured interval with defined endpoints. It is not a recovery-time-objective result because CTN supplied no approved RTO target. Similarly, the 08:30 snapshot's age is not, by itself, the amount of data lost; targeted reconciliation preserved the legitimate later S40/S41 changes in this case. RTO and RPO targets must be defined by the owner and compared with actual outcomes before a compliance claim can be made.

8.5 A backup is an artifact; the recovery target is a governed statement

Many mistakes in response recovery result from confusing artifact validity, restore feasibility, business correctness and operational acceptance. They are four independent questions.

Artifact validity asks whether a received backup corresponds to its expected bytes and metadata. A digest match supports byte consistency with the named baseline, but it cannot prove the backup captured all relevant rows, that the operator selected the correct time, or that the stored information reflects the organization's desired business state. Restore feasibility asks whether the backup can be loaded in a compatible and authorized isolated environment. Business correctness asks whether its values comply with the current approved transaction history. Operational acceptance adds application behavior, security logging, access dependencies, user impact and monitoring.

C26 supplies a documented 08:30 snapshot with a matching digest and an isolated read. The snapshot contains S40=open, S41=open and S42=open. At 10:12, the current owner-scoped state is S40=reserved, S41=reserved and S42=unavailable. The S40/S41 reservations are legitimate later changes under the approved 08:50 work. Therefore blindly restoring the older snapshot would appear to fix S42 while undoing two authorized reservations. A hash that validates a wrong-business-state artifact cannot transform it into the correct target. An operator must compare the snapshot's age and values with the owner-approved current intent, not merely its filename or creation time.

The business target for this synthetic decision is S40=reserved, S41=reserved, S42=open. This target is not inferred from the most recent timestamp or the analyst's personal preference: the service owner approves it. An entry-level practitioner should record source versions and change relationships before proposing to edit values. If the owner cannot confirm which later transactions remain valid, pause and request a bounded reconciliation; do not choose a restore point by visual appeal.

NIST SP 800-184 emphasizes planning, testing and improvement in cybersecurity recovery. The CTN three-slot transaction example and proposed gate are original teaching devices, not NIST-prescribed recovery parameters.

8.6 Construct a state-difference argument with a loss ledger

For each candidate state, list every field that differs from the approved target. The test is not simply “Does S42 appear open?” The candidate that recovers S42 but regresses S40/S41 is a partial and dangerous repair. A useful ledger records target value, baseline version/source, current value, proposed value, business authority, intended preservation and rollback reference.

The three candidate strategies have different failure signatures:

Lesson table; scroll horizontally to read all columns →

The targeted strategy wins this specific comparison, but it is not universally safer than restoration. A real application may have cross-record invariants, queues, enrollment counters, caches, foreign-key relationships or transactional consistency constraints that a single-field adjustment would violate. The professional responder asks the data and application owners how the logical transaction is represented and which writes are atomic. A one-row change outside the application may bypass audit hooks and create a new failure. The learning target is an owner-approved, isolated-testable reconciliation—not an instruction to modify a database manually.

A useful dry-run precondition is: “Current S42 version still equals the captured pre-change version; otherwise abort and re-evaluate.” That is analogous to optimistic concurrency control. Without a version check, another legitimate update arriving after the 10:12 snapshot could be silently overwritten. The case does not provide evidence of such a race; the precondition is a general design safeguard proposed for a real implementation review, not a historical CTN event.

8.7 Identity readiness and service readiness are coupled but not identical

At 10:11, C25 reports a separately approved 10:08 identity-owner/service-owner decision: remove the unapproved recovery method, perform a scoped credential change and revoke s-77. The identity operator reports completion at 10:10; a fresh status check at 10:11 finds s-77 inactive. This is a specific identity-track result, not evidence of universal account compromise or universal account safety. It also does not automatically prove approved batch-17 will work with an updated credential path.

Recovery introduces a dependency: restarting scheduled enrollment when the integration credential has changed can produce an avoidable outage or prompt operators to restore an old secret unsafely. Therefore the acceptance contract includes a negative control: legitimate batch-17 must continue through its approved authentication path, while suspect access does not regain access merely because the app is restarted. A successful scheduled job is relevant to availability, but not by itself a proof that every unauthorized session is gone. Conversely, s-77 inactive is valuable but cannot substitute for S42 data correctness or audit completeness.

Another dependency is the event trail. The C27 first isolated candidate passes the proposed slot values and manual enrollment function, yet its alternate API-route audit record has a blank actor field. If the owner-defined gate requires useful audit actor and request fields, the correct decision is no-go even if the visible page works. The test result must remain in the record; an engineer must not silently redefine “good logging” to mean “any log line exists” after seeing a failure.

8.8 Design the gate before the experiment

An acceptance gate is a contract agreed before the outcome is known. For this classroom gate, five criteria are mandatory: (1) the three slot values match approved intent; (2) both manual and scheduled routes behave correctly; (3) new audit events include required actor and request identifiers; (4) the original evidence and its provenance remain preserved; and (5) a rollback checkpoint and owner exist. For any absent or failed mandatory criterion, the decision is stop for review. A percentage score is useful for diagnosing test coverage, but it must not replace the stop rule.

At 10:16, C27's first isolated run reveals the missing alternate-route audit actor. It is a failed acceptance test despite data correctness and a successful manual path. This is not proof of an exploited vulnerability or malicious tampering; it is a failure against a deliberately declared recovery criterion. At 10:20, C28 records an application-owner audit-mapping adjustment in isolation and a rerun where slot targets, both service routes, the new audit fields and rollback copy meet the supplied gate. The outcome is isolated candidate pass—not an implemented production change.

In real operations a pass in a rehearsal is conditional on the fidelity of the test environment: schema versions, dependency mocks, test identities, feature flags, clock and notification routing may differ from production. Describe what was simulated and what was not. A worker that succeeds against an in-memory stub may still fail with the real queue, credential rotation or network path. The owner decides whether remaining differences permit a guarded production change; this book does not declare that an isolated pass authorizes production automatically.

C29 supplies the missing operational decision as an independent case record: at 10:24 the service owner and incident lead approve a bounded S42 correction and staged restart; at 10:26 the authorized operators report performing it. At 10:30 read-only checks show intended S42/S40/S41 values, approved batch-17 function and useful new audit fields. This is early operational verification over a four-minute window. It is incorrect to relabel C28's isolated result as C29's approval or to promote C29's 10:30 first checks directly to sustained acceptance.

8.9 Rollback is a transaction to be justified, not a magical undo button

A rollback has its own trigger, authority, scope, expected effect, evidence and test. If a C29 staged change produces wrong slot values, a failed legitimate route or a blank new actor field, the owner should stop advancement and ask the designated operator to invoke the approved recovery path. Before rollback, preserve enough evidence of the failed state to diagnose what happened. If the rollback itself would erase more recent legitimate changes, it needs another reconciliation decision rather than blind execution.

Distinguish configuration rollback from business-state rollback. Restoring a prior configuration may reinstate application behavior without restoring lost reservations. Restoring a prior data snapshot may alter current business state. Neither action can retroactively retract messages already delivered or restore historical logging fields that were never collected. The rollback operator should report the exact version changed, the post-action state and observed business checks. The incident lead should record whether security monitoring and identity controls remain effective after reversal.

C30 adds the owner acceptance that C29 lacked. At 10:45, a 15-minute monitored interval reports no unexpected S42 edits or scheduled-job failures in the observed sources. The service owner accepts limited return to service and assigns two more hours of monitoring. Do not rewrite “two hours assigned” as “two hours completed,” or “no unexpected edits observed” as “no other path could ever edit S42.”

There is a valid measurement from the 09:04 support ticket receipt to 10:45 owner acceptance: 101 minutes. There is no supported claim that CTN met or violated an RTO, because no approved objective is supplied. Similarly, the 08:30 backup's age does not equal actual data loss; the chosen targeted reconciliation deliberately preserves later authorized S40/S41 reservations. Service targets and denominators have to be defined by the service owner before a performance claim is credible.

8.10 Correct recovery recommendation and a deceptive alternative

Correct recommendation after C26 and before C27: “Use the 08:30 snapshot as a preserved reference, not as the immediate full restore. The owner-approved target is S40/S41 reserved and S42 open; the snapshot would erase valid S40/S41 changes. Request permission for an isolated, version-checked S42 reconciliation that preserves other slots and can produce required audit data. Preannounce mandatory two-route, audit, preservation and rollback tests. If any fail, stop and revise the candidate before a separately approved production change.”

Incorrect recommendation: “The snapshot digest matches, therefore restore it wholesale. If the webpage works, close recovery and send an all-clear.” A valid digest has no knowledge of the correct business target. A webpage check omits the alternate route, the scheduled job, the required audit field, rollback and monitored acceptance. An “all-clear” also conflates service readiness with unknown human attribution and later privacy assessment. The correct decision is more constrained even though it may require greater coordination.

8.11 Offline laboratory: candidate mismatch and mandatory gate

Goal: compute exact slot mismatches and distinguish a failed acceptance gate from a passing one. Inputs: synthetic owner target, 08:30 copy, 10:12 current state, and two isolated acceptance checklists. Safe execution: Python 3 only; no file or network access; the gate dictionaries are modeling assumptions. Evaluation: the two mismatches and two pass/fail labels must match the recorded output, and the learner must explain why C28 cannot independently authorize production.

target = {"S40": "reserved", "S41": "reserved", "S42": "open"}
candidates = {
    "snapshot": {"S40": "open", "S41": "open", "S42": "open"},
    "current": {"S40": "reserved", "S41": "reserved", "S42": "unavailable"},
}
for name, state in candidates.items():
    gaps = [key for key in sorted(target) if state[key] != target[key]]
    print("C8", name, "mismatch:", ",".join(gaps))

checks = {
    "C27": {"data": 1, "manual": 1, "scheduled": None, "audit": 0, "rollback": 1},
    "C28": {"data": 1, "manual": 1, "scheduled": 1, "audit": 1, "rollback": 1},
}
for name, result in checks.items():
    print("C8", name, "GO" if all(result.values()) else "NO-GO")

Executed output:

C8 snapshot mismatch: S40,S41
C8 current mismatch: S42
C8 C27 NO-GO
C8 C28 GO

The flags are synthetic summaries of the specified isolated checks, not measurements of a live application. In particular, the C27 scheduled value None means “not established as passing in this modeled gate,” not a newly discovered C27 scheduled-job failure. The C28 “GO” means isolated gate passes; it says nothing about authorization or production deployment. The fixture omits concurrency, user permissions, transaction invariants and actual audit content by design. The learner must retain those limits.

8.12 Recovered data must satisfy a business invariant, not resemble a backup

A recovery candidate is a data copy or proposed correction that still needs testing; a recovery target is the state the accountable service owner has accepted. The difference matters at CTN because C26's intact 08:30 snapshot would make S42 open but also revert approved S40/S41 reservations. Byte integrity of that snapshot cannot establish business correctness. Nor does a small, targeted S42 change automatically preserve all constraints: a real application might maintain seat counts, audit state, retries, notifications and relational invariants across more than one row. This chapter's three-slot data are a bounded teaching frame, not the complete CTN database.

For a supervised recovery plan, define the unit of acceptance before choosing the tool: an owner-approved S42 enrollment state plus continued correctness of S40/S41 and dependent workflows. Request a read-only current-version source pointer. Compare snapshot and current states with the owner-approved target, identify accepted work since the snapshot, and document any incomplete journal coverage. Prefer a controlled application path over an undocumented direct database edit; ask the system owner which transaction boundary guarantees a consistent result. A precondition such as "S42 still has the expected version before writing" stops a stale candidate from overwriting a legitimate intervening change. The condition must be enforced atomically by a real approved workflow; the toy diff alone cannot enforce it.

NIST SP 800-184 describes planning, testing and improving recovery, including prioritizing organizational resources. The five acceptance gates used here—correct data, authorized action, denied unauthorized action, usable actor/request audit and rollback readiness—are original CTN acceptance criteria, not mandatory NIST controls. A locally approved business-impact analysis would separately set recovery time and recovery point objectives.

8.13 A recovery receipt chain has several independent owners

The recovery lead can produce an isolated copy test without approving production writes. The application owner checks versions, integration routes and audit fidelity. The identity owner checks the separately changed authentication path. The service owner chooses the acceptable returned enrollment functionality, residual restrictions and monitoring. The incident lead coordinates the change and preserves a record of risk, but cannot substitute a technical smoke test for the business acceptance decision.

The chronological CTN chain is instructive. C25's 10:11 check verifies one specific session inactive after a separately approved identity action; it does not prove every identity path closed. C26 supplies the backup/current/target comparison. C27 at 10:16 fails the audit actor criterion, despite favorable limited data and manual-function checks. C28 at 10:20 supplies a new isolated pass after a mapping adjustment. C29 separately records 10:24 production authorization, 10:26 operator action and 10:30 initial production observations. C30 records a 15-minute monitored interval and limited owner acceptance at 10:45, with another two hours of monitoring assigned, not completed. No step backdates the next one. The approved 09:04 ticket-to-10:45 receipt interval is 101 minutes; absent a predeclared owner RTO target or verified outage-onset semantics, it is not proof that RTO was met. A candidate copy's nominal age is not a verified lost-transaction duration.

Treat each gate as PASS, FAIL or UNKNOWN. When the audit field is blank, that mandatory gate is FAIL. If scheduled-route behavior was not observed, it is UNKNOWN rather than an invented success. Approval for the isolated test is not production approval; reported production execution is not the owner's acceptance.

8.14 Two contrasted recovery recommendations

Defensible candidate selection: The engineer freezes C26's snapshot as a reference and asks the service owner to confirm S40 and S41 must remain reserved while S42 should be open. The snapshot candidate is rejected for wholesale use because it regresses valid bookings. The do-nothing candidate leaves an observed wrong S42 value. A conditional targeted reconciliation is selected for isolated testing: compare current version, use an approved transaction path, retain original state, check both authorized and denied operations, require actor and request identifiers on each relevant audit route, and define a rollback/reopen condition. When C27 fails the audit gate, the reviewer records NO-GO instead of approving 4/5. C28 later supplies a separate isolated pass; C29 and C30 provide further evidence for bounded operational acceptance, not retroactive authority.

Incorrect "fast restore" case: "The backup hash matches and the test import was quick. Restore everything, count the import duration as RTO, and close once the page loads." This ignores later valid S40/S41 reservations, lacks a version precondition, omits scheduled enrollment and actor attribution, and confuses a technical task's duration with the period to approved service acceptance. The corrective request needs an explicit data ledger and two independently signed decisions: approval for the correction and acceptance after its checks.

8.15 Offline laboratory C8X — screen stale writes and incomplete release gates

Objective: Keep candidate-data differences separate from approved execution, route/audit tests and owner acceptance. The program uses invented in-memory values, not actual recovered CTN data or authenticated receipts. Python 3 standard library only; no files, account changes or network.

TARGET = {"S40": "reserved", "S41": "reserved", "S42": "open"}
SNAPSHOT = {"S40": "open", "S41": "open", "S42": "open"}
CURRENT = {"S40": "reserved", "S41": "reserved", "S42": "unavailable"}

def assess8(data, manual, scheduled, audit, owner, receipt, version_ok):
    if not version_ok:
        return "STOP_STALE_VERSION"
    if not receipt:
        return "NO_EXECUTION_RECEIPT"
    if data is not True:
        return "DATA_GATE_FAIL"
    if manual is not True or scheduled is not True:
        return "SERVICE_GATE_FAIL"
    if audit is not True:
        return "AUDIT_GATE_FAIL"
    if not owner:
        return "NO_OWNER_ACCEPTANCE"
    return "BOUNDED_ACCEPTED_NOT_INCIDENT_CLOSURE"

print("SNAPSHOT_MISMATCH", ",".join(k for k in sorted(TARGET)
      if TARGET[k] != SNAPSHOT[k]))
print("CURRENT_MISMATCH", ",".join(k for k in sorted(TARGET)
      if TARGET[k] != CURRENT[k]))
base = dict(data=True, manual=True, scheduled=True, audit=True,
            owner=True, receipt=True, version_ok=True)
cases = [
    ("C27", {"scheduled": None, "audit": False, "owner": False, "receipt": False}),
    ("C28", {"owner": False, "receipt": False}),
    ("C29_INITIAL", {"owner": False}),
    ("C30_LIMITED", {}),
    ("STALE", {"version_ok": False}),
    ("AUDIT_BLANK", {"audit": False}),
    ("SCHEDULED_DOWN", {"scheduled": False}),
]
for name, changes in cases:
    print(name, assess8(**{**base, **changes}))

Literal tested output:

SNAPSHOT_MISMATCH S40,S41
CURRENT_MISMATCH S42
C27 NO_EXECUTION_RECEIPT
C28 NO_EXECUTION_RECEIPT
C29_INITIAL NO_OWNER_ACCEPTANCE
C30_LIMITED BOUNDED_ACCEPTED_NOT_INCIDENT_CLOSURE
STALE STOP_STALE_VERSION
AUDIT_BLANK AUDIT_GATE_FAIL
SCHEDULED_DOWN SERVICE_GATE_FAIL

Interpretation: This deliberately records the first blocking gate, not every simultaneous failure. C27 has both an absent production receipt and a failed isolated audit criterion; its label here is not a replacement for C27's original isolated-test NO-GO. C28 remains isolated candidate pass in the original five-gate rehearsal and has no production receipt in this second artificial sequence. C29_INITIAL assumes test flags and a production receipt but no owner acceptance. C30_LIMITED is a synthetic selected-scope acceptance; it does not close an incident or authenticate the supplied evidence. The STALE adversarial input rejects a change to S42 even with every other flag true; AUDIT_BLANK and SCHEDULED_DOWN independently demonstrate mandatory-gate failure.

Supervised activity: Freeze C26 target, snapshot and current tables. Explain which specific approved reservations a whole restore would regress; construct a targeted correction proposal with authoritative version check; predict the nine output lines; state why C27 and C28 differ from C29/C30; and draft one owner-specific monitoring/reopen trigger. Eight-point rubric: two for data-loss comparison, two for approval/execution/acceptance separation, one for the stale-version stop, one for audit failure, one for service dependency and one for rejecting full recovery from C30. This does not authorize a live restore.

8.16 Synthesis and next decision

A recovery candidate may be technically usable yet fail current owner-approved data, audit or service criteria. A service may be conditionally accepted without a complete actor finding or an established future monitoring result. Preserve C27's failed audit observation, C28's isolated correction, C29's independently approved production work and C30's limited owner acceptance as different records. Chapter 9 then introduces a new, unverified information claim whose communication and privacy route must not be collapsed into a service-restored announcement.

Each record keeps its own source, approver and time.

Common errors and limits

• Choosing the most recent backup without comparing its contents to the approved target and later legitimate writes.
• Calling C28 a production success. It is an isolated copy; C29/C30 supply later operational evidence.
• Accepting C27 despite a failed preannounced audit criterion without an explicit revised risk decision.
• Saying C25 proves “all access removed.” It verifies one session and one method; discovery scope remains limited.
• Treating C30's limited acceptance as incident closure, privacy resolution or a proof of no future recurrence.

Practice: recovery gate review

Assign recovery custodian, application owner, service owner and observer roles. Given C25/C26, each writes the target and failure conditions before reading C27. Reveal C27, record a no-go rationale, then reveal C28 and require a fresh gate decision. Finally reveal C29/C30 and compare isolated, production and monitoring evidence. The practice uses only invented values and the local Python fixture; no restoration is performed by the learner.

Exercises — subject 8

EX036 — Candidate comparison. Inputs: C13, C25 and C26. Compare whole snapshot, do-nothing and targeted-reconciliation options for S40/S41/S42 correctness, service impact, permission, rollback and remaining uncertainty. A 2-point result rejects a whole restore as currently specified without rejecting backups in general.

EX037 — Acceptance gates. Inputs: C27 and C28. Score each against the five criteria in §8.4, name the first failed criterion, and write separate isolated-test decisions. A 2-point result records C27 no-go and C28 isolated pass without claiming production success. Reproduce the C8 isolated gate labels in §8.11 and explain why an unknown scheduled-route result cannot compensate for the failed C27 audit criterion.

EX038 — Value-diff fixture. Run or hand-check the Python fixture in §8.3. Reproduce both exact output lines, state the value implication and one reason the code cannot authorize a real correction. A 2-point result notices both S40/S41 regression risk and S42 mismatch. Compare the two original value-diff lines with the C8 mismatch lists in §8.11; specify a version-precondition stop rule.

EX039 — Staged return record. Inputs: C29/C30. Produce a timeline of approval, execution, first production checks, 15-minute observation and owner acceptance, with a rollback trigger and 2-hour monitoring owner. A 2-point result does not call 10:30 a sustained-stability result.

EX040 — Recovery handoff. Inputs: C20–C30. Write a 130–190-word handoff with data choice, C27 failure and C28 correction, C29/C30 outcome, residual risk, unresolved actor and next checkpoint. A 2-point result distinguishes measured 101-minute interval from an unspecified RTO target.

Subject synthesis

CTN's limited return is supported by a data comparison, failed and passing isolated gates, a bounded production approval, observed service behavior and a 15-minute review. The case remains open for monitoring, source-quality review and possible data questions. Chapter 9 will separate operational status messages from a new, unverified privacy signal and route notice decisions to the appropriate owner.