CIS audit log management policy template (Control 8)

What a CIS audit log management policy template must cover for Control 8

When a customer, contract or regulator asks for CIS alignment and your audit log policy is missing or out of date, the fastest route is CIS's free IG1 policy template for Control 8. It supports Safeguard 8.1, which asks for a written process that sets your logging requirements and explains 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, and the assessment specification scores it as failing if no process exists or the last review is more than 12 months old.

The template gives you the structure, but the detail you write depends on your asset count, the log destinations you run, and the Implementation Group you target. At IG1, the policy needs to name the asset classes that generate logs, the systems that receive them, the review cadence and the retention period. Moving toward IG2 adds Safeguards such as time synchronization, detailed, DNS, URL and command-line logging, centralization and service provider logs, so the policy and the effort grow with each of those additions. Ask for a written scope that lists which assets and destinations are covered before anyone prices the work.

Three roles should be separated in your planning. Your organization owns the policy, approves its logging requirements and performs the reviews. An implementation partner can configure collection, storage and retention on self-hosted platforms and prepare the evidence. Only an independent auditor or assessor reports on whether the controls meet the standard you are being measured against. CIS's Controls Navigator helps you check how Control 8 relates to frameworks your customers or regulators already use.

How Safeguards 8.2 and 8.3 turn the policy into evidence

Safeguard 8.2 asks the organization to collect audit logs and to have logging enabled across the enterprise assets the audit log management process defines. The policy sets the scope, so the assessor's first question is whether the asset list in the process matches what is actually logging. An assessor will usually compare the documented scope against an asset inventory and then sample systems to confirm that logging is switched on and that events reach the collection point.

Asset coverage list: a list, drawn from the Control 1 inventory, of the enterprise assets in scope for logging, with the date it was last reconciled.
Logging configuration exports: configuration files or exported settings from operating systems, applications and network devices showing that audit logging is enabled.
Collection flow records: evidence that events arrive at the central collector, such as input status pages or sample events with timestamps.
Exception records: documented reasons, owners and review dates for any in-scope asset that cannot send logs.
Sampling results: a short record of which systems were checked and what they showed, kept with the review cycle.

Illustrative example: a server missing from the asset list but still sending events is a gap in the scope document, even if collection works. Confirm with your assessor which sampling method they plan to use before you build the evidence set.

Why Control 8 grows from 3 Safeguards at IG1 to 11 at IG2

IG1 asks for three audit log Safeguards as the essential hygiene floor for every enterprise. IG2 adds eight more for organizations with greater operational complexity that hold sensitive information, and IG3 adds one more for regulated, sensitive assets. The cards show what the IG2 additions change in your written policy, and the CIS Controls Navigator confirms which Safeguards apply to your enterprise.

Centralized log collection

The centralization Safeguard asks that logs from enterprise assets reach one central point where they can be searched together. In the policy, name the central platform, the sources that must forward to it and the team that administers it. Check that every in-scope asset class appears in the forwarding list, including cloud workloads and endpoints, which are the sources most often missed. Self-hosted platforms such as Graylog Open ingest logs over inputs such as syslog, GELF and Beats, but confirm each of your source types is supported before you commit to a design.

Synchronized time sources

Time synchronization keeps events from different systems in the correct order, which reviewers need when they rebuild an incident across firewalls, servers and identity systems. The policy should name the authoritative time source, the assets that must sync to it and the check that catches drift. Without it, timestamps from different devices can disagree and produce a misleading timeline. Ask your platform team how each virtual machine, container host and cloud instance receives its time, since defaults often differ.

Detailed, DNS and URL logs

IG2 adds Safeguards for detailed event logging, DNS query logging and URL request logging. Together they record what happened on a host, which names systems tried to resolve and which web addresses users or processes requested. The policy should state which asset types must produce each log type, which fields are retained and how volume is handled, since DNS and URL logs grow quickly. Storage planning under Safeguard 8.3 depends on these choices.

