Risk Exception Management: Creating a Policy Exception Process

Corporate policies help maintain consistency and ensure stakeholders know what the organization expects from them. But because no policy is perfect, companies are sometimes forced to make exceptions to the rules, which generates risks. Risk exception management provides a structured way to handle those situations without letting things get out of control.

What Is a Risk Exception?

A risk exception occurs when an organization allows a stakeholder to temporarily bypass company policy for a justified reason. For example, a typical organization has standards that suppliers and vendors must meet before working together, often for compliance or security purposes. However, it can make an exception to do business with a reputable third party that hasn’t met all the requirements yet.

Risk exceptions give you some flexibility when sticking to internal standards isn’t practical. They help you find the right balance between following policies and adapting to different circumstances in the real world. Use them where the benefits of making an exception outweigh the potential drawbacks — or where the downsides are manageable with the right risk mitigation measures in place.

Risk Exception vs Risk Acceptance

Risk exception and risk acceptance are entirely different terms.

With risk acceptance, you “acknowledge the existence of the risk but take no action” to mitigate it, according to Stanford University. It means you’ve assessed a risk and decided it’s tolerable without having to implement any control measures. For example, you might determine that a software vendor’s minor noncompliance with your company’s cybersecurity policies poses a low risk such that further action is unnecessary. So, you take the risk as-is and live with it in the long run.

A risk exception, on the other hand, is a short-term deviation from company policy. It involves putting measures in place to reduce the chances of a risk occurring or to minimize its impact. Meanwhile, if you accept a risk, you do nothing to mitigate it.

Risk exceptions usually have expiration dates, which means they are temporary. Risk acceptance is about deciding to live with a risk permanently. The table below summarizes the risk exception vs risk acceptance comparison:

Creating a Policy Exception Process

Policy exceptions involve stakeholders, such as employees and external partners, who ask to bypass a company’s policy. Selected authorizing officials in the organization evaluate the exception request and decide whether to approve or deny it.

Each company may have a unique policy exception procedure. But there are common basic steps you can follow to set up the process in your organization.

Step 1. Establish How to Submit a Request and Define Requirements

For most companies, stakeholders can ask for exceptions using a request form on policy management software. Each request should meet specific requirements, such as:

• Specify the particular policy for which an exception is requested
• Include the name and contact details of the person or third party requesting exceptions
• Justify why the exception is being requested
• Show alternative ways that could be used instead of a policy exception and why they are not applicable in the particular case
• Provide measures the requestor will take to mitigate risks that emerge from approving the exception requests
• Specify how long the exception will last or the anticipated length of noncompliance (start and end dates)

A robust policy management solution like Onspring allows users to document why they need to bypass a policy, indicate the exception’s duration and provide any other details relevant to the exception request. Besides submitting forms for exception, stakeholders can use the tool to monitor the approval process from beginning to end.

Step 2: Set Up a Team of Approvers

While the approver can be an individual, having tiers of authorizing officials adds structure and accountability to the policy exception process. The officials can review and authorize requests based on the level of risk posed by policy exceptions.

A three-tier team of approvers, for example, can have the following officials in each tier:

• Tier 1: A front-line manager like a risk management supervisor
• Tier 2: A middle-level leader like an IT security manager
• Tier 3: A senior leader, such as a chief compliance officer (CCO)

What matters most when selecting approvers? Choose people who have the right level of authority to make policy exception decisions in the company. They should also have expertise in assessing risks effectively.

Step 3. Evaluate the Potential Risks Related to the Exception

Once someone submits an exception request, it goes to authorizing officials for analysis and confirmation. During the evaluation, they check what could go wrong if the proposed exception is granted, how severe the impact would be and whether the risk can be mitigated.

Depending on how likely a risk is to occur and the damage it would cause, a policy exception can be classified as:

• Low risk: Rare or unlikely to happen; if it occurs, the resulting damage is minimal
• Medium risk: May happen occasionally and could cause moderately serious damage
• High risk: Very likely to happen and could severely harm the organization when it occurs

These rankings help determine how a policy exception is approved. It also helps you decide whether to approve, deny or modify the request.

Step 4. Determine How to Mitigate Identified Risks

After identifying the risks associated with a policy exception, the next step is brainstorming mitigation strategies. How will you make the risk less likely to occur or minimize its impact?

The goal here is to make sure that when a policy exception is approved, measures are taken to prevent operational, compliance and security problems. Document the mitigation plan, including who will be responsible for implementing it and measuring its effectiveness.

