Your environment on day one is not your environment today. Since you first switched on your identity security queries, someone has connected a new SaaS app, retired a legacy directory, spun up a contractor program, and moved a few teams between clouds. The detection library you turned on in week one was tuned for a company that no longer exists.
Most programs feel this as noise before they recognize it as drift. A dashboard full of findings for a system you decommissioned last quarter. A Critical tile your team learned to scroll past. A query that fires correctly by the book and incorrectly for your business. Meanwhile, detections for the systems you just onboarded sit in the catalog, never switched on.
Teams in this position usually have two bad options. Keep everything running and teach analysts to ignore part of the dashboard. Or delete what doesn’t fit, and lose the definition, its history, and every improvement the catalog ships for it afterward. Neither builds a program. One trains people to tune out risk. The other trades long-term coverage for short-term quiet.
Control over detections isn’t a single switch. It’s a lifecycle. And the posture dashboard is only as trustworthy as your ability to run that lifecycle on purpose.
Silenced detections are an attack surface
Some of the most expensive breaches of the last decade weren’t missed because nobody was watching. They were missed because a detection was ignored, distrusted, or quietly turned off.
Target, 2013: the alerts that fired and went nowhere
Six months before attackers stole data on 40 million payment cards, Target had deployed a malware detection system. It worked. It flagged several versions of the attackers’ malware and even surfaced the servers they used to stage stolen data. Those alerts reached the security team and drew no response, and the feature that could have removed the malware automatically had been switched off. The root cause is one security teams still fight today: when a tool produces more alerts than people trust, real signal looks like noise.
Equifax, 2017: a monitor that was off, and nobody knew
Equifax had a device in place to inspect network traffic for exactly the kind of exfiltration that hit it. According to the House Oversight Committee’s investigation, an expired certificate had left that device blind for 19 months. Attackers ran roughly 9,000 queries across 48 databases without being seen. Once the certificate was renewed, the suspicious traffic surfaced almost immediately. A detection that is off without anyone knowing is worse than no detection at all, because everyone believes they’re covered.
Snowflake customers, 2024: the finding that was already on the dashboard
In 2024, a financially motivated group accessed data at roughly 165 organizations through their Snowflake accounts. There was no platform exploit. The accounts didn’t require MFA, and the attackers signed in with credentials harvested by infostealer malware, some of them unrotated for years. That is precisely the exposure an out-of-the-box identity query for active accounts without MFA exists to surface. Now picture that query disabled as noise during a busy quarter, with no trace of the decision on the dashboard. The detection you silenced last quarter can be the one describing next quarter’s breach.
Attackers turn detections off on purpose
Adversaries understand this better than anyone. MITRE ATT&CK catalogs Impair Defenses as its own technique, including disabling or modifying security tools so malicious activity goes unnoticed, and recommends routinely reviewing who has permission to change defensive tools and settings. A disabled detection, whether it was switched off by a tired analyst, a compromised admin account, or an insider, should never be invisible.
The lesson isn’t to never disable anything. Noise is its own threat. It trains people to ignore the dashboard, which is exactly what happened at Target. The lesson is that disabling has to be deliberate, visible, and instantly reversible. That’s a lifecycle problem, not a toggle.
A detection library is a living system
Effective identity security teams treat their detection library the way good engineering teams treat code. It grows as the business grows. It gets tuned, branched, and occasionally retired. And every change is visible, reversible, and owned. That comes down to six moves.
Six moves that keep a detection library aligned with the environment it protects.
Enable what your environment now needs
When a new system or use case comes online, the fastest path to coverage is the out-of-the-box content already built for it. Turning those queries on as you onboard, rather than once at deployment, keeps coverage moving at the speed of the business.
Disable what doesn’t apply, without deleting it
Some detections are noise in your environment. A disabled query stops contributing to your dashboard and overall risk score while its definition, origin, and lineage stay intact. If the context changes, it comes back exactly as it was. Disabling is a reversible judgment. Deleting is a permanent one.
Customize when your logic genuinely differs
Your directory handles MFA registration differently. Your privileged roles have different names. When the OOTB definition isn’t quite right, clone it or tune it, and keep a visible connection to the original.
Preserve the baseline
Out-of-the-box content keeps improving: sharper logic, recalibrated risk levels, better remediation guidance. Customers keep receiving those improvements only when OOTB content stays intact rather than being overwritten or deleted. We covered how Access Intelligence stages and reviews those updates in our last post on query lifecycle management.
Know what’s running, and why
At any moment you should be able to answer: what’s active, what’s disabled, what’s been customized, and what came from the catalog unchanged. Status and provenance turn a pile of queries into an inventory you can defend.
Shape signal so posture reflects real risk
All of this serves one outcome. The posture dashboard should reflect the risks that matter to your organization, not the full theoretical catalog. Signal quality is a decision you make, not a setting you inherit.
Disabled is a decision, not a deletion
The difference between disabling and deleting sounds small. In practice it decides whether tuning your program makes it stronger or slowly hollows it out. A quick way to choose:
|
When this happens |
The right move |
What you keep |
|
A new system or use case comes online |
Enable the OOTB queries built for it |
Coverage on day one, with catalog improvements as they ship |
|
A detection is noisy or irrelevant here |
Disable it |
The definition, its origin, and a one-click way back |
|
Your logic genuinely differs |
Clone or customize |
Your version plus a visible link to the original |
|
The catalog ships something better |
Review the update |
Your tuning, until you choose otherwise |
|
A detection has truly outlived its purpose |
Delete it |
A clean library, by explicit decision |
Disable is the move teams reach for most, and until now it carried a cost. You disabled a query on the dashboard where you noticed the noise, but undoing it meant leaving that dashboard for the global query list and working out which disabled queries belonged where. A one-time confirmation link was the only bridge back. Once it disappeared, the dashboard gave no sign anything had been turned off.
Decisions you can’t see are decisions you can’t revisit. So we brought the whole loop onto the dashboard.
What’s new: tune and restore detections where you see them
Disable from the card you’re looking at
Every query card on a dashboard now carries Disable Query in its action menu. When a detection isn’t earning its place in your view, you act on it in context, the moment you notice it. Once disabled it cannot contribute to the overall risk score until its re-enabled on purpose.
Disable Query sits in the card’s action menu, right where the noise shows up.
The decision stays visible after you make it
Disabling removes the card from the active view and confirms what happened, including exactly how to get it back. The confirmation points to something durable: the Status filter on the dashboard itself.
The confirmation points to the Status filter, so the path back never depends on a one-time link.
One filter answers what’s active, what’s disabled, and what’s here
The dashboard toolbar now includes a Status filter alongside Time Range, Integration Types, Risk Levels, and Labels. Active is the default, so your posture view shows only the detections you’ve chosen to trust. Disabled shows only what’s been turned off on this dashboard. All shows both, side by side.
The Status filter switches between Active, Disabled, and All without leaving the dashboard.
Disabled queries render as muted cards with a Disabled badge, in the same sections they came from. Nobody has to reconstruct which detections belong to which dashboard. The layout already tells you.
Filtered to Disabled: muted cards, clear badges, original sections intact.
Restore in one step, exactly where it was
When the context changes, open the card’s menu and choose Enable Query. The detection returns to its original place on the dashboard and resumes contributing to your posture. No rebuild, no re-import, no lost definition.
Enable Query brings a detection back to its original slot on the dashboard.
Restore a whole set at once
Detections often need to come back together. A new identity provider goes live. An incident widens the scope of what you need to watch. An auditor asks to see the full catalog running again. With the Status filter set to Disabled, select the queries you want back and re-enable them in a single action. Each one returns to its original place and resumes evaluation. Restoring coverage in the middle of an investigation takes seconds, not a hunt across pages.
Scoped here, consistent everywhere
The dashboard answers what’s disabled here. The query list page still answers what’s disabled anywhere. Both reflect the same underlying state, with the same terminology and the same badge, so moving between them never means relearning anything.
How this strengthens your identity security posture
Your dashboard reflects your risk. Active by default means posture shows the detections your team has chosen to trust, not every query in the catalog.
Tuning becomes safe to do. Because disabled detections are one click from restored, teams can quiet noise aggressively without fear of losing coverage permanently.
Silenced detections can’t hide. Every disabled query stays visible on the dashboard it came from, so a reviewer, an auditor, or an incident responder can see what’s been turned off and judge whether that decision still holds.
Coverage comes back at incident speed. Bulk re-enable restores a whole set of detections in one action when the threat picture changes.
Coverage keeps compounding. Disabling instead of deleting keeps OOTB content intact, so the library keeps benefiting from catalog improvements as they ship.
Analysts stop learning to ignore findings. When noise has a proper home, every tile left on the dashboard deserves attention again.
Where this is going
Enable and disable is one capability inside a broader Identity security system, and that is where we’re investing. As part of ServiceNow, we’re building toward a detection library that adapts as fast as your environment does: content that could be switched on as new systems arrive, tuning that never costs you the baseline, and a clear record of every query’s status, origin, and owner. The goal is simple. Every detection on your dashboard should be there because someone chose it.
Try it today
Open any dashboard and set the Status filter to Disabled. If something is there that should be back in your posture view, choose Enable Query, or select several and bring them back together. If a card is noise in your environment, disable it from its menu and know you can always bring it back.
A detection library you can’t steer will eventually steer you.
About the author
