Safeguard 8.8 Command-line audit logs: requirements

What Safeguard 8.8 command-line audit logging requires in practice

Safeguard 8.8 requires command-line audit logs to be collected, and CIS gives Bash, PowerShell and remote administrative terminals as its example sources. If your enterprise is IG2 or IG3, expect an assessor to ask whether administrator and operator commands are recorded somewhere the security team can read them. Under CIS Controls v8.1 the Safeguard sits in the Data asset class and the Detect security function, and it applies only to Implementation Groups 2 and 3, so IG1 organizations do not need to meet it for that baseline. Confirm your own Implementation Group before you scope the work.

The detection risk is straightforward. An administrator who runs a privileged command on a server, a jump host or a network device can change configuration, create accounts or move data without leaving a trace in the logs that your alerting depends on. Command-line activity is often the earliest visible step of an intrusion, so a gap here weakens every detection rule that follows. Collecting it is harder than it sounds. Windows, Linux and macOS record command history in different ways, shells such as Bash, PowerShell and their variants have different logging hooks and defaults, and interactive sessions opened through remote administrative tools may not pass through the shell logging you enabled on the workstation image.

Privileged sessions are the hardest part. Shell history is often writable by the user, cleared on logout or disabled for root and service accounts, so a logging design that relies only on defaults will miss the activity you most need to see. Before the assessment, inventory which shells, jump hosts and remote terminal tools your administrators actually use, record how each one writes command activity, and decide where the records are forwarded. Ask your assessor to confirm the measures they will apply to the configuration coverage metric, and check how the prerequisite data from Safeguards 1.1 and 4.1 supports that measurement. Your evidence should show the configuration, a sample of collected commands and the destination they reach.

Which hosts, shells and teams fall under Safeguard 8.8

Safeguard 8.8 is only as complete as the inventory it starts from. The cards below cover the assets, shells and teams that usually need command-line logging, and the scoping decisions that change how much work the Safeguard becomes. Treat each card as a question to answer in your own environment before you size the work.

Servers and their interactive shells

Start with every server that accepts interactive logins, including Linux hosts running Bash and Windows servers running PowerShell. Batch-only servers that never receive a human session still need a decision, because scheduled scripts can run commands that matter to an investigation. Confirm which shells are installed and which are enabled for each server role, since a shell that is present but unused still needs a defined logging position.

Workstations used for administration

Administrators often run privileged commands from laptops and desktops rather than from servers. A workstation that holds an administrator's session can expose the same command history as a server, so include any endpoint where PowerShell, Bash on Windows or terminal emulators run with elevated rights. Check whether these endpoints are in your asset inventory under Safeguard 1.1, because an unlisted administrator workstation is the most common gap in command-line coverage.

Jump hosts and bastion systems

Jump hosts relay administrator sessions into production networks, so they concentrate command activity from many people. Logging on the jump host shows which commands crossed the boundary, while logging on the target shows what ran there. Decide whether you need both views, and confirm that the jump host records the session before the administrator reaches a second system.

Remote administrative terminals

Remote terminals include SSH sessions, remote PowerShell sessions and terminal access brought in through remote management tools. Each protocol may log commands differently, and some log only the session start and end. List every remote method your administrators use, then test whether a command typed in each one reaches your log destination. A method that passes through a gateway may be logged at the gateway but not on the target.

Cloud administration consoles and CLIs

Cloud administration is often performed through web consoles and command-line tools such as cloud provider CLIs running on administrator laptops or build runners. Command-line activity in these tools may be recorded by the provider's control plane rather than the host, so determine which records count as command-line evidence for your assessment. Confirm this with your cloud team and the assessor before you rely on either source alone.

Network appliances with shells

Many routers, firewalls and storage appliances expose a shell for maintenance. Vendor support sessions often use these shells, and their logs may sit on the device with limited retention. Identify which appliances offer command logging, which can forward it to your central platform, and which need a compensating process. This is where Safeguard 4.1 secure configuration records matter, because they show how each appliance's administrative access is set up.

