SCS評価制度★3の取引先管理とは？4つの評価基準で求められる外部接続システムの把握・機密情報の取扱い・インシデント対応を解説 | OPTiM お役立ち情報

SCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）の★3では、自社内部のセキュリティ対策だけでなく、取引先・子会社・クラウドサービスなど、外部とのつながりを把握・管理することも求められます。

★3の「取引先管理」は、外部接続システムの把握、その年次点検、機密情報の取扱いの取り決め、インシデント時の役割・責任の明確化という4つの評価基準で構成されています。本記事では、この4基準すべてについて、企業が何を確認し、どのような記録を残せばよいのかを解説します。

★3は、SCSセキュリティ専門家の確認を受けた自己評価を基本とする仕組みで、2026年度末頃（概ね2027年3月頃）の運用開始が予定されています。

※本記事は2026年9月下旬時点で公開されている要求事項・評価基準をもとにしています。IPAは★3・★4の要求事項・評価基準の解説書を2026年10月頃に公開予定としており、今後、具体的な評価方法などが明確化される可能性があります。

1. SCS評価制度★3で求められる「取引先管理」とは

★3取引先管理の要求事項と評価基準

★3の取引先管理に該当する要求事項は3件、評価基準は4件です。要求事項・評価基準は、IPA（情報処理推進機構）の公式サイトで公開されています。

要求事項	評価基準	求められる対応
2-1-1 取引先とのビジネス又はシステム上の関係	2-1-1-1	自社の資産が接続する外部組織のシステムを把握する仕組みを整備する
2-1-1 取引先とのビジネス又はシステム上の関係	2-1-1-2	把握した情報を年1回以上点検する
2-1-2 機密情報の取扱い	2-1-2-1	機密情報を共有する相手と、業務開始前に取扱方法を取り決める
2-1-4 セキュリティインシデント発生時の役割・責任	2-1-4-1	インシデント発生時の双方の役割・責任を定める

なお★4では、取引先管理の分野に要求事項・評価基準が追加されます。★3で整備する台帳や契約の仕組みは、将来★4を目指す際の土台にもなります。

なぜ「取引先管理」が求められるのか

近年のサイバー攻撃では、セキュリティ対策が比較的手薄な取引先や委託先、保守事業者を足がかりに、本来の標的企業へ侵入する手口が繰り返し報告されています。保守用のVPN装置、取引先と共有しているファイル共有サービス、グループ共通システムなどは、いずれも「外部との接点」であると同時に、攻撃者にとっての侵入経路にもなり得ます。

SCS評価制度は、こうしたサプライチェーン全体のリスクを踏まえ、発注側・受注側の双方が一定水準のセキュリティ対策を実施していることを可視化するための仕組みです。その中で取引先管理は、「自社がどの外部組織とどうつながっているか」を把握し、万一の際に連携して対応できる状態をつくる役割を担っています。

自社の対策がどれだけ強固でも、接続先の管理状況や、情報を預けている相手の取扱いが不明確なままでは、サプライチェーンの一員として十分な対策とはいえません。取引先管理は、自社を守るためだけでなく、取引先から信頼されるための要件でもあります。

取引先管理の考え方

★3の取引先管理では、外部組織との「接続関係」と「情報共有」の状況を把握し、必要なルールをあらかじめ定めておくことが求められます。

企業のIT環境は、自社だけで完結しません。例えば、次のようなケースがあります。

顧客の受発注システムへ自社PCからアクセスしている
取引先が提供するファイル共有サービスを利用している
子会社と共通の業務システムを利用している
Microsoft 365などのクラウドサービスを業務で利用している
業務委託先へ自社の機密情報を提供している
外部事業者が自社システムの保守を行っている

こうした外部との接点を管理できていないと、インシデント発生時に、影響するシステムや情報、連絡すべき相手をすぐに特定できません。

そのため★3では、単に「取引先一覧」を作るのではなく、システム上の接続関係と機密情報の共有関係の双方を把握することがポイントになります。

2. 自社の資産が接続している外部システムを把握する【2-1-1-1】

評価基準2-1-1-1では、次の対応が求められています。

自社以外の組織が管理・提供し、自社の資産が接続しているシステムを把握するための仕組みを整備すること。

対象となる外部組織には、顧客、子会社、関係会社、取引先、クラウドサービス提供者などが含まれます。

ポイントは、自社が所有・管理するシステムだけを台帳に載せればよいわけではない、という点です。次のようなシステムも確認対象になります。

