The provider is accountable for making retention configurable, storage tamper-evident, and access dependable. Customers have different compliance and data-minimization requirements, so a single fixed retention period is rarely defensible. The service should let each organization set an appropriate window and keep logs available when they are needed most, including during active incidents.
Why This Matters for Security Teams
audit logs are only useful if they survive the exact moment they are needed: an investigation, a regulator request, or a dispute over user or system activity. Accountability is therefore not just about who stores the logs, but who ensures retention settings, availability, integrity, and access paths are reliable under pressure. The provider typically owns the platform controls, while the customer owns policy decisions such as retention duration and review requirements. That division should be explicit in contracts and operating procedures, especially where logs may support incident response, legal hold, or compliance evidence.
This is a common control gap in shared-responsibility environments. Security teams often assume logging is “enabled” if events appear in a console, but that does not prove the logs are retained long enough, protected against tampering, or retrievable during an outage. Guidance from the NIST Cybersecurity Framework 2.0 reinforces that logging must support detection, response, and recovery, not merely collection. In practice, many security teams encounter missing or inaccessible logs only after an incident has already limited their ability to reconstruct what happened.
How It Works in Practice
Effective audit-log accountability starts with separating policy from platform duties. The customer defines what must be retained, for how long, and under what legal or operational constraints. The provider must make that choice enforceable through configuration, durable storage, monitored access, and export options. If logs are part of a SaaS, cloud, or managed security service, the provider should also state how availability is preserved during incident conditions, such as service degradation, account suspension, or regional disruption.
Practitioners should look for a few concrete capabilities:
- Configurable retention periods that align with legal, contractual, and investigative needs.
- Immutable or tamper-evident storage so event history cannot be quietly altered.
- Role-based access and strong authentication for log review and export.
- Search, filtering, and export functions that remain usable during active investigations.
- Clear evidence of backups, redundancy, and recovery objectives for log data.
The control intent maps closely to NIST SP 800-53 Rev 5 Security and Privacy Controls, especially controls around audit logging, access enforcement, and information system monitoring. It also aligns with CIS Controls v8, which emphasize logging, monitoring, and secure configuration as part of continuous defence. For operational teams, the practical test is simple: if an analyst cannot retrieve a needed log during a live event, then retention exists in theory but not in practice. These controls tend to break down when logs are centralized in a single admin account or when retention settings are fixed by the provider and cannot be adjusted per tenant because customer obligations diverge.
Common Variations and Edge Cases
Tighter retention and stronger immutability often increase storage cost, indexing overhead, and administrative complexity, requiring organisations to balance evidential value against operational burden. Best practice is evolving here, because there is no universal standard for the “right” retention period across every sector or jurisdiction. Some customers need short retention for data-minimization reasons, while others need long retention for fraud, security, or regulated investigations.
Edge cases matter. Multi-tenant services may need tenant-specific retention controls so one customer’s legal hold does not expose another’s data. In highly regulated environments, log access may need to be split between operations, security, and compliance to avoid excessive privilege. Where logs contain personal data, teams should also define redaction, export, and deletion procedures so retention does not conflict with privacy obligations. Availability expectations should be written into service commitments, including what happens during outages, account compromises, or tenant suspension. The provider should be accountable for making logs dependable, but the customer remains accountable for choosing and validating the policy that fits its risk and regulatory profile.
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, NIST SP 800-53 Rev 5 and CIS-Controls-v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.AE-3 | Audit logs support anomaly detection and incident reconstruction. |
| NIST SP 800-53 Rev 5 | AU-11 | Retention policy directly governs how long audit records are preserved. |
| CIS-Controls-v8 | 8 | Logging and monitoring controls underpin reliable investigation readiness. |
Centralize logs, secure access, and test that records are usable when incidents occur.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
