Safeguard 8.11 Conduct audit log reviews: evidence guide

What Safeguard 8.11 asks for and why the weekly interval matters

If your enterprise is in Implementation Group 2 or 3 and an assessor or customer questionnaire asks about Safeguard 8.11, the short answer is this: your audit logs must be reviewed at least once a week for unusual or abnormal events that might point to a threat. The Safeguard sits in the Detect security function and the Data asset class, and it applies from IG2 upward, not to IG1 enterprises. The purpose is detection. Collecting logs under Safeguards 8.2 and 8.9 gives you a record of what happened, but a record nobody reads cannot tell you that an account is being abused or that a server is beaconing to an unknown host. The review is the step that turns stored events into a decision about whether something needs investigation.

Collection alone therefore does not satisfy the Safeguard. An assessor will ask who performs the review, how often it happens, what they look for, and what happens to anything suspicious. Three problems make this hard in practice. First, no one is named as the reviewer, so reviews happen informally or not at all during leave, staff changes or busy weeks. Second, alert noise from unfiltered rules trains people to ignore the queue. Third, log sources are spread across endpoint tools, cloud consoles, network devices and identity platforms, so the review either misses sources or takes so long that it slips past a week. Illustratively, a team that reviews a single SIEM dashboard every Monday but never checks identity logs has a weekly cadence on paper and a gap in coverage in practice.

Before an assessment, confirm three things and record the answers: the named role or team that owns the review, the sources and alert queues it covers, and the dated evidence that each review took place. The CIS Controls Assessment Specification measures a single value, the time between reviews, and scores the Safeguard as failing when that interval exceeds seven days, so a missed week is a failed measure even if your tools work. Ask your auditor how they expect review dates to be shown, and if you use a managed monitoring provider, confirm in writing how that provider's reviews are recorded and handed back to you under Safeguard 15 obligations.

Which logs, systems and teams fall under the audit log review interval

The seven-day review interval in Safeguard 8.11 applies to whatever log data the organization has chosen to collect under Control 8. The cards below set the boundary: which log sources feed the review, which assets and data classes count, how manual and automated review divide the work, and how provider logs change the picture.

Upstream log sources from Safeguards 8.2 to 8.12

The review can only cover logs that exist. Safeguards 8.2 to 8.12 define the sources: baseline collection on enterprise assets (8.2), storage (8.3), time synchronization (8.4), detailed logs on sensitive-data assets (8.5), DNS, URL and command-line logs (8.6 to 8.8), centralization (8.9), retention (8.10) and service provider logs (8.12). Before measuring the interval, list which of these sources are enabled and where they land, because an unreviewed source is outside the test. Confirm each source is in the audit log management process from Safeguard 8.1.

Data asset class and sensitive data scope

Safeguard 8.11 sits in the Data asset class, so the review scope should follow where sensitive data lives. Map the systems that store or process regulated or confidential data, such as databases, file shares, document stores and the applications that front them, and confirm their logs reach the review. Systems that hold no sensitive data may still generate logs that matter for detection, so record a deliberate decision for each group rather than leaving the boundary implicit.

Detect function and the systems that generate alerts

Safeguard 8.11 belongs to the Detect function, so the review is part of detection, not only record keeping. Identify the security tools, identity platforms, endpoint agents and network sensors whose alerts should be examined in the same cycle. An organization that reviews raw logs but ignores alerts already generated by its tooling may miss anomalies the platform flagged. Document which tools feed the review queue and who owns triage.

Manual, automated or mixed review

The Safeguard does not require a specific method, but the assessor measures the time between reviews. Automated rules can flag anomalies continuously, while a person still needs to review the results on the required cadence. Decide which events are triaged by rules, which are read by staff and how the review date is recorded. Illustrative example: a rule engine raises alerts daily, and an analyst signs off on the alert queue each week, which creates a dated record for the assessor.

Named teams and reviewer accountability

Someone must own the review interval, and assessors will ask who performed each review and when. Assign a primary reviewer and a backup for each log source group, and define what counts as a completed review, such as a documented alert triage or a dated checklist. Coverage gaps often appear during leave or staff changes, so confirm the backup covers the same sources.

Service provider logs and shared responsibility

Safeguard 8.12 brings logs from service providers, such as sign-in, authorization and data events, into the scope where supported. Those logs arrive on the provider's schedule and format, which can delay the weekly cycle. Confirm which provider logs you can export or receive, how often they arrive and whether the contract allows access. Where a provider cannot supply logs, record that gap, because the review interval cannot cover events you never received.

How to set up a weekly audit log review that holds up under assessment

This sequence turns Safeguard 8.11 into a repeatable routine: a named reviewer and cadence, a defined scope, detection tuned to that scope, and a dated record of every review, so the interval between reviews can be measured and shown to an assessor.

Confirm the cadence and reviewer in the log management process
Start by reading the audit log management process written under Safeguard 8.1. Check that it names the role responsible for reviewing logs, the review cadence, and where review records are kept. Safeguard 8.11 asks for review at least once a week, so the documented cadence must match or exceed that. If the process is silent on who reviews or how often, amend it and get approval before any review runs. The step is done when the owner, backup owner and cadence appear in the approved document.
Define the log sources and review scope
List every log source the review must cover, such as identity systems, endpoints, network devices, cloud control planes and key business applications, and mark which sources come from the collection and centralization Safeguards in Control 8. Record the retention location for each source so the reviewer knows where to look. Confirm with the asset owners which sources are in scope and which are excluded, and document the reason for each exclusion. The output is a scope register that an assessor can compare against the asset inventory.
Write triage criteria for unusual and abnormal events
Set out what counts as an unusual or abnormal event for this environment. Examples include repeated failed sign-ins, administrative actions outside change windows, new service accounts, unexpected outbound connections and log gaps from a source that normally reports. Assign a severity or priority to each category and state the action for each, including when a finding moves to incident response under Control 17. The output is a short triage standard the reviewer applies the same way each week.
Configure detection rules and alerting
Load detection content into the log platform so that matching events reach the reviewer without manual searching. Open-source options include OpenSearch Security Analytics, which runs detectors built on Sigma rules and sends alerts to channels such as Slack or email, and Wazuh, which compares decoded events against a ruleset and writes alerts that feed its dashboard. Test each rule against sample events, tune out known noise, and record who approved each rule. Confirm with the platform vendor which detectors and integrations your version supports before you commit to a design. Done means a test event produces an alert in the review queue.
Schedule each review and record it
Create a recurring calendar entry or ticket for each review and assign the named reviewer and a backup. At the start of each review, record the date, reviewer, log sources covered, alerts opened and their disposition, and any gaps observed. Keep the record in the system the process names, such as a ticketing tool, GRC platform or log platform audit trail. The record is the evidence an assessor uses to measure the interval between reviews, so entries must be dated and must not be edited after the fact.
Handle escalations and close findings
Route each finding according to the triage standard. Low-priority items are closed with a reason, while suspected threats are escalated to the incident response process, where the incident is logged, assigned and tracked to closure. Record the escalation path, the person who approved closure and the outcome for each finding. Review a sample of closed items periodically to confirm the triage standard is being applied. The output is a traceable path from log event to disposition for every escalated item.
Keep the review interval measurable
Produce a simple report showing the date of each completed review and the gap since the previous one. An assessor measures the time between reviews and scores the Safeguard as failing when that interval exceeds seven days, so the report should show the longest gap in the period as well as the average. Set an alert for any missed review, and document the reason and corrective action when one occurs. Ask the auditor which evidence format they prefer before the assessment. Done means the report can be generated from records without reconstructing dates from memory.

How an assessor measures the interval between log reviews

This table walks through how an assessor tests Safeguard 8.11, from the single CAS measure to the evidence requested and the findings that most often cause a failure. Read each row as a stage of the test, and note that the decisive question is whether the dated record shows no gap longer than seven days.