Command-line audit logs

Command-line audit logging records the commands that administrators and processes run on enterprise assets, making it one of the most useful sources for tracing privilege use and lateral movement. The policy should define which shells, interpreters and administrative tools are covered, who can read these entries and how sensitive values typed on a command line are handled before storage. Confirm with your engineers that the operating systems and endpoint tools you run can capture this without weakening existing protections.

Service provider logs

Logs produced by service providers that run part of your environment can leave a gap in your own audit trail. The policy should require providers to supply the log types your process defines, state how those logs reach your central store and assign who reviews them. Confirm which Safeguard covers provider logs and its Implementation Group in the CIS Controls Navigator before writing it into scope, because the tier determines what you must commit to.

Annual and change-driven review

The policy itself must be reviewed once a year or after significant enterprise changes, and the assessment specification scores the process as failing when its last review is more than 12 months old. IG2 also expects the logs themselves to be reviewed, so the policy should define who reviews which sources, how often and which alerts escalate to incident response. Record each review with a date and reviewer, since that dated record is the evidence an assessor will request.

What a CIS audit log policy and its evidence cost

The policy document itself carries no licence fee. CIS publishes its policy templates free for use under its licence, and CIS states that the Controls are free for any organization to use to improve its own cybersecurity. The cost of Control 8 sits in everything the policy describes: configuring logging on enterprise assets, building and sizing the log destinations, staff time to review logs and keep the process current, and any outside help with the work. Those costs are one-time for setup and recurring for storage, licences, operations and the annual policy review that Safeguard 8.1 requires. Commercial use of the Controls content needs CIS's prior approval, so an outside firm that repackages the templates for resale should confirm its own rights before the engagement starts.

CIS's Accreditation application fees, $1,500 for CREST members and $2,500 for non-members, apply only to providers applying for CIS Controls accreditation. They do not apply to an organization writing its own audit log management policy, and a buyer should not treat them as a cost of compliance. The effort your organization faces depends on a short list of drivers: the number of enterprise assets in scope, the number and type of log sources (endpoints, servers, cloud control planes, network devices and SaaS applications), the retention periods your rules set, and whether you already run a SIEM that can take over collection, search and storage. An existing SIEM can shorten setup, but it can also add licence cost that scales with ingest volume, so confirm that pricing model before you commit.

Before you engage an implementer, request a written scope and quote that lists the assets and log sources covered, the retention rules and storage sizing assumed, the platform and version to be deployed, which parts of the policy the partner drafts and which your staff approve, how the review of Safeguard 8.1 will be run and recorded, and what evidence will be delivered at handover. Ask whether the work is fixed-scope and what changes would trigger a new quote. DeployOpen plans and implements self-hosted platforms in your own infrastructure and works to a written scope, but it does not publish prices and it does not issue assessment results. Confirm with any assessor, whichever firm you choose, which evidence it will accept before the logs are built.

What makes audit log work more or less demanding

The effort behind an audit log management process rises or falls with a small set of scope decisions made before any collector is installed. Each factor below changes how many sources must be logged, how long records must be kept and how much storage the destinations need, so each one should be fixed in writing before the policy is approved.

Asset count and locations

The number of enterprise assets and the sites, data centers, regions and cloud accounts that host them sets the size of the logging scope. Start from the asset inventory required by Control 1 and tag each asset with its location and owner. Then decide which asset classes must log at the minimum level. Ask for the inventory export before estimating effort, because an incomplete inventory produces a log policy that quietly excludes whole segments.

Log sources across the estate

Endpoints, identity providers, network devices, cloud control planes and business applications each emit different event types in different formats. Define the minimum log set first: authentication events, administrative actions, security tool alerts and DNS or command-line activity where the policy requires them. Count sources by category rather than by device, since one identity platform may represent thousands of users. Confirm which sources can forward natively and which need an agent.

Retention set by internal rules

