---
sourceDocument: Xanadu のガバナンス、リスク、コンプライアンス
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/xanadu/governance-risk-compliance

 Release :

    - xanadu

ft:locale :

    - ja-JP

ft:publication_title :

    - Xanadu のガバナンス、リスク、コンプライアンス

ft:clusterId :

    - grc

bundleId :

    - grc

workflow :

    - Technology


---

# ポリシー例外を要求

# ポリシー例外を要求 {#ariaid-title1}

* リリースバージョン: Xanadu
* 
* 更新日 2024年08月01日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：4分

ユーザーは、例外が適用されるシステム、アプリケーション、ネットワーク、またはエンティティの特定のリストで例外の理由を指定することで、ポリシー、コントロール目標、または問題の例外を要求できます。ユーザーは、例外が必要な期間も指定する必要があります。

## 始める前に

必要なロール： sn_grc.business_user、sn_grc.business_user_lite

## このタスクについて

例外は、特別な状況のためにコンプライアンス要件を満たすことができないユーザーを一時的に保護します。たとえば、ユーザーが、OS ベンダーがパッチをリリースしてから 48 時間以内にすべての重要な OS サーバーにパッチを適用する必要があるという規定を満たすことができない場合などです。

## 手順

1. 移動先 すべてPolicy and Compliance自分のポリシー例外.
2. \[新規\] をクリックします。
3. フォームのフィールドに入力します。  
   {#request-policy-exception__table_epy_qrq_f5__entry__2}{#request-policy-exception__source-type-policy-excep}{#request-policy-exception__policy-ext-det}

   | フィールド | 説明 |
   |-|-|
   | 番号 | 一意の識別番号。 |
   | 要求者 | ポリシー例外を要求するユーザー (通常はコントロールオーナー)。 |
   | 承認グループ | コンプライアンスマネージャーロールを持つグループ。ポリシー例外がレビュー状況に達すると、承認グループを編集できません。 承認グループを指定しない場合、フィールドはデフォルトでコンプライアンスマネージャーに設定されます。コンプライアンスマネージャーは、ポリシー例外が GRC と統合されたアップストリームアプリケーションから発生した場合のデフォルトのロールです。たとえば、インシデントに関連する問題に対してポリシー例外を生成し、その問題が GRC に関連しているとします。 |
   | 承認者 | 承認グループのユーザー。例外ポリシーが \[分析\] ステータスに移行した場合は、承認者を選択する必要があります。 |
   | 状況 | 承認ワークフロー内のポリシー例外のステータス。 |
   | サブステート | 承認ワークフロー内のポリシー例外の承認サブステート。 |
   | 優先度 | このポリシー例外の承認優先度 |
   | ウォッチリスト | 要求が更新されたときに通知されるユーザー。 |
   | 名前 | ポリシー例外の一意の名前。 |
   | 理由 | ポリシー例外を要求する理由。要求者は、ポリシーの例外が承認されるまで理由を変更できます。 |
   | 正当性 | ポリシー例外の説明。理由は \[コメント\] タブの \[追加コメント\] フィールドにも表示されます。 |
   | ソース ||
   | ソースタイプ | 作成するポリシー例外のタイプ。オプションは次のとおりです。 * ポリシー：ポリシーに基づいてポリシー例外を作成します。 * コントロール目標：デフォルトは、ポリシー例外が作成される単一のコントロール目標です。コントロール目標を選択すると、\[影響を受けるコントロール\] タブが表示され、コントロール目標に関連付けられたコントロールを選択できます。 * コントロール：複数のコントロールでポリシー例外を作成するオプション。異なるコントロール目標から複数のコントロールを関連付けるには、\[コントロール\] を選択します。このオプションは、複数のコントロールに適用される複数のポリシー例外を作成するのではなく、ポリシー例外の複数のコントロール目標をサポートします。 * 問題：このポリシー例外に関連する問題。 {#request-policy-exception__ul_oyk_tx5_ksb} |
   | コントロール目標 | このポリシー例外に関連付けられたコントロール目標。 |
   | 問題 | このポリシー例外に関連する問題。 |
   | ターゲットレコード | ポリシー例外が適用されるターゲットレコードテーブル。このテーブルは、\[ポリシー例外統合レジストリ\] フォームの \[ポリシー例外ターゲットテーブル\] フィールドでも参照されます。 |
   | リスクアセスメント ||
   | リスク評価 | ポリシー例外で実行されるリスクアセスメントで定義されるリスク評価を選択します。 |
   | リスク詳細 | リスクアセスメント中にリスクマネージャーによって実行されたリスクの説明。 |
   | リスクと影響度の分析 | このリスクが発生する可能性と、このリスクがポリシーの例外に及ぼす残存影響度の詳細。 |
   | リスク軽減計画 | このポリシー例外のリスク軽減計画。 |
   | スケジュール ||
   | 有効期限開始 | ポリシー例外が開始される日。 |
   | 有効期限 | ポリシー例外が終了する日。 \[有効期限\] の日付は \[有効期限開始\] よりも後である必要があり、過去の日付にすることはできません。 |
   | 期間 | \[有効期限開始\] と \[有効期限\] の間の日数。 |
   | 承認された延長 | これまでに要求され、承認された延長の回数。 |
   | 残りの延長 | 将来的に延長を要求できる回数。 `残りの延長 = `Number of extensions allowed for a policy exception` プロパティの値 -- 承認された延長の数`。 |
   | 作成済み | ポリシー例外が要求された日付。 |
   | 承認日 | 要求が承認された日付。 |
   | 延長日 | 要求された延長日。\[有効期限\] より後の日付です。 |
   | 延長理由 | 延長の理由。 |
   | 元の有効期限 | ポリシー例外が最初に要求され、承認された日付。元の \[有効期限\] の日付は、延長が承認された場合にのみ入力されます。 |
   | コメント ||
   | 作業メモ | 例外のレビュー担当者と承認者は、作業メモを使用して例外に関する情報を共有できます。 |
   | 追加コメント | これらのコメントは、レビュー担当者が例外要求者に追加情報を伝えるために使用します。 |
   | 機密性 ||
   | 機密 | レコードの機密性を有効にするオプション。アサインされた機密ユーザーまたはユーザーの機密グループのみがレコードにアクセスできます。 機密オプションの詳細については、「[監査およびコンプライアンスレコードの機密性フラグ](https://servicenow-prod.fluidtopics.net/NSTgkRYJxXwY9qe9qaIHpg "機密性フラグは、問題、エンゲージメント、観察事項、コントロールテスト、アクティビティ、面談、およびチュートリアルのレコードに、レコードレベルで設定できます。許可されたユーザーが、これらのレコードを表示および更新できます。")」を参照してください。 |
   [表 : 1. ポリシー例外フォーム]

   {#request-policy-exception__table_epy_qrq_f5}  
   注:  
   バージョン 10.1 より前のバージョンでは、\[リスクアセスメント\] タブは \[ビジネスインパクトアナリシス\] と呼ばれており、GRC: リスク管理 アプリケーションがアクティブ化されている必要がありました。バージョン 10.1 以降、リスク管理 への依存関係が削除され、関連するフィールド名が変更されました。

   \[承認済みの延長\]、\[残りの延長\]、\[承認日\]、\[延長日\]、\[延長の理由\]、\[元の有効期限\] フィールドは、ポリシー例外の延長を要求し、承認者によって承認された場合にのみ表示されます。
4. ポリシー例外を保存します。
5. いずれかのタブをクリックして、ポリシー例外のさまざまなタイプの情報を表示します。
6. \[更新\] をクリックします。