SCS対応に必要な社内体制｜情シス・事業部・法務の役割分担｜ハチマルヤ合同会社（808）

「SCS対応、情シスでやっておいて」

こう言われて着手したものの、途中で完全に手が止まる——これはSCS評価制度の対応で最もよくある展開です。

原因ははっきりしています。★3の要求事項26件の中に、情報システム部門の権限では判定すらできない項目が含まれているからです。[※1] 取引先との関係、契約上の機密情報の取扱い、守秘義務のルール。これらは営業・調達・法務・人事が関わらなければ動きません。

この記事では、ハチマルヤ合同会社（808）のコンサルタントが、公式の要求事項をもとに「どの項目にどの部門が必要か」を整理し、現実的な体制の作り方を解説します。

要求事項26件の全体像は、別記事で解説しています。

→ SCS評価制度とは？2027年から始まる新制度の全体像と対象企業

---

情シス単独では完結しない理由

まず、26件を「どの部門の情報が必要か」で分けてみます。

区分	該当する主な要求事項	件数の目安
情シスで完結できる	ID管理手続、パスワードルール、アクセス権管理、バックアップ、パッチ適用手続、マルウェア対策、ネットワーク境界防護、監視、資産把握 など	約15件
他部門の情報・判断が必要	取引先との関係の把握、機密情報の取扱い、インシデント時の役割分担、守秘義務のルール、外部情報サービスの管理、機密区分に応じた情報管理 など	約8件
経営層の承認・関与が必要	セキュリティ推進活動部門の決定、セキュリティ対応方針の策定、事業継続要件に沿った復旧準備	約3件

※分類は自社の組織構造によって変わります。目安としてご覧ください。

26件のうち3分の1以上が、情シス以外の関与を必要とします。しかもこれらは後回しにできない項目です。理由は次のセクションで説明します。

---

部門別・関わる要求事項の一覧

情報システム部門

技術的な対策とIT運用に関する項目の大半を担当します。

• ユーザID・管理者IDの管理手続（4-1-1、4-1-2）
• 認証の強度・実装方法の決定（4-1-3）
• アカウントロック制御（4-1-4）
• パスワードの設定・管理ルール（4-1-5、4-1-6）
• アクセス権の管理ルール（4-1-7）
• バックアップ（4-3-4）
• 安全な構成の確立・維持（4-4-1）
• セキュリティパッチ・アップデートの手続（4-4-4）
• マルウェア感染からの保護（4-4-5）
• ネットワーク境界防護（4-5-1）
• ネットワーク接続・データの監視（5-1-1）
• 情報機器・OS・ソフトウェアの把握（3-1-1）
• ネットワークに関する情報の把握（3-1-2）

役割：SCS対応の実務推進の中心。ただし「すべてを自部門で判断する」のではなく、他部門への確認事項を洗い出して依頼する調整役も担います。

営業・調達部門

取引先に関する情報を持っているのはこの部門です。

• 取引先とのビジネス又はシステム上の関係の把握（2-1-1）
• 機密情報の取扱いを共有先との間で明確にする（2-1-2）
• セキュリティインシデント発生時の他社との役割・責任の明確化（2-1-4）

役割：取引先の一覧化と、実際の連絡・調整の窓口。情シスが「どの取引先とどんなデータをやり取りしているか」を把握するには、この部門の協力が不可欠です。

依頼のポイント：「セキュリティ対応のため取引先情報を出してほしい」だけでは動きにくいことがあります。「取引先から同種の照会が来る可能性があり、先に整理しておくと対応が楽になる」という文脈で伝えると、協力を得やすくなります。

法務部門

契約と規程に関わる項目を担当します。

• 守秘義務のルールの策定（1-2-3）
• 機密情報の取扱いに関する契約面の確認（2-1-2の一部）
• インシデント発生時の責任範囲の整理（2-1-4の一部）

役割：契約書の条項確認と、必要に応じた条文の追加・修正。既存契約をすべて見直すのは現実的でないため、新規契約から順次対応し、既存分は更新時に反映する進め方が一般的です。

人事・総務部門

• 守秘義務のルールの周知・遵守徹底（1-2-3）
• セキュリティインシデント発生時の教育・訓練の実施（4-2-2）

役割：全社員への周知と教育の実施体制。教育は情シスが内容を作り、人事が実施を回すという分担が機能しやすいです。

各事業部門

• 機密区分に応じた情報の管理（3-1-4）
• 外部情報サービスの管理（3-1-3）

