LESSON 30分

ストーリー

田中VPoE
データガバナンスの中で、最も法的リスクが高いのが「プライバシーとコンプライアンス」だ。これを軽視すると、会社の存続に関わるインシデントになりかねない
あなた
個人情報保護法の対応は一応やっているはずですが、「していると思う」レベルだと前回の棚卸しで分かりました
田中VPoE
「していると思う」は「していない」と同じだ。個人情報保護法、GDPR、CCPA — 規制は年々厳しくなっている。「あとで対応する」は通用しない
あなた
具体的にどうすればいいですか?
田中VPoE
まず規制の全体像を理解し、次にデータ分類に基づいたコンプライアンス体制を設計する。そして最も重要なのは、コンプライアンスを「コスト」ではなく「信頼構築」と位置づけることだ

データプライバシー規制の全体像

主要な規制とその要件

規制対象地域主な要件違反時の制裁
個人情報保護法(日本)日本利用目的の特定・公表、安全管理措置、第三者提供の制限命令違反で1億円以下の罰金
GDPR(EU一般データ保護規則)EU/EEA同意の取得、データ主体の権利保障、DPO設置義務全世界年間売上の4%または2,000万EUR
CCPA/CPRA(カリフォルニア)米国カリフォルニア州知る権利、削除権、オプトアウト権意図的違反で1件7,500USD
APPI改正(2022年施行)日本個人関連情報の第三者提供規制、漏洩報告義務報告義務違反で罰則強化

共通する基本原則

原則内容実装への影響
目的限定収集時に明示した目的以外に使用しないデータの利用目的をメタデータに記録
データ最小化目的達成に必要最小限のデータのみ収集不要なPIIの収集を見直し
正確性個人データは正確かつ最新に保つデータ品質管理の対象に含める
保存制限目的達成後は速やかに削除保持期間ポリシーの策定と自動削除
完全性・機密性適切なセキュリティ対策を講じる暗号化、アクセス制御、監査ログ
説明責任遵守していることを証明できる文書化、監査証跡の保持

Privacy by Design の実践

7つの基本原則

原則説明実装例
事前的(Proactive)問題が起きてからではなく、事前に対策する設計段階でPIAを実施
デフォルトでプライバシー保護何も設定しなくてもプライバシーが保護されるオプトイン方式の採用
設計に組み込むプライバシー保護を後付けではなく設計に組み込むアーキテクチャレベルでの暗号化
ゼロサムではないプライバシーと機能性は両立できる差分プライバシー、合成データ
ライフサイクル全体データ収集から廃棄まで全段階で保護自動保持期間管理
可視化と透明性データの取り扱いが利用者に見えるプライバシーダッシュボード
ユーザー中心個人の利益を最優先するデータポータビリティ

PIA(プライバシー影響評価)プロセス

PIA(プライバシー影響評価)の流れ:

Step 1: データフローの特定
  └── どのPIIが、どこで、どのように処理されるか

Step 2: リスクの識別
  ├── 収集段階のリスク(過剰収集、同意不備)
  ├── 処理段階のリスク(目的外利用、不適切なアクセス)
  ├── 保存段階のリスク(暗号化不備、過剰保持)
  └── 共有段階のリスク(第三者提供、越境移転)

Step 3: リスクの評価
  ├── 影響度(高/中/低)
  └── 発生可能性(高/中/低)

Step 4: 対策の策定
  ├── 技術的対策(暗号化、匿名化、アクセス制御)
  └── 組織的対策(ポリシー、教育、監査)

Step 5: 残留リスクの受容判断
  └── 対策後も残るリスクを経営層が判断

データ保護の技術的対策

技術的対策の一覧

対策概要適用場面
暗号化(保存時)AES-256等でデータを暗号化して保存DB、ストレージ、バックアップ
暗号化(転送時)TLS 1.3でデータの転送経路を保護API通信、データ連携
トークナイゼーション機密データをトークンに置換クレジットカード番号、マイナンバー
仮名化個人を直接特定できないように加工分析用データの提供
匿名化個人を特定できない状態に不可逆変換統計分析、公開データ
差分プライバシー統計的ノイズを追加して個人の特定を防止MLモデルの学習データ
RBAC/ABAC役割/属性ベースのアクセス制御データアクセス管理全般
監査ログすべてのデータアクセスを記録コンプライアンス証明

データ保護レベルの設計

機密度保存時暗号化転送時暗号化アクセス制御監査ログマスキング
Restricted必須(カラムレベル)必須(TLS 1.3)個人単位承認全操作記録必須
Confidential必須(テーブルレベル)必須部門単位承認読み取りも記録推奨
Internal推奨必須社員アクセス可書き込み記録不要
Public不要推奨制限なし不要不要

データ削除権(忘れられる権利)への対応

技術的な実装パターン

パターン概要メリットデメリット
物理削除データを完全に削除確実リネージが途切れる、復旧不可
論理削除+暗号化キー破棄データは残すがキーを破棄して読めなくする参照整合性を維持キー管理が複雑
仮名化個人と紐づく情報を削除し、仮名化データのみ残す統計分析に影響なし完全削除ではない

削除対応のアーキテクチャ

削除リクエストの処理フロー:

[ユーザー] ──→ [削除リクエストAPI]

                    ├── 本人確認
                    ├── 削除対象データの特定
                    │     ├── 顧客マスター(物理削除)
                    │     ├── 注文履歴(仮名化)
                    │     ├── 行動ログ(匿名化)
                    │     └── バックアップ(次回ローテーション時に削除)
                    ├── 削除実行
                    ├── 第三者提供先への削除通知
                    └── 削除完了の記録・通知

「プライバシー対応は”やらなければならないこと”ではなく、“顧客の信頼を勝ち取るための投資”だ。プライバシーを大切にする組織は、顧客からも社員からも信頼される」 — 田中VPoE


まとめ

ポイント内容
主要規制個人情報保護法、GDPR、CCPA — 共通原則を押さえる
Privacy by Design事前対策、デフォルト保護、設計への組み込み
技術的対策暗号化、トークナイゼーション、匿名化、アクセス制御
削除対応物理削除、暗号化キー破棄、仮名化を使い分ける

チェックリスト

  • 主要なデータプライバシー規制の概要を把握した
  • Privacy by Designの7原則を理解した
  • PIAのプロセスを把握した
  • データ保護の技術的対策を理解した
  • 削除権への対応パターンを把握した

次のステップへ

次は「演習:データガバナンス体制を設計しよう」です。ここまで学んだガバナンスフレームワーク、オーナーシップ、メタデータ管理、プライバシー対応を統合して、具体的な体制を設計します。


推定読了時間: 30分