What CIS Safeguard 8.10 audit log retention requires
Safeguard 8.10 requires audit logs across enterprise assets to be retained for at least 90 days, and it applies at Implementation Groups 2 and 3 but not IG1. If an assessor, customer or internal audit asks for proof of retention, the question is less about whether logs exist and more about whether the oldest relevant entry is still there. The risk this Safeguard addresses is simple: an intrusion often goes unnoticed for weeks, and if the logs that would show it were overwritten or deleted first, the investigation has nothing to work from. A fixed 90-day floor gives every team the same starting point, which is why it is easy to state in a policy and a contract.
Proving it is harder than stating it. Retention is a setting that lives in several places: each source system, any local buffer, the aggregation platform and any archive tier. An assessor will want to see the configured value and a sample of logs old enough to test it, not a policy sentence. Measurement under the CIS Controls Assessment Specification is framed around the share of log aggregation software configured to keep logs for 90 days or more, which is why Safeguard 8.9 (centralized audit logs) is a prerequisite. Without a central platform, there is no single place to read the retention setting or confirm that older entries still exist.
The practical step is to export the retention configuration from the aggregation platform, confirm that the setting applies to every log source in scope, and pull a dated query for an event roughly 90 days old. Confirm with your auditor or assessor exactly how they will sample sources and which configuration exports they accept. For self-hosted open-source platforms, check the native retention and rotation settings of each source. For example, Nextcloud's admin_audit app writes to a file set by logfile_audit, so the rotation policy on that file determines whether 90 days survive on disk. Confirm the equivalent behavior for each system in your environment before you rely on it.
Which systems and tools audit log retention applies to
Safeguard 8.10 applies to audit logs from enterprise assets, and the scope you draw determines how much retention work you take on. The cards below cover the decisions that most often change the effort: which assets and Implementation Group apply, where logs are aggregated, which systems never reach the aggregator, and which logs a provider holds.
Enterprise assets in the Data context
Safeguard 8.10 sits in the Data asset class, so the retention question starts with the assets that hold or touch sensitive data, not with every device on the network. Build a list of enterprise assets that generate audit logs and tag each one by the data it handles. Assets that hold regulated or sensitive data usually need the retention period enforced first and verified with evidence. Ask your assessor whether they expect the full inventory or a risk-based subset, and document the reasoning either way.
IG2 and IG3 applicability
Safeguard 8.10 is assigned to IG2 and IG3 but not IG1, so an organization that has only adopted IG1 has no formal obligation to meet it. Confirm your Implementation Group before scoping, because the decision changes whether retention is a requirement or a recommendation. Organizations that adopt IG2 for contractual or regulatory reasons should treat the 90-day minimum as the baseline for every in-scope asset, not as an optional improvement.
Log aggregation tools in scope
The measure for Safeguard 8.10 applies to the log aggregation software from Safeguard 8.9, so the aggregator's retention settings are the primary control point. List every platform that stores audit logs, including SIEMs, log indexes and object storage buckets used for archives. Each one needs its retention configured and recorded, because a single aggregator set to a shorter window fails the measure even when source systems keep logs longer. Confirm each tool's retention setting in its configuration, not only in the design document.
Logs kept only on the source
Some systems generate audit logs but never forward them to a central platform, such as standalone appliances, legacy applications or local administrative tools. Safeguard 8.10 is measured on aggregation software, so these sources fall outside the compliance measure unless they are centralized. Decide for each one whether to forward its logs, accept a documented exception, or retire it. Local-only logs also tend to be overwritten by size limits before 90 days, so check the rotation settings on each source.
Provider-held logs
Cloud platforms, managed security services and SaaS providers may hold audit logs about your environment that you cannot configure directly. Retention for those logs depends on the contract, the service tier and the provider's default settings. Identify which provider logs you rely on for investigations, check their retention periods in writing, and export them to your own aggregator when the provider's window is shorter than 90 days or the contract does not state one. Record the result as part of your service provider review.
Retention evidence per aggregator
Each in-scope aggregator needs its own evidence that retention is set to 90 days or more, so the assessor can see the configuration rather than a policy statement. Export the retention setting or a screenshot from the platform, record the date, and store it with the audit log management process records. Repeat the check after upgrades or migrations, since default values can change between versions. A single consolidated report usually works only if it names each tool and its setting.
How an assessor tests audit log retention
This table walks through how an assessor approaches Safeguard 8.10, from the inputs that must exist before testing to the evidence requested and the findings that most often appear. Read it as a checklist of what to prepare, since the CIS specification defines what is measured but not the exact method an assessor will use.
| Test element | What the assessor looks for | Common finding or gap |
|---|---|---|
| Measure | The share of log aggregation software configured to keep audit logs for 90 days or more | Retention set on the central platform but not on every tool that feeds it |
| Prerequisite: Safeguard 4.1 | A documented secure configuration process that shows how log settings, including retention, are defined and approved | Retention values exist in tool settings but no documented baseline states the required period |
| Prerequisite: Safeguard 8.9 | A centralized audit log platform that receives logs from enterprise assets, so the retention measure has a defined population | Assets outside the aggregator, so their retention is never counted in the measure |
| Retention configuration evidence | Exports or screenshots of retention settings for each log aggregation tool, dated and tied to the system under test | Exports that show a default value without a record of who set or approved it |
| Sampled log availability | Logs from a sampled source that can still be retrieved for a date at least 90 days back | Logs present at the source but absent from the aggregator, or rotated out before the 90-day point |
| Population check | A list of log sources and the aggregator each one reports to, so the assessor can confirm the denominator | Sources added after the last inventory that were never assigned a retention setting |
| Ask your assessor | Which tools are in the denominator, which dates are sampled, and whether the sample covers both the source and the aggregator | Assumptions about method that differ from the assessor's own approach, discovered late in the audit |
How to implement 90-day audit log retention in order
This sequence turns the Safeguard 8.10 requirement into a documented, tested and repeatable retention setting across every log aggregation tool that receives audit logs from enterprise assets. Each step ends with a record an assessor can read.
Confirm the retention period in the audit log process
Start with the documented audit log management process from Safeguard 8.1, which sets logging requirements for collection, review and retention. Confirm that it states a retention period of at least 90 days for audit logs across enterprise assets, and that the policy owner has approved it. The output is the retention clause in the approved process document, with the approver's name and date. The step is done when the 90-day minimum appears in writing and someone accountable has signed it off.
Inventory every log aggregation tool in use
List each platform that receives audit logs, including the SIEM or log store from Safeguard 8.9, any secondary archive, and any tool that keeps logs from high-value assets. Record the owner, the log sources feeding it and where the data physically resides. Ask the platform team to confirm that no assets send logs to an unlisted destination, since a missed tool leaves logs outside the measurement. The output is a tool inventory that maps sources to destinations. The step is done when the inventory has been reviewed against the Safeguard 8.9 centralization records.
Set retention on each tool
For each tool in the inventory, change the retention or lifecycle setting so that stored audit logs remain available for at least 90 days. Retention is often configured in different places, such as index lifecycle policies, storage buckets, database purge jobs or local rotation settings, so check the vendor documentation for the exact control on each platform. Keep the configuration in version control where the platform supports it. The output is a per-tool configuration record showing the setting name, the value and the change reference. The step is done when every tool's record shows a value of 90 days or more.
Verify retention with a query on older data
Retention settings only prove something when old data is still there. Run a query against each tool for audit events older than 90 days, or for the oldest events the tool holds if the platform is newer than that. Confirm the results return events, not an empty set, and that the earliest timestamp matches the configured retention. For self-hosted platforms, also check that purge jobs are not deleting data sooner than the setting implies. The output is a saved query result or screenshot for each tool, with the date run and the operator. The step is done when every tool returns data at or beyond the 90-day boundary.
Document configuration and assign an owner
Write a short standard for each tool that names the owner, the retention value, the storage location, the configuration reference and the verification query used in the previous step. Link this record to the audit log management process so that a reader can trace the requirement to the setting. Confirm the owner has accepted responsibility in writing. The output is a signed retention standard with one entry per tool. The step is done when every tool has an accountable owner and the standard is stored where assessors can request it.
Set a recurring retention check
Schedule a recurring check that repeats the configuration review and the old-data query for each tool, at an interval the audit log process defines. Also review the check when a tool is upgraded, migrated or replaced, since upgrades can reset lifecycle policies or change defaults. Track any deviation as a finding with an owner and a closure date. The output is a check calendar, a check log with dated results and a change trigger list. The step is done when the first recurring check has run and its result is recorded.
Evidence that passes a retention assessment
An assessor testing Safeguard 8.10 wants proof that a retention rule exists, that each aggregation tool actually enforces it, and that old logs are still there. The six artifacts below connect those three points, and each one should be refreshed on a schedule rather than rebuilt the week before an audit.
Written retention standard
The audit log management process from Safeguard 8.1 should state the minimum retention period, which sources it covers and who approves exceptions. Check that the document names the 90-day minimum for enterprise assets and that the review date is current. Assessors compare the tool settings against this text, so a mismatch between the policy and the configuration is the first finding most teams receive. Re-confirm the standard at each scheduled review and whenever a new log source is added.
Per-tool retention configuration export
Export the retention setting from every log aggregation tool, with the export timestamp and the tool version. The assessment measures the share of aggregation software configured to keep logs for 90 days or more, so each tool needs its own line. Store exports as files rather than screenshots so the values can be compared over time. Re-export after every upgrade, since upgrades can reset or rename configuration keys.
Dated proof of aged data
A configuration setting shows intent, but assessors also look for data that has actually survived. Capture a dated query result or screenshot showing events at least 90 days old still returned by the aggregation tool. Record the query, the time range and the oldest event timestamp returned. Repeat the capture on a schedule so the evidence shows continuity, not a single moment.
Log source to tool mapping
Maintain a list that maps each enterprise asset and log source to the aggregation tool that stores its logs, as Safeguard 8.9 centralization requires. Retention can only be measured for sources the assessor can trace to a tool. Flag any source with no mapping, and review the list when new systems, cloud accounts or applications are onboarded. A stale list is the usual reason a tool appears compliant while a source is missing.
Retention change records
Keep a change record for every edit to a retention setting, including the requester, approver, date, previous value and new value. Changes that shorten retention below 90 days are the most important to catch, so tie them to a documented approval. Review the change log against the configuration exports to confirm no silent edits occurred. Ticketing system records or version-controlled configuration files usually satisfy this when they are retained themselves.
Exception register for short-retention sources
Some sources cannot meet the minimum because of storage limits, vendor constraints or legacy systems. Record each one in an exception register with the source, the actual retention, the compensating control, the owner and a review date. Assessors expect exceptions to be visible and approved, not discovered during testing. Confirm with each platform owner whether the limitation is real, and revisit the register whenever storage or the platform changes.
What audit log retention costs to meet
This table breaks down the cost components of keeping audit logs for at least 90 days under Safeguard 8.10, who is paid for each, and whether it is one-time or recurring. Read the driver column to see what pushes each cost up, and the last row for what to request in a written quote.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Log storage capacity and growth | Cloud or data center provider, or the organization's own storage team | Recurring, growing with volume | Up: log volume from IG2 sources such as DNS, URL and command-line logs. Down: tiered storage that moves older logs to cheaper media while staying retrievable for the 90-day window |
| Aggregation tool licenses or hosting | Commercial SIEM vendor, or the organization for self-hosted open-source tooling | Recurring (licenses or hosting), one-time (initial deployment) | Up: number of tools feeding the Safeguard 8.9 aggregation point and per-volume licensing. Down: self-hosted open-source aggregation within the organization's own infrastructure removes license spend, though hosting and staff time remain |
| Engineering time to configure retention | Internal platform or security engineers, or an implementation partner under a written scope | One-time, with periodic re-checks after changes | Up: many separate log sources with different retention settings, or no documented baseline from Safeguard 8.1. Down: one retention standard applied through configuration management |
| Verification of 90-day retention on each tool | Internal engineers or an implementation partner | One-time for baseline, recurring for each audit cycle | Up: number of aggregation tools in scope, since the assessment measures the share configured for 90 days or more. Down: keeping retention settings in version-controlled configuration so the check is a repeatable query |
| Retention beyond 90 days | Storage provider and tool licensing or hosting | Recurring | Up: longer retention periods set by legal, regulatory or contractual needs, and multi-region copies. Down: retain only what those obligations require and document the reason for each longer period |
| Multi-region or replicated storage | Cloud provider or data center operator | Recurring | Up: replication for resilience or data residency. Down: confirm whether the 90-day requirement is met by a single compliant store before paying for copies |
| Ongoing evidence upkeep | Internal compliance or security staff, or a retained support provider under a written scope | Recurring, each assessment cycle | Up: manual screenshots and exports. Down: scheduled exports of retention settings and storage metrics that are kept with the audit log management process |
| External review and gap assessment | Independent assessor or consultant, where the organization chooses one | Optional, one-time or periodic | Up: broad scope spanning many tools and frameworks. Down: a narrow scope limited to Safeguard 8.10 and its prerequisites, 4.1 and 8.9 |
| Auditor sampling time | Independent auditor or certification body | Recurring, each audit cycle | Up: unclear evidence and inconsistent settings across tools. Down: a single exportable configuration record per aggregation tool showing the 90-day setting and its change history |
Open-source tools that produce retention evidence
Two self-hosted tools named in the researched facts can supply retention evidence for Safeguard 8.10, but neither one proves the 90-day minimum on its own. The first is Nextcloud. Its admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. Pointing that setting at a known location lets you show an assessor exactly which file holds the records, then check that the retention settings and any rotation rules keep that file for at least 90 days. Confirm the exact logging configuration keys and rotation behavior in the Nextcloud admin manual: Logging for the version you run, because the assessor will test the live configuration, not the documentation.
The second is OpenBao. Its audit devices keep a detailed JSON log of every API request and response, including errors, and most sensitive values are hashed with HMAC-SHA256. That makes the log useful for showing who accessed which secrets and when, which is the kind of question a reviewer asks when checking retention. Because the audit device writes to a file or another destination you choose, the retention period depends on your rotation and archival setup, not on OpenBao itself. Check the OpenBao documentation on audit devices and then test that a 90-day window of records is still present and readable.
Plan for licensing before you build evidence around either tool. Nextcloud is licensed under AGPL-3.0-only, and OpenBao is licensed under MPL-2.0. Both licenses permit self-hosted use, but they carry different obligations if you modify the code or distribute it, so have counsel confirm how they apply to your deployment. Whatever the tools produce, the organization owns its retention decision, and an independent auditor decides whether the evidence is sufficient. Your implementation partner can configure and document these settings, but neither the partner nor the tool vendor issues an attestation.
Who does what in retention work
Your organization owns the control. Safeguard 8.10 asks that audit logs across enterprise assets be kept for at least 90 days, so the retention decision, its written standard and its accountability sit with you. A partner can configure systems, but the policy that sets how long each log source is kept, who approves exceptions and how often the setting is reviewed must come from your own governance. Assessors will ask who made the decision and whether it was approved, so the answer should name roles, not vendors.
- Retention standard: Own the written requirement that sets the minimum period, the log sources in scope and any longer periods for sensitive systems.
- Configuration decisions: Decide which aggregation tools hold the logs, which retention values apply and how changes go through change control.
- Exception handling: Approve and record any log source that cannot meet the period, with a compensating action and an expiry date.
- Evidence ownership: Keep the configuration exports, change tickets and review records that show the setting stayed in place.
- Ongoing review: Confirm that the retention setting is checked on a schedule and after platform upgrades.
Before engaging anyone, confirm that a named owner can explain the retention standard and show where its approval is recorded.
An implementation partner such as DeployOpen can prepare the systems that hold your logs. In a fixed-scope engagement, the partner typically configures the log aggregation tools from Safeguard 8.9 to keep records for the period your standard sets, documents how each setting was applied and runs verification checks before your assessor arrives. The partner works inside your cloud accounts, data centers or air-gapped network. It prepares evidence, but it does not attest to it and does not issue any report on Safeguard 8.10.
- Configuration work: Set retention values on the aggregation platform and on any self-hosted source that keeps its own audit trail, such as the admin_audit app in Nextcloud, which writes to a file in the data directory or a path set with
logfile_audit. - Verification runs: Test that retention settings hold after restarts, upgrades and storage changes, and record the results.
- Evidence packs: Export configuration, retention policies and sample log entries in a form your team and assessor can read.
- Documentation: Write runbooks for how retention is set and how it is restored after a rebuild.
- Out of bounds: The partner does not decide the retention period, grant exceptions or sign off on compliance.
When requesting a quote, ask which deliverables are fixed, which systems are in scope and how verification results will be handed over.
An independent auditor, assessor or certification body tests whether Safeguard 8.10 is met and issues any report or certificate. The assessor examines the retention configuration directly, samples evidence and checks that the settings match your written standard. Independence is the reason its conclusion carries weight, so it must not design, configure or prepare the controls it tests in the same engagement, and it should be selected and paid under terms that keep that separation intact.
- Configuration testing: Inspect retention settings on the aggregation tools and confirm the retention period is at least 90 days across the in-scope assets.
- Evidence sampling: Select log sources and time ranges and check that records exist for the full period.
- Standard comparison: Compare the configuration against your approved retention standard and any exceptions.
- Report issuance: Only the assessor issues a report, attestation or certificate, and it states its own findings.
- Line drawn at attestation: Evidence prepared by a partner is an input the assessor may test, not a conclusion the partner can give.
Ask your assessor which evidence formats it accepts and whether it has any conflict with the partner you have selected.
Questions buyers ask about audit log retention
How much work does 90-day audit log retention take?
For most environments the work is configuration and verification rather than new tooling, because Safeguard 8.10 only requires audit logs across enterprise assets to be kept for at least 90 days. The effort depends on how many log sources exist, how many aggregation tools receive them, and whether retention is already set consistently. Teams with a centralized logging platform from Safeguard 8.9 usually have fewer retention settings to review than teams with logs spread across individual hosts. Ask any partner to inventory every log source and every aggregation tool before agreeing a fixed scope.
Can we meet Safeguard 8.10 in-house?
Yes, an organization can meet Safeguard 8.10 with its own staff, since CIS Controls content is free for organizations to use to improve their own cybersecurity. The practical question is whether your team has the skills to configure the aggregation platform, document retention settings and produce evidence an assessor will accept. CIS measures the share of log aggregation software configured to keep logs for 90 days or more, so the work is largely about configuration records and proof. Organizations that lack this in-house skill often bring in an implementation partner for a fixed scope while keeping ownership of the control.
What does our team need to own for audit log retention?
Your organization owns the control, so it needs named owners and a written standard before any configuration begins. The standard should state the retention period, which log sources it covers, who may change retention settings and how changes are recorded. Your team also needs administrative access to the log aggregation tools and a way to export configuration evidence. Safeguards 4.1 and 8.9 are prerequisites in the CIS assessment specification, so owners of secure configuration and centralized logging should be part of the work.
How long do configuration and verification usually take?
Duration depends on the number of log sources, the state of the existing aggregation platform and how much change control your organization requires. Configuration itself is often shorter than the approval, testing and evidence collection that surround it. Verification should show that retention settings are active on every in-scope aggregation tool and that older logs are still available for the full period. No standard duration applies to every organization, so ask for a timeline built from your own asset inventory and change process rather than a generic estimate.
Do IG1 organizations have to meet Safeguard 8.10?
No, Safeguard 8.10 is assigned to Implementation Groups 2 and 3 and is not part of the IG1 set. IG1 covers essential cyber hygiene as a minimum standard for every enterprise, so an IG1 organization can focus first on its baseline logging Safeguards. An IG1 organization may still choose to retain logs for 90 days, because longer retention helps investigations even when it is not required. Confirm your Implementation Group against the CIS Controls Implementation Groups page before scoping work, since your obligations follow the group, not your size alone.
How does storage cost scale with 90-day retention?
Storage cost grows roughly with the volume of logs collected and the length of time they are kept, so a longer retention period multiplies the footprint of every log source. Costs typically include the storage platform itself, backup or archive copies, and the compute needed to search retained data. The main cost drivers are log volume per asset, the number of enterprise assets that produce detailed logs, and the chosen storage tier. Ask for a sizing estimate based on your measured daily log volume, and confirm whether your aggregation platform charges by ingestion, storage or both.
What should a partner's scope include in writing for audit log retention?
A written scope should list the log sources and aggregation tools in scope, the retention period to be configured, and the evidence the partner will prepare. It should also state what the partner will not do, such as issuing an audit report or certifying compliance, since only independent assessors issue those. DeployOpen plans and implements systems inside your own infrastructure, and most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ask for named responsibilities, a handover of configuration records and a plan for verifying retention after go-live.
How DeployOpen prepares audit log retention evidence
DeployOpen plans, implements and documents self-hosted open-source logging platforms inside the client's own infrastructure so that retention settings and their evidence can be shown to an assessor. The organization owns its controls and its retention policy, and an independent auditor or assessor reaches any conclusion about them.
How we scope
- Engagements are fixed-scope, with the log sources, retention targets and platforms agreed in writing before work starts.
- The written scope names which log aggregation tools fall under Safeguard 8.9 and must keep logs for at least 90 days.
- Scope also confirms the enterprise assets and data classes whose audit logs Safeguard 8.10 covers in the client's environment.
How we build
- We configure log aggregation software so that each in-scope tool's retention setting is set to 90 days or more, then record the setting.
- We check that prerequisites such as the secure configuration process from Safeguard 4.1 and centralized collection from Safeguard 8.9 are in place.
- We test retention by confirming that logs from earlier dates are still available in each tool after the configured period has run.
How we hand over
- Deliverables include a configuration record for each in-scope tool, showing its retention setting and where that setting is held.
- We document the retention procedure, the test results and the steps the client's team follows to verify retention after changes.
- Handover covers evidence packaging for the client's assessor, with the client confirming which items the assessor will request.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer that keeps retention settings verified after platform changes.
- Retainer work can re-test retention after upgrades, so the evidence stays current between assessments.
- Questions about what an assessor will accept should go to the auditor or certification body, not to DeployOpen, which does not issue reports or certificates.
