#### Day 41 — Separate business recovery evidence from possible data impact **Objective.** Independently substantiate a service-status claim and a data-assessment claim, showing source IDs, as-of time, uncertainty, owner and next discriminating question. Complete [EX041](#exercise-ex041); inspect [its worked explanation](#answer-ex041) only afterward. **Technical teaching.** A status proposition has a subject, measurable scope, time horizon and evidence producer. A technically sound recovery test concerns whether a *specified service state* satisfies the service owner's acceptance criteria. It does not determine which notification stages occurred, whether personal information was exposed or what a legal duty requires. The fallacy of transferring a successful result from one claim to another can be prevented by a **two-track claim ledger**: record (a) observation and receipt, (b) inference bounded by source coverage, (c) decision owner, and (d) next test. [NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final) places response within organizational cybersecurity risk management; the ledger and CTN approval assignments are original teaching devices. **Worked example at 11:00 UTC.** Freeze the case at the moment C33 is released, retaining the original event times: | Track | Supported observation and decision | Evidence limit | Next accountable action | |---|---|---|---| | Service | C29 records 10:24 production approval, 10:26 reported operation and 10:30 checks. C30 records **limited** S42 acceptance at 10:45 after 15 minutes of bounded monitoring. | The additional two monitoring hours, incident closure, alternate routes and historical actor identification are not proved. The 101-minute ticket-to-acceptance measurement has no approved RTO target. | Service owner monitors acceptance; incident lead escalates on a new S42 edit, job failure, wrong data or required audit failure. | | Possible data effect | C31 reports a batch created at 10:47 and released at 10:48 with **12 pseudonymous tokens**; C32 opens a restricted privacy review at 10:52; C33 at 11:00 reports the scoped internal entries **not-dispatched**. | There is a 10:49–10:51 gateway log gap. Neither 12 people, message contents, external dispatch, nor universal nondispatch is established. | Privacy steward defines purpose and scope; gateway/queue custodian investigates only approved batch and range; legal authority decides duties. | The two rows do not conflict. C30 supports only a limited operational state; C33 concerns a distinct queue. A gap in a gateway is **missing observation**, not evidence for either “sent” or “never sent.” A pseudonymous token count is not a count of validated data subjects. Importing C33 into an earlier 10:45 service decision would also violate the release chronology. A message's **as-of time** must not be confused with the time stamped inside a source later acquired. **Counterexample.** “The portal is back, so no data could have left” borrows a recovery conclusion to answer a privacy question. “Twelve customers were breached” invents mapping and transport. Even perfect formatting cannot rescue unsupported premises. **Independent practice.** For [EX041](#exercise-ex041), produce two rows without copying the table: UTC cutoff, claim, source IDs, uncertainty and source coverage, accountable role, and one falsifiable source request. Add a deliberately rejected claim and state why it is rejected. **Artifacts:** two ledgers, one rejection note. **Rubric 0–2:** 2 for separate support/limits and next owners; 1 for incomplete checkpoint or custodian; 0 for invented exposure, closure, future observation or affected persons. Compare the [existing answer and day extension](#answer-ex041). **Continue studying — Day 41:** [← Day 40](#week-08-day-05) · [Course index](../SUBJECTS.md) · [Day 42 →](#week-09-day-02) ### Exercise for this lesson **EX041 — Two-track status ledger.** Inputs: C29–C33. Write separate service and data-assessment lines at 11:00 with source IDs, confidence, owner and next checkpoint. A 2-point result preserves C30's limited service acceptance and C33's incomplete external-delivery picture. ## Worked answers **EX041 — Model two-track status.** Service line: “At 10:45 C30 records service-owner acceptance of S42 return after C29's production checks; two-hour monitoring continues. Owner: service owner and application operator. Next checkpoint: scheduled monitoring review or any new S42 write.” Data-assessment line: “At 11:00 C31 shows 12 pseudonymous tokens in an internal staging batch; C33 reports the batch `not-dispatched` but the inspected gateway window has a 10:49–10:51 gap. External delivery and affected identities remain unconfirmed. Owner: privacy steward with queue/gateway custodians. Next checkpoint: approved scoped gateway/source review and 12:00 status.” One line must not borrow the other's confidence. **Additional professional worked reasoning:** The internal note must distinguish C30's 10:45 limited acceptance from C31's 10:47 staging batch and C33's 11:00 scoped not-dispatched queue status, with the gateway gap expressly unresolved. Name privacy steward and incident lead as different owners. Do not equate an internal queue state with every possible gateway/export path or claim twelve affected learners.