मुख्य मजकुराकडे जा
मराठी

सामायिक WiFi ऑपरेटर्ससाठी GDPR डेटा धारणा: आपण अतिथी लॉगिन डेटा आणि नेटवर्क लॉग किती काळ ठेवू शकता

सामायिक WiFi चालवणारे DPOs, नेटवर्क आर्किटेक्ट्स आणि वेन्यू ऑपरेटर्ससाठी एक व्यावहारिक UK अनुपालन मार्गदर्शक. हे GDPR स्टोरेज-मर्यादेच्या निर्णयांना सशर्त IPA धारणा-सूचना प्रणालीपासून वेगळे करते, नंतर नियंत्रक-प्रक्रिया विश्लेषण धारणा वेळापत्रक, Article 28 चेकलिस्ट आणि मिटवण्याच्या कार्यप्रवाहात रूपांतरित करते.

प्रकाशित अद्ययावत केले
📖 12 मिनिट वाचन2,808 शब्द3 सोडवलेली उदाहरणे10 महत्वाच्या व्याख्या

हे मार्गदर्शक ऐका

पॉडकास्ट ट्रान्सक्रिप्ट पहा
सामायिक WiFi ऑपरेटर्ससाठी GDPR डेटा धारणा स्वागत आहे. ही माहिती अशा लोकांसाठी आहे ज्यांना हॉटेल्स, शॉपिंग डेस्टिनेशन्स, को-वर्किंग इस्टेट्स, स्टेडियम्स आणि सार्वजनिक ठिकाणी डेटा धारणा (retention) चे निर्णय प्रत्यक्षात अंमलात आणावे लागतात. मुख्य बातमी अशी आहे. UK GDPR पाहुण्यांच्या WiFi ऑपरेटर्सना लॉगिन डेटा किंवा नेटवर्क लॉग्ससाठी ठराविक दिवसांची संख्या देत नाही. कलम ५ मधील साठवणूक मर्यादा (storage limitation) नुसार तुम्ही ओळखता येण्याजोगा डेटा तुम्ही दस्तऐवजीकरण केलेल्या हेतूसाठी आवश्यकतेपेक्षा जास्त काळ ठेवू नये. याचा अर्थ प्रत्येक रेकॉर्डसाठी एकच सरसकट सेटिंग असणे ही सहसा चुकीची रचना ठरते. इस्टेट मॉडेलपासून सुरुवात करा. स्वतःच्या ॲक्सेस, सेवा हमी आणि सुरक्षा हेतूंसाठी पाहुण्यांचे नेटवर्क चालवणारे हॉटेल सहसा त्या हेतूंसाठी नियंत्रक (controller) म्हणून निर्णय घेईल. को-वर्किंग ऑपरेटर त्याच्या सदस्य नेटवर्कसाठी तेच करू शकतो. परंतु जेथे ऑपरेटर भाडेकरू व्यवसायासाठी कर्मचारी SSID प्रदान करतो, तेथे कर्मचाऱ्यांचा ओळख डेटा का गोळा केला जातो, तो किती काळ ठेवला जातो आणि कर्मचाऱ्यांच्या विनंत्या कशा हाताळल्या जातात हे तो भाडेकरू ठरवू शकतो. त्या प्रक्रियेत, ऑपरेटर एक प्रोसेसर असू शकतो. भिन्न हेतूंसाठी वेगवेगळ्या क्षमतेमध्ये समान डेटा हाताळला जाऊ शकतो. तुम्ही लेबलवर वाद घालण्यापूर्वी हेतूचा मॅप तयार करा. पुढे, तुमचा डेटा वेगळा करा. कनेक्शन मेटाडेटा मध्ये डिव्हाइसला दिलेला पत्ता, डिव्हाइस आयडेंटिफायर, सेशन सुरू होण्याची आणि संपण्याची वेळ, DHCP लीजेस, RADIUS अकाऊंटिंग आणि ट्रॅफिक एकूण संख्या समाविष्ट असू शकते. नावाच्या लॉगिन नेटवर्कवर, ते रेकॉर्ड सामान्यतः वैयक्तिक डेटा असतील कारण तुम्ही ते एखाद्या व्यक्तीशी जोडू शकता. एका निर्दिष्ट सुरक्षा आणि इन्सिडंट-रिस्पॉन्स हेतूसाठी, ३० ते ९० दिवसांचा ऑपरेशनल कालावधी हा एक योग्य सुरुवातीचा टप्पा असू शकतो. हे कायदेशीर सुरक्षा कवच (safe harbour) नाही. तुमच्या घटना किती लवकर शोधल्या जातात, तुम्ही क्वेरी करू शकता अशा सिस्टीम्स, घुसखोरीचा धोका आणि तुम्ही वापरत असलेली नियंत्रणे यावर आधारित हे तपासून घ्या. प्रमाणीकरण (Authentication) डेटाला स्वतःच्या नियमांची गरज असते. ईमेल पत्ता, नाव, मोबाईल नंबर आणि सोशल-लॉगिन आयडेंटिफायर याने फायरवॉल इव्हेंटसारखाच टाइमर फॉलो करू नये. जर पाहुण्यांच्या नेटवर्कवर प्रवेश मिळवणे हाच एकमेव हेतू असेल, तर प्रवेश संपल्यानंतर आणि कोणताही छोटा, दस्तऐवजीकरण केलेला वाद मिटवण्याचा कालावधी निघून गेल्यावर तो मिटवून टाका किंवा अपरिवर्तनीयपणे अनामित करा. जर तुम्ही त्याचा वापर मार्केटिंगसाठी करत असाल, तर तुम्हाला मार्केटिंगच्या कायदेशीर आधाराचा आणि इलेक्ट्रॉनिक-मार्केटिंग नियमांचा आदर करावा लागेल. संमती मागे घेतल्याने मार्केटिंगचा वापर संपतो. त्या व्यक्तीला पुन्हा मार्केटिंगचे संदेश मिळणार नाहीत याची खात्री करण्यासाठी आवश्यक असलेला किमान दडपशाही (suppression) रेकॉर्डच फक्त ठेवा. स्थान आणि उपस्थिती डेटाला अधिक शिस्तबद्ध रचनेची आवश्यकता असते. संकलित केलेली माहिती जी खरोखर अनामित (anonymised) केली गेली आहे जेणेकरून लोक ओळखले जाऊ शकत नाहीत, ती वैयक्तिक डेटा नाही. परंतु एखाद्या व्यक्तीच्या नावाच्या जागी टोकन ठेवल्याने ती माहिती अनामित होत नाही जर तुम्ही ते टोकन पुन्हा जोडू शकत असाल. ओळखण्यायोग्य ट्रेल्ससाठी, एक लहान ऑपरेशनल विंडो सेट करा, नंतर संकलित करा किंवा मिटवून टाका. त्या वेळेत ऑपरेशनल समस्यांचा तपास करणाऱ्या ठिकाणासाठी ३० दिवसांचा ट्रेस कालावधी व्यावहारिक असू शकतो. याचे कारण दस्तऐवजीकरण करा. तपशीलवार हालचालींचे ट्रेल्स साठवू नका कारण ते कदाचित नंतर उपयुक्त ठरू शकतात.गैरवर्तन आणि सुरक्षा लॉगसाठी, न्याय्य हितसंबंध (legitimate interests) योग्य असू शकतात परंतु ते स्वयंचलित नाही. ICO ची त्रिसुत्री चाचणी विचारते: सुरक्षेचा हेतू न्याय्य आहे का, ही डेटा धारणा (retention) आवश्यक आहे का, आणि व्यक्तीचे हितसंबंध तुमच्या हितसंबंधांपेक्षा अधिक महत्त्वाचे आहेत का? वाजवी अपेक्षा, फील्ड्सची संवेदनशीलता, प्रवेश नियंत्रणे (access controls) आणि दीर्घकाळ डेटा ठेवल्याने होऊ शकणारे नुकसान दस्तऐवजीकरण करा. जर तुमच्या शेअर्ड सार्वजनिक पत्त्याचा अर्थ असा असेल की तुम्हाला गैरवर्तनाच्या तक्रारीसाठी ऐतिहासिक विशेषता (historical attribution) आवश्यक आहे, तर विशिष्ट वातावरणात ३६५ दिवसांचा नियम समर्थनीय असू शकतो. हा सार्वत्रिक GDPR निकष नाही. त्याची एक दस्तऐवजीकरण केलेली धोरणात्मक निवड करा, त्याचे पुनरावलोकन करा आणि ठेवलेली फील्ड्स कमीत कमी करा. आता UK Investigatory Powers Act, ज्याला अनेकदा IPA म्हणून संक्षिप्त केले जाते. येथेच अनेक शेअर्ड WiFi मार्गदर्शिका चुकतात. दूरसंचार चालकाची (telecommunications operator) कायदेशीर व्याख्या व्यापक आहे. सरकारची सद्य नियमावली सांगते की यामध्ये हॉटेल, विमानतळ लाउंज आणि सार्वजनिक वाहतूक यांसारख्या ठिकाणी पाहुण्यांना किंवा सार्वजनिक नागरिकांना दळणवळण सेवांमध्ये प्रवेश देणाऱ्या पुरवठादारांचा समावेश असू शकतो. यामुळे हा प्रश्न शेअर्ड WiFi चालकांसाठी सुसंगत ठरतो. याचा अर्थ असा नाही की प्रत्येक ठिकाणावर स्वयंचलितपणे बारा महिन्यांचे कर्तव्य आहे. अधिकृत सूचना कोडमधील डीफॉल्ट स्थिती अशी आहे की कोणत्याही चालकाला जोपर्यंत डेटा धारणा सूचना (data retention notice) प्राप्त होत नाही तोपर्यंत या कायद्यांतर्गत डेटा ठेवण्याची आवश्यकता नाही. कलम ८७ अंतर्गत, नोटीस आवश्यक आणि प्रमाणबद्ध असणे आवश्यक आहे, त्यामध्ये चालक, डेटा आणि धारणा कालावधी ओळखला गेला पाहिजे आणि त्यामध्ये बारा महिन्यांपेक्षा जास्त काळ डेटा ठेवण्याची आवश्यकता असू शकत नाही. जर तुम्हाला नोटीस मिळाली नसेल, तर असे अंतर्गत धोरण लिहू नका जे सांगते की IPA नुसार तुम्हाला प्रत्येक नेटवर्क रेकॉर्ड वर्षभर ठेवणे आवश्यक आहे. कायद्यात तसे म्हटलेले नाही. जर तुम्हाला नोटीस मिळाली, तर त्वरित तज्ञ कायदेशीर सल्लागाराचा सल्ला घ्या. केवळ संबंधित दळणवळण डेटा आणि प्रत्यक्षात नमूद केलेला कालावधी जतन करा. तो तुमच्या वेळापत्रकात वेगळा ठेवा. सरकारी नियमावली असा डेटा ओळखते जो दळणवळणाचा कोण, केव्हा, कुठे आणि कसा हे ओळखण्यास मदत करू शकतो. उदाहरणांमध्ये स्त्रोत आणि गंतव्यस्थान पत्ते (source and destination addresses), पोर्ट्स, इंटरनेट ॲक्सेस सेशनच्या वेळा, ॲक्सेस-पॉइंट ओळख आणि ॲक्सेस-पॉइंट ठिकाणे समाविष्ट आहेत. IPA प्रत्येक कंटेंट लॉगचे रूपांतर धारणा लक्ष्यात करत नाही. कंटेंट ही एक वेगळी श्रेणी आहे. GDPR च्या उद्देशांसाठी, लागू असलेले कायदेशीर कर्तव्य Article 6 मधील कायदेशीर-बंधन (legal-obligation) आधार प्रदान करू शकते. परंतु तुमच्या वेळापत्रकात अचूक वैधानिक संदर्भ आणि नोटीसची व्याप्ती असणे आवश्यक आहे. आपण योग्य असेल तिथे आपल्या गोपनीयता माहितीमध्ये त्या मर्यादित डेटा धारणेचे स्पष्टीकरण देखील दिले पाहिजे आणि नोटीसशी संबंधित गोपनीयतेच्या दायित्वांचे पालन केले पाहिजे. कायदेशीर आधार अतिरिक्त डेटा गोळा करण्याचे किंवा असंबद्ध मार्केटिंगसाठी ठेवलेले रेकॉर्ड वापरण्याचे समर्थन करत नाही.जर एखाद्या व्यक्तीने डेटा पुसून टाकण्याची (erasure) विनंती केली तर काय होते? विनंती प्राप्त करा, योग्य प्रमाणात ओळख सत्यापित करा, डेटा श्रेणी आणि उद्देशानुसार रेकॉर्ड शोधा, आणि सरसकट प्रतिसाद देण्याऐवजी प्रत्येक श्रेणीचा स्वतंत्रपणे निर्णय घ्या. ICO नुसार सामान्य प्रतिसाद वेळ एक महिना आहे. यापुढे आवश्यक नसलेला डेटा पुसून टाका. संमती मागे घेतली असल्यास किंवा संबंधित व्यक्तीने आक्षेप घेतल्यास मार्केटिंग डेटा वापरणे थांबवा. जेथे कायदेशीर बंधन लागू होते किंवा जेथे कायदेशीर दावा सिद्ध करण्यासाठी, वापरण्यासाठी किंवा त्याचे संरक्षण करण्यासाठी डेटा आवश्यक असतो, तेथे मर्यादित सवलतीचे स्पष्टीकरण द्या आणि केवळ त्याद्वारे वाजवी असलेला डेटा ठेवा. बॅकअपचा देखील विचार करणे आवश्यक आहे. लाईव्ह सिस्टम्समधून डेटा डिलीट करा, बॅकअप डेटाचा वापर रोखा आणि ओव्हरराईटचे वेळापत्रक स्पष्ट करा. याचे रूपांतर पॉलिसी PDF मध्ये न करता एका सिस्टममध्ये करा. तुमच्या धारणा वेळापत्रकात (retention schedule) डेटा श्रेणी, उद्देश, नियंत्रक किंवा प्रोसेसर भूमिका, कायदेशीर आधार, डीफॉल्ट कालावधी, डिलीट करण्याची घटना, कायदेशीर-होल्ड ओव्हरराईड आणि मालक यांचे नाव असावे. स्वयंचलित पर्ज (purge) जॉब्स कॉन्फिगर करा. एक स्वतंत्र कायदेशीर-होल्ड संग्रह ठेवा. डिलीट केलेल्या लॉग्जची चाचणी घ्या. DPO ला एक त्रैमासिक अपवाद अहवाल द्या ज्यामध्ये सामान्य कालावधीपेक्षा जास्त काळ ठेवलेल्या गोष्टी आणि त्यामागील कारणे दर्शविली असतील. Purple कॉन्फिगर करण्यायोग्य धारणा कालावधी, स्वयंचलित पर्ज वेळापत्रक आणि प्रवेश व डेटा पुसून टाकण्याच्या विनंत्यांसाठीच्या वर्कफ्लोसह त्या ऑपरेटिंग मॉडेलला समर्थन देऊ शकते. टेनंट इस्टेटसाठी, स्टाफ SSID ऑनबोर्ड करण्यापूर्वी उद्देश आणि भूमिका मॅट्रिक्स वापरा. त्यानंतर तुम्ही टेनंटच्या सूचनांवर प्रक्रिया करत असाल तेथे कलम २८ च्या अटी लागू करा. करारामध्ये दस्तऐवजीकरण केलेल्या सूचना, सुरक्षा, गोपनीय कर्मचारी प्रवेश, सब-प्रोसेसर, हक्क सहाय्य, उल्लंघन आणि DPIA समर्थन, सेवा संपल्यावर परत करणे किंवा डिलीट करणे आणि ऑडिट अधिकार समाविष्ट असावेत. वेगवान प्रश्नांपूर्वी, चार सामान्य अपयश टाळा. पहिले, बॅकअप धारणा कालावधी हा लाईव्ह-डेटा कालावधी म्हणून वापरू नका. बॅकअप हे एक लवचिकता नियंत्रण आहे, सक्रिय प्रोफाइल ठेवण्याचे कारण नाही. दुसरे, प्रत्येक व्हेंडर कॉन्फिगरेशनमध्ये १२ महिन्यांचा आकडा कॉपी करू नका. IPA नोटीस, जर असेल तर, कायदेशीर व्याप्ती निश्चित करते. तिसरे, अतिथी संमती, टेनंट कर्मचारी प्रमाणीकरण आणि सुरक्षा पुरावे एकाच सरमिसळ केलेल्या एक्सपोर्टमध्ये एकत्र करू नका. स्वतंत्र उद्देशामुळे तुम्ही सब्जेक्ट विनंतीला कसा प्रतिसाद देता, तुम्ही टेनंटसोबत कसा करार करता आणि रेकॉर्ड कोण शोधू शकते हे बदलते. चौथे, धारणा वेळापत्रक हे मॅन्युअल काम बनवू नका. जर सुरक्षा प्रमुखाला प्रत्येक तिमाहीच्या शेवटी फोल्डर डिलीट करण्याचे लक्षात ठेवावे लागत असेल, तर ते प्रभावी नियंत्रण नाही. स्वयंचलित पर्ज जॉब्स, समाप्ती तारखांसह अपवाद होल्ड्स आणि सिस्टमने डेटा कधी काढून टाकला किंवा एकत्रित केला हे दर्शवणारा ऑडिट अहवाल वापरा. जेव्हा धारणा कालावधी बदलतो, तेव्हा गोपनीयता माहिती, LIA आणि तांत्रिक टाइमर एकत्र अपडेट करा.तीन जलद उत्तरे. पहिले, आपण अतिथी लॉगिन डेटा एका निश्चित कालावधीसाठी ठेवू शकता का? होय, आपण घोषित उद्दिष्टाच्या तुलनेत अचूक कालावधीचे समर्थन करू शकत असल्यास. दुसरे, IPA अंतर्गत आपल्याला बारा महिन्यांचे कनेक्शन लॉग ठेवणे आवश्यक आहे का? केवळ लागू असलेल्या धारणा नोटीसमध्ये तशी आवश्यकता असेल तरच, आपण फक्त सामायिक WiFi चालवता म्हणून नाही. तिसरे, प्रत्येक भाडेकरूसाठी डेटा प्रोसेसिंग कराराची आवश्यकता असते का? आपण जेथे जेथे त्यांच्या दस्तऐवजीकरण केलेल्या सूचनांवरून भाडेकरू कर्मचार्‍यांच्या डेटावर प्रक्रिया करणारे प्रोसेसर असाल, तेथे आपल्याला Article 28 कराराची आवश्यकता असेल. आपण संयुक्तपणे उद्दिष्टे आणि साधने निर्धारित करत असल्यास, त्याऐवजी Article 26 संयुक्त - नियंत्रक व्यवस्थेचे मूल्यांकन करा. पुढील व्यावहारिक पाऊल म्हणजे आपल्या DPO, नेटवर्क लीड, व्यावसायिक मालक आणि प्रत्येक संबंधित भाडेकरू प्रतिनिधीला एकाच कामकाजाच्या सत्रात एकत्र आणणे. डेटाची यादी करा. भूमिकेची पुष्टी करा. कालावधी निश्चित करा. पर्ज कंट्रोल तयार करा. डेटा हटवण्याच्या (erasure) विनंतीची चाचणी घ्या. आणि कोणत्याही IPA नोटीसला त्वरित पुढे पाठवा (escalate). याद्वारेच आपण अभ्यागतांच्या वर्तनाचा अनिश्चित काळासाठी संग्रह न बनवता आवश्यक नेटवर्क रेकॉर्ड ठेवू शकता. ही माहिती तांत्रिक माहिती आहे, कायदेशीर सल्ला नाही. धोरणावर विसंबून राहण्यापूर्वी आपल्या मालमत्तेची तथ्ये, भाडेकरू करार आणि कोणत्याही वैधानिक नोटीसची पडताळणी करण्यासाठी पात्र सल्लागाराचा सल्ला घ्या.

