Safeguard 8.3 Ensure adequate audit log storage: requirements and evidence

What Safeguard 8.3 asks for and why audit log storage fails quietly

Safeguard 8.3 requires that the destinations receiving audit logs have enough storage capacity to meet what the audit log management process demands. If an auditor or customer questionnaire asks whether logs are kept, this is the Safeguard that answers the storage half of that question: logs being generated is not enough if the systems receiving them run out of room. In CIS Controls v8.1 it sits in the Data asset class and the Protect security function, and it is assigned to all three Implementation Groups, which makes it part of IG1 essential cyber hygiene. Its practical job is to make the collection work done under Safeguard 8.2 durable, because collection that silently stops when a disk fills does not meet the process your organization wrote under Safeguard 8.1.

Storage fails quietly for a simple reason: log volume grows with usage, new services and verbose settings, and nothing alerts anyone until a destination fills, rotates out old entries or stops accepting writes. Teams often discover the gap only during an incident, when the events they need were never kept. The reader's first decision is therefore to name every destination that receives logs (local hosts, log collectors, SIEM or cloud log stores) and record the retention period each one must support. The second is to confirm that each destination has a capacity check or a storage alert, and that someone owns the response when it fires. Ask your platform team how the logging tools behave when storage is full, since some drop events and some stop writing.

The CIS Controls Assessment Specification lists Safeguard 1.1, the enterprise asset inventory, as a prerequisite for measuring Safeguard 8.3. The reason is practical: you cannot confirm that every logging destination has enough capacity until you know which assets exist and which of them produce or receive logs. Start from the inventory, mark the systems that act as log sources or sinks, and then check each sink's storage against the retention your process sets. Keep the resulting list as evidence. The specification's measures for this Safeguard are defined in the CIS Controls Assessment Specification, and you should confirm the exact evidence an assessor expects with your auditor before you finalize the design.

Which log destinations and teams fall under Safeguard 8.3

Safeguard 8.3 applies to every place audit logs land, not only the SIEM. The cards below cover the destinations that usually receive logs under the audit log management process, the scoping choices that change the storage work, and the teams that own each piece. Confirm ownership in writing before sizing storage, because a destination nobody owns is usually the one that fills up first.

Central SIEM and log analytics platforms

The SIEM is the destination most people think of first, and it is the one Safeguard 8.3 measures most directly against the storage needed for the log management process. Confirm how much storage the platform is provisioned for, how many days of hot and archived data that covers, and what happens when the limit is reached: whether ingestion stops, older data rolls off, or new events are dropped. The security operations team usually owns the platform, but the infrastructure team often owns the underlying disks or subscriptions, so agree who watches capacity alerts.

Log aggregation servers and syslog collectors

Intermediate collectors receive logs from endpoints, servers and network devices and forward them onward. They hold data only briefly, but a collector that buffers to a small local disk can silently drop events during an outage. Check disk size against the peak event rate and the length of the longest expected forwarding interruption. The platform engineering or infrastructure team typically owns these hosts, and they should be included in the same capacity monitoring as the central store.

Cloud and third-party hosted logging services

Logs sent to a cloud provider's logging service or a hosted SIEM count as log destinations in scope, even when the organization does not run the storage itself. Confirm which storage quotas, retention tiers and ingestion limits apply, and whether the contract lets the organization raise them. The cloud platform team usually administers the account, while procurement and the service provider management owner track the contractual terms. Hosted services also need the evidence Safeguard 8.3 expects, meaning capacity and coverage reports the organization can produce on request.

Application data directories and local log files

Some applications write audit logs to a local directory before any forwarder reads them. For example, Nextcloud's admin_audit app writes to audit.log in the data directory unless a different path is set with logfile_audit. A full disk here can stop the application or the log writes, so the application owner and the server operations team should agree on the file path, rotation settings and disk headroom. Confirm the path in the server configuration rather than relying on the default.

Appliance buffers and sensitive-data assets

Firewalls, load balancers and other appliances often buffer logs locally, and their buffers are easy to forget in capacity planning. Assets that hold sensitive data need more detailed logging under Safeguards 8.5 and 8.9, which increases event volume and therefore storage demand at the destination. The network team usually owns appliance buffers, and the data owner for each sensitive system should confirm which logs must reach the central store so the storage estimate reflects them.

How an assessor tests logging storage coverage

This table compares each step of an assessor's check on Safeguard 8.3 with the evidence requested and the gaps that commonly appear. Read it as a sequence: the inventory and process set the scope, sampling tests the destinations, and capacity against volume and retention decides the result. The main takeaway is that a storage figure on paper is not enough; the assessor expects proof that destinations keep up with real log volume for the full retention period.

Test area	Evidence requested	Common findings
Asset inventory (Safeguard 1.1 prerequisite)	Current enterprise asset inventory showing which systems generate logs and where they send them	Log sources missing from the inventory, so their storage needs never get counted
Logging requirements (Safeguard 8.1 process)	Documented audit log management process stating collection scope, review and retention periods	Process silent on retention length or storage ownership, leaving no measurable target
Destination sampling	List of log destinations such as SIEM, log servers or cloud buckets, with a sample of each checked in the console or configuration	Destinations with no owner, or a sampled system that writes to a local disk with no forwarding
Capacity versus volume	Daily or monthly ingest volume per source, compared with allocated capacity and growth trend	Capacity sized from a one-time estimate and never revisited as sources were added
Capacity versus retention	Calculation showing total capacity covers the retention period set in the process for every destination	Storage holds weeks of data where the process requires longer, or retention is undocumented
Alerting on storage thresholds	Alert rules or dashboards for disk usage on log destinations, with recent alert history	No threshold alerts, so teams learn about full volumes only after logging stops
Dropped or lost logs when storage fills	Configuration showing behavior at full capacity, plus records of gaps or ingest errors	Logs silently dropped or overwritten when storage fills, with no alert and no gap record
Remediation records	Tickets or change records showing storage was expanded or retention adjusted after earlier findings	Fixes made in the console without a change record, so the assessor cannot verify them

How to implement Safeguard 8.3 in six steps

This sequence takes a team from an unclear set of logging destinations to a measured, monitored storage position that can support the audit log management process. Each step closes with a named artifact the team can show an assessor.

Confirm the asset inventory baseline
Start from the enterprise asset inventory produced under Safeguard 1.1, which the CIS Controls Assessment Specification treats as a prerequisite for measuring Safeguard 8.3. Confirm that every asset that generates logs appears in it, and flag any gaps for the asset owners to resolve. Done means you hold a reconciled asset list that names the systems expected to send logs. Ask whoever owns the inventory to confirm the last reconciliation date before you rely on it.
Build the log destination register
List every system that receives audit logs, such as a SIEM, log aggregation service, object store or local log volume on an asset, and record the owner of each destination. Map which source assets send logs to which destination. The output is a destination register with one owner per destination and a clear link to the assets it serves. Ask the owners to confirm the register, since undocumented destinations are the most common reason storage gaps surface late.
Set storage and retention requirements
Take the storage and retention expectations from the audit log management process documented under Safeguard 8.1, and translate them into a requirement for each destination. Specify how much data must be kept, for how long, and what must happen when a destination approaches its limit. The output is a requirements sheet that states the retention period and capacity target per destination. Where the process does not yet give a retention value, the Safeguard 8.10 requirement and your own legal or contractual obligations are the inputs to confirm.
Measure current volume and growth
For each destination, measure the storage in use, the free capacity and the daily or weekly rate at which log volume grows, using the platform's own storage metrics. Record the figures over a period long enough to show normal peaks, not a single quiet day. The output is a capacity baseline that shows, for every destination, how much headroom remains against the requirement from the previous step. Confirm that the measurement method is repeatable so an assessor can reproduce it.
Add capacity alerts with a named owner
Create an alert rule for each destination that fires before projected usage would breach the storage requirement, and route it to the owner recorded in the destination register. In a self-hosted stack, a metrics platform such as Prometheus can collect the storage figures, and Grafana Alerting can evaluate the rule and notify the owner from a single view. The output is an alert rule set in which every rule has a named owner, a threshold and a documented response. Confirm that alerts reach a person, not only a shared mailbox nobody checks.
Set a review cadence and record metric results
Agree how often the capacity baseline and alert history are reviewed, and assign the reviewer. Each review compares current usage with the requirement, records any destination that is trending toward its limit, and notes the action taken. The CIS Controls Assessment Specification defines three measures for Safeguard 8.3, combined into one logging storage coverage metric, so record the results in a form that lets you calculate that metric each cycle. The output is a dated metric log and review record that shows storage coverage over time.

Evidence that shows logging storage is adequate

Safeguard 8.3 is tested through records that connect each log destination to its capacity, its retention settings and the decisions made when space ran short. The cards below cover the artifacts an assessor is most likely to request, and each one should be kept current between audits rather than rebuilt when a review is due. None of these artifacts passes an assessment on its own; the assessor judges whether the set is consistent, dated and matches the systems in scope.

Logging destination register

A maintained list of every system that receives audit logs, such as a SIEM, log aggregator, object store or local collector, with its owner, location and the asset classes it serves. It is the starting point for Safeguard 8.3 because every later storage record must trace back to a destination on this list. Check that it is reconciled against the asset inventory from Safeguard 1.1, which the CIS assessment specification names as a prerequisite, and that new collectors added by teams are captured. Export it on a schedule and store the dated copies.

Audit log management process document

The documented process from Safeguard 8.1 sets the storage requirements that capacity must meet, including what must be logged, how long it is kept and who reviews it. Storage adequacy is measured against this document, so an outdated version creates a gap that an assessor will see first. Confirm that the storage section names the destinations and the retention period each one must support, that the document has been reviewed in the current cycle, and that approval is recorded with a date.

Dated capacity reports

Periodic reports that show log volume written to each destination against the storage it has available, with the time window and the growth trend. These reports prove that adequacy was monitored over time rather than assessed once. Automate the export from the storage platform or monitoring tool into a dated archive so that reports exist for past periods, not only the current one. Check that the reports cover the same destinations listed in the register.

Capacity alert rules and notifications

Alert rules that fire when a destination approaches a defined free-space or ingestion threshold, together with the history of notifications sent and who acknowledged them. An assessor can test whether low storage was detected and acted on before logs were lost. In Grafana Alerting, rules can be built from queries across data sources and managed from one view, which helps keep storage alerts beside other operational alerts. Confirm the thresholds are documented, the notification routes reach a staffed team, and the alert history is exported for audit periods.

Retention settings per destination

The configured retention period and rotation behavior for each log destination, taken from the platform configuration rather than from memory. Retention is where storage requirements become concrete, because a longer period needs more space. Record the setting, the file or configuration key that holds it and the date it was last changed. For example, a self-hosted application may write its audit output to a configured path, and the assessor will want to see that path, its size limit and its rotation policy in the same record.

Records of capacity changes and reviews

Change tickets, approvals and review notes showing when storage was expanded, when retention was adjusted and when the capacity plan was revisited. These records close the loop between the monitoring data and the decisions taken. Each entry should state the trigger, such as a threshold alert or a new source added to the register, the action taken and the person who approved it. Keep the tickets linked to the alert history so that an assessor can follow one event from detection to resolution.

What meeting Safeguard 8.3 costs in money and effort

This table breaks down the cost components of meeting Safeguard 8.3 and shows who is paid for each, whether it is one-time or recurring, and what moves it up or down. The CIS Controls are free to use, so the spend sits in storage, tooling, engineering time and review, and the right-hand column shows how to keep each one under control. Ask for an itemized quote tied to a written scope before you commit to a design.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Log storage capacity (hardware or cloud volumes)	Recurring	Log volume per day, the retention period set under the audit log management process, and replication for resilience	Size retention to the documented process, tier older logs to cheaper storage, and confirm pricing with your cloud or hardware vendor
Storage sizing and capacity planning	One-time, then periodic	Number of enterprise assets in the Safeguard 1.1 inventory, log sources enabled by Safeguards 8.2 and 8.5 to 8.8, and growth expectations	Use a complete asset inventory as the sizing baseline and re-check capacity after new log sources go live
Open-source collectors and log stores	Recurring infrastructure, no license fee for the software itself	Hosting footprint, operational overhead, and the number of log destinations to maintain	Run fewer, well-sized destinations and automate deployment so changes are repeatable
Engineering and configuration time	One-time build, then recurring maintenance	Number of logging destinations, alert and storage thresholds to define, and integration with existing platforms	Fix a standard storage configuration and reuse it across environments under a fixed-scope written agreement
Capacity monitoring and alerting	Recurring	Number of storage metrics tracked, alert rules written, and who responds to capacity warnings	Track a small set of storage and ingestion metrics, with alerts routed to a named owner
Evidence upkeep	Recurring	How often capacity reports are produced, how long they are kept, and how many systems must be shown	Automate capacity reports and store them with the audit log management records
External review and auditor sampling	Recurring, tied to assessment cycles	Number of logging destinations sampled, depth of testing, and whether an independent assessor is engaged	Prepare a clear evidence pack in advance and keep the scope of the assessment defined
Retainer support for upgrades and testing	Recurring, if chosen	Scope of ongoing support, frequency of testing, and response expectations written into the retainer	Limit the retainer to the systems that need it and set response terms in writing

Which self-hosted tools can show storage headroom and alerts

