結論:自社をいくら固めても、委託先を「契約で縛り、確認する仕組み」がなければ横から入られる

自社のEDRもMFAもバックアップも整えた。それでも侵入されるとしたら、入口は自社ではなく、委託先・子会社・取引先と共用しているツールである。IPA「情報セキュリティ10大脅威 2026(組織編)」では「サプライチェーンや委託先を狙った攻撃」が2位に位置づけられており、攻撃者にとって、守りの固い本体を正面から崩すより、統制の緩い周辺から入るほうが効率がよい。それにもかかわらず、多くの業務委託契約には秘密保持条項しかなく、MFA・パッチ適用・インシデント通知義務・監査権といったセキュリティ要件が入っていない。これが本稿で扱う失敗である。

  • サプライチェーン攻撃の入口は委託先・子会社・共用ツールであり、自社の対策だけでは防げない。
  • 契約にセキュリティ要件がなければ、平時に確認を求める根拠も、有事に責任を問う根拠もない。
  • チェックシートは「はい」と書いて返ってくるだけで形式化する。証跡の添付と更新の仕組みが要る。
  • 要件は契約に書いて終わりではなく、年次の点検・是正フォローまで回して初めて機能する。
  • 発注側が中小の場合は逆に、自社が大手取引先の「踏み台」と見なされ、契約を切られるリスクがある。

この連載は「セキュリティ対策の失敗図鑑」として、対策が破られる典型パターンを一つずつ分解している。第4回となる本稿は、自社の意識の問題を扱う回や自社のID管理を扱う回とは視点を変え、「統制が自社の外にある相手」をどう縛るかに絞る。自社が狙われる前提を持てないという「うちは狙われない」正常性バイアスの失敗でも、自社内の退職者アカウント・共有ID放置の失敗でもなく、相手方の統制を契約とガバナンスで担保する論点である。また、npmやVS Code拡張などソフトウェア経由の侵入事例はサプライチェーン攻撃2026年H1事例集約で横断整理しており、本稿は狭義のサプライチェーン、すなわち取引先・委託先・子会社という「組織経由の侵入」を契約で縛る側から扱う。


なぜ「契約で縛らない」委託先管理は破られるのか

秘密保持条項はあっても、セキュリティ要件がない

業務委託契約の多くには秘密保持条項(NDA相当)が入っている。だがNDAが縛るのは「漏らさない」という結果の約束であって、「漏れないように何をするか」という手段は縛っていない。委託先がMFAを使っているか、VPN機器のパッチを当てているか、退職者のアカウントを消しているか——これらは契約に書かれていなければ、確認を求める根拠すらない。実際に委託先経由で侵入されたとき、契約上の義務がなければ責任の所在も曖昧になり、是正を求める交渉も一からやり直しになる。

チェックシートが「書いて返す」だけの儀式になっている

委託先管理の定番であるセキュリティチェックシートは、運用を誤ると最も形式化しやすい仕組みである。年に一度シートを送り、全項目「はい」で返ってくる。誰が記入したのか分からず、裏付けの証跡もなく、回答が実態と違っていても気づけない。受け取る側も、回収して保管した時点で「委託先管理はやっている」と安心してしまう。チェックシートそのものが悪いのではなく、証跡の添付を求めず、回答を検証する手段を持たないまま回すことが失敗である。

確認と是正の仕組みがなく、契約が「書いて終わり」になる

仮に契約へ要件を書き込んでも、それを確認する仕組みがなければ実効性はない。要件違反が見つかったときに是正を求める手順、是正されない場合の扱い、インシデント発生時に通知が来ることの担保——ここまで設計されていないと、契約条項は有事の損害賠償の根拠にはなっても、侵入を防ぐ平時の統制にはならない。守りたいのは賠償金ではなく事業であり、契約は「事故後に勝つため」ではなく「事故を起こさせないため」に書く必要がある。

実例とデータ:10大脅威2位の現実と、大手事案が示した波及

