セキュリティ組織図より先に決めるべき「業務範囲」の定め方 自社リスク起点の4ステップとその考え方

1.　セキュリティ組織の業務範囲は「全部やるではなく、何を担うか」が重要

第1回・第2回では、「セキュリティ対応組織の教科書」（以下、教科書）と「ITU-T勧告X.1060」の関係や成立の背景を取り上げました。第3回では、「CDC（Cyber Defence Centre）」³ という、組織でセキュリティサービスを提供する「主体」の考え方とともに、教科書が示す9カテゴリー・64サービスはセキュリティ対応組織が実施し得る活動を幅広く捉えたもので、抽象的な目標を具体的な業務へ落とし込むための設計図として機能することを説明しました。

カテゴリー・サービスの一覧を前にすると「どれも必要そうだ」と感じる一方で、実際の企業では、人員、予算、運用時間、社内の意思決定スピードなどの制約があります。そのため、64のサービスをそのまま並べるだけでは、実務の設計図としてはまだ抽象的です。

現場で本当に悩ましいのは、「実施すべき項目を全部やるべきか」よりも、「どこまでを自分たちの責務として持つか」です。たとえば、監視は外部委託していても、セキュリティインシデントとして正式に扱うかどうかや経営報告の判断は、自社で持つべきかもしれません。逆に、脅威情報の収集や高度分析は、自社で抱え込むより、外部サービスと連携したほうが現実的な場合もあります。

こうした違いは、単なる体制差ではなく、各社が重く見るリスクの違いといえます。そのリスクの軸をそろえることで、業務範囲を決めるための考え方を整理しやすくなります。内製／アウトソースの判断や成熟度評価の前提として、まず「自社は何を担うのか」を明確にしておくことが必要です。

2.　セキュリティ組織の業務範囲が会社ごとに異なる理由と各部門の傾向

2.1　経営層が見るリスク：事業停止と信用低下

経営層が最も気にするのは、それが事業にどのような影響を与えるかです。基幹業務が止まるのか、主要顧客への説明が必要になるのか、売上や取引継続に影響するのか、といった観点でリスクを見ます。

そのため、製造業や物流業のようにシステム停止が事業継続に直結する企業では、監視や初動対応、復旧連携がセキュリティ組織の中心業務になりやすくなります。一方で、顧客情報や機微情報を多く扱う企業では、漏えい防止や説明責任の整理のほうが、より重要になることがあります。

2.2　現場が見るリスク：運用負荷と判断速度

現場の担当者が直面するリスクは、より運用実務に近いものです。夜間や休日のアラートを誰が見るのか、端末隔離や通信遮断をどの時点で判断するのか、重大性の判定基準はどこにあるのか。こうした点が曖昧なままでは、セキュリティインシデント発生時に判断が遅れ、被害が拡大しやすくなります。

つまり、現場にとって重要なのは、組織の名前や箱の数よりも、「誰がどこで判断し、どこで引き継ぐか」が決まっていることです。組織図を整えるだけではなく、運用上の境界線を明確にする必要があります。

2.3　法務・管理部門が見るリスク：説明責任と統制

法務、総務、広報、監査といった部門が重く見るのは、説明責任や統制の観点です。どの時点でセキュリティインシデントと判断したのか、誰がどの情報をもとに経営へ報告したのか、対外説明や社内記録の整合性は保たれているか、といった点が重要になります。

このように、経営、現場、管理部門では重視するリスクの軸が異なります。したがって、セキュリティ組織の業務範囲も、単純に他社事例をまねるだけでは決められません。まずは各部門が見ているリスクを可視化し、自社では何をセキュリティ組織の主責務とするのかを定めることが出発点になります。

3.　自社に合った業務範囲を定めるための4つのステップ

ここでは、現場で使いやすいように、業務範囲を定める作業を4つのステップに整理して考えます。

表1　業務範囲を定めるための4つのステップ

ステップ	考えること	出力イメージ
1	止められない業務、守るべき情報、説明責任が重い領域を洗い出す	事業影響ベースの優先対象一覧
2	どの場面でセキュリティ組織が主導権を持つべきかを決める	主導すべき判断ポイントの整理
3	64サービスを主担当／共同担当／対象外に仮置きする	守備範囲の初期案
4	境界線、連絡経路、引き継ぎ条件を文章で残す	責任分界と連携ルール

3.1　ステップ1：守る対象ではなく、まず「止められない業務」を言語化する

