स्टोरेज लिमिटेशन 2026 में एनालिटिक्स के लिए प्रवर्तन की नई फ्रंटलाइन है

GDPR का महँगा सवाल पहले हुआ करता था क्या इसे इकट्ठा करने का आपके पास वैध आधार है। 2026 में यह बन गया यह अब भी आपके डेटाबेस में क्यों है। दो प्रवर्तन घटनाओं ने रिटेंशन को दस्तावेज़ के फ़ुटनोट से उठाकर फ्रंटलाइन पर ला खड़ा किया, और एनालिटिक्स सिस्टम ठीक उस प्रभाव-क्षेत्र में हैं।

दो फ़ैसले जिन्होंने निशाना बदल दिया

13 जनवरी 2026 को CNIL ने Free Mobile पर €27 मिलियन और Free पर €15 मिलियन का जुर्माना लगाया। ज़्यादातर रिपोर्टिंग 2024 के उस ब्रीच पर केंद्रित रही जिसमें 2.4 करोड़ सब्सक्राइबर कॉन्ट्रैक्ट उजागर हुए थे, लेकिन फ़ैसले ने अनुच्छेद 5(1)(e) — स्टोरेज लिमिटेशन — का भी सीधे हवाला दिया। Free Mobile ने दस साल से अधिक पहले रद्द किए गए 28 लाख कॉन्ट्रैक्ट का डेटा बिना किसी औचित्य के रखा हुआ था। डेटा अवैध रूप से इकट्ठा नहीं किया गया था। उसे अवैध रूप से रखा गया था।

एक महीने बाद, EDPB ने अपने 2025 के समन्वित प्रवर्तन कार्रवाई के नतीजे प्रकाशित किए। बत्तीस डेटा संरक्षण प्राधिकरणों ने इरेज़र प्रथाओं पर 764 कंट्रोलर्स का ऑडिट किया और दो प्रणालीगत विफलताएँ पाईं: आंतरिक डेटा वर्गीकरण का अभाव, और स्वयं IT सिस्टम में स्वचालित डिलीशन का अभाव। एक दस्तावेज़ीकृत रिटेंशन पॉलिसी जिसे तकनीकी रूप से कुछ भी लागू नहीं करता, उसे शमन-कारक नहीं बल्कि गंभीरता बढ़ाने वाला कारक माना गया।

संकेत स्पष्ट है। रेगुलेटर अब मान लेते हैं कि संग्रह हुआ है; वे डिलीशन का ऑडिट करते हैं।

एनालिटिक्स ही देखने की स्पष्ट जगह क्यों है

अनुच्छेद 5(1)(e) के तहत स्टोरेज लिमिटेशन कहती है कि व्यक्तिगत डेटा को पहचान-योग्य रूप में उद्देश्य की ज़रूरत से ज़्यादा समय तक नहीं रखा जाना चाहिए। ज़्यादातर एनालिटिक्स स्टैक चुपचाप इसमें विफल रहते हैं।

एक सामान्य इवेंट टेबल हर इंटरैक्शन के लिए एक रो स्टोर करती है जो किसी स्थिर आइडेंटिफ़ायर — एक cookie ID, एक डिवाइस ID, एक हैश किया हुआ ईमेल — से जुड़ी होती है, टाइमस्टैम्प के साथ और बिना किसी एक्सपायरी के। स्कीमा को इस तरह डिज़ाइन किया जाता है कि सब कुछ हमेशा के लिए रखा जाए ताकि "शायद बाद में इसे क्वेरी करना चाहें" बना रहे। यही ठीक वह एहतियातन रिटेंशन है जिस पर CNIL ने दंड लगाया।

समस्या इसलिए और बढ़ती है क्योंकि आइडेंटिफ़ायर ही वह चीज़ है जो रो को व्यक्तिगत डेटा बनाती है। जब तक user_id = a91f... को महीनों के इवेंट्स में किसी व्यक्ति से वापस जोड़ा जा सकता है, उन रोज़ में से हर एक दायरे में है, हर एक एक्सेस और इरेज़र अनुरोधों के अधीन है, और हर एक ब्रीच में एक देयता है। रिटेंशन कोई स्टोरेज लागत नहीं है। यह समय में मापा गया एक्सपोज़र है।

राइट टाइम पर मिनिमाइज़ेशन, रीड टाइम पर डिलीशन से बेहतर है

टिकाऊ समाधान कोई बेहतर cron जॉब नहीं है जो पुरानी रोज़ को छाँटता हो। यह एक डेटा मॉडल है जहाँ पहचान-योग्य रूप पहले स्थान पर कभी टिकता ही नहीं।

