Start with logs that can prove identity-bound actions, data access, and change history, then retain them long enough to support triage and forensics. CloudTrail, object access logs, and database audit logs are usually higher value than generic network telemetry when the main question is what a user or service actually did.
How to choose cloud logs that earn their storage cost
The right filter is business and security value, not raw volume. Keep logs that can answer who did what, against which resource, and when the change happened, because those records support incident triage, access review, and forensic reconstruction. Logs that only describe traffic volume or routine health noise usually have lower evidentiary value unless they are tied to a specific detection use case.
Start by ranking each log source against three questions: can it prove identity-bound action, can it show data access or privilege use, and can it establish change history. If a log source does none of those, it may still be useful for observability, but it is harder to justify as a long-retention security log. That is why CloudTrail-style management events, object access logs, and database audit trails usually sit above generic network telemetry.
Retention should follow the longest plausible investigation window, not the shortest operational convenience. If your response team needs to reconstruct a suspicious action after the fact, a log that rolls off before an incident is detected has little value, even if it is detailed. In practice, teams often separate “high-value security evidence” from “short-lived troubleshooting telemetry” so the first class gets stricter retention, integrity protection, and access controls.
Which log types usually matter most?
Control-plane and data-plane records are usually the first tier. Cloud control-plane logs show account changes, policy changes, and administrative actions; object and storage access logs show reads, writes, deletes, and permission-sensitive access; database audit logs show queries, privilege changes, and suspicious administrative activity. Those sources tend to answer the questions investigators actually ask after an alert or audit finding.
Workload and platform telemetry can still matter, but mainly when it helps confirm execution path, lateral movement, or abuse of a service. Network telemetry is often lower-fidelity for proving intent or accountability because it may show that traffic happened without showing which authenticated principal initiated it. If the security question is “what happened to the asset,” not just “what moved across the wire,” then logs closer to the control point usually deliver more value.
Exception handling matters. In regulated environments, in shared cloud accounts, or where multiple teams use the same platform, logs that preserve administrative attribution and change history become more important because accountability is otherwise easy to lose. For a practical logging reference point, many teams anchor retention and review to NIST Cybersecurity Framework 2.0 because it ties logging to detect, respond, and recover outcomes rather than treating it as a standalone storage problem.
What makes a log worth keeping for longer?
A log source is worth longer retention when it is durable evidence, not just operational noise. Strong candidates typically have three properties: they are tied to an authenticated actor or trusted service, they record an action that changes state or exposes data, and they are specific enough to support investigation without needing many other sources to explain them. When those three align, the log becomes a primary record, not a convenience record.
Longer retention is also justified when the log supports control validation. Access reviews, incident reconstruction, policy enforcement checks, and post-change verification all depend on being able to look backward across time. If your team cannot prove a change happened or who initiated it, you may have a governance gap as much as a monitoring gap.
That logic matches common control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially the audit and access-control families. It also fits the operational pattern described by FIRST, where incident response depends on enough evidence to reconstruct the sequence of events and contain the blast radius.
Risk and Threat Considerations
Keeping the wrong logs is a cost issue, but keeping too few of the right logs is a security issue. If you cannot retain the records that show identity, access, and change history, attackers and insiders can blend into ordinary activity, and defenders lose the evidence needed to prove scope, sequence, and impact.
Failure mechanism: Short retention windows, incomplete source coverage, or logs that omit identity and action context break the chain between an actor and a consequential change. That leaves blind spots in triage, weakens forensic timelines, and makes it harder to distinguish malicious activity from routine administration.
Impact: The result is slower containment, weaker attribution, and a higher chance that a real compromise is under-scoped or misclassified. In the worst case, the organisation keeps plenty of telemetry but still cannot answer the only question that matters after an incident: who did what to which data or system.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-09 — External Service Provider Activities are Monitored | Cloud log retention supports monitoring and investigation of provider-side and shared-responsibility activity. |
| DE.CM-01 — Networks and Network Services are Monitored to Find Potentially Adverse Events | Network telemetry is part of the log selection trade-off for security monitoring. | |
| Recommendation — Retain logs that let you detect and investigate provider or platform activity affecting your environment. Use network monitoring as supporting telemetry, but keep higher-value evidence logs for accountability. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Log selection depends on which events are important enough to record and retain. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Logs are worth keeping when they support review and incident analysis. | |
| AU-11 — Audit Record Retention | The question is fundamentally about which logs justify longer retention. | |
| Recommendation — Define and retain event types that support investigation, accountability, and compliance. Prioritise logs that analysts can review to reconstruct incidents and validate access. Set retention periods by investigative and evidentiary value, not by storage convenience. | ||
Practitioner Guidance
What to prioritise: Keep the logs that bind identity to action first, then preserve the logs that show sensitive data access and privileged change. If a source cannot support triage, forensic reconstruction, or access review, treat it as a lower-tier operational log and give it shorter retention.
What to verify: Check whether each retained source includes actor attribution, target resource, action type, timestamp, and enough context to correlate with other records. If one of those fields is missing, the log may still be useful, but it is not strong evidence by itself.
Practitioner takeaway: The best retention policy is evidence-led, not vendor-led, and the logs that most often survive pruning are the ones that can stand on their own in an investigation.
Related resources from NHI Mgmt Group
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities in cloud environments?
- How should security teams decide which integrations are worth keeping in the SOC?
- How should security teams decide when technical debt in cloud platforms is becoming a security risk worth fixing?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org