どうも おかしん です。
今日は、情シスや情報セキュリティの人が、経営とどう対話し、リスクと効果を判断材料にするために、事業の何を見るべきなのかという話をします。
前回の記事では、AIに個人情報を入れてはいけない、で思考停止していないかというテーマで、AI、SaaS、クラウドを含む外部サービスの利用は、効果とリスクを天秤にかけて経営が判断するべきものだと書きました。
では、その経営判断に必要な材料を、誰がどう作るのか。
ここが今回のテーマです。
この話は、情シスやセキュリティが「危ない」と言っているのに経営に届かず、結果として無視されてしまうケースだけを扱うものではありません。
逆に、現場や事業部門が「入れたい」「使いたい」と思っているAIやSaaSが、リスクを理由に止まり続けてしまうケースもあります。そこでは、メリット側の説明が経営判断の材料になっていないことがあります。
情シスやセキュリティの説明が経営に届かないとき、経営側の理解不足だけが原因とは限りません。もちろん、経営がITやセキュリティに十分な関心を持っていないこともあるでしょう。そこは確かに問題です。
ただ、こちら側が事業の文脈を理解しないまま、リスクだけ、あるいはメリットだけを語っていることもあるのではないでしょうか。
「このAIサービスは危ないです」
「このSaaSはリスクがあります」
「このクラウド構成は推奨できません」
「このツールを入れれば便利です」
「生産性が上がるので使わせてください」
これらは、技術的には正しい指摘かもしれません。
でも経営からすると、そこで聞きたいのは「では、事業として何を取り、何を受け入れ、どう判断すればいいのか」です。
この記事では、公的な分類そのものではなく、NIST、IPA、重要インフラ関連の考え方などを参考にしながら、私なりに、情シス・情報セキュリティが経営に判断材料を出すための見方を整理します。
なお、この記事は個別の法令適合性や、特定サービスの利用可否を判断するものではありません。あくまで、経営に判断材料を出すための考え方の整理です。
リスク説明も導入メリットも、なぜ経営に届かないのか
情シスや情報セキュリティの仕事をしていると、リスクを説明しているのに、経営や事業部門にうまく伝わらないことがあります。
一方で、事業部門や現場が導入メリットを説明しているのに、情シス・セキュリティ側の懸念と噛み合わず、経営が判断できる形にならないこともあります。
「それは分かったけど、結局やっていいの？」
「それを止めると、事業側はどれくらい困るの？」
「どこまで対策すれば使えるようになるの？」
「競合がやっているのに、うちはなぜできないの？」
こういう反応を受けたことがある人は多いのではないでしょうか。
ここで大事なのは、経営はセキュリティリスクだけを見て意思決定しているわけではない、ということです。
売上を伸ばす必要がある。コストを下げる必要がある。人手不足を補う必要がある。顧客体験を良くする必要がある。サービスを止めない必要がある。規制や監査に耐える必要がある。限られた予算と人員の中で、どこに投資するかを決める必要がある。
その中の一つとして、セキュリティリスクがあります。
だから、情シスやセキュリティが「危ないです」とだけ言っても、経営判断の材料としては足りません。事業部門が「便利です」「成果が出ます」とだけ言っても、同じように足りません。
本当に必要なのは、「どの効果を取りに行くと、どのリスクが増えるのか」「どの統制を入れると、どこまでリスクを下げられるのか」「残るリスクは何か」「使わない場合のリスクは何か」を、事業の言葉に翻訳することです。
NIST IR 8286 Rev.1は、サイバーセキュリティリスクを企業全体のERM、つまりエンタープライズリスクマネジメントに接続する考え方を示しています。サイバーリスクは、情報システム部門の中だけで閉じるものではなく、事業目的やリスク選好と結びつけて扱うべきものです。
これは、情シスやセキュリティにとってかなり重要な示唆だと思っています。
技術的に正しいリスク説明や、現場にとって明らかな導入メリットを、経営に届く判断材料へ変えることは、似ているようで違います。
取りに行く効果と受け入れるリスクは、事業によって違う
同じAI利用、同じSaaS利用、同じクラウド利用でも、どの効果を取りに行き、どこまでリスクを受け入れるべきかは会社や業務によって変わります。
営利企業でも非営利組織でも同じです。ITツールは、何らかの事業や活動をより良くするために使います。売上を伸ばす、支援を広げる、業務を効率化する、社会に必要なサービスを安定して届ける。目的は違っても、何かを良くするためにITを使うという点は変わりません。
ただし、何を重視するかは大きく違います。
たとえば、新規事業やプロダクト開発、営業、マーケティングのような領域では、早く試し、学び、改善することが重要です。AIやSaaSを使えないことで、競合よりも学習速度が落ちるなら、それ自体が事業リスクになります。
一方で、医療、インフラ、公共性の高いサービス、24時間止められない業務では、便利になることよりも、継続して提供できることや、事故時に復旧できることの比重が大きくなります。
金融や個人データを大量に扱う業務、監査対象になる業務では、説明責任や証跡、委託先管理、規制対応が事業価値に直結します。ここでは「便利だから使う」だけでは足りません。
さらに、同じ業種でも、売上規模、従業員数、専門人材の有無、IT依存度、財務余力によって、現実的に取れる対策は変わります。
IPAの情報セキュリティ対策ベンチマークでも、従業員数、売上高、重要情報の保有数、IT依存度などを踏まえて組織の状況を把握する考え方が示されています。これは、「業種だけでリスクを語ってはいけない」という意味でも参考になります。
つまり、利用判断は業種名だけでは決まりません。
その会社が何を伸ばしたいのか。何を止めてはいけないのか。何を失うと信用を失うのか。どれくらいの運用余力があるのか。
そこまで見ないと、経営に届く判断材料にはなりません。
情シス・セキュリティは事業を理解してリスクを翻訳する
情シスやセキュリティの役割は、リスクをゼロにすることではありません。メリットだけを押し通すことでもありません。
事業が得たい効果を理解し、その効果を取りに行くために、どのリスクをどこまで下げるべきかを整理することです。
ここを誤ると、セキュリティ説明は事業から浮きます。
たとえば、あるAIツールについて「入力データが外部サービスに送信されます」と説明するだけでは、経営判断にはなりません。
それが、社内公開済みのナレッジを要約する用途なのか、未公開のM&A情報を扱う用途なのか、医療情報を扱う用途なのか、営業資料のドラフトを作る用途なのかで、意味はまったく違います。
同じ「外部サービスに送信される」でも、対象業務、対象データ、利用目的、契約条件、保持期間、監査ログ、権限管理、人間レビューの有無によって、判断は変わります。
NIST SP 800-39は、情報セキュリティリスクを、組織、ミッション・業務プロセス、情報システムの層で見る考え方を示しています。これは実務的にもかなり大事です。
情報システム層だけを見れば、「このシステムにはリスクがあります」で終わります。
しかし、ミッションや業務プロセスの層で見ると、「この業務を速くするために必要な機能なのか」「止まると誰に影響するのか」「誤るとどの程度の損失や信用毀損が起きるのか」という問いになります。
組織の層で見ると、「そのリスクは会社として受け入れられるのか」「リスクを取らないことで、どの事業機会を失うのか」という問いになります。
経営に届く判断材料とは、この層を行き来して作るものだと思います。
判断材料を作るための4つの軸
私なら、情シス・セキュリティが経営に判断材料を出すとき、少なくとも次の4つの軸で整理します。
1つ目は、事業目的です。
その取り組みで何を得たいのか。売上を伸ばしたいのか、業務効率を上げたいのか、サービスを安定提供したいのか、信用を守りたいのか。市場競争上、今やらないことがどれくらいリスクになるのかも含めて見ます。
2つ目は、事業影響です。
その業務が止まったら誰に影響するのか。情報が漏えいしたら、誰が困るのか。データが改ざんされたら、どの意思決定が壊れるのか。AIやシステムが誤った判断をしたとき、人命、財産、契約、信用、売上にどの程度影響するのか。
NIST IR 8286Dでは、BIA、つまりビジネスインパクト分析を使ってリスクの優先順位付けを考えることが示されています。BIAは可用性要求だけに閉じず、事業目的に対する損失影響を広く見るためにも使えます。機密性や完全性の観点も、事業影響として整理する対象になります。
3つ目は、外部要求です。
法令、業界ガイドライン、重要インフラとしての要求、取引先からの要求、監査、顧客契約、プライバシー対応などです。ここは事業によってかなり差が出ます。
たとえば、NCOの重要インフラ対策関連資料では、国民生活や社会経済活動に影響する重要インフラの継続的提供が重視されています。このような領域では、一般的な業務効率化とは違う重み付けが必要です。
4つ目は、組織余力です。
どれだけの人員、予算、専門性、運用能力があるのか。理想的な管理策を並べても、運用できなければ意味がありません。逆に、専任情シスがいない組織だからこそ、標準化されたSaaSやマネージドサービスを使った方が安全に運用できることもあります。
この4つの軸を見ずに、「AIだから危ない」「SaaSだから危ない」「クラウドだから危ない」と言っても、経営判断の材料としては弱いです。
4つの事業・業務パターンで考える
ここまでの4つの軸は、判断材料を作るための観察項目です。ここからの4つのパターンは、その観察結果を経営と話しやすくするための見立てです。
ここからは、実務で考えやすいように、ざっくり4つのパターンに分けます。
これは公的な分類そのものではありません。NISTやIPAなどを参考にしつつ、NIST SP 800-39 が示す、組織、ミッション・業務プロセス、情報システムの層を行き来してリスクを見る考え方を、この記事向けに実務の言葉へ落とした私なりの整理です。ここで挙げる事業例も、一次情報に載っている分類表ではなく、経営と話すための便宜的な当てはめです。
また、会社全体を一つのパターンに押し込むものでもありません。同じ会社の中でも、新規事業は成長探索型、経理は業務効率・標準化型、基幹システムは安定供給型、個人データ処理は規制・信用重視型になることがあります。
業務単位、ユースケース単位で見ることが大切です。
一方で、全社のセキュリティ基準を考えるときは、重い事業やデータにかかる外部要求を無視できない場面があります。
たとえば、金融分野では金融庁のサイバーセキュリティ関連資料が経営陣の関与を求めています。重要インフラではNCOの重要インフラ対策関連資料が継続的提供を重視しています。個人情報を扱う場合は、個人情報保護委員会のデータガバナンスに関する情報にあるように、責任部署、データマッピング、PIAなどの観点が必要になります。
金融事業、医療データ、重要インフラ、大企業向けSaaSとして預かる顧客の機密情報などがある場合、全社共通の最低ラインも、こうした重い要求を踏まえて設計する必要があります。監査、契約、事故時の説明責任に耐える必要があるからです。
ただし、全社の最低ラインを重い事業に合わせることと、すべての業務を同じ重さの承認フローに乗せることは別です。NIST IR 8286D がBIAをリスク優先順位に使う考え方を示しているように、何がどの事業に影響するのかを分けて見る必要があります。
全社共通の土台として、SSO、MFA、端末管理、ログ、データ分類、契約確認などは重い要求に合わせる。そのうえで、公開情報だけを使う検証、社内限定データを使う業務効率化、顧客データや規制対象データを扱う処理では、使えるツール、承認、監査、レビューの重さを変える。
つまり、類型だけで決めるのではなく、データ分類でも補正します。同じ成長探索型の取り組みでも、公開情報だけで試すのか、顧客データを使うのか、規制対象データを使うのかで判断レーンは変わります。
そうしないと、全社を守るための統制が、軽く試せるはずの業務まで止めてしまいます。逆に、軽い業務のスピード感を全社に広げると、本当に重い事業やデータを守れなくなります。
成長探索型
成長探索型は、市場投入の速さ、仮説検証、顧客獲得、学習速度が事業価値に直結する事業です。
見る問いは、止まることより、試行回数や学習速度が競争力を左右するかです。
たとえば、立ち上げ直後のSaaS、D2CやECの新ブランド、メディアやコンテンツ事業、新規プロダクト、海外展開、営業主導で市場を作っているBtoB事業などです。まだ勝ち筋が固まり切っておらず、試行回数と改善速度が競争力になります。
ここでは、リスクを下げることだけに寄せすぎると、事業機会を失います。
AIやSaaSを使うことで、提案書作成が速くなる。顧客仮説を検証しやすくなる。問い合わせ対応の初動が速くなる。プロダクト開発の調査や実装が速くなる。こうした効果が大きい領域では、使わないこと自体がリスクになります。
AIについては、AI事業者ガイドラインでも、便益とリスクを踏まえたリスクベースの取組として扱われています。これは、成長探索型のような領域で「危ないから一律禁止」にしないための考え方としても参考になります。
もちろん、何でも自由にしてよいわけではありません。
このパターンで情シス・セキュリティが出すべき判断材料は、どこまで広く使わせると効果が出るのか、入れてはいけないデータは何か、社外送信前に人間レビューを入れるべき箇所はどこか、失敗しても戻せる範囲はどこか、といったものです。
ここで大事なのは、「禁止」ではなく「早く安全に試すための柵」を作ることです。
業務効率・標準化型
業務効率・標準化型は、同じような業務を多人数、多拠点、複数部門で繰り返すことが多く、標準化によって効率が出る事業です。
見る問いは、個別最適よりも、組織全体で同じやり方にそろえることが価値になるかです。
たとえば、多拠点の小売・サービス業、店舗運営、コールセンター、BPO、士業やコンサルティングのような文書業務が多い事業、社内手続きや問い合わせが多い一定規模以上の企業などです。個別最適よりも、組織全体で同じ道具を使えることが価値になります。
ここでは、広く使われるほど効果が出ます。数人だけが使うより、組織全体で標準的に使える方が、生産性向上のインパクトは大きくなります。
一方で、統制がないまま広がると、シャドーIT、権限過多、個人アカウント利用、ログ不足、データ分類の崩れが起きやすくなります。
このパターンで情シス・セキュリティが出すべき判断材料は、標準ツールを何にするか、SSOやSCIMで管理できるか、監査ログを取れるか、共有設定や権限をどう見直すか、利用者教育をどう行うか、利用状況をどうレビューするかです。
ここでは、細かい例外を増やすより、組織として使いやすい標準ルートを作ることが重要です。
使える道を用意せずに禁止だけすると、個人アカウントや未承認サービスに流れます。それでは、むしろ管理できません。
安定供給型
安定供給型は、サービスを止めないこと、復旧できること、社会や顧客への影響を抑えることが事業価値の中心にある事業です。
見る問いは、止まる、壊れる、誤ることが、顧客や社会への大きな影響につながるかです。
たとえば、電力、ガス、水道、通信、交通、物流、製造ライン、医療機関、クラウド基盤、マネージドサービス、24時間稼働の業務システムなどです。売上成長も重要ですが、それ以前に「止まらず提供し続けること」が顧客との約束になっています。
ここでは、便利になることよりも、止めないこと、壊さないこと、復旧できること、説明できることの比重が高くなります。
だからといって、新しい技術を使ってはいけないという話ではありません。
むしろ、安定提供を強化するためにクラウドやAIを使うことはあります。障害対応のナレッジ検索、監視アラートの整理、手順書作成、復旧訓練、問い合わせ対応の支援など、使いどころはあります。
ただし、適用範囲や導入順序は慎重に考える必要があります。
このパターンで情シス・セキュリティが出すべき判断材料は、何が止まると誰に影響するのか、RTOやRPOはどの程度か、障害時の代替手段はあるか、変更管理や段階導入が必要か、外部委託先やサプライチェーンに依存しすぎていないか、といったものです。
便利だから一気に広げるのではなく、継続提供に効く範囲から、影響を測りながら入れていく判断が必要になります。
規制・信用重視型
規制・信用重視型は、信用、説明責任、法令・契約遵守が事業継続に直結する事業です。
見る問いは、事故時に監査、契約、規制、顧客説明へ耐えられることが事業継続に直結するかです。
たとえば、銀行、証券、保険、決済、医療・ヘルスケア、法務、会計、人事・給与、認証・ID管理、セキュリティサービス、大企業向けSaaS、顧客の機密情報や個人データを預かる受託業務などです。事故が起きると、直接損害だけでなく、取引停止、監督当局対応、顧客離れ、監査指摘につながります。
ここでは、事業価値の中心に信用と説明責任があります。
事故が起きたときの問題は、直接的な損害だけではありません。監督当局、顧客、取引先、社会からの信頼を失うことがあります。場合によっては、事業継続や取引条件にも影響します。
金融分野では、金融庁のサイバーセキュリティ関連資料でも、サイバーセキュリティを経営陣が主体的に関与すべき論点として扱っています。このような領域では、スピードだけでなく、説明責任、委託先管理、監査可能性が重くなります。
このパターンで情シス・セキュリティが出すべき判断材料は、法令や業界ガイドライン、契約上の要求、委託や再委託、第三者提供、越境移転、監査ログ、証跡、データマッピング、PIA、承認フロー、例外管理、定期レビューです。
個人情報を扱う場合は、個人情報保護委員会のデータガバナンスに関する情報にもあるように、責任者や責任部署、データマッピング、PIAといった観点が重要になります。
ここでも、結論は「使うな」ではありません。
使うなら説明できる状態にする。監査できる状態にする。契約とデータの流れを整理する。例外を例外として管理する。
そういう判断材料が必要になります。
小規模・外部依存は、別の補正軸として見る
もう一つ、どのパターンにも重なる重要な軸があります。
それが、組織の規模や運用余力です。
中小企業、専任情シスがいない組織、少人数で多くのSaaSを使っている組織では、大企業と同じ管理策をそのまま入れることはできません。
たとえば、専任情シスがいない会社で、全社員が複数のSaaSを個別契約している。管理者権限を社長や総務が兼務している。取引先からセキュリティチェックシートを求められるが、ログ確認や棚卸しを継続する人がいない。こうした状況です。
理想的なルールを作っても、運用できなければ破綻します。監査ログを見ろと言っても、見る人がいなければ意味がありません。例外承認フローを作っても、承認する人が曖昧なら機能しません。
だから、小規模組織では、まず守るべき最重要データと業務を絞る必要があります。
そのうえで、SSO、MFA、端末管理、バックアップ、管理者権限の整理、標準SaaSの選定、マネージドサービスの活用など、運用できる範囲から優先順位を付けるべきです。
ここで間違えてはいけないのは、小規模だから低リスクという意味ではないことです。
むしろ、専門人材や予算が少ないからこそ、外部サービスの選定、標準機能の活用、補助制度や公的支援の利用、取引先から求められる水準の把握が重要になります。
組織余力を見ないセキュリティ提案は、正しくても実行されません。
経営に出す判断材料はこの形にする
最後に、情シス・情報セキュリティが経営に判断を仰ぐときの形を整理します。
ここまでの型を見立てたら、同じ10項目でも厚く見る場所を変えます。成長探索型なら「取りに行く効果」と「使わない場合のリスク」を厚く見る。安定供給型なら「事業影響」と「必要な管理策」を厚く見る。規制・信用重視型なら「残るリスク」と「経営に決めてほしいこと」を、説明責任に耐える形まで具体化する。
私は、少なくとも次の10項目は揃えた方がよいと思っています。
- 取りに行く効果
- 対象業務
- 対象データ
- 想定リスク
- リスクが顕在化した場合の事業影響
- 必要な管理策
- 残るリスク
- 使わない場合のリスク
- 推奨案
- 経営に決めてほしいこと
この中で、特に抜けやすいのは「取りに行く効果」と「使わない場合のリスク」です。
セキュリティの説明は、どうしても「起きると困ること」に寄りがちです。もちろん、それは必要です。
でも経営判断では、得られる効果も同じくらい重要です。
AIを使えば、営業資料作成が速くなるかもしれない。問い合わせ対応の初動が改善するかもしれない。開発者の調査時間が減るかもしれない。ナレッジ検索が速くなり、属人化が減るかもしれない。
それを使わなければ、競合より遅れるかもしれない。人手不足を補えないかもしれない。従業員が個人アカウントで勝手に使うかもしれない。正規ルートを用意できないことで、むしろ統制不能になるかもしれない。
こうした「取らないリスク」を含めて出すから、経営は判断できます。
情シス・セキュリティが出すべきなのは、単なる危険リストではありません。
経営が妥協ラインを決めるための材料です。
まとめ
情シス・情報セキュリティの専門性は、リスクを止めることだけにあるわけではありません。
事業が何を目指しているのかを理解し、その目的に沿ってリスクを翻訳し、経営が判断できる材料を出すことにあります。
技術的には正しい指摘でも、事業の文脈を外していれば、経営から見ると筋が悪いことがあります。
逆に、事業理解のあるセキュリティ判断は、事業を止めるものではありません。事業を強くするための経営機能になります。
AI、SaaS、クラウド、外部サービスをどう使うかは、これからますます重要になります。
そのとき、情シスやセキュリティがやるべきことは、「危ないからやめましょう」と言うことだけではありません。
その会社が何を勝ちに行っているのかを理解する。そのうえで、どの効果を取りに行くなら、どのリスクを受け入れる必要があるのかを整理する。どの統制で、どこまで下げられるのかを示す。最後に、経営が決めるべきことを明確にする。
経営に届く判断材料とは、そういうものだと思っています。
