Safeguard 8.2 Collect audit logs: evidence and cost

What Safeguard 8.2 Collect audit logs asks for before any other logging control works

If an auditor, a customer questionnaire or an internal review asks whether audit logs are collected, the direct answer is this: Safeguard 8.2 requires logging to be enabled across enterprise assets, as the audit log management process defines, and it sits in the IG1 baseline, so every enterprise is expected to meet it. Under CIS Controls v8.1 the Safeguard is classed under the Data asset class and the Detect security function, and it applies to all three Implementation Groups. The practical question for your team is therefore not whether logging is a good idea but whether you can name every asset that should log, show that logging is switched on for each one, and show what happens to those logs next. The detection risk of an unlogged asset is simple. If a server, workstation, network device or cloud workload produces no audit records, an intrusion that runs through it leaves no trace for the security team to find, and an investigator later cannot reconstruct who did what. Gaps are rarely deliberate. They usually come from three places: assets nobody recorded in the first place, so logging was never configured on them; mixed platforms, where Linux hosts, Windows endpoints, SaaS tenants and appliances each keep logs in a different place and at a different level of detail; and logs that are enabled locally but never forwarded, so they sit on a host that an attacker can clear. Each of these is a failure of 8.2 even when the logging feature itself works. Start with three checks before you buy or tune any tool. First, confirm that your enterprise asset inventory is current, because Safeguards 1.1, 4.1 and 8.1 are listed as prerequisites for measuring 8.2 and the inventory defines the population you must cover. Second, compare the inventory against the logging configuration on each asset class and record the assets where collection is off, partial or unverified. Third, check that the audit log management process names which events must be recorded and where they must go. The assessment specification for 8.2 measures coverage, so an unexplained gap will count against you whatever the tooling. Consider the sign-off a decision point: the organization owns this scope, and any implementation partner or auditor will rely on the list you can produce.

Which assets, data and teams fall inside Safeguard 8.2 scope

Safeguard 8.2 looks simple on paper, but the scope decisions made before logging is switched on determine how much work follows. The cards below cover the asset types, the v8.1 classification, the inventory that defines the target list, and the teams and providers that own the logs.

Enterprise assets versus cloud and SaaS

Safeguard 8.2 is written around enterprise assets, so endpoints, servers, network devices and self-hosted applications are the core of the scope. Cloud control planes and SaaS tenants often produce their own audit trails that the organization can export but does not run. Confirm for each cloud and SaaS service whether logs are available, which events they cover and whether the organization can collect them into its own store.

The Data asset class and Detect function

In v8.1, Safeguard 8.2 sits in the Data asset class and the Detect security function. That placement tells assessors the logs are there to detect events affecting data, not only to satisfy an administrative requirement. Scope reviews should ask which systems hold sensitive data and whether their logs reach the team that monitors for suspicious activity.

The asset inventory defines what gets logged

Safeguard 1.1 produces the enterprise asset inventory, and assessors treat it as a prerequisite for measuring Safeguard 8.2. Any asset missing from the inventory is likely missing from the log collection plan as well. Reconcile the inventory against log sources before setting the coverage target, and record which assets are excluded and why.

Platform, endpoint and application owners

Logging crosses team boundaries. Platform engineering usually owns servers and the logging agents, endpoint teams own workstations and mobile devices, and application owners decide which events their software emits. Security operations defines what it needs to detect. Assign a named owner for each asset group so that a gap found in a coverage check has someone to fix it.

Provider-controlled logging

Where a third-party platform controls logging, the organization may depend on the provider for log availability, format and retention. Identify each such platform, confirm in writing which logs the provider makes available and how they are exported, and record the gap between provider logs and the Safeguard requirement. Safeguard 15.1 covers the provider inventory that supports this check.

How the CIS assessment specification measures Safeguard 8.2 coverage

The CIS Controls Assessment Specification defines three measures for Safeguard 8.2, and CIS combines them into one metric that is best read as coverage: how much of the enterprise asset estate is actually sending audit logs. The specification is the source for those measures, so it should be the first document an assessor or internal reviewer opens. CIS describes what to measure, not how to build the measurement, which means the organization owns the method. Read the Safeguard 8.2 section directly for the exact wording of each measure, and do not rely on a summary, including this one, when you define your own test scripts or evidence requests.

