Now that you’ve defined a custom risk model, it’s important to understand how to use it for maximum benefit. This section explains what changes in the Nucleus platform once Custom Risk Score is active, how to interpret the new scores, and best practices for adjusting and maintaining your model over time.
Where the Custom Score Appears:
When enabled, your Custom Risk Score will replace the standard Nucleus Risk Score in most parts of the UI for that project. Key places you’ll notice the custom score:
Top Risks Page: The Top Risks view (Vulnerabilities > Top Risks) will use your custom scoring to rank the highest-risk vulnerability instances in your environment. Essentially, it answers “which vulns on which assets have the highest custom risk score?” If you had an existing Top Risks list, this may be re-ordered according to the new calculations. Use this page to verify that the results align with your expectations (are the items at the top truly your most urgent issues?).
Automation Rules: Perhaps one of the biggest advantages: you can use the custom risk in automation workflows just like the default score. In the Automation rule builder (Finding Processing Rules), you’ll find a filter criterion for Custom Risk Score (e.g.
custom_risk_score >= X). Use this to, say, auto-tag or escalate any finding over a certain score. If you had rules based on the old Nucleus score, be sure to update them if your scale changed. For example, if you previously had a rule “if Nucleus Risk Score >= 700 then priority = P1”, and you changed your thresholds, you’ll want to create a similar rule using your custom score (maybe the cutoff is now 800, etc., depending on how you set levels).Vulnerabilities/Findings Listings: In any list of findings (e.g. the Active Vulnerabilities page or search results), the risk score column now reflects your custom score. The same color-coding by risk level (using the custom levels you defined) will apply. For instance, if you set 800+ as “Critical” risk, those findings will be highlighted in red. Each finding’s detail view will also show the custom risk score prominently. If you open a vulnerability details panel, you might see a breakdown or at least the numeric score with the label of the risk level.
Assets and Asset Groups: Asset risk scores are now derived from your custom model. On the Assets page, each asset’s risk score and color will correspond to how your model aggregates the vulnerabilities on that asset. For example, if you chose “highest vulnerability score” as the asset risk method, an asset with one Critical (900-point) finding will show a ~900 risk. If you used a cumulative approach, an asset with many Medium findings might show a higher risk than it would have under the old model. Dashboards that list assets by risk or any “Asset Risk” widgets will reflect this accordingly.
Dashboards & Reports: All dashboard widgets that involve risk metrics (e.g., “Risk Score Distribution”, “Top 10 Riskiest Assets”, trend of average risk over time) will use the custom scores. Reports generated (PDF/Excel) that include risk scoring will likewise use the new values. This means your monthly vulnerability report to the CIO can now show risk categorized exactly by the levels you set, which improves clarity and trust. It’s a good idea to review key dashboards after enabling the custom score to ensure the visualization still make sense. You may need to adjust chart thresholds or SLA values to align with the new scale.
API & Exports: The custom risk score is also available via the Nucleus API and data exports. If your team pulls data into spreadsheets or BI tools, look for a field like “custom_risk_score” or similar in the export. This allows external reporting or integration to use the same risk lens.
Interpreting the Scores and Levels:
Because you designed the model, you have the intuition of what the scores mean – but it’s important to communicate this to your team. Ensure everyone understands the new risk scale and categories. For example, if you retained 0–1000, people might not notice a difference except that the distribution of scores could change. But if you switched to a 0–100 scale or altered the thresholds for “High” vs “Medium”, make sure to highlight that. A “High Risk” in the new model might require a higher bar (or lower) than before.
Nucleus doesn’t treat your custom risk levels differently than the default; they’re just labels. So all built-in features that use risk level (like red/yellow/green indicators, sorting by severity, etc.) will use your custom definitions. Leverage that transparency: if someone asks “Why is this vulnerability 850 (Critical) now when previously it was 750 (High)?”, you can explain the factors from your model that led to that increase (perhaps the asset is more critical or you added points for exploitability). In fact, you can click on a vulnerability and see details that help trace the score. While the UI may not explicitly list each rule contribution yet, you know the logic. It can be useful to walk your analysts through a couple of examples: show a vulnerability’s context and manually verify how the rules applied. This builds confidence in the scoring. Remember, every custom score is explainable – it’s calculated exactly as you specified, which is a huge advantage for reporting to management.
Adjusting and Evolving Your Model:
Treat your custom risk model as a living thing. After using it for a while, you might discover that certain vulnerabilities are consistently over- or under-prioritized. That’s your cue to tweak the model. Some tips for managing it going forward:
.png)
Start Simple, Then Refine: It’s okay if your first iteration is basic – e.g., a base by severity and a handful of adjusters. In fact, that’s preferable to over-complicating things from the get-go. Over time, you can add rules as needed. Use data to guide you: if you notice, for example, that a lot of Medium severity issues on critical assets are still scoring lower than you’d like, you could raise the asset criticality adjuster or add a new rule.
Monitor Score Distribution: Keep an eye on the distribution of scores and levels. A well-tuned model will have a spread – only a small percent should be “Critical” (red) and most will fall into lower categories, with a gradation. If after enabling, 80% of findings show up as High/Critical, the model might be too liberal (everything can’t be top priority!). Conversely, if almost everything is Low, you may have been too conservative. Use Nucleus dashboards or exports to visualize how many findings/assets fall into each risk level. Adjust your level thresholds or rule values if needed to get a sensible distribution that helps you focus on the true top risks.
Validate Against Reality: Periodically pick a sample of vulnerabilities and sanity-check their scores. Does a notorious vulnerability (say, a wormable RCE on a production server) indeed have one of the highest scores? If not, consider why and whether your model should be tuned to capture that scenario. Likewise, if something trivial ended up with a high score, figure out which rule did that and whether it’s intended. Engage your security team in this process – it can be a great exercise in risk reasoning.
Leverage Transparency for Buy-in: One major benefit of Custom Risk Score is being able to show why something is ranked the way it is. Use the model to your advantage in meetings: e.g., “This found vulnerability is Critical not just because CVSS says so, but because in our model we add points for being internet-facing and having active exploits.” This helps stakeholders understand decisions. If someone disagrees with the weighting, you have the ability to adjust the model to accommodate new consensus. In this way, your risk scoring can become a collaborative, accepted standard over time.
Documentation & Versioning: Keep a log of changes you make to the scoring model (e.g., “Jan 2026: increased KEV adjuster from +100 to +200 after ransomware trend” etc.). This helps track the evolution and reasons. If needed, you can revert or compare outcomes before/after changes. Nucleus may introduce the ability to save multiple models or templates in the future; until then, manual documentation is key.
Stay Updated on New Features: As noted, Custom Risk Score is a growing feature set. Nucleus plans to introduce more aggregation modes, testing tools, and even templates of common scoring models. Keep an eye on release notes. For example, a future update might let you maintain two different scoring schemes or easily share a model configuration. Being aware of these will help you continuously improve your program’s risk approach.
Best Practices and Examples:
To support both new and experienced users, here are a few best practices when using Custom Risk Score:
Use business context that matters: Early adopters have successfully integrated business-specific context into their scoring. For instance, tying in tags from a CMDB (like asset importance ratings) or business unit info can ensure the score reflects what’s mission-critical. If your finance servers are tagged as such, include that in an adjuster (maybe +X for assets in “Finance” BU). This aligns vulnerability risk with business risk.
Incorporate threat intelligence for true risk-based prioritization: Make use of fields like
cisa_kev,exploit_available, EPSS, malware detections, etc. These are key to distinguishing merely “serious on paper” vulns from those being actively exploited in the wild. Adding significant points for known exploited issues will push those to the top – exactly what you want for incident-driven prioritization.Adjust for environment and timing: Not all findings need the same urgency. Use the model to de-prioritize things in non-prod environments or those nearing decommission, and to elevate things that have breached internal SLA thresholds (e.g., older findings). This dynamic approach saves you from chasing low-risk items just because they have a high CVSS.
Communicate the changes: If you roll out a custom score, let your vulnerability management team and stakeholders know that the scoring has been customized. Explain at a high level the new factors. This will prevent confusion like “Why did my asset’s risk score jump from 650 to 720 overnight?” and instead turn it into an informed discussion about risk. Consider adding a note in your internal reports: “Using Acme Corp Custom Risk Score model: incorporates asset criticality, threat intel, etc.”. This can be a brief section in your methodology.
Iterate with feedback: Solicit feedback from the analysts using the tool daily. They might discover patterns (“All our database servers always come out high risk now, is that intentional?”). This feedback is gold – use it to refine the model. Because you can update the config and immediately recalc scores, don’t be afraid to make incremental improvements. Just avoid constant churn; find a stable baseline, and then tweak in controlled steps.
Fallback to Standard Score (if needed): If ever you want to compare or revert, remember that the standard Nucleus Risk Score algorithm is still available. You could disable the custom model (or toggle it off) to see how things look with the default, if only for analysis. This can help quantify what difference your custom model is making. Ideally, your custom model should be more effective at highlighting true risk than the generic one – if not, revisit your approach.
By following these practices, you’ll ensure that Custom Risk Score becomes a powerful ally in your vulnerability management program – one that not only surfaces the most critical issues for remediation but does so in a way that resonates with your organization’s understanding of risk.
Finally, don’t hesitate to reach out to Nucleus Support or your Customer Success engineer for guidance. Designing a risk model can be nuanced, and we’re here to help you succeed. With a well-tuned Custom Risk Score, you can confidently answer the classic question “Are we fixing the right things?” with data-driven assurance, knowing that “right” is defined on your terms. Enjoy the newfound control and clarity as you continue to protect your enterprise with Nucleus!