Safeguard 17.9 Security incident thresholds: requirements

What Safeguard 17.9 security incident thresholds requires

Safeguard 17.9 asks you to establish and maintain security incident thresholds that, at a minimum, tell your staff and responders when something that happened on your systems becomes an incident. The threshold must separate an incident from an event, and it must be reviewed annually or after significant enterprise changes. Only Implementation Group 3 carries this Safeguard, so it applies to enterprises with security specialists and regulated, sensitive assets facing sophisticated, targeted attacks. If your organization has been asked to show a documented incident threshold by a customer, regulator or assessor, this is the Safeguard they will look for. CIS publishes the Controls for free use by any organization to improve its own cybersecurity, so the threshold document you write does not need a license to be used internally, although commercial reuse of CIS content requires CIS's approval.

The distinction between an event and an incident is the core of the requirement. An event is any observable occurrence, such as a failed login or an alert from a scanner. An incident is an event that has, or is likely to have, an adverse effect that triggers your response process. CIS gives example threshold categories to anchor the definitions: abnormal activity, security vulnerability, security weakness, data breach and privacy incident. A useful threshold states, for each category, what evidence moves an item from one bucket to another, who decides, and which response path applies. For instance, a privacy incident may require notifying the data protection officer within a set window, while a vulnerability with no evidence of exploitation may go to the patch queue. The exact categories and triggers are your decisions, so write them down and tie them to the response process in Safeguard 17.4.

Thresholds are hard to get right in practice because the boundaries blur. Analysts see many abnormal events each day, and a threshold set too low floods the response team while one set too high delays notification duties that carry legal deadlines. Privacy and breach categories often depend on facts that are not known in the first hours, so the threshold needs a way to escalate on uncertainty. Assessors measure the documentation itself: the Assessment Specification scores Safeguard 17.9 on the completeness of the components in the threshold document, and a missing document fails the Safeguard. Confirm with your assessor which components they expect, and check whether your detection tools, such as Wazuh rule severities or OpenSearch Security Analytics findings, can be mapped to your threshold categories so that the classification can be shown in case records.

Which systems, teams and events fall under incident thresholds

A threshold is only as useful as the events it can see. The cards below cover the scoping decisions that determine which event sources, business units, regulated data sets, service providers and enterprise changes the documented thresholds must reach, and what each decision means for the work that follows.

Event sources that feed the threshold

Decide which telemetry the threshold is written against: the SIEM, endpoint detection and response, cloud control plane and workload logs, identity provider logs, and alerts from third-party monitoring. A threshold that names only one source will classify events from the others inconsistently. List each source, the team that owns it, and whether its alerts reach the incident queue. Confirm that a single event can be traced across sources, because a classification depends on context from more than one feed.

Business units in scope

Record which business units, subsidiaries and sites the threshold applies to. An enterprise that writes thresholds for headquarters but not for an acquired unit will have two definitions of an incident in one organization. Each in-scope unit needs a named owner who can confirm that its systems emit the events the thresholds reference. Units with separate reporting lines often need their own examples for abnormal activity, so the document should say where local additions are allowed and who approves them.

Regulated and sensitive data sets

Identify the data sets that move a suspected event into the breach or privacy incident category. Personal data, payment data, health records and controlled unclassified information each carry their own notification duties, so their boundaries belong in the threshold. Name the repositories, databases and file shares that hold them, and state what evidence of access or exfiltration triggers the higher category. Confirm with legal counsel which regulations apply, because the threshold cannot assign an event to a notification path it has not defined.

Service provider events

Decide how events reported by service providers are classified. A provider may report a breach in its own environment that affects your data, or send an alert about your tenant that you must triage. Write down which provider notifications count as incidents for your enterprise, how quickly they must be received, and who on the internal side takes ownership. Contract terms and the provider inventory should match these decisions, so that an event raised by a third party does not sit outside the threshold.

Enterprise changes that trigger review

