Cloud audit logging for SOC 2 and ISO
Logs are the evidence behind most cloud controls. An auditor needs them for the whole audit period, kept somewhere an administrator cannot quietly delete them. Retention cannot be applied backwards, so set it before the window opens.
For a cloud audit, log every administrative action across every account and region, log access to customer data on the services that hold it, keep those logs for at least the audit period plus three months, and store them in a separate account or project that production administrators cannot modify. That is the whole requirement. The provider-specific settings follow.
| Provider | Log | Default | What to set for an audit |
|---|---|---|---|
| AWS | CloudTrail management events | 90 days in Event history, no trail | Organization trail, all regions, log file validation, to a log archive account bucket with object lock |
| AWS | CloudTrail data events (S3, Lambda) | Off | On for buckets holding customer data |
| Azure | Activity Log | 90 days | Diagnostic setting to Log Analytics or storage, 365 days or more |
| Azure | Entra ID sign-in and audit logs | 30 days with P1/P2, 7 days free | Diagnostic setting to the same destination |
| Google Cloud | Admin Activity audit logs | On, 400 days | Aggregated sink to a locked bucket if you need longer or central storage |
| Google Cloud | Data Access audit logs | Off for most services, 30 days when on | On for data services, routed to the same sink |
How long should cloud logs be kept for an audit?
Keep logs for the length of the audit period plus the time until fieldwork ends: around fifteen months for a twelve-month SOC 2 Type 2. ISO 27001 does not set a number; your own policy does, and the certification body tests against it. PCI DSS v4.0.1 requires twelve months with three immediately available. Many companies keep a year in hot storage and a longer tail in cheaper archive storage.
Protecting logs from tampering
An auditor will ask whether the people whose actions are logged could delete the logs. The answer that passes is no, for structural reasons.
- Separate account or project. Logs land in a log archive account on AWS, a dedicated subscription on Azure, or a logging project on Google Cloud, with access limited to security staff.
- Immutability. S3 Object Lock in compliance mode, Azure immutable blob storage, or Google Cloud bucket lock with a retention policy.
- Integrity validation. CloudTrail log file validation produces signed digest files. Keep it on.
- Guardrails. An SCP or policy that denies stopping the trail or deleting the diagnostic setting.
Logs nobody reads
SOC 2 CC7.2 and ISO 27001 control 8.15 and 8.16 expect logs to be monitored, not just kept. For a small company that means alerts on a short list of events and a record that someone acted on them.
| Event | Why |
|---|---|
| Root or global admin sign-in | Should almost never happen |
| Audit logging stopped or changed | First thing an attacker does |
| MFA disabled or policy changed | Weakens every other control |
| New admin role assignment outside the process | Privilege escalation |
| Storage made public | Most common cause of cloud data exposure |
| Security group or firewall opened to the internet on admin ports | Direct exposure |
| High severity threat detection finding | GuardDuty, Defender or SCC flagged something |
Route alerts to a channel with an owner and keep the triage history. That history is the evidence for CC7.
Application logs
Cloud audit logs cover the control plane. Your application's own logs, particularly authentication events and administrative actions inside your product, cover the part customers care about. Log them with user, action, time and source, keep them as long as the cloud logs, and avoid writing personal information into log lines you did not intend to keep.
Is CloudTrail on by default?
CloudTrail Event history records management events for 90 days in each account without configuration. That is not enough for an audit: it is per region, short, and not protected. Create an organization trail covering all regions, delivered to a separate log archive account.
Do I need a SIEM for SOC 2?
No. You need logs kept, protected and monitored for important events. The provider's native alerting or a modest log platform covers that for most small companies. A SIEM becomes worth it when the volume of sources and alerts outgrows people looking at them directly.
Should logs stay in a Canadian region?
If the logs contain personal information and your customers require Canadian residency, yes. Application logs often contain email addresses and IP addresses. Keep the log archive in the same Canadian region as the data it describes.
Need logging set up before your window opens?
Firms in the network configure trails, sinks and retention in a week or two.
Get matched