Policy Exceptions and Issue Management

[Karin4]

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

[HenkHeath · Accepted solution]

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.

[Anurag22]

@HenkHeath , Brilliant explanation through an example, however when you said, "Metrics track issues and their resolution", could you please tie it back to your SAP example? 

I am trying to learn something out of it, so if SAP as an entity (in ServiceNow) failed the attestation of MFA control, an Issue was generated. How come metrics track that issue and its resolution?

[HenkHeath]

Metrics (general use of the term) is anything I want to measure.  So naturally I need to define what I am measuring it against to determine its performance.

With every application, the aim is to report;

• Risk - what does my risk posture look like? (how much risk am I taking while conducting business)
• Compliance - How compliant am I in meeting my obligations (external - Authority documents / Internal - policies ).  Basically how healthy is my control environment
• CMDB - how health and complete is my CMDB?

So everything we do is with the aim to report. This is where ServiceNow offers a few options;

• Informational record overview tabs.  helps you understand the record at a glance
• Dashboards
• More importantly - Performance analytics (PA) - PA not only provides what the above 2 provide, but also a trend analysis.  what has happened to my compliance over time.*   (* check if your customer is licensed for PA)

In general the basic metrics are presented in the "Overview" dashboard for each of the modules.

PA runs on Metrics

In order to measure, you need to set up a collection of data (Metric Sources).  In the example of SAP and the issues.  There are many OOTB metrics available, and they may already be collecting data in order to display it on your records and dashboards.

You may want to set up a source that collects all issues, with an appropriate breakdown (Entities) so that you can evaluate the issues by entity.

It is not always about reporting at the end of a period - 31 March - 3 open issues / 30 April - 3 open Issues.  This does not seem too bad.  Good Job!

The PA indicator will tell you the full story. 

31 March - 3 open issues

During April - 30000 new issues 

During April - 30000 issues closed 

30 April - 3 open issues 

Clearly we have a major problem here that needs to be addressed!

Example of what you could see (not related to the figures above - just demo data) 

If you were looking at a dashboard that shows you open issues, you would not have picked up the problem.  With Metrics and Control Indicators, you could have been warned on 1 April that something was wrong.

In this case you may have had a metric/indicator that measures number of issues per application in a 30 day period.  If for example it exceeds 5 then alert the relevant owner groups / compliance.

Examples of metrics you could use.

- Time an issue has been overdue (basically SLA breach) because SLAs differ you want to use the Business elapsed percentage >100%

- Number of issues per period.

- Percentage issues closed in a period.  ( careful here.  make sure you understand the numerator and denominator for your calculation - what about cancelled? only issues created in the same period? what about accepted issues?)

- % of controls non-compliant

- Number of Extreme risks

The list is endless. 

Reporting is probably the most complex side of any business activity.  you really need to know what you are measuring and how you are measuring it. 

[Community Alums]

Hi @Karin4 ,

Find the answers :

1. There are diffrent reasons for risks, issues and exceptions. All have diffrent situations.

Let's say for Policy exception Users can request exceptions for policies, control objectives, or issues by specifying the reason of exception on a particular list of the systems, applications, networks, or entities for which the exception will apply. The user must also specify the duration for which the exception is required.

For Risks, let's undertsand it's menaing ,a "risk" is a potential event that could negatively impact an organization's ability to achieve its objectives, requiring systematic identification, assessment, and mitigation. 

Risks are created from the Risk Statements.  This process is similar to the Control Objective and Control creation process.Once you have created all your Risk Statements, you can associate them with Entity Types.  All the Entities in the Entity Type will then get a Risk associated with them.

Finally, Issues can be created manually to document audit observations or remediations, or to accept any problems. They are automatically generated from indicator results, attestation results, or control test effectiveness.

2. By Default, policy exception is 30 days , however you can extend it by changing the property "sn_compliance.default_maximum_exception_duration" . And you can Configure the Number of extensions allowed for a policy exception property to request policy extension multiple times. If you enter 20, then you can request 20 extensions for each policy exception. If an extension request is rejected by the approver, then you can request another extension until the Valid to date is reached.

3. We Add the Risk to the policy Exception Record. Issues are not Linked: