---
sourceDocument: Yokohama Governance, Risk, and Compliance
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/yokohama/governance-risk-compliance

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama Governance, Risk, and Compliance

ft:clusterId :

    - grc

bundleId :

    - grc

workflow :

    - Technology


---

# Request a policy exception using the Compliance Workspace

# Request a policy exception using the Compliance Workspace {#ariaid-title1}

* Release version: Yokohama
* 
* Updated January 30, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 8 minutes to read

Use the Compliance Workspace to 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 applies. You must
also specify the duration for which the exception is required.

## Before you begin

Role required:
sn_grc.business_user, sn_grc.business_user_lite

## About this task

Exceptions provide temporary relief when you are unable to meet compliance
requirements due to extraordinary situations. For example, you are unable to meet a
control that stipulates all critical OS servers must be patched within 48 hours
after the OS vendor releases patches.  
Note:  
For more information on policy exceptions, see [Manage policy exceptions and extensions](https://servicenow-prod.fluidtopics.net/sXloJnIQvMsddmBc03jugA "Policy exceptions and extensions provide temporary relief for non-compliant controls.").

## Procedure

1. Navigate to AllPolicy and ComplianceCompliance Workspace.
2. Click Policy exception in the Create list.
3. On the form, fill in the fields.  
   {#request-policy-exception-ws__table_epy_qrq_f5__entry__2}{#request-policy-exception-ws__source-type-policy-excep}{#request-policy-exception-ws__policy-ext-det-ws}{#request-policy-exception-ws__take-risk-assess}

   | Field | Description |
   |-|-|
   | Number | Unique identification number. |
   | Name | Name of the policy exception. |
   | Requester | Person requesting the policy exception, usually the control owner. |
   | Reason | Reason for requesting the policy exception. The requester can change the reason until the policy exception is approved. |
   | Short description | Description for the policy exception request. |
   | State | State of the policy exception within the approval workflow. |
   | Substate | Approval substate of the policy exception within the approval workflow. |
   | Priority | Approval priority of this policy exception |
   | Justification | Evidence or rationale for the policy exception. |
   | Source ||
   | Source type | Type of policy exception that you want to create. The options are: * Policy: Create a policy exception based on a policy. * Control objective: Default is a single control objective on which the policy exception is created.When you select a control objective, the Impacted controls tab appears, where you can select controls associated to the control objective. * Controls: Option to create a policy exception on multiple controls.Select Control to associate multiple controls from different control objectives. This option supports multiple controls objectives for your policy exception, instead of creating multiple policy exceptions that could be applied on multiple controls. * Issue: Issue associated with this policy exception. {#request-policy-exception-ws__ul_oyk_tx5_ksb} |
   | Policy | Policy for which the exception is created. |
   | Control objective | Control objective associated with this policy exception. |
   | Issue | Issue associated with this policy exception. |
   | Target record | Target record table on which the policy exception is applied. This table is also referenced in the Policy exception target table field of the Policy Exception Integration Registry form. |
   | Schedule ||
   | Valid from | Day on which the policy exception begins. |
   | Valid to | Day on which the policy exception ends. Valid to date must be after Valid from date and cannot be a past date. |
   | Duration | Number of days between the Valid from and Valid to dates. |
   | Approved extensions | Number of times extensions have been requested so far and have been approved. |
   | Remaining extensions | Number of times extensions can be requested in future. `Remaining extensions = Value in the `Number of extensions allowed for a policy exception` property -- Number of Approved extensions`. |
   | Created | Date on which the policy exception was requested. |
   | Date approved | Date on which the exception was approved. |
   | Extension date | Requested extension date, which is after the Valid to date. |
   | Extension reason | Reason for extension. |
   | Original valid to | Date until which the policy exception was originally requested and approved. The originalValid to date is populated only when the extension is approved. |
   | Assignment ||
   | Watch list | Users that are notified when the request is updated. |
   | Approval group | Group that has the compliance manager role. If the policy exception reaches Review state you cannot edit the approval group. If you don't provide an approval group, then the field defaults to compliance manager. Compliance manager is the default role if the policy exception is raised from any upstream application that is integrated with GRC. For example, if you raise a policy exception for a problem that is related to an incident and that problem is related to GRC. |
   | Approver | User from the approval group. If the exception policy moves to the Analyze state, then you must select an approver. |
   | Risk assessment ||
   | Method | Method to assess risk: * Select risk rating: Select the risk rating associated to this policy exception. * Take risk assessment: Take a risk assessment to calculate the risk rating. Note: This option is available only when GRC: Advanced Risk plugin is installed. {#request-policy-exception-ws__ul_tqx_tqf_wtb} Risk assessment can be triggered by clicking the Assess risk button on the form. This button is available only when Take risk assessment is selected. |
   | Risk rating | Risk rating as determined by the risk assessment performed on the policy exception. If you had selected Select risk rating option in the Method field, then you can select a value from the list. If you select Take risk assessment option in the Method field, then this field is auto-populated with the response provided in risk assessment. |
   | Override | Option to override Risk rating that was auto-populated based on the responses provided for the risk assessment. This field appears if the Method is Take risk assessment option. |
   | Risk description | Description of the risk as performed by the risk manager during risk assessment. |
   | Analysis of risk and impact | Details on the likelihood of this risk occurring and residual impacts of this risk on the policy exception. |
   | Risk mitigation plan | Risk mitigation plan for this policy exception. |
   | Comments ||
   | Work Notes | Work notes can be used by exception reviewers and approvers to share Information about the exception. |
   | Additional comments | These comments are used by the reviewer to communicate additional information to the exception requester. |
   | Confidentiality ||
   | Confidential | Option to enable confidentiality of the record. Only the assigned confidential users or confidential groups of users can access the record. For more information on confidential option, see [Confidentiality flag for audit and compliance records](https://servicenow-prod.fluidtopics.net/TWV43mDPBfODaXMrhD5aEg "You can set the confidentiality flag at the record level for an issue, engagement, observation, control test, activity, interview, and walkthrough records. The users whom you determine to view and update these records are allowed users."). |
   [Table 1. Create New Policy Exception form]

   {#request-policy-exception-ws__table_epy_qrq_f5}  
   Note:  
   In versions prior to Version 10.1, the Risk assessment related list was called Business Impact Analysis and required that the GRC: Risk Management application be activated. Starting in Version 10.1, the dependency on Risk Management has been removed and the associated field names have changed.

   Approved extensions,
   Remaining extensions, Date approved, Extension date,
   Extension reason, Original valid to fields appear only when you've requested an
   extension on the policy exception and has been approved by the
   approver.  
   With regard to the m2m association of an issue with policy exceptions, there are certain considerations you must know about the values populating in the Issue field, Control objective field, and in the Impacted control tab:
   1. If you select an issue in the Source type field, then the Issue reference field lists issues that have one or more active controls associated with them. Active controls are the ones in Attest, Review, or Monitor states and not in Draft or Retired states. You can navigate to the Impacted controls tab to view the controls associated to the issue.
   2. If the issue is linked to only one control objective, then that linked control objective is populated in the Control objective reference field. If the issue is linked to more than one control objective, then no value is populated in the Control objective field. Click the Control objective reference field to select a control objective.
   3. If you didn't select an issue in the Issue field, but a control objective is populated in the Control objective reference field, then the Issue reference field will list only those issues that are linked to this control objective.
   4. As soon as you add an issue in the Issue field, then all the controls linked to the issue are added in the Impacted controls tab. However, when you select a control objective in the Control objective reference field, then all the controls listed in the Impacted controls tab are replaced with only those controls that are linked to the selected control objective and the issue. Controls can be in any state but not in Draft or Retired state.
   5. An impacted control linked to one issue of a policy exception will not be listed for you to add in another policy exception because that control is already listed in the Impacted control tab of the first policy exception. If you add more controls to the issue later, and when you link the issue to the second policy exception, then all the newly added controls will be added as impacted controls but not the one that was already added as an impacted control of the first policy exception.
   6. Previously, an issue-based exception required a linked policy or control objective for additional approvals. Now, it requires any one of the following: a linked policy, control objective, or control. If a control is used, it must be linked to the policy exception itself, not just to the issue.
   {#request-policy-exception-ws__ol_x2d_wry_bwb}
4. Save the policy exception.  
   The Policy exception is in New state.
5. Click the Request approval button.  
   If verification rules are configured, then verification approvals are triggered. After the verification approvals are approved, the policy exception moves to Analyse state.

   After the policy exception is approved and if the
   Valid to date is reached, then the state moves to
   Closed and the substate moves to
   Expired.

   You can also withdraw the policy
   exception anytime before the policy exception is approved, if it's no longer
   required, right from the New state.
6. To withdraw the policy exception, click the Cancel Request button.  
   The state moves to Closed and the substate to Canceled.
{#request-policy-exception-ws__steps_x5q_m4z_2qb}

## What to do next

As a requester you can request extensions to a policy exception that is in the
Approved state more than once. Configure the Number of extensions allowed for a policy exception property to request policy extension multiple
times.

To set up the property, see [Configure the number of extensions allowed for a policy exception](https://servicenow-prod.fluidtopics.net/vrAvayeJPp3qjbX6n4t0qA#request-policy-extension-platform__substeps_pol-ext-multi).

To request extension, click the Request extension button and
[enter the details in the Request extension pop-up](https://servicenow-prod.fluidtopics.net/vrAvayeJPp3qjbX6n4t0qA#request-policy-extension-platform__request-exten-pol-excep).

Click Request. You can see the policy extension details in the
[Schedule tab of the Policy
exception form](https://servicenow-prod.fluidtopics.net/AaSW8RL1Bixkz~Uz6qNSPw#request-policy-exception-ws__pol-ext-det-ws) after the requester has requested for an extension and the
policy extension has been approved by the approver.

*[\>]: and then