Encryption and key management: verify the protection chain

Encryption protects information under particular assumptions. A useful implementation explains which data is protected, against which access, and how keys remain controlled throughout their lifecycle. An “encryption enabled” setting answers only a small part of that question.

For a CTO, the engineering task is to verify the protection chain: where plaintext originates, where it travels, where ciphertext is stored, who can request decryption, and what happens during failure or recovery. That chain includes applications, identities, cloud services, administrators, backups, and operational procedures.

The following practical recommendations provide a way to design and review that chain. Start with one sensitive data store, then extend the same method to its dependent systems and secondary copies.

Define the protection objective before choosing technology

Begin with a threat statement, not an algorithm. “Protect customer records” is too broad to guide implementation. “Prevent someone holding a stolen backup from reading customer records without separately controlled keys” identifies an asset, an attacker capability, and a protection boundary.

Different threats require different controls. Disk encryption can protect a powered-off stolen laptop, but an authenticated user or malicious process may still read files while the disk is unlocked. Database encryption can protect storage media while allowing database queries to return plaintext. Application-layer encryption can restrict what database administrators see, but it may not protect against a compromised application with permission to decrypt.

Use a short data-flow inventory to make these distinctions explicit. Include production records, uploaded documents, caches, queues, analytics extracts, logs, temporary files, snapshots, and backups. Data discovery should identify copies that escape the main storage architecture, not just the systems on the architecture diagram.

For each important flow, record:

• The data category and its confidentiality needs.
• The source, destination, intermediate services, and plaintext boundaries.
• The attacker or unauthorized role the encryption is intended to constrain.
• The identity permitted to decrypt and the reason it needs that permission.
• Availability, retention, and recovery requirements.
• An owner responsible for implementation and a reviewer responsible for evidence.

A threat-modeling approach helps test whether the selected boundary matches the threat. If an attacker can assume the application's identity, transparent storage encryption alone will not prevent access through that application.

The deliverable is a protection map: a data-flow diagram accompanied by explicit assumptions and exceptions. This becomes the reference for configuration checks, authorization tests, and recovery exercises.

Understand what the cryptographic building blocks actually provide

Encryption transforms plaintext into ciphertext using a cryptographic algorithm and a key. Its confidentiality depends on the construction, implementation, key secrecy, and operating environment. A strong algorithm cannot compensate for a key committed to a source repository or an application endpoint that returns another customer's records.

Symmetric and asymmetric cryptography have different jobs

Symmetric encryption uses a shared secret key for encryption and decryption. It is commonly used for bulk data because it is efficient. AES supports 128-, 192-, and 256-bit keys, but a key-size label alone does not describe a secure implementation: the mode, nonce handling, authentication, and library behavior also matter.

Asymmetric cryptography uses related public and private keys. Depending on the algorithm and protocol, it supports encryption, signatures, or key agreement. RSA and elliptic-curve constructions have different capabilities and parameters; they are not interchangeable labels. Asymmetric cryptography is not inherently “more secure” than symmetric encryption.

Modern systems often combine them. A secure transport protocol can authenticate a peer and establish shared secrets, then use symmetric encryption to protect traffic. Bulk files are typically encrypted with symmetric data keys rather than directly processing the entire file with an asymmetric algorithm.

Confidentiality is not the same as integrity or authenticity

Authenticated encryption, such as AES-GCM used correctly, protects confidentiality and detects unauthorized changes to protected ciphertext and associated data. Nonce reuse under the same key can undermine that protection. Prefer maintained libraries and well-supported formats that handle these requirements safely; do not invent a cipher, mode, or key-exchange protocol.

Hashing produces a digest rather than recoverable ciphertext. An ordinary hash does not prove who created a message. Password storage needs purpose-built password hashing, not reversible encryption or a fast general-purpose digest alone.

A message authentication code uses a secret to verify integrity and authenticity among parties sharing that secret. Digital signatures use a private signing key and public verification key; they do not make the signed content confidential.

These distinctions matter during review. Ask which property is required and which mechanism supplies it, rather than accepting “cryptography” as a single undifferentiated control.

Check each storage layer and every secondary copy

Encryption at rest covers stored information, including data actively used by a running service. The phrase does not mean only archived or inactive data.

Different layers protect against different access paths:

Verify the actual resource configuration, not merely an account default. A default might apply only to newly created storage. Existing objects, imported volumes, replicas, or historical snapshots can follow different settings.

For databases, inspect transaction logs, temporary storage, replicas, exports, and administrative dump procedures. For object storage, check uploads, copies, replication destinations, versioned objects, and download paths. For endpoints, check recovery-key handling and whether removable media is covered.

