| ServiceNow IRMではじめる監査DX（第1回） 内部監査はこう変わる |
| ServiceNow IRMではじめる監査DX（第2回） 監査を支えるすべての情報をつなぐ（本記事） |
| ServiceNow IRMではじめる監査DX（第3回） AIは監査人の最強のパートナーになる |
| ServiceNow IRMではじめる監査DX（第4回） AIエージェントが監査を自律実行する |
| ServiceNow IRMではじめる監査DX（第5回） 人は判断へ――Agentic Workflowが描く監査の未来 |
01. IRMを支えるデータ基盤 ― ISMS(ISO/IEC 27001)監査を例に
IRMの価値は、個々の機能ではなく「一貫したデータのつながり」にあります。抽象的な規制要求から、目の前にある一台のPCまでが、一本の鎖でつながっている ― これがIRMのデータ基盤です。
ここでは、多くの企業が実際に運用している ISO/IEC 27001 のISMSを題材にします。取り上げるのは、Annex A 7.10（記憶媒体の管理）に関連する、「USBメモリ経由の情報漏洩をどう防ぐか」という、どの組織にもある統制です。
この一つの統制を、IRMは次のようにデータへと分解します。
| ISO 27001 / ISMS上の概念 | IRMのデータオブジェクト | 役割 |
| 準拠すべき規格そのもの（ISO/IEC 27001） | Authority Document | 「何に従うか」という出典 |
| 規格内の具体条項（Annex A 7.10） | Citation | 出典の中の該当箇所 |
| 社内規程（情報セキュリティ管理規程） | Policy | 規制を自社の言葉に落とした方針 |
| 統制目標（リムーバブルデバイスによる持ち出しを制限する） | Control Objective | 「達成すべき状態」（※1） |
| 具体的な統制（PC端末にデバイス管理を適用しUSBを使用不可にする） | Control | 「実際に講じる対策」（※1） |
| 実施状況の申告（「USBを使用不可にする制限は入っていますか？」） | Attestation | 統制の実施状況の自己申告 |
| 対象資産（OA用PC / PC1234567） | Entity（Entity Type / Entity） | 統制が適用される「現物」 |
ポイントは、規格という抽象的な要求が、Authority Document → Citation → Policy → Control Objective と段階を追って具体化され、最終的に「一台のPCで何をするか」という実行レベル（ControlとEntity）まで一本につながっていることです。監査業務でいえば、監査計画の根拠（規程）から、実際にテストする統制（Control）までが、初めから紐づいた状態で管理されるということです。
データ基盤の要：統制を「現物」に結びつける
ここで最も重要なのは、Controlが「紙の上の決まりごと」で終わらず、CMDB上に実在する資産（Entity）に結びついている点です。図の中央にある Entity Framework が、「OA用PC」という管理対象種別（Entity Type）と「PC1234567」という実際の管理対象（Entity）を、CMDBの構成アイテムと紐づけています。
この一手間があることで、統制は「どの資産で、実際に効いているのか」を追跡できる対象へと変わります。そして次章で述べるとおり、この共有された資産情報こそが、複数のモジュールを一つに束ねる土台になります。
※1：Control Objective と Control の関係(IRM導入担当者向けの補足)
表では Control Objective を「達成すべき状態」、Control を「実際に講じる対策」として区別して示しました。
これは業務上の理解としては正しいのですが、IRMのデータ設定という観点では、両者はしばしば実質的に同じデータ内容になるケースが多いです。導入時に混乱しやすい点なので、補足しておきます。
データ構造上、両者の役割は次のように整理できます。
- Control Objective は、Control を生成するためのテンプレート(ひな型)のような役割
- Control は、そのひな型を「特定の資産に適用した」実体のような役割
そのため実際の設定では、Control Objective だけを登録し、IRMの標準機能でその内容に沿って Control を自動生成する——という進め方が一般的です。一つひとつの資産(Entity)について手作業で Control を作るわけではありません。
これは図の Entity Framework の魅力の一つでもあります。組織内の管理対象(例えば、PCやサーバーなどのIT資産)が増えても、その対象に紐づく統制データが自動的に生成できるため、組織全体の運用コストを抑えられます。第2章で述べる「同じ統制・同じ資産を全モジュールで共有する」という統合の価値も、この自動生成の仕組みに支えられています。
詳細は、ServiceNow の研修「GRC: Integrated Risk Management (IRM) Implementation」をご確認ください。
GRC: Integrated Risk Management (IRM) Implementation
02. モジュールはどう繋がるのか ― 統合リスク管理の価値
前章で作った「規制 → 方針 → 統制 → 資産」という基盤は、Policy and Compliance だけのものではありません。同じControl、同じEntityを、他のモジュールがそれぞれの視点で共有・再利用します。これが「統合（Integrated）」リスク管理と、部門ごとにバラバラな「サイロ型」管理との決定的な違いです。
同じ「USB禁止」という一つの統制を、3つの視点から見てみましょう。
| 視点 | ServiceNow IRMモジュール | 問い | 主なデータオブジェクト |
| 何をすべきか | Policy and Compliance | 規制上、どのような統制が求められるか？ | Policy / Control Objective / Control / Attestation |
| 実施しないと何が起きるか | Risk Management / Advanced Risk | この統制が破られた場合、どの程度の影響があるか？ | Risk Statement / Risk / Risk Assessment |
| 本当に実施できているか | Audit Management | 申告どおりに統制が機能しているか、独立した立場で確かめる | Audit Task / Issue / Remediation Tasks |
Policy and Compliance ―「何をすべきか」を定義する
これは第1章で見た通りです。規制を起点に、Policy から Control Objective、Control へと要求を具体化し、「あるべき姿」を定義します。統合リスク管理では、この Control が出発点であり、共通言語になります。
Risk Management / Advanced Risk ―「実施しないと何が起きるか」を評価する
同じ Control Objective を、リスクの視点から見ると景色が変わります。「リムーバブルデバイスによる持ち出しを制限する」という目標は、裏を返せば「制限できなければ、リムーバブルデバイスを介した情報漏洩が起きる」というリスクそのものです。
図の左側にある Risk Statement → Risk → Risk Assessment の連鎖は、まさにこの「実施しないと何が起きるか」を管理する系列です。そして図中の点線が示すとおり、Risk Statement は Control Objective と、Risk は Control と相互に参照し合っています。つまり、方針側とリスク側が別々の台帳ではなく、同じ統制を両面から見ているのです。
Advanced Risk は、この評価をさらに一歩進めます。過去のAttestation結果やIssueの発生頻度といったデータをもとに、リスクを定量的に評価・優先順位付けし、「どのリスクに先に予算と人を割くべきか」という経営判断の材料を提供します。
| リスク管理上の概念 | IRMのデータオブジェクト | 役割 |
| リスクの記述（統制目標が達成されないと何が起きるか） | Risk Statement | 統制目標の裏返し。「持ち出しを制限できなければ情報漏洩が起きる」というリスクの汎用的な言明（Control Objective と相互参照） |
| 個別のリスク事象（当該資産で顕在化しうる情報漏洩） | Risk | 対象に紐づく具体的なリスク。「OA用PCからのUSB経由の情報漏洩」（Control と相互参照） |
| リスクアセスメント（発生可能性 × 影響度の評価） | Risk Assessment |
そのリスクの大小・優先度を評価した結果。リスク対応・監査計画の優先順位付けの判断材料になる |
Audit Management ―「本当に実施できているか」を独立して検証する
ここで、監査ならではの視点が加わります。図の右にある Attestation は、「USBを使用不可にする制限は入っていますか？（Y/N）」という自己申告です。統制の担当部門が「できています」と回答する ― これは第1・第2ラインの活動です。
しかし、監査（第3ライン）の役割は、その申告を鵜呑みにしないことにあります。Audit Management では、同じ Control を監査対象として取り上げ、Audit Task（監査人が実施する独立テスト）によって「申告どおりに、本当にUSBが無効化されているか」を自ら確かめます。差異が見つかれば Issue として記録し、Remediation Tasks で是正を追跡します。
Attestation（自己申告）と Audit Task（独立検証）が別々のデータとして併存すること ― これこそが監査の独立性を担保する仕組みです。両者を混同し、自己申告だけで済ませてしまうと、3ラインが機能しなくなります（この点は次章の「落とし穴」でも改めて触れます）。
「統合」の価値：一つの基盤を、全員が同じ目で見る
重要なのは、Policy and Compliance、Risk Management、Advanced Risk、Audit Management が、それぞれ別々のデータを抱えているのではないということです。全モジュールが、同じ Control・同じ Entity を参照しています。
この価値がはっきり出る例の一つが、規格が改訂されたときです。たとえば ISO/IEC 27001 が2013年版から2022年版へ改訂され、Annex A の管理策が再編されたとしましょう。従来のサイロ型管理であれば、コンプライアンス部門が規程を直し、リスク部門がリスク台帳を見直し、監査部門が監査チェックリストを差し替える ― という作業を、それぞれの Excel の上でバラバラに、かつ整合を取りながら進めなければなりません。どこか一つが古いまま取り残されても、誰も気づけません。
統合された IRM では、この見直しが「追跡可能」になります。改訂に合わせて Authority Document と Citation（Annex A 7.10 に相当する条項）を更新すると、その Citation に紐づく Policy、Control Objective、Control を、リレーションをたどって特定できます。さらに Control と相互参照している Risk 側の評価前提も、「どのリスク評価が、この統制の変更の影響を受けるか」を洗い出せます。監査を担う Audit Management は、こうして最新化された統制を検証対象にできます。
サイロ型管理との違いは、この「影響範囲の見える化」にあります。Excel がバラバラに存在する環境では、規格改訂の影響がどこまで及ぶかは担当者の記憶と手作業の突き合わせに頼るしかなく、見落としが起きます。統合された IRM では、一つの Citation の変更が、どの Policy・Control・Risk・監査項目につながっているかをデータのリレーションとしてたどれる ― だからこそ、見直しの網羅性が担保されるのです。
一つの事実を、方針・リスク・監査という異なる立場から同時に見る ― これが、ツールを寄せ集めただけでは得られない統合リスク管理の本質的な価値です。
03. IRM導入時の落とし穴と回避策
もっとも、統合の価値は自動的に手に入るわけではありません。ここでは実装の各フェーズに沿って、つまずきやすい点と回避策を整理します。前半（3-1〜3-3）は監査が始まる前の準備フェーズ、後半（3-4〜3-5）は監査を実際に回すフェーズです。監査実務の流れ（現状整理 → 初期設定 → 監査計画 → 監査実施 → 報告・是正）に沿って読み進めてください。
3-1. 監査業務整理フェーズ
システム化の前に、まず「いまの監査業務が何をしているか」を言語化する段階です。ここを飛ばすと、暗黙知がシステムに乗らず、ツールだけが導入されて誰も使えない、という事態を招きます。
| 落とし穴 | 回避策 |
| 既存の監査手法が文書化されておらず、ベテランの経験の中にしかない | 導入前に「監査プロセスの棚卸し」を行い、暗黙知を標準チェックリスト／テンプレートとして可視化してから、システム化を検討する |
| 監査対象（Entity）の粒度に社内の共通認識がない（部門か、システムか、業務プロセスか） | 設定作業の前に、監査部門とIT／業務部門で「監査対象の分類基準」を書面で合意し、それをEntity Frameworkの設計に落とす |
| 監査部門内の流れだけを整理し、被監査側の協働のしかたを見落とす | 現状整理の段階で被監査部門（最低1〜2部門）にヒアリングし、Attestation回答者やIssue是正責任者など、部門をまたぐ役割の実態を先に把握する |
3-2. IRM初期設定フェーズ
棚卸しした業務を、ServiceNow上の土台として組み上げる段階です。ここも監査が始まる前に完了しておくべき準備で、特にデータ品質と権限設計は、後のすべての監査の信頼性を左右します。
| 落とし穴 | 回避策 |
| CMDBのデータ品質を過小評価する（IRMの土台なのにIT側の課題として後回しにされる） | CMDBのデータ整備を、並行作業ではなくIRMプロジェクトの前提マイルストーンとして位置づけ、完全性・正確性の受入基準を満たすまで次工程に進めない |
| 権限・ロール設計をテンプレートのまま流用し、監査独立性を損なう | ロール設計はIT部門だけではなく監査部門と協働し、「監査人・被監査側・経営層」の権限境界を明示。監査人が自らの監査対象のControlを変更できない等、独立性要件を一つずつ検証する。 |
3-3. 監査計画フェーズ
「何を、どの単位で監査するか」を設計する段階です。Engagement（監査案件）は組織軸（部門・拠点）、プロセス軸（購買・販売・IT運用など）、テーマ軸（情報セキュリティ、J-SOX など横断テーマ）のどの切り口でも組めますが、切り方によって被監査対象とControlの紐づき方が変わります。同じControlが複数のEngagementに現れることもあるため、切り口をあらかじめ定めておくことが要になります。
| 落とし穴 | 回避策 |
| 計画立案にRisk Assessmentの最新結果が反映されず、「例年どおり」の網羅になる | 監査計画の立案プロセスで、Risk Managementの最新のリスク評価・順位を必須の入力として引用させ、リスクベースの計画に転換する |
| 監査テーマ（切り口）が定まらないままEngagementを量産し、対象の重複や抜けが生じる | まず監査計画の切り口（組織／プロセス／テーマ軸）を年度方針として決め、それに沿ってEngagementの単位を統一する。同じControlが複数のEngagementに現れる場合は、統合基盤上で重複検証を可視化する |
| Engagementの粒度が不適切で、進捗・責任の追跡が甘くなる | 過去1〜2年の実績工数から「標準的なEngagement工数の範囲」を基準として設定し、それに沿ってControlの範囲を分割・統合する |
3-4. 監査実施フェーズ
計画に沿って、実際に統制をテストする段階です。ここでは監査の独立性と証拠の質が問われます。
| 落とし穴 | 回避策 |
| Attestation（自己申告）に依存し、独立テストを軽視する | 明確なサンプリング方針（高リスクControlは全件独立テスト、中低リスクは比率抽出等）を定め、Audit TaskをAttestationとは別データとして必ず記録させ、両者を代替させない(※2) |
| 証拠（Evidence）の保管方法が標準化されておらず、監査調書の追跡性が損なわれる | 証拠の保管規約（命名規則・必須添付種別・保存期間）を定め、Issue／Findingをクローズする際の前提チェック項目とする（事後の補完で済ませない） |
※2 補足：ServiceNowはサンプリングを「決めない」
サンプリング方針そのものを自動で決める機能は、ServiceNowに存在しません。サンプリングは監査人の職業的判断と監査基準・内部方法論に基づくものであり、ツールが決めるものではないからです。
ServiceNowが提供するのは「判断を支える情報」と「決めた方針を繰り返し運用に乗せる仕組み」です。
具体的には、監査部門が定めたサンプリング方針を Risk Assessment の結果（高・中・低）と結びつけ、高リスクControlには全件、中低リスクには抽出サンプルのAudit Taskを生成する ― という設計を Audit Task の生成テンプレートに仕込みます。Advanced Riskのリスクスコアを使えば「なぜこのControlを全件テストするのか」を定量的に説明できます。人がリスク評価を入力に範囲を設計し、それを繰り返し使える形にする ― これがServiceNow流のサンプリング運用です。
3-5. 報告・是正フェーズ
検出事項を報告し、是正を追跡する段階です。ここでの落とし穴は、ほとんどが「更新の遅れ」と「システム外への転記」に集約されます。
| 落とし穴 | 回避策 |
| 監査検出事項の状態更新が遅れ、システム上の進捗と実態が乖離する | 一定日数を超えて未更新のIssueを自動でエスカレーションする仕組みを設け、「是正進捗の更新遅延率」自体を関係部門（監査部門・非監査部門）のKPIの一つとする |
| 報告が依然としてExcel／PowerPointに頼り、システムデータが「二次転記」される | システムのダッシュボードから経営報告へ直接連携する仕組みを優先的に整備。当面は「主要指標は自動取得、記述部分は人手」といった部分的自動化からでも、人手による転記の比率を段階的に減らす |
落とし穴の先にあるもの ― 次回への接続
ここまで見てきた落とし穴を並べると、ある共通点が浮かび上がります。その多くが「人手に依存するがゆえに、抜け・遅れ・属人化が起きる」という構造を持っていることです。
暗黙知が文書化されない、証拠の整理が標準化されない、Issueの更新が遅れる、報告のたびに手で転記する ― いずれも、人が手で担っている工程だからこそ生じる痛みです。そして、まさにこの「人手依存の工程」こそ、次回以降で扱うAIが最も効く領域です。
本章で整理した「準備で押さえるべき土台」は、AIを載せるための地盤でもあります。データ基盤が整い、監査の独立性が設計され、リスクベースの計画が回っている ― その上ではじめて、AIは信頼できるパートナーになれるのです。
第2回のまとめ
- データ基盤。規制（ISO 27001）から社内規程、統制、そして実在する資産（手元にあるPC）までが一本の鎖でつながる
- モジュール連携。その同じ統制・同じ資産を、Compliance・Risk・Auditが異なる視点で共有する。ここに「統合」の価値がある
- 落とし穴。価値は自動では手に入らない。各フェーズで「業務の合意」「データ品質」「監査独立性」を先に押さえることが要になる
次回予告 ・ 第3回
AIは監査人の最強のパートナーになる
次回は、本記事で整えた基盤の上に AI を載せます。ServiceNow AI機能が証跡の読み込み・所見のドラフト・分析をどう支援し、監査人が本来集中すべき「判断」に時間を割けるようになるのか——具体的に見ていきます。
