PCI DSS is unusual among the frameworks we cover in our complete guide to OCI compliance and sovereignty because its cost is almost perfectly proportional to its scope. Every system in scope must satisfy more than 250 testable requirements; every system out of scope satisfies none of them. A payment platform with a tightly segmented cardholder data environment of thirty instances and a platform with the same business volume but an unsegmented flat network of three hundred instances face the same standard and wildly different audit bills. On OCI, the tools to draw that boundary precisely, compartments, separate VCNs, network security groups, and private connectivity to Oracle services, are all native and free. The work is in using them deliberately.
Why scope is the whole game
The cardholder data environment, the CDE, is the set of people, processes, and system components that store, process, or transmit cardholder data or sensitive authentication data. That is the core. PCI DSS scope then extends further, to any system component that connects to the CDE or could impact its security. This second category is where estates lose control. A monitoring agent with an open path into the CDE, a shared Active Directory domain, a jump host used for both payment and general administration, a CI pipeline that deploys into the CDE: each of these drags itself, and often everything it touches, into scope.
Scope creep has a compounding character. Every additional in scope system needs hardening evidence, patching evidence, access reviews, log coverage, vulnerability scanning, and a seat in the annual assessment. Assessors price engagements by the size of the environment they must sample, and internal teams pay the same tax in preparation hours. The single highest return security investment in a payment estate is therefore segmentation: a network boundary, verified by testing, that lets you declare the rest of the estate out of scope and prove it. The PCI Security Standards Council's own scoping guidance says exactly this, and assessors follow it.
The other lever is reducing where cardholder data exists at all. Tokenization, a validated third party payment page, or a point to point encryption solution can remove entire application tiers from scope before any network design begins. Always ask the data question before the network question: the cheapest CDE is the one that holds nothing worth assessing.
Oracle's attestation and the shared responsibility split
Oracle Cloud Infrastructure holds a PCI DSS Attestation of Compliance as a Level 1 service provider, covering a long list of OCI services across commercial regions, including compute, block and object storage, virtual cloud networks, load balancers, the database services including Autonomous Database and Exadata, OCI Kubernetes Engine, and the core security and observability services. You can confirm whether a specific service in a specific region is in the attested list through the compliance documents available in the OCI console, and you should, because the list is the boundary of what Oracle will attest for you. We maintain a broader map of what Oracle attests across frameworks in our guide to OCI compliance certifications.
The split matters more in PCI DSS than in almost any other framework because your assessor will ask for the AOC and then move on. Oracle's attestation covers the physical data centers, the hypervisor and the infrastructure beneath your instances, the operation of the attested platform services, and Oracle's own personnel and processes. It does not cover anything you build. Your operating systems, your application code, your IAM policies, your network rules, your key management, your logging configuration, and your users are assessed against you, with your evidence. The standard formalizes this in Requirement 12.8 and 12.9: you must hold the provider's attestation, document the responsibility split, and monitor it annually. Practically, that means downloading Oracle's PCI Shared Responsibility Matrix, mapping every requirement to Oracle, to you, or to both, and keeping that mapping current. Teams coming from HIPAA will recognize the shape of this exercise from business associate agreements, and our companion piece on running HIPAA workloads on OCI covers that parallel in detail.
Designing the CDE on OCI
The native OCI constructs map cleanly onto PCI DSS scoping concepts, and a good design uses each one for what it does best.
Compartments as the administrative boundary
Put the CDE in its own compartment, or a small compartment tree, with IAM policies written so that only the payment platform group can manage resources inside it. Compartments do not segment networks, a mistake we still see in design reviews, but they do segment administration, and PCI DSS cares deeply about who can administer in scope systems. A dedicated CDE compartment gives you a crisp answer to the access review questions in Requirement 7 and a natural anchor for Cloud Guard targets and budget tracking.
A separate VCN as the network boundary
Give the CDE its own VCN. Not a subnet in a shared VCN, a separate VCN. Within a VCN, routing between subnets exists by default and the burden falls on security rules to restrict it; between VCNs, no path exists until you build one. Assessors understand that distinction immediately, and it turns the segmentation argument from a review of hundreds of rules into a review of a handful of deliberate attachments. All CDE subnets should be private subnets. Instances in a private subnet cannot receive public IP addresses, which makes the no public ingress posture structural rather than procedural. Inbound traffic from the internet, if the payment flow needs it, terminates on a load balancer in a separate ingress VCN or subnet, with a web application firewall in front of it, and only the load balancer may initiate connections inward.
Network security groups over security lists
Use network security groups, not subnet level security lists, for CDE traffic rules. Security lists apply to every VNIC in a subnet, which forces rules to be written for the loosest case and makes the rule set drift toward broad. NSGs attach to specific resources and can reference other NSGs as source or destination, so the rule that matters reads as application tier to database tier on port 1521, not as one wide CIDR range to another. That is precisely the least privilege story Requirement 1 asks you to tell, and it produces rule sets an assessor can actually read. Keep a minimal security list as a backstop and put the real policy in NSGs.
Private paths to Oracle services
The CDE will need Object Storage for backups, OCI services for patching and telemetry, and possibly Autonomous Database. Route that traffic through a service gateway, which reaches Oracle services without traversing the internet, and through a NAT gateway only for the outbound flows you have explicitly justified, ideally filtered through a firewall or proxy that enforces an allowlist. An internet gateway has no place attached to a CDE VCN. Administrative access comes in through the OCI Bastion service or a hardened jump host in a separate management subnet, with MFA enforced and sessions recorded. This is the same direction of travel as a broader zero trust design, and the patterns compose: our article on zero trust architecture on OCI shows how the CDE controls extend to the rest of the estate.
Segmentation patterns compared
Three patterns cover most OCI payment estates, and they differ mainly in how much scope they remove and how much engineering they demand.
| Approach | Scope reduction | Complexity | Cost | Audit effort |
|---|---|---|---|---|
| Dedicated CDE VCN with DRG routing | Strong. Out of scope VCNs have no path except through inspected DRG attachments | Moderate. Route tables and NSGs, all native constructs | Low. VCNs, NSGs, and the DRG carry no charge | Moderate. Assessor reviews attachments, route tables, and NSG rules |
| Hub and spoke with a network firewall | Strong. All traffic between the CDE spoke and anything else crosses an inspection point with full logging | Higher. Firewall policy lifecycle, transit routing, and HA design | Moderate. OCI Network Firewall or a partner appliance is a real line item | Lower. One choke point, one rule base, one log source to sample |
| Tokenization or outsourced payment page | Strongest. Systems that never see a PAN can leave scope entirely, sometimes reducing the assessment to a lighter SAQ | Application change rather than network change, plus a provider dependency | Provider fees, offset by a much smaller in scope estate | Lowest. The assessment shrinks to the token boundary and the residual CDE |
These compose rather than compete. The estates that sail through assessment usually tokenize first to shrink the data footprint, then place the residual CDE in a dedicated spoke VCN behind a firewall hub. Whatever you choose, remember that segmentation is only real once it is verified: PCI DSS requires penetration testing to confirm that segmentation controls actually isolate the CDE, annually for merchants and every six months for service providers, and the test report is the evidence that your out of scope declaration holds.
What PCI DSS v4.0 changes on cloud
PCI DSS v4.0 replaced v3.2.1 in March 2024, and its remaining future dated requirements became mandatory at the end of March 2025, so every assessment now runs against the full standard. Three changes matter disproportionately on OCI.
Targeted risk analysis. Several requirements now let you set your own frequency for a control, provided a documented, targeted risk analysis justifies it. That flexibility is useful on cloud, where some legacy frequencies make little sense, but it converts into work: each analysis must be written down, reviewed annually, and defensible in front of an assessor. Treat the set of targeted risk analyses as a controlled document set from day one.
Authenticated internal scans. Internal vulnerability scans must now run with authenticated access for systems that can support it. On OCI that means your scanning approach needs credentials managed properly, ideally through a vault, and coverage across instances that have no public exposure. The OCI Vulnerability Scanning Service helps with host coverage, but most estates pair it with a commercial scanner to satisfy the authenticated scanning and reporting detail assessors expect.
MFA everywhere. Version 4.0 extends multifactor authentication from remote and administrative access to all access into the CDE, for everyone. On OCI, enforce MFA in your identity domain, require it in sign on policies that gate federated access, and make sure the requirement follows administrators through the bastion path, not just the console. Financial entities in the EU will recognize the direction here, since operational resilience rules are converging on the same expectations, a convergence we examine in our article on DORA compliance on OCI.
Logging, evidence, and scanning cadence
Requirement 10 is where OCI's native services earn their keep. The OCI Audit service records control plane activity in every tenancy automatically and cannot be disabled, which gives you the who changed what record for the cloud layer with no engineering at all. Turn on VCN flow logs for every CDE subnet, because they are both a detection source and the practical proof that your segmentation rules behave as documented. Add OS and application logs shipped through the Logging service or your SIEM, and wire Cloud Guard and Events to alert on the changes that threaten scope, a route table edit, an NSG rule addition, an internet gateway appearing where none should exist.
Retention is specific: PCI DSS requires twelve months of audit log history, with the most recent three months immediately available for analysis. OCI Audit retains its records for a fixed period that is shorter than a year, so you must export audit events, typically to Object Storage through a service connector, and apply retention rules to the bucket to cover the full twelve months. An assessor will ask to see a log from month eleven; have a runbook that retrieves it in minutes.
Scanning cadence on OCI follows the standard rules. External vulnerability scans run quarterly against your public endpoints and must come from a PCI approved scanning vendor, not from your own tooling, with passing results on file for each quarter. Internal scans run at least quarterly, now authenticated, with high risk findings remediated and rescanned. Penetration testing runs at least annually and after significant changes, covers both network and application layers, and includes the segmentation validation discussed above. Note that you are testing your own tenancy resources under Oracle's published testing policy, which permits customer penetration testing of customer assets without prior approval within stated rules; read those rules before your tester starts, and never aim tests at Oracle managed infrastructure or other tenants.
What assessors keep finding on OCI estates
Across the OCI environments we have assessed, remediated, or run under our 24/7/365 monitoring practice, the same findings recur. Security lists left at their permissive defaults alongside carefully written NSGs, so the effective policy is looser than the documented one. Quarterly access reviews that cover the application layer but skip OCI IAM, leaving departed administrators with live API keys. Audit log retention silently capped at the platform default rather than exported for twelve months. Flow logs enabled at launch and disabled during an incident investigation, never re enabled. A management VCN peered into the CDE for convenience, with no inspection and no documented business justification, quietly doubling the assessed scope. Customer managed keys created for the database tier but Object Storage backups still on Oracle managed encryption, undermining the key management narrative. None of these are exotic, and all of them are cheap to fix in month one and expensive to fix in the week before an assessment. Our OCI security practice builds CDE landing zones with these controls in place from the start, drawing on 20+ years of combined Oracle experience across regulated estates.
An eight step sequence to scope and segment a CDE on OCI
Run this in order. Each step makes the next one smaller.
- Map the cardholder data flows. Diagram every path a PAN takes through your systems, from capture to storage to settlement, including batch files, support tools, and logs. Scope follows data, and undiscovered flows are undiscovered scope.
- Shrink the data first. Decide what tokenization, a validated payment page, or point to point encryption can remove before any infrastructure work. Every tier that stops seeing PANs is a tier you never have to segment.
- Declare the CDE boundary. Write down which systems store, process, or transmit cardholder data, which systems connect to them, and which are out of scope, with the reason for each. This document anchors the entire assessment.
- Build the CDE compartment and VCN. Dedicated compartment with restrictive IAM, dedicated VCN with private subnets only, service gateway for Oracle services, no internet gateway, bastion access with MFA.
- Write the segmentation rules as NSGs. Express every allowed flow as an NSG to NSG rule with a documented justification, attach the CDE VCN to the DRG or firewall hub, and default deny everything else.
- Wire the evidence pipeline. OCI Audit exported to Object Storage with twelve months of retention, flow logs on all CDE subnets, OS and application logs to the SIEM, Cloud Guard and Events alerting on scope threatening changes.
- Stand up the scanning rhythm. Quarterly ASV scans of external endpoints, quarterly authenticated internal scans, and a remediation workflow that produces passing rescans, all calendared before the first assessment.
- Test the segmentation and rehearse. Commission a penetration test that explicitly attempts to reach the CDE from out of scope networks, fix what it finds, then walk the evidence end to end as if the assessor were in the room.
PCI DSS on OCI rewards exactly the discipline that good cloud architecture rewards anyway: small blast radius, explicit paths, evidence by default. The platform attestation is Oracle's job and it is done. The boundary is yours, and on OCI it is built from constructs that cost nothing but intent. Draw it tight, test that it holds, and the annual assessment becomes a review of a small, well lit room rather than a tour of the whole building.
Free white paper
Go deeper on this topic with The OCI Security and Compliance Blueprint, an audit ready architecture mapped to SOC 2, ISO 27001, PCI DSS, and DORA. An independent analyst style report with comparison tables and recommendations, free with a work email. Prefer a monthly summary instead? The OCI Brief delivers one practical OCI briefing a month.
Part of a series
This guide is part of OCI Security & Compliance — our complete pillar guide on the topic.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings.