Should Your Cloud Provider Control Your Encryption Keys?
Should your cloud provider control your encryption keys?
Your cloud provider can control encryption keys for lower-risk workloads, but sensitive or regulated data may justify customer-managed or externally held keys. Decide by data class, separation of duties, recovery capability, outage tolerance, and exit requirements. Do not approve the model until your team has tested access, disablement, recovery, logging, and provider failure.
Key takeaways
- Encryption-key control should vary by data class rather than follow one company-wide default.
- Customer control adds authority over key use but also adds operational duties that can make data unavailable.
- External keys create stronger separation only when the external service and recovery path are tested.
- Philippine privacy obligations require documented security measures, not a named cloud key-custody model.
The loss figures show why key control deserves a board-level decision, but they do not select a model. IBM's 2026 Cost of a Data Breach Report puts the global average breach cost at US$4.99 million, 12% above the prior year. Verizon's 2026 DBIR executive summary says ransomware appeared in 48% of breaches, up from 44% the year before. These are global datasets, not Philippine benchmarks, and key custody will not prevent every breach or ransomware event.
The decision is who can authorize use, who can disable a key, who sees each operation, and who can restore access after failure. NIST Special Publication 800-57 Part 1 Revision 5, published in 2020, states: “Secret and private keys need to be protected against unauthorized disclosure, and all keys need to be protected against modification.” Start by mapping protected data through Infocentric's data discovery and classification capability, then match the custody model to the harm caused by disclosure or loss of access.
Which encryption-key control models should you compare?
Compare provider-owned defaults, customer-managed keys inside the cloud provider, and keys held in an external manager. The names vary among providers, so compare authority and failure behavior rather than accepting a product label as proof of control.
This original decision table translates vendor documentation into buyer evidence. It is an Infocentric editorial aid, not a universal cloud specification.
| Control model | Authority to verify | Failure test before approval |
|---|---|---|
| Provider-owned default | The provider operates the key lifecycle and service integration. | Prove what your team can audit, restrict, export, or change. |
| Customer-managed in cloud KMS | Your organization sets key location, access, rotation, use, status, and destruction within the provider's service. | Disable a test key, restore it, rotate it, and confirm which workloads lose access. |
| Externally held key | An external manager decides whether the cloud service may use the key. | Interrupt the external path, recover it, and prove that no single person can strand the data. |
The distinctions are concrete in current vendor documentation. Google Cloud's customer-managed encryption key guide says customers can control location, protection level, creation, access, rotation, use, and destruction, while integrated services perform encryption and decryption through a service agent. AWS documents customer-managed, AWS-managed, and AWS-owned keys with different policy, audit, rotation, deletion, and pricing behavior. These examples explain two providers; they do not establish identical controls elsewhere.
External custody has a sharper tradeoff. Google Cloud's external key manager guide says Google does not control the availability of an externally managed key and cannot recover cloud data if the customer loses that key. Stronger separation therefore comes with a real availability dependency. Treat Infocentric's encryption capability as the service context, then require each bidder to demonstrate its exact boundary.
What evidence should you require before approving key custody?
Require a data-to-key map, named authorities, lifecycle records, tested failure recovery, and an exit path before approving encryption-key custody. A policy statement is insufficient if nobody can show which data uses which key, who can change it, or how the business regains access after a key or service failure.
Use this six-part approval sequence:
- Classify the data. List the applications, records, backups, analytics copies, and regions in scope; connect that inventory to your data loss prevention program.
- Assign separate roles. Name who administers keys, approves policy changes, uses protected data, reviews logs, and authorizes emergency recovery; no one person should hold every path.
- Record the lifecycle. Capture generation or import, activation, rotation, suspension, recovery, archival, destruction, and the evidence retained for each event.
- Run failure exercises. Disable a nonproduction key, interrupt the key service, restore access, test backup material, and measure the effect on applications, logs, and recovery objectives.
- Prove monitoring and response. Send denied access, policy change, key disablement, and destruction events to accountable reviewers, then rehearse the response boundary with an Infocentric managed-services team if operations are shared.
- Test the exit. Document whether keys and encrypted data can move, which workloads require re-encryption, what evidence the provider returns, and how retired copies become unreadable.
The Philippine legal anchor sets the obligation without prescribing custody. Section 20 of the Data Privacy Act of 2012 requires reasonable and appropriate organizational, physical, and technical measures for personal information, a security policy, and safeguards against unauthorized processing. The Act does not say that a cloud provider, customer, or external manager must hold the keys. Your assessment must account for the information's nature, processing risks, organizational size and complexity, current data privacy practices, and implementation cost.
What do Philippine security leaders ask about cloud keys?
Philippine security leaders ask whether customer control is always safer, whether external keys remove provider trust, how rotation affects data, what evidence privacy reviewers need, and when provider defaults remain reasonable. Each answer depends on data sensitivity and the operating capability that can be proved before signing.
Are customer-managed encryption keys always safer?
No. Customer-managed keys give your organization more policy and lifecycle control, but a bad permission, disablement, destruction event, or failed recovery can also block legitimate access. The safer model is the one that meets the data's confidentiality and availability needs and passes a witnessed failure exercise.
Does holding an external key remove cloud-provider risk?
No. External custody separates key authority from the cloud service, but the application still depends on the provider's infrastructure and on a reachable external key manager. It also adds another service, network path, support boundary, and recovery plan that your team must operate and test.
Does key rotation re-encrypt all existing cloud data?
Do not assume it does. Rotation, key-version selection, and re-encryption behavior differ by service and provider. Require the bidder to demonstrate which version encrypts new data, which versions decrypt existing data, how old ciphertext is migrated, and what happens when a version is disabled or destroyed.
What evidence supports a Philippine privacy review?
Retain the data classification, lawful processing context, selected key model, role assignments, access policy, lifecycle events, audit logs, exceptions, failure-test results, recovery evidence, and exit procedure. Section 20 of the Data Privacy Act makes the personal information controller responsible for reasonable and appropriate safeguards, even when processing uses a cloud provider.
When can provider-owned encryption keys be reasonable?
Provider-owned keys can be reasonable for data whose sensitivity, contractual terms, recovery needs, and threat assessment do not justify added customer custody. Record that decision by workload, verify the provider's encryption and access evidence, and set a review trigger for changes in data, regulation, architecture, or business impact.