साझा WiFi ऑपरेटरों के लिए GDPR डेटा रिटेंशन: आप गेस्ट लॉगिन डेटा और नेटवर्क लॉग कितने समय तक रख सकते हैं

GDPR WiFi डेटा के लिए कोई निश्चित प्रतिधारण (retention) अवधि तय नहीं करता है। Article 5(1)(e) आपको व्यक्तिगत डेटा केवल तब तक रखने की अनुमति देता है जब तक कि प्रत्येक उद्देश्य के लिए इसकी आवश्यकता होती है। एक बचाव योग्य समय-सीमा यह है - कनेक्शन मेटाडेटा 30-90 दिनों के लिए, व्यक्तिगत स्थान का पता 30 दिनों के लिए और दुरुपयोग लॉग 365 दिनों के लिए। Investigatory Powers Act 2016 केवल तभी 12 महीनों तक का कर्तव्य जोड़ता है यदि आपके पास प्रतिधारण नोटिस है।

एक साझा WiFi ऑपरेटर के लिए GDPR डेटा प्रतिधारण का क्या अर्थ है?

GDPR का Article 5(1)(e) भंडारण सीमा का सिद्धांत (storage limitation principle) है। यह आपको पहचाने जाने योग्य रूप में व्यक्तिगत डेटा को उद्देश्य की आवश्यकता से अधिक समय तक न रखने की अनुमति देता है। यह दिनों की कोई संख्या निर्धारित नहीं करता है। आप अवधि निर्धारित करते हैं, इसका कारण दस्तावेजित करते हैं, और अनुसूची के अनुसार डेटा को हटाते हैं या उसका नाम छिपाते हैं (anonymise करते हैं)। यह शब्दावली UK GDPR और EU GDPR में समान है।

एक नाम वाले लॉगिन नेटवर्क पर, आपकी प्रणाली द्वारा दर्ज की जाने वाली लगभग हर चीज व्यक्तिगत डेटा होती है। एक बार जब आप इसे स्प्लैश पेज लॉगिन से जोड़ते हैं, तो एक IP address, MAC address या सत्र टाइमस्टैम्प किसी व्यक्ति की पहचान करता है। Recital 30 ठीक इसी कारण से IP addresses और समान ऑनलाइन पहचानकर्ताओं का नाम लेता है।

भंडारण सीमा Article 5(1)(c) में डेटा न्यूनीकरण (data minimisation) और Article 5(2) में जवाबदेही (accountability) के साथ काम करती है। जवाबदेही का अर्थ है अपना काम दिखाना। आपको एक लिखित प्रतिधारण अनुसूची, प्रत्येक डेटा श्रेणी के लिए एक कानूनी आधार और इस बात के प्रमाण की आवश्यकता है कि डेटा वास्तव में हटाया जा रहा है।

एक एकल स्थान की तुलना में साझा नेटवर्क पर प्रतिधारण अधिक कठिन क्यों है?

Hotels और Retail जैसे क्षेत्रों में एकल-स्थान ऑपरेटर अपने स्वयं के उद्देश्यों के लिए अतिथि डेटा एकत्र करते हैं। वे एक नियंत्रक (controller) के रूप में कार्य करते हैं और इससे अधिक कुछ नहीं। एक साझा WiFi ऑपरेटर अधिक जटिल स्थिति में होता है। इसमें एक MDU या बिल्ड-टू-रेंट (BTR) मकान मालिक, एक सह-कार्य (co-working) प्रदाता और कई किरायेदार संगठनों को सेवा देने वाला एक प्रबंधित सेवा प्रदाता (MSP) शामिल है।

आप अपने स्वयं के उद्देश्यों, जैसे नेटवर्क सुरक्षा, बिलिंग विवादों और दुरुपयोग से निपटने के लिए एक नियंत्रक (controller) हैं। आप किसी किरायेदार व्यवसाय के लिए एक प्रोसेसर भी हो सकते हैं, जिसके कर्मचारी एक SSID, ब्रॉडकास्ट नेटवर्क नाम, का उपयोग करते हैं जिसे आप उनकी ओर से चलाते हैं। आप Investigatory Powers Act 2016 (IPA) के तहत एक दूरसंचार ऑपरेटर भी हो सकते हैं। प्रत्येक भूमिका का अपना प्रतिधारण तर्क होता है, और एकल-साइट खुदरा विक्रेताओं के लिए लिखे गए मार्गदर्शन उन्हें अलग नहीं करते हैं।

क्या आप एक नियंत्रक (controller), एक प्रोसेसर या दोनों हैं?

Article 4(7) आपको वहां एक नियंत्रक बनाता है जहां आप प्रसंस्करण के उद्देश्यों और साधनों को तय करते हैं। Article 4(8) आपको वहां एक प्रोसेसर बनाता है जहां आप किसी अन्य की ओर से डेटा का प्रसंस्करण करते हैं। परीक्षण यह है कि कौन निर्णय लेता है, न कि एक्सेस पॉइंट का मालिक कौन है।

