DPA（データ処理契約）の必須条項とGDPR対応の実務

クラウドサービス、SaaS、生成AI、決済基盤、CRM、分析ツールなどを利用すると、顧客企業が保有する個人データを外部事業者が処理する場面が生じます。その契約実務で中心となるのがDPA（Data Processing Agreement、データ処理契約）です。

もっとも、DPAは「個人データを外部に渡すときに必ず締結する定型契約」ではありません。GDPR上の管理者・処理者関係なのか、双方が独立した管理者なのか、共同管理者なのかによって、必要な契約の内容は変わります。また、越境移転のためのSCCとDPAは目的が異なります。最初に当事者の役割とデータフローを整理し、その結果を契約に落とすことが出発点です。

1．まず確認すべきは「DPAが必要な関係か」

GDPR第28条が直接問題となるのは、GDPRが適用される個人データ処理について、管理者が処理者に処理を委託する場面です。契約書上の呼称ではなく、実際に誰が処理の目的と主要な手段を決めているかを確認します。

「DPA」という独立した文書を必ず別途署名しなければならないわけではありません。GDPR第28条が要求する事項を満たすのであれば、マスターサービス契約の別紙、データ保護条項、オンラインで合意される追加条項等として構成することもできます。GDPR第28条は、契約その他の法的行為が書面（電子形式を含む。）であることを求めています。

2．controller / processorの判定を契約名だけで決めない

DPA交渉で最も重要なのは、契約のテンプレートを選ぶ前に役割を判定することです。GDPR上、管理者は個人データ処理の「目的」と「手段」を決定し、処理者は管理者のために個人データを処理します。EDPBも、形式的な契約名ではなく実態に基づいて役割を判断する考え方を示しています。

実務では、一つのサービス提供者が処理ごとに異なる役割を持つことがあります。たとえば、SaaS事業者が顧客企業の業務データを顧客の指示に従って処理する部分では処理者となり得る一方、請求先担当者情報や自社サービスのセキュリティログを自社の独立した目的で扱う部分については、別の評価が必要になることがあります。

2-1．AI・分析機能では「自社目的利用」の有無を確認する

生成AIや分析サービスでは、入力データを顧客の指示どおりに処理するだけなのか、それともベンダーがモデル改善、広告、プロファイリングその他の独自目的に再利用するのかを確認します。独自目的で目的・手段を決める処理まで一律に「processor」と表示しても、実態と一致しなければ十分ではありません。

GDPR第28条10項は、処理者がGDPRに反して自ら処理の目的と手段を決定した場合、その処理について管理者とみなされ得ることを定めています。したがって、「サービス改善のため利用できる」といった条項は、DPA本体だけでなく利用規約、プライバシーポリシー、製品仕様と合わせて確認する必要があります。

3．GDPR第28条でDPAに求められる主要事項

GDPR第28条3項は、管理者と処理者の契約等に含めるべき事項を具体的に定めています。条文を並べるだけでは運用できないため、「契約で何を決め、実務では何を用意するか」を対応させることが重要です。

4．必須条項を「運用できる条項」にするポイント

4-1．処理指示と目的外利用の線引きを明確にする

DPAでは、「管理者の指示に従う」と記載するだけでなく、通常の指示が何かを処理別紙やサービス仕様で特定します。データの種類、処理目的、保存場所、保持期間、利用可能な機能、統計化・匿名化の扱いなどを整理しておくと、後から「その利用は顧客の指示の範囲か」という争いを減らせます。

特に、製品改善・機械学習・不正検知・広告などにデータを利用する場合は、それが顧客のための処理なのか、ベンダーの独立目的なのかを分けて設計する必要があります。

4-2．安全管理措置はSecurity Annex（TOMs）で具体化する

「業界標準のセキュリティを講じる」といった抽象的な文言だけでは、実装との照合が困難です。GDPR第32条は、リスクに応じて、仮名化・暗号化、機密性・完全性・可用性・回復力、復旧、対策の有効性を定期的に検証するプロセスなどを考慮することを求めています。