Three other Safeguards are listed as prerequisites for measuring 8.2. Safeguard 1.1 requires an enterprise asset inventory, which gives you the denominator for coverage: without a trustworthy list of devices, you cannot say what share of them logs. Safeguard 4.1 covers the secure configuration process, which defines the baseline settings that should include audit logging on each asset type. Safeguard 8.1 covers the audit log management process, which states what must be logged and where it goes. Each one typically produces data the 8.2 measurement needs, so a gap in any of them usually shows up as an unmeasurable result rather than a clean pass or fail.

Before the first measurement, confirm three things with your team: that your asset inventory from Safeguard 1.1 is current enough to serve as the denominator, that the logging settings required by your 4.1 baseline and 8.1 process are written down per asset class, and that you can pull the log source status for each asset from a central location. Illustratively, if the inventory lists 400 assets and only 360 report logs, the coverage result is an explicit gap of 40 assets to explain or close. Ask your implementation partner or auditor to agree in writing how each of the three measures will be calculated and what evidence will be retained for each.

How an assessor tests Safeguard 8.2 and what they ask for

This table follows the steps an assessor takes to test Safeguard 8.2, from building the asset population to comparing logging coverage against the total. Read each row as a stage of the test, what the assessor asks you to produce, and where engagements usually stall. The main takeaway is that coverage is only as credible as the asset inventory and the logging destinations behind it.

Assessment step	What the assessor asks for	Common findings
Build the asset population	The enterprise asset inventory from Safeguard 1.1, exported with asset class, owner and status, so the assessor can count in-scope assets	Inventory is older than the environment, cloud instances or containers are missing, or the asset count differs between tools
Confirm prerequisites	Evidence that the audit log management process from Safeguard 8.1 and the secure configuration process from Safeguard 4.1 exist and name the log sources expected on each asset type	Process document is undated, does not list asset types, or was never approved by management
Sample assets	A sample drawn from the inventory across device types, operating systems and environments, with the assessor choosing the sample	Samples are picked by the team to avoid known gaps, or servers are sampled while endpoints and network devices are not
Check logging is enabled	Configuration exports or screenshots from each sampled asset showing audit logging turned on for the events the process requires	Logging is enabled on the domain controller but not on Linux hosts, or defaults were changed by a later update
Check the destination	Evidence that logs leave the asset or are written to a retained location, such as a collector, SIEM index or protected local store	Logs are written locally and overwritten, forwarding agents are installed but stopped, or the destination is not named
Compare coverage to the total	A coverage calculation of logging-enabled assets divided by all in-scope assets, with exceptions documented and approved	Exceptions are undocumented, coverage is reported without a denominator, or unmanaged assets are excluded from the total
Verify over time	Recent log samples or collection health reports showing logs arrived during the assessment period	Collection stopped after a migration or certificate change and nobody noticed until the test

How to enable audit logging across enterprise assets in sequence

This sequence turns Safeguard 8.2 from a statement of intent into a set of enabled log sources, forwarded to a defined destination, checked against the asset inventory and documented with named exceptions. Each step ends with an artifact a reviewer can inspect.

Confirm the enterprise asset inventory
Start from the enterprise asset inventory that Safeguard 1.1 calls for, because you cannot confirm logging on assets you have not listed. Sort the inventory by asset class (devices, servers, network devices, cloud accounts and applications) and mark which assets hold sensitive data. The output is an inventory extract with an owner and a logging-relevant attribute on each row, which becomes the denominator for the coverage check later in the sequence.
Define the logging baseline in the audit log management process
Using the documented audit log management process from Safeguard 8.1, write down which event types must be logged for each asset class, which accounts or services generate them, and who approves the baseline. Keep the baseline short enough that engineers can apply it per platform. The output is a versioned baseline table, signed off by the process owner, that names the minimum event sources expected from each asset class.
Enable native logging on endpoints and servers
Turn on the operating system and endpoint audit facilities that the baseline names, such as Windows event logging, Linux auditd or syslog, and macOS unified logging, using your configuration management tooling so settings are repeatable. Confirm the change on a sample of hosts first. The output is a configuration file or policy in version control and a report from your configuration tool showing which hosts received it.
Enable logging on network devices, cloud accounts and applications
Repeat the enablement for network devices (firewalls, switches, VPN gateways), cloud control plane audit logs and business applications, using each platform's native audit settings. Record the exact setting or policy name used on each platform, because vendor names for these settings differ and change between versions. The output is a per-platform configuration record that shows the setting is on, with a screenshot, export or command output as evidence.
Forward logs to the agreed destination
Configure each source to send its logs to the destination named in the audit log management process, which is often a central log store or SIEM covered by Safeguards 8.3 and 8.9. Check that transport is encrypted where the platform supports it, that timestamps reach the destination intact, and that a failed forwarder raises an alert. The output is a list of active forwarding rules and a test event from each source that appears at the destination.
Verify coverage against the inventory
Compare the log sources that arrived at the destination with the asset inventory from the first step, and list every inventory row without a matching log stream. This comparison is the practical core of the coverage metric the CIS assessment specification uses for Safeguard 8.2. Run it on a schedule once it works manually. The output is a coverage report that states how many inventory assets are logging, how many are not, and the date of the check.
Record exceptions with named owners
For every asset that cannot log, or cannot log to the agreed destination, create an exception entry that states the reason, the compensating control, the named owner and the decision date, and route it to the process owner for approval. Do not mark an asset as covered until its logs are confirmed at the destination. The output is an exception register that a reviewer can read alongside the coverage report, showing that gaps are known, owned and reviewed.
Confirm the sequence with an independent assessor
Once the baseline, configurations, coverage report and exception register exist, ask the independent assessor or auditor you have engaged to test a sample of assets from the inventory end to end, from the source setting through to a log entry at the destination. The organization owns the controls and the evidence; the implementation partner, if one is used, prepares it. The output is the assessor's own test record, which only the assessor can issue.

