suggest-remediation-tasks

GRC 是正タスクの提案

概要

このスキルは、GRC の問題と、それに関連する統制上のギャップ、リスクプロファイル、規制フレームワークを分析し、的を絞った是正タスクを提案します。推奨担当者、期限、優先度を含む、実行可能なタスクリストを作成します。

主な機能：

• ギャップ分析： 問題の原因となっている統制上の不備を特定し、それぞれを是正措置に対応付けます
• リスクベースの優先順位付け： 残余リスクスコア、悪用可能性、ビジネスへの影響に基づいて、提案タスクに順位を付けます
• 規制との整合： タスクを特定の規制要件（SOX、GDPR、HIPAA、PCI-DSS、NIST）に対応付けます
• 担当者の割り当て： 統制の所有者、割り当てグループ、過去の解決パターンに基づいてタスク担当者を提案します
• 期限の算出： 問題の優先度、規制上の期限、組織の SLA に基づいて期日を提案します
• タスクテンプレートの生成： 必須フィールドをすべて入力した、すぐに作成できるタスクレコードを生成します

使用する場面：

• 新しい GRC の問題が特定され、是正計画が必要な場合
• 監査での指摘に対し、体系的な是正措置計画が必要な場合
• 定期的なリスクレビューで、未解決の統制上のギャップに対処する場合
• 規制の変更に伴い、是正アプローチの更新が必要な場合
• 組織全体で是正計画を標準化する場合

前提条件

• ロール： sn_grc.manager、sn_compliance.manager、または admin
• プラグイン： com.sn_grc、com.sn_compliance、com.sn_risk
• アクセス権： sn_grc_issue、sn_grc_risk、sn_compliance_control、sn_grc_profile への読み取りアクセス権、sn_grc_remediation_task への書き込みアクセス権
• 知識： 組織に適用される規制フレームワークと統制の所有者構造に関する知識

主な GRC テーブル

テーブル	用途	主なフィールド
sn_grc_issue	GRC の問題と指摘事項	number、short_description、state、priority、risk_rating、profile、item、category、source
sn_grc_risk	プロファイルにリンクされたリスクレコード	number、risk_score、state、treatment、residual_risk、inherent_risk、category
sn_compliance_control	コンプライアンス統制	number、state、control_objective、owner、effectiveness、test_result、test_date
sn_grc_remediation_task	問題に対する是正タスク	number、state、assigned_to、due_date、short_description、issue、priority
sn_compliance_citation	規制上の引用	number、reference、regulation、authority
sn_compliance_policy	コンプライアンスポリシー	number、short_description、state、owner、policy_statement

手順

ステップ 1：対象の GRC 問題を取得する

是正計画が必要な問題を、関連するコンテキストフィールドをすべて含めて取得します。

MCP を使用（Claude Code/Desktop）：

Tool: SN-Get-Record
Parameters:
  table_name: sn_grc_issue
  sys_id: [ISSUE_SYS_ID]
  fields: sys_id,number,short_description,description,state,priority,risk_rating,profile,item,assigned_to,due_date,category,source,remediation_plan,sys_created_on

REST API を使用：

GET /api/now/table/sn_grc_issue?sysparm_query=number=[ISSUE_NUMBER]&sysparm_fields=sys_id,number,short_description,description,state,priority,risk_rating,profile,item,assigned_to,due_date,category,source,remediation_plan&sysparm_limit=1&sysparm_display_value=all

ステップ 2：問題に関連付けられた統制上のギャップを分析する

不合格または不備のある統制を特定し、是正が必要な内容を判断します。

MCP を使用：

Tool: SN-Query-Table
Parameters:
  table_name: sn_compliance_control
  query: profile=[issue_profile_sys_id]^stateNOT INcompliant,passed^active=true
  fields: sys_id,number,short_description,state,control_objective,owner,effectiveness,test_result,test_date,remediation_owner
  limit: 50

REST API を使用：

