Safeguard 8.9 Centralize audit logs: requirements and evidence

What Safeguard 8.9 asks you to centralize and why it is hard

If your audit logs sit on individual hosts, in separate cloud accounts and inside applications that nobody has reviewed together, Safeguard 8.9 asks you to bring collection and storage of those logs into one central place as far as you can, following your documented audit log management process. CIS's own example is a SIEM that pulls many log sources together. The Safeguard belongs to the Data asset class and the Detect security function, and it applies at Implementation Groups 2 and 3 only, so IG1 organizations are not expected to meet it yet. In the CIS Controls Assessment Specification, the measurement is built from 3 measures combined into one metric, log aggregating. That metric asks whether logs from in-scope assets actually reach the central store, not whether a tool has been purchased.

The difficulty is rarely the tool. Most teams first have to find out which sources exist, which is why the enterprise asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1) are listed as prerequisites for measuring 8.9. Without them, you cannot show an assessor that the set of forwarded sources matches the set of in-scope assets. Next come formats: Windows event data, Linux syslog, cloud control plane events and application logs rarely share field names, so normalization needs a decision about which fields are mandatory. Time synchronization (Safeguard 8.4) also matters, because events from unsynchronized sources cannot be correlated reliably once they are centralized. Storage sizing is the last common trap, since a central store that fills up silently drops the evidence the process depends on.

Start by asking your team to confirm three things in writing: the list of in-scope log sources derived from the inventories, the forwarding method for each source, and the health check that shows a source has stopped sending. Ask your SIEM or log platform vendor to confirm how it reports ingestion gaps. For open-source options, OpenSearch Security Analytics runs detectors against ingested logs from hosts, network devices and cloud services, and Wazuh decodes collected logs and forwards alerts to its indexer. Both help with ingestion and detection, but you must still verify which of your sources they actually receive. Treat any source that is not forwarded as an open finding for the assessor, with a documented reason and an owner.

Which log sources and teams fall inside Safeguard 8.9

Safeguard 8.9 reaches as far as the enterprise assets and log sources it covers, so scope is a decision the organization documents, not a default. The cards below cover the asset and software inventories the assessment specification relies on, the retention link to Safeguard 8.10, and the exclusions an assessor will ask you to justify.

Enterprise assets in the aggregation scope

Start with every enterprise asset that generates audit logs: endpoints, servers, network devices, cloud control planes, identity systems and business applications. Safeguard 8.9 asks for collection and storage in one central place as far as possible, so each asset class needs either a forwarding path into the aggregation tool or a recorded reason it cannot forward. Confirm that the asset list matches what your logging platform actually receives, since gaps usually sit in assets that were never registered.

Dependence on the asset inventory

The assessment specification lists Safeguard 1.1, the enterprise asset inventory, as a prerequisite because it supplies the population of systems that should send logs. Without a current inventory, you cannot show that the aggregation covers the enterprise, and an assessor will ask how you know the list is complete. Reconcile the inventory against the log sources reporting to your SIEM and treat unreported entries as findings to resolve.

Dependence on the software inventory

The software inventory, Safeguard 2.1, is the second prerequisite. Applications, agents and operating system components generate many of the log events that matter, and each one needs a known source and log format before it can be parsed and centralized. Check that every production application appears in the software inventory with its logging capability noted, so that unlisted software does not quietly stay outside the central store.

Third-party and service provider logs

Logs from SaaS platforms, managed services and hosted infrastructure may reach you only through an export, an API or a provider portal. Decide which provider sources are in scope, record how each is ingested, and note where the provider controls retention. Safeguard 8.12 covers service provider logs in more depth, so link the two decisions in the scope document and confirm the contract terms that govern log access.

Retention alignment with Safeguard 8.10

Safeguard 8.10 requires audit logs kept for at least 90 days and measures that retention on the aggregation tools defined under Safeguard 8.9. Scope therefore sets the retention obligation: a source excluded from the central store is also excluded from the retention measurement. Confirm that each in-scope source has a retention setting in the aggregation platform, and that the setting is at least the minimum your process documents.

Documented exclusions and their reasons

Some assets will be excluded, for example devices that cannot produce logs, isolated systems or legacy platforms with no export path. An assessor expects each exclusion to appear in the audit log management process with a named owner, a reason and a review date. Vague exclusions such as "not supported" invite questions, so record the specific limitation, the compensating control and who accepted the risk.

Teams that own each log source