Which evidence shows Safeguard 8.2 is met, and which open-source tools produce it

An assessor testing Safeguard 8.2 wants to see that audit logs are collected from every enterprise asset in scope, not just a sample of servers. The cards below cover the artifacts that prove coverage and the open-source platforms that generate log evidence inside your own environment.

Coverage report against the asset inventory

This report compares your enterprise asset inventory from Safeguard 1.1 with the list of systems that actually send audit logs to your collection point. Each asset in the inventory should appear as logging, as excluded with a documented reason, or as a gap. The CIS assessment specification measures coverage, so this report is the artifact that maps most directly to the metric. Check that the inventory is current before you trust the percentage it produces, because an outdated inventory overstates coverage.

Configuration exports showing logging enabled

Export the logging settings from each platform, operating system and network device, and keep the files with the date they were taken. These exports show that auditing is switched on, which events are included and where the output goes. Compare them against the audit log management process from Safeguard 8.1 to confirm that the configured scope matches the documented requirements. A configuration file on disk is weaker evidence than a dated export from the running system, so capture both where possible.

Sample log extracts with timestamps

Keep dated extracts from several asset types showing that events are being written and that each record carries a timestamp. Choose samples from different time windows so an assessor can see that collection is continuous rather than a one-off test. Timestamps are only useful for correlation if the clocks agree, so pair these extracts with the time synchronization evidence from Safeguard 8.4. Confirm that the sample fields match what your process requires.

Exception records for unlogged assets

Some assets cannot send logs, for example embedded devices or legacy systems that lack a supported logging option. Record each exception with the asset name, the reason logging is not possible, the compensating control, the named owner and a review date. An exception register with no owners or review dates usually fails the assessment because it reads as an unmanaged gap. Keep the register short and specific, and link each entry back to the coverage report.

Change records for newly added assets

Each new server, container platform, application or network device should show logging enabled before it enters production. Keep the change ticket that adds the asset alongside the configuration export taken at go-live. Without this link, coverage drifts over time and the inventory no longer matches the log sources. Ask your change board to reject production changes that lack a logging step, and sample these records during internal reviews.

Nextcloud admin_audit application logs

The admin_audit app records additional event information to audit.log in the data directory, or to a path you set with logfile_audit. Enable it, point the file to a location your collector reads, and check which event classes it writes for your deployment before you claim coverage. Confirm the exact events with your own test actions, because the list depends on your enabled apps and version. Forward the file to central storage so the record survives a compromised application server.

OpenBao audit device logs

OpenBao audit devices write a detailed JSON record of every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256, so the log can show who did what without exposing secrets. Enable at least one audit device, and confirm that a failed audit device write blocks requests, since a silent gap would break your coverage claim. Test that each device path is recorded before you rely on it as evidence.

What meeting Safeguard 8.2 costs in money and effort