No self-hosted tool satisfies Safeguard 8.3 on its own. The organization owns the requirement, and the evidence is a record that each logging destination has enough capacity for what the audit log management process demands. Open-source platforms help by exposing storage numbers that can be trended, alerted on and kept as evidence. Prometheus is the most direct source: it collects metrics from instrumented jobs through a pull model over HTTP and stores them as time series on its autonomous local storage, which you can query with PromQL. Confirm which storage metric your Prometheus deployment exposes for each log destination, typically through the node or filesystem exporter in your environment, and confirm the retention period you configure, because the trend is only useful if it covers the review period your assessor will sample.

Grafana Alerting turns those numbers into a control signal. Its alert rules are built from queries and expressions across multiple data sources, so a rule can evaluate storage metrics alongside log-related metrics and log queries from one place. The alert history and the rule definitions can be exported as evidence that a threshold exists and that someone is notified when it is crossed. Grafana is licensed under AGPL-3.0-only, so review how your organization's use and any modifications fit that license before you build it into a product or service you distribute. The thresholds and escalation routes are decisions you must document, and their values should follow your own log volume and retention requirements, not a default.

Two applications write logs to disk in ways that need the same capacity check. The Nextcloud admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. Confirm whether that path sits on the same volume as user data, which can fill quickly and stop audit writes. OpenBao audit devices write a detailed JSON log of every API request and response, including errors, with most sensitive values hashed with HMAC-SHA256, so the file grows with API traffic. Measure growth under normal and peak load, then size the volume and set an alert on free space for each path. Record the calculation, the alert and the test that shows the alert fires, since an assessor will ask for proof that the headroom is monitored.

Who does what: your team, an implementation partner and the auditor

Your organization owns Safeguard 8.3. The control asks that every destination receiving audit logs has enough storage to meet what your audit log management process demands, so the decisions about how much capacity is enough, how long logs must survive and what happens when storage runs short belong to you. These decisions follow from the process set under Safeguard 8.1 and the retention rules you have written down, not from a vendor default.

Destination register: Keep a current list of every system that receives audit logs, including SIEMs, log aggregation servers, cloud log stores and local log directories, with the owner of each.
Capacity decisions: Set the storage thresholds, growth assumptions and retention periods for each destination, and record who approved them.
Process ownership: Keep the audit log management process current and make sure the storage rules in it match what the platforms actually do.
Exception handling: Decide what happens when a destination reaches its threshold, including who is notified and which logs may be dropped, if any.
Asset inventory link: Confirm that the inventory from Safeguard 1.1 includes every logging destination, because the assessment specification treats that inventory as a prerequisite.

Check that someone inside the organization can explain each capacity number and produce the approval record without referring to a consultant.

Where organizations fall short on log storage and how to close it

Most logging failures under Safeguard 8.3 are not hardware shortages. They are gaps in ownership, inventory and review that let a destination fill, overwrite or silently drop logs. Each card names one gap, the fix and the artifact an assessor can inspect to confirm it is closed.

Log destinations missing from the inventory

A SIEM, syslog relay or cloud log bucket that nobody lists cannot be sized, monitored or patched. Safeguard 8.3 measurement relies on the asset inventory from Safeguard 1.1, so unlisted destinations quietly fall outside the storage check. Fix this by recording every log receiver, its storage limit and its owner in the inventory. Evidence: the inventory export with log destinations tagged, and a reconciliation against the logging configuration on each source.

Retention set in policy but not on the destination

The audit log management process may state a retention period, yet the storage platform often keeps data on its own default settings. The gap appears only when old logs are missing during an investigation. Fix this by translating the retention requirement into destination settings, such as index lifecycle or bucket rules, and testing that they apply. Evidence: exported retention configuration from each destination, compared with the requirement in the documented process.

Disks filling without an alert

When a log volume reaches capacity, many platforms stop accepting new events or discard the oldest ones without notifying anyone. The result is a gap that looks normal in the dashboard. Fix this by alerting on used capacity and on ingestion failures at thresholds that leave time to act. Evidence: alert rule definitions, a test notification record and the incident ticket generated when the alert fires.

No owner for capacity decisions

Storage growth usually follows new log sources, verbosity changes or longer retention, and each change is made by a different team. Without a named owner, nobody approves the growth or funds the expansion. Fix this by assigning one accountable role for logging capacity and requiring it to sign off on new sources. Evidence: a RACI entry or role description in the audit log management process and records of capacity approvals.

Storage metrics collected but never reviewed

Teams often gather disk and ingestion metrics but never look at trends, so a steady climb toward the limit goes unnoticed until the disk is full. Keeping the metrics is not the same as reviewing them. Fix this by scheduling a recurring review of storage trends and recording the outcome. Evidence: retained metric history covering the review period, and dated review notes showing forecasts and actions taken.

