プライバシーチームに個人データがどこにあるかを尋ねると、スプレッドシートが返ってきます。エンジニアリングに尋ねると、個人データにまったく触れていない構成図が返ってきます。どちらも不完全です。スプレッドシートではデータがどう動くかを示せず、構成図は何がなぜ動くのかを語りません。
GDPR のデータマッピング図は、この 2 つが出会う場所です。このガイドでは、データマップに記録すべき項目、作り方の手順、そして典型的な SaaS 製品のデータマップの作例を紹介します。これは法的助言ではありません。適法性の根拠、移転の仕組み、保存期間を決めるのは、社内のプライバシー責任者か法律顧問です。
データマップと取扱活動の記録
GDPR 第 30 条は、各管理者に対して、次の事項を含む取扱活動の記録を保持するよう求めています。
- 管理者の名称と連絡先、および該当する場合はその代理人とデータ保護オフィサーの名称と連絡先
- 取扱いの目的
- データ主体の種類と個人データの種類
- 第三国の取得者を含む、取得者の種類
- 第三国への移転と、一部の移転については保護措置の文書
- 可能な場合、消去の期限
- 可能な場合、セキュリティ対策の概要
処理者も、各管理者のために行う取扱いについて同様の記録を保持します。第 30 条第 5 項は従業員 250 人未満の組織を適用除外としていますが、それは取扱いが人々の権利に対するリスクを生じさせる可能性が低く、一時的なものであり、特別な種類のデータや犯罪歴に関するデータを含まない場合に限られます。顧客データを毎日処理する SaaS 企業が該当することはまれです。EU の立法者はこの基準の引き上げを議論してきたので、当てにする前に現行の条文を確認してください。
記録は表です。データマップは、その表に何を書くべきかを見つけ出し、後からそれがまだ正しいかを確かめるための手段です。
フローごとに記録する項目
| 項目 | SaaS 製品の例 |
|---|---|
| データ主体 | 顧客企業のユーザー、アカウント管理者、見込み客、サポートの問い合わせ担当者 |
| 個人データの種類 | アカウントデータ、請求先の連絡先、利用イベント、サポートへのメッセージ |
| 特別な種類のデータ | 健康、生体、その他第 9 条のデータ。ある場合ははっきり示します |
| 目的 | サービスの提供、請求、製品利用の分析、サービスメールの送信 |
| 適法性の根拠 | 目的ごとにプライバシーチームが決めます。契約、正当な利益、同意など |
| システム | データが保存または処理される場所 |
| 取得者 | あなたの代わりに処理を行う処理者と、ほかの管理者 |
| 移転 | EEA 外の移転先と、使う保護措置 |
| 保存 | 各ストアがデータを保持する期間と、削除の方法 |
うまくいく手順
- システムを棚卸しします。 リストアップできるものから始めます。クラウドアカウント、データベース、シングルサインオンや財務チームのベンダー支払いから見つかる SaaS ツールなどです。シャドー IT のツールはそこで見つかります。
- ユーザージャーニーを 1 つずつたどります。 サインアップ、請求、日々の製品利用、サポートチケット、マーケティングメール。データがどこから入り、どこに保存され、次にどこへ行くのかを描きます。
- 担当者に聞きます。 システムごとに、どのフィールドを、何のために、誰が受け取り、どのくらいの期間保持するのかを確認します。
- 処理者と移転に印を付けます。 各ベンダーがどこでデータを処理しているか、データ処理契約(DPA)を結んでいるか、EEA 外への移転をどの保護措置でカバーしているかを書き留めます。
- 保存と削除を追加します。 保存期間のないストアは、それ自体が指摘事項です。
- プライバシーチームとレビューし、データマップから第 30 条の記録を作ります。
EEA 外への移転
GDPR 第 5 章(第 44 条から第 49 条)は、一定の根拠がある場合に限って第三国への移転を認めています。SaaS 企業でよく使われるものは次のとおりです。
- 十分性認定。 欧州委員会は、保護水準が十分だと認めた国を公表しています。米国については、2023 年 7 月の決定が EU-米国データプライバシーフレームワーク(DPF)に参加する企業を対象としています。EU 一般裁判所は 2025 年 9 月にこの決定を支持し、2025 年 10 月には司法裁判所への上訴が提起されたので、当てにする前に現状を確認してください。
- 標準契約条項。 欧州委員会の 2021 年版標準契約条項(SCC)は、十分性認定が適用されない場合に使われる、契約による一般的な保護措置です。
- その他の保護措置と例外。 拘束的企業準則(BCR)や明示的な同意などで、より限られたケース向けです。
データマップ上では、移転はあなたのリージョンから出ていくエッジとして描き、移転先と保護措置をラベルに書きます。
作例:B2B SaaS 製品
この製品は EU のクラウドリージョンで動いています。Web アプリ、PostgreSQL データベース、分析用データウェアハウスです。個人データを受け取るベンダーは 5 社あります。EEA 内のメール配信と決済、米国内の製品分析、サポートデスク、CRM です。
ダイアグラムの内容
- Customer user
- Our systems · EU region
- Web app
- App database
- Analytics warehouse
- Processors in the EEA
- Email delivery
- Payment provider
- Processors in the US · transfers
- Product analytics
- Support desk
- CRM
- account, billing, usage
- account, workspace, billing status
- usage events, pseudonymous IDs
- name, email, message
- billing contact, invoices
- pseudonymous ID, events · DPF
- name, email, tickets · SCCs
- admin contacts, plan · DPF
図の読み方は次のとおりです。
- 入口。 顧客企業のユーザーがアカウントを作り、支払い、製品を使い、サポートに問い合わせます。Web アプリから出るすべてのフローに、運ぶデータの種類をラベルとして付けています。
- 自社システム、EU リージョン。 アプリデータベースはアカウントとワークスペースのデータを保持します。データウェアハウスが受け取る利用イベントには、氏名ではなく仮名化された ID が付いています。
- EEA 内の処理者。 メール配信は氏名、メールアドレス、メッセージ本文を、決済は請求先の連絡先と請求書を受け取ります。移転は発生しません。
- 米国内の処理者。 このフレームに入るエッジはすべて移転で、保護措置を記しています。フレームワークの認証を受けたベンダーには DPF、受けていない 1 社には SCC です。
- 凡例 はラベルを説明し、ストアごとの保存期間の例を挙げています。
役に立つ描き方の約束事
- エッジには技術ではなく、データの種類をラベルとして付けます。 「氏名、メール、チケット本文」はレビュー担当の役に立ちますが、「REST API」は役に立ちません。
- 自社システムの周りに境界線を引き、処理者はその外側にリージョンごとにまとめて置きます。
- すべての移転に印を付け、移転先と保護措置を書きます。
- 特別な種類のデータは強調します。 一貫した 1 色を使い、その意味を凡例に書きます。
- 各ストアに保存期間を書きます。 取扱活動の記録で最も抜けやすい項目です。
- 目的と適法性の根拠は記録に書き、図の横に置きます。図は「どこ」を示し、記録は「なぜ」を述べます。
最新の状態に保つ
データマップは、誰かがベンダーを追加した日に古くなります。更新は、マップを変えるイベントに結び付けます。ベンダーの導入、新しいデータを収集する新機能、データ保護影響評価です。第 35 条により、管理者は高いリスクを生じさせる可能性が高い取扱いを、開始前に評価しなければなりません。その評価の自然な出発点がデータマップです。年に 1 回はマップ全体を見直し、前のバージョンを残しておきましょう。腐らない構成図では、まさにそのためのワークフローを紹介しています。また、プライバシー wiki にライブの図を埋め込めば、全員が同じバージョンを見られます。
データ主体からの請求にデータマップが役立つ理由
アクセスや消去の請求には、その人のデータがあるすべての場所を含めなければなりません。アプリデータベース、データウェアハウス、バックアップ、そしてすべての処理者です。最新のデータマップがあれば、回答は探し物ではなくチェックリストになります。処理者は契約上こうした請求に協力する義務を負っており、どこに依頼すればよいかはデータマップが教えてくれます。
同じフローをセキュリティの観点から見るには、脅威モデリングのためのデータフロー図を参照してください。
Archboard で作る
- Google または GitHub でサインインし、図を作成します。
- 顧客企業のユーザー用に、C4 モデルパックの 人物 を追加します。
- EU リージョンの自社システム用に基本パックの フレーム を追加し、その中に Web アプリ用の C4 モデルパックの コンテナ、アプリデータベース用のデータパックの Postgres、分析用のデータパックの データウェアハウス を置きます。
- 処理者用に基本パックの フレーム をさらに 2 つ追加し(EEA 用と米国用)、ベンダーの役割ごとに C4 モデルパックの 外部システム ノードを置きます。
- 各エッジに運ぶデータの種類をラベルとして付け、米国フレームに入るエッジには保護措置を書き加えます。
- 凡例と保存期間を書いた基本パックの Markdown ブロックを追加します。
この例で使うダイアグラムノードは 13 個で、Free プランの範囲に収まります。GDPR データマッピングのユースケースでは、データマップのほかのレイアウトを紹介しています。
よくある質問
GDPR はデータマップを義務付けていますか? GDPR が第 30 条で求めているのは取扱活動の記録であり、図ではありません。ただし多くのチームは、先にフローをマッピングしないと、正確な記録を作ることも維持することもできないと気づきます。
データマップの持ち主は誰にすべきですか? 記録とその中の判断はプライバシーチームが持ち、システムはエンジニアリングが持ちます。図にはそれぞれの側から 1 人ずつ担当者を置き、一緒にレビューします。
データマップに個々のデータベーステーブルを載せるべきですか? いいえ。ストアと、そこに含まれるデータの種類を載せます。テーブル単位の詳細はデータカタログで管理します。
処理者であり管理者でもあるベンダーはどう表しますか? 1 回だけ描き、フローごとに役割をラベルとして付けます。決済事業者のように、取扱いの一部について管理者として行動する事業者もあります。どの部分かは契約に書かれています。
図で第 30 条の記録を置き換えられますか? いいえ。記録には、目的やセキュリティ対策など、特定の情報を書面で含める必要があります。図は、記録を作って確認するために使います。