クラウド型ソフトウェア（SaaS）を 提供する側 も 使う側 も、ドイツ・EUで事業を行う以上、GDPR（EU一般データ保護規則） への対応は避けて通れません。SaaSは顧客の個人データを国境を越えて預かる仕組みであるため、GDPRの論点が凝縮されているからです。
本記事では、日本企業のドイツ・EU展開で必須となる 「SaaSのGDPR実務」 を、基本から実務の進め方まで整理します。GDPR全体像はGDPR対応完全ガイドも併せてご覧ください。
まず押さえる：管理者（Controller）と処理者（Processor）
GDPR実務の出発点は 役割の確定 です。
- 管理者（Controller／Verantwortlicher）：データ処理の目的と手段を決める者。通常はSaaSを利用する顧客企業。
- 処理者（Processor／Auftragsverarbeiter）：管理者の指示でデータを処理する者。通常はSaaS提供事業者。
SaaS提供者は多くの場合 処理者 に当たり、GDPR第28条に基づく データ処理契約（DPA／独語ではAVV） の締結義務が生じます。この役割を曖昧にしたまま運用すると、契約・責任の所在が不明確になり、顧客の調達審査（セキュリティチェック）で必ず問題になります。
SaaS GDPR実務の進め方（7ステップ）
ステップ1：役割の確定と処理活動の記録（第30条）
自社が管理者か処理者かを明確にし、処理活動の記録（Verzeichnis von Verarbeitungstätigkeiten） を作成します。どのデータを、何の目的で、どこに保存し、誰に渡すかを文書化します。
ステップ2：データ処理契約（DPA／AVV）の締結（第28条）
SaaS提供者と顧客の間で、第28条が求める 9つの必須要素（処理の対象・期間・目的、管理者の指示、秘密保持、安全管理、サブプロセッサー、データ主体の権利支援、削除・返却、監査協力など）を含むDPAを締結します。サブプロセッサー（再委託先） を使う場合は、第28条4項により、管理者の 事前の書面による承認（個別または一般）と、変更時の通知、同等義務の流し込みが必要です。処理者は再委託先の不履行についても管理者に責任を負います。
ステップ3：法的根拠と同意の設計（第6条）
個人データの処理には適法な根拠（同意、契約履行、正当な利益など）が必要です。SaaSのUI・利用規約・Cookie同意の設計に落とし込みます。
ステップ4：越境データ移転の手当て
ここは日本企業に朗報があります。EUと日本は2019年1月23日に相互の十分性認定を発効 させており（2023年4月の第1回見直しでも適切性が継続確認、以降は4年周期へ。詳細は個人情報保護委員会：日EU間のデータ越境移転）、EUから日本への個人データ移転は、原則として標準契約条項（SCC）なしで可能 です（認定の対象範囲内）。一方、米国のサブプロセッサー を使う場合はEU-US データプライバシーフレームワーク（DPF）認証または 標準契約条項（SCC、2021年版） が必要で、Schrems II判決を踏まえた 移転影響評価（TIA） も検討します。
ステップ5：技術的・組織的措置（TOMs／第32条）
暗号化、アクセス制御、ログ管理、バックアップ、権限分離など、リスクに見合った安全管理措置を実装し、文書化します。
ステップ6：データ主体の権利対応
アクセス、訂正、削除（忘れられる権利）、データポータビリティなどの請求に、SaaSの機能として応えられる設計にします。
ステップ7：インシデント対応（第33条・第34条）
個人データ侵害が起きた場合、原則72時間以内に監督官庁へ通知、高リスクなら本人にも通知します。検知・連絡・記録のプロセスを事前に整えます。
ドイツ特有の論点
GDPRはEU共通ですが、ドイツには上乗せルールがあります。
データ保護責任者（DPO）の選任：BDSGの20名基準
ドイツ連邦データ保護法（BDSG）第38条により、個人データの自動処理に常時20名以上が従事 する場合、データ保護責任者（DPO）の選任が義務づけられます。これはGDPRの原則より 低い（厳しい）基準 です。20名未満でも、DPIA（データ保護影響評価）が必要な処理などでは選任義務が生じます。
管轄監督官庁は「州別」
ドイツの監督官庁は 連邦のBfDIに加え、16州それぞれのLandesdatenschutzbehörde（州データ保護監督機関） で構成され、合計18機関が存在します。自社が拠点を置く州の監督機関 が原則の窓口になるため、「ドイツ国内（州別）」でどの当局が管轄するかを把握しておく必要があります。
顧客の調達審査で聞かれる定番項目
ドイツ・EUの企業にSaaSを販売する場合、契約前のセキュリティ・データ保護審査（ベンダーアセスメント）が事実上の関門になります。頻出の確認項目は決まっています。データの保存場所（EU域内かどうか）、サブプロセッサーの一覧と変更通知の仕組み、DPAのひな型（自社標準を持っているか）、暗号化・アクセス制御・ログの方針、インシデント時の通知プロセス、認証（ISO 27001等）の有無、そしてデータ主体の権利行使への対応手順です。これらを英語・ドイツ語の標準回答集として整備しておくと、商談のたびに数週間かかっていた審査が大幅に短縮されます。逆にこの準備がないベンダーは、「GDPR対応が弱い」と判断され、機能や価格の土俵に乗る前に脱落します。実際の商談では、審査担当（情報セキュリティ部門・DPO）と意思決定者（事業部門）が別であることが多く、審査担当を早く通過させる資料の整備が、そのまま受注リードタイムの短縮につながります。標準回答集は一度作れば全商談で再利用でき、投資対効果の高い営業資産です。
よくある質問（FAQ）
Q. 十分性認定があれば、日本のSaaS事業者は何もしなくてよいのですか。 A. いいえ。十分性認定が解決するのは「越境移転の合法化」だけで、GDPR本体の義務（DPA締結、安全管理措置、権利対応等）はすべて残ります。また日本側で受領したデータには、個人情報保護法に加えて補完的ルールの遵守が求められます。
Q. DPAは顧客のひな型と自社のひな型、どちらを使うべきですか。 A. 交渉力次第ですが、自社標準を持っていること自体が交渉の出発点になります。サブプロセッサー条項・監査条項・責任制限は、顧客ひな型のままだと過大な義務を負いがちな箇所で、法務レビューに値します。解釈に迷う論点はEDPB（欧州データ保護会議）の公表ガイドラインが一次的な拠り所になります。
Q. 中小規模でもDPO（データ保護責任者）の選任は必要ですか。 A. ドイツにはBDSGの20名基準があるため、EU他国より義務が生じやすいのが特徴です。外部DPOサービスの利用も認められており、社内に適任者がいない場合の現実解になっています。
Q. GDPR対応はどこまでやれば「十分」ですか。 A. 完全な網羅より、「役割の確定 → DPA → 越境移転 → 安全管理措置 → 権利対応」という骨格を文書で示せる状態が実務上の合格ラインです。審査で落ちる企業の多くは、対応が不足しているのではなく、「対応を説明する文書がない」ことで落ちています。
よくある落とし穴
- Controller/Processorの混同：役割が曖昧だと契約も責任も崩れる。
- DPA未締結・サブプロセッサー条項漏れ：顧客の調達審査で失注要因になる。
- 越境移転の誤解：EU→日本は十分性で可だが、米国SaaSの再委託にはDPF/SCCが必要。
- ドイツのDPO義務の見落とし：20名基準を知らずに未選任のまま運用する。
GDPRを含むEU規制全体の体制づくりはEUコンプライアンス体制ガイド、実務の詳細はGDPR対応実務も参照ください。
まとめ
SaaSの GDPR実務 は、役割の確定から契約・移転・安全管理・権利対応までを一気通貫で設計する取り組みです。要点を整理します。
- SaaS提供者は通常 処理者 であり、DPA（第28条） の締結が必須。サブプロセッサー条項に注意。
- EU→日本は十分性認定でSCC不要（範囲内）。米国経由はDPF/SCC＋TIAで手当て。
- ドイツでは DPO 20名基準（BDSG） と 州別の監督官庁 という上乗せ論点を押さえる。
TSM合同会社では、SaaS事業者・SaaS利用企業の双方に向けて、GDPR対応の役割整理、DPA／AVVの整備、越境移転スキームの設計、ドイツのDPO・監督官庁対応まで、日系企業のデータ保護実務を一気通貫でサポートしています。SaaSのGDPR対応でお困りの企業様は、法務・コンプライアンス支援とあわせてお気軽にご相談ください。
本記事は2026年7月16日時点の一般的な解説であり、特定の事案に対する法的助言ではありません。GDPR・BDSGや十分性認定・移転制度は改正・見直しの可能性があります。個別のデータ保護対応にあたっては、最新の公式情報と専門家の助言をご確認ください。