Safeguard 13.11 Tune alerting thresholds

What CIS Safeguard 13.11 asks for and why alert tuning fails in practice

If your SIEM or alerting platform is noisy, stale, or simply trusted less every quarter, Safeguard 13.11 requires that security event alerting thresholds be tuned at least monthly, and it is an IG3 safeguard that only applies once centralized alerting under 13.1 is in place. The assessment specification treats 13.1 as a prerequisite, so a team that cannot show centralized alerting has no basis for claiming 13.11. The safeguard is measured at zero and fails if more than thirty days have passed since thresholds were last tuned, which makes the review cadence the thing an assessor checks first.

The risk behind the cadence is drift. Detection thresholds were set against the environment as it looked on the day they were written. Over time, new applications, cloud services, and user populations change the baseline, so rules either flood analysts with false positives, which produces alert fatigue and quiet dismissal, or stop matching real behavior, which produces missed detections. Both failures look healthy on a dashboard until an incident shows the gap. Tuning is the control that keeps the alerts matched to the environment they monitor.

Tuning fails for three predictable reasons. Ownership is unclear: the SIEM team owns the platform, the security operations team owns the alerts, and the application owners own the logs that feed them, so nobody is accountable for the monthly review. Tuning is treated as a one-time project delivered at go-live rather than a recurring process. And changes are made in consoles without records, so an assessor cannot tell what was tuned, why, or when. Before a readiness review, confirm a named owner, a standing monthly review with dated minutes, and a change log that links each threshold change to the alert volume or detection evidence that justified it.

Which alerting pipelines, teams and third parties fall under the monthly tuning cycle

Safeguard 13.11 only makes sense against a defined set of alerting pipelines, owners and providers. The cards below cover the decisions that set how much work the monthly tuning cycle involves and who signs off on it.

Log sources feeding centralized alerting

Safeguard 13.1 centralizes security event alerting, and 13.11 tunes the thresholds applied to that stream. Start by listing every log source the central platform ingests, such as endpoint agents, firewalls, identity providers and cloud audit trails. Each source changes event volume and noise, so a threshold that suits one source can flood another. Confirm which sources are actually connected and which are only documented.

Detection rules and their owners

Every detection rule, whether a vendor ruleset, a Sigma rule or a custom correlation, has a threshold that may need adjustment. Record which rules are active, which were disabled, and who approved each change. A rule with no named owner tends to stay untuned for longer than the monthly cycle allows. Keep this inventory in version control so the assessor can see the change history.

Network assets in the Network asset class

Safeguard 13.11 is assigned to the Network asset class in v8.1, so the tuning scope should follow the network devices, sensors and segments whose alerts reach the central platform. Map which switches, routers, firewalls, VPN concentrators and network intrusion sensors are in scope. Devices left out of the inventory generate alerts that nobody tunes and events that nobody reviews.

Security operations and threshold ownership

Security operations usually decides which alerts are actionable and which thresholds are too sensitive. Platform engineering often controls the pipeline, parsers and retention that determine what reaches the rules at all. Write down which team proposes a change, which team implements it and who approves it. Without that split, a threshold change can pass review in one team and break ingestion in another.

Managed service providers and detection vendors

If a managed detection provider monitors the alerts, it may own part of the tuning work, and the contract should say so. Ask the provider who approves threshold changes, how often it reviews them, and whether it documents each change with a date and reason. Your organization still owns the control, so the evidence for the monthly review must be available to you and to your assessor, regardless of who performs the work.

IG3 scope and voluntary adoption

Safeguard 13.11 is assigned only to Implementation Group 3, one of 23 IG3 safeguards. Organizations at IG1 or IG2 are not required to meet it, but they can adopt the monthly cycle voluntarily if their alerting volume justifies it. If you adopt it early, state that in your scope so the assessor does not measure you against an IG3 requirement you have not claimed. Check the Implementation Groups page before you write the scope statement.

How 13.11 maps to NIST, ISO, SOC 2 and PCI DSS requirements

The CIS Controls Navigator maps Safeguard 13.11 to NIST SP 800-53 Rev. 5 control SI-4, ISO/IEC 27001:2022 Annex A control 5.7, AICPA SOC 2 criteria A1.1 and CC7.2, and PCI DSS v4.0 requirement 12.10.5. In practice, this means one body of evidence for tuning security event alerting thresholds at least monthly can be offered to several assessors. The tuning record, the review date, the threshold changes and the rationale behind them are the artifacts that matter. A mapping tells you where that evidence is likely to be relevant, but it is a CIS statement about its own Safeguard, not a finding by any framework owner or assessor.