आपकी स्थिति	आपकी भूमिका	आपको क्या चाहिए
निवासी या सदस्य आपके साझा नेटवर्क पर लॉगिन करते हैं	Controller	गोपनीयता नोटिस, कानूनी आधार और प्रतिधारण अनुसूची
आप एक कर्मचारी SSID चलाते हैं और किरायेदार तय करता है कि कौन जुड़ता है और क्यों	किरायेदार के लिए Processor	उस किरायेदार के साथ Article 28 डेटा प्रोसेसिंग समझौता (DPA)
आप टेनेंट स्टाफ को प्रमाणित करते हैं और अपनी नेटवर्क सुरक्षा के लिए उनके लॉग भी रखते हैं	प्रमाणीकरण के लिए प्रोसेसर, सुरक्षा लॉग के लिए कंट्रोलर	DPA, साथ ही सुरक्षा लॉग को कवर करने वाली आपकी अपनी गोपनीयता सूचना
आप और एक टेनेंट संयुक्त रूप से निर्णय लेते हैं कि एक साझा नेटवर्क का उपयोग कैसे किया जाता है	संयुक्त कंट्रोलर	प्रत्येक पक्ष की जिम्मेदारियों को निर्धारित करने वाली Article 26 व्यवस्था

नेटवर्क डिज़ाइन को इन भूमिकाओं को दर्शाना चाहिए। हमारा गाइड Per-unit VLAN and PSK architecture: a design walkthrough for MDU networks इसे विस्तार से समझाता है। एक VLAN तार्किक रूप से अलग नेटवर्क सेगमेंट है, और एक PSK प्री-शेयर की (pre-shared key) है। अलग-अलग सेगमेंट प्रति टेनेंट एक अलग रिटेंशन नियम लागू करना बहुत आसान बनाते हैं।

आप WiFi डेटा की प्रत्येक श्रेणी को कब तक रख सकते हैं?

एक विशिष्ट साझा WiFi प्लेटफ़ॉर्म पांच श्रेणियों के डेटा को कैप्चर करता है। प्रत्येक को अपने स्वयं के उद्देश्य, कानूनी आधार और समय-सीमा की आवश्यकता होती है।

1. कनेक्शन मेटाडेटा

कनेक्शन मेटाडेटा असाइन किए गए IP एड्रेस, सोर्स MAC एड्रेस, सेशन शुरू और समाप्त होने का समय, ट्रांसफर किए गए बाइट्स और DHCP लीज रिकॉर्ड को कवर करता है। इसके उद्देश्य नेटवर्क सुरक्षा, ट्रबलशूटिंग और क्षमता योजना हैं।

कानूनी आधार Article 6(1)(f) के तहत वैध हित है। Recital 49 स्पष्ट रूप से नेटवर्क और सूचना सुरक्षा को वैध हित के रूप में मान्यता देता है। हम 30 दिनों की सलाह देते हैं, यदि आप रुक-रुक कर होने वाली खराबी की जांच करते हैं या तिमाही दर तिमाही क्षमता की तुलना करते हैं तो यह बढ़कर 90 दिन हो जाता है। यदि आपको लंबी अवधि के रुझानों की आवश्यकता है, तो पहले एकत्रित (aggregate) करें। प्रति एक्सेस पॉइंट प्रति घंटे सेशन की गिनती में कोई पहचानकर्ता नहीं होता है।

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

2. गेस्ट प्रमाणीकरण डेटा

यह श्रेणी Captive Portal पर कैप्चर किए गए ईमेल एड्रेस, नाम, फोन नंबर और सोशल लॉगिन पहचानकर्ता को कवर करती है, जो स्प्लैश पेज एक डिवाइस पहुंच प्राप्त करने से पहले देखता है। यह दो उद्देश्यों को पूरा करता है, प्रत्येक की अपनी समय-सीमा होती है।

पहुंच के लिए, उद्देश्य समाप्त होने पर रिटेंशन समाप्त हो जाता है। मुफ्त पहुंच वाले आगंतुकों के लिए, हम Article 6(1)(f) के तहत विवादों को कवर करने के लिए अंतिम सेशन के 30 दिनों के बाद तक की सलाह देते हैं। अनुबंध पर रहने वाले निवासियों और सदस्यों के लिए, Article 6(1)(b) लागू होता है। उनका डेटा किरायेदारी या सदस्यता समाप्त होने तक, प्लस 30 दिनों तक रखें। प्रमाणीकरण चरण के बाद सोशल लॉगिन टोकन स्टोर न करें।

मार्केटिंग के लिए, आधार Article 6(1)(a) के तहत सहमति है, साथ ही इलेक्ट्रॉनिक मार्केटिंग के लिए PECR विनियमन 22 है। रिटेंशन तब तक चलता है जब तक व्यक्ति सहमति वापस नहीं ले लेता। Article 7(3) के अनुसार सहमति वापस लेना उतना ही आसान होना चाहिए जितना कि सहमति देना। वापस लेने के बाद, केवल एक न्यूनतम सप्रेशन प्रविष्टि रखें ताकि आप उस व्यक्ति से फिर कभी संपर्क न करें।

3. स्थान और उपस्थिति डेटा

