साझा WiFi ऑपरेटरों के लिए GDPR डेटा प्रतिधारण: आप अतिथि लॉगिन डेटा और नेटवर्क लॉग को कब तक रख सकते हैं

UK GDPR के तहत, पहचान योग्य अतिथि WiFi लॉगिन डेटा और नेटवर्क लॉग को केवल प्रलेखित उद्देश्य के लिए ही रखें और उससे अधिक समय तक नहीं। अधिकांश परिचालन सुरक्षा लॉग एक संक्षिप्त, परीक्षण की गई अवधि को उचित ठहरा सकते हैं, न कि किसी सार्वभौमिक नियम को। 12 महीने की IPA अवधि केवल तभी लागू होती है जब कोई लागू डेटा प्रतिधारण नोटिस विशिष्ट डेटा को रखे जाने की आवश्यकता रखता हो।1 7 9

एक बचाव योग्य WiFi डेटा-प्रतिधारण नीति क्या है?

एक बचाव योग्य नीति प्रत्येक डेटा श्रेणी को एक उद्देश्य, एक जवाबदेह पक्ष, एक वैध आधार, एक प्रतिधारण अवधि और एक विलोपन घटना से जोड़ती है। यह अनुच्छेद 5(1)(e) की परिचालन अभिव्यक्ति है: व्यक्तिगत डेटा आवश्यकता से अधिक समय तक पहचान योग्य नहीं रहना चाहिए। ICO निश्चित अवधि निर्धारित नहीं करता है। आपको अवधि को उचित ठहराना होगा, उसका दस्तावेजीकरण करना होगा, उसकी समीक्षा करनी होगी और जब इसकी आवश्यकता न हो तो डेटा को मिटाना या अनामीकृत करना होगा।1

कानूनी नोट। यह तकनीकी अनुपालन मार्गदर्शन है, औपचारिक कानूनी सलाह नहीं। प्रतिधारण कार्यक्रम पर भरोसा करने से पहले अपने एस्टेट मॉडल, किरायेदार अनुबंधों और किसी भी IPA नोटिस को सत्यापित करने के लिए योग्य कानूनी सलाहकार से परामर्श लें।

साझा WiFi एक अलग अनुपालन समस्या क्यों है?

Multi-Tenant WiFi ऐसी परतें बनाता है जो एक एकल-साइट अतिथि नेटवर्क नहीं बनाता है। आप निवासियों, सदस्यों, मेहमानों और आगंतुकों के लिए एक साझा एक्सेस परत का संचालन कर सकते हैं, जबकि किरायेदार नियोक्ता को Staff WiFi सेवा प्रदान कर सकते हैं। अपने स्वयं के उद्देश्यों के लिए, जैसे कि नेटवर्क सुरक्षा, सेवा आश्वासन और बिलिंग विवाद प्रबंधन, आप एक नियंत्रक (controller) हो सकते हैं। केवल किरायेदार के प्रलेखित निर्देशों पर संसाधित कर्मचारी प्रमाणीकरण के लिए, आप एक प्रोसेसर (processor) हो सकते हैं। व्यावसायिक समझौते में लगा लेबल इस मुद्दे को तय नहीं करता है।

ICO का कहना है कि भूमिका विशिष्ट प्रसंस्करण गतिविधि के अनुसार तय होती है। जो पक्ष यह तय करता है कि डेटा क्यों एकत्र किया जा रहा है, उसका वैध आधार, डेटा श्रेणियां, प्राप्तकर्ता, गोपनीयता जानकारी, अधिकारों का प्रबंधन या प्रतिधारण क्या है, उसके नियंत्रक होने की संभावना है। एक प्रोसेसर तकनीकी तरीकों, सुरक्षा नियंत्रणों और विलोपन तंत्रों को चुन सकता है बिना नियंत्रक बने, जब तक कि वह समग्र निर्णय नहीं लेता है। इसलिए एक ही डेटासेट को उद्देश्य और भूमिका के आधार पर अलग किया जा सकता है। यदि दोनों पक्ष संयुक्त रूप से उद्देश्यों और साधनों को निर्धारित करते हैं, तो संबंध को एक साधारण प्रोसेसर सेवा के रूप में मानने के बजाय अनुच्छेद 26 संयुक्त-नियंत्रक व्यवस्था का उपयोग करें।4

यह विश्लेषण विशेष रूप से Hospitality, Retail, Healthcare और Transport संपत्तियों के लिए महत्वपूर्ण है, जहां एक साझा नेटवर्क एक ही इमारत में कई स्वतंत्र व्यवसायों की सेवा कर सकता है।

आपको 5 WiFi डेटा श्रेणियों को कैसे वर्गीकृत करना चाहिए?

कनेक्शन मेटाडेटा में असाइन किया गया IP पता, स्रोत MAC पता, सत्र शुरू और समाप्त होने का समय, स्थानांतरित बाइट्स, DHCP लीज रिकॉर्ड और RADIUS अकाउंटिंग शामिल हैं। नाम-लॉगिन सेवा पर, ये फ़ील्ड आमतौर पर व्यक्तिगत डेटा होंगे क्योंकि उन्हें किसी व्यक्ति से जोड़ा जा सकता है। परिभाषित सुरक्षा और समस्या निवारण (troubleshooting) उद्देश्य के लिए आवश्यक फ़ील्ड रखें। एक सुझाया गया 30 से 90 दिनों की परिचालन अवधि एक प्रारंभिक नीति है, न कि कोई वैधानिक सुरक्षित आश्रय। आपकी घटना-खोज का समय, थ्रेट मॉडल और जांच करने की क्षमता स्वीकृत अवधि निर्धारित करनी चाहिए।1 6

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

स्थान और उपस्थिति डेटा को कच्चे पहचान योग्य ट्रेल्स और समग्र आउटपुट के बीच एक कड़ा अंतर रखने की आवश्यकता होती है। यदि आप इसे लॉगिन से दोबारा जोड़ सकते हैं तो एक टोकन गुमनाम नहीं है। ICO का कहना है कि छद्म नाम (pseudonymised) वाला डेटा आमतौर पर व्यक्तिगत डेटा ही रहेगा, जबकि वह डेटा जो अब पहचान की अनुमति नहीं देता है, उसे भंडारण-सीमा नियम के बाहर रखा जा सकता है। एक 30-दिवसीय कच्चा-ट्रेस अवधि और उसके बाद अपरिवर्तनीय एकत्रीकरण (aggregation) एक समझदारी भरा नीति पैटर्न है जहां आपको अल्पकालिक परिचालन विश्लेषण की आवश्यकता होती है। एकत्रीकरण विधि का दस्तावेजीकरण करें और परीक्षण करें कि क्या पुन: पहचान अभी भी संभव है।1Marketing communications history में भेजना, खोलना, क्लिक करना और प्राथमिकताओं में बदलाव शामिल हैं। security-log टाइमर को इनहेरिट न करें। इसे केवल घोषित मार्केटिंग उद्देश्य के लिए, लागू होने वाले कानूनी आधार पर, एक प्रलेखित समीक्षा तिथि के साथ बनाए रखें। नीचे दिया गया 24 महीने का समीक्षा बिंदु एक सुझाया गया ऑपरेटिंग लिमिट है, न कि ICO की कोई समय सीमा। केवल इसलिए किसी सहभागिता प्रोफ़ाइल (engagement profile) को बनाए न रखें क्योंकि व्यक्ति ने सहमति वापस नहीं ली है। यदि सहमति वापस ले ली जाती है, तो मार्केटिंग इतिहास को मिटा दें या डी-आइडेंटिफाई कर दें, जब तक कि कोई अलग, प्रलेखित आवश्यकता लागू न हो। एक ऑप्ट-आउट सप्रेशन प्रविष्टि अलग है: यह आगे के संदेशों को रोकती है।2 6

Abuse and security logs में फ़ायरवॉल अस्वीकृतियाँ (firewall denials), DNS सुरक्षा इवेंट और RADIUS accounting शामिल हो सकते हैं। नेटवर्क और सूचना सुरक्षा वैध हितों का समर्थन कर सकती है, लेकिन ऐसा स्वचालित रूप से नहीं होता है। अवधारण (retention) अवधि शुरू करने से पहले उद्देश्य, आवश्यकता और संतुलन परीक्षणों को पूरा करें। 365 दिनों की समय-सीमा वहां बचाव योग्य हो सकती है जहां एक साझा सार्वजनिक IP एड्रेस का अर्थ है कि आपको विलंबित घटना, दावे या सम्मन (subpoena) से निपटने के लिए एट्रिब्यूशन साक्ष्य की आवश्यकता है। यह कोई GDPR फ्लोर नहीं है। आर्किटेक्चर या जोखिम बदलने पर फ़ील्ड कम करें, एक्सेस को प्रतिबंधित करें, सर्च को लॉग करें और वैध हितों के मूल्यांकन की समीक्षा करें।1 6

निर्णय प्रवाह: स्वचालित पर्ज नियम सेट करने से पहले पहचान योग्यता, भूमिका, कानूनी आधार और किसी भी वैधानिक नोटिस को निर्धारित करें।

आप कौन सा अवधारण शेड्यूल (retention schedule) अपना सकते हैं?

नीचे दिया गया शेड्यूल UK के एक साझा WiFi एस्टेट के लिए तैयार किया गया आधारभूत ढांचा है। इसे जानबूझकर उद्देश्य के आधार पर विभाजित किया गया है। इसे केवल तभी अपनाएं जब कंट्रोलर ने एस्टेट के लिए उद्देश्य, कानूनी आधार और जोखिम मूल्यांकन का दस्तावेजीकरण कर लिया हो। एक IPA नोटिस, कानूनी रोक या सक्रिय दावा एक सामान्य पर्ज तिथि को ओवरराइड कर सकता है, लेकिन केवल विशिष्ट रिकॉर्ड और अवधि के लिए जो अपवाद को उचित ठहराता है।1 7 9

90-दिन की कनेक्शन अवधि और 365-दिन की दुरुपयोग अवधि नीतिगत विकल्प हैं, अनिवार्य आंकड़े नहीं। ये केवल तभी उपयोगी होते हैं जब आपकी लिखित LIA, गोपनीयता नोटिस, सिस्टम साक्ष्य और स्वचालित विलोपन डिज़ाइन सभी मेल खाते हों। एक सार्वजनिक प्राधिकरण को यह भी जांचना चाहिए कि क्या वह किसी सार्वजनिक कार्य का निष्पादन कर रहा है, क्योंकि वह उस कार्य के लिए वैध हितों (legitimate interests) पर भरोसा नहीं कर सकता है।6

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

नहीं, डिफ़ॉल्ट रूप से नहीं। दूरसंचार ऑपरेटर की IPA परिभाषा व्यापक है। सरकार का 2025 नोटिस कोड कहता है कि इसमें वह व्यक्ति शामिल हो सकता है जो मेहमानों या जनता के सदस्यों को संचार सेवाओं तक पहुंच प्रदान करता है जो किसी अन्य सेवा के सहायक हैं, जिसमें होटल जैसे व्यावसायिक परिसर शामिल हैं। यह इस मुद्दे को MDU, को-वर्किंग या प्रबंधित WiFi ऑपरेटर के लिए प्रासंगिक बनाता है।8 9

लेकिन वही कोड स्पष्ट है कि डिफ़ॉल्ट स्थिति अधिनियम के तहत कोई प्रतिधारण दायित्व नहीं है जब तक कि डेटा प्रतिधारण नोटिस नहीं दिया जाता है। IPA की धारा 87 के तहत, गृह सचिव केवल वहीं नोटिस जारी कर सकते हैं जहाँ आवश्यकता आवश्यक और आनुपातिक हो और एक न्यायिक आयुक्त ने इसे मंजूरी दी हो। नोटिस में ऑपरेटर, डेटा और अवधि की पहचान होनी चाहिए। यह 12 महीनों से अधिक के प्रतिधारण की आवश्यकता नहीं रख सकता है। केवल इसलिए एक सामान्य "सब कुछ 12 महीनों के लिए रखें" नीति न बनाएं क्योंकि सेवा दूरसंचार ऑपरेटर की व्यापक परिभाषा को पूरा कर सकती है।7 9

