Request a 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.
Before you begin
Role required: sn_grc.business_user, sn_grc.business_user_lite
About this task
Exceptions provide temporary relief for users unable to meet compliance requirements due to extraordinary situations. For example, if the user is unable to meet a control that stipulates that all critical OS servers must be patched within 48 hours after the OS vendor releases patches.
Procedure
Navigate to All > Policy and Compliance > My Policy Exceptions.
Click New.
On the form, fill in the fields.
| Field | Description |
|---|---|
| Number | Unique identification number. |
| Requester | Person requesting the policy exception, usually the control owner. |
| Approval group | Group that has the compliance manager role. You cannot edit the approval group if the policy exception reaches Review state.If you do not 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. |
| 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 |
| Watch list | Users that are notified when the request is updated. |
| Name | Unique name of the policy exception. |
| Reason | Reason for requesting the policy exception. The requester can change the reason until the policy exception is approved. |
| Justification | Statement of explanation for the policy exception. Justification is also displayed in the Additional comments field of the Comments tab. |
| 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, theImpacted controls tab appears, where you can select controls associated to the control objective.
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.
|
| 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. |
| Risk assessment | |
| Risk rating | Select the risk rating as determined by the risk assessment performed on the policy exception. |
| 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 | The risk mitigation plan for this policy exception. |
| 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 request 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 original Valid to date is populated only when the extension is approved. |
| 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. |
**Note:** In versions prior to Version 10.1, the **Risk assessment** tab 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 have requested an extension on the policy exception and has been approved by the approver.
Save the policy exception.
Click any of the tabs to view the various types of information for the policy exception
Click Update.
Parent Topic:Manage policy exceptions and extensions