डेटा रिटेंशन और डिलीशन

डेटा को हमेशा के लिए रखना एक देनदारी है। प्राइवेसी कानून कहता है कि जब डेटा की ज़रूरत न रहे, तो उसे डिलीट करें। इस चैप्टर में रिटेंशन पॉलिसी (डेटा कितने समय तक रखें) और डिलीशन प्रोसेस (यूज़र की डिलीशन रिक्वेस्ट और सिस्टम की सफ़ाई कैसे संभालें) बताए गए हैं।

डेटा रिटेंशन पॉलिसी क्यों मायने रखती हैं

कानूनी ज़रूरत

GDPR और ऐसे कानून डेटा रिटेंशन पॉलिसी माँगते हैं। अपना बताया गया मक़सद पूरा होने के बाद आपको डेटा डिलीट करना होगा। "बस कभी काम आ जाए, इसलिए हमेशा रखना" डेटा मिनिमाइज़ेशन के सिद्धांतों का उल्लंघन है और जुर्माने की वजह है।

संचालन का फ़ायदा

पुराना डेटा कम काम का होता है। 2 साल पुराना इवेंट शायद ही आज के फ़ैसलों पर असर डालता है। पुराना डेटा डिलीट करने से स्टोरेज का खर्च घटता है, बैकअप सरल होते हैं, और ब्रीच होने पर जोखिम घटता है (सामने आने वाला डेटासेट छोटा होता है)।

यूज़र की उम्मीदें

यूज़र उम्मीद करते हैं कि जब उनके डेटा की ज़रूरत न रहे, तो आप उसे डिलीट कर देंगे। क्लाउड पर चलने वाले टू-डू ऐप को आपका अकाउंट बंद होने पर आपके टास्क डिलीट कर देने चाहिए, हमेशा के लिए नहीं रखने चाहिए। साफ़ डिलीशन पॉलिसी से भरोसा बनता है।

रिटेंशन पॉलिसी तय करना

कौन सा डेटा? कितने समय?

अलग-अलग तरह के डेटा की रिटेंशन ज़रूरतें अलग होती हैं:

एनालिटिक्स इवेंट: 12 महीने आम है। एक साल बाद पुराने इवेंट का शायद ही एनालिसिस होता है। अगर ज़्यादा चाहिए, तो 24 महीने ठीक है। हमेशा के लिए न रखें।

ग्राहक का अकाउंट डेटा: अकाउंट चालू रहने तक रखें। अकाउंट बंद होने के 90 दिन बाद डिलीट करें (वापस चालू करने का समय मिलता है)। हमेशा के लिए न रखें।

सपोर्ट टिकट: 2-3 साल रखें (विवादों की क़ानूनी समय-सीमा)। फिर डिलीट करें।

फ़ाइनेंशियल रिकॉर्ड: 7 साल रखें (टैक्स/कानूनी ज़रूरतें)। फिर डिलीट करें।

मार्केटिंग लिस्ट: ग्राहक के लिस्ट में रहने तक रखें। अनसब्सक्राइब के 30 दिन बाद डिलीट करें।

ख़ास मामलों के लिए लंबा रिटेंशन

कुछ डेटा को ज़्यादा समय रखना पड़ सकता है: फ़्रॉड डिटेक्शन (ऑडिट ट्रेल के लिए), कानूनी विवाद (समाधान तक), रेगुलेटरी कंप्लायंस (इंडस्ट्री के हिसाब से अलग)। ये अपवाद हैं। डिफ़ॉल्ट यह होना चाहिए: काम का न रहते ही डिलीट कर दें।

अपनी पॉलिसी को लिखकर रखना

अपनी रिटेंशन पॉलिसी लिखें: कौन से डेटा प्रकार, हर एक का रिटेंशन समय, रिटेंशन का कानूनी आधार। इसे अपनी प्राइवेसी पॉलिसी में यूज़र के लिए उपलब्ध कराएँ। "हम आपका डेटा X महीने रखते हैं, फिर डिलीट कर देते हैं।" पारदर्शिता से भरोसा बनता है।

ऑटोमैटिक डिलीशन लागू करना

शेड्यूल्ड डिलीशन जॉब

ऐसे ऑटोमैटिक जॉब सेट करें जो शेड्यूल पर (मासिक, तिमाही) चलें और रिटेंशन की तारीख़ पार कर चुका डेटा डिलीट करें। उदाहरण: एक जॉब जो 12 महीने से पुराने सभी एनालिटिक्स इवेंट डिलीट करे। इसे अपने-आप चलाएँ ताकि डिलीशन हाथ से न हो और भूला न जाए।

इवेंट से शुरू होने वाला डिलीशन

कुछ डिलीशन किसी इवेंट से शुरू होते हैं: जब यूज़र अपना अकाउंट बंद करे, तो उसका डेटा डिलीट करें। जब यूज़र अनसब्सक्राइब करे, तो उसका ईमेल डिलीट करें। ऐसे ऑटोमैटिक वर्कफ़्लो सेट करें जो कोई ख़ास इवेंट होने पर डिलीट करें।