Test element	What the assessor does	What to have ready
Measure and threshold	Measures the time between consecutive log reviews and scores the Safeguard as failing when that interval exceeds seven days.	A review schedule that never allows an interval longer than seven days, including over holidays and staff absences.
Prerequisites	Checks no prerequisite Safeguards before measuring. The test starts directly from review records.	Confirm with the assessor that they are testing 8.11 alone and not relying on earlier Safeguards.
Scope of logs	Confirms which log sources are in scope for review, typically the logs collected under Safeguards 8.2, 8.9 and 8.10.	A list of log sources and the systems or tools that hold them, matched to the review scope.
Sampling review dates	Takes a period under test and lists every review date, then calculates each gap between them.	Dated review records covering the full period, not only the most recent weeks.
Evidence of the review itself	Looks for proof that someone examined the logs for unusual or abnormal events, not only that a tool ran.	Signed review notes, dashboard review logs or ticket entries naming the reviewer and what was checked.
Alert dispositions	Checks whether alerts raised during the period were triaged, closed or escalated, and when.	Alert records with timestamps and disposition notes, such as closed as benign, escalated or linked to an incident.
Common finding: undated reviews	Cannot calculate an interval when reviews have no date, so the gap cannot be shown to be within seven days.	Date and time stamps on every review entry, applied at the time of review.
Common finding: holiday gaps	Identifies periods with no recorded review, often around year-end or public holidays, that exceed seven days.	A documented cover arrangement or automated review for holiday periods, with records for those dates.

Why a dated review record matters more than a tool dashboard

An assessor testing Safeguard 8.11 needs evidence that a person reviewed the logs inside each seven-day window, not evidence that a log platform was switched on. The Assessment Specification scores the interval between reviews, so the artifact that matters is a dated record of each review. A dashboard that shows logs arriving tells an assessor the pipeline works. It does not show that anyone looked at the events, and it cannot show gaps in human review. Before the assessment, confirm with your assessor which form of record they will accept, and whether they expect the record to be generated by the tool, written by the reviewer, or both.

A useful review record names the reviewer, the date and time, the log sources and time range covered, the detection rules or queries run, the findings, and the disposition of each finding. For example, a Wazuh review might cite the alerts.json range reviewed, the rule groups filtered, the alerts judged benign with a reason, and the tickets opened for the rest. Each closed finding should link to the ticket or incident record that shows what was done. Keep these records in a system your team controls and that is retained for longer than the review cycle, so that the history can be shown after the fact.

Gaps usually come from absence, not from neglect. Name at least two trained reviewers for each source, and write a handover step into the review procedure so that a missed week is caught by a named person rather than discovered in an audit. Test the process by checking whether the last seven days of records exist for every in-scope log source, and ask your implementation partner or internal team to set an alert when a review record is overdue. Confirm internally who owns that alert, because an alert nobody answers produces the same gap as no review at all.

Evidence that passes a Safeguard 8.11 review

An assessor testing Safeguard 8.11 mainly needs proof that reviews happened on schedule and that anomalies were acted on. The cards below cover the documents that define the review, the records that prove each review, the detection configuration behind the findings, and the disposition trail that follows. Each item should be refreshed continuously so the sample pulled at audit time reflects the whole period, not just the final week.

Review schedule and runbook

The documented schedule states who reviews which log sources, how often, and what counts as an anomaly worth escalating. The CIS assessment specification measures the time between reviews and fails the Safeguard when that interval exceeds seven days, so the schedule should commit to a weekly or shorter cadence. Keep the runbook under version control, record each revision with its approver and date, and confirm that the named reviewers still hold those duties. Assessors check whether the written cadence matches what the logs show.

Dated review records or tickets

Each review should leave a timestamped record that names the reviewer, the log sources covered, the time window examined, and the result, even when nothing was found. Tickets in the organization's workflow tool or a signed log in the SIEM both work if they are consistent. The interval between these records is the figure the assessor measures. Gaps during holidays, staff changes or outages are the most common failure, so plan coverage and a backup reviewer in advance.

Detector and rule configuration