इसमें ड्वेल टाइम, ज़ोन ऑक्यूपेंसी और हीटमैप विजिट शामिल हैं। Recital 26 वास्तव में अनाम, एग्रीगेटेड डेटा को GDPR के दायरे से पूरी तरह बाहर रखता है। छद्मनाम (Pseudonymised) डेटा, जैसे कि हैश किया हुआ MAC एड्रेस, व्यक्तिगत डेटा ही रहता है क्योंकि आप अभी भी व्यक्ति की पुनः पहचान कर सकते हैं।

लॉगिन सेशन से जुड़े व्यक्तिगत लोकेशन ट्रेल्स पर Article 5(1)(e) का पूरा दायित्व लागू होता है। हम व्यक्तिगत ट्रेल्स को 30 दिनों तक रखने, फिर उन्हें एग्रीगेट करने और सोर्स रिकॉर्ड्स को हटाने की सिफारिश करते हैं। केवल एक या दो लोगों को कवर करने वाले एग्रीगेट्स से भी किसी की पहचान हो सकती है। तड़के 3 बजे किसी ज़ोन में एक अकेला डिवाइस इसका एक उदाहरण है, इसलिए छोटी संख्याओं को छिपा दें। WiFi Analytics रिपोर्टिंग एग्रीगेट्स से काम करती है, इसलिए डेटा हटाए जाने के बाद भी रिपोर्ट सुरक्षित रहती हैं। प्राइवेसी बाय डिज़ाइन और GDPR के लिए WiFi डेटा को अनाम बनाने पर हमारी अलग गाइड इन तकनीकों को विस्तार से कवर करती है।

4. मार्केटिंग संचार इतिहास

इसमें भेजने के टाइमस्टैम्प, ओपन और क्लिक शामिल हैं। यह सहमति रिकॉर्ड का हिस्सा है और उसी समयावधि को साझा करता है, इसलिए जब व्यक्ति सहमति वापस ले ले तो इसे हटा दें। GDPR निष्क्रिय संपर्कों के लिए कोई समय सीमा निर्दिष्ट नहीं करता है, और न ही ICO करता है। हम उन संपर्कों को पुनः अनुमति देने या हटाने की सलाह देते हैं जिन्होंने 24 महीनों में कोई ईमेल नहीं खोला या क्लिक नहीं किया है। उस तर्क को अपनी रिटेंशन नीति में दर्ज करें, क्योंकि जवाबदेही के लिए आपको इस आंकड़े को न्यायोचित ठहराने की आवश्यकता होती है।

5. दुरुपयोग और सुरक्षा लॉग

इस श्रेणी में फ़ायरवॉल डिनाई इवेंट्स, NAT ट्रांसलेशन टेबल, DNS क्वेरी लॉग और RADIUS अकाउंटिंग रिकॉर्ड शामिल हैं। RADIUS यानी रिमोट प्रमाणीकरण डायल-इन यूज़र सर्विस, वह प्रोटोकॉल है जो डिवाइसों को प्रमाणित करता है और उनके सेशन दर्ज करता है। एक ही सार्वजनिक IP एड्रेस के पीछे MDU नेटवर्क पर, आप ही एकमात्र पक्ष हैं जो किसी बाहरी एड्रेस और टाइमस्टैम्प को किसी निवासी से मैप कर सकते हैं। इसलिए अधिकार धारक और पुलिस आपके पास आते हैं।

MDU टैलेंट सेशन एट्रिब्यूशन और एब्यूज हैंडलिंग पर हमारी गाइड नागरिक प्रकटीकरण अनुरोधों का जवाब देने के लिए व्यावहारिक रिटेंशन अवधि के रूप में 365 दिन निर्धारित करती है। UK की अदालतों में, ये आमतौर पर नोर्विच फ़ार्माकल आदेशों का रूप लेते हैं। GDPR का औचित्य तीन-भाग वाले वैध हित परीक्षण (legitimate interests test) का पालन करता है जिसे ICO निर्धारित करता है:

• उद्देश्य। कानूनी दावों और प्रकटीकरण आदेशों का जवाब देने में आपका वास्तविक हित है। Recital 49 इसके ऊपर नेटवर्क सुरक्षा को भी जोड़ता है।
• आवश्यकता। लॉग के बिना आप गतिविधि का श्रेय नहीं दे सकते, और NAT मैपिंग किसी अन्य के पास नहीं होती है।
• संतुलन। Recital 47 उचित अपेक्षाओं पर निर्भर करता है। एक साझा नेटवर्क पर रहने वाले निवासी तर्कसंगत रूप से ऑपरेटर से दुरुपयोग से निपटने के लिए लॉग रखने की उम्मीद कर सकते हैं। यह तब तक मान्य है जब तक कि अवधि आनुपातिक है और आपकी प्राइवेसी नोटिस में इसका उल्लेख है।

आनुपातिकता श्रेणी के भीतर भी लागू होती है। DNS क्वेरी लॉग ब्राउज़िंग व्यवहार को उजागर करते हैं, जो उन्हें सेशन रिकॉर्ड की तुलना में अधिक दखलअंदाज़ बनाता है। RADIUS अकाउंटिंग और NAT रिकॉर्ड्स को 365 दिनों के लिए रखें। पूर्ण DNS क्वेरी लॉग्स को घटाकर 90 दिन करें, और केवल नामित सुरक्षा कर्मचारियों तक पहुंच को सीमित करें।

