Audit Logging on OCI: Building Evidence for Regulators

Auditors and supervisors rarely ask whether you have logging. They ask for specific records: every change to a security list in March, every read of a particular bucket by a particular principal, every login to the database that holds cardholder data. Teams that treat logging as something the cloud does for them discover, at the worst moment, that the records they need were never enabled, aged out months ago, or sit in a form nobody can attest to. Evidence is a recurring theme in our complete guide to OCI compliance and sovereignty, because nearly every framework in it resolves to the same question: can you prove it.

This article is for the security engineers and compliance leads who own that question on Oracle Cloud Infrastructure: what separates logs from evidence, the four layers of OCI logging, the retention and integrity architecture, how it maps to regulator asks, and how to keep the bill sane.

Logs are not evidence

A log becomes evidence when it satisfies four properties at once, and a weakness in any one of them gives an auditor a finding and an opposing counsel an argument.

Completeness. The record covers every system and event class in scope, with no gaps in time. A flow log enabled in June cannot testify about May, and an audit trail that misses one subnet misses the one the incident used.

Integrity. You can demonstrate the records have not been altered or selectively deleted since capture, including by your own administrators. A log the people under investigation could have edited proves very little.

Retention. The records survive for the full period the framework requires, which is routinely longer than any platform default.

Retrievability. You can find, filter, and export the relevant records within the deadline of the request. A petabyte of unindexed archive that takes three weeks to search is retention without retrievability.

Everything that follows is about engineering those four properties into an OCI tenancy deliberately, because none of them arrives by default.

The OCI log landscape

OCI logging is not one thing. It is four layers with different owners, different defaults, and different retention behavior, and an evidence architecture has to account for all of them.

The Audit service: the control plane record

The OCI Audit service records control plane API calls across the tenancy: every create, update, delete, and most list and get operations, whoever initiated them and through whatever path, console, CLI, SDK, or Terraform. It is enabled by default in every tenancy and every region, it cannot be switched off, and each event carries the principal, source IP address, user agent, request parameters, and response status, the who, what, when, and from where that open most investigations.

Retention is where teams get caught. The Audit service keeps events for 90 days by default, extendable to a maximum of 365 days inside the service itself. For regulated estates that is the start of the design, not the end, for two reasons. Many obligations run longer than a year, and an investigation into a slow moving fraud can reach back further still. And audit events held inside the service live under the same administrative domain as the activity they record, so exporting them to storage with independent access control is what gives the record standing. The rule we apply on every engagement: set in service retention to 365 days, and export everything continuously to controlled storage for the real retention period.

Service logs through the Logging service

The Logging service collects logs emitted by individual OCI services, and unlike the Audit service these are opt in per resource. The ones that matter most for evidence: VCN flow logs, which record accepted and rejected traffic and are usually the only way to reconstruct lateral movement; Object Storage access logs, which answer who actually touched the data rather than who could have; load balancer logs; WAF logs, capturing blocked and allowed web requests with rule context; and Functions logs for serverless invocation history. Because each must be enabled resource by resource, the failure mode is silence: a bucket created outside the standard module simply never logs. The fix is structural, enable logs in the infrastructure as code modules that create the resources, and audit for unlogged resources continuously. The CIS Benchmark for OCI codifies exactly this, with checks for flow logs, bucket logging, and maximum audit retention, and running it is the fastest way to find the gaps.

Custom application logs through the unified agent

Application and operating system logs reach the Logging service through the unified monitoring agent, built on Fluentd, which tails files, journals, and syslog on compute instances and ships them into custom log groups. This is how application authentication events, privileged shell activity, and business level audit trails join the same pipelines as the platform logs. Treat agent configuration as code and monitor agent health, because an agent that silently stopped is a completeness gap you will discover during the audit.

Database auditing: a layer of its own

Infrastructure logs tell you a session reached the database listener. They do not tell you which rows were read. Database auditing is its own discipline: unified audit inside Oracle Database captures logons, privilege use, schema changes, and access to designated objects with policy precision, and Oracle Data Safe adds activity auditing across the fleet, collecting unified audit records centrally, applying alert policies, and producing the reports auditors recognize. For any regulation that cares about the data itself, PCI DSS, GDPR, most healthcare regimes, this is the layer the assessor reads first. Plan its retention separately, because audit records held inside the database disappear with it in a worst case, which is precisely when you need them. Export database audit data into the same archive architecture as everything else.

Designing the architecture: from log streams to evidence store

The pattern that survives audits has three stages: capture everywhere, concentrate into one controlled place, then fan out to the destinations that serve retention, analysis, and detection respectively.

Concentration comes first. Create a central log compartment, or for larger estates a dedicated security tenancy, that receives log data from every workload compartment and is administered by the security function rather than the application teams. A dedicated tenancy puts the evidence store behind a different tenancy boundary entirely, the cloud equivalent of keeping the CCTV tapes in a different building, and it pairs naturally with the segmentation thinking in our article on zero trust architecture on OCI.

Service Connector Hub is the plumbing. It moves data from the Audit stream and from Logging log groups to targets, Object Storage, Streaming, Logging Analytics, or Functions for transformation, with filtering on the way. The canonical compliance pipeline is one connector per region shipping audit events and critical service logs to an Object Storage bucket in the central compartment, continuously, without anyone remembering to run anything.