Application-layer encryption deserves a separate design decision. It may reduce exposure to database operators or narrow which workloads can decrypt selected fields. It can also complicate indexing, searching, analytics, and support workflows. Document where decrypted values enter memory, logs, error reports, or exports.

Avoid treating encryption as a substitute for authorization. An application can decrypt a record correctly and still disclose it to the wrong tenant. Keep tenant isolation, access checks, and privileged-access controls in the same review.

Verify transport from the first sender to the final recipient

Transport encryption protects data moving between endpoints. The useful question is not “Do we use HTTPS?” but “Which connections are protected, and which identities are authenticated?”

Map browser-to-edge, edge-to-application, service-to-service, application-to-database, replication, backup transfer, administrative access, and third-party export connections. TLS termination at a load balancer creates a boundary: the next hop requires its own protection decision. A private network does not automatically remove interception or lateral-movement risks.

As a practical baseline, prefer supported modern TLS configurations and maintained client libraries. TLS 1.3 is a strong default where supported; appropriately configured TLS 1.2 may remain necessary for compatibility. Legacy SSL is not a suitable modern security choice.

Certificate validation is part of the protection. Check hostname verification, trust stores, expiry monitoring, certificate renewal, and the absence of production settings that disable validation. Encryption to an unauthenticated endpoint can protect traffic from passive observation while still sending it to the wrong party.

Mutual TLS can authenticate both ends of a connection, but it does not replace application authorization. Certificate issuance, workload identity, renewal, and revocation become operational dependencies that need owners and tests.

Distinguish transport encryption from end-to-end encryption. A service that terminates TLS and processes plaintext is not providing end-to-end confidentiality from itself. End-to-end designs reserve decryption for designated endpoints; they introduce separate questions about device enrollment, recipient verification, multi-device access, and recovery.

The evidence should include configuration and connection tests. Test rejected invalid certificates and prohibited protocol versions, not just one successful encrypted connection.

Govern keys as assets with a lifecycle

Keys require generation, storage, authorized use, replacement, revocation, retention, and destruction. Each stage should have an owner and a defined procedure.

Generate and register keys deliberately

Generate keys using maintained cryptographic facilities with suitable randomness. Do not derive production encryption keys from memorable passwords, identifiers, timestamps, or ordinary application random-number functions.

Maintain a key inventory containing purpose, owner, environment, protected systems, algorithm, key identifier, creation date, status, and recovery dependencies. Record metadata, not secret key material. Distinguish encryption keys, signing keys, TLS private keys, and API credentials because their exposure and replacement procedures differ.

Separate production from development and testing. Sharing a key across environments expands the impact of a lower-trust environment and makes usage logs harder to interpret.

Separate key control from data access

A key management service, or KMS, typically provides governed key operations, access policies, versioning, and usage records. A hardware security module, or HSM, provides a hardware-backed boundary for cryptographic operations and key protection. Services can combine these functions, but product names do not establish the exact security boundary.

Determine whether keys are exportable, which operations occur inside the boundary, who administers policies, and how recovery works. Choose managed key services or hardware protection according to risk and operational requirements rather than treating dedicated hardware as universally necessary. HSMs primarily protect keys and cryptographic operations; they are not general-purpose repositories for all encrypted business data.

Envelope encryption is a common pattern. A data-encryption key encrypts content, and a key-encryption key protects that data key. The encrypted data key can accompany the ciphertext. Its security depends on keeping the ability to unwrap it separately controlled, not on hiding every encrypted key blob in another location.

Limit decryption to the workloads that need it. Where feasible, separate key administration from key use and storage administration. Review whether an administrator who cannot currently decrypt can grant themselves that permission. Emergency access should have explicit approval, limited duration, and a review trail.

Treat rotation as a change process, not a checkbox

Set cryptoperiods according to data sensitivity, exposure, algorithm constraints, usage volume, and applicable requirements. Rotation is also appropriate after suspected compromise or a material change in trust.

Clarify what “rotation” does in the chosen service. Creating a new key version for future encryption may leave historical data dependent on older versions. Rewrapping data keys under a new key-encryption key differs from decrypting and re-encrypting the underlying data. Neither operation should be assumed from an automatic-rotation setting.

A rotation plan should identify affected applications, stored key identifiers, historical versions, staged rollout, failure monitoring, rollback conditions, and eventual retirement. Test mixed-version reads and long-lived jobs before removing old access.

Distinguish revocation from destruction

Revocation removes permission or disables future key use. It does not erase plaintext already retrieved, invalidate every cached data key, or make an exported secret disappear.