A mapping is a starting point, not a determination. It does not replace the independent auditor's or assessor's own testing, and each framework is judged on its own text. The SOC 2 criteria, for example, are evaluated in the context of the service organization's system description and the period covered by the report. ISO/IEC 27001 certification is issued by an accredited certification body, and PCI DSS validation depends on the assessor's scoping decisions. Before relying on the mapping, confirm each link against the current framework text with your assessor, and ask whether they expect the monthly tuning record to be sufficient on its own or paired with other evidence such as the alert review workflow.

Practical step: build one evidence register for 13.11 with columns for each framework reference, the artifact that supports it, the owner and the date of the most recent tuning cycle. Ask your assessor to confirm which references they will test and which artifacts they will request, since requirements such as the PCI DSS and SOC 2 items may be assessed against different sample periods. Where a reference is unclear, record the question rather than assuming the mapping settles it. An implementation partner can help organize the register and the tuning records, but the organization owns the controls and the assessor alone issues any report or certification.

How an assessor tests Safeguard 13.11 and what they ask for

This table walks through how an assessor works through Safeguard 13.11, from the 13.1 prerequisite to the 30-day check and the evidence requested. Read it as a checklist of what to have ready before an assessment, with the common findings that cause a fail.

Assessment step	What the assessor checks	Evidence to have ready
Prerequisite check	Confirms Safeguard 13.1 centralized security event alerting is in place, since 13.11 is measured against alerts that flow through that central point	Description of the central alerting platform, its log sources and a sample of correlated alerts from the current period
Date of last tuning	Identifies the most recent date on which security event alerting thresholds were tuned and compares it with the current assessment date	Dated change records for each threshold or rule change, with the person who made it
30-day limit	Measures 13.11 as failed if more than thirty days have passed since the last tuning, so the assessor looks for a continuous cadence rather than a single past review	A tuning calendar or recurring review ticket series showing no gap longer than thirty days
Before and after versions	Compares the threshold or rule version before and after each tuning event to confirm a real change was made and recorded	Versioned rule or threshold files, configuration diffs and the reason recorded for each change
Approval records	Checks that changes followed the organization's own change process and were approved by an accountable owner	Approval tickets, change advisory minutes or pull request approvals tied to each tuning event
Sampling of tuning events	Selects a sample of tuning events and traces each one to the alert volume and alert review results that prompted it	Alert volume reports before and after each change and records of the analyst review that followed
Common finding: undocumented changes	Threshold changes made directly in the console without a ticket, so the tuning date cannot be proven	Enforced change logging on the platform, with an audit trail of who changed which rule and when
Common finding: tuning not tied to review	Tuning happens on a schedule but is not linked to any review of alert quality, so the assessor cannot see why thresholds moved	A documented review that states which alerts were false positives, missed events or noisy, and what was changed in response

How to set up a monthly alert tuning cycle that passes the 30-day test

This sequence turns Safeguard 13.11 into a repeatable monthly routine: a verified central alerting foundation, a named owner, data-driven threshold changes with peer review, and a dated record that proves each tuning happened within the 30-day window.

