Who controls the encryption keys for your offsite backups?

Control of an offsite backup encryption key means control over the authority needed to turn encrypted backup data back into readable information. The key holder may be the backup provider, your organisation, or a separately governed key-management service. This decision affects confidentiality, operational independence, auditability and whether data can be recovered if an account, supplier relationship or administrator becomes unavailable.

Encryption is only as strong as the controls around the key. A backup can be encrypted during transfer and while stored, but authorised access to the relevant key is still required for a restore. Organisations should therefore establish exactly who can request decryption, who can approve it, where the key is held, and how those actions are recorded.

There are several common arrangements:

• Provider-managed keys: the backup platform creates and protects the encryption keys as part of the service. This usually reduces the administration required from the customer, but means the organisation must understand the provider’s access controls, support procedures and arrangements for exporting or restoring data.
• Customer-managed keys: the organisation creates or administers the keys and defines which systems or administrators may use them. This gives the customer more direct control over access and key lifecycle decisions, but introduces responsibility for protecting the key and maintaining a workable recovery process.
• External key-management: the backup system uses a separate key-management platform or security module. This can provide stronger separation between backup administration and decryption authority, although it adds another dependency that must be documented, monitored and included in continuity testing.

Key ownership should not be confused with access to the backup console. A person may be able to start, delete or monitor backup jobs without being able to decrypt their contents. Conversely, an administrator with access to the key-management system may be able to authorise decryption without managing the backup schedules. Separating these roles reduces the risk that one compromised account can control the entire backup system.

A sound design normally addresses the following controls:

• Least-privilege access: grant key access only to the accounts, services and administrators that require it for defined tasks.
• Multi-person approval: require more than one authorised person for sensitive actions such as exporting a key, changing its permissions or approving a large-scale restore.
• Strong authentication: protect administrative and key-management accounts with appropriate authentication controls, rather than relying solely on a password.
• Audit records: log key creation, use, permission changes, rotation, export and deletion, and review those records as part of security governance.
• Separation of duties: avoid giving the same individual unrestricted control over backup configuration, key administration and deletion.

Key rotation can limit the useful life of a compromised key, but it must be implemented carefully. Existing backup sets may remain associated with earlier keys, so rotating a key does not automatically re-encrypt every historical recovery point. The organisation should know how older keys are retained, how long they remain usable, and whether a restore from each generation is possible after a rotation.

Key loss is a different risk from key theft. If a customer-controlled key is destroyed, corrupted or made inaccessible, encrypted backups may become unusable even though the backup files themselves are intact. Key material should therefore have a protected recovery copy, with access restricted separately from the primary system. Recovery arrangements should cover staff departures, loss of administrative credentials, damage to the primary office and failure of the key-management service.

Retention and deletion policies also need to cover keys. Deleting a key can make retained backup data permanently unreadable, while retaining keys indefinitely may conflict with data-minimisation or destruction requirements. Before removing a key, confirm which backup versions depend on it, whether retention obligations still apply, and whether an approved destruction record is required.

When assessing a provider or backup design, ask:

• Who generates the keys, and who can access the key material or authorise its use?
• Can provider personnel decrypt customer data, and under what documented circumstances?
• Can the customer use its own key-management system?
• Are keys logically or physically separated between customers?
• How are key access events recorded and made available for review?
• What happens to encrypted backups if the service account is suspended or the contract ends?
• Can data and the associated key material be recovered independently during a major incident?
• How are key rotation, revocation, archival and destruction handled?

The choice should reflect the organisation’s risk profile, regulatory duties, internal capability and recovery requirements. Greater control can improve oversight and reduce dependence on a provider, but it also creates operational obligations that cannot be ignored. The most reliable arrangement is one in which key ownership, delegated access, recovery authority and exit procedures are documented, tested and reviewed alongside the offsite backup plan.