Service accounts that run commands

Service accounts that execute scripts, scheduled tasks or automation pipelines produce command activity without a person behind it. Decide whether these commands fall in scope, and if so, record which account ran each command so that reviewers can tell automated activity from human activity. Coordinate with the owners of Safeguard 5.x account management records to confirm that each service account has a named owner.

Sensitive data and third-party administered systems

Assets that hold sensitive data justify deeper logging, and systems run by a service provider need a contractual route to their command logs. Ask which in-scope hosts store regulated data, which are administered by an outside party, and whether that party will share command records on request. Where a provider cannot supply them, record the gap in your service provider review so the decision is documented and owned.

Safeguards 1.1 and 4.1 as prerequisites

The CIS assessment specification lists Safeguard 1.1, the enterprise asset inventory, and Safeguard 4.1, the secure configuration process, as prerequisites for measuring Safeguard 8.8. Without a current inventory, you cannot prove that every shell-bearing asset is covered. Without documented configuration, you cannot show which shells are enabled and how they log. Confirm both records exist and are current before you start the measurement work.

How an assessor tests command-line logging under CIS 8.8

This table walks through how an assessor approaches Safeguard 8.8, from the three measures that feed the configuration coverage metric to the evidence requested and the gaps that most often fail. Use it to prepare your own evidence before an assessment, and to see where outside help is worth the cost. CIS defines what to measure, while the assessor's own procedure determines how the test is run.

Assessment element	What the assessor looks for	Evidence that usually satisfies it
Measure 1: Shell and interpreter coverage	Whether every in-scope asset running Bash, PowerShell or similar interpreters has command-line logging enabled in its configuration	Configuration exports or policy files showing the logging settings applied to each asset group
Measure 2: Remote administrative terminals	Whether sessions opened over remote administration channels, such as SSH or remote PowerShell, produce command-line records	Sample log entries from remote sessions, with timestamps and user identity present
Measure 3: Collection point delivery	Whether command-line records actually arrive at the central collection point rather than staying on the endpoint	Coverage report from the log platform listing hosts that have sent command-line events in the review period
Combined configuration coverage metric	The three measures are combined into one coverage figure, so a gap in any one measure lowers the result	A reconciled report comparing the asset inventory against hosts with working command-line logging
Prerequisite data from Safeguards 1.1 and 4.1	A current asset inventory and a documented secure configuration process, because the test depends on them to define scope and baseline	Enterprise asset inventory extract and the approved configuration standard referenced by the logging settings
Sampling approach	Assessor selects a sample of assets and sessions, then checks shell history or logging configuration and confirms the records reach the collection point	Sample selection list, screenshots or exports for each sampled host, and the matching entries in the central platform
Common finding: partial coverage	Logging enabled on servers but not on administrator workstations, or on some operating system builds but not others	Coverage report showing gaps by asset class, with the remediation plan and dates to close them
Common finding: unlogged remote terminals	Remote administrative sessions that bypass the shell configuration used for local sessions	Session records that show no command-line entries for remote logins, which the assessor will flag for follow-up

Implementing command-line logging step by step

This sequence takes Safeguard 8.8 from an inventory of where administrative shells run to a documented, tested configuration that sends command-line records to the central log store. Each step leaves an artifact an assessor can inspect.

