Audit log coverage
Audit log coverage is the question of whether the control-plane record actually exists everywhere it needs to — every account, subscription, project, and region, capturing the event types an investigation depends on. It is distinct from how long logs are kept or how well they are protected: a perfectly retained, tamper-proof log is worthless if the action that mattered was never recorded in the first place. Coverage is where cloud logging silently fails, because it degrades as the estate grows rather than breaking all at once — a new account is vended, an opt-in region is switched on, a team ships a service, and none of it lands in the trail. We assess coverage against an authoritative inventory of the whole estate, not a sample, and we look at event depth (management-plane, data-plane, and read events) as well as breadth. The result is a precise map of where you are recording, where you are blind, and which of those blind spots sit over your most sensitive services.
Overview
What this check looks like in practice
Control-plane audit logs record every API call that creates, changes, or deletes cloud resources — the primary source of truth for an investigation. Coverage tends to drift as the estate grows: a new account, region, or project gets stood up and the trail is never enabled, leaving silent blind spots. We measure whether audit logging is on everywhere and captures the event types that matter, not just a sample.
Why it matters
You can only investigate, contain, or prove what you recorded, and attackers know that unmonitored corners of an estate are the safest place to operate — an unused opt-in region, a newly provisioned account, or a service whose data-plane events were never turned on. A capable intruder's first move against your visibility is often to disable or delete the trail entirely, which is why coverage and the guardrails that protect it are inseparable. From the auditor's side, coverage is one of the first things sampled: an assessor pulls a handful of accounts and checks whether logging was on, so a single unlogged production account can undermine an entire control narrative. Cyber insurers and incident responders make the same check, because the absence of a trail turns a contained incident into an open-ended, unprovable one. This is why audit-log coverage maps so directly to PCI-DSS Requirement 10, SOC 2 monitoring criteria, HIPAA audit controls, ISO 27001 logging controls, and the CIS logging benchmarks.
What we assess
What we look for
- A single organization-wide trail or sink (CloudTrail organization trail, Azure diagnostic settings enforced by policy at management-group scope, GCP org-level aggregated sink) so every current and future account, subscription, and project inherits logging automatically rather than by hand
- All regions covered, including opt-in regions and regions with no active workloads, plus global-service events — the empty regions attackers prefer are exactly the ones teams forget
- Management-plane (create/modify/delete) events captured universally, with data-plane and read events enabled for the services where they materially aid an investigation
- Critical control services — IAM, KMS / Key Vault / Cloud KMS, Secrets Manager, storage, and configuration services — explicitly included rather than filtered out by event selectors or exclusion rules to save volume
- Identity-provider audit trails (Entra ID sign-in and audit logs, IAM/directory events) exported deliberately, since they are separate from resource logging and easy to leave behind
- Guardrails that prevent logging from being turned off — SCPs, Azure Policy deny rules, or GCP org policy that block stopping, deleting, or reconfiguring the trail, with alerting on any such change
- New-account provisioning (Control Tower / landing zone, subscription vending, project factory) that bakes audit logging into the baseline so coverage does not decay as the estate expands
- Coverage verified by reconciling enabled trails against a live inventory of every account and region, not confirmed from a sample or assumed from an original setup
Across your clouds
AWS, Azure & Google Cloud
AWS
A CloudTrail organization trail applied at the AWS Organizations root, configured multi-region (including global service events and opt-in regions) and delivered to a dedicated logging account; management events everywhere — which is also where AWS KMS cryptographic operations and Secrets Manager API calls are recorded, as management read events, so read management events must be captured and KMS events left un-excluded — plus data events for the sensitive services that support them (S3, DynamoDB, Lambda) via advanced event selectors. An SCP that denies cloudtrail:StopLogging, cloudtrail:DeleteTrail, and cloudtrail:UpdateTrail keeps the trail from being disabled or narrowed, and CloudTrail Lake or a central S3 target consolidates delivery.
Azure
The Azure Monitor Activity log is per-subscription and retained only about 90 days on the platform, so durable coverage comes from Diagnostic settings enforced through Azure Policy (DeployIfNotExists) at management-group scope, sending Activity and resource logs to a Log Analytics workspace or storage account. Resource-level diagnostic categories (Key Vault, storage data plane, etc.) and Microsoft Entra ID sign-in and audit logs are separate streams that each need explicit configuration to be covered.
Google Cloud
Cloud Audit Logs split into Admin Activity (always on, no charge) and Data Access logs (ADMIN_READ / DATA_READ / DATA_WRITE) which are off by default and must be enabled in the IAM audit configuration, ideally set at the organization node so projects inherit it. An organization-level aggregated log sink routes everything to a dedicated logging project or bucket, and org policy plus an intercepting org-level aggregated sink and IAM restrictions on logging.configWriter/admin prevent the routing from being overridden or disabled at the project level.
Example finding
Organization trail covers active regions only, read management events are disabled (so KMS and Secrets Manager access goes unrecorded), and S3 data-event logging is off
Risk: Activity in the three opt-in regions carries no audit trail at all, and an attacker who reads secrets or decrypts data through the covered services leaves no record of the access — the two event classes most useful for proving what was actually touched are simply missing.
Fix: Reconfigure the organization trail to all regions including opt-in and global-service events, capture read management events (and stop excluding KMS events) so KMS and Secrets Manager access is recorded, add advanced event selectors for S3 (and other supported services) data events, and attach an SCP that blocks any account from stopping, deleting, or reconfiguring the trail.
Remediation
How to close it
- 1 Build an authoritative inventory of every account, subscription, project, and enabled region, then reconcile it against the trails that actually exist to expose the blind spots — do this before changing anything.
- 2 Consolidate to one org-level trail or sink delivering to a dedicated logging account or project: a CloudTrail organization trail (all regions, including global and opt-in), Azure diagnostic settings enforced by policy at management-group scope, and a GCP aggregated org sink.
- 3 Enable data-plane and read logging for the services where it matters most — IAM, KMS/Key Vault, Secrets Manager, and crown-jewel storage — scoping thoughtfully to control volume but never excluding those control services.
- 4 Export the identity-provider trails explicitly (Entra ID sign-in and audit logs, IAM/directory events), since they do not flow through resource logging by default.
- 5 Enforce guardrails that prevent logging from being disabled — SCPs, Azure Policy deny rules, or GCP org policy — and alert on any change to the logging configuration itself.
- 6 Bake audit logging into account and project provisioning (Control Tower/landing zone, subscription vending, project factory) and add a recurring reconciliation check so coverage is re-verified as the estate grows.
Compliance evidence
Questions
Do we need data-event or data-access logging turned on everywhere?
No. Management-plane logging should be universal, but data-plane logging generates far more volume and is best targeted to the services where read and write records genuinely help an investigation — key management, secrets, and your most sensitive storage. We help you scope it so you capture the evidence that matters without drowning the trail in noise.
We enabled CloudTrail years ago — isn't coverage already solved?
Coverage is a moving target, not a one-time switch. Every new account, region, or project is a fresh chance for a gap, and opt-in regions and newly launched services routinely fall outside an older trail. We verify against a live inventory of the estate rather than assuming the original setup still spans everything you run today.
How is this different from the retention and integrity review?
Coverage is whether the event was ever recorded; retention and integrity are whether that record survives long enough and unaltered. Coverage is the prerequisite — a log that is perfectly retained and tamper-proof still proves nothing if the action was never captured. We assess both, but they answer different questions.
More in logging & monitoring
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
