SCS対応、結局だれがやるのか｜必要な体制とスキル

1. なぜ情報システム部門だけでは完結しないのか

SCS対応の担当を情報システム部門に任せる企業は少なくありません。セキュリティの話だから情シスの仕事、という整理は自然に見えます。ただ、要求事項の構成を見ると、その前提では進まないことが分かります。

1-1. 要求事項の7分類のうち、情シスの権限外にある領域

SCS評価制度の要求事項は、NIST CSF（サイバーセキュリティフレームワーク）の「統治」「識別」「防御」「検知」「対応」「復旧」の6分類に、「取引先管理」を加えた7つの分類で構成されています。

このうち技術寄りの領域は「防御」「検知」あたりで、ここは情報システム部門の担当範囲に収まります。問題はそれ以外です。

「統治」は、経営層がセキュリティにどう関与しているかという領域です。方針を承認する、リスクをどこまで受け入れるかを判断する、必要な予算を確保する。これらは情報システム部門の権限では動かせません。

「取引先管理」は、自社が委託している先をどう管理しているかという領域です。契約内容の見直しや、委託先への確認依頼が含まれます。購買・調達部門や法務との連携なしには進みません。

つまりSCS対応は、その性質上はじめから部門横断の取り組みになります。情報システム部門に丸ごと任せると、担当者は自分の権限が及ばない領域について他部門に依頼して回ることになり、そこで止まります。

1-2. ★3にも「専門家の確認」が必要になる

もう一点、体制を考えるうえで押さえておきたいのが評価の方法です。

★3は自己評価がベースですが、自己申告だけで完結するわけではありません。取得を希望する組織が自己評価を記入し、社内外のセキュリティ専門家が内容を確認・助言したうえで提出する流れになっています。★4ではさらに、評価機関による文書の確認、実地審査、技術検証が入ります。

ここから分かるのは、対応する体制のなかに「記入する人」とは別に「確認する人」が必要になるということです。社内に該当する人材がいない場合、社外に依頼することになります。この点は体制を設計する段階で織り込んでおく必要があります。

なお、確認を担う専門家に求められる要件の細部については、現在も具体化が進められている段階です。具体的な資格や条件については、経済産業省およびIPAの公式サイトで最新の情報をご確認ください。

2. SCS対応に必要な4つの役割

では、具体的にどのような役割が必要になるのか。大きく4つに整理できます。

2-1. 4つの役割がそれぞれ何をするのか

責任者（経営層）は、要求事項の「統治」に直接かかわります。どこまでのリスクを受け入れるかという判断は、現場では決められません。ここが空席のままだと、推進担当がいくら整理しても最後の決裁で止まります。

推進事務局が、実質的な中心になります。要求事項と自社の現状を突き合わせ、足りない部分を洗い出し、規程を整備し、証跡を集める。4つの役割のなかで最も作業量が多いのがここです。担当を決めるときは、この負荷を前提に考える必要があります。

技術実装は、ID管理やログの取得、端末管理といった具体的な仕組みづくりです。4つのなかでは最も外部に委託しやすい領域といえます。

現場部門は見落とされがちですが、欠かせません。どの部署がどんな情報資産を持っているかを把握しているのは現場です。推進事務局がどれだけ優秀でも、現場が資産の棚卸しに協力しなければ作業は終わりません。

2-2. 兼任してよい組み合わせと、破綻する組み合わせ

4つの役割が必要だと聞くと、専任チームを作らなければと身構えるかもしれません。しかしすべてを専任にする必要はありません。中小企業では一人が複数の役割を兼ねるのが現実的です。

ただし、兼任して問題のない組み合わせと、無理が出る組み合わせがあります。

推進事務局と技術実装の兼任は、むしろ効率的に働くことが多い組み合わせです。一方で、経営層の意思決定だけは他の役割で代替できません。ここを兼任でごまかすと、対外的に説明が必要になった場面で根拠を示せなくなります。

体制を考えるときは「何人必要か」ではなく、「4つの役割に担当が割り当たっているか」を基準にしてください。

3. 求められるスキルの正体

「セキュリティの専門知識がある人がいないから、うちでは無理だ」という声をよく聞きます。ただ、実際に対応を進めるうえで効いてくるのは、少し違う種類のスキルです。

3-1. 要求事項を自社の業務に翻訳する力

要求事項は、どの企業にも当てはまるように抽象的な言葉で書かれています。そのため、「自社の場合、具体的に何をすることなのか」への変換作業が必ず発生します。

たとえば「委託先の管理」という要求事項があったとして、自社では何社が該当するのか、どの契約が対象なのか、誰が窓口になっているのか。これを特定する作業は、自社の業務を知っている人にしかできません。

ここを外部のコンサルタントに任せきりにすると、一般論としては正しいが自社の実態とは噛み合わない規程ができあがります。この翻訳作業が、内製すべき領域の中心にあります。

3-2. 実施していることを記録として残す力

もう一つが、記録を残す力です。

対策を実施していても、いつ誰が何をしたのかが残っていなければ、第三者には確認のしようがありません。特に★4では評価機関による実地審査や技術検証が入るため、記録の整備水準は一段上がります。

ここで重要なのは、証跡のために作業を増やすのではなく、業務をこなせば自然に記録が残る形に寄せるという発想です。担当者が手作業でスクリーンショットを撮って保存していく運用は、まず続きません。ツールの監査ログやワークフローの承認履歴など、すでに残っているものを証跡として使えないかを先に検討するほうが現実的です。

記録の整備は運用フェーズで最も負荷がかかる部分です。詳しくは次の記事で解説しています。
「大変なのは取得より運用｜SCS対応でつまずく6つのこと」

3-3. 「確認を担う専門家」をどう確保するか