Confirm the asset inventory and secure configuration baseline
Start from the enterprise asset inventory under Safeguard 1.1 and the secure configuration process under Safeguard 4.1, because the CIS Controls Assessment Specification treats both as prerequisites for measuring Safeguard 8.8. Your team lists every host class that runs a shell, including Linux servers, Windows servers, workstations and network or appliance hosts that accept administrative sessions. The output is a scoped list of hosts with their operating system, owner and current baseline. You know this step is done when every host in scope maps to an inventory record and a documented configuration baseline.
Define the shells and remote terminals to log
Decide which command interpreters and remote administrative paths count as in scope for each host class. Typical entries include Bash and other Unix shells, PowerShell, and remote terminals such as SSH sessions and Windows remote management sessions. Security and operations leads agree the list, and the platform owner records any shell that is deliberately excluded with a reason. The output is a shell and session register that the audit log management process can reference. The step is complete when the register is approved and matches the inventory from the previous step.
Configure Bash and Unix shell command logging
On Linux and Unix hosts, administrators configure the shell and the system audit facility to record executed commands with user identity and timestamp. Engineers confirm the exact method for each distribution and shell version, since logging settings and file locations vary, and they set file permissions so that users cannot alter or disable the records. The output is a versioned configuration file or policy set committed to the configuration repository. The step is done when a test session on each host class produces a command record that includes the user, the command and the time.
Configure PowerShell and Windows session logging
On Windows hosts, engineers enable PowerShell script block and module logging and transcription where the platform supports them, and they enable process creation auditing with command-line capture for the same hosts. Remote administrative sessions are logged through the remote management service's own logging options. Confirm each setting against the Windows version in use, because available options differ by release. The output is a group policy or configuration management export and a record of which events are written to which channel. The step is complete when a PowerShell session and a remote session both produce events visible in the local event log.
Forward command-line logs to the central store
Configure the log forwarder on each host to send command-line records to the central log platform defined under Safeguard 8.9. Engineers map each source to a log index or stream, apply the retention settings required by Safeguard 8.10, and confirm that the transport is encrypted and authenticated. The output is a forwarding configuration and a data flow note that names the source, the destination and the transport. The step is done when records from each host class appear centrally with a consistent host identifier and timestamp.
Validate coverage with test commands
Run a defined set of harmless test commands from each shell and remote terminal on each host class, then search the central store for those exact records. Testers also check that a command run through a privilege escalation path is attributed to the correct user, and that a deliberately blocked or failed command is still recorded where the platform is configured to record it. Record the results in a coverage report that lists host, shell, test command, expected record and result. The step is complete when every in-scope combination has a passing entry or a documented exception with an owner.
Document the process and schedule recurring checks
Write the procedure into the audit log management process so that new hosts, shells and remote paths follow the same steps, and link the configuration baseline, shell register and coverage report to it. Assign an owner for drift checks, and have the configuration management tool or a scheduled query confirm that command-line logging remains enabled. The output is an approved procedure, a control record for Safeguard 8.8 and a schedule for re-running the test set after major changes. An independent assessor will review these records, and the organization owns the controls that they describe.

Why command-line logs go missing even when logging is turned on

Turning on command-line logging does not guarantee that 8.8 is met, because the evidence has to cover every shell an administrator or service account can use, not only the default one. The first gap is per-user shell history. Interactive shells often write history to a file in each user's home directory, and that file can be truncated, overwritten by a second session, or never leave the host. Shell history is also not a timestamped, tamper-resistant record of who ran what. Ask your team to confirm, for each shell in use on Linux and macOS hosts, whether history is written centrally in real time or only saved when a session exits, and whether users can edit or delete it.

PowerShell is the second gap. Script block logging, module logging and transcription are separate settings, and none of them should be assumed active on every Windows host just because the operating system is installed. Confirm them through your group policy or configuration management baseline, and check a sample of hosts rather than trusting the policy object alone. Also confirm that the events are forwarded to the same place as your other Windows security logs, since a log that exists only on the local host does not satisfy the Safeguard's intent for collection and review.