आमच्या मुख्य मालिकेचा भाग: WiFi Marketing मार्गदर्शक →

सामायिक WiFi ऑपरेटर्ससाठी GDPR डेटा धारणा: आपण अतिथी लॉगिन डेटा आणि नेटवर्क लॉग किती काळ ठेवू शकता

UK GDPR अंतर्गत, ओळखण्यायोग्य गेस्ट WiFi लॉगिन डेटा आणि नेटवर्क लॉग केवळ दस्तऐवजीकरण केलेल्या हेतूसाठी आणि आवश्यकतेपेक्षा जास्त काळ न ठेवता जतन करा. बहुतांश ऑपरेशनल सुरक्षा लॉग हे एका लहान, चाचणी केलेल्या कालावधीचे समर्थन करू शकतात, परंतु हा सार्वत्रिक नियम नाही. १२ महिन्यांचा IPA कालावधी केवळ तेव्हाच लागू होतो जेव्हा एखादी लागू डेटा धारणा नोटीस विशिष्ट डेटा ठेवण्याची आवश्यकता दर्शवते.1 7 9

एक बचावात्मक WiFi डेटा धारणा धोरण काय आहे?

एक बचावात्मक धोरण प्रत्येक डेटा श्रेणीला एका हेतूशी, एका जबाबदार पक्षाशी, एका कायदेशीर आधाराशी, एका धारणा कालावधीशी आणि डेटा काढून टाकण्याच्या एका घटनेशी जोडते. हे Article 5(1)(e) चे ऑपरेशनल प्रकटीकरण आहे: वैयक्तिक डेटा आवश्यकतेपेक्षा जास्त काळ ओळखण्यायोग्य राहू नये. ICO निश्चित कालावधी ठरवून देत नाही. तुम्हाला कालावधीचे समर्थन करावे लागेल, त्याचे दस्तऐवजीकरण करावे लागेल, त्याचे पुनरावलोकन करावे लागेल आणि जेव्हा डेटाची यापुढे आवश्यकता नसेल तेव्हा तो हटवावा लागेल किंवा अनामित (anonymise) करावा लागेल.1

