SCS評価制度★3｜取引先管理（サプライチェーン）の3要求事項をCSIRTが実務解説 #007

サプライチェーン管理で「取引先に何を求め、何を決めればよいか」が整理できずに悩んでいませんか？

本記事では、SCS★3「取引先管理」の3要求事項・4評価基準を、CSIRT実務でハマる3つの壁とともに解説します。

筆者は大手グローバル製造業でセキュリティチーム（CSIRT）のリーダーを務めており、本業で法人のセキュリティ設計・運用を見ています。

読了後、取引先管理の全体像と「顧客・子会社も含む範囲設計」が理解でき、実装順を決められます。

はじめに
【CSIRT現場の独自ノウハウ】取引先管理でハマる3つの壁
「取引先管理」の全体像：3要求事項・4評価基準
取引先の外部システムを洗い出す（要求事項2-1-1）
1. 2-1-1-1：自社以外の組織（顧客・子会社・関係会社・クラウドサービス提供者を含む取引先）が管理・提供し、自社の資産が接続しているシステムを把握するための仕組みを整備すること
2. 2-1-1-2：年1回以上の頻度で2-1-1-1において把握すべき情報の内容を点検すること
機密情報の取扱を業務開始前に取り決める（要求事項2-1-2）
1. 2-1-2-1：自社の機密情報を共有する取引先との間で、業務開始前に以下の事項を取り交わすこと
インシデント発生時の役割・責任を定める（要求事項2-1-4）
1. 2-1-4-1：機密情報を共有する子会社または取引先との間で、セキュリティインシデント発生時の役割・責任について、以下の事項を定めること
現場疑問：なぜ「顧客と子会社が同列」なのか
まとめ：取引先管理で求められている4つの評価基準
関連リンク
関連記事
このブログが目指していること
相談してみませんか？

はじめに

SCS評価制度★3の「取引先管理」は、3つの要求事項（外部システム把握・機密情報取扱・インシデント時の役割責任）から成り、4つの評価基準が定められています。

前段のガバナンス整備（#006）が「社内の体制」を問うのに対し、取引先管理は「社外との関係」を問う要求事項です。IT部門だけで完結せず、法務・営業・経営層を巻き込んだ全社横断の取り組みが必須になります。

この記事では、グローバル製造業でCSIRTリーダーを務める筆者が、実務目線で以下を解説します：

3要求事項×4評価基準の全体像
外部システム棚卸しの具体的な進め方（申請制／定期棚卸し／ネットワーク可視化）
NDAとの関係整理（法務連携の必要性）
インシデント発生時の通知フロー（社長・広報・法務・警察・JPCERT/CC）
現場でハマる3つの壁（独自ノウハウ）

なお筆者自身、取引先管理は情報セキュリティ委員会が主管しており、CSIRTとしては側面支援の立場です。「どの領域が誰の管轄か」を把握することもSCS対応の一部という視点で読んでいただければと思います。

【CSIRT現場の独自ノウハウ】取引先管理でハマる3つの壁

要求事項を字面で読むと「外部システムを把握する／NDAを結ぶ／通知フローを決める」というシンプルな話に見えます。ところが現場で運用してみると、以下の3つの壁に必ずぶつかります。

壁1：申請されていないクラウドが山のように出てくる

「使っているクラウドサービスはない」と回答した部署が、よくヒアリングすると顧客が提供するファイル共有サービス・無料アンケートツール・翻訳サイトなどを日常的に使っている、というケースが頻発します。

対策：申請制の導入と部署単位の対面ヒアリング（メール調査だけでは絶対に洗い出せません）。

壁2：NDAが古くて要件を満たしていない

既存のNDAはあっても、内容が「機密情報の定義／取扱／返還または廃棄」の3点を明示していないケースが多いです。特に10年以上前に締結したNDAはSCSの要件を満たしていないことがほとんど。

対策：法務部門との連携必須。NDAの棚卸しと再締結が実質的な負担になります。

壁3：インシデント通知フローが「絵に描いた餅」

「有事の際は連絡します」と書いてあっても、具体的な連絡先・担当者・タイムラインが決まっていない契約が多数。実際にインシデントが発生した時に「誰に何時までに通知するのか」で現場が混乱します。

対策：平時に机上訓練を実施し、通知先リストを最新化することが必須です。

これらは要求事項を守るためだけでなく、実際にインシデントが起きた時に被害を最小化するための実務ノウハウでもあります。以下、要求事項ごとに詳しく見ていきます。

「取引先管理」の全体像：3要求事項・4評価基準

SCS★3における「取引先管理」は、3つの要求事項に対して4つの評価基準が定められています。前回の「ガバナンスの整備」（3要求事項・8評価基準）より評価基準の数は少ないですが、内容は地道な運用が求められるものが多い印象です。

