We found three engineering initiatives that require executive sponsorship.
Critical. Serious risk on your modified configuration — warrants executive attention now.
The letter restates the band: A Healthy · B Moderate · C Elevated · F Critical. Only configuration modified from the platform baseline drives this grade — untouched ServiceNow baseline and packaged apps don’t count against you.
Why Critical, not just high: 38 of 44 grade-driving findings (86%) come from a single pattern — high configuration-change velocity by a single account in 7 days. That concentration in one area (Governance) is what pulls the overall into the Critical band, even though no individual finding is rated Critical. The upside is leverage: resolving that one pattern would move the grade more than any other single action.
Projection based on the findings in this assessment. Actual results will be confirmed by a new scan after remediation.
The grade counts only configuration modified from the platform baseline — per ServiceNow's own customization history, and outside ServiceNow-packaged apps. “Modified” means the record isn't stock; it doesn't assert who changed it (your team, a partner, an update set, or a Store app). Packaged-app findings are listed separately, not counted against you.
EnableNow Demo2 grades F — 31/100, Critical. Three engineering initiatives (about 2–4 weeks) would clear the majority of the risk. The biggest single item: It's hard to know who changed what, because configuration is changing quickly with limited review.
Customization Inventory
How much of the configuration we examine has been changed from the platform baseline — an all-time surface view. This is a separate lens from the grade and does not affect it.
This sample runs on a ServiceNow demo instance, so customer customization is near zero by design. On a real production instance this share is typically much higher — this is where you'd see how much of your platform is genuinely yours.
0% of the configuration we examine is customized from baseline — 224 of 77,728 objects.
Across 77,728 objects we examine (access controls, business rules, client scripts, script includes, scheduled jobs). Customer-modified = the object has an entry in ServiceNow's all-time customization ledger.
Configuration risk like this accumulates gradually, across years of customization and upgrades — it rarely reflects any single mistake. The reassuring part: nearly all of it traces to just 3 root causes, addressable through three engineering initiatives.
If left unresolved
The highest-priority risks, in plain terms — each a single fix that clears every instance behind it.
It's hard to know who changed what, because configuration is changing quickly with limited review.
Left unresolved, this is what a change-management audit flags as weak control — many configuration changes with little traceable review — and it makes production incidents slow to trace back to a cause.
Recommended action Strengthen review and change-control on high-velocity areas.
Technical pattern: High configuration-change velocity by a single account in 7 days · e.g. sheeba.showkat, towqeer.altaf, admin · view the records behind this →
Sensitive data can be exposed, because it is returned without re-checking the user's permissions.
Left unresolved, this is a data-exposure path a security review will flag: a client-callable interface returns sensitive data without re-checking the caller's permissions.
Recommended action Add permission checks before returning sensitive data.
Technical pattern: Client-callable Script Include reads a sensitive table with no in-script authorization · e.g. EmployerInsurerAjax, WS5GetUserDetails · view the records behind this →
Unpredictable behavior and hard-to-trace errors can occur, because automation can trigger itself in loops.
Recommended action Rework these rules so they don't re-trigger themselves.
Technical pattern: Global business rule calls current.update() (recursion risk) · e.g. WS5-Master Claim Stage Handler BEFORE · view the records behind this →
Root causes & engineering initiatives
These 3 root-cause patterns are the underlying source of 44 individual findings on modified configuration, grouped below into 3 engineering initiatives. Resolving these patterns removes hundreds of related issues at once.
Without this you can't reliably answer “who changed what, and was it reviewed?” — where audits and incidents both start.
Every month these stay open is a month sensitive data can be reached by people who shouldn't reach it.
Each one quietly raises the cost and effort of every future change your team makes.
What happens if nothing changes
- Unauthorized-access and data-exposure risk becomes more likely.
- Ongoing support and maintenance costs rise.
- Audits and change reviews get harder to pass.
Estimated remediation shape
Roughly 2–4 weeks across 3 engineering initiatives — a planning shape from the volume and severity of findings, not a fixed quote (and independent of your team's size).
Health by area
Priority action plan
- Investigate the change burst, confirm it went through update-set review, and enforce peer review / change windows for high-volume contributors. — 38 findings (high)
- Add an explicit role check before the query, or use GlideRecordSecure so ACLs apply — 4 findings (high)
- Avoid current.update() in business rules — 2 findings (high)
Untouched platform baseline
1,406 findings on configuration with no customization recorded in ServiceNow's own history — it shipped with the platform, a plugin, or a Store app. They do not count against your grade; review them with your ServiceNow contacts or fold selected items into your remediation plan deliberately.
About this assessment
Independent, evidence-backed assessment — every finding links to the exact configuration it came from. An object is a single configuration record we read (a script, business rule, ACL, field, and so on). Checks are codified from ServiceNow's published best-practice and secure-coding guidance; each check cites its source documentation (see the full methodology →).
Recommendation
Approve a 2–4-week engineering initiative covering the three priorities in this assessment. Expected outcome: the grade moves from F·31 to a projected A·100, removing the majority of the platform's governance, security, and maintainability risk.
Forward this to your engineering lead and approve the three initiatives.
Generated 8/2/2026 · Assessment performed using InstanceGuard Methodology v1.0 · read-only. Findings are signals for human review, not confirmed vulnerabilities; each links to its evidence and a suggested remediation.