क्या इन्वेस्टिगेटरी पावर्स एक्ट 2016 आपको 12 महीनों के लिए WiFi रिकॉर्ड रखने के लिए बाध्य करता है?

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

क्या आप IPA के तहत एक दूरसंचार ऑपरेटर हैं?

संभवतः। धारा 261(10) एक दूरसंचार ऑपरेटर को ऐसे किसी भी व्यक्ति के रूप में परिभाषित करती है जो यूके में व्यक्तियों को दूरसंचार सेवा प्रदान करता है या प्रदान करता है। यह ऐसे किसी भी व्यक्ति को भी कवर करता है जो यूके में दूरसंचार प्रणाली को नियंत्रित करता है या प्रदान करता है। धारा 261(11) सेवा को दूरसंचार प्रणाली का उपयोग करने के लिए पहुंच और सुविधाएं प्रदान करने के रूप में परिभाषित करती है। निवासियों या सदस्यों को इंटरनेट से जोड़ने वाला एक साझा नेटवर्क उस परिभाषा में आसानी से फिट बैठता है।

वास्तव में 12 महीने का कर्तव्य क्या बनाता है?

धारा 87 राज्य के सचिव को एक विशिष्ट ऑपरेटर को रिटेंशन नोटिस जारी करने की अनुमति देती है। नोटिस के लिए उस ऑपरेटर को निर्दिष्ट संचार डेटा बनाए रखने की आवश्यकता होती है। एक न्यायिक आयुक्त को निर्णय को मंजूरी देनी होगी। धारा 87(3) रिटेंशन को 12 महीनों तक सीमित करती है, इसलिए 12 महीने एक सीमा है जो एक नोटिस लागू कर सकता है। यह कोई न्यूनतम सीमा नहीं है जिसे हर ऑपरेटर को पूरा करना होगा। डेटा रिटेंशन एंड एक्विजिशन रेगुलेशन 2018 ने बाद में इन शक्तियों में संशोधन किया।

यदि आपके पास कोई नोटिस है, तो निर्दिष्ट डेटा को बनाए रखना अनुच्छेद 6(1)(c), कानूनी दायित्व के अनुपालन पर निर्भर करता है। इसके बाद अनुच्छेद 17(3)(b) उस डेटा के लिए मिटाने के अधिकार को अमान्य कर देता है। नोटिस केवल उसी डेटा तक पहुँचता है जिसका वह नाम लेता है। आपकी मार्केटिंग सूची और स्थान विश्लेषण अपने स्वयं के, छोटे समय-सीमा बनाए रखते हैं। अधिनियम नोटिस के अस्तित्व के प्रकटीकरण को प्रतिबंधित करता है, इसलिए आपकी गोपनीयता नोटिस इसे कैसे वर्णित करती है, इस पर सलाह लें।

यदि आपके पास कोई नोटिस नहीं है, तो आप 12 महीने के रिटेंशन को सही ठहराने के लिए IPA का हवाला नहीं दे सकते। भाग 3 प्राधिकरण वाला एक सार्वजनिक प्राधिकरण अभी भी आपसे आपके द्वारा पहले से धारित संचार डेटा को प्रकट करने की आवश्यकता कर सकता है। वह शक्ति केवल उसी तक पहुँचती है जो आपके पास है, और यह आपको कभी भी डेटा को अधिक समय तक रखने के लिए बाध्य नहीं करती है।

एक रक्षात्मक रिटेंशन अनुसूची कैसी दिखती है?

इसे एक शुरुआती बिंदु के रूप में अपनाएं, फिर इसे अपने प्रलेखित उद्देश्यों के अनुसार समायोजित करें।

डेटा श्रेणी	इसमें क्या शामिल है	कानूनी आधार	रिटेंशन अवधि	समाप्ति पर
कनेक्शन मेटाडेटा	IP, MAC, सत्र समय, बाइट्स, DHCP लीज	Art. 6(1)(f), Recital 49	30 - 90 दिन	हटाएं या प्रति-एक्सेस-पॉइंट गिनती में एकत्र करें
प्रमाणीकरण (पहुंच)	नाम, ईमेल, फोन, सोशल लॉगिन ID	आगंतुकों के लिए Art. 6(1)(f), निवासियों और सदस्यों के लिए 6(1)(b)	अंतिम सत्र के 30 दिन बाद आगंतुक; निवासी और सदस्य, अनुबंध की समाप्ति और 30 दिन	हटाएं
प्रमाणीकरण (मार्केटिंग)	ईमेल, नाम, सहमति रिकॉर्ड	Art. 6(1)(a), PECR reg. 22	वापस लेने तक, या बिना जुड़ाव के 24 महीने	हटाएं, दमन प्रविष्टि रखें
व्यक्तिगत स्थान निशान	प्रति-उपकरण ड्वेल और ज़ोन विजिट	Art. 6(1)(f)	30 दिन	एकत्र करें, फिर स्रोत रिकॉर्ड हटाएं
एकत्रित स्थान डेटा	ज़ोन गिनती, हीटमैप्स	GDPR के बाहर (Recital 26)	हर 12 महीने में समीक्षा करें	उपयोगी होने तक रखें
मार्केटिंग इतिहास	भेजता है, खोलता है, क्लिक करता है	Art. 6(1)(a)	सहमति रिकॉर्ड के समान	संपर्क के साथ हटाएं
RADIUS अकाउंटिंग और NAT लॉग	सेशन-टू-आइडेंटिटी मैपिंग	आर्ट. 6(1)(f), आर्ट. 17(3)(e)	365 दिन	हटाएं जब तक कि कानूनी रोक न हो
DNS क्वेरी लॉग	प्रति सेशन अनुरोधित डोमेन	आर्ट. 6(1)(f)	90 दिन	हटाएं
IPA रिटेंशन नोटिस के तहत डेटा	जैसा कि नोटिस में निर्दिष्ट है	आर्ट. 6(1)(c), आर्ट. 17(3)(b)	निर्दिष्ट अनुसार, अधिकतम 12 महीने	नोटिस की अवधि समाप्त होने पर हटाएं