Safeguard 17.9 requires review after significant enterprise changes, so the document needs a defined list of those changes. Typical triggers include a new cloud region, a merger, a new regulated product line, a replaced SIEM or EDR platform, and a change in the service provider that runs monitoring. Assign an owner to log each change and decide whether it prompts a review. Without this list, the annual review is the only check, and new telemetry may go unclassified for months.

How the CIS assessment specification scores 17.9

The CIS Controls Assessment Specification scores Safeguard 17.9 on a Completeness metric: the share of the threshold components that appear in your documented security incident thresholds. The specification treats Safeguard 17.4, the documented incident response process, as a prerequisite, so an assessor will expect to see that process in place before the thresholds are measured. If your enterprise has no documented security incident thresholds at all, the Safeguard receives a failing score. Partial documentation earns a partial result, which means the document itself needs to be complete, not just present.

The specification says what to measure, not how. It does not define which components a threshold must contain, which severity levels to use, or what evidence a particular assessor will accept as proof of review. You must decide those points and be able to defend them. Before drafting, confirm with your assessor or auditor which components they will count and how they want the annual review and post-change review recorded. Read the specification for 17.9 directly at the CIS Controls Assessment Specification page for Safeguard 17.9 and map each example category in the Safeguard to a component in your own document.

A practical check is to list every threshold category you rely on, such as abnormal activity, security vulnerability, security weakness, data breach and privacy incident, and confirm that each one has a defined trigger, owner and escalation path in writing. Then test the document against the review trigger: if a significant enterprise change occurred and the thresholds were not revisited, the completeness score will fall short of what the Safeguard describes. Record the review date and the reviewer so that the evidence shows the thresholds were maintained, not only written once.

How an assessor tests Safeguard 17.9

This table compares the five checks an assessor typically runs against Safeguard 17.9, the evidence each one asks for, and the gaps that most often appear. Read each row as a question the assessor will put to the organization, with the evidence needed to answer it. The main takeaway is that a threshold document alone rarely passes; assessors look for a clear incident and event split, coverage of the example categories, review records and a visible link to the response process.

Assessment check	Evidence the assessor expects	Where it usually fails
Confirm documented thresholds exist	A current, approved document that sets out security incident thresholds, with an owner and version history	Thresholds exist only in analyst practice or tool settings and were never written down, which results in a failing score
Check the incident versus event definition	Written criteria stating when an observed event becomes an incident, with the decision point and who makes the call	Definitions are present but vague, such as 'anything suspicious,' so triage decisions cannot be reproduced
Check coverage of CIS example categories	Thresholds addressing abnormal activity, security vulnerabilities, security weaknesses, data breaches and privacy incidents, or documented reasons for any category not used	Breach and privacy incidents are missing, often because the policy was written only by the security team without legal or privacy input
Check annual and post-change review records	Dated review records at least annually, plus evidence of review after significant changes such as new platforms, mergers or cloud migrations	Reviews are documented as completed but show no changes, or no review follows a major infrastructure change
Check linkage to the 17.4 response process	Cross-references from the thresholds to the incident response process, showing which threshold triggers which response steps and roles	Thresholds and the response plan were written separately and do not agree on severity levels, escalation paths or timing

Steps to define and maintain incident thresholds

This sequence turns Safeguard 17.9 into a working set of definitions that the security team, incident handlers and detection engineers apply the same way. It ends with documented thresholds, mapped event sources, named escalation owners and a review schedule that stays current as the enterprise changes.

