GDPRの国際データ移転で使うSCCを、契約にどう組み込み、どのAnnexをどう記入し、どの証跡を残すべきかを企業法務・個人情報保護実務向けに整理します。
URL参照ではなく、選択済み・記入済み・拘束力ある別紙として管理します。
URL参照ではなく、選択済み・記入済み・拘束力ある別紙として管理します。
SCC（Standard Contractual Clauses、標準契約条項）は、主としてGDPR上、EEAからEEA外へ個人データを移転する際に用いられる、欧州委員会があらかじめ承認した契約条項です。契約書に何となくリンクを貼るだけでは足りず、対象移転、モジュール、Annex、署名、優先関係、TIAまで一体で設計する必要があります。
最も安全な添付方法は、SCC本文そのものを、選択済み・記入済み・署名可能な状態で、DPA又はデータ移転契約の別紙・別添・Schedule・Exhibitとして添付し、SCCと他の契約条項の優先関係を明示し、Annexを空欄にしないことです。
次の重要ポイントは、SCC（標準契約条項）の添付方法で最初に押さえるべき結論をまとめたものです。単なる添付の有無ではなく、当事者を拘束し、データ主体や監督機関に説明できる状態になっているかを読み取ってください。
本文でSCCが適用されることを明記し、選択済みモジュールと記入済みAnnexを別紙として保存し、矛盾時にはSCCが優先することを示す構成が実務上安全です。
次の3つの要素は、SCCの添付が実効的といえるための基本条件です。左から、契約本文での法的な接続、別紙としての実体、運用証跡の順に並んでおり、3つがそろっているかを確認してください。
DPA又はデータ移転契約に、どの対象移転へSCCが適用されるかを明記します。
不要なモジュールや選択肢を削除し、Annex I、II、必要に応じてIIIを記入します。
Annex I.A、電子署名ログ、TIA、復処理者変更、見直し期限を契約管理で追跡します。
国際データ移転用SCCと管理者・処理者間SCCを区別します。
SCCとは、Standard Contractual Clauses の略称であり、日本語では標準契約条項と訳されます。GDPRの文脈では、EEAからEEA外の第三国又は国際機関へ個人データを移転する場合に、適切な保護措置を提供するための契約上の仕組みとして利用されます。
GDPR第44条は、第三国又は国際機関への個人データ移転について、GDPR第5章の条件を満たす必要があるという一般原則を定めています。十分性認定がある国・地域への移転はGDPR第45条に基づく移転が可能ですが、十分性認定がない場合、GDPR第46条に基づく適切な保護措置が問題になり、SCCが代表的手段になります。
次の比較表は、2021年に採択された標準契約条項のうち、実務で混同しやすい2種類を分けたものです。どちらの条項を使うかを誤ると、契約目的と法的根拠がずれるため、対象移転がEEA外移転か、処理委託関係の整理かを読み取ってください。
| 種類 | 主な目的 | 添付方法での注意点 |
|---|---|---|
| 管理者・処理者間SCC | GDPR第28条3項・4項の処理委託要件を満たすための標準契約条項です。 | EEA内の管理者・処理者関係を整理する文脈で使われます。 |
| 国際データ移転用SCC | EEA外への個人データ移転で、GDPR第46条上の適切な保護措置として使います。 | このページで主に扱う対象です。Module 2・3には第28条要件も組み込まれています。 |
日本企業がSCCを検討する場合、GDPR上のSCCと日本の個人情報保護法上の外国第三者提供規制は分けて考える必要があります。EU SCCを締結したからといって、日本法上の越境移転規制が自動的に充足されるわけではありません。
十分性認定、日本法、英国データ、移転スキームを先に分けます。
SCCを添付する前に、そもそもGDPR第5章上の第三国又は国際機関への個人データ移転に当たるかを確認します。典型例は、EEA内の企業が、米国、インド、シンガポール、日本などのクラウドベンダー、SaaS事業者、BPO事業者、グループ会社、外部コンサルタントへ個人データを送信又はアクセス可能にする場面です。
次の判断の流れは、SCCを添付する前に、移転根拠と追加書類をどこまで確認するかを示しています。上から順に確認し、十分性認定、英国データ、日本法レイヤー、オンワード移転の有無を分けて読み取ってください。
クラウド保存、海外サポート閲覧、API連携、バックアップ、ログ解析も確認します。
移転先国、受領者の属性、対象データの範囲を確認します。
Module、Annex、優先関係、TIA、補完的措置を設計します。
日本の補完的ルール、英国Addendum、再移転、日本法上の外国第三者提供規制を確認します。
英国データについては、EU SCCだけでは足りないことがあります。英国ICOは、UK GDPR上の制限移転について、IDTA又はEU SCCに対するUK Addendumを利用できると説明しています。EEAデータと英国データが同じ取引で移転される場合は、EU SCC、UK Addendum、DPA、MSAの優先順位を整理します。
DPA別紙、Data Transfer Addendum、グループ内契約を使い分けます。
SCCは、独立したデータ移転契約として締結することも、DPAの別紙として添付することも、MSAや業務委託契約のScheduleとして組み込むこともできます。既存契約が多い場合は、Data Transfer Addendumを差し込む方式が実務上有効です。
次の比較表は、代表的な添付パターンを、向いている場面と注意点に分けて整理したものです。契約数、既存契約の有無、グループ会社の多さ、SCC更新のしやすさを比較して、自社に合う方式を読み取ってください。
| パターン | 向いている場面 | 注意点 |
|---|---|---|
| 独立したデータ移転契約 | 既存契約に個人データ条項が乏しい場合や、グループ会社間移転を横断管理したい場合です。 | 商取引上の責任、対価、SLA、知財、解除は別契約との整合性を確認します。 |
| DPAの別紙 | SaaS、クラウド、BPO、人事・給与、CRM、広告、分析ツールなどで最も一般的です。 | DPA本文の責任制限、監査制限、復処理者条項がSCCと矛盾しないようにします。 |
| MSA又は業務委託契約のSchedule | DPAを別途作らない中小規模・単発取引で使いやすい方式です。 | 商業条項とSCCの優先順位を明確にし、Annexを空欄にしないことが必要です。 |
| Data Transfer Addendum | 既存ベンダーとのSCC更新や旧SCCから2021年SCCへの移行に向いています。 | 改定対象契約、適用開始日、既存条項との矛盾範囲を明確にします。 |
| グループ内データ移転契約 | 多国籍グループで参加会社や拠点が増える場合に向いています。 | docking clause、参加手続、Annex I.A、データ移転マトリクスを更新します。 |
次の一覧は、DPA別紙方式を採る場合の文書構成を示しています。上から本契約、DPA、各Scheduleへ具体化していく順番に意味があり、SCC本文とAnnexの位置を契約管理上すぐ確認できることが重要です。
商業条件、サービス、責任、解除、準拠法などを定めます。
本契約処理指示、セキュリティ、復処理者、監査、返還・削除、国際移転を定めます。
DPA処理詳細とセキュリティ措置を記載し、Annex I.B・Annex IIと整合させます。
処理詳細EU SCC本文、Annex I.A、I.B、I.C、Annex II、必要に応じてAnnex IIIを置きます。
SCC本体英国データがある場合、UK Addendum又はIDTAを追加します。
英国対応データ棚卸しからTIA保存まで、抜けやすい順番をつぶします。
SCC（標準契約条項）の添付は、契約書編集から始めるのではなく、データフローの棚卸しから始めます。データ輸出者、データ輸入者、管理者・処理者・復処理者の役割、データ主体、個人データの種類、移転頻度、保存期間、復処理者、移転先国を一覧化します。
次の時系列は、SCCを有効に添付するための12ステップを、作業順に並べたものです。前半は対象移転とモジュール選択、中盤はAnnex記入、後半は優先関係とTIAの証跡管理を示しています。
輸出者、輸入者、役割、データ主体、個人データ、移転頻度、保存期間、復処理者、移転先国を一覧化します。
第28条対応か、第46条対応かを分け、Module 1から4のうち移転類型に合うものを選びます。
不要なモジュールや選択肢は削除しますが、SCCの中核文言は書き換えません。
当事者、署名、移転内容、監督機関、安全管理措置、復処理者を空欄にしません。
SCCが矛盾時に優先することを示し、移転先国法制・補完的措置・残余リスクを記録します。
次の表は、2021年SCCのModule 1から4を整理したものです。データ輸出者とデータ輸入者の役割に応じて、どの移転にどのモジュールが適用されるかをAnnex I.Bで区別して読み取れる状態にすることが重要です。
| モジュール | 移転類型 | 典型例 |
|---|---|---|
| Module 1 | Controller to Controller | EEA企業がEEA外の独立した取引先へ顧客データを提供し、双方が独自目的で処理する場合です。 |
| Module 2 | Controller to Processor | EEA企業がEEA外のSaaS、クラウド、BPO、給与計算、分析ベンダーへ処理を委託する場合です。 |
| Module 3 | Processor to Processor | EEA内処理者が、EEA外の復処理者へ処理を再委託する場合です。 |
| Module 4 | Processor to Controller | EEA内処理者が、EEA外の管理者へデータを戻す、又は管理者のために収集したデータを送る場合です。 |
Annex I.A、I.B、I.C、II、IIIの記入内容を具体化します。
Annexは、SCCの実務上の中核です。SCC本文が正しく添付されていても、Annex Iに当事者や移転内容がなく、Annex IIに抽象的な安全管理措置しかない場合、どの移転をどの措置で保護しているのか説明しにくくなります。
次の一覧は、各Annexに何を書くべきかを整理したものです。番号が進むほど、当事者情報からデータ移転の具体化、安全管理措置、復処理者管理へ深く入るため、どのAnnexが空欄になっているかを読み取ってください。
データ輸出者・輸入者の名称、住所、連絡先、DPO又はEU代理人、活動、署名、日付、役割を記載します。
データ主体、個人データのカテゴリー、特別カテゴリー、移転頻度、処理の性質、目的、保存期間を記載します。
管轄監督機関を記載します。EEA内輸出者か、GDPR第3条2項の域外適用かで検討が変わります。
暗号化、アクセス制御、ログ、バックアップ、インシデント対応など、実装済みの技術的・組織的措置を具体化します。
Module 2又は3で個別承認を採る場合、復処理者の名称、処理内容、所在国、再移転根拠を記載します。
次の比較表は、Annex IIの記載で避けるべき抽象表現と、より具体的な記載の方向性を比べたものです。左列は説明責任を果たしにくい表現、右列は移転対象データに対して何を実装しているかを読み取れる表現です。
| 避けるべき記載 | 望ましい具体化 |
|---|---|
| 業界標準に従った適切な安全管理措置を講じます。 | TLS 1.2以上による通信時暗号化、AES-256相当の保存時暗号化、多要素認証、管理者アクセスログの定期確認を記載します。 |
| 必要なアクセス制限を行います。 | 本番環境へのアクセスを承認済み担当者に限定し、need-to-know basis と職務分掌を記載します。 |
| バックアップを適切に管理します。 | 暗号化バックアップ、最大保存日数、災害復旧テスト、削除手順を記載します。 |
| インシデント時に通知します。 | 移転データに影響する個人データ侵害を認識後、不当な遅滞なく通知する手順を記載します。 |
日本語で管理する場合でも、契約上の正文が英語であれば、英語のAnnex IIを正式版とし、日本語訳は参考訳として添付するのが安全です。翻訳だけを添付し、欧州委員会の原文に基づくSCCが存在しない状態は避ける必要があります。
URLだけ、空欄、全モジュール残し、本文改変、TIAなしを避けます。
SCC（標準契約条項）の添付では、見た目だけ整っていても、移転根拠として説明しにくい状態があります。特に、欧州委員会のURLだけを貼る、空欄のSCCを添付する、全モジュールを残す、SCC本文を自社標準に合わせて変更する、といった対応は避ける必要があります。
次の一覧は、避けるべき添付方法を、なぜ問題になるかとあわせて整理したものです。各項目では、形式上の添付ではなく、当事者・データ主体・監督機関に説明できる実体があるかを読み取ってください。
どのモジュール、選択肢、Annexが適用されるか分からず、データ主体へのコピー提供にも不十分となり得ます。
Annex I、II、IIIが空欄では、対象移転や安全管理措置が特定されません。
DPAやMSAの責任制限が、SCCに基づく責任やデータ主体の権利を弱めないよう注意します。
適用条項が曖昧になります。該当しないモジュールや選択肢は削除し、適用モジュールを明確にします。
SCC本文を変更すると、GDPR第46条上の移転根拠として使えなくなるおそれがあります。
SCCは必要条件になり得ますが、移転先国法制や政府アクセスリスクの検討が別途必要です。
次の重要ポイントは、SCCと本契約の優先関係を整える理由を示しています。優先関係条項を置くことで、責任制限、監査、政府アクセス、復処理者、解除、準拠法、裁判管轄、データ主体の権利に関する矛盾を発見しやすくなります。
法務、プライバシー、IT、調達、監査、経営が分担します。
SCCの添付は、法務担当だけで完結しません。Annex I.Bにはデータ主体や個人データのカテゴリーが必要であり、Annex IIには実装済みの技術的・組織的措置が必要です。復処理者やベンダーDPAの管理には調達・ベンダー管理担当も関わります。
次の表は、SCC添付に関わる主な役割と責任を整理したものです。左列の役割ごとに、どの情報を出し、どの判断を支えるかを読み取ることで、Annexを法務だけで埋めてしまうリスクを下げられます。
| 役割 | 主な責任 |
|---|---|
| 法務担当・企業内弁護士 | 契約構成、SCCモジュール選択、DPA整合性、責任制限、準拠法、管轄の確認を担います。 |
| 外部専門家 | EU法、英国法、移転先国法、監督機関実務、難易度の高いTIA支援を担います。 |
| 個人情報保護・プライバシー担当 | データマッピング、データ主体対応、プライバシー通知、社内記録を担います。 |
| IT・セキュリティ担当 | Annex IIの暗号化、アクセス制御、ログ、脆弱性管理、インシデント対応を具体化します。 |
| 調達・ベンダー管理担当 | ベンダーDPA、復処理者リスト、契約更新、監査証跡を管理します。 |
| 内部監査・経営層 | SCC締結状況、台帳整備、更新漏れ、高リスク移転の承認、残余リスク受容を確認します。 |
次の一覧は、SCC締結後に契約管理システムで持つべき情報を整理したものです。締結しただけで終わらず、バージョン、適用モジュール、移転先、復処理者、見直し期限を検索できる状態にすることが重要です。
2021年版SCC、締結日、改定日、適用開始日、旧SCCからの移行状況を保存します。
移転先国、データ輸入者、復処理者、クラウドリージョン、再移転根拠を記録します。
署名済みPDF、電子署名ログ、Annex、TIA、顧客監査への提出履歴を保存します。
復処理者変更、データ種類変更、法令変更、セキュリティ変更、見直し期限を追跡します。
一般情報として、移転スキームや準拠法で結論が変わる点を整理します。
一般的には、SCCを広い商取引契約に組み込むことは可能であり、常に紙で全文を綴じ込む必要があるわけではありません。ただし実務上は、選択済み・記入済み・署名済みのSCCを、契約のSchedule又はExhibitとして保存し、当事者、データ主体、監督機関が内容を確認できる状態にしておくべきとされています。単なるURL参照だけでは不十分となる可能性があります。
一般的には、推奨されません。欧州委員会が採択したSCCの正文はEUの公用語版であり、日本語は通常、便宜訳にとどまります。日本語訳を付けること自体は有用ですが、英語等の正文と併せて添付し、矛盾時には正文が優先する旨を明記することが考えられます。
一般的には、DPAとSCCは目的が異なります。DPAは主として管理者・処理者間の処理委託関係を規律する契約であり、SCCはEEA外移転の適切な保護措置として使われます。Module 2又はModule 3の国際データ移転用SCCにはGDPR第28条要件が組み込まれているため、別途DPAが不要になる場合もありますが、商業実務上はDPA本文で補足すべき事項が多いとされています。具体的には、対象データと契約体系を踏まえて専門家へ相談する必要があります。
そうとは限りません。EUから日本への一定の移転は十分性認定によりSCCなしで可能となることがありますが、十分性認定の範囲、補完的ルール、移転元・移転先の属性、オンワード移転、英国データ、米国等の第三国への再移転、GDPR第3条2項の適用などによって判断が変わります。個別の移転設計は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、DPA又はSCCの復処理者条項に従い、事前通知、異議申立期間、復処理者契約、再移転根拠、Annex又は復処理者リストの更新を行う必要があります。Module 2又は3で個別承認を採っている場合、Annex IIIの更新・承認が必要となる可能性があります。
欧州委員会Q&Aでは、2021年9月27日以降に締結される新規移転契約は新SCCに基づく必要があり、旧SCCに基づく既存契約の移行期間は2022年12月27日までと説明されています。その後は旧SCCに依拠できないとされるため、旧SCCが残っている契約は現在の移転根拠を確認する必要があります。