Monoid का आइडेंटिटी मॉडल इसी के इर्द-गिर्द बना है। एक विज़िटर को केवल एक दैनिक हैश से दर्शाया जाता है:

SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)

रॉ IP और User-Agent केवल Worker मेमोरी में उतनी देर रहते हैं जितनी उस हैश की गणना के लिए ज़रूरी है; D1 हैश स्टोर करता है, रॉ वैल्यू कभी नहीं। चूँकि तारीख एक इनपुट है, उसी विज़िटर का हैश हर आधी रात बदल जाता है। रखने के लिए कोई स्थिर क्रॉस-डे आइडेंटिफ़ायर नहीं है, इसलिए वह क्रॉस-सेशन प्रोफ़ाइल जिसे स्टोरेज लिमिटेशन निशाना बनाती है, जमा हो ही नहीं सकती — पॉलिसी से नहीं, बल्कि संरचना से।

यह राइट टाइम पर डेटा मिनिमाइज़ेशन है। आप बाद में लिंकेज नहीं मिटाते क्योंकि आपने उसे कभी लिखा ही नहीं। एक इरेज़र अनुरोध तुच्छ हो जाता है जब मिटाने के लिए कोई टिकाऊ की ही न हो।

ऐसा रिटेंशन जिसे आप वाकई साबित कर सकें

स्टोरेज लिमिटेशन को फिर भी एक बाहरी सीमा चाहिए, और एक बचाव-योग्य सीमा छोटी और प्रवर्तित होती है, लंबी और महत्वाकांक्षी नहीं। Monoid पेजव्यू डेटा को अधिकतम 730 दिनों तक ही रखता है। दो साल ट्रेंड विश्लेषण के लिए जानबूझकर तय की गई अधिकतम सीमा है, और पर्ज टेबल पर एक वास्तविक ऑपरेशन है, किसी पॉलिसी PDF में लिखी एक लाइन नहीं। EDPB का निष्कर्ष यह था कि प्रवर्तन के बिना पॉलिसियाँ ही वह खामी हैं जिसका जाँच फ़ायदा उठाती हैं; एक रिटेंशन जो वाकई निष्पादित होता है, उसे बंद कर देता है।

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

जिस भी एनालिटिक्स पर आप निर्भर हैं, उसे कैसे परखें

आपकी साइट के पीछे जो भी एनालिटिक्स हो, तीन जाँचें सीधे उससे मेल खाती हैं जो रेगुलेटर ने ऑडिट किया:

• हर उस फ़ील्ड को खोजें जो किसी रिकॉर्ड को समय के साथ किसी व्यक्ति से जोड़ता है। एक स्थिर user ID, एक persistent cookie वैल्यू, एक रॉ IP, एक fingerprint। हर एक किसी इवेंट लॉग को एक रखी हुई प्रोफ़ाइल में बदल देता है — इसलिए पूछें कि जो एनालिटिक्स आप इस्तेमाल करते हैं, वह इनमें से कोई भी संग्रहित करता है या नहीं।
• पूछें कि रिटेंशन कब लागू होता है — इंजेशन पर या किसी त्रैमासिक समीक्षा में। डेटा लिखे जाते समय होने वाली मिनिमाइज़ेशन उस डिलीशन जॉब से बेहतर है जिसे किसी को चलाना याद रखना पड़ता है। सबसे मज़बूत उत्तर वह मॉडल है जहाँ पहचान-योग्य रूप पहले स्थान पर कभी संग्रहित ही नहीं हुआ।
• पूछें कि क्या डिलीशन प्रदर्शन-योग्य है। अगर कोई वेंडर ऐसी कठोर रिटेंशन सीमा की ओर इशारा नहीं कर सकता जो वाकई निष्पादित होती है, तो उसके पास एक पॉलिसी है, कंट्रोल नहीं — और EDPB की जाँच ने अभी-अभी बता दिया कि इन दोनों में से किस पर जुर्माना लगता है।

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

स्रोत

• GDPR अनुच्छेद 5 — व्यक्तिगत डेटा प्रसंस्करण के सिद्धांत (स्टोरेज लिमिटेशन)
• विनियमन (EU) 2016/679 (GDPR), EUR-Lex आधिकारिक पाठ
• EDPB — मिटाने के अधिकार के कार्यान्वयन पर 2025 समन्वित प्रवर्तन कार्रवाई
• Google Analytics 4 — डेटा रिटेंशन