システム開発の委託先で情報漏洩｜発注者の責任範囲と初動対応

「委託先で情報漏洩が起きたかもしれない」――システム開発を外部に委託している企業の担当者にとって、この一報ほど血の気が引く瞬間はありません。漏洩を起こしたのは委託先のベンダーであっても、発注者である自社の責任が完全に消えるわけではなく、対応のスピードと判断の正確さがその後の被害規模を大きく左右します。

しかし、いざ連絡を受けてみると「何時間以内に・誰に・どこまで動けばいいのか」が判然としません。契約書を読み返しても具体的な分担が書かれておらず、社内に手順書もない。個人情報保護委員会への報告は自社が行うべきなのか、それともベンダー任せで良いのか――判断材料が不足したまま時間だけが過ぎていきます。

本記事では、システム開発の委託先で情報漏洩が発生した際に、発注者がどの時間軸で何をすべきかを時系列で整理します。発覚から24時間以内の緊急初動、72時間以内〜1週間以内の報告判断、1ヶ月以降のベンダーへの責任追及、そして再発防止のための契約条項見直しまで、改正個人情報保護法（2022年4月施行）と実務判例を踏まえた実務ガイドとしてまとめました。

緊急時には記事末尾の時系列チェックリストをブックマークすれば、全体の流れがいつでも思い出せる構成にしています。連絡が来た「いま」、まず何から手をつけるべきか――最後までお読みいただければ、社内で落ち着いて指示を出せる状態になるはずです。

—Free Download / 資料ダウンロード

システム開発における秘密保持契約書(NDA)の雛形

この資料でわかること

BtoB取引において必須とも言える秘密保持契約書(NDA)の雛形をご紹介します。

こんな方におすすめです

• システム開発を発注する際にどのようなNDAを結ぶのか興味がある
• システム開発会社がきちんとNDAを取り交わしているのか不安
• 通常のNDAと違いがあるのか気になる

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

委託先で情報漏洩が起きたとき、発注者はなぜ責任を問われるのか

「漏らしたのはベンダーなのに、なぜ自社が責任を負うのか」――最初に直面するのがこの疑問です。結論から言えば、個人情報を扱う業務を外部に委託した場合、発注者には「委託先を監督する義務」が法的に課されており、ベンダー側のミスであっても発注者の責任が消えるわけではありません。

個人情報保護法における「委託先の監督義務」

個人情報保護法第25条は、個人データの取扱いを委託する事業者に対して「委託を受けた者に対する必要かつ適切な監督を行わなければならない」と定めています。ここでいう「必要かつ適切な監督」とは、(1) 適切な委託先の選定、(2) 委託契約の締結、(3) 委託先における個人データ取扱状況の把握、の3つを指します（個人情報保護委員会ガイドライン通則編）。

つまり「契約してベンダーに任せた」だけでは監督義務を果たしたことにならず、稼働開始後の運用状況まで継続的に把握しておく必要があります。

機密保持契約だけでは責任は限定できない

「機密保持契約（NDA）を結んでいるから大丈夫」と考える方は少なくありませんが、NDAは情報の取扱いルールを定めたものに過ぎず、漏洩が起きた際の監督責任を発注者から免除する効力はありません。発注者が監督義務を尽くしていたか否かは、契約書の有無ではなく、選定時の審査・運用中のモニタリング・是正措置の実態で判断されます。

発注者が負う3つの責任

委託先で漏洩が起きた場合、発注者は次の3種類の責任を負う可能性があります。

• 行政上の責任：個人情報保護委員会から指導・勧告・命令を受ける可能性があります。命令違反には刑事罰（1年以下の拘禁刑または100万円以下の罰金）が科されます。なお、法人に対しては両罰規定により1億円以下の罰金が科される場合があります（個人情報保護法第178条・第184条）
• 民事上の責任：漏洩した本人から損害賠償請求を受ける可能性があります（不法行為・契約上の安全管理義務違反）
• 社会的信用上の責任：取引先・顧客・株主からの信頼失墜、ブランド毀損

これら3つの責任は、ベンダーへの責任追及とは別軸で発注者に降りかかります。だからこそ、ベンダーからの第一報を受けた瞬間からの初動対応が重要になるのです。

なお、発注時点で監督義務を仕様書や契約書にどう落とし込むかは個人情報保護法とシステム開発｜発注者が仕様書・契約書に反映すべき7つの法的要件で、外注プロジェクトの設計・運用段階で押さえるべき項目は個人情報保護法対応のシステム開発チェックリストで整理しています。今回の漏洩を教訓に再発防止策を見直す際の併読資料としてご活用ください。