Confirm the incident response process exists
Before writing thresholds, check that the incident response process required by Safeguard 17.4 is documented and approved. The assessment specification lists 17.4 as a prerequisite for measuring 17.9, so the thresholds must plug into an existing process rather than float on their own. The security lead or incident handling lead confirms the process, its owner and its approval date. The output is a short written confirmation that the process exists, or a gap list to close first.
Inventory the event sources
List every place security-relevant activity is recorded or detected: endpoint and network sensors, identity systems, cloud audit logs, email security, application logs, vulnerability scanners, data loss prevention and third-party service feeds. Assign each source an owner and note what it can and cannot tell you. This inventory shows where abnormal activity, vulnerabilities and possible breaches will first appear, so later threshold categories have real signals behind them. The output is a source register that the detection and operations teams have reviewed.
Draft definitions for events and incidents
Write plain definitions that separate an event, meaning any observable occurrence in a system, from an incident, meaning an event that has or is likely to have an adverse effect on confidentiality, integrity or availability. Define the example categories CIS gives for 17.9: abnormal activity, security vulnerability, security weakness, data breach and privacy incident. Include the sensitive data terms your organization uses, so privacy incidents are recognized even when no security control failed. Draft the glossary with legal and privacy input. The output is a draft definitions section with one entry per category.
Set escalation criteria and named owners
For each category, state the conditions that move an item from event to incident and the conditions that trigger escalation to the incident handling lead, legal, privacy, executive leadership or external parties such as law enforcement, insurers or regulators. Name an accountable role for each decision, with a backup where the role is staffed by one person. Where a third party runs monitoring, state which decisions stay internal. Confirm each criterion with the owners, since a threshold no one can act on does not help. The output is a threshold matrix with criteria, decision owners and escalation paths.
Approve and publish the thresholds
Route the draft through the approval body your governance model uses, such as the security steering group or the executive owner of incident response, and record the approver and the approval date. Publish the approved version where the incident response team and the workforce reporting process can find it, and make sure the definitions match the wording in the Safeguard 17.3 reporting guidance. The output is an approved, versioned threshold document that the assessor can read as the documented thresholds.
Wire thresholds into detection tooling
Translate the thresholds into the rules and case handling of your detection stack. In a SIEM or security analytics platform, map detection rules to the event categories and set the severity or case-creation behavior that follows from each threshold. In a case management tool, configure how alerts become cases and which fields record the category. Test the mapping with sample events to confirm that the same activity is classified the same way each time. The output is a test record showing each category produces the intended alert or case.
Schedule annual and change-triggered reviews
Safeguard 17.9 expects the thresholds to be reviewed annually and after significant enterprise changes, such as a new cloud platform, an acquisition, a new regulated service or a major vendor change. Record the review owner, the review date and the change triggers in the document itself. Each review should compare the thresholds with recent incidents, false positives and near misses, then update the definitions and the tooling mapping. The output is a review log with dated entries, approvers and a list of changes made in each cycle.

Evidence that shows documented thresholds are in use

An assessor checking Safeguard 17.9 will look past the threshold document itself and ask whether the thresholds are applied to real alerts and changed when the environment changes. The cards below cover the documents, review records, detection mappings, tuning logs and case records that connect a written threshold to daily triage decisions.

Threshold document with approval history

The core artifact is the written threshold document, which must at minimum separate an incident from an event and give example categories such as abnormal activity, security vulnerability, security weakness, data breach and privacy incident. Keep each version with its owner, approver, approval date and a summary of what changed. Check that the current version is the one staff actually follow, and that the document names who may reclassify an item. Without a documented approval trail, an assessor has no basis for treating the thresholds as management-approved.

Category-to-detection mapping

Maintain a table that maps each threshold category to the detections that feed it, such as a Sigma rule match, an EDR alert or a user report. Each row should name the data source, the triage owner and the category it produces. For example, an illustrative row could map repeated failed logins from one account to the abnormal activity category and list the SIEM rule that raised it. Gaps in this table show where a category exists on paper but no detection feeds it.

Review records with dates and triggers

Safeguard 17.9 calls for thresholds to be reviewed annually or after significant enterprise changes. Keep a dated review log that records who reviewed the document, the outcome, and the trigger, such as an acquisition, a new cloud region, a regulatory change or a major incident. Each change trigger should link to a dated entry in the change or risk register. Confirm that the annual review date is on a calendar and that missed reviews are visible to the owner.

Tuning and rule change logs

Detection rules are tuned over time, and each change can shift which events cross the incident line. Record every rule addition, suppression or severity change with the reason, the requester, the approver and the date. Version control for rule repositories, such as Git history on Sigma or Wazuh custom rules, supplies much of this record. Check that a rule change which moves an alert between categories also updates the threshold document or the mapping table.

Sample case records showing thresholds applied

Case records are the strongest evidence that thresholds work in practice. Pick representative cases that show an event screened out, an event promoted to an incident, and a privacy incident routed to the right owner. Each record should carry the classification decision, the rationale and the time stamps. Case management tools such as DFIR-IRIS keep these as a single record with tasks, evidence and an audit trail, which makes sampling straightforward for an assessor.

Keeping evidence current between audits

Evidence decays between assessments, so assign an owner to each artifact and a recurring check, such as a quarterly sample of recent alerts classified against the document. Store the threshold version, mapping and logs in one controlled location with retention rules set by policy. Ask your platform team to confirm which log retention periods apply to detection and case data in your environment, because those periods determine how far back an assessor can sample.

What meeting Safeguard 17.9 costs in money and effort

This table lists the cost and effort components of documenting and maintaining security incident thresholds, who is paid for each, whether it is one-time or recurring, and what drives it up or down. No fees are published here, so use the columns to build a quote request and compare written scopes. Most of the recurring effort comes from the annual review, not the first draft.

Cost component	Who is paid or who spends time	One-time or recurring, and what drives it
Threshold authoring time	Internal security or incident response lead, with legal and operations input	One-time for the first version. Drivers: number of business units, regulated data types, and how many threshold categories already exist in other incident documents.
Detection tuning engineering	Internal SOC or platform engineers, or an implementation partner preparing rules and alert routing	Initial setup, then recurring tuning. Drivers: log sources connected, alert volume, and how many rules must map to each threshold category.
Review meeting time	Incident response owner, security leadership, legal and privacy staff	Recurring at least annually, and after significant enterprise changes. Drivers: organizational change rate, mergers, new cloud regions, and new regulated services.
Tooling and licenses	Vendors for commercial SIEM, SOAR or case management; or internal staff for self-hosted tools	Commercial licenses recur. Self-hosted open-source tools such as DFIR-IRIS, OpenSearch Security Analytics and Wazuh carry no license fee, but hosting, storage, upgrades and staff time still apply.
External review of the threshold document	Independent consultant or legal counsel, if engaged	Optional and usually one-time per revision. Drivers: regulatory exposure, written scope of the review, and whether the reviewer also tests the detection rules.
Auditor sampling and evidence preparation	Internal evidence owner; the independent auditor performs sampling and issues any report	Recurring with each assessment cycle. Drivers: number of samples requested, how easily dated thresholds and review records can be produced, and whether the auditor has a sampling plan.

Open-source tools that produce threshold evidence

DFIR-IRIS is a case management platform for incident response, licensed under LGPL-3.0-or-later. It does not decide whether an alert is an event, a vulnerability, a breach or a privacy incident. Its value for Safeguard 17.9 is that it records what the team decided and when, so an assessor can compare documented thresholds against real handling decisions.

Case records: Each case is kept as one record that groups affected assets, indicators of compromise, tasks and evidence, which lets you show which category a case was assigned to.
Audit trail: Changes to a case are logged, so reviewers can see when a classification was made or revised.
Alert triage: Alerts from SIEM, EDR and REST sources can be triaged into cases, creating a link between a detection and the threshold category applied.
Evidence chain of custody: Evidence is logged with SHA-256 verification and chain of custody records, which supports breach and privacy incident files.
Reports: Reports generated from case data can be used to show how thresholds were applied across a review period.

Confirm with your team that the case categories you use match the threshold categories in your written policy, and that the audit trail is retained for the period your auditor will sample.

Where threshold programs usually fall short

Safeguard 17.9 looks simple on paper, but most gaps appear where thresholds are written once and never connected to the rest of the response program. The cards below cover the failure points an assessor is likely to find, each with the check that closes it.

No documented thresholds