Export the detector definitions, rule sets and log source mappings that generate the findings reviewers examine. Show which hosts, network devices and cloud services feed each detector, and when each rule was last changed. In OpenSearch Security Analytics, detectors match ingested logs against Sigma rules and write findings with severity; in Wazuh, the ruleset and any custom rules are the equivalent. Keep configuration exports dated, so the assessor can see that detection was active throughout the period under review.

Alert disposition records

For every alert or finding reviewed, record the disposition: closed as benign with a reason, linked to an incident, or escalated. A review that touches an alert without a disposition shows activity but not judgment. Keep the disposition field mandatory in the ticketing or case tool and retain the original alert payload alongside it, so the decision can be traced back to the evidence. Periodic spot checks by a second person strengthen this record.

Escalation and incident hand-off records

When a review finds something that could indicate a threat, the record should show who was notified, when, and what happened next. Link the review ticket to the incident record created under the organization's incident response process. Assessors look for at least one traced path from an anomaly to a resolution, and they check that the escalation time is consistent with the review cadence. If no escalations occurred during the period, the review records should still show that the detection pipeline was tested.

Sampled reviews across the period

Assessors typically select a sample of review dates across the audit period and ask for the matching records, configuration versions and dispositions. Prepare a single index that lists every review by date so that any sample can be produced within a short time. Confirm that each sampled date has a complete trail, and that the detector configuration in force on that date is retrievable. Refresh the index at a fixed interval rather than assembling it during fieldwork, because reconstructed evidence is weaker than contemporaneous records.

What meeting Safeguard 8.11 costs in money and effort

This table breaks down the cost components of running weekly audit log reviews, who is paid for each, and whether the cost is one-time or recurring. Read it to see where spending goes and which decisions move it up or down. No prices are stated because none are supplied for this topic, so confirm figures against your own staffing and written scope.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Reviewer time each week	Internal analysts or a managed security provider, paid per hour or per seat	Recurring	Log volume, number of log sources in scope and how many findings need human judgment. Narrower, well-tuned detections lower the weekly load.
Review cadence coverage	Internal staff covering weekends, holidays and absences	Recurring	Safeguard 8.11 is failed when the gap between reviews exceeds seven days, so cover for leave and staff turnover must be planned in advance.
Log analysis tooling	Vendor or open-source platform. Open-source licenses carry no fee, but hosting and staff time still apply	Recurring (hosting, support) and one-time (setup)	Choice between a self-hosted stack such as OpenSearch Security Analytics or Wazuh and a commercial SIEM. Confirm licensing terms with each vendor.
Hosting and storage for review data	Your cloud account, data center or the implementation partner who configures it	Recurring	Retention period, volume of indexed events and number of environments. Confirm retention needs with Safeguard 8.10 requirements.
Detection rule tuning	Internal security engineers or implementation partner under a fixed-scope agreement	One-time at setup, then recurring	Alert noise from default rulesets. Noisy alerts increase reviewer time, so budget tuning cycles after each new log source is added.
Review procedure and evidence upkeep	Internal compliance or security staff	Recurring	Number of reviewers, frequency of review records and how often the review process is revised. Records must show each weekly review occurred and what was found.
Escalation and incident handling	Internal incident responders or external responders on retainer	Recurring, variable	Number of genuine anomalies found. Clear escalation thresholds and documented triage steps limit unplanned effort.
Independent assessor sampling	Independent auditor or assessor, paid by the organization being assessed	Recurring at each assessment cycle	Assessor sample size and the number of review records requested. Consistent, dated review records reduce sampling effort.

Open-source platforms that produce review evidence

OpenSearch Security Analytics (Apache-2.0) runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match is recorded as a finding with its rule, log type and severity, and alerts can go to channels such as Slack or email. Findings and alert history are the strongest candidates for review evidence, because they show what was flagged and when it was handled. A correlation engine links findings across log types in a correlation graph, which helps reviewers see related events together.

