データ保持ポリシーと自動化: 必要なものを保持し、必要なものを削除

企業は法的に必要なデータよりも平均 33% 多くのデータを保持しており、ストレージ コストと侵害の危険性の両方が増大しています。 データ保持には、法的コンプライアンス、コストの最適化、セキュリティが集約されます。保持しすぎると攻撃対象領域が増加します。保持額が少なすぎると、訴訟ホールドの要件に違反します。

このガイドでは、保持ポリシーの設計、データ タイプ別の法的要件、および手動介入なしで組織のコンプライアンスを維持するための自動適用について説明します。

重要なポイント

• 保存期間は、法的要件、ビジネス ニーズ、プライバシー義務の交差点によって決定されます。
• 自動化された強制が不可欠 --- 手動削除プロセスの失敗率は 40%
• 同じシステム内のデータ型が異なると、保持期間も異なる場合があります
• 訴訟が予想される場合、訴訟ホールドは標準の保持ポリシーをオーバーライドする必要がある

---

規制による保存期間要件

最小保存要件

国別の税金留保

---

保持スケジュールの設計

ステップ 1: インベントリ データ カテゴリ

ステップ 2: 保存期間の割り当て

カテゴリごとに、次の階層を使用して保存期間を決定します。

1. 法的最低限度: 法律では何を守る必要がありますか?
2. 法的な最大値: 法律では何を削除する必要がありますか? (GDPR目的の制限)
3. ビジネス上の必要性: 実際にどのくらいの期間必要ですか?
4. リスク許容度: 保存する場合と削除する場合のコストはどれくらいですか?

保存期間は次のとおりです: MAX (法定最小値、ビジネス上の必要性) ただし、法定最大値 (該当する場合) を超えてはなりません。

ステップ 3: 廃棄アクションの定義

---

自動保存の強制

PostgreSQL の実装

-- Retention policy table
CREATE TABLE retention_policies (
    id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
    table_name VARCHAR(100) NOT NULL,
    date_column VARCHAR(100) NOT NULL,
    retention_days INTEGER NOT NULL,
    action VARCHAR(20) NOT NULL, -- 'DELETE', 'ANONYMIZE', 'ARCHIVE'
    condition TEXT, -- Optional WHERE clause
    enabled BOOLEAN DEFAULT TRUE,
    last_run TIMESTAMP,
    records_affected INTEGER DEFAULT 0
);

-- Insert policies
INSERT INTO retention_policies (table_name, date_column, retention_days, action, condition) VALUES
('support_tickets', 'closed_at', 1095, 'ANONYMIZE', 'status = ''closed'''),
('recruitment_candidates', 'applied_at', 730, 'DELETE', 'status != ''hired'''),
('session_logs', 'created_at', 90, 'DELETE', NULL),
('newsletter_unsubscribed', 'unsubscribed_at', 365, 'DELETE', NULL),
('audit_logs', 'created_at', 2555, 'ARCHIVE', NULL);

-- Enforcement function
CREATE OR REPLACE FUNCTION enforce_retention_policies()
RETURNS TABLE(policy_id UUID, table_name TEXT, records_affected BIGINT) AS $$
DECLARE
    policy RECORD;
    affected BIGINT;
    query TEXT;
BEGIN
    FOR policy IN
        SELECT * FROM retention_policies WHERE enabled = TRUE
    LOOP
        IF policy.action = 'DELETE' THEN
            query := format(
                'DELETE FROM %I WHERE %I < NOW() - INTERVAL ''%s days''',
                policy.table_name, policy.date_column, policy.retention_days
            );
            IF policy.condition IS NOT NULL THEN
                query := query || ' AND ' || policy.condition;
            END IF;
        ELSIF policy.action = 'ANONYMIZE' THEN
            -- Anonymization requires table-specific logic
            -- This is a simplified example
            query := format(
                'UPDATE %I SET email = ''[email protected]'', name = ''Anonymized'' WHERE %I < NOW() - INTERVAL ''%s days''',
                policy.table_name, policy.date_column, policy.retention_days
            );
            IF policy.condition IS NOT NULL THEN
                query := query || ' AND ' || policy.condition;
            END IF;
        END IF;

        EXECUTE query;
        GET DIAGNOSTICS affected = ROW_COUNT;

        UPDATE retention_policies
        SET last_run = NOW(), records_affected = affected
        WHERE id = policy.id;

        RETURN QUERY SELECT policy.id, policy.table_name::TEXT, affected;
    END LOOP;