हटाने की प्रक्रिया आपके बैकअप तक भी पहुंचनी चाहिए। ICO मार्गदर्शन स्वीकार करता है कि बैकअप को हमेशा तुरंत नहीं मिटाया जा सकता है। हालाँकि, आपको डेटा का उपयोग बंद कर देना चाहिए और एक निश्चित चक्र पर उसे ओवरराइट करना चाहिए।

जब आपको कुछ डेटा रखना अनिवार्य हो, तो आप मिटाने के अनुरोध (erasure request) को कैसे संभालते हैं?

अनुच्छेद 17 के तहत मिटाना पूर्ण नहीं है, लेकिन हर अस्वीकृति के लिए एक नामित छूट की आवश्यकता होती है। प्रत्येक अनुरोध पर एक ही तरह से काम करें:

1. लॉग करें और सत्यापित करें। तिथि रिकॉर्ड करें और पहचान की पुष्टि करें। अनुच्छेद 12(3) आपको जवाब देने के लिए एक महीने का समय देता है।
2. अपनी भूमिका जांचें। यदि अनुरोध किसी टेनेंट के स्टाफ SSID से संबंधित है जहां आप एक प्रोसेसर हैं, तो इसे टेनेंट को भेजें। अनुच्छेद 28(3)(e) के तहत आपको उनका जवाब देने में मदद करना आवश्यक है।
3. डेटा को मैप करें। बैकअप और एक्सपोर्ट सहित सभी पांच श्रेणियों में खोजें।
4. मार्केटिंग डेटा मिटाएं। अनुच्छेद 21(3) डायरेक्ट मार्केटिंग के विरोध को पूर्ण बनाता है, इसलिए सप्रेशन एंट्री को छोड़कर सब कुछ हटा दें।
5. दुर्व्यवहार लॉग का मूल्यांकन करें। जहां कोई दावा सक्रिय है या उचित रूप से संभावित है, अनुच्छेद 17(3)(e) आपको प्रासंगिक रिकॉर्ड रखने की अनुमति देता है। अन्यथा, आपको यह दिखाना होगा कि आपके आधार व्यक्ति के हितों से अधिक महत्वपूर्ण हैं। आपका वैध हित मूल्यांकन (legitimate interests assessment) उस भार का अधिकांश हिस्सा वहन करता है।
6. कोई भी रिटेंशन नोटिस लागू करें। नोटिस द्वारा निर्दिष्ट डेटा अनुच्छेद 17(3)(b) के तहत रहता है।
7. परिणाम स्पष्ट करें। व्यक्ति को बताएं कि आपने क्या मिटाया, क्या रखा, क्यों रखा, और रखा गया डेटा कब हटाया जाएगा।

क्या आपको हर टेनेंट के साथ Data Processing Agreement की आवश्यकता है?

हाँ, हर उस टेनेंट के साथ जिसके लिए आप प्रोसेसर के रूप में कार्य करते हैं। उनके कर्मचारियों से कोई भी प्रमाणीकरण डेटा एकत्र करने से पहले इस पर हस्ताक्षर करें। अनुच्छेद 28(3) के लिए एक लिखित अनुबंध की आवश्यकता होती है, और प्रत्येक में इन बिंदुओं को शामिल किया जाना चाहिए:

• प्रसंस्करण का विषय, अवधि, प्रकृति और उद्देश्य, व्यक्तिगत डेटा के प्रकार और डेटा विषयों की श्रेणियां
• केवल टेनेंट के दस्तावेज निर्देशों पर प्रसंस्करण, जिसमें कोई भी अंतर्राष्ट्रीय स्थानांतरण शामिल है
• डेटा प्रोसेस करने के लिए अधिकृत सभी लोगों की गोपनीयता प्रतिबद्धताएं
• अनुच्छेद 32 सुरक्षा उपाय
• सब-प्रोसेसर को शामिल करने की शर्तें, समान दायित्वों के साथ
• डेटा विषय अधिकारों के अनुरोधों में सहायता
• अनुच्छेद 32 से 36 के तहत सुरक्षा, उल्लंघन अधिसूचना, प्रभाव आकलन और पूर्व परामर्श में सहायता
• अनुबंध समाप्त होने पर सभी व्यक्तिगत डेटा को हटाना या वापस करना, जब तक कि कानून द्वारा भंडारण की आवश्यकता न हो
• अनुपालन प्रदर्शित करने के लिए जानकारी और ऑडिट पहुंच
• यदि कोई निर्देश डेटा सुरक्षा कानून का उल्लंघन करता है तो तत्काल सूचना

