GDPRのController/Processorを、目的と本質的手段、DPA、日本法の委託先管理、SaaS・AI・越境移転まで企業法務の実務目線で整理します。
目的と本質的手段を誰が決め、誰が指示に従って処理するかを最初に整理します。
目的と本質的手段を誰が決め、誰が指示に従って処理するかを最初に整理します。
ControllerとProcessorの役割分担は、個人データ処理について、誰が目的と本質的手段を決め、誰がその指示に従って処理するだけかを切り分ける作業です。単に発注者ならController、受託者ならProcessor、大企業ならController、SaaSベンダーならProcessorと決めることはできません。
このページは、企業法務、プライバシー法務、IT・AI・データ法務、コンプライアンス、内部監査、契約実務、M&A、危機管理の観点から一般的な情報を整理するものです。特定案件の法律意見や当局対応方針ではありません。実際の契約、越境移転、漏えい対応、M&A、共同利用、AI・広告配信・クラウド利用では、対象国、業種、データ類型、契約構造、運用を踏まえ、弁護士等の専門家による個別確認が必要です。
次の比較表は、ControllerとProcessorの中核的な違いを示しています。契約名だけでなく、責任、契約上の整理、注意点を同時に確認することで、DPAや本人対応の設計を誤りにくくなります。
| 観点 | Controller | Processor |
|---|---|---|
| 中核的な役割 | 処理の目的と本質的手段を決定します。 | Controllerの指示に基づき、Controllerのために処理します。 |
| 典型例 | 顧客管理を行う事業会社、従業員データを管理する雇用主、マーケティング目的を決める広告主などです。 | 給与計算代行会社、ホスティング事業者、メール配信代行会社、BPO事業者などです。 |
| 契約上の整理 | プライバシー通知、法的根拠、権利対応、委託先管理、越境移転、DPIAなどを整えます。 | DPA、指示処理、秘密保持、安全管理、再委託、監査、削除・返却、侵害通知などを整えます。 |
| 責任の性質 | 原則として処理全体の適法性について中心的な責任を負います。 | Processor固有義務違反、指示違反、指示逸脱、再委託管理違反などについて責任を負います。 |
| 重要な注意点 | データへ直接アクセスしなくても、目的や本質的手段を決めていればControllerになり得ます。 | 技術的・組織的な実装方法を一定範囲で選んでも、直ちにControllerになるとは限りません。 |
EDPBのガイドラインは、Controller/Processorを形式的な肩書ではなく、実際の活動から判断する機能的な概念として説明しています。契約書にProcessorと書いてあっても、相手方が独自目的でデータを利用していれば、その範囲でControllerまたはJoint Controllerになり得ます。
DPA、本人対応、漏えい通知、再委託、越境移転、損害賠償の責任分界に直結します。
ControllerとProcessorの役割分担は、用語整理ではなく、企業がどの契約を結び、誰が本人対応を行い、誰が漏えいを当局に報告し、誰が再委託を承認し、誰が越境移転や損害賠償リスクを負うかを決める基礎構造です。
次の一覧は、役割分担が問題になりやすい場面を整理しています。導入前、契約交渉前、事故対応前に確認することで、DPA未締結や通知漏れなどの実害を抑えやすくなります。
SaaS、クラウド、BPO、給与計算、CRM、MAツール、広告配信、アクセス解析、生成AI、データ分析サービスで問題になります。
販売代理店、プラットフォーム、アプリ、広告代理店、決済代行、物流会社との個人データ共有で整理が必要です。
欧州居住者、EU拠点、英国拠点、海外顧客、海外ユーザー、グローバル従業員のデータで重要になります。
ランサムウェア、クラウド設定ミス、委託先事故、内部不正では、通知先と期限を事前に決めておく必要があります。
当局調査、顧客監査、SOC2/ISO監査、内部監査、上場審査、取引先DDでは、分類根拠と証跡が問われます。
分類を誤ると、本来必要なDPAがない、本人対応義務の分担が合わない、法的根拠やプライバシー通知が不足する、独自利用を単なる委託として扱う、再委託承認が抜ける、侵害通知の期限が決まらない、日本法の委託先管理とGDPR上のProcessor管理を混同する、といった問題が起きます。
GDPR上、Controllerは適法性、透明性、データ主体の権利、安全管理、Processor選定、DPA締結、越境移転、侵害通知などについて広範な責任を負います。Processorも、指示処理、秘密保持、安全管理、再委託管理、Controllerへの支援、削除・返却、監査協力、記録作成、侵害通知などについて直接義務を負います。
Personal Data、Processing、Joint Controller、Sub-processor、DPAまで一体で押さえます。
用語の理解がずれると、契約書の条項も社内運用もずれてしまいます。次の用語一覧では、GDPR上の意味と企業実務で確認すべき読み方を並べています。
識別された、または識別可能な自然人に関する情報を広く含みます。氏名、メールアドレス、従業員ID、顧客ID、オンライン識別子、位置情報、Cookie ID、端末識別子、IPアドレス、購買履歴、行動履歴、応募者情報、健康情報、信用情報などが問題になります。
データ分類収集、記録、保管、変更、閲覧、利用、開示、送信、結合、制限、消去、破壊など、個人データに対する広い行為を含みます。CRM保存、メール配信、クラウド保管、ログ分析、AIツールでの分類・要約も対象になり得ます。
処理範囲個人データ処理の目的および手段を単独または共同で決定する者です。目的、本質的手段、本人通知、法的根拠、保存期間、開示先などを誰が決めるかが中心になります。
目的と本質的手段Controllerに代わって個人データを処理する者です。Controllerとは別主体であり、Controllerのために、独自目的ではなく文書化された指示に従って処理していることが重要です。
指示処理複数の者が共同で処理の目的および手段を決定する場合に成立します。共同事業やデータ共有があるだけでは足りず、共同で目的・手段を決めているかを具体的に見ます。
共同決定ProcessorがControllerから受けた処理をさらに委託する先です。Controllerの事前承認または一般的承認、同等義務、所在地、変更通知、異議申立期間などが重要です。
再委託Controllerが決める本質的手段と、Processorに委ね得る非本質的手段を分けて考えることも重要です。下の比較では、目的や保存期間などの中核事項と、サーバ構成やバックアップ方式などの実装事項を区別して読んでください。
| 分類 | 主な項目 | 実務上の見方 |
|---|---|---|
| 本質的手段 | 処理目的、データ種類、本人カテゴリー、開示先、保存期間、法的根拠、本人通知です。 | 誰が決めるかによってController性が強くなります。 |
| 非本質的手段 | サーバ構成、バックアップ方式、暗号化アルゴリズム、チケット管理、ログ管理基盤、保守手順です。 | 専門的な実装としてProcessorに委ねられることがあります。 |
| 注意領域 | 保存期間、アクセス権限、第三者開示、再利用目的、プロファイリング、AI学習への影響です。 | 技術事項に見えても、目的や本質的手段に近づく場合があります。 |
DPAは、ControllerとProcessorの間で締結される個人データ処理契約です。処理の対象、期間、性質、目的、個人データの種類、本人カテゴリー、Controllerの義務・権利を定め、指示処理、秘密保持、安全管理、再委託、本人権利対応、侵害対応、削除・返却、監査協力を条項化します。
処理単位、発注者性、プラットフォーム性、アクセス可能性を分けて見ます。
一つの会社が常にControllerまたは常にProcessorになるわけではありません。同じSaaSベンダーでも、顧客が入力したエンドユーザー情報ではProcessorになり得る一方、契約管理、請求、アカウント認証、不正利用防止、マーケティング、プロダクト改善のための顧客担当者情報では自社Controllerになり得ます。
次の判断の流れは、契約名に引っ張られずに実態を見るための順番を示しています。上から順に、誰が目的と本質的手段を決めているか、相手方が指示に従うだけか、共同決定や独立目的がないかを確認します。
データ、本人カテゴリー、目的、保存期間、関与国、ベンダーを特定します。
なぜ処理するか、処理しない選択ができるか、成果を自社目的で使うかを見ます。
データ項目、本人カテゴリー、開示先、保存期間、AI学習、本人権利対応を見ます。
DPAだけでなく、責任分担やデータ共有契約を検討します。
指示処理、再委託、安全管理、削除・返却、監査を条項化します。
発注者が常にControllerとは限りません。弁護士、会計士、税理士、医師、監査法人、外部通報窓口、調査会社、信用調査会社などは、職業上の独立性、記録保存、利益相反確認、本人確認、品質管理、紛争対応を自ら行うため、独立Controllerになり得ます。
大規模SaaSやプラットフォームも、常にControllerになるわけではありません。顧客データを顧客の指示に従って処理し、独自目的で利用しない範囲ではProcessorになり得ます。ただし、広告、レコメンド、プロファイリング、サービス横断分析、第三者提供、モデル学習、信用スコアリングに利用する場合は、Controller性が強まります。
アクセスできるかどうかも、結論を単純に決めません。GDPR上は、個人データへ直接アクセスできなくても、処理目的や本質的手段を決めていればControllerになり得ます。逆に、クラウド事業者が技術的にアクセス可能でも、契約上・技術上の制約により顧客の指示に従うだけであれば、Processorと評価され得ます。
Controllerは処理の設計責任者として、適法性と説明可能性を中心的に担います。
Controllerは、個人データ処理の目的と本質的手段を決める者であり、処理全体の適法性と説明可能性について中心的な責任を負います。GDPRのアカウンタビリティの考え方では、適法に処理しているだけでなく、それを説明できることが重要です。
次の表は、Controllerが担う主な責任を一覧化したものです。各項目は、DPAだけでなく、プライバシー通知、社内規程、委託先管理台帳、インシデント対応手順に反映する必要があります。
| 項目 | Controllerの主な責任 |
|---|---|
| 処理目的 | なぜ処理するのかを決定し、目的外利用を防ぎます。 |
| 法的根拠 | 同意、契約履行、法的義務、正当利益などの根拠を整理します。 |
| 透明性 | プライバシー通知、利用目的、本人説明を整備します。 |
| データ最小化 | 必要なデータだけを取得・利用します。 |
| 正確性と保存期間 | 正確性を保つ手続、保存期間、削除基準を決めます。 |
| 安全管理 | 適切な技術的・組織的措置を実装します。 |
| Processor選定 | 十分な保証を提供するProcessorだけを利用します。 |
| DPA締結 | GDPR Article 28に対応する契約を締結します。 |
| 本人権利対応 | アクセス、訂正、削除、制限、異議、ポータビリティなどに対応します。 |
| 侵害対応 | 当局報告、本人通知、原因究明、再発防止を行います。 |
| DPIAと越境移転 | 高リスク処理のDPIA、SCCなどの移転根拠、補完的措置を検討します。 |
| 記録 | Article 30の処理記録、判断メモ、監査証跡を整備します。 |
ControllerのProcessor選定責任は、契約締結だけでは完了しません。契約前デューデリジェンス、契約条項、セキュリティ評価、再委託先確認、監査権、継続的モニタリングを通じて、十分な保証があるかを確認します。
個人データ侵害では、Controllerが監督機関へ不当な遅滞なく、可能な場合には認識後72時間以内に通知することが求められます。Processorは、侵害を認識した後、不当な遅滞なくControllerへ通知します。DPAでは、実務上、認識後24時間以内の初報、重大性が疑われる場合の直ちの初報、判明次第の続報など、Controllerが72時間ルールに対応できる設計が有用です。
説明責任のためには、データマッピング表、処理記録、役割分担メモ、法的根拠分析、正当利益評価、DPIA、TIA、DPA・SCC・Sub-processor一覧、セキュリティ評価票、委託先審査結果、契約交渉履歴、本人通知改定履歴、インシデント対応記録、監査報告・是正措置記録を残します。
Processorは単なる下請ではなく、GDPR上の直接義務と防御実務を持ちます。
ProcessorはControllerの指示に従う立場ですが、GDPR上は直接義務を負います。Article 28、Article 30、Article 32、Article 33、Article 82、Article 83に関連する義務・責任が問題になります。
次の表は、Processorに求められる主な義務を整理しています。Controller側は委託先監督の確認項目として、Processor側は標準DPAや監査対応資料の整備項目として読むことが重要です。
| 項目 | Processorの主な義務 |
|---|---|
| 指示処理 | Controllerの文書化された指示に従って処理します。 |
| 秘密保持 | 処理担当者に秘密保持義務を課します。 |
| 安全管理 | Article 32に基づく適切な技術的・組織的措置を講じます。 |
| 再委託 | Controllerの承認なくSub-processorを利用しない運用にします。 |
| 同等義務 | Sub-processorに同等のデータ保護義務を課します。 |
| 本人権利対応支援 | Controllerの本人権利対応を支援します。 |
| 侵害通知 | 侵害認識後、不当な遅滞なくControllerに通知します。 |
| DPIA等支援 | DPIA、事前協議、セキュリティ評価に協力します。 |
| 削除・返却 | 契約終了時にデータを返却または削除します。 |
| 監査協力 | 必要情報を提供し、監査に協力します。 |
| 記録 | Processorとしての処理記録を保持します。 |
| 違法指示の通知 | 指示がGDPR等に違反すると考える場合に通知します。 |
ProcessorがControllerになる典型例は、Controllerの指示を超えて自らの目的で個人データを処理する場合です。次の一覧は、Processor側のサービス設計や営業資料で特に確認すべきリスク行為を示しています。
顧客データを自社広告配信、第三者販売、第三者提供に使う場合は、Processorの範囲を超える可能性があります。
顧客データを自社のAIモデル学習や他社顧客データとの結合分析に使う場合は、独自目的が問題になります。
承認されていない目的でログを長期保存し、サポート目的を超えて閲覧・抽出する場合は注意が必要です。
Controllerが許可していないSub-processorへ移転する場合、DPA違反と役割分類の問題が同時に生じます。
Processorがサーバ冗長化、脆弱性管理、パッチ適用、監視方法、バックアップ、暗号化実装、アクセスログ管理などを専門的に決めることは通常あります。これらがControllerの目的と本質的手段に従属する非本質的手段にとどまる限り、Processor性は否定されにくいと考えられます。
Processor企業の防御実務では、標準DPA、Sub-processor一覧、セキュリティ白書、監査報告書、認証証明書、データ処理仕様書、顧客データの独自利用の有無、AI学習利用の設定・オプトアウト・保持期間、侵害時の顧客通知プロセス、顧客監査の範囲・頻度・費用、削除・返却手順、顧客別例外条項の管理を整備します。
Joint Controller、独立Controller、日本法の委託先監督を混同しないように整理します。
Joint ControllerとProcessorの違いは、共同で目的・本質的手段を決めているか、それとも一方が他方の指示に従っているだけかにあります。データ共有や相互利益だけでは、直ちにJoint Controllerになるわけではありません。
次の比較表は、ControllerとProcessorの境界でよく出る4類型を示しています。契約書を選ぶ前に、判断の中心と典型例を並べて確認することで、DPA、共同管理者取決め、Controller間契約を使い分けやすくなります。
| 類型 | 判断の中心 | 典型例 | 契約上の対応 |
|---|---|---|---|
| Controller-Processor | Controllerが目的・本質的手段を決め、Processorが指示に従います。 | 給与計算代行、クラウド保存、メール配信代行です。 | DPA、Article 28条項、再委託、監査、削除・返却を定めます。 |
| Joint Controllers | 複数当事者が共同で目的・本質的手段を決めます。 | 共同キャンペーン、共同研究、共同プラットフォーム運営です。 | Joint Controller Arrangement、責任分担、本人通知を定めます。 |
| Independent Controllers | 各当事者が各自の目的で別々に処理します。 | 企業と外部専門家、売主と買主、決済事業者などです。 | Controller間契約、データ共有契約、第三者提供・移転根拠を整理します。 |
| Controllerなし | 個人データ処理がない、または相手方が個人データを取り扱いません。 | 暗号化されアクセス不能な一部クラウド利用などです。 | 情報セキュリティ契約、非個人データ整理、アクセス制御証跡を整えます。 |
Joint Controllerであっても、各当事者の責任が常に同一という意味ではありません。本人権利、情報提供、法的根拠、安全管理、侵害通知、DPIA、Processor利用、越境移転、連絡窓口、費用負担、損害賠償、終了時のデータ削除・返却を透明な方法で分担します。
日本の個人情報保護法には、GDPRと同じ意味でのController/Processor二分法はありません。日本法では、個人情報取扱事業者、個人データ、保有個人データ、第三者提供、委託、共同利用、安全管理措置、委託先の監督などの概念で整理します。GDPR型DPAを日本国内取引へそのまま持ち込むと、用語と義務範囲がずれることがあります。
日本法上、個人データの取扱いを委託する場合、委託元は委託先における安全管理措置が図られるよう必要かつ適切な監督を行います。委託契約では、業務範囲、個人データの種類、利用目的、目的外利用禁止、安全管理、秘密保持、従業者監督、再委託、漏えい等報告、取扱状況の報告、監査、契約終了時の返却・削除、違反時の是正・解除・損害賠償を定めます。
クラウド利用では、クラウド事業者が個人データを取り扱わないと評価される場合、第三者提供にも委託にも当たらないと整理され得ます。ただし、契約上・技術上、クラウド事業者が個人データを取り扱わない状態が確保されている必要があります。2024年の個人情報保護委員会の注意喚起も、実際に個人データを取り扱うと評価される場合の委託先監督の重要性を示しています。
SaaS、広告、専門家、M&A、グループ会社、AIまで、処理目的ごとに分類します。
役割分担は、業務類型ごとに典型的な傾向があります。ただし、どの類型でも、最終的にはデータ種類、目的、保存期間、独自利用、本人通知、契約条項、実際の運用を処理単位で確認します。
次の一覧は、企業法務で特に問題になりやすい10類型を整理しています。各行では、誰が目的を決めるか、どの場面で独自Controller性が出るかを読み取ることが重要です。
| 類型 | 通常の整理 | 注意点 |
|---|---|---|
| 給与計算・人事BPO | 雇用主がController、給与計算会社や人事BPOはProcessorになりやすいです。 | BPO事業者の法令遵守、請求、品質管理、紛争対応、利用ログは自社Controller性を確認します。 |
| クラウドホスティング・SaaS | 顧客が入力するエンドユーザー情報では、顧客企業がController、SaaSベンダーがProcessorになりやすいです。 | 分析、広告、AI学習、サービス横断プロファイリング、契約担当者情報は別処理として確認します。 |
| メール配信・MA | 広告主・事業会社が配信目的、対象者、内容、タイミング、セグメント条件を決める場合、Controllerになりやすいです。 | ツール提供会社が行動データを広告ネットワーク、データ商品、横断分析、AI改善に利用する場合は注意します。 |
| 広告配信・アドテク・アクセス解析 | 広告主、代理店、DSP、SSP、DMP、CMP、SNS、解析事業者の関与を分解します。 | Cookie同意管理、共同管理者取決め、業界フレームワーク、ePrivacy、各国当局見解も確認します。 |
| コールセンター・サポート | 企業が目的、範囲、FAQ、エスカレーション、保存期間を決める場合、企業がControllerになりやすいです。 | 教育、品質評価、音声分析、AI応答モデル学習、ベンチマーク利用は独自目的を確認します。 |
| 物流・配送・決済 | 配送先情報を指示通り使うだけならProcessorの余地があります。 | 運送約款、法令保存義務、事故対応、AML/CFT、不正検知、決済ネットワーク規則では独立Controller性が出ます。 |
| 外部専門家 | 弁護士、会計士、税理士、社労士、弁理士は独立Controllerとして整理されることが多いです。 | 単純な事務代行、データ入力、翻訳、資料整理だけを指示通り行う場合はProcessor性も検討します。 |
| M&A・DD | データルーム事業者はProcessorになりやすく、売主・対象会社・買主は独立ControllerまたはJoint Controllerを検討します。 | マスキング、アクセス権限、ログ監査、目的外利用禁止、破談時削除、クリーンチームが重要です。 |
| グループ会社間共有 | グループ会社は原則として別法人であり、自由な共有とは扱いません。 | 共通HR、シェアードサービス、コンプライアンス調査、共同マーケティングで整理が変わります。 |
| 生成AI・AI SaaS | 企業が入力するデータについて、AIベンダーがProcessorか、自社Controllerかを確認します。 | モデル学習、人間レビュー、保存期間、保存国、サブプロセッサー、出力データ、DPIA、営業秘密を確認します。 |
生成AI・AI SaaSでは、入力データがモデル学習に使われるか、初期設定で有効か無効か、オプトアウトが可能か、人間レビューがあるか、サポート担当者が入力内容を閲覧できるか、データ保存期間が何日か、ログがどの国に保存されるか、サブプロセッサーは誰か、出力結果を誰が管理するかを確認します。
役割分担条項、Article 28要素、再委託、侵害通知、削除・返却、監査、責任制限を整えます。
契約書またはDPAでは、当事者の役割を処理単位で定めます。抽象的に「各自、適用法上必要な範囲でControllerまたはProcessorとして行動する」と書くだけでは、サポートログ、契約担当者情報、AI学習用データなどで齟齬が残ります。
次の表は、SaaS取引を例に処理対象ごとの役割を分けたものです。処理目的ごとにControllerとProcessorを分けることで、DPA対象、独立Controller処理、個人データ該当性、顧客承認の要否を読み取れます。
| 処理対象 | 処理目的 | Controller | Processor | 備考 |
|---|---|---|---|---|
| 顧客企業がSaaSに入力するエンドユーザー情報 | SaaS提供です。 | 顧客企業です。 | SaaSベンダーです。 | DPA対象です。 |
| 顧客企業の契約担当者情報 | 契約管理・請求です。 | SaaSベンダーです。 | 該当しません。 | ベンダーが独立Controllerです。 |
| サポートログ | 障害対応です。 | 顧客企業またはSaaSベンダーです。 | 事案によります。 | ログ利用目的を確認します。 |
| 集計済み統計情報 | サービス改善です。 | 個人データ該当性を検討します。 | 個人データでなければGDPR外です。 | 匿名化の有効性が重要です。 |
| AI学習用データ | モデル改善です。 | 原則としてベンダーController性を検討します。 | 顧客承認が必要です。 | 利用目的・本人通知を確認します。 |
DPAには、Article 28に対応する要素を漏れなく入れます。次の一覧は、本文、別紙、注文書、仕様書、セキュリティ別紙に分けて管理しやすい項目です。
安全管理措置は、組織的管理、人的管理、技術的管理、物理的管理、運用管理、インシデント対応、サプライチェーン管理、監査に分けて別紙化します。抽象的に適切な措置と書くだけでは、顧客監査や事故時の説明が難しくなります。
Sub-processor条項では、一般承認か個別承認か、既存一覧、変更通知、異議申立期間、代替措置・解除権、同等義務、所在地・移転国、セキュリティ評価、事故時報告、一覧の更新頻度を定めます。多数顧客を持つSaaSでは、Web掲載、メール通知、管理画面通知、異議申立期間を組み合わせることがあります。
侵害通知条項では、通知義務の発生時点、初報期限、続報期限、通知先、初報に含める最低情報、フォレンジック調査、当局・本人・顧客・メディアへの通知分担、FAQやコールセンター対応、費用負担、再発防止、秘密保持、証拠保全を定めます。
削除・返却条項では、返却形式、返却期限、削除期限、バックアップ削除、削除証明書、法令保存例外、係争・監査・請求対応の保存、匿名化・集計化データ、移行支援費用を定めます。監査条項では、第三者監査報告書、追加説明、リモート監査、現地監査の順に階層化すると運用しやすくなります。
責任制限・補償では、個人データ侵害による損害、制裁金、調査費用、通知費用、信用回復費用、間接損害、故意・重過失、守秘義務違反、セキュリティ義務違反、Sub-processor事故、違法指示が原因の場合の免責・補償を分けて検討します。ただし、契約上の責任制限により、監督当局や本人に対する義務が当然に消えるわけではありません。
契約前確認、台帳管理、継続モニタリング、シャドーIT対策まで運用へ落とします。
Controllerは、Processor候補を利用する前に、法務、プライバシー、セキュリティ、IT、購買、事業部、内部監査の観点から確認します。役割分類は契約だけでなく、導入審査と継続管理の一部として扱います。
次の表は、契約前デューデリジェンスで部門横断的に見るべき領域を整理しています。法務だけでなく、ITやセキュリティ、購買、事業部の情報を合わせることで、DPAと実運用のずれを見つけやすくなります。
| 確認領域 | 確認事項 |
|---|---|
| 法務 | DPA、SCC、Sub-processor、責任制限、準拠法、監査権を確認します。 |
| プライバシー | 役割分類、利用目的、本人通知、データ保持、権利対応を確認します。 |
| セキュリティ | 認証、暗号化、アクセス制御、ログ、脆弱性管理、BCPを確認します。 |
| IT | アーキテクチャ、データ保存国、API、削除仕様、移行性を確認します。 |
| 購買 | 価格、SLA、契約期間、解除、変更通知を確認します。 |
| 事業部 | 業務目的、必要データ、運用手順、代替手段を確認します。 |
| 内部監査 | 監査証跡、統制設計、リスク評価を確認します。 |
Processor/委託先は台帳化します。ベンダー名、サービス名、業務オーナー、契約管理部門、処理目的、データカテゴリー、本人カテゴリー、センシティブデータの有無、役割分類、DPA締結日、SCC締結日、保存国・アクセス国、Sub-processor一覧、セキュリティ評価日、次回評価日、インシデント履歴、契約終了時削除確認を管理します。
ベンダー管理は契約締結時で終わりません。サービス仕様、Sub-processor、データ保存国、AI学習利用、セキュリティ認証、インシデント履歴、利用規約は変化します。年次レビュー、Sub-processor変更通知、規約・DPA改定、重要ベンダーの事故情報、アクセス権限棚卸、削除テスト、監査報告書更新、高リスクベンダーの経営・財務・セキュリティ状況を確認します。
SaaSやAIツールは事業部門が直接導入できるため、シャドーIT化しやすい領域です。SaaS導入申請、個人データ利用チェックシート、AIツール利用申請、ベンダーリスク区分、高リスクサービスの法務・セキュリティ必須審査、契約締結権限管理、社内研修、定期的な利用棚卸を設けます。
Processor利用、SCC、TIA、AIの学習利用は別々に確認します。
Processorを利用することと、越境移転が適法であることは別問題です。EU個人データをEU域外へ移転する場合、十分性認定、SCC、BCR、例外事由などの移転根拠が必要になります。Controller/Processor分類に加え、移転国、アクセス国、Sub-processor、リモートアクセス、保守対応を確認します。
次の比較は、Article 28対応のSCCと国際移転SCCの違いを示しています。どちらもSCCと呼ばれるため混同しやすく、DPA本文、移転条項、UK Addendum、Swiss Addendum、Sub-processorリスト、TIAを一体で確認することが重要です。
| 項目 | Article 28対応のSCC | 国際移転SCC |
|---|---|---|
| 目的 | ControllerとProcessor間の処理契約として機能します。 | 第三国移転の適法化のために用いられます。 |
| 対象 | GDPR Article 28のDPA条項を満たすためのものです。 | ControllerからController、ControllerからProcessor、ProcessorからProcessor、ProcessorからControllerなどに対応します。 |
| 実務での使い方 | DPA本文や別紙に組み込みます。 | DPAに加えて、移転モジュール、TIA、補完的措置と合わせて使います。 |
TIAでは、移転先国の法制度、公的機関アクセス、裁判上救済、暗号化、鍵管理、アクセス制御、データ最小化、仮名化、契約上の通知義務などを評価します。クラウド事業者やSub-processorが所在する国、サポートアクセス国、法執行アクセスリスクを確認します。
AI SaaSは、入力データが複数国のサーバ、Sub-processor、モデル評価チーム、ログ分析基盤を経由することがあります。入力データの保存国、推論処理の実行国、ログ保存国、サポートアクセス国、Sub-processorの国、モデル学習利用、学習データからの削除可否、出力データの権利・責任、高リスクAI規制、DPIAの必要性を確認します。
法令違反、契約不履行、評判、訴訟・求償、M&A・資金調達に波及します。
役割分担の誤りは、DPA未締結だけでなく、本人通知、越境移転、Sub-processor、侵害通知、顧客監査、M&A・IPOのDDまで波及します。次のリスク一覧では、どの領域で実害が出るかを確認できます。
DPA未締結、法的根拠不備、本人通知不備、越境移転不備、Sub-processor未承認、侵害通知遅延が生じます。GDPRではArticle 28、30、32、33などの違反が行政制裁金の対象になり得ます。
顧客とのDPAに違反すれば、契約解除、損害賠償、補償、監査、是正要求、取引停止につながります。大企業、金融、医療、公共、海外企業との取引では重大な契約違反と扱われることがあります。
個人データ事故は、顧客信頼、採用、投資家評価、上場審査、M&A価値、ブランド価値に影響します。委託先事故でも、自社の管理責任を問われやすくなります。
複数関与者間で損害賠償責任や求償が問題になります。日本法でも、漏えい、目的外利用、違法提供、委託先管理不備により損害賠償や役員責任が問題になり得ます。
DPA締結状況、委託先管理、越境移転、Cookie・広告規制、AI学習利用、漏えい履歴がDD項目になります。整理不足は表明保証、補償、価格調整、是正義務に影響します。
特にクラウド事故や委託先事故では、自社の事故ではないと説明しても、顧客からは管理責任を問われることが多くあります。委託先管理の証跡、DPA、通知手順、Sub-processor管理、監査記録を平時から残しておくことが重要です。
6つの判断ステップと社内責任分担表で、契約・運用・監査に反映します。
実務では、抽象論を判断手順と社内責任分担に落とすことが重要です。次の判断手順は、処理単位の特定から、目的、本質的手段、指示処理、共同決定、独立Controller性の確認までを順番に示しています。
どのデータか、誰のデータか、どのシステムで、どの目的で、どの期間、どの国・ベンダー・Sub-processorが関与するかを整理します。
なぜ処理するか、処理しない選択ができるか、本人に説明する利用目的を決めるのは誰か、成果を自社目的で使うのは誰かを見ます。
データ項目、本人カテゴリー、開示先、保存期間、プロファイリング・AI学習、本人権利対応の設計を見ます。
文書化された指示、独自利用の不存在、Sub-processor承認、削除・返却、指示違反時の責任を確認します。
共同キャンペーン、共同データベース、共同分析目的、不可分な役割、本人から見た透明性を確認します。
法令上・職業上の独自義務、自社判断での保存・開示・利用、自社プライバシーポリシー、当局・本人対応を確認します。
社内では、ControllerとProcessorの役割分担を相手方との契約だけでなく、責任者と協議先にも落とし込みます。次の表では、Rは実行責任、Aは最終責任、Cは協議先、Iは報告先を示します。
| 業務 | 事業部門 | 法務 | プライバシー担当 | 情報セキュリティ | IT | 購買 | 内部監査 | 経営 |
|---|---|---|---|---|---|---|---|---|
| 処理目的の特定 | R | C | C | C | C | I | I | A |
| Controller/Processor分類 | C | R | R | C | C | I | I | A |
| 法的根拠分析 | C | R | R | I | I | I | I | A |
| プライバシー通知 | C | R | R | I | I | I | I | A |
| ベンダー選定 | R | C | C | C | C | R | I | A |
| セキュリティ評価 | C | I | C | R | R | I | I | A |
| DPA交渉 | C | R | R | C | C | C | I | A |
| SCC・越境移転評価 | C | R | R | C | C | I | I | A |
| DPIA | R | C | R | C | C | I | I | A |
| Sub-processor確認 | C | R | R | C | C | C | I | A |
| 本人権利対応 | C | R | R | C | C | I | I | A |
| 侵害対応 | R | R | R | R | R | I | C | A |
| 委託先監査 | C | C | R | R | C | C | R | A |
| 契約終了時削除確認 | R | C | R | C | R | C | I | A |
法務だけで完結させないことが重要です。役割分類は法的判断であると同時に、ITアーキテクチャ、セキュリティ、購買、事業運用、内部監査、経営判断の問題でもあります。
一般的な制度説明として、個別案件では結論が変わる点を前提に整理します。
一般的には、契約書上の記載だけでProcessorになるものではないとされています。実際の処理で相手方が独自の目的や本質的手段を決めていれば、その範囲でControllerまたはJoint Controllerと評価され得ます。ただし、契約書上の記載は重要な証拠になります。具体的な分類は、処理内容、契約、サービス仕様、運用を踏まえて弁護士等の専門家へ相談する必要があります。
一般的には、サーバ構成、バックアップ、暗号化、ログ管理、パッチ適用などの非本質的手段をProcessorが専門的に選択しても、それだけでControllerになるとは限らないとされています。ただし、保存期間、第三者開示、独自再利用、AI学習、プロファイリングなどを決める場合は結論が変わる可能性があります。
一般的には、常にProcessorと整理できるものではありません。顧客企業が入力する顧客・従業員データを顧客の指示に従って処理する範囲ではProcessorになりやすい一方、契約担当者情報、請求情報、不正利用防止ログ、マーケティング情報、サービス改善用データを自社目的で処理する場合は、ベンダーがControllerになり得ます。
一般的には、外部専門家は独立Controllerとして整理されることが多いとされています。職業上の独立性、守秘義務、記録保存、利益相反確認、法令遵守、専門的判断を行うためです。ただし、単純な事務代行、データ入力、翻訳、資料整理など、依頼者の指示に従うだけの処理ではProcessor性が問題になり得ます。
一般的には、同じ概念ではないとされています。日本法の委託は、第三者提供規制の例外、委託先監督、安全管理措置の文脈で機能します。GDPRのProcessorは、Controllerの指示に基づき処理する者としてArticle 28等に基づく直接義務を負います。重なる部分はありますが、同一概念として扱うことは避ける必要があります。
一般的には、日本法上、クラウド事業者が個人データを取り扱わないと評価される場合、第三者提供にも委託にも当たらないと整理され得ます。ただし、そのためには契約上・技術上、クラウド事業者が個人データを取り扱わない状態が確保されている必要があります。保守アクセス、管理者ID、障害対応、ログ閲覧、暗号鍵管理などで結論が変わる可能性があります。
一般的には、Controllerがすべての技術仕様を自ら設計する必要はないとされています。Controllerは適切なProcessorを選定し、DPAで安全管理措置を定め、監督します。専門的な技術実装はProcessorに委ねられることがあります。ただし、セキュリティ水準、リスク、データ類型、監査、侵害通知、再委託管理について説明できる状態が必要です。
一般的には、GDPR上、ProcessorはControllerの事前の個別承認または一般的承認なくSub-processorを利用できないとされています。一般承認の場合でも、Sub-processorの変更についてControllerに通知し、異議を述べる機会を与える必要があります。契約構造やデータ類型によって必要な手続は変わります。
一般的には、Joint Controllerの場合はArticle 28型DPAだけでは足りないとされています。Joint Controller Arrangementを作成し、各当事者の責任、本人通知、権利対応、侵害対応、法的根拠、安全管理、Processor利用、越境移転などを定める必要があります。
一般的には、システム導入、キャンペーン設計、ベンダー選定、M&A DD、AI利用開始、データ共有開始の前に整理することが望ましいとされています。契約締結直前では、サービス仕様、本人通知、同意設計、越境移転、Sub-processor、安全管理措置を修正しにくいことがあります。
初期確認、Controller側、Processor側、日本法対応を漏れなく確認します。
最後に、社内で使えるチェック項目として、初期確認、Controller側、Processor側、日本法対応を分けて整理します。どの項目も、契約書、台帳、審査資料、証跡に反映することが重要です。
次の一覧は、実務で抜けやすい確認事項を4分類にまとめたものです。左から順に、導入前の分類、Controller側の義務、Processor側の防御、日本法対応を確認してください。
処理単位、個人データの種類、本人カテゴリー、処理目的、本質的手段の決定者、相手方の独自利用、AI学習・広告利用、プライバシーポリシーとDPAの矛盾を確認します。
法的根拠、プライバシー通知、DPIA、Processor選定証跡、DPA、SCC・越境移転、Sub-processor、侵害通知SLA、削除・返却、監査方法を確認します。
指示範囲、顧客データの独自利用、AI学習時の法的根拠と契約承認、Sub-processor管理、セキュリティ措置、侵害時通知、削除・返却、監査対応資料、顧客別例外条項を確認します。
個人情報・個人データ・保有個人データの区分、委託該当性、委託先監督、委託契約、安全管理、再委託、共同利用、第三者提供、クラウド取扱い、漏えい等報告を確認します。
ControllerとProcessorの役割分担は、個人データ保護実務の根幹です。Controllerは処理の目的と本質的手段を決め、適法性、透明性、安全管理、本人権利、Processor選定、DPA、越境移転、侵害通知について中心的な責任を負います。ProcessorはControllerの指示に従って処理する一方、指示処理、秘密保持、安全管理、再委託管理、侵害通知、削除・返却、監査協力などについて直接義務を負います。
判断の要点は、法人単位ではなく処理単位で見ること、契約上のラベルではなく目的・本質的手段の決定者を見ること、非本質的な技術的手段の選択だけで直ちにControllerとしないこと、相互利益やデータ共有だけでJoint Controllerとしないこと、日本法の委託先管理とGDPRのProcessor規制を同一視しないことです。
正確な役割分担は、GDPR対応だけでなく、説明責任、取引先からの信頼、事故時の初動力、グローバル事業の継続性、経営リスク管理を支える基礎になります。