役割：現場で実際に扱っている情報とサービスの実態を提供します。特に外部情報サービス（クラウドストレージ、SaaSなど）は、部門ごとに個別契約されているものが情シスの把握外にあるケースが多く、棚卸しには各部門への確認が必須です。

経営層

• セキュリティ推進活動部門の決定（1-2-1）
• セキュリティ対応方針の策定（1-3-1）
• 事業継続要件の決定（7-1-1の前提）

役割：予算・体制の承認に加えて、要求事項の対象そのものです。特に1-2-1は「担当する部署、役員及び従業員を決定し、責任及び権限を割り当てること」という内容で、経営層の意思決定なしには成立しません。[※1]

なお★4では、セキュリティ対策推進計画の策定と経営層への定期報告が要求事項に加わります。[※1]

経営層を動かす説明の組み立て方は、以下の記事で解説しています。

→ SCS対応の予算が通らないときの考え方｜経営層への説明の組み立て方

---

他部門が絡む項目こそ、着手を最優先する

体制の話で最も重要なのがこの点です。

情シスで完結する項目は、担当者の工数さえ確保できれば期間を短縮できます。しかし他部門・社外が絡む項目は、こちらの都合で進められません。

• 営業部門に取引先リストを依頼 → 通常業務の合間の対応になり、数週間かかることがある
• 法務に契約条項の確認を依頼 → レビュー待ちが発生する
• 取引先へインシデント時の役割分担を照会 → 相手方の社内検討を待つ

これらは待ち時間そのものが工程になります。「情シスの作業が一段落してから他部門に依頼しよう」と考えると、終盤で確実に詰まります。

判定した時点で、他部門への依頼だけは先に出しておく。これが体制運用の鉄則です。

対応の順序全体については、以下の記事で整理しています。

→ SCS評価制度対応で陥りがちな失敗5パターンと回避策

---

現実的な体制の作り方

専任チームは必須ではない

「SCS対応プロジェクトチームを組成する」と聞くと大掛かりに感じますが、多くの企業ではそこまでの体制は必要ありません。実態として機能しやすいのは、次のような形です。

推進担当（情シス）1名：全体の進行管理と、情シス領域の実務を担当。要求事項の判定を主導する。

各部門の窓口担当（兼務）：営業・法務・人事・各事業部から1名ずつ、質問に答える役割の人を決めておく。専任である必要はなく、「この件はこの人に聞けばよい」という状態を作るだけで進行速度が変わります。

経営層のスポンサー1名：役員クラスで、部門間の調整が必要になったときに動かせる立場の人。

要求事項1-2-1（セキュリティ推進活動部門）は、この体制を文書化することで対応できます。「セキュリティ推進を担当する部署と、責任・権限を明確にした文書」があればよく、大規模な組織変更は不要です。

会議体は既存のものを使う

新たに定例会議を設けると、それ自体が負担になります。既存の部門長会議や経営会議に「SCS対応の進捗」を議題として1枠もらう形が現実的です。

★4を目指す場合は、経営層への定期報告が要求事項に含まれるため、この報告枠が要求事項への対応そのものになります。[※1]

情シスに全部丸投げされないための言い方

「セキュリティは情シスの仕事」という認識を変えるのに有効なのは、要求事項の原文を見せることです。

たとえば2-1-1は「取引先と自社とのビジネス又はシステム上の関係を把握すること」という要求事項です。[※1] これを見せて「この判定には営業部門が持っている情報が必要です」と説明すれば、担当範囲の議論ではなく事実の確認になります。

抽象的に「協力してほしい」と伝えるより、公式文書を根拠にするほうが話が早く進みます。

---

体制づくりでつまずきやすい3つのケース

ケース①：窓口担当を決めずに、その都度探している

「取引先のことは営業に聞けばいいだろう」と考えて都度依頼すると、担当者が不在だったり、誰が答えるべきか社内で確認が発生したりして、毎回時間がかかります。

最初に部門ごとの窓口を1名決めておけば、2回目以降の照会が一気に速くなります。決めるだけなら会議1回で済む作業です。

ケース②：依頼の粒度が大きすぎる

「取引先の情報をすべて出してほしい」という依頼は、受け手にとって着手の負担が大きく、後回しにされがちです。

「機密情報をやり取りしている取引先を10社挙げてほしい」のように範囲を絞ると、動いてもらいやすくなります。まず範囲を絞って始め、順に広げていく進め方が現実的です。