अपनी किराएदारी या सदस्यता समझौते में एक मानक DPA संलग्न करें, ताकि नए किराएदार ऑनबोर्डिंग के दौरान हस्ताक्षर कर सकें। कई इमारतों का संचालन करने वाले ऑपरेटर Multi-site guest WiFi for franchises: central control with local branding से केंद्रीय-नीति मॉडल लागू कर सकते हैं। आप एक शेड्यूल सेट करते हैं और इसे प्रति साइट लागू करते हैं।

व्यवहार में यह कैसा दिखता है?

नीचे दी गई तीन स्थितियां उदाहरण के रूप में हैं। प्रत्येक परिणाम की गणना स्थिति के अपने आंकड़ों से की जाती है।

सार्वजनिक क्षेत्र: परिषद द्वारा संचालित एक एंटरप्राइज सेंटर

स्थिति। परिषद के स्वामित्व वाला एक एंटरप्राइज सेंटर 22 किराएदार व्यवसायों की मेजबानी करता है, जिनमें से प्रत्येक का अपना स्टाफ SSID है। यह कोई DPA नहीं रखता है और ऑडिट के दिन तक तीन साल पुराने कनेक्शन लॉग को अनिश्चित काल के लिए रखता है।

क्या किया गया। केंद्र ने खुद को स्टाफ प्रमाणीकरण के लिए प्रोसेसर और सुरक्षा लॉग के लिए कंट्रोलर के रूप में वर्गीकृत किया। इसने अपने अगले नवीनीकरण पर सभी 22 किराएदारों के साथ DPA पर हस्ताक्षर किए। इसके बाद इसने कनेक्शन मेटाडेटा प्रतिधारण को घटाकर 90 दिन कर दिया।

परिणाम। सभी 22 प्रोसेसिंग संबंधों में अब Article 28 अनुबंध हैं। पहचान योग्य कनेक्शन मेटाडेटा 1,095 दिनों से घटकर 90 दिन हो गया, जो 92% की कमी है।

कार्यक्रम: एक सम्मेलन और प्रदर्शनी केंद्र

स्थिति। एक सहभागी उसी सप्ताह डेटा मिटाने का अनुरोध करता है जिस सप्ताह अधिकार धारक स्थान के सार्वजनिक IP पते से जुड़े कॉपीराइट उल्लंघन के बारे में लिखता है।

क्या किया गया। टीम ने सहभागी का मार्केटिंग रिकॉर्ड और स्पलैश पेज डेटा मिटा दिया। इसने एक सप्रेशन प्रविष्टि रखी। इसने Article 17(3)(e) का हवाला देते हुए विवादित सत्रों के लिए RADIUS अकाउंटिंग और NAT रिकॉर्ड को कानूनी रोक के तहत रखा। इसके उत्तर में दोनों निर्णयों को निर्धारित किया गया।

परिणाम। केंद्र ने 30 दिन की समय सीमा के छठे दिन जवाब दिया। इसके पास अभी भी वह सबूत था जिसकी नॉर्विच फार्मकल ऑर्डर को आवश्यकता होगी।

रिटेल: ज़ोन एनालिटिक्स वाला एक शॉपिंग सेंटर

स्थिति। एक शॉपिंग सेंटर साल-दर-साल ग्राहकों की संख्या की तुलना करने के लिए 13 महीनों के लिए व्यक्तिगत खरीदार स्थान के निशानों को रखता है।

क्या किया गया। इसने साल-दर-साल की रिपोर्टिंग को एग्रीगेटेड ज़ोन काउंट पर स्थानांतरित कर दिया। इसके बाद इसने 30 दिनों के बाद व्यक्तिगत निशानों को हटाने के लिए सेट किया।

परिणाम। पहचान योग्य स्थान इतिहास 395 दिनों से घटकर 30 दिन हो गया, जो 92% की कमी है। साल-दर-साल रिपोर्टिंग बिना किसी रुकावट के जारी रही।

Purple आपके द्वारा पहले से चलाए जा रहे सिस्टम के साथ कहाँ फिट बैठता है?

Purple साझा WiFi ऑपरेटरों को वे नियंत्रण प्रदान करता है जिनकी इस शेड्यूल को आवश्यकता होती है। आपको प्रति डेटा श्रेणी कॉन्फ़िगर करने योग्य प्रतिधारण अवधि और स्वचालित पर्ज शेड्यूल मिलते हैं। डेटा विषय पहुंच अनुरोध टूलिंग और इरेज़र वर्कफ़्लो इसमें अंतर्निहित हैं। स्पलैश पेज पर सचेत-पसंद ऑप्ट-इन नेटवर्क एक्सेस से अलग मार्केटिंग सहमति को रिकॉर्ड करते हैं। यह दोनों घड़ियों को अलग रखता है।