Step 5: Approve or Deny the Exception Request

If a tiered team of approvers oversees your policy exception process, the magnitude of evaluated risks will determine the level of authorization that’s necessary.

For instance, low-risk exceptions may only require approval by a low-level manager. Medium-risk exceptions, on the other hand, may need authorization by both a low-level and mid-level manager. Meanwhile, high-risk exceptions can require approval by all authorizing officials. The chart below summarizes the example of approval levels:

Approvers can deny a policy exception request when:

• The negative impacts of granting an exception outweigh the projected benefits
• There are feasible alternatives to a policy exception
• An exception request creates significant risks without robust controls to mitigate them

If an exception requires authorization from two or more leaders in an organization, unanimous agreement by all approvers is often necessary for the exception to be granted. If any approver rejects the request, the policy exception is denied.

When a risk exception is denied, the requestor won’t be allowed to bend the rules in question. In that case, your organization can give that person a reasonable deadline to comply with company policy.

Step 6: Extend or Retire Expired Risk Exceptions

Policy exceptions usually have expiration dates. When the validity duration is almost over, your organization can send automated alerts to remind relevant stakeholders to request an extension or terminate the exception if it is no longer necessary.

Some companies encourage stakeholders to ask for extensions weeks or even months before the expiration date. This provides enough time for approvers to:

• Evaluate any new risks created by the exception extension
• Develop potential measures to mitigate the resulting risks
• Find potential alternatives to the exception extension
• Decide whether extending the duration of a particular policy exception is a good idea

Policy management solutions like Onspring make the entire risk exception process easy. They provide a centralized place for stakeholders to request policy exceptions and obtain appropriate reviews and approvals. Users can also request extensions right from the platform.

Policy Exception Examples

Security Policy Exception

A company requires all applications to have an event logging feature, which records security-related events like login attempts and system modifications. One custom-made application does not have the capability. The software developer plans to include the feature, but doing so will take several months. Because the application supports critical business operations, the organization approves the exception.

Policy Exception for Legacy Systems

A new organization policy requires multi-factor authentication (MFA) when logging into any system with sensitive details. However, the HR department runs a legacy payroll system that can’t handle MFA. Switching to a new platform will take months. So, the company allows HR to use the outdated software (with other safeguards in place, like frequent monitoring) until the upgrade is done.

Records Access Policy Exception

Employees from another department need temporary access to sensitive client records in HR or finance for a special project. Normally, they wouldn’t access these details as a matter of data protection policy. However, the organization grants an exception with two conditions:

• The employees’ access is strictly limited to information necessary to get the job done
• The access is revoked as soon as the project is over

Managing Risk Exceptions: Tips and Best Practices

You can streamline policy exception management and reduce risks by implementing the following best practices:

Set Conditions for a Policy Exception Request

Every time you approve an exception request, your company faces extra risks. Having solid conditions can prevent stakeholders, especially third parties like vendors and suppliers, from abusing your exception process.

For instance, you can ask third parties to disclose what may go wrong as a result of the exception. You can use the disclosure to hold them accountable in the future and improve your third-party risk management. You can also limit exception duration — a shorter period reduces the time your company is exposed to risks associated with exceptions.

Track Exceptions Even After Approval

Continuous monitoring ensures you keep risks related to exceptions in check. If, for some reason, they become more significant than you evaluated in the risk exception process, you can take action quickly before things get out of hand.

Regularly Check and Update Company Policies

Regular reviews may reveal overly strict or outdated policies that lead to frequent exception requests. Updating the rules to better fit the current circumstances in the real world can reduce the need for exceptions in the first place.

Have a Formal Exception Process

Depending on a company’s size and maturity, exceptions can be approved during a simple hallway conversation or in a formal procedure. The second option is the best because you’ll have a structured, well-documented process that captures the following details in writing:

• Who is requesting a policy exception
• Why the exception is being requested (justification)
• When the exception will expire
• The risks involved
• How to mitigate those risks

When all these details are well-documented, analyzing, approving and tracking exceptions is easy. The details can also be helpful when preparing for audits or other regulatory compliance checks.

Risk Exception Management in Onspring

Without technology, a company may be forced to use emails and spreadsheets to manually review, authorize and track risk exceptions. These manual processes are time-consuming, costly and difficult to manage.

Onspring’s policy management software brings all your policy management data in one place for easy access and analysis, including the risk exception process. We’re happy to show you how it works. Just schedule your demo to see how Onspring can help.