目次
はじめに:自社が攻撃されていなくても、事業が止まる時代に
2026年10月7日、ソフトバンクグループ子会社のIDCフロンティアが提供するクラウドサービス「IDCFクラウド」が、第三者によるランサムウェア攻撃を受けたと公表しました。影響は、同サービスを契約する495の企業や自治体に及んでいると報じられています。契約先の中には、Webサイトが閲覧できなくなった自治体や、商品の入出荷ができなくなった企業もありました。自社が直接攻撃を受けたわけではないのに、使っていたクラウドが止まったことで、業務が止まってしまう。そんな事態が現実になったのです。
同じ日、個人情報保護委員会は「大規模な漏えい等事案を踏まえた対応について(注意喚起)」を公表しました。この注意喚起は特定の事案を名指ししたものではありませんが、不正アクセスによる個人データの漏えいが相次いでいることを受け、事業者に安全管理措置の見直しを求める内容です。そして、そこで取り上げられた事例には、委託先やクラウドサービス、グループ会社との関係に関わるものが複数含まれています。
ここで大切になるのが、「契約書」です。委託先やクラウド事業者との契約書に、セキュリティ対策の範囲、事故が起きたときの報告、データの返却と消去、責任の分担などが、どこまで書かれているか。それが、事故が起きたときの被害の大きさや、その後の対応のしやすさを左右します。
本記事では、2026年10月に起きた2つの動きを整理したうえで、委託先やクラウドの事故に備えるために、契約書で見直したい8つの条項、標準約款が変えられないときの対応、事故が起きたときの初動、平時の委託先管理の進め方を解説します。法務や総務、情報システム、購買の担当者が、明日から使える確認ポイントをまとめました。
※本記事の内容は、2026年10月29日時点の報道と公表資料に基づいています。事案の状況は更新される可能性があるため、最新の情報は各社・各機関の公式発表でご確認ください。
2026年10月に何が起きたのか:2つの動きを整理する
まず、事実関係を整理しておきましょう。ここで取り上げる2つの動きは、同じ日(10月7日)に起きていますが、別々のものです。
時系列で見る主な動き
| 日付 | 動き | ポイント |
|---|---|---|
| 2026年10月7日 | IDCフロンティアの「IDCFクラウド」で障害が発生。同日中に、原因が第三者によるランサムウェア攻撃だと公表された | 東日本リージョン1で発生し、影響は契約する495の企業・自治体。被害拡大を防ぐためネットワークを切り離してシステムを停止し、他のリージョンも安全確認のため、利用者向けの管理コンソールを停止 |
| 2026年10月7日 | 個人情報保護委員会が「大規模な漏えい等事案を踏まえた対応について(注意喚起)」を公表 | 大量の個人データを扱う事業者などに、安全管理措置の見直しを促す内容。特定の事案を名指ししたものではない |
| 2026年10月9日 | 政府が相次ぐ情報漏えいに注意喚起し、委託先の管理も要請したと報じられた | 国家サイバー統括室や総務省なども、不正アクセスによる漏えい等を踏まえた注意喚起を公表 |
| 2026年10月18日まで | IDCフロンティアが、第1報から第6報まで順次発表 | 状況は更新されているため、最新の発表を確認する必要がある |
IDCFクラウドの障害で見えたこと
この事案で多くの人が注目したのは、「契約している企業・自治体の先」にまで影響が広がった点です。報道によると、契約先のサービスを使っている住民や事業者にも影響が及び、たとえばニッスイは、グループ会社の日水物流で、システム障害により商品の入出荷ができなくなったと発表しました。同社は原因を、委託先のデータセンターへの第三者による不正アクセスとみられるとしています。
また、同社の発表を受けた報道では、一部の顧客のデータは復旧が困難とされています。なお、「495」という数字は、障害の影響を受けた契約先の数であり、情報漏えいが確認された組織の数ではない点には注意が必要です。
個人情報保護委員会の注意喚起は「特定の事案への対応」ではない
個人情報保護委員会の公表文は、「近時」の大規模な漏えい等事案に接していることを背景に、事業者の安全管理措置の改善を促すものです。特定の事案名は書かれていません。したがって、「IDCFクラウドの事案を受けた注意喚起」と断定するのは適切ではありません。ただし、注意喚起で示された事例の内容は、今回のようなクラウドや委託先の事故への備えを考えるうえで、非常に参考になります。次の章で詳しく見ていきましょう。
個人情報保護委員会の注意喚起:契約実務に関わる3つのポイント
個人情報保護委員会が2026年10月7日に公表した資料(公表資料、改訂されたWARNING~不正アクセスによる個人データ漏えい防止のための注意喚起~)から、契約や委託先管理に関わるポイントを3つ取り上げます。
ポイント1:措置が不十分だと、3つの条文の違反になり得る
WARNING資料では、報告された事案を分析し、問題点を九つの事例に類型化したうえで、これらへの措置が十分でない場合、次の違反と判断される可能性があると指摘しています。
- 安全管理措置(個人情報保護法第23条)
- 従業者の監督(同法第24条)
- 委託先の監督(同法第25条)
また、対策はどれか一つを講じればよいものではなく、多層的に講じる必要があるとされています。事例の多くは、委託先などを含め、事業者の内外にある複数の組織や部署が関係するため、技術的な対応にとどまらず、経営層を交えて組織的に対応することが必要だとも述べられています。
なお、個人情報保護委員会は、ガイドラインの「手法の例示」について、現代化を含めた見直しを予定しており、内容の確定は来年4月を予定していると説明しています。今回の資料では、見直し予定の内容を先取りして示しています。「講じなければならない措置」は、従わないと法違反と判断される可能性がありますが、「手法の例示」は、必ずしもすべてを講じなければならないわけではないとされています。
ポイント2:九つの事例には、契約や委託先の問題が多く含まれる
WARNING資料が示す九つの事例は、次のとおりです。
| 事例 | 内容 | 契約・委託先管理との関わり |
|---|---|---|
| 1 | 脆弱性が放置された事例 | システム保守の契約に脆弱性対応が含まれていない、役割分担が決まっていないことが原因の一つ |
| 2 | 脆弱性への対応が遅れた事例 | グループ会社間での対応の役割分担が不明確 |
| 3 | 不正ログインの事例 | 認証強度、ログの保存・監視のルール |
| 4 | グループ会社や海外拠点が狙われた事例 | 拠点や貸与機器を含めたIT資産の把握 |
| 5 | グループ会社間のアクセス制御不備があった事例 | 業務上必要な範囲に絞ったアクセス制御 |
| 6 | 個人領域に保存したデータの漏えい事例 | 個人データの取扱いに関する規律・ルールの整備 |
| 7 | グループ会社への監督が不十分な事例 | グループ会社への委託でも、通常の外部委託先と同じ基準で監督 |
| 8 | 利用するクラウドサービスからの漏えい事例 | クラウド利用を委託と考えず、監督していなかった |
| 9 | APIが悪用される事例 | APIの棚卸し、認証・認可、アクセス回数の制限 |
ポイント3:不要になった個人データは、遅滞なく消去する
個人情報保護法第22条は、利用する必要がなくなった個人データを、遅滞なく消去するよう努めなければならないと定めています(法令で保存期間が定められている場合を除く)。個人情報保護委員会は、こうした対応が徹底されず、漏えい等の事案がより深刻化した事例にも接しているとして、保管している個人データの必要性を、法令等の根拠とともに確認することを、あらためて注意喚起しています。
これは、委託先やクラウドに預けたデータにも当てはまります。契約が終わったあとも、委託先にデータが残り続けていないか。契約書に、返却や消去の取り決めがあるか。この点は、のちほど契約条項の見直しのなかで取り上げます。
見落としやすい落とし穴:「グループ会社」「クラウド利用」は監督の対象外?
委託先管理というと、外部の業者への委託を思い浮かべがちです。しかし、個人情報保護委員会のWARNING資料が取り上げた事例のなかには、「監督は不要だ」という思い込みが原因になったものがあります。特に注意したいのが、次の2つです。
落とし穴1:グループ会社だから、監督は不要という思い込み(事例7)
資料で紹介された事例では、親会社がグループ子会社の従業者等の個人データを、人事システムで一括して管理していました。ところが、親会社の安全管理措置の不備が原因で、子会社の個人データが漏えいしました。委託元である子会社は、委託先である親会社の取扱状況を把握するなどの、必要かつ適切な監督を行っていなかったとされています。
原因として挙げられているのは、次のような認識です。
- グループ会社同士で一定の信頼関係があるとして、取扱状況の監査を行っていなかった
- 外部の取引先とは違い、親会社に管理してもらうことは委託に該当せず、監督は不要と認識していた
- グループ全体のセキュリティポリシーが改訂されたのに、子会社が対応できていなかった
対策として示されているのは、委託先がグループの親会社であっても、通常の外部委託先に対するルールと同じ基準で、必要かつ適切な監督を行うことです。たとえば、親会社による自己点検や、第三者機関による検査の結果を、子会社がモニタリングするといった仕組みが例示されています。
落とし穴2:クラウド利用は「委託」ではないから、監督は不要という思い込み(事例8)
もうひとつが、クラウドサービスの利用です。資料の事例では、クラウドサービス提供事業者の業務システムが不正アクセスを受け、クラウド環境で管理されていた多数の顧客企業の個人データが暗号化され、大量の個人データについて漏えいのおそれが生じました。顧客企業の側は、業務の委託ではないクラウドサービスの利用は、個人データの取扱いの委託に該当しないと考えていたため、委託先に対する取扱状況の監督を実施していなかったとされています。
対策としては、次の2点が示されています。
- 顧客企業は、利用しようとするクラウドサービスで適切なセキュリティ対策が講じられているかを、利用規約や、クラウドサービスの安全性評価に関する資料などで確認し、適切なサービスを選定する
- クラウドサービスの利用が個人データの取扱いの委託となる場合、顧客企業が取扱状況を適切に把握できるよう、提供事業者は、セキュリティレポートなどの必要な情報を積極的に公開することが望ましい
契約実務から見た2つの教訓
これらの事例から、契約実務に関して次の2点が見えてきます。
- 「委託かどうか」の線引きだけで、安心しない:クラウドの利用が、個人データの取扱いの委託にあたるかどうかは、サービスの内容や、事業者が個人データを取り扱うかどうかなどによって異なります。判断に迷う場合は、個人情報保護委員会のQ&Aなどで確認し、あたるかどうかにかかわらず、利用するサービスのセキュリティ水準を確認する習慣をつけましょう。
- グループ会社間にも、外部と同じレベルの取り決めを:グループ会社への委託や共同利用でも、業務範囲、セキュリティ要件、報告の方法などを、契約書や覚書として明確にしておくことが大切です。
次の章では、こうした視点を踏まえ、契約書でどの条項を見直すべきかを具体的に見ていきます。
契約書で見直したい8つの条項
委託先やクラウド事業者との契約書を見直すときの視点を、8つの条項に整理しました。個人情報保護委員会の資料で挙げられた事例や、技術的安全管理措置の内容を踏まえています。
| No. | 条項 | 見直しの視点 | 関連する根拠・事例 |
|---|---|---|---|
| 1 | 委託業務の範囲と役割分担 | 脆弱性への対応、パッチ適用、システム保守まで、委託の範囲に含まれているか。誰がどこまで行うかが書かれているか | 事例1・2(保守契約に脆弱性対応が含まれていない、役割分担が不明確) |
| 2 | セキュリティ要件 | アクセス制御、本人認証(多要素認証を含む)、不正アクセスの防止、通信の暗号化、ログの保存と分析などの水準を定めているか | 技術的安全管理措置(アクセス制御、識別と認証、不正アクセス等の防止・検知など) |
| 3 | 再委託 | 再委託を行う場合の事前承諾、再委託先にも同等の義務を課すこと、再委託先の管理責任 | 委託先の監督(法第25条)。実務上の観点 |
| 4 | インシデント発生時の報告 | 事故やそのおそれを把握したときの連絡期限・窓口・報告内容、調査への協力 | 漏えい等報告(法第26条)への対応に必要。実務上の観点 |
| 5 | 監査・報告 | セキュリティレポートの提出、第三者による評価・認証の確認、点検結果の共有、必要に応じた立入確認 | 事例7・8(監督を行っていなかった、レポート公開が望ましい) |
| 6 | 事業継続・復旧 | 障害時の復旧の目標、バックアップの取り方、復旧できない場合の対応、代替手段 | IDCFクラウドの事案で、一部データが復旧困難と報じられた点 |
| 7 | データの返却・消去 | 契約終了時の返却と消去の方法、復元できない形での消去、消去したことの証明 | 法第22条(不要データの消去)、クラウド上の個人データ消去の例示 |
| 8 | 責任範囲・損害賠償 | 賠償の範囲と上限、免責の条件、再委託先に起因する損害の扱い、保険の有無 | 実務上の観点 |
条項1:委託の範囲に「セキュリティ対策」が入っているか
個人情報保護委員会のWARNING資料の事例1では、原因として、システム業者との間でシステム導入の業務委託契約しか締結しておらず、セキュリティ対策に関する保守の契約を結んでいなかったこと、また、保守契約はあったが、委託業務の内容に脆弱性対応が含まれていなかったことが挙げられています。対策としては、脆弱性対策などのセキュリティ対策を含むシステム保守の業務委託契約を締結することが示されています。
契約書を見直すときは、「導入は頼んでいるが、導入後の運用や保守は誰がやるのか」という点を、まず確認しましょう。
条項4:インシデント報告条項の例
事故が起きたとき、委託先から速やかに情報が上がってこなければ、委託元は対応が遅れます。次は、報告条項のイメージを示す、あくまで参考の例文です。
第〇条(事故等の対応)
1 受託者は、委託業務に関して個人データその他の情報の漏えい、滅失、毀損
その他の事故(そのおそれがある場合を含む。以下「事故等」という。)が
発生したときは、直ちに委託者に報告し、委託者の指示に従い、被害の拡大
防止、原因の調査及び再発防止のために必要な措置を講じる。
2 前項の報告には、事故等の発生日時、概要、影響を受けた情報の範囲、現時点
で把握している原因、及び講じた措置を含める。
3 受託者は、調査の進捗に応じて、委託者に対し、状況を継続して報告する。
4 委託者が法令に基づく報告、本人への通知その他の対応を行う必要があるとき
は、受託者はこれに協力する。「直ちに」を、「〇時間以内」と具体的な期限にするかどうかは、委託の内容や、取り扱う情報の重要度に応じて検討します。例文は一般的なイメージであり、実際の契約書への適用にあたっては、弁護士などの専門家に確認してください。
見直しの優先順位
すべての契約を一度に見直すのは現実的ではありません。次の順で優先度をつけると、効率的です。
- 個人データや機密情報を大量に預けている委託先・クラウド
- 止まると事業に大きな影響が出る、基幹業務のシステム
- 再委託が多い、または再委託の実態が見えにくい委託先
- 契約の更新時期が近いもの(更新のタイミングで見直す)
クラウドの標準約款が変えられないときの対応
クラウドサービスの多くは、利用者ごとに契約内容を変更できない、標準の利用規約(約款)で提供されています。「契約書を見直そう」と思っても、交渉の余地がないケースが少なくありません。そんなときは、約款の内容を確認したうえで、自社でできる補完策を組み合わせましょう。
約款・規約で確認したいポイント
| 確認項目 | 見るべき点 | 気をつけたいこと |
|---|---|---|
| 稼働率・障害時の扱い(SLA) | 稼働率の目標値や、障害時の返金・補償の範囲 | 補償が利用料の返金にとどまり、事業の損失は対象外ということも多い |
| 責任の範囲と上限 | 事業者が負う責任の範囲と、賠償額の上限 | 上限が低く設定されている場合、損害の大部分は自社の負担になり得る |
| データの取扱い | バックアップの責任の所在、データの保管場所、事業者によるアクセス | 「バックアップは利用者の責任」とされているケースがある |
| 事故時の通知 | 事故が起きたときの通知の方法とタイミング | 通知の期限が明記されていない場合は、問い合わせで確認する |
| 契約終了時のデータ | 返却や消去の方法、期間 | 復元できない方法での消去が行われるかを確認する |
| 再委託・サブプロセッサー | 事業者がさらに外部へ委託する場合の取り扱い | 利用者が把握できる仕組みがあるか |
セキュリティ水準を確認する材料
個人情報保護委員会のWARNING資料でも、顧客企業は、利用規約やクラウドサービスの安全性評価に関する資料などで、適切なセキュリティ対策が講じられているかを確認し、サービスを選定することが示されています。次のような材料を活用しましょう。
- 事業者が公開しているセキュリティレポートや、セキュリティに関する説明資料
- 第三者による認証や評価の取得状況(ISO/IEC 27001、SOC2、政府系のクラウド評価制度など)
- 過去の障害・事故の公表内容と、その後の改善の説明
- 問い合わせへの回答の丁寧さと、情報開示への姿勢
契約で変えられない部分を、自社の対策で補う
約款上の補償が十分でない部分は、自社の運用でカバーします。
- バックアップを別の場所にも持つ:クラウド事業者のバックアップだけに頼らず、別のサービスや別の拠点にも、重要なデータのコピーを保管します。復元の手順も、あらかじめ試しておきます。
- 重要データの集中を避ける:基幹の業務データを、ひとつのクラウドに集約しすぎないよう、システム構成を見直します。
- 代替手段を用意する:クラウドが止まったときに、一時的に業務を続けるための手順を、事業継続計画として準備します。
- 権限と認証を自社でも強化する:管理者の権限の最小化、多要素認証の導入、不要なアカウントの削除などを徹底します。
- 保険の活用を検討する:サイバー保険など、事業の損失を補う手段を検討します。
社内で決めておきたいこと
- 重要度の高いクラウドサービスの一覧と、それぞれの担当者
- 障害が長引いた場合の、事業への影響と許容できる停止時間
- 約款の変更通知を、誰が確認するか
約款を変えられなくても、「何がリスクで、どう備えるか」を整理しておくことが、事故が起きたときの落ち着いた対応につながります。
委託先・クラウドで事故が起きたときの初動6ステップ
事故は、備えていても起こり得ます。大切なのは、起きたときに慌てず、順序立てて動けることです。委託先やクラウドの事故を想定した、初動の流れを6つのステップにまとめました。
ステップ1:事実を確認し、自社への影響範囲をつかむ
まず、委託先やクラウド事業者の公式発表、通知メール、サポートの案内を確認します。そのうえで、「自社のどのシステムやデータが、そのサービスを利用しているか」を洗い出します。直接契約しているサービスだけでなく、利用しているSaaSや保守委託先が、背後でどの基盤を使っているのかも、必要に応じて事業者へ問い合わせて確認しましょう。
ステップ2:社内の緊急連絡体制を動かす
責任者、情報システム部門、法務、広報、経営層へ、速やかに情報を共有します。担当者ひとりで抱え込まず、事前に決めた連絡経路で、状況を伝えます。
ステップ3:被害の拡大を防ぐ措置をとる
事業者の案内に従い、パスワードの変更、該当システムへの接続の停止や制限、重要なログの保全などを行います。ただし、独自の判断で操作すると、調査に必要な情報を失うおそれがあるため、事業者の指示を確認しながら進めます。
ステップ4:報告や通知が必要かどうかを判断する
個人データの漏えい等が生じた場合や、そのおそれがある場合には、個人情報保護法に基づく報告や、本人への通知が必要になることがあります。何が対象になるか、いつまでに行うかは、法令や個人情報保護委員会のガイドラインで定められているため、最新の案内を確認し、迷う場合は専門家や相談窓口に早めに相談しましょう。契約書に定めた、委託先からの報告内容や協力義務も、ここで活用します。
ステップ5:取引先・顧客へ誠実に説明する
影響がある、または影響の可能性がある取引先や顧客には、次の点を整理して伝えます。
- 現時点でわかっていることと、わかっていないこと
- 自社が行っている対応と、今後の見通し
- 問い合わせ窓口
推測を事実のように伝えるのは避け、公式の発表に基づいて説明します。情報が更新されたら、その都度、続報を伝えます。
ステップ6:記録を残し、振り返りを行う
対応の時系列、判断の根拠、関係者とのやり取りを記録します。事態が落ち着いたら、契約に基づく対応(報告の受領、損害の請求の検討など)を整理するとともに、再発防止のための見直し(契約条項、委託先の選定、バックアップ、事業継続計画)につなげます。
「契約書をすぐ取り出せる」ことが初動を早くする
事故が起きたとき、真っ先に確認したいのが、委託先やクラウド事業者との契約書や規約です。連絡窓口、報告の期限、責任の範囲、データの取扱いなどを、すぐに確認できなければ、対応が遅れます。契約書の保管場所を一本化し、委託先ごとの重要な条件を一覧にしておくことが、初動のスピードを大きく左右します。
平時にやっておく委託先管理の5ステップ
事故が起きてから慌てないために、平時からできる準備を5つのステップにまとめます。一度にすべてを整えようとせず、重要なものから順に取り組みましょう。
ステップ1:委託先・クラウドを棚卸しする
社内で使っている委託先、クラウドサービス、SaaS、システム保守の業者、グループ会社への委託を洗い出します。部署が個別に契約しているサービスも見落とさないよう、購買や経理の支払い記録も手がかりにします。WARNING資料の事例でも、管理対象から漏れていたIT資産や、把握できていなかった機器が、被害の一因になっていました。
ステップ2:預けている情報と、止まったときの影響で重要度をつける
棚卸しした委託先を、次の2つの軸で分類します。
- 預けている情報の重要度:個人データ、機密情報、財産的被害につながる情報などを、どれだけ預けているか
- 事業への影響度:そのサービスが止まった場合に、業務がどれだけ止まるか
重要度が高いものから、契約の見直しや点検を進めます。
ステップ3:契約書・規約を見直す
重要度の高い委託先から、前の章で挙げた8つの条項を確認します。契約書で変えられない標準約款は、補完策を整理します。グループ会社への委託も、外部と同じ基準で確認します。
ステップ4:定期的に点検し、記録を残す
契約を結んだら終わりではありません。年に1回程度、委託先からセキュリティレポートを受け取る、点検の結果を確認する、担当者や連絡先の変更を反映するなど、定期的に状況を確認します。点検の記録は、のちに「必要かつ適切な監督を行っていた」ことを説明する材料にもなります。
ステップ5:訓練と見直しを行う
初動の手順を、実際に動かしてみる訓練も有効です。委託先が止まった想定で、連絡体制、報告の判断、取引先への説明などを確認し、課題を洗い出します。契約の更新や、サービスの変更、新しい事例の公表があったときにも、ルールを見直します。
委託先管理台帳に入れたい項目
契約管理台帳に、委託先管理に必要な項目を加えておくと、点検や事故時の確認がスムーズになります。
| 項目 | 記載する内容 |
|---|---|
| 委託先・サービス名 | 正式名称、担当部署と窓口 |
| 委託内容・利用範囲 | どの業務、どのシステムで使っているか |
| 預けている情報 | 個人データ、機密情報などの種類と量の目安 |
| 重要度 | 情報の重要度と、事業への影響度 |
| 契約書・規約の保管場所 | 契約書、覚書、利用規約、SLAなど |
| 連絡窓口・報告の期限 | 事故時の連絡先、報告の期限 |
| 再委託の有無 | 再委託先の名称、承諾の状況 |
| データの保管場所 | 国内外のどこに保管されるか |
| 第三者認証・レポート | 取得している認証、最新のレポートの入手日 |
| 最終点検日・次回予定 | 点検した日と、次回の予定 |
| 契約終了時の対応 | データの返却・消去の方法 |
契約書の管理台帳をすでに運用している場合は、これらの項目を追加する形で、無理なく始められます。
委託先・クラウド管理チェックリスト
自社の委託先管理の状態を確認するためのチェックリストです。チェックが付かない項目が、優先的に見直したいポイントです。
棚卸しと重要度
- 利用している委託先・クラウド・SaaSの一覧がある
- 部署ごとに個別契約しているサービスも、一覧に含めている
- グループ会社への委託や、共同利用も一覧に含めている
- 預けている情報の重要度と、止まったときの影響度で分類している
契約書・規約
- 委託の範囲に、脆弱性対応やシステム保守が含まれているか確認した
- セキュリティ要件(アクセス制御、認証、暗号化、ログ)が定められている
- 再委託の取り扱い(事前承諾、同等の義務)が定められている
- 事故発生時の連絡窓口、報告の内容と期限が定められている
- 監査やセキュリティレポートの提出について定めがある
- 契約終了時のデータの返却・消去の方法が定められている
- 責任範囲や損害賠償の上限を把握している
- 標準約款のサービスについて、SLAや責任の範囲を確認した
運用と点検
- 年に1回程度、委託先の状況を点検している
- 第三者認証やセキュリティレポートの最新版を入手している
- 委託先の担当者・連絡先の変更を、台帳に反映している
- 契約書・規約の保管場所が一本化されており、すぐに取り出せる
事故への備え
- 重要なデータは、クラウド事業者のバックアップとは別にも保管している
- 重要なサービスが止まったときの代替手段や手順を決めている
- 事故発生時の社内の連絡体制(責任者、法務、広報、経営層)が決まっている
- 報告や通知の要否を判断する担当と、相談先が決まっている
- 事故対応の訓練を、定期的に実施している
結果の見方
- 17個以上:基本的な体制は整っています。定期的な点検と訓練で、質を保ちましょう。
- 9〜16個:土台はあります。チェックが付かなかった項目から、重要度の高い委託先を優先して整えましょう。
- 8個以下:まずは、委託先の棚卸しと、重要度の分類から始めるのがおすすめです。
委託先管理に関するよくある質問(FAQ)
Q1. 自社が攻撃されていなくても、委託先の事故で責任を問われますか?
個人情報保護委員会のWARNING資料では、事例への措置が十分でない場合、安全管理措置(第23条)、従業者の監督(第24条)、委託先の監督(第25条)の違反と判断される可能性があるとされています。委託先の事故であっても、委託元として必要かつ適切な監督を行っていたかが問われ得ます。個別のケースについては、弁護士などの専門家や、個人情報保護委員会の相談窓口に確認してください。
Q2. クラウドサービスの利用は、個人データの取扱いの「委託」にあたりますか?
サービスの内容や、事業者が個人データを取り扱うかどうかなどによって異なります。WARNING資料の事例8では、「業務の委託ではないクラウド利用は委託にあたらない」と考えて監督をしていなかったことが、問題点として挙げられています。あたるかどうかの判断に迷う場合は、個人情報保護委員会のQ&Aなどで確認し、あたるかどうかにかかわらず、サービスのセキュリティ水準を確認する姿勢が大切です。
Q3. クラウドの標準約款は、交渉で変えられますか?
利用規模やサービスによって異なりますが、多くの場合、標準約款の変更は難しいのが実情です。変えられない場合は、約款のSLAや責任の範囲を確認したうえで、バックアップの分散、代替手段の用意、権限管理の強化、保険の活用といった、自社側の補完策を組み合わせましょう。
Q4. グループ会社への委託にも、契約書は必要ですか?
WARNING資料の事例7では、グループ会社への委託を、外部の取引先とは違うものとして扱い、監督を行っていなかったことが問題点とされています。委託先がグループの親会社であっても、通常の外部委託先と同じ基準で必要かつ適切な監督を行うことが対策として示されています。業務の範囲、セキュリティ要件、報告の方法などを、契約書や覚書で明確にしておくことが望ましいといえます。
Q5. 個人情報を預けていない委託先は、見直さなくてもよいですか?
個人情報以外にも、取引条件や技術情報などの機密情報、事業を止めないための基幹システムなど、守るべきものは多くあります。個人情報を預けていなくても、機密保持、事故時の報告、事業継続、データの返却・消去などの条項は、見直す価値があります。
Q6. 注意喚起は、大企業だけが対象ですか?
個人情報保護委員会の公表文は、特に、大量の個人情報や、機微性の高い個人情報などを保有する事業者に向けた内容です。ただし、安全管理措置は、個人情報取扱事業者全般に求められるものです。事業の規模にかかわらず、自社が取り扱う個人データの性質と量に応じて、必要かつ適切な措置を検討することが大切です。
まとめ:契約書は、委託先の事故に備える「最初の防波堤」
2026年10月の相次ぐ事案から見えてきたポイントを、あらためて整理します。
- IDCFクラウドのランサムウェア被害では、契約先の495の企業・自治体に影響が及んだと報じられ、自社が攻撃されていなくても、事業が止まり得ることが示された
- 個人情報保護委員会の注意喚起は、特定の事案を名指ししたものではないが、九つの事例を示し、措置が不十分な場合は第23条・第24条・第25条の違反と判断される可能性があるとしている
- 事例には、保守契約に脆弱性対応が含まれていない、グループ会社への監督を不要と思い込む、クラウド利用を委託でないと考えて監督しないなど、契約や委託先管理に関わる問題が多く含まれる
- 契約書では、業務範囲と役割分担、セキュリティ要件、再委託、インシデント報告、監査・報告、事業継続、データの返却・消去、責任範囲の8点を見直す
- クラウドの標準約款が変えられないときは、約款を確認したうえで、バックアップの分散や代替手段などの補完策を組み合わせる
- 事故が起きたときの初動と、平時の委託先管理(棚卸し、重要度分類、点検、訓練)を、あらかじめ決めておく
契約書にどんな取り決めがあるかは、事故が起きる前には目に見えにくい部分です。しかし、起きたときの対応のしやすさと被害の大きさを、確実に左右します。まずは、個人データや機密情報を預けている委託先、止まると事業に影響が大きいクラウドから、契約書や規約を取り出し、チェックリストで現状を確認してみてください。
※本記事は2026年10月29日時点の報道および公表資料に基づく一般的な解説であり、個別の法的助言ではありません。事案の状況や法令・ガイドラインは更新される場合があります。実際の対応にあたっては、各社・各機関の公式発表を確認のうえ、弁護士などの専門家にご相談ください。
参考にした公式情報