Purple Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme और Fortinet पर एक हार्डवेयर-एग्नॉस्टिक क्लाउड ओवरले के रूप में चलता है। आप एक्सेस पॉइंट को बदले बिना रिटेंशन नीति बदल सकते हैं, जैसा कि Why your next WiFi upgrade doesn't need new hardware में बताया गया है। Multi-Tenant WiFi प्रत्येक निवासी या किरायेदार के ट्रैफ़िक को अलग करने के लिए पहचान-आधारित नेटवर्क का उपयोग करता है। Guest WiFi आगंतुक पहुंच को कवर करता है।

Purple ISO 27001, Cyber Essentials और B Corp प्रमाणित है, और GDPR और CCPA का अनुपालन करता है। Purple के अपने डेटा के अनुसार, यह 80,000+ से अधिक लाइव स्थानों को सेवा प्रदान करता है और इसने 2024 में 440 मिलियन लॉगिन संभाले हैं।

कौन सी सीमाएं हैं जो आपको जाननी चाहिए?

• यह कानूनी सलाह नहीं है। आपके पास रिटेंशन नोटिस है या आप PECR के अंतर्गत आते हैं, इसकी पुष्टि आपके वकील से होना आवश्यक है।
• अनुशंसित अवधियां केवल शुरुआती बिंदु हैं। GDPR कोई न्यूनतम सीमा निर्धारित नहीं करता है, इसलिए ऊपर दी गई प्रत्येक अवधि के पीछे आपका अपना दस्तावेजी उद्देश्य होना चाहिए।
• गुमनामीकरण (Anonymisation) जितना दिखता है उससे कहीं अधिक कठिन है। हैश किए गए पहचानकर्ता व्यक्तिगत डेटा बने रहते हैं, और छोटे समूचे डेटा से भी व्यक्तियों की पहचान की जा सकती है।
• संवेदनशील स्थान बार को ऊंचा करते हैं। Healthcare स्थानों में, स्थान डेटा यह प्रकट कर सकता है कि मरीज किस क्लिनिक में गया था। विश्लेषण करने से पहले अनुच्छेद 35 के तहत डेटा सुरक्षा प्रभाव मूल्यांकन चलाएं।

आपको आगे क्या करना चाहिए?

1. कंट्रोलर और प्रोसेसर तालिका का उपयोग करके प्रत्येक डेटा प्रवाह के लिए अपनी भूमिका का नक्शा बनाएं।
2. लिखित रूप में पुष्टि करें कि क्या आपके पास IPA रिटेंशन नोटिस है।
3. अपने उद्देश्यों के अनुसार समायोजित रिटेंशन शेड्यूल अपनाएं, और अपनी गोपनीयता सूचना में इन अवधियों को प्रकाशित करें।
4. प्रत्येक किरायेदार के साथ अनुच्छेद 28 DPA पर हस्ताक्षर करें जिसके लिए आप प्रोसेसर के रूप में कार्य करते हैं।
5. बैकअप सहित डेटा हटाने की प्रक्रिया को स्वचालित करें, और शुरू से अंत तक डेटा मिटाने के अनुरोध का परीक्षण करें।

नेटवर्क डिज़ाइन के लिए, प्राइवेसी-बाय-डिजाइन गुमनामीकरण और MDU किरायेदार सत्र एट्रिब्यूशन पर हमारे गाइड के साथ Purple का Multi-Tenant WiFi अवलोकन पढ़ें।

अक्सर पूछे जाने वाले प्रश्न

मैं GDPR के तहत गेस्ट WiFi लॉगिन डेटा को कब तक रख सकता हूं?

इसे केवल तब तक रखें जब तक कि उद्देश्य के लिए आवश्यक हो, क्योंकि GDPR कोई निश्चित अवधि निर्धारित नहीं करता है। नेटवर्क एक्सेस के लिए, हम आगंतुकों के लिए अंतिम सत्र के 30 दिनों तक की सिफारिश करते हैं। निवासियों और सदस्यों के लिए, इसे उनका अनुबंध समाप्त होने तक, प्लस 30 दिनों तक रखें। सहमति से एकत्र किया गया मार्केटिंग डेटा तब तक रह सकता है जब तक कि व्यक्ति सहमति वापस नहीं ले लेता। हमारा सुझाव है कि उन संपर्कों को हटा दें जिन्होंने 24 महीनों में कोई गतिविधि नहीं दिखाई है। अपने रिटेंशन शेड्यूल और गोपनीयता सूचना में प्रत्येक अवधि का दस्तावेजीकरण करें।

क्या UK इन्वेस्टिगेटरी पावर्स एक्ट के तहत मुझे 12 महीनों के लिए WiFi कनेक्शन रिकॉर्ड रखने की आवश्यकता है?