कायदेशीर नोंद. हे तांत्रिक अनुपालन मार्गदर्शन आहे, औपचारिक कायदेशीर सल्ला नाही. धारणा वेळापत्रकावर अवलंबून राहण्यापूर्वी तुमच्या इस्टेट मॉडेल, भाडेकरू करार आणि कोणत्याही IPA नोटीसची पडताळणी करण्यासाठी पात्र कायदेशीर सल्लागाराचा सल्ला घ्या.

सामायिक WiFi ही एक वेगळी अनुपालन समस्या का आहे?

Multi-Tenant WiFi असे स्तर तयार करते जे एकाच ठिकाणच्या गेस्ट नेटवर्कमध्ये नसतात. तुम्ही रहिवासी, सदस्य, अतिथी आणि अभ्यागतांसाठी सामायिक ऍक्सेस स्तर ऑपरेट करत असतानाच भाडेकरू नियोक्त्याला Staff WiFi सेवा देखील प्रदान करू शकता. तुमच्या स्वतःच्या हेतूंसाठी, जसे की नेटवर्क सुरक्षा, सेवा हमी आणि बिलिंग विवाद व्यवस्थापन, तुम्ही नियंत्रक (controller) असू शकता. भाडेकरूच्या दस्तऐवजीकरण केलेल्या सूचनांवरच प्रक्रिया केलेल्या कर्मचाऱ्यांच्या प्रमाणीकरणासाठी, तुम्ही प्रोसेसर (processor) असू शकता. व्यावसायिक करारातील लेबल यावर अंतिम निर्णय ठरवत नाही.

ICO चे म्हणणे आहे की भूमिका विशिष्ट प्रक्रिया क्रियाकलापाचे अनुसरण करते. डेटा का गोळा केला जातो, त्याचा कायदेशीर आधार, डेटा श्रेणी, प्राप्तकर्ते, गोपनीयता माहिती, अधिकारांची हाताळणी किंवा धारणा यावर निर्णय घेणारा पक्ष हा सामान्यतः नियंत्रक असतो. एक प्रोसेसर जोपर्यंत व्यापक निर्णय घेत नाही तोपर्यंत नियंत्रक न बनता तांत्रिक पद्धती, सुरक्षा नियंत्रणे आणि हटवण्याची प्रक्रिया निवडू शकतो. म्हणूनच, एकच डेटा संच हेतू आणि भूमिकेनुसार वेगळा केला जाऊ शकतो. जर दोन्ही पक्ष संयुक्तपणे हेतू आणि माध्यमे निश्चित करत असतील, तर हा संबंध केवळ एक साधी प्रोसेसर सेवा म्हणून मानण्याऐवजी Article 26 च्या संयुक्त-नियंत्रक व्यवस्थेचा वापर करा.4

सामायिक WiFi क्रियाकलाप संभाव्य भूमिका प्रश्न व्यावहारिक नियंत्रण
ऑपरेटरच्या स्वतःच्या नेटवर्कसाठी गेस्ट स्प्लॅश-पेज प्रमाणीकरण ऑपरेटर डेटा संकलन, नोटीस आणि धारणा यावर निर्णय घेतो का? त्या हेतूसाठी ऑपरेटरची नियंत्रक म्हणून नोंद करा.
भाडेकरू कर्मचाऱ्यांचे Staff WiFi प्रमाणीकरण भाडेकरू लोकसंख्या, प्रवेशाचा हेतू आणि धारणा निश्चित करतो का? ऑपरेटर भाडेकरूच्या सूचनांचे पालन करत असल्यास Article 28 च्या अटी वापरा.
भाडेकरूच्या नेतृत्वाखालील एंगेजमेंट मोहीम भाडेकरू प्रेक्षक आणि संदेशाचा उद्देश निवडतो का? स्वतंत्र आधाराशिवाय ऑपरेटर मार्केटिंगसाठी पुनर्वापरास प्रतिबंध करा.