• アクセス権限、特権ID、MFA、認証・認可の設計
• 通信時・保存時の暗号化、鍵管理
• ログの取得・保全・監視、異常検知
• 脆弱性管理、パッチ、ペネトレーションテスト等
• バックアップ、復旧目標、事業継続
• 従業者管理、教育、秘密保持
• データ削除、媒体廃棄、環境分離
• インシデント対応、連絡経路、フォレンジック協力

実務では、本文に細かな技術仕様を書き込みすぎると変更のたびに契約改定が必要になります。契約本文で義務の骨格を定め、Security AnnexやTOMsに実装内容を整理し、重要な変更の通知・同等性維持のルールを置く方法が扱いやすいでしょう。

4-3．再処理者は「全面禁止」より変更管理を設計する

クラウド型サービスでは、ホスティング、メール配信、サポート、監視、分析など複数の再処理者を利用することがあります。GDPR第28条2項は、管理者の事前の個別承認又は一般的書面承認を求め、一般的承認の場合は、処理者が追加・変更を管理者に知らせ、異議を述べる機会を与えることを求めています。

DPAでは、再処理者一覧の掲載場所、変更通知期間、異議を述べられる理由、解決できない場合の代替措置・解約、再処理者にも同等のデータ保護義務を課すことを定めます。GDPR第28条4項上、再処理者が義務を履行しない場合でも、元の処理者は管理者に対してその履行について全面的な責任を負います。

4-4．漏えい通知は「72時間」をそのまま転記しない

契約上は、処理者が事実確認の完了を待たずに初動通知を行い、その後に原因、対象データ、件数、影響、封じ込め状況等を段階的に更新する仕組みを設けます。具体的な通知時間を合意する場合も、それは当事者の契約上のSLAであり、GDPRが処理者に一律24時間等を直接課しているわけではない点を区別します。

4-5．監査権は「実効性」と「過度な負担」を両立させる

GDPR第28条3項は、処理者に対し、遵守を示すために必要な情報を提供し、管理者又はその委任を受けた監査人による監査・検査を可能にし、これに協力することを求めています。ただし、SaaS事業者が多数の顧客から無制限のオンサイト監査を受けることは現実的ではありません。

そこで、通常時はISO認証、SOC報告書、第三者監査結果、質問票等を第一次的な確認手段とし、重大事故、重大な契約違反の合理的疑い、規制当局からの要請など一定の場合に追加監査を行う設計が考えられます。監査の通知期間、頻度、秘密保持、費用、他顧客情報の保護も定めておくと実務上の摩擦を減らせます。

4-6．終了時の「削除」はバックアップまで設計する

契約終了時には、管理者の選択に従って個人データを返却又は削除し、法令上保存が必要な場合を除きコピーを削除することがGDPR第28条3項で求められます。実務では、即時に本番環境から削除できても、バックアップや災害復旧領域から直ちに物理消去できないことがあります。

DPAでは、本番データの削除期限、エクスポート形式、バックアップの自然消去サイクル、その期間中の隔離・利用禁止、法令保存データの分離管理、削除証明の有無をサービス実装に合わせて定めます。契約上「直ちに完全削除」と書きながらシステム上実現できない状態は避けるべきです。

5．DPAとSCCは同じものではない

「SCCを締結したからDPAは不要」「DPAがあれば国外移転も適法」という理解は正確ではありません。EUには、名称が似ていて目的の異なる標準契約条項があります。

越境移転がある場合は、DPAの有無とは別に、移転先、移転経路、十分性認定やSCC等の移転根拠、必要な追加措置を確認します。SCCを利用する場合も、実際の移転先国の法制度や技術的・組織的措置の検討を契約書の添付だけで終わらせないことが重要です。

6．日本の個人情報保護法では「DPAという名称」より委託先監督が重要