Many enterprises apply judgment case by case and have no written thresholds at all. Under the CIS Controls Assessment Specification, a missing document is a failing score for Safeguard 17.9, regardless of how capable the team is in practice. Check that a current, approved document exists, names the categories used, and is findable by the people who triage alerts.

Events and incidents conflated

Teams often treat every alert as an incident, or every incident as a routine event, so queues overflow or real compromises wait. Safeguard 17.9 asks at minimum for a clear line between the two. Test the definitions by giving three sample alerts to two analysts and checking whether they reach the same classification using only the written thresholds.

Thresholds disconnected from the response process

A threshold only matters if it triggers something. When the categories are not tied to the response process required by Safeguard 17.4, a classified incident may not reach the incident handling lead or the reporting contacts. Confirm that each category names the action, owner and escalation path it starts, and that the mapping is written into the response process itself.

No review trigger

Thresholds drift as systems, data flows and regulatory duties change, yet many documents are never revisited. Safeguard 17.9 expects review at least annually and after significant enterprise changes such as a merger, a new cloud region or a new regulated service. Check the review date, the named owner and a change log that shows when the last review was triggered and why.

Thresholds without matching detection rules

A threshold on paper does nothing if no detector, correlation rule or alert routing reflects it. Analysts then classify by memory, and the documented categories cannot be shown in logs. Map each threshold category to at least one detection source, such as a Sigma rule in OpenSearch Security Analytics or a Wazuh rule, and keep the rule identifiers in the threshold record as evidence.

Questions buyers ask about Safeguard 17.9

How much effort does Safeguard 17.9 take to document?

Most of the effort is analysis and sign-off, not software. The main cost is internal staff time from security, IT operations, legal, privacy and business owners who agree what counts as an event, an incident and each example category. Some of that work is one-time: drafting the thresholds and getting them approved. Some recurs: the safeguard calls for review at least annually and after significant enterprise changes. Effort rises with the number of systems and data types in scope, the number of alert sources that must be mapped, how many approvers are involved, and whether a documented incident response process under Safeguard 17.4 already exists. The Assessment Specification lists 17.4 as a prerequisite, so a missing process adds work. When asking for a quote, request a written scope that lists workshops, deliverables, document format, approval steps and the review cycle.

How long does it take to write incident thresholds?

No researched duration is available for this work, so the honest answer depends on your environment. The schedule is driven by how quickly stakeholders can meet, how many systems and data classes need thresholds, whether your incident response process and roles are already written, and how many review cycles your approvers require. Thresholds are easier to write after the process under Safeguard 17.4 and the roles under Safeguard 17.5 exist, because the categories then match the way your team actually escalates. Ask any provider, including DeployOpen, to state milestones and dates in the written scope before work starts. DeployOpen agrees scope, deliverables and timelines in writing before work begins, so the schedule should appear there rather than as a verbal estimate.

What does the work need from our internal staff?

Internal staff must make the decisions, because the thresholds describe your own risk tolerance and operations. Typical contributions include:

A named owner, usually in security or incident response, who approves the final document and keeps it current.
Incident handling leads from Safeguard 17.1, who know how alerts become cases in practice.
Privacy or data protection staff, who define what a privacy incident means for your organization.
Legal and compliance reviewers, who check how categories relate to contractual and regulatory duties.
Operations and application owners, who describe normal activity so abnormal activity can be recognized.

Expect each group to attend a few working sessions and review drafts. Ask who will hold the decision rights and how disagreements between groups will be resolved before the work starts.

Can we define security incident thresholds in-house?

Yes. Safeguard 17.9 is a documentation requirement, and an internal team with incident response and business knowledge can write it. CIS states that the Controls are free for any organization to use to improve its own cybersecurity, so an internal team can adopt the categories without a license conversation. Outside help is most useful for an independent view of gaps, facilitated workshops, and mapping thresholds to the detection tools you already run. Check licensing before an outside firm reuses CIS text in its deliverables. CIS content is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0, and commercial use requires CIS's prior approval. Ask any provider to confirm how it will reference CIS material in your documents and whether that use is permitted for your engagement.

