GDPR के तहत फ्रीलांसर कैसे नियुक्त करें

GDPR के तहत एक फ्रीलांसर को कैसे नियुक्त करें: चरण-दर-चरण मार्गदर्शिका

फ्रीलांसर को हायर करना आम तौर पर तेज़ होता है। GDPR नहीं। अगर आप GDPR के तहत फ्रीलांसर कैसे हायर करें यह समझना चाहते हैं, तो पहले यह मानिए कि हर प्रोजेक्ट में डेटा का एक छिपा हुआ रास्ता होता है।

अगर आपके प्रोजेक्ट में नाम, ईमेल पते, इनवॉइस, पहचान-पत्र, लॉगिन एक्सेस, या भुगतान संबंधी जानकारी शामिल है, तो आप पहले से ही व्यक्तिगत डेटा को संभाल रहे हैं। इसका मतलब है कि आपको अनुमान नहीं, बल्कि एक स्पष्ट प्रक्रिया चाहिए। अच्छी बात यह है कि यह प्रक्रिया सरल हो सकती है, यहाँ तक कि एक छोटी टीम के लिए भी जो 2 हफ़्तों के काम के लिए एक डिज़ाइनर, एक डेवलपर, या एक अनुवादक को हायर करती है।

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

1. समझें कि फ्रीलांस हायरिंग पर GDPR कब लागू होता है

GDPR तब लागू होता है जब EU संदर्भ में व्यक्तिगत डेटा इकट्ठा, संग्रहीत, साझा या प्रोसेस किया जाता है। फ्रीलांसर प्रोजेक्ट में यह आसानी से हो सकता है। एक साधारण प्रस्ताव वाला ईमेल ही नाम और संपर्क जानकारी रखता है। साइन किया हुआ कॉन्ट्रैक्ट और जानकारी जोड़ देता है। बैंक ट्रांसफ़र भुगतान विवरण जोड़ देता है। तीन दस्तावेज़, एक कानूनी मुद्दा।

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

हायर करने से पहले एक सीधा सवाल पूछें: क्या फ्रीलांसर कोई व्यक्तिगत डेटा देखेगा, संभालेगा, या स्थानांतरित करेगा? अगर जवाब हाँ है, तो हायरिंग को GDPR-संबंधित संबंध मानें। यही वह बिंदु है जहाँ साधारण ईमेल थ्रेड पर्याप्त नहीं रहता।

कुछ टीमें इसे इसलिए चूक जाती हैं क्योंकि काम सुनने में नुकसानरहित लगता है। लोगो का ब्रीफ़ नुकसानरहित लगता है। पेड टेस्ट असाइनमेंट भी नुकसानरहित लगता है। फिर फ्रीलांसर को 120 लोगों वाली कॉन्टैक्ट शीट चाहिए होती है, और नियम तुरंत बदल जाते हैं।

2. पहचानें कि आप किस तरह का व्यक्तिगत डेटा संभालेंगे

प्रोजेक्ट से गुजरने वाले हर डेटा आइटम की सूची बनाइए। पहले संपर्क विवरण लें: नाम, कार्य ईमेल, फ़ोन नंबर, नौकरी का शीर्षक। फिर कॉन्ट्रैक्ट, इनवॉइस, टैक्स विवरण, भुगतान संदर्भ, पहचान दस्तावेज़, और अकाउंट क्रेडेंशियल्स पर जाएँ। हर आइटम का एक उद्देश्य होता है। हर आइटम में एक जोखिम भी होता है।

इनवॉइस आम हैं। कॉन्ट्रैक्ट भी। पहचान दस्तावेज़ थोड़े संवेदनशील होते हैं। अगर आप सिर्फ़ इसलिए पासपोर्ट स्कैन माँग रहे हैं क्योंकि “फ़ाइनेंस टीम को ऐसा पसंद है,” तो रुकिए। देखें कि क्या वह दस्तावेज़ वास्तव में काम, भुगतान विधि, या कानूनी जाँच के लिए ज़रूरी है। अक्सर नहीं होता।