セキュリティの議論は資産台帳やシステム一覧から始まりがちですが、業務範囲を決めるときは、まず「何を止められないか」を明確にするほうが実務には向いています。たとえば、短時間でも停止すると顧客影響が大きい業務は何か、外部への説明や報告が必要になりやすい情報は何か、社外攻撃よりも内部不正を強く警戒すべき領域はどこか、といった問いです。

これを整理すると、自社のリスクの軸が見えやすくなります。同じ「セキュリティインシデント対応」という言葉でも、ある企業では「止めないこと（事業継続）」が中心であり、別の企業では「漏らさないこと」や「説明できること」が中心になります。ここが曖昧なままでは、セキュリティ組織の業務範囲も曖昧になります。

3.2　ステップ2：セキュリティ組織が主導すべき場面を決める

次に考えるべきなのは、どの場面でセキュリティ組織が主導権を持つべきかです。典型的には、監視アラートの一次判断、セキュリティインシデントとして正式に扱うかどうかの判断、初動対応の指示、経営層への報告とりまとめ、法務・広報との連携開始判断、再発防止策のとりまとめなどが候補になります。

24時間監視や一部の分析作業は外部委託しやすい一方で、事業影響の判断、経営報告、対外説明の起点になる判断などは、自社側に残したほうがよい場合が多いでしょう。重要なのは、「何を委託するか」より前に、「どの判断を自社が持つか」を決めることです。

3.3　ステップ3：64のサービスを「主担当」「共同担当」「対象外」に分ける

第2回で見た64のサービスは、業務範囲を決めるための道具として使うことができます。

まずは、各サービスを以下の3つの区分に仮置きし、その内容で定義を進め、関係部門や経営層と合意形成し確定させると整理がしやすくなります。

表2　64サービスを整理する際の基本区分

区分	意味	例
主担当	セキュリティ組織が中心となって運営し、最終判断にも責任を持つ	トリアージ基準管理（A-9）、インシデント報告受付（D-1）、幹部向けセキュリティ報告（I-7）
共同担当	他部門や委託先と役割分担しながら実施する	リアルタイム監視（B-1）、インシデント対応・封じ込め（D-4）、対外説明準備
対象外	現時点では自組織の守備範囲に置かない、または別組織が主に担う	高度分析の一部、専門診断の一部、個別システム保守運用

ここで重要なのは、「対象外」を恐れないことです。すべてを自組織で持たないからといって、不十分とは限りません。むしろ、今は持たないものを明示することで、それが未整備なのか、意図的に別組織や外部へ置いているのかを区別できます。この区別ができると、将来の見直しもしやすくなります。

3.4　ステップ4：組織図ではなく、境界線と連携先を文章で残す

分類結果をもとに組織の箱を作るだけで終わらせないことも重要です。実務では、「情報システム部」「CSIRT」「SOCベンダー」といった名称よりも、どの条件で誰に引き継ぐのかという役割と行動の境界線のほうが重要になるからです。

たとえば、重大アラートの報告基準、休日・夜間の連絡先と判断代行者、端末隔離や通信遮断の実施条件、法務・広報へ連携するトリガー、経営層報告が必要となる閾値（しきい値）などは、短い文章でもよいので明文化しておく価値があります。組織図の箱を増やしても、この境界線が定義されていなければ、運用の実効性は上がりにくいでしょう。

4.　実践シナリオ：リスクの重み付け別のセキュリティ組織設計例

ここでは、業務範囲の決め方をイメージしやすくするために、リスクの重み付けの異なる3つの典型例を見てみます。重要なのは「正解例」を示すことではなく、同じ教科書を参照しても、重視するリスクによって設計が変わることです。

4.1　可用性を重視する企業

工場、物流、オンラインサービスなど、業務停止の影響が大きい企業では、検知から初動、復旧連携までの速さが重要になります。この場合、監視ルールの整備、アラートの優先度を決めるトリアージ、セキュリティインシデントとして正式に扱うかどうかの判断、システム部門や事業部との連携調整などが、セキュリティ組織の主担当に入りやすくなります。

法務や広報との連携も必要ですが、業務範囲の中心はまず「止めないこと」と「早く戻すこと」です。そのため、可用性の高い運用設計やエスカレーションの速度が重視される傾向にあります。

4.2　機密性・知財保護を重視する企業