Retention periods come from the organization's own obligations, such as contractual terms, sector rules, internal investigation needs or legal hold practice. Document the period per log category instead of applying one number everywhere. Longer retention multiplies storage and search cost for the whole pipeline. Ask legal and compliance owners to confirm each period in writing, and record who approves changes to it.

Storage architecture

Where logs land, how indices are sized and how old data is removed determine whether the retention rule is achievable. A single central store, regional stores or tiered hot and cold storage each carry different capacity and access patterns. Plan capacity from event volume and retention together, then set rotation and deletion rules that match the policy. Test that the destination can absorb peak volume during an incident, not only steady-state traffic.

Existing tooling and integrations

Existing SIEM platforms, cloud-native logging services and endpoint tools determine how much new collection work is needed. Map each current tool to the required log categories and note gaps, duplicated feeds and fields that are dropped during forwarding. Confirm time synchronization across sources, since uncorrelated timestamps make reviews unreliable. Where an open-source platform such as Graylog Open is introduced, check inputs, pipelines and storage limits against the source list before committing to it.

Staff ownership and review load

Someone must own each log source, the review cadence and the response when a review finds a gap. Ownership gaps are the most common reason a documented process falls behind the actual estate. Name a primary and backup owner per log category, assign the annual process review, and record who reviews alerts and how often. Confirm that these people have the access and time the policy assumes before adding more sources.

How to build the policy and evidence it step by step

This sequence turns the CIS audit log management policy template into a working process, with the logging requirements, collection settings, storage records and review history that an assessor will ask to see for Control 8.

Confirm the implementation group and scope
Start by deciding which Implementation Group the organization is working toward and which enterprise assets, cloud accounts and applications fall inside the logging scope. Owners are the CISO or security lead with IT operations, and they should record the IG target and the scope statement in the policy's header. CIS's policy templates cover IG1 Safeguards only, so an IG2 or IG3 target means the team must plan additional content from the start. The output is a signed scope statement that names the target group and the systems covered.
Adopt the IG1 template and extend it
Take CIS's IG1 audit log management template as the base and add the Safeguards that the target group requires beyond the three IG1 items. Safeguard 8.1 expects the written process to explain collection, review and retention, and IG2 adds further Safeguards that the template does not address. Assign an owner for each section and record every added section against its Safeguard number. The output is a draft policy in which each section maps to a Safeguard the organization has chosen to address.
Define logging requirements for each asset class
Write the logging requirements for each asset class in the inventory, such as devices, software, data, users, network and documentation, and state which event types each class must produce. Security, operations and engineering leads should agree the list, then check it against the asset inventory produced under Control 1 and Control 2. Identify who approves exceptions and how they are recorded. The output is a logging requirements table that an assessor can compare directly with the systems that are actually logging.
Configure collection and retention in the platform
Configure the chosen log platform so that each in-scope source sends its logs to the central destination. If the team uses Graylog Open, inputs such as syslog, GELF or Beats receive the events, streams and processing pipelines route them, and index rotation and retention settings control how long they are kept. Confirm the retention period with the policy owner and the legal or compliance team, since the policy sets the value. The output is a configuration export or screenshot record showing each source, its input and its retention setting.
Record storage sizing against the policy
Estimate the storage that the retention period and the expected log volume require, then compare the result with the capacity of each destination. Safeguard 8.3 asks for enough capacity to meet what the process demands, so the sizing worksheet should state the assumptions and the headroom. Infrastructure owners approve the figures, and any shortfall goes into a remediation item with an owner. The output is a dated sizing record that links each destination to the retention requirement it supports.
Run and document the first review
Perform a documented review of the policy against the live configuration, covering the collection coverage, the review of log content, and whether the retention and storage records still match. Record who conducted the review, what was checked, what gaps were found and how each gap was closed. This first review establishes the baseline that the assessment specification reads for the review date. The output is a signed review record with a findings list and the approval of the policy owner.
Set the annual and change-triggered review cycle
Put the policy on a recurring review calendar with a named owner, and add a rule that the policy is also reviewed after any significant change to the enterprise, such as a new cloud account, a platform migration or an acquisition. Safeguard 8.1 sets the yearly review and the change trigger, and the assessment specification fails the Safeguard when the last review is more than 12 months old. Keep each review as a dated record in the same repository as the policy. The output is a review calendar and a change log that together show the policy has been kept current.

