data-lineage-tracking

データリネージの追跡

目的

組織のシステムを通じた個人データのライフサイクル全体を、最初の収集地点から、すべての変換、移転、保存場所を経て、最終的な削除または匿名化に至るまでマッピングし、記録します。

前提条件

• 個人データを処理するシステムを特定したデータインベントリまたは資産台帳
• システム間の接続を示すネットワークアーキテクチャの文書
• システムメタデータ、ETL 設定、API ドキュメントへのアクセス
• GDPR 第30条に基づく処理活動記録（RoPA）

ワークフロー

ステップ 1：データリネージの範囲を定義する

リネージマッピング作業の対象範囲を定めます。

1. データカテゴリ：追跡する個人データのカテゴリを特定します（識別データ、連絡先データ、財務データ、行動データ、第9条に基づく特別カテゴリデータ）
2. システムの境界：対象とするシステムを定義します（本番データベース、データウェアハウス、分析プラットフォーム、サードパーティの SaaS、バックアップシステム）
3. 時間的範囲：現在の状態のリネージのみをマッピングするか、過去のデータフローも含めるかを決定します
4. 法的根拠のマッピング：リネージ内の各処理活動を、GDPR 第6条の適法な根拠に関連付けます

ステップ 2：データソース（収集地点）を特定する

個人データが組織に入るすべての地点を記録します。

1. 直接収集：ウェブフォーム、モバイルアプリ、POS 端末、カスタマーサービスでの対応、スキャンしてデジタル化した紙のフォーム
2. 間接収集：サードパーティのデータプロバイダー、一般公開されている情報源、データブローカー、パートナー組織
3. 派生データ：処理によって生成されるデータ（リスクスコア、顧客セグメント、行動プロファイル）
4. 推論データ：他のデータポイントから推論されるデータ（信用力、健康状態の予測、嗜好）

各ソースについて、以下を記録します。

• ソース識別子と種類
• 収集するデータカテゴリ（第30条(1)(c)のカテゴリを参照）
• 第6条(1)に基づく法的根拠、および該当する場合は第9条(2)に基づく法的根拠
• 第13条または第14条に基づきデータ主体に提供した情報
• 収集量と頻度

ステップ 3：データの変換をマッピングする

個人データに適用されるすべての変換を記録します。

1. ETL プロセス：システム間でデータを移動する抽出・変換・ロードのパイプライン
2. 集約：個々のレコードをグループ化して要約統計を作成すること
3. 仮名化：第4条(5)および前文26に従って識別子をトークンに置き換えること
4. 匿名化：WP29 Opinion 05/2014に従った、元に戻せない識別情報の除去
5. エンリッチメント：複数のソースのデータを組み合わせて、情報を拡充したプロファイルを作成すること
6. 形式変換：データ形式の変更（CSV から JSON への変換、データベースの移行）

各変換について、以下を記録します。

• 入力データのカテゴリとソースシステム
• 変換ロジックの説明
• 出力データのカテゴリと送信先システム
• 変換によってデータ主体の識別可能性が変わるかどうか
• 第5条(1)(e)の保存期間の制限に基づく送信先での保存期間

ステップ 4：データフローと移転を記録する

システム間および関係者間での個人データの移動をすべてマッピングします。

1. 内部フロー：組織内の部門、システム、データベース間の移動
2. 処理者への移転：第28条に基づく契約を締結したデータ処理者への移転
3. 第三国への移転：第44条〜第49条の保護措置が必要な国境を越えた移転
4. 第三者への開示：独立した管理者（規制当局、パートナー、法執行機関）への開示

各フローについて、以下を記録します。

• 送信元と送信先のシステム／主体
• 移転方法（API、ファイル転送、データベースレプリケーション、手動エクスポート）
• 国際移転に関する法的保護措置（SCC、BCR、十分性認定）
• 転送中および保存時の暗号化
• 頻度と量

ステップ 5：データの保存と保持をマッピングする

各段階で個人データがどこに存在するかを記録します。

1. プライマリストレージ：本番データベース、CRM システム、HRIS
2. セカンダリストレージ：データウェアハウス、分析データベース、レポートシステム
3. アーカイブストレージ：長期アーカイブ、コールドストレージ、コンプライアンスアーカイブ
4. バックアップストレージ：災害復旧システム、バックアップテープ、クラウドバックアップ
5. 一時ストレージ：キャッシュ、メッセージキュー、ログファイル、セッションストレージ

各保存場所について、以下を記録します。

• 保存技術と場所（オンプレミス、クラウドリージョン）
• 保持期間と保持の法的根拠
• アクセス制御と暗号化
• 保持期間終了時の削除または匿名化の仕組み

ステップ 6：自動化されたデータリネージの検出を実装する

データリネージの追跡を自動化するツールを導入します。

1. データベースレベルのデータリネージ：クエリログ分析、SQL 解析によるカラムレベルのデータリネージ
2. アプリケーションレベルのデータリネージ：API 呼び出しのトレース、サービスメッシュの可観測性
3. パイプラインレベルのデータリネージ：ETL ツールのメタデータ（Apache Airflow のデータリネージバックエンド、dbt ドキュメント）
4. インフラストラクチャレベルのデータリネージ：ネットワークフローログ、データレイクの監査証跡

scripts/process.py ヘルパーを使用してシステムメタデータを解析し、データリネージグラフを生成します。

ステップ 7：RoPA およびコンプライアンスと統合する

データリネージデータを GDPR コンプライアンス文書にリンクします。

1. 第 30 条の RoPA：各データリネージ経路を RoPA の処理活動に対応付けます
2. DPIA のトリガー：第 35 条第 3 項に該当する処理（大規模なプロファイリング、体系的な監視、特別な種類のデータ）を伴うデータリネージ経路にフラグを付けます
3. データ主体の権利：データリネージを使用して、DSAR 対応に必要なすべてのデータを特定します（第 15 条のアクセス権、第 17 条の消去権、第 20 条のデータポータビリティ権）
4. 侵害の影響範囲の特定：第 33 条第 3 項に従い、インシデント対応時にデータリネージを使用して影響を受けるデータ主体とデータカテゴリーを特定します

ステップ 8：維持および検証する

データリネージを継続的に維持する体制を整えます。

1. 変更管理：新しいシステム、データフロー、処理活動が導入された際にデータリネージを更新します
2. 定期的な検証：実際のシステムの動作と照らし合わせてデータリネージの正確性を確認するため、四半期ごとにレビューします
3. 関係者レビュー：データオーナー、システムアーキテクト、DPO による年次承認を実施します
4. 完全性チェック：データリネージをデータインベントリおよび RoPA と照合し、ギャップを特定します

検証

• すべての個人データカテゴリーについて、ソースからシンクまでのデータリネージ経路が文書化されている
• 各データリネージノードに、法的根拠、保持期間、アクセス制御が含まれている
• 変換ステップに識別可能性への影響が記載されている
• 国境を越える移転が特定され、第 44～49 条の保護措置が文書化されている
• データリネージが第 30 条の RoPA エントリーと統合されている
• 自動検出が少なくともデータベース層とパイプライン層を対象としている
• 責任者が割り当てられた四半期ごとの検証スケジュールが策定されている