Destruction can make retained ciphertext unrecoverable, but only if all usable copies and recovery paths are addressed. Consider replicas, escrow, exported material, backups, and shared-key dependencies. If unrelated records share a key, destroying it may also destroy access to data that must remain available.

Keep retention and deletion design connected. Indefinite key retention can undermine a deletion objective; premature destruction can create an availability incident.

Evaluate cloud key models by their actual control boundary

Cloud encryption can reduce implementation work, but the provider's defaults do not decide your threat model. Assess the service, key policy, administrative access, region, recovery model, and supporting evidence together.

Provider-managed keys may suit some risks with relatively little operational burden. Customer-managed keys can provide more explicit policy control, ownership, and lifecycle decisions. Externally held keys can create a different trust boundary, while also introducing a dependency on external availability and connectivity.

Terms such as bring your own key, bring your own encryption, and encryption as a service are not equivalent architectural guarantees. Importing a key into a provider service does not necessarily mean the provider can never perform decryption. Deploying client-side encryption changes the plaintext boundary but can complicate application features and recovery.

Ask a prospective provider:

• Can we identify the key used for each relevant storage resource and backup?
• Who can change key policies, and how are those changes recorded?
• What happens when a key is disabled or the key service is unavailable?
• How do export, replication, migration, and account closure affect protection?
• Which usage events are available, and what activity is outside their visibility?

Evaluate performance using representative workloads: throughput, latency, key-service quotas, caching behavior, and failure modes. A service that works in a small demonstration may fail during bulk restoration. Data location and customer key ownership are useful design inputs, not proof of sovereignty or regulatory compliance.

Select a solution through an operational trial

Compare candidates against the protection map rather than a list of algorithm names. Include library maintenance, supported platforms, administrative separation, evidence availability, migration options, and the team's ability to operate the service. If a contract requires a validated cryptographic module, establish the relevant module, version, operating environment, and validation scope; an AES label alone does not establish that requirement.

A practical trial should encrypt representative data, exercise normal reads, rotate a key, restore an older copy, and simulate an unavailable key service. Include bulk imports and exports, because their behavior may differ from routine application requests. Measure the effect on the application's own latency and recovery objectives rather than accepting a generic performance claim.

Record an explicit acceptance decision: which threats are addressed, which dependencies are introduced, what remains outside scope, and who owns those residual risks. Also test portability. Exported ciphertext is of little operational value if its format, wrapped keys, or required metadata cannot be interpreted after the service relationship ends.

Design recovery alongside confidentiality

For a backup, establish three things: the data is encrypted, authorized recovery staff can obtain the required key operations, and restoration succeeds.

Do not place the only recovery path inside the same failure boundary as production. An account lockout, regional disruption, or administrative mistake can affect both the backup and its keys. Separate recovery arrangements should remain tightly controlled; making them independent must not make them broadly accessible.

Document key versions needed by each backup generation, required identities, approval steps, provider dependencies, and restrictions on restored data. Restoration into a test environment should not silently expose production information to developers.

Exercise recovery in an isolated environment. Record whether the backup could be located, integrity checks passed, required keys remained usable, application data was readable, and the achieved recovery time met the organization's objective. Any timing figures belong to the actual exercise, not an assumed benefit of encryption.

Include key-service failure in resilience testing. Decide whether a workload should fail closed, retry, or use an approved cached key. Caching may improve availability but extends the period during which a process can decrypt after central access is removed. Document that trade-off explicitly.

Prepare for suspected key compromise

The response depends on what was exposed. A leaked application credential with permission to call a KMS differs from an exported encryption key: removing the credential may stop future service access, while an attacker holding the key and ciphertext may decrypt independently. A compromised signing key creates a different problem involving trust in signatures, not simply confidentiality.

Prepare a runbook that identifies the decision-maker, affected key identifiers, dependent systems, containment options, and evidence to preserve. Investigate policy changes, unusual key operations, data downloads, application access, and the possible exposure window. Missing log events are not proof that no decryption occurred, particularly where keys can be exported or cached.

Containment may involve disabling an identity, narrowing a policy, isolating a workload, or disabling a key. Assess availability consequences before an irreversible action. Do not destroy the only recovery key as an improvised containment step.

After containment, determine which data needs migration to uncompromised keys. Rotating a wrapping key is not sufficient if the attacker obtained the underlying data keys. Re-encrypting retained data can protect future copies, but it cannot retract ciphertext and keys already stolen together. Similarly, replacing a compromised application identity without fixing its authorization flaw leaves the original disclosure path open.

Retain the incident timeline, affected-data assessment, replacement and validation records, and remaining uncertainties. Where personal data is involved, assess notification duties separately; “the database was encrypted” does not answer whether the attacker could obtain plaintext or usable keys.