How Graylog Open can produce the audit log evidence

Graylog Open (SSPL-1.0) can serve as the collection and storage layer that produces much of the evidence a Control 8 audit log management process describes. Its inputs ingest logs over syslog, GELF and Beats, so the sources named in the process (endpoints, servers, network devices and applications) can be pointed at one destination. Streams and processing pipelines then route and filter events in real time, which is where the organization can separate security-relevant records from routine noise and tag them for review. The decision for the team is which sources feed which streams, and whether that routing matches the logging requirements written in the policy rather than a default configuration.

For storage, the relevant settings are index rotation and retention. Graylog rotates indices by message count, size or time, and its retention setting deletes the oldest indices once a limit is reached. Those values determine whether the destination has enough capacity for the volume the policy expects and how far back the organization can search. The Graylog Index Model documentation explains how these pieces fit together, and it is the right place to check the rotation and retention options before setting values. Search with time range filtering and dashboards then supports the periodic review the policy requires, provided the review is written down with its date and reviewer.

Graylog Open does not satisfy Control 8 on its own. It does not decide what must be logged, who reviews the logs, how long records must be kept or whether the review happens yearly and after significant changes. The client must confirm which features fit its own policy, test retention against its stated period, and keep the review records outside the tool. Independent assessors will also expect evidence that logging is enabled on the sources the process names, so the inventory of those sources should be checked against the Graylog inputs before any assessment.

Who owns the policy, who prepares evidence and who assesses it

The organization owns the audit log management policy. It decides what the logging requirements are, which asset classes must produce logs, how long records are kept and who reviews them. Safeguard 8.1 asks for a written process that sets these requirements and is itself reviewed once a year or after significant enterprise changes, and that review is the organization's responsibility, not a vendor's.

Setting requirements: Decide which enterprise assets, applications and identity systems fall within the logging scope and what each must record.
Approving the process: Name the owner who signs off on the audit log management process and the schedule for its review.
Assigning review duties: Decide who reviews collected logs, how often and how findings are escalated.
Keeping the review current: Record each annual or post-change review so the last review date is provable.
Accepting residual risk: Document any exceptions, such as assets that cannot emit logs, and who approved them.

Before engaging anyone, confirm that the policy names an accountable owner inside the organization and that the review record exists in a form an assessor can read.

Questions buyers ask about the CIS audit log policy

Is the CIS audit log management policy template free to use?

Yes, the template is free to use for your own organization. CIS publishes its policy templates for IG1 Safeguards, and the CIS Controls content is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0. CIS says the Controls are free for any organization to use to improve its own cybersecurity. The licence matters for commercial use: reproducing or adapting the Controls content for commercial purposes requires CIS's prior approval. If you plan to sell a modified version of the template to clients or publish it in a commercial product, confirm the terms with CIS before you start. Your internal cost is the time to adapt the template to your environment, approve it and keep it current.

Can our team write the audit log policy without outside help?

Usually yes, if someone in security or IT operations owns the document and the people who run logging systems review it. The template gives you the structure: logging requirements, how logs are collected, reviewed and retained. The harder work is filling it with facts about your environment, such as which asset classes produce logs, who reviews them, and where they are kept. Outside help is most useful when the team lacks time, when the policy must be reconciled with several frameworks at once, or when you want an independent check before an assessment. An implementation partner can prepare systems and evidence that the policy describes, but the organization owns the policy and its approval. Only an independent auditor or assessor issues reports or certificates.

How often must the audit log management policy be reviewed?

