OCI Compliance Certifications: SOC, ISO, and Industry Maps

Every vendor risk review of Oracle Cloud Infrastructure starts the same way: someone asks for the certifications, someone else forwards a marketing page, and the actual question, can we evidence that this platform meets our obligations, goes unanswered for three more weeks. The fix is not more documents. It is understanding what each attestation family attests, who it is written for, and how it maps onto the obligations your own auditors and regulators will test you against. That mapping exercise sits at the center of everything we cover in our complete guide to OCI compliance and sovereignty, and this article is the part of that guide that procurement and compliance teams use most often.

What provider certifications do, and what they do not

A provider certification is an independent statement that the cloud platform, as Oracle designs and operates it, met a defined set of control criteria during a defined period or at a defined point in time. That statement is genuinely valuable. It lets you inherit assurance over physical security, infrastructure operations, personnel controls, and platform level processes that you could never audit yourself, and it gives your own auditors a recognized artifact to rely on instead of a site visit that no hyperscaler would grant.

What it does not do is say anything about your tenancy. The shared responsibility model draws a hard line: Oracle attests the cloud, you remain responsible for what you build in the cloud. A SOC 2 report covering OCI says nothing about whether your IAM policies follow least privilege, whether your Object Storage buckets are private, whether your audit logs are retained long enough, or whether your network security groups actually segment anything. Auditors increasingly understand this distinction, and the most common finding we see in compliance driven OCI reviews is not a gap in Oracle's paperwork. It is a tenancy whose configuration contradicts the story the provider attestation tells. Closing that gap is tenancy engineering, the kind of work our OCI security practice does when it builds and hardens landing zones, and no certificate from any provider substitutes for it.

So read every attestation with two questions in mind. First, which of my controls can I inherit from this document. Second, which controls does this document explicitly leave to me. The answers become your control responsibility matrix, and that matrix is worth more to an audit than the certificates themselves.

The main attestation families

Oracle publishes attestations across several families, each built for a different audience and a different question. Treat them as distinct instruments, because handing the wrong one to the wrong reviewer wastes a review cycle.

SOC 1, SOC 2, and SOC 3

The SOC family comes from the AICPA and is the workhorse of vendor risk in North America and increasingly everywhere else. SOC 1 addresses controls relevant to financial reporting. Your external financial auditors want it when OCI hosts systems that feed your financial statements, and almost nobody else does. SOC 2 addresses the Trust Services Criteria, security and, depending on scope, availability, confidentiality, processing integrity, and privacy. A Type 2 report covers operating effectiveness over a period, usually twelve months, and is the document most vendor risk teams actually need. SOC 3 is the public summary of a SOC 2: same criteria, no detailed control descriptions, free distribution. It is useful for early stage screening but will not satisfy a serious review.

Distribution matters here. SOC 1 and SOC 2 reports are restricted use documents, released under nondisclosure through your Oracle account channel, while SOC 3 is public. And because SOC reporting periods end on a fixed date, there is always a gap between the end of the audited period and today. The standard answer is a bridge letter, a short statement from the provider that no material control changes occurred between the report date and the letter date. Vendor risk teams should ask for the bridge letter as a matter of routine whenever the report period ended more than a quarter ago.

The ISO family and CSA STAR

Where SOC reports describe controls in detail, ISO certifications certify that a management system conforms to a standard. ISO 27001 is the anchor: it certifies the information security management system behind the platform. Around it sit extensions that answer more specific questions. ISO 27017 adds cloud specific controls for providers and customers. ISO 27018 addresses the protection of personal data in public clouds, which is the certificate your privacy office will ask about first. ISO 27701 extends the management system into privacy information management, useful when you must evidence GDPR aligned processing by your providers. The certificates themselves are short documents naming the certification body, the scope, and the expiry date, and unlike SOC reports they are generally public. CSA STAR sits alongside the ISO family: it maps the provider's posture against the Cloud Security Alliance's Cloud Controls Matrix, and its registry entries are a fast, free first pass for screening before you request the restricted material.

Industry attestations: PCI DSS and HIPAA

Some obligations are contractual rather than statutory, and the card schemes are the classic case. Oracle maintains a PCI DSS attestation of compliance covering a defined list of OCI services, which lets you build a cardholder data environment on attested infrastructure. The attestation covers the provider's responsibilities only; your own PCI obligations, segmentation, key management, logging, and quarterly scanning among them, remain yours, and the service list in scope is exactly the thing to verify before you commit an architecture. We walk through that division of labor in detail in our guide to PCI DSS on OCI.

Healthcare works differently because HIPAA has no certification at all. There is no such thing as a HIPAA certified cloud. What Oracle offers is a business associate agreement, a BAA, covering eligible OCI services, which is the legal instrument that allows protected health information to be processed on the platform. The compliance work then happens in your tenancy: encryption, access control, audit trails, and breach response. Our companion article on running HIPAA workloads on OCI covers the BAA boundary and the tenancy controls that have to sit inside it.

Government programs: FedRAMP and DISA impact levels

For United States public sector work, the relevant programs attach to Oracle's government realms rather than to commercial regions. FedRAMP High authorization covers the US Government Cloud regions, and DISA impact level authorizations cover Department of Defense workloads in the defense regions. The practical consequence for a compliance map is that these authorizations do not transfer to commercial tenancies: if your obligation requires FedRAMP authorized infrastructure, you need a tenancy in the corresponding realm, which is a procurement and architecture decision, not a paperwork request.

Regional and national programs