Remote terminals create the third gap. An SSH session, a WinRM remote shell, and an RDP-based console each record activity in a different place, often under a different event source, and some record only connection metadata rather than the commands typed. A session that starts on a jump host and then moves to a database server may leave its command trail split across two systems. Build an inventory of every remote administration path into the environment, then map each path to the log source that shows the commands, not only the logins. Privileged elevation is the fourth gap: tools such as sudo or a runas-style elevation can run commands through a path that bypasses the logging configured for the ordinary shell. Confirm that elevation events are logged with the command executed, and test this with a controlled administrative action during your evidence walkthrough.

Evidence that passes a Safeguard 8.8 assessment

An assessor testing Safeguard 8.8 wants proof that command-line activity is logged on the systems where it matters, that the logs reach a place where they can be read, and that the setup stays the same over time. The cards below are the artifacts that tie those points together, and the habits that keep them accurate between audits.

Logging configuration baselines per platform

Write one baseline for each shell and admin path in use, such as Bash history and auditd rules on Linux, PowerShell script block and transcription settings on Windows, and session recording on remote administrative terminals. Each baseline should name the setting, the file or policy object that holds it, and the owner who approved it. Assessors use these to confirm the intended configuration exists before they sample real hosts. Confirm the exact keys with the vendor documentation for each platform version you run.

Coverage inventory of command-line sources

Map each enterprise asset to its command-line log source, using the asset inventory from Safeguard 1.1 as the starting list. Mark hosts where logging is not supported or not enabled, and record the reason and any compensating control. This inventory is the document that turns a configuration baseline into a measurable coverage figure, which is the metric the assessment specification uses for this Safeguard. Review it whenever hosts are added, retired or re-imaged.

Sample command-line events with identity

Keep representative events exported from the log store, each showing the timestamp, the host, the account that ran the command and the command text or session identifier. Include a privileged session, a remote administrative session and a service account example. Assessors check that events are attributable to a person or a named service, so an event without a user identity is a finding. Store the samples with the query used to pull them so the result can be repeated.

Forwarding and retention settings from the aggregator

Export the forwarding rules, index or storage settings and retention periods from the log aggregation tool that receives command-line logs. Confirm that every source in the coverage inventory appears in the forwarding configuration and that events arrive within a stated delay. Retention should match the period set in the audit log management process. Check the settings against the aggregator's own documentation, since configuration keys differ between products.

Change records for logging configuration

Keep a dated record of every change to logging settings, including who requested it, who approved it, what changed and why. Changes to shell history controls, audit rules or forwarding filters are the ones assessors ask about most, because they can silently remove coverage. Link each change to a ticket in the change management system. Records of rolled-back changes matter as much as successful ones.

Keeping evidence current between audits

Schedule exports of the baselines, coverage inventory and forwarding settings, for example monthly, and store them with a version and date. Run configuration drift checks on hosts that compare live logging settings to the baseline and open a ticket for each mismatch. Track the count of hosts with missing command-line logs over time, so that a gap found in review is shown to be fixed. Use the same scripts for each export so that the evidence format does not change between cycles.

Open-source tools that support command-line audit evidence

osquery exposes host state, such as running processes, open network connections, loaded kernel modules and file hashes, as SQL tables that can be queried on a single machine or across a fleet. Its osqueryd daemon can run those queries on a schedule, which lets a team gather a recurring record of process activity that an assessor can compare against the command-line logging policy. It does not record every typed command by itself, so it is best treated as a complementary source that shows what was running on a host at each query time.

Scheduled process snapshots: osqueryd runs defined queries on a schedule across enrolled hosts, producing timestamped results.
Fleet-wide consistency: The same query runs on every enrolled endpoint, which makes gaps in coverage easier to spot.
Ad hoc investigation: Analysts can run SQL queries against process and network tables during a review.
Configuration evidence: Saved query packs and their schedules show how monitoring was set up.

Confirm in your environment which platforms osquery supports, how results are shipped to your log store, and whether the query set captures the command-line details your Safeguard 8.8 policy requires.

