セキュリティ施策の”主幹”はどこ？——中小企業に責任分界点の議論はいらない

▼ 「それ、情シスがやるんですよね？」

セキュリティ施策を進めていると、必ずと言っていいほどこの問いにぶつかる。

脆弱性診断の主幹はCSIRT？インフラ？　EDRの運用はセキュリティチーム？情シス？　PCI DSSの対応は誰が旗を振る？

大企業であれば「責任分界点を明確にしましょう」「RACIを定義しましょう」という話になる。それ自体は正しい。ただ、この議論をそのまま50〜200名規模の中小企業に持ち込むと、ほぼ確実に形骸化する。

今回は、自分が大企業と中小企業の両方で情シスをやってきた経験から、「セキュリティ施策の主幹問題」を中小企業ではどう捉えるべきかを書く。

▼ 大企業で起きる「誰がボールを持つのか」問題

ある程度の規模の会社では、情シス・インフラ・CSIRT・開発——といった形でチームが分かれている。セキュリティ施策が出てくると、こういうやりとりが発生する。

これ、エンジニアや情シスをやっていれば一度は経験したことがあるはずだ。問題の本質は、「作業の依頼」と「責任の移管」の区別が曖昧なまま進んでいることにある。

大企業ではチームが分かれている分、この曖昧さが「調整コスト」として顕在化する。会議が増え、Slackのスレッドが伸び、最終的に「一回認識を揃えましょう」というMTGが設定される。チーム間の温度感のズレを埋めるためだけに、関係者の時間が消費される。

▼ 中小企業では、この問題が「見えなくなる」だけ

50〜200名規模の会社で、CSIRTが独立して存在することはほとんどない。インフラチームと情シスが分かれていることも稀だ。多くの場合、情シスは1〜2人。セキュリティもネットワークもSaaS管理もヘルプデスクも、全部同じ人がやっている。

だから「誰が主幹か」という議論はそもそも発生しない。全部自分だから。

ただし——問題が消えたわけではない。見えなくなっただけだ。

中小企業の情シスに置き換えると、大企業の「誰がボールを持つのか」問題は、こういう形に変わる。

大企業での問題	中小企業での問題
チーム間で主幹が決まらない	全部自分だけど、優先順位がわからない
作業依頼と責任移管の区別が曖昧	経営層の「ちゃんとやって」が作業指示なのか責任移管なのか曖昧
技術がわかる人に仕事が集中する	そもそも自分しかいないので集中も何もない（が、限界は来る）
認識のズレが事後にSlackで表面化	インシデント発生時に初めて「え、それ情シスが見てたんじゃないの？」と言われる

特に最後の行が致命的だ。中小企業では、セキュリティ周りのボールの所在が曖昧なまま何年も過ぎて、インシデントが起きた瞬間に「誰の責任か」が問われる。そのとき情シスが「いや、自分はMDMとアカウント管理を優先していたので、脆弱性診断まで手が回っていませんでした」と言っても、経営層からすれば「でもITのことは全部お願いしてたよね？」となる。

▼ チーム分けの話ではなく、「判断」と「作業」を分ける話

自分が支援している50〜200名規模の会社で実感しているのは、中小企業に必要なのは「責任分界点の定義」でも「RACI表」でもないということだ。

必要なのは、セキュリティ施策ひとつひとつに対して「判断した人」と「手を動かす人」を記録する、それだけでいい。

NotionでもGoogle スプレッドシートでもいい。大事なのは、判断と作業が分離して記録されていることだ。

なぜこれが効くのか

中小企業の情シスは、日々の業務の中で無意識に「判断」と「作業」を同時にやっている。EDRを導入するとき、「うちにはEDRが必要だ」という判断と、「Jamf ProtectとCrowdStrikeを比較してJamf Protectに決めた」という判断と、「展開スクリプトを書いて全台に配った」という作業が、全部ひとりの中で完結している。

それ自体は問題ない。問題は、あとから「なぜEDRを入れたのか」「なぜその製品にしたのか」を聞かれたとき、判断の根拠がどこにも残っていないことだ。

ある会社で、監査対応のときにこう聞かれたことがある。「このセキュリティ対策は誰が決めたんですか？」——答えは「前任の情シスがなんとなく入れたっぽいです」だった。判断の記録がないと、こうなる。

▼ 実務で使える「判断ログ」のイメージ

実際に自分が支援先で使っている形式を紹介する。大げさなものではなく、Notionのテーブルやスプレッドシートの1シートで十分だ。

施策	判断者	判断日	作業者	ステータス	備考
EDR導入（Jamf Protect）	CTO	2025/04	情シス	完了	CTO承認のうえ情シスが選定・展開
脆弱性診断（外部委託）	CEO	2025/06	外部ベンダー	進行中	予算承認済、スコープは情シスが定義
パスワードマネージャー導入	情シス	2025/03	情シス	完了	情シス判断で導入、月次報告で共有済
セキュリティ研修（年1回）	CEO	2025/01	情シス＋外部	完了	経営判断で実施、コンテンツは情シス作成
ISMS取得検討	未決定	—	—	保留	営業要望あり、経営判断待ち

この表の一番の価値は、「判断者」の列にある。情シスが自分で決めたものと、経営層が決めたものが明確に分かれている。これがあるだけで、「なぜやったのか」「なぜやっていないのか」の説明がいつでもできる。

最後の行の「ISMS取得検討」のように、「まだ誰も判断していない」ことが可視化されるのも大きい。宙に浮いているボールが見える状態になる。

▼ 「責任分界点を定義しましょう」が中小で機能しない理由

大企業向けのセキュリティコンサルや、ISMSの審査員が言いがちなのが「まず責任分界点を明確にしましょう」「RACI表を作りましょう」というアドバイスだ。

これが中小企業で機能しない理由は単純で、チームが分かれていないのにチーム間の責任を定義しても意味がないからだ。

情シス1人の会社でRACIを書くと、全行に同じ名前が並ぶ。ResponsibleもAccountableもConsultedも全部「田中さん」になる。それは定義ではなく、ただの現状確認だ。

もうひとつの問題は、RACI表もポリシー文書も、作った瞬間に更新されなくなること。中小企業の情シスにドキュメント管理のリソースは基本的にない。運用に乗らないドキュメントは、監査のときだけ引っ張り出されるお飾りになる。

▼ まとめ

• ▶ 大企業の「誰が主幹か」問題は、中小では「優先順位がわからない」「経営層との責任範囲が曖昧」に形を変える
• ▶ 中小企業にRACIや責任分界点の定義を持ち込んでも形骸化する
• ▶ 必要なのは「判断した人」と「作業する人」を記録する習慣
• ▶ Notionやスプレッドシート1枚でいい。大事なのは運用に乗ること
• ▶ 「まだ誰も判断していない施策」を可視化できるだけで、ボールの宙ぶらりんは防げる

チームを分けること、責任分界点を定義すること——それ自体が悪いわけではない。ただ、50〜200名規模の会社でそこから入ると、ほぼ確実に手が止まる。まずは判断ログをひとつ作るところから始めればいい。仕組みは、運用が回ってから整えればいい。