फ्रीलांसर डेटा में काम के नमूने, प्रोफ़ाइल लिंक, प्रोजेक्ट टूल्स से IP पते, और चैट ऐप्स में संदेश भी शामिल हो सकते हैं। प्रोजेक्ट मैनेजर शायद केवल कॉन्ट्रैक्ट के बारे में सोचता है, लेकिन असली डेटा-ट्रेल इससे कहीं बड़ा होता है। एक Slack थ्रेड में पाँच व्यक्तिगत जानकारियाँ हो सकती हैं, और किसी को पता भी नहीं चलता।

प्लेटफ़ॉर्म-स्तरीय रिकॉर्ड्स को समझने के लिए फ्रीलांस मार्केटप्लेस के सभी टैग देखें। यह आपको धुंधले “प्रोजेक्ट डेटा” की जगह श्रेणियों में सोचने में मदद कर सकता है।

डेटा प्रकारों को एक छोटी सूची में लिखें। बहुत से कामों के लिए पाँच पंक्तियाँ काफ़ी हैं। अगर आप डेटा की सूची नहीं बना सकते, तो आप उसकी सुरक्षा भी नहीं कर सकते।

3. अपने संबंध के लिए सही GDPR भूमिका चुनें

पहली भूमिका जाँचने लायक है: कंट्रोलर। अगर आपका व्यवसाय तय करता है कि फ्रीलांसर के व्यक्तिगत डेटा का उपयोग क्यों और कैसे होगा, तो आप संभवतः कंट्रोलर हैं। यह तब आम है जब आप अपने procurement या HR प्रक्रिया के माध्यम से फ्रीलांसर को हायर करते हैं।

प्रोसेसर की भूमिका तब आती है जब फ्रीलांसर आपके निर्देशों पर व्यक्तिगत डेटा प्रोसेस करता है। एक वेबसाइट एडमिन जो आपकी कंपनी के लिए ग्राहक रिकॉर्ड संभालता है, इस पैटर्न में फिट हो सकता है। ऐसे में कॉन्ट्रैक्ट को अतिरिक्त ध्यान चाहिए, क्योंकि फ्रीलांसर सिर्फ़ विक्रेता नहीं है; वह आपके उद्देश्य के लिए डेटा संभाल रहा है।

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

अनुमान मत लगाइए। निर्णय प्रक्रिया का नक्शा बनाइए। कौन टूल चुनता है? रिटेंशन कौन तय करता है? कौन फ्रीलांसर को बताता है कि किसके डेटा तक पहुँचना है? जवाब भूमिका की ओर इशारा करते हैं। अगर जवाब बँटे हुए हैं, तो भूमिका भी बँटी हो सकती है।

एक आसान टेस्ट मदद करता है: अगर फ्रीलांसर काम चुन सकता है लेकिन उद्देश्य नहीं, तो आपका व्यवसाय आम तौर पर ज़िम्मेदार है। अगर दोनों पक्ष उद्देश्य तय करते हैं, तो यह कॉन्ट्रैक्ट में साफ़ लिखा होना चाहिए। अस्पष्टता बाद में भ्रम पैदा करती है, और भ्रम देरी।

अगर आप एक व्यापक हायरिंग चेकलिस्ट चाहते हैं, तो फ्रीलांसर को सुरक्षित तरीके से कैसे हायर करें एक उपयोगी साथी लेख है। GDPR सुरक्षा का सिर्फ़ एक हिस्सा है, लेकिन अनदेखा करने पर यही हिस्सा महँगा पड़ता है।

4. सही कॉन्ट्रैक्चुअल शर्तें लागू करें

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

गोपनीयता और डेटा सुरक्षा एक जैसी नहीं हैं, लेकिन दोनों ज़रूरी हैं। कोई फ्रीलांसर जो यह वादा करता है कि वह क्लाइंट रिकॉर्ड दोस्तों के साथ साझा नहीं करेगा, उसे फिर भी स्टोरेज, एक्सेस, और डिलीशन के निर्देश चाहिए। एक वादा सामाजिक है। दूसरा परिचालनात्मक है।

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

डेटा वापस करने और हटाने की शर्तें स्पष्ट होनी चाहिए। बताइए क्या वापस करना है, किस फ़ॉर्मेट में, और कब तक। फिर बताइए क्या हटाना है। “हम सब कुछ हटा देंगे” जैसा धुंधला वादा सुनने में अच्छा लगता है, लेकिन परखा जाने पर टूट जाता है।