Some self-hosted platforms write their own audit logs of administrative actions. Nextcloud's admin_audit app writes extra event information to audit.log in the data directory, or to a path set with logfile_audit. OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed using HMAC-SHA256. These logs are relevant to Safeguard 8.8 only where the platform is part of the administrative surface you review, such as an admin console or a secrets service used from a terminal.

Nextcloud audit log: Enable admin_audit and confirm where logfile_audit points, since the default location is in the data directory.
OpenBao audit devices: Enable an audit device and confirm the JSON log destination and how hashed values are handled.
Scope discipline: Include these logs only where administrators act through them, and state that boundary in your evidence.
Not a shell log: Neither log replaces operating system shell logging on the hosts where administrators type commands.

Confirm the current configuration keys and log locations in each product's documentation before you cite them in an assessment.

What meeting Safeguard 8.8 costs in money and effort

This table breaks down the cost components of meeting Safeguard 8.8 for command-line audit logs, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to scope internal work against outside help and to build a quote request, since the open-source tools carry no license fee but the surrounding effort and storage do not disappear.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it
Tooling and licenses	No license fee for the open-source tools named (for example osquery, Velociraptor, Nextcloud audit logging). Confirm any paid add-on or hosting service with its vendor.	One-time setup, recurring if you buy hosted support	Choice of platforms; whether a commercial distribution or support contract is added
Log storage and central log platform	Your cloud or data center provider, or your SIEM vendor, for storage and ingestion	Recurring	Volume of command-line events, retention period, and how many hosts forward logs
Engineering time to enable and configure each platform	Your platform or security engineers, or an implementation partner under a written scope	One-time, with periodic changes	Number of operating systems, shells and remote administrative paths in scope
Coverage validation	Your team or a partner tests that Bash, PowerShell and remote terminal sessions produce records in the central store	One-time, repeated after major changes	Count of configurations and whether a standard baseline exists
Evidence upkeep	Your compliance or security staff keep configuration records, sample outputs and change history current	Recurring	How often hosts, shells or administrative access paths change
External review or assessment	An independent auditor or assessor, under their own fee structure. A partner can prepare evidence but does not issue findings.	Periodic, at each assessment cycle	Scope of the assessment and how many systems are sampled
Auditor sampling effort	Your staff pull samples on request and explain them to the assessor	Recurring, per assessment	Whether logs are searchable by host, user and time, and how quickly samples can be produced
Storage and retention controls	Your staff or partner configure retention for command-line logs and confirm access restrictions	One-time setup, recurring operation	Retention period set in the audit log management process and the volume of stored records
Cost reducers to ask about	Your engineering team applies a standard configuration baseline and automated forwarding	Mostly one-time investment that lowers recurring effort	Fewer custom configurations, and fewer manual exports for auditors

Who owns command-line logging: your team, a partner and the auditor

Your organization owns Safeguard 8.8 in full. That means deciding which command-line sources count as in scope, which hosts and administrative paths must produce logs, how long logs are kept, who can read or alter them, and who answers when a gap appears. The control is only as good as those decisions, and no partner or auditor can make them for you. Your team also owns the evidence trail: the configuration records, the coverage reports and the review history that show the control runs as designed every day, not only on the day of an assessment.

Scope decisions: Name the shells (for example, Bash, PowerShell) and remote administrative terminals that must log, and record why any excluded system is out of scope.
Policy alignment: Tie command-line logging to the audit log management process from Safeguard 8.1, including who reviews the logs and how often.
Ownership of changes: Approve every change to logging configuration and keep the change record.
Operational response: Staff the alerting and review that act on command-line events, and document what happens when logging stops.
Evidence custody: Keep the coverage reports, configuration exports and review records in a location your assessor can reach.

Before engaging anyone, confirm internally who signs off on the scope and who holds the evidence after the project ends.

Where command-line logging usually falls short

Command-line logging rarely fails in one dramatic way. It usually fails at the edges: a platform that was never switched on, a remote terminal nobody recorded, or a privileged path that skips collection altogether. Each card below names one gap, what it looks like in practice, and how to close it so the evidence holds up under assessment.