For the long term store, Object Storage gives you the three controls that matter. The Archive tier cuts storage cost by an order of magnitude for data you expect to read rarely, at the price of a restore delay of roughly an hour. Retention rules prevent objects from being modified or deleted for a defined duration. And a locked retention rule makes that protection irrevocable: once the lock takes effect, after a mandatory 14 day delay that exists so you can catch mistakes, no administrator, however privileged, can shorten the rule or delete the data inside its window. The lock converts a bucket into write once storage and gives you a credible answer to the tampering question.

Archived logs satisfy retention but not analysis, so the same connectors fan out to a query destination. Logging Analytics is the native option, with parsers for OCI sources, a purpose built query language, and dashboards that make recurring evidence requests repeatable. Estates with an established SIEM ship to it instead or in addition, typically through OCI Streaming, which presents a Kafka compatible interface that Splunk, Sentinel, QRadar, and the other mainstream platforms consume readily. Often the answer is both: the SIEM holds the rolling hot window where the SOC works, and the bucket with the locked retention rule remains the source of truth everything else is a copy of.

Integrity and access control

IAM policy is the first integrity control. Grant application teams read access to the logs of their own compartments, grant the security function read access everywhere, and grant delete and configuration rights on the evidence store to nobody in day to day use, holding them behind a break glass identity whose own use generates audit events. The separation between reading logs and managing logs is easy to express in OCI policy and embarrassing to be unable to demonstrate.

The locked retention rule defeats deletion, but a careful estate adds tamper evidence as well: a scheduled job that computes a cryptographic hash for each day's log objects, writes the digests to a manifest, and stores that manifest in a second location, ideally outside the tenancy. When a regulator asks how you know the archive is intact, recomputing hashes against an independently held manifest is a short and convincing answer, and it elevates the archive from stored to attested.

Mapping the architecture to regulator asks

Frameworks phrase it differently, but they converge on the same architecture.

PCI DSS is the most concrete: audit trail history retained for at least one year, with a minimum of three months immediately available for analysis. The hot window in your SIEM or Logging Analytics covers the three months, the archive bucket covers the year, and the assessor will want to see both the records and the retention configuration.

DORA pushes financial entities toward reconstruction: when an ICT incident occurs, the firm must determine what happened, in what order, across which systems, and report within tight deadlines. That is a completeness and retrievability test more than a retention test, which is why flow logs and database audit matter as much as control plane events. We cover the full obligation set in our guide to DORA compliance on OCI.

SOC 2 turns logging into evidence requests: the auditor samples a period and asks for the monitoring records, the alerts that fired, and the follow up. Repeatable saved queries pay for themselves here, and the logging architecture itself becomes a control in the system description. The broader attestation landscape is mapped in our article on OCI compliance certifications, including what Oracle's own audit reports cover and what remains yours to evidence.

GDPR contributes the accountability principle: you must demonstrate compliance, including who accessed personal data, while remembering that logs containing personal data are themselves regulated and need their own minimization and retention discipline. Logging everything forever is not a GDPR strategy; logging deliberately with documented purposes is.

Alerting on the logs you keep

An archive nobody watches satisfies the letter of retention and fails the spirit of monitoring, and most frameworks test both. The Events service turns specific audit events into action in close to real time: a rule matching changes to IAM policies, network security groups, or the logging configuration itself can publish to a notification topic or trigger a function within seconds of the API call. The short list we wire on every engagement: policy changes, security list and NSG changes, bucket visibility changes, logging and connector configuration changes, and break glass identity use. Cloud Guard complements the rules you write with detectors Oracle maintains, flagging risky configurations and suspicious activity tenancy wide, and its findings are themselves evidence that monitoring operates. The remaining gap is humans: alerts firing into an unread mailbox at 2am are findings waiting to be written, which is why estates without an internal SOC put our OCI monitoring service behind the pipeline, with 24/7/365 eyes on the alert stream.

Controlling the cost of keeping everything

Log volume grows with the estate, and undisciplined logging architectures become their own budget line. Three levers keep it proportionate. Tier aggressively: keep the hot window in the SIEM or Logging Analytics as short as the operational need allows, often 90 days, with everything older in the Archive tier at a small fraction of the cost. Filter at the connector: flow logs and load balancer logs drive the volume, and connector filters or a transformation function can drop health check chatter before it is stored, provided the compliance owner signs off on the exclusion and it is documented. Compress and batch: large compressed objects cost less and restore faster than millions of tiny files. These levers regularly reclaim a meaningful share of observability spend, and they sit alongside the broader levers behind the 40% average reduction we find across OCI estates.

Standing up regulator grade logging: the sequence

On a fresh tenancy or a remediation project, the order of operations below avoids the common trap of buying analysis tooling before the evidence foundation exists.

When the request lands: the evidence runbook

Treat every real request as four steps. Locate: translate the ask into sources and time ranges, control plane events from the audit archive, traffic from flow logs, data access from bucket logs and database audit, and confirm coverage for the whole window before promising anything. Export: restore from the Archive tier early, since the restore delay is the long pole, then extract with saved queries, keeping a copy of exactly what was produced. Prove integrity: include the retention lock configuration and the hash manifest verification for the objects involved, so the package demonstrates its own trustworthiness. Document the chain: record who requested, who extracted, when, from which sources, and who reviewed, because the handling of the evidence is part of the evidence. Teams that rehearsed step eight above complete this in days; teams improvising it take weeks, with caveats no one enjoys writing.

Logging is the rare compliance control that is cheap when designed early and painful in every dimension when retrofitted under a deadline. Build the pipeline before anyone asks, lock the archive, watch the alerts, and the audit becomes a retrieval exercise instead of an excavation.