漏洩発覚から24時間以内にやるべきこと（緊急初動フェーズ）

委託先から「情報漏洩の可能性がある」という一報が入ったら、最初の24時間で何をするかが被害規模を決めます。社内対策本部の立ち上げと、委託先からの情報収集を並行で進めるのが基本動作です。

委託先から確認すべき5項目

ベンダーへの最初のヒアリングでは、感情的に責任追及をするのではなく、判断に必要な事実を冷静に集めます。最低限、次の5項目は確認しましょう。

1. 漏洩の範囲：どのシステム・どのDB・どの顧客セグメントが対象か
2. 漏洩の原因（推定でも可）：不正アクセス・内部犯行・設定ミス・紛失等
3. 漏洩件数（概算）：1,000件未満か、超えるか（後述の報告義務判断に直結）
4. 流出経路と外部への到達状況：ダークウェブ流出の確認・身代金要求の有無
5. 封じ込め状況：すでにアクセス遮断・パスワード変更等が完了しているか

特に「件数」と「漏洩したデータの種類」は、個人情報保護委員会への報告義務の発生有無を左右する重要情報です。ベンダー側もこの段階では正確な数字を把握しきれていないことが多いため、「現時点で判明している事実」と「未確定事項」を明確に区別して受け取ります。

社内対策本部の立ち上げと役割分担

第一報を受けた担当者は、できる限り早く経営層（CEO・役員）に報告し、対策本部を組成します。本部には次のメンバーを配置するのが一般的です。

• 総括責任者：経営層（最終意思決定者）
• 技術調査担当：情報システム部門（委託先との技術的なやり取り）
• 法務・コンプライアンス担当：報告義務の判断、契約条項の確認
• 広報担当：対外的な発信内容のコントロール
• 顧客対応担当：本人通知の準備、問い合わせ窓口の設置
• 記録担当：時系列で対応経過を記録（後の損害賠償請求や報告書作成に必須）

社内に法務専任やセキュリティ専任がいない中堅企業の場合、顧問弁護士・外部のフォレンジック調査会社・サイバー保険の付帯サービス等への連絡もこの段階で行います。

証拠保全と「やってはいけない」初動対応

初動でやってはいけないことが3つあります。

1. 委託先のサーバ・ログを発注者側で勝手に操作する：証拠が改変・消失し、後の原因究明や責任追及に支障が出ます。委託先に対しては「ログ・サーバ状態を現状保全すること」を文書で要請します
2. 独断での外部公表：正確な事実が固まらないうちに公表すると、後の訂正で信頼をさらに失います。公表のタイミングは法務・広報と協議して決定します
3. 委託先への過度な調査妨害：詰問や責任追及を急ぐあまり、委託先の調査を遅らせては本末転倒です。原因究明と再発防止のために、まずは協力体制を維持します

「証拠保全の依頼」「対策本部設置」「経営層報告」――この3つを24時間以内に完了させることが、その後の対応を左右する分岐点になります。

72時間以内〜1週間以内にやるべきこと（報告判断・通知準備フェーズ）

初動の混乱が少し落ち着いた段階で待っているのが、「個人情報保護委員会への報告は必要か」「自社が報告主体になるのか」という判断です。改正個人情報保護法（2022年4月施行）により、一定の要件に該当する漏洩は報告と本人通知が法的義務となりました（漏えい等報告・本人への通知の義務化について｜個人情報保護委員会）。

個人情報保護委員会への報告が必要な「4つの報告対象事態」

報告義務が発生するのは、次の4類型のいずれかに該当する場合です（個人情報保護法施行規則第7条）。

「件数1,000人以下」だからといって安心できない点に注意が必要です。第1〜3類型は件数に関係なく報告対象になります。たとえば不正アクセスによる漏洩であれば、1件であっても第3類型に該当する点を見落とさないようにしましょう。

委託元・委託先のどちらが報告するか

委託先で漏洩が発生した場合、原則として委託元・委託先の双方が報告義務を負います（個人情報保護委員会 FAQ Q5-17-16）。この場合、両者連名で報告することも可能です。

ただし重要な例外として、委託先が「報告事項のうち把握している内容を、速やかに委託元へ通知した」場合、委託先の報告義務は免除されます（個人情報保護法第26条但書）。つまり実務的には、委託先が委託元に必要事項を通知し、委託元（発注者）が個人情報保護委員会への報告主体となるケースが多くなります。