हा विश्लेषणात्मक अभ्यास विशेषतः Hospitality, Retail, Healthcare आणि Transport इस्टेट्ससाठी महत्त्वाचा आहे, जेथे सामायिक नेटवर्क एकाच इमारतीतील अनेक स्वतंत्र व्यवसायांना सेवा देऊ शकते.

तुम्ही 5 WiFi डेटा श्रेणींचे वर्गीकरण कसे करावे?

कनेक्शन मेटाडेटा मध्ये नियुक्त केलेला IP पत्ता, स्त्रोत MAC पत्ता, सत्र सुरू होण्याची आणि संपण्याची वेळ, ट्रान्सफर केलेले बाइट्स, DHCP लीज रेकॉर्ड आणि RADIUS अकाउंटिंग समाविष्ट आहे. एका नामांकित लॉगिन सेवेवर, हे फील्ड सामान्यतः वैयक्तिक डेटा असतील कारण ते एखाद्या व्यक्तीशी जोडले जाऊ शकतात. परिभाषित सुरक्षा आणि समस्येचे निवारण (troubleshooting) करण्याच्या उद्देशासाठी आवश्यक असलेले फील्ड ठेवा. सूचित केलेली ३० ते ९० दिवसांची कार्यरत विंडो हे केवळ एक सुरुवातीचे धोरण आहे, वैधानिक सुरक्षित आश्रयस्थान (safe harbour) नाही. तुमच्या घटनेचा शोध घेण्याची वेळ, थ्रेट मॉडेल आणि तपास करण्याची क्षमता यावर मंजूर कालावधी ठरवला पाहिजे.1 6

अतिथी प्रमाणीकरण डेटा (Guest authentication data) मध्ये ईमेल पत्ता, नाव, फोन नंबर आणि ऑथेंटिकेशन आयडेंटिफायर समाविष्ट असतो. जर तुम्ही तो केवळ एखाद्या व्यक्तीला Guest WiFi मध्ये प्रवेश देण्यासाठी गोळा करत असाल, तर प्रवेशाचा उद्देश सत्रासह संपतो. केवळ तुम्ही स्पष्टीकरण देऊ शकता अशा ठिकाणीच अल्प, दस्तऐवजीकरण केलेला वाद किंवा फसवणूक संबंधित पुरावा राखून ठेवा. तुम्ही जाणीवपूर्वक निवडलेला मार्केटिंग ऑप्ट-इन देखील गोळा करत असल्यास, मार्केटिंग रेकॉर्ड प्रवेश डेटापासून वेगळा करा. संमती मागे घेतली जाऊ शकते, तर इलेक्ट्रॉनिक मार्केटिंगचे स्वतःचे नियम देखील असतात. संमती मागे घेतल्यावर किंवा आक्षेप घेतल्यावर, मार्केटिंग थांबवा आणि निवडीचा आदर करण्यासाठी आवश्यक असलेली केवळ किमान सप्रेशन माहिती राखून ठेवा.2 6

स्थान आणि उपस्थिती डेटा (Location and presence data) मध्ये मूळ ओळखण्यायोग्य मार्ग (raw identifiable trails) आणि एकत्रित परिणाम (aggregate outputs) यामध्ये स्पष्ट फरक असणे आवश्यक आहे. जर तुम्ही एखादा टोकन पुन्हा लॉगिनशी जोडू शकत असाल तर तो अनामित (anonymous) राहत नाही. ICO चे म्हणणे आहे की छद्मनाव दिलेला (pseudonymised) डेटा सामान्यतः वैयक्तिक डेटाच राहील, तर ज्या डेटामुळे ओळख पटवणे शक्य नाही तो साठवणूक मर्यादा नियमाच्या बाहेर राखून ठेवला जाऊ शकतो. ३० दिवसांचा मूळ-ट्रेस कालावधी आणि त्यानंतर अपरिवर्तनीय एकत्रीकरण (irreversible aggregation) हे एक समजूतदार धोरण आहे जेथे तुम्हाला अल्पकालीन ऑपरेशनल विश्लेषणाची आवश्यकता असते. एकत्रीकरण पद्धतीचे दस्तऐवजीकरण करा आणि पुन्हा ओळख पटवणे शक्य आहे का याची चाचणी घ्या.1 मार्केटिंग कम्युनिकेशन्स इतिहासामध्ये सेंड्स, ओपन्स, क्लिक्स आणि पसंतींमधील बदल समाविष्ट असतात. सिक्युरिटी-लॉग टाइमर वारसा म्हणून घेऊ नका. लागू होणाऱ्या कायदेशीर आधारावर, दस्तऐवजीकरण केलेल्या पुनरावलोकन तारखेसह केवळ नमूद केलेल्या मार्केटिंग हेतूसाठी ते राखून ठेवा. खालील २४ महिन्यांचा पुनरावलोकन बिंदू हा सुचवलेला ऑपरेटिंग मर्यादेचा कालावधी आहे, ICO ची अंतिम मुदत नाही. केवळ संबंधित व्यक्तीने संमती मागे घेतली नाही म्हणून कधीही एंगेजमेंट प्रोफाईल राखून ठेवू नका. संमती मागे घेतल्यास, जोपर्यंत स्वतंत्र, दस्तऐवजीकरण केलेली आवश्यकता लागू होत नाही तोपर्यंत मार्केटिंग इतिहास मिटवा किंवा तो अनामित करा. ऑप्ट-आऊट सप्रेशन नोंद वेगळी असते: ती पुढील संदेश जाण्यापासून रोखते.2 6

अब्युज आणि सिक्युरिटी लॉग्समध्ये फायरवॉल डिनायल्स, DNS सुरक्षा इव्हेंट्स आणि RADIUS अकाउंटिंग समाविष्ट असू शकते. नेटवर्क आणि माहिती सुरक्षा वैध हितसंबंधांना (legitimate interests) समर्थन देऊ शकते, परंतु ते आपोआप असे करत नाही. धारणा कालावधी सुरू करण्यापूर्वी हेतू, आवश्यकता आणि संतुलन चाचण्या पूर्ण करा. ३६५ दिवसांचे वेळापत्रक अशा ठिकाणी न्याय्य ठरू शकते जेथे सामायिक सार्वजनिक IP पत्त्याचा अर्थ असा आहे की विलंबित घटना, दावा किंवा सबपोना हाताळण्यासाठी तुम्हाला विशेषता पुराव्याची आवश्यकता आहे. हा GDPR चा किमान निकष नाही. आर्किटेक्चर किंवा जोखीम बदलल्यास फील्ड कमी करा, प्रवेश प्रतिबंधित करा, शोध लॉग करा आणि वैध हितसंबंधांच्या मूल्यांकनाचे पुनरावलोकन करा.1 6

सामायिक WiFi ऑपरेटर्ससाठी GDPR डेटा धारणा: आपण अतिथी लॉगिन डेटा आणि नेटवर्क लॉग किती काळ ठेवू शकता - retention decision flow

निर्णय प्रवाह: स्वयंचलित पर्ज नियम सेट करण्यापूर्वी ओळखण्याची क्षमता, भूमिका, कायदेशीर आधार आणि कोणतीही वैधानिक सूचना निश्चित करा.

तुम्ही कोणते धारणा वेळापत्रक स्वीकारू शकता?

खालील वेळापत्रक हे UK मधील सामायिक WiFi इस्टेटसाठी तयार केलेले मूळ बेसलाइन आहे. हे मुद्दाम हेतूनुसार विभागलेले आहे. नियंत्रकाने (controller) इस्टेटसाठी हेतू, कायदेशीर आधार आणि जोखीम मूल्यमापन दस्तऐवजीकरण केल्यानंतरच याचा अवलंब करा. IPA नोटीस, कायदेशीर होल्ड किंवा सक्रिय दावा सामान्य पर्ज तारखेला ओव्हरराइड करू शकतो, परंतु केवळ विशिष्ट रेकॉर्ड्स आणि अपवाद समर्थित करणाऱ्या कालावधीसाठीच.1 7 9