जहाँ एक वैध नोटिस कानूनी दायित्व बनाता है, वहाँ Article 6(1)(c) अनुपालन के लिए आवश्यक प्रोसेसिंग के लिए UK GDPR कानूनी आधार प्रदान कर सकता है। यह एक संविदात्मक आधार नहीं है। ICO का कहना है कि आपको विशिष्ट कानूनी प्रावधान की पहचान करनी चाहिए, निर्णय का दस्तावेजीकरण करना चाहिए और गोपनीयता जानकारी में उद्देश्य और कानूनी आधार को समझाना चाहिए। नोटिस माध्यमिक विपणन (secondary marketing) उपयोग या असीमित संग्रह को अधिकृत नहीं करता है।

एक Article 28 किरायेदार समझौते में क्या होना चाहिए?

यदि आप किरायेदार के कर्मचारी डेटा को केवल किरायेदार के प्रलेखित निर्देशों पर संसाधित करते हैं, तो उस प्रोसेसिंग को शुरू करने से पहले एक Article 28 डेटा प्रोसेसिंग समझौता लागू होना चाहिए। समझौते में विषय वस्तु और अवधि, प्रकृति और उद्देश्य, डेटा प्रकार, डेटा-विषय श्रेणियां, और नियंत्रक के अधिकारों और दायित्वों का वर्णन होना चाहिए। इसके बाद इसमें नीचे दिए गए परिचालन प्रतिबद्धताएं होनी चाहिए।5

संयुक्त-नियंत्रक (joint-controller) व्यवस्था को छिपाने के लिए Article 28 समझौते का उपयोग न करें। यदि ऑपरेटर और किरायेदार संयुक्त रूप से निर्णय लेते हैं कि कर्मचारी एनालिटिक्स का उपयोग क्यों किया जाएगा, कौन से फ़ील्ड एकत्र किए जाएंगे और वे कब तक उपलब्ध रहेंगे, तो इसके बजाय Article 26 का आकलन करें।4

आपको हटाने के अनुरोध (erasure request) को कैसे संभालना चाहिए?

Article 17 erasure (डेटा हटाना) एक वन-क्लिक डिलीट फ़ंक्शन नहीं है। एक आनुपातिक पहचान जांच के साथ शुरुआत करें। फिर उद्देश्य और भूमिका के आधार पर डेटा खोजें: अतिथि एक्सेस, मार्केटिंग, सुरक्षा, किरायेदार निर्देश और कोई विशिष्ट नोटिस-रिटेंशन। ICO का कहना है कि आपको बिना किसी अनावश्यक देरी के और अधिकतम एक महीने के भीतर जवाब देना चाहिए। जहां डेटा की अब आवश्यकता नहीं है, या सहमति वापस ले ली गई है, इसे लाइव रिकॉर्ड से मिटा दें और आवश्यकतानुसार प्रासंगिक प्राप्तकर्ताओं को सूचित करें।2

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

डेटा मिटाने के वर्कफ़्लो को डिलीट किए जाने वाले डेटा को एक प्रलेखित अपवाद के तहत रखे गए सीमित रिकॉर्ड से अलग करना चाहिए।

वास्तविक स्थानों (venues) में यह कैसे काम करता है?

हॉस्पिटैलिटी परिदृश्य: अतिथि एक्सेस और किरायेदार स्टाफ एक्सेस वाला एक होटल

एक 200 कमरों वाला होटल आगंतुकों के लिए Guest WiFi संचालित करता है और अपने रेस्तरां किरायेदार को Staff WiFi SSID प्रदान करता है। होटल प्रोसेसिंग के दो अलग-अलग रिकॉर्ड लिखता है। यह अतिथि प्रमाणीकरण, 90-दिवसीय कनेक्शन डेटा और सुरक्षा जांच के लिए नियंत्रक (controller) के रूप में कार्य करता है। रेस्तरां अपने स्टाफ SSID के लिए कर्मचारी संख्या, एक्सेस की शर्तों और डेटा रिटेंशन का निर्णय लेता है, इसलिए होटल उस प्रोसेसिंग पर Article 28 की शर्तें लागू करता है। मापने योग्य नियंत्रण एक मासिक रिपोर्ट है जो दिखाती है कि 90 दिनों से पुराना प्रत्येक अतिथि सत्र हटा दिया गया है, जबकि किसी भी अपवाद में एक घटना या नोटिस संदर्भ है।

