Deciding
Worked example: prioritizing three data classes
Compare health records, signed firmware, and session analytics; distinguish exposure rank from a conditional program order.
7 min read · 7 min 14 sec film
What you'll be able to do
- Apply the full reasoning chain to concrete, contrasting data classes.
- Distinguish a genuine HNDL priority from a future-forgery priority within the same worked example.
- Propose a conditional work order and name evidence or dependencies that could change it.
Lesson film
Watch: Worked example: prioritizing three data classes
Three data classes, the same four questions, and one of them turns out not to belong in the ranking at all.
7 min 14 sec · 9 scenes
7 min 14 sec, narrated by your browser's voice. Captions and a full transcript are below — nothing here needs sound.
A reasoning chain only proves useful when it is run on something specific, so here are three things an organisation plausibly holds at once.
With the player focused: Space plays or pauses, ← → seek ten seconds, Home restarts, M toggles narration.
Full transcript
1. Run it on something real
2. The three candidates
3. Health records
4. Recorded properly
5. The one that leaves
6. Session analytics
7. The order, with reasons
8. Defensible, not just decided
9. Takeaway
The written lesson
The chain only proves useful when it is run on something specific. Take three data classes an organization plausibly holds at the same time: patient health records, a firmware code-signing key, and session analytics. Each goes through the same questions: how long must it stay confidential, where can it be captured, and what cryptography actually protects it.
| Data class | Confidentiality lifetime (X) | Harvestable today? | What protects it |
|---|---|---|---|
| Health records (backups, replicated to a third-party analytics platform) | Decades | Plausible vendor-storage capture under the stated access model | Backup encryption key directly RSA-wrapped; both backup and wrapped-key file held by the same third party |
| Firmware signing key (signs released firmware images) | Not an HNDL question — see below | Not applicable to confidentiality | An RSA or ECDSA signing key |
| Session analytics (short-lived click and session data) | Hours to weeks | Partially — passes over the internet in transit | Hybrid TLS key exchange on ingest; classical-only on one internal replication hop |
The publicly distributed signed firmware is not an HNDL ciphertext merely because its signature is classical: recording it today does not create a later decryption path. Its authenticity, however, has a long trust lifetime; future forgery and archival verification belong on a separate track. An encrypted backup of the private signing key would be a different confidentiality flow to analyze on its own terms.
- 01
Health records — lifetime
Decades of required confidentiality, and roughly none of it has elapsed for recently collected records.
- 02
Health records — harvestability
A third-party analytics platform holds a replicated copy with its own retention policy — a plausible, durable capture surface independent of the primary system.
- 03
Health records — protection path
Both the encrypted backup and its RSA-wrapped data key are held by the third party under this example. If an adversary captures both, the wrapping path is quantum-vulnerable.
- 04
Health records — verdict
Long X and a plausible capture of both needed artifacts make this the clearest HNDL candidate in the example. The program sequence still depends on migration time, impact, confidence, and shared dependencies; no value of Y is supplied here.
Session analytics may be lower priority if the underlying data truly loses confidentiality value after hours or weeks. Confirm that the payload does not contain long-lived identifiers or sensitive attributes, and inspect the classical internal hop. A short session token lifetime by itself is not evidence that every copied datum is short-lived.
An automated inventory or prioritization tool can help organize evidence, but it cannot by itself verify data-owner secrecy needs, every capture route, or a vendor claim. Revisit decisions when underlying observations change.
Work it through
H01: build an exposure register
A fictional organization has one migration team and four assets. The owner wants a first tranche, an explicit uncertainty list, and the observation most likely to change the order. Ranges and facts below are exercise inputs, not claims about any real deployment.
About 20 min of unscored practice
Evidence supplied for this exercise
| Asset | Secrecy / impact | Capture and protection evidence | Lead time / dependency |
|---|---|---|---|
| A. Patient export | Owner says 20+ years; high harm from disclosure | Vendor holds AES-256 backup and a stored RSA-wrapped data key; both artifacts accessible to a vendor-storage intruder | 2-4 years; vendor replacement needed |
| B. Internal research store | 10-20 years; moderate to high business impact | Separately generated AES-256 key in isolated HSM; no identified vulnerable key transcript or wrapped key under stated insider-only model | 1-2 years; access review needed |
| C. Partner gateway | Contracts may contain 10-year trade secrets; owner confirmation pending | One sampled TLS hop is hybrid; partner-to-origin group unknown; partner says it keeps logs | 6-12 months; partner cooperation needed |
| D. Firmware root | Authenticity for devices that cannot all receive updates | ECDSA signing key; distributed trust anchors on 8-year-life devices | 4-6 years; device firmware and OEM dependency |
Your task
- Build a row per asset with observed facts, missing evidence, planning assumption, confidence, risk type, and next action.
- Rank HNDL candidates separately from authenticity work; then recommend a first program tranche under the one-team constraint.
- State one plausible new observation that would reverse part of your sequence.
Type here or copy the template. Your response stays in this page and is not submitted or scored.
Reveal model response and self-check rubric
A different answer can be sound when it states its assumptions and follows the evidence.
A is a strong HNDL candidate: long secrecy, a credible copy of both backup and RSA-wrapped key, and a long vendor path. Verify the wrapping details with the vendor and start dependency work. B is lower HNDL priority under this stated threat model: an AES label alone does not supply a later public-key recovery path; inspect HSM access and copies. C is unresolved rather than safe: sample the partner-to-origin exchange, inspect logs, and confirm the data owner’s lifetime. D is an authenticity program, not a record-decryption case; its long device lead time may justify immediate preparatory work despite a different risk type.
A defensible first tranche starts A vendor engagement and D device compatibility discovery, while collecting C handshake and retention evidence immediately. With one implementation team, the first deployment could be C if its classical hop is confirmed and can be fixed quickly; this must be described as a conditional choice, not a universal rank. If C is fully hybrid and stores no sensitive copies, A moves ahead. If D trust anchors cannot be updated before device renewal, D may require earlier engineering capacity.
Self-check
For each point: 0 = absent or incorrect, 1 = partly supported, 2 = well supported.
- Trace necessary capture artifacts and protecting keys; do not rank from AES or an asset label alone.
- Keep facts, assumptions, date, confidence, and next verification separate.
- Distinguish HNDL confidentiality from future signature/authenticity work.
- Consider migration lead time, impacts, shared dependencies, and alternatives under the capacity constraint.
- Name a new observation that could change the recommended order.
Primary reading and claim sources
Publication status checked on the date shown. Draft guidance can change.
- Cybersecurity in an Era with Quantum Computers: Will We Be Ready?Michele Mosca · Research paper · checked 2026-09-26
- TR 104 016: A Repeatable Framework for Quantum-Safe MigrationsETSI · Published technical report · checked 2026-09-26
- SP 800-30, Revision 1: Guide for Conducting Risk AssessmentsNIST · Final guidance · checked 2026-09-26
- RFC 4998: Evidence Record SyntaxIETF · Standards-track RFC · checked 2026-09-26
Marking a lesson complete only updates this browser.