प्राइवेसी कानून लोगों को उनके डेटा पर अधिकार देता है। यूज़र माँग सकते हैं कि आपने क्या इकट्ठा किया है वह दिखाया जाए, गलत डेटा सुधारा जाए, उसे डिलीट किया जाए, या कहीं और ट्रांसफ़र किया जाए। ये रिक्वेस्ट आम हैं और कानूनी रूप से बाध्यकारी हैं। आपके पास इन्हें जल्दी और पूरी तरह संभालने की प्रक्रियाएँ होनी चाहिए। इस चैप्टर में यूज़र के मुख्य अधिकार और उन्हें व्यवहार में लागू करने का तरीका बताया गया है।
यूज़र के मुख्य अधिकार
एक्सेस का अधिकार
यूज़र माँग सकते हैं कि आपके पास उनके बारे में जो भी डेटा है, उसकी कॉपी दी जाए। आपके पास इसे देने के लिए 30 दिन हैं (GDPR)। डेटा आम और पोर्टेबल फ़ॉर्मेट (CSV, PDF) में होना चाहिए। आपको सभी तरह का डेटा शामिल करना होगा: एनालिटिक्स इवेंट, अकाउंट की जानकारी, बातचीत, लेन-देन का इतिहास।
यह जटिल है क्योंकि डेटा अक्सर कई सिस्टम में फैला होता है। आपको सभी सिस्टम में क्वेरी करनी होगी, डेटा इकट्ठा करना होगा, उसे पढ़ने लायक फ़ॉर्मेट में बनाना होगा और सुरक्षित तरीके से भेजना होगा।
सुधार का अधिकार (करेक्शन)
यूज़र गलत डेटा के सुधार की माँग कर सकते हैं। अगर आपके सिस्टम में यूज़र का नाम "John" की जगह "Jhn" दिख रहा है, तो वे सुधार माँग सकते हैं। आपको इसे जल्दी सुधारना होगा। यह उस हर डेटा पर लागू होता है जिसे यूज़र गलत बताए।
मिटाने का अधिकार (डिलीशन)
पिछले चैप्टर में बताया गया। यूज़र अपने डेटा के डिलीशन की रिक्वेस्ट कर सकते हैं। आपके पास पालन के लिए 30 दिन हैं (कानूनी दायित्वों के अपवाद के साथ)।
प्रोसेसिंग सीमित करने का अधिकार
यूज़र आपसे कह सकते हैं कि उनके डेटा का इस्तेमाल सीमित करें। उदाहरण: "मेरा डेटा मार्केटिंग के लिए इस्तेमाल न करें, लेकिन अकाउंट मैनेजमेंट के लिए रख सकते हैं।" आपको इस पाबंदी का सम्मान करना होगा और अपने सिस्टम में डेटा को सीमित के तौर पर चिह्नित करना होगा।
डेटा पोर्टेबिलिटी का अधिकार
यूज़र अपना डेटा ऐसे फ़ॉर्मेट में माँग सकते हैं जिसे वे किसी दूसरी कंपनी के पास ले जा सकें। सर्विस बदलने के लिए यह ख़ास तौर पर ज़रूरी है। आपको डेटा एक व्यवस्थित, आम तौर पर इस्तेमाल होने वाले फ़ॉर्मेट (JSON, CSV) में देना होगा। डेटा मशीन से पढ़ने लायक होना चाहिए ताकि वे उसे कहीं और इंपोर्ट कर सकें।
आपत्ति करने का अधिकार
यूज़र कुछ मक़सद के लिए अपने डेटा की प्रोसेसिंग पर आपत्ति कर सकते हैं। अगर आप डेटा मार्केटिंग के लिए इस्तेमाल कर रहे हैं, तो वे आपत्ति कर सकते हैं। आपको रुकना होगा, जब तक जारी रखने की कोई ठोस कानूनी वजह न हो।
ऑटोमैटिक फ़ैसलों से जुड़े अधिकार
अगर आप यूज़र के बारे में फ़ैसले लेने के लिए एल्गोरिदम इस्तेमाल करते हैं (क्रेडिट के फ़ैसले, सर्विस के लिए पात्रता), तो यूज़र को यह समझने का अधिकार है कि फ़ैसला कैसे हुआ और इंसान से समीक्षा माँगने का भी। यह एनालिटिक्स से आगे की बात है, लेकिन जानना अच्छा है।
डेटा एक्सेस रिक्वेस्ट वर्कफ़्लो बनाना
स्टेप 1: रिक्वेस्ट का तरीका बनाएँ
यूज़र के लिए रिक्वेस्ट भेजना आसान बनाएँ। विकल्प: वेब फ़ॉर्म, ईमेल एड्रेस (data-requests@yourcompany.com), या आपकी अकाउंट सेटिंग में सेल्फ़-सर्विस पोर्टल। इसे आसानी से मिलने लायक बनाएँ (फ़ुटर, प्राइवेसी पॉलिसी, अकाउंट सेटिंग में लिंक)।
स्टेप 2: पहचान जाँचें
पक्का करें कि रिक्वेस्ट असली यूज़र या उसके अधिकृत प्रतिनिधि की है। ईमेल कन्फ़र्मेशन, पासवर्ड वेरिफ़िकेशन, या सरकारी ID की जाँच माँगें (संवेदनशीलता के हिसाब से)। आप नहीं चाहेंगे कि पर्सनल डेटा किसी नक़ली व्यक्ति को चला जाए।
स्टेप 3: तय करें कौन सा डेटा देना है
उन सभी सिस्टम में क्वेरी करें जहाँ यूज़र का डेटा है: अकाउंट, एनालिटिक्स, सपोर्ट, ईमेल लिस्ट, CRM, बैकअप। सब कुछ इकट्ठा करें। इनमें शामिल करें: यूज़र को भेजे गए ईमेल, फ़ॉर्म सबमिशन, सपोर्ट टिकट, खरीदारी, ट्रैकिंग इवेंट, पसंद-नापसंद, बातचीत का इतिहास।
पूरा दें। एक आम उल्लंघन: कुछ डेटा देना लेकिन सारा नहीं। अगर रेगुलेटर जाँच करे और ऐसा डेटा मिले जो आपने नहीं बताया, तो यह समस्या है।
स्टेप 4: पढ़ने लायक फ़ॉर्मेट बनाएँ
डेटा साफ़ फ़ॉर्मेट में दें। कच्चे डेटाबेस डंप मान्य नहीं हैं। एक व्यवस्थित दस्तावेज़ बनाएँ: पहले अकाउंट की जानकारी, फिर इवेंट, फिर बातचीत। टेबल और साफ़ हेडिंग इस्तेमाल करें। अगर यूज़र को पोर्टेबिलिटी चाहिए, तो ऐसा फ़ॉर्मेट दें जिसे वह इंपोर्ट कर सके (JSON, CSV)।
स्टेप 5: सुरक्षित तरीके से भेजें
पर्सनल डेटा बिना एन्क्रिप्ट किए ईमेल से न भेजें। सुरक्षित फ़ाइल ट्रांसफ़र सर्विस इस्तेमाल करें (ख़त्म होने वाला सुरक्षित डाउनलोड लिंक, एन्क्रिप्टेड ईमेल, SFTP)। मिलने की पुष्टि लें।
स्टेप 6: दर्ज करें
रिक्वेस्ट लॉग करें: कब मिली, कब प्रोसेस हुई, कौन सा डेटा दिया गया, कैसे भेजा गया। जाँच होने पर यह आपके पालन का सबूत है।
बड़े पैमाने पर रिक्वेस्ट संभालना
ऑटोमैटिक बनाम हाथ से
छोटी कंपनियों के लिए हाथ से रिक्वेस्ट संभालना संभव है। लाखों यूज़र वाली कंपनियों को ऑटोमेशन चाहिए। ऐसा सिस्टम बनाएँ जो: रिक्वेस्ट ले, पहचान जाँचे, डेटाबेस में क्वेरी करे, डेटा फ़ॉर्मेट करे और उसे डिलीवर करे, यह सब कम से कम हाथ के काम से।
टेम्पलेट और चेकलिस्ट
जवाब के टेम्पलेट बनाएँ: "हमें आपकी रिक्वेस्ट [तारीख़] को मिली। यह रहा आपका डेटा..." चेकलिस्ट बनाएँ: अकाउंट डेटा, हो गया; एनालिटिक्स, हो गया; सपोर्ट, हो गया। चेकलिस्ट से कोई डेटा प्रकार गलती से छूटता नहीं।
डेटा रिक्वेस्ट संभालने की आम गलतियाँ
समय पर जवाब न देना: 30 दिन की सीमा वैकल्पिक नहीं है। चूकना उल्लंघन है। रिमाइंडर लगाएँ और डेडलाइन ट्रैक करें।
अधूरा डेटा देना: अगर आप कुछ डेटा देते हैं लेकिन सारा नहीं, तो आप नियमों के अनुरूप नहीं हैं। पक्का करें कि आपकी क्वेरी सभी सिस्टम को कवर करे।
खराब फ़ॉर्मेट: कच्चा डेटाबेस आउटपुट देना नियमों के अनुरूप नहीं है। डेटा को पढ़ने लायक फ़ॉर्मेट में दें।
पहचान न जाँचना: नक़ली व्यक्ति को पर्सनल डेटा भेजने से आप पर ज़िम्मेदारी आती है। हमेशा जाँचें।
बाद की रिक्वेस्ट को अनदेखा करना: अगर वही यूज़र कई रिक्वेस्ट करता है, तो हर एक को संभालें। यह न मानें कि पिछली रिक्वेस्ट इसे कवर कर चुकी है।
फ़ीस लेना: GDPR सिर्फ़ तभी फ़ीस की इजाज़त देता है जब रिक्वेस्ट साफ़ तौर पर बेबुनियाद या हद से ज़्यादा हो। जायज़ रिक्वेस्ट को हतोत्साहित करने के लिए फ़ीस का इस्तेमाल न करें।
यूज़र के अधिकार और बिज़नेस का संचालन
डेटा रिक्वेस्ट संभालना संचालन पर बोझ है। लेकिन जो कंपनियाँ यूज़र के अधिकारों का सम्मान करती हैं, वे: भरोसा बनाती हैं, जुर्माने से बचती हैं, प्राइवेसी का ध्यान रखने वाले ग्राहक खींचती हैं, और टैलेंट भी खींचती हैं (कर्मचारी नैतिक कंपनियों के लिए काम करना पसंद करते हैं)। संचालन का खर्च संस्कृति और कंप्लायंस में निवेश है।
यूज़र के अधिकारों को प्रोडक्ट डिज़ाइन में शामिल करना
सबसे समझदारी का तरीका: यूज़र के अधिकार शुरू से ही अपने प्रोडक्ट में बनाएँ। यूज़र को सेल्फ़-सर्विस पोर्टल दें जहाँ वे: अपना डेटा देख सकें, डाउनलोड कर सकें, डिलीट कर सकें, पसंद बदल सकें। इससे सपोर्ट का बोझ घटता है और यूज़र को ताक़त मिलती है। ज़्यादातर आधुनिक ऐप में यह होता है (अकाउंट सेटिंग, डेटा एक्सपोर्ट, अकाउंट डिलीट करने के बटन)।
यह पक्का करने के लिए कि मैं अपने जवाब में यूज़र का सारा डेटा शामिल करूँ, कोई व्यवस्थित चेकलिस्ट क्या है?
इन्वेंटरी बनाएँ: (1) अकाउंट सिस्टम (ईमेल, नाम, फ़ोन, पसंद)। (2) एनालिटिक्स (इवेंट, टाइमस्टैम्प, डिवाइस की जानकारी, लोकेशन)। (3) बातचीत (भेजे गए ईमेल, सपोर्ट टिकट, चैट लॉग)। (4) लेन-देन (खरीदारी, रिफ़ंड, फ़ेल हुए भुगतान)। (5) थर्ड-पार्टी डेटा (वेंडर से शेयर किया गया डेटा)। हर सिस्टम में यूज़र ID से क्वेरी करें। हाथ की खोज पर निर्भर न रहें; ऑटोमेट करें। दर्ज करें कि आपने क्या और कब क्वेरी किया।
डेटा एक्सेस जवाब को फ़ॉर्मेट करने और भेजने का सबसे अच्छा तरीका क्या है?
सेक्शन वाला PDF या HTML दस्तावेज़ बनाएँ: 'आपके अकाउंट की जानकारी', 'आपकी गतिविधि', 'बातचीत'। इवेंट के लिए टेबल इस्तेमाल करें (तारीख़, कार्रवाई, ब्योरा)। पोर्टेबिलिटी रिक्वेस्ट के लिए CSV/JSON भी दें। सुरक्षित डिलीवरी इस्तेमाल करें: पासवर्ड वाला डाउनलोड लिंक (14 दिन में ख़त्म), एन्क्रिप्टेड ईमेल, या सुरक्षित फ़ाइल ट्रांसफ़र सर्विस। यूज़र से मिलने की पुष्टि लें। कंप्लायंस रिकॉर्ड के लिए डिलीवरी के तरीके की कॉपी रखें।
डेटा एक्सेस रिक्वेस्ट के लिए मैं यूज़र से कब और कितनी फ़ीस ले सकता हूँ?
GDPR: फ़ीस तभी लें जब रिक्वेस्ट 'साफ़ तौर पर बेबुनियाद या हद से ज़्यादा' हो (बहुत कम)। आम तौर पर मुफ़्त। CCPA: सिर्फ़ उचित फ़ीस। व्यवहार में: पहली रिक्वेस्ट पर फ़ीस न लें; सिर्फ़ उसी यूज़र की छोटे समय में बार-बार की रिक्वेस्ट पर लें (बेकार की सीमा से ऊपर)। पहली रिक्वेस्ट का जवाब हमेशा मुफ़्त दें। नीति पहले ही अपनी प्राइवेसी पॉलिसी में बताएँ।
जो डेटा मुझे सचमुच नहीं मिल रहा, उसे मैं कैसे संभालूँ, और क्या मुझे खोजते रहना होगा?
उचित खोज: अपने कंट्रोल के सभी चालू सिस्टम में क्वेरी करें + बैकअप देखें अगर पहुँच है। अगर डेटा आपके मुख्य सिस्टम में नहीं है, तो आप नियमों के अनुरूप हैं। अगर आपको आंशिक डेटा मिला (एनालिटिक्स है लेकिन अकाउंट की जानकारी नहीं), तो दर्ज करें कि आपने कौन से सिस्टम जाँचे। यूज़र को भेजें: 'हमने [सिस्टम की सूची] में खोजा और [X] पाया। हमें [Y सिस्टम] में डेटा नहीं मिला क्योंकि [कारण]।'
किसी यूज़र की ओर से काम करने वाले व्यक्ति की रिक्वेस्ट संभालने की कानूनी प्रक्रिया क्या है?
स्टेप 1: अधिकृत व्यक्ति से यूज़र का लिखित प्राधिकरण माँगें (नाबालिग/अक्षमता के लिए नोटरी वाली ID)। स्टेप 2: जाँचें कि हस्ताक्षर करने वाला वही है जो वह कहता है (ID से मिलान करें)। स्टेप 3: जाँचें कि प्राधिकरण उस ख़ास रिक्वेस्ट प्रकार (एक्सेस, डिलीशन वगैरह) को कवर करता है। स्टेप 4: अधिकृत व्यक्ति या यूज़र को जवाब दें (अपने क्षेत्राधिकार के नियम देखें, कुछ में यूज़र को कॉपी देना ज़रूरी है)। प्राधिकरण को अपनी फ़ाइल में दर्ज करें।
अगर मैं अभी डेटा रिक्वेस्ट की डेडलाइन पूरी नहीं कर पा रहा, तो मेरी एक्शन प्लान क्या हो?
तुरंत: (1) सभी बकाया रिक्वेस्ट खोजें, कारण बताकर डेडलाइन 30 दिन बढ़ाएँ। (2) रिक्वेस्ट ट्रैकिंग सिस्टम बनाएँ (कम से कम स्प्रेडशीट, बड़े पैमाने पर प्राइवेसी रिक्वेस्ट टूल)। (3) ज़िम्मेदार तय करें (एक व्यक्ति जवाबदेह)। (4) 20 दिन की अंदरूनी डेडलाइन रखें (30 दिन की कानूनी डेडलाइन से पहले 10 दिन का बफ़र)। (5) प्रक्रिया दर्ज करें: रिक्वेस्ट मिली → सिस्टम में खोज → जवाब फ़ॉर्मेट करें → भेजें। पहले एक नक़ली रिक्वेस्ट से टेस्ट करें।