Confirm centralized alerting and log coverage
Before tuning anything, confirm that Safeguard 13.1 is in place. Security events from endpoints, servers, network devices and cloud services should reach one alerting platform, such as a SIEM or log analytics stack, and the assessment specification treats 13.1 as a prerequisite for measuring 13.11. Write down which log sources feed the platform, which are missing, and who approved the gap list. Tuning thresholds on incomplete feeds only hides the gaps, so a source inventory is the first output. Keep it as a coverage register that the monthly cycle checks against. The step is done when every in-scope source is either connected or listed with an owner and a planned date.
Assign a named owner and a fixed monthly date
Name one accountable owner for alert tuning and a backup who can act when the owner is absent. Put a recurring calendar entry on a fixed day each month, so the cycle does not depend on someone remembering. The owner should be able to approve threshold changes or route them to an approver. Record the owner, backup, approver and calendar date in the tuning register. A common gap is assigning the task to a shared mailbox or to whoever has time that month, which tends to break the cycle after the first missed review. The step is done when the register names the people and the recurring date, and the calendar invitation exists.
Review alert volume, false positives and missed detections
Pull the last period of alerts from the platform and sort them by rule, source and severity. Count how many alerts were closed as false positives, how many led to real investigations, and how many incidents were found by other means, such as a user report or a threat hunt that the rules did not flag. The missed detections are the most useful input because they show where thresholds are too high. Save the figures and the query used to produce them, so a later reviewer can reproduce the numbers. A common gap is tuning with no baseline, changing a threshold because it feels noisy without comparing it to earlier periods. The output is a dated review sheet tied to the rules it covers.
Change thresholds through a tracked change process
For each proposed threshold change, write a short change record that states the rule, the current value, the proposed value, the reason from the review sheet and the expected effect on alert volume. A second person who did not propose the change should review it before it goes live, and the approver should record acceptance. Apply the change in a test or staging instance where the platform allows it, then deploy to production. Common gaps include editing rules directly in production, skipping peer review because the change looks small, and suppressing a noisy rule entirely instead of narrowing it. The output is a change ticket linked to the register entry for each rule changed.
Record the outcome with the tuning date
Close the cycle by writing the date tuning was completed, the rules reviewed, the changes approved and any rules deliberately left unchanged with a reason. Confirm that the record shows a tuning event within the last thirty days, because that is the date the assessment specification measures for 13.11. Store the register, review sheets and change tickets together so an assessor can trace each change from data to approval to deployment. Run a spot check at the end of the cycle to confirm the production rules match the approved changes. The step is done when the register shows the completion date and an assessor could follow the trail without asking the owner for explanations.

Which evidence shows that thresholds were tuned within the last 30 days

Safeguard 13.11 is measured on one question: when were alerting thresholds last tuned? The cards below are the records an assessor expects to see, and they connect because each one dates, justifies or proves a tuning change made within the 30-day window. Keep them current between audits, not just before one.

Dated tuning register

A single register listing every threshold or rule change, with the date, the detector or rule name, the owner and the reason for the change. This is the first document an assessor opens, because the Safeguard is measured against the most recent tuning date. Check that the newest entry falls within 30 days of the assessment date and that the register is kept under version control, so the dates cannot be edited quietly.

Before and after change tickets

Tickets that record the threshold value before a change, the value after it, and the reason. Each ticket should link to the alert volume data that justified the change. Assessors use these to confirm that tuning actually changed something rather than being a rubber stamp. Check that tickets capture the exact values, not descriptions such as lowered or raised.

Alert volume and false positive reports

A report for each review showing how many alerts fired, how many were closed as false positives and how many led to investigation. These numbers are the basis for deciding whether a threshold is too sensitive or too loose. Keep one report per review cycle, exported from the SIEM with the query and time range recorded, so the figures can be reproduced.

Approval and peer review records

Evidence that a second person reviewed each threshold change before it went live, such as a signed change approval or a pull request review for rules stored as code. A reviewer who is independent of the person making the change strengthens the record. Confirm that approvers are named, that approval happens before deployment and that the approval timestamp is earlier than the change.

Detector and rule version history

The version history of detectors and rules in the SIEM or detection platform, showing each deployed revision with its author and timestamp. For open-source platforms this is often the rule repository's commit log plus the deployed configuration. Confirm that the deployed version matches the version in the register, because an assessor will compare them.

Monthly review calendar and minutes

A calendar entry or meeting minutes for each monthly review, listing attendees and the thresholds discussed, including reviews that changed nothing. A recurring gap in the calendar is the most common reason a 30-day window is missed. Keep minutes short, dated and linked to the register, and record the decision even when the answer is to leave the threshold as it is.

How OpenSearch Security Analytics and Wazuh support threshold tuning

Both OpenSearch Security Analytics and Wazuh produce the records that a Safeguard 13.11 tuning review needs, but neither one decides on your behalf what a threshold should be. The tuning decision stays with your security operations team, and the platforms supply the rule history, match counts and alert volumes that justify each change. 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 that carries the rule, the log type and the severity, and alerts go to channels such as Slack or email. Its correlation engine links findings across log types in a correlation graph, which helps you see whether a noisy rule is firing alongside related activity or on its own.

