The detailed method behind our ACL & Data Security Analysis, for anyone who wants to see exactly what we check and why, before trusting us with the question.
Our ACL Analyser currently checks a ServiceNow instance against 21 distinct risk patterns, covering tables, fields, roles and access control scripts. We organise every finding into one of three tiers: Critical, High, and Lower priority, based on how confidently we can say a finding is a real, exploitable gap rather than something that needs further judgement in context.
Our fixed-price ACL & Data Security Analysis focuses specifically on the six Critical checks described below. The remaining checks, covering areas like role scope, script hygiene and configuration drift, make up the rest of the methodology and inform our broader platform governance work, but they are not the subject of this particular offer.
Critical means black and white: if the check finds something, it's a real, immediately exploitable gap, no threshold to argue about, no context required.
Every other check in our methodology involves some degree of judgement: a named heuristic, a configurable threshold, or a risk that's indirect rather than immediate. These six don't. Each one is either a genuine gap or it isn't, which is exactly why we're comfortable pricing an analysis of them at a fixed rate rather than a scoping exercise.
Within the six, two deserve attention first. A rule that looks protected but isn't is more dangerous than a rule that's simply missing, because nobody goes looking for a problem they believe is already solved. Checks 4 and 5 below are marked accordingly.
A table with no access rule for an operation, create, read, write or delete, relies entirely on ServiceNow's default behaviour rather than a decision your team actually made. The default is usually admin-only rather than open, but it's a gap nobody chose on purpose, and on your own customisations it's worth knowing it exists.
Restricting who can edit a record while leaving read access wide open sounds safer than it is. ServiceNow grants access if any matching rule allows it, so a single fully open read rule is enough to expose a record, even when stricter rules also exist alongside it.
The same logic applies when more than one rule governs the same operation on the same table: one fully open rule silently overrides every stricter rule sitting next to it. The restriction looks real in the configuration. In practice, it isn't. It follows the same false-security pattern as checks 4 and 5 below, just one step more indirect, since it takes more than one rule to see it.
A rule with no role, no condition, no script and no explicit deny-unless setting blocks nobody. Any authenticated user can pass it. There's no interpretation required here: the door is simply open. We treat this as critical specifically on your own custom applications; the same pattern inside ServiceNow's base platform is a lower priority, since that isn't yours to fix.
Some access rules rely on a script rather than a simple role check. If that script can never actually return false, regardless of input, the rule provides no protection at all. Arguably worse than check 4, because a rule still exists and looks correct to anyone reviewing the configuration. It just doesn't do anything.
An access check should check something, not change something. A script that writes to the database as a side effect of deciding who can see a record is unpredictable, and in the worst case can corrupt data, regardless of what the original developer intended.
The remaining 15 checks in our methodology sit across our High and Lower priority tiers. They cover things like role scope, script hygiene, and configuration drift, patterns worth knowing about, but ones that generally need a named threshold or some understanding of your specific environment to interpret correctly. We use the full set in our ongoing platform governance work. The fixed-price analysis is deliberately scoped to the six checks above, where the answer doesn't depend on context.
We'd rather show you exactly what we look for and why, before you commit to anything, than ask you to trust a black box. If a finding from one of the six checks above shows up in your instance, there's no argument to be had about whether it matters.
A fixed-price analysis of your six most critical ACL risks, focused on your own customisations, no production access required.
See the offer