data-inventory-mapping

分類のためのデータインベントリとマッピング

概要

データインベントリは、組織全体のすべての個人データ処理活動を体系的に一覧化するものであり、プライバシーコンプライアンスの基盤となります。GDPR 第 30 条では、管理者に対し、個人データのカテゴリ、処理の目的、受領者のカテゴリ、第三国への移転など、特定の項目を含む処理活動記録（RoPA）の維持が義務付けられています。このスキルでは、RoPA の基礎となるデータインベントリの構築に焦点を当て、システムごとの調査、データフローのマッピング、分類との関連付け、データカテゴリごとの法的根拠の割り当てを重視します。

管理者に必要な Art. 30 の記載事項 — Art. 30(1)

必須項目	説明	分類との関連性
(a) 管理者の身元	管理者、共同管理者、代理人、DPO の名称と連絡先	管理上の項目 — 分類には依存しません
(b) 処理の目的	各処理活動の具体的な目的	目的によって適用される適法な根拠が決まり、分類から取り扱いへのマッピングを導きます
(c) データ主体のカテゴリ	データが処理される個人の種類（顧客、従業員、応募者）	データ主体のカテゴリは、適用される保護に影響します（例：子ども、従業員）
(d) 個人データのカテゴリ	活動ごとに処理される個人データの種類	データ分類の直接的な成果 — 個人データ、特別カテゴリ、犯罪に関するデータ
(e) 受領者のカテゴリ	処理者を含む、データの受領者	移転および共有に関する管理策を決定します
(f) 第三国への移転	国際移転および保護措置の仕組み	第 V 章のコンプライアンス要件が発生します
(g) 保持期間	さまざまなカテゴリのデータを消去するまでに想定される期間	分類レベルによって保持ポリシーが決まります
(h) セキュリティ対策	第 32 条の技術的および組織的対策の概要	分類レベルによってセキュリティ管理策の水準が決まります

データインベントリの構築方法

フェーズ 1：システムの調査（第 1～3 週）

ステップ 1：エンタープライズアプリケーションのインベントリ

個人データを処理するシステムの完全な一覧を作成します。

調査方法	情報源	成果物
IT 資産管理システム	CMDB、ServiceNow、Lansweeper	登録済みのアプリケーションとサーバー
調達記録	ベンダー契約、SaaS サブスクリプション、ライセンス管理	データを処理するサードパーティシステム
ネットワークトラフィック分析	ファイアウォールログ、プロキシログ、DNS クエリ	外部サービスへの未文書化のデータフロー
シャドー IT の調査	クラウドアクセスセキュリティブローカー（CASB）のログ、SaaS ツールの経費報告書	未承認または不明なアプリケーション
部門への聞き取り	事業部門の責任者、データスチュワード	部門で使用するツールとローカルデータベース

Vanguard Financial Services — システムインベントリの例

システム	種別	部門	データ主体	分類の優先度
Salesforce CRM	SaaS	営業、カスタマーサービス	顧客、見込み顧客	Tier 1
Workday HR	SaaS	人事	従業員、候補者	Tier 1
ADP GlobalView	SaaS	給与計算	従業員	Tier 1
Oracle Data Warehouse	オンプレミス	データエンジニアリング	すべてのデータ主体	Tier 1
SharePoint Online	SaaS	全部門	すべてのデータ主体	Tier 1
NICE Actimize	オンプレミス	コンプライアンス	顧客、取引相手	Tier 1
HID Global Access	オンプレミス	施設管理	従業員、請負業者	Tier 2
Cority Occ Health	SaaS	産業保健	従業員	Tier 2
Bloomberg Terminal	SaaS	トレーディング	取引相手	Tier 2
Microsoft Teams	SaaS	全部門	従業員、外部の連絡先	Tier 2
Adobe Analytics	SaaS	マーケティング	ウェブサイト訪問者	Tier 2
ServiceNow ITSM	SaaS	IT	従業員	Tier 3
Confluence Wiki	SaaS	エンジニアリング	従業員	Tier 3

フェーズ 2：データ要素のマッピング（第 3～6 週）

システムごとに、すべてのデータ要素を記録します。

ステップ 2：スキーマの抽出

• 構造化データベース：SQL メタデータクエリまたはデータカタログ API を通じて、スキーマのメタデータ（テーブル名、列名、データ型）を抽出します
• SaaS アプリケーション：API ドキュメントを使用して、データオブジェクトとフィールドを列挙します
• 非構造化リポジトリ：ドキュメントの種類と、通常含まれる個人データの内容をカタログ化します
• 自動検出：すべてのリポジトリ内の PII を特定するスキャンツールを導入します（auto-data-discovery スキルを参照）

ステップ 3：データ要素の分類

データ要素ごとに、以下を割り当てます。

• 個人データの分類：PERSONAL_DIRECT、PERSONAL_INDIRECT、SPECIAL_CATEGORY、CRIMINAL_ART10、PSEUDONYMISED、ANONYMISED、NON_PERSONAL（personal-data-test スキルを参照）
• 分類ティア：公開、内部、機密、制限付き（classification-policy スキルを参照）
• 第 6 条の適法な根拠：明記された目的ごとに、この要素を処理する法的根拠
• 第 9 条第 2 項の条件：特別カテゴリーの場合は、具体的な処理条件

