Risk assessment appetite status calculation matrix

[Majji Koteswar1]

Hi Team,

Could some one explain calculation matrix of Appetite status on risk assessment record?

Thanks,

Majji

[rahulswami]

Hi @Majji Koteswar1 

Appetite Status is not a calculation like the risk score. It is a comparison. The engine takes the residual rating from your assessment, compares it to two thresholds on the appetite that applies, and stamps a choice value.

Below Amber gives Within appetite. Past Amber but not past Red gives Outside appetite. Past Red gives Outside tolerance.

Two things worth knowing.

First, appetite is inherited. It can be set at entity level, risk statement level or on the risk itself. If the status looks wrong, confirm which appetite record actually applied before anything else.

Second, this is the usual root cause. The appetite scale is linked to the Qualitative Rating Criteria in your Risk Assessment Methodology. If the numeric ranges do not line up, you get statuses that are arithmetically correct and business-wise wrong. Classic reported case, appetite Averse defined as 1 to 5, risk scores exactly 5, status comes out as Outside appetite. Nothing is broken, the boundary is inclusive on one side and exclusive on the other. Check the boundary values first.

To see what the engine actually stored, run this in Scripts - Background.

var gr = new GlideRecord('sn_risk_advanced_risk_assessment_instance');
gr.get('YOUR_ASSESSMENT_SYS_ID');
var f = gr.getFields();
for (var i = 0; i < f.size(); i++) {
var n = f.get(i).getName();
if (n.indexOf('appetite') > -1 || n.indexOf('tolerance') > -1 || n.indexOf('residual') > -1)
gs.info(n + ' = ' + gr.getValue(n) + ' | ' + gr.getDisplayValue(n));
}

If you ever hit "As the risk appetite status is '', comments are required", do not search business rules or client scripts. GRC assessment validations are data driven through sn_grc_exception records, handled by sn_risk_advanced.RiskAssessmentValidationHelperUtils.

I work mainly in ITSM, so verify table and field names on your own version.

If you share your appetite ranges and the residual rating you got, the mismatch will probably be obvious.

[Majji Koteswar1]

Hi  @rahulswami 

Thank you for the response. We have a risk assessment with residual risk score of 33 which is set as Medium Residual risk but the Appetite status is set to Outside appetite. Below are the qualitative rating criteria with risk appetite scale.

I wanted to understand how the comparison is happening, what are all considered in comparison and where they are configured exactly in the system to set the appetite status. It would be helpful if you can provide these.

Thanks,

Majji

[rahulswami]

Hi  @Majji Koteswar1 

Let me walk through your exact number instead of explaining the concept.

The important bit up front: 33 is never compared to anything. It gets converted to a band first, and the band is what gets compared.

YOUR SETUP (from your screenshot)

Qualitative Rating Criteria, each row mapped to a Risk appetite scale:

Very Low -> Very Low (rank 1)
Low -> Low (rank 2)
Medium -> Medium (rank 3)
High -> High (rank 4)

WHAT HAPPENED TO YOUR 33

Step 1. Score 33 falls into your Medium score range. Rating = Medium.
Step 2. The Medium row maps to Risk appetite scale = Medium, rank 3.
Step 3. The engine reads the appetite set on the risk. Say it is Low, rank 2.
Step 4. Compare: 3 > 2. Result = Outside appetite.

That is it. The 33 stops mattering the moment it becomes Medium.

SAME RISK, DIFFERENT APPETITE

Keep the score at 33 and only change the appetite on the risk:

Appetite Very Low (1) vs assessed Medium (3) = 2 steps over = Outside tolerance
Appetite Low (2) vs assessed Medium (3) = 1 step over = Outside appetite <- your case
Appetite Medium (3) vs assessed Medium (3) = equal = Within appetite
Appetite High (4) vs assessed Medium (3) = under = Within appetite

So a score of 33 can legitimately show all three statuses. It depends entirely on the appetite, not the number.

PROVE IT IN TWO MINUTES

Take a test risk, note the current appetite and status, change the appetite from Low to Medium, re-run the assessment. The status should flip to Within appetite with the score untouched at 33. If it does, nothing is broken and your config is doing what it was told.

WHERE TO LOOK

The appetite on the risk. Check whether it is set on the risk itself or inherited from the risk statement or entity, because people often set it in one place and read it in another.

The rank. Right click the Risk appetite scale field label, Configure, Dictionary, open the reference table, and check the order or sequence on each record. The comparison uses rank, not the name. If Medium has a lower order than Low, everything looks scrambled while each individual record looks fine.

Override score on the rating criteria row. If populated it silently replaces the computed value.

If 33 is genuinely inside your Medium band and the appetite on the risk is Medium or above, then something is off and it is worth digging further.

If this helps you then mark it as helpful and accept as a solution.

[rahulswami]

Hi  

Appetite Status is not a calculation like the risk score. It is a comparison. The engine takes the residual rating from your assessment, compares it to two thresholds on the appetite that applies, and stamps a choice value.

Below Amber gives Within appetite. Past Amber but not past Red gives Outside appetite. Past Red gives Outside tolerance.

Two things worth knowing.

First, appetite is inherited. It can be set at entity level, risk statement level or on the risk itself. If the status looks wrong, confirm which appetite record actually applied before anything else.

Second, this is the usual root cause. The appetite scale is linked to the Qualitative Rating Criteria in your Risk Assessment Methodology. If the numeric ranges do not line up, you get statuses that are arithmetically correct and business-wise wrong. Classic reported case, appetite Averse defined as 1 to 5, risk scores exactly 5, status comes out as Outside appetite. Nothing is broken, the boundary is inclusive on one side and exclusive on the other. Check the boundary values first.

To see what the engine actually stored, run this in Scripts - Background.

var gr = new GlideRecord('sn_risk_advanced_risk_assessment_instance');
gr.get('YOUR_ASSESSMENT_SYS_ID');
var f = gr.getFields();
for (var i = 0; i < f.size(); i++) {
var n = f.get(i).getName();
if (n.indexOf('appetite') > -1 || n.indexOf('tolerance') > -1 || n.indexOf('residual') > -1)
gs.info(n + ' = ' + gr.getValue(n) + ' | ' + gr.getDisplayValue(n));
}

If you ever hit "As the risk appetite status is '', comments are required", do not search business rules or client scripts. GRC assessment validations are data driven through sn_grc_exception records, handled by sn_risk_advanced.RiskAssessmentValidationHelperUtils.

I work mainly in ITSM, so verify table and field names on your own version.

If you share your appetite ranges and the residual rating you got, the mismatch will probably be obvious.