How to Calculate Impact, Likelihood, and Quantitative Risk (SLE, ARO, ALE) on Policy Exception Table

[usernotfound225]

Understanding Impact, Likelihood, and Quantitative Risk (SLE, ARO, ALE) Integration on Policy Exceptions

Hi Everyone,

I am working on configuring Risk Calculations for Policy Exceptions in ServiceNow GRC / Policy and Compliance Management, and I need some guidance on the complete quantitative and qualitative risk process.

Specifically, I want to understand:

1. Qualitative Scoring on Policy Exception: How do Impact and Likelihood dynamically calculate the overall Risk Rating on the Policy Exception (sn_compliance_policy_exception) table?

2. Quantitative Risk Factors (SLE, ARO, ALE): How do single-loss and annual-frequency metrics integrate into this flow?

   • SLE (Single Loss Expectancy): Asset Value $\times$ Exposure Factor

   • ARO (Annualized Rate of Occurrence): Estimated frequency of the exception occurring per year

   • ALE (Annualized Loss Expectancy): $\text{SLE} \times \text{ARO}$

3. Combination & Mapping: What is the standard ServiceNow best practice to combine qualitative (Impact/Likelihood matrix) and quantitative (SLE/ALE/ARO) risk assessments on a Policy Exception record? Do we map them through Risk Assessment Methodologies (RAM) in Advanced Risk, or handle them via custom Script Includes / Business Rules?

Any insight, configuration steps, or OOTB references on this would be greatly appreciated.

[Tom_T]

I'm not sure if I would do that. A policy exception is a short-term, timely limited exception form a non-compliance state (temporarily not permanent violation of a policy). That's why we use the simplified risk scoring of ServiceNnow OOTB (1-5). If the policy exception should be permanent - then it becomes a risk and I'll do a full risk analysis. One of the advantages I see in not doing qualitative and qunatitaive scoring is that a policy exception often  needs to bedecided extremely fast.

Definition:

A policy exception process is a formal procedure that allows an organization to temporarily deviate from established policies, standards, or procedures. This process is typically used when compliance with a policy is not feasible due to urgent business needs or unique circumstances. Key elements include

• Request Submission: Individuals or departments submit a request detailing the specific policy, the reason for the exception, and the duration needed.
• Risk Assessment: The request is reviewed to assess the associated risks and determine if compensating controls can mitigate these risks.
• Approval: The request is approved by relevant authorities, such as the Chief Information Security Officer (CISO) or department heads.
• Documentation: The exception is documented, including the rationale and any conditions for approval.