外部システムの例	接続・利用例
顧客の業務システム	自社PCから顧客の受発注システムへアクセス
取引先のファイル共有	ブラウザや専用アプリから資料を共有
子会社・関係会社のシステム	グループ共通システムへ接続
クラウドサービス	グループウェア、SaaS、オンラインストレージなどを利用
外部事業者の保守環境	VPNなどを利用してシステムへ接続

実務上は、これらを「外部接続システム台帳」として一覧化すると管理しやすくなります。

外部接続システムを洗い出す方法

外部接続システムは、情報システム部門だけで把握しきれないことが多いため、複数の情報源を組み合わせて洗い出すのが効果的です。

情報源	見つけやすい外部システム
購買・経費精算データ	部門単位で契約しているSaaS、クレジットカード払いのクラウドサービス
契約書の管理台帳	業務委託先・保守事業者のシステム、取引先指定のシステム
シングルサインオン（SSO）・ID管理基盤の連携設定	社内IDでログインしている外部サービス
ファイアウォール・プロキシのログ	実際に通信が発生している外部サービスやVPN接続先
端末のインストール済みアプリ一覧	取引先指定の専用アプリ、VPNクライアント、同期ツール
各部門へのヒアリング・アンケート	顧客・取引先のWebシステム、無料で使っているクラウドサービス

特に見落としやすいのが、顧客や取引先が提供するWebシステムです。ブラウザからアクセスするだけのため、契約書や購買データに記録が残らないことがあります。部門へのアンケートでは「業務で使っている、社外の会社が運営するシステムやサービス」を具体例付きで尋ねると、回答の抜け漏れを減らせます。

台帳の粒度をそろえる

台帳を作る際は、「1行＝1つの外部システム（サービス）」を基本単位にすると管理しやすくなります。同じ取引先でも、受発注システムとファイル共有サービスのように複数のシステムを利用している場合は、行を分けて記録します。

逆に、全社で利用している1つのクラウドサービスを部門ごとに別の行で登録すると、点検時に重複や記載ゆれが生じやすくなります。利用部門が複数ある場合は、1行の中で「利用部門」欄に列挙する形がおすすめです。

外部接続システム台帳の項目例

管理項目	記載例
外部組織名	○○株式会社
システム・サービス名	○○受発注システム
利用目的	商品の受発注
接続する自社資産	営業部門の業務PC
接続方法	Webブラウザ、VPNなど
取り扱う情報	顧客情報、受発注情報など
自社担当部門	営業部
システム管理担当	情報システム部
契約・利用開始日	2026年4月1日
最終点検日	2026年9月1日

これらの項目がすべて評価基準で必須とされているわけではありません。求められているのは「仕組み」の整備、つまり外部システムを継続して把握できる状態をつくることです。

3. 外部システムの情報を年1回以上点検する【2-1-1-2】

外部接続システム台帳は、一度作って終わりではありません。評価基準2-1-1-2では、2-1-1-1で把握した情報を年1回以上点検することが求められています。

少なくとも年1回は、次の点を確認します。

現在も利用しているか
契約が終了したサービスが残っていないか
新しいクラウドサービスが追加されていないか
接続方法が変更されていないか
管理担当者が変わっていないか

台帳に次の項目を設けておくと、点検記録を残しやすくなります。

点検項目	管理例
最終点検日	2026年9月1日
点検担当者	情報システム部 ○○
利用状況	利用中／利用終了
変更有無	有／無
変更内容	接続方法をVPNからWebアクセスへ変更
次回点検予定	2027年9月

「年1回確認した」という事実だけでなく、いつ・誰が・何を確認したかを記録として残すことが重要です。

年次点検の進め方

年次点検は、次のような流れで進めると、担当者が変わっても同じ品質で実施できます。

点検時期を決める：決算期や契約更新が集中する時期など、毎年同じタイミングに固定する
各部門へ照会する：台帳の該当行を各部門に送付し、利用状況や変更の有無を確認してもらう
他の情報源と突き合わせる：購買データや端末のアプリ一覧などと比較し、台帳にない外部システムがないか確認する
台帳を更新する：利用終了・新規追加・変更内容を反映する
承認・記録する：点検結果を責任者が確認し、点検日・点検者・結果を記録として保存する

点検の結果、利用を終了した外部システムが見つかった場合は、台帳から削除するだけでなく、アカウントの削除や預けていたデータの返還・削除といった後処理まで確認しておくと安心です。この後処理は、後述する2-1-2-1の「返還または廃棄の方法」とも関係します。