This table lists each cost component of collecting audit logs under Safeguard 8.2, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to structure a request for a line-item quote from a written scope, since no price list applies.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Logging tooling or licenses	Software vendor or subscription provider, if a commercial product is chosen	Usually recurring (subscription or per-volume licensing)	Event volume, number of enterprise assets, vendor pricing model. Open-source collectors remove license spend but not the cost below
Engineering to enable and forward logs	Internal platform or IT team, or an implementation partner under a fixed-scope agreement	One-time for initial enablement, recurring for changes to new asset types	Number of asset types, platform mix (Windows, Linux, cloud, SaaS), and how many log sources need custom parsing
Storage for log destinations	Organization (on-premises hardware or cloud storage bills)	Recurring	Log volume per asset, retention period set by the audit log management process, and whether logs are compressed or indexed
Evidence upkeep	Internal compliance or security staff, or an external consultant preparing evidence	Recurring, typically at each review cycle	Frequency of configuration changes, number of assets to sample, and whether evidence is generated automatically from the logging platform
External review	Independent auditor or assessor, who issues any report or attestation	Recurring per assessment cycle	Assessment scope, number of in-scope assets, and whether the organization has prepared sample populations before fieldwork
Auditor sampling and testing	Auditor's time, billed under the engagement agreement	Recurring per assessment cycle	Sample sizes the auditor chooses, population completeness, and how quickly the organization can produce log extracts on request
Open-source tooling and self-hosting	No license fee for the software itself; the organization or its partner pays for hosting and operations	Hosting and operations are recurring; setup is one-time	Hardware or cloud capacity, staff time for patching and monitoring the logging stack, and the support model chosen
Quote basis	DeployOpen quotes from a written scope, which lists assets, log sources, retention and deliverables	Quote is one-time per engagement	Ask for each component as a separate line with its assumptions, so the quote can be compared with internal estimates

Who owns, implements and independently checks Safeguard 8.2

Your organization owns Safeguard 8.2. The Safeguard asks that audit logs are collected across enterprise assets, and the scope of that collection is set by your audit log management process (Safeguard 8.1) and your enterprise asset inventory (Safeguard 1.1). Those decisions belong to you, and no partner or auditor can make them on your behalf.

Scope decisions: Deciding which asset classes, systems and log sources are in scope and which are excluded, with reasons recorded in the process.
Asset inventory: Keeping the inventory current, since a device missing from it will silently fall outside logging coverage.
Ownership of log sources: Naming an accountable owner for each system's logging settings, including who approves changes.
Exception handling: Documenting assets that cannot produce logs, with compensating controls and a review date.
Operating the coverage measure: Running the coverage check on a schedule and acting on gaps.

Before engaging anyone, confirm that your scope decisions and exception records already exist in writing, because an assessor will test them first.

Where Safeguard 8.2 programs usually fall short

Most Safeguard 8.2 gaps are not about whether logging is turned on. They come from a mismatch between what the enterprise believes it covers, what it actually logs, and what it can show an assessor. The cards below cover the failure points we see most often and what to check for each.

Logging on servers only

Teams often enable audit logging on servers and domain controllers, then assume endpoints, laptops, virtual machines and cloud accounts are covered. Safeguard 8.2 applies to all enterprise assets defined in the audit log management process, so an uncovered device class is a gap even when the server estate is clean. Check each asset class against the process and confirm that logging is enabled and writing on a sample from every class.

Logged population differs from inventory

Coverage is only meaningful against a known population. When the logged assets do not match the enterprise asset inventory, the coverage figure is misleading: unlogged assets are invisible and retired assets inflate the count. Reconcile the logging source list against the inventory from Safeguard 1.1 at least once per audit cycle, and record the differences as named exceptions.

Logs kept only on the source

Local logs that are never forwarded disappear when a host is reimaged, compromised or fails. Local-only logging also defeats the purpose of collection, because an attacker with administrator rights on the host can alter or delete what it recorded. Confirm that each log source forwards to a collection point outside the asset, and test forwarding by generating a known event and finding it in the central store.

Exceptions without an owner

Some assets cannot run a logging agent, such as appliances or legacy systems. These exceptions are usually recorded informally and never reviewed, so they quietly grow. Each exception needs a named owner, a documented compensating control or a date for removal, and an approval from the people accountable for the audit log management process. Ask for the exception register during any readiness review.

No coverage metric between audits

Teams often measure coverage once, just before an assessment, and then let it drift. Safeguard 8.2 is measured through a coverage metric built from its measures, so the number needs a record across time to show the control operates continuously. Track the percentage of in-scope assets sending logs on a recurring schedule, keep the trend, and investigate any sustained drop before the next review.

Logging on unsupported platforms

Some platforms in the estate, such as end-of-life operating systems, older SaaS tenants or embedded devices, may offer limited or no native audit logging. Assuming they log because a feature exists in a newer version creates false coverage. Confirm the logging capability for each platform and version in use, record platforms that cannot produce logs as exceptions, and plan a migration or compensating control for them.

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