NO	要求事項	評価基準の数	一言まとめ
2-1-1	取引先との関係把握	2つ	外部システムを洗い出し、年1回点検する
2-1-2	機密情報の取り扱い明確化	1つ	業務開始前に取引先と取り決める
2-1-4	インシデント発生時の役割・責任の明確化	1つ	通知義務・連絡先・再発防止協議を定める
合計	3つの要求事項	4つ

順番に見ていきます。

取引先の外部システムを洗い出す（要求事項2-1-1）

2-1-1-1：自社以外の組織（顧客・子会社・関係会社・クラウドサービス提供者を含む取引先）が管理・提供し、自社の資産が接続しているシステムを把握するための仕組みを整備すること

評価基準の原文はこのように表現されており、重要なポイントが2つあります。まず「自社以外の組織」には顧客・子会社・関係会社・クラウドサービス提供者が含まれること。そして「自社の資産が接続している」システムが対象であることです。つまり、全取引先の全システムを把握する必要があるわけではなく、「自社と繋がっているもの」が対象の範囲です。

とはいえ、クラウドシフトが進んでいるため、対象はかなり多くなることが想定されます。担当者にとってはとても大変な作業だと思います。

自分たちで購入・導入したハードウェアやソフトウェアであれば、台帳に記録して管理するという流れは比較的イメージしやすいと思います。ところが、クラウドサービスや無料ツールは「使い始めたことを誰も申告していない」ケースもあるのではないでしょうか。

現実的な対策として考えられるのは以下のような運用です。

申請制の導入： 外部システム・クラウドサービスの利用開始時に申請を必須にする
定期棚卸し： 年1回以上、現在使っているサービスを部署ごとに確認する
ネットワーク経由の可視化： インターネット経由のサービス利用をネットワーク機器で検出する技術的手段もある

ただし3については、「検出の精度が十分でない」「対象外のサービスを誤ってブロックしてしまった」「サービスの種類が多すぎて管理しきれない」といった難しさもありますし、投資も必要です。最初から完璧を目指すより、ルールを決めて運用を始め、定期的に改善していくサイクルを作ることが現実的だと思います。

担当者が粘り強く各部署にヒアリングしていくことも大切です。「使っているサービスはない」と言っていた部署が、よく聞いたら顧客が提供するファイル共有サービスを日常的に使っていた、ということもあると思います。

2-1-1-2：年1回以上の頻度で2-1-1-1において把握すべき情報の内容を点検すること

1の「仕組みを整備する」だけでなく、年1回以上の点検も求められています。サービスの利用開始・終了、担当者の異動など、状況は常に変わるため、定期的に見直す必要があるということです。

「台帳を作ったけど更新されていない」という状態は、評価の際にも実態としても意味をなしません。点検の実施記録（いつ、誰が確認したか）も残しておくと安心です。

機密情報の取扱を業務開始前に取り決める（要求事項2-1-2）

2-1-2-1：自社の機密情報を共有する取引先との間で、業務開始前に以下の事項を取り交わすこと

具体的に求められているのは、以下の3点を業務開始前に合意しておくことです。

機密情報の定義（何が機密情報にあたるか）
機密情報の取り扱い（表示方法・保管方法・複製の可否・第三者への提供可否）
機密情報の返還または廃棄（契約終了時にどうするか）

「これ、NDA（秘密保持契約）と同じでは？」と思いますよね。多くの会社ですでに取引先との間でNDAを結んでいると思いますが、内容が上記の要件を満たしているかを確認しておくといいかもしれません。

ここはIT部門というよりも、法務部門や契約担当との連携が必要な領域です。前回のガバナンスの整備でも経営層が関わる項目がありましたが、SCS対応は全社横断の取り組みだということが、こういった要求事項からもよくわかります。

インシデント発生時の役割・責任を定める（要求事項2-1-4）

2-1-4-1：機密情報を共有する子会社または取引先との間で、セキュリティインシデント発生時の役割・責任について、以下の事項を定めること

求められているのは3点です。

セキュリティインシデント発生時の相手方への通知義務
セキュリティインシデント発生時の連絡先
再発防止策の協議方法

これは筆者自身も経験のあることなのですが、「会社外への通知」は実際には複数の部署・相手先にまたがる複雑な動きになります。

インシデント発生時の通知先と担当部署はおおむね以下のようになります。

通知先	主な担当部署
自社ホームページ・記者会見	社長・広報・IT
取引先	営業・IT
弁護士	法務・IT
個人情報保護委員会・警察・JPCERT/CC	総務・IT

こうして並べると、CSIRTや情報システム担当だけで完結する話ではないことがよくわかります。有事の際に「誰が何をするか」を事前に整理しておかないと、インシデント対応の最中に「この件は誰に報告すればいい？」という混乱が起きます。

ただ、正直に言うと、この通知フローは筆者が全てを経験できているわけではなく、例えば「どういうケースに個人情報保護委員会への通知義務が発生するか」「取引先への通知のタイミングはいつが適切か」という判断は、法的な知識とケースバイケースの判断が必要で、一概に言いにくい部分があります。この辺りは末尾の関連リンクに掲載しているNote記事で深掘りしています。