The organisation that owns the storage should control retention, access, and downstream use of the logs through its own cloud governance model. That means applying IAM policies, retention rules, and archive controls in the destination environment, then deciding whether to route the data into analytics or SIEM tools. Central ownership improves accountability and consistency.
Who should own log retention and access once logs land in cloud storage?
Once logs are streamed into cloud storage for compliance, control should sit with the organisation that owns the destination environment, because that is where the retention policy, access model, and archive behaviour are enforced. The source system may generate the records, but the storage owner governs who can read, alter, delete, export, or chain the data into downstream tools. That separation matters because compliance evidence is only as trustworthy as the controls protecting the archive.
For log stores, ownership is not just administrative convenience. It determines whether retention can be enforced consistently, whether privileged access can be audited, and whether legal hold or deletion requests can be handled without breaking the evidence chain. In NIST Cybersecurity Framework 2.0 terms, the organisation responsible for the asset must also define the protection and recovery expectations around it. In practice, many teams discover that log custody was never clearly assigned only after retention disputes or access reviews expose gaps in the archive model.
How cloud log custody works in practice
The practical rule is simple: the party that controls the cloud storage account, bucket, workspace, or archive tier should control retention and access through that platform’s native governance controls. That usually means setting immutable or time-bound retention rules, narrowing read permissions to a small operational group, and separating routine investigation access from administrative rights. If logs are being preserved for compliance, the destination should be treated as a governed evidence store, not as a convenience sink for telemetry.
This model works because it aligns responsibility with enforcement. The source system can forward events, but once the data is copied into cloud storage, the storage owner decides how long it stays, who can retrieve it, and whether it can be re-used for analytics or sent to a SIEM. If the storage is managed by a third party, the contract and operating model still need to make ownership explicit, because “we sent it there” is not the same as “we control it there.”
- Retention should be set in the destination environment, not left to the source emitter.
- Access should be limited to the smallest team that needs administrative or forensic use.
- Deletion, archive, and restore actions should be logged separately from the log data itself.
- Downstream consumption should be approved deliberately, especially when analytics tooling expands the reader set.
Where teams go wrong is assuming the pipeline that produced the logs also governs the stored copy. That breaks down when retention periods differ, when multiple business units need the same archive, or when compliance evidence must survive source-system changes.
Where custody gets messy: shared services, legal holds, and analytics copies
Tighter log governance often increases operational overhead, requiring organisations to balance evidentiary integrity against analyst convenience. That tradeoff becomes visible when multiple teams want different retention periods, or when a legal or regulatory hold overrides routine deletion. The answer is not to hand control back to the source system, but to define which function owns policy decisions and which functions are only consumers of the stored records.
There is also a practical distinction between storage custody and investigative access. Security operations may need broad search capability in a SIEM, while compliance or legal teams may need controlled read-only access to the archive. Those are different use cases, and they should not be collapsed into one flat permission set. If the logs are replicated into multiple tools, the destination with the broadest access becomes the effective control point, so that environment needs the strongest governance.
Consensus is strong on central ownership of the retained copy, but organisations differ on how much control can safely be delegated to platform teams versus compliance owners. The safest pattern is to keep policy authority with the data owner or governance function, while delegating day-to-day administration to the platform team under documented approval rules. That preserves accountability without forcing every operational action through manual review.
For a practical reference point, the storage owner should be able to show who can change retention, who can access archived logs, and how those permissions are reviewed over time. In cloud environments, the first failure usually appears as an access gap or an over-retained archive, not as a missing log line.
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 CIS Controls v8 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-1 — Cybersecurity Supply Chain Risk Management | Cloud log custody depends on third-party and platform governance boundaries. |
| Recommendation — Define cloud log custody responsibilities and contractually bind retention and access controls. | ||
| CIS Controls v8 | 6.3 — Access Management | Access to retained logs must be tightly limited and reviewed in the destination store. |
| 4.1 — Establish and Maintain an Inventory of Enterprise Assets | You need to know where the retained log copy lives to govern it consistently. | |
| Recommendation — Restrict archive access to approved roles and review permissions regularly. Inventory every log repository and assign an accountable owner for each store. | ||
| ISO/IEC 42001:2023 | A.5 — Policies for AI System Use and Governance | Not directly applicable to logs as such; omitted from selection. |
| Recommendation — Omit AI governance mappings unless logs are part of an AI governance workflow. | ||
Practitioner Guidance
What to prioritise: Assign a single policy owner for the retained log copy, then separate that from routine platform administration. If the organisation cannot name that owner, it will struggle to prove custody or defend access decisions during audit or incident review.
What to verify: Check that retention, legal hold, read access, and delete rights are all enforced in the destination environment, and that those permissions are reviewed on a schedule. The key test is whether an administrator of the source system can alter the stored archive without going through the destination controls.
Decision rule: If the logs are being used as compliance evidence, treat the cloud storage account or archive tier as the control boundary. If they are only transient operational telemetry, the access model can be narrower, but the retention obligation still needs a documented owner.
Practitioner takeaway: The most defensible model is to govern the retained log copy where it resides, because custody, retention, and access control only matter if the destination owner can actually enforce them.
Related resources from NHI Mgmt Group
- Why do cloud procurement applications create compliance gaps for access control programs?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities for compliance?
- How should security teams run access reviews for non-human identities?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
