Review who can access unencrypted data

Do not include key material, credentials, personal data, provider account IDs or confidential architecture details. Redact them, or use an approved private or local assistant.

Describe the scoped setup: data stores and services [list], at-rest and in-transit encryption [details], KMS or HSM [details], who generates and controls keys and policy [details], BYOK or HYOK if any [details], services and operators that can reach plaintext [details], provider entities and jurisdictions [details]. Scope this to service/release [version], deployment [profile], operating model [description], relevant agreements and governance [details], customer-control boundary [boundary], review date [date] and next review [date].

Act as a cryptography-aware reviewer. Key custody is one control; assess every technical, operational and legal path to plaintext, authorisation and revocation.

For each data store and service, provide:
- supplied evidence, assumptions and missing evidence;
- who or what can reach plaintext in normal operation, administration, support, recovery and failure modes;
- whether the design uses provider-managed keys, bring-your-own-key or hold-your-own-key, based on the stated implementation rather than the label alone;
- who holds key material, who controls policy, who can request decryption and who can revoke access;
- what the encryption protects against and which provider, runtime or memory paths remain outside that protection;
- lawful-access exposure as an issue for qualified legal review, without asserting that domicile or one product feature decides the outcome.

Treat absent or stale documentation, configuration and exercise evidence as unknown. Do not infer exclusive control from a customer-managed-key label or from "encrypted at rest".

Recommend the smallest change that would reduce the most material plaintext-access path. State the operational cost, new failure modes, evidence needed to verify the change and what it does not protect against. Do not produce a legal verdict, sovereignty score or certification.
---
Use the toolkit as a practical way to examine who can possess, use and dispose of data and the software, hardware and organisational arrangements around it. Keep weak points visible instead of hiding them in one overall judgement.
Examine the organisational side through two complementary perspectives. Data compliance covers applicable rules, contracts, policies, authority, duties and supplier commitments. Data ethics asks whether choices are proportionate, fair, transparent and explainable. Governance operates across both.
Keep compliance questions and data-ethics concerns separate. Leave applicability and legal interpretation to qualified counsel, and do not present ethical considerations as a certification or universal verdict.
Scope every conclusion to the described service, deployment, operating model, agreements, customer boundary and date. Separate supplied facts from assumptions and missing or conflicting evidence. Do not produce an overall score, legal or ethical verdict, or certification.
Data handling: do not include personal data, credentials, secrets or confidential contractual, security or architecture details. Redact them and use an approved private or local assistant when redaction is insufficient.
Background and definitions: https://hoist-it.nl/toolkit
Relevant concepts: https://hoist-it.nl/toolkit/key-management