GET /api/now/table/sn_compliance_control?sysparm_query=profile=[profile_sys_id]^stateNOT INcompliant,passed^active=true&sysparm_fields=sys_id,number,short_description,state,control_objective,owner,effectiveness,test_result,test_date&sysparm_limit=50&sysparm_display_value=all

ステップ 3：優先順位付けのためのリスクコンテキストを評価する

関連するリスクレコードを取得し、深刻度と対応方針を把握します。

MCP を使用：

Tool: SN-Query-Table
Parameters:
  table_name: sn_grc_risk
  query: profile=[issue_profile_sys_id]^active=true
  fields: sys_id,number,short_description,risk_score,state,treatment,residual_risk,inherent_risk,category,owner
  limit: 25

REST API を使用：

GET /api/now/table/sn_grc_risk?sysparm_query=profile=[profile_sys_id]^active=true&sysparm_fields=sys_id,number,short_description,risk_score,state,treatment,residual_risk,inherent_risk,category,owner&sysparm_limit=25&sysparm_display_value=all

ステップ 4：該当する規制要件を特定する

引用とポリシーを取得し、是正タスクを規制上の義務に適合させます。

MCP を使用：

Tool: SN-Query-Table
Parameters:
  table_name: sn_compliance_citation
  query: active=true
  fields: sys_id,number,short_description,reference,regulation,authority
  limit: 50

ステップ 5：是正タスクの提案を生成する

分析に基づいて、体系化された是正タスク一式を作成します。

MCP を使用：

Tool: SN-Execute-Background-Script
Parameters:
  script: |
    var issueNumber = 'ISSUE0001234'; // Replace with target issue
    var gr = new GlideRecord('sn_grc_issue');
    gr.addQuery('number', issueNumber);
    gr.query();

    if (!gr.next()) { gs.info('Issue not found'); return; }

    var profileId = gr.profile.toString();
    var issuePriority = parseInt(gr.priority.toString()) || 3;
    var issueDue = gr.due_date.toString();
    var tasks = [];

    // Analyze failing controls and generate tasks
    var ctrl = new GlideRecord('sn_compliance_control');
    ctrl.addQuery('profile', profileId);
    ctrl.addQuery('active', true);
    ctrl.addQuery('state', 'NOT IN', 'compliant,passed');
    ctrl.query();

    while (ctrl.next()) {
      var controlState = ctrl.state.getDisplayValue();
      var effectiveness = ctrl.effectiveness.getDisplayValue();
      var taskPriority = issuePriority;

      // Escalate priority for ineffective or failed controls
      if (controlState == 'Failed' || effectiveness == 'Ineffective') {
        taskPriority = Math.max(1, issuePriority - 1);
      }

      // Calculate due date based on priority
      var dueDate = new GlideDateTime();
      if (taskPriority == 1) dueDate.addDaysUTC(7);
      else if (taskPriority == 2) dueDate.addDaysUTC(14);
      else if (taskPriority == 3) dueDate.addDaysUTC(30);
      else dueDate.addDaysUTC(60);

      // Cap at issue due date if earlier
      if (issueDue && new GlideDateTime(issueDue).compareTo(dueDate) < 0) {
        dueDate = new GlideDateTime(issueDue);
      }

      var owner = ctrl.owner.getDisplayValue() || gr.assigned_to.getDisplayValue() || 'Unassigned';

      // Task 1: Remediate the control gap
      tasks.push({
        short_description: 'Remediate control gap: ' + ctrl.short_description.toString(),
        description: 'Address ' + controlState + ' control ' + ctrl.number.toString() +
          '. Control objective: ' + ctrl.control_objective.toString() +
          '. Last test result: ' + ctrl.test_result.getDisplayValue(),
        priority: taskPriority,
        suggested_owner: owner,
        due_date: dueDate.toString(),
        control_reference: ctrl.number.toString(),
        task_type: 'control_remediation'
      });

      // Task 2: Retest the control after remediation
      var retestDate = new GlideDateTime(dueDate.toString());
      retestDate.addDaysUTC(14);
      tasks.push({
        short_description: 'Retest control: ' + ctrl.number.toString(),
        description: 'Verify remediation effectiveness by retesting ' + ctrl.number.toString() +
          '. Document test evidence and update control state.',
        priority: taskPriority + 1 > 4 ? 4 : taskPriority + 1,
        suggested_owner: owner,
        due_date: retestDate.toString(),
        control_reference: ctrl.number.toString(),
        task_type: 'control_retest'
      });
    }

    // Analyze risks for additional mitigation tasks
    var risk = new GlideRecord('sn_grc_risk');
    risk.addQuery('profile', profileId);
    risk.addQuery('active', true);
    risk.addQuery('residual_risk', '>=', '50');
    risk.query();

    while (risk.next()) {
      var riskDue = new GlideDateTime();
      riskDue.addDaysUTC(issuePriority <= 2 ? 14 : 30);

      tasks.push({
        short_description: 'Implement risk mitigation: ' + risk.short_description.toString(),
        description: 'Reduce residual risk for ' + risk.number.toString() +
          '. Current residual risk: ' + risk.residual_risk.toString() +
          '. Treatment strategy: ' + risk.treatment.getDisplayValue(),
        priority: issuePriority,
        suggested_owner: risk.owner.getDisplayValue() || 'Unassigned',
        due_date: riskDue.toString(),
        risk_reference: risk.number.toString(),
        task_type: 'risk_mitigation'
      });
    }

    // Summary
    var summary = {
      issue: issueNumber,
      total_tasks_suggested: tasks.length,
      by_type: {
        control_remediation: tasks.filter(function(t) { return t.task_type == 'control_remediation'; }).length,
        control_retest: tasks.filter(function(t) { return t.task_type == 'control_retest'; }).length,
        risk_mitigation: tasks.filter(function(t) { return t.task_type == 'risk_mitigation'; }).length
      },
      tasks: tasks
    };

    gs.info('SUGGESTED REMEDIATION TASKS:\n' + JSON.stringify(summary, null, 2));
  description: "GRC: Generate remediation task suggestions for a specific issue"

