はじめに
第1回では、データマッピング導入に向けた要件定義の考え方について解説した。目的整理、スコープ設計、ヒアリング方針を整理し、何を管理対象とするのかを明確化した。
第2回では、その要件をどのように情報構造へ落とし込むかを扱った。データマッピングは単なる処理活動一覧ではなく、Processing Activity（データ処理活動）を中心に、データカテゴリ、システム、第三者提供先、法的根拠、保存期間などを関係構造として管理し、RoPA（処理活動記録）、データフロー可視化、リスク管理、監査対応に活用できる状態を作ることが目的である。
しかし、設計書が完成しただけではデータガバナンスは実現しない。実際には、第2回で整理した情報構造、管理粒度、ワークフロー、権限の考え方をツール上へ具体的に実装し、継続的に更新できる状態へ構築する必要がある。
本稿では、架空のグローバル企業を例に、OneTrustを利用したデータマッピング基盤の実装方法について解説する。実装の第一歩として重要なのは、個別の機能を手当たり次第に設定することではなく、OneTrust利用開始時に前提となりやすい「組織構造」「ユーザー・権限」「属性」を整理しておくことである。もっとも、以下で示す設定順序や項目立ては、あくまで一つの型であり、企業の体制やツールのバージョンに応じて柔軟に組み替えて差し支えない。本稿ではこれらの前提設定を解説したうえで、データ処理活動のテンプレート作成・登録に進む。なお、各章の画面キャプチャは実装イメージを掴むための作業例であり、細部の操作手順そのものよりも、第1回・第2回で整理した設計思想がどのようにツール上の設定へつながるかという考え方を中心に読み進めていただきたい。
なお、本稿内の画像は、弊社が提供する「IIJデータマッピング・リスク評価ツール」である米国OneTrustの画面表示である。
1. ケーススタディ
本稿では、以下のような企業を想定する。A社は日本本社であり、ドイツ子会社を有している。A社はSalesforceとMicrosoft 365を利用し、外部マーケティング会社へ顧客情報を含むデータ処理の一部を委託している。また、ドイツ子会社を通じてEU居住者データを取り扱っており、GDPR対応とデータガバナンス強化を目的として、OneTrustを利用したデータマッピング基盤の構築を進めている。
A社のような企業では、顧客管理、メール配信、分析、委託先とのデータ共有など、複数の処理活動が複数のシステム・組織・第三者と関係している。そのため、第2回で整理した「データ処理活動中心の関係構造」を、実装段階でどれだけ正確にツールへ反映できるかが重要となる。
A社
- 日本本社
- ドイツ子会社を有する
- Salesforce利用
- Microsoft 365利用
- 外部マーケティング会社へ顧客情報を含むデータ処理を委託
- ドイツ子会社を通じてEU居住者データを取り扱う
2. 組織構造（Organization Structure）を設定する
OneTrust利用開始にあたり、最優先で設計すべきなのが組織階層である。組織階層は、Processing Activity、Asset、Third Partyなど、ツール上のあらゆるオブジェクトへのアクセス範囲を決定する土台であり、これが整備されていない状態では、後続のユーザー・権限設定やデータ処理活動の管理範囲を正しく切り分けることができない。
組織階層におけるアクセス制御の考え方は次のとおりである。親組織は子組織のオブジェクトへアクセスできる一方、子組織は親組織のオブジェクトへアクセスできず、同一階層の兄弟組織同士も互いにアクセスできない。
A社のケースでは、日本本社とドイツ子会社を兄弟組織として定義し、双方がお互いのオブジェクトへアクセスできないように設定する。これにより、法人ごとの責任分界点を明確にし、不要な横断閲覧や誤更新を防止できる。
組織階層は、グローバル設定の組織（Organizations）メニューから作成する。起点となる組織（親組織）を登録したうえで、その配下に子組織を追加していくことで、ツリー構造が構築される。階層を後から変更すると、既に登録済みのオブジェクトのアクセス範囲にも影響するため、要件定義・設計段階で管理単位を慎重に検討したうえで、初期段階で階層を確定させておくことが望ましい。
3. ユーザー追加・権限管理を行う
組織階層が整備できたら、次に実際にツールを操作する担当者をユーザーとして追加する。OneTrust利用開始時には、業務担当者だけでなく、レビューや承認を行う関係者も含めて、誰がどの範囲でツールを利用するのかを、あらかじめ整理しておくことが望ましい。
ユーザー追加は、グローバル設定のユーザー管理（Users）メニューから行う。メールアドレスを指定してユーザーを招待し、招待を受けたユーザーは付与された認証情報（またはSSO）でログインすることで利用を開始する。ユーザーの追加時には、後述するロールと、アクセス可能な組織範囲をあわせて指定する。
利用者と管理者では役割が異なる。一般利用者は、自身が所属する組織に紐づくデータ処理活動の登録・更新や、質問票への回答が中心となる。これに対し、後述するサイト管理者は、組織階層・属性・テンプレートといったグローバル設定自体を変更する権限を持つ。実務では、まずサイト管理者を数名に限定して登録し、その後、部門担当者を一般ユーザーとして順次登録していく進め方が現実的である。
4. サイト管理者権限と一般権限の違いを理解する
ユーザー追加や属性設定といった作業は、付与された権限によって実施できる範囲が異なる。そのため、ユーザー追加に先立ち、権限の考え方をあわせて理解しておくと、後続の運用がスムーズになる。
ツールではロールベースアクセス制御（RBAC）により権限管理を行う。各機能は権限と紐付いており、付与されていない機能は画面上に表示されないため、役割に応じたアクセス制御を実現できる。
| 権限 | 主な操作範囲 |
|---|---|
| サイト管理者（Site Admin） | 組織階層、ユーザー、属性、テンプレートなどグローバル設定全般の変更。全組織のオブジェクトの閲覧・編集。 |
| 一般ユーザー | 自身が割り当てられた組織の範囲内での、データ処理活動の登録・更新、質問票・評価への回答など、業務に必要な限定的な操作。 |
事前定義されたロールに加え、運用要件に応じたカスタムロールも作成可能である。実務上は、既存ロールを複製し、必要な権限のみを調整する方法が有効である。組織構造・ユーザー・権限の設定が整うことで、次章以降で扱う属性やテンプレートの管理範囲も明確になる。
5. データ処理活動の属性を設定する
組織・ユーザー・権限の設定が整ったら、次にデータ処理活動（Processing Activity）を管理するための属性（Attribute）を設定する。属性とは、データ主体、データカテゴリ、利用システム、第三者提供先、法的根拠、保存期間など、Processing Activityに紐づくメタ情報の選択肢を指す。
属性は、Processing Activityの詳細画面や、次章で作成するテンプレートの選択肢として利用される。そのため、テンプレートを作成する前に、自社の管理粒度に沿った属性の選択肢を、あらかじめ整備しておくことが望ましい。標準で用意されている属性値をそのまま利用すると、自社の実態と合わない選択肢が並び、現場が回答に迷う原因となる。
例えば、法的根拠の属性については、GDPR上の「同意」「契約履行」「正当な利益」等、自社が実際に用いる根拠に沿って選択肢を整理する。保存期間についても、部署ごとにバラバラな単位・表記で入力されないよう、あらかじめ区分（例：契約終了後1年、法定保存期間に準拠 等）を定義しておく。
なお、本稿では対象をデータ処理活動に絞って解説しており、アセットや事業体に紐づく属性についての詳細は割愛する。
6. データ処理活動テンプレートを作成する
第2回では、データマッピングの質を左右するのは現場ヒアリングの内容であり、その本質は処理構造の把握にあると述べた。実装フェーズでは、そのヒアリング項目を、前章で整備した属性を用いたデータ処理活動向けの質問票テンプレートとして構築し、現場が回答可能な形に落とし込む。
ツールには標準テンプレートが用意されているが、そのまま利用するだけでは自社の管理粒度やリスク管理要件に十分適合しない場合がある。A社のケースでは、「GDPR データ処理の記録（管理者向け）」テンプレートをベースにしつつ、必要な管理項目だけを残し、回答しやすい構成に調整する。
以下はAssessment Template一覧画面の例である。この画面では、どのテンプレートを標準として利用するか、どのテンプレートを自社向けに編集するかを管理する。テンプレート数を増やしすぎると運用が複雑になるため、できるだけ汎用性の高い標準テンプレートをベースに調整するのが現実的である。
以下は質問票の作成画面の例である。この画面では、質問項目、回答形式、表示順、必須入力条件などを設定できる。第2回で示したとおり、「個人情報を扱っていますか」といった抽象的な聞き方ではなく、「どの業務でどのデータを利用しているか」「どの外部委託先が存在するか」といった業務起点の質問に組み替えることが重要である。
また、法的根拠、保存期間、越境移転の有無といった項目は、前章で整備した属性を用いて、できるだけ選択式で実装する方が、表記ゆれを抑え、後続の検索や分析の精度を高めやすい。以下のような個別質問設定画面では、回答形式や選択肢の定義を細かく調整できる。
さらに、条件分岐を用いて、特定の回答を選択した場合にのみ追加質問を表示させることもできる。例えば、「越境移転あり」と回答した場合にのみ、移転先地域、移転根拠などの詳細質問を表示することで、不要な質問を減らしつつ、必要な論点を漏れなく収集できる。
以下は回答内容に応じたリスク設定画面の例である。特定の回答に対してリスクスコアや追加確認条件を設定しておくことで、後続の評価プロセスへ接続しやすくなる。
テンプレートは単なる入力フォームではなく、全社で統一された管理項目を回収するための統制手段であることを意識すべきである。加えて、回答内容に応じて注意すべきリスク観点をあらかじめ設定しておくことで、後続の評価と接続しやすくなる。例えば、第三国への越境移転、機微情報の取扱い、外部委託の有無、プロファイリングの有無といった回答については、追加確認が必要な項目として扱い、必要に応じて高いリスクスコアを設定することが考えられる。こうした構成にしておけば、質問票は情報収集のための様式にとどまらず、データ処理活動をリスクの観点から把握し、後続の評価プロセスへつなぐ基盤として機能する。
7. データ処理活動（Processing Activity）を登録する
組織構造、ユーザー・権限、属性、テンプレートの整備が完了したら、実際のデータ処理活動をProcessing Activityとして登録する。第2回でも説明したとおり、データマッピングにおいてProcessing Activityは中心となる管理単位であり、各種メタデータや関連オブジェクトを結び付ける役割を持つ。RoPAも処理活動単位で整理されるため、多くの企業ではこれを基本単位として運用する。
ここで重要なのは、「業務名を登録すること」自体が目的ではないという点である。Processing Activityは、どのようなデータを、どのような目的で、どのシステムを通じて、どの法的根拠に基づき処理しているかを説明するための管理単位である。したがって、第2回で示したとおり、実装時にも「業務目的」「利用データ」「管理責任」が区別可能な単位を目安として粒度を決めることが重要となる。
例えばA社において、「顧客管理」を一つのProcessing Activityにまとめてしまうと、メール配信、顧客分析、契約管理など異なる目的や法的根拠を一つのレコードに混在させることになり、RoPAやリスク評価の精度が低下する。そのため、用途や責任主体の違いに応じて、顧客登録、メール配信、顧客分析といった単位で分けて登録するのが実務的である。
以下はProcessing Activity一覧画面の例である。一覧画面では、登録された処理活動の件数、担当組織、ステータスなどを横断的に確認できる。A社では、この画面で顧客登録、メール配信、顧客分析といった各処理活動を個別に管理する。
以下はProcessing Activity詳細画面の例である。詳細画面では、データ主体、データカテゴリ、利用目的、法的根拠、保存期間、関連Asset、関連Third Partyなど、前章までに整備した属性の値を登録・確認できる。ここで入力された情報が、後続のRoPA出力や評価の基礎情報となる。
8. ワークフローを構築する
第2回では、入力フォームだけ整備しても更新プロセスが存在しなければデータは陳腐化し、その価値を失うと述べた。実装フェーズでは、このワークフロー設計をツール上の承認・更新フローとして反映する。
A社では、業務担当者が初回登録を行い、その後、部門レビュー、リスク管理部門確認、承認という流れを標準ワークフローとして設定する。このような段階的な確認フローを実装することで、誰が、いつ、どの内容を確認・承認したのかを記録しやすくなり、後続の監査や運用見直しにも対応しやすくなる。
以下はWorkflow設定画面の例である。この画面では、登録から承認までのステップを定義し、どの役割がどの段階でレビューや差戻しを実施するかを設定する。ワークフローを実装しておくことで、データマッピングは単なる一覧表ではなく、継続的に見直される統制プロセスとして機能する。
なお、承認フローを適切に機能させるためには、第4章で解説した権限設定に基づき、誰が登録・レビュー・承認できるのかを明確にしておくことが前提となる。
さらに、更新トリガーをどのタイミングで発火させるかも明確にしておく必要がある。新規システム導入、SaaS利用開始、委託先変更、海外移転などを契機としてProcessing Activityの見直しを求める設計にしておくことで、情報の陳腐化を防止しやすくなる。
9. 評価を実施する
ここまでで、組織構造、ユーザー・権限、属性、テンプレート、Processing Activity、ワークフローが実装された。しかし、データマッピングの目的は情報を登録すること自体ではない。重要なのは、登録された情報を利用してリスクを評価し、必要な対応を実施できる状態を構築することである。第2回でも、データマッピングはリスク管理や監査対応に活用できる状態を作ることが目的であると述べた。
以下はアセスメントの一覧・起票画面の例である。この画面では、対象となるProcessing Activityに対して評価を起票し、どの処理活動が評価済みか、どの処理活動に追加確認が必要かを管理できる。A社では、顧客分析や外部マーケティング会社への委託を伴うProcessing Activityを優先的な評価対象とする。
以下は評価フォーム画面の例である。評価フォームでは、第三者提供の有無、越境移転、機微情報の取扱い、利用システム、委託先などをもとに回答する。Processing Activityに紐付けられた各種情報が前提として整理されているため、評価時に確認すべき論点を漏れなく把握しやすい。
さらに、評価の結果をもとにリスク水準や追加措置の要否を確認できる。例えば、越境移転や外部委託を伴う処理について高いリスクが示された場合には、契約条件の見直し、追加的な安全管理措置、法的根拠の再確認などの対応を検討することになる。データマッピング基盤は、このように「台帳」ではなく「評価と統制の入口」として機能する。
10. セキュリティと認証を設定する
実装フェーズでは、Processing Activityや評価結果だけでなく、それらを管理する基盤の認証・利用管理もあわせて整えておくことが望ましい。例えば、一定時間非アクティブな状態が続いた場合に自動的にログアウトさせるセッションタイムアウトを設定することで、離席時や共有端末利用時の不正利用リスクを抑制できる。ツールでは、セッションタイムアウト時間を5分から24時間の範囲で設定可能である。
また、セッション保護を有効化し、セッション Cookie を利用することで、認証済みセッションの悪用リスクを低減できる。認証方式としてはSAMLによるシングルサインオン（SSO）が望ましく、SSOを利用しない場合には多要素認証（MFA）や招待ユーザーへのワンタイムパスワード（OTP）検証を有効化することで、本人確認を強化できる。
さらに、ログイン履歴の保存期間も30日から7年の範囲で設定できる。誰がいつログインしたかを追跡できる状態を維持しておけば、監査対応やインシデント調査に活用しやすくなる。セキュリティと認証の設定は、単なるログイン制御ではなく、データマッピング基盤を安全に継続運用するための前提となる重要な実装要素である。
11. 実務で気を付けたいポイント
データマッピング実装の実務で気を付けておきたいポイントとして、第2回で示した設計上の失敗が、そのまま実装段階で顕在化することである。例えば、Processing Activityの管理粒度が粗すぎるまま登録を進めると、一つのレコードに複数の処理活動が混在し、評価やRoPA出力の精度が低下する。逆に、項目数を増やしすぎると、現場が回答できず更新率が落ちる。
また、組織構造やユーザー・権限の設定を後回しにしたまま、事業体やアセット、Processing Activityの登録を先に進めてしまうと、同じシステムや委託先が重複・多重登録され、後から集計や分析を行う際に大きな障害となる。さらに、更新責任者や権限を明確にしないまま運用を開始すると、誰が変更すべきか分からず、台帳が更新されなくなる。
特に危険なのは、「登録完了＝統制完了」と誤解することである。重要なのは、登録済みのProcessing Activityが継続的に見直され、必要に応じて評価・更新される状態を維持することである。データマッピングは、入力作業そのものではなく、継続的なデータガバナンス活動として、その運用方法を構築していくことが望ましい。
おわりに
本稿では、第2回で設計した情報構造をツールへ実装する方法について解説した。組織構造、ユーザー・権限、属性といった前提設定を優先度の高い順に整備したうえで、データ処理活動のテンプレート作成・登録に進む流れを取り上げた。なお、実際の設定順序や項目は、企業の体制やツールのバージョンに応じて柔軟に見直して差し支えない。
重要なのは、Processing Activityを中心として、組織、システム、第三者、法的根拠、保存期間などを関係構造として実装し、それを質問票、ワークフロー、権限、評価へ連動させることである。
データマッピング基盤は、単なる一覧表や入力フォームではない。設計した関係構造を、継続的に更新・評価・監査可能な形でシステムへ落とし込むことで、初めてリスク管理や説明責任に耐えうる情報基盤となる。
もっとも、実装が完了した時点では、まだ基盤が正しく機能しているとは言えない。登録された情報の整合性、権限設定の妥当性、ワークフローの動作、評価結果の妥当性などを検証し、実運用に耐えられる品質かどうかを確認しておくとよい。次回の第4回では、実装したデータマッピング基盤が正しく機能することを確認し、組織に定着させるためのテスト・運用フェーズについて解説する。
