Audit logs only help if someone reads them
Every major cloud records nearly everything. Almost nobody reads it. The gap between 'logged' and 'noticed' is where breaches live for months.
Your cloud provider is already writing down nearly everything that happens: every API call, every permission change, every bucket made public, every key created. The uncomfortable question isn't whether the evidence exists — it's whether anyone will ever read it before the incident review.
The common gaps
- Logging isn't on everywhere. CloudTrail, Azure Activity Log and GCP Audit Logs have to be enabled per account and per region. Attackers look for the region nobody watches. So should you.
- Retention is too short. Thirty days of logs is a confession that you only care about last month. Breaches are commonly discovered 90+ days in. Keep a year if you can.
- Logs go nowhere. Logs that sit in the service that produced them don't get read. Centralize them somewhere queryable.
- Nobody alerts on the high-signal events. IAM policy changes, new access keys, public exposure of storage, logging itself being disabled — these are rare, high-signal, and should interrupt someone.
A sane starting point
Enable audit logging in every region, including the ones you don't use. Centralize with at least 90 days hot. Write alerts for the dozen events that should never happen quietly. Then — the hard part — actually read the stream, or get something that reads it for you.
That last part is why BlackPing reads cloud audit logs in full rather than sampling them: the interesting event is by definition the rare one, and a sample is where rare events go to disappear.