Findings log: Each finding records the rule, log type and severity, giving a dated trail of what the detectors raised.
Alert channels: Slack or email notifications show when a reviewer was told about an event, useful for timing evidence.
Sigma rules: Prepackaged or custom rules can be versioned, so you can show which detection logic was active during a period.
Correlation graph: Links between findings across log types support investigation records.
Triage records: The platform shows matches, but a ticket or case record is still needed to prove a person reviewed and closed each finding.

Confirm with your team which detectors cover your in-scope log sources, and whether finding status and analyst notes are retained long enough for your review interval.

Where organizations miss the weekly review and how to close it

Safeguard 8.11 is measured by the time between reviews, so most failures are not missing tools but missing ownership, records and coverage. The cards below describe the gaps assessors most often find and the closing action for each. Each one can be checked against the review record and the log pipeline before an assessment begins.

No named owner for reviews

When no one is accountable for the weekly review, the task drifts to whoever has time, and the interval quietly stretches past seven days. Assign a primary reviewer and a named backup in the audit log management process, and state which log sources and alert classes each person covers. Close it by writing the owner, backup and scope into the documented process so an assessor can match the schedule to a named person.

Reviews recorded only in chat

Teams often say a review happened in a chat thread or a stand-up, but nothing durable proves the date, scope or findings. An assessor measuring the interval needs timestamps that can be retrieved and compared. Close it by recording each review in a ticket or log entry with the date, reviewer, sources checked and outcome, and keeping that record in the system of record for the audit log program.

Alert queues left unworked

A detection tool can generate alerts every day while nobody triages them, so the review looks active but produces no evidence of analysis. Check whether the queue has an age report and whether items are closed with a disposition. Close it by setting an alert triage rule, such as assigning each new alert to a person within the review cycle, and reporting open items older than the review interval.

Gaps during leave and rotation

Vacations, sick leave and staff turnover are the most common reason a weekly review slips past seven days. Without cover, the first missed week is often the one an assessor samples. Close it by publishing a coverage calendar with a named substitute for every absence, and confirming that the substitute has access to the review tool before the absence begins.

Log sources missing from the review tool

A weekly review of a central tool only covers the sources that reach it. Hosts, cloud services or network devices that were never forwarded produce no events for the reviewer to see, even when the review itself is on time. Close it by comparing the list of enabled log sources against the sources actually ingested, and treating any silent source as an open finding until forwarding is confirmed.

Review scope left undefined

Reviewers who do not know which events matter tend to scan a few dashboards and call the review complete. Safeguard 8.11 asks for review of unusual or abnormal events that might point to a threat, so the scope should name the event types and the detection rules that drive review. Close it by documenting the review checklist, mapping each item to the rules or dashboards it uses, and sampling reviews periodically to confirm the checklist is followed.

Common questions about Safeguard 8.11 cost, effort and outsourcing

How much effort does a weekly audit log review take?

The effort depends on log volume, the number of sources, and how well alerting is tuned, so no fixed hour count applies across environments. Safeguard 8.11 only sets the ceiling: the time between reviews must not exceed seven days, as the assessment specification measures it. A team with well-tuned alerts often spends its review time triaging a short list of flagged events and checking that the collection pipeline is still running. Before estimating, ask your team to measure current event volume per source, how many alerts a week need human judgment, and who is named as the reviewer for each week. Those three numbers drive the effort far more than any generic estimate.

Does an automated tool satisfy Safeguard 8.11 on its own?

No. Safeguard 8.11 asks for logs to be reviewed for unusual or abnormal events, so a tool that generates alerts is only part of the evidence. The organization still needs a documented reviewer, a schedule that keeps the interval within seven days, and records showing that reviews happened and that flagged events were handled. Detection platforms such as Wazuh and OpenSearch Security Analytics can match events against rules and write alerts, which supports the review but does not replace it. Confirm with your assessor how they want review records presented, because they test the interval and the evidence of each review.

How long does it take to prepare for Safeguard 8.11?

