Safeguard 8.10: Retain Audit Logs

To meet the safeguard 8.10: retain audit logs requirement, you must define retention periods, centralize and protect security-relevant logs, and prove you can retrieve them for investigations and audits. Operationalize it by inventorying log sources, setting retention by data class and system criticality, enforcing immutable storage controls, and running recurring evidence captures. ¹

Key takeaways:

• Define and document audit-log retention requirements, then apply them consistently across in-scope systems. ¹
• Store logs centrally with access controls and tamper-resistant/immutable protections appropriate to your risk. ¹
• Prove operation with repeatable evidence: retention settings, storage controls, and successful retrieval tests. ¹

Retaining audit logs is a “make-or-break” control during incident response and assessment work because you either have the data or you do not. Safeguard 8.10 focuses on ensuring audit logs persist long enough, remain trustworthy, and are accessible when an investigation, legal hold, customer inquiry, or auditor request lands. ¹

For most organizations, the gap is rarely “we don’t log anything.” The gap is inconsistent retention (some systems keep days, others months), weak protection (admins can delete or modify), and poor retrieval (logs exist but can’t be found fast, or the query path is unclear). Those issues become operational failures during containment and root-cause analysis, and they create audit failures because you cannot demonstrate control operation with durable artifacts.

This page turns Safeguard 8.10 into an implementable requirement: who needs to follow it, what decisions you must make, what technical configurations typically satisfy it, what evidence to retain, and what auditors ask when they test it. It also includes a practical execution plan you can hand to IT, Security Operations, and GRC without rewriting.

Regulatory text

Excerpt (provided): “CIS Controls v8 safeguard 8.10 implementation expectation (Retain Audit Logs).” ¹

Operator interpretation: You must retain audit logs for a defined period and in a manner that supports security monitoring, investigations, and assessment needs. This implies (a) you know which logs are “audit logs” for your environment, (b) you have a retention standard, (c) retention is enforced technically, and (d) you can produce logs on request. ¹

What an assessor is really testing:

• Do you have a documented retention requirement for audit logs?
• Is it applied consistently to in-scope platforms (endpoints, servers, identity, cloud, network, critical applications)?
• Are logs protected against tampering and unauthorized deletion?
• Can you retrieve logs within a reasonable operational window when asked? ¹

Plain-English requirement (what it means)

The safeguard 8.10: retain audit logs requirement means: keep the security-relevant record of activity long enough, and protect it well enough, that you can reconstruct what happened. That includes authentication events, privilege changes, administrative actions, security tool alerts, and key application/system events.

You are trying to prevent three common failure modes:

1. Logs roll off before you detect the incident.
2. Logs are altered or deleted by an attacker or an insider.
3. Logs exist but you cannot locate, access, or query them under pressure.

Who it applies to

Entity scope: Enterprises and technology organizations implementing CIS Controls v8. ¹

Operational scope (what systems are typically in-scope):

• Identity and access: SSO/IdP, directory services, privileged access tooling
• Core infrastructure: servers (on-prem and cloud), endpoints, container platforms
• Network and security stack: firewalls, VPN, WAF, IDS/IPS, EDR, email security
• Cloud control plane: cloud audit logs, API activity, configuration changes
• Business-critical applications and data platforms where admin/user activity matters

Third-party consideration: If a third party hosts systems or provides managed services (MSSP, SaaS, cloud), you still need contractual and technical assurance that the audit logs exist, are retained, and are retrievable. Treat log retention as a third-party due diligence checkpoint and a contract requirement.

What you actually need to do (step-by-step)

Step 1: Define “audit logs” for your environment

Create a scoped list of log categories that qualify as audit logs. Keep it short and defensible. Examples:

• Authentication and authorization events (success/failure, MFA changes)
• Privilege and role changes
• Administrative actions (policy changes, security control disablement)
• System security events (EDR alerts, malware detections, blocked traffic)
• Cloud API/control-plane events and key configuration changes

Deliverable: “Audit Log Scope” section in your logging standard, plus a log-source inventory.

