Who controls the encryption keys for your cloud backup data?

Encryption key control determines who can authorise access to the encrypted copies of your business data and who can recover them if the backup service, account or infrastructure is unavailable. The answer is found in the provider’s key-management architecture and contract, not simply in the statement that backups are encrypted.

Most cloud backup platforms use a hierarchy of keys. A root or master key protects other encryption keys, which in turn protect individual backup sets, files or storage objects. This design allows the service to rotate or replace lower-level keys without re-encrypting every item of data. Ask the provider which level your organisation controls, where the master key is held, and whether the provider can decrypt data without your approval.

There are three broad arrangements:

• Provider-managed keys: the backup provider creates, stores, rotates and uses the keys. This is operationally simpler, but your organisation depends on the provider’s access controls, administrative processes and recovery procedures.
• Customer-managed keys: your organisation controls the relevant key-management account or service, while the backup platform is granted carefully defined permissions to use the key. This provides greater oversight of authorisation, revocation and audit records.
• Bring-your-own-key arrangements: you supply a key generated or managed within your chosen key-management environment. The exact level of control varies, so confirm whether the provider ever receives a copy, whether it can export the key, and whether it can use it without an explicit authorisation.

These labels are not consistent across suppliers. A service described as customer-managed may still retain administrative access to the key-management system, or may use a provider-controlled secondary key. A meaningful assessment therefore needs to examine the technical permissions rather than rely on the product name.

Key ownership is also different from data ownership. Your organisation can own the data while the provider controls the encryption keys. Conversely, retaining a key does not automatically prevent every form of provider access: account administrators may still be able to view metadata, manage backup policies or initiate restore operations. Review encryption, identity and privileged-administration controls together.

For a customer-controlled model, check the following points before relying on it for business continuity:

• Which people, roles or services can create, use, disable, rotate or destroy the key?
• Can the backup provider use the key for scheduled backups and restores without a separate approval?
• Are key-use events, administrative changes and failed authorisation attempts recorded in an audit log?
• Can access be restricted by role, network, location or approval workflow?
• Does key rotation preserve access to older recovery points, or must historical data be re-encrypted?
• What happens if the key is disabled, deleted, expires or becomes inaccessible?
• Can data be restored if the relationship with the backup provider ends?

The last question is particularly important. A key that is unavailable can make an otherwise intact backup unusable. Key protection should therefore include independent administrative accounts, documented recovery procedures and a securely controlled recovery copy where the design permits one. Those arrangements should be tested, because a key-recovery process that exists only on paper may fail when the original administrators, credentials or systems are unavailable.

Key rotation improves security by limiting the useful life of a cryptographic key, but it is not a substitute for access control. Rotation schedules should be compatible with retention periods, immutable recovery points and legal or contractual requirements. Before changing or revoking a key, establish which backups, replicas and exported copies depend on it.

Consider also the separation between backup encryption and encryption used for data in transit or within the provider’s storage system. A provider may use one control for communications, another for stored data and a separate customer key for selected backup repositories. Confirm what each key protects and whether snapshots, replicated copies, temporary restore areas and support exports follow the same policy.

For compliance reviews, retain evidence showing the selected key model, permissions, rotation policy, audit records, supplier responsibilities and recovery tests. Policies should state who may approve key access and how access is removed when an administrator changes role. This creates an auditable chain from the backup policy to the people and systems capable of decrypting data.

A practical decision depends on the organisation’s risk profile and operational capability. Provider-managed keys may be appropriate where simplicity and dependable administration are the priority. Customer-controlled keys may be preferable where contractual, regulatory or internal security requirements demand stronger control over decryption. In either case, the arrangement is only effective when key access is restricted, monitored, recoverable and included in regular restore testing.