Wazuh (GPL-2.0-only) takes a different path to the same evidence. It decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus any custom rules you add. Matching alerts are written to alerts.log and alerts.json, mapped to MITRE ATT&CK, and forwarded to the Wazuh indexer for review in the dashboard. For the tuning register, the practical step is to keep dated copies of the rule set in use, record each rule change with its reason and approver, and compare alert volume before and after each change. Confirm with the vendor which exact threshold and frequency settings each tool exposes in your version, because the available knobs differ between rule types and releases.

Before you rely on either platform for the monthly review, confirm the license terms that apply to your deployment. Apache-2.0 and GPL-2.0-only impose different obligations if you modify the code or distribute it to others, and a managed or embedded use may raise questions your legal team should answer. Ask your implementation partner to document which rule sources, custom rule repositories and alert destinations are in scope, so the tuning history can be reproduced for an assessor. The audit question is not whether a tool fired, but whether the thresholds were reviewed on schedule and each change was justified from recorded evidence.

What meeting 13.11 costs in tooling, engineering time and assessment

This table breaks down the cost components of keeping security event alerting thresholds tuned monthly under Safeguard 13.11, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to build your request for quote, since no prices or durations are stated here and each line item must come from your own scope and environment.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
SIEM or alerting licenses	Software vendor, or no license fee for self-hosted open source	Setup is one-time, subscription or capacity fees recur	Log volume, number of log sources and retention period; open-source options such as OpenSearch Security Analytics or Wazuh remove license spend but not labor
Initial alerting baseline and threshold design	Internal engineers or implementation partner	One-time	Number of log sources, existing detection content and how much history is available to set baselines
Engineering time to build and maintain rules	Internal platform or detection engineers, or a retained partner	Build is one-time, rule maintenance recurs	Rule count, rule ownership model and how often log formats change after upgrades
Analyst time for monthly threshold review	Internal SOC or security operations staff	Recurring every month at minimum	Alert volume, false positive rate and whether review is documented as a repeatable process with change records
Evidence upkeep	Internal compliance or security team	Recurring	Frequency of threshold changes, the level of detail kept in tuning records and whether dates are captured automatically
Platform upkeep and upgrades	Internal operations team or retained implementation partner	Recurring	Version currency, number of nodes and the amount of custom integration that must be retested after each upgrade
External review or testing, if bought	Independent testers or consultants	Usually one-time per engagement, may recur if retained	Scope of the review, whether detection logic is tested against simulated attacks and whether findings are retested
Auditor sampling effort	Independent auditor, paid under the audit engagement	Recurring with each assessment cycle	Number of tuning records the auditor samples, and whether each change has a clear rationale and approval trail

Who owns threshold tuning, what an implementation partner can take on, and what the auditor will not do

Security operations owns the decision to change an alerting threshold and the monthly review that shows thresholds were tuned. The organization owns Safeguard 13.11 itself, so no partner or auditor can accept that responsibility on its behalf. The team decides which detectors are noisy, which are blind, and which findings justify a change, and it signs off each change with a reason.

Monthly review ownership: Name a accountable role and a backup who run the tuning review at least every thirty days, because the assessment specification fails the control when more than thirty days pass without tuning.
Threshold decisions: Record the old value, the new value, the rule or detector affected, the business reason and the approver for every change.
Feedback from analysts: Capture false positive and missed detection notes from triage so tuning is based on operational data, not guesses.
Prerequisite confirmation: Confirm that centralized alerting under Safeguard 13.1 is running before tuning starts, since the assessment specification treats it as a prerequisite.
Exception handling: Document any review that slips and the corrective action taken.

Check that someone inside the organization can explain every threshold change in the last review cycle without referring to an outside party.

How much effort does monthly alert tuning take, and can we do it in-house

How much effort does monthly alert tuning take?

The effort depends on how many detection rules are active, how noisy the log sources are, and how many alerts analysts already close as false positives. Tuning means reviewing which alerts fired, which were actionable, and then adjusting thresholds, suppressions or rule scope and recording the change. A small, well-documented ruleset with clean log sources takes far less monthly time than a large estate with many unmanaged sources. The Assessment Specification does not set a number of hours. Ask any provider to break its quote into the review, the change work and the documentation, and to state how many rules and log sources the estimate covers.

Can we tune alerting thresholds in-house?

