- Trace a real data export instead of checking only the primary application.
- Separate encryption coverage from the permissions that expose decrypted data.
- Test key recovery and retain access to keys needed for older backups.
An HR platform may encrypt its database while an exported payroll spreadsheet sits on an unmanaged laptop. Reviewing only the platform's encryption setting misses the copy employees actually use.
Start with one sensitive business workflow and follow its data. Record the original system, exports, email attachments, shared folders, devices, backups, and supplier destinations. Ask the owner why each copy exists and whether it still needs to be retained.
Trace an ordinary export
For a hypothetical payroll workflow, ask an authorized employee to describe the transfer using test data. Does the export land in Downloads? Is it attached to email, uploaded through a portal, or copied to a shared drive? Who can open each copy, and what removes it afterward?
Create a short record for each location: data owner, access group, encryption method, key custodian, retention decision, and recovery dependency. Do not put keys or passwords in the record.
Prefer the approved transfer route with the fewest unnecessary copies. If a file must be encrypted separately, use an organization-approved method and communicate access secrets through a separate protected channel. Verify the recipient and avoid treating any password-protected archive as equivalent to a reviewed encryption solution.
Check what encryption does and does not protect
Device encryption can protect stored data when a lost device is powered off and appropriately secured. It does not stop an attacker using an already authorized session from opening files the user can access. Likewise, encryption at rest in a SaaS platform does not correct excessive sharing permissions.
Review transport protection for transfers, stored-data protection at each destination, and the permissions that release decrypted information. Include old devices and removable media in the inventory. A current laptop policy cannot establish how a retired drive was handled.
CISA's Encrypt Business Data guidance is a starting point for coverage. Pair it with access reviews and data reduction rather than assuming encryption addresses every disclosure path.
Assign key ownership
NIST's key management guidance covers protection and lifecycle management of cryptographic keys. For a small team, the immediate questions are operational: who can retrieve a recovery key, who can authorize its use, and what happens when that person leaves?
Distinguish vendor-managed encryption from customer-managed keys. Customer control introduces responsibilities for availability, permissions, rotation, and deletion; it is not automatically the right choice for every service. Confirm the specific product's behavior before changing settings.
When rotating keys, verify how older encrypted copies remain recoverable. Deleting a key needed by retained backups can make the backups unusable. Record dependencies before scheduling destructive changes.
Test recovery without disclosing secrets
Use an authorized test device or protected sample backup. Have an alternate administrator follow the recovery procedure, retrieve the necessary key through the approved process, and demonstrate access to the expected data. Log the authorization and outcome, not the secret value.
If the only key copy is inside the encrypted system being recovered, resolve that circular dependency. Protect any independent recovery copy with appropriate access controls and auditability.
Finish the review by removing unnecessary exports, correcting broad access, and assigning the remaining encryption gaps. Keep the data map with the service's recovery documentation so the next device replacement, vendor change, or staff departure does not erase key ownership.
Turn this response guidance into clearer roles, containment decisions, evidence paths, and executive briefing rhythm.