सार्वजनिक नियमों और ऑनबोर्डिंग अपेक्षाओं वाली साइटों के लिए 24freelance.pro साइट के नियम. freelance पेज एक अच्छा अनुस्मारक है कि लिखित शर्तें मायने रखती हैं। यही बात आपके अपने कॉन्ट्रैक्ट्स पर भी लागू होती है।

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

5. केवल न्यूनतम आवश्यक डेटा ही इकट्ठा करें और साझा करें

डेटा मिनिमाइज़ेशन कहना आसान है, लेकिन इसे चूकना भी आसान है। केवल वही साझा करें जो फ्रीलांसर को काम करने के लिए चाहिए। अगर डिज़ाइनर को लोगो ब्रीफ़ चाहिए, तो उसे पेरोल फ़ाइलों की ज़रूरत नहीं है। अगर अनुवादक को सोर्स टेक्स्ट चाहिए, तो उसे आपके पूरे CRM एक्सपोर्ट की ज़रूरत नहीं है। एक काम, एक डेटा सेट।

कोई आइटम भेजने से पहले जाँचें कि क्या वह वाकई ज़रूरी है। अगर कंपनी रजिस्ट्रेशन नंबर काम चला सकता है, तो ID दस्तावेज़ इकट्ठा न करें। अगर टेस्टिंग के लिए 20 रिकॉर्ड का सैंपल पर्याप्त है, तो पूरा कस्टमर डेटाबेस साझा न करें। छोटे-छोटे कटौती भी मायने रखती हैं।

एक्सेस सीमित करना भी इसी विचार का हिस्सा है। फ्रीलांसर को सिर्फ़ वही फ़ोल्डर, टिकट, या सिस्टम दें जिनकी उसे ज़रूरत है। काम पूरा होने पर एक्सेस हटा दें। यह बुनियादी लगता है क्योंकि यह बुनियादी है।

संवेदनशील जानकारी की सबसे छोटी उपयोगी मात्रा साझा करें। अगर फ्रीलांसर को सिर्फ़ उपनाम चाहिए, तो नाम न भेजें। अगर उसे सिर्फ़ मास्क किए गए कार्ड रेफ़रेंस चाहिए, तो पूरा पेमेंट इतिहास न भेजें। जानकारी आपके इनबॉक्स से निकलते ही तेज़ी से फैलती है।

कुछ टीमें ज़्यादा इकट्ठा करती हैं क्योंकि उन्हें बाद में कुछ छूट जाने का डर होता है। आम तौर पर यही बाद की समस्या बनती है। एक हल्का-फुल्का फ़ाइल सेट समझाना आसान होता है, उसकी सुरक्षा आसान होती है, और उसे हटाना भी आसान होता है।

6. सुरक्षित कामकाज और संचार पद्धतियाँ तय करें

सुरक्षित संचार के लिए 10 टूल नहीं चाहिए। इसके लिए साफ़ आदतें चाहिए। जहाँ संभव हो, प्रोजेक्ट संदेशों के लिए कंपनी ईमेल इस्तेमाल करें। संवेदनशील अटैचमेंट्स को किसी भी व्यक्तिगत अकाउंट से भेजने से बचें। अगर फ़ाइल महत्वपूर्ण है, तो चैनल भी महत्वपूर्ण है।

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

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

पब्लिक Wi-Fi, साझा कंप्यूटर, और खुले कोलैबोरेशन स्पेस के साथ सावधानी बरतें। कैफ़े से काम करने वाला फ्रीलांसर भी बेहतरीन काम कर सकता है। लेकिन साझा मशीन पर खुला छोड़ दिया गया लॉगिन सत्र कुछ ही मिनटों में प्रोजेक्ट उजागर कर सकता है। यह नाटकीय नहीं है। यह आम है।

अगर प्रोजेक्ट क्लाउड सिस्टम्स से जुड़ा है, तो अपने एक्सेस सेटअप की तुलना क्लाउड कंप्यूटिंग तकनीक में बताई गई बुनियादी बातों से करें। एक्सेस परमिशन, अकाउंट ओनरशिप, और स्टोरेज लोकेशन सभी GDPR हैंडलिंग को प्रभावित करते हैं।

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

7. स्टोरेज, रिटेंशन, और डिलीशन सही तरीके से संभालें

