DPAとは何か（後編）｜SaaSのDPAの具体的な中身

個人データの処理を外部に委託する場面が増えるなか、「DPA（Data Processing Agreement：データ処理契約）」の重要性が高まっています。しかし、DPAは単にひな形を埋めれば完成する文書ではありません。自社のデータ処理の実態に合わせて、何をどこまで書くべきかを設計する必要があります。本記事では、DPAに盛り込むべき代表的な規定と、日本企業が押さえておきたい実務上のポイントを解説します。

結論｜DPAは「ひな形を埋める文書」ではなく、自社のデータ処理実態に合わせて設計すべき文書

DPAの作成では、インターネット上のひな形をそのまま使う方も少なくありません。しかし、DPAは自社がどのようなデータを、どのような目的で、どのように処理するかによって内容が大きく変わります。ひな形の丸写しでは、実態と乖離した義務を負ったり、必要な規定が抜け落ちたりするリスクがあります。

前編のおさらい｜DPAは「個人データ処理」の役割分担を定める文書

DPAとは、個人データを取り扱う際の「管理者（コントローラー）」と「処理者（プロセッサー）」の役割分担を明確にする契約です。誰がデータの利用目的を決め、誰がその指示に従って処理を行うのか。この関係性を整理し、各当事者の義務を定めるのがDPAの役割です。

⇒⇒DPA前編はこちらから：DPAとは何か（前編）？SaaS事業者が最初に押さえるべき基本

DPAに入る代表的な規定

①処理の目的・対象データ・処理内容

DPAの出発点は、「何のために」「どのようなデータを」「どう処理するか」を明確にすることです。処理の範囲が曖昧だと、後から「この処理は契約範囲外だ」といった紛争の原因になります。

②指示に従った処理

処理者は、管理者の指示に従ってのみデータを処理する義務を負います。処理者が独自の判断でデータを利用することは原則として認められません。

③守秘義務

処理者およびその従業員は、取り扱う個人データについて守秘義務を負います。アクセスできる人員を限定し、秘密保持契約を締結させることが一般的です。

④監査・情報提供

管理者が処理者の対応状況を確認できるよう、監査権や情報提供義務を定めます。ただし、SaaS事業者などでは実地監査が現実的でない場合もあり、代替手段の設計が重要です。例えば、第三者による監査レポート（SOC2、ISO27001等）の提供をもって監査に代えるという方法があります。

⑤契約終了時の返却・削除

契約が終了した際に、個人データをどう扱うかを定めます。返却するのか、削除するのか、バックアップの扱いはどうするのか、事前に合意しておく必要があります。

⑥データ侵害時の通知

個人データの漏えいや不正アクセスが発生した場合、処理者は管理者に速やかに通知する義務を負います。通知期限や通知内容をどこまで具体化するかは交渉のポイントになります。

⑦責任分担

損害が発生した場合の責任の所在や賠償の上限を定めます。責任範囲が曖昧だと、紛争時に大きな問題となります。

再委託（サブプロセッサー）をどう定めるか

サブプロセッサーとは、データ処理者（プロセッサー／ベンダー）が、サービス提供のためにデータ処理の一部をさらに委託する第三者のことです。

現代のSaaSやITサービスでは、自社リソースだけで全てを完結させることは稀で、AWSやGoogle Analyticsのようなサービスが典型的なサブプロセッサーとなります。

処理者の再委託先が、データを好き勝手に使ってはDPAの意義が没却されてしまいます。

サブプロセッサー条項は、「情報のバケツリレー」において、途中でバケツに穴が開かないよう、またバケツを渡す相手を勝手に変えないよう縛るためのルールといえます。

安全管理措置をどう書くか

DPAにおける安全管理措置（Technical and Organizational Measures / TOMs）条項は、いわば「データの守り方に関する具体的なルールブック」です。

前述のサブプロセッサー条項が「誰が」扱うかを決めるものなら、こちらは「どうやって」守るかを定義する、DPAの心臓部とも言えるセクションです。

技術的・組織的措置をどう表現するか

安全管理措置は、暗号化、アクセス制御などの「技術的措置」と、従業員教育や内部規程の整備などの「組織的措置」の２つに分けて書くことが一般的です。

抽象的な約束にとどめるか、具体的措置まで書くか

「適切な措置を講じる」という抽象的な表現で足りる場合と、具体的な措置を別紙で列挙すべき場合があります。相手方の要求水準や業界慣行を踏まえて判断します。

この条項をチェック・作成する際は、以下の点に注意が必要です。