नहीं, तब तक नहीं जब तक कि राज्य सचिव ने आपको रिटेंशन नोटिस न दिया हो। अधिकांश साझा WiFi ऑपरेटर IPA की दूरसंचार ऑपरेटर की व्यापक परिभाषा को पूरा करते हैं। केवल यह स्थिति ही कोई रिटेंशन कर्तव्य नहीं बनाती है। धारा 87 एक नोटिस को अधिकतम 12 महीनों के लिए निर्दिष्ट डेटा के रिटेंशन की आवश्यकता की अनुमति देती है। बिना किसी नोटिस के, आप अपने स्वयं के उद्देश्यों की आवश्यकता से अधिक समय तक डेटा रखने को उचित ठहराने के लिए IPA का हवाला नहीं दे सकते।

क्या मैं अपने किरायेदारों के कर्मचारियों के लिए एक स्टाफ SSID पर डेटा नियंत्रक (controller) या प्रोसेसर हूँ?

यदि किरायेदार यह तय करता है कि उसके स्टाफ SSID से कौन जुड़ता है और क्यों, तो आप आमतौर पर एक प्रोसेसर होते हैं। आप अपने स्वयं के उद्देश्यों, जैसे कि नेटवर्क सुरक्षा लॉग के लिए रखे जाने वाले किसी भी डेटा के लिए एक नियंत्रक बन जाते हैं। कई सह-कार्य (co-working) ऑपरेटर एक ही समय में दोनों भूमिकाएं निभाते हैं। अनुच्छेद 4 का परीक्षण इस बात पर निर्भर करता है कि प्रसंस्करण के उद्देश्यों और साधनों का निर्णय कौन करता है, न कि इस पर कि नेटवर्क हार्डवेयर का मालिक कौन है।

साझा WiFi नेटवर्क पर IP एड्रेस लॉग के लिए सही अवधारण (retention) अवधि क्या है?

ट्रैबलशूटिंग और सुरक्षा के लिए, वैध हितों के तहत 30 - 90 दिन का समय उचित है। एक एकल सार्वजनिक IP एड्रेस के पीछे के नेटवर्क पर, RADIUS अकाउंटिंग और NAT ट्रांसलेशन रिकॉर्ड 365 दिनों के लिए रखें। यह आपको प्रकटीकरण आदेशों का जवाब देने की अनुमति देता है, क्योंकि केवल आप ही किसी बाहरी एड्रेस को किसी निवासी से जोड़ सकते हैं। पूर्ण DNS क्वेरी लॉग को 90 दिनों तक सीमित करें, क्योंकि वे ब्राउज़िंग व्यवहार को प्रकट करते हैं और इसके लिए अधिक मजबूत औचित्य की आवश्यकता होती है।

जब मुझे ट्रैफ़िक डेटा भी बनाए रखना हो, तो मैं डेटा विषय मिटाने के अनुरोध (erasure request) को कैसे संभालूँ?

वह सब कुछ मिटा दें जो किसी छूट के अंतर्गत नहीं आता है, और स्पष्ट करें कि आपने क्या रखा है और क्यों। केवल एक दमन प्रविष्टि (suppression entry) को बनाए रखते हुए, मार्केटिंग और प्रमाणीकरण डेटा हटाएं। जहां अनुच्छेद 17(3)(e) के तहत कोई कानूनी दावा लाइव या संभावित हो, वहां दुरुपयोग लॉग रखें। अनुच्छेद 17(3)(b) के तहत IPA अवधारण नोटिस में निर्दिष्ट डेटा रखें। एक महीने के भीतर जवाब दें, जैसा कि अनुच्छेद 12(3) के लिए आवश्यक है, और बताएं कि रिटेन किया गया डेटा कब डिलीट किया जाएगा।

क्या मुझे प्रत्येक किरायेदार संगठन के साथ डेटा प्रोसेसिंग समझौते (DPA) की आवश्यकता है?

हाँ, प्रत्येक उस किरायेदार के साथ जिसके लिए आप प्रोसेसर के रूप में स्टाफ डेटा को प्रोसेस करते हैं। अनुच्छेद 28(3) के अनुसार प्रसंस्करण शुरू होने से पहले एक लिखित अनुबंध की आवश्यकता होती है। इसमें प्रलेखित निर्देश, गोपनीयता, सुरक्षा, उप-प्रोसेसर, डेटा विषय अधिकारों में सहायता, अनुबंध समाप्त होने पर विलोपन और ऑडिट पहुंच शामिल होनी चाहिए। अपने किरायेदारी या सदस्यता समझौते में एक मानक DPA संलग्न करने का अर्थ है कि प्रत्येक नया किरायेदार ऑनबोर्डिंग के समय इस पर हस्ताक्षर करता है।

क्या Purple उन एक्सेस पॉइंट के साथ काम करता है जिन्हें मैं पहले से चला रहा हूँ?

हाँ। Purple Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme और Fortinet पर एक हार्डवेयर-अज्ञेयवादी क्लाउड ओवरले के रूप में चलता है। आप एक्सेस पॉइंट को बदले बिना Purple में अवधारण अवधि, स्वचालित पर्ज और इरेज़र वर्कफ़्लो को कॉन्फ़िगर करते हैं। Purple ISO 27001 और Cyber Essentials प्रमाणित है और GDPR का अनुपालन करता है। Purple के अपने डेटा के अनुसार, यह 80,000+ लाइव स्थानों पर सेवा प्रदान करता है।