はじめに
「うちの会社は情報セキュリティとサイバーセキュリティで担当組織が分かれていて、自分はサイバーセキュリティ担当なので取引先管理はあまりわからない」
これは私自身の話です。CSIRTリーダーとして3年やってきましたが、今回の「取引先管理」は日々の業務では情報セキュリティ委員会が担当していて、私は直接携わることが少ない領域です。
それを最初に正直にお伝えしたのには理由があります。SCS対応の現場では、おそらく「全部の要求事項に詳しい担当者」なんていないと思います。むしろ、ほとんどの会社で「この領域は自分の管轄外」「この部署を巻き込まないといけない」という壁が出てくるはずです。
それがわかること自体が、SCS対応では重要な一歩だと思っています。今回は「取引先管理」の4つの評価基準を、現場での感覚も交えながら確認していきます。
「取引先管理」の全体像：3要求事項・4評価基準
SCS★3における「取引先管理」は、3つの要求事項に対して4つの評価基準が定められています。前回の「ガバナンスの整備」（3要求事項・8評価基準）より評価基準の数は少ないですが、内容は地道な運用が求められるものが多い印象です。
| NO | 要求事項 | 評価基準の数 | 一言まとめ |
|---|---|---|---|
| 2-1-1 | 取引先との関係把握 | 2つ | 外部システムを洗い出し、年1回点検する |
| 2-1-2 | 機密情報の取り扱い明確化 | 1つ | 業務開始前に取引先と取り決める |
| 2-1-4 | インシデント発生時の役割・責任の明確化 | 1つ | 通知義務・連絡先・再発防止協議を定める |
| 合計 | 3つの要求事項 | 4つ |
順番に見ていきます。
1. 2-1-1 取引先との関係把握（評価基準2つ）
2-1-1-1：自社以外の組織（顧客・子会社・関係会社・クラウドサービス提供者を含む取引先）が管理・提供し、自社の資産が接続しているシステムを把握するための仕組みを整備すること
評価基準の原文はこのように表現されており、重要なポイントが2つあります。まず「自社以外の組織」には顧客・子会社・関係会社・クラウドサービス提供者が含まれること。そして**「自社の資産が接続している」システムが対象**であることです。つまり、全取引先の全システムを把握する必要があるわけではなく、「自社と繋がっているもの」が対象の範囲です。
とはいえ、クラウドシフトが進んでいるため、対象はかなり多くなることが想定されます。担当者にとってはとても大変な作業だと思います。
自分たちで購入・導入したハードウェアやソフトウェアであれば、台帳に記録して管理するという流れは比較的イメージしやすいと思います。ところが、クラウドサービスや無料ツールは「使い始めたことを誰も申告していない」ケースもあるのではないでしょうか。
現実的な対策として考えられるのは以下のような運用です。
- 申請制の導入： 外部システム・クラウドサービスの利用開始時に申請を必須にする
- 定期棚卸し： 年1回以上、現在使っているサービスを部署ごとに確認する
- ネットワーク経由の可視化： インターネット経由のサービス利用をネットワーク機器で検出する技術的手段もある
ただし3については、「検出の精度が十分でない」「対象外のサービスを誤ってブロックしてしまった」「サービスの種類が多すぎて管理しきれない」といった難しさもありますし、投資も必要です。最初から完璧を目指すより、ルールを決めて運用を始め、定期的に改善していくサイクルを作ることが現実的だと思います。
担当者が粘り強く各部署にヒアリングしていくことも大切です。「使っているサービスはない」と言っていた部署が、よく聞いたら顧客が提供するファイル共有サービスを日常的に使っていた、ということもあると思います。
2-1-1-2：年1回以上の頻度で2-1-1-1において把握すべき情報の内容を点検すること
1の「仕組みを整備する」だけでなく、年1回以上の点検も求められています。サービスの利用開始・終了、担当者の異動など、状況は常に変わるため、定期的に見直す必要があるということです。
「台帳を作ったけど更新されていない」という状態は、評価の際にも実態としても意味をなしません。点検の実施記録（いつ、誰が確認したか）も残しておくと安心です。
2. 2-1-2 機密情報の取り扱い明確化（評価基準1つ）
2-1-2-1：自社の機密情報を共有する取引先との間で、業務開始前に以下の事項を取り交わすこと
具体的に求められているのは、以下の3点を業務開始前に合意しておくことです。
- 機密情報の定義（何が機密情報にあたるか）
- 機密情報の取り扱い（表示方法・保管方法・複製の可否・第三者への提供可否）
- 機密情報の返還または廃棄（契約終了時にどうするか）
「これ、NDA（秘密保持契約）と同じでは？」と思いますよね。多くの会社ですでに取引先との間でNDAを結んでいると思いますが、内容が上記の要件を満たしているかを確認しておくといいかもしれません。
ここはIT部門というよりも、法務部門や契約担当との連携が必要な領域です。前回のガバナンスの整備でも経営層が関わる項目がありましたが、SCS対応は全社横断の取り組みだということが、こういった要求事項からもよくわかります。
3. 2-1-4 インシデント発生時の役割・責任の明確化（評価基準1つ）
2-1-4-1：機密情報を共有する子会社または取引先との間で、セキュリティインシデント発生時の役割・責任について、以下の事項を定めること
求められているのは3点です。
- セキュリティインシデント発生時の相手方への通知義務
- セキュリティインシデント発生時の連絡先
- 再発防止策の協議方法
これは私自身も経験のあることなのですが、「会社外への通知」は実際には複数の部署・相手先にまたがる複雑な動きになります。
インシデント発生時の通知先と担当部署はおおむね以下のようになります。
| 通知先 | 主な担当部署 |
|---|---|
| 自社ホームページ・記者会見 | 社長・広報・IT |
| 取引先 | 営業・IT |
| 弁護士 | 法務・IT |
| 個人情報保護委員会・警察・JPCERT/CC | 総務・IT |
こうして並べると、CSIRTや情報システム担当だけで完結する話ではないことがよくわかります。有事の際に「誰が何をするか」を事前に整理しておかないと、インシデント対応の最中に「この件は誰に報告すればいい？」という混乱が起きます。
ただ、正直に言うと、この通知フローは私が全てを経験できているわけではなく、例えば「どういうケースに個人情報保護委員会への通知義務が発生するか」「取引先への通知のタイミングはいつが適切か」という判断は、法的な知識とケースバイケースの判断が必要で、一概に言いにくい部分があります。この辺りは別の機会にNoteでも取り上げていこうと思っています。
取引先管理で気になったこと：「顧客と子会社が同列」
評価基準をよく見ると、1と3のいずれも「自社以外の組織（顧客・子会社・関係会社・クラウドサービス提供者を含む取引先）」という形で、顧客と子会社が同じレベルで並んでいます。
現場感覚として正直なところをお伝えすると、子会社であれば、親会社から方針や規定を展開することができるので、子会社の方がガバナンスを効かせやすいと感じています。
SCS対応を進める中で、「制度の要件を満たすために、社外の相手方と何かを取り決める必要がある」という局面では、IT部門だけで抱え込まず、経営層や他部門を巻き込むことが大切だと感じます。
まとめ：取引先管理で求められていること
今回確認した4つの評価基準をまとめます。
前回のガバナンスの整備と比べると、取引先や社外との確認が必要な場面が多く、IT部門や情報システム部門だけで完結しない印象です。法務・営業・経営層への働きかけが必要になります。
SCS対応は全社横断の取り組みですので、担当者としては「何が必要か」「誰を巻き込めばいいか」を整理して、社内を動かすことに集中するのが現実的な進め方だと思います。
このブログが目指していること
私はグローバルな製造業グループのCSIRTリーダーとして働いており、セキュリティ製品を売る立場ではありません。自動車部品メーカーに勤めているため、取引先にセキュリティ要件を「求める側」であり、完成車メーカーから要件を「求められる側」でもあります。
その立場から、「このブログを読んだ担当者が、経営者を動かすための言葉と資料を手に入れられる」ことを目指して書いています。
「要求される側の現場目線」を込めようとしています。難しい言葉をわかりやすく言い換えるだけでなく、「現場では実際にどう判断するか」という視点を大事にします。
次回の予告
次回は3つ目の大分類「リスクの特定」を確認します。
「リスク」という言葉はよく聞くわりに、何をどう整理すれば「リスクを特定した」と言えるのかが曖昧になりがちです。資産・脆弱性・脅威・対策の関係を整理しながら、担当者が経営層に説明できる形に落とし込むことを意識してお伝えしていきます。
相談してみませんか？
「ちょっと聞いてみたい」という段階でも構いません。私の経歴・支援内容の詳細は「このブログについて」をご覧ください。
なお、SCSへの関心が高まる中、制度に便乗した不審な勧誘も出てきています。私のことも含め、見知らぬ相手を安易に信用しすぎないようご注意ください。経産省も注意喚起を出しています。
→ サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）に係る不適切な勧誘に御注意ください https://www.meti.go.jp/policy/netsecurity/20260427_scs.html
CISSP・情報処理安全確保支援士 ｜ けい
コメント