Centralized Cloud Audit Logging

Audit logging should survive the environment it describes. If an application account is compromised, deleted, or misconfigured, investigators still need its identity, configuration, and data-access evidence.

That leads to a consistent architecture across providers: collect at the organization or tenant level where possible, route to a security-owned destination, separate search from durable retention, and verify delivery continuously.

This is engineering guidance, not legal advice or a compliance guarantee. For organizations regulated by HIPAA, HHS describes audit controls that record and examine activity in systems containing or using ePHI, plus procedures to regularly review system activity. The appropriate event coverage, review frequency, retention, and vendor terms still depend on the organization's risk analysis, policies, agreements, and authorized privacy, security, and legal owners.

Do not call every record an audit log

Cloud control-plane records cannot explain every application action. Application logs cannot prove who changed a cloud policy. Build a coverage matrix by service and question: which source records reads, writes, denied requests, identity changes, console access, network decisions, deployments, and business actions; whether it is enabled by default; and which actor, resource, outcome, timestamp, and correlation fields it supplies.

Separate collection, investigation, and retention

Organization, tenant, and identity sources
└── Organization-wide routing and health monitoring
    ├── Search + detection tier (shorter, queryable retention)
    ├── Protected archive (longer, deletion-resistant retention)
    └── Incident workflow (case ID, timeline, preserved exports)

The searchable destination supports operations and investigation. The archive supports longer retention, recovery, and evidence protection. They can use the same service when its access and immutability controls fit both purposes, but they remain separate responsibilities.

• Use a security-owned account, project, or subscription for central destinations.
• Encrypt data at rest and in transit; use customer-managed keys only when the threat model, contractual requirements, and operational ability justify them.
• Separate collection administration, key administration, archive deletion, routine search, investigation, and broad export privileges.
• Use a locked retention or WORM control where justified, after testing the irreversible behavior, account or project deletion implications, and recovery path.
• Monitor the logging configuration and destination as security-critical resources.
• Document expected delivery delay, failure behavior, and recovery.

CloudTrail needs explicit coverage decisions

AWS CloudTrail Event history provides the previous 90 days of management events in a Region; it is not the durable organization archive. For an ongoing record, create a trail or event data store. An AWS Organizations trail can send events from the management account and member accounts to common S3, CloudWatch Logs, and EventBridge destinations. Use a multi-Region trail for enabled Regions and account explicitly for other AWS partitions.

CloudTrail distinguishes management, data, network activity, and Insights events. Trails and event data stores record management events by default, but data, network activity, and Insights events require explicit choices and can add cost. Map required reads and writes to supported resource types and selectors instead of enabling every high-volume data event without a question it must answer.

• Deliver to a dedicated log-archive account and bucket with restrictive S3, KMS, public-access, lifecycle, versioning, and—where justified—Object Lock controls.
• Enable CloudTrail log-file integrity validation and actually run a validation procedure; digest delivery alone does not validate the files.
• Send selected events to operational detection systems without making them the only copy.
• Alert on trail changes, delivery failures, bucket-policy changes, and key-policy changes.
• Check get-trail-status, validation failures, the latest delivery time, new accounts, and opt-in Regions rather than assuming a visible organization trail proves delivery.

Route Cloud Audit Logs through aggregated sinks

Google Cloud aggregated sinks can route entries from an organization or folder and its children to a central logging project, log bucket, Cloud Storage bucket, BigQuery dataset, or Pub/Sub topic. Prefer a dedicated logging project. Choose non-intercepting or intercepting routing deliberately: an intercepting sink can change routing in child resources, so test first with a non-intercepting sink and confirm the sink writer can write to the destination.

Admin Activity and System Event audit logs are always written. Policy Denied logs are generated by default but can be excluded from storage. Data Access logs—except for BigQuery Data Access logs—are disabled by default, can be high volume, and support principal exemptions. Set an organization or folder default for required services, review exemptions, and verify the effective configuration in existing and new projects.

• Use restricted log views and narrowly grant private-log access because Data Access entries and request metadata may be sensitive.
• Set custom retention and, when justified, lock the log bucket only after testing: locking is irreversible and project deletion needs separate protection such as a lien.
• Review sink filters, child-resource routing, exclusions, exemptions, and billable volume for coverage gaps or cost surprises.
• Monitor changes to sinks, exclusions, retention, IAM, and audit-log configuration.
• Generate known admin and data-access actions and confirm they arrive centrally.

Export Activity Logs and configure resource logs

Azure Activity Log records subscription-level control-plane activity and retains it for 90 days by default. Create a subscription diagnostic setting to send it to a central Log Analytics workspace, Event Hubs, or Storage. Log Analytics supports correlation and alerts; Storage can support longer-lived audit or backup copies.

Resource logs cover service and data-plane behavior. Resources generate them, but Azure Monitor does not collect them until a diagnostic setting routes the selected categories. Create a separate setting for each applicable resource, use Azure Policy and remediation at scale, and inspect service-specific categories. Microsoft Entra audit, sign-in, service-principal, and managed-identity activity is a separate source with its own tenant diagnostic settings.

• Use security-owned Log Analytics, Event Hubs, and Storage destinations with distinct query, export, retention, key, and deletion roles.
• For a protected archive, evaluate Blob immutable storage and lifecycle tiers; test append compatibility and lock behavior before committing to WORM retention.
• Monitor diagnostic settings, Azure Policy compliance and remediation, workspace access, data-export rules, storage immutability, and retention.
• Verify subscription Activity Log, selected resource data-plane operations, and Entra identity events independently.