日本の個人情報保護法は、GDPR第28条と同じ形式で「DPA」という名称の契約締結を一律に義務付けているわけではありません。しかし、個人情報取扱事業者が個人データの取扱いを委託する場合、個人情報保護法第25条に基づき、委託先に対する必要かつ適切な監督を行わなければなりません。

個人情報保護委員会のガイドラインは、委託先の選定、委託契約の締結、委託先における取扱状況の把握を通じて、委託元が講ずべき安全管理措置と同等の措置が委託先でも確保されるよう監督する考え方を示しています。契約では、取扱い範囲、安全管理、再委託、事故報告、監査・報告などを定め、締結後も実際の運用状況を確認することが必要です。

6-1．委託なら「第三者提供ではない」で終わらない

利用目的の達成に必要な範囲で個人データの取扱いを委託する場合、個人情報保護法上、委託先は一定の範囲で「第三者」に該当しないため、通常の第三者提供と同じ同意手続を直ちに要するわけではありません。しかし、委託先は委託された業務の範囲を超えて個人データを取り扱えるわけではなく、委託元の監督義務も残ります。

6-2．海外委託では日本法とGDPRを別々に確認する

海外のクラウドや再委託先を利用する場合、日本法上の外国にある第三者への提供規制の適用関係と、GDPR上の国際移転規制の双方を確認する必要があります。EUから十分性認定に基づいて日本へ移転された個人データについては、日本側の補完的ルールにも留意します。

「データセンターが海外にある」「契約相手が海外法人である」といった一つの事情だけで結論を出すのではなく、誰がどの法人へどのデータを提供・委託し、どの国からどの国へアクセス・移転されるのかをデータフローで確認することが有効です。

6-3．裁判例から見る委託先監督と安全管理措置

東京地裁令和6年3月25日判決（平成27年（ワ）第11262号）と、その控訴審である東京高裁令和7年1月22日判決（令和6年（ネ）第2935号）は、大規模な個人情報漏えいについて、委託先の安全管理措置と委託元の監督が問題となった一連の裁判例です。

本件では、委託元が顧客情報システムの開発・運用等を外部会社へ委託し、その業務がさらに多段階で再委託されていました。実際に顧客情報を持ち出したのは、委託元から見ると4次委託先の従業員で、業務用パソコンに私物スマートフォンをUSB接続し、MTPという通信方式を利用して大量の顧客情報を転送し、外部へ持ち出しました。

一審は、委託先において、導入済みのセキュリティソフトの設定を変更し、MTP対応スマートフォンへの情報書き出しを防止する措置を講ずべき注意義務があったとして、情報書き出し制御措置義務違反を認めました。また、委託元についても、委託先に対する監督を怠った過失を認めました。

控訴審も一審の判断を維持しました。委託元は委託先に対する定期的な監査自体は実施していましたが、セキュリティソフトの具体的な設定内容は監査対象となっていませんでした。東京高裁は、適切に報告を求めていれば、スマートフォンへの書き出し制御・接続制御が不十分であることを把握し、設定変更等を指示できたとして、委託先監査は不十分だったと判断しています。

さらに東京高裁は、個人情報保護法上の「必要かつ適切な監督」の内容は、ガイドラインに例示された事項だけに限られるものではなく、当時の予見可能な事情を含む、個人データの安全管理に関する個別的な事情によって定まるとしています。

この裁判例から、DPAや委託契約を締結し、定期監査を行っているという形式だけで監督が十分になるとは限らないことが分かります。もっとも、委託元が常に委託先の全システム設定まで確認しなければならないという一般論を示したものではありません。取り扱うデータの性質・量、アクセス方法、利用端末、再委託構造、技術の変化等を踏まえ、契約上のTOMsや監査項目が実際のリスクに対応しているかを継続的に確認することが重要です。

7．損害賠償・制裁金条項はDPAだけで完結させない

DPAでは、データ侵害時の補償、損害賠償の上限、第三者請求、規制当局対応費用などが交渉になります。ただし、当事者間の責任制限条項を置いても、それ自体によって監督機関の権限やデータ主体の法定権利を制限できるわけではありません。DPAと本体契約の責任条項の優先関係も明確にしておく必要があります。