डेटा प्रवर्ग हेतू आणि कायदेशीर आधार सुचवलेले डीफॉल्ट धारणा हटवणे किंवा बदलण्याचा इव्हेंट
कनेक्शन मेटाडेटा आणि DHCP किंवा RADIUS सेशन डेटा नेटवर्क सुरक्षा आणि त्रुटी तपासणी - कलम 6(1)(f), LIA च्या अधीन ९० दिवस एखादी मंजूर घटना किंवा कायदेशीर होल्ड लागू नसल्यास ९० व्या दिवशी पर्ज करा.
गेस्ट ॲक्सेस ऑथेंटिकेशन डेटा गेस्ट ॲक्सेस प्रदान करणे आणि लहान वाद सोडवणे - डिझाइननुसार कलम 6(1)(b) किंवा 6(1)(f) सेशन संपल्यानंतर ३० दिवस ३० व्या दिवशी ओळखण्यायोग्य ॲक्सेस डेटा मिटवा.
मूळ ओळखण्यायोग्य लोकेशन ट्रेसेस अल्पकालीन ऑपरेशनल विश्लेषण - कलम 6(1)(f), LIA च्या अधीन ३० दिवस ३० व्या दिवशी अपरिवर्तनीयपणे एकत्रित करा किंवा मिटवा.
मार्केटिंग संपर्क आणि एंगेजमेंट इतिहास संमती किंवा अन्य दस्तऐवजीकरण केलेला मार्केटिंग आधार मागे घेणे, आक्षेप घेणे किंवा २४ महिन्यांचे पुनरावलोकन, यापैकी जे आधी घडेल ते प्रोफाईल मिटवा किंवा अनामित करा. आवश्यकतेनुसार केवळ किमान सप्रेशन रेकॉर्ड राखून ठेवा.
Security and abuse evidence Network security, defence of claims or an applicable legal duty 365 days only where the LIA documents the shared-address attribution need Purge at day 365 unless a specific hold or legal obligation applies.
Data specified in a valid IPA retention notice Compliance with the notice - Article 6(1)(c) Exact notice period, capped at 12 months Purge when notice-specific period ends, unless another documented basis applies.

९०-दिवसांचा कनेक्शन कालावधी आणि ३६५-दिवसांचा गैरवापर कालावधी हे पॉलिसीचे पर्याय आहेत, अनिवार्य आकडे नाहीत. जेव्हा तुमचे लिखित LIA, गोपनीयता नोटीस, सिस्टम पुरावे आणि स्वयंचलित हटवण्याची रचना हे सर्व जुळतात तेव्हाच ते उपयुक्त ठरतात. सार्वजनिक प्राधिकरणाने ते सार्वजनिक कार्य करत आहेत की नाही हे देखील तपासले पाहिजे, कारण ते त्या कार्यासाठी कायदेशीर हितसंबंधांवर अवलंबून राहू शकत नाहीत.6

तुमच्या विशिष्ट सेटअपबद्दल काही प्रश्न आहेत का?

आमची टीम ८०,००० हून अधिक वेन्यूजमधील वेन्यू ऑपरेटर्स, IT मॅनेजर्स आणि नेटवर्क इंजिनिअर्ससोबत काम करते. २० मिनिटांचा कॉल बुक करा आणि तुमच्यासारख्या इतरांनी ही समस्या कशी सोडवली हे आम्ही तुम्हाला दाखवू.

IPA ने सामायिक WiFi ऑपरेटरला १२ महिन्यांसाठी लॉग्स राखून ठेवण्याची आवश्यकता आहे का?

नाही, डीफॉल्टनुसार नाही. टेलिकम्युनिकेशन ऑपरेटरची IPA व्याख्या व्यापक आहे. सरकारचा २०२५ चा नोटीस कोड सांगतो की यामध्ये अशा व्यक्तीचा समावेश असू शकतो जो अतिथींना किंवा जनतेला दळणवळण सेवांचा प्रवेश प्रदान करतो जो दुसऱ्या सेवेसाठी पूरक आहे, ज्यामध्ये हॉटेल्ससारख्या व्यावसायिक आवारांचा समावेश आहे. यामुळे हा विषय MDU, को-वर्किंग किंवा व्यवस्थापित WiFi ऑपरेटरसाठी सुसंगत ठरतो.8 9

पण तोच कोड स्पष्ट करतो की डीफॉल्ट स्थिती ही आहे की डेटा रिटेंशन नोटीस मिळेपर्यंत कायद्यांतर्गत कोणतीही रिटेंशन ड्युटी नाही. IPA कलम ८७ अंतर्गत, गृहसचिव केवळ तेव्हाच नोटीस जारी करू शकतात जेव्हा ही आवश्यकता आवश्यक आणि प्रमाणशीर असेल आणि ज्युडिशियल कमिशनरने त्यास मान्यता दिली असेल. नोटीसमध्ये ऑपरेटर, डेटा आणि कालावधी निश्चित करणे आवश्यक आहे. यासाठी १२ महिन्यांपेक्षा जास्त काळ राखून ठेवण्याची आवश्यकता असू शकत नाही. केवळ सेवा टेलिकम्युनिकेशन ऑपरेटरच्या व्यापक व्याख्येशी जुळत असल्यामुळे जेनेरिक "सर्व काही १२ महिन्यांसाठी ठेवा" असे धोरण तयार करू नका.7 9

जिथे वैध नोटीस कायदेशीर बंधन तयार करते, तिथे Article 6(1)(c) पालन करण्यासाठी आवश्यक असलेल्या प्रक्रियेसाठी UK GDPR कायदेशीर आधार प्रदान करू शकते. तो करारजन्य आधार नाही. ICO चे म्हणणे आहे की तुम्ही विशिष्ट कायदेशीर तरतूद ओळखली पाहिजे, निर्णयाचे दस्तऐवजीकरण केले पाहिजे आणि गोपनीयता माहितीमध्ये उद्देश आणि कायदेशीर आधार स्पष्ट केला पाहिजे. नोटीस दुय्यम मार्केटिंग वापर किंवा अमर्याद संकलनास अधिकृत करत नाही.3

Article 28 भाडेकरू करारामध्ये काय समाविष्ट असणे आवश्यक आहे?

तुम्ही केवळ भाडेकरूच्या दस्तऐवजीकरण केलेल्या सूचनांवर भाडेकरू कर्मचाऱ्यांच्या डेटावर प्रक्रिया करत असल्यास, ती प्रक्रिया सुरू होण्यापूर्वी Article 28 डेटा प्रोसेसिंग करार अस्तित्वात असणे आवश्यक आहे. करारामध्ये विषय आणि कालावधी, स्वरूप आणि उद्देश, डेटाचे प्रकार, डेटा-विषय श्रेणी आणि नियंत्रकाचे अधिकार आणि कर्तव्ये यांचे वर्णन केले पाहिजे. त्यानंतर त्यात खालील ऑपरेशनल वचनबद्धता असणे आवश्यक आहे.5

Article 28 obligation What to make operational on Staff WiFi
Documented instructions Store the tenant’s approved authentication, retention and disclosure instructions.
गोपनीयता आणि सुरक्षा विशेषाधिकारप्राप्त प्रवेश मर्यादित करा, प्रशासकीय प्रवेश एनक्रिप्ट करा आणि भूमिका-आधारित ऑडिट लॉग ठेवा.
उप-प्रोसेसर संबंधित उप-प्रोसेसर बदलांबद्दल भाडेकरूला सूचित करा आणि समतुल्य संरक्षण लागू करा.
हक्कांचे सहाय्य प्रवेश, दुरुस्ती, मिटवणे आणि आक्षेप घेण्याच्या विनंत्यांसाठी हँड-ऑफ परिभाषित करा.
उल्लंघन आणि DPIA समर्थन घटना अधिसूचना मार्ग आणि सुरक्षा-मूल्यांकन सहाय्य सेट करा.
करार संपुष्टात आल्यावर परत करणे किंवा हटवणे परत करणे किंवा सुरक्षित हटवणे निवडा, जिथे युके कायद्यानुसार एखादी विशिष्ट नोंद ठेवणे आवश्यक आहे ते वगळता.
ऑडिट आणि पुरावा अनुपालन सिद्ध करण्यासाठी आवश्यक असलेली माहिती आणि ऑडिट प्रवेश प्रदान करा.

संयुक्त-नियंत्रक व्यवस्था लपवण्यासाठी कलम 28 कराराचा वापर करू नका. कर्मचारी विश्लेषण का वापरले जाईल, कोणते फील्ड गोळा केले जातात आणि ते किती काळ उपलब्ध राहतील हे जर ऑपरेटर आणि भाडेकरू संयुक्तपणे ठरवत असतील, तर त्याऐवजी कलम 26 चे मूल्यांकन करा.4

