Adjust severity when the underlying rule is valid but its operational importance differs by context. Write custom rules when you need a control that the standard catalog does not cover, or when compliance requirements demand a precise local policy. This separates tuning from true extension, which keeps governance clearer and makes maintenance easier over time.
When a rule is right, but the severity is off
Adjust severity when the rule itself is still correct, but the business impact, exposure, or operational context changes how urgently it should be acted on. This is common when one control failure is noisy in one environment and material in another, or when a finding is valid but only becomes critical on production assets, regulated data, or privileged paths.
Severity tuning is a prioritisation decision, not a rewriting exercise. It lets teams keep a standard rule intact while reflecting differences in asset criticality, blast radius, compensating controls, or exception handling. That distinction matters because it preserves comparability across environments and avoids turning the rule catalog into a local fork.
When a custom rule is the better choice
Write a custom rule when the standard catalog does not express the condition you need to detect or govern. That usually means the control objective is genuinely new, the logic depends on local business policy, or a compliance requirement needs a precise condition that severity labels cannot capture.
A custom rule changes the control surface. It adds new logic, new maintenance, and a stronger obligation to document ownership and testing. If the request is really about a different threshold, scope, or exception path, severity adjustment is usually cleaner. If the request is about a missing requirement or a materially different detection pattern, a custom rule is justified.
How to separate tuning from extension in practice
The practical test is whether the underlying rule still answers the same question. If yes, adjust severity or routing. If no, define a new rule. That keeps the catalog coherent and makes it easier to explain why two environments, two business units, or two control sets produce different outcomes.
Teams also need a clear change record for either path. Severity changes should reference the context that drove the new priority, while custom rules should state the unmet control objective, the intended scope, and how the new rule will be reviewed over time. That discipline reduces duplicate logic and makes later maintenance much easier.
Risk and Threat Considerations
Misclassifying a tuning decision as a custom rule can create control sprawl, while forcing a genuinely new requirement into severity alone can hide a gap in coverage. The risk is not just operational clutter, it is that important exceptions, privileged paths, or compliance-specific conditions become harder to see and harder to govern.
Failure mechanism: The team uses severity to describe a condition that actually needs new logic, or writes a new rule when the existing rule already covers the issue, which leads to duplicated controls, inconsistent triage, and weaker auditability.
Impact: Response priorities become inconsistent, maintenance cost rises, and control intent becomes harder to prove to auditors or internal reviewers. Over time, that can produce both missed issues and noisy escalation pathways.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-17 — Incident Response Management | Rule severity affects triage priority and response handling. |
| Recommendation — Set severities so responders can prioritize alerts consistently during triage. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Rule tuning changes how monitoring findings are prioritized and escalated. |
| Recommendation — Adjust monitoring thresholds and alert severity to preserve actionable detection. | ||
| ISO/IEC 27001:2022 | A.8.16 — Monitoring activities | Severity tuning supports monitoring outcomes and reduces noisy or unclear alerts. |
| Recommendation — Calibrate monitoring rules so findings remain meaningful and reviewable. | ||
Practitioner Guidance
What to verify: Before changing severity, confirm that the rule logic still matches the control objective and that only the priority has changed. Before writing a custom rule, verify that the standard catalog cannot express the condition through scope, threshold, or exception handling.
Decision rule: If the question is “how urgent is this finding here?”, tune severity. If the question is “what condition should be detected that the catalog cannot currently express?”, write a custom rule.
Practitioner takeaway: Use severity to reflect context, and custom rules to express new control intent, because that separation keeps governance understandable and prevents the rule base from becoming a pile of local exceptions.
Related resources from NHI Mgmt Group
- When should organisations use prebuilt policy templates instead of writing custom policy code?
- When should organisations choose managed policy enforcement over writing custom OPA rules?
- How do organisations operationalise NHI ownership at scale?
- When should organisations treat an NHI as a high-priority risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