Step 2: Set retention requirements (by class, not by guesswork)

Document retention periods by system criticality and data sensitivity. CIS does not provide a one-size number in the provided excerpt, so your job is to set a requirement that matches your risk and any overlapping obligations (contracts, legal holds, sector rules), then apply it consistently. ¹

A workable pattern:

• Baseline retention for all in-scope audit logs
• Extended retention for identity, privileged access, cloud control plane, and crown-jewel applications
• Exception process for systems that cannot meet retention due to technical constraints (with compensating controls)

Deliverable: Logging & Audit Log Retention Standard (policy-level) plus a runbook (procedure-level) that lists where settings live.

Step 3: Centralize storage and normalize collection

Push audit logs off the originating system to reduce the chance of deletion or local rollover. Common approaches:

• SIEM or log analytics platform for searchable retention
• Object storage with lifecycle policies for longer-term retention
• Security data lake (if that’s your model)

Focus on a repeatable ingestion path: endpoints, servers, identity provider, cloud audit, and network/security devices.

Deliverable: Architecture diagram (one page) showing log sources → collectors/forwarders → central store(s).

Step 4: Protect log integrity and access

Implement controls that make logs trustworthy:

• Role-based access control to view/export logs
• Separation of duties (admins of source systems should not be able to erase central copies)
• Immutable or tamper-resistant storage where feasible (for high-risk logs)
• Alerts for logging pipeline failures (collection stopped, sudden drop, forwarding errors)

Deliverable: Access control list/export of roles, plus configuration evidence for immutability/tamper resistance where you apply it.

Step 5: Implement lifecycle management (retention + disposal)

Retention is not only “keep.” It is also “expire appropriately.” Use:

• SIEM index retention settings
• Storage lifecycle policies (transition to cheaper storage, then delete)
• Legal hold process that overrides deletion when needed (handled through Legal/Privacy procedures)

Deliverable: Screenshots/exports of retention and lifecycle configurations, and the legal hold trigger procedure.

Step 6: Prove retrievability with scheduled tests

Run a recurring retrieval test: pick a defined time range and system, retrieve logs, and show they contain expected events (e.g., a known admin login, role change, or EDR alert). Capture evidence.

This is where teams fail audits: they have retention set, but no one has verified the query path or permissions recently.

Deliverable: Retrieval test record (ticket + query + exported sample + reviewer sign-off).

Step 7: Operationalize in GRC (mapping + recurring evidence capture)

Map Safeguard 8.10 to a documented control, an owner, a frequency for evidence collection, and an exception workflow. The minimum viable recommended control from the provided guidance is to “map 8.10 to documented control operation and recurring evidence capture.” ¹

How Daydream fits naturally: Daydream is useful here as the system of record to (a) map 8.10 to your logging standard and technical procedures, (b) schedule recurring evidence requests from Security/IT, and (c) track exceptions and remediation to closure without losing the audit trail.

Required evidence and artifacts to retain

Keep evidence that demonstrates design and operation:

Design evidence (static, updated on change):

• Logging & Audit Log Retention Standard (approved, versioned)
• Audit log scope definition and in-scope system list
• Logging architecture diagram/data flow
• Access control design (roles/groups that can read/export/delete)
• Exception and compensating-control procedure

Operational evidence (recurring):

• SIEM/index retention settings export or screenshots
• Storage lifecycle policy configs and audit of policy enforcement
• Sample log ingestion health reports (forwarder status, dropped events)
• Retrieval test artifacts (ticket, query, exported sample, approval)
• Access review evidence for log admin roles (who has rights, review outcome)

Common exam/audit questions and hangups

Expect these, and pre-package answers:

• “Show me your retention standard and where it is enforced technically.”
• “Which systems are in scope for audit logs? How do you know you didn’t miss cloud control plane logs or the IdP?”
• “Who can delete logs? Can a domain admin erase evidence?”
• “Demonstrate retrieval: pull logs from a specific date for a specific user/system.”
• “How do you detect failures in log forwarding or sudden gaps?”

Hangups that trigger follow-ups:

