DPA, डेटा रेजिडेंसी और सबप्रोसेसर

Didit डिफ़ॉल्ट रूप से EU में प्रोसेस करता है, एंटरप्राइज़ कॉन्ट्रैक्ट पर इन-कंट्री प्रोसेसिंग उपलब्ध है। यहां बताया गया है कि DPA, TOM, और आपकी प्रोक्योरमेंट रिव्यू जो सवाल पूछेगी उनके जवाब कैसे पाएं।

Didit सपोर्ट द्वारा लिखित · अपडेट किया गया 15 सितंबर 2026

#डेटा कहां प्रोसेस होता है

डिफ़ॉल्ट रूप से, सत्यापन डेटा EU में, आयरलैंड (eu-west-1) के AWS इन्फ़्रास्ट्रक्चर पर प्रसंस्कृत और संग्रहीत होता है। बायोमेट्रिक संक्रियाएँ उसी क्षेत्र में चलती हैं।

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

एक क्षेत्र स्पष्ट रूप से बताने लायक है क्योंकि यह अक्सर पूछा जाता है: किसी भी प्लान पर रूस में कोई प्रसंस्करण क्षेत्र नहीं है, इसलिए डेटा को रूसी संघ के भीतर रखने की आवश्यकता पूरी नहीं की जा सकती।

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

#DPA कैसे पाएं

आपके पास पहले से एक है। डेटा प्रसंस्करण परिशिष्ट (DPA) उन व्यावसायिक नियमों और शर्तों का अनुलग्नक 2 है जिन्हें आपके संगठन ने साइन-अप पर स्वीकार किया, और सेवा स्तर समझौता (SLA) अनुलग्नक 1 है। दोनों अलग से भी प्रकाशित हैं (व्यावसायिक शर्तें, Data Processing Addendum, Service Level Agreement) और मुफ़्त तथा पे-एज़-यू-गो प्लान पर आपके और Didit के बीच अनुच्छेद 28 समझौता हैं। GDPR अनुच्छेद 32 द्वारा अपेक्षित तकनीकी और संगठनात्मक उपाय (TOMs) दस्तावेज़ बिना NDA के आपके Didit संपर्क से अनुरोध पर उपलब्ध है।

पे-एज़-यू-गो पर जो नहीं है वह है प्रति-हस्ताक्षरित प्रति: अनुबंध वही प्रकाशित शर्तें हैं जैसी स्वीकार की गईं, और यदि कोई लेखा परीक्षक पूछे तो सहायता आपके संगठन की स्वीकृति तिथि की पुष्टि कर सकती है। यदि आपकी अनुपालन फ़ाइल को हस्ताक्षरित MSA, आपके अपने काग़ज़ पर DPA या बातचीत से तय SLA चाहिए, तो वह पूर्व-भुगतान क्रेडिट समझौते के साथ आता है, जो 2,000 USD से शुरू होता है और कभी समाप्त न होने वाले क्रेडिट में बदल जाता है। अपने Didit संपर्क से पूछें और अपना कानूनी नाम, हस्ताक्षरकर्ता का ईमेल और निगमन का देश तैयार रखें।

12

1. Terms & Policies में DPA और साइन किए गए एग्रीमेंट होते हैं।
2. ऐप्लिकेशन सेटिंग्स ऑर्गनाइज़ेशन-वाइड सेटिंग्स से अलग होती हैं।

यदि आपका संगठन हस्ताक्षरित प्रति के बजाय स्वीकृत शर्तों पर निर्भर है, तो सहायता से पुष्टि करवाएँ कि आपने ठीक कौन सा संस्करण कब स्वीकार किया। यह एक तथ्यात्मक प्रश्न है जिसका तथ्यात्मक उत्तर है, और यही उत्तर लेखा परीक्षक आपसे माँगेगा।

#सबप्रोसेसर

Didit के दो उप-प्रोसेसर हैं:

इनमें से किसी के माध्यम से कोई डेटा EEA से बाहर नहीं जाता। बाध्यकारी सूची और उसमें बदलावों की सूचना व्यवस्था DPA में है: यह तालिका वर्तमान उत्तर है, DPA वह दस्तावेज़ है जिस पर आपकी अनुपालन टीम निर्भर करती है।

#सिक्योरिटी क्वेश्चनेयर का जवाब देना

सिक्योरिटी रिव्यू जो ज़्यादातर चीज़ें मांगती है वे किसी न किसी डॉक्यूमेंट के रूप में मौजूद हैं। लगभग उसी क्रम में जिसमें क्वेश्चनेयर पूछते हैं:

तारीखों के साथ पूरी क्रेडेंशियल सूची के लिए देखें सर्टिफिकेशन और कंप्लायंस।

#ऐसी प्रतिबद्धताएं जो यह पेज आपके लिए नहीं कर सकता

प्रोक्योरमेंट में आने वाले कुछ सवाल कॉन्ट्रैक्चुअल होते हैं, टेक्निकल नहीं, और ईमानदार जवाब यह है कि वे एक नेगोशिएटेड एग्रीमेंट में होने चाहिए:

• डिलीशन को लेकर कॉन्ट्रैक्चुअल वारंटी, जिसे किसी जांचने योग्य ऑडिट ट्रेल या समय-समय पर होने वाले सर्टिफिकेशन का समर्थन हो।
• GDPR की समयसीमा के अलावा ब्रीच नोटिफिकेशन की समयसीमाएं - उदाहरण के लिए ऑस्ट्रेलिया की Notifiable Data Breaches असेसमेंट विंडो।
• क्षेत्रीय होस्टिंग रोडमैप और उनसे जुड़ी तारीखें।
• रिटेंशन ज़िम्मेदारियां जो आपको लगता है कि आप पर लागू होती हैं।

इनमें से हर एक को अपने Didit संपर्क के पास लाएं और जवाब कॉन्ट्रैक्ट में लें। एक हेल्प पेज किसी प्रतिबद्धता का वर्णन करना उस प्रतिबद्धता के बराबर नहीं है, और एक को दूसरा मान लेना हमारे लिए नहीं बल्कि आपके लिए जोखिम है।

#आपके यूज़र्स से इरेज़र रिक्वेस्ट

आपके यूज़र्स आपके डेटा सब्जेक्ट हैं, और एक इरेज़र रिक्वेस्ट कंट्रोलर के तौर पर आपके पास आती है। इस पर सीधे कार्रवाई करने के लिए आपके पास टूल हैं: कंसोल या API से सेशन डिलीट करें, तुरंत और अपरिवर्तनीय रूप से। देखें सेशन और व्यक्तिगत डेटा डिलीट करना।

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