Logging enabled on some platforms only

Teams often turn on command-line logging for Linux servers and forget developer workstations, jump hosts or network appliances that also accept shell sessions. Safeguard 8.8 is judged against the enterprise's assets, so partial coverage is a gap, not a success. Close it by listing every platform that accepts interactive commands, then confirming for each one that the shell or console writes history or script-block events to the central collector. Keep the configuration check for each platform as evidence.

Remote terminals missing from inventory

Remote administrative terminals, such as SSH sessions into cloud instances or PowerShell remoting from an admin workstation, often sit outside the asset inventory that Safeguard 1.1 is meant to produce. If the session target is not in the inventory, nobody checks whether its commands are logged. Close it by tagging every administrative entry point, bastion or remote management endpoint in the inventory, then tracing a sample session from start to central log to confirm the commands arrive.

Logs stored only locally and overwritten

A shell history file on the host it describes is easy to delete, and a rotating local log can silently overwrite the entries an investigator needs. Command records kept only on the source machine also disappear when that machine is rebuilt or compromised. Close it by forwarding command-line events to a central store as they are written, restricting who can alter that store, and setting retention so the local copy is never the only copy.

No coverage metric for the assessor

Safeguard 8.8 is measured by the CIS Controls Assessment Specification through a configuration coverage metric, so an assessor will ask what share of in-scope assets log commands, not whether logging was once configured. Many teams cannot answer because nobody compares the asset list with the log sources. Close it by reporting the ratio of in-scope systems sending command-line events to the total in the inventory, recorded on a schedule with the exceptions listed and approved.

Privileged paths bypassing collection

Break-glass accounts, emergency consoles, direct root logins and scripts run under service identities can bypass the normal logging path. These are the sessions most worth recording, so a gap here weakens the whole control. Close it by inventorying each privileged path, testing whether its commands reach the central log, and either adding collection or documenting a compensating control with a named owner and review date.

Safeguard 8.8 questions buyers ask before hiring help

Does Safeguard 8.8 apply to IG1 organizations?

No. CIS Controls v8.1 assigns Safeguard 8.8 to Implementation Groups 2 and 3 and leaves it out of IG1. IG1 is CIS's essential cyber hygiene baseline, and its command-line logging expectations sit in other Control 8 Safeguards. An IG1 organization can still choose to collect shell or PowerShell history, but it is not measured against 8.8 unless its IG placement changes. Confirm your Implementation Group on the CIS Implementation Groups pages before you scope the work. IG2 suits organizations with more operational complexity that hold sensitive information, and IG3 suits regulated organizations with sensitive assets facing sophisticated attacks. Your placement decides whether 8.8 is in scope for your assessment.

How much effort does command-line audit logging take?

The effort depends on how many places commands are run. The CIS Controls Assessment Specification defines three measures for Safeguard 8.8, combined into one metric called configuration coverage, so the work is mostly about covering every source across the estate. Shells such as Bash and PowerShell, plus remote administrative terminals, each need configuration, testing and proof that events reach the log destination. The main drivers are the number of operating systems, the number of shells and remote access tools in use, fleet size, and whether an asset inventory (Safeguard 1.1) and a secure configuration process (Safeguard 4.1) already exist. The assessment specification lists both as prerequisites because they produce the data needed to measure coverage. Recurring effort comes from keeping coverage current as hosts are added, images change and administrators adopt new tools.

Can our own team implement command-line logging without outside help?

Often yes, if the team has working knowledge of each shell, the logging pipeline and the destination platform. Implementation itself is usually configuration work. The harder parts are measuring coverage across the full estate, proving to an assessor that every in-scope source is covered, and handling the sensitive content that command lines can contain, such as tokens or passwords typed as arguments. Ask whether your team has time for those tasks, whether it can produce repeatable evidence, and whether it has staff who know both Windows and Linux administration well. Outside help is most useful when the internal team lacks one of those skills or when a fixed-scope engagement would deliver a clearer evidence set sooner. Either way, the organization keeps ownership of the control and of its decisions about what is logged.