ここで発注者が陥りがちな落とし穴が「ベンダーが報告してくれるはず」という思い込みです。委託先が委託元に通知した時点で委託先の報告義務は免除されるため、委託元（発注者）が報告しなければ誰も報告しない状態になってしまいます。「自社で報告するのか、ベンダーと連名にするのか、ベンダーが単独で報告するのか」を早い段階で明確に役割分担しましょう。

速報（3〜5日以内）と確報（30日／60日以内）の書き分け

報告は2段階で行います。

• 速報：報告対象事態を知ったときから概ね3〜5日以内に、その時点で把握している事項を報告
• 確報：原則30日以内、ただし不正アクセス等の第3類型は60日以内に、全項目を確定して報告

速報の段階では「全容が固まっていないから報告できない」と考えがちですが、把握している範囲で報告すれば足り、未確定事項は確報で補完すれば問題ありません。むしろ「3〜5日」を超えて速報が遅れる方が、後に行政指導の対象となるリスクが高まります。

報告は個人情報保護委員会の電子申請フォームで行います。ベンダーから受け取った情報を社内で整理し、報告書ドラフトを早めに準備しておくと、確報期限に追われずに済みます。

被害者本人への通知方法と謝罪文の押さえどころ

報告対象事態に該当する場合、個人情報保護委員会への報告と並行して、漏洩した本人への通知も義務となります。通知は次の要件を満たす必要があります。

• 通知内容：漏洩した個人データの項目・原因・二次被害防止策・連絡先など（個人情報保護法施行規則第10条）
• 通知方法：書面・電子メール等、本人に確実に到達する手段
• 通知時期：「当該事態の状況に応じて速やかに」

通知が困難な場合（連絡先不明者が多数いる等）は、自社サイトでの公表など代替措置が認められます。

謝罪文の押さえどころは、(1) 事実を曖昧にしない、(2) 原因と再発防止策を具体的に書く、(3) 本人が取るべき自己防衛策（パスワード変更・カード再発行など）を明示する、(4) 問い合わせ窓口を24時間以上の長時間運用にする、の4点です。テンプレ的な謝罪文は本人の不信感を増幅させるため、必ず自社の言葉で書き起こします。

ベンダーへの責任追及と費用回収（1ヶ月以降の対応フェーズ）

初動と報告対応が落ち着いた段階で、次に向き合うのが「立て替えた対応費用をベンダーからどこまで回収できるか」という金銭面の課題です。本人通知の郵送費、コールセンター設置費、フォレンジック調査費用、弁護士費用――これらが数百万〜数千万円規模に膨らむこともあり、回収可能性を最大化するためには早い段階での証拠固めが欠かせません。

ベンダーが負うセキュリティ対策義務の範囲（参考判例）

参考になるのが、東京地裁平成26年1月23日判決（平23（ワ）32060号）です。この事案は、家具販売会社のECサイトがSQLインジェクション攻撃を受け、約7,000件のクレジットカード情報が流出したもので、裁判所は次のように判断しました。

• 契約書に明記がなくても、ベンダーは契約締結時点の技術水準に応じたセキュリティ対策を講じる義務を負う
• 経済産業省・IPAが当時公表していたSQLインジェクション対策（バインド機構・エスケープ処理）が技術水準として確立していたため、その実装漏れは債務不履行に該当する
• 結論として、約2,260万円の損害賠償（過失相殺3割適用後）を認容

この判決のポイントは「契約書に書いていないから免責される」とは限らないという点です。発注者側がセキュリティ要件を明示していなくても、業界標準・公的機関のガイドラインで確立した対策を怠れば、ベンダーに賠償責任が生じる可能性があります。

請求できる費用の種類と算定の考え方

漏洩対応で発生する費用は、典型的に次の4種類です。

これらのうち、ベンダーへの請求対象となるのは「ベンダーの過失と相当因果関係がある損害」に限られます。たとえばサービス停止期間の判断が過剰だった場合や、被害者対応で過大な見舞金を支払った場合、その分は減額される可能性があります。

契約書の損害賠償条項の確認ポイント

請求検討の前に、契約書の以下の条項を必ず確認しましょう。

• 損害賠償の上限額：「業務委託料の総額を上限とする」等の上限条項があるか
• 免責条項：「故意・重過失の場合は上限の適用なし」となっているか
• 間接損害・逸失利益の除外：「間接損害は賠償対象外」となっていないか
• 時効・請求期限：契約上の請求期限が設定されているか

特に上限条項は要注意です。委託料が500万円の案件で、対応費用が3,000万円かかったとしても、上限条項により500万円しか回収できないケースがあります。ただし、ベンダーに故意・重過失が認められれば上限条項の効力が否定されることもあるため、原因が悪質な場合は弁護士に相談する価値があります。