How much effort does enabling audit logging under Safeguard 8.2 take?

The effort depends mainly on how many enterprise assets need logging, how many different platforms they run, and how much of the logging is already switched on. Mature environments often have logging partly enabled, so the work becomes a gap-closing exercise. Environments with many legacy systems, appliances and cloud accounts take longer because each source needs its own configuration, access and testing. Ask for the effort to be broken down by platform type, so you can see which sources drive the total and where your own staff must act.

Can our own team enable audit logging without an outside partner?

Yes, many organizations do this in house, provided they have people who administer each platform and time to test that events arrive where they should. Safeguard 8.2 is a configuration task, so the main risks are gaps you do not know about, not technical complexity alone. An outside partner is most useful when platforms are numerous, when systems are self-hosted and need hardening, or when staff are stretched. Whichever route you choose, the organization remains responsible for the control and its evidence.

What does the work need from our organization before it starts?

Safeguard 8.2 depends on knowing what to log, so the work needs several inputs from your organization:

An enterprise asset inventory (Safeguard 1.1), so every in-scope system is listed
A documented secure configuration process (Safeguard 4.1) that shows how logging settings are applied
An audit log management process (Safeguard 8.1) that sets collection requirements and names owners
Administrator access to each platform, plus named people who can approve changes

Without these, logging becomes hard to measure and hard to defend during an assessment.

How long does enabling audit logging take?

The duration depends on scope, meaning the number of assets, the platforms involved, the access your team can provide, and how many approvals each change needs. The CIS Controls Assessment Specification describes what to measure for Safeguard 8.2 but does not set a timeline. Ask any provider for a duration tied to a written scope that lists the platforms, the logging settings to be enabled and the verification steps. A fixed-scope agreement makes the schedule easier to compare across proposals.

Can a partner issue a CIS Controls certificate for Safeguard 8.2?

No. CIS does not certify organizations against the CIS Controls through implementation partners, and DeployOpen does not issue audit reports, attestations or certifications. A partner can configure logging, document the process and prepare evidence such as log source lists, configuration records and coverage checks. Independent assessors or auditors then review that evidence and report on it. Ask any provider to state clearly which parts of the work it performs and which parts remain with your organization or an independent assessor.

Does Safeguard 8.2 alone satisfy IG1?

No. Safeguard 8.2 is one of the 56 Safeguards in Implementation Group 1, which CIS defines as essential cyber hygiene and a minimum standard for every enterprise. IG1 also depends on the asset inventory, secure configuration, the audit log management process and other Safeguards across the Controls. Treat 8.2 as one part of a coordinated IG1 program, and use the assessment specification to check each Safeguard you claim to meet.

How do we request a fixed-scope quote for Safeguard 8.2 work?

Send a written scope that lists the in-scope asset classes, the platforms and log sources, the current logging state where known, the access you can provide, and the evidence you need at the end. DeployOpen plans and delivers most engagements as fixed-scope work, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from that written scope. Ask for deliverables, assumptions and out-of-scope items to be listed explicitly.

How DeployOpen scopes, implements and prepares Safeguard 8.2 evidence

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so audit logging for Safeguard 8.2 runs where your enterprise assets run. We prepare the systems, log configuration and evidence that show collection is enabled, while your organization keeps ownership of the control and independent assessors or auditors draw their own conclusions.

How we scope

We confirm which enterprise assets fall within the Safeguard 8.2 collection baseline, starting from the asset inventory.
The written scope lists the platforms, log sources and hosting environments we will configure for audit logging.
We agree in writing which Safeguard 8.1 process and 4.1 configuration records the collection work depends on.

How we build

We enable audit logging on each in-scope platform and document the exact settings applied for each asset class.
We test that events from each platform reach the designated log destination, and record the results.
We check that log records include the fields your audit log management process requires for review and investigation.

How we hand over

We deliver configuration documentation, coverage records and test results that show which assets produce audit logs.
We provide a gap list of assets where logging is not yet enabled, with the reason and the owner for each item.
We walk your team through the evidence set so your staff can reproduce the checks and answer assessor questions.

How we support

Ongoing support, upgrades and continuous testing of logging configuration are available as a retainer.
Retainer work can re-check coverage after platform upgrades, new assets or changes to the audit log management process.
Confirm with us in the written scope which support level, response expectations and deliverables apply to your engagement.