What Safeguard 8.5 Collect detailed audit logs asks for
Safeguard 8.5 asks for detailed audit logging on enterprise assets that hold sensitive data, with each event recording its event source, date, username, timestamp, source and destination addresses, and the other elements an investigator needs to reconstruct what happened. If an auditor or customer asks whether your sensitive-data systems log enough to investigate an incident, this is the Safeguard they will measure against. The risk it addresses is a breach that is detected but cannot be explained: without fields that tie an action to a person, a host and a moment in time, the organization cannot scope the incident, prove what data was touched, or meet its own reporting duties. CIS places this Safeguard in the Data asset class and the Detect security function, and assigns it to IG2 and IG3 rather than IG1. The reasoning is that IG1 covers essential hygiene for every enterprise, while detailed forensic logging takes more operational maturity and is most valuable where sensitive information and sophisticated attackers are both present.
The hard part is rarely turning logging on. Most organizations already have logs; the gaps are usually in the fields. A default application log may record that an action occurred but omit the authenticated user, the source address or the destination of a connection, so the entry looks complete while failing the investigation. The other common gap is scope: sensitive-data assets that nobody inventoried are never configured at all. The Assessment Specification lists the enterprise asset inventory from Safeguard 1.1 as a prerequisite for measuring Safeguard 8.5, so the inventory of sensitive-data assets is the first document to produce. Confirm with the CIS Controls Assessment Specification which measures and metrics apply to your environment, and check that the event fields your tools emit match the list in this Safeguard.
Practically, pick a sample of assets that hold sensitive data, export a few representative events from each, and check whether every required element is present and populated. Record the result against the inventory, and treat any asset that cannot produce these fields as an open item with an owner and a date. Ask any implementation partner or auditor to show this sample check, because a configuration screenshot alone does not show that the fields reach the log store. Open-source platforms vary in how much detail they write by default, so confirm each product's audit settings with its vendor before scoping the work. For example, Nextcloud's admin_audit app writes additional event information to a file set by logfile_audit, while OpenBao audit devices record every API request and response in JSON, with most sensitive values hashed. Each of these must be checked against the fields the Safeguard names.
Which assets and teams fall under Safeguard 8.5
Safeguard 8.5 applies only to enterprise assets that hold sensitive data, so the first work is deciding which systems qualify. Each decision below changes how many sources need detailed logging and who must sign off on the configuration.
Sensitive data assets in the Data class
Safeguard 8.5 sits in the Data asset class, so the scope starts with the systems that store or process sensitive data. Use the data inventory and classification work from Control 3 to name those systems. A file server holding customer records falls in scope, while a kiosk that only displays public signage usually does not. Check whether sensitive data is copied into logs, backups or reporting databases, because those copies can pull additional assets into scope.
Asset inventory from Safeguard 1.1
The CIS Controls Assessment Specification lists the enterprise asset inventory from Safeguard 1.1 as a prerequisite for measuring Safeguard 8.5. Without a current inventory, you cannot show that every sensitive-data asset produces detailed logs. Reconcile the inventory against the classification list, and treat any asset missing from both as an open scoping gap rather than an exception to document and move on from.
Applications and their internal audit features
Business applications often record events in their own audit trails rather than in the operating system log. Each in-scope application needs its audit features enabled, its log file location known, and its fields checked against the event source, date, username, timestamp and address elements the Safeguard describes. For example, Nextcloud's admin_audit app writes extra event detail to a separate audit.log file, so that setting must be turned on and collected deliberately.
Third-party hosted systems
Software-as-a-service platforms and other hosted systems that store sensitive data may not be enterprise assets you control. Decide whether each one sits in scope, then confirm what detailed audit events the provider exposes and how you export them. Contracts should state log access and retention. Where the provider cannot supply the fields, record the gap and the compensating control, because assessors will ask how the requirement is met for that system.
Logging configuration ownership
Detailed logging is set in several places: operating systems, applications, identity platforms and the aggregation tool. Assign an owner to each source so changes are approved and recorded. Infrastructure teams usually own host settings, application teams own application audit features, and security operations owns collection into the central store. Without named owners, a configuration change in one team can silently remove fields the assessor expects to see.
Scope changes and periodic checks
Scope is not fixed at the start. New systems, data migrations and reclassifications can move assets in or out of the Data class. Build a recurring check that compares the classification register and asset inventory against the logging configuration, and record each decision with its date and approver. This check is the evidence that the scope still matches reality when an assessor asks, and it determines how much re-work each change creates.
How an assessor tests detailed audit logging
This table compares the assessment steps, the evidence an assessor usually asks for and the findings that tend to come up for Safeguard 8.5. Read it as a preparation checklist: the CIS Controls Assessment Specification defines what is measured, while the independent auditor decides the conclusion.
| Assessment step | Evidence requested | Common findings |
|---|---|---|
| Establish the asset scope using the Safeguard 1.1 inventory | Enterprise asset inventory export showing which assets hold sensitive data, with owners and classification | Inventory omits cloud workloads or SaaS tenants, so the sensitive-data population the assessor samples is incomplete |
| Confirm the process for detailed logging exists | Documented logging requirements from the audit log management process, naming the event fields expected on sensitive-data assets | Field lists are generic and do not mention source and destination addresses, usernames or timestamps |
| Measure completeness of process | Approved process document, review dates and evidence that logging standards were applied to new sensitive-data assets | Process exists on paper but is not applied to assets added after the last review |
| Measure logging coverage on sensitive-data assets | Sampled asset list with log configuration exports showing the required event fields are enabled | Logging is enabled on some assets but key fields such as source address or username are missing |
| Sample assets across sensitive-data categories | Log samples from each sampled asset, showing event source, date, username, timestamp and addresses for a defined period | Samples come from the most mature systems only, while legacy or cloud-hosted stores produce no detailed records |
| Test forensic usefulness of the records | Sample events traced end to end, for example an authentication event matched to its session and destination | Timestamps are not synchronized across assets, so events cannot be correlated during an investigation |
| Check that logs are protected and retained | Access controls on log stores and retention settings that match the audit log management process | Detailed logs are written locally and overwritten before the assessor's sample period |
| Record results against the four measures | Assessor working papers showing measure results combined into the completeness and coverage metrics | Results are reported only as a yes or no, without evidence for each measure, so remediation is unclear |
How to implement detailed logging on sensitive-data assets
This sequence takes Safeguard 8.5 from an asset list to a tested ability to reconstruct an incident, with a written record at each stage that an assessor can follow. Each step produces an artifact the organization owns, whether or not an implementation partner helps.
Confirm the sensitive-data asset list
Start from the enterprise asset inventory that Safeguard 1.1 calls for, then filter it for assets that store, process or transmit sensitive data. The data owner or business unit should confirm the list, because the inventory alone does not show which systems hold regulated or confidential records. The output is a scoped asset register that names each in-scope system, its owner and the data classes it holds. Done means every system in scope has a named owner who has signed off on the list.
Define the minimum field set per log source
Using the audit log management process from Safeguard 8.1, write down for each log source the fields that must be present in every event. The minimum set should cover event source, date, username, timestamp, and source and destination addresses, plus any other fields the organization needs for forensic work, such as the action performed and the outcome. The output is a field matrix that maps each asset type to its required fields and to the person accountable for it. Done means the matrix has been approved and stored with the process documentation.
Enable and configure logging on each asset
Turn on audit logging on each in-scope asset according to the field matrix, and record the exact settings used. For example, an application such as Nextcloud can write its admin_audit output to a dedicated file through the logfile_audit setting, and secrets management tools such as OpenBao expose audit devices with their own configuration. Platform engineers or the system owner perform the change through the normal change process. The output is a configuration record per asset showing the settings, the version and the date of change. Done means each asset has a record that matches the field matrix.
Verify fields in sample events
Generate test activity on each configured asset, such as a sign-in, a failed authentication, a permission change and a data export, then open the resulting log events. Check that each required field is present, populated and correctly timestamped. Where a field is missing, correct the configuration and repeat the test rather than accepting partial events. The output is a verification log with sample event excerpts, the test performed and the result for each field. Done means every required field appears in events from every in-scope source.
Centralize and confirm coverage
Forward the verified logs to the central log store or SIEM that Safeguard 8.9 describes, and confirm that events arrive intact and in the expected format. Compare the inventory from the first step with the sources that actually report, so that any asset without logs appears as a gap. The output is a coverage report listing each in-scope asset, its log source, the forwarding status and any open gaps with owners. Done means the coverage report accounts for every asset in the scoped register.
Test a reconstructed incident
Run a tabletop or technical exercise in which the team reconstructs a realistic sequence of actions on a sensitive-data asset using only the centralized logs. The exercise should answer who acted, what they did, when, from where and to where. Record each question the team could not answer, because those gaps point to missing fields or sources. The output is an exercise record with findings and assigned fixes, which feeds back into the field matrix. Done means the team can answer the core questions for each scenario, or the gaps have owners and dates in the process.
Evidence that passes Safeguard 8.5
An assessor testing Safeguard 8.5 wants to see that detailed logging is configured, that the right fields are present in real events, and that the coverage is complete for sensitive assets. The artifacts below connect those three checks, and each one goes stale as systems change, so the refresh plan matters as much as the first snapshot.
Field-level configuration exports
Export the logging configuration from every system that holds sensitive data, showing which event categories are enabled and which fields they record. For Nextcloud, the admin_audit app writes additional event information to audit.log, and the configuration should show where that file is kept, including any path set with logfile_audit. Check that each export names the fields Safeguard 8.5 lists: event source, date, username, timestamp, and source and destination addresses. Re-export after every upgrade or configuration change, and store exports in version control so the diff shows who changed what and when.
Sample log events with required fields
Pull real events from each in-scope system and place them beside the field list the assessor will test against. A sample should show a username, timestamp, event source and, where the event involves network activity, source and destination addresses. Samples taken from a test account are useful, but add production samples too, because test traffic often omits fields that real sessions populate. Schedule a fresh sample pull each quarter and retain the dated set, so a regression in a field shows up before an assessment does.
Coverage report by asset
Produce a table that maps each enterprise asset holding sensitive data to its logging source, the destination it writes to, and the date it last sent an event. Start from the asset inventory required by Safeguard 1.1, since the CIS assessment specification treats that inventory as a prerequisite for measuring Safeguard 8.5. Flag any asset that holds sensitive data but shows no logging source. Generate the report from the inventory and the log platform rather than by hand, and rerun it on a fixed schedule so newly provisioned systems are added.
Centralization and retention settings
Capture the configuration of the aggregation point that receives detailed logs, including forwarding rules, storage location, and retention period. Assessors compare these settings against the audit log management process from Safeguard 8.1 and check that detailed logs from sensitive-data assets are not dropped or filtered out before they arrive. Record the retention value as configured and the date it was last changed. Confirm the setting after each platform upgrade, because default retention and forwarding behavior can change between releases.
Audit records of logging changes
Keep change records for every modification to logging scope, including enabling or disabling an audit device, adding a field, changing a log path, or excluding an asset. Each record should name the approver, the reason, and the date. OpenBao audit devices, for example, keep a detailed JSON log of every API request and response, with most sensitive values hashed using HMAC-SHA256, so changes to audit device configuration should appear in both the platform log and the ticket that authorized them. Review these records at the same cadence as the coverage report, so gaps between approved and actual configuration are caught early.
Open-source platforms that produce detailed audit logs
Nextcloud is a self-hosted file sharing and collaboration platform. Its admin_audit app records additional event information beyond the standard server log and writes it to audit.log in the data directory, or to a path you set with logfile_audit. You configure the app and its output through the Nextcloud logging settings, so the evidence is only as complete as those settings and the events the app covers in your version.
- Enable and scope the app: Turn on admin_audit and confirm it is active on every node in a multi-server deployment, so no node writes an incomplete trail.
- Set a protected log path: Use
logfile_auditto move audit entries to a location with restricted write access, separate from routine application logs, and limit who can read or delete the file. - Check field coverage: Compare the entries with your own list of required elements, such as username, timestamp, event source, and source and destination addresses, and record any gaps.
- Plan retention and forwarding: The file grows on local disk, so define rotation, retention and a route to central storage that supports your log retention and centralization obligations.
- Account for the license: Nextcloud is licensed under AGPL-3.0-only, which carries network copyleft obligations if you modify the software and make it available to users over a network. Confirm with counsel how this applies to your deployment.
Before you cite the file as evidence, generate test events in your own environment and confirm that every field you have committed to collect appears in the output.
OpenBao is an open-source secrets management platform. Its audit devices keep a detailed JSON log of every API request and response, including errors, and most sensitive values are hashed with HMAC-SHA256 before they are written. This makes the log a strong source for evidence about who requested access to secrets and what the platform did with those requests, but the exact content depends on the device type and configuration you choose.
- Enable at least one audit device: Check the OpenBao audit devices documentation for the device types available and where each one writes its output.
- Understand what is hashed: HMAC-SHA256 hashing covers most sensitive values, so confirm which fields remain readable and whether hashed values still let investigators correlate events for the same secret.
- Test with failed and successful requests: Because the log records errors, generate both kinds of request from known accounts and compare each entry with your list of required fields, such as username, timestamp, source address and request path.
- Handle retention and forwarding: Decide where the JSON output goes, how long it is kept, how it reaches your central log store, and how you prevent edits or deletion on the device path.
- Review the license: OpenBao is licensed under MPL-2.0, a file-level copyleft license, so modifications to MPL-licensed files you distribute must remain available under that license. Confirm with counsel how your changes and any distribution affect your obligations.
Before relying on the log, run a controlled test and keep the output as part of the evidence set, so you can show exactly which fields an assessor will see.
The CIS Controls Assessment Specification for Safeguard 8.5 measures two things: the completeness of the logging process and the coverage of logging across assets. An assessor will therefore look for a list of assets that hold sensitive data, proof that each one produces the required fields, and evidence that the logs are kept and reviewed. The CAS lists the enterprise asset inventory (Safeguard 1.1) as a prerequisite because it tells you which systems must be checked.
- Build the asset list first: Use your inventory to identify every system that stores sensitive data, then mark which platforms in this section apply to each one.
- Create a field matrix: For each platform, list the fields you have committed to collect, such as event source, date, username, timestamp, and source and destination addresses, and record the result of a test event for each field.
- Document retention and forwarding: Keep configuration exports, retention settings and forwarding rules that show logs reach central storage and survive local rotation.
- Record license obligations: Keep a register of the license for each platform, including the AGPL-3.0-only and MPL-2.0 terms, and the advice you received on what they require.
- Separate preparation from assessment: An implementation partner can prepare the systems, logs and evidence, but only an independent auditor or assessor reaches a conclusion on whether Safeguard 8.5 is met.
Ask your assessor, before testing begins, which sample of assets and which test events they will use, so your evidence set answers their questions directly.
What meeting Safeguard 8.5 costs in money and effort
This table breaks down the cost components of meeting Safeguard 8.5 by who is paid, whether each cost is one-time or recurring, what drives it up and how to keep it down. Use it to structure a quote request, since no price is published here and every figure depends on your own asset count, data volume and log sources.
| Cost component | Who is paid | One-time or recurring | What drives it up and how to keep it down |
|---|---|---|---|
| Logging platform licenses | Software vendor, if a commercial SIEM or log platform is chosen | Recurring | Driven by ingestion volume and log sources. Open-source collectors remove license spend but not the infrastructure to run them. Ask whether pricing scales by events, data volume or assets. |
| Field configuration of audit logging | Internal engineers or an implementation partner | One-time, with periodic updates | Driven by the number of asset types and sensitive-data systems. Standardize one logging profile per asset class to reduce repeated work. Ask for the configured fields listed against the Safeguard 8.5 elements. |
| Storage and SIEM ingestion | Cloud provider, data center team or log platform vendor | Recurring | Driven by sensitive-data volume, verbosity of detailed logs and retention length. Filter low-value events at source where policy allows. Ask for projected monthly volume per log source. |
| Asset discovery and data scoping | Internal asset owners, with help from a partner if needed | One-time, then recurring as assets change | Safeguard 8.5 depends on knowing which assets hold sensitive data, and the assessment specification lists the asset inventory from Safeguard 1.1 as a prerequisite. Keep the inventory current to avoid re-scoping. |
| Evidence collection and upkeep | Internal compliance or security staff | Recurring | Driven by how often configurations change and how many systems must show coverage. Automate exports of logging configuration and coverage reports. Ask whether the partner delivers repeatable evidence scripts. |
| External testing or review | Independent assessor or an outside security firm | Recurring, per assessment cycle | Driven by the framework requiring the review (for example, a SOC 2 or PCI DSS assessment) and the number of in-scope systems. Scope the review to Safeguard 8.5 coverage where your framework allows. Ask for scope and deliverables in writing. |
| Auditor sampling and testing | Independent auditor or assessor, paid by the organization | Recurring, per audit cycle | Driven by the number of systems and log samples the auditor selects. Keep logs complete and searchable so samples can be produced quickly. Ask the auditor which log fields and time windows they will sample. |
| Ongoing support and retainers | Implementation partner, if engaged | Recurring, if chosen | Driven by the scope of upgrades, monitoring and log tuning. Limit retainers to the systems that change often. Ask for the support scope, response expectations and what is excluded. |
Who does what for Safeguard 8.5
Your organization owns Safeguard 8.5. Only you can decide which enterprise assets hold sensitive data, what the detailed logs must capture for those assets and how long the logs are kept. The CIS Controls Assessment Specification treats the enterprise asset inventory from Safeguard 1.1 as a prerequisite, so your team must be able to show which systems are in scope and why. Ownership also means the reviews are yours to perform and record, not a vendor's.
- Sensitive-data asset list: Maintain the register of assets that hold sensitive data, linked to the inventory and approved by the data owner.
- Log content decisions: Decide which event source, date, username, timestamp, source and destination address fields are required for each asset class and document the reasons.
- Retention decisions: Set retention periods with legal, compliance and forensics input, and record them in the audit log management process.
- Reviews and sign-off: Carry out and record periodic checks that logging still runs on the listed assets, and track exceptions to closure.
- Staff capability: Keep at least one named person able to explain the logging design to an assessor.
Before any outside work begins, confirm that your sensitive-data list and logging decisions exist in writing and that someone internal can answer assessor questions about them.
An implementation partner such as DeployOpen can prepare the systems and the evidence under a written scope. Typical work includes configuring detailed logging in self-hosted platforms, building field matrices that map each required element to its source, setting up centralization into your log store and assembling evidence packs. The partner works inside your infrastructure and reports to your team. It does not decide what is sensitive, and it does not decide whether the result meets Safeguard 8.5.
- Configuration: Enable detailed audit output in the platforms in scope, for example the
admin_auditapp in Nextcloud, which writes toaudit.logor a path set withlogfile_audit, or OpenBao audit devices that record API requests and responses. - Field matrices: Document, per platform, which required fields are captured, where they are stored and how they are hashed or redacted.
- Centralization and time sync: Route logs to the central store and verify that timestamps are consistent across the sources.
- Evidence packs: Collect configuration files, sample log entries and screenshots with dates, labelled for the assessor.
- Scope limits: Work is fixed in writing, so any change to the asset list or log fields is a documented change order.
Ask the partner which parts of the work it will perform, which it will leave to your staff and how it will hand over configuration and evidence in a form you can keep.
The independent auditor, assessor or certification body tests whether Safeguard 8.5 is implemented and issues the conclusion. It uses the measures and metrics in the CIS Controls Assessment Specification, which cover completeness of process and logging coverage, and it samples your assets and log records to check them. Independence means the auditor cannot be the party that configured the logging and then certified it. For that reason, the partner prepares evidence but never issues the assessment result.
- Testing: The auditor selects assets, requests log samples and checks that required fields appear for a sample period.
- Conclusion: Only the auditor states whether the Safeguard is met, and in what form the report or attestation is issued.
- Independence: The auditor must not design the controls it assesses, and the partner must not sign the auditor's conclusion.
- Access: Plan read-only access to log stores and configuration for the auditor, and record each request and response.
- Mapping questions: Confirm with the auditor which framework, such as ISO/IEC 27001 Annex A or SOC 2, the evidence will be used for.
Before engaging an auditor, confirm its independence rules, the evidence format it expects and whether the CIS Controls assessment is a fit for your reporting need.
Where Safeguard 8.5 logging usually falls short
Most teams have some audit logging switched on, so the gaps are rarely about having no logs at all. They sit in which assets are covered, which fields are actually recorded, whether copies survive an incident, and whether anyone checks the result. Each card below names one gap and the action that closes it.
Fields missing from enabled logs
Logging can be turned on while the entries still omit the username, source address or destination address that an investigator needs. Safeguard 8.5 asks for event source, date, username, timestamp, and source and destination addresses, among other forensic elements. Pull a sample of entries from each sensitive asset and check every required field is present and populated. Where a field is missing, change the logging configuration on that asset and re-test the sample.
Sensitive assets missing from inventory
Detailed logging only applies to enterprise assets that hold sensitive data, so an asset left out of the inventory is usually left out of logging too. The assessment specification treats the enterprise asset inventory from Safeguard 1.1 as a prerequisite for measuring Safeguard 8.5. Cross-check the asset inventory against the data classification records, then confirm each sensitive system appears in the inventory with an owner and a logging status.
Timestamps that do not correlate
Detailed events are only useful for forensics if they can be placed in the same order across systems. Hosts that drift from one another produce entries that look out of sequence, which slows investigations and can hide the real order of actions. Confirm each in-scope asset syncs to the agreed time sources and that log entries record the time zone or offset in a consistent format. Sample events from two systems involved in one transaction and compare their times.
Logs stored only on the asset
A detailed log that lives only on the machine it describes can be deleted or overwritten by an attacker who gains control of that machine. Safeguard 8.5 logs need a copy that is sent to a central location, such as a SIEM or log store that the asset's administrators cannot quietly edit. Confirm that each sensitive asset forwards its audit logs to the central platform, and test that a deliberately generated event arrives there.
No evidence of field verification
Logging configurations drift after upgrades, new applications and changed audit policies, and nothing in the logs will announce that a field has dropped out. Without a recorded check, an assessor has no evidence that the detailed logging still works today. Set a recurring verification task that samples logs on each sensitive asset, records the result and the person who checked it, and opens a ticket for any gap. Keep these records as evidence of the measurement.
Undocumented logging exceptions
Some systems cannot produce every required field, and teams often disable logging on them without a record. An undocumented exception looks identical to a forgotten asset during assessment. For each asset where detailed logging is not enabled or not fully possible, record the reason, the compensating control, the risk owner who accepted it and a review date. Store the exception list with the audit log management process so the gap is visible and governed.
Questions buyers ask about Safeguard 8.5
How much does it cost to meet Safeguard 8.5 detailed audit logging?
No price for this Safeguard is published, so the cost depends on the scope you agree in writing. The main cost drivers are the number of enterprise assets that hold sensitive data, how many event fields each log source must capture, how much log storage and search capacity the retention period needs, and whether logs flow into an existing SIEM or a new one. Expect one-time costs for design, configuration and onboarding, and recurring costs for storage, log platform licensing or hosting, and periodic review of the logging rules. Ask any provider to split the quote into these items and to state which assets are in scope and which logs are excluded.
How long does Safeguard 8.5 implementation take?
No timeline figures are supplied for this Safeguard, so no duration can be given with confidence. The schedule depends on how many sensitive-data assets need detailed logging, how many of them already produce usable audit records, how many log formats must be normalized, and how quickly your team can approve field lists and test alerts. Ask for a written scope with phases, milestones and dependencies before work starts. A fixed-scope agreement makes the timeline visible and lets you check progress against named deliverables.
What does my team need to provide for Safeguard 8.5?
Safeguard 8.5 depends on knowing what you have, so the assessment specification treats the enterprise asset inventory from Safeguard 1.1 as a prerequisite. Your team should supply an accurate list of systems that hold sensitive data, owners who can confirm which event fields matter for investigations, access to those systems and their existing logs, and decision-makers who sign off on retention and privacy limits. Security operations staff also need to agree on how logs will be searched and reviewed. Without these inputs, the logging design will be guesswork.
Can we meet Safeguard 8.5 in-house with open-source platforms?
Yes, many organizations do, provided they have engineers who can configure logging on each platform and run the log pipeline. Open-source platforms can produce detailed records. For example, Nextcloud's admin_audit app writes additional event information to audit.log, and OpenBao audit devices keep a detailed JSON log of API requests and responses with most sensitive values hashed. Your team must still confirm that each platform captures the fields Safeguard 8.5 names, that records are forwarded to central storage, and that someone owns the logging design. DeployOpen can implement and harden these platforms inside your environment if you prefer outside help, but the organization keeps ownership of the controls.
Will an assessor accept the CIS Controls assessment specification as the test basis?
The CIS Controls Assessment Specification defines the measures and metrics used to verify that a Safeguard is implemented, including the four measures for Safeguard 8.5 that roll up into completeness of process and logging coverage. It describes what to measure, not how, so acceptance depends on your engagement. Some assessors use it directly, while others map it to the framework they are auditing against, such as ISO/IEC 27001:2022 Annex A 5.28 and 8.15, SOC 2 CC5.2 and CC7.2, or PCI DSS v4.0 requirements 10.2 and related items. Confirm with your assessor which basis they will use, and remember that only an independent auditor or assessor issues reports or certificates.
Why don't IG1 organizations need Safeguard 8.5?
CIS assigns Safeguard 8.5 to Implementation Groups 2 and 3, not IG1. IG1 is defined as essential cyber hygiene, a minimum standard for every enterprise, and it focuses on basic audit log collection, storage, time synchronization and retention. IG2 adds Safeguards for enterprises with more operational complexity that often hold sensitive information, and detailed logging on sensitive-data assets fits that profile. IG1 organizations should first establish reliable collection and retention. Moving to detailed logging becomes relevant when you hold sensitive data and need records that support forensic investigation.
What risks come with detailed audit logging?
Detailed logs capture usernames, addresses and activity, so they can contain personal data and sensitive operational details. Privacy and security teams should decide which fields are necessary, how long they are kept, who can read them and how access is audited. Logs can also grow quickly, which affects storage and search performance, and poorly tuned collection can hide useful events in noise. Protect the log store against tampering and unauthorized deletion, and test that a sample investigation can actually answer its questions. Confirm these design choices in writing before implementation.
How DeployOpen scopes and prepares Safeguard 8.5 evidence
DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure. For Safeguard 8.5, we prepare detailed audit logging on the sensitive-data assets in scope and the evidence that shows it works, while the organization owns the control and an independent assessor reviews it.
How we scope
- We confirm which enterprise assets holding sensitive data fall inside the Safeguard 8.5 scope, starting from the asset inventory.
- The written scope lists the log fields to capture, such as event source, date, username, timestamp and source and destination addresses.
- We agree the assets, deliverables and timelines in writing before work starts, since most engagements are fixed-scope.
How we build
- We configure detailed audit logging on the in-scope self-hosted platforms within your cloud accounts, data centers or air-gapped networks.
- We check that each in-scope platform records the agreed fields and sends them to the log destination defined in your process.
- We test coverage against the measures in the CIS assessment specification and record gaps with owners and fixes.
How we hand over
- We document the logging configuration, field lists, coverage results and the procedure for adding new sensitive-data assets.
- We deliver sample log records and a coverage map that your assessor can trace back to each Safeguard 8.5 measure.
- Your team owns the controls and the resulting evidence, and an independent auditor or certification body issues any report or certificate.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover re-checking logging coverage when new sensitive-data assets or platform versions are added.
- Ask any provider to confirm in writing which logging fields and assets are included before you sign.