交渉・訴訟に進む前に揃えておくべき証拠

回収可能性を高めるには、初動段階から次の証拠を残しておくことが重要です。

• 委託先とのやり取り（メール・議事録）の時系列保全
• ベンダーが提出した原因調査報告書・再発防止策
• 自社が支払った費用の領収書・契約書（フォレンジック調査・弁護士費用等）
• 個人情報保護委員会への報告書写し
• 本人からの問い合わせ・苦情の記録

請求の場面で「あの時、ベンダーがこう言った」という主張を裏付ける書面がなければ、交渉力は大きく落ちます。対策本部の「記録担当」を初動から置く意味は、この証拠保全にあります。

再発防止のためのシステム開発委託先の管理体制と契約見直し

インシデント対応が一段落したら、最後に取り組むべきは「次に同じことを起こさないための構造的な対策」です。経営層からも「同じことが起きないと言えるのか」と問われる場面が必ず来ます。社内体制と契約条項の両面から見直しを進めましょう。

社内体制の見直し3つの観点

• 委託先選定基準の文書化：プライバシーマーク・ISMS（ISO27001）認証の有無、過去のインシデント履歴、再委託先の管理状況などを評価項目化し、選定時のチェックリストとして運用します
• 定期監査の実施：年1回以上、委託先のセキュリティ管理状況を書面または現地で確認します。監査記録は監督義務を果たした証拠として保存します
• インシデント対応規程の整備：今回のインシデント対応経験を踏まえて、社内の手順書・連絡フロー・対策本部の構成を文書化します

契約書に盛り込むべき4つの条項

既存の委託契約を見直す際、最低限次の4条項を整備します。

1. 監督権限条項：定期報告義務、立入監査権、セキュリティ対策の証跡提出義務
2. セキュリティ要件条項：具体的な技術要件（脆弱性診断の頻度、暗号化、アクセスログ保管期間など）を別紙仕様書として明記
3. 報告義務条項：インシデント発生時の通知期限（例: 24時間以内）、通知すべき内容、改正個人情報保護法第26条に基づく委託元への通知義務の明記
4. 再委託管理条項：再委託の事前承認制、再委託先への遵守義務継承、再委託先での漏洩時の責任範囲

特に「報告義務条項」で通知期限を明示しておくと、今回のような「いつ連絡してくれるのか分からない」状況の再発を防げます。

再委託・クラウドベンダー利用時の追加チェック項目

近年は委託先がさらにクラウドサービス（AWS・Azure・SaaS等）を利用しているケースが大半です。再委託やクラウド利用に関しては、次の点を追加で確認します。

• 再委託先のリスト提出義務と、変更時の事前承認プロセス
• クラウドサービスの責任共有モデル（インフラ層と利用者層の責任分界）
• データの保管国・準拠法（越境移転規制との適合）
• クラウドベンダーが第三者認証（SOC2・ISO27017等）を取得しているか

クラウドベンダーが直接の取引相手でなくても、個人情報保護法上の「委託先」に該当する場合があります。再委託の連鎖がどこまで及ぶかを契約締結時点で明らかにし、見えない委託先を作らないことが重要です。

まとめ：時系列チェックリスト

委託先での情報漏洩対応は、時間軸でやるべきことが大きく変わります。緊急時に立ち戻れるよう、本記事の内容を以下のチェックリストにまとめました。

委託先での情報漏洩は、どれだけ予防策を講じても完全には防ぎきれない経営リスクです。重要なのは「起きた後にどれだけ早く正確に動けるか」であり、そのためには平時のうちに本記事のチェックリストを社内手順書に組み込み、対策本部のメンバー候補・連絡先・契約書の該当条項を一覧化しておくことをおすすめします。

秋霜堂株式会社はシステム開発を受託する立場として、発注者と委託先の両方の実務感覚を持ち合わせています。委託先管理や契約条項の見直しに不安をお持ちの場合は、平時の準備段階こそが最大の打ち手になることをお伝えしておきます。

—Free Download / 資料ダウンロード

システム開発における秘密保持契約書(NDA)の雛形

この資料でわかること

BtoB取引において必須とも言える秘密保持契約書(NDA)の雛形をご紹介します。

こんな方におすすめです

• システム開発を発注する際にどのようなNDAを結ぶのか興味がある
• システム開発会社がきちんとNDAを取り交わしているのか不安
• 通常のNDAと違いがあるのか気になる

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。