तुम्ही मिटवण्याची विनंती कशी हाताळली पाहिजे?

कलम 17 मिटवणे (erasure) हे एका क्लिकवर हटवण्याचे कार्य नाही. प्रमाणबद्ध ओळख तपासणीने सुरुवात करा. नंतर हेतू आणि भूमिकेनुसार डेटा शोधा: अतिथी प्रवेश, विपणन, सुरक्षा, भाडेकरू सूचना आणि कोणतीही नोटीस-विशिष्ट धारणा (retention). ICO चे म्हणणे आहे की आपण विनाकारण उशीर न करता आणि जास्तीत जास्त एका महिन्याच्या आत प्रतिसाद दिला पाहिजे. जिथे डेटा आता आवश्यक नाही, किंवा संमती मागे घेतली गेली आहे, तो थेट रेकॉर्डमधून मिटवा आणि आवश्यक असेल तिथे संबंधित प्राप्तकर्त्यांना सूचित करा.2

जिथे कायदेशीर बंधन लागू होते, किंवा कायदेशीर दाव्यांच्या स्थापनेसाठी, वापरासाठी किंवा संरक्षणासाठी डेटा आवश्यक असतो, तिथे मिटवण्याचा अधिकार त्या मर्यादेपर्यंत लागू होत नाही. मर्यादित कारण स्पष्टपणे सांगा. राखून ठेवलेला डेटा वेगळा ठेवा, असंबंधित वापर रोखा आणि संबंधित समाप्ती तारीख लागू करा. बॅकअपसाठी स्पष्ट उत्तराची आवश्यकता असते: जिथे व्यवहार्य असेल तिथे हटवण्याच्या प्रक्रियेमध्ये बॅकअप देखील समाविष्ट असावा. त्वरित ओव्हरराइट करणे अशक्य असल्यास, बॅकअप रेकॉर्ड वापराबाहेर ठेवा आणि ओव्हरराइटचे वेळापत्रक उघड करा.2

सामायिक WiFi ऑपरेटर्ससाठी GDPR डेटा धारणा: आपण अतिथी लॉगिन डेटा आणि नेटवर्क लॉग किती काळ ठेवू शकता - data erasure request wo…

मिटवण्याच्या वर्कफ्लोमध्ये हटवायचा डेटा आणि दस्तऐवजीकरण केलेल्या अपवादाअंतर्गत राखून ठेवलेल्या मर्यादित नोंदी एकमेकांपासून वेगळ्या केल्या पाहिजेत.

वास्तविक ठिकाणी हे कसे कार्य करते?

आदरातिथ्य परिस्थिती: अतिथी प्रवेश आणि भाडेकरू कर्मचारी प्रवेश असलेले हॉटेल

एक 200 खोल्यांचे हॉटेल अभ्यागतांसाठी Guest WiFi चालवते आणि त्याच्या रेस्टॉरंट भाडेकरूला Staff WiFi SSID पुरवते. हॉटेल प्रक्रियेच्या दोन वेगवेगळ्या नोंदी लिहिते. हे अतिथी प्रमाणीकरण, 90 दिवसांचा कनेक्शन डेटा आणि सुरक्षा तपासणीसाठी नियंत्रक म्हणून कार्य करते. रेस्टॉरंट त्याच्या कर्मचाऱ्यांची संख्या, प्रवेश अटी आणि त्यांच्या Staff SSID साठी धारणा निश्चित करते, म्हणून हॉटेल त्या प्रक्रियेला कलम 28 च्या अटी लागू करते. मोजता येण्याजोगे नियंत्रण म्हणजे मासिक अहवाल जो दर्शवतो की 90 दिवसांपेक्षा जुने प्रत्येक अतिथी सत्र काढून टाकले गेले आहे, तर कोणत्याही अपवादासाठी घटना किंवा नोटीस संदर्भ आहे.

किरकोळ विक्री परिस्थिती: एका सार्वजनिक पत्त्यावरील खरेदीचे ठिकाण

एक रिटेल डेस्टिनेशन अनेक युनिट्समध्ये एकच पब्लिक इग्रेस ॲड्रेस वापरते. सुरक्षा एलआयए (LIA) हे नोंदवून ठेवते की उशिराने केलेल्या गैरवर्तनाच्या आरोपांना विशिष्ट कनेक्शनशी जोडणे का आवश्यक असू शकते. हे ३६५ दिवसांचे सुरक्षा-पुरावा वेळापत्रक सेट करते, परंतु एकत्रीकरण (aggregation) करण्यापूर्वी ३० दिवसांसाठी मूळ ओळखण्यायोग्य लोकेशन ट्रेल्स सुरक्षित ठेवते. याचे मोजता येण्याजोगे नियंत्रण म्हणजे त्रैमासिक एलआयए (LIA) पुनरावलोकन आणि सुरक्षेचा कालावधी संपलेल्या मूळ लोकेशन डेटाचा वापर न करता एका विशिष्ट परवानगीप्राप्त घटनेची पुनर्रचना एका सुरक्षा विश्लेषकाद्वारे केली जाऊ शकते की नाही याची चाचणी घेणे.

इव्हेंट्स सिनेरिओ: प्रायोजक-मालकीच्या ऑडिअन्ससह कॉन्फरन्सचे ठिकाण

एक कॉन्फरन्स सेंटर उपस्थितांना प्रवेश प्रदान करते तर प्रायोजक स्वतंत्रपणे ब्रँड केलेल्या प्रवासांद्वारे ऑप्ट-इन्स गोळा करतात. हे ठिकाण सेवा आणि सुरक्षा डेटासाठी कंट्रोलर राहते. प्रत्येक प्रायोजक स्वतःच्या मार्केटिंग हेतूवर नियंत्रण ठेवतो आणि त्याला केवळ तेच ऑप्ट-इन्स मिळायला हवेत जे वापरण्याचा त्याला अधिकार आहे. याचे मोजता येण्याजोगे नियंत्रण म्हणजे एका प्रायोजकाच्या प्रवासात ऑप्ट-इन काढून घेतल्यास त्या विशिष्ट प्रायोजकाचे संभाषण थांबवले जाते की नाही याची इव्हेंट-पूर्व चाचणी घेणे, ज्यामुळे त्या ठिकाणचा सुरक्षित ठेवलेला सुरक्षा पुरावा नष्ट होणार नाही.

तुम्ही पुढे काय करावे?

पॉलिसी टेम्पलेटऐवजी ६० मिनिटांच्या रिटेंशन वर्कशॉपने सुरुवात करा. तुमच्या डीपीओ (DPO), नेटवर्क आर्किटेक्ट, ठिकाणाचे ऑपरेशन्स लीड आणि प्रत्येक संबंधित भाडेकरू प्रतिनिधीला एकत्र आणा. स्प्लॅश पेज, DHCP, RADIUS, फायरवॉल, DNS आणि ॲनालिटिक्स घटकांकडून येणाऱ्या फील्ड्सचा एक टेबल तयार करा. प्रत्येक फील्डसाठी हेतू, कंट्रोलर किंवा प्रोसेसरची भूमिका, कायदेशीर आधार, रिटेंशन टाइमर, डिलीशन ॲक्शन, ऑडिट मालक आणि कायदेशीर होल्ड प्रक्रिया निश्चित करा.

त्यानंतर काम पूर्ण करण्यासाठी सिस्टम कॉन्फिगर करा. Purple कॉन्फिगर करण्यायोग्य रिटेंशन कालावधी, स्वयंचलित पर्ज शेड्यूल्स, ऍक्सेस-रिक्वेस्ट टूलींग आणि इरेजर वर्कफ्लो प्रदान करते जे या ऑपरेटिंग मॉडेलला समर्थन देतात. तुमचे Guest WiFi वातावरण कोणत्याही भाडेकरूच्या स्टाफ WiFi च्या हेतूंपासून वेगळे ठेवा. जिथे तुम्ही WiFi Analytics वापरता, तिथे ओळखण्यायोग्य रिटेंशन विंडो संपण्यापूर्वी डेटा एकत्रित किंवा डि-आयडेंटिफाय करा. क्लाउड ओव्हरलेने संपूर्ण वितरित मालमत्तेवर सातत्याने पॉलिसी लागू करणे सोपे केले पाहिजे, डिफॉल्टनुसार रेकॉर्डचे आयुष्य वाढवू नये.