• Retention defined only in a policy, not implemented in SIEM/storage settings
• Relying on default retention
• Gaps for SaaS logs (no collection, or only short portal retention)
• No evidence cadence (you “could” retrieve, but you haven’t recently)

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	What to do instead
Treating retention as a SIEM checkbox	SIEM retention may not cover long-term or immutable needs	Pair SIEM search retention with longer-term storage lifecycle policies
Logging only on endpoints/servers	Identity and cloud control plane logs are often the real root cause trail	Make IdP + cloud audit logs first-class sources
Too many people can administer logging	Increases tampering risk and audit scrutiny	Enforce least privilege and separate duties for log administration
No pipeline health monitoring	You “retain” nothing if ingestion is broken	Alert on forwarding failures and volume anomalies
No retrieval drills	Retrieval fails during an incident	Schedule retrieval tests and keep proof

Risk implications (why operators care)

If you cannot retain and retrieve audit logs, incident response becomes guesswork. That increases the chance you miss persistence mechanisms, cannot confirm scope, and cannot support post-incident reporting with defensible facts. From a governance perspective, weak log retention also undermines your ability to validate other controls (access reviews, privileged activity monitoring, change management) because the evidence trail is incomplete. ¹

Practical execution plan (30/60/90-day style, without fixed calendar promises)

First 30 days: Stabilize and define

• Name an owner (Security Operations or IT Security) and a GRC control owner.
• Publish a logging and retention standard that defines audit logs, minimum retention expectations, and the exception process. ¹
• Inventory current log sources and retention settings for: IdP, cloud audit logs, EDR, key servers, firewalls/VPN.
• Identify high-risk gaps: no centralization, short retention, shared admin accounts, no retrieval path.

Days 31–60: Enforce and protect

• Implement/extend central collection for missing critical sources (start with IdP and cloud control plane).
• Apply retention and lifecycle policies in the SIEM and long-term storage.
• Lock down log admin permissions; document access groups and add an access review step.
• Add monitoring for ingestion failures and material drops in event volume.

Days 61–90: Prove operation and make it auditable

• Run recurring retrieval tests and store evidence in your GRC repository.
• Formalize metrics that are operational, not vanity: ingestion health, retrieval success, exception counts.
• Complete the mapping of Safeguard 8.10 to control language, owners, systems, and evidence cadence. ¹
• If you use Daydream, set up an evidence workflow so each cycle produces a clean audit packet without manual chasing.

Frequently Asked Questions

What counts as an “audit log” for Safeguard 8.10?

Treat audit logs as records that reconstruct security-relevant activity: authentication, privilege changes, admin actions, security alerts, and key system/application events. Write this scope down and tie it to named log sources so auditors can test it. ¹

Do we need a SIEM to meet the safeguard 8.10: retain audit logs requirement?

No specific tool is required by the provided CIS excerpt. You do need a central, controlled retention mechanism and proof you can retrieve logs, whether that is a SIEM, managed log platform, or storage-backed approach with searchable access. ¹

How do we handle SaaS platforms where we can’t change retention settings?

Document what the SaaS retains natively, then export or stream logs to your controlled storage if native retention is insufficient for your standard. If you cannot export, open an exception with compensating controls and a remediation plan.

What evidence is most persuasive in an audit?

Configuration exports/screenshots showing retention and lifecycle settings, plus a recent retrieval test that demonstrates you can pull a defined time window of logs on request. Pair that with an approved standard and a clear in-scope system list. ¹

Who should own log retention: Security, IT, or GRC?

Security/IT should own technical operation (collection, storage, access controls), and GRC should own the requirement mapping, evidence cadence, and exception governance. Assign both roles explicitly so the control doesn’t degrade between audits.

How do we operationalize recurring evidence capture without creating busywork?

Standardize an “audit packet” checklist (retention settings export, access list, ingestion health, retrieval test) and collect it on a fixed cadence. A GRC workflow tool like Daydream can automate requests, store artifacts, and track exceptions so evidence is consistent cycle to cycle. ¹

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8