Centralization crosses team boundaries: endpoint, network, cloud, application and identity teams each run sources that feed the SIEM. Name an owner for each source who is responsible for forwarding, format changes and retention. Without named owners, a source can silently stop reporting, and the review cycle in Safeguard 8.11 has no one accountable for fixing the gap.

How an assessor tests log centralization

This table walks through how the CIS Controls Assessment Specification approaches Safeguard 8.9, from the three measures that combine into the log aggregating metric to the inputs, evidence and gaps an assessor typically meets. The CAS defines what to measure, so the rows describe the measurement logic and the evidence, while the method of testing is left to the assessor and the enterprise's own process.

Element	What the assessment looks at	Evidence an assessor expects	Where it usually falls short
Assessment approach	The CAS defines three measures for Safeguard 8.9, combined into one log aggregating metric that shows whether assets send audit logs to a central place.	A documented statement of how the aggregating metric was calculated and which measures were applied to each asset class.	Teams report that logs are collected, without showing how much of the enterprise the aggregation actually covers.
Prerequisite inputs	Safeguards 1.1 (enterprise asset inventory) and 2.1 (software inventory) typically supply the population the metric is measured against.	Current asset and software inventories that match the aggregation scope, with the date each was last reconciled.	Inventories are out of date, so assets exist that the aggregation platform never sees.
Log source list	The log sources the enterprise intends to send to the central platform, mapped to the asset classes they belong to.	A register of log sources with owner, asset class, log type and the platform each source feeds.	The list covers servers and endpoints but omits network devices, cloud services or SaaS tenants.
Aggregation platform configuration	How the central platform (for example a SIEM) receives, parses and stores events from each source.	Configuration exports or screenshots showing receivers, ingestion rules, parsers and storage settings tied to named sources.	Configuration exists for a pilot group but was never extended to production assets.
Local-only logging	Whether assets keep audit logs only on the host or appliance, with no forwarding to the central platform.	Forwarding configuration for each source, plus a sample event that arrives in the central platform with its source identified.	Sources write to local files such as an application log path, and nobody checks whether the forwarding agent runs.
Partial asset class coverage	Whether aggregation reaches every asset class in scope, including Devices, Software, Data, Users and Network, rather than only some of them.	A coverage view by asset class showing which sources reach the platform and which do not, with exceptions documented.	Endpoints and servers are aggregated, while cloud control planes, identity systems or network devices are left out.
Documented process link	Whether centralization follows the documented audit log management process set under Safeguard 8.1.	Process text that names the central platform, the sources in scope and the owner who approves exceptions.	The process describes centralization in general terms and nobody owns the source list.
Confirm with your assessor	The method of testing, sample sizes and acceptance thresholds are decided by the assessor and the enterprise's own process, not by the CAS.	A written agreement on what evidence will be sampled and how coverage gaps will be recorded before testing starts.	Evidence is gathered for the wrong scope because the population was never agreed in writing.

How to centralize audit logs in six steps

This sequence takes an enterprise from scattered logs to a central store that is documented, time-aligned and searchable, so that the coverage Safeguard 8.9 asks for can be shown to an assessor.

Confirm the asset and software inventories
Start from the enterprise asset inventory under Safeguard 1.1 and the software inventory under Safeguard 2.1. The CIS Controls Assessment Specification treats both as prerequisites for measuring Safeguard 8.9, because they define which systems must send logs. Your team owns this step and reconciles the two lists against each other, flagging hosts, cloud accounts and applications that appear in one but not the other. It is done when every in-scope asset has an owner, a name and a recorded place in the inventory, and the open gaps are listed with an assigned owner.
Map log sources to the audit log management process
Take the audit log management process documented under Safeguard 8.1 and list which log sources it requires for each asset class, such as operating system events, application audit trails, identity provider sign-ins and network devices. Record the log type, the source system, and who is responsible for enabling it. Where the process does not yet name a source, decide whether to add it or record a documented exception. The output is a log source register that the central platform will be measured against.
Choose the central platform
Select a SIEM or log store that can receive, index and retain the sources in the register. Decide whether it runs in your own infrastructure, which matters for data residency and for self-hosted open-source options such as Wazuh or OpenSearch. Confirm with each vendor or project which ingestion methods, parsers and retention controls it supports, rather than assuming them. The output is a written platform decision that names the storage location, the administrators and the access model for the log data.
Onboard sources with consistent formats and synchronized time
Configure each source in the register to forward its logs to the central platform, using one agreed transport and a consistent field layout where the source allows it. Confirm that every forwarding source uses the time synchronization set under Safeguard 8.4, because mismatched clocks make cross-system correlation unreliable. Your engineers perform the configuration and keep the change records. The step is complete when each source appears in the platform with a source label, a parsed timestamp and a named owner.
Validate that events arrive and are searchable
Generate a controlled test event on each source, such as a failed sign-in or a configuration change made for testing, and confirm it appears in the central platform within the time your process sets. Run a search that returns the test event by source, user and timestamp. Keep the test records, the query used and the date of the test, because an assessor will ask for evidence that centralization works in practice and not only in design. Any source that fails the test returns to step four.
Document coverage and keep it current
Produce a coverage record that compares the log source register with what the platform actually receives, showing each source, its status, its exceptions and its last successful test. Store the record with the audit log management process so both are reviewed together. Your compliance lead owns the record and updates it when assets or sources change. The output is a current coverage document that lets you explain to an assessor which assets are centralized, which are not, and why.