前述のとおり、★3では社内外のセキュリティ専門家による確認が入ります。社内に該当者がいない場合は、社外に依頼することになります。

この点は、体制を組む段階で「自社で確保できるのか、外部に頼むのか」を決めておかないと、整備が終わってから慌てることになります。なお具体的な要件は制度の細部が具体化されている段階のため、依頼先を検討する際は最新の枠組みを確認してください。

4. 内製する部分と外部に任せる部分

ここまでの整理を踏まえて、どこまでを社内でやり、どこから外部に頼むかを考えます。

4-1. 外部に任せきりにできない領域

先に、外部に任せられない領域を押さえておきます。

• 自社業務の実態把握（どの部署が何を持ち、誰がどう扱っているか）
• 現場ルールの運用（決めたことを日々守り続けること）
• 経営としての判断（方針の承認、リスク受容、予算）

これらを外部に委ねると、書類の上では整っているのに実態が伴わない状態になります。「全部お任せ」で進めた結果、誰も読まない規程ができあがるというのは、セキュリティ対策に限らずよくある失敗です。

4-2. 外部の支援が向いている領域

一方で、外部の知見が効く領域もあります。

• 要求事項の解釈（制度の意図をどう読むか）
• 規程のひな形（ゼロから書き起こすより早い）
• 技術的な実装（ID管理、ログ、端末管理などの構築）
• 第三者の視点での確認（自社だけでは気づきにくい抜けの指摘）

特に技術実装については、新しい製品を入れるかどうかの判断も含めて外部の知見が役立ちます。すでに利用しているツールの機能でまかなえる範囲は意外と広く、そこを見極められるかどうかでコストが変わります。

支援会社の選び方については、次の記事で整理しています。
「SCS支援会社の選び方｜4タイプの特徴と7つの確認点」

4-3. よくある詰まり方

体制の設計が不十分なまま走り出すと、だいたい同じところで止まります。

推進担当が孤立し、経営層の承認で止まる。 責任者の役割が埋まっていないケースです。着手前に、誰が最終的に判断するのかを決めておけば防げます。

規程は作ったが現場に浸透せず、証跡が残らない。 現場部門の役割が埋まっていないケースです。規程を作る段階で現場の意見を聞いていないと、守れない内容になります。

棚卸しを現場に依頼したが返ってこない。 依頼が推進担当から出ているだけで、経営層からの指示になっていないケースです。役割の設計段階で、誰の名前で依頼を出すかまで決めておくと進み方が変わります。

いずれも、体制の設計段階で手を打てる種類の詰まり方です。

5. まとめ：人数ではなく、役割が埋まっているか

SCS対応に必要なのは、大きな専任チームではありません。経営層・推進事務局・技術実装・現場部門という4つの役割それぞれに、担当が割り当たっていることです。一人が複数を兼ねても構いませんが、経営層の意思決定だけは代替できません。

そして求められるスキルは、高度なセキュリティの専門知識よりも、要求事項を自社の業務に翻訳する力と、実施していることを記録として残す力です。前者は自社にしかできず、後者は仕組みで軽くできます。

とはいえ、体制を考える前にもう一つやっておきたいことがあります。それは、自社の現状が要求事項に対してどれだけ足りていないかを把握することです。必要な体制の規模は、そこが見えてはじめて決まります。全社的に足りないのか、特定の領域だけなのかで、必要な人数も期間もまったく変わるからです。

サン・エム・システムの「SCS対応支援サービス」では、SCS評価制度の要求事項と自社の現状の差分を確認できる無料のセルフ診断をご用意しています。Web上で完結し、回答後すぐに結果が表示されます。体制を検討する前の材料として、まずは以下より、無料セルフ診断をお試しください。

※本診断は当社独自の簡易診断であり、制度上の評価・登録を保証するものではありません。

よくある質問（FAQ）

Q. 専任の担当者を置く必要があるか？

A. 必ずしも専任である必要はありません。重要なのは人数ではなく、4つの役割それぞれに担当が割り当たっていることです。推進事務局と技術実装は同じ担当者が兼ねても成立しますし、中小企業ではむしろそのほうが話が早い場合もあります。ただし経営層の意思決定だけは他の役割で代替できないため、ここだけは必ず別に確保してください。

Q. 情報システム部門がない会社はどう進めればよいか？

A. 総務や管理部門が推進事務局を担い、技術実装を外部に委託する形が現実的です。要求事項には経営層の関与や取引先管理といった、もともと情報システム部門の範囲外の領域が含まれているため、「情シスがない＝対応できない」ということにはなりません。ただし自社業務の実態把握と現場ルールの運用は社内に残るため、推進の窓口となる担当者は社内に置く必要があります。

Q. 経営層にどう説明すれば動いてもらえるか？

A. 要求事項に「統治」が含まれており、方針の承認やリスク受容の判断は経営層以外が代替できない、という制度上の事実を示すのが最も確実です。加えて、取引条件として求められる可能性がある点も説明材料になります。そのうえで、現状把握の結果を「どの領域が何割できているか」といった形で示せると、判断に必要な材料がそろい、話が具体的になります。

SCS対応は部門横断の取り組みになるため、どこから手をつけるかの判断に迷いやすい領域です。サン・エム・システムでは、無料のセルフ診断から詳細なヒアリング、規程の整備、技術的な実装、運用の定着までを一貫してご支援しています。支援の範囲は企業ごとに調整しますので、すでにできている領域を除いて必要な部分だけをご相談いただくことも可能です。制度の解釈だけでなく、システム会社として実装まで見られる点が当社の特徴です。
サービスの内容や支援の進め方は、下記のページでご確認いただけます。

参考・出典

• 経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」
• IPA「SCS評価制度の詳細情報」

【この記事を書いた人】
サン・エム・システムコラム編集部