A suspect key file has no dates on it — how do you bound which stored data it protected, and over what window?

seniorshould knowfreq 54%

answer

two boundaries, then the contents
when could it encrypt at all
ciphertext names the key that wrote it
usage records find undocumented callers
missing evidence widens scope, never narrows

basics

~20 s

Bound it from three sides: the period the key could encrypt, the datasets whose ciphertext names it, and what the manager's usage records show calling it. Where a side is missing, the honest scope is everything it could have covered.

solid answer

~40 s

Scoping produces two answers, not one — which data, and over what window. The window's early end is when the key came into existence; its late end is the newest stored ciphertext that names the key, which beats any documented retirement date, because a write proves use and a document does not. The data comes from three sources: the key identifier carried in each record, the manager's usage records naming which callers asked it to operate, and the derived copies — backups, replicas, exports — that inherit whatever the live dataset had. Then write the gaps down explicitly. Usage-record retention ends the evidence, not the activity, so an unbounded side stays unbounded; treating absent records as proof of non-use is how a key-compromise report ends up understating the scope.

code

json · 19 lines

json

{
  "keyId": "key-a41",
  "keyCreatedAt": "2023-02-11",
  "lastEncryptingWriteSeen": "2026-08-30",
  "documentedRetirementDate": "2025-11-01",
  "datasetsNamingKey": ["orders", "order_attachments", "settlement_exports"],
  "callersSeenInUsageRecords": ["order-writer", "nightly-export", "unattributed-host-7"],
  "usageRecordsCoverFrom": "2026-06-22",
  "derivedCopiesInWindow": {
    "nightlyBackups": 1286,
    "readReplicas": 2,
    "partnerExports": 41
  },
  "evidenceGaps": [
    "no usage records before 2026-06-22",
    "partner export destinations unrecorded",
    "file-level backups carry no key identifier"
  ]
}

go deeper

for a junior

Recall that scoping asks two things: which data a key protected and between which dates. Both need evidence from the systems, not from anyone's memory of what the key was for.

for a middle

Explain where the evidence comes from: the key identifier stored beside the ciphertext, the manager's usage records, and the catalogue of derived copies. Say what each one bounds and what it cannot.

for a senior

Show that you distinguish proof from absence. Retention ends usage history without ending activity, and a write naming the key beats a documented retirement date. Push the derived copies into the scope before anyone has to ask.

for a principal

Decide what the organisation is told while the scope is still open. An unbounded side has to be reported as unbounded, and the inventory investment that would have bounded it is a standing decision, not an incident task.

What scoping has to produce

Two separate answers, and conflating them is the usual first mistake:

Which data the suspect key protected — a list of datasets and their derived copies.
Over what window it could have protected anything — two timestamps, each with the evidence that established it.

Note what does not narrow either answer: when the copy escaped. If a key file was exported eighteen months ago and only surfaced last night, the data it covered is still everything it ever encrypted. The escape date bounds how long somebody could have been reading, which is a different question from what there was to read.

Bounding the window

The early end is when the key could first encrypt. Usually its creation time in the manager, but not always — a key imported into a manager may have encrypted data long before it arrived there, and then the manager's timestamp understates the window.
The late end is the newest stored ciphertext that names the key. This is the number to trust. A documented retirement date is somebody's intention; a record carrying the key's identifier is proof something was still encrypting with it.
Usage records bound what you can prove, not what happened. Retention cuts the history at a fixed depth, and beyond that depth you have no evidence in either direction.

A worked example: the manager keeps ninety days of usage records, so on 2026-09-20 they reach back to 2026-06-22. The key was created 2023-02-11. That leaves three and a half years of coverage with ninety days of evidence — so the window is the full three and a half years, and the records tell you only about its last quarter.

Enumerating the data

The key identifier in the ciphertext is the direct route: every record that names keyId is in scope, and the enumeration is a query rather than an argument.
Whole-object encryption with no stored identifier is the hard case, and it is common in file and backup paths. There you fall back to which service held the key and what that service wrote.
Usage records name callers, which is how you find the consumer nobody documented — the export job, the analytics extract, the migration script somebody ran once.
Derived copies inherit the scope. Backups, read replicas, staging refreshes, per-report extracts and anything sent to a partner were all encrypted with the same key and are all in scope. These are routinely forgotten and are routinely the largest part of the answer.

What each piece of evidence is worth

Evidence	What it bounds	How it fails
Key creation timestamp	Earliest possible coverage	Understates it for an imported key
Key identifier in ciphertext	Which records are in scope	Absent where whole objects are encrypted
Newest write naming the key	Latest possible coverage	Missing if writes are not retained
Usage records	Callers and dates of operations	Retention cuts the history
Backup and replica catalogue	Derived copies	Catalogues lag what actually exists

Writing the scope down