How a central log pipeline is built and where it breaks

A central log pipeline for Safeguard 8.9 Centralize audit logs has four stages that an assessor can trace: collection agents or forwarders on each enterprise asset, transport to a receiving tier, parsing and normalization, and storage in a central index such as a SIEM. The trust boundary sits between the source systems and the central store. Everything upstream of that boundary is produced by systems that may already be compromised, so the central store should accept only authenticated, encrypted transport from known senders and should never let a source system read back or alter what it has already sent. Draw this boundary on your architecture diagram before you choose a product, because it determines which accounts can write, which can query and which can delete.

Parsing and normalization are where many pipelines quietly lose value. If a Windows event, a Linux syslog line and a cloud API record all land with different field names for the same user or source address, correlation rules written for one format miss the others. Decide on a common schema, such as the one your SIEM or an open schema standard supports, and test each log source against it. The failure points to test and document are dropped events (forwarder queues that fill during an outage, rate limits, or parsing errors that discard lines), clock skew (sources whose time is not synchronized, which breaks event ordering and the 8.4 time synchronization evidence), and unauthorized access to the central store (over-privileged administrators, shared credentials or deletion rights held by the systems being monitored). For each failure point, ask your provider or integrator to show the monitoring that would detect it, such as forwarder health alerts, ingestion count comparisons against asset inventory from Safeguard 1.1, and audit logs of the central store itself.

Evidence that shows logs are centralized

Assessors looking at Safeguard 8.9 want to see that logs from enterprise assets actually reach one central store, not just that a SIEM exists. The artifacts below connect the asset inventory, the platform configuration, the onboarding trail and the query results, so each claim can be traced back to a system. Keep them dated and regenerated on a schedule so they reflect the environment at audit time.

Log source inventory mapped to assets

This is a register that lists every log source feeding the central platform and ties each one to an asset record from the enterprise asset inventory under Safeguard 1.1. Each row should name the asset, the log type, the forwarding method and the owner. Check the other direction too: assets in the inventory that have no matching log source are the gaps an assessor will ask about. Because Safeguard 8.9 lists Safeguards 1.1 and 2.1 as prerequisites, an inventory that is out of date will undermine this evidence from the start.

Aggregation platform configuration exports

Export the configuration of the central platform, including input definitions, index or storage settings, parsing rules and the detector or rule sets that run against ingested data. For an OpenSearch Security Analytics deployment, the detector definitions and the Sigma rule set in use are the relevant items. Store the exports in version control so that each change has a date and an author. Assessors compare these exports against what the running system does, so confirm they were taken from production and not from a test copy.

Source onboarding records

Each new log source should have a ticket or change record showing when it was connected, who approved it, which parser handled it and what test event confirmed arrival. These records show that centralization is a repeatable process, which is what the audit log management process under Safeguard 8.1 expects. Retired sources need the same treatment, with a record of the decommission date so that gaps are explained rather than discovered. Keep the template fixed so records from different years can be compared.

Coverage reports by asset

A coverage report counts, for a given date, how many in-scope assets sent logs to the central store within an agreed window and lists those that did not. Generate it from the platform itself rather than from a spreadsheet, and keep the query used to produce it. Set the window and the in-scope asset class with the audit log management process so the threshold is documented before the assessor asks. Silent sources are the most common finding in this area, so review the report on a fixed cadence and record the follow-up.

Sample queries across multiple sources

Capture saved searches or dashboard queries that return events from at least two different source types for the same time range, such as a host authentication log and a network device log for one incident. This shows that the events can be correlated in one place, which is the practical test of centralization. Save the query text, the time range used and a dated screenshot or export of the result. Re-run the same queries at each review so the evidence shows the capability still works.

