Key takeaway
Encryption protects a package only within its actual key and access arrangements. Identify who can decrypt it and what remains after access ends.
Ask about the path to plaintext
A recipient may say that every stored file is encrypted while its application, administrators and backup operators can all obtain readable copies. The word encrypted answers one technical question. It does not identify the people and services that can see records, the approved purpose, or the copies created after decryption. Start with the actual access path.
NIST’s key-management guidance distinguishes key associations, revocation and destruction. It calls for associating keying material with its use and entities, and considers eventual destruction of copies. Apply those concepts as review questions for the proposed environment, not as a certification that a recipient’s chosen product or architecture is suitable.
A hypothetical key-and-copy review
A fictional approved evaluation uses package E1 for seven days. Its recipient proposes a managed encrypted store. Before release, the owner asks who can request decryption and where readable extracts can persist. The names below describe roles, not actual companies or a design recommendation.
The review needs evidence for each route, including routes operated by the recipient’s vendors. Listing a service provider is not itself approval for that provider to access this package.
| Access route | Who controls it | Evidence requested | Open decision |
|---|---|---|---|
| Evaluator application | Named recipient service role | Role-to-package access policy and bounded test | Approve only specified purpose/period |
| Administrator recovery | Recipient security team | Recovery privilege and access-log procedure | Review elevated plaintext access |
| Backup/key copy | Hosting operator | Copy inventory and retention/key lifecycle | Resolve exit treatment |
| Downloaded analysis file | Named evaluator | Approved output scope and copy log | Separate readable-copy handling |
| Evaluation expiry | Recipient operations owner | Access removal and copy closure evidence | Revocation alone does not prove erasure |
Use identifiers in the record, never keys
An internal review record can contain the package version, key identifier, controlling organization, authorized role, application purpose, approval period and evidence location. It should not contain secret key material, recovery credentials or passwords. Ask the technical owner to review the mechanism in the appropriate secure environment rather than pasting sensitive configuration into a business brief.
Distinguish who administers a policy from who can exercise decryption. A person may be able to change a role without routinely seeing records; a service may decrypt automatically on behalf of several users. Map that distinction and any separation of duties. Review temporary support and emergency access explicitly rather than treating them as impossible because the normal evaluator list is short.
An expiry needs more than an access toggle
NIST treats ending authorized key use, destroying key copies and retaining relevant audit metadata as distinct lifecycle concerns. For the evaluation, ask separately about credentials, key copies, encrypted backups and readable extracts. Removing an application role may prevent future reads through that role while leaving a previously downloaded file untouched.
If the recipient proposes cryptographic erasure, have the responsible security owner establish its actual scope and evidence. Do not infer that it resolves independent plaintext copies, differently keyed backups or trained artifacts. The closure record should state which artifacts were addressed, which obligations remain and who can verify each assertion. Avoid promising a stronger outcome than the mechanism supports.
NIST’s September 2025 sanitization guide makes the limitation concrete: cryptographic erase addresses encrypted data through keys, while prior plaintext and backed-up or escrowed copies need separate consideration. Ask what the proposed mechanism covers and how all relevant key copies are addressed. That technical evidence must precede an assertion that the evaluation has been closed.
Resolve the smallest necessary environment question
E1 remains on hold until the recovery route, backup lifecycle and downloaded-output scope are resolved. The review can start with architecture descriptions and a synthetic test package; the actual records need not be exposed to discover an unexplained administrator path. Define the evidence that would release the hold and who has authority to assess it.
Use buyer diligence to record these questions and the introduction brief for a separately approved metadata discussion. VOID’s initial referral does not install encryption, take source records or certify the receiving environment. A later evaluation needs its own recipient, purpose, permission and handling decision even if the proposed system uses a familiar security label.