Yes, most organizations can, provided they have someone who understands the detection logic and the systems generating the events. Safeguard 13.11 requires the tuning to happen at least monthly and to be evidenced, so the real question is whether your team can sustain that cadence after launch. In-house tuning works best when the same people own the SIEM or log platform, the alert queue and the change record. Teams that struggle usually lack a named owner, so reviews slip past the 30-day window the Assessment Specification uses to fail the measure.

How long does setup take before monthly tuning can start?

Setup timing depends on scope: how many log sources must be centralized first, how much of the ruleset needs to be built or customized, and how many teams approve changes. Safeguard 13.11 depends on Safeguard 13.1, centralized security event alerting, so tuning cannot be measured until alerting is centralized. DeployOpen works to a fixed-scope written plan that sets the timeline and deliverables before work starts, and we will not state a duration before that scope exists.

What does the tuning work need from our team?

Tuning needs four things from your side. Read access to the alert and event data from the centralized platform, so reviewers can see what fired and why. A named owner who signs off on each threshold change. A change approval path that fits your existing process, so tuning is not blocked by ad hoc requests. A record of each review, including the date, the alerts examined, the changes made and the reason. Without these, the work can be done but cannot be shown to an assessor. Confirm each item in writing before the scope is agreed.

Is Safeguard 13.11 required for every organization?

No. CIS assigns Safeguard 13.11 to Implementation Group 3 only, and it is one of the 23 Safeguards reserved for that group. Implementation Group 1 is the essential baseline for every enterprise, and Implementation Group 2 adds Safeguards for organizations with more operational complexity. IG3 targets enterprises with security specialists and regulated, sensitive assets facing sophisticated attacks. Your IG depends on your risk profile and any contract or regulator that references the Controls. Confirm which group applies with the party requiring the Controls, and check whether a framework you must meet, such as ISO/IEC 27001:2022 or SOC 2, requires equivalent monitoring evidence even if the IG does not.

Will an auditor accept a spreadsheet as tuning evidence?

An auditor decides whether the evidence is sufficient, so there is no guaranteed answer. A spreadsheet can work if it records each review date, the alerts examined, the threshold or rule changes made, the approver and the reason, and if the source data can be traced back to the platform. Problems arise when the log is edited by hand, reviews are backdated, or changes are made in the platform without a matching record. Ask your assessor early what format they will test. Many teams keep the platform's own change history as the primary record and use the spreadsheet as the review index.

What can a partner do for an audit, and what can it not do?

DeployOpen can plan the tuning process, configure the detection platform, prepare the review records and document how the evidence is produced. We can also support your team through the first review cycles. We cannot own the control, decide that your alerting is adequate, or issue an audit report, attestation or certification. Those belong to your organization and to the independent auditor or certification body you engage. The organization remains accountable for running the reviews, and the auditor tests whatever the organization can show.

How DeployOpen scopes, tunes and documents alerting for CIS 13.11

DeployOpen plans, implements and documents the tuning of security event alerting thresholds inside your own infrastructure, so the monthly review required by Safeguard 13.11 is scheduled, performed and recorded. We build on a centralized alerting foundation under Safeguard 13.1 and hand over the evidence your assessor will ask for, while your organization keeps ownership of the control.

How we scope

Engagements are fixed-scope, with the alerting sources, detectors and rule sets in writing before work starts.
The written scope names the log sources feeding Safeguard 13.1 and confirms the 13.11 review owner and cadence.
Scope defines the monthly tuning schedule and the thirty-day limit the assessment specification applies to each review.

How we build

We configure detectors and rules in the client's own deployment, such as OpenSearch Security Analytics or Wazuh, and confirm that matched events reach the alert channels.
We record a baseline of thresholds and alert volumes so each tuning change can be compared against what came before.
We test that tuned thresholds still raise alerts for known test events, so tuning does not silently suppress detection.

How we hand over

Handover includes a tuning log that records each review date, the thresholds changed, the reason and the approver.
We document the procedure so your staff can repeat the monthly review without DeployOpen involved.
Evidence packages are prepared for your independent assessor, who decides whether the evidence meets the requirement.

How we support

Ongoing support, upgrades and continuous testing of the alerting stack are available as retainers.
A retainer can cover the monthly tuning review on your behalf while your team retains approval of each change.
Ask for the support scope, response arrangements and review cadence in writing before you sign.