automating-storage-limitation-controls

保存期間制限の管理の自動化

概要

GDPR 第 5 条第 1 項（e）は、個人データを「個人データが処理される目的に必要な期間を超えて、データ主体を識別できる形式で保管してはならない」と定めています。これが保存期間制限の原則です。管理者は、処理目的に基づき、個人データの各カテゴリーについて保存期間を定める必要があります（第 13 条第 2 項（a）は、保存期間またはその決定基準の開示を求めています）。

手作業による保存期間管理では、大規模な運用においてコンプライアンス上の不備が避けられないため、自動化が不可欠です。EDPB の第 25 条に関するガイドライン 4/2019 では、自動削除の仕組みをデータ保護バイデザインの例として明示しています。

保存期間ポリシーのフレームワーク

保存期間の決定

各保存期間は、処理目的、法的要件、または正当な事業上の必要性を根拠として正当化する必要があります。

データカテゴリー	目的	適法性の根拠	保存期間	保存期間の起算点	法的参照
顧客アカウントデータ	サービスの提供	Art. 6(1)(b)	契約期間＋90日	アカウントの閉鎖	Art. 5(1)(e), Art. 17(1)(a)
取引記録	税務コンプライアンス	Art. 6(1)(c)	10年	取引日	Swiss CO Art. 958f, EU VAT Directive 2006/112/EC Art. 242
サポートチケット	顧客サービス	Art. 6(1)(b)	3年	チケットのクローズ	Art. 5(1)(e)、時効期間
サーバーアクセスログ	セキュリティ監視	Art. 6(1)(f)	12か月	ログの作成日	Art. 5(1)(e)、ENISA の推奨
マーケティング同意記録	説明責任	Art. 6(1)(c)	同意期間＋5年	同意の撤回	Art. 7(1), Art. 5(2)
雇用記録	法的義務	Art. 6(1)(c)	雇用期間＋10年	雇用の終了	Swiss OR Art. 127-128
Cookie 分析データ	製品の改善	Art. 6(1)(a)	13か月	データ収集	ePrivacy Directive Art. 5(3)、CNIL のガイダンス
DPIA 記録	説明責任	Art. 6(1)(c)	処理期間＋3年	処理の終了	Art. 35, Art. 5(2)

TTL ベースの削除アーキテクチャ

┌─────────────────────────────────────────────────────────────┐
│                   Retention Policy Engine                     │
│  ┌───────────────┐  ┌────────────────┐  ┌───────────────┐  │
│  │ Policy Store  │  │ TTL Calculator │  │ Legal Hold    │  │
│  │ (per category)│  │ (trigger+period)│  │ Registry      │  │
│  └───────┬───────┘  └───────┬────────┘  └──────┬────────┘  │
│          └──────────────────┼───────────────────┘           │
└─────────────────────────────┼───────────────────────────────┘
                              │
┌─────────────────────────────▼───────────────────────────────┐
│                   Lifecycle Scheduler                         │
│  ┌──────────────────┐  ┌──────────────┐  ┌──────────────┐  │
│  │ Expiry Scanner   │  │ Archive Mover│  │ Deletion     │  │
│  │ (daily cron)     │  │ (pre-delete) │  │ Executor     │  │
│  └──────────────────┘  └──────────────┘  └──────────────┘  │
└─────────────────────────────┬───────────────────────────────┘
                              │
┌─────────────────────────────▼───────────────────────────────┐
│                   Audit and Verification                     │
│  ┌──────────────────┐  ┌──────────────┐  ┌──────────────┐  │
│  │ Deletion Log     │  │ Verification │  │ Exception    │  │
│  │ (immutable)      │  │ Scanner      │  │ Reporter     │  │
│  └──────────────────┘  └──────────────┘  └──────────────┘  │
└─────────────────────────────────────────────────────────────┘

分散システムにおける削除パターン

パターン	説明	ユースケース	複雑さ
TTL カラム	有効期限のタイムスタンプを格納するデータベースのカラム。バックグラウンドジョブが期限切れの行を削除します	単一データベースのシステム、Redis、DynamoDB	低
イベント駆動型削除	ライフサイクルイベント（アカウントの閉鎖）により、削除コマンドをメッセージキューに送信します	マイクロサービスアーキテクチャ	中
トゥームストーン＋コンパクション	レコードを削除済みとしてマークし、バックグラウンドのコンパクションでデータを物理的に削除します	追記専用ストア、イベントソーシング	中
カスケード削除	外部キーの関係を通じて削除を伝播させます	参照整合性のあるリレーショナルデータベース	中
分散サーガ	失敗時のロールバックを伴い、複数のサービスにわたる削除を協調して実行します	ポリグロット永続化、サービス間のデータ	高
暗号シュレッディング	データを物理的に削除せず、暗号化キーを破棄してデータを読み取り不能にします	物理的な削除が現実的でないシステム（バックアップ、不変ログ）	中

