Cloud audit logging and threat detection guide for SaaS
Build a cloud audit logging baseline for SaaS with organization-wide event coverage, protected central storage, purposeful retention, actionable alerts and tested investigations.
In this guide
What should cloud audit logging capture?
Cloud audit logging records control-plane and selected data-access activity so a team can investigate who changed a resource, identity or policy, when it happened and what was affected. It complements application audit logs and operational metrics; it does not replace them. Start by mapping accounts and projects, choosing event categories based on risk, centralizing protected copies and testing whether responders can answer real investigation questions.
Inventory providers, environments and available event categories
List cloud accounts, subscriptions, projects, regions, identity systems and critical services. Identify which provider logs are always on, which data-access or resource logs need explicit configuration, and which activity is not recorded. Google Cloud, for example, distinguishes Admin Activity, Data Access, System Event and Policy Denied logs; Data Access logs are disabled by default for many services and can add storage cost.
Record high-impact identity and configuration changes
Prioritize authentication and privilege changes, new credentials, public exposure, security-group or firewall edits, key-policy changes, logging changes, new resources and administrative access to sensitive data. Confirm the audit event includes a stable actor, resource, time and result or denial reason when the provider exposes those fields.
Separate cloud control-plane audit from product-level user activity
Cloud provider logs show actions against cloud resources; they usually do not explain every action a SaaS user took inside your product. Keep application security events such as tenant changes, exports, role grants and account recovery in the application audit system, with tenant scope and privacy controls. Correlate both sources with timestamps and request IDs when investigating an incident.
| Account or project | Events enabled and gaps | Central destination and retention | Detection rule and test | Owner and evidence |
|---|---|---|---|---|
| Production identity and access | ||||
| Network and public exposure | ||||
| Sensitive data access |
How do you protect and retain cloud audit logs?
Route important records to a separate, restricted destination
Use a central security or log-archive account, project or subscription where appropriate. Separate the permission to produce logs from the permission to read, change retention or delete them. AWS recommends a dedicated, centralized S3 destination for CloudTrail records; Google Cloud and Azure provide their own organization-level routing and export options.
Enable integrity controls and alert if collection stops
Turn on provider-supported integrity validation or tamper-resistant storage where available. Monitor for disabled trails, changed sinks, missing regions, failed exports and unexpected retention changes. A log destination that silently stops receiving events can create the same investigative gap as a log that was never enabled.
Set retention by investigation and legal need, then manage cost
Choose hot-search and archive periods from incident response, contractual and legal requirements; document who approved them. Azure activity logs are retained for 90 days by default and need export for longer retention; provider defaults differ, so verify current service limits. Data-access logs can be high volume and chargeable, so scope them to the services and events that matter and budget for the destination.
How do teams turn cloud audit logs into useful detections?
Write alerts for risky changes that someone can investigate
Start with events such as a new administrator, disabled logging, public database exposure, a changed trust policy, unusual key use or access from an unexpected environment. Include the affected resource, actor, time, change and response owner. Avoid flooding on-call staff with alerts that have no action or context.
Test detections using a safe, known event
Generate or locate a controlled test event, confirm it reaches the central destination, verify the query and alert, and make sure the on-call person can retrieve supporting records. Test a denied action as well as a successful change. Record expected delivery delay and what to do if the signal is absent.
Protect personal and security-sensitive information in logs
Restrict log access to people who need it, use redaction or field-level access where supported, and avoid recording request bodies or secrets without a defined investigation need. Treat logs as sensitive data, preserve them during incident response and review access to the archive itself.
Cloud audit logging FAQs
Are cloud audit logs enabled for every action by default?
No. Provider coverage and defaults differ by service and event type. Some control-plane logs are always written, while data access may need explicit enablement and incur cost. Inventory the relevant services and test the actual records rather than assuming the dashboard contains a complete history.
Are cloud audit logs the same as SaaS application audit logs?
No. Cloud audit logs describe activity in the provider account or resource. Application audit logs should capture product actions such as a user exporting data, changing a tenant role or recovering an account. Use both for a complete investigation and enforce tenant access in the application.
How long should a SaaS company keep cloud audit logs?
There is no single retention period for every service. Set a documented period that supports incident investigation and applicable legal or contractual duties, then verify provider defaults, storage cost, deletion rules and archive retrieval time. Keep the decision and owner reviewable.
Does collecting logs automatically detect an attack?
No. Collection creates evidence; detection requires useful queries or rules, alert delivery, an owner and a practiced response. Test the whole path from event generation to investigation, including missing or delayed logs.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- Security Best Practices in AWS CloudTrailAmazon Web Services
- Cloud Audit Logs OverviewGoogle Cloud
- Best Practices for Cloud Audit LogsGoogle Cloud
- Activity Log in Azure MonitorMicrosoft Learn
- Create an Activity Log, Service Health, or Resource Health Alert RuleMicrosoft Learn