Endpoint logs overwritten before collection

On endpoints, local log files often rotate on a small size limit, so older entries are overwritten before the central collector retrieves them. Storage on the destination is then adequate, yet the data never arrived. Fix this by sizing local rotation to cover the forwarding delay and monitoring for gaps between local and central event counts. Evidence: the rotation configuration on sample endpoints and a reconciliation report showing collected versus generated events.

Questions buyers ask about Safeguard 8.3 cost, effort and outside help

How much effort does Safeguard 8.3 take to meet?

The effort depends mostly on how many logging destinations you run, how much log volume they receive, and how much of that storage is already measured. Safeguard 8.3 asks that the destinations receiving logs have enough capacity for what your audit log management process requires, so the work has two parts: sizing the storage against your retention and collection rules, and showing that the sizing holds over time. Environments with few log sources and a clear retention rule need less work than estate-wide collection with many SIEM indexes, object stores and self-hosted application logs. Ask any partner to break the effort into inventory, sizing, monitoring and evidence so you can see where the time goes.

Can our team meet Safeguard 8.3 without outside help?

Yes, if you have people who can run the logging platforms and maintain the documented retention rules. The organization owns its controls, so the storage decision, the retention rule and the evidence remain your responsibility either way. Outside help is most useful when the logging destinations are spread across several platforms, when no one owns the audit log management process, or when the team lacks time to build storage alerts and dashboards. An implementation partner can prepare systems and evidence, but only an independent auditor or assessor issues any report or attestation.

What does our staff need to contribute to this work?

Your staff must supply knowledge that no outside party has. Plan for the owners of each logging destination to confirm current capacity, growth and retention settings, and for someone who owns the audit log management process to confirm the retention period it requires. The asset inventory from Safeguard 1.1 is a prerequisite for measuring this Safeguard, so the people who maintain that inventory will also be involved. Expect a regular review step where someone checks storage trends and acts on warnings before logs are lost.

How long does this work typically take, and what sets that length?

No duration is stated here because the timeline depends on your environment. The main drivers are the number of logging destinations, whether the asset inventory is already current, how many platforms need capacity alerts, and whether a retention rule is already documented and approved. Work goes faster when the process from Safeguard 8.1 exists and the destinations report usage in a consistent way. Ask for a timeline in the written scope that lists each destination, the dependency on the asset inventory and the point at which evidence is handed over.

Can we outsource log storage, and what must stay in-house?

You can outsource the hosting of storage, such as a managed SIEM or a cloud storage service, but the obligation stays with you. Your organization should keep ownership of the retention rule, the decision on what must be retained and for how long, and the review of capacity reports. Where a provider hosts the logs, check its contract for storage capacity commitments, retention terms and how you obtain usage data. Safeguard 15 service provider management covers how to assess that provider. If you self-host, the storage, sizing and alerting are the work you directly control.

What should we ask a partner to include in a quote?

Ask for a written scope that names each logging destination in scope, the storage sizing method, the capacity alerts to be built, the evidence to be produced and the handover point. Also ask which items are one-time work, such as sizing and alert setup, and which recur, such as monitoring, upgrades and periodic re-sizing. Confirm who owns the retention decision and who signs off on the evidence. A fixed-scope quote follows from this written scope, and DeployOpen does not publish a price list, so the scope is what allows you to compare proposals.

How DeployOpen prepares log storage evidence for Safeguard 8.3

DeployOpen helps organizations show that their logging destinations have enough storage for the audit log management process they already run. We prepare the systems, sizing records and evidence inside your own infrastructure, while your organization owns the control and an independent assessor reviews it.

How we scope

The written scope lists which logging destinations, platforms and asset groups are covered for Safeguard 8.3.
Scope names the retention requirements from your audit log management process that storage must satisfy.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts; ongoing support is available as a retainer.

How we build

We size storage on each log destination against collection volume and the retention period your process sets.
We configure capacity alerting so teams see storage pressure before log collection stops or drops data.
We confirm the asset inventory from Safeguard 1.1 covers every device and platform that sends logs to storage.

How we hand over

You receive documented storage sizing, capacity thresholds and alert rules mapped to each logging destination.
Evidence packs include storage usage records over time, showing coverage across the measured destinations.
Your team gets runbooks for expanding storage and for recording the decisions behind each capacity change.

How we support

Ongoing support can track storage growth as new log sources are added or retention requirements change.
We can re-run sizing and testing after platform upgrades, migrations or changes to the audit log process.
Your organization decides what counts as adequate; an independent auditor or assessor issues any report or certificate.