ステップ 6：承認済みの是正タスクを作成する

レビュー後、承認されたタスクを ServiceNow に作成します。

MCP を使用：

Tool: SN-Create-Record
Parameters:
  table_name: sn_grc_remediation_task
  fields:
    short_description: "Remediate control gap: Inadequate access review process"
    description: "Address Failed control CTRL0001892..."
    priority: 2
    assigned_to: [owner_sys_id]
    due_date: "2026-04-15"
    issue: [issue_sys_id]
    state: open

REST API を使用：

POST /api/now/table/sn_grc_remediation_task
Content-Type: application/json
{
  "short_description": "Remediate control gap: Inadequate access review process",
  "description": "Address Failed control CTRL0001892...",
  "priority": "2",
  "assigned_to": "[owner_sys_id]",
  "due_date": "2026-04-15",
  "issue": "[issue_sys_id]",
  "state": "open"
}

ツールの使用

操作	MCP ツール	REST エンドポイント
イシューを読み取る	SN-Get-Record	GET /api/now/table/sn_grc_issue/{sys_id}
コントロールを照会する	SN-Query-Table	GET /api/now/table/sn_compliance_control
リスクを照会する	SN-Query-Table	GET /api/now/table/sn_grc_risk
提案を生成する	SN-Execute-Background-Script	POST /api/now/table/sys_trigger
タスクを作成する	SN-Create-Record	POST /api/now/table/sn_grc_remediation_task
スキーマを検出する	SN-Discover-Table-Schema	GET /api/now/table/sys_dictionary

ベストプラクティス

