Data Processing Agreement（DPA、データ処理契約）の作り方～セキュリティ措置を中心に～
本記事は裏 法務系 Advent Calendar 2024のエントリーです。
A0さんからバトンを受け取りました。セキュリティ要素が少し重なってうれしいです。
法務系アドベントカレンダー初参加ですのでお手柔らかにお願いします。🙇
はじめに
海外に事業展開すると今や個人データの保護を避けて通れません。
はじめて海外の個人データ保護法に相対するとき、「GDPR！GDPR！」といわれる一方で、具体的に何をすればいいのかに悩むことでしょう。
GDPRがどのようなものか調べる以下のような記事を書いてみましたが、今回はDPAといわれるデータ処理契約について深堀りしたいと思います。
Data Processing Agreement（DPA、データ処理契約）とは
GDPR28条とGDPR32条で求められる個人データの保護のための契約。
日本でいう委託先との契約（GDPRではクラウドサービスなども一律でProcessorになるため対象の相手の範囲は広い）。
会社によってはProcessingでなくProtection（処理でなく保護）であるときがあります。
またAgreementでなくAddendum（追加条項）のときがあります。この場合は利用規約など別の契約条件に追加的に設けられています。
いずれであってもその効力に違いはありません。
後述のSCCと違いフォーマット指定はないため、各社体裁や条項はばらついています。
必要的記載事項
28条によって以下のように規定されています。
処理の対象と期間
処理の性質と目的
処理される個人データの種類とデータ主体のカテゴリ
管理者（Controllerであって処理者の指揮命令者でない）の義務と権利
管理者による文書化された指示に基づいてのみ個人データを処理する旨
処理の従事者が秘密保持を負うことを保証する旨
32条にもとづく措置
Sub-Processorを起用する場合の管理者の事前の承認
管理者がデータ主体の権利行使に応じることを支援する旨
管理者のセキュリティ措置、侵害通知、データ保護影響評価、監督機関との事前協議を支援する旨
管理者の求めに応じて処理終了後に個人データを削除・返却する旨
義務の順守を証明するための情報の提供、監査の協力
指示がGDPR等に反する場合は管理者に通知する旨
求められるセキュリティ事項
32条では、”とりわけ（inter alia）”以下の内容を含む、「リスクに応じた適切な技術的および組織的安全管理措置」（1項）と規定されています。
個人データの仮名化・暗号化
処理システムおよびサービスの、秘密性、完全性、可用性および回復力の継続に対する保証能力
物理的または技術的インシデント時の適時の個人データへの可用性及びアクセスの復元力
処理のセキュリティを保証する技術的及び組織的安全管理措置の有効性に対する定期的なテスト、評価および見直すプロセス
リスクに応じた適切な措置を評価する際には、”特に（in particular）”「送信、保存その他の処理された個人データに対する、偶発的または不法な破壊、紛失、変更、不正な開示またはアクセスによって生じるリスクを考慮する」（2項）とされています。
管理者および処理者は、個人データにアクセスする管理者・処理者の自然人が個人データを管理者の指示以外に処理しないことを保証する対策（守秘誓約などいわゆる人的安全管理措置）を施さなければならない（shall take steps）、ただしEUまたは加盟国の法令で求められる場合はこの限りでない（4項）ともされています。
上記に加えて、5条では「データ最小化」、28条2項では「必要最小限のアクセス」が求められますので、これについての言及もできれば望ましいでしょう。
個人データに関する一連の処理と求められる安全管理措置のイメージを図示すると以下になります。
DPAはEU圏以外も必要なの？GDPR基準で１つ作れば通じるの？
DPAはGDPRを参考に個人情報保護法を作った国々でも採用され、今や多くの国で求められます。
中国、シンガポール、GDPRを参考にしたタイなどで求められています。
基本的に各国観点は同じであるため、GDPRの基準で用意すれば問題はないと思われます。
また現地語であることが明示的に義務付けられているものは見当たりません（ただしインドネシアは言語法により必要になる可能性があります）。
ただし、カリフォルニア州の場合はService Providerが処理者に相当しますが、GDPRにおけるDPAとは内容が異なります（CPRA7051）。
そのため、グローバルを対象にしたDPAの場合はCCPAの内容を特約として定めていることが多いです。
他にUK GDPRも特約として定められることが多くあります。
SCC (Standard Contractual Clauses)って？DPAと何が違うの？
SCCはGDPR28条と46条(2)(c)で求められる個人データの越境移転をする際の保護措置としての標準契約条項です。
「保護レベルの低い国はGDPRと同水準の義務を契約で確保しろ」というものです。
決まったフォーマットがあり、2021年に新しいものが採択されています（新SCC）。
移転先（の国）が適切な個人データの保護水準を持っていない場合、SCCによって契約としてGDPRと同水準の保護を強制するものになります。（GDPR条文の押し付け）
管理者・処理者、処理者・処理者、などの組み合わせによってモジュール（条項セット）が設けられており、選択をしたうえで、原則この内容のまま締結することになっています。
SCCはDPAの内容を含んでいるため、SCCを締結するならばDPAも締結したことになります。（QA29）
なお、2024年現在、日本はEUの十分性認定を受けているため、SCCなくEUの個人データを日本に移転させることができます。ただしその場合、補完的ルールを遵守しなければなりません。
しかし安全のため、SCCを締結してしまうことを選択するケースもあるでしょう。
また、日本の管理者が、日本国内の処理者にGDPR対象の個人データの処理を委託する際は、両者とも十分性認定国内の事業者であるので、SCCを使う必要はなく、DPAの内容を満たせばよいことになります（QA29）。
ただし、日本企業同士であっても基本的に英語で締結することが一般的です。
日本でも、日本と同水準の個人情報保護制度を有する国以外には法第4章第2節の規定の趣旨に沿った措置として契約を締結することがありますが、標準条項は定められていないものの同じような狙いのものです。
ASEAN加盟国ではASEANモデル契約条項が採択されていますが、推奨している国、GDPRのSCCでも可としている国、明確でない国（越境移転規制を持たない国）など、対応がばらけているためか、実際に使われている場面は多くないのではないかと思います。なおSCCと違いアレンジを認めています。
シンガポールはASEANモデル契約条項とEU SCCの対比及び要件充足性についてはガイドを公表しています。
主なベンダーのDPAの例
以下に入手できるDPAを参考として載せます。
とりあえず作るには
一から作る場合はProton AGのものをベースに、処理の対象と期間、処理の性質と目的、処理される個人データの種類とデータ主体のカテゴリ、セキュリティ措置、サブプロセッサーのリストは別紙にすることで、とりあえずの形にできます。
また文章として参考にする際はAWSがシンプルで使い勝手のよいものと思われますので参考になります。
カリフォルニア州の個人データの扱いもカバーするには以下の言及を足します。
カリフォルニア州の個人データを販売または共有しないこと。
※「販売・共有」はCPRAの定義を参照。CCPAを遵守すること。
SCCを組み込むには
SCCを締結するならDPAは不要と書きましたが、逆に基本はDPAとして運用しつつ、SCCが必要になる越境移転が発生した場合も想定してカバーしなければいけない場合があります。日本の場合、EU以外の標準契約条項を求めている国の個人データを越境させる場合などです。
その場合は、以下の言及も足します。
標準契約の定義を追加
※中国、UKのような独自のSCCを持つ国。なお中国は免除規定も考慮。DPAに組み込まれる旨を追加
※適用モジュールの言及なども行います。該当する移転の際はSCCが優先適用の言及を追加
※日本への移転の場合は厳しいSCCを適用させないように「十分性認定、BCRに基づく移転が適用可能な場合以外にSCCに基づき移転する」という記載にすることも考えられます。
なお、シンプルなDPAではSCCを満たせない条項として以下があります。
データ主体の権利を第三受益者の権利として認めること
データ主体の救済方法
ドッキング条項（オプション条項）
EEC域内の加盟国を準拠法、管轄とすること。
監督機関の管轄に服すること
公的機関によるアクセスの場合の対応
EU、中国のSCCは当局の監督を直接受けることを認めることになるので、本当に締結していいかは十分性認定や免除規定を踏まえて慎重に考えるべきでしょう。
セキュリティ措置の記載
GDPRは「リスクに応じた適切な技術的および組織的安全管理措置」を求めていますが、具体性がなく何を書けばよいのか悩ましいポイントです。
項目の観点からはICOが公表している英国GDPRにおけるセキュリティ措置のガイドが参考になるでしょう。
大枠は日本の個人情報保護法ガイドラインが求める「講ずべき安全管理措置」に沿えば満たすこともできます（インシデントからの回復の観点が弱いので追加が必要）。
また各社の記載を見るとわかるとおり、必ずしもGDPR32条(a)～(d)の順番に沿って記載する必要はありません。
最も重要視され、最低限記載すべき項目としては以下と思われます。
いわゆる秘密性、完全性、可用性の項目になります。
従業員の教育
入退室管理、ユーザー認証、アクセス制御
送信、保存時のデータの暗号化措置
不正アクセス、マルウェア対策
バックアップ
ログ監視・監査証跡
インシデント対応、復旧手順の策定
継続的な改善
具体的には実際に処理する個人データの種類や状況を加味して設定と記載が必要になりますが、組織的・人的・物理的・技術的安全管理措置の観点から記載していけばよいでしょう。
ISMS認証を取得している会社であれば安全管理措置の観点から抜粋して記載することで基本的には足りると思われます。
上記をチェックリスト的にして、担当事業部に「こういうことはやってますか？」というようなコミュニケーションをしながら、「記述する」のではなく「埋めて」いきましょう。
さいごに
DPAの参考資料、必要的記載事項、セキュリティ措置の主要ベンダーの比較表を添付しますので、常識の範囲でご自由にお使いください。
次回はマギー住職さんです！