Access control records for the central store

Export the list of accounts and roles that can read, modify or delete data in the central store, along with the review record showing who approved each entitlement. Include administrator accounts for the platform itself and any service accounts used by forwarders. Assessors often test whether the log store is protected from the systems it records, so also keep evidence of the separation between the central store and the sources' administrators. Review these records on the same schedule as the other artifacts so that departing staff are removed promptly.

What centralizing audit logs costs

This table breaks down the cost components of centralizing audit logs for Safeguard 8.9, who is paid for each one, and whether it is one-time or recurring. Use it to see where spending lands before you request a quote. The main takeaway is that the CIS Controls themselves are free to use, so the cost sits in tooling, storage, engineering time and evidence upkeep.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Log platform (SIEM or self-hosted stack)	Software vendor for licenses, or your team and infrastructure for a self-hosted platform such as OpenSearch or Wazuh	Licenses recur; self-hosted build is one-time, then recurring operation	Platform choice, deployment model, number of nodes and whether support is bought
Storage and retention capacity	Your cloud provider or data center budget, or the storage vendor	Recurring	Log volume per source, retention period set in Safeguard 8.10, indexing and replication settings
Engineering time to onboard sources	Internal platform or security engineers, or an implementation partner under a fixed-scope agreement	One-time per source, plus change work as assets are added	Number of enterprise assets and sources, how many are already on an asset inventory (Safeguards 1.1 and 2.1), and whether forwarding is standardized
Parsing and normalization effort	Internal engineers or a partner writing decoders, field mappings and custom rules	One-time per log type, then recurring tuning	Number of distinct log formats, use of a common schema, and how many custom rules your detections need
Access control and secure transport	Internal identity and network teams	One-time setup, recurring review	Number of collection paths, encryption requirements and how many administrators need query access
Evidence upkeep	Internal compliance or security staff, with optional help from a readiness partner	Recurring, for example each assessment cycle	How often you export configuration, source coverage reports and retention proof for the assessor
External review and auditor sampling	Independent auditor or assessor, who issues the report	Recurring, tied to the audit cycle	Size of the population the auditor samples, evidence quality and how quickly requests are answered

Open-source tools that produce centralization evidence

OpenSearch (Apache-2.0) Security Analytics is a candidate central point for Safeguard 8.9 because it ingests logs from hosts, network devices and cloud services, then evaluates them against detection rules. Its detectors match events against prepackaged or custom Sigma rules, and each match is recorded as a finding that carries the rule, log type and severity. Findings can trigger alerts to channels such as Slack or email, and a correlation engine links findings across log types in a correlation graph. Assessors looking for evidence of centralization will want to see the ingestion sources, the detector configuration and the stored findings together.

Ingestion evidence: A list of the log sources connected to the index, with the log types each detector consumes.
Detector records: Exported detector definitions showing which Sigma rules are active and how they were customized.
Findings history: Stored findings with rule, log type and severity, which show that matching ran over the centralized data.
Alert routing: Channel configuration for Slack or email, showing who receives notifications.
Correlation graph: Output that links findings across log types, useful when explaining how related events were connected.

Confirm in the OpenSearch documentation for your version which log types, detector options and correlation features are available, and check the Apache-2.0 terms for any bundled components you plan to redistribute.

Wazuh (GPL-2.0-only) collects events, decodes them and compares each one against a ruleset of over 3,000 built-in rules and decoders plus any custom rules you write. Matching events are written to local alert files and forwarded to the Wazuh indexer, where they can be reviewed in the dashboard. Alerts are mapped to MITRE ATT&CK, which helps explain detection coverage. For Safeguard 8.9, the evidence is less about a single log store and more about showing that collected logs from enterprise assets are decoded, analyzed and kept in a central index.

Alert files: alerts.log and alerts.json provide a local, machine-readable record of matched events.
Indexer forwarding: Configuration showing that alerts reach the Wazuh indexer, which is the central repository for review.
Ruleset version: The ruleset and decoder versions in use at the time of the assessment period.
Custom rule records: Version-controlled custom rules with the reason each one exists.
MITRE ATT&CK mapping: Alert fields that tie detections to techniques, supporting coverage discussions.

Confirm the ruleset count, file locations and forwarding behavior in the Wazuh documentation for your release. Review GPL-2.0-only obligations if you modify Wazuh and distribute it.