なお、年次点検だけに頼ると、新しいSaaSを導入してから台帳に反映されるまで最大1年近く空いてしまいます。「SaaS導入」「新規取引開始」「システム接続開始」などの社内申請と台帳更新を連動させ、年1回の点検は全体の棚卸しとして位置づける運用が現実的です。

4. 機密情報を共有する相手とは業務開始前に取扱方法を決める【2-1-2-1】

評価基準2-1-2-1では、自社の機密情報を共有する子会社または取引先との間で、業務開始前に機密情報の取扱いを取り決めることが求められています。対象となる事項は、少なくとも次のとおりです。

機密情報の定義
機密情報の利用制限
機密情報の保管方法
複製の可否
第三者提供の可否
返還または廃棄の方法

多くの企業では、これらを秘密保持契約（NDA）や業務委託契約で定めています。ただし、NDAを締結しているだけで対応完了とは限りません。

既存の契約書には「秘密情報の定義」「目的外利用の禁止」「第三者提供の禁止」は書かれていても、「保管方法」「複製の可否」「契約終了時の返還・廃棄」までは明記されていないケースがあります。

まず既存のNDAや契約書を棚卸しし、上記の事項が網羅されているかを確認します。不足があれば、契約書の改定のほか、覚書やセキュリティに関する付属文書で補う方法もあります。

既存契約の確認ポイント

既存のNDAや業務委託契約を確認する際は、次のような観点で差分を洗い出すと効率的です。

確認事項	確認ポイント	よくある不足例
機密情報の定義	何が機密情報にあたるかが明確か	「秘密である旨を明示したもの」に限定され、口頭やデータでの提供が曖昧
利用制限	利用目的が特定されているか	目的の記載が抽象的で、範囲を判断できない
保管方法	保管場所や管理方法が定められているか	保管に関する記載がない
複製	複製の可否・条件が定められているか	複製について言及がない
第三者提供	再委託先への提供を含めて定められているか	再委託時の扱いが不明確
返還・廃棄	契約終了時の返還・廃棄方法と確認手段があるか	「返還または廃棄する」のみで、方法や報告の定めがない

「機密情報の定義」を検討する際は、自社の機密区分（社外秘、関係者限りなど）と対応づけておくと、共有先ごとの取扱条件を判断しやすくなります。★3では、機密区分に応じた情報管理ルールも別の要求事項（3-1-4）で求められているため、あわせて整理しておくとよいでしょう。

また、「業務開始前」という条件にも注意が必要です。新規取引では、

契約締結 → 機密情報の取扱条件を確認 → 業務開始

という順序になるよう、社内の取引開始手続きに組み込んでおくと確実です。

5. インシデント発生時の役割・責任を取引先と定める【2-1-4-1】

評価基準2-1-4-1では、自社の機密情報を共有する子会社または取引先との間で、セキュリティインシデント発生時の双方の役割・責任を定めることが求められています。

例えば取引先で情報漏えいが起きた場合、事前の取り決めがなければ、

誰が自社へ連絡するのか
誰が影響範囲を調査するのか
どちらが顧客へ報告するのか

が曖昧になり、初動が遅れます。

実務では、次のような内容を整理しておくことが考えられます。

項目	取り決めの例
インシデントの連絡	発生または発覚時に所定の窓口へ連絡する
緊急連絡先	双方の担当部署・連絡先を定める
影響調査	発生組織が一次調査を実施し、必要な情報を共有する
ログ・証拠の保存	調査に必要なログなどを適切に保存する
被害拡大防止	必要に応じてアクセス停止などを実施する
対外的な報告	顧客・関係機関などへの報告主体を整理する
復旧対応	システム復旧などの担当範囲を整理する
再発防止	原因調査結果をもとに双方で必要な対策を検討する

初動対応の流れを具体化しておく

役割・責任を取り決める際は、項目を並べるだけでなく、時間の流れに沿って「誰が・何を」するかを整理しておくと、実際のインシデントで機能しやすくなります。

フェーズ	取引先側の対応例	自社側の対応例
発覚直後	自社の窓口へ第一報を連絡する	連絡を受け、社内の対応体制を立ち上げる
初期調査	影響を受けた情報・システムの範囲を調査する	共有していた情報の内容・件数を確認する
被害拡大防止	侵害されたアカウントの停止や通信遮断を行う	必要に応じて接続の一時停止やパスワード変更を行う
報告	調査結果を報告書として提出する	顧客・関係機関への報告要否を判断する
再発防止	原因と対策を報告し、実施する	対策内容を確認し、必要に応じて取扱条件を見直す