संबंधित नियंत्रणांसाठी, या डेटा-रिटेंशन डिझाइनची तुलना Hardening RADIUS against MD5 collision attacks (BlastRADIUS), Privacy by design: anonymising WiFi data for GDPR compliance आणि MDU WiFi tenant session tracking and abuse attribution सोबत करा. अधिक व्यापक संदर्भासाठी, The definitive timeline of WiFi: from ALOHAnet to WiFi 7 and beyond, Guest WiFi Management: Smart Authentication & Segmentation, Cloud Wifi Management: Secure Enterprise Connectivity 2026 आणि Purple appoints Imani Butler as Growth Director, North America पहा.

वारंवार विचारले जाणारे प्रश्न

GDPR अंतर्गत मी अतिथी WiFi लॉगिन डेटा किती काळ ठेवू शकतो?

प्रवेश, विवाद, सुरक्षितता किंवा इतर नमूद हेतू आवश्यक असेपर्यंतच तो ठेवा. केवळ-प्रवेश प्रमाणीकरणासाठी व्यावहारिक सुरुवात म्हणजे सत्र संपणे अधिक ३० दिवसांसारखा एक लहान दस्तऐवजीकरण केलेला विवाद कालावधी. हा एक पॉलिसी पर्याय आहे, GDPR नियम नाही. हेतू, कायदेशीर आधार आणि डेटा हटवण्याची घटना नोंदवा, नंतर डेटा पूर्णपणे काढून टाकण्याची चाचणी घ्या.

UK Investigatory Powers Act साठी १२ महिन्यांचे WiFi कनेक्शन रेकॉर्ड ठेवणे आवश्यक आहे का?

नाही. IPA प्रत्येक सामायिक WiFi ऑपरेटरसाठी स्वयंचलित १२ महिन्यांचे बंधन तयार करत नाही. डेटा संचयनाचे बंधन केवळ तेव्हाच सुरू होते जेव्हा लागू डेटा संचयन नोटीस दिली जाते. नोटीस संबंधित संप्रेषण डेटा आणि संचयन कालावधी परिभाषित करते, जो १२ महिन्यांपेक्षा जास्त असू शकत नाही. आपल्याला अशी नोटीस मिळाल्यास त्वरित तज्ञांचा सल्ला घ्या.7 9

स्टाफ WiFi वरील भाडेकरूच्या कर्मचाऱ्यांसाठी मी कंट्रोलर आहे की प्रोसेसर?

हे प्रक्रिया क्रियाकलापावर अवलंबून असते. जर भाडेकरूने कर्मचारी संख्या, हेतू, नोटीस, हक्क हाताळणी आणि संचयन निश्चित केले आणि आपण दस्तऐवजीकरण केलेल्या सूचनांवर सेवा चालवत असाल, तर आपण त्या क्रियाकलापासाठी प्रोसेसर असण्याची दाट शक्यता आहे. जर आपण स्वतःच्या हेतूसाठी ते निर्णय घेत असाल, तर आपण कंट्रोलर आहात. जिथे दोन्ही बाजू संयुक्तपणे आवश्यक हेतू आणि साधने ठरवतात, तिथे संयुक्त कंट्रोलरशिपचे मूल्यांकन करा.4

सामायिक WiFi नेटवर्कवरील IP-address लॉग्जसाठी योग्य संचयन कालावधी काय आहे?

यासाठी कोणताही विहित UK GDPR कालावधी नाही. नमूद केलेल्या सुरक्षा आणि ट्रबलशूटिंगच्या गरजेनुसार एक प्रमाणबद्ध कालावधी निश्चित करा. हे मार्गदर्शक कनेक्शन मेटाडेटासाठी ९० दिवस हा सुचवलेला डीफॉल्ट कालावधी वापरते. केवळ तिथेच ३६५ दिवसांपर्यंत वाढवा जिथे दस्तऐवजीकरण केलेले LIA खऱ्या सामायिक-पत्ता विशेषता किंवा दाव्यांच्या गरजेला समर्थन देते, ज्यामध्ये फील्ड मिनिमायझेशन आणि प्रवेश नियंत्रणे समाविष्ट असतील.1 6

जेव्हा माझ्याकडे ट्रॅफिक डेटा ठेवण्याचे कायदेशीर बंधन असते तेव्हा मी डेटा हटवण्याच्या (erasure) विनंतीचे काय करावे?

जे रेकॉर्ड आता आवश्यक नाहीत ते हटवा, परंतु कायदेशीर बंधनासाठी आवश्यक असलेला मर्यादित डेटा आणि कालावधीच संचयित ठेवा. एका महिन्याच्या आत प्रतिसाद द्या, लागू असलेली सूट स्पष्ट करा आणि संचयित डेटाचा असंबंधित हेतूंसाठी वापर होण्यापासून रोखा. बॅकअपसाठी देखील हाच निर्णय लागू करा, एकतर ते हटवून किंवा शेड्यूल केलेल्या ओव्हरराईट होईपर्यंत ते वापराबाहेर ठेवून.2 3

मला प्रत्येक भाडेकरू संस्थेसोबत DPA ची आवश्यकता आहे का?

जेव्हा जेव्हा आपण भाडेकरूच्या कर्मचाऱ्यांच्या डेटावर त्या भाडेकरूच्या दस्तऐवजीकरण केलेल्या सूचनांनुसार प्रक्रिया करता, तेव्हा आपल्याला कलम २८ डेटा प्रोसेसिंग कराराची (DPA) आवश्यकता असते. केवळ आपण एकाच इमारतीमध्ये आहोत म्हणून आपल्याला त्याची आवश्यकता नसते. जर दोन्ही बाजू मिळून हेतू आणि आवश्यक साधने ठरवत असतील, तर त्याऐवजी कलम २६ मधील संयुक्त-कंट्रोलर व्यवस्थेची आवश्यकता असू शकते.4 5

अतिथीने संमती काढून घेईपर्यंत मी मार्केटिंग इतिहास ठेवू शकतो का?

नाही. सक्रिय संमती स्टोरेज-मर्यादेचे बंधन काढून टाकत नाही. मार्केटिंगच्या इतिहासासाठी पुनरावलोकन कालावधी निश्चित आणि दस्तऐवजीकरण करा, जसे की २४-महिन्यांचे पुनरावलोकन, आणि नमूद केलेल्या हेतूसाठी यापुढे उपयुक्त नसलेला डेटा काढून टाका किंवा त्याची ओळख मिटवून टाका. संमती मागे घेतल्यास किंवा आक्षेप घेतल्यास, मार्केटिंग थांबवा आणि त्या निर्णयाचा आदर करण्यासाठी आवश्यक असलेला किमान दमन (suppression) डेटाच केवळ राखून ठेवा.1 2

References

महत्वाच्या व्याख्या

स्टोरेज मर्यादा

Article 5(1)(e) चे तत्व ज्यानुसार ओळखण्यायोग्य वैयक्तिक डेटा त्याच्या प्रक्रियेच्या उद्देशासाठी आवश्यकतेपेक्षा जास्त काळ न ठेवणे आवश्यक आहे.

ब्लँकेट लॉग-धारणा नियमाऐवजी प्रत्येक WiFi रेकॉर्ड प्रकारासाठी मंजूर टायमरचे समर्थन करण्यासाठी याचा वापर करा.

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

नेटवर्क प्रवेश सत्राविषयीचा डेटा, जसे की IP पत्ता, डिव्हाइस अभिज्ञापक, सत्र वेळ, DHCP lease आणि RADIUS accounting रेकॉर्ड.

जेव्हा आपण सत्राला एखाद्या नामांकित व्यक्तीशी जोडू शकता तेव्हा तो वैयक्तिक डेटा बनू शकतो.

DHCP lease

नेटवर्कवरील डिव्हाइसला IP पत्ता नियुक्त करणारी वेळ-मर्यादित नोंद.

हे त्रुटी तपासणी आणि गुणविशेषणास समर्थन देते, परंतु त्याचे स्वतःचे धारणा विश्लेषण असावे.

RADIUS accounting

जेव्हा एखादे डिव्हाइस नेटवर्कमध्ये प्रवेश करते तेव्हा तयार केलेल्या प्रमाणीकरण, अधिकृतता आणि अकाउंटिंग नोंदी.

सामायिक WiFi तपासणीमध्ये आवश्यक असलेल्या ओळख-ते-सत्र पुराव्यासाठी हे सहसा केंद्रस्थानी असते.

टोपणनाव (Pseudonymisation)

एक तंत्र जे डेटाला टोकन किंवा कोडसह बदलून थेट ओळख कमी करते तर पुनर्-ओळख लिंक शक्य राहते.

हे एक सुरक्षा कवच आहे, GDPR धारणा कर्तव्यांतून आपोआप सुटका नाही.

अनामितीकरण (Anonymisation)