END;
$$ LANGUAGE plpgsql;

スケジュール設定

# Run retention enforcement daily at 3 AM
# /etc/cron.d/retention-enforcement
0 3 * * * postgres psql -d ecosire -c "SELECT * FROM enforce_retention_policies();" >> /var/log/retention-enforcement.log 2>&1

---

訴訟ホールド

訴訟ホールドが適用される場合

訴訟ホールドは、訴訟が予想される場合、係争中、または進行中の場合に、通常の保持ポリシーを一時停止します。関連する可能性のあるデータはすべて、保持スケジュールに関係なく保存する必要があります。

実装

-- Legal hold table
CREATE TABLE legal_holds (
    id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
    matter_name VARCHAR(255) NOT NULL,
    description TEXT,
    custodians TEXT[], -- Users whose data is held
    tables_affected TEXT[], -- Tables where retention is suspended
    created_at TIMESTAMP DEFAULT NOW(),
    released_at TIMESTAMP,
    created_by UUID REFERENCES users(id)
);

-- Modified retention enforcement respects legal holds
CREATE OR REPLACE FUNCTION enforce_retention_with_holds()
RETURNS void AS $$
BEGIN
    -- Skip tables under active legal hold
    DELETE FROM session_logs
    WHERE created_at < NOW() - INTERVAL '90 days'
    AND 'session_logs' NOT IN (
        SELECT UNNEST(tables_affected)
        FROM legal_holds
        WHERE released_at IS NULL
    );
END;
$$ LANGUAGE plpgsql;

---

検証とコンプライアンス

毎月の保持監査

• すべての保持ポリシーが文書化されており、最新のものです。
• 自動適用は正常に実行されました (ログを確認してください)
• 保存期間を超えたデータは存在しません（サンプルチェック）
• 訴訟ホールドは係属中のすべての訴訟に対して有効です
• 新しいデータ カテゴリに保存期間が割り当てられました
• サードパーティのプロセッサは保持要件に準拠しています

---

よくある質問

GDPR に基づいて必要以上にデータを保持するとどうなりますか?

必要な保存期間を超えて個人データを保存することは、GDPR の保存制限原則 (第 5 条(1)(e))に違反します。監督当局は最大2,000万ユーロまたは世界の年間売上高の4％の罰金を課すことができる。より現実的には、過剰なデータにより侵害の危険が増大します。所有すべきではなかったデータに対して責任を負うことになります。

バックアップ コピーの保持はどのように処理すればよいですか?

バックアップには特定の時点のデータのスナップショットが含まれるため、保存が複雑になります。オプション: (1) 最長の保存期間に合わせたスケジュールでバックアップをローテーションする、(2) バックアップを暗号化し、保存期限が切れたら暗号化キーを破棄する (「暗号シュレッディング」)、(3) バックアップに期限切れのデータが含まれる可能性があることを受け入れるが、これを補償制御による技術的制限として文書化します。

Odoo で保持を実装するにはどうすればよいですか?

Odoo には保存の自動化が組み込まれていません。 (1) 古いレコードをアーカイブまたは匿名化するスケジュールされたアクション (cron ジョブ)、(2) 特定のモデルに保持ルールを強制するカスタム モジュール、(3) 一括操作のためのデータベース レベルの関数を使用して実装します。 ECOSIRE は、自動化されたデータ ライフサイクル管理のための Odoo カスタマイズ を提供します。

---

次に何が起こるか

データ保持は、完全なガバナンス プログラムのコンポーネントの 1 つです。新しいシステムの場合は プライバシー バイ デザイン、人事データの場合は 従業員データのプライバシー、サードパーティ プロセッサの場合は ベンダー契約管理 と組み合わせます。

データ保持ポリシーの設計と実装に関するコンサルティングについては、ECOSIRE にお問い合わせください。

---

ECOSIRE が発行 -- 企業がライフサイクル全体を通じてデータを管理できるように支援します。