How should we review and remediate Health Assessment findings to improve our ServiceNow platform

[avinashnk]

Hi Community,

We recently reviewed the ServiceNow Health Assessment report for our Norstella instance and would like to understand the best-practice approach for analyzing and remediating the findings.

The Health Assessment categorizes findings into Manageability, Performance, Security, Upgradeability, and User Experience, with findings further classified as Act, Recommended, and Discuss. ServiceNow documentation indicates that Act findings are generally the highest-priority items, Recommended findings should be addressed next, and Discuss findings represent opportunities for improvement.

We would appreciate guidance from the community on the following:

1. How should we approach the "Act" findings?

• Should all Act findings be treated as immediate remediation items?
• How do you determine whether an Act finding is genuinely applicable to the business/platform?
• What validation should be performed before making configuration changes?
• How should we handle findings that are caused by intentional customizations or business requirements?
• When should we remediate versus document an exception?

2. How should we prioritize the findings?

Would the following approach be considered a good practice?

Act → Recommended → Discuss

How should we review each Health Assessment category?

Manageability

Performance

Security

Upgradeability

User Experience

[Dr Atul G- LNG]

Hi @avinashnk 

Health Scan Report – Platform Owner Perspective

As a platform owner, I’m happy to share my perspective. The Health Scan report from SN provides good insights and helps identify areas where we can improve. However, I don’t think we should treat every finding as something that must be fixed immediately.

The Health Scan covers multiple parameters, so I would recommend prioritizing the findings based on their business and platform impact rather than trying to address everything at once.

My suggested priority would be:

1. Security
2. Performance
3. Manageability
4. User Experience
5. Upgradeability

I would recommend creating separate epics for each area and tracking the remediation items as stories under the relevant epic. This will help us prioritize the most important findings and work through them systematically.

Questions & Recommendations

Should all ACT findings be treated as immediate remediation items?

AG: No. We should first assess the impact of each finding and prioritize accordingly. Start with the findings that have the highest impact, particularly the security-related ones. We should set up a meeting with the client, walk them through the findings and recommendations from SN, and agree on what should be addressed first. We should then create user stories and plan the remediation accordingly rather than trying to fix everything immediately.

How do you determine whether an ACT finding is genuinely applicable to the business/platform?

AG: It depends on the client and their specific environment. The client's environment and business requirements should be the first point of analysis. As I mentioned, it isn't necessarily required to fix every finding. We need to determine whether the finding is actually applicable and whether it has a meaningful impact on that particular environment.

What validation should be performed before making configuration changes?

Atul: Take the current threshold or baseline value first, then make the configuration change and compare the results. This will help us validate whether the change actually improves the situation before making it permanent.

How should we handle findings caused by intentional customizations or business requirements?

AG: I wouldn't say we should simply ignore them. First, check whether there is an OOTB way to meet the requirement. If there isn't, and the customization is genuinely required to support the business need, then we should document the reason and treat it as an exception where appropriate.

When should we remediate versus document an exception?

AG: Similar to customizations, if the finding is caused by a legitimate business requirement or an intentional configuration, and remediation isn't practical or would negatively impact the business, we should document it as an exception rather than making a change just to satisfy the scan.