Nextcloud (AGPL-3.0-only) is a self-hosted file and collaboration platform. Its admin_audit app logs additional event information to a file, which makes it a log source to onboard into the central platform rather than a central platform itself. The log is written to audit.log in the data directory by default, or to a path you set with logfile_audit. Because Safeguard 8.9 asks for enterprise asset logs to be centralized, the work is to ship this file into your SIEM or indexer and show that it arrives.

Log location: The audit.log file in the data directory, or the path set with logfile_audit, which should be documented in your asset inventory.
Shipping evidence: Agent or pipeline configuration showing the file is forwarded to the central platform.
Arrival proof: Sample searchable events in the central store that match entries in the local file.
Configuration record: Settings for the app and logging level, kept under change control.
License note: AGPL-3.0-only applies to the software you run and to modifications you make available over a network, so review it with counsel before customizing Nextcloud.

Confirm the app availability, log fields and configuration keys in the Nextcloud admin manual for your server version.

Gaps that fail a log aggregation test

An assessor measuring Safeguard 8.9 looks past whether a log platform exists and asks whether the right sources feed it, with correct timestamps, controlled access and enough retention to be useful. The gaps below are the ones that most often turn a working SIEM into a failed measurement, and each one has a closing action the team can check before the assessment starts.

Log sources missing from the aggregator

A central platform only counts for the sources it actually receives. Servers, cloud control planes, identity providers, endpoints and network devices often send logs to local files while the aggregator covers only a subset. Compare the list of assets that produce audit logs with the list of sources the aggregator ingests, and record every gap with an owner and a date. Ask whether each excluded source is excluded by a documented decision or simply forgotten.

Sources without synchronized time

Events aggregated from hosts with drifting clocks cannot be ordered reliably during an investigation, which undermines the correlation that centralization is meant to provide. Confirm that every forwarded source uses the time synchronization set under Safeguard 8.4, and check the aggregator for events whose timestamps sit outside the expected window. Sources that stamp events in local time without a zone offset need a documented fix before they count as aggregated.

No inventory linking sources to assets

Assessors expect to trace each aggregated source back to an enterprise asset, which depends on the asset inventory from Safeguard 1.1 and the software inventory from Safeguard 2.1. Without those records, the team cannot tell whether a silent source means a failed forwarder or a decommissioned host. Maintain a mapping from each log source to its asset and software owner, and review it when assets are added or retired.

Aggregation without access control

A central log store often holds credentials in command lines, user activity and security events, so it becomes a target in its own right. Check who can query, export, alter or delete aggregated logs, and whether those rights are reviewed like any other privileged access. Confirm that administrators of the aggregator cannot quietly edit the records that the aggregator stores, and that access events on the platform are themselves logged.

Retention shorter than Safeguard 8.10 needs

Safeguard 8.10 sets a retention minimum of 90 days, and it is measured on the same aggregation tools that Safeguard 8.9 uses. If the aggregator rotates indexes or deletes data after a shorter period, the centralization may pass its own measure while failing 8.10. Compare the configured retention on the platform with the 90-day minimum, and check that archived data stays searchable for the period the process requires.

No evidence of coverage over time

A dashboard showing sources today does not prove that they fed the platform throughout the period an assessor reviews. Forwarders fail quietly after upgrades, certificates expire and cloud accounts are created outside the normal process. Keep periodic reports of ingestion volume and the last event time per source, and retain them with the audit log management process records. Ask whether a source going silent for a set period raises an alert.

Questions buyers ask about Safeguard 8.9

How much effort does centralizing audit logs under Safeguard 8.9 take?

The effort depends mostly on how many enterprise assets and log sources you need to onboard, how varied their formats are, and how much of the pipeline already exists. Effort falls into three parts: designing the collection architecture and retention settings, onboarding each source (agents, forwarders, syslog or API connections, parsing and field mapping), and validating that events arrive complete and correctly timestamped. Costs recur in the platform itself (compute, storage, licensing if you use a commercial SIEM) and in staff time for tuning and reviewing alerts. When requesting a quote, ask the provider to list each source class, the parsing work it includes, the storage model, and what acceptance testing covers.

How long does it take to onboard log sources into a central platform?

Onboarding time is driven by the number of source types, not the number of log lines. Standard operating system and identity logs are usually quicker to connect than custom business applications, which need parsers written and tested against real events. Other drivers include network access from sources to the collector, change approval windows, the state of asset inventories from Safeguards 1.1 and 2.1, and whether the sources already write to a consistent format. Ask any partner for a source-by-source plan with dependencies and acceptance criteria, rather than a single overall duration, and confirm which assets fall within the agreed scope.

