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.
What the score is — and isn’t. This is a modified-configuration score. Clearing it (a perfect 100) means these configuration checks pass — not that the instance is secure, compliant, or upgrade-ready. Those are separate reviews.
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.
Completing all three initiatives resolves every finding on modified configuration. Projection based on the findings in this assessment; actual results are 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 scores 31/100 on its modified configuration — grade F, Critical. Three engineering initiatives (about 2–4 weeks) would take the grade from F to a projected A. The biggest single item: A high volume of configuration changes is concentrated in a short window — a reason to check whether they went through normal review, not proof on its own that review was skipped.
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 recurring patterns, 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.
A high volume of configuration changes is concentrated in a short window — a reason to check whether they went through normal review, not proof on its own that review was skipped.
If the changes turn out to lack traceable review, a change-management audit would flag it, and production incidents get slower to trace back to a cause.
Recommended action Confirm these changes went through update-set review/approval; strengthen change-control if they didn't.
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 →
A client-callable interface queries a sensitive table without a visible permission re-check — a likely exposure path to validate; whether it actually returns sensitive fields to an unauthorized caller needs confirmation.
If confirmed, a security review will flag it: a client-callable interface reaching a sensitive table 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 →
Recurring patterns & engineering initiatives
These 3 recurring configuration 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.
Check whether this change burst went through approval and review — the answer to “who changed what, and was it reviewed?” is where audits and incidents both start.
If confirmed, these are paths to sensitive data reachable by people who shouldn't — worth an authorization review now rather than later.
These patterns can increase maintenance effort; confirm their context and impact before choosing changes.
What happens if nothing changes
- If the access gaps are confirmed, unauthorized-access and data-exposure risk rises.
- Ongoing support and maintenance costs can rise.
- If the changes weren't reviewed, 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
Recommended implementation sequence
- 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 entry in ServiceNow's own change ledger (sys_update_xml) — most shipped as platform, plugin, or Store-app baseline, though some may be older or otherwise-untracked changes the ledger doesn't record. 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. This is the total number of findings detected across all report tiers; a subset drives the grade (see the provenance breakdown above). Checks are codified from ServiceNow's published best-practice and secure-coding guidance; each check cites its source documentation (see the full methodology →).
Two separate counts. Customization inventory — a baseline-vs-modified survey of 77,728 configuration objects; a separate lens that does not feed the grade. Findings — what the checks flagged: 19,654 across all report tiers, of which 1,450 appear in this executive report = 44 modified from baseline (drive the grade) + 1,406 untouched baseline (excluded).
How this score is computed
Deterministic arithmetic — each category's score, weighted by its finding count, then averaged. Empty categories score 100 and are excluded. (full formula →)
Modified-configuration score today — 31 / 100
| Category | Findings | Score | Score × findings |
|---|---|---|---|
| Security | 4 | 39 | 156 |
| Maintainability | 2 | 44 | 88 |
| Governance | 38 | 30 | 1,140 |
| Total | 44 | 1,384 |
round(1,384 ÷ 44) = 31 / 100 (rounded to the nearest integer)
After the Week-1 fixes (projected) — 100 / 100
| Category | Findings | Score | Score × findings |
|---|---|---|---|
| Total | 0 | 0 |
No remaining findings — the scoring model assigns 100 / 100 by convention.
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 once all three initiatives are complete — resolving every finding on modified configuration.
Forward this to your engineering lead and approve the three initiatives.
Instance scanned 8/2/2026 · report generated 9/6/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.