Data Retention Policies and Automation: Keep What You Need, Delete What You Must

کمپنیاں قانونی طور پر اپنی ضرورت سے اوسطاً 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 = ''anonymized@removed.com'', 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)) کی خلاف ورزی کرتا ہے۔ نگران حکام 20 ملین یورو یا عالمی سالانہ کاروبار کے 4% تک کے جرمانے جاری کر سکتے ہیں۔ زیادہ عملی طور پر، اضافی ڈیٹا کی خلاف ورزی میں آپ کی نمائش میں اضافہ ہوتا ہے --- آپ اس ڈیٹا کے ذمہ دار ہیں جو آپ کے پاس نہیں ہونا چاہیے تھا۔

ہم بیک اپ کاپیوں کی برقراری کو کیسے سنبھالتے ہیں؟

بیک اپ برقرار رکھنے کو پیچیدہ بنا دیتے ہیں کیونکہ ان میں وقت کے مخصوص پوائنٹس پر ڈیٹا کے اسنیپ شاٹس ہوتے ہیں۔ اختیارات: (1) آپ کے سب سے طویل برقرار رکھنے کی مدت کے ساتھ منسلک ایک شیڈول پر بیک اپ کو گھمائیں، (2) بیک اپ کو انکرپٹ کریں اور برقراری کی میعاد ختم ہونے پر خفیہ کاری کی کلید کو تباہ کر دیں ("کرپٹو-شریڈنگ")، (3) یہ قبول کریں کہ بیک اپ میں میعاد ختم ہونے والا ڈیٹا ہو سکتا ہے لیکن اسے معاوضہ دینے والے کنٹرول کے ساتھ تکنیکی حد کے طور پر دستاویز کریں۔

ہم Odoo میں برقراری کو کیسے نافذ کرتے ہیں؟

Odoo میں بلٹ ان ریٹینشن آٹومیشن نہیں ہے۔ اس کو استعمال کرتے ہوئے لاگو کریں: (1) طے شدہ ایکشنز (کرون جابز) جو پرانے ریکارڈز کو محفوظ یا گمنام کرتے ہیں، (2) اپنی مرضی کے ماڈیولز جو مخصوص ماڈلز پر برقراری کے قوانین کو نافذ کرتے ہیں، (3) بلک آپریشنز کے لیے ڈیٹا بیس کی سطح کے افعال۔ ECOSIRE خودکار ڈیٹا لائف سائیکل مینجمنٹ کے لیے Odoo حسب ضرورت فراہم کرتا ہے۔

---

آگے کیا آتا ہے۔

ڈیٹا کو برقرار رکھنا مکمل گورننس پروگرام کا ایک جزو ہے۔ اسے نئے سسٹمز کے لیے پرائیویسی بذریعہ ڈیزائن، HR ڈیٹا کے لیے ملازمین ڈیٹا پرائیویسی اور تھرڈ پارٹی پروسیسرز کے لیے وینڈر کنٹریکٹ مینجمنٹ کے ساتھ جوڑیں۔

ڈیٹا برقرار رکھنے کی پالیسی کے ڈیزائن اور نفاذ سے متعلق مشاورت کے لیے ECOSIRE سے رابطہ کریں۔

---

ECOSIRE کے ذریعہ شائع کیا گیا -- کاروباروں کو اس کے پورے لائف سائیکل میں ڈیٹا کا نظم کرنے میں مدد کرنا۔