What Safeguard 8.1 asks for before any log is collected
Safeguard 8.1 asks for a written audit log management process that sets your logging requirements and explains, at minimum, how audit logs from enterprise assets are collected, reviewed and kept. The process must itself be reviewed once a year or after significant enterprise changes. If an auditor, a customer questionnaire or a new CIS Controls program asks for proof that logging is governed rather than merely switched on, this document is the first thing they will request. CIS classifies the Safeguard under the Govern security function and the Documentation asset class, and it sits in Implementation Group 1, so every enterprise following the Controls is expected to have it. Safeguards 8.2 through 8.12 then implement what this process sets, from collection and storage to centralization, retention and review, so the process is the reference point that makes the later technical work testable.
The risk this Safeguard addresses is logging that exists on paper or varies from team to team. One group may forward firewall events to a central store while another keeps server logs on local disks for a few days, and nobody can say which systems are covered or how long evidence survives. A written process forces the decisions into the open: which asset classes produce logs, who owns each log source, who reviews them and how long they are kept. Ask your team to name the owner of each decision in a draft before anything is configured, because unclear ownership is the most common reason the document is never finished. The document also goes stale quickly. Systems are added, cloud accounts change and staff move on, so a process written once and filed away will fail the annual review test. Plan for a named owner, a review date and a trigger list that includes significant enterprise changes. CIS publishes the CIS Controls Assessment Specification, which defines the inputs, measures and metrics an assessor uses to verify Safeguard 8.1. It states what to measure but not how, so your organization still chooses the format, approval path and level of detail. Read the CIS Controls Assessment Specification entry for 8.1 before drafting, and confirm with your assessor how they will evaluate the completeness of the three elements it names.
Which systems, data, teams and providers the process must cover
The audit log management process has to name what it covers before anyone can measure it. Each card below is one scoping decision that changes the collection, review and retention work, and the process is where the organization records those decisions and any exclusions with their reasons.
Enterprise assets in scope
Start with an inventory of the endpoints, servers, cloud workloads, network devices, identity systems and SaaS applications the enterprise runs. Safeguard 8.1 asks the process to say how logs from enterprise assets are collected, so an asset missing from the scope statement is an asset with no logging rule. Check that the list matches the asset inventory maintained under Control 1 and Control 2, and record the owner of each asset class.
Excluded asset classes and reasons
The process is the place to decide which asset classes are excluded from logging and why, such as an isolated test lab or a device that cannot generate audit events. Write each exclusion with its reason, the compensating control, and the person who approved it. An assessor reviewing the process will look for exclusions that were never discussed, so a short, justified list is easier to defend than an unstated gap.
Data classes that raise logging depth
Assets that hold sensitive data need more detailed logging than assets that do not. Identify which data classes, such as personal data, payment data or health records, sit on which systems, because those classifications decide where the detailed logging Safeguards apply. Confirm the classification scheme with the data owners before writing the process, since the depth rules depend on it.
Teams that generate and consume logs
IT operations, security operations and application owners each produce or read different logs, and the process should name who owns collection, who performs the reviews and who receives alerts. A gap between teams is a common reason logs exist but nobody reviews them. Assign a named role for each log source and confirm that each role has access to the logs it must review.
Third-party hosted services
SaaS platforms, managed cloud services and outsourced infrastructure often keep their own audit trails, and the enterprise must obtain them to meet its own requirements. List each hosted service, the events its provider logs, how the enterprise receives those logs, and how long the provider keeps them. Contracts should state the log access terms, because a provider that cannot supply the logs leaves a gap the enterprise still owns.
Requirements for the process itself
The process should also state how often it is reviewed, which is at least once a year and after significant enterprise changes, and who approves each revision. Keep the approval record with the document. An assessor testing Safeguard 8.1 will check the review date, so an unreviewed scope from a prior year fails the test even when the logging itself is working.
How an assessor tests the audit log management process
This table sets out how an assessor approaches Safeguard 8.1, from the test approach and evidence requests to the findings that most often fail a review. Read it as a checklist for preparing the process document before an assessment starts. The main takeaway is that a written process is only half the test: the assessor also checks that it names all three elements, has been reviewed within the last 12 months and reflects the systems actually in use.
| Assessment area | What the assessor checks | Evidence requested | Common findings |
|---|---|---|---|
| Written process exists | Whether a documented audit log management process is in place and approved for the enterprise | The approved process document and its approval record | No document exists, or logging practice is described only in tickets or tribal knowledge |
| Three elements covered | Whether the process addresses collection, review and retention of audit logs from enterprise assets | The process text mapped to the three elements, with the section numbers that cover each | Document covers collection only, or retention is mentioned without a period or storage location |
| Completeness measure | The share of the three elements (collection, review, retention) the process includes; the assessor selects the method used to confirm it | Annotated copy of the process showing where each element appears | Assessor counts elements that are named but have no operational content |
| Last review date | Whether the most recent review took place within 12 months of the assessment date | Review record with date, reviewer name and the outcome of the review | Last review more than 12 months old, or review dated but never signed off |
| Review after significant change | Whether significant enterprise changes, such as a new SIEM, cloud migration or merger, triggered a review of the process | Change records or change tickets linked to a process review | No change-triggered review recorded after a major platform migration |
| Version control | Whether the process has a version history showing what changed, when and who approved it | Version history, change log and approval for each version | Document overwritten in place with no record of prior versions |
| Process matches systems | Whether the stated collection, review and retention practices match the systems in use | Sample of enterprise assets with logging settings and retention configuration | Process names a SIEM or retention period that does not match the deployed tools |
| Ownership | Whether a named role owns the process and is accountable for reviews | Role description or responsibility assignment in the document | Document lists elements but no owner, so no one is accountable for the review date |
How to write, approve and keep the 8.1 process current
This sequence turns Safeguard 8.1 into a working document with a named owner, a known set of log sources, set logging rules and a review cycle. The result is a process that exists and is current before Safeguard 8.2 collection is measured.
Name an accountable owner and approvers
Assign one named owner who is accountable for the audit log management process and its annual review, then list the approvers, typically security leadership and the teams that run logging platforms. The output is a short ownership record stating who writes, who approves and who answers assessor questions. Confirm the owner has authority over the logging tools that the process will govern, because a process that no one can enforce will not pass a review of its operation.
Inventory asset classes and log sources
List the enterprise asset classes in scope (devices, software, data, users, network and documentation) and, for each, the systems that produce logs, such as operating systems, applications, identity providers, network devices and cloud control planes. The output is a log source register that names each source, its asset class and the team that operates it. This register is the input that makes the collection, review and retention rules concrete rather than general.
Set logging requirements for collection and review
For each log source, write the collection requirements: what events are logged, where they are sent, and who reviews them and how often. Record the review cadence as a stated rule, since the Safeguard 8.1 assessment specification checks whether the last review is within 12 months, and Safeguard 8.11 sets a weekly or more frequent review expectation for the logs themselves. The output is a requirements table that a reviewer can check line by line against the log source register.
Set retention rules and define off-cycle triggers
Document how long each log category is kept and where it is held, then define the events that force an unscheduled review of the process, such as major platform changes, mergers, acquisitions or a new regulatory obligation. The output is a retention schedule and a trigger list. Safeguard 8.1 expects the process to be reviewed after significant enterprise changes as well as annually, so the trigger list is part of what an assessor will test. Ask your legal and records teams to confirm any retention periods that a regulator or contract sets.
Publish under version control with access rights
Store the document in a controlled location, such as a wiki or document management system that keeps page history, and restrict edit rights to the owner and approvers while leaving read access to staff who run logging. Record each version with its date, author and approval. The output is a published, versioned document with an approval history. Test that a previous version can be retrieved, because assessors ask for the version in force on a given date.
Schedule and record the annual review
Put the annual review on a recurring calendar owned by the process owner, and record each review in a review log with the reviewer, the date, the changes made and the approvals obtained. A review that changes nothing still needs a record. The output is a review log showing the last review date, which is the evidence the assessment specification uses to decide whether the process is current. Confirm with your assessor how they expect review evidence to be presented.
Link the process to Safeguard 8.2 collection
Map each collection requirement in the process to the Safeguard 8.2 work that enables it, naming the platform, configuration owner and verification method for each source. The output is a traceability table from the process to the collection tasks. Safeguard 8.2 lists Safeguard 8.1 as a prerequisite, so the process should be approved and dated before collection is measured. Keeping this link explicit lets you show an assessor that collection was built from the documented requirements.
Evidence that proves the 8.1 process exists and is current
Safeguard 8.1 is tested on two things: whether a written audit log management process exists, and whether it was reviewed within the last 12 months. The cards below are the records an assessor will ask for to show both, along with the process content and the staff communication behind it. Each record should link back to the process document, so a single review cycle keeps all of them current.
Approved process document with owner
The core artifact is a written audit log management process that names the owner, sets logging requirements, and explains how logs from enterprise assets are collected, reviewed and kept. Record the approver and the approval date on the document itself, not only in a separate tracker. Check that the owner is a named role with authority over logging, and that the document covers all three completeness elements: collection, review and retention. Keep the current approved copy in a controlled location that staff can reach.
Version history of changes
Version history shows how the process evolved and who changed it. Use a platform that records each edit with a timestamp and author, such as the version control built into XWiki, so an assessor can see changes between any two versions. Confirm that every approved version is retained and that rollbacks are themselves logged. A history with no entries for the past year is a signal that the process has not been maintained, even if the current text looks complete.
Annual and off-cycle review records
Each annual review needs a dated record showing who reviewed the process, what they checked, and whether changes were made. Safeguard 8.1 also calls for a review after significant enterprise changes, such as a new SIEM, a cloud migration or a merger, so keep a separate record for each off-cycle review and link it to the change that triggered it. Set a calendar reminder for the annual review date and create a change ticket for each significant change that references the process document.
Log source mapping to the process
A current inventory that maps each log source, such as servers, identity systems, applications and network devices, to the process shows that the process covers the enterprise's actual assets. Note the log type, the collecting system and the owner for each source. Compare the mapping against the asset inventory from Control 1 at each review, since a source missing from the mapping is a gap an assessor will find. Store the mapping as a maintained file that the process document references.
Retention and review schedule
A written schedule states how long each log category is kept, where it is stored, and how often it is reviewed. Retention and review are two of the three completeness elements, so the schedule is direct evidence for them. Confirm that the schedule matches the retention settings in the logging platform, since a mismatch between the document and the configuration is a common finding. Update the schedule in the same change ticket as any retention setting change.
Staff communication records
Records showing that the process was communicated to the staff who run logging, such as system administrators, SOC analysts and application owners, demonstrate that the process is used and not only filed. Keep acknowledgment records, training attendance or a dated announcement that links to the current document. Add the process to the standing agenda of the team's regular operations meeting so that changes reach people who maintain log pipelines.
What meeting Safeguard 8.1 costs in money and effort
This table breaks down the cost and effort components of writing, maintaining and evidencing the Safeguard 8.1 audit log management process, who is paid for each, and what drives it up or down. Use it to frame a fixed-scope quote, since no price list applies to this Safeguard. The main takeaway is that the Controls themselves are free to use, so most of the cost sits in internal time and in any outside help you choose to buy.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Writing and approving the process (security, IT operations and legal time) | One-time, then revised | Number of log sources, existing logging policies, how many approvers must sign off | Start from CIS's free IG1 policy templates and reuse existing retention and classification policies |
| Document tooling and licenses | Recurring if commercial | Whether the process lives in a wiki, document management system or GRC tool | Use an open-source wiki with version history, such as XWiki or BookStack, if it meets your approval workflow |
| Annual review effort | Recurring, at least once a year | Scope of enterprise assets covered, and extra reviews after significant changes | Schedule the review against an existing change or policy calendar and record changes as they happen |
| Evidence upkeep (approval records, review dates, versions) | Recurring | How many review cycles and versions must be kept, and where evidence is stored | Keep one dated, versioned source of truth and link it from the audit evidence folder |
| External review or gap assessment (optional) | One-time or periodic, bought from a provider | Size of the environment, and whether the reviewer must be independent of the writers | Ask for a fixed-scope quote with named deliverables and a written list of what the reviewer checks |
| Auditor sampling time (where the Safeguard is tested in an audit) | Per audit cycle, paid by the organization | How many process versions and review dates the auditor samples, and how easily they are found | Prepare a clear index of current and prior process versions and review records before fieldwork |
Open-source tools that host the process and its version history
Safeguard 8.1 asks for a written audit log management process that is reviewed at least once a year. The tools below are places to keep that document, control who edits it, keep its history, and name the logging sources it governs. None of them replaces the process itself, and the organization still owns the content and its approval.
Version-controlled process documents
XWiki keeps every change to a page under version control, recording what changed, when and by whom. Reviewers can compare any two versions and roll back to an earlier one. For Safeguard 8.1, this history shows an assessor when the process was last reviewed and what changed at that review. Check that the review date and approver are recorded in the page itself, because the version log alone does not prove a review took place. Confirm the license terms apply to your deployment.
Role-based editing rights
BookStack gives each user abilities from the roles assigned to them, and permissions can be overridden per role at the shelf, book, chapter or page level. For Safeguard 8.1, this lets you restrict who can edit the logging requirements while leaving them readable to operations and audit staff. Check that the people who approve the process are the only ones with edit rights on that page, and review role assignments when staff change. Confirm the license terms apply to your deployment.
Named Nextcloud audit log source
Nextcloud's admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. The process should name this file, its location and who can read it, so that an assessor can trace collection from the process to the source. Confirm the log path, retention and access controls in your own environment, since the default location may not match your storage design. Confirm the license terms apply to your deployment.
OpenBao audit devices as a governed source
OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed using HMAC-SHA256. This is a logging source that the process should govern: name the audit device, where its output goes, who reviews it and how long it is kept. Confirm that hashing meets your own sensitivity requirements and that the device is enabled before you claim it as evidence. Confirm the license terms apply to your deployment.
Who owns the 8.1 process, who helps and who assesses it
Your organization owns Safeguard 8.1 in full. The team that is accountable for security governance sets the logging requirements, decides how long audit logs are kept, approves the written process and signs off on each annual review. This ownership cannot be handed to anyone else because the process records decisions about your risk appetite, your legal obligations and the systems that matter most to your business. The same team also keeps the evidence current, which means recording the date of each review and the reason for any off-cycle review after a significant change to enterprise assets or operations.
- Decision rights: Name an accountable owner and an approver for the process, and record both in the document.
- Requirements: Set the collection, review and retention requirements that the process states.
- Review cadence: Run the annual review and any off-cycle review after significant enterprise changes.
- Evidence custody: Keep the approved version, its approval record and the review history in one controlled location.
- Staff awareness: Confirm that the people who read and act on logs know the process exists and where it is kept.
Before engaging anyone else, confirm who in your organization can approve the process and who will sign the first review.
An implementation partner such as DeployOpen helps prepare the systems and documents that the process depends on. Work typically includes building the asset and log source inventory, drafting the process against the CIS Controls Assessment Specification, configuring the controlled document location and its version history, and assembling the evidence pack that your team reviews. The partner does not decide your logging requirements or retention periods on your behalf. Every draft is a proposal until the accountable owner approves it, and the written scope should say so.
- Inventory support: Prepare the list of enterprise assets and log sources that the process covers, for your team to validate.
- Drafting: Write a first draft of the process mapped to the three elements the assessment specification checks: collection, review and retention.
- Document control: Configure a controlled location, for example with the open-source wiki or knowledge base tools described on this site, that keeps version history and approval records.
- Evidence assembly: Collect the approved document, review records and log configuration exports into a single pack.
- Boundaries: The partner does not approve the process, does not sign reviews and does not represent your decisions to an assessor.
Ask the partner to state in the written scope which deliverables are drafts, which require your sign-off and who keeps the final files after the engagement ends.
An independent auditor, assessor or certification body tests the process and decides whether it meets the requirement for the framework that applies to you. They read the approved document, check that the review dates are within the required interval, sample evidence from the log sources and compare what the process says with what the systems actually do. Only this independent party issues a report, attestation or certificate. DeployOpen prepares systems and evidence but does not issue audit reports, attestations or certifications.
- Testing: The assessor checks the process against the assessment specification, including whether a review occurred within the last twelve months.
- Sampling: The assessor selects log sources and reviews records to confirm the process is followed in practice.
- Independence: A partner that drafted or prepared the evidence for an engagement should not also perform the assessment of that same work.
- Reporting: Only the assessor's report or certificate, if one applies, states the assessment result.
- Selection: Ask any assessor how they handle prior involvement and what their independence rules require.
Confirm the assessor's independence rules and the framework they assess against before you agree on scope.
Where organizations fall short on the 8.1 process and how to close each gap
Safeguard 8.1 is easy to write once and easy to let decay. The gaps below are the ones assessors most often find when they test the documented process against the Assessment Specification, and each one has a closing action the organization can take before the next review.
No named owner for the document
A process document with no accountable owner tends to sit untouched, because nobody is responsible for pulling it up when a review falls due. Name one role, such as the security operations lead or head of IT operations, and record that person's name, role and deputies in the document header. Check that the owner can say where the current version lives and who approved it. Assign the owner in writing so the duty survives staff turnover.
Last review older than 12 months
The Assessment Specification scores Safeguard 8.1 as failing when the last review is more than 12 months old, so a lapsed review date fails the Safeguard even when the content is sound. Put the next review date in the document and in the team calendar, and add a reminder to the owner 60 days before it falls due. Record each review with a date, the reviewer and a short note on what changed, so an assessor can see the cycle is running.
Process covers collection only
The completeness measure checks whether the process addresses three elements: collection, review and retention. Many documents describe which systems send logs but say nothing about who reads them or how long they are kept. Audit the document against those three headings and write a short, specific section for any that is missing, naming the review cadence and the retention period the organization actually applies. A gap in one element lowers the completeness score even if the other two are thorough.
No review after significant change
Safeguard 8.1 expects the process to be revisited after significant enterprise changes, not only on the annual cycle. A document that names a SIEM, log forwarders or cloud accounts that have since been replaced will mislead the people who rely on it. Set a short list of triggers, such as a new cloud account, a migration of the log platform or a change in retention law, and make each trigger open a documented review. Keep the change log so the trigger and the outcome can be shown together.
Document stored without version control
An assessor needs to see which version was in force on a given date and who changed it. A process stored as loose files in a shared folder often has several copies, no approval record and no history of edits. Keep the controlled version in a system that records changes, authors and timestamps, and that allows earlier versions to be compared and restored. A wiki or document platform with built-in version history can do this, but confirm the audit trail meets your own evidence requirements before relying on it.
Logging staff never read it
A process that exists on paper does not change how engineers configure log sources, set retention or review alerts. Brief the people who run logging, SIEM administrators and on-call responders on the sections that apply to them, and record the briefing with names and dates. Add a short acknowledgment step to onboarding for roles that touch logging. Assessors often ask operators to explain the process in their own words, so the briefing is part of the evidence.
Questions buyers ask about the 8.1 process before hiring help
How much effort does a Safeguard 8.1 audit log management process take to write?
The effort depends mostly on how many enterprise assets and log sources the process must cover, how many systems already produce logs, and whether the organization already has logging, retention or review policies to build on. A small estate with one identity provider, a few servers and an existing policy set needs a short document and a review cycle. A large estate with many cloud accounts, network devices and SaaS applications needs an inventory of log sources, named owners for each source and approval steps. Ask any partner to show how they will size the work before you agree on a number.
Can our team write the 8.1 process without outside help?
Yes. CIS publishes free policy templates for the Implementation Group 1 Safeguards, and the Assessment Specification describes what an assessor checks in the documented process: that it exists, that it covers collection, review and retention, and that it was reviewed within the last 12 months. An internal owner who understands the enterprise's logging sources can draft the document, get it approved and set a review date. Outside help is most useful when the internal team lacks time, when log sources are spread across many teams, or when the document must match other frameworks the organization follows.
How long does it take to get the 8.1 process in place?
The timeline depends on the scope of log sources to cover and on how many approvals the document needs before it takes effect. Drafting is usually the shorter part. Agreeing on retention periods, review owners and sign-off from security, legal and operations leads often takes longer. A fixed-scope quote from a partner should state the deliverables and the dates for each step, including when the organization must provide approvals and access. Without those inputs, no reliable date can be set.
What does our organization need to provide for this work?
Four inputs make the work move. First, a named owner with authority to approve the process. Second, an asset list or inventory that shows which systems produce logs. Third, approvers from security, operations and any teams that hold logs or retention obligations. Fourth, access to the log sources, such as cloud accounts, identity systems, servers and applications, so the partner can confirm what is logged and where it goes. Delays usually come from missing approvers and from log sources that nobody can confirm.
Will Safeguard 8.1 alone get us certified?
No. CIS Controls are a set of recommended safeguards, not a certification, and CIS states that they do not replace any regulatory, compliance or authorization scheme. Safeguard 8.1 is one written process that supports other Safeguards in Control 8. Any report or certificate tied to a framework comes from an independent auditor, assessor or certification body, not from the organization or from an implementation partner. Check with your assessor which evidence they will accept for the framework you must meet.
Can a partner write the audit log policy for us?
A partner can draft the process, map it to the log sources in your environment and prepare the supporting evidence. The organization still owns the process, decides its retention and review settings and approves the final version. Approval records, owner names and the review history must come from your own governance. Ask the partner to state in writing which parts they draft, which parts you must approve and who maintains the document after handover.
What should we ask for in a quote for this work?
Ask for a written scope that lists the log sources covered, the document sections to be drafted, the approval steps and the evidence to be delivered. Confirm whether the quote includes a review cycle after handover, how changes after significant enterprise changes are handled and what the organization must provide and by when. Ask who holds the final document and what happens if a source is added later. Compare quotes on the same scope rather than on headline totals. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen works on this
DeployOpen helps organizations write and operate the audit log management process that Safeguard 8.1 requires, inside their own infrastructure. The organization owns the process and its decisions, DeployOpen prepares the documentation, configuration and evidence, and an independent assessor reviews the result.
How we scope
- Agree in writing which enterprise assets, systems and log sources the 8.1 process covers before work starts.
- Record who owns collection, review and retention decisions, and which roles approve each revision of the process.
- Confirm the annual review date and the trigger events, such as significant enterprise changes, that force an earlier review.
How we build
- Draft the process document with the three elements the assessment measures: collection, review and retention requirements.
- Map each stated logging requirement to the platforms in the environment and identify where configuration or evidence is missing.
- Test that each platform's audit logs are produced and stored as the written process describes, and record the results.
How we hand over
- Deliver the approved process document, its revision history and a dated record of the last review for the assessor.
- Provide a gap list that shows which elements the process still lacks and which owner must close each gap.
- Walk the internal owners through the review cycle so the next annual review can run without outside help.
How we support
- Engagements are fixed-scope, and the written scope sets the deliverables and timeline before any work begins.
- Ongoing support, upgrades and continuous testing are available as a retainer if the organization wants help between reviews.
- Confirm with your assessor which evidence format they accept before the process document is finalized.
