EDPB का 2026 प्रवर्तन लक्ष्य आपका privacy notice है

दो साल से महंगा GDPR सवाल बदलता रहा है। पहले regulators यह audit करते थे कि आपके पास lawful basis था या नहीं, फिर यह कि आपने data समय पर delete किया या नहीं। 19 मार्च 2026 को European Data Protection Board ने अगली जांच को एक तीसरे लक्ष्य पर केंद्रित किया: कि आप जो इकट्ठा करते हैं उसके बारे में आपका privacy notice ईमानदार है या नहीं।

2026 coordinated action किसका audit करती है

EDPB का Coordinated Enforcement Framework (CEF) हर साल पूरे bloc में एक साझा theme चलाता है। 2025 की action ने right to erasure की जांच की। 2026 की action — पाँचवीं — GDPR के Articles 12, 13, और 14 के तहत transparency और information obligations की जांच करती है।

पच्चीस data protection authorities इसमें भाग ले रही हैं। उनकी घोषणा method के बारे में बेबाक है: भाग लेने वाली DPAs "जल्द ही पूरे यूरोप में विभिन्न क्षेत्रों के controllers से संपर्क करेंगी, या तो enforcement actions के ज़रिए या fact-finding exercises के ज़रिए।" निष्कर्षों को 2026 की दूसरी छमाही में एक समेकित EDPB report में जोड़ा जाएगा, साथ ही "राष्ट्रीय और EU दोनों स्तरों पर targeted follow-ups" होंगे।

यह guidance नहीं है। यह इस बात का सबूत मांगने वाला एक coordinated अनुरोध है कि आपकी site पर मौजूद document आपके database में मौजूद data से मेल खाता है।

Article 13 असल में आपको क्या disclose करने के लिए कहता है

right to be informed इस पैराग्राफ से पूरा नहीं होता कि "हम आपकी privacy को महत्व देते हैं।" Article 13 — जो तब लागू होता है जब आप visitor से सीधे data इकट्ठा करते हैं — यह सूचीबद्ध करता है कि एक notice को collection के क्षण पर क्या बताना चाहिए:

• controller की पहचान और संपर्क विवरण।
• processing के purposes और हर एक के लिए legal basis।
• data के recipients या recipients की श्रेणियाँ।
• किसी third country को कोई transfer और उसके लिए safeguards।
• retention period, या उसे तय करने के लिए इस्तेमाल किए गए criteria।
• data subject rights: access, rectification, erasure, restriction, objection, portability।
• automated decision-making का अस्तित्व, जिसमें profiling शामिल है, और इसमें शामिल logic के बारे में सार्थक जानकारी।

हर clause आपके stack के किसी तथ्य से जुड़ता है। एक notice तभी सटीक है जब हर disclosure सच हो। fact-finding exercise ठीक यही जांचती है — यह नहीं कि notice मौजूद है या नहीं, बल्कि यह कि वह हकीकत का वर्णन करता है या नहीं।

surveillance analytics notice को नाज़ुक क्यों बना देता है

एक सामान्य analytics integration को इस सूची से गुज़ारें और disclosures कई गुना बढ़ जाते हैं। cross-site identifiers वाला एक behavioral tag मतलब आपके पास नाम बताने के लिए recipients हैं — vendor, उसके ad partners, उसका measurement network। इसका आमतौर पर मतलब एक third-country transfer घोषित करना और सुरक्षित करना है। एक stable identifier जो महीनों तक किसी visitor का पीछा करता है, वह profiling है, जो automated-decision-making clause को खींच लाता है। retention period वही है जो vendor की default है, जिसे अब आपको जानना और सही-सही बताना होगा।

इनमें से हर एक एक वाक्य है जो गलत हो सकता है। जैसे ही vendor कोई sub-processor जोड़ता है, region बदलता है, या retention बढ़ाता है, notice भटक जाता है — और आपको शायद ही कभी पता चलता है। एक transparency audit के तहत, recipients या retention को कम बताने वाला notice typo नहीं है। यह वही उल्लंघन है जिसे सामने लाने के लिए CEF बना है।

एक छोटा notice ही बचाव योग्य होता है

transparency audit पास करने का सबसे सस्ता तरीका है disclose करने के लिए बहुत कम होना। यह एक data-model गुण है, copywriting का गुण नहीं।

एक cookie-free tracker Article 13 notice के analytics section को कुछ ईमानदार पंक्तियों में समेट देता है। कोई third-party recipients नहीं हैं क्योंकि कुछ भी साझा नहीं किया जाता। कोई profiling नहीं है क्योंकि कोई identifier टिकता ही नहीं। Visitor identity edge पर memory में गणना किया गया one-way daily hash है:

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

raw IP और User-Agent का इस्तेमाल केवल उस digest की गणना के लिए होता है और इन्हें कभी लिखा नहीं जाता; D1 hash store करता है, inputs नहीं। चूंकि date एक input है, hash हर आधी रात घूम जाता है, इसलिए वर्णन करने के लिए कोई cross-session profile नहीं होती। retention एक कठोर, बताई जा सकने वाली सीमा है — pageviews 730 दिन बाद purge कर दिए जाते हैं — न कि कोई vendor default जिसे आपको ढूंढना पड़े।

परिणामस्वरूप जो disclosure बनती है वह छोटी है क्योंकि processing छोटी है। यह कहती है: हम aggregate pageviews गिनते हैं, edge पर country और coarse device type निकालते हैं, किसी के साथ साझा नहीं करते, कोई profile नहीं बनाते, और data को अधिकतम दो साल रखते हैं। हर clause schema के विरुद्ध सत्यापन योग्य है।

उसी exercise का Article 30 वाला आधा हिस्सा

visitor के लिए transparency (Articles 12–14) का एक आंतरिक जुड़वां है: Article 30 records of processing activities, वह document जो कोई authority सबसे पहले मांगती है। इसे purposes, recipients, transfers, और retention सूचीबद्ध करने चाहिए — वही तथ्य जो public notice में हैं, controller की ओर से।

जब ये दोनों असहमत होते हैं, तो यह अंतर ही finding बन जाता है। एक stack जो कोई personal identifier store नहीं करता और कुछ भी साझा नहीं करता, दोनों documents को संरेखित रखता है, क्योंकि किसी भी ओर record करने के लिए लगभग कुछ नहीं होता।

एक privacy notice आपके data model के बारे में एक वादा है। 2026 की जांच यह जांचती है कि वादा सच है या नहीं। सबसे कम जोखिम वाला वादा वह है जिसे आप बिना सोचे निभा सकते हैं — क्योंकि आपने वह चीज़ कभी इकट्ठा ही नहीं की जिसे अन्यथा आपको समझाना पड़ता।

Sources

• EDPB launches the Coordinated Enforcement Action for 2026 on transparency and information obligations
• Coordinated Enforcement Framework: EDPB selects topic for 2026
• GDPR Article 13 — Information to be provided where personal data are collected from the data subject
• GDPR Article 30 — Records of processing activities
• ICO — Right to be informed