第一報の期限（例：発覚から○時間以内）や、報告書に含める項目をあらかじめ決めておくと、双方の認識のずれを防げます。

また、取引先がさらに別の事業者へ業務を再委託している場合は、再委託先でインシデントが起きた際の連絡経路も確認しておく必要があります。再委託先から取引先を経由して自社に報告が届くまでに時間がかかるケースもあるためです。

これらすべてが評価基準で必須項目として列挙されているわけではありません。重要なのは、インシデントが起きてから役割を決めるのではなく、事前に双方の役割と責任を明確にしておくことです。

契約書、NDA、業務委託契約、SLA、セキュリティ仕様書、インシデント対応手順書など、既存の文書を組み合わせて整理する方法も有効です。

6. SCS評価制度★3対応で準備しておきたい文書・記録

★3では、取得希望組織が要求事項・評価基準に基づいて自己評価を行い、その内容をSCSセキュリティ専門家が確認する仕組みが示されています。

そのため、ルールを定めるだけでなく、実際に運用していることを説明できる記録を残しておく必要があります。4つの評価基準については、例えば次の文書・記録が考えられます。

評価基準	準備する文書・記録の例
2-1-1-1	外部接続システム台帳、クラウドサービス一覧、取引先台帳
2-1-1-2	年次点検チェックシート、台帳の更新履歴、点検記録
2-1-2-1	NDA、業務委託契約、覚書、情報取扱規程
2-1-4-1	契約条項、インシデント対応手順、緊急連絡先一覧、責任分担表

特に注意したいのは、規程はあるが運用記録がない状態です。「外部システムを毎年点検する」と規程に書いていても、点検日や点検結果を示せなければ、実施状況を説明できません。

記録を残す際のポイント

記録は、次の点を意識して管理すると、専門家による確認の際にも説明しやすくなります。

版を管理する：台帳や規程を更新した日付と更新内容を残し、過去の版も参照できるようにする
承認者を明確にする：点検結果や規程の改定を、誰が確認・承認したかを記録する
保存場所を一元化する：契約書、台帳、点検記録が部門ごとに散在しないよう、保存場所を決めておく
評価基準との対応を示す：どの文書がどの評価基準に対応するかを一覧にしておく

特に最後の「評価基準との対応表」は、自己評価の作成時に役立ちます。評価基準ごとに「対応する文書」「保存場所」「担当者」を整理しておくと、確認を受ける際にすぐ提示できます。

規程・台帳・実施記録の3点をセットで管理することが重要です。

7. 取引先管理への対応手順（7ステップ）

4つの評価基準への対応は、次の順番で進めると整理しやすくなります。

STEP1：外部との接点を洗い出す

顧客、取引先、子会社、関係会社、クラウドサービスなど、自社のIT資産が接続している外部システムを洗い出します。

STEP2：外部接続システム台帳を作成する

システム名、外部組織、接続する自社資産、利用目的、担当部門などを一覧化します。

STEP3：機密情報の共有先を特定する

外部システムの一覧とは別に、自社の機密情報を提供・共有している子会社や取引先を確認します。

STEP4：既存の契約書を確認する

NDAや業務委託契約に、機密情報の定義、利用制限、保管、複製、第三者提供、返還・廃棄が定められているかを確認します。

STEP5：インシデント時の役割分担を確認する

通知、調査、復旧、対外報告など、双方の役割・責任が明確になっているかを確認します。

STEP6：新規取引・システム導入時の手続きに組み込む

取引やSaaSの開始時に、台帳登録と契約確認を行う仕組みを設けます。

STEP7：年1回以上棚卸しする

台帳を点検し、終了したサービスの削除や新規サービスの追加を行います。

社内の役割分担

取引先管理は、情報システム部門だけでは完結しません。関係部門の役割を明確にしておくと、対応が滞りにくくなります。

部門	主な役割
情報システム部門	外部接続システム台帳の管理、年次点検の主管、技術的な接続状況の確認
法務部門	NDA・業務委託契約の確認と改定、機密情報の取扱条件の整備
購買・調達部門	新規取引・SaaS契約時の申請受付と台帳登録の連携
事業部門	利用している外部システムの申告、点検時の利用状況の回答
セキュリティ推進部門	インシデント時の連絡体制の整備、取引先との役割分担の取りまとめ

組織の規模によっては、1つの部門や担当者が複数の役割を兼ねることもあります。その場合でも、「誰が台帳を更新し、誰が点検結果を承認するか」だけは明確にしておくことが大切です。

SCS評価制度への対応を一時的な「認証取得作業」で終わらせず、購買・契約・システム導入といった通常の業務フローに組み込むことが、継続運用のポイントです。

8. 取引先管理で注意したい4つのポイント

「取引先一覧」だけでは不十分

2-1-1-1で求められているのは、会社同士の取引関係ではなく、自社資産と外部システムの接続関係の把握です。会社名を並べただけの取引先台帳では、どのシステムに何が接続しているかを確認できません。

クラウドサービスも対象に含める

2-1-1-1の対象には、クラウドサービス提供者も明記されています。社内サーバーやVPN接続先だけでなく、業務で利用するクラウドサービスも台帳に含める必要があります。

特に、部門ごとに個別契約しているSaaSや無料のクラウドサービスは、情報システム部門が把握できていないことがあります。

なお★3では、別の要求事項（3-1-3 外部情報サービスの管理）でも、自社の機密情報を扱う外部情報サービスの管理が求められています。クラウドサービスの一覧は、両方の要求事項で活用できるよう共通化しておくと効率的です。

子会社・グループ会社も対象になる

2-1-1-1の対象には、子会社や関係会社も含まれています。グループ内のシステムは「身内」として管理の対象外にされがちですが、グループ共通の業務システムやネットワークへの接続も、外部組織のシステムとの接続として把握する必要があります。

同様に、2-1-2-1・2-1-4-1でも子会社が対象として明記されています。グループ会社に機密情報を共有している場合は、グループ内の規程や契約で取扱条件とインシデント時の役割が定められているかを確認しましょう。

NDAがあれば対応完了とは限らない

確認すべきはNDAの締結有無ではなく、要求されている取扱条件が具体的に定められているかです。既存契約をすべて作り直す必要はなく、まず現行の契約内容と要求事項との差分を確認することから始めます。

「対象範囲」を混同しない

2-1-1-1は、自社資産が接続している外部組織のシステムを把握する要求です。一方、2-1-2-1と2-1-4-1の対象は、自社の機密情報を共有する子会社または取引先との取り決めです。

つまり、すべての外部接続先に同じ契約対応が必要なわけではありません。「システム上の接続関係」と「機密情報の共有関係」を分けて整理すると、対象範囲を判断しやすくなります。

9. IT資産管理・MDMと取引先管理の関係

取引先管理の4つの評価基準は、外部システムの一覧化や契約管理といった組織的な運用が中心です。MDMやIT資産管理ツールを導入するだけで対応が完了するわけではありません。

一方で、2-1-1-1の「自社の資産が接続している外部システム」を把握するには、まず自社側の資産、つまり端末と利用者を正確に把握していることが前提になります。手作業での棚卸しには限界があるため、こうしたIT資産の可視化にはMDM（モバイルデバイス管理）ツールの活用が極めて有効です。

例えば、弊社が提供する「OPTiM Biz」では、Windows PC、Mac、iPhone・iPad、Android端末を1つの管理画面で一元管理し、次の情報を把握できます。

端末ごとのOS・OSバージョン
端末と利用ユーザー・所属組織の紐付け
端末にインストールされているアプリケーションの一覧
これらの情報のCSV出力（機器レポート・アプリケーションレポート）

こうした情報は、外部接続システム台帳の「接続する自社資産」欄を具体化する際や、年次点検で「どの部門の、どの端末・利用者が対象か」を確認する際の基礎データとして活用できます。インストール済みアプリの一覧からは、取引先指定の専用アプリやVPNクライアントなど、外部接続の手がかりを見つけられる場合もあります。

例えば年次点検では、OPTiM Bizの機器レポートとアプリケーションレポートをCSVで出力し、外部接続システム台帳と突き合わせる使い方が考えられます。台帳上は「利用終了」となっている取引先の専用アプリが、まだ端末に残っていないかを確認するといった点検にも活用できます。

また、端末・OS・ソフトウェアの情報把握は、★3の別の要求事項（3-1-1 情報機器、OS及びソフトウェアに関する情報の把握）で直接求められている対応でもあります。

ただし、取引先が提供するシステムやクラウドサービスそのものの一覧管理、NDAなどの契約管理、インシデント時の責任分担までをMDMで管理できるわけではありません。SCS評価制度への対応では、IT資産管理・契約管理・取引先管理・インシデント対応を組み合わせて運用することが重要です。