What will an assessor ask for to verify Safeguard 17.9?

The Assessment Specification scores Safeguard 17.9 with a Completeness metric, which measures the share of required components included in your documented thresholds. If no thresholds are documented, the safeguard fails. An assessor will therefore ask for the thresholds document itself, showing that it separates an incident from an event and addresses example categories such as abnormal activity, security vulnerability, security weakness, data breach and privacy incident. Expect requests for version history, the approval record, evidence of the annual review, and records of reviews after significant changes. The assessor will also look at whether the thresholds connect to the process under Safeguard 17.4. The Specification defines what to measure, not how, so your documentation must show the method you chose.

Can a partner issue the assessment or certify Safeguard 17.9?

No partner can issue an assessment report or certificate for Safeguard 17.9 except an assessor that is authorized to do so. DeployOpen prepares systems, controls and evidence, and it does not issue audit reports, attestations or certifications. Only independent auditors and certification bodies issue those. First, confirm with whoever requires the evidence whether they accept self-assessment, an internal audit review, or a third-party assessment. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme, so a customer or regulator may require more than a CIS-aligned document. CIS Controls Accreditation covers CIS SecureSuite member organizations that provide implementation, auditing or assessment services, with a listed application fee of $1,500 for CREST members and $2,500 for non-members. Ask any provider whether it holds that accreditation and what its role would be.

How do thresholds connect to detection and case tools?

Thresholds tell your detection pipeline which signals are events to monitor and which are incidents to open as cases, so they should map to severity and escalation rules. Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus custom rules, then writes alerts to alerts.log and alerts.json and maps them to MITRE ATT&CK. OpenSearch Security Analytics matches logs against Sigma rules, records findings with severity and sends alerts to channels such as Slack or email. DFIR-IRIS triages alerts from SIEM, EDR and REST sources into cases with an audit trail, and logs evidence with SHA-256 verification. Confirm how each platform handles severity and case creation in your version, then test one example per threshold category. Illustrative example: a failed login spike becomes an event, and confirmed credential misuse on a privileged account becomes a case.

How DeployOpen prepares incident thresholds for assessment

DeployOpen's role on Safeguard 17.9 is to prepare the threshold documentation, the detection configuration that follows from it and the evidence an independent assessor will ask for, inside your own cloud accounts, data centers or air-gapped network. The organization keeps ownership of its thresholds and decides who may change them. Scope, deliverables and timelines are agreed in writing before any work starts, so the written scope should state which business units, asset classes and log sources the thresholds cover, and who signs off the final document. DeployOpen does not issue audit reports, attestations or certifications. Only an independent auditor, assessor or certification body does that, and the assessor decides whether the evidence meets the Safeguard.

In practice, the threshold document needs to show a clear line between an incident and an event, with the example categories named in the Safeguard (abnormal activity, security vulnerability, security weakness, data breach and privacy incident) each given a definition, an owner and a response path. DeployOpen can draft that content with your incident response lead and legal and privacy staff, then align the detection side so that alerts from tools such as Wazuh or OpenSearch Security Analytics carry a category that maps back to the document. The assessment specification treats Safeguard 17.4 as a prerequisite, so the threshold document should reference the incident response process rather than sit beside it as a separate artifact. Confirm with your assessor which version of the specification and which Implementation Group scope they will use before drafting begins.

The evidence an assessor typically asks to see is the approved threshold document with its version history, the annual or post-change review record, and a sample showing how a real or test alert was classified. DeployOpen can organize these records, export detector and rule configurations, and prepare a short walkthrough for the assessor, but the classification decisions and the review sign-off remain with your staff. Ask any implementation partner to name the artifacts it will hand over, the format and the owner of each, and what happens if the assessor requests more. Costs usually split into one-time work to write the thresholds and configure detection, plus recurring effort for annual review and for updating thresholds after significant enterprise changes, which the Safeguard requires.

Safeguard 17.9 Security incident thresholds