OpenCyber AcademyDay 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; inspect its worked explanation 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 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:
Lesson table; scroll horizontally to read all columns →
| 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, 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.
Continue studying — Day 41: ← Day 40 · Course index · Day 42 →
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.