SCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）の情報が段階的に公開されるにつれ、発注企業の調達・法務・情報システム部門では「取引先にサイバー保険の加入を確認すべきか」「加入証明書を全社に求めるべきか」という論点が生じます。しかし、全取引先へ一律に証明書を求める運用は、取引先の負担を増やす割に、自社が本当に負うリスクの把握にはつながりにくいのが実情です。
この記事では、発注企業が取引先を自社事業への影響度で絞り込み、「事故を起こしにくくする対策」と「事故後に残る費用の資金手当」を取引先台帳の別の欄として分けて確認し、未加入・補償不足を即失格にせず更新確認まで回す、という一続きの審査フローの設計方法を整理します。個別の保険証券・証明書の読み方ではなく、複数の取引先をポートフォリオとして審査・更新し続ける仕組みが主題です。
サイバーセキュリティ保険の専用ページで資料請求・お見積もりを受け付けています
資料請求・お見積もりは無料、入力は約1分です
この記事でわかること
- SCS評価制度と取引先のサイバー保険加入確認の関係（2026年10月時点の事実関係）
- 取引先を影響度で層別化し、確認の深さを変える手順
- 取引先の事故が自社へ波及するシナリオの4区分と、それに照らした保険の確認軸
- 取引先台帳に置く「保険確認欄」の最小設計
- 未加入・補償不足だった場合に、取引停止以外で取り得る選択肢
SCS評価制度は取引先のサイバー保険加入を求める制度ではない（2026年10月時点）
最初に事実関係を確定させます。経済産業省と内閣官房国家サイバー統括室は、2026年3月27日にSCS評価制度の構築方針を公表しました。制度はIPA（情報処理推進機構）が運営します。
制度の狙いは、委託元にとって委託先の対策状況が可視化しづらく、各社が独自に作るチェックリストの適正性も担保しづらいこと、委託先にとっては複数の発注企業から重複した要求が届き過度な負担になること、という双方の課題を、共通基準で解消することにあります。2社間の取引契約等において、委託元が取引上の重要性に応じた段階（★）を委託先に示し、対策を促し、その実施状況を確認する利用が想定されています。
2026年10月時点で公表されている内容は、次のとおりです。
- ★3・★4は2027年3月頃の運用開始予定。★3は専門家の確認を伴う自己評価、★4は第三者評価と技術検証を伴う。
- IPAは2026年8月28日に基本規程等を、9月11日に制度基準・制度手順を、9月18日に料金設定を公開し、評価機関等の募集を開始。要求事項・評価基準の解説書は2026年10月頃の公開予定とされているが、2026年10月時点では未公開。
- 公表されている制度目的・要求事項・評価基準はセキュリティ対策の評価・可視化に関するものであり、サイバー保険への加入をSCS取得の要件とはしていない。
また国家サイバー統括室は、「評価を取得していないと商取引が規制される」「今すぐ取得しないと入札から除外される」といった説明による勧誘は制度趣旨と異なるとして、注意を呼びかけています。SCSは個社間の取引を一律に規制する制度ではなく、発注企業が自社の取引実態に合わせて使う任意の共通ものさしと捉えるのが正確です。
したがって「SCSで保険が義務化される」という前提で社内ルールを作るのではなく、SCSという共通基準が整うこの機会に、自社の取引先審査で保険をどう扱うかを自ら設計する、という順序で考えるのが実務的です。
発注企業の審査で分けるべき2つの欄：事故を起こしにくくする対策と、事故後に残る費用
取引先審査に保険確認を組み込むときに、最初に決めておくべきことが1つあります。それは、次の2つを取引先台帳の同じ欄で扱わないということです。
| 確認する対象 | 確認手段の例 | わかること |
|---|---|---|
| 事故を起こしにくくする対策（発生可能性の低減） | SCSの段階、既存の認証、質問票、証跡 | 取引先がどの水準の対策を実施しているか |
| 事故後に残る費用・賠償・休業等の資金手当（残余リスクの手当） | サイバー保険の加入状況と補償内容 | 事故が起きた後の費用を誰がどこまで負担できるか |
対策をどれだけ積み上げても事故の可能性はゼロにはならず、残った部分が現実になったときに、契約内容に応じて資金面を手当てするのが保険です。逆に、保険に加入していることは対策の代わりにはなりません。この2つを1つの「セキュリティ評価」欄にまとめてしまうと、「SCSマークがあるから安心」「保険に入っているから対策は問わない」という、方向の異なる2つの誤りが起きます。
両者の役割分担をより詳しく整理した内容は、SCS評価制度とサイバー保険の役割の違いで解説しています。本記事では、この分離を前提に、審査フローの設計へ進みます。
全取引先に一律で加入証明書を求めない：影響度による取引先の絞り込み
審査フローの第1段階は、「誰を調べるか」を決めることです。取引先の数が数百社規模になる企業で、全社に同じ質問票と加入証明書を求める運用は、回収・更新の負荷で早晩回らなくなります。
IPAの「プラクティス9-1」では、社内の委託元部署への調査によって主要取引先を洗い出し、インターネット利用の有無や委託業務の内容からサイバーリスクのある取引先を特定し、必要最低限の質問を送って回答と証跡を総合評価し、懸念を一覧化して経営者へ報告する、という進め方が事例として示されています。まず台帳を作り、母集団を絞るという順序です。
層別化に使う4つの軸
- 自社事業への影響：その取引先が止まったとき、自社のどの製品・サービス・顧客対応が止まるか。
- システム接続・アクセス権限：自社ネットワークやクラウド環境への接続、アカウントや権限の付与があるか。EDI・API連携、リモート保守なども含む。
- 預託情報：個人情報、顧客情報、設計・技術情報など、自社が預けている情報の種類と量。
- 代替可能性・復旧時間：他社への切り替えが可能か、切り替えにどれだけの時間を要するか。単独調達か複数調達か。
この4軸で取引先を「重要」「標準」「低」といった層に分けます。層の数は3つ程度で十分機能します。重要なのは精緻さではなく、確認の深さを層ごとに変えると決めることです。
なお、経済産業省が示すパートナーシップの考え方でも、発注側が一律に過大な要求を課すのではなく、取引の実態に応じた要請とすることが前提とされています。層別化は、自社の負荷を下げる手段であると同時に、取引先との関係を保つための前提でもあります。
重要取引先の対策状況をどこまで確認するか（SCSの段階・既存認証・質問票・証跡）
第2段階は、絞り込んだ層ごとに対策の確認手段と深さを設計することです。
| 層 | 確認手段の例 |
|---|---|
| 重要（停止・情報漏えいが自社事業に直結） | 取引上の重要性に応じたSCSの段階の提示、既存認証の確認、個別質問票、必要に応じた証跡の確認、契約上の措置 |
| 標準 | 共通質問票、既存認証やSCSの段階の申告、契約条項による最低要件の設定 |
| 低 | 契約条項による最低要件と、事故時の通知義務の設定を中心とする |
SCS評価制度の★3・★4の運用が始まれば、この「対策の確認」を各社独自のチェックリストから共通基準へ寄せられる余地が広がります。ただし注意点があります。SCSマークの取得は、その取引先で事故が起きないことの保証ではありません。評価は一定時点の対策状況を示すものであり、取得後に環境や業務範囲が変われば実態も変わります。台帳上は「対策の確認手段と確認時点」を記録する欄として扱い、「リスクが消えた」という結論を書き込まないことが大切です。
取引先自身がどのように★3・★4の取得へ準備を進めるか（要求事項の分類や申請の実務）は、SCS評価制度の★3・★4取得に向けた準備で扱っています。発注企業として取引先へ案内する際の参考にしてください。
取引先の事故が自社へ波及するシナリオを分ける：供給停止／調査・復旧／通知・顧客対応／第三者賠償
第3段階は、保険を確認する前に行う作業です。「取引先で事故が起きたとき、自社に何が起きるのか」を損失の型で分けておかないと、保険の内容を見ても十分かどうかを判断できません。
サプライチェーンを経由するリスクの重みは、統計にも表れています。IPA「情報セキュリティ10大脅威 2026」（組織編）では「サプライチェーンや委託先を狙った攻撃」が2位に選出され、8年連続の選出となりました（順位は危険度そのものを示すものではありません）。また、全国4,191社を対象としたIPAの2024年度中小企業実態調査では、2023年度に被害を受けたと回答した企業群において、「特になし」を除くと約7割で取引先への何らかの影響（サービスの停止・遅延、補償の負担、原因調査・復旧費用の発生など）があったと報告されています。これは全中小企業の7割という意味ではなく、被害を受けた企業群についての結果ですが、事故が取引関係を通じて波及しやすいことを示しています。
波及シナリオの4区分
- 供給停止：取引先のシステム停止により、部材・データ・サービスの提供が止まり、自社の生産・納品・サービス提供が遅延または停止する。
- 調査・復旧：自社側でも影響範囲の調査、ログ解析、接続遮断、システムの復旧・再構築が必要になる。外部専門家の費用が発生する。
- 通知・顧客対応：預託していた情報が漏えいした場合の本人への通知、監督官庁への報告、コールセンター設置、告知、見舞い対応などが発生する。
- 第三者賠償：自社の顧客や取引先から、納品遅延や情報漏えいに関する損害賠償を請求される。
この4区分を重要取引先ごとに当てはめ、どの型の損失が、どれくらいの期間・規模で発生し得るかを粗くでも書き出します。ここが定まっていない状態で加入証明書だけを集めても、「加入している／していない」以上の情報にはなりません。
シナリオに照らして保険を確認する：加入の有無の先にある確認範囲
第4段階が保険の確認です。ここで押さえるべきは、証明書に「サイバー保険」と記載があることは、自社が想定した損失が手当てされていることを意味しないという点です。補償内容、支払限度額、免責金額、付帯サービスは、保険会社・プラン・約款・契約条件によって異なります。
そのため、重要取引先については、加入の有無に加えて次の軸を必要な範囲で確認します。
- 保険期間：現在有効か。いつ満期を迎えるか。
- 被保険者・対象業務：契約当事者である法人が被保険者に含まれるか。自社との取引に係る業務が対象業務の範囲に含まれるか（グループ会社名義、別事業部の契約というケースがある）。
- 主な損害区分：前節の4区分（供給停止／調査・復旧／通知・顧客対応／第三者賠償）に対応する損害が、契約上どのように扱われているか。
- 支払限度額・免責金額：自社が想定した損失の規模との関係。1事故あたりか期間中通算か。
- 地域・準拠：海外拠点や海外での情報処理が関わる取引の場合の扱い。
- 事故通知・初動連携：事故時に誰から誰へ、どのタイミングで連絡が来るか。
この確認は、取引先に新たな書類作成を強いるためのものではありません。保険会社が発行する加入証明書や契約内容の概要で確認できる範囲は様式によって異なるため、必要な項目は取引先を通じて個別に確認します。「何を見るか」を自社側が先に決めておくことが、取引先の負担を最小にする近道です。
証明書そのものの読み方、すなわち記載項目の見方、再委託先の扱い、海外での情報処理が絡む場合の論点などは、委託先の情報漏えい保険の加入証明書で確認したい項目で詳しく扱っています。
取引先台帳に置く「保険確認欄」の最小設計
ここまでの内容を、運用可能な形に落とし込みます。取引先台帳に新設するのは、以下の高位項目だけで足ります。証明書の細目をすべて台帳へ転記する必要はありません。
| 欄 | 記録する内容 | 置く理由 |
|---|---|---|
| 加入状況 | 加入／未加入／確認中 | 母集団の把握と、確認漏れの検出 |
| 保険期間・確認日・次回確認日 | 保険期間の満了時期、直近の確認日、次に確認する日 | 保険は満期で切れる。確認の鮮度を管理する |
| 対象法人・対象業務の該当 | 当該取引が被保険者・対象業務の範囲に含まれるか | 加入していても当該取引が範囲外というずれを検出する |
| 想定事故への対応 | 4区分のうち、どの損害区分が契約上扱われているか | 自社の想定損失と契約内容を突き合わせる |
| 支払限度額・免責金額 | 限度額と免責金額、自社の想定損失との関係の所見 | 「加入あり」だけでは判断できない部分を残す |
| 事故通知・初動連携の窓口 | 取引先側の連絡窓口、自社側の受け手部署 | 事故時に最も効く情報。平時に決めておく |
| 不足時の対応方針と決裁者 | 不足・未加入と判断した場合の方針、判断した部署・決裁者 | 判断の所在を残し、現場任せにしない |
ここで意図的に置いていないものがあります。「限度額◯億円以上」といった一律の基準値です。必要な水準は、事故シナリオ、契約上の責任分担、自社への波及の大きさ、取引先の財務耐力によって変わるため、一律の数値を台帳の合否基準にすると、実態と合わない判断を量産することになります。
未加入・補償不足を自動失格にしない：リスク低減、契約上の責任分担、代替調達、自社側の手当
第5段階は、確認結果をどう扱うかです。ここで「保険あり／なし」を合否判定にしないことが、この審査フローを機能させる分かれ目になります。
IPAのプラクティス9-1でも、取引先の対策に懸念があっても現場だけで直ちに取引先を変更することは困難な場合があるため、懸念を一覧化して組織としてリスク対応方針を検討する、という流れが示されています。保険についても同じ構造です。未加入や補償不足がわかった時点で取引を止めるのではなく、次の選択肢を組み合わせて判断します。
- リスク低減：取引先と対策の改善計画を合意する。接続経路や権限を絞る、預託する情報の範囲を減らす、といった自社側の設計変更も含む。
- 契約上の責任分担：事故時の通知義務、協力義務、責任の範囲や上限、再委託の条件を契約で明確にする。
- 代替調達：単独調達の解消、代替先の確保、在庫やバックアップ手段による復旧時間の短縮。
- 自社側の手当：取引先に手当てを求めきれない部分について、自社のサイバー保険の補償範囲を見直す、あるいは自己保有（自社で負担する）と決める。
4つ目が特に見落とされがちです。取引先の保険で埋まらない部分は、放置すれば自社が負うことになります。台帳で残余リスクが可視化されたら、それを自社側の保険設計へ戻す。ここまでを一続きにして、初めて審査が経営判断につながります。
取引先への要請の出し方：層別化と協議を前提にする
審査設計と同じくらい重要なのが、要請の出し方です。経済産業省が示すパートナーシップの考え方では、発注側がセキュリティ対策を求める場合に、取引先との対話や必要な価格交渉を通じて円満に合意する進め方が想定事例として示されています。
実務上のポイントは3つです。
- 対象を層別化して伝える：全取引先へ同じ文面を一斉送付せず、なぜその取引先に確認が必要なのか（接続がある、情報を預けている、代替が難しい等）を示す。
- 追加コストと導入期間を協議する：対策の導入や保険の手配には費用と時間がかかる。要請と同時に、期限と負担のあり方を協議のテーブルに載せる。
- 求める理由と使い道を説明する：確認結果を取引の可否ではなくリスク対応方針の検討に使うと伝えることで、正確な回答が返りやすくなる。
SCS評価制度が整備される背景には、各社独自の要求が重複して委託先の負担になっているという課題認識があります。要請の設計は、制度の趣旨に沿って負担を減らす方向で行う。これが、長く続けられる審査運用の条件です。
一度確認して終わりにしない：更改・業務範囲変更・再委託・事故発生時の再確認
最後の段階は更新です。取引先審査で見落とされやすいのは、新規採用時に一度確認して、そのまま数年が過ぎることです。保険は満期で切れ、対策状況は環境変化で変わります。
再確認の契機は、あらかじめ列挙しておきます。
- 契約の更改時：更新のタイミングに確認を紐付ける。
- 保険期間の満了時：台帳の「次回確認日」から逆算して確認する。
- 業務範囲・接続・権限の変更時：預託情報が増えた、接続経路が追加された、といった変化は層別化の結果自体を変える。
- 再委託の発生・変更時：実際の作業者が変わる場合、確認対象も変わる。
- 事故発生時：自社に影響がなかった事故でも、対応と手当ての実態を確認する好機になる。
これらを台帳の「確認日・次回確認日」欄に落とし込めば、審査は一過性のプロジェクトではなく、回り続ける仕組みになります。層別化した重要取引先だけでも、この運用が回っている状態を目指すのが現実的です。
この記事の前提と留意事項
- SCS評価制度はサイバー保険への加入を義務付ける制度ではありません。SCSマークは事故が起きないことの保証ではなく、保険加入も保険金支払を保証するものではありません。
- 加入証明書の存在や支払限度額の記載のみをもって、自社の想定損失が手当てされていると判断することはできません。
- 補償内容、引受条件、保険料、保険金の支払は、商品・約款・契約条件および個別事情によって異なります。
- 必要な補償の水準は、事故シナリオ、契約上の責任分担、自社への波及、取引先の財務耐力等によって変わるため、一律の基準額は示していません。
- 本記事の制度情報は2026年10月時点の公表内容にもとづきます。
那由他保険テクノロジーズが取引先のサイバーリスク審査と保険の設計でご支援できること
ここまでの審査フローのうち、那由他保険テクノロジーズがご一緒できるのは「事故後に残る費用を、誰がどこまで負担できるようにしておくか」の設計です。具体的には、次の内容をお手伝いしています。
- 取引構造と事故シナリオの整理：どの取引先が止まると自社の何が止まるのか、どの情報を誰に預けているのかを、取引の実態から一緒に洗い出します。
- 残余リスクの構造分析：重要取引先ごとに、対策で下げきれずに残る損失を、供給停止・調査復旧・通知対応・第三者賠償の型に分けて構造化します。
- 補償ギャップ分析：想定した損失と、現在の自社の保険契約・取引先側の手当てを突き合わせ、どこが空いているかを可視化します。「取引先の保険で埋まらず、自社が負っている部分」を明確にします。
- 補償条件の比較と保険プログラム設計・調達支援：ギャップを埋める方法を、補償条件の比較、契約の組み替え、自己保有との切り分けを含めて検討し、適切な保険の調達までご支援します。
- 継続的な確認運用の論点整理：取引先台帳の保険確認欄をどう設計し、更改・変更・満期のタイミングでどう回し続けるか、保険契約管理の観点から論点を整理します。
ご相談いただいた後には、次の判断材料が手元に残ります。
- 数ある取引先のうち、どこを重点的に確認すべきか
- 取引先で事故が起きたとき、どの損失を誰が負担することになるのか
- 自社側と取引先側の補償ギャップがどこにあるか
- その結果として、契約の変更や新たな保険の調達が必要かどうか
なお、当社はセキュリティ監査やSCSの認証、法務上の判断を行うものではありません。保険・リスクの側面から、社内の情報システム部門や顧問弁護士の検討と噛み合う形の材料をご用意します。
「取引先のリストはあるが、どこから手を付ければよいかわからない」「自社の保険が取引先の事故に対応しているのか把握していない」——その段階からで問題ありません。資料が揃っていなくても、現在の取引の状況をうかがうところから一緒に整理していきます。まずはお気軽にお問い合わせください。
参考情報（出典・2026年10月時点）
- 経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」
https://www.meti.go.jp/policy/netsecurity/scs.html - IPA「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」
https://www.ipa.go.jp/security/scs/index.html - IPA「SCS評価制度の詳細情報」
https://www.ipa.go.jp/security/scs/details.html - IPA「要求事項・評価基準」
https://www.ipa.go.jp/security/scs/requirements-criteria.html - IPA「制度規程・委員会」
https://www.ipa.go.jp/security/scs/regulation-advisory-committeess.html - 内閣官房 国家サイバー統括室「SCS評価制度に係る不適切な勧誘に御注意ください」
https://www.cyber.go.jp/pdf/news/press/20260427_supply-chain-security.pdf - IPA「情報セキュリティ10大脅威 2026」
https://www.ipa.go.jp/security/10threats/10threats2026.html - IPA「2024年度 中小企業における情報セキュリティ対策に関する実態調査」
https://www.ipa.go.jp/security/reports/sme/sme-survey2024.html - IPA「プラクティス9-1 サイバーセキュリティリスクのある委託先の特定と対策状況の確認」
https://www.ipa.go.jp/security/economics/practices_navi/practice237.html - 経済産業省「サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップの構築に向けて」
https://www.meti.go.jp/policy/netsecurity/partnership2.html - 日本損害保険協会「サイバー保険」
https://www.sonpo.or.jp/sme_insurance/cyber-hoken/
更新に関する注意：SCS評価制度の運用開始時期、費用、申請方法、要求事項・評価基準の解説書、指定機関等は今後更新される可能性があります。本記事は2026年10月時点で参照した公表情報にもとづいており、基本規程等は2026年8月28日、料金設定は2026年9月18日に公開済みです。最新の内容は各出典元でご確認ください。