रिटेल परिदृश्य: एक ही सार्वजनिक पते पर एक शॉपिंग गंतव्य

एक रिटेल गंतव्य कई इकाइयों में एक ही सार्वजनिक इग्रेस पते का उपयोग करता है। इसकी सुरक्षा LIA यह रिकॉर्ड करती है कि देरी से आने वाले दुरुपयोग के आरोपों के लिए किसी विशिष्ट कनेक्शन के एट्रिब्यूशन की आवश्यकता क्यों हो सकती है। यह 365-दिन का सुरक्षा-साक्ष्य शेड्यूल सेट करता है, लेकिन एकत्रीकरण से पहले 30 दिनों के लिए रॉ पहचान योग्य स्थान ट्रेल्स रखता है। मापने योग्य नियंत्रण एक त्रैमासिक LIA समीक्षा के साथ-साथ एक परीक्षण है कि एक सुरक्षा विश्लेषक समाप्त हो चुके रॉ स्थान डेटा तक पहुंचे बिना एक अनुमत घटना का पुनर्निर्माण कर सकता है।

इवेंट परिदृश्य: प्रायोजक के स्वामित्व वाले दर्शकों के साथ एक सम्मेलन स्थल

एक सम्मेलन केंद्र उपस्थित लोगों को एक्सेस प्रदान करता है जबकि प्रायोजक अलग-अलग ब्रांडेड यात्राओं के माध्यम से ऑप्ट-इन एकत्र करते हैं। स्थल सेवा और सुरक्षा डेटा के लिए नियंत्रक बना रहता है। प्रत्येक प्रायोजक अपने स्वयं के मार्केटिंग उद्देश्य को नियंत्रित करता है और उसे केवल वही ऑप्ट-इन प्राप्त होने चाहिए जिनका उपयोग करने का वह हकदार है। मापने योग्य नियंत्रण एक प्री-इवेंट परीक्षण है जो साबित करता है कि एक प्रायोजक यात्रा पर ऑप्ट-इन वापस लेने से उस प्रायोजक के संचार बंद हो जाते हैं, बिना स्थल के संकीर्ण रूप से रखे गए सुरक्षा साक्ष्य को हटाए।

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

एक पॉलिसी टेम्पलेट के बजाय 60 मिनट की अवधारण कार्यशाला के साथ शुरुआत करें। अपने DPO, नेटवर्क आर्किटेक्ट, वेन्यू ऑपरेशंस लीड और प्रत्येक प्रासंगिक किरायेदार प्रतिनिधि को बुलाएं। स्पलैश पेज, DHCP, RADIUS, फ़ायरवॉल, DNS और एनालिटिक्स घटकों से प्रवाहित होने वाले फ़ील्ड्स की एक तालिका बनाएं। प्रत्येक फ़ील्ड के लिए उद्देश्य, नियंत्रक या प्रोसेसर की भूमिका, वैध आधार, अवधारण टाइमर, विलोपन कार्रवाई, ऑडिट स्वामी और लीगल-होल्ड प्रक्रिया तय करें।

फिर काम करने के लिए सिस्टम को कॉन्फ़िगर करें। Purple कॉन्फ़िगर करने योग्य अवधारण अवधि, स्वचालित पर्ज शेड्यूल, एक्सेस-अनुरोध टूलिंग और इरेज़र वर्कफ़्लो प्रदान करता है जो इस ऑपरेटिंग मॉडल का समर्थन करते हैं। अपने Guest WiFi परिवेश को किसी भी किरायेदार Staff 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 लॉगिन डेटा को कब तक रख सकता हूँ?

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

क्या UK Investigatory Powers Act के लिए 12 महीने के WiFi कनेक्शन रिकॉर्ड की आवश्यकता होती है?

नहीं। IPA प्रत्येक साझा WiFi ऑपरेटर के लिए स्वचालित 12-महीने का कर्तव्य नहीं बनाता है। प्रतिधारण कर्तव्य केवल तब शुरू होता है जब एक लागू डेटा प्रतिधारण नोटिस दिया जाता है। नोटिस प्रासंगिक संचार डेटा और प्रतिधारण अवधि को परिभाषित करता है, जो 12 महीने से अधिक नहीं हो सकती है। यदि आपको ऐसा कोई नोटिस मिलता है तो तुरंत विशेषज्ञ की सलाह लें।7 9

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