リーガルホールド管理

データが訴訟、規制当局による調査、または監査手続きの対象となる場合、リーガルホールドによって自動削除が停止されます。

リーガルホールドのライフサイクル：

1. ホールドの開始 — 法務担当者が、対象範囲（データカテゴリ、日付範囲、対象者）と案件の参照情報を指定したホールド通知を発行します
2. ホールドの登録 — Retention Policy Engine がホールドを登録し、該当するレコードに対する TTL ベースの削除を上書きする免除を作成します
3. ホールドの監視 — 法務担当者が毎月レビューを行い、ホールドが引き続き必要であることを確認します
4. ホールドの解除 — 法務担当者が解除通知を発行します。Retention Policy Engine は免除を削除し、通常の保持処理を再開します
5. 削除の追いつき処理 — ホールド期間中に削除されるはずだったレコードを、現在の保持ポリシーに照らして評価し、期限切れであれば削除します

Prism Data Systems AG の実装：

ホールドパラメーター	値
ホールド対象範囲の形式	data_categories、date_range_start、date_range_end、subject_identifiers、matter_reference を指定する JSON ドキュメント
ホールドレジストリ	不変の監査証跡を備えた PostgreSQL テーブル
レビュー頻度	法務担当者が毎月、DPO が四半期ごと
更新なしでのホールドの最長期間	12 か月
ホールド解除の承認	二者承認：法務担当者 + DPO

アーカイブポリシー

3 層ストレージのライフサイクル

層	ストレージタイプ	アクセスパターン	暗号化	保持フェーズ
ホット	プライマリデータベース（PostgreSQL）	リアルタイムの読み書き	フィールドレベルの AES-256-GCM	アクティブな処理
ウォーム	オブジェクトストレージ（S3 互換、Glacier Instant Retrieval クラス）	低頻度の読み取り、書き込みなし	オブジェクトレベルの AES-256-GCM	目的達成後、削除前（法務・監査）
コールド	オフラインアーカイブ（テープ／保管庫）	要求に応じて復元（24～48 時間）	AES-256-GCM + エンベロープ暗号化	法定保持期間のみ

Prism Data Systems AG の移行ルール：

移行	トリガー	自動化
ホット → ウォーム	目的達成（例：アカウントの閉鎖）から 90 日後	日次ライフサイクルジョブ
ウォーム → コールド	ウォームの保持期間が終了し、法定保持期間が引き続き適用される	月次ライフサイクルジョブ
コールド → 削除	法定保持期間が終了し、有効なリーガルホールドがない	DPO 承認ゲートを設けた四半期ごとのライフサイクルジョブ
任意 → リーガルホールド	該当する範囲に対してリーガルホールドが登録された場合	即時停止

実装ワークフロー

1. データストアを棚卸しする — プライマリデータベース、キャッシュ、メッセージキュー、ログ、バックアップ、サードパーティとの連携を含め、個人データを保存するすべてのシステムを一覧化します。

2. 保持要件を対応付ける — データカテゴリと処理目的ごとに、目的上の必要性、法的義務、時効期間に基づいて保持期間を決定します。

3. TTL メタデータを実装する — 各データストアに、created_at、retention_trigger_event、retention_trigger_date、ttl_expiry_date、legal_hold_id など、保持に関連する列またはメタデータを追加します。

4. ライフサイクルスケジューラーをデプロイする — 毎日、期限切れレコードを検索し、有効なリーガルホールドを確認して、削除またはアーカイブへの移行を実行するバックグラウンドサービスを実装します。

5. 削除の検証を実装する — 各削除サイクルの後に検証スキャンを実行し、対象のレコードがプライマリストア、レプリカ、キャッシュからすべて削除されたことを確認します。

6. バックアップローテーションを設定する — バックアップの保持期間が、適用される最長の保持期間に一致するようにします。細粒度の削除が実用的でないバックアップメディアには、暗号学的消去を実装します。

7. 監視とアラートをデプロイする — 削除ジョブの成功率を監視し、TTL を 7 日以上超過したレコードにフラグを立て、リーガルホールドの期限切れについてアラートを出します。

主要な規制上の参照先

• GDPR 第5条第1項(e) — 保存期間の制限に関する原則
• GDPR 第13条第2項(a) — 保存期間の開示要件
• GDPR 第17条第1項(a) — データが不要になった場合の消去権
• GDPR 第25条第1項 — 設計によるデータ保護
• GDPR 前文第39項 — 保存期間の制限に関する指針
• GDPR 第25条「設計およびデフォルトによるデータ保護」に関する EDPB ガイドライン 4/2019
• スイス債務法第958f条 — 事業記録の10年間保存
• EU VAT 指令 2006/112/EC 第242条 — 請求書の保存要件