SwissNowIs your ServiceNow instance over-permissioned?
Access control on ServiceNow rarely breaks all at once - it drifts, one "just add the role" exception at a time, until nobody can say who can see what, or why.
Where over-permissioning actually comes from
Almost nobody sets out to over-permission a table. It accumulates through individually reasonable decisions that nobody revisits.
Table-level roles instead of record-level
A role required to see any record on a table, when the actual business need was only ever "records this person is assigned to."
ACL conditions that pass for everyone
A condition script left over from testing, or written loosely enough that it evaluates true regardless of who's asking.
Admin overrides left switched on
Added for a one-off fix during an incident, then never revisited once the incident was closed.
Missing field-level ACLs on sensitive fields
The table itself is protected, but one specific field carrying sensitive data has no extra restriction of its own.
Orphaned role grants
A role assigned to a group for a project that ended months ago - the access was never revoked because nobody owns revoking it.
How to check, not guess
An access review usually doesn't need a new tool - it needs someone to actually read what's already there.
Read the ACL, not just its name
A meaningfully-named ACL can still have a condition or script that grants far more than the name implies. The only way to know is to read sys_security_acl's actual condition and script fields, per operation and per table.
Look for admin overrides specifically
These are meant to be temporary by design - and a quick pass across active ACLs for one still switched on is one of the highest-value checks available.
Cross-reference roles against actual usage
A role that exists on paper isn't the same as a role someone is actively relying on. Comparing who holds a role against who's actually touched the data it protects surfaces the grants nobody remembers making.
Patterns worth auditing first
- ACLs with no condition and no scriptA role-only gate - anyone holding the role passes, with nothing else narrowing it.
- Broad table-level write access for a narrow workflow stepA role that can write to an entire table when it was only ever meant to update one field in one state.
- Roles inherited through group membership nobody remembers assigningAccess that traces back through a group, not a direct grant - easy to lose track of over time.
- Sensitive fields with no field-level ACLTable-level protection exists, but the one field actually worth protecting has nothing extra.
- Security-relevant ACLs untouched for over a yearNot wrong by default - but worth a second look, since nothing has re-validated it since it was written.
The manual version doesn't scale
A real access review means reading every relevant ACL's actual condition, cross-referencing role holders against real usage, and doing it again next quarter, because the drift never stops. It's the kind of work that's genuinely valuable and genuinely tedious in exactly the way that means it keeps getting postponed.
Running this review continuously, automatically
Our own platform, neo.ai, reads every active ACL's real condition and role combination on a schedule, judges whether the access actually matches what the record protects, and only surfaces what's genuinely worth a look. It's one of seven categories it watches across a ServiceNow instance.