यह प्रोसेसिंग गतिविधि पर निर्भर करता है। यदि किरायेदार कर्मचारी आबादी, उद्देश्य, नोटिस, अधिकारों के प्रबंधन और प्रतिधारण का निर्णय लेता है, जबकि आप प्रलेखित निर्देशों पर सेवा का संचालन करते हैं, तो आप संभवतः उस गतिविधि के लिए प्रोसेसर हैं। यदि आप अपने स्वयं के उद्देश्य के लिए वे निर्णय लेते हैं, तो आप नियंत्रक हैं। जहां दोनों पक्ष संयुक्त रूप से आवश्यक उद्देश्यों और साधनों का निर्णय लेते हैं, वहां संयुक्त नियंत्रक स्थिति का आकलन करें।4

साझा WiFi नेटवर्क पर IP-address लॉग के लिए सही प्रतिधारण अवधि क्या है?

कोई निर्धारित UK GDPR अवधि नहीं है। घोषित सुरक्षा और समस्या निवारण आवश्यकता से जुड़ी एक आनुपातिक अवधि निर्धारित करें। यह मार्गदर्शिका कनेक्शन मेटाडेटा के लिए सुझाए गए डिफ़ॉल्ट के रूप में 90 दिनों का उपयोग करती है। केवल वहीं 365 दिनों तक बढ़ाएं जहां एक प्रलेखित LIA वास्तविक साझा-पता एट्रिब्यूशन या दावों की आवश्यकता का समर्थन करता है, जिसमें फ़ील्ड न्यूनीकरण और एक्सेस नियंत्रण शामिल हैं।1 6

जब मेरे पास ट्रैफ़िक डेटा बनाए रखने का कानूनी कर्तव्य हो तो मुझे मिटाने के अनुरोध (erasure request) के साथ क्या करना चाहिए?

उन रिकॉर्ड्स को मिटा दें जो अब आवश्यक नहीं हैं, लेकिन केवल कानूनी दायित्व द्वारा आवश्यक संकीर्ण डेटा और अवधि को ही बनाए रखें। एक महीने के भीतर जवाब दें, लागू छूट की व्याख्या करें और प्रतिधारित डेटा को असंबंधित उद्देश्यों के लिए उपयोग किए जाने से रोकें। बैकअप को हटाकर या शेड्यूल किए गए ओवरराइट होने तक उन्हें अनुपयोगी बनाकर यही निर्णय बैकअप पर भी लागू करें।2 3

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

जब भी आप उस किरायेदार के प्रलेखित निर्देशों पर किरायेदार के कर्मचारी डेटा को संसाधित करते हैं, तो आपको एक Article 28 डेटा प्रोसेसिंग समझौते की आवश्यकता होती है। आपको केवल इसलिए इसकी आवश्यकता नहीं है क्योंकि आप एक इमारत साझा करते हैं। यदि दोनों पक्ष मिलकर उद्देश्यों और आवश्यक साधनों का निर्धारण करते हैं, तो इसके बजाय एक Article 26 संयुक्त-नियंत्रक व्यवस्था की आवश्यकता हो सकती है।4 5

क्या मैं मार्केटिंग इतिहास को तब तक रख सकता हूँ जब तक कि कोई अतिथि सहमति वापस नहीं ले लेता?

नहीं। सक्रिय सहमति भंडारण-सीमा (storage-limitation) के दायित्व को समाप्त नहीं करती है। मार्केटिंग इतिहास के लिए एक समीक्षा अवधि निर्धारित और प्रलेखित करें, जैसे कि 24 महीने की समीक्षा, और उस डेटा को हटा दें या उसकी पहचान समाप्त कर दें जो अब घोषित उद्देश्य को पूरा नहीं करता है। सहमति वापस लेने या आपत्ति जताने पर, मार्केटिंग बंद करें और विकल्प का सम्मान करने के लिए आवश्यक केवल न्यूनतम सप्रेशन डेटा (suppression data) बनाए रखें।1 2

References