ケース③：情シスが他部門の作業まで巻き取ってしまう

進まないことに焦って、情シス担当者が契約書を読み込んだり、取引先へ直接連絡したりするケースです。一時的には進みますが、判断の正確性に問題が出るうえ、担当者の負荷が限界を超えます。

情シスの役割は「判定を主導し、必要な情報を各部門から集めること」です。専門的な判断は各部門に委ねる線引きを、最初に共有しておいてください。

---

担当者が変わっても回る形にする

SCS評価制度は取得して終わりではなく、継続的な運用が前提の制度です。担当者の異動でゼロに戻らないよう、次の3点を整えておいてください。

判定の根拠を残す：「なぜこの項目を対応済みと判断したか」をメモしておくと、後任者が一から確認し直す必要がなくなります。

証跡の保管場所を統一する：各部門がバラバラの場所に記録を置いていると、次の更新時に探すところから始まります。共有フォルダの構成を最初に決めておくのが有効です。

他部門の窓口担当も文書化する：「誰に聞けばよいか」が属人的な記憶になっていると、担当交代時に一番困ります。

---

まとめ

• ★3の要求事項26件のうち、3分の1以上が情シス以外の関与を必要とする
• 取引先関連（営業・調達）、契約と規程（法務）、教育（人事）、現場の実態（事業部）、方針と体制（経営層）に分かれる
• 他部門・社外が絡む項目は待ち時間が工程になるため、判定した時点で依頼だけ先に出す
• 専任チームは必須ではない。推進担当1名＋各部門の窓口（兼務）＋経営層のスポンサーで機能する
• 会議体は既存のものを使う。★4では経営層への定期報告が要求事項に含まれる
• 情シスへの丸投げを防ぐには、要求事項の原文を見せて事実で説明するのが有効

---

よくある質問（FAQ）

Q1：情シス担当が1名しかいません。それでも対応できますか？

対応は可能ですが、1名ですべてを完結させる想定では計画が破綻します。重要なのは、他部門に「作業を依頼する」のではなく「質問に答えてもらう窓口を作る」ことです。各部門の窓口担当を決めておけば、実務の中心は1名でも進行できます。あわせて、時間のかかる技術的整備や専門性の高い部分は外部支援の活用も検討してください。

Q2：部門横断の体制を作りたいのですが、経営層が動いてくれません。

要求事項1-2-1が「担当する部署、役員及び従業員を決定し、責任及び権限を割り当てること」という内容であることを示すのが有効です。[※1] 体制の決定そのものが要求事項に含まれるため、「経営判断が必要な項目」として提示できます。加えて、取引先管理の項目が情シスの権限では判定できないことを、要求事項の原文とともに説明してください。

Q3：営業部門に取引先情報の提供を依頼しましたが、後回しにされています。

依頼の粒度を下げると動きやすくなります。「全取引先のリストを出してほしい」ではなく、「機密情報をやり取りしている取引先を10社だけ挙げてほしい」という形にすると、着手のハードルが下がります。SCS評価制度でも、すべての取引先に一律対応するのではなく、重要な取引先から優先する進め方が現実的です。

Q4：CISOを置く必要がありますか？

SCS評価制度の★3の要求事項では、CISOという役職の設置は求められていません。1-2-1で求められているのは「担当する部署、役員及び従業員を決定し、責任及び権限を割り当てること」です。[※1] 既存の役員が兼務する形でも要件を満たせます。組織の規模や体制に応じて判断してください。

Q5：グループ会社がある場合、体制はどう考えればよいですか？

まず評価の対象範囲（どの法人・どの事業を対象とするか）を確定させることが先決です。範囲が決まれば、その中で必要な部門を洗い出す流れになります。グループ全体を一体で評価するのか、法人単位で分けるのかによって体制の設計が変わるため、範囲の決定を最初に行ってください。

---

ハチマルヤ合同会社（808）では、SCS評価制度への対応を専門チームがサポートしています。体制の設計から要求事項のギャップ分析、対策の実施支援まで、「社内をどう巻き込めばよいかわからない」という段階からご相談を受け付けています。まずはお気軽に無料相談をご利用ください。

→ 無料相談はこちら

---

参考資料・出典

※1 IPA（情報処理推進機構）「★3・★4 要求事項・評価基準」（2026年4月21日公開）
https://www.ipa.go.jp/security/scs/requirements-criteria.html

---