Why This Keeps CISOs Up at Night
ServiceNow isn't just an IT ticketing system, and hasn't been for years. Most enterprises now run it as the platform underneath IT, HR, finance, security operations, and governance, risk and compliance, often all at once. That means a single instance can hold your technology architecture and dependency map alongside HR case data on real employees, financial approvals, audit findings, and live security incident detail, all governed by the same underlying access model.
A single misconfigured table doesn't just leak IT data. Depending on which domain it sits in, it can expose personnel records, financial detail, or the exact list of your unresolved compliance gaps to someone who was never meant to see any of it.
Access Control Lists, or ACLs, are the only thing standing between that data and the wrong person. They're also, in most instances, a mess nobody chose on purpose.
How Access Quietly Gets Out of Control
Nobody sits down and designs a broken permission model. It happens gradually. Internal teams and external consultants keep extending ServiceNow to work through the backlog, and every field added, every table extended, every new integration potentially needs its own access rule. Under deadline pressure, the easiest way to keep functionality working is to grant broad access rather than precise access. It's faster, and it's rarely revisited once the ticket is closed.
Do that for a few years, across a few teams, and the result is predictable: tables with no explicit ACL at all, roles that grant far more than anyone intended, forgotten script overrides, and rules that quietly contradict each other. A table with no ACL defined might fall back to a safe default, or it might not. That depends on your version, the table type, and how it inherits from its parent, and nobody can tell you which applies without checking.
Each of these is invisible until an audit, a breach, or a compliance review forces the question: who can actually see this data, and why?
Why No Human Can Actually Check This
A mature ServiceNow instance can carry many thousands of ACL records. Reviewing that by hand isn't a matter of discipline, it's a matter of scale. Nobody can hold that many rules, roles, and script conditions in their head at once, and a spreadsheet audit goes stale the moment the next sprint ships. Most developers are optimising for functionality, not for least-privilege access, which is exactly the incentive that creates the gap in the first place.
What's Actually Hiding in There
The specific patterns that matter most: tables with no protection, read and write rules that contradict each other, always-true scripts that bypass the access check entirely, public or guest-accessible ACLs, admin overrides being misused, and roles still granting access long after anyone remembers why they were created. Individually, each looks like a small technical detail. Together, across thousands of access control records, they're the actual shape of your data exposure, and almost nobody has ever seen that shape drawn out.
Turning an Invisible Risk Into a Short List
That's what we built ACL Analyser to do. It's an on-demand audit that scans your instance's ACL configuration and surfaces exactly these blind spots before they become incidents: 21 distinct checks across tables, fields, roles, and scripts, organised into Critical, High, and Lower Priority tiers, so you know what to fix first instead of guessing.
The result is a Service Portal dashboard with a clear health score and enough detail on each finding to act on it directly, turning a sprawling, invisible risk into a short, prioritised list.
You can't secure what you can't see, and nobody can see this by hand.
The value isn't the scan itself. It's the fact that a question CISOs currently can't answer with confidence, who can actually see this data, finally has a direct, evidence-based answer.
Do you know who can actually see your ServiceNow data?
Most CISOs can't answer that with confidence. Let's find out together.
Speak with us