Policy Exceptions and Issue Management

Karin4
ServiceNow Employee
ServiceNow Employee

Please share your use cases and best practices with me for the following:

  • How do you determine (or train users to determine) when a situation should be a policy exception, an issue, a risk, or a combination of the three?
  • Policy exceptions have an OOB date constraint forcing the exception to be valid for up to 30 days from the valid from date and can be extended once. Does this assume that a policy exception should be short term and issue if greater than 60 days?
  • What process do you follow when a policy exception is requested, but requires a new risk and issue to be created?
  • Any other tips for managing issues, risks, and policy exceptions for cyber and IT risk and compliance management.

#Integratedriskmanagement #IRM #policyexception #cyberrisk

1 ACCEPTED SOLUTION

HenkHeath
Tera Expert

Hello @Karin4 

 

Applying Risk, Compliance & SecOps in Banking, Education and Superannuation environments, I can share the following;

Under Policy and Compliance have a look at a few configurable properties (All > Policy and Compliance > Properties) 

  • Default duration for which a policy exception can be requested (days)
  • Number of extensions allowed for a policy exception

These will help with the time constraints, but in general;

  • Policies are there for a reason, so why are you unable to comply?  might be financial constraints / time constraints, or any other reason.  This does not mean you can sidestep the policy by indefinitely seeking exemption.  Hence the short timeframe, and the maximum number of extensions.  You need to seek a solution (issue to be resolved)
  • Issues are to be used when something no longer operates as expected, so in the absence of an attestation / indicator, etc that will trigger a issue, the users need to be trained to create issues to maintain an audit train for future audits as well.  But these need to be genuine issues (severity implied).
  • Failing control will heighten your risk exposure, so you will need to configure this
  • Metrics track issues and their resolution

Setting the scene (just an example);

Policy - All business application should only be accessed by duly authorised persons

Risk - Unauthorised access to information

Control - Multifactor authentication

 

  1. When the attestation on Multifactor authentication on SAP fails, then an issue is automatically created.
  2. Since the IT manager is unable apply a fix to resolve it, SAP will temporarily have to be without MFA
  3. Since he is unable to resolve the Issue, he needs to seek exemption
  4. the exemption is there to allow a timeframe for extraordinary reasons to NOT comply with the policy.  The exemption requires the requestor to perform an assessment of the risk of not complying, and if approved, the exemption will stand for the duration
  5. Since the control is used to mitigate a risk, you may also want to alert the Risk manager / Risk owner
  6. Risk Owner / Risk Manager will have insight into the Issue and the Exemption, and if they choose they may even trigger a re-assessment of the risk.
  7. If this scenario presents a new risk, the risk manager / risk owner can easily introduce a new risk.

 

In an IT Risk Management environment I would suggest you delve into Risk Metrics and Control Indicators quickly (don't wait for maturity to start on these) as these will greatly enhance your automated evaluation. 

  • The environment is just too dynamic to rely on 6-monthly attestations and risk assessment (if as frequent) 
  • Business applications are aplenty, (some banks use in excess of 2300 business applications)
  • Change Management is an area of control that is easily automated via control indicators, especially if change management is done within ServiceNow  

 

On policy Exception - I once had a customer who insisted that the timeframe for a policy exception be set at 364 days and the number of extensions allowed be set to 3. - My question would be:  if this is a policy, why would you allow someone the opportunity to not comply for 4 years?  

 

Ensure you have a strong project manager to test, challenge requirements.

 

View solution in original post

5 REPLIES 5

Tom_T
Tera Contributor

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.

 

Some more information:'

Purpose: The policy exception process is focused on allowing temporary deviations from established policies, while the risk management process is aimed at identifying and managing risks to minimize their impact on the organization.

Duration: Policy exceptions are typically temporary and specific to certain circumstances, whereas risk management is an ongoing process.

Scope: Policy exceptions address specific deviations from policies, while risk management encompasses a broader range of risks affecting various aspects of the organization