フェーズ 3：データフローのマッピング（第 6～9 週）

ステップ 4：システム内データフロー

組織内でデータがどのように移動するかを記録します。

Customer Onboarding Data Flow — Vanguard Financial Services

Customer ──[web form]──► Salesforce CRM
                              │
                    ┌─────────┼──────────┐
                    ▼         ▼          ▼
              Oracle DW   SharePoint   Email (welcome)
              (analytics) (documents)  (notifications)
                    │
                    ▼
              Adobe Analytics
              (web behaviour)

ステップ 5：外部データフロー（第三者との共有）

外部当事者とのすべてのデータ共有を記録します。

送信元システム	受信者	データカテゴリー	移転メカニズム	法的保護措置
Salesforce CRM	Salesforce Inc.（処理者）	顧客の個人データ	SaaS ホスティング	標準契約条項（2021/914）
Workday HR	Workday Inc.（処理者）	従業員の個人データおよび特別カテゴリーのデータ	SaaS ホスティング	EU-US データプライバシーフレームワーク
ADP Payroll	HMRC（法定受領者）	従業員の財務データ	セキュアなファイル転送	第 6 条第 1 項（c）に基づく法的義務
NICE Actimize	NCA（法定受領者）	顧客の AML データ（第 10 条）	SAR Online ポータル	POCA 2002 に基づく法的義務
Oracle DW	Deloitte（監査人）	匿名化された財務データ	暗号化されたファイル転送	共同管理者契約

フェーズ 4：法的根拠と目的のマッピング（第 9～11 週）

Step 6: 目的・法的根拠マトリクス

各処理活動について、データのカテゴリーを目的および法的根拠に対応付けます。

処理活動	データカテゴリー	目的	第6条の根拠	第9条(2)／第10条
顧客アカウント管理	氏名、メールアドレス、住所、アカウント番号	契約の履行	第6条(1)(b)	該当なし
KYC本人確認	氏名、生年月日、本人確認書類、住所	法的義務（MLR 2017）	第6条(1)(c)	該当なし
従業員の給与計算	氏名、NINO、銀行口座情報、給与	契約の履行	第6条(1)(b)	該当なし
従業員の多様性モニタリング	民族的出自、性的指向	平等性のモニタリング	第6条(1)(a)／6(1)(c)	第9条(2)(a)／9(2)(b)
建物の入退室管理	指紋テンプレート	物理的セキュリティ	第6条(1)(f)	第9条(2)(a)
AMLモニタリング	取引パターン、SARデータ	法的義務（POCA 2002）	第6条(1)(c)	第10条 — DPA 別表1 第2部 第10項
ウェブサイト分析	IPアドレス、Cookie、閲覧履歴	正当な利益	第6条(1)(f)	該当なし
マーケティング通信	メールアドレス、設定	同意	第6条(1)(a)	該当なし

フェーズ5：文書化と保守（継続的）

Step 7: インベントリの統合

検出結果をすべて正式なデータインベントリに統合します。

• システムごと、データ要素ごとに1件の記録を作成
• RoPA内の処理活動と相互参照
• 各要素に分類ラベルを適用
• 分類レベルごとにレビュー日を設定

Step 8: 継続的な保守

保守活動	頻度	担当
自動検出スキャンの照合	毎月	プライバシーエンジニアリング
新規システム導入時のインベントリ作成	新規システムの導入ごと	システムオーナー＋プライバシーアナリスト
部門データスチュワードによるレビュー	四半期ごと	データスチュワード
インベントリ全体の正確性監査	毎年	DPO
分類の再評価レビュー	毎年（境界例：6か月ごと）	プライバシーアナリスト

データフロー図の標準

表記規則（DFDレベル0／1に基づく）

記号	意味
長方形	外部エンティティ（データ主体、第三者、規制当局）
角丸長方形	プロセス（システムまたはアプリケーション）
開いた長方形（平行な2本の線）	データストア（データベース、ファイル共有）
矢印	データフロー（データカテゴリーをラベル表示）
破線の矢印	任意または条件付きのデータフロー
赤い枠線	特別カテゴリーまたは犯罪関連データを含む
青い枠線	国際移転

執行事例

• Österreichische Datenschutzbehörde（オーストリアDPA）対 Local Bakery Chain（2020）：第30条の記録を維持しなかったとして、4,000ユーロの罰金が科されました。DPAは、小規模な組織であっても処理記録を維持しなければならないと指摘しました。
• CNIL対 Sergic（2019）：データマッピングが不十分であったことなどを理由に、40万ユーロの罰金が科されました。管理者は個人データの保存場所を把握していることを証明できず、その結果、データ侵害の検知が遅れました。
• ICO対 British Airways（2020）：データマッピングが不十分であったために侵害の検知が遅れ、2,000万ポンドの罰金が科されました。管理者は、ウェブインフラストラクチャを通過する個人データの流れを把握できていませんでした。

統合ポイント

• auto-data-discovery：自動スキャンにより、データ要素をインベントリに追加
• personal-data-test：インベントリ内の各データ要素に分類判断を適用
• special-category-data：第9条のデータにフラグを立て、処理条件に対応付け
• criminal-data-handling：第10条のデータを特定し、国内法上の許可に対応付け
• data-lineage-tracking：リネージグラフにより、静的なインベントリを動的なフロー情報で拡張