डिलीशन को लॉग करना

लॉग करें कि डेटा कब डिलीट हुआ (कौन सा डेटा, कब, क्यों)। इससे ऑडिट ट्रेल बनता है। अगर रेगुलेटर पूछें कि कुछ डेटा क्यों नहीं है, तो आप दिखा सकते हैं कि वह पॉलिसी के हिसाब से डिलीट हुआ, छिपाया नहीं गया।

यूज़र की डिलीशन रिक्वेस्ट संभालना

भुला दिए जाने का अधिकार

GDPR लोगों को "भुला दिए जाने का अधिकार" देता है। यूज़र अपने पर्सनल डेटा के डिलीशन की रिक्वेस्ट कर सकते हैं। आपके पास पालन के लिए 30 दिन हैं (कानूनी दायित्वों के अपवाद के साथ)। इसका मतलब है कि आपके पास रिक्वेस्ट पर यूज़र का डेटा डिलीट करने की क्षमता होनी चाहिए।

डिलीशन वर्कफ़्लो लागू करना

स्टेप 1: रिक्वेस्ट लें। यूज़र सपोर्ट फ़ॉर्म या अकाउंट सेटिंग से डिलीशन रिक्वेस्ट भेजता है।

स्टेप 2: पहचान जाँचें। पक्का करें कि रिक्वेस्ट अकाउंट के मालिक की है (फ़र्ज़ी रिक्वेस्ट नहीं)।

स्टेप 3: डेटा पहचानें। इस यूज़र से जुड़ा सारा डेटा खोजें: अकाउंट, एनालिटिक्स इवेंट, सपोर्ट टिकट, ईमेल लिस्ट, बैकअप।

स्टेप 4: डिलीट करें। चालू सिस्टम और बैकअप से हटाएँ। यूज़र को लिखित में डिलीशन की पुष्टि दें।

स्टेप 5: लॉग करें। डिलीशन को दर्ज करें: किसने माँगा, कब, क्या डिलीट हुआ।

डिलीशन के अपवाद

आपको डिलीट करना ज़रूरी नहीं अगर: डेटा रखना आपकी कानूनी बाध्यता है (टैक्स रिकॉर्ड, कोर्ट के आदेश), आपको उसकी ज़रूरत किसी बताए गए मक़सद के लिए है जो अभी पूरा हो रहा है, या यूज़र ने डिलीशन रिक्वेस्ट के बाद आगे की प्रोसेसिंग के लिए कंसेंट दी। लेकिन ये अपवाद हैं। रिक्वेस्ट आने पर डिलीट करना ही डिफ़ॉल्ट है।

लागू करने की चुनौतियाँ

बिखरा हुआ डेटा

यूज़र का डेटा अक्सर कई सिस्टम में फैला होता है: चालू डेटाबेस, बैकअप, थर्ड-पार्टी सर्विस (एनालिटिक्स वेंडर, ईमेल प्रोवाइडर), कर्मचारियों के लैपटॉप। डिलीट करने के लिए सारा डेटा ढूँढना जटिल है। समाधान: डेटा इन्वेंटरी रखें। जानें कि यूज़र का डेटा कहाँ है। वेंडर एग्रीमेंट में डिलीशन की शर्तें शामिल करें।

बैकअप रिटेंशन

चालू सिस्टम से डिलीट होने के बाद भी बैकअप में यूज़र का डेटा रहता है। आप बैकअप कितने समय तक रखते हैं? शायद आप 3 साल पुराने बैकअप से रोज़ रीस्टोर नहीं करते, लेकिन कानूनी होल्ड के कारण उन्हें रखना पड़ सकता है। साफ़ रहें: बैकअप चालू डेटा से ज़्यादा समय रखे जा सकते हैं, लेकिन उन्हें भी आख़िर में डिलीट करना होगा।

अनाम डेटा

सचमुच का अनाम डेटा डिलीशन के अधिकारों में नहीं आता (वह पर्सनल डेटा नहीं है)। लेकिन ज़्यादातर "अनाम" डेटा असल में एग्रीगेट या सूडोनिमाइज़्ड (वापस पहचाना जा सकने वाला) होता है। अगर आप उसकी फिर से पहचान कर सकते हैं, तो वह पर्सनल डेटा है और रिक्वेस्ट पर डिलीट करना होगा। समझें कि आप असल में क्या स्टोर कर रहे हैं।

प्राइवेसी बाय डिज़ाइन: आर्किटेक्चर में डिलीशन

सिस्टम को शुरू से डिलीशन को ध्यान में रखकर डिज़ाइन करें। ऐसे डेटा स्ट्रक्चर इस्तेमाल करें जिनसे डिलीशन कुशल हो। अलग रिटेंशन ज़रूरतों वाले डेटा प्रकार आपस में न मिलाएँ। यूज़र का डेटा खोजना और डिलीट करना आसान बनाएँ। अगर आप डिलीशन की क्षमता शुरू में ही बना लेते हैं, तो आगे कंप्लायंस सरल हो जाता है।