State the window with both ends and, beside each, how it was established. "Created 2023-02-11 per the manager; newest write naming it 2026-08-30" is a scope. "About three years" is not.
List the datasets with the evidence for each, separating the ones enumerated by identifier from the ones inferred from which service used the key.
List the gaps as gaps. "No usage records before 2026-06-22" belongs in the report, unresolved, rather than being quietly rounded to zero.

The failure that makes the report wrong

Almost every understated key-compromise scope comes from the same move: absence of evidence read as evidence of absence. No usage records before a date becomes "unused before that date". No catalogue entry for an export becomes "no export existed". A missing identifier becomes "not encrypted with this key". Each one narrows the report without narrowing the exposure, and each one is discovered later by somebody else.

## What scoping has to produce Two separate answers, and conflating them is the usual first mistake: - **Which data** the suspect key protected — a list of datasets and their derived copies. - **Over what window** it could have protected anything — two timestamps, each with the evidence that established it. Note what does *not* narrow either answer: when the copy escaped. If a key file was exported eighteen months ago and only surfaced last night, the data it covered is still everything it ever encrypted. The escape date bounds how long somebody could have been reading, which is a different question from what there was to read. ## Bounding the window - **The early end** is when the key could first encrypt. Usually its creation time in the manager, but not always — a key imported into a manager may have encrypted data long before it arrived there, and then the manager's timestamp understates the window. - **The late end** is the newest stored ciphertext that names the key. This is the number to trust. A documented retirement date is somebody's intention; a record carrying the key's identifier is proof something was still encrypting with it. - **Usage records** bound what you can *prove*, not what happened. Retention cuts the history at a fixed depth, and beyond that depth you have no evidence in either direction. A worked example: the manager keeps ninety days of usage records, so on 2026-09-20 they reach back to 2026-06-22. The key was created 2023-02-11. That leaves three and a half years of coverage with ninety days of evidence — so the window is the full three and a half years, and the records tell you only about its last quarter. ## Enumerating the data - **The key identifier in the ciphertext** is the direct route: every record that names `keyId` is in scope, and the enumeration is a query rather than an argument. - **Whole-object encryption with no stored identifier** is the hard case, and it is common in file and backup paths. There you fall back to which service held the key and what that service wrote. - **Usage records name callers**, which is how you find the consumer nobody documented — the export job, the analytics extract, the migration script somebody ran once. - **Derived copies inherit the scope.** Backups, read replicas, staging refreshes, per-report extracts and anything sent to a partner were all encrypted with the same key and are all in scope. These are routinely forgotten and are routinely the largest part of the answer. ## What each piece of evidence is worth | Evidence | What it bounds | How it fails | |---|---|---| | Key creation timestamp | Earliest possible coverage | Understates it for an imported key | | Key identifier in ciphertext | Which records are in scope | Absent where whole objects are encrypted | | Newest write naming the key | Latest possible coverage | Missing if writes are not retained | | Usage records | Callers and dates of operations | Retention cuts the history | | Backup and replica catalogue | Derived copies | Catalogues lag what actually exists | ## Writing the scope down 1. State the window with **both ends** and, beside each, how it was established. "Created 2023-02-11 per the manager; newest write naming it 2026-08-30" is a scope. "About three years" is not. 2. List the datasets with the evidence for each, separating the ones enumerated by identifier from the ones inferred from which service used the key. 3. List the gaps **as gaps**. "No usage records before 2026-06-22" belongs in the report, unresolved, rather than being quietly rounded to zero. ## The failure that makes the report wrong Almost every understated key-compromise scope comes from the same move: absence of evidence read as evidence of absence. No usage records before a date becomes "unused before that date". No catalogue entry for an export becomes "no export existed". A missing identifier becomes "not encrypted with this key". Each one narrows the report without narrowing the exposure, and each one is discovered later by somebody else.

The team says the key was retired last year, but new ciphertext still names it. How do you resolve that?
Believe the ciphertext. A key is retired when nothing encrypts with it any more, and a write carrying its identifier proves something still did. Move the late end of the window to the newest such write, then use the manager's usage records to find which caller produced it — that caller is usually also a consumer nobody had on the list.
The usage records only reach back ninety days. What can you still say about the window?
That the key was in use across that period, and nothing more. The records bound the earliest date you can prove, not the earliest date it happened. Fall back to the key's creation time and to the age of the oldest ciphertext naming it, and record the ninety-day boundary as an evidence gap rather than as a start date.

saying these in an interview costs you the question

Scopes only the system the key file was found on
Assumes the key was unused before its earliest usage record
Bounds the window by when the copy escaped, not when the key encrypted
Trusts a documented retirement date over the newest write
Leaves backups, replicas and exports out of the scope

A suspect key file has no dates on it — how do you bound which stored data it protected, and over what window?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

What scoping has to produce

Bounding the window

Enumerating the data

What each piece of evidence is worth

Writing the scope down

The failure that makes the report wrong

▾common follow-ups2 questions

▾red flags5 flags

What scoping has to produce

Bounding the window

Enumerating the data

What each piece of evidence is worth

Writing the scope down

The failure that makes the report wrong

answer

go deeper