Under Safeguard 8.1 of CIS Controls v8.1, the audit log management process must be reviewed once a year, and it must also be reviewed after significant enterprise changes. The annual date is a minimum, not a target you can wait for. Significant changes that should trigger an early review include adding a new cloud account, moving logs to a new platform, changing retention obligations or acquiring a business unit with its own systems. The CIS Controls Assessment Specification scores Safeguard 8.1 as failing when no process exists or when its last review is more than 12 months old, so keep a dated review record that an assessor can read. Confirm the exact wording and any updates on the CIS Controls v8.1 pages.

What does the audit log policy need from our staff?

The policy needs named owners and a few recurring actions from people who run systems and handle incidents. Assign an owner who approves the policy and holds the annual review date. System owners need to confirm which assets are enabled for logging, since Safeguard 8.2 requires logging across the enterprise assets defined in the process. Operations staff must follow the review and retention rules and keep the records that show it happened. Security staff must know where logs go, who can query them and how long they are kept. Staff who never touch the logging platform still need to know that they must report logging gaps they notice. Name a backup for each role, because a policy that depends on one person fails when that person is absent.

Does a customer contract require IG2 for audit logging?

Not by default. The customer contract or framework decides which Implementation Group applies, so read the requirement before you assume IG2. Under CIS Control 8, Implementation Group 1 contains 3 Safeguards, IG2 adds 8 more, and IG3 adds 1 further Safeguard, for 12 in total. The IG1 Safeguards cover the logging process, log collection and storage capacity. Many contracts ask for more depth, such as centralized review or time synchronization, which appear in the IG2 additions. If a customer asks for "CIS Controls" without naming a group, ask which Implementation Group and which Safeguards they expect, and get the answer in writing. CIS states the Controls do not replace any regulatory or compliance scheme, so check what your other obligations require too.

Will a logging tool make us compliant with the CIS audit log requirements?

No. A tool can collect, store and search logs, but it cannot write your policy, set your retention rules or approve your review cycle. Compliance depends on the documented process, the records of its annual review and evidence that logging is enabled across the assets your policy defines. Open-source platforms such as Graylog Open can support several of those needs by ingesting logs over inputs like syslog, GELF and Beats, providing search with time range filtering, and managing storage through index rotation and retention that deletes the oldest indices. Confirm how each capability fits your environment before you rely on it. Ask an independent assessor how they expect the evidence to look, because the tool produces data while the organization owns the control.

How DeployOpen prepares audit log systems and evidence

DeployOpen plans, implements and documents self-hosted open-source logging platforms inside your own infrastructure, so the audit log management process your organization owns is backed by working systems and retained evidence. We prepare the systems and evidence; the policy decisions, sign-off and any independent assessment remain with your organization and its assessor.

How we scope

Engagements are fixed-scope, with the enterprise assets, log sources and destinations agreed in writing before work starts.
The written scope lists which Safeguards from Control 8 are in play, including the IG1 Safeguards 8.1 to 8.3 and any IG2 additions you require.
Scoping confirms the review cycle, retention periods and storage capacity your audit log management process must set out.

How we build

We deploy Graylog Open in your cloud accounts, data centers or air-gapped network, configured for the log inputs your assets produce.
Streams and processing pipelines are set up to route and filter logs, with index rotation and retention configured to match the documented process.
We test that logging is enabled across the in-scope assets and that storage capacity holds the retention the process demands.

How we hand over

Deliverables include configuration documentation, a record of collection and retention settings, and evidence of log collection for the assessor.
We document the review steps for the audit log management process so your staff can run the annual review and the review after significant changes.
Handover includes a walkthrough so your team can operate, search and maintain the logging platform after the engagement closes.

How we support

Ongoing support, upgrades and continuous testing of the logging platform are available as retainers, scoped separately from the original engagement.
Retainers can cover periodic review of collection coverage and storage headroom so the evidence stays current between assessments.
Independent auditors and certification bodies issue any reports or certificates; DeployOpen prepares the systems and evidence they review.