• 作成前に確認する： ServiceNow でタスクを作成する前に、提案されたタスクを必ず人が確認できるようにします
• フレームワークに準拠させる： 各タスクを、対応する具体的な規制要件またはコントロール目標に関連付けます
• 現実的な期限を設定する： 期日の算出時には、組織の対応能力と承認ワークフローを考慮します
• 担当者を明確にする： タスクの担当者にはコントロールオーナーを優先し、担当が不明確な場合はグループリーダーにエスカレーションします
• 証跡要件を含める： 完了時に添付が必要な証跡（スクリーンショット、ログ、証明書など）を指定します
• 関連タスクをまとめる： 一元的に追跡できるよう、関連タスクを単一の修正計画の下にグループ化します
• 有効性を追跡する： タスク完了後に、イシューのリスク評価が適切に改善したことを確認します

トラブルシューティング

修正タスクテーブルが見つからない

症状： sn_grc_remediation_task がエラーまたは空の結果を返す 原因： テーブル名は ServiceNow のバージョンによって異なる場合や、カスタムの拡張タスクテーブルが使用されている場合があります 解決策：

Tool: SN-Discover-Table-Schema
Parameters:
  table_name: sn_grc_issue

タスクタイプのテーブルを参照する参照フィールドを探します。sn_grc_task を確認するか、sys_db_object を照会して、ラベルに「remediation」を含むテーブルを検索します。

コントロールオーナーフィールドが空

症状： コントロールオーナーが登録されていないため、提案されたタスクに担当者がいない 原因： コントロールの所有者は、個々のコントロールではなく、コントロール目標のレベルで管理されている場合があります 解決策： sn_compliance_control_objective を照会し、親コントロール目標の owner フィールドを使用します。

期日が規制上の対応期間を超える

症状： 算出された期日が規制上の対応要件を超えている 原因： デフォルトの期限ロジックでは、フレームワーク固有の期間（例：PCI-DSS の90日間の修正期間）が考慮されない場合があります 解決策： スクリプトに規制固有の期限の上書きを追加します。sn_compliance_citation を照会して、該当する期間を取得します。

例

例1：SOX コンプライアンスイシューの修正

シナリオ： イシュー ISSUE0003456 により、財務報告における職務分掌違反が特定されました

1. イシューを取得：優先度1（重大）、リスク評価「高」、期限まで30日
2. 不備のあるコントロールを2件特定：CTRL0002100（アクセスレビュー）、CTRL0002101（承認ワークフロー）
3. リスクの背景情報を取得：関連する財務報告リスクの残余リスクスコアは82
4. 5件のタスクを生成：
   • ERP システムで役割を分離する（優先度1、7日、IT セキュリティリード）
   • アクセスレビュープロセスを更新する（優先度1、14日、コンプライアンスマネージャー）
   • 補完的な承認ワークフローを設定する（優先度2、14日、IT オペレーション）
   • 修正後に CTRL0002100 を再テストする（優先度2、28日、内部監査）
   • 修正後に CTRL0002101 を再テストする（優先度2、28日、内部監査）

例2：データプライバシーの不備の修正

シナリオ： イシュー ISSUE0004789 により、GDPR 第17条に基づくデータ保持コントロールの欠如が指摘されました

1. イシューを取得：優先度2（高）、データプライバシープロファイルに関連付け
2. 不備のあるコントロールを3件特定：データ分類、保持スケジュール、削除確認
3. 90日間の規制上の対応期間に合わせて6件のタスクを生成
4. 各タスクに GDPR の条項参照と必要な証跡資料を含める
5. タスクをデータ保護責任者と IT データ管理チームに割り当てる

関連スキル

• grc/issue-validator - 是正タスクを生成する前に、課題を検証します
• grc/issue-summarization - 是正が必要な課題を要約します
• grc/issue-action-plan - 個別のタスクを超えた、より広範なアクションプランを生成します
• grc/control-objective-management - タスクによって是正する管理策を管理します
• grc/risk-assessment-summarization - 優先順位付けのためにリスクの背景を評価します