Outside the United States, national assurance programs carry the weight that FedRAMP carries domestically, and Oracle participates in many of them. A representative selection: C5 in Germany, the BSI's cloud criteria catalog that German regulated entities and public bodies expect; HDS in France, required for hosting health data; IRAP assessment in Australia for government workloads; K FSI oriented assurance in Korea for financial sector cloud use; ENS in Spain for public administration; Cyber Essentials Plus in the United Kingdom; and ISMAP registration in Japan for government procurement. This is deliberately not an exhaustive list, and scope within each program changes as regions and services are added. Treat the program names here as a checklist of what to look for, and verify the current status, scope, and regions on Oracle's compliance page before you cite any of them in a regulatory filing.

How to actually obtain the documents

There are three channels, and knowing which one holds which document saves weeks. First, Oracle maintains a public compliance documents portal listing programs, attestations, and the services and regions in scope for each. Public certificates, ISO among them, and the SOC 3 report are available there directly. Second, restricted documents, the SOC 1 and SOC 2 reports in particular, are released under nondisclosure through your Oracle account team or through the document request workflow tied to your tenancy. Build the lead time into your audit calendar, because the request, the NDA step, and internal routing can take longer than the review itself. Third, program specific packages, such as FedRAMP materials, flow through the program's own channels rather than through standard sales contacts.

A practical tip from the procurement side: ask for the scope statement and the service list at the same time as the report. The report alone tells you the controls passed. The scope statement tells you whether the services and regions you are actually buying were in the audit at all, and that is the question your reviewer will ask next.

Mapping attestations to your own obligations

Collecting documents is the easy half. The half that satisfies an auditor is the mapping: which of your obligations each attestation discharges, and what remains for you to evidence.

For vendor risk reviews, the SOC 2 Type 2 report is usually the spine. Map its Trust Services Criteria coverage against your third party risk questionnaire, note the complementary user entity controls the report lists, those are the controls the auditor assumed you operate, and confirm you actually operate them. Reviewers who skip the user entity controls section are signing up for inherited assurance they have not earned.

For ISO aligned organizations, the provider's ISO 27001 certificate slots into your own ISMS as supplier assurance under your supplier security controls. The 27017 and 27018 extensions give you cloud and privacy specific control language to reference in your statement of applicability, which is considerably stronger than a generic note that the supplier is certified.

The general principle is inherit where you can, implement where you must. Physical security, hypervisor integrity, and platform operations are inherited. Identity configuration, data classification, encryption key custody, logging, and incident response inside the tenancy are implemented. Write the split down explicitly per framework, because every serious audit will ask for exactly that document, and teams with 20+ years of combined Oracle experience still get challenged on it when the split lives only in someone's head.

Scope caveats that catch teams out

Two caveats account for most of the unpleasant surprises. The first is service and region scope. Every attestation covers a defined list of services in defined regions, and the lists differ between programs. A service can be in scope for SOC 2 but not yet for PCI DSS; a new region can be live for workloads months before it appears in an attestation cycle. Never assume that because the platform holds a certification, the specific service in your architecture is covered by it.

The second is attestation lag. Audits are periodic, so newly launched services and regions enter scope at the next cycle, not at launch. If your architecture depends on a service released this quarter, check whether your obligation allows you to run on it before the attestation catches up, or design around it until it does. Both caveats argue for the same habit: verify current scope on Oracle's compliance page at design time and again before go live, rather than relying on a list that was accurate when the project started.

Building a certification map for your industry

The portfolio only becomes useful when you cut it down to the attestations your industry actually tests. Three examples show the shape of the exercise.

Financial services. The spine is SOC 1 and SOC 2 for audit and vendor risk, PCI DSS where card data is in play, ISO 27001 for the ISMS, and the regional financial programs where you operate, K FSI in Korea or C5 for German supervised entities among them. European firms also face operational resilience obligations that go beyond certificates into exit planning and concentration risk, which is the territory of our article on DORA compliance on OCI.

Healthcare. The map is shorter but stricter: the BAA as the legal foundation, SOC 2 and ISO 27018 for assurance over the platform's handling of sensitive data, HDS if you host French health data, and a tenancy configuration that can survive an OCR investigation, because no provider document will defend an unencrypted bucket.

Public sector. Realm choice dominates. FedRAMP High and DISA impact levels in the United States, IRAP in Australia, ENS in Spain, ISMAP in Japan, and the question of whether your mandate requires a government realm or a sovereign realm rather than a commercial region with the right paperwork. Decide the realm first; the certificates follow from it.

Keeping the evidence current

An evidence pack is perishable. SOC reports operate on annual cycles, ISO certificates carry expiry dates and surveillance audits, and scope lists change every time Oracle adds services and regions to a program. The teams that stay ahead of this treat provider evidence the way they treat their own controls: owned, scheduled, and monitored. Calendar the report cycles, request bridge letters when reports age past a quarter, and recheck scope whenever the architecture changes. The same discipline applies inside the tenancy, where your own audit trail is the evidence your assessors will spend most of their time in; our guide to audit logging on OCI covers retention, export, and the configurations that make tenancy evidence stand up. Across 500+ OCI engagements, the estates that pass audits calmly are the ones where provider evidence and tenancy evidence are refreshed on the same schedule, often under the same 24/7/365 monitoring umbrella that watches the workloads themselves.

A seven step OCI evidence pack

If you are starting from zero, or from a shared drive full of stale PDFs, this sequence produces a defensible evidence pack and keeps it alive.

None of this is glamorous work, but it is decisive work. The organizations that struggle with cloud compliance are rarely missing a certificate; they are missing the map between the certificates and their own obligations, and the routine that keeps the map current. Build both once, properly, and every subsequent audit becomes a document handover instead of a fire drill.