Every identity security program starts the same way. You connect your systems, switch on the out-of-the-box queries, and within minutes you’re looking at real risk: active accounts without MFA, Salesforce users who can modify all data, public GitHub repositories anyone can fork. That library is the fastest path from zero to posture.
Then you make it yours.
You add a label so a query lands on the right dashboard. You tighten a condition because your directory handles MFA registration differently. You raise a risk level because that finding matters more in your environment. That’s exactly what good teams should do. A detection library you can’t tune to your environment is a demo, not a program.
But the moment you tune a query, you inherit a question most platforms never answer: what did this look like before we touched it, and has the original moved since?
Two ways a detection library quietly decays
Out-of-the-box content isn’t static. Detection logic gets sharper as attack paths evolve. Risk levels get recalibrated. Explanations and remediation guidance get written and rewritten. Some queries get retired because they’re noisy, redundant, or replaced by something better. A good catalog is a living thing.
Your customized copy of it usually isn’t. So one of two things happens.
The platform overwrites you. An update lands on startup, replaces the definition, and your label, your extra condition, and your risk tuning disappear without a word. The dashboard that depended on that label goes quiet. Nobody notices until an auditor asks why a finding dropped off the report.
Or, far more commonly, the platform leaves you behind. Your customized query becomes a fork frozen in time. A sharper version ships, with better remediation guidance and a corrected risk level, and you never see any of it. When a query is retired upstream, your copy keeps running with no signal that it’s now orphaned. Months later, nobody on the team can say which queries still reflect current guidance and which are running on a stale baseline.
Both outcomes erode the same thing: trust in the detection. When you can’t trace a query back to its source, you can’t defend its results. And posture you can’t defend isn’t posture. It’s a guess with a dashboard.
The principle: customize freely, never lose the baseline
Effective query lifecycle management rests on one idea. Every query should always know where it came from, what changed, and what’s new upstream, and a person, not a startup script, decides what happens next.
That comes down to three commitments. Provenance: every query shows whether it came from the out-of-the-box catalog and whether it’s been modified. Transparency: you can see your version and the original side by side, any time, without changing either. Control: upstream updates and removals arrive as proposals you review, not changes that happen to you.
That’s what we’ve built into Access Intelligence.
What’s now available
You decide how catalog changes land
It starts with one switch. In System Settings, Stage OOTB Query Updates for Review turns out-of-the-box query updates and removals into pending changes for an admin to review, instead of applying them automatically on startup. Your tuned queries are no longer at the mercy of a release cycle.
One setting moves catalog updates and removals from automatic to reviewed.
Every query carries its lineage
Open any out-of-the-box query and the header tells its story at a glance: who created it and its current modification state. Unchanged means it matches the catalog. Edited means your team has tuned it. Removed by Veza means it’s been retired from the catalog. Each state comes with the action that fits it, right where you’re already looking.
An edited Azure AD MFA query shows its origin, its Edited state, and a View Changes action inline.
See exactly what you changed, and undo it when you want
View Changes opens a side-by-side comparison of your current version against the original, with differences highlighted so nobody has to diff definitions by eye. In this example, the team added an mfa_health label and broadened the logic to also catch users who are MFA-capable but never registered. The comparison is read-only, so looking never changes anything. If a customization has outlived its purpose, Reset to Original returns the query to its out-of-the-box definition in one step.
Compare With Original shows your version and the catalog version side by side, with Reset to Original one click away.
Know when the baseline moves
When the catalog ships a better version of a query you haven’t touched, an Update Available indicator appears on the query itself. Nothing changes until you look.
An unchanged Salesforce query flags that a newer catalog version is available.
Reviewing the update puts the original next to the updated version, with every changed field highlighted. Here, the Salesforce ModifyAllRecords query arrives with a recalibrated risk level (Critical to Medium), a new privileged_access label, and full risk explanation and remediation guidance that tells an analyst why the permission is dangerous and exactly how to fix it. You choose Update Query or Dismiss.
The update review highlights what changed: risk level, labels, and new explanation and remediation guidance.
Accept it, and the query moves to the latest version, returns to Unchanged, and immediately carries the new guidance into every result it produces.
After the update, the query is back in sync with the catalog and shows the new risk level and guidance.
Updates don’t bulldoze your tuning
The hardest case is the one most platforms get wrong: a query your team has edited that the catalog has also updated. Access Intelligence shows both states, Edited and Update Available, so you know there’s something new upstream without losing what you built.
An edited query with an upstream update shows both states side by side.
The review compares your current version against the suggested update. In this example, the team had described the Salesforce ModifyAllData query as covering users who can modify all data “without exception” and set it to Critical. The updated version proposes High, along with new risk explanation and remediation guidance. You decide whether the new baseline serves you better than the one you built.
Your current version and the suggested update, compared field by field before anything changes.
Retirement without surprises
When a query is removed from the catalog, it doesn’t vanish, and it doesn’t keep running in the dark. It’s marked Removed by Veza with a Review Removal action.
The review states plainly that the query hasn’t been changed or disabled and keeps running as it is until you decide. It shows the exact definition running today and gives you two clear choices: Keep Query if it still earns its place in your environment, or Delete Query if it doesn’t.
Keep Query or Delete Query: a retired detection ends with an explicit choice, not a silent drop.
How this strengthens your identity security posture
Query lifecycle management isn’t housekeeping. It’s what keeps a detection library trustworthy over time.
Your customizations survive every release. Staged updates mean your labels, conditions, and risk tuning are never overwritten without a decision.
You stay current without starting over. Improvements to detection logic, risk levels, and remediation guidance reach you as reviewable updates, even on queries you’ve customized.
Every result is defensible. When an auditor or your CISO asks why a query flags what it flags, you can show where it came from, what your team changed, and how it compares to current catalog guidance.
Drift becomes visible. At a glance you can tell which queries match the catalog, which your team has tuned, which have updates waiting, and which have been retired upstream.
Orphaned detections get resolved. Retired queries surface for an explicit keep-or-delete decision instead of lingering on a stale baseline.
Tuning gets braver. With Reset to Original always one click away, teams can tune aggressively without fear of losing the known-good version.
Safe by design
Every part of this workflow follows the same rule: the platform informs, people decide. Comparisons are read-only and never touch your query or the original. Update Available and Review Removal are signals, not actions, so a query keeps running on its current definition until someone chooses otherwise. Updates, dismissals, resets, and deletions each take an explicit choice. And every query shows who last updated it and when, so the history of a detection is never a mystery.
Where this is going
Out-of-the-box content is the fastest way to get value from an identity security platform, and customization is how that value becomes yours. Those two shouldn’t be in tension. As part of ServiceNow, we’re building toward a detection library that evolves with the threat landscape and with your environment at the same time, where every query carries its lineage and every change is one you made on purpose.
Try it today
If you’re a customer, turn on Stage OOTB Query Updates for Review in System Settings, then open your queries and check the Modifications field. Compare your edits against the original, review what’s new upstream, and decide what stays. Your tuning is yours. The baseline is always within reach.
Out of the box should be a starting point, not a blind spot.
About the author