• 「内容の固定化」のリスク： 技術は日々進化します。条項があまりに具体的すぎると、新しい技術を導入した際に契約違反になってしまう可能性があります。そのため、「同等以上の水準を維持しつつ、更新できる」という柔軟性を持たせることが一般的です。
• 「別紙（Annex）」への切り出し： DPA本文には「適切な措置を講じる」という基本方針だけを書き、具体的なセキュリティチェックリスト（どの暗号化方式を使っているか等）は「別紙」にまとめて参照する形が、実務では最もスマートとされています。

契約終了後の返却・削除をどう設計するか

データ処理者（SaaSベンダー）の立場からすると、「契約終了時のデータ返却・削除」条項は、実は最も「運用コスト」と「法務リスク」が直結する部分です。

契約が切れた後もダラダラとデータを持ち続けることは、漏洩リスクを抱え続ける（かつ保管コストがかかる）だけであり、SaaSベンダー側としても「いかに速やか、かつ確実に手を離すか」という設計が重要になります。

返却か削除か

通常、DPAでは「管理者の選択に従い、削除または返却する」と記載されます。提供側としては、以下の点を用意しておく必要があります。

• 返却形式の限定： 「当社が指定する標準的なフォーマット（例：CSV）」での提供に限定しましょう。特殊な形式での返却を求められると、開発コストが発生してしまいます。
• デフォルトルールの設定： 「終了後○日以内に、管理者から返却の指示がない場合は、当社の判断で削除できる」という規定を入れます。これにより、連絡が取れない顧客のデータを永遠に保持し続けるリスクを回避できます。

バックアップデータの扱い

多くの提供側が陥る罠が、「本番環境からは即座に消せるが、バックアップ（テープ保存やアーカイブ）からはすぐには消せない」という物理的な制約です。

これがないと、契約終了の翌日に「バックアップも含めて完全に消去した証明を出せ」と言われた際、技術的に不可能な約束をしたことになってしまいます。

上記の不都合の対策として、 「バックアップに記録されたデータについては、当社の通常のバックアップサイクルに従って上書き・削除されるものとする。それまでの間は、安全管理措置を継続する」といった免責条項を入れます。

削除完了の確認方法

削除証明書の発行を求められることもありますが、対応可能な範囲を事前に確認しておくべきです。

究極の対策

特にSaaSを提供されている場合、「管理画面から顧客自身がデータをエクスポート・削除できる機能」を備えておくことが、究極の対策になります。

「契約終了前までに、お客様自身の操作でエクスポートしてください。終了後は当社のスケジュールで消去します」という運用に誘導できれば、個別の手作業が発生せず、リスクも最小限に抑えられます。

越境移転をどう扱うか

海外サーバーを利用する場合や、再委託先が海外にいる場合、個人データの越境移転が生じます。GDPRが適用される場面では、標準契約条項（SCC）の締結など追加的な対応が必要になる場合があります。日本法のみで足りるケースとGDPR対応が必要なケースを整理し、DPAにどこまで明示すべきかを検討しましょう。

日本法とGDPRの違い

GDPRは処理者との契約締結を法的義務として明確に定めています。一方、日本の個人情報保護法では「DPA」という名称の契約は義務付けられていませんが、委託先の監督義務があり、実質的には同様の対応が求められます。海外顧客を持つ場合やEU域内の個人データを扱う場合は、GDPR対応を視野に入れた設計が必要です。

日本企業向け実務設計｜3層構造で考える

純国内市場のみを対象とする日本企業にとって、欧州並みの詳しいDPAは必ずしも必要ではありません。日本企業がDPAを設計する際は、以下の3層構造で考えると整理しやすくなります。

• 第1層：日本国内向けの基本条項（委託先監督義務を満たす最低限の規定）
• 第2層：海外展開も見据えた追加条項（GDPR対応の基礎的な規定）
• 第3層：大企業・海外顧客向けの高度対応条項（詳細な監査対応や厳格な通知義務など）

この3層のうち、どこまでを標準装備とし、どこからを個別交渉事項とするかを決めておくと、契約交渉がスムーズになります。

よくある失敗

• 顧客のDPAひな形をそのまま受け入れる：自社の運用と合わない義務を負ってしまうリスクがあります。
• 利用規約やNDAとの役割分担が曖昧：どの文書で何を定めるか整理しておかないと、矛盾や抜け漏れが生じます。
• 実際の運用に合わない義務を書いてしまう：守れない約束は契約違反のリスクを高めます。

まとめ｜DPAは「事業運営に耐える契約設計」で考える

DPAは、法令対応のためだけに作成する文書ではありません。自社のサービス内容、顧客層、データ処理の実態を踏まえ、事業運営に耐えうる契約として設計することが重要です。ひな形をそのまま使うのではなく、自社に合った形にカスタマイズすることで、リスクを適切にコントロールできます。

DPAの作成や見直しについて不安がある場合は、早めに専門家に相談することをお勧めします。当事務所でも対応しておりますので、お気軽にお問い合わせください。