Note: This article was first published in 2020 and updated in June 2025 to reflect Oracle's current cloud security architecture, terminology, and controls.
Security is a paramount concern for any organization's finance and accounting systems, and it is often the single biggest reason teams hesitate to move off on-premises Oracle software. The worry is understandable, but it is worth examining closely, because for most organizations a well-run cloud environment is more secure than the on-premises system it replaces, not less. Oracle Cloud is engineered with security as a foundational design principle rather than an add-on, and it is backed by independent, third-party audits. This article walks through how that security actually works, from the physical data center up to the account controls you manage yourself, so you can evaluate the move on facts rather than instinct.
Physical and Infrastructure Security
Oracle operates its own global network of data centers and is responsible for their physical security. The infrastructure is organized in three tiers. A region is a localized geographic area; each region contains one or more availability domains, which are isolated data centers that do not share power, cooling, or internal network; and each availability domain is divided into three fault domains, groupings of hardware that let workloads be distributed so that a single hardware failure or maintenance event does not take everything down at once. Traffic between availability domains and between regions is encrypted.
This layered design is what delivers high availability. Rather than depending on a single building staying online, the architecture assumes components will occasionally fail and is built to keep running when they do, which is difficult and expensive to replicate in a typical on-premises data center. Oracle substantiates this posture with independent certifications and attestations, including ISO 27001, SOC 1, SOC 2, and SOC 3, and HIPAA, among others. Because the exact certifications vary by service and region, the current scope is published on Oracle's compliance portal and is worth confirming for your specific applications.
Data Encryption
Oracle encrypts your data both in transit and at rest.
For data in transit, Oracle Fusion Cloud EPM and Enterprise Data Management use Transport Layer Security (TLS) 1.2 and 1.3 with strong cipher suites, spanning 128-bit and 256-bit AES encryption. Session information stored in cookies is encrypted and tied to randomly generated session IDs to guard against session hijacking, and TLS certificates are renewed on a periodic schedule. This applies across the ways you connect, including web browsers, Oracle Smart View for Office, EPM Automate, and the integration agent.
For data at rest, Oracle uses Transparent Data Encryption together with OCI Block Volume encryption, and the encryption keys themselves are protected in FIPS 140-2 compliant hardware security modules. For organizations that want to hold the keys to their own data, Oracle offers a Bring Your Own Key option, so that encryption keys can be customer-managed rather than solely Oracle-managed.
Access Control and Data Isolation
Every customer's environment is logically isolated so that one organization cannot see another's data. On top of that isolation, Oracle Cloud gives you a substantial set of controls to govern who can reach your environment and what they can do once inside.
Access for your users is governed by role-based access control, so people receive only the privileges their responsibilities require. You can externalize authentication through single sign-on with your own identity provider, which is also how multi-factor authentication is typically enforced, and you can layer on sign-on policies, maximum session durations, idle-session timeouts, and multiple password policies. To limit the network paths into your environment, you can configure an IP allowlist so that connections are accepted only from the address ranges you approve, routing all access through your organization's own security perimeter.
One point deserves correction from how cloud security is sometimes described. It is not accurate to say that Oracle employees simply cannot access customer data; rather, Oracle operates on a least-privilege model and gives you concrete controls to restrict and monitor Oracle's own manual access to your EPM and Enterprise Data Management databases. Combined with the Bring Your Own Key option, this means you can both limit operator access and hold the keys that protect the underlying data, with an audit trail of any such access.
Backup and Resilience
Oracle Cloud EPM environments are backed up automatically. A daily maintenance snapshot, the Artifact Snapshot, captures your artifacts and data and is retained in Oracle Object Storage for 60 days, and you can create environment backups on demand or on a schedule using EPM Automate and the built-in lifecycle management procedures. By default, that storage lives in the same OCI region as your environment. Oracle also offers a self-service option to configure a second Object Storage bucket in a different region and replicate your backups to it, so a copy of your data can survive a serious incident in the primary region. Setting that replication up is on your side of the shared responsibility line, not something Oracle does for you automatically, but it is a straightforward option worth configuring for anything business-critical. Even without it, the automatic daily snapshot and retention window are a materially stronger starting position than most organizations achieve with self-managed on-premises backups.
Monitoring, Patching, and Compliance
Oracle continuously monitors its environments and maintains the software on your behalf. Security patches and updates are applied on a controlled, regular schedule, so environments stay current with the latest fixes without you having to plan and execute each upgrade. Detailed access logs, login reports, activity reports, audit reports, and role-assignment records track activity across the systems, and these can be fed into your own SIEM tooling for centralized security monitoring. Oracle also runs periodic penetration testing and ethical hacking, undergoes external security audits, follows the Oracle Software Security Assurance program in how its software is built, and supports customer-initiated security testing within defined rules.
The Shared Responsibility Model
Security in the cloud is a shared responsibility, and understanding the split is essential to running a secure environment. Oracle is responsible for security of the cloud: the physical security of its data centers, the isolation of compute, network, and storage, the identity and access management framework, and the hardware, software, and facilities that run its services. Your organization is responsible for security in the cloud: your data and how it is classified, your user credentials and account information, how you manage access and enforce strong authentication, your network and firewall configuration, and the security of the browsers, devices, operating systems, and connections your people use to reach the environment.
In other words, Oracle secures the platform, and you secure how your organization uses it. Neither party can deliver a secure system alone, and the most common cloud security failures happen on the customer side of that line, in weak credentials or over-broad access, not in the platform itself. This is precisely where an experienced implementation partner earns its keep.
Moving Forward
The security concerns that keep organizations on aging on-premises systems are, in most cases, better addressed by a well-architected cloud environment than by the status quo, provided the customer side of the shared responsibility model is set up correctly. That setup, tenant configuration, access design, allowlisting, authentication, backup strategy, and monitoring, is exactly what determines whether a cloud migration is more secure or merely different.
CloudADDIE can guide you through moving from on-premises to the cloud and, just as importantly, help you configure the controls that keep it secure once you are there. Many organizations, including Fortune 500 companies, have already made this move; if you would like to evaluate it for yours, we are glad to help.
The security features described here reflect Oracle's documentation as of this update and vary by service, edition, and region. Confirm the specifics that apply to your applications with Oracle's current documentation and compliance portal.