No preparation duration is fixed for this Safeguard, and any figure quoted without your environment would be guesswork. Preparation usually covers confirming which log sources feed a central location, setting up detection rules, naming reviewers and a cover rota, and running a few review cycles so evidence exists before an assessment. The work scales with how many systems already log centrally. Ask any partner for a written scope and timeline before work starts, and ask them to list which parts depend on your own change approvals and staff availability.

Can our own team run weekly audit log reviews in-house?

Often yes, if the team has someone who understands the log sources and the organization's normal activity. Safeguard 8.11 is not an IG1 requirement; it applies from IG2 and IG3, so the organization's implementation group is a useful starting point for how much rigor to plan. In-house teams usually need a named owner, a backup reviewer for absences, a documented procedure, and time in the schedule. Where internal staff lack detection engineering skills or time, some organizations bring in an implementation partner to tune rules and document the process, while keeping the review itself internal. Ownership of the control stays with the organization in either model.

What does a partner need from us to help with Safeguard 8.11?

A partner needs enough access and context to configure detection and document the review process accurately. Typically this means a list of in-scope log sources, read access to the central logging platform, the current audit log management process, named owners for each system, and the alert routing that already exists. The partner prepares systems and evidence, but the organization owns the controls and the reviewer roles. Ask the partner to state in writing which artifacts they will deliver, such as rule configurations, review procedures and evidence templates, and which items you must supply.

How does the weekly review connect to Safeguards 8.1 and 8.9?

Safeguard 8.1 requires a documented audit log management process, and that process should state the review cadence, which for this Safeguard must keep intervals within seven days. Safeguard 8.9 centralizes audit logs, and centralization is what makes a single review point practical. In practice, the review schedule in the 8.1 process refers to the logs gathered under 8.9, and the review records show the interval. If the process sets a different cadence, or logs are not centralized, the review cannot be measured reliably. Check that your process document, collection points and review records all describe the same flow.

What evidence should we keep to show reviews happened on time?

The most useful evidence is a dated record for each review, showing who performed it, which log sources were covered, what was flagged, and how each flagged event was closed or escalated. The assessment measures the time between reviews, so consistent timestamps matter. Keep the review schedule, the procedure, alert rule exports, and tickets for escalated events. Confirm with your auditor which format they accept, since they decide what is sufficient for the evidence they test.

Which open-source tools can help the review, and what should we confirm?

Wazuh decodes collected logs, compares events with a ruleset that includes over 3,000 built-in rules and decoders, writes alerts to files, and forwards them to a dashboard for review. OpenSearch Security Analytics runs detectors against ingested logs using Sigma rules and records findings with severity. Both support the review, but you should confirm each platform's current capabilities, license terms and supported log sources in your environment before relying on them. Tool choice does not change the obligation; the review record still needs a named reviewer and a schedule. See the Wazuh ruleset documentation for rule details.

How DeployOpen prepares review processes and evidence for Safeguard 8.11

DeployOpen plans, implements and documents the log review workflow that Safeguard 8.11 asks for, inside your own infrastructure. We prepare the systems, review cadence and evidence that an independent assessor can test, while your organization owns the control and the decision to meet it.

How we scope

Each engagement starts with a written scope listing the log sources, platforms and teams that fall under the weekly review.
We confirm which assets sit in IG2 or IG3 scope and record the review owner for each log stream.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.

How we build

We configure detectors and Sigma-based rules in self-hosted tools such as OpenSearch Security Analytics or Wazuh to surface anomalies for review.
We set up review schedules and alert routing so each review date is recorded and the interval between reviews can be measured.
We test detection logic against sample events and document the tuning decisions, so reviewers can explain what they looked for.

How we hand over

We deliver a written review procedure covering cadence, reviewer roles, escalation paths and how review completion is recorded.
We provide exported review records, alert histories and dashboard configurations that show review dates across the period assessed.
Your staff receive a walkthrough so they can run reviews, and an independent assessor can test the evidence without DeployOpen involvement.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, so the review workflow keeps running after handover.
We can review rule changes and platform upgrades against the documented procedure before they reach production logs.
Confirm with your auditor or assessor which review records they will accept, since DeployOpen prepares evidence but does not issue any report or certificate.