एक रूपांतरण ज्यामुळे व्यावहारिकरित्या ओळखणे यापुढे शक्य राहत नाही.

मूळ कार्यरत कालावधीनंतर याचा वापर करा जेव्हा आपल्याला केवळ एकत्रित WiFi विश्लेषणाची आवश्यकता असते.

कायदेशीर हितसंबंध मूल्यांकन

Article 6(1)(f) प्रक्रियेच्या हेतूसाठी दस्तऐवजीकरण केलेले उद्दिष्ट, आवश्यकता आणि समतोल विश्लेषण.

किमान कार्यात्मक गरजेपलीकडे सुरक्षा लॉग ठेवण्यापूर्वी हे पूर्ण करा.

डेटा धारणा नोटीस

एक IPA कलम ८७ नोटीस ज्यामध्ये निर्दिष्ट दूरसंचार ऑपरेटरने निर्दिष्ट संबंधित संप्रेषण डेटा एका विशिष्ट कालावधीसाठी ठेवणे आवश्यक आहे.

हे कायदेशीर-जबाबदारीचा आधार तयार करू शकते, परंतु हे प्रत्येक अतिथी WiFi ऑपरेटरसाठी स्वयंचलित कर्तव्य नाही.

Article 28 डेटा प्रक्रिया करार

नियंत्रकाच्या दस्तऐवजीकरण केलेल्या सूचनांवर प्रोसेसरद्वारे केलेल्या प्रक्रियेचे नियमन करणारा करार.

भाडेकरू स्टाफ WiFi प्रक्रियेसाठी याचा वापर करा जेथे भाडेकरू का आणि कसे यावर नियंत्रण ठेवतो.

कायदेशीर होल्ड

एका विशिष्ट तपासणी, दावा किंवा कायदेशीर बंधनासाठी आवश्यक असलेल्या नोंदी डिलीट करण्यापासून रोखणारा एक दस्तऐवजीकरण केलेला, मर्यादित वेळेचा अपवाद.

याने केवळ संबंधित पर्ज नियम निलंबित केला पाहिजे, सर्व ऐतिहासिक WiFi डेटा जतन करू नये.

सोडवलेली उदाहरणे

एक २०० खोल्यांचे हॉटेल अतिथी WiFi आणि त्याच्या रेस्टॉरंट भाडेकरूसाठी स्टाफ WiFi SSID चालवते. त्याने धारणा निर्णय कसे वेगळे केले पाहिजेत?

दोन प्रक्रियेच्या नोंदी तयार करा. हॉटेल अतिथी प्रमाणीकरण, ९०-दिवसांचा कनेक्शन डेटा आणि स्वतःच्या सुरक्षा तपासासाठी नियंत्रक म्हणून काम करते. रेस्टॉरंट कर्मचाऱ्यांचे उद्दिष्ट, लोकसंख्या आणि धारणा सेट करते, त्यामुळे हॉटेल Article 28 च्या अटींनुसार कार्य करते. मासिक पर्ज रिपोर्ट आणि प्रत्येक अपवादासाठी नोंदवलेल्या कारणासह अनुपालन सिद्ध करा.

एक रिटेल डेस्टिनेशन अनेक युनिट्समध्ये एकच सार्वजनिक इग्रेस पत्ता वापरते. स्थान मागोवा अनिrestricted काळासाठी न ठेवता ते गैरवर्तणुकीचे पुरावे कसे जतन करू शकते?

LIA मध्ये विशेषता गरजेची दस्तऐवजीकरण करा, सुरक्षा पुरावे आवश्यक फील्ड्सपुरते मर्यादित करा आणि सामायिक-पत्ता संदर्भ जिथे समर्थन करतो तिथेच ३६५-दिवसांचे पुनरावलोकन करण्यायोग्य गैरवर्तन-लॉग धोरण सेट करा. मूळ ओळखण्यायोग्य स्थान मागोवा ३० दिवसांसाठी ठेवा, त्यानंतर ते अपरिवर्तनीयपणे एकत्रित करा किंवा मिटवून टाका. परवानगी दिलेल्या घटनेच्या परिस्थितीनुसार त्रैमासिक या प्रक्रियेची चाचणी घ्या.

प्रायोजक स्वतंत्र ब्रँडेड ऑप्ट-इन्स गोळा करत असताना एक कॉन्फरन्स सेंटर प्रवेश प्रदान करते. वेन्यूकडे कोणत्या नोंदी राहिल्या पाहिजेत?

सेवा आणि नेटवर्क-सुरक्षा नोंदींना वेन्यूचा नियंत्रक-उद्दिष्ट डेटा म्हणून समजा. प्रायोजकांना केवळ तेच ऑप्ट-इन्स द्या जे ते त्यांच्या स्वतःच्या घोषित विपणन हेतूसाठी वापरण्यास पात्र आहेत. प्रत्येक इव्हेंटपूर्वी, चाचणी घ्या की प्रायोजक माघार घेतल्याने प्रायोजक संवाद थांबतो तर केवळ वेन्यूचे काटेकोरपणे न्याय्य सुरक्षा पुरावे जतन केले जातात.

या मालिकेमध्ये पुढे वाचा

पुनरावृत्ती भेटी वाढवण्यासाठी मार्केटिंगमध्ये SMS चा कसा वापर करावा

हे तांत्रिक संदर्भ मार्गदर्शक स्पष्ट करते की एंटरप्राइझ स्थाने वारंवार येणाऱ्या भेटींना चालना देण्यासाठी SMS मार्केटिंग इंजिनसह WiFi विश्लेषण कसे समाकलित करू शकतात. हे रिअल-टाइम प्रेझेन्स डेटा कॅप्चर करण्यासाठी, शारीरिक वर्तनावर आधारित स्वयंचलित SMS मोहिमा सुरू करण्यासाठी आणि रिटर्न रेट्सवर थेट परिणाम मोजण्यासाठी आवश्यक असलेल्या आर्किटेक्चरचा तपशील देते. नेटवर्क इन्फ्रास्ट्रक्चरला मार्केटिंग ऑटोमेशनसह संरेखित करून, IT आणि ऑपरेशन्स टीम्स ग्राहकांना टिकवून ठेवण्यासाठी उच्च-उत्पन्न देणारा चॅनेल स्थापित करू शकतात.

मार्गदर्शिका वाचा →

First-party data marketing: व्यवसायांसाठी एक व्यापक मार्गदर्शक

हे मार्गदर्शक एंटरप्राइझ Guest WiFi नेटवर्कचा वापर करून एक मजबूत first-party data मार्केटिंग धोरण कसे तयार करावे हे स्पष्ट करते. यामध्ये captive portals द्वारे सुरक्षित डेटा कॅप्चर करण्यासाठी तांत्रिक आर्किटेक्चर, GDPR-compliant संमती वर्कफ्लो, CRM इंटिग्रेशन पॅटर्न आणि स्वयंचलित मोहीम उपयोजन समाविष्ट आहे. हॉस्पिटॅलिटी, रिटेल, इव्हेंट्स आणि सार्वजनिक-क्षेत्रातील ठिकाण ऑपरेटर्सना निष्क्रिय अभ्यागतांना उच्च-गुणवत्तेच्या, मालकीच्या मार्केटिंग प्रेक्षकांमध्ये रूपांतरित करण्यासाठी कृतीयोग्य मार्गदर्शन मिळेल.

मार्गदर्शिका वाचा →

ग्राहक डेटा व्यवस्थापन प्लॅटफॉर्म: व्यवसायांसाठी एक व्यापक मार्गदर्शिका

ही मार्गदर्शिका स्पष्ट करते की वेन्यू ऑपरेटर विखुरलेला अभ्यागत डेटा एकत्रित करण्यासाठी ग्राहक डेटा व्यवस्थापन प्लॅटफॉर्म कसा तैनात करू शकतात. यामध्ये तांत्रिक आर्किटेक्चर, एकत्रीकरण धोरणे आणि फर्स्ट-पार्टी डेटा प्रोफाईल तयार करण्यात Guest WiFi ची महत्त्वपूर्ण भूमिका समाविष्ट आहे.

मार्गदर्शिका वाचा →

तुमच्या विशिष्ट सेटअपबद्दल काही प्रश्न आहेत का?

आमची टीम ८०,००० हून अधिक वेन्यूजमधील वेन्यू ऑपरेटर्स, IT मॅनेजर्स आणि नेटवर्क इंजिनिअर्ससोबत काम करते. २० मिनिटांचा कॉल बुक करा आणि तुमच्यासारख्या इतरांनी ही समस्या कशी सोडवली हे आम्ही तुम्हाला दाखवू.