How long does Safeguard 8.8 work take to complete?

This page does not give a duration, because the time needed depends on scope. The main variables are the number of asset classes and operating systems in scope, whether the asset inventory and secure configuration process already exist and are current, how many remote administration paths need coverage, and how quickly your change and approval processes move. DeployOpen's engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. Ask any provider, including DeployOpen, for a written schedule tied to a defined list of hosts, shells and log destinations, along with the dependencies on your team. Expect measurement to recur after the initial build, since coverage must be re-checked as the environment changes.

What does the work need from our team?

Several named roles are needed, and missing one usually delays the work. You need an owner for the control who can make decisions about scope and sign off on evidence. You need administrative access to endpoints, servers, jump hosts and the log platform, along with change windows to alter shell configuration on production systems. You also need a person who understands the log destination and can confirm events arrive as expected. Security or privacy staff should review how command lines containing sensitive values are stored and who can read them. Finally, you need an evidence custodian who keeps configuration records, test results and coverage reports in a place an independent assessor can access. Clarify these roles in the written scope before the work begins.

Can an implementation partner issue the certification or audit report?

No. DeployOpen plans, implements, documents and supports systems and evidence, but it does not issue audit reports, attestations or certifications. Only an independent auditor, assessor or certification body can do that. The CIS Controls are a set of prioritized safeguards that CIS states do not replace any regulatory, compliance or authorization scheme, so a customer, regulator or framework that asks for assurance will name its own assessor or process. A partner's role is to prepare the environment so that an assessor can test Safeguard 8.8 directly. Confirm with your assessor which evidence they will accept, and confirm with CIS whether any accreditation applies to the providers you are considering, since CIS Controls Accreditation covers CIS SecureSuite member organizations rather than a client's own certification.

How DeployOpen scopes and prepares Safeguard 8.8 evidence

DeployOpen plans and implements self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, and command-line logging for Safeguard 8.8 is scoped the same way: in a written, fixed-scope agreement agreed before any work starts. The scope should name the in-scope endpoints and servers, the shells and administrative terminals to be logged (Bash, PowerShell and any remote administrative sessions), the destination for the logs and the people who will review them. Scope also has to reflect Safeguards 1.1 and 4.1, because the CIS assessment specification treats the enterprise asset inventory and the secure configuration process as prerequisites. A client without a current inventory or documented configuration baseline should expect that gap to be listed in the scope document as work to be done first or as a client-owned dependency.

Once scope is agreed, the work is deployment and documentation. The engineering team configures the command-line logging the client has chosen, sets the log destinations, confirms that events from the tested hosts arrive with usable fields such as user, host, time and command text, and records each configuration key, file path and service account in a configuration record the client keeps. Where the client uses osquery or Velociraptor for endpoint visibility, the team can document which queries or artifacts support the review of command-line activity, but the client should confirm with its security team which tools it intends to rely on for this Safeguard. The coverage measurement the assessment specification describes (configuration coverage across three measures) should be run and the results retained as evidence that the configuration is in place.

DeployOpen then prepares the evidence package for the client's own assessor, which may be an internal audit function, a CIS Controls assessor or an external auditor for a framework that maps to Safeguard 8.8. DeployOpen does not issue audit reports, attestations or certifications, and it does not decide whether Safeguard 8.8 is met. The client owns the control, the logging policy and the review process, and it should decide with its assessor which sample of hosts, time window and log extracts will be presented. Ask any implementation partner to confirm in writing which artifacts will be delivered, who maintains them after handover and how changes to logging configuration will be recorded, because the evidence only remains credible if it stays current after the engagement ends.