रिटेंशन वह जगह है जहाँ बहुत-से फ्रीलांस प्रोजेक्ट भटक जाते हैं। कोई “सिर्फ़ ज़रूरत पड़ने पर” कॉन्ट्रैक्ट रख लेता है। कोई और इनवॉइस हमेशा के लिए सहेज देता है। कोई फ़ाइलें तीन फ़ोल्डरों में कॉपी कर देता है और सबसे पुरानी कॉपी भूल जाता है। यह कोई रणनीति नहीं है।

हर रिकॉर्ड प्रकार के लिए रिटेंशन अवधि तय करें। कॉन्ट्रैक्ट्स को काम की फ़ाइलों से ज़्यादा समय तक रखना पड़ सकता है। इनवॉइस टैक्स या अकाउंटिंग कारणों से रखनी पड़ सकती हैं। ड्राफ्ट, अस्थायी एक्सपोर्ट, और टेस्ट फ़ाइलों का प्रोजेक्ट खत्म होने के बाद आम तौर पर कोई कारण नहीं होता कि वे बनी रहें।

जो चाहिए उसे आर्काइव करें और जो नहीं चाहिए उसे हटाएँ। आर्काइविंग से कानूनी और अकाउंटिंग रिकॉर्ड उपलब्ध रहते हैं, बिना सक्रिय प्रोजेक्ट डेटा को घूमते रहने दिए। डिलीशन असली डिलीशन होनी चाहिए, न कि “मुझे लगता है मैंने डेस्कटॉप से हटा दिया।” जहाँ संभव हो, क्लाउड फ़ोल्डर, सिंक किए गए डिवाइस, बैकअप, और लोकल कॉपियाँ जाँचें।

काम के अंत में फ्रीलांसर से डिलीशन की पुष्टि माँगें। वह पुष्टि लिखित में रखें। अगर उसने सब-कॉन्ट्रैक्टर इस्तेमाल किए या साझा टूल्स का उपयोग किया, तो डिलीशन स्टेप में वे रास्ते भी शामिल होने चाहिए। एक भूली हुई कॉपी पूरी सफ़ाई को बेकार कर सकती है।

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

प्रोजेक्ट डेटा कभी संयोग से न रखें। संयोग कोई कानूनी कारण नहीं है। यह बस एक क्लीनअप समस्या है जो समयसीमा का इंतज़ार कर रही होती है।

8. भविष्य की फ्रीलांस हायरिंग के लिए एक सरल GDPR चेकलिस्ट बनाएँ

एक चेकलिस्ट एक अच्छे प्रोसेस को दस बार दोहराने योग्य बनाती है। ऑनबोर्डिंग से शुरू करें: क्या इस फ्रीलांसर को व्यक्तिगत डेटा चाहिए, हाँ या नहीं? फिर भूमिका, कॉन्ट्रैक्ट, न्यूनतम डेटा सेट, एक्सेस तरीका, और डिलीशन योजना जाँचें। छह कदम अधिकांश छोटे प्रोजेक्ट्स को कवर कर सकते हैं। यह आपकी फ्रीलांसर हायरिंग GDPR चेकलिस्ट का आधार होना चाहिए।

चेकलिस्ट इतनी छोटी रखें कि लोग वास्तव में उसका उपयोग करें। दो पेज का फ़ॉर्म चल सकता है। 20 पेज की पॉलिसी आम तौर पर नहीं चलती। उद्देश्य कागज़ी काम नहीं, बल्कि कम गलतियाँ है।

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

चेकलिस्ट को कॉन्ट्रैक्ट और प्रोजेक्ट ब्रीफ़ के साथ सेव करें। इससे अगला मैनेजर देख सकेगा कि क्या मंज़ूर हुआ, क्या साझा किया गया, और क्या हटाया गया। दस्तावेज़ीकरण की कमी बाद में अतिरिक्त काम बनाती है, खासकर तब जब क्लाइंट पूछे कि कोई विशेष दस्तावेज़ पहली बार में क्यों इकट्ठा किया गया था।

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

एक अंतिम व्यावहारिक आदत: हर प्रोजेक्ट के बाद चेकलिस्ट की समीक्षा इस सवाल के साथ करें, “हमने ऐसा क्या इकट्ठा किया जिसकी ज़रूरत नहीं थी?” यह एक वाक्य फ़ोल्डर भर ड्राफ्ट नीतियों से ज़्यादा समस्याएँ पकड़ लेता है।