Can our team centralize audit logs without an outside partner?

Yes, if your team has the skills and capacity to do the work. Safeguard 8.9 is an engineering and operations task rather than a document, so the team needs people who can deploy collection agents, manage storage and access to the central store, write or adapt parsers, and keep the pipeline healthy. Many organizations keep ownership in-house and bring in a partner for a fixed-scope build, or for specific pieces such as a self-hosted platform deployment or a hardening review. Whichever route you choose, the organization remains responsible for the control and its evidence, and an independent auditor or assessor decides whether the evidence is sufficient.

Does Safeguard 8.9 require a SIEM?

No. The Safeguard describes a result: collection and storage of audit logs from enterprise assets brought together in one central place as far as practical, following your audit log management process. CIS uses a SIEM as its example because a SIEM is a common way to aggregate many sources, but a central log store, a self-hosted log analytics platform or a managed service can also meet the intent. What matters to an assessor is that the aggregation exists, covers the in-scope assets, follows your documented process and can be shown working. Record the reasons for any assets left out of the central store.

How does Safeguard 8.9 relate to 8.10 and 8.11?

Safeguard 8.9 is the foundation for the other two. Safeguard 8.10 requires audit logs to be retained for at least 90 days, and the assessment specification measures that retention on the log aggregation tools from 8.9, so an unaggregated log estate makes retention hard to demonstrate. Safeguard 8.11 requires regular reviews of audit logs to find anomalies, and reviews are far easier to perform and to evidence when logs sit in one place with consistent fields and timestamps. Treat 8.9 as the dependency: if the central store is incomplete, retention and review evidence will be incomplete too.

What does the work need from our internal team?

The work needs named owners across several functions. Security or operations staff must decide which assets and sources are in scope and how the central store is secured. Infrastructure and application owners must allow agents or forwarders, confirm log formats and provide test events. Identity or cloud administrators must confirm which sign-in and administrative logs are available. Compliance staff should link the work to your audit log management process so that the documented requirements, the configuration and the evidence match. Ask for a written list of these responsibilities before work starts, along with the dependency on the inventories from Safeguards 1.1 and 2.1, which the assessment specification identifies as prerequisites for measuring 8.9.

What evidence shows that Safeguard 8.9 is met?

Assessors look for evidence that aggregation exists and works. Useful artifacts include the list of in-scope assets and their log sources, the architecture diagram showing collectors and the central store, configuration exports showing which sources forward, screenshots or queries that show recent events from each source, and records of the audit log management process that define scope. Gaps are typically visible as sources that stopped forwarding, assets missing from the inventory, or exceptions with no documented reason. Build the evidence as you deploy, not at audit time, and confirm with your assessor which format they accept.

How DeployOpen prepares centralized audit logs for assessment

DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, including the log collection and aggregation stack that Safeguard 8.9 depends on. For this Safeguard, that work usually means deciding which enterprise assets feed a central log platform, deploying the collectors and the aggregation tool in the client's cloud accounts, data centers or air-gapped networks, and writing down how the platform is operated. The organization still owns the decision to centralize, the audit log management process it follows, and the log sources it chooses to include. DeployOpen prepares the systems and the evidence that show the centralized platform is in place, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments and reach their own conclusions.

Preparation for assessment starts with the prerequisites the CIS Controls Assessment Specification names for this Safeguard. Measuring Safeguard 8.9 draws on the enterprise asset inventory from Safeguard 1.1 and the software inventory from Safeguard 2.1, so the engagement should confirm that both inventories exist and are current before log sources are mapped to them. DeployOpen can help assemble that mapping, export configuration evidence from the aggregation tool and keep a record of which assets forward logs, which do not and why. Ask each prospective partner to state in writing which of these artifacts they will produce, who will review them and who keeps custody of the evidence after handover.

Fixed-scope engagements suit this work because the Safeguard has a clear boundary: a defined set of log sources, a defined platform and a defined set of documents. Before work begins, the written scope should list the assets in and out of scope, the platform components to be deployed, the documentation to be delivered and the handover tests the client will run. DeployOpen issues a quote that follows from that written scope, so changes to the number of sources or the platform design are priced as scope changes. Ask for the quote to separate one-time build and documentation work from any recurring support or upgrade retainer, because the centralized platform will need ongoing operation after the engagement ends.

Safeguard 8.9 Centralize audit logs