Data Encryption on OCI

Encryption on OCI is mostly on already. Block storage, object storage, file storage, and databases are encrypted at rest by default, and traffic to the platform travels over encrypted connections. That is good news, because it means the common worry, is my data encrypted, usually has the answer yes without you doing anything. The work that actually matters is not switching encryption on. It is controlling the keys, knowing the scope of what is and is not covered, and being able to prove the protection to an auditor.

It helps to separate two ideas that often get blurred. Encryption at rest protects data stored on disk, so a stolen disk or an improperly accessed storage layer yields nothing readable. Encryption in transit protects data moving across the network, so a connection that is intercepted yields nothing readable either. OCI gives you both, and a complete posture needs both, because data is vulnerable both when it sits and when it moves.

What is encrypted by default

The major storage services encrypt data at rest without you taking any action, and databases including Autonomous Database apply encryption as a matter of course. This default coverage is why the basic question of whether data is encrypted is usually settled. What is not automatic is the parts of encryption that require a decision, chiefly who controls the keys and whether traffic between your own components is encrypted as well as traffic to the platform.

So the right mental model is that the platform handles the floor, the baseline that everything sits on, and your job is to make deliberate choices above that floor where the value of the data warrants it. Those choices connect directly to the key management work described in our Vault and key management guide, because the strength of encryption at rest comes down to who can use the key.

Customer managed keys and scope

Default encryption typically uses keys the platform manages, which is fine for many workloads. For sensitive or regulated data, the decision to use customer managed keys gives you control over the key lifecycle and the ability to disable a key, which is often a compliance requirement and always a meaningful increase in control. The trade is that you take on the responsibility of operating those keys carefully, which is exactly the discipline covered in our key management guide.

Scope is the other thing to get right. Default encryption covers the platform storage and database layers, but traffic between your own application components inside the network is yours to secure. Sensitive data moving between two of your services should be encrypted in transit even though it never leaves the platform, because the network is not a trusted space simply for being private. This is part of the zero trust thinking that runs through modern security design.

Proving it

For most regulated workloads, having encryption is only half the requirement. The other half is being able to demonstrate it, to show an auditor which data is encrypted, with which keys, under whose control, and with what rotation history. That is where customer managed keys and the audit trail combine into something useful, because the key lifecycle and its use are recorded, giving you evidence rather than assertion. The logging side of this is covered in our audit and logging guide, and together they turn a claim into proof.

Common gaps

The most common gap is assuming default encryption covers everything and never thinking about keys, which leaves sensitive data protected by keys the team does not control and cannot revoke. The second is encrypting at rest while leaving internal traffic in plain text, on the assumption that the private network is safe, which it is not against an attacker who has already gained a foothold. The third is having encryption but no evidence, so when an auditor asks, the team scrambles to reconstruct what should have been recorded all along. All three are avoidable with the deliberate choices above, and all three are the kinds of issue our IAM and security practice surfaces in a review.

Encryption is not a substitute for access control

A subtle trap is to treat encryption as if it were the whole of data protection, when in fact it only addresses one specific threat. Encryption at rest protects you against someone obtaining the raw storage, and encryption in transit protects you against someone intercepting the connection. Neither does anything to stop a properly authenticated request from an over permissive identity reading the data through the front door, because that request is decrypted for the caller exactly as intended. In other words, encryption guards the data against being read by the wrong path, but access control guards it against being read by the wrong person, and you need both. A database that is beautifully encrypted but readable by an account with far more access than it should have is not well protected, it is just protected against the wrong threat.

This is why encryption sits alongside, not instead of, the identity discipline in our IAM policies guide. The two address different attack paths and a complete posture closes both. When you review a workload, it is worth asking the two questions separately: is the data encrypted with keys we control, and is access to it restricted to exactly the identities that need it. A yes to one and a no to the other is a common and dangerous combination, and seeing them as distinct questions is what stops a strong answer on one from masking a weak answer on the other.

Bringing it together

OCI gives you encryption at rest by default and encrypted connections to the platform, so the baseline is strong without effort. The work that matters is above that baseline: choosing customer managed keys for sensitive data, encrypting your own internal traffic rather than trusting the private network, operating keys with discipline, pairing encryption with tight access control, and keeping the evidence to prove protection when asked. Encryption only protects you when the keys are controlled and the scope is complete. The key management detail is in our Vault guide, the wider model is in our complete security guide, and our IAM and security practice builds and verifies this for clients.