研究開発型の企業や、顧客データ・設計情報などを多く扱う企業では、漏えいや内部不正の抑止・検知のウェイトが相対的に重くなります。この場合、アクセス権限の見直し、ログの相関分析、内部不正の兆候検知、証跡保全、調査手順の整備などが主担当に入りやすくなります。

また、人事、法務、監査との共同担当領域も広がりやすく、単なるSOC機能だけでは足りないことが見えてきます。誰が事実確認を主導し、誰が証拠保全を担い、誰が関係者対応を行うのかといった分界が重要になります。

4.3　規制対応や説明責任が重い企業

金融、通信、社会インフラなど、事故発生時の説明責任が重い企業では、セキュリティインシデント判断基準、記録の一貫性、経営報告、社外説明の標準化・一元化が大きなテーマになります。この場合、監視そのものよりも、「どの事象を重大とみなすか」「どの時点でどこへ報告するか」「事実確認をどうそろえるか」といった統制機能が、セキュリティ組織の重要業務になります。

このように、同じ64のサービスを見ても、どの範囲の業務を厚く持つかは企業によって変わります。だからこそ、「教科書どおりに全部そろえる」よりも、「自社のセキュリティ組織では何を主担当とするか」を先に決めるほうが、現実的で継続しやすい設計になります。

5.　ツール導入の前に実施すべき「社内連携」「信頼関係」の構築

セキュリティ体制の議論になると、どうしてもSIEM（Security Information and Event Management）、EDR（Endpoint Detection and Response）、SOAR（Security Orchestration, Automation and Response）といったツールの話に意識が向きがちです。もちろんツールは重要ですが、ツールを導入しただけで、組織の判断力や連携力まで自動的に整うわけではありません。

たとえば、アラートが上がっても事業部側のシステム担当にすぐ連絡がつかない、法務に相談すべきタイミングが分からない、広報と使う言葉がそろっていない、といった状況では、どれだけ高機能なセキュリティ製品があっても運用品質は上がりにくくなります。解決策の一例として、下記などが考えられます。

社内連携や人間関係は、ツール導入の補助的な要素ではなく、むしろ運用そのものの一部です。特に、ツールを増やす前の段階で、誰が何を判断し、どの言葉で話し、どこへつなぐのかを整えておくと、その後の製品選定や外部委託の議論も進めやすくなります。

6.　各部門における「主担当・共同担当・対象外」の考え方の活用方法

この「主担当・共同担当・対象外」で考える方法は、セキュリティ部門だけのためのものではありません。各部門がそれぞれの立場から使うことで、組織全体の設計が進めやすくなります。

6.1　IT・情報システム部門

IT・情報システム部門にとっては、何を自部署が持ち、何をセキュリティ組織へ寄せ、何を外部へ委ねるのかを整理する材料になります。曖昧なまま運用負荷だけを抱え込む状況を避けやすくなります。

6.2　セキュリティ組織

セキュリティ組織にとっては、自分たちの責任範囲と、他部門へエスカレーションすべき境界を明確にできます。これにより、セキュリティ運用における対応手順・判断基準、報告フローも設計しやすくなります。

6.3　法務・管理部門

法務や管理部門にとっては、どの段階で関与するのか、何を事前に取り決めておくべきかが見えやすくなります。結果として、説明責任や記録整備の質も上げやすくなります。

6.4　経営層

経営層にとっては、「何が足りないのか」を組織名ではなく責務で理解しやすくなります。人員や予算の議論も、「SOCが必要かどうか」ではなく、「どの責務をどこまで自社で持つか」という形で進めたほうが、意思決定しやすくなるでしょう。

7.　正解の組織図より、納得できる責務分界を

第4回では、自社に合ったセキュリティ組織の業務範囲をどのように定めるかを、「リスクの軸」という観点から整理しました。ポイントは以下の3つです。

組織作りでは、つい「何を導入するか」「どのような名前の組織を置くか」に目が向きがちです。しかし、実務で先に決めるべきなのは、守るべき事業は何か、そしてそれに対して誰が何を引き受けるのかという責務の置き方です。その意味で、セキュリティ組織の設計とは、単なる体制図の作成ではなく、リスクと責任の分界を定義する作業といえます。

次回は、今回定めた業務範囲を前提に、社内外のリソースをどう割り当てるか、成熟度をどう捉えるか、そして実施すべきサービスの優先度をどう考えるかを扱う予定です。

---