How to Audit Your Cloud Log Coverage Before an Incident Forces You to Discover the Gaps
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Enabling CloudTrail in 2022 and assuming your AWS logging is complete in 2026 is a category error. Services have been added to your account. New regions have been deployed into. Data events (S3 object-level operations, Lambda invocations) were probably not enabled when the management trail was created. The logging configuration that was correct at enablement time has drifted as your environment has grown.
Most organizations discover their logging gaps during incident investigation, when the answer to "what happened to this S3 bucket between Tuesday and Thursday?" is "we have management-plane events but no data-plane events, so we cannot tell you which objects were accessed."
This guide covers how to audit your cloud logging coverage proactively -- validating actual log presence rather than configuration settings, identifying the gaps that matter most for incident reconstruction, and establishing a quarterly audit process that prevents the logging drift that accumulates silently between reviews.
The Seven Log Source Categories and Why Each Requires Separate Validation
A complete cloud logging architecture requires coverage in seven distinct categories, each with different configuration mechanisms and different failure modes:
1. Management plane logs (CloudTrail API Calls, Azure Activity Logs, GCP Admin Activity Audit Logs). These record every API call to create, modify, or delete cloud resources. This is typically the first log source enabled and the most reliably collected -- but verify it covers all regions, not just the home region.
2. Data plane logs (S3 object access, DynamoDB item-level operations, Azure Blob Storage access, GCP Cloud Storage data access). These record access to data, not just resource management. Data plane logging is typically disabled by default due to volume and cost. This is the most common gap: organizations have management plane coverage but no data plane coverage for their most sensitive data stores.
3. Network flow logs (AWS VPC Flow Logs, Azure NSG Flow Logs, GCP VPC Flow Logs). These record source and destination IP, port, protocol, and accepted/rejected status for network traffic. VPC Flow Logs must be enabled per-VPC -- a gap in any VPC creates a network visibility blind spot.
4. Identity and authentication logs (AWS CloudTrail for IAM events, Azure AD Sign-In Logs, GCP Cloud Identity Audit Logs). These record authentication events, role assumptions, and permission changes. Verify that role assumption events (AWS AssumeRole) and cross-account access events are captured.
5. Container and orchestration logs (EKS audit logs, AKS control plane logs, GKE Admin Activity logs). Kubernetes control plane audit logs are not enabled by default in all managed Kubernetes services. These logs are essential for detecting unauthorized pod creation, secret access, and RBAC manipulation.
6. Serverless execution logs (Lambda invocation logs, Azure Function logs, Cloud Run logs). Function invocation logs capture the trigger source, execution duration, and error output. Without them, serverless-based lateral movement or data exfiltration is nearly invisible.
7. DNS query logs (Route 53 Resolver Query Logs, Azure DNS Analytics, Cloud DNS logs). DNS logs record every domain lookup from your cloud resources. DNS-based C2 detection and data exfiltration via DNS tunneling both require DNS query log coverage.
Validating Actual Log Presence (Not Just Configuration)
A logging configuration review tells you what services are set to log. A logging coverage audit validates that logs are actually appearing in your centralized log destination. These are different because log delivery fails silently: an S3 bucket with an incorrect policy stops receiving CloudTrail logs without generating an error that reaches your monitoring system, and you will not know until you query for logs that are not there.
The validation process for each log source category:
Generate a known event and confirm it appears. For management plane logs: create a test IAM role in the target account, query CloudTrail for the CreateRole API call, confirm it appears in your SIEM within the expected ingestion delay (typically 5 to 15 minutes for CloudTrail). For data plane logs: access a monitored S3 object, query your logging destination for the GetObject event for that specific object key. For VPC Flow Logs: make a connection to a known IP from a test EC2 instance, query Flow Logs for the connection. If the known event does not appear within 30 minutes, the log delivery pipeline has a gap.
Query for recent log volume and confirm expected baseline. Run a query against your SIEM or log aggregation system: "how many CloudTrail events did we receive in the last 24 hours?" Compare to the previous 7-day average. A 50% or greater drop in log volume for any source indicates a delivery failure. Set up an automated daily alert for log volume drop of 40% or more across each source category.
Verify regional coverage. For AWS, run an account-wide query that shows CloudTrail log counts broken down by region. Any region with zero events in the last 7 days that should have activity is a coverage gap.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The Five Most Common Cloud Logging Gaps Found in Practice
Five gaps appear consistently across cloud environments that pass basic logging configuration reviews:
Gap 1: Data events disabled. The CloudTrail management trail is enabled, but S3 data events and Lambda invocations are not. The CIS Benchmark for AWS recommends enabling S3 data events for any bucket containing sensitive data. Enable via the CloudTrail console under Data Events -- it requires selecting specific buckets or enabling for all S3 operations.
Gap 2: Single-region CloudTrail trail. CloudTrail was enabled as a single-region trail covering the primary region. Resources deployed in secondary regions (disaster recovery, lower-latency endpoints) generate no CloudTrail events. Fix: enable a multi-region trail. CloudTrail charges per 100,000 management events, so the cost of a multi-region trail is proportional to actual API call volume in secondary regions.
Gap 3: VPC Flow Logs not enabled for new VPCs. The original VPCs have Flow Logs enabled, but VPCs created in the last 12 months do not. Fix: an AWS Config rule (vpc-flow-logs-enabled) or an AWS Organization SCP combined with an EventBridge rule that automatically enables Flow Logs on new VPC creation.
Gap 4: Kubernetes control plane logs disabled. EKS or AKS clusters have application and worker node logging but no control plane audit logging. Control plane audit logs capture kubectl commands, secret access, and API server authentication events. Enable in EKS via the cluster logging configuration (API Server, Authenticator, and Audit log types are the three most security-relevant).
Gap 5: Log retention below incident investigation requirements. CloudTrail delivers to S3 with no default retention period -- the S3 lifecycle policy determines retention. Logs older than the lifecycle expiration date are gone. For effective incident investigation, 90 days queryable in your SIEM and 365 days in cold storage (S3 Glacier or equivalent) is the minimum. Verify your lifecycle policies explicitly.
Retention and Query Coverage Requirements for Incident Investigation
Log retention has two requirements that are commonly conflated: how long the logs are stored and how quickly they are queryable. Both matter for incident investigation.
Storage retention. Cloud breach investigations regularly require examining logs from 60 to 90 days before detection -- attackers in persistent access scenarios are often present weeks before active exploitation is detected. A 30-day CloudWatch Logs retention window is common in default configurations and is insufficient. Recommended: 90 days in your primary log aggregation system (SIEM or queryable log store) and 365 days in compressed archival storage (S3 Standard-IA or Glacier) for regulatory compliance and extended investigation scenarios.
Query coverage. Logs that are stored but not queryable within 30 minutes are not useful for active incident investigation. If your SIEM indexes the last 30 days and older logs require a manual S3 query using Athena or a log export tool, validate that you can actually perform that query under incident conditions. Test it: run an Athena query against your CloudTrail S3 bucket for a specific Account ID and Event Name and confirm you can get results within 15 minutes without pre-configuration.
Log integrity. For regulatory compliance and incident investigations that may lead to legal proceedings, logs must be demonstrably unmodified. Enable CloudTrail log file validation, which generates a digest file every hour that allows you to verify that log files have not been modified, deleted, or forged. Verify that the S3 bucket receiving CloudTrail logs has Object Lock enabled (write-once, immutable storage) and that no principal except the logging delivery role has delete permissions on the bucket.
Cross-Account and Multi-Cloud Logging Gaps
Centralized log aggregation in multi-account and multi-cloud environments introduces additional gap categories that single-account environments do not face:
Cross-account event visibility. In AWS Organizations, a CloudTrail Organization Trail captures events from member accounts. But management events in member accounts that are NOT in the organization (shadow accounts, recently acquired company accounts, development sandboxes created by engineers) are invisible to the organization trail. Run an AWS Organizations account inventory query and compare it to the list of accounts sending logs to your SIEM. Any account present in the inventory but absent from the SIEM log flow is a coverage gap.
Cross-account IAM role assumption. When an identity in account A assumes a role in account B, the AssumeRole event appears in CloudTrail in account A (the source). But the API calls made using that assumed role in account B appear in CloudTrail in account B (the destination). If your SIEM is not collecting logs from both accounts, you see the role assumption but not what was done with it. Verify that all member accounts are sending logs to the centralized SIEM.
Multi-cloud coverage. Organizations running workloads across AWS and Azure, or AWS and GCP, frequently have complete logging coverage on the primary cloud and minimal coverage on the secondary. The secondary cloud is often where shadow workloads exist and where security controls are weakest. Verify that your SIEM has connectors and active data flows from every cloud environment where you have running workloads, not just your primary cloud.
The Quarterly Log Coverage Audit Checklist
A quarterly audit that takes one analyst approximately 4 hours can catch logging drift before it becomes an incident investigation failure. The checklist:
Coverage verification (2 hours): Generate a known test event in each log source category and confirm it appears in the SIEM within 30 minutes. Query log volume by source for the last 30 days and compare to the prior quarter. Enumerate all active VPCs, accounts, regions, and Kubernetes clusters and verify each has a confirmed log entry in the SIEM from the last 7 days.
Retention verification (30 minutes): Query your SIEM for logs from 91 days ago and confirm they are accessible. Query your archival S3 bucket for logs from 366 days ago and confirm the files exist and are readable. Verify CloudTrail log file integrity validation digest files are present and current.
Gap remediation tracking (30 minutes): Review the gap findings from the prior quarter's audit. For any gap not yet remediated, update the tracking ticket with current status. Add any newly discovered gaps to the tracking system with an assigned owner and remediation date.
New resource coverage check (1 hour): Enumerate cloud resources created in the last 90 days (new VPCs, new EKS clusters, new AWS accounts, new Azure subscriptions). Confirm each new resource class has corresponding log coverage. For any resource created without logging enabled, create a remediation ticket.
The quarterly audit output is a one-page coverage report: sources covered, sources with confirmed gaps, gaps in remediation, and new gaps discovered. This report is the evidence artifact for security program reviews and compliance audits.
The bottom line
Logging configuration is not the same as logging coverage. A configuration that was complete at setup has likely drifted as new services, regions, accounts, and workloads were added without corresponding logging updates. The gaps that matter most -- data plane events for sensitive data stores, Kubernetes control plane logs, multi-region CloudTrail coverage, and cross-account visibility -- are consistently absent in environments that pass basic configuration reviews. Validate actual log presence by generating known events and confirming they appear in your SIEM. Verify retention is sufficient for incident investigation (90 days queryable, 365 days in cold storage). Run the quarterly checklist to catch drift before it becomes a forensic gap during an active investigation. The four hours per quarter this requires is a small investment against the alternative: discovering during a breach investigation that the logs you need do not exist.
Frequently asked questions
What is the difference between a logging configuration review and a logging coverage audit?
A logging configuration review checks that logging services are enabled and set to collect the right event types. A logging coverage audit validates that logs are actually appearing in your centralized destination -- that configuration is translating to actual log delivery. The two diverge due to S3 bucket policy errors that stop CloudTrail delivery, IAM permission changes that break log shipping, service quotas that throttle log volume, and regional gaps where new resources are deployed without logging. Coverage audits require generating known test events and confirming they appear in your SIEM, not just checking that the logging service checkbox is enabled.
What are the most common cloud logging gaps found in AWS environments?
Five gaps appear consistently: S3 data events disabled (management trail is enabled but data plane access to S3 objects is not captured), single-region CloudTrail trail that misses resources deployed in secondary regions, VPC Flow Logs not enabled for VPCs created after the initial logging setup, Kubernetes control plane audit logs disabled in EKS clusters, and log retention below 90 days in the primary queryable log store. The CIS Benchmark for AWS covers the first three; Kubernetes control plane logging and retention are frequently missed even in environments that pass CIS benchmark evaluations.
How much cloud log retention do I need for incident investigation?
Minimum 90 days in a queryable log store (SIEM or Athena-accessible S3) and 365 days in compressed archival storage (S3 Glacier or equivalent). The 90-day requirement comes from the typical breach dwell time -- attackers with persistent access are often present 60 to 90 days before active exploitation or detection. Logs older than your queryable retention window require a manual archive retrieval process that adds hours to an investigation. Verify that your S3 lifecycle policies explicitly set retention and that no automated cleanup policy is silently expiring logs before the target retention date.
How do I detect if my CloudTrail logs have stopped flowing?
Three signals indicate CloudTrail delivery failure: alert on log volume drop of 40% or more in any 24-hour period compared to the 7-day average for that source, validate CloudTrail log file integrity digests are being generated hourly (gaps in digest generation indicate delivery interruption), and run a weekly check that confirms log volume by region for all active regions. To confirm the alert works: test it by temporarily modifying the S3 bucket policy on your CloudTrail destination to block delivery, wait 30 minutes, and verify your alert fires. Restore the policy after testing.
What cloud logs are most important for incident investigation?
Priority order for incident investigation: management plane logs (CloudTrail API calls, Azure Activity Logs) for resource creation and modification events, identity and authentication logs (IAM events, role assumptions, authentication failures) for access reconstruction, data plane logs (S3 object access, database queries) for data exfiltration investigation, network flow logs (VPC Flow Logs, Azure NSG Flow Logs) for lateral movement and C2 communication reconstruction, and DNS query logs for domain-based C2 detection. Kubernetes control plane logs and serverless execution logs become critical when incidents involve container or serverless workloads.
How do I audit cloud logging coverage in a multi-account AWS environment?
Three checks specific to multi-account environments: enumerate all AWS accounts via the Organizations API and compare to the accounts actively sending logs to your SIEM (any account in the inventory but absent from SIEM log flow is a gap), verify that AssumeRole events in CloudTrail are being collected from both the source account (where the role is assumed) and the target account (where API calls are made with the assumed role), and confirm that a CloudTrail Organization Trail is active and covers all member accounts rather than per-account trails that may have been created inconsistently. Accounts created through Organization invitation rather than through the Organizations console may not automatically inherit the Organization Trail.
What does a quarterly cloud log coverage audit include?
A quarterly audit covering four areas in approximately 4 analyst hours: coverage verification (generate test events in each log source category, confirm they appear in SIEM within 30 minutes, query log volume by source and compare to prior quarter baseline), retention verification (query logs from 91 days ago to confirm queryability, verify archival files exist at 366 days, confirm CloudTrail log integrity validation digests are current), gap remediation tracking (review prior quarter gaps and update status), and new resource coverage check (enumerate resources created in the last 90 days and confirm each has corresponding log coverage). Output is a one-page coverage report with sources covered, confirmed gaps, gaps in remediation, and newly discovered gaps.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.