Normalize context without erasing the source

Preserve each provider's original event and add normalized fields for provider, organization or tenant, account or project or subscription, region, service, event class, action, resource, outcome, source IP, user agent, and correlation identifiers. Resolve assumed roles, service accounts, managed identities, federated sessions, and application users to the stable identity and session that acted; keep both the displayed name and immutable provider IDs.

Store event time, ingestion time, and—when available—service processing time in UTC. Provider events can arrive late or out of order, so build investigation timelines using identifiers and causal evidence rather than sort order alone. Synchronize clocks for application and infrastructure sources, record observed skew, and alert when it breaches the investigation tolerance.

Record the business action without copying the record

A healthcare application often needs to establish that an authorized user viewed, changed, disclosed, exported, or deleted information. The audit event should identify the authenticated actor, effective role, action, object type and reference, tenant, purpose or authorization context where appropriate, outcome, UTC time, source context, session, and correlation ID.

An internal identifier can still be PHI or otherwise sensitive when it can be linked to a person or combined with another system. Use controlled schemas and allowlisted fields; keep patient names, diagnoses, clinical text, complete URLs, query strings, request and response bodies, tokens, and exported records out of general logs. Redaction is defense in depth, not permission to send PHI to an unapproved service. If a log platform creates, receives, maintains, or transmits ePHI on behalf of a regulated organization, validate the applicable service scope, configuration, data location, subcontractors, and BAA with authorized owners.

Start with changes that weaken your controls

High-value alerts are tied to decisions and response ownership. Begin with events such as:

• Audit trail, sink, diagnostic setting, exclusion, or retention changes.
• Creation of broad administrators, access keys, service-account keys, or federated trust.
• Changes to encryption keys, secret policies, public access, firewall rules, or logging destinations.
• Unusual data exports, object reads, secret access, or cross-environment access.
• Break-glass use, failed privilege elevation, or deployment outside the approved pipeline.

Each alert needs a severity, owner, response path, expected false positives, and test procedure. Sending every cloud event to one noisy channel is collection, not detection.

Keep enough evidence, not unlimited sensitive debris

Retention should follow legal, contractual, security, operational, investigation, and cost requirements. Different log classes can have different searchable, archive, and deletion periods. Do not automatically convert HHS's six-year retention rule for required Security Rule documentation into a blanket six-year requirement for every raw log; have authorized owners map which records and evidence the organization must retain. Make legal holds or incident preservation explicit.

Separate permissions to configure collection, search routine logs, conduct investigations, manage retention, administer keys, and export data. Use just-in-time or case-bound access for broad investigations, record queries and exports, and review access regularly. Broad read access can expose identities, IP addresses, resource names, request parameters, and application context across every environment.

Spend according to investigation value

Estimate volume before enabling high-volume data, network, or application events. Measure by source, event class, service, environment, and read-versus-write activity; set budget and anomaly alerts; and review cardinality, duplicate routing, recursive destinations, noisy health checks, and unused indexes.

Keep security-relevant events intact. Reduce cost through justified selectors, tiered retention, storage lifecycle, sampling of non-audit telemetry, and shorter searchable retention with a protected archive—not silent exclusions that make an investigation impossible. Every exclusion should have an owner, rationale, expiry or review date, and regression test.

Preserve first, then build the timeline

1. Open a case with an owner, scope, UTC time window, systems, identities, and known blind spots.
2. Preserve original provider records, integrity metadata, query text, export hashes, access history, and chain-of-custody notes before transformations.
3. Pivot from the alert through stable actor, session, request, resource, and correlation identifiers across identity, cloud, application, network, deployment, and vendor sources.
4. Record event time and ingestion time, late arrivals, duplicates, conflicting fields, clock skew, and any provider outage or delivery failure.
5. Limit exports and PHI exposure to the approved purpose, share through the case system, and document who accessed the evidence.
6. Hand technical facts and uncertainties to the authorized incident, privacy, security, and legal decision-makers; preserve decisions and remediation separately from raw evidence.

Test the evidence path end to end

1. Inventory every current account, project, subscription, identity source, service category, destination, and expected event type; detect newly created resources and hierarchy drift.
2. Generate harmless control-plane, allowed data-read, data-write, denied-access, identity, and application actions in each environment.
3. Confirm the original and normalized records contain the expected actor, session, action, target, outcome, UTC time, and correlation fields.
4. Confirm each record reaches search and protected archive tiers; measure end-to-end delay, duplicates, parse failures, schema drift, and gaps.
5. Trigger representative alerts, verify the owner and response path, and rehearse a cross-provider investigation from an isolated account.
6. Attempt unauthorized sink, retention, key, destination, exclusion, and reader changes; verify prevention or detection and recovery.
7. Restore an archived sample and validate integrity controls, including CloudTrail digest validation where used.

Connect evidence to environments and delivery

Sources reviewed 13 Aug 2026: AWS CloudTrail concepts and organization trails, data events, network activity events, and log-file integrity validation; Google Cloud Audit Logs, Data Access configuration, aggregated sinks, and log-bucket retention and locking; Microsoft Azure Activity Log, diagnostic settings, Entra activity-log routing, and Blob immutable storage; and HHS HIPAA Audit Protocol and cloud-computing guidance.