Veri Saklama Politikaları ve Otomasyon: İhtiyacınız Olanı Tutun, İhtiyacınız Olanı Silin

Şirketler yasal olarak ihtiyaç duyduklarından ortalama %33 daha fazla veri saklıyor, bu da hem depolama maliyetlerini hem de ihlal riskini artırıyor. Veri saklama, yasal uyumluluk, maliyet optimizasyonu ve güvenliğin birleştiği yerdir. Çok fazla tutarsanız saldırı yüzeyinizi artırırsınız. Çok azını elinizde tutarsanız yasal bekletme gerekliliklerini ihlal etmiş olursunuz.

Bu kılavuz, saklama politikası tasarımını, veri türüne göre yasal gereklilikleri ve kuruluşunuzun manuel müdahaleye gerek kalmadan uyumlu kalmasını sağlayan otomatik yaptırımı kapsar.

Önemli Çıkarımlar

• Saklama süreleri yasal gereklilikler, iş ihtiyaçları ve gizlilik yükümlülüklerinin kesişimine göre belirlenir
• Otomatik yaptırım önemlidir --- manuel silme işlemlerinin başarısızlık oranı %40'tır
• Aynı sistemdeki farklı veri türlerinin saklama süreleri farklı olabilir
• Davanın beklendiği durumlarda yasal saklama, standart saklama politikalarını geçersiz kılmalıdır

---

Düzenlemeye Göre Saklama Süresi Gereksinimleri

Minimum Saklama Gereksinimleri

Ülkeye Özel Vergi Saklama

---

Saklama Planı Tasarlama

Adım 1: Envanter Veri Kategorileri

2. Adım: Saklama Sürelerini Belirleyin

Her kategori için bu hiyerarşiyi kullanarak saklama süresini belirleyin:

1. Yasal minimum: Yasalar neye uymanızı gerektiriyor?
2. Yasal maksimum: Yasa neyi silmenizi gerektiriyor? (GDPR amacı sınırlaması)
3. İş ihtiyacı: Aslında buna ne kadar süreliğine ihtiyacınız var?
4. Risk toleransı: Saklamanın ve silmenin maliyeti nedir?

The retention period is: MAX(legal minimum, business need) but NOT LONGER THAN legal maximum (if applicable).

Adım 3: İmha Eylemlerini Tanımlayın

---

Otomatik Saklama Uygulaması

PostgreSQL Uygulaması

-- 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;

Planlama

# 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

---

Yasal Bekletmeler

Hukuki Durdurma Uygulandığında

Davanın beklendiği, beklemede veya devam ettiği durumlarda, yasal bekletme normal saklama politikalarını askıya alır. Potansiyel olarak ilgili tüm veriler, saklama programlarına bakılmaksızın korunmalıdır.

Uygulama

-- 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;

---

Doğrulama ve Uyumluluk

Aylık Saklama Denetimi

• Tüm saklama politikaları belgelenmiştir ve günceldir
• Otomatik yaptırım başarıyla çalıştırıldı (günlükleri kontrol edin)
• Saklama süresinin ötesinde veri mevcut değil (örnek kontrolü)
• Devam eden tüm davalar için yasal bekletmeler etkin
• Yeni veri kategorilerine saklama süreleri atandı
• Üçüncü taraf işleyiciler saklama gerekliliklerine uygundur

---

Sıkça Sorulan Sorular

Verileri GDPR kapsamında gerekenden daha uzun süre saklarsak ne olur?

Kişisel verilerin gerekli saklama süresinin ötesinde saklanması, GDPR'nin depolama sınırlama ilkesini ihlal eder (Madde 5(1)(e)). Denetleyici otoriteler 20 milyon Euro'ya kadar veya küresel yıllık cironun %4'üne kadar para cezası verebilir. Daha pratik olarak, fazla veri, ihlale maruz kalma olasılığınızı artırır; sahip olmamanız gereken verilerden siz sorumlusunuz.

Yedek kopyaların saklanmasını nasıl gerçekleştireceğiz?

Yedeklemeler, belirli zaman noktalarındaki verilerin anlık görüntülerini içerdikleri için saklamayı karmaşık hale getirir. Seçenekler: (1) yedeklemeleri en uzun saklama sürenize uygun bir programa göre dönüşümlü yapın, (2) yedeklemeleri şifreleyin ve saklama süresi dolduğunda şifreleme anahtarını yok edin ("kripto parçalama"), (3) yedeklemelerin süresi dolmuş veriler içerebileceğini kabul edin ancak bunu telafi edici kontrollerle teknik bir sınırlama olarak belgeleyin.

Odoo'da saklamayı nasıl uygularız?

Odoo'nun yerleşik saklama otomasyonu yoktur. Bunu kullanarak uygulayın: (1) eski kayıtları arşivleyen veya anonimleştiren zamanlanmış eylemler (cron işleri), (2) belirli modellerde saklama kurallarını uygulayan özel modüller, (3) toplu işlemler için veritabanı düzeyinde işlevler. ECOSIRE, otomatik veri yaşam döngüsü yönetimi için Odoo özelleştirmesi sağlar.

---

Sırada Ne Var?

Veri saklama, eksiksiz bir yönetişim programının bir bileşenidir. Yeni sistemler için tasarım gereği gizlilik, İK verileri için çalışan veri gizliliği ve üçüncü taraf işleyiciler için satıcı sözleşme yönetimi ile birleştirin.

Veri saklama politikası tasarımı ve uygulama danışmanlığı için ECOSIRE ile iletişime geçin.

---

ECOSIRE tarafından yayınlandı - işletmelerin verileri tüm yaşam döngüsü boyunca yönetmelerine yardımcı olur.