---
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分

アプリケーションのリスクを評価する際、アプリケーションはさまざまな段階のリスク識別およびアセスメントを経ます。要件に基づいて識別およびアセスメントのワークフローを定義できます。

アプリケーションのリスクを評価する前に、アプリケーションをビジネスアプリケーションテーブルで作成し、GRC に取り込む必要があります。アプリケーションが GRC に取り込まれると、リスク識別レコードが作成されます。アプリケーションオーナーは、アプリケーションに関する情報を IT リスクマネージャーに提供します。IT リスクマネージャーは、推奨されるリスク、引用、およびポリシーをマッピングします。  
ビジネスアプリケーションのリスクの特定とアセスメントのワークフローを理解するために、次の例について検討してください。新しいビジネスアプリケーションが組織に導入されました。この新しいアプリケーションはビジネスアプリケーションテーブルの一部です。新しいアプリケーションには次の 2 人のオーナーがいます。

* IT アプリケーションオーナー
* ビジネスオーナー：このユーザーには sn_grc.business_user ロールが必要です。

{#workflow-risk-identification__ul_rw2_ky4_smb}  
注:  
組織はさまざまなロールを使用できます。
この時点では、アプリケーションは GRC の一部ではありません。リスクを評価する前に、アプリケーションをエンティティとして GRC に取り込む必要があります。新しいアプリケーションには、情報オブジェクトも関連付けられている必要があります。

アプリケーションリスクアセスメントのワークフローと承認者は、リスク識別構成フォームの設定によって決定されます。ワークフローを定義するプロセスについては、「[リスク識別統合の設定](https://servicenow-prod.fluidtopics.net/Mvfl5mye4feBib3lzPtXTw "アプリケーションを評価する前に、リスクの特定を開始する必要のあるターゲットアプリケーションを指定します。")」を参照してください。リスクの特定を再開するために、フローデザイナーアクションが提供されています。  
新しいビジネスアプリケーションを評価する際のリスク識別のワークフローは次のとおりです。

1. ビジネスアプリケーションは、自動的に、またはアプリケーションオーナーによってビジネスアプリケーションテーブルに作成されます。
2. GRC が新しいビジネスアプリケーションを検出します。新しいアプリケーションの GRC エンティティが作成されます。検出は、バックグラウンドで実行される GRC プロファイル生成スケジュール済みジョブによって処理されます。
3. アプリケーションの新しいリスク識別レコードが作成されます。  
   注:  
   リスクマネージャーは、設定レコードを変更し、アセスメントのワークフローを決定できます。リスク識別構成が公開された後、リスクマネージャーは設定レコードの一部のフィールドのみを変更できます。
4. アプリケーションの詳細を収集するために、アンケートが開始され、アプリケーションオーナーに送信されます。
5. アプリケーションオーナーがアンケートに回答します。
6. IT リスクマネージャーが応答をレビューします。応答が不十分な場合、マネージャーはアンケートをアプリケーションオーナーに返送します。  
   注:  
   アンケートが返送されると、新しい応答が元のフォームに戻ります。
7. 構成に基づいて、IT リスクマネージャーが応答に満足すると、システムは固有のアセスメントを開始します。
8. GRC は、エンティティタイプに基づいてリスクとコンプライアンスオブジェクトをマッピングします。
9. IT リスクマネージャーは、情報オブジェクトマッピングをレビューします。
10. システムは、構成で選択されているアルゴリズムに基づいて、推奨エンジンを実行します。
11. IT リスクマネージャーは、関連付けられた情報オブジェクトに基づいて、推奨されるリスク、ポリシー、および引用をレビューしてマッピングします。
12. IT リスクマネージャーは、関連付けられた引用、ポリシー、およびリスクに基づいて、推奨コントロールをマッピングします。
13. アプリケーションオーナーは、コントロールのライフサイクルを管理し、コントロールを証明します。
{#workflow-risk-identification__ol_g2v_qxb_mmb}  
次の図は、ソリューションのワークフローを表しています。図 : 1. GRC と APM 統合のソリューションワークフロー

## リスク識別レコードの状況 {#workflow-risk-identification__section_ppm_xcv_nnb}

リスク識別構成が \[公開\] ステータスに移行すると、関連エンティティのリスク識別レコードが作成されます。  
リスク識別レコードは、次の状況に移行します。

* 新規：新しいレコードが作成されます。
* 情報収集：アプリケーションに関する情報が収集されます。
* レビュー：リスクマネージャーが、情報をレビューします。
* 固有のアセスメント：リスクマネージャーが固有のリスクアセスメントを実行します。
* リスクマッピング：リスクマネージャーは、必要なリスク、引用、およびポリシーをマッピングします。
* 監視：リスクが監視されます。
* 廃止：リスクは必要に応じて廃止されます。
{#workflow-risk-identification__ul_dxl_ycv_nnb}

リスク識別構成が \[廃止\] ステータスに移行すると、構成が無効になり、関連エンティティのリスク識別レコードが作成されません。  
ライフサイクルの観点では、リスク識別レコードは、次の状況を辿ります。

1. 新規
2. 情報収集
3. レビュー
4. 固有のアセスメント
5. リスクマッピング
6. 監視
7. 廃止
{#workflow-risk-identification__ol_c3t_hfn_4nb}