GDPR第83条では、第25条から第39条までの管理者・処理者の義務違反（第28条を含む。）について、一定の場合に最大1,000万ユーロ又は全世界年間売上高の2％のいずれか高い方までの行政制裁金が規定されています。一方、基本原則や国際移転規制等の一定の違反は、最大2,000万ユーロ又は4％の層に位置付けられています。DPA違反を一律に「2,000万ユーロ又は4％」と説明するのは正確ではありません。

また、GDPR第82条では、処理者が損害について責任を負うのは、処理者に直接課されるGDPR上の義務に違反した場合、又は管理者の適法な指示から外れて行動した場合等とされています。契約交渉では、法定責任と当事者間の補償・責任上限を区別して設計します。

8．DPA交渉で優先順位を付ける

すべての条項を最大限厳しくすることが最適とは限りません。サービスのデータ量、要配慮個人情報の有無、停止時の影響、代替可能性、再処理者の数、海外移転などを踏まえ、事故時に本当に機能する条件へ優先順位を付けます。

9．DPAを締結するまでの実務フロー

10．弊所の実務上の視点｜DPAは契約と運用をつなぐ

DPAレビューでは、法令上の必須文言が揃っているかだけでなく、契約上の約束をシステムと運用で本当に実行できるかを確認することが重要です。特に次のような不整合は、事故や顧客監査の場面で問題になりやすいポイントです。

• 契約上はprocessorとされているが、サービス改善等の名目で独自目的利用が広く認められている
• 「72時間以内」とだけ書かれ、処理者から管理者への初動通知と管理者から当局への法定通知が区別されていない
• 再処理者の一般承認条項はあるが、最新一覧・変更通知方法・異議手続が実装されていない
• 高度な安全管理を契約で約束しているが、Security Annexと実際のインフラ設定が一致していない
• 終了時「完全削除」としているが、バックアップの保持期間やデータ移行手段が整理されていない
• 監査権が無制限又は逆に形骸化しており、現実的な証跡確認の方法が設計されていない

そのため、DPAは法務だけで完成させず、情報セキュリティ、プロダクト、インフラ、カスタマーサポート、営業・調達などと確認しながら作る方が実効性が高まります。特にSaaS提供者側では、複数顧客に共通して提示できる標準DPA・TOMs・再処理者一覧を整備し、例外交渉の基準を社内で決めておくと契約締結の速度も上げやすくなります。

11．DPAチェックリスト

12．FAQ

主要な一次資料・公的資料

• EU「Regulation (EU) 2016/679（GDPR）」第26条、第28条、第32～36条、第44～49条、第82条、第83条
• European Commission「Commission Implementing Decision (EU) 2021/915」（controller / processor間の標準契約条項）
• European Commission「Commission Implementing Decision (EU) 2021/914」（第三国移転の標準契約条項）
• European Data Protection Board「Guidelines 07/2020 on the concepts of controller and processor in the GDPR」
• European Data Protection Board「Recommendations 01/2020 on measures that supplement transfer tools」
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（外国にある第三者への提供編）」
• 個人情報保護委員会「個人情報の保護に関する法律に係るEU及び英国域内から十分性認定により移転を受けた個人データの取扱いに関する補完的ルール」

まとめ｜DPAはテンプレートではなくデータ処理の設計図

DPAで重要なのは、GDPR第28条の必須文言を形式的に並べることではありません。誰がcontroller / processorなのかを処理ごとに確認し、実際のデータフロー、セキュリティ、再処理者、事故対応、本人対応、削除・返却を契約と一致させる必要があります。

また、DPAと越境移転SCC、日本の個人情報保護法上の委託先監督は、それぞれ関連しながらも別の論点です。国内外のクラウドやAIサービスを組み合わせる場合ほど、契約単体ではなく、データフロー図・TOMs・再処理者一覧・事故対応手順まで一体で整備することが重要です。

DPA・データ処理契約のご相談