Accountability sits with the organisation operating the cloud estate, not the provider. Providers supply logs such as CloudTrail, Activity Log, or Cloud Audit Logs, but customers decide whether those logs are enabled, retained, and exported. Security and platform teams should assign ownership for log coverage at the account, subscription, or project level, because missing visibility is a customer-side control gap.
Why This Matters for Security Teams
Incomplete cloud logging is not just a visibility issue. It affects incident detection, forensic reconstruction, compliance evidence, and the ability to prove that administrative actions were authorised. When logging is disabled by default or not exported into a durable store, the organisation can lose the only reliable record of who changed what, when, and from where. That weakens both security operations and accountability.
This is why the question sits squarely with control ownership, not provider branding. Cloud services often expose logs as configurable customer-side controls, which means the operating team must decide whether to activate them, retain them, and protect them from tampering. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls treats audit logging as a governed control objective, not an optional feature. The same principle appears in cloud security baseline work from CISA and other public guidance: the provider may supply telemetry, but the customer owns the risk if it is not collected or preserved.
In practice, many security teams encounter the logging gap only after an incident has already occurred, rather than through intentional control testing.
How It Works in Practice
Cloud logging responsibility usually splits across three layers: the provider, the platform team, and the workload owner. The provider supplies the logging service, such as control-plane audit events, configuration changes, and identity actions. The platform or cloud operations team configures account-level, subscription-level, or project-level defaults. The workload or application owner may need to enable service-specific logs, application logs, or data access logging where the platform does not cover everything.
Operationally, the first question is whether the logging service is enabled at the right scope. The second is whether logs are retained long enough for detection, legal hold, and investigation. The third is whether logs are exported to a separate account or SIEM so that an attacker with cloud admin rights cannot simply delete evidence. That is why cloud logging should be treated as part of the broader control stack alongside identity governance, privileged access, and monitoring.
- Define ownership for each cloud account, subscription, or project.
- Set default-on logging through policy, not manual setup.
- Export logs to an immutable or separately governed destination.
- Monitor for disabled sinks, shortened retention, or excluded services.
- Test that alerting still works when a log source fails.
For teams aligning to detection engineering, the MITRE ATT&CK technique Impair Defenses: Disable or Modify Tools is a useful lens because log suppression is often part of an intrusion path. The same applies to cloud-native logging guidance from the Cloud Security Alliance Cloud Controls Matrix, which reinforces that auditability must be designed into the control plane. These controls tend to break down when organisations use multiple cloud tenants with inconsistent policy inheritance because logging defaults and retention settings drift across estates.
Common Variations and Edge Cases
Tighter logging governance often increases cost, storage load, and operational friction, so organisations have to balance visibility against retention and performance constraints. That tradeoff becomes more visible in high-volume environments, but the security downside of under-logging is usually worse than the cost of keeping the evidence.
There is no universal standard for every service-level log type yet, especially for managed platforms where some telemetry is exposed only if the customer enables it at creation time. Best practice is evolving toward policy-as-code, central log pipelines, and continuous compliance checks that flag missing audit sources before deployment. In highly regulated environments, this expectation is stronger, particularly where secure-by-design principles require logging to be part of the default control posture rather than an afterthought.
Identity also matters here. If cloud logging is incomplete, it becomes harder to distinguish benign admin activity from misuse of privileged or non-human identities. That is especially important where automation, service accounts, and federated access are heavily used, because missing audit trails can obscure who or what actually executed a change.
The biggest edge case is shared responsibility ambiguity in managed services: if a provider exposes only partial telemetry, the organisation still owns the residual risk and must document compensating controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Logging and monitoring coverage are core continuous monitoring outcomes. |
| MITRE ATT&CK | T1562.001 | Attackers often disable logs or tools to reduce detection. |
| NIST SP 800-53 Rev 5 | AU-2 | Event logging requirements map directly to audit event capture and review. |
| NIST Zero Trust (SP 800-207) | AU | Zero Trust depends on trustworthy telemetry to validate access decisions. |
Confirm log sources are active and monitored across the estate, then alert on missing telemetry.