Build evidence that tests the chain

A policy describes intended behavior. Evidence should demonstrate that the implementation follows it and that important failure paths behave as expected.

Use configuration exports, policy reviews, access tests, key-use logs, deployment checks, and recovery records together. Screenshots can support a review, but they rarely explain scope, historical behavior, or drift on their own.

Interpret logging coverage carefully. With envelope encryption and cached data keys, one key-service operation can enable several later local decryptions. A KMS log is therefore not necessarily a complete record of every plaintext access. Pair it with application authorization and data-access records where appropriate.

Redact secrets from evidence packages. Never upload raw keys, recovery phrases, live credentials, or unnecessary plaintext records. Preserve the resource identifier, timestamp, scope, reviewer, test result, and relevant configuration without creating a new exposure.

Exceptions should state the affected system, reason, compensating controls, owner, expiry, and remediation task. A temporary legacy transport exception needs a decision and an exit plan, not a permanent note in a spreadsheet.

As a practical recommendation, repeat targeted checks after changes to storage, workload identities, key policies, certificates, or backup destinations. Scheduled reviews remain useful, but a deployment can alter the protection boundary before the next calendar review. Automated checks should raise actionable findings with resource context and an owner, while human reviewers assess exceptions and changes in the threat model.

Worked example: trace a customer-document service

Assume an illustrative SaaS service stores confidential customer documents in object storage. Its application retrieves documents for authenticated users, and daily backups support a business-defined recovery objective. The threats under review are stolen storage copies, unauthorized administrative access, and cross-tenant disclosure.

The team maps browser-to-edge TLS, edge-to-application TLS, application-to-storage connections, the production bucket, and a separate backup destination. It discovers that a troubleshooting export job writes decrypted files to a support folder. That folder becomes an immediate scope item; the production bucket's encryption setting does not cover it.

For the initial design, storage encryption with a customer-managed key protects production objects. The application identity can retrieve authorized objects and invoke the necessary key operations. The deployment role can create resources but has no routine decryption permission. Key-policy administration follows a separate approval path.

The team recognizes the remaining boundary: an application compromise could still retrieve plaintext. It considers application-layer encryption for a particularly sensitive document category, then evaluates search requirements, support access, and recovery complexity before deciding whether the additional boundary is justified.

Verification produces specific results:

• An unauthorized service identity cannot retrieve or decrypt a document.
• An authenticated user from another tenant is denied by the application.
• Invalid upstream certificates are rejected rather than bypassed.
• An older backup restores successfully with its required historical key version.
• A staged key change allows both existing documents and new uploads to be read.
• The support export job is changed to use an approved, access-controlled encrypted destination with defined retention.

The reviewer retains the data-flow map, configuration exports, identity policies, sanitized negative-test results, rotation record, and restore report. A key-disablement exercise in a non-production environment confirms that the service returns a controlled error rather than exposing data or silently discarding writes.

This example does not establish protection against every attack. It establishes which threats the design addresses, which identity remains trusted, and what evidence supports those conclusions.

Connect legal requirements and future changes to the design

Encryption decisions should reflect legal, contractual, and framework requirements without turning them into blanket claims. GDPR Article 32 uses a risk-based approach and includes encryption among appropriate measures; it does not impose a universal encryption mandate for every processing activity. Encryption also does not remove duties concerning lawful processing, access, retention, or incident assessment.

Within a scoped ISO 27001 ISMS, document the risk treatment, applicable controls, ownership, and evidence rather than assuming one encrypted database satisfies the wider management system. Where NIS2 applies through national law, its Article 21 measures include policies and procedures concerning cryptography and, where appropriate, encryption. Confirm applicability and national requirements separately.

Plan for cryptographic change as an engineering dependency. Inventory algorithms, certificates, libraries, protocols, and embedded formats so outdated mechanisms can be replaced. For long-lived confidential data, assess the relevance of future cryptanalytic and quantum threats. Post-quantum migration concerns differ across key establishment, signatures, and symmetric encryption; avoid an untested wholesale replacement presented as a universal fix.

Make the next review concrete

Secani can connect the target systems, control requirements, implementation descriptions, evidence, owners, and review decisions for this work. Attach the protection map and sanitized test records to the relevant systems and controls, turn unresolved key-access or recovery questions into tasks, and retain why each cryptographic choice was approved. Review AI-assisted suggestions against their sources and keep human approval explicit.

Start with one sensitive data store and trace data access, key access, and recovery together. Select one negative authorization test and one restoration exercise, assign owners, and record the results before expanding scope. Our cloud-security guide provides the surrounding configuration context.