IPAが2026年1月に発表した「情報セキュリティ10大脅威 2026(組織編)」では、ランサムウェアによる被害が11年連続の1位、それに次ぐ2位が「サプライチェーンや委託先を狙った攻撃」である。サプライチェーン攻撃では、大手企業への侵入手段としてセキュリティが手薄な取引先が狙われる。順位の解説と中小企業の優先対策はIPA情報セキュリティ10大脅威2026の解説記事で整理している。

大手の実例として、村田製作所では2026年2月28日に社内情報共有システムへの不正アクセスの可能性を検知し、3月1日に外部専門機関と調査を開始、3月6日の第一報を経て、4月6日の第二報で顧客・取引先情報および従業員の個人情報の流出が確認された。基幹システム(購買・生産・出荷)への影響はなかったが、注目すべきは漏えい対象に「取引先情報」が含まれた点である。1社への侵入が、その会社と取引する多数の企業の情報を巻き込む——これがサプライチェーンの怖さであり、自社が委託先に預けた情報も、委託先が破られれば同じ立場に置かれる。事案の詳細と製造業向けの点検項目は村田製作所サイバー攻撃と中堅製造業30日チェックリストでまとめている。

この事案を受けるまでもなく、大手製造業を中心にサプライヤーへのセキュリティ基準の要求は厳しくなっており、体制が不十分な場合に新規取引の審査に落ちるケースも出始めている。委託先を縛る側の論点は、そのまま「縛られる側」の論点でもある。

発注側が中小の場合:「自社が踏み台」と見なされ契約を切られるリスク

ここまで「委託先をどう縛るか」を述べてきたが、自社が中小・中堅であれば、視点を反転させる必要がある。大手取引先から見れば、自社こそが「セキュリティが手薄な取引先」、つまり踏み台の候補である。中堅サプライヤーは大手の取引審査やSBOM提出要請の最前線に立たされており、要求に答えられなければ、攻撃を受ける前に取引のほうを失う。

踏み台にされた場合に想定されるのは、取引先の機密情報の漏えいによる損害賠償、取引関係の断絶による売上の大幅減少、評判の毀損による新規取引の困難化である。つまり中小にとってサプライチェーン攻撃は「自社のデータが暗号化される」リスクである以上に、「取引資格を失う」リスクとして現れる。

備えの方向は明確である。取引先から要求される前に、後述する最低要件(MFA・パッチ・アカウント管理・通知体制)を自社で満たし、チェックシートに「はい」と書くだけでなく、設定画面や台帳といった証跡で答えられる状態を作っておく。審査に証跡で答えられる会社と、回答だけの会社の差は、取引先側が確認の仕組みを強化するほど大きくなる。

委託先に求める最低要件と、契約条項チェックリスト

委託先に求める最低要件(表)

完璧な要求リストを作って委託先と揉めるより、侵入経路として実際に多い領域に絞った最低要件を、証跡の確認方法とセットで定めるのが現実的である。

領域最低要件確認方法(証跡)
認証外部からアクセス可能な全アカウントにMFAを適用する設定状況の画面証跡・対象アカウント台帳
脆弱性対応VPN機器等の重大な脆弱性修正をあらかじめ定めた期限内に適用する適用記録・対象機器一覧の提出
アカウント管理退職・契約終了時の即時削除、共有IDの禁止アカウント台帳と在籍情報の突合
接続管理自社システムへ接続するアカウント・経路の限定と最小権限接続経路・権限の一覧
通知義務インシデントの兆候を検知したら、定めた期限内に第一報を入れる連絡フロー文書・窓口責任者の指名
再委託再委託は事前承諾制とし、同等の要件を課す再委託先一覧の提出
データ管理預けたデータの保管場所の特定、契約終了時の返却・消去保管場所一覧・消去証明

ポイントは、すべての項目に「確認方法」を付けていることである。証跡を出せない要件は、形式化したチェックシートと同じ運命をたどる。

契約条項に入れるべき項目(チェックリスト)

上の要件を実効化するために、契約・覚書に次の項目が入っているかを点検したい。

  • セキュリティ要件(MFA・パッチ適用期限・アカウント管理・接続管理)を別紙仕様として契約に添付しているか。
  • インシデント発生時の通知義務(第一報の期限・通知先・通知すべき内容)を定めているか。
  • 監査権(報告徴求、必要に応じた立入またはリモートでの確認)を定めているか。
  • 再委託の事前承諾制と、再委託先へ同等の要件を課す義務を定めているか。
  • 契約終了時のデータ返却・消去と、消去の証明を定めているか。
  • 要件違反時の是正要求、是正されない場合の契約解除・損害賠償の根拠条項があるか。
  • チェックシートの回答に証跡の添付を求め、年1回以上の更新を定めているか。
  • 委託先側の窓口責任者と、自社側で回答を確認する責任者を決めているか。

既存契約に後から差し込む場合は、契約更新のタイミングで覚書・別紙として追加するのが通りやすい。条項の法的な書きぶりは顧問弁護士の確認を前提としつつ、「何を要求するか」の中身はセキュリティ側で先に固めておく必要がある。

契約は入口にすぎない——確認のサイクルまで設計する

契約と要件表が揃ったら、残るは運用である。年1回のチェックシート更新と証跡確認、指摘事項の是正期限の管理、重要度の高い委託先(基幹システムの保守、顧客データを預ける先)への監査権の行使——この確認サイクルを回す担当と頻度を決めて、初めて委託先管理は形式から実効に変わる。重要委託先は四半期ごと、一般委託先は年1回、重大な脆弱性・不正アクセス・再委託先変更が起きた場合は都度レビューとし、是正期限は重大項目30日、その他90日を目安に置くと運用に落としやすい。自社だけで委託先の重要度の格付けや要件の線引きが難しい場合は、委託先を含めた体制全体の点検としてセキュリティコンサルティングで扱っており、自社側の対策状況も含めた全体像はセキュリティ事業トップから確認できる。

関連記事

よくある質問

Q1. 秘密保持契約(NDA)を結んでいれば、委託先経由の侵入にも備えられているといえるか。

いえない。NDAが定めるのは「漏らさない」という結果の義務であり、MFAやパッチ適用といった「漏れないようにする手段」は縛っていない。委託先の対策状況を平時に確認する根拠もNDAからは生まれない。セキュリティ要件・通知義務・監査権を別紙仕様や覚書として契約に組み込み、確認方法とセットで運用する必要がある。

Q2. 委託先に送っているセキュリティチェックシートは、どこまで信用してよいか。

回答だけのチェックシートは検証できないため、信用の根拠にはならない。全項目「はい」で返ってきても、記入者も裏付けも分からなければ実態は不明のままである。重要な項目には設定画面や台帳などの証跡の添付を求め、年1回以上更新させ、重要度の高い委託先には監査権に基づく確認を組み合わせるのが現実的な線である。

Q3. 当社は発注側ではなく受注側の中小企業だが、何から手を付ければよいか。

取引先から要求される前に、侵入経路として狙われやすい領域の最低要件を自社で満たすことである。具体的には、外部からアクセスできる全アカウントへのMFA適用、VPN機器等の重大パッチの期限内適用、退職者アカウントと共有IDの整理、インシデント時の連絡体制の文書化が出発点になる。あわせて、チェックシートに証跡で答えられる状態を作っておくと、取引審査での評価が変わる。

Q4. 既存の委託契約にセキュリティ条項が入っていない場合、後から追加できるか。

できる。契約更新のタイミングで、セキュリティ要件を別紙仕様または覚書として追加するのが一般的な進め方である。期中であっても、重要なデータを預けている委託先には覚書での合意を打診する価値がある。条文の書きぶりは顧問弁護士の確認を前提とし、要求する要件の中身と確認方法はセキュリティ側で先に固めてから法務に渡すと、形式だけの条項になりにくい。


委託先・子会社・取引先まで含めた体制の点検は、自社単独では線引きと優先順位の判断が難しい領域である。委託先の格付け、最低要件の設計、契約条項への落とし込み、年次の確認サイクルづくりまで一気通貫で整理したい場合は、無料相談から現状の委託先一覧と契約の状況を持ち込んでいただきたい。

出典