ओहि प्रश्न पर सरल-अंग्रेजी गहन-अध्ययन जे वास्तवमे मायने रखैत अछि।

न्यूनतम विषयवस्तु जाँच-सूची

Act क Section 5(1) आ DPDP Rules क Rule 3 अन्तर्गत, अहाँक गोपनीयता सूचनामे रहबाक चाही:

1. अहाँ जे प्रत्येक श्रेणीक व्यक्तिगत डेटा संग्रह करैत छी ओकर मदवार सूची
2. ओ डेटा अहाँ जे प्रत्येक उद्देश्य लेल प्रसंस्करण करैत छी ओकर मदवार सूची
3. जाहि तरीकासँ Data Principal सहमति वापस लऽ सकैत अछि — जेना ओ देल गेल छल, ओहि समानता संग
4. जाहि तरीकासँ ओ Sections 11-14 अन्तर्गत अपन अधिकार प्रयोग कऽ सकैत अछि
5. जाहि तरीकासँ ओ Data Protection Board मे शिकायत दर्ज कऽ सकैत अछि

मदवार सूची किएक महत्वपूर्ण

'हम सेवा देबाक लेल व्यक्तिगत सूचना संग्रह करैत छी' ई मदवार सूची नहि थिक। मानक एकर लगीच अछि: 'हम संग्रह करैत छी: (क) नाम, (ख) मोबाइल नम्बर, (ग) ईमेल पता, (घ) उपकरण पहिचानकर्ता, (ङ) हमर एप प्रयोग करैत काल स्थान निर्देशांक।' प्रत्येक मद ततेक विशिष्ट रहबाक चाही जे Data Principal ओकरा अपना साँचहुँ देल वस्तु मानिकऽ चिन्ह सकय।

उद्देश्य लेल सेहो ओएह मानक: 'सेवा देबाक लेल' बड़ अस्पष्ट अछि। 'अहाँक ऑर्डर प्रसंस्करण करबाक लेल, SMS सँ डिलिवरी अपडेट पठेबाक लेल, आ ग्राहक-सहायता प्रश्नक उत्तर देबाक लेल' ई बेसी लगीच अछि।

वापसीक समानता

जँ साइनअप पर चेकबॉक्स टिक कऽ सहमति देल गेल छल, तँ वापसी कम-सँ-कम ततबे सहज रहबाक चाही — सामान्यतः खाता सेटिंगमे एक-क्लिक टॉगल। जँ कुकी बैनर द्वारा सहमति देल गेल छल, तँ वापसी ओहि बैनर (वा स्पष्ट समकक्ष) द्वारा उपलब्ध रहबाक चाही। सभसँ स्पष्ट परीक्षण: की एकटा गैर-तकनीकी प्रयोक्ता सहायतासँ सम्पर्क कएने बिना 30 सेकेंडमे सहमति वापस लऽ सकैत अछि?

भाषा

Section 5(3) अनुसार सूचना अनुरोध पर अंग्रेजी सहित 22 Eighth Schedule भाषामे उपलब्ध रहबाक चाही। बेसी डिजिटल सतह पर 'अनुरोध पर' मानेकी एकटा भाषा-चयन नियंत्रण, से Rules स्पष्ट करैत अछि। सर्वोत्तम अभ्यास: प्रयोक्ताक भाषा चिन्हिकऽ डिफॉल्ट रूपमे मिलैत संस्करण देखाउ।

अनुपालक सूचना कोना लगैत अछि

सम्पूर्ण रूपसँ तैयार उदाहरण लेल अहाँ हमर Privacy Notice Template (हमर पुस्तकालयमे Template 01) देखि सकैत छी। संरचना तीन स्तरमे काज करैत अछि: ऊपर संक्षिप्त सार, बीचमे मदवार तालिका, नीचाँ सम्पर्क आ अधिकार तंत्र।

Section 7 अन्तर्गत छह कानूनी आधार

DPDP Act क Section 7 छह 'वैध प्रयोग' वर्णन करैत अछि जकरा लेल एकटा Data Fiduciary, Section 6 अन्तर्गत स्पष्ट सहमति नहि लऽ कऽ सेहो व्यक्तिगत डेटा प्रसंस्करण कऽ सकैत अछि:

1. Section 7(a) — स्वेच्छासँ देनाइ: जतय Data Principal कोनो विशिष्ट उद्देश्य लेल स्वेच्छासँ अपन व्यक्तिगत डेटा देने अछि, आ ई संकेत नहि देने अछि जे ओ सहमत नहि अछि।
2. Section 7(b) — राज्य प्रसंस्करण: जतय राज्य वा ओकर संस्था अनुदान, लाभ, सेवा, प्रमाणपत्र, अनुज्ञप्ति वा अनुमति देबाक वा जारी करबाक लेल प्रसंस्करण करैत अछि।
3. Section 7(c) — वैधानिक अनुपालन: जतय कोनो कानून, फैसला वा आदेशक पालन लेल प्रसंस्करण आवश्यक अछि।
4. Section 7(d) — चिकित्सा आपात: जतय कोनो व्यक्तिक जीवन वा स्वास्थ्यकेँ खतरा बला चिकित्सा आपातमे जवाब देबाक लेल प्रसंस्करण आवश्यक अछि।
5. Section 7(e) — विपत्ति / सार्वजनिक स्वास्थ्य: जतय विपत्ति वा सार्वजनिक व्यवस्था टूटबाक काल उपाय लेल प्रसंस्करण आवश्यक अछि।
6. Section 7(g) — रोजगार: जतय नियोक्ताकेँ हानि वा दायित्वसँ बचेबा सहित रोजगारक उद्देश्य लेल प्रसंस्करण अछि।

कम-प्रयोगक समस्या

स्पष्ट रूपसँ Section 7(a) स्वेच्छासँ देनाइक दायरामे अबय बला प्रसंस्करण लेल सेहो बहुत टीम सहमति पर जोर दैत अछि — जेना ग्राहक सम्पर्क फॉर्ममे टाइप कएल ईमेलक प्रसंस्करण, वा चेकआउटमे टाइप कएल पताक प्रसंस्करण। परिणाम अछि सहमति थकान (बैनर पर बैनर), जे स्वयं Section 6 क भावनाक उल्लंघन करैत अछि (सहमति स्वतंत्र रहबाक चाही)।

बेसी-प्रयोगक समस्या

एकर उनटा बेसी सामान्य आ बेसी खतरनाक अछि। प्रयोक्ता साइनअप पर अपन पता 'स्वेच्छासँ देलक' ई आधार पर प्रचार ईमेल पठेबाक लेल विपणन टीम Section 7(a) क दावा करैत अछि — मुदा प्रयोक्ता ओ खाता बनेबाक लेल देने छल, विपणन लेल नहि। डेटा जाहि उद्देश्य लेल देल गेल छल, ताहिसँ अतिरिक्त आन उद्देश्यक प्रसंस्करण धरि Section 7(a) विस्तारित नहि होइत अछि।

कोना चुनू

हम ग्राहक संग प्रयोग करय बला आधार-चयन परीक्षण:

1. की प्रयोक्ता माँगल सेवा लेल प्रसंस्करण कड़ाईसँ आवश्यक अछि? → 7(a) स्वेच्छासँ देनाइ
2. की प्रसंस्करण कोनो विशिष्ट कानून, फैसला वा आदेश द्वारा आवश्यक अछि? → 7(c) वैधानिक
3. की मूल सेवासँ बाहर कोनो वस्तुमे opt-in करबाक लेल प्रयोक्ताकेँ कहल जा रहल अछि? → S.6 सहमति
4. एहिमेसँ कोनो नहि? → पुनर्विचार करू जे अहाँकेँ प्रसंस्करण करबाक चाही की नहि

स्तम्भ 1: सूक्ष्मता

प्रत्येक उद्देश्यकेँ अपन सहमति चाही। खाता निर्माण, विपणन, व्यवहार विश्लेषण, तेसर-पक्ष साझेदारी आ कुकी-आधारित ट्रैकिंग सभकेँ समेटय बला एकहि 'हम गोपनीयता नीति स्वीकार करैत छी' चेकबॉक्स Section 6 क जाँचमे नहि टिकत। प्रयोक्ताकेँ खाता निर्माणमे opt-in करैत काल विपणनसँ opt-out करबाक सक्षम रहबाक चाही। न्यूजलेटरमे opt-in करैत काल प्रचार SMS सँ opt-out करबाक सक्षम रहबाक चाही।

हम अनुशंसा करय बला न्यूनतम सूक्ष्मता: खाता/सेवा सहमति, चैनल-वार विपणन (ईमेल / SMS / पुश / WhatsApp), व्यवहार विश्लेषण, साझेदार प्रकार अनुसार वर्गीकृत तेसर-पक्ष साझेदारी। पाँच अलग स्विच, एकटा महा-स्विच नहि।

स्तम्भ 2: वापसीक समानता

वापसी 'देबा जकाँ सहज' रहबाक चाही — ओएह चैनल, ततबे चरण, ततबे प्रयास। जँ सहमति एक-क्लिक टॉगल छल, तँ वापसी सेहो एक-क्लिक टॉगल रहबाक चाही। जँ SMS opt-in (STOP कीवर्ड) द्वारा सहमति देल गेल छल, तँ ओहि STOP कीवर्ड द्वारा वापसी काज करबाक चाही। वापसीकेँ तीन मेनू गहीर नुकाएब, वा email-to-support माँगब अनुपालनहीन थिक।

परीक्षण: गैर-तकनीकी प्रयोक्ताकेँ विशिष्ट सहमति वापस लेबामे कतेक समय लगैत अछि, नापू। जँ 30 सेकेंडसँ बेसी अछि तँ अहाँक डिजाइन अनुपालनहीन अछि।

स्तम्भ 3: डार्क पैटर्नसँ बचाव

Rules 'डार्क पैटर्न' शब्द प्रयोग नहि करैत अछि, मुदा Section 6 क आवश्यकता (स्वतंत्र, विशिष्ट, सूचित, बिनु शर्त, स्पष्ट) ओएह प्रभाव उत्पन्न करैत अछि। जाहिसँ बचबाक अछि:

• पहिनेसँ टिक कएल सहमति बक्सा
• 'सभ स्वीकार करू' प्रमुख बटनक रूपमे, जखन 'सभ अस्वीकार करू' उप-मेनूमे नुकाएल
• धूसर 'अस्वीकार' बटनक विरुद्ध रंगीन 'स्वीकार' बटन
• प्रयोक्ताक अस्वीकार कएलाक बादो बेर-बेर फेर पूछब
• ऐच्छिक सहमति अस्वीकार कएलासँ सेवा घटत, से संकेत दैत 'सीमित सुविधाक संग आगू बढ़ू' प्रस्तुति
• असम्बन्धित उद्देश्यकेँ एकहि स्विचमे बान्हब

स्तम्भ 4: लेखापरीक्षा पथ

माँग पर सहमति सिद्ध करबाक सक्षम रहबाक चाही। प्रत्येक सहमति घटना लेल न्यूनतम लग प्रविष्टि:

• हैश कएल Data Principal पहिचानकर्ता
• टाइमस्टैम्प (UTC + IST)
• चैनल (वेब, एप, कॉलमे, SMS, कागज)
• उद्देश्य कोड
• देखाओल सूचना संस्करण
• परिणाम (देल गेल, अस्वीकार, वापस लेल)

लगकेँ कम-सँ-कम सम्बन्धक अवधि आ अहाँक धारण अवधि धरि संग्रहित करू। सूचना संस्करण बिनाक सहमति अभिलेख उल्लेखनीय रूपसँ कमजोर होइत अछि — प्रयोक्ताकेँ साँचहुँ की कहल गेल छल, से संस्करणे सिद्ध करैत अछि।

संदर्भ डिजाइन

हमर Consent UX Spec (Template 03) बैनर, सूक्ष्म मोडल, प्राथमिकता केन्द्र, लेखापरीक्षा JSON स्कीमा आ API अनुबंध समेटय बला सम्पूर्ण संदर्भ वास्तुकला दैत अछि। एकरा शुरुआती बिन्दुक रूपमे प्रयोग करू आ अपन स्टैक अनुसार ढालू।

पाँच चरण

प्रत्येक परिचालन DSAR कार्यक्रममे जतबो अलग नामसँ पुकारू, ओएह पाँच चरण रहैत अछि:

1. प्राप्ति
2. पहिचान सत्यापन
3. खोज आ निर्भरता मैपिंग
4. जवाब मसौदा आ स्वीकृति
5. वितरण आ लेखापरीक्षा

चरण 1: प्राप्ति

अनेक प्राप्ति चैनल — वेब फॉर्म, एपमे स्व-सेवा, ईमेल, ग्राहक सहायता एस्केलेशन, डाक — सभ एकटा अद्वितीय संदर्भ संख्या सहित एकहि टिकट पंक्तिमे मिलैत अछि। ओएह संदर्भ सम्पूर्ण समय Data Principal क ट्रैकिंग ID आ अहाँक केस ID रहैत अछि।

प्राप्तिक काल लिखू: कोन अधिकार प्रयोग भऽ रहल अछि (पहुँच / सुधार / मेटाएब / शिकायत), Data Principal कहल पहिचानकर्ता (ईमेल, खाता ID), भेटबाक तिथि, आ हुनकर देल कोनो संदर्भ।

चरण 2: पहिचान सत्यापन

अनुरोध करय बलाइए Data Principal थिक, से अहाँकेँ सत्यापित करय पड़त। मजबूतीक क्रममे सत्यापन विधि:

• प्रमाणित सत्र (लॉग-इन रहैत काल कएल अनुरोध)
• बहु-कारक सत्यापन (निबंधित फोन वा ईमेल पर OTP)
• ज्ञान-आधारित प्रश्न (अंतिम लेनदेन, निबंधित पता)
• दस्तावेज-आधारित सत्यापन (Aadhaar ऑफलाइन KYC, DigiLocker)

सत्यापन मानककेँ संलग्न डेटाक संवेदनशीलतासँ मिलाउ। विपणन सूचीक प्रविष्टि मेटेबा लेल वित्तीय लेनदेन इतिहास मेटेबासँ कम चाही।

चरण 3: खोज आ निर्भरता मैपिंग

असफल DSAR जवाबक सभसँ पैघ एकल कारण: टीम कोनो सिस्टम बिसरि गेल। प्रयोक्ता अहाँक CRM मे, अहाँक सहायता हेल्पडेस्कमे, अहाँक विपणन ऑटोमेशन औजारमे, अहाँक विश्लेषण प्लेटफॉर्म पर, अहाँक डेटा गोदाममे, अहाँक बैकअपमे रहैत अछि — आ सम्भवतः अहाँक प्रोसेसरक सिस्टममे सेहो।

Data Principal डेटा राखि सकय बला प्रत्येक सिस्टमक निर्भरता नक्शा (RoPA अनुसार) राखू। DSAR वर्कफ्लो सूचीक प्रत्येक सिस्टम देखैत अछि, निष्कर्ष संग्रह करैत अछि, आ एकीकृत करैत अछि।

चरण 4: जवाब मसौदा आ स्वीकृति

जटिल अनुरोध लेल जवाबमे रहैत अछि:

• हम कोन डेटा रखैत छी (श्रेणी आ स्रोत)
• प्रत्येक श्रेणीक उद्देश्य
• अनुरोध सम्पूर्ण, आंशिक पूरा भऽ सकैत अछि, वा अस्वीकार
• कोनो आंशिक अस्वीकारक कारण (जेना, वैधानिक धारण)
• असंतुष्ट रहला पर Data Principal लऽ सकय बला अगिला डेग (Grievance Officer धरि, फेर DPBI धरि एस्केलेशन)

पठेबासँ पहिने Privacy / DPO स्वीकृति। अस्वीकार लेल कानूनी स्वीकृति।

चरण 5: वितरण आ लेखापरीक्षा

Data Principal माँगल चैनल द्वारा (वा डिफॉल्ट रूपमे हुनकर निबंधित चैनल द्वारा) वितरित करू। वितरण लग करू। सम्पूर्ण लेखापरीक्षा पथ सहित केस बन्द करू। SLA गणना आ RAG स्थिति स्वचालित करय बला तैयार स्प्रेडशीट लेल Template 10 (DSAR Tracker) प्रयोग करू।

90-दिनक SLA

Rule 14(3) जवाबकेँ 90 दिनमे सीमित करैत अछि। ई अधिकतम सीमा थिक, लक्ष्य नहि। परिपक्व कार्यक्रम नियमित पहुँच अनुरोध लेल 14-30 दिन, जटिल मेटाएब वा सुधार लेल बेसी लक्ष्य रखैत अछि। अपन वितरण ट्रैक करू — जँ अहाँ लगातार 60 दिनसँ ऊपर छी, तँ अहाँक परिचालन डिजाइने समस्या थिक।

पता चलबासँ अधिसूचना धरि: चारि चरण

चरण 1: पता चलब (T+0 सँ T+2 घंटा)

जागरूकता कतयसँ आएल: निगरानीसँ चेतावनी, विक्रेताक खुलासा, ग्राहक शिकायत, पत्रकारक पूछताछ, नियामक सम्पर्क? प्रत्येक लेल अलग शुरुआती-चरणक सम्हार चाही। नियंत्रण तत्काल प्राथमिकता — पहुँच बाट बन्द करू, प्रभावित सिस्टम अलग करू, प्रमाण सुरक्षित राखू।

चरण 2: वर्गीकरण (T+2 सँ T+12 घंटा)

क्रॉस-फंक्शनल घटना जवाब टीम बैसैत अछि (तकनीकी, कानूनी, संचार, व्यवसाय मालिक, कार्यकारी प्रायोजक)। शुरुआती दायरा मूल्यांकन: कोन डेटा, कतेक अभिलेख, कोन आक्रमण बाट। तीव्रता वर्गीकरण: की ई अधिसूचनायोग्य अछि? DPDP क सीमा विस्तृत — 'अनधिकृत प्रसंस्करण' वा 'आकस्मिक खुलासा' बला कोनो 'व्यक्तिगत डेटा उल्लंघन' Section 8(6) केँ सक्रिय करैत अछि।

चरण 3: अधिसूचना (T+12 सँ T+72 घंटा)

जँ अधिसूचनायोग्य अछि, तँ विलम्ब बिना दू अलग अधिसूचना जएबाक चाही:

• Data Protection Board of India केँ: Rule 7 अनुसार विस्तृत प्रतिवेदन — उल्लंघनक स्वरूप, श्रेणी आ अभिलेखक अनुमानित संख्या, सम्भावित परिणाम, उठाओल डेग।
• प्रत्येक प्रभावित Data Principal केँ: स्पष्ट, सरल-भाषाक सूचना — की भेल, कोन डेटा, हुनका कोन डेग उठएबाक चाही, सहायता लेल कतय सम्पर्क करी।

'विलम्ब बिना' मानेकी 72 घंटा नहि। 72-घंटाक अंक GDPR क थिक — DPDP तय नहि करैत अछि, मुदा कार्यान्वयन अपेक्षा सम्भवतः ओएह रहत। सम्पूर्ण जाँचक बाट नहि जोहू; जे बूझल अछि ताहि संग शुरुआती अधिसूचना पठाउ, आ बेसी स्थापित भेला पर अद्यतन करू।

चरण 4: नियंत्रण, पुनर्प्राप्ति, पाठ (T+72 घंटाक बाद)

सम्पूर्ण फोरेंसिक जाँच, मूल-कारण विश्लेषण, उपचार योजना, नियामक अनुसरण, ग्राहक संचार, घटनोत्तर समीक्षा। घटनोत्तर समीक्षा निर्णायक — Section 8(5) अन्तर्गत दायित्व सीमित करय बला 'उचित उपाय'क प्रमाण ओएह थिक।

संचारक व्यवस्था

पहिनेसँ तैयार अधिसूचना टेम्पलेट (Template 05 प्रयोग करू) वास्तविक घटनाक काल 6+ घंटा बचबैत अछि। टेम्पलेटमे घटना-विशिष्ट डेटा लेल स्थानधारक रहबाक चाही, मुदा संरचना, स्वर आ आवश्यक तत्व स्थिर रहबाक चाही।

आंतरिक संचार: प्रत्येक प्राथमिक सम्पर्क लेल विकल्प सहित स्थापित एस्केलेशन वृक्ष। T+0 पर वार-रूम चैनल स्थापित।

निर्णय अधिकार

ककरा अधिकार अछि, लिखू: घटना घोषित करब, Board धरि एस्केलेट करब, अधिसूचना शुरू करब, बादक कोनो दावाक निपटारा पर सहमत होएब, सार्वजनिक रूपसँ संचार करब। ई निर्णय घटनाक काल पहिल बेर नहि लेल जा सकैत अछि।

रनबुक

Template 04 (72-Hour Breach Runbook) सभ छह चरण (T+0 सँ T+30) समेटय बला हमर 25-पन्नाक संदर्भ थिक, भूमिका-विशिष्ट जाँच-सूची, तीव्रता वर्गीकरण, निर्णय वृक्ष आ टेबलटॉप परिदृश्य सहित। आवश्यकता पड़बासँ पहिनहि एकरा पढ़ू।

टकरावक बिन्दु

BFSI संस्था अनेक नियामकक अन्तर्गत काज करैत अछि। DPDP ओहिमेसँ ककरो प्रतिस्थापित नहि करैत अछि — ई ऊपर स्तरक रूपमे जुड़ैत अछि। घर्षण तीन बिन्दु पर सभसँ तीव्र अछि:

1. KYC धारण vs DSAR मेटाएब

RBI क KYC सम्बन्धी Master Direction ग्राहक सम्बन्ध समाप्त भेला दिनसँ 5-वर्षक धारण माँगैत अछि। PMLA Section 12 सेहो 5-वर्षक धारण माँगैत अछि। मेटेबाक अनुरोध करय बला ग्राहकक KYC ई अवधिसँ पहिने नहि मेटाओल जा सकैत अछि — मुदा ई अहाँकेँ अपन DSAR जवाबमे स्पष्ट बुझएबाक अछि, मौन अस्वीकार नहि।

सर्वोत्तम-अभ्यास जवाब टेम्पलेट: '[कानून] अनुसार, हमरा [श्रेणी] केँ [ट्रिगर] सँ [अवधि] धरि रखबाक अछि। रखबाक आवश्यकता नहि बला डेटा हम मेटा देलहुँ — अर्थात् [सूची]। बाकी डेटा खाली वैधानिक उद्देश्य लेल राखल अछि आ आन कोनो प्रयोग लेल उपलब्ध नहि।'

2. भुगतान डेटा स्थानीयकरण

RBI क भुगतान-प्रणाली डेटा स्थानीयकरण निर्देश (2018) भुगतान डेटा खाली भारतमे संग्रहित करबाक माँग करैत अछि। एकर उनटा DPDP Section 16 आब सीमा-पार हस्तांतरणकेँ अनुमति दैत अछि, जतय केन्द्र सरकार देश-प्रतिबंध अधिसूचना जारी करैत अछि ताहिसँ अतिरिक्त। जतय ओ मिलैत अछि (भारतीय प्रयोक्ताक भुगतान डेटा), ओतय RBI नियम बेसी कठोर — ओकरे पालन करू।

भ्रमक बिन्दु: बहुत BFSI टीम RBI स्थानीयकरणकेँ DPDP आवश्यकता जकाँ मानैत अछि। ओ नहि थिक। ओ स्वतंत्र अछि। भविष्यमे Section 16 अन्तर्गत कोनो MeitY अधिसूचना गैर-भुगतान डेटाकेँ प्रतिबंधित करैत अछि, तँ ओ एकटा अतिरिक्त बाध्यता थिक, विकल्प नहि।

3. उल्लंघन अधिसूचनाक प्रतिस्पर्धी स्थिति

एकहि उल्लंघन लेल अहाँक सामने एकहि संग अनेक अधिसूचना बाध्यता भऽ सकैत अछि:

• CERT-In: 6 घंटा (28 अप्रैल 2022 क Directions अन्तर्गत)
• RBI: सूचना सुरक्षा सम्बन्धी Master Direction अनुसार (संस्थाक प्रकार अनुसार भिन्न)
• IRDAI / SEBI: क्षेत्रीय साइबर-सुरक्षा दिशानिर्देश अनुसार
• DPDP: DPBI केँ आ प्रभावित Data Principals केँ 'विलम्ब बिना'

एकीकृत प्लेबुक बिना, अधिसूचना अलग-अलग समय पर, अलग दायराक संग, अलग भाषामे जाइत अछि — आ एक-दोसरक खंडन कऽ सकैत अछि। सरलतम बचाव: साझा घटना अभिलेखसँ सभ आवश्यक अधिसूचना उत्पन्न करय बला एकहि घटना-प्रबंधन प्रक्रिया।

SDF प्रश्न

मापदंड अधिसूचित भेला पर लगभग प्रत्येक अर्थपूर्ण BFSI संस्थाकेँ SDF नामांकनक अपेक्षा करबाक चाही। परिमाण + संवेदनशीलता + क्षेत्रीय जोखिम + सार्वभौम-हित कारक सभ ओहि दिशामे ठेलैत अछि। अहाँ नामित होएब, ई अनुमान पर अतिरिक्त Rule 13 बाध्यता (DPIA कार्यक्रम, लेखापरीक्षा चक्र, बोर्ड रिपोर्टिंग सहित भारत-निवासी DPO) अपन रोडमैपमे सम्मिलित करू।

Account Aggregator प्रश्न

जँ अहाँ AA ढाँचाक अन्तर्गत FIU छी: अहाँक AA-मध्यस्थ डेटा साझेदारी RBI नियमक अन्तर्गत सहमति-आधारित अछि। ताहि पर DPDP Section 6 आवश्यकता स्तरक रूपमे जोड़ू — प्रत्येक उद्देश्य लेल सूक्ष्मता, वापसी समानता, लेखापरीक्षा पथ। बहुत AA कार्यान्वयन RBI सहमति लिखैत अछि मुदा DPDP तत्व बिना।

केन्द्रीय भ्रम

'हम ABDM-अनुपालक छी, तेँ हम DPDP-अनुपालक छी।' प्रत्येक स्वास्थ्य सेवा काजमे हम ई सुनैत छी। ई सही नहि।

NDHM आ ABDM सहमति ABDM परिवेशक अन्तर्गत डेटा साझेदारी केँ नियंत्रित करैत अछि। DPDP सहमति (Section 6) अहाँक संस्थाक भीतर अहाँक व्यक्तिगत डेटा प्रसंस्करण केँ नियंत्रित करैत अछि। ओ मिलैत अछि मुदा कोनो दोसरक विकल्प नहि।

जतय ओ मिलैत अछि

सिद्धांत मिलल अछि: सूक्ष्म, उद्देश्य-सीमित, समय-बद्ध सहमति। ABDM सहमति अभिव्यक्ति (उद्देश्य, डेटा श्रेणी, अवधि) DPDP सहमति आवश्यकता पर बेस साफ ढंगसँ मैप होइत अछि। जतय अहाँ ABDM सहमति प्रवाह बनौने छी, ओतय अहाँ ओहि डेटा लेल DPDP-अनुपालक प्रवाहक 70% बाट पहुँचि गेल छी।

जतय ओ भिन्न अछि

तीन उल्लेखनीय भिन्नता:

• दायरा: ABDM द्वारा साझा कएल डेटा ABDM समेटैत अछि। अहाँ जे सभ व्यक्तिगत डेटा प्रसंस्करण करैत छी से DPDP समेटैत अछि। रोगीक अपॉइंटमेंट बुकिंग डेटा DPDP दायरामे अछि मुदा ABDM दायरामे नहि।
• वापसी समानता: ABDM सहमति वापसी ABDM consent manager द्वारा होइत अछि। देल चैनल संग वापसी समानता DPDP माँगैत अछि — अहाँक संस्थाकेँ ओ सोझे देबय पड़त।
• बच्चाक डेटा: ABDM मे बाल-चिकित्सा सहमति प्रवाह अछि। DPDP Section 9 + Rule 10 मानक ऊँच करैत अछि — सत्यापन-योग्य अभिभावकक सहमति आवश्यक, खाली संरक्षकक हस्ताक्षर नहि।

धारणक पहेली

अहाँक सामने अनेक धारण चालक अछि:

• Clinical Establishments Act / राज्य नियम: छुट्टीक बाद कम-सँ-कम 3-5 वर्ष
• चिकित्सा अभिलेख सम्बन्धी NMC Regulations: इनडोर 3 वर्ष, शल्य / ऑन्कोलॉजी लेल बेसी
• PCPNDT Act: निदान केन्द्र लेल विशिष्ट बाध्यता
• D&C Rules: Schedule H पर्ची अभिलेख
• NABH (जतय लागू): मान्यता अध्याय अनुसार
• DPDP: वैधानिक रूपसँ रखबाक आवश्यकता नहि रहला पर अनुरोध पर मेटाएब

एकरा सम्हारबाक सही तरीका: प्रत्येक डेटा श्रेणीकेँ सभसँ कठोर लागू धारण बाध्यतासँ मैप करय बला एकहि धारण तालिका (Template 15), कानूनी स्रोत स्पष्ट लिखैत। एकरा DSAR जवाब लेल मुख्य संदर्भ बनाउ।

HealthTech एप प्रकार

जँ अहाँ HealthTech एप छी — टेलिमेडिसिन, फिटनेस, मानसिक स्वास्थ्य — तँ ऊपरक बेसी लागू होइत अछि। संगहि: बेसी प्रयोक्ता वयस्क रहत मुदा बच्चाक ओरसँ एप प्रयोग करय बला अभिभावक एकटा अर्थपूर्ण अल्पसंख्यक रहत। ओहि अल्पसंख्यक पर Section 9 लागू होइत अछि। बेसी प्रयोक्ताकेँ आवश्यकता नहि रहला पर सेहो सत्यापन-योग्य अभिभावकक सहमति प्रवाह बनाउ।

Rule 10 तय कएल मानक

बच्चाक (18 वर्षसँ कम कोनो व्यक्तिक) व्यक्तिगत डेटा प्रसंस्करणसँ पहिने सत्यापन-योग्य अभिभावकक सहमति लेबाक, से Act क Section 9 Data Fiduciaries सँ माँगैत अछि। 'सत्यापन-योग्य' मानेकी, से Rule 10 तय करैत अछि — उत्तर: सहमति देनिहार व्यक्ति अभिभावक थिक आ ओ सहमत अछि, दुनूक पुष्टि करय बला एकटा भरोसेमंद तंत्र।

स्व-घोषित उम्रक गेट ('की अहाँ 18 वा ताहिसँ बेसी छी?') ई मानक पूरा नहि करैत अछि। बच्चाक डेटाकेँ गम्भीरतासँ लेनिहार कोनो गोपनीयता व्यवस्थाक अन्तर्गत ओ कहियो पर्याप्त नहि छल, आ Rule 10 केँ ओ निश्चित रूपसँ पूरा नहि करैत अछि।

ई किएक कठिन

तकनीकी समस्या: अहाँ कहियो नहि भेटल व्यक्तिक अभिभावकत्वक स्थिति, बच्चाक्के भऽ सकय बला उपकरण पर कोना सत्यापित करब? कानूनी समस्या: अभिभावकक सहमति पर्याप्त नहि — सहमति जे किछु होअय, बच्चाक 'ट्रैकिंग, व्यवहार निगरानी वा लक्षित विज्ञापन'सँ सेहो अहाँकेँ दूर रहबाक अछि।

काज करैत देखल चारि वास्तुकला

1. DigiLocker-मध्यस्थ

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

2. Aadhaar ऑफलाइन KYC

अभिभावक एकटा Aadhaar ऑफलाइन KYC कलाकृति (PDF वा QR) साझा करैत अछि, जे हुनकर पहिचान स्थापित करैत अछि। अभिभावकत्वक घोषणा संग मिलिकऽ ई Rule 10 केँ संतुष्ट करैत अछि। घर्षण मध्यम; तकनीकी एकीकरण नीक जकाँ लिखल।

3. भुगतान-साधन सत्यापन

अभिभावक अपन PAN सँ जुड़ल सत्यापित भुगतान साधनसँ एकटा टोकन लेनदेन (₹1, वापस देल) करैत अछि। ई वयस्क पहिचान (बैंकमे KYC) आ सहमति सिद्ध करैत अछि। भुगतान जे तरहेँ होइते अछि, ओहि शुल्क बला सेवा लेल उपयोगी।

4. दस्तावेज-अपलोड + हस्तचालित समीक्षा

अभिभावक ID आ एकटा सम्बन्ध दस्तावेज (विद्यालयक अभिलेख, अभिभावकक नाम सहित पासपोर्ट, इत्यादि) अपलोड करैत अछि। प्रशिक्षित टीम द्वारा हस्तचालित समीक्षा। उच्च घर्षण, उच्च लागत — खाली कम-परिमाणक प्रीमियम सेवा लेल व्यवहार्य।

'व्यवहार लक्ष्यीकरण नहि' नियम

Section 9 बच्चाक ट्रैकिंग, व्यवहार निगरानी वा लक्षित विज्ञापन निषेध करैत अछि। ई निरपेक्ष अछि, सहमतिसँ एकर निवारण नहि होइत अछि। अभिभावकक सहमति रहला पर सेहो अहाँ नहि कऽ सकैत छी:

• कोनो बच्चा प्रयोक्ताक सत्र पर व्यवहार-वैयक्तिकीकरण इंजन चलाएब
• हुनकर ब्राउजिंगक आधार पर पुनर्लक्ष्य संदेश पठाएब
• बच्चा प्रयोक्ताक डेटासँ सदृश दर्शक बनाएब
• बच्चा प्रयोक्ताक व्यवहार लिखय बला हीटमैप प्रयोग करब

कार्यान्वयन: 18 सँ कम चिन्हल प्रयोक्ता लेल एनालिटिक्स SDK, विपणन पिक्सेल आ वैयक्तिकीकरण इंजन कठोरतासँ निष्क्रिय करू। सभ विपणन सिस्टममे बच्चा-खंड बहिष्करण जोड़ू। ई एकटा उल्लेखनीय अभियांत्रिकी परियोजना थिक — आबहि शुरू करू।

उम्र-संक्रमणक समस्या

जखन कोनो प्रयोक्ता 18 क होइत अछि, सहमति अभिभावक-मध्यस्थसँ सोझ भऽ जाइत अछि। अहाँक डेटा मॉडलकेँ एकर समर्थन करबाक चाही। परिपक्व कार्यान्वयन:

• प्रयोक्ताक उम्र ट्रैक करू आ 18 पर पुनः-सहमति सक्रिय करू
• प्रयोक्ताकेँ (आब वयस्क) अपन बचपनक डेटा राखबाक वा हटेबाक विकल्प दिअ
• व्यवहार-लक्ष्यीकरण प्रतिबंध हटाउ
• संक्रमणक विषयमे अभिभावककेँ सूचित करू (जँ ओ खाता सम्हारि रहल छल)

भारतमे गिनल-चुनल EdTech प्लेटफॉर्म ई बनौने अछि। इएह अगिला सीमा थिक।

दायराक समस्या

बेसी संस्था विक्रेता दायराकेँ 3-5 गुना कम आँकैत अछि। क्रय विभाग राखल 'आधिकारिक' विक्रेता सूची सम्भवतः वास्तविक प्रोसेसरक एक-तिहाई समेटैत अछि। बाकी ओ औजार थिक जे अलग-अलग टीम जोड़लक, क्रय विभाग बिना कीनल बिन्दु एकीकरण, विभाग प्रयोग कएल SaaS क नि:शुल्क स्तर, ठेकेदार आनल उप-विक्रेता।

एकटा सामान्य मध्यम आकारक B2C कम्पनीमे सम्पूर्ण सूची बनौला पर 80-150 प्रोसेसर रहैत अछि। सामान्य B2B SaaS कम्पनीमे 30-80। दुनू अभ्यासक शुरुआतमे अपन 'आधिकारिक' सूचीमे 20-30 गनत।

क्रम

अहाँ सभ किछु एकहि संग ठीक नहि कऽ सकैत छी। 12-मासक कार्यक्रम लेल सही क्रम:

मास 1-2: खोज

प्रत्येक टीमक सर्वेक्षण करू। नेटवर्क एग्रेस, OAuth एप, SaaS सदस्यताक खर्च प्रतिवेदन, भुगतान-एग्रीगेटर लेनदेन सूचीक लेखापरीक्षा करू। परिणाम: एकटा सम्पूर्ण विक्रेता सूची।

मास 2-4: वर्गीकरण

विक्रेताकेँ जोखिम (डेटा संवेदनशीलता × परिमाण × निर्णायकता) अनुसार वर्गीकृत करू। शीर्ष स्तर: सभसँ पैघ, सभसँ संवेदनशील डेटा सेट राखय बला 10-20 विक्रेता। हिनका गहीर DPA, सम्पूर्ण सुरक्षा समीक्षा, आ महत्वपूर्ण रहला पर स्थलगत लेखापरीक्षा।

मास 3-9: शीर्ष-स्तरक उपचार

शीर्ष-स्तरक विक्रेता संग DPA अद्यतन करू। प्रत्येक लेल Vendor DDQ (Template 08)। उप-प्रोसेसर प्रवाह, उल्लंघन दायित्व, क्षतिपूर्ति लिखू। प्रति शीर्ष-स्तर विक्रेता औसत चक्र समय: 4-8 सप्ताहक कानूनी-आ-क्रय आदान-प्रदान।

मास 6-12: मध्य-स्तर

मध्य-स्तरक विक्रेताकेँ मानक DPA अनुसूची। हल्का DDQ। एक बेरमे 5-10 क समूहमे पूरा।

मास 9-12: नमहर पूँछ

निचला-स्तरक विक्रेता लेल (कम डेटा संवेदनशीलता, कम परिमाण) सरल तरीका: एक-पन्नाक DPDP प्रमाणन, क्लिकरैप DPA, वा अहाँक मानक शर्तक संदर्भ दैत अनुबंध धारा। जे वास्तवमे कम-जोखिमक अछि, ताहि पर कानूनी चक्र समय घटाउ।

Master DPA

हमर पुस्तकालयमे Template 07 एकटा 14-धाराक Master DPA थिक जे Section 8(2) सँ मिलैत अछि। ई उद्देश्य सीमा, सुरक्षा, उल्लंघन अधिसूचना, उप-प्रोसेसर, लेखापरीक्षा अधिकार, समाप्ति पर वापसी / नाश, आ सहायक तालिका समेटैत अछि। शीर्ष-स्तरक उपचार लेल एकरा अपन आधार बनाउ।

प्रोसेसर सूची दस्तावेज

एकहि प्रोसेसर सूची राखू: विक्रेताक नाम, व्यक्तिगत डेटाक श्रेणी, उद्देश्य, अहाँकेँ ज्ञात उप-प्रोसेसर, DPA स्थिति (हस्ताक्षरित / लंबित / अवधि समाप्त), DDQ अंक, अंतिम-समीक्षा तिथि। प्रोसेसर संलग्न कोनो उल्लंघनक जाँच करैत काल नियामक सभसँ पहिने इएह दस्तावेज माँगत।

'DPA नहि, गो-लाइव नहि' नीति

नव विक्रेता जोड़बा लेल सरलतम नियंत्रण: DPA नहि, उत्पादन पहुँच नहि। क्रय गेटकेँ कार्यान्वयन बिन्दु बनाउ। अहाँ उपचार कऽ सकय बला गतिसँ तेज सूची बढ़बासँ ई रोकैत अछि।

मापदंड

Act क Section 10(1) केन्द्र सरकारकेँ एहि आधार पर Significant Data Fiduciaries नामित करबाक अनुमति दैत अछि:

• प्रसंस्कृत व्यक्तिगत डेटाक परिमाण आ संवेदनशीलता
• Data Principals क अधिकारकेँ जोखिम
• भारतक सार्वभौमत्व आ अखंडता पर सम्भावित प्रभाव
• चुनावी लोकतंत्रकेँ जोखिम
• राज्यक सुरक्षा
• सार्वजनिक व्यवस्था

व्यवहारमे एकर अर्थ

मापदंड जानि-बूझिकऽ खुजल राखल अछि। सरकार आइ धरि (2025 क अंत धरि) औपचारिक सीमा अधिसूचना जारी नहि कएने अछि, मुदा मापदंड संकेत करैत अछि जे संस्थाक अनेक श्रेणी अत्यंत सम्भावित उम्मीदवार अछि:

• पैघ BFSI संस्था (परिमाण + संवेदनशीलता + क्षेत्रीय)
• स्वास्थ्य सेवा आ HealthTech (संवेदनशीलता + अधिकारकेँ जोखिम)
• दूरसंचार (परिमाण + सार्वभौमत्व)
• प्रमुख सामाजिक प्लेटफॉर्म (परिमाण + चुनावी लोकतंत्र)
• प्रमुख ई-कॉमर्स / D2C प्लेटफॉर्म (परिमाण)
• प्रमुख fintech (परिमाण + संवेदनशीलता + क्षेत्रीय)
• Aadhaar-जुड़ल सेवा प्रदाता (संवेदनशीलता + सार्वभौमत्व)

पहिनेसँ तैयारी किएक?

एक बेर नामित भेला पर, Section 10 क बाध्यता सीमित संक्रमण संग लागू होइत अछि। Rule 13 तय करैत अछि:

• 'Data Principals क अधिकारकेँ उच्च जोखिम' बला प्रसंस्करणसँ पहिने DPIA
• पैनलमे रहल लेखापरीक्षक द्वारा वार्षिक स्वतंत्र लेखापरीक्षा
• भारत-निवासी Data Protection Officer
• DPO केँ Board (वा समकक्ष शासकीय निकाय) केँ प्रतिवेदन देबय पड़त
• समय-समय पर जोखिम मूल्यांकन

एकरा शून्यसँ बनेबामे — विशेष रूपसँ लेखापरीक्षा चक्र आ बोर्ड-रिपोर्टिंग बला DPO काज — 6-12 मास लगैत अछि। जँ अहाँकेँ (मानि लिअ) Q3 2027 मे 6-मासक संक्रमण संग अधिसूचित कएल जाइत अछि, आ अहाँ तैयारी नहि कएने छी, तँ समयसीमा छुटि जाएत।

पूर्व-तैयारी जाँच-सूची

1. मापदंडक विरुद्ध स्व-मूल्यांकन करू (एहि विषयमे हम मार्गदर्शन प्रकाशित कएने छी — हमर Tools खंडमे SDF Classifier देखू)
2. जँ सम्भावित SDF: बोर्ड रिपोर्टिंग रेखा सहित भारत-निवासी DPO नियुक्त करू। भूमिका विवरण लेल Template 13 प्रयोग करू।
3. DPIA कार्यक्रम ठाढ़ करू। सभसँ उच्च-जोखिमक प्रसंस्करण गतिविधि पर अपन पहिल DPIA चलाउ। Template 12 प्रयोग करू।
4. एकटा लेखापरीक्षा फर्म चिन्हू आ पहिनेसँ सम्पर्क करू (जे सरकार पैनल प्रकाशित कएला पर ताहिमे रहत)
5. DPDP जोखिम पर त्रैमासिक बोर्ड रिपोर्टिंग स्थापित करू। बोर्ड पैक स्वरूप लेल Template 16 प्रयोग करू।
6. सभ किछु लिखू। लेखापरीक्षा आएत तँ देखत जे बाध्यता वास्तवमे कार्यान्वित भेल छल की नहि — खाली घोषित भेल छल की नहि, से नहि।

जँ अहाँ निश्चित रूपसँ SDF नहि छी

गैर-SDF सेहो उच्च-जोखिमक प्रसंस्करण पर DPIA चलेबासँ, नियुक्त DPO राखबासँ, आ Board केँ प्रतिवेदन देबासँ लाभ पबैत अछि। अनुशासन मूल्यवान; खाली कानूनी बाध्यता भिन्न।

वर्तमान व्यवस्था

DPDP Act क Section 16 — अंतर्राष्ट्रीय मानक अनुसार — उदार अछि। ई कहैत अछि जे केन्द्र सरकार अधिसूचना द्वारा विशिष्ट देश वा क्षेत्र लेल भारतक बाहर व्यक्तिगत डेटा हस्तांतरण सीमित कऽ सकैत अछि। डिफॉल्ट स्थिति: हस्तांतरणक अनुमति अछि। प्रतिबंध लेल विशिष्ट अधिसूचना चाही।

व्यापक सीमा-पार प्रतिबंध बला 2019 क PDP Bill सँ ई उल्लेखनीय रूपसँ भिन्न अछि। लागू भेल स्वरूपमे Act प्रतिबंधकेँ अपवाद बनबैत अछि।

भावी व्यवस्था

अनेक कारक भावी प्रतिबंधक दिशामे संकेत करैत अछि:

• पारस्परिकता विचार — प्रतिबंधात्मक व्यवस्था बला देश (चीन) भारतीय प्रतिबंध आकर्षित कऽ सकैत अछि
• सार्वभौम-हित डेटा श्रेणी (रक्षा, महत्वपूर्ण आधारभूत संरचना)
• Rule 13(4) अन्तर्गत SDF-विशिष्ट बाध्यता — SDFs क किछु व्यक्तिगत डेटा भारतमे रहय, से सरकार माँगि सकैत अछि

किछु श्रेणीक डेटा, किछु वर्गक fiduciary लेल, भविष्यमे कोनो तिथिकेँ स्थानीयकरण वा हस्तांतरण प्रतिबंधक अन्तर्गत आएत, ई अनुमान पर संस्था योजना बनाबय।

मैपिंग अभ्यास

वर्तमान व्यवस्था जे किछु होअय, अहाँकेँ अपन सीमा-पार व्यक्तिगत डेटा प्रवाहक सम्पूर्ण नक्शा चाही। नक्शामे लिखल जएबाक चाही:

• स्रोत सिस्टम (कोन एप्लिकेशन, कोन देशमे, डेटा उत्पन्न करैत अछि)
• गंतव्य सिस्टम (कोन एप्लिकेशन, कोन देशमे, डेटा प्राप्त करैत अछि)
• हस्तांतरित व्यक्तिगत डेटाक श्रेणी
• हस्तांतरणक उद्देश्य
• स्रोत पर Data Fiduciary, गंतव्य पर Processor / Data Fiduciary
• हस्तांतरणक कानूनी आधार (सहमति, अनुबंध, कानूनी बाध्यता)
• परिमाण (प्रति त्रैमास अभिलेख)

शीघ्र लाभ

मैपिंग करैत काल स्पष्ट जोखिम सम्हारू:

• भारतीय क्षेत्र उपलब्ध रहितो भारतीय ग्राहक डेटा गैर-भारतीय क्षेत्रमे राखय बला SaaS औजार — भारतीय क्षेत्र पर बदलू
• भारतीय प्रयोक्ताक व्यवहार डेटा वैश्विक इंस्टेंसमे एकत्र करय बला विश्लेषण प्लेटफॉर्म — क्षेत्र प्रतिबंध देखू वा हस्तांतरणसँ पहिने अनाम करू
• भारतक बाहर बैकअप गंतव्य — मूल्यांकन कऽ लिखू

प्रोसेसर प्रश्न

बहुत सीमा-पार 'हस्तांतरण' वास्तवमे प्रोसेसर-सँ-प्रोसेसर होइत अछि। Data Fiduciary भारतेमे रहैत अछि; Processor (जेना, कोनो क्लाउड प्रदाताक US-आधारित विश्लेषण सेवा) बाहर प्रसंस्करण करैत अछि। एहि पर सेहो Section 16 लागू होइत अछि। अहाँक DPA केँ ई सम्हारय पड़त।

संस्था

Data Protection Board of India (DPBI) ओ नियामक थिक जे DPDP Act क Sections 18-26 अन्तर्गत स्थापित अछि। 2025 क अंत धरि ई औपचारिक रूपसँ गठित अछि मुदा आइयो सम्पूर्ण परिचालनमे नहि। सम्पूर्ण परिचालनमे अएला पर, ई सम्पूर्ण ढाँचाक केन्द्रीय कार्यान्वयन मंच बनि जाइत अछि।

संरचना

Board मे एक Chairperson आ आन Members रहैत अछि। तकनीकी आ कानूनी विशेषज्ञता पर सरकारक जोर संकेत करैत अछि जे सदस्यमे वरिष्ठ न्यायाधीश, नियामक आ प्रौद्योगिकीविद् रहत। कार्यकाल दू वर्ष, नवीकरणीय।

अधिकार

Board क पास व्यापक अधिकार अछि:

• उल्लंघन आ आन अतिक्रमणक जाँच
• तत्काल उपचारात्मक उपायक निर्देश
• Schedule क सीमा धरि दंड लगाएब (सुरक्षा विफलता लेल अधिकतम ₹250 करोड़)
• Data Fiduciaries केँ निर्देश जारी करब
• डिजिटल कार्यालयक रूपमे कार्यवाही चलाएब (महत्वपूर्ण — ई ऑनलाइन चलेबाक लेल बनाओल गेल)

प्रक्रियात्मक नमूना

Board क उद्देश्य डिजिटल-प्रथम नियामक होएब। दाखिला, सुनवाई, प्रमाण प्रस्तुति — सभ ऑनलाइन चलाओल जाइत अछि। ई पहुँच आ गति लेल जानि-बूझिकऽ कएल चयन; एकर अर्थ ई सेहो जे अहाँक प्रमाण-सम्हार प्रक्रियाकेँ पहिल दिनसँ डिजिटल उत्पादनक समर्थन करबाक अछि।

दंड खाली दीवानी। DPDP Act फौजदारी अपराध नहि बनबैत अछि (IT Act सँ उल्लेखनीय प्रस्थान)। सभ कार्यवाहीक परिणाम निर्देश आ / वा आर्थिक दंड होइत अछि।

अपील बाट

DPBI सँ अपील आदेशक 60 दिनक भीतर Telecom Disputes Settlement and Appellate Tribunal (TDSAT) मे जाइत अछि। TDSAT सँ अगिला अपील कानूनक प्रश्न पर सर्वोच्च न्यायालयमे।

ई बाट — DPBI → TDSAT → SC — सामान्य भारतीय नियामक सीढ़ीसँ (नियामक → उच्च न्यायालय → SC) तेज अछि। न्यायशास्त्रक भंडार शीघ्र विकसित हेबाक अवसर देब एकर उद्देश्य।

की तैयार करी

• DPBI जाँच लेल एकहि सम्पर्क बिन्दु नियुक्त करू — सामान्यतः DPO वा Grievance Officer
• विवादित कोनो प्रसंस्करण लेल अपन निर्णय प्रक्रिया लिखू — मूल निर्णयसँ लेखापरीक्षा पथ बेसी महत्वपूर्ण
• सहमति संग्रह, सुरक्षा कार्यान्वयन, उल्लंघन जवाब लेल प्रमाण शृंखला राखू। Board कागजी अभिलेखसँ काज करत।
• समयक दबावमे Board-तैयार अधिसूचना दस्तावेज उत्पन्न करैत अछि, से सुनिश्चित करबा लेल अपन घटना-जवाब प्रक्रिया परीक्षण करू

प्रारम्भिक कार्यान्वयन प्राथमिकता

अनुमानित, मुदा सरकारी वक्तव्य आ विश्वभरक समान नियामकसँ सूचित:

• अधिसूचना अनुपालन (करबाक छल जखन, की अहाँ वास्तवमे प्रतिवेदन कएल?)
• बच्चाक डेटा (Section 9) — उच्च राजनीतिक महत्व
• विक्रेता आ प्रोसेसर प्रवाह (Section 8(2)) — उच्च-प्रभावक बिन्दु
• वर्गीकृत भेलाक बाद SDFs लेल सीमा-पार हस्तांतरण अनुपालन

संरचना

DPDP Act क Schedule of Penalties दीवानी दंड पर सीमा लगबैत अछि। Act मे कोनो फौजदारी अपराध नहि — IT Act सँ जानि-बूझिकऽ कएल प्रस्थान। सीमा:

• ₹250 करोड़ — उचित सुरक्षा सुरक्षण नहि लेबाक विफलता (Section 8(5))
• ₹200 करोड़ — Board / Data Principal केँ उल्लंघन सूचना नहि देबाक विफलता (Section 8(6))
• ₹200 करोड़ — बच्चाक-डेटा बाध्यता पूरा नहि करबाक विफलता (Section 9)
• ₹150 करोड़ — Significant Data Fiduciary क अतिरिक्त बाध्यताक विफलता (Section 10)
• ₹50 करोड़ — आन कोनो कर्तव्यक विफलता
• ₹10,000 — कोनो Data Principal कर्तव्यक विफलता (Section 15) प्रति घटना

Board एकरा कोना लागू करैत अछि

दंडक परिमाण तय करैत काल Board जाहि विषयकेँ ध्यानमे रखैत अछि, Section 33 ओकरा सूचीबद्ध करैत अछि:

• अतिक्रमणक स्वरूप, गम्भीरता, अवधि
• प्रभावित व्यक्तिगत डेटाक प्रकार आ स्वरूप
• पुनरावृत्ति स्वरूप
• की अनुचित लाभ भेल
• की स्वैच्छिक उपचार भेल
• अतिक्रमणकर्ता पर असमान प्रभाव
• जनता पर प्रभाव

सीमा अधिकतम छत थिक, फर्श नहि। छोट, कम-गम्भीर अतिक्रमण छोट दंड आकर्षित करैत अछि।

संयोजनक प्रश्न

एकहि घटनासँ उत्पन्न अनेक अतिक्रमण अनेक दंड आकर्षित कऽ सकैत अछि। बच्चाक डेटा संलग्न उल्लंघन, विलम्बित अधिसूचना संग, कोनो SDF द्वारा प्रसंस्कृत, सुरक्षा अपर्याप्तता संग — सिद्धांततः Sections 8(5), 8(6), 9 आ 10 अन्तर्गत एकहि संग दंड आकर्षित कऽ सकैत अछि। अधिकतम सैद्धांतिक जोखिम: ₹800 करोड़।

जोखिम कोना सीमित करी

सभसँ सोझे अहाँक नियंत्रणमे कारक:

1. उचित उपाय: Section 8(5) सुरक्षाक विफलताकेँ दंडित करैत अछि। लिखल, प्रमाण सहित सुरक्षा कार्यक्रम देखाएब (Rule 6 नियंत्रण कार्यान्वित, लेखापरीक्षित, समीक्षित) उल्लंघन भेला परो जोखिम सीमित करैत अछि।
2. अधिसूचना अनुशासन: Section 8(6) अधिसूचना नहि देबाकेँ दंडित करैत अछि। पहिनेसँ बनल प्लेबुक, पहिनेसँ मसौदा कएल टेम्पलेट, नियुक्त निर्णयकर्ता — सभ विलम्बित वा नहि देल अधिसूचनाक जोखिम घटबैत अछि।
3. स्वैच्छिक उपचार: स्व-खुलासा कएल अतिक्रमण, लिखल उपचार संग, घटल दंड आकर्षित करैत अछि।
4. बच्चाक-डेटा कार्यक्रम: Section 9 सभसँ उच्च सीमामेसँ एक रखैत अछि। सभसँ बेसी प्रभावक एकल निवेश थिक सत्यापन-योग्य अभिभावकक सहमति प्रवाह आ विपणन-सिस्टममे बच्चा-बहिष्करण।
5. विक्रेता प्रवाह: Section 8(2) प्रोसेसरक विफलता लेल अहाँकेँ उत्तरदायी बनबैत अछि। मजबूत DPA आ विक्रेता-DDQ कार्यक्रम एकरा सीमित करैत अछि।

बोर्ड-पैक दृष्टिकोण

बोर्ड-स्तरक प्रतिवेदन लेल दंड जोखिम एहि रूपमे प्रस्तुत करू: अधिकतम सैद्धांतिक जोखिम (सम्बन्धित सीमाक योग) versus वर्तमान नियंत्रणक बाद अहाँक अवशिष्ट जोखिम। स्वरूप लेल Template 16 प्रयोग करू। त्रैमासमे अवशिष्ट जोखिमक प्रवृत्ति सभसँ उपयोगी एकल मापक थिक।

Phase 1 — आब

Phase 1 वर्तमान स्थिति थिक। Act लागू अछि। Rules अधिसूचित (13 नवम्बर 2025, G.S.R. 846(E))। DPBI गठित। मूल ढाँचा — कर्तव्य, कानूनी आधार, सुरक्षा, उल्लंघन अधिसूचना, अधिकार — तकनीकी रूपसँ लागू।

जे पहिनेसँ परिचालनमे रहबाक चाही:

• DPDP-अनुपालक Privacy Notice
• Section 6 + Rule 3 सँ मिलैत सहमति संग्रह
• Rule 6 सँ मिलैत सुरक्षा आधाररेखा
• Rule 7 अनुसार उल्लंघन जवाब क्षमता
• 90-दिनक SLA ट्रैकिंग सहित DSAR पूर्ति वर्कफ्लो
• प्रकाशित grievance officer
• Section 8(2) सँ मिलैत विक्रेता DPAs

जँ अहाँक कार्यक्रम एतय नहि अछि, तँ अहाँ पाछू छी।

Phase 2 — ~नवम्बर 2026

Phase 2 Consent Manager परिवेशकेँ सक्रिय करैत अछि। Consent Managers ओ मध्यस्थ थिक जे Data Principals क ओरसँ सहमति एकत्र, प्रबंधित आ रद्द करैत अछि। ढाँचा DPDP Rules क Rule 4 मे अछि।

ई हिनका लेल महत्वपूर्ण:

• जे व्यवसाय Consent Managers क रूपमे काज करय चाहैत अछि — DPBI मे निबंधन, तकनीकी आ परिचालन मानक
• जे व्यवसाय Consent Managers सँ जुड़त — API, सहमति-अभिलेख स्वरूप, वापसी सम्हार
• Account Aggregator-सम्बन्धित व्यवसाय — AA ढाँचाकेँ DPDP समन्वयक आवश्यकता हएत

Phase 3 — 13 मई 2027

Phase 3 मूल बाध्यताक स्फटिकीकरणक तिथि थिक। Rules क अधिसूचनासँ दू वर्ष। एहि तिथि धरि:

• Significant Data Fiduciaries अधिसूचित (वा अधिसूचना लगीच)
• SDFs लेल सम्पूर्ण Section 10 + Rule 13 बाध्यता लागू
• दंड कार्यान्वयन स्थिर अवस्थामे पहुँचैत अछि
• शिकायत-आ-अपील तंत्र पैघ पैमाना पर परिचालनमे
• SDFs लेल वार्षिक लेखापरीक्षा चक्र चलि रहल अछि

बनेबामे 12-18 मास लगय बला मूल कार्यक्रम (RoPA, DPIA चक्र, 50+ प्रोसेसरमे विक्रेता उपचार, स्वचालित DSAR पोर्टल, एन्क्रिप्शन सुधार) Phase 3 धरि उत्पादन-तैयार हेबा लेल 2026 क मध्य धरि चलैत रहबाक चाही।

जाल

सभसँ सामान्य रणनीतिक भूल: 13 मई 2027 केँ शुरुआत तिथि मानिकऽ ओहि अनुसार गति राखब। ओ समयसीमा थिक। समयसीमा लेल तय गतिक कार्यक्रम समयसीमा 6-12 मास सँ छुटैत अछि।

Q4 2026 मे पूर्णता लेल गति राखू। Q1-Q2 2027 परीक्षण, लेखापरीक्षा, बोर्ड स्वीकृति आ निरंतर सुधार लेल प्रयोग करू। समयसीमा पर शिप नहि करू।

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

The DPDP Act is not an Indian copy of GDPR. It shares the vocabulary of notice, consent, rights and breach reporting, but it drops legitimate interests, sensitive data categories and the one-month DSAR clock, and it replaces turnover-based fines with fixed rupee caps of up to Rs 250 crore. An Indian mid-market firm with a GDPR programme for EU customers can reuse roughly a third of its artefacts as they stand, must rewrite a third, and needs to build the rest. This page sets out the 15 differences in one table, then sorts your GDPR artefacts into reuse, rewrite and build-new lists.

Is DPDP same as GDPR? Why the short answer is no

Many Indian firms serving EU customers assume that “GDPR compliant” means “DPDP covered”. In our reading that is the most expensive assumption a compliance lead can make this year.

The two laws share a lineage: a controller-style entity (controller, data fiduciary), a processor, an individual (data subject, data principal) and a regulator. Both require notice, access and correction rights, security safeguards and breach reporting.

The similarity stops at the architecture. GDPR is a broad, principle-driven regulation with six lawful bases and a large body of guidance. The DPDP Act is narrower and more prescriptive: it applies only to digital personal data, it recognises consent plus a closed list of “legitimate uses” under Section 7, and it leaves detail to the DPDP Rules, 2025 (notified November 2025) and future notifications. If you are new to the Indian framework, start with our DPDP 101 explainer.

Timing matters. Most substantive DPDP obligations become enforceable in May 2027, 18 months after the Rules were notified, with consent manager provisions at 12 months. That is the window for closing the gap.

DPDP Act vs GDPR differences: the 15-row comparison

The table below is the core of this page. Use the reuse, rewrite and build-new lists that follow to plan the work.

Row 11 is covered in our cross-border transfer guide. Two other rows deserve attention. Row 5 is where most GDPR programmes depend structurally on a mechanism DPDP does not offer. Row 9 is where an EU-tuned runbook will make you late, because DPDP requires you to tell affected individuals without delay rather than after a risk threshold is crossed. Our 72-hour breach response article walks through the Indian sequence, including how the CERT-In six-hour direction sits alongside it.

GDPR compliant company, DPDP India obligations: what changes in practice

Consider a Bengaluru SaaS company with 300 staff, EU enterprise customers and a GDPR programme built in 2019.

Lawful basis remapping

Its ROPA lists 42 activities: nineteen on “contract”, eleven on “legitimate interests”, nine on consent, three on legal obligation. Some contract entries fit “voluntary provision” under Section 7, but the marketing and analytics entries fit no Section 7 head and need consent under Section 6. That consent must be free, specific, informed, unconditional and unambiguous, with withdrawal as easy as giving it, which rules out bundled consents copied from a cookie banner. Our Section 7 lawful basis explainer shows the mapping activity by activity.

Children’s data

The company runs a student edition used by some 17-year-olds, with a GDPR age gate at 16. Under Section 9 it needs verifiable parental consent for anyone under 18 and must switch off tracking and targeted advertising for that cohort. Penalty exposure for getting this wrong is up to Rs 200 crore.

Breach response

The GDPR runbook has a gate: assess risk, notify the authority within 72 hours, notify individuals only if the risk is high. The DPDP runbook has no gate for individuals. Intimation to affected data principals and to the Board goes out without delay, and a detailed report reaches the Board within 72 hours. In parallel, listed cyber incidents go to CERT-In within six hours.

Significant Data Fiduciary exposure

If notified as an SDF, the company must appoint an India-based DPO, engage an independent data auditor and run periodic DPIAs. Its EU-based DPO does not satisfy the residency requirement. Use the SDF Classifier tool to test whether your profile is likely to fall into scope.

DPDP GDPR mapping: artefacts you can reuse as-is

These carry across with little more than updated legal references.

Data inventory and data flow maps. What you hold, where it flows and who touches it does not change with the law. Add a digital-or-paper column, since only digital personal data is in DPDP scope.

Information security policies and controls. Encryption, access control, logging and monitoring, and backups are the DPDP Rules’ reasonable security safeguards almost verbatim. Confirm log retention meets the one-year DPDP floor and the CERT-In 180-day in-India requirement.

Vendor due diligence questionnaires. Add one question: can the vendor support “without delay” breach intimation?

Training on privacy fundamentals and governance structure. Purpose limitation, minimisation and need-to-know apply equally; only legal references and penalty slides change. Steering committees and escalation paths continue unchanged. See our DPDP training options for India-specific modules.

DPDP GDPR mapping: artefacts you must rewrite

These share a purpose with their DPDP equivalent but their content would fail an Indian audit.

Privacy notices and consent flows. Section 5 requires notice of the data processed, the purpose, how to exercise rights and how to complain to the Board. GDPR notices are longer, mention legitimate interests and cite EU authorities. A Section 5 notice should be shorter, purpose-specific and issued with or before the consent request. Consent flows need withdrawal as easy as consent and purpose-specific ties; rebuild rather than patch.

Records of processing. Keep the structure; rewrite the lawful basis column to Section 6 or 7 heads, add the retention trigger (erasure when purpose is served or consent withdrawn) and flag children’s data.

Processor agreements. An Article 28 DPA is a good skeleton. Add breach intimation aligned to “without delay”, cooperation with the Board, and a statement that the fiduciary remains responsible regardless of the processor. Our vendor remediation guide lists the clauses most often missing.

Breach runbook. Rebuild around three clocks: CERT-In six hours, DPDP “without delay” intimation, and the 72-hour detailed report to the Board. Remove the risk gate for individual notification.

DSAR procedure. Publish your response period (up to 90 days), add nomination requests, drop portability for India-only data, and route grievances to a named Section 8 contact before they reach the Board. The DSAR workflow article provides a template process.

Penalty and risk register. Replace turnover-percentage exposure with the fixed Schedule caps; the Penalty Exposure Estimator gives a rupee figure for board reporting.

DPDP GDPR mapping: artefacts you must build new

These have no GDPR counterpart, or one so different that starting fresh is faster.

Verifiable parental consent mechanism. Section 9 needs a verification method, a consent record, and a technical flag that switches off tracking and targeted advertising for under-18 users.

Section 7 legitimate use register. For each activity not based on consent, which Section 7 head applies and why. This replaces the LIA library and, in our reading, is the document the Board will ask for first.

SDF readiness pack. If classification is plausible, prepare the India-based DPO appointment, data audit scope and DPIA calendar now.

Retention and inactivity erasure logic. Specified large fiduciaries (e-commerce with 2 crore or more users, online gaming 50 lakh or more, social media 2 crore or more) must erase after three years of inactivity with 48 hours prior notice. Even outside those classes, Section 8 requires erasure once the purpose is served, and most GDPR retention schedules have no automated trigger.

Board-facing grievance log. The Data Protection Board is a new regulator. Keep a log of grievances, response times and escalations that can be produced on request.

Rather than drafting from a blank page, the 16 DPDP Starter Templates include notices, a breach runbook and vendor agreements aligned to the Act and Rules.

Frequently Asked Questions

If we are GDPR compliant, are we automatically DPDP compliant?

No. GDPR compliance gives you a strong foundation in security controls, data inventories and governance, but DPDP removes legitimate interests, sets the children’s threshold at 18, changes breach notification recipients and timing, and uses fixed rupee penalties. In our experience roughly a third of GDPR artefacts can be reused as-is, a third need rewriting and a third must be built new.

Can we keep using legitimate interests for marketing and analytics in India?

Not for data in DPDP scope. Section 7 provides a closed list of legitimate uses with no balancing test, and marketing or product analytics does not fall within it. Those activities will generally need consent under Section 6, with withdrawal as easy as giving consent.

Does our EU-based DPO satisfy the DPDP Act?

Only if you are not a Significant Data Fiduciary. SDFs must appoint a DPO based in India under Section 10 and must also engage an independent data auditor and conduct periodic DPIAs. Non-SDFs are not required to appoint a DPO but must publish a contact for grievances.

How do the breach notification rules differ between GDPR and DPDP?

GDPR requires notification to the supervisory authority within 72 hours and to individuals only where there is a high risk. DPDP requires intimation to the Board and to every affected data principal without delay, followed by a detailed report to the Board within 72 hours, with no risk threshold for informing individuals. CERT-In’s six-hour reporting direction applies in parallel for listed cyber incidents.

Do we need Standard Contractual Clauses for transfers out of India?

No. Section 16 permits cross-border transfers except to countries restricted by Central Government notification, and there is no SCC or adequacy mechanism. Sector regulators such as the RBI may still impose localisation on specific data sets, so check sectoral rules before assuming a transfer is free.

Related explainers

• DPDP vs GDPR: key differences

• Significant Data Fiduciary (SDF) explained

• Data Fiduciary vs Data Processor under the DPDP Act

Next step

If your GDPR programme is mature and you want a defensible DPDP position before May 2027, the fastest route is a GDPR-to-DPDP gap assessment that sorts every artefact into reuse, rewrite or build new and hands you a sequenced plan. That is what the Readiness Sprint delivers.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

A virtual DPO (vDPO) is an outsourced, named data protection officer who carries the DPDP Act’s accountability role for your organisation on a monthly retainer instead of a full-time salary. Under Section 10, only Significant Data Fiduciaries must appoint a DPO based in India who reports to the board, but every fiduciary must publish a contact person for grievances under Section 8, and most substantive obligations become enforceable in May 2027. This page covers what a vDPO does each month, in-house versus virtual, indicative INR fee bands, a 30-day onboarding plan and when a vDPO alone is not enough.

What does a virtual DPO India engagement actually cover?

A virtual DPO is not a helpline or a document library. It is a named individual, backed by a small team, who carries the DPO role under the DPDP Act and can be put in front of your board, your customers and, if needed, the Data Protection Board of India.

Section 10 requires a Significant Data Fiduciary (SDF) to appoint a DPO based in India who represents the fiduciary, is responsible to the board and acts as the point of contact for grievance redressal. Section 8 requires every fiduciary, SDF or not, to publish the contact details of a DPO or of a person able to answer data principals’ questions. In practice, a non-SDF still needs someone competent whose name sits on its privacy notice and who responds within the published grievance period, which the Rules cap at 90 days.

A vDPO fills both roles: statutory officer for an SDF, published contact person and programme owner for everyone else. If you are unsure which category you fall into, our SDF classification explainer and the SDF Classifier on our tools page walk through the factors the Central Government is expected to weigh.

What the vDPO does month by month

The value of a retainer is rhythm. A typical cycle looks like this:

Breach response is the item most clients underestimate; our 72-hour breach response article explains the sequence.

DPO as a service India: how it compares with an in-house hire

Should we hire, or should we retain? The comparison reflects what we see in practice across Indian mid-market companies.

Two cautions. First, a vDPO must genuinely meet Section 10: based in India, empowered to represent the fiduciary and reporting to the board. A foreign firm’s remote advisor does not meet that test for an SDF. Second, the DPO role does not dilute the fiduciary’s liability. Schedule penalties, up to Rs 250 crore for failing security safeguards and up to Rs 150 crore for SDF obligations, attach to the company, not the officer.

Outsourced data protection officer: what is in scope and what is not

Retainer scope is where most disappointments originate, so we set it out explicitly.

In scope. Acting as the named DPO or contact person. Owning the records of processing, consent register and vendor register. Signing off Section 5 notices and Section 6 consent flows, including withdrawal that is as easy as giving consent. Advising on Section 7 legitimate uses, particularly employment purposes. Handling rights requests and grievances. Running the DPIA cycle and liaising with the independent data auditor for SDFs. Quarterly board reporting. Breach response leadership. Monitoring Board guidance and translating it into actions.

Out of scope, unless separately agreed. Drafting the full initial document set from a blank page (that is a Readiness Sprint). Implementing security controls; the vDPO specifies, IT or a vCISO delivers. Adversarial representation before the Board beyond the statutory point-of-contact role. Complex Section 16 cross-border structuring for groups. Engineering work on consent platforms, though the vDPO reviews the design.

Where the gap assessment is long, run a fixed-scope sprint first, then the retainer to hold the position. Companies starting from little often shortcut drafting with our DPDP Starter Templates: privacy notices, a breach runbook and processor agreements the vDPO then tailors.

DPDP DPO requirement: who must appoint one and who must publish a contact

Tier one: Significant Data Fiduciaries

Section 10 lets the Central Government notify any fiduciary or class of fiduciaries as an SDF. An SDF must appoint an India-based DPO responsible to the board and acting as grievance contact, appoint an independent data auditor, and carry out periodic DPIAs. Failure on SDF obligations carries a penalty of up to Rs 150 crore.

Tier two: every other data fiduciary

Section 8 applies to all fiduciaries: publish the contact of a DPO if appointed, or otherwise of a person able to answer data principals’ questions, and run an effective grievance mechanism. The person you publish must be reachable, competent and backed by a process.

Timing

Under the phased commencement, DPO and SDF obligations become enforceable 18 months after notification, in May 2027. In our reading, waiting until the last quarter is a mistake: SDF notifications may arrive with short lead times, and a DPO appointed a month before enforcement has no record of oversight to point to. The enforcement phases explainer sets out the timeline, and the Act and Rules Explorer lets you read Sections 8 and 10 alongside the Rules.

DPO cost India: indicative fee bands

All figures are indicative, expressed as ranges, and exclude GST. They reflect the Indian market for a retainer with a named lead holding recognised privacy and audit credentials. Cheaper offerings are usually a document subscription with a shared helpdesk, which does not satisfy Section 10 for an SDF.

One-time onboarding is usually charged separately, indicatively Rs 1,50,000 to Rs 6,00,000 depending on documentation maturity, and covers the 30-day plan below. Breach response beyond an agreed annual allowance is billed at time and materials. A vDPO bundled with a vCISO is often cheaper than two retainers.

By comparison, a senior in-house privacy lead in a metro indicatively costs Rs 30 lakh to Rs 60 lakh a year all-in, before tooling and the recruitment cycle. For most companies below 1,000 staff, the retainer is the more economical and more defensible option. Test your exposure with the Penalty Exposure Estimator on our tools page before deciding how much governance to buy.

Onboarding a vDPO in 30 days

This is the plan we run.

Days 1 to 7: appointment. Board resolution appointing the vDPO or naming the contact person. Kick-off with each function and collection of existing notices, contracts and system inventories. Publication of contact details on the website and privacy notice.

Days 8 to 15: data mapping and gap assessment. Build the records of processing: what data, for what purpose, on which lawful basis (consent or a Section 7 legitimate use), where stored, which processors, retained how long. Gaps scored by severity. Preliminary SDF likelihood view.

Days 16 to 23: quick fixes. Publish or correct the Section 5 notice. Fix visible consent problems: pre-ticked boxes, bundled consent, missing withdrawal routes. Stand up the grievance mailbox and rights log with the published response period. Issue processor addenda to the top ten vendors by data volume. Confirm breach escalation and CERT-In reporting routes.

Days 24 to 30: governance. First leadership report with the roadmap sequenced to May 2027. Agree the monthly cadence, internal champion and escalation matrix. Book DPIAs for high-risk processing, particularly children’s data under Section 9 or biometric attendance in HR.

By day 30 you have a named officer, a published contact, a processing register, a gap list with owners and a board that has seen the plan.

When a virtual DPO is not enough

We re-scope engagements when a vDPO alone would give false comfort. Recognise yourself in any of these and plan for more than a retainer.

You have no security baseline. Without access control, logging, backups and encryption, the vDPO will write findings nobody can close. The Rules list these safeguards and the penalty for failing them is the highest in the Schedule. Pair the vDPO with a Cybersecurity Posture Check and an implementation owner.

You are a large SDF with regulator-facing operations. A bank, insurer, large lending platform or hospital group with regular supervisory interaction usually needs an in-house DPO supported by an outsourced team, not the reverse. The vDPO works well as deputy, auditor liaison or interim officer during recruitment.

Your group spans jurisdictions. A vDPO can hold the India role, but a group under GDPR and DPDP needs a global privacy lead who owns the conflicts, such as GDPR’s one-month DSAR window against DPDP’s published period, or GDPR’s legitimate interests balancing which has no DPDP equivalent.

Leadership wants a name, not a function. A vDPO denied information, access and authority is a liability, not a safeguard. Fix that first.

Frequently Asked Questions

Is a virtual DPO legally valid under the DPDP Act?

Yes, in our reading. Section 10 requires an SDF’s DPO to be based in India, represent the fiduciary, report to the board and act as grievance contact; it does not require an employee. A properly appointed, independent vDPO meeting those conditions satisfies the requirement, and the Section 8 contact-person duty for non-SDFs is even more clearly met.

Do I need a DPO if my company is not a Significant Data Fiduciary?

Not a statutory DPO, but you must publish the contact of a person who can answer data principals’ questions and run an effective grievance mechanism. That person needs the same skills as a DPO, and appointing one now positions you for a later SDF notification without starting over.

How much does a virtual DPO cost in India?

Indicatively, monthly retainers range from about Rs 60,000 for a small non-SDF to Rs 4,00,000 and above for a notified SDF or regulated entity, excluding GST. Onboarding is typically Rs 1,50,000 to Rs 6,00,000. These are market ranges, not quotes.

What happens if we suffer a breach during the retainer?

The vDPO leads the response: notifying affected data principals and the Data Protection Board without delay, filing the detailed report within 72 hours under the Rules, and coordinating any CERT-In 6-hour reporting. Hours within the annual allowance are covered; extended forensic or legal work is scoped separately.

How quickly can a vDPO be operational?

The officer is appointed and published in the first week, and the processing register, gap assessment and grievance process are in place by day 30. Companies starting from scratch usually add a Readiness Sprint alongside the first month.

Related explainers

• Significant Data Fiduciary (SDF) explained

• Data Fiduciary vs Data Processor under the DPDP Act

Next step

If you need a named, India-based data protection officer or a published contact person before May 2027, the fastest route is a short scoping call where we size the retainer against your data, sector and SDF likelihood. Book a vDPO scoping call at /services and we will send a written scope and indicative fee within five working days.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

Employee data is the one dataset the DPDP Act touches in every Indian organisation, regardless of sector or size. Section 7 lets employers process personal data for employment purposes without consent, but that legitimate use is narrower than most HR teams assume and does not cover third-party background checks, non-essential biometrics, wellness health data or intrusive monitoring. Retention after exit is set by labour, provident fund and income tax laws first, and by the DPDP erasure duty for everything else. This guide gives HR and compliance leads a data inventory checklist, a consent-versus-legitimate-use decision table and a sample retention schedule to work from before May 2027.

Why dpdp act employee data is the compliance problem every company shares

A ten-person startup and a 40,000-person manufacturer differ in almost everything except this: both hold PAN, Aadhaar copies, bank details, salary history, medical certificates and performance records for every person they employ. Customer data varies by business model. Employee data does not.

HR data is now almost entirely digital, so it sits squarely within the Act. Under Section 4, every item must be processed either with consent under Section 6 or for a legitimate use under Section 7. There is no third option, and unlike the GDPR there is no legitimate interests balancing test to fall back on (see our DPDP 101 explainer). HR therefore needs to know, for each category of employee data, which basis it relies on, and be able to show that answer to the Data Protection Board. Most organisations we review cannot do that today.

What dpdp hr compliance requires under the Section 7 employment purpose

Section 7 lists situations in which a data fiduciary may process personal data without consent. The one HR relies on covers processing for purposes of employment, or for safeguarding the employer from loss or liability, including prevention of corporate espionage, confidentiality of trade secrets, and provision of any service or benefit sought by the employee.

In our reading, this covers the core of the relationship: onboarding, payroll and statutory deductions, leave and attendance, performance management, misconduct investigations, access control, and benefits the employee has asked for.

Where the employment purpose stops

Three boundaries recur in practice. First, the purpose must actually be employment: using employee contacts for marketing is not. Second, necessity is the operative test; blood group, religion, caste and marital status often sit in onboarding forms with no employment justification. Third, Section 7 does not switch off other duties. Section 8 security safeguards and erasure once the purpose is served, and the Section 11 to 14 rights, apply whether or not consent was taken. The Section 5 notice is tied to consent-based processing, but in practice a clear HR privacy notice is the simplest way to evidence purpose limitation for legitimate-use processing too. See our Section 7 lawful basis explainer.

When is employee consent dpdp compliant, and when is it still needed?

Employers routinely take a blanket consent signature at offer stage. Under Section 6 that consent is close to worthless: consent must be free, specific, informed, unconditional and unambiguous, with withdrawal as easy as giving it. A candidate who must sign to receive an offer is not consenting freely, and one line covering “all HR purposes” is not specific.

The better approach is to rely on Section 7 for what it genuinely covers and take separable consent only where the employment purpose does not reach. The table reflects our practice view.

Anything on the consent side must be operationally reversible: an employee who withdraws consent to the wellness app must keep their job without detriment. For every category on the legitimate-use side, keep a short written record of why it is necessary. That record is your defence.

Biometric attendance and necessity

A fingerprint or face template cannot be changed once compromised. We covered the detail in our biometric attendance blog post, and the conclusion holds: an employer that considered alternatives, limited the template to attendance, encrypted it, kept it off the device vendor’s cloud unless a processor contract exists, and set a deletion date at exit is defensible. One that let the vendor’s app upload templates to an unknown server is not. The Act has no sensitive data categories, but the Board’s view of reasonable security safeguards under Section 8 will in practice be stricter for data that causes permanent harm if leaked.

Background verification consent dpdp requirements and candidate data

Candidates are data principals from the moment a CV arrives. In our reading the Section 7 employment purpose extends to prospective employment, so evaluating a CV is covered. Keeping every rejected CV for five years is not: the purpose is served when the requisition closes. A workable rule is six to twelve months tied to a documented purpose such as defending process complaints, then deletion. For a talent pool, ask for consent and honour withdrawal.

Background verification is the sharpest edge because three parties are involved: the employer, the BGV vendor, and the sources the vendor contacts (former employers, universities, courts, neighbours). The vendor is a data processor that must be engaged under a valid contract, and the employer remains responsible for what it does. The consent should name the vendor, the checks, the sources, the retention period for the report, and the candidate’s right to see and correct it. In regulated sectors, the RBI Master Direction on KYC and the RBI cyber security framework for banks push towards documented staff screening; that does not remove the need for consent, it strengthens the case for doing it properly.

Payroll, HRMS and BGV vendors as data processors

The average mid-sized Indian company we review has employee data in six to ten external systems: cloud HRMS, payroll bureau, PF and ESI consultants, insurance broker and TPA, BGV vendor, biometric device vendor, learning platform, and an offshore parent’s global HR system. Each is a processor engaged under what must be a valid contract, and the Rules list contractual measures with processors among the reasonable security safeguards, so a purchase order with no data protection terms is a gap.

Minimum contract terms in practice: processing only on documented instructions, safeguards matching the Rules (encryption, access control, one-year log retention, backups), breach notification fast enough for you to meet your own 72-hour duty to the Board, sub-processor and cross-border disclosure, and deletion at contract end. Our vendor remediation guide covers the renegotiation sequence. For subsidiaries whose global HRMS sits abroad, Section 16 permits the transfer except to countries restricted by Central Government notification; the missing contract and the missing notice to employees are usually the real problem.

HR data inventory checklist

You cannot assign a basis, a retention period or a processor to data you have not listed. Complete one row per data category, not per system.

Employee data retention india: statutory holds versus DPDP erasure

Section 8 requires erasure when the purpose is served, unless retention is necessary for compliance with law. For HR data the second half does most of the work, because labour, provident fund and income tax laws impose retention periods that outlast the employment. The Rules’ three-year inactivity erasure rule applies to specified large platforms, not to employers as such.

The schedule below is indicative and should be validated by labour counsel against the statutes applicable to your state and sector; periods differ across state Shops and Establishments rules and the labour codes as they come into force.

“Retain for tax” does not mean retain everything: keep the payroll ledger, delete the Aadhaar scan. Retention must also be enforced at each vendor, so the exit checklist needs a line per processor.

Handling employee rights requests

Employees and former employees have the same Section 11 to 14 rights as customers: access to a summary of their data and the processors it went to, correction and erasure, grievance redressal within a published period (the Rules cap it at 90 days), and nomination. The access and correction rights are framed around consent-based processing, but in practice we advise treating every employee request as if the rights apply, because most HR data is a mix of both bases anyway.

The requests that actually arrive are predictable. A former employee asking for their file during a dispute should receive a summary and the underlying documents, minus third-party data. A request to correct a performance rating can be declined with reasons where the rating is an evaluative opinion, not a factual error. A request to erase a disciplinary record can be declined while the dispute defence purpose is live, with the reason recorded. Our DSAR workflow guide covers intake and response, and Your DPDP Rights is the version you can point employees to.

The exposure for getting this wrong sits in Section 33 and the Schedule: up to Rs 250 crore for security safeguard failures, which is what a leaked payroll file or biometric database represents, and up to Rs 50 crore for most other breaches. The Penalty Exposure Estimator lets you model your own numbers.

Frequently Asked Questions

Does an employer need consent from employees under the DPDP Act?

Not for the core of the employment relationship. Section 7 allows processing for employment purposes and for safeguarding the employer from loss or liability without consent. Consent is still needed for processing outside that purpose, such as wellness programmes, third-party background checks on candidates, biometrics where alternatives exist, and use of employee photos in marketing.

Is a signed consent clause in the offer letter valid under Section 6?

In our reading, no. Section 6 requires consent to be free, specific and unconditional, and a clause that must be signed to receive an offer is neither free nor specific. Rely on Section 7 for what it covers, and take separate, withdrawable consent only for the categories that fall outside it.

How long can we keep employee data after an employee leaves?

As long as a law requires, and no longer than the purpose needs. Income tax, provident fund and labour statutes set retention periods for payroll and statutory records that typically run three to eight years. Data with no statutory driver, such as biometric templates and background verification reports, should be deleted at exit or within a short documented buffer.

Are payroll and background verification vendors data processors under the DPDP Act?

Yes. Any vendor processing employee data on your behalf is a data processor, must be engaged under a valid contract, and you remain responsible for its compliance. The contract should cover security safeguards, breach notification timing, sub-processors, cross-border transfers and deletion at contract end.

When do these HR obligations become enforceable?

Most substantive obligations under the DPDP Act, including notice, consent, security safeguards, breach notification and data principal rights, become enforceable 18 months after the November 2025 notification of the Rules, which is May 2027. Employee data inventories, vendor contracts and retention schedules take months to fix, so the work should start now.

Related explainers

• Data Fiduciary vs Data Processor under the DPDP Act

• DPDP Act vs IT Act SPDI Rules

Next step

The fastest way to close the transparency gap is a clear HR privacy notice that tells employees and candidates what you collect, on what basis, which vendors see it and how long you keep it. Download the HR privacy notice template, part of the 16 DPDP Starter Templates, and adapt it to the inventory you have just built.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

DPDP compliance for SaaS companies turns on one question: for each set of personal data you touch, are you the data fiduciary or the data processor? For customer data loaded into your platform you are almost always a processor, which means you act only under a valid contract with your customer and the customer remains legally answerable to the Data Protection Board. For your own users, prospects and employees you are the fiduciary with the full set of Section 5 to Section 8 duties. This guide covers the test, the processor-side DPA, sub-processor management and the DPDP questionnaires enterprise customers are already sending ahead of the May 2027 enforcement date.

Are you a data processor under DPDP Act or a data fiduciary?

A data fiduciary determines the purpose and means of processing; a data processor processes on the fiduciary’s behalf. The Act attaches nearly every substantive obligation (notice, consent, safeguards, breach notification, rights, erasure) to the fiduciary. The processor appears mainly in Section 8: a fiduciary may engage one “only under a valid contract”, and remains responsible for compliance regardless of that contract.

The practical test

In our reading, three questions per data set settle it:

Who decided this data would be collected, and why? If your customer, you are processing for them.

Who can repurpose it? If you cannot without the customer’s instruction, you are a processor.

Whose data principals are they? A relationship with your customer, not you, points to processor status.

Worked examples

A payroll SaaS storing salary and bank details for 400 client companies is a processor for that data: the client decided to collect it and could switch vendors tomorrow. The same company is the fiduciary for the HR managers who log in, because it chose to collect their names, emails and login logs for its own account management.

A CRM or analytics product that pools customer data to build benchmark models is harder. If it uses customer data for its own product improvement or model training, it is determining a purpose of its own, and in our reading becomes a fiduciary for that processing. The Act and Rules Explorer gives the exact statutory wording for these definitions.

What a data processor under DPDP Act must actually do

These obligations flow from Section 8 and the DPDP Rules, 2025 (notified November 2025) through your contract, plus the CERT-In Directions of April 2022 which apply to you directly.

The statutory obligation sits with your customer; the contract turns it into yours. A weak DPA is how you accept an open-ended indemnity instead of a manageable set of duties. The stakes explain why customers are aggressive: under the Schedule, failure of security safeguards attracts up to Rs 250 crore and failure to notify a breach up to Rs 200 crore. Those penalties land on the fiduciary, who will look to recover from the processor whose control failed. Our penalties Schedule explainer walks through each tier.

What a SaaS data processing agreement India customers will expect should contain

There is no prescribed DPA form. In practice the market is converging on GDPR Article 28 style documents adjusted for Indian law. A SaaS data processing agreement India customers will accept should cover the following.

Scope and instructions

Define data categories, data principals, purposes and duration. State that you process only on documented instructions, with service documentation and admin console settings counting as instructions, and carve out processing required by Indian law.

Security safeguards

Attach a security annex mapped to the Rules’ safeguard list: encryption in transit and at rest, role-based access, MFA for privileged access, centralised logging with one-year retention, tested backups, vulnerability management. Cite ISO 27001 or SOC 2 Type II if held. Promise specific, verifiable controls, not “bank-grade security”.

Breach notification timeline

The clause customers negotiate hardest. Because the fiduciary must notify the Board without delay and report within 72 hours, most enterprise customers ask for processor notification within 24 hours of confirmation, some within 12. Commit to what your incident process can deliver and define “becoming aware” carefully. Our 72-hour breach response guide sets out a timeline that works from the processor side too.

Sub-processing

Obtain general written authorisation for the sub-processors in your register, with a notice period (30 days is typical) before adding one and a right to object. Commit to flowing down equivalent terms and remaining liable for sub-processor performance.

Cross-border transfers

Section 16 permits transfers outside India except to countries restricted by Central Government notification. Disclose hosting regions and offshore support access, and commit to complying with any restriction notification. See our Section 16 cross-border explainer.

Rights assistance, exit and liability

Commit to tooling for rights requests (the customer must meet its published response period, max 90 days under the Rules), audits on notice with a right to substitute a third-party report, and deletion within a defined period after termination, confirmed in writing. Resist unlimited liability; a super-cap of two to three times annual contract value is a common commercial landing point. The DPDP Starter Templates include a vendor agreement pack adaptable to the processor side.

DPDP for B2B software: the dual-role trap

DPDP for B2B software is harder than it looks because most SaaS companies think of themselves as “just a processor” and stop there. The dual-role trap is the set of flows where you are in fact the fiduciary and nobody has noticed.

Product usage data about your customer’s users. Login times, feature clicks and session recordings collected for your own analytics make you a fiduciary for that data, needing a Section 5 notice and a Section 6 or 7 basis.

Your own employees. Section 7 provides an employment legitimate use, but safeguards, breach handling and a grievance contact still apply.

Prospects and website visitors. Form fills, cookie tracking and lead enrichment are fiduciary activities from the first byte. Read our Section 7 lawful basis explainer before assuming a legitimate use covers B2B prospecting; in our reading it usually does not.

The fix is a data inventory that assigns a role to every data set. Flows tagged “fiduciary” go through your own compliance programme: notice, lawful basis, retention, rights handling. Flows tagged “processor” go through the contract programme above. A flow tagged both, such as product telemetry, is the one to escalate to counsel. DPDP 101 is a good grounding for product and marketing teams who need to understand why.

Sub-processor DPDP flow-down and the register you must keep

Every SaaS company uses sub-processors: hosting, email delivery, payment gateways, error tracking and, increasingly, AI model providers. A sub-processor DPDP flow-down binds each of them to terms at least as protective as your own DPA, because your customer’s Section 8 responsibility runs through you to them.

Three flow-down rules

First, no personal data reaches a vendor without data processing terms. A click-through ToS is a contract, but read it: many US vendors’ terms allow product improvement uses your customers have not authorised.

Second, map each sub-processor to the data it can touch; an error-tracking tool receiving full request payloads sees far more than its category suggests.

Third, maintain a register and a change notification process; customers cannot object to what they cannot see. Our vendor remediation explainer covers vendors who refuse to sign.

Sub-processor register template

Keep the register under version control; the review date column shows customers you actually manage it.

How to answer customer DPDP questionnaires and what to put on a trust page

Procurement teams in banking, insurance, pharma and IT services are already sending DPDP questionnaires to SaaS vendors. The questions are predictable, and vendors who answer fastest win deals.

The questions you will be asked

The trust page

A public trust page reduces questionnaire volume. It should contain your role statement, hosting and residency summary, a security overview mapped to the Rules’ safeguards, your sub-processor register, your standard DPA, your breach notification commitment, certifications with dates, and a named privacy contact for grievances. “Enterprise-grade security” persuades nobody; “logs retained 12 months in Mumbai region, MFA on all privileged access” does.

Run the Readiness Checklist against both your processor commitments and fiduciary obligations before publishing; a trust page that overstates controls becomes evidence against you in a dispute. Do not wait for May 2027: contracts signed in 2026 will still be in force when enforcement begins.

Frequently Asked Questions

Is a SaaS company legally liable under the DPDP Act if it is only a processor?

The Act places statutory obligations and penalties on the data fiduciary, which remains responsible regardless of any contract with the processor. In practice a processor’s liability arrives through the DPA, including indemnities and breach notification commitments. A processor also carries direct obligations under the CERT-In Directions, including six-hour incident reporting.

Do we need a DPDP-specific DPA if we already have a GDPR Article 28 DPA?

A GDPR DPA is a good base but needs adjustment. Indian customers will expect references to the DPDP Act and Rules, breach timelines that support the fiduciary’s 72-hour report to the Board, and Section 16 transfer language. Many firms maintain one global DPA with an India addendum.

Can we use customer data to train our AI models or improve our product?

Only if the contract clearly authorises it, and in our reading that use makes you a fiduciary for that processing, with its own notice and lawful basis requirements. Aggregation or anonymisation clauses help only if the output is genuinely no longer personal data.

How quickly must a processor notify its customer of a breach?

The Act and Rules do not set a processor-to-fiduciary timeline; they require the fiduciary to notify affected data principals and the Board without delay and file a detailed report within 72 hours. Enterprise contracts therefore typically require processor notification within 12 to 24 hours of confirmation.

Do sub-processors outside India create a problem under DPDP?

Section 16 permits cross-border transfers except to countries restricted by Central Government notification, so offshore sub-processors are generally permissible. Disclose locations in your register, commit to complying with any future restriction, and check sector rules such as RBI requirements for payment data that impose localisation independently.

Related explainers

• Data Fiduciary vs Data Processor under the DPDP Act

• DPDP vs GDPR: key differences

Next step

If your customers are already sending DPDP questionnaires or redlining your DPA, a processor-side review will settle what you can commit to and where the dual-role gaps are. Our Privacy Governance Review covers your DPA, sub-processor register, security evidence and trust page in a single engagement. Book it before your next enterprise renewal cycle.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

The DPDP Act allows a data fiduciary to engage a data processor “only under a valid contract”, and the DPDP Rules, 2025 list contractual measures with processors among the reasonable security safeguards. A data processing agreement under DPDP is therefore the document that proves you controlled your vendors when the Data Protection Board asks. This guide sets out the 12 clauses a compliant agreement needs, with sample wording for six, marks negotiation red lines for each side, compares the result with a GDPR Article 28 DPA, and gives a rollout plan for existing vendors before May 2027.

Why a data processing agreement under DPDP is a legal requirement, not a nicety

The Act separates the data fiduciary, who decides purpose and means, from the data processor, who acts on its behalf. Two features matter for contracts: the fiduciary may engage a processor only under a valid contract, and it remains responsible for compliance regardless of that contract. You can outsource the work but not the liability.

The DPDP Rules, 2025 sharpen this. The reasonable security safeguards required under Section 8 include encryption, access control, logging and monitoring with logs retained for at least one year, backups, and contractual measures with data processors. A fiduciary whose vendor loses data and who cannot produce a contract obliging that vendor to protect it has, in our reading, failed the security safeguards duty itself, which the Schedule caps at Rs 250 crore. Our penalties Schedule explainer sets out the tiers.

The timeline is tight. Security safeguards and breach notification become enforceable in May 2027, and most Indian businesses have dozens to hundreds of vendors touching personal data. Each needs a contract that reflects the Act before that date.

DPDP vendor contract clauses: the 12 you cannot leave out

The Act does not prescribe a clause list the way GDPR Article 28 does. That gives drafting freedom, but the Board will judge whether your contract actually delivered the safeguards the Act expects. In practice, these 12 clauses are the minimum. Sample language is given for the six that generate the most negotiation.

1. Scope and purpose

State the categories of data principals and personal data, the processing operations, and the specified purpose. Tie the purpose to your Section 5 notice, because a processor cannot be asked to do something you never told the data principal about.

Sample clause: “The Processor shall process Personal Data solely for the purposes in Schedule 1. Any other processing requires the Fiduciary’s prior written instruction. The Processor acknowledges that Data Principals have been given notice for the Schedule 1 purposes only.”

2. Processing on documented instructions

The processor acts only on documented instructions and must flag any instruction it believes would breach the Act. This clause keeps the vendor a processor rather than a fiduciary in its own right.

3. Security safeguards

Do not write “industry standard security”. Mirror the Rules.

Sample clause: “The Processor shall implement and maintain, at minimum, the safeguards in Schedule 2, which include: encryption of Personal Data in transit and at rest; access limited to personnel with a documented need; logging of access to and processing of Personal Data, with logs retained for not less than one year; and backups sufficient to restore Personal Data within the recovery objectives in Schedule 2.”

4. Sub-processing

Require prior authorisation for sub-processors, a maintained list, flow-down of the same obligations, and full responsibility for sub-processors’ acts. Most disputes with cloud and SaaS vendors sit here.

Sample clause: “The Processor shall not engage a Sub-processor without the Fiduciary’s prior written authorisation. The Processor shall impose on each Sub-processor, by written contract, obligations no less protective than those in this Agreement and shall remain fully liable to the Fiduciary for the performance of each Sub-processor.”

5. Breach notification and assistance timelines

The fiduciary must notify affected data principals and the Board without delay and file a detailed report within 72 hours; CERT-In Directions separately require reporting of listed incidents within 6 hours. If the vendor takes five days to tell you, both deadlines are gone. The contract must set a much shorter clock.

Sample clause: “The Processor shall notify the Fiduciary of any Personal Data Breach without undue delay and in any event within 12 hours of becoming aware of it, providing the information in Schedule 3, and shall update that information as it becomes available. The Processor shall provide all assistance the Fiduciary reasonably requires to notify Data Principals, the Data Protection Board and CERT-In within applicable statutory timelines.”

Our 72-hour breach response guide shows how this clock feeds your own runbook.

6. Assistance with data principal rights

Data principals can seek access, correction, erasure and grievance redressal under Sections 11 to 14, within the period you publish under the Rules (maximum 90 days). The processor must locate, correct and erase data within a window that leaves you time to respond.

7. Retention and deletion on termination

Section 8 requires erasure when the purpose is served. The processor must delete or return data on termination or instruction, certify deletion, and clear backups within a stated cycle.

Sample clause: “Within 30 days of termination or expiry, or earlier on the Fiduciary’s instruction, the Processor shall return or securely delete all Personal Data, including copies held by Sub-processors, and shall certify deletion in writing. Personal Data in backup media shall be deleted within the Processor’s standard backup rotation cycle, not exceeding 90 days, and shall not be restored to live systems.”

8. Audit and evidence

The Board can require evidence, and Significant Data Fiduciaries face an independent data audit under Section 10. Reserve the right to request evidence and to audit on reasonable notice.

Sample clause: “The Processor shall, on 15 days’ notice and not more than once in any 12 months (or at any time following a Personal Data Breach), permit the Fiduciary or an independent auditor bound by confidentiality to audit its compliance with this Agreement, and shall provide on request the evidence in Schedule 4.”

9. Cross-border processing

Section 16 permits transfers except to countries restricted by Central Government notification. Require disclosure of processing locations, advance notice of changes, and cessation of transfers to any restricted country. Sector rules such as RBI payment data localisation may be stricter. See our Section 16 cross-border explainer.

10. Confidentiality and personnel

Personnel with access must be under written confidentiality obligations, trained, and background-checked in proportion to the data.

11. Liability and indemnity

Penalties fall on the fiduciary, so the contract is your only route to recover from a vendor. Cover indemnity for penalties and third-party claims caused by the processor, and negotiate the cap deliberately rather than accepting a fee-based boilerplate.

12. Term and survival

Confidentiality, deletion, audit rights for a defined period, and indemnity must survive termination.

Negotiation red lines in a dpdp third party contract: fiduciary versus processor

Both sides have legitimate positions. The table shows where each should hold and where it can concede.

A processor that refuses any breach notice, audit or deletion obligation cannot meet the Act. In practice, that is a vendor to replace, not negotiate with.

Data processor agreement India template versus a GDPR Article 28 DPA

GDPR-style DPAs signed with European customers or global SaaS vendors are a useful starting point, not a substitute.

In practice a GDPR DPA needs its breach clock tightened, log retention added, the Board and CERT-In named as recipients, the rights window aligned to your published period, and the cross-border clause rewritten around restricted-country notifications rather than adequacy. For a broader comparison, see our DPDP 101 primer and the Act and Rules Explorer.

Rolling out a dpa template india across vendors you already have

New vendors are easy. The harder job is the existing base. A workable rollout, with indicative timelines, looks like this.

Step 1: Inventory and tier (3 to 4 weeks)

List every vendor that receives, stores or can access personal data and tier them by volume, sensitivity and substitutability. Tier 1 holds customer or employee data at scale (payroll, cloud, CRM, support outsourcing); Tier 3 has incidental exposure, such as a courier receiving a name and address. Our Readiness Checklist includes a vendor inventory section.

Step 2: Decide the instrument (1 week)

Tier 1: a standalone agreement or comprehensive addendum. Tier 2: an addendum to the master agreement. Tier 3: standard clauses in purchase order terms. Negotiating a full DPA with 300 vendors is how programmes stall.

Step 3: Issue and negotiate (8 to 12 weeks)

Send the addendum with a cover note citing the statutory basis and the May 2027 date. Global vendors will offer their own DPDP addendum; review it against the 12 clauses rather than redlining line by line. Track responses in a register.

Step 4: Handle refusers (ongoing)

A vendor that will not sign leaves three options: accept a documented risk with a replacement plan, restrict the data shared, or exit. Record the decision. A documented risk decision is more defensible than a missing contract with no explanation.

Step 5: Evidence and maintenance

File signed agreements, sub-processor lists and evidence packs in one place, with a trigger to re-check whenever a restricted country is notified. Our vendor remediation guide covers the register format we use.

Indicative effort for a mid-sized company with 80 to 150 data-touching vendors is 12 to 20 weeks of part-time work by legal, procurement and IT. Start in 2026.

Frequently Asked Questions

Does the DPDP Act require a written data processing agreement?

The Act says a fiduciary may engage a processor only under a valid contract, and the DPDP Rules, 2025 list contractual measures with processors among the reasonable security safeguards. In our reading, a written agreement is the only practical way to evidence both. Treat it as mandatory.

Can our existing GDPR DPA with a vendor serve as our DPDP agreement?

Only partly. A GDPR DPA has the right structure but the wrong timelines, recipients and cross-border mechanics. Tighten the breach clock, add log retention of at least one year, name the Data Protection Board and CERT-In, and align the rights window to the period you publish under the Rules.

How quickly should a processor be required to notify us of a breach?

The fiduciary must notify the Board and affected data principals without delay and file a detailed report within 72 hours, and CERT-In requires reporting of listed incidents within 6 hours. In practice we recommend initial contractual notice within 12 to 24 hours of awareness, with updates as information becomes available.

Is the fiduciary still liable if the processor causes the breach?

Yes. The Act states that the fiduciary remains responsible for compliance regardless of any arrangement with a processor. The contract’s indemnity and liability clauses are your only route to recover losses from the vendor, so the cap deserves careful negotiation.

When do these contracts need to be in place?

Security safeguard and breach notification obligations become enforceable in May 2027, 18 months after the Rules were notified in November 2025. Given negotiation cycles of 8 to 12 weeks per wave of vendors, most organisations should have the programme running through 2026.

Related explainers

• Data Fiduciary vs Data Processor under the DPDP Act

• DPDP vs GDPR: key differences

Next step

The 12 clauses above are drafted in full, with schedules for data description, security safeguards, breach information and audit evidence, in our vendor agreement template, part of the 16 DPDP Starter Templates. Download the vendor agreement template and issue it to your Tier 1 vendors this quarter.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

Marketing is the function most likely to draw the first DPDP Act complaint, because it touches the most people, uses the most channels and is the easiest thing for a data principal to notice and object to. Under Section 6, marketing consent must be free, specific, informed, unconditional and unambiguous, and withdrawal must be as easy as giving it. This page maps that standard to each channel, explains how to triage a CRM with no consent records, and shows how to measure campaigns without personal data. Most obligations become enforceable in May 2027, but consent collected today is what you will rely on then.

Why marketing is the fastest route to a DPDP Act marketing consent penalty

Marketing processes personal data for the company’s own benefit, and Section 7 gives it no shelter. The legitimate uses cover voluntary provision for a specified purpose, employment, medical emergencies and State functions. Promotional messaging is not on the list, and there is no GDPR-style legitimate interests test to fall back on. In our reading, consent under Section 6 is the only lawful basis for outbound marketing, obtained with a Section 5 notice that names the purpose plainly.

Volume and visibility make marketing uniquely exposed: one badly worded checkbox becomes lakhs of defective consents, and the unwanted message itself is the evidence. On penalties, marketing failures generally fall in the “other breaches” band of up to Rs 50 crore in the Schedule, and if the audience includes anyone under 18, Section 9’s ban on tracking and targeted advertising directed at children moves exposure to the Rs 200 crore band. Our penalties Schedule explainer covers how gravity, duration and repetition are weighed.

WhatsApp marketing consent under DPDP: opt-in is not the same as a phone number

Meta’s WhatsApp Business policy requires an opt-in before marketing templates are sent, and many teams treat that opt-in as proof of DPDP consent. It is not. The platform opt-in is usually a bundled line in checkout terms, an auto-ticked box, or inferred because the customer messaged first. Section 6 requires consent that is specific (marketing named as a purpose, separate from order updates), unconditional (the purchase cannot depend on it) and unambiguous (an affirmative act, not silence). A customer asking for delivery status has, at most, volunteered their number for that purpose under Section 7; they have not consented to a weekly catalogue.

The second gap is withdrawal. If a customer opted in with one tap, replying “STOP” must work across every template and every sending vendor, without a helpline call. Keep a consent record per number showing the wording shown, timestamp, source and any withdrawal event. That record is your defence when the Board asks.

Channel-by-channel consent table

The standard is the same on every channel; the mechanics differ.

On SMS: TRAI’s DLT framework is enforced by telecom operators to control spam; the DPDP Act is enforced by the Board to protect the person. A template can be DLT-compliant and still unlawful under Section 6 because the consent was never specific or was withdrawn. Run both registers, and make sure a STOP on one updates the other.

Email marketing under the DPDP Act: notice, separation and unsubscribe

From May 2027, sending to a contact without a consent record you can produce is processing without a lawful basis, however old the list.

What the notice must say

Section 5 requires the notice to describe the data and purpose and to explain how to withdraw consent, exercise rights and complain to the Board. For a marketing signup that is a short, visible line at the point of collection, not a link to a 4,000-word policy. Our Section 5 notice guide has wording that survives both legal and conversion-rate review.

Transactional versus promotional

Order confirmations, invoices and password resets can rely on Section 7 voluntary provision. Add a “you might also like” block and the same email becomes marketing. Keep the streams separate so a marketing withdrawal does not break service messaging.

Unsubscribe parity

If signup took one click, unsubscribe must take one click. Preference centres that require a login, “are you sure” interstitials, or a ten-day processing window fail Section 6 in our reading. Honour the request in the sending platform, the CRM and every downstream sync; a person who unsubscribes and receives one more email has a clean complaint.

CRM data DPDP compliance: triaging a legacy database with no consent record

“We have 8 lakh contacts and no idea where half came from. Do we delete them?” Not necessarily, but you cannot keep marketing to them as if nothing changed. We recommend a triage, run before May 2027.

Step 1: classify every record by provenance

Tag each contact with the best evidence you have: an opt-in event with wording and timestamp; a customer relationship with an order date; an event badge scan; an imported file with no source. Provenance also tells you how long you can defensibly keep the record under Section 8.

Step 2: apply a decision rule

Step 3: run the re-permission campaign properly

A re-permission campaign is itself processing, so keep it to one message per channel, name the purpose, make “no” as easy as “yes”, and treat no response as no. Indicative response rates in Indian B2C re-permission campaigns run between 5 and 20 percent, so budget for a much smaller but defensible list. Suppress non-responders during the window (you need a record of who declined), then delete once the window closes and no other purpose such as accounting, warranty or dispute requires retention. Our DPDP Starter Templates include a re-permission notice and a suppression log format.

Consent managers, records and the role they play for marketing

The Act creates a consent manager, registered with the Board under the Rules, through which a data principal can give, review and withdraw consent across fiduciaries. These provisions apply 12 months after notification, ahead of most other obligations. A consent manager will not replace your own capture, but it changes two things for marketing.

First, a withdrawal can arrive through a consent manager rather than your unsubscribe link, so your suppression pipeline needs an intake for third-party signals. Second, when a person can see every consent they have given in one dashboard, vague purposes such as “communications and offers” will look weak beside specific ones. Design consent records now with fields a consent manager could consume: purpose code, wording version, timestamp, channel, source and status. The Act and Rules Explorer traces the consent manager provisions against the Rules.

Cookie consent in India under the DPDP Act: what the banner must actually do

The Act has no cookie clause, but a retargeting pixel or analytics cookie that identifies a device and links it to browsing behaviour is processing digital personal data for marketing, so Section 6 applies. That matters for the banner most Indian sites copied from a European template and never configured.

Non-essential tags must not fire until the person acts; a banner that says “we use cookies” while the Meta pixel has already loaded is notice without consent. “Reject all” must be as visible as “Accept all”; burying rejection behind “Manage preferences” fails parity in our reading. Withdrawal must be reachable later through a persistent footer link that reopens the choice and clears identifiers set under the earlier consent.

Dark patterns to remove before 2027

The patterns we most often flag, each undermining a Section 6 condition: pre-ticked marketing boxes (not unambiguous); consent bundled into “I agree to the terms” (not specific); discounts or app access conditional on marketing consent (not unconditional); accept buttons in brand colour with reject in grey text, or confirmshaming copy such as “No, I don’t want to save money” (not free); unsubscribe links that lead to a login page (withdrawal harder than consent). Each is cheap to fix and expensive to defend.

Children and marketing

Section 9 prohibits tracking, behavioural monitoring and targeted advertising directed at anyone under 18, and requires verifiable parental consent for a child’s data. Brands with a teenage audience (edtech, gaming, fashion, snacks) should assume retargeting and lookalike pipelines will pull in under-18s unless designed to exclude them. The marketing consequence is simple: do not profile or target where you cannot rule out a child. Our DPDP 101 guide covers Section 9 in more depth.

Measuring campaigns without personal data

Consent-first does not mean measurement-blind, but it does mean moving from person-level tracking to aggregate and modelled measurement wherever the consent rate does not justify the risk.

Server-side event collection behind a consent gate counts conversions from consented users without leaking data to third-party scripts. Cohort analysis on data stripped of direct identifiers, and geo or time-split holdout tests (run a campaign in one set of cities against a matched control), give incrementality readings that need no individual tracking. Attribution can lean on first-party data you hold consent for, such as order counts by promo code, and on platform-side aggregated reports rather than user-level exports. Where a metric needs personal data, ask whether the purpose was in the notice; if not, it is out of scope until the notice is updated. Raw event logs tied to an identifier should have a defined lifetime, since Section 8 expects erasure once the purpose is served. Keep the aggregates, delete the rows.

Frequently Asked Questions

Is a WhatsApp Business opt-in enough for DPDP Act compliance?

No. The platform opt-in is a Meta policy requirement and is often collected in a bundled or inferred way. Section 6 needs a separate, specific, unambiguous consent for promotional messaging, backed by a Section 5 notice, and a withdrawal route that is as easy as the opt-in was.

Do we have to delete our whole CRM if we have no consent records?

No, but you cannot continue marketing to it unchanged. Classify records by provenance, run a single re-permission message where a genuine relationship exists, suppress non-responders and untraceable imports, and delete once the window closes and no other retention purpose applies.

Are cookie banners legally required in India under the DPDP Act?

The Act does not name cookies, but non-essential cookies and pixels that identify a device for advertising process digital personal data for a marketing purpose. That requires consent before the tags fire, a reject option as easy as accept, and a way to withdraw later, which in practice means a properly configured banner.

When do these marketing obligations become enforceable?

Consent manager provisions apply 12 months after the Rules were notified in November 2025, and most substantive obligations including notice, consent and data principal rights become enforceable in May 2027. Fix capture and withdrawal flows now rather than re-permissioning twice.

Related explainers

• what is a Consent Manager under the DPDP Act

• DPDP vs GDPR: key differences

Next step

If your signup forms, WhatsApp templates, cookie banner and unsubscribe flows were built for conversion rather than for Section 6, a short review will show exactly which screens must change before May 2027. Book a Consent UX review and we will return a screen-by-screen fix list, a CRM triage plan and the consent record schema your systems should be capturing today.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

If you hold an ISO 27001:2022 certificate, in our reading you already have most of the reasonable security safeguards that Section 8 of the DPDP Act and the DPDP Rules, 2025 demand, because encryption, access control, logging, backup, processor contracts and incident management all trace to Annex A controls. What ISO 27001 does not give you is the privacy layer: notice, consent, data principal rights, purpose-bound retention, children’s data and Significant Data Fiduciary duties. This page provides an ISO 27001 DPDP mapping table, lists the gaps, explains where ISO 27701 fits, and shows how to run one audit calendar and one evidence set for both. Security obligations become enforceable in May 2027, so the mapping belongs in this financial year.

ISO 27001 vs DPDP: two different questions about the same data

ISO 27001 asks whether information is protected against loss of confidentiality, integrity and availability. The DPDP Act asks whether personal data of individuals is processed lawfully, transparently and only for the purpose it was collected. Security is one obligation among many in the Act, and the Act does not care whether you hold a certificate. It cares whether safeguards were in place and working when something went wrong.

The overlap is real. Section 8(5) obliges every data fiduciary to implement reasonable security safeguards, and the Rules spell out the minimum, which reads like a subset of Annex A. The divergence is scope: ISO 27001 covers whatever you put inside the certified scope, while DPDP covers all digital personal data you process, including systems your Statement of Applicability excluded.

The Schedule sets its highest cap, up to Rs 250 crore, for failure of security safeguards, and up to Rs 200 crore for failure to notify a breach. Our penalties Schedule explainer covers how the Board is expected to weigh gravity, duration and mitigation.

ISO 27001 DPDP mapping: safeguard by safeguard

The table maps each safeguard item in the DPDP Rules to the Annex A controls an auditor would expect evidence for. It is a working mapping, not a legal opinion; one Rule item usually needs several controls behind it.

Two observations from applying this mapping at client sites.

First, the one-year log retention in the Rules is longer than the 180 days most Indian firms configured after the CERT-In Directions of April 2022. Your A.8.15 implementation probably satisfies CERT-In and falls short of DPDP. Change the retention setting, get the storage cost approved, and record the change in your logging standard.

Second, A.5.34 is the only Annex A control that references personal data directly, and it is a one-line requirement to identify and meet applicable privacy obligations. Under DPDP it becomes the hook on which the whole privacy programme hangs, so treat it as a pointer to a separate body of work rather than a control that is implemented because a policy exists.

The DPDP technical safeguards rule and where a certificate is not enough

The DPDP technical safeguards rule sets a floor, and the statute adds the word “reasonable”, which is where the Board’s judgement will come in. A certificate proves controls existed and were audited at a point in time. It does not prove they were applied to the right data. The most common finding in our posture checks is scope mismatch: the ISMS covers the corporate network and the flagship product, while the HR system, the marketing automation platform and the customer support tool, which hold most of the personal data, sit outside it.

The second gap is the processor chain. A.5.19 to A.5.21 require you to manage supplier security, but the Act goes further: a fiduciary may engage a processor only under a valid contract and remains fully responsible regardless of what the processor does. Every vendor touching personal data needs DPDP-specific clauses on purpose limitation, sub-processing, breach support and deletion at exit. Our vendor remediation guide explains how to prioritise the contract backlog by data volume rather than contract value.

The third gap is notification timing. A.5.26 asks you to respond to incidents; the Rules require intimation to affected data principals and the Board without delay, followed by a detailed Board report within 72 hours. Your ISO incident process may have no legal notification workstream, no Board report template and no decision rule for what counts as a personal data breach. Bolt these on to the existing runbook; our 72-hour breach response article sets out the decision tree.

ISMS privacy DPDP gaps: what ISO 27001 leaves open

The obligations below have no Annex A equivalent. An ISMS privacy DPDP extension has to be built, not mapped.

Notice (Section 5). Every consent request must be accompanied or preceded by a notice describing the data, the purpose, how to exercise rights and how to complain to the Board. ISO 27001 says nothing about what you tell individuals. Our Section 5 notice explainer is the drafting standard we use.

Consent (Section 6). Consent must be free, specific, informed, unconditional and unambiguous, with withdrawal as easy as giving it. That is a product and marketing design problem with records to prove it.

Legitimate uses (Section 7). Employment purposes, voluntary provision and other listed uses allow processing without consent, but you must show which basis applies to each activity. That needs a processing inventory, which an ISMS asset register only partly resembles.

Data principal rights (Sections 11 to 14). Access, correction, erasure, grievance redressal and nomination need a workflow, a published response period (the Rules cap it at 90 days), identity verification and a request log. The Your DPDP Rights page sets out what individuals can ask for.

Retention and purpose limitation (Section 8). Personal data must be erased when the purpose is served or consent is withdrawn, subject to legal retention. Specified large fiduciaries face the three-year inactivity erasure rule with 48 hours prior notice. A.5.33 protects records; it does not delete them when purpose ends.

Children (Section 9). Verifiable parental consent for anyone under 18, and no tracking or targeted advertising.

Significant Data Fiduciary duties (Section 10). A DPO based in India, an independent data auditor and periodic DPIAs. An information security officer and ISMS internal audits do not substitute. Run the SDF Classifier to see whether you are likely to be notified.

Each carries its own penalty band, from up to Rs 200 crore for children’s obligations and Rs 150 crore for SDF obligations to Rs 50 crore for the rest. The certificate on the wall does not reduce them.

ISO 27701 India: the privacy extension and whether you need it

ISO 27701 extends ISO 27001 with a privacy information management system. It adds privacy requirements to the management system clauses and two annexes of controls, one for PII controllers and one for PII processors. The controller annex covers exactly the gaps above: conditions for collection and processing, obligations to PII principals, privacy by design and default, and PII sharing and transfer.

For an ISO 27001 India certificate holder, 27701 is the most efficient route to a privacy programme because it reuses your risk methodology, document control, internal audit and management review. You add a privacy risk assessment, a processing inventory, privacy roles and the annex controls, and your certification body audits the combined system in one visit.

Two cautions. ISO 27701 was written with GDPR vocabulary, so translate: PII controller to data fiduciary, PII processor to data processor, PII principal to data principal. DPDP has no legitimate interests basis and no sensitive data categories, and consent plus legitimate uses are its only lawful routes, so several 27701 controls need narrowing. Our DPDP 101 guide summarises the Indian definitions. And 27701 certification is not required by the Act; the Board will treat it as a way of organising the work, not as a defence in itself.

Indicative cost for adding 27701 to an existing 27001 programme in a mid-sized Indian firm is Rs 8 lakh to Rs 25 lakh in advisory and internal effort, plus certification body fees, over four to eight months.

One audit calendar for ISO 27001 and DPDP

Two separate compliance cycles double the interruption to operations and produce findings that contradict each other. Align DPDP work to the ISMS rhythm you already keep.

Use the Act and Rules Explorer when a control owner asks what the requirement actually says.

Evidence reuse: getting credit twice for the same work

The largest saving in a combined programme is evidence. Certification auditors and an independent data auditor under Section 10 want the same artefacts: a policy, proof it was applied, and proof someone checked. Access review records serve A.5.18 and the access control safeguard. SIEM retention configuration serves A.8.15 and the one-year log rule. Restore test reports serve A.8.13 and the backup safeguard. The supplier register with a clause tracker serves A.5.19 to A.5.22 and the valid-contract requirement. The incident register and post-incident reviews serve A.5.24 to A.5.27 and double as mitigation evidence when the Board determines a penalty.

Tag each evidence item in your GRC tool with both the Annex A reference and the DPDP section or rule, so one upload satisfies both audits. And add personal data fields to your asset register: data categories, purpose, lawful basis, retention period and processors. That turns an ISMS register into a processing inventory at marginal effort, and it is the document the Board will ask for first after a breach. Our DPDP Starter Templates include a processing inventory and processor agreement pack built to sit beside standard ISMS documentation.

Frequently Asked Questions

Does ISO 27001 certification satisfy the DPDP Act’s reasonable security safeguards?

In our reading it goes a long way if the certification scope covers every system holding personal data and the controls match the Rules’ listed items, particularly one-year log retention. It does not satisfy the Act by itself, because the Board will look at whether safeguards actually protected the data, not at the certificate. Notice, consent, rights and retention duties remain entirely outside ISO 27001.

Do we need ISO 27701 to comply with DPDP?

No. The Act does not require any certification. ISO 27701 is a structured way to build the privacy layer on top of an existing ISMS and reuse your audit machinery. Firms with a mature privacy function may prefer to map DPDP obligations directly without certifying.

Our logs are retained for 180 days to meet CERT-In. Is that enough for DPDP?

No. The DPDP Rules, 2025 require logs to be retained for at least one year, while the CERT-In Directions of April 2022 require 180 days within India. Configure retention to the longer period and keep logs in India to satisfy both.

When do the security safeguard obligations become enforceable?

Most substantive obligations, including security safeguards and breach notification, become enforceable 18 months after the Rules were notified in November 2025, which is May 2027. Consent manager provisions come earlier, at 12 months. Starting the mapping now leaves time for a full audit cycle before the deadline.

Related explainers

• DPDP Act vs IT Act SPDI Rules

• Significant Data Fiduciary (SDF) explained

Next step

If you hold ISO 27001 and want to know precisely how much of the DPDP security bar you already clear, our Cybersecurity Posture Check tests your controls against the DPDP Rules safeguard list, checks scope coverage of personal data systems and returns a prioritised gap list with evidence reuse noted. Book it through Aizzentec services.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

One cyber incident in India can start two regulatory clocks at once. The CERT-In Directions of 28 April 2022 require listed cyber incidents to be reported within 6 hours of noticing, while the DPDP Act, 2023 and DPDP Rules, 2025 require a personal data breach to be notified to affected data principals and the Data Protection Board without delay, with a detailed Board report within 72 hours. The regimes differ in trigger, recipient, content and penalty, and RBI, SEBI or IRDAI add a third layer for regulated entities. This article gives one timeline, one classification matrix and one runbook structure so your team is not reconciling clocks at 2 a.m.

CERT-In Directions 2022 and DPDP breach rules: what each regime actually requires

CERT-In, under section 70B of the IT Act, protects Indian cyberspace as a whole. The DPDP Act protects individuals whose personal data is exposed. Treating them as one obligation is the most common mistake we see in incident plans.

The CERT-In clock

The CERT-In Directions of 28 April 2022 apply to service providers, intermediaries, data centres, body corporates and government organisations, and expressly include cloud and VPN providers. Listed cyber incidents (unauthorised access, ransomware and malware, data breaches and leaks, defacement, phishing, attacks on cloud and payment systems, among others) must be reported within 6 hours of noticing. ICT logs must be kept for 180 days within India, clocks synchronised to NIC or NPL NTP servers, and VPN, cloud and data centre providers must retain subscriber KYC for 5 years.

The clock runs from “noticing”, not confirmation: a ransomware note found at 03:10 starts the clock at 03:10. CERT-In accepts a partial initial report; it does not accept silence.

The DPDP clock

Section 8 of the DPDP Act requires every data fiduciary to intimate a personal data breach to the Board and to each affected data principal. The DPDP Rules, 2025 (notified November 2025) set the mechanics: notify affected principals and the Board without delay, and file a detailed report with the Board within 72 hours. The principal notice must be in plain language and cover nature and extent, likely consequences, mitigation, steps the individual can take and a contact. Failure to notify carries a penalty of up to Rs 200 crore under section 33 and the Schedule, separate from up to Rs 250 crore for failure of security safeguards; see our penalties Schedule explainer.

Breach notification becomes enforceable 18 months after the Rules were notified, i.e. May 2027, while CERT-In has been enforceable since June 2022. Until May 2027 the DPDP clock is a rehearsal, but one to run now, because logging and evidence habits take a year to bed in. See our enforcement phases article.

Side-by-side

CERT-In vs Data Protection Board notification: how the triggers diverge

The practical question is not “which regulator do we call” but “which clocks has this incident started”. Four combinations exist.

CERT-In only. A DDoS attack takes your website down; no personal data is accessed. Report to CERT-In within 6 hours and record why DPDP was not triggered.

DPDP only. An employee emails 4,000 customer records to the wrong external address. In our reading this is a personal data breach, and arguably a “data leak” on the CERT-In list. Report to CERT-In when in doubt: over-reporting has no penalty, under-reporting does.

Both. Ransomware encrypts a customer database and exfiltrates records. CERT-In within 6 hours, principals and Board without delay, detailed Board report within 72 hours. Build the runbook around this scenario.

Neither. An encrypted laptop is stolen and the key is not compromised. Document the assessment and close the ticket.

The regimes also diverge on audience. CERT-In wants technical indicators. DPDP requires you to speak to affected individuals in plain language, so customer support and legal must be in the room, not just the SOC. The rights those individuals can then exercise are set out in Your DPDP Rights.

India breach notification timeline: one clock from T+0 to T+72h and beyond

Merge the regimes into one timeline and drill it. Times are from first noticing.

In our reading “without delay” is shorter than 72 hours; the 72-hour window is for the detailed report. Plan for principals to hear from you within 24 to 48 hours (indicative) once you know who is affected. The CERT-In window does not pause for weekends, so the on-call roster must include someone authorised to send the report.

For the DPDP-specific detail on the 72-hour window, including draft notice wording, see our 72-hour breach response guide and the companion breach notification 72-hour plan on our blog.

Sector overlays: RBI, SEBI and IRDAI on top of CERT-In and DPDP

Regulated entities carry a third clock. RBI-supervised entities report cyber incidents to RBI within 6 hours under the RBI cyber security framework for banks and related directions, with further expectations under the RBI Digital Lending Guidelines and the Account Aggregator framework. Market intermediaries report under SEBI’s cyber security and cyber resilience framework. Insurers report under the IRDAI information and cyber security guidelines.

A regulated entity may therefore file three reports on one incident. Do not write three runbooks. Write one, with a sector annex listing the extra recipient, format and deadline. Our banking sector post covers the RBI overlay.

Incident classification matrix: three questions in the first hour

Classify every incident against three questions within the first hour.

Print the resulting code at the top of the incident record, for example “PD-Y / CI-Y / SEC-RBI”.

Two decision rules we apply in practice. First, “plausibly involved” starts the DPDP clock: if a server holding personal data was accessed and you cannot prove the data was untouched, treat it as involved. Second, processor incidents are your incidents. The fiduciary remains responsible regardless of the processor, so a breach at your payroll vendor or cloud host starts your clock when you become aware. Processor contracts must require notice within hours, not days; see our vendor remediation article.

A single runbook structure that satisfies both regimes

One document, six sections, reviewed quarterly.

1. Activation and roles. Who declares an incident, how the on-call reporter is reached at 03:00, and the RACI below.

2. Classification. The three-question matrix, with examples from your own CRM, HRMS and cloud tenancy rather than generic ones.

3. Reporting packs. Pre-filled templates for the CERT-In report, principal notice, Board intimation and 72-hour Board report, plus a sector annex. Pre-fill entity details and standard paragraphs so only incident specifics are typed under pressure.

4. Communications. Approved holding statements for customers, employees, media and the board; no external statement without legal and the incident commander signing.

5. Evidence and logging. What to preserve and where, with retention confirmed at 180 days for CERT-In and 1 year for DPDP.

6. Closure and learning. Root cause, remediation tracker, regulator follow-ups, insurance actions and a dated lessons-learned entry.

A word on Board mechanics. The exact form of the Rules notification, the Board’s portal and any acknowledgement process will be operationalised as the Board activates. Re-check them against our Data Protection Board explainer and the Act and Rules Explorer before relying on this page, and update your reporting packs when the Board publishes its formats.

RACI: who signs what during an Indian breach

Speed fails when signatures are ambiguous. Set the RACI before the incident.

Significant Data Fiduciaries must have a DPO in India under section 10, so for an SDF the Accountable role on DPDP deliverables belongs to the DPO. For everyone else, the section 8 grievance contact should sign principal notices. If you are unsure whether you are an SDF, the SDF Classifier in our tools gives a first view.

Evidence to preserve, and why the two regimes want different things

CERT-In wants indicators and attack chain. The Board wants to know what happened to personal data and how fast you acted. Preserve for both.

Technical evidence (CERT-In focus). Firewall, VPN, endpoint and identity logs for the affected window; disk and memory images taken before rebuild; malware hashes, attacker IPs and domains; NTP-synchronised timestamps.

Personal data evidence (DPDP focus). Inventory of records and fields exposed, mapped to the number of principals; access and query logs showing what was read or exported; copies of every principal notice with timestamps; Board submissions with proof of filing; the helpline log.

Decision evidence (both). A timestamped decision log recording when the incident was noticed, when each classification question was answered, who approved each report and why any report was not filed. In our experience regulators distinguish between organisations that acted imperfectly but visibly and those that cannot show what they did.

Retain all of it for at least one year under the DPDP Rules logging safeguard, and longer if litigation, insurance or a sector regulator requires.

Frequently Asked Questions

Does the CERT-In 6-hour rule apply to a small company with no security team?

Yes. The CERT-In Directions apply to all body corporates and service providers regardless of size, with no small business exemption. Designate one person with authority to send the initial report and keep the CERT-In form and contact details in the runbook. The report can be partial; the deadline cannot be missed.

If we report to CERT-In, have we satisfied the DPDP breach obligation?

No. CERT-In and the Data Protection Board are separate authorities with separate triggers and content requirements. A CERT-In report says nothing to affected individuals, who must be notified separately under section 8 and the DPDP Rules, 2025. Treat them as two filings on one timeline.

When does the DPDP 72-hour clock start?

The detailed report to the Board is due within 72 hours of the fiduciary becoming aware of the breach. In our reading awareness starts when someone in the organisation reasonably recognises a personal data breach, not when it is formally confirmed. The intimation to principals and the Board must be made without delay, which is earlier than the 72-hour report deadline.

Are DPDP breach penalties enforceable today?

Not yet. The breach notification duty becomes enforceable 18 months after the Rules were notified, i.e. May 2027. The CERT-In Directions have been enforceable since June 2022, so the 6-hour clock is live now. Build the DPDP process today so it is tested before penalties apply.

Do we notify principals before we know the full scope?

In practice, yes, once you know a group of principals is affected, even if the full list is still being built. The Rules require notification without delay, and notifying known principals first and updating as scope grows is more defensible than waiting for certainty. Record the basis for each stage in the decision log.

Related explainers

• DPDP Act vs IT Act SPDI Rules

• DPDP vs GDPR: key differences

Next step

Two clocks are manageable when the runbook, templates and RACI exist before the incident does. Download the breach runbook template, with the merged timeline, classification matrix and reporting packs, from our DPDP Starter Templates and adapt it this quarter.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

Fintechs and NBFCs already operate under a dense RBI stack: Digital Lending Guidelines, the Master Direction on KYC, the Account Aggregator framework, payment data storage rules and the outsourcing and IT governance directions. The DPDP Act, 2023 sits on top of that stack and pulls in a different direction on retention, consent artefacts, cross-border transfer and what a lending app may collect. Most substantive DPDP obligations become enforceable in May 2027, with penalties of up to Rs 250 crore for security safeguard failures. This page gives you the overlap map, a conflict table, lending app collection limits, NBFC priorities and a 90-day plan.

Why dpdp compliance fintech programmes start from the RBI stack, not the Act

Most compliance teams in regulated lenders read the DPDP Act and conclude that they already do most of it. The gap is not that RBI missed something. RBI rules were written for prudential and conduct purposes, while DPDP is written around the data principal, and the two produce different paperwork, rights and timelines for the same data.

Treat each RBI control as the baseline and ask: does it also satisfy the DPDP obligation, and if not, what is the smallest addition that closes the gap? The answer is usually a notice paragraph, a retention flag or a contract annexure, not a new system. Our Act and Rules Explorer lets you read each section alongside the Rules.

What the nbfc dpdp act overlap means for a regulated lender

An NBFC is a data fiduciary for every borrower, guarantor, co-applicant, declined applicant and employee, and usually for data received from bureaus, AA ecosystems and LSPs, because it decides purpose and means once the data lands. That makes the NBFC, not the app vendor or LSP, the entity the Data Protection Board will look at first.

First, every LSP and DLA arrangement is a fiduciary-processor relationship. DPDP requires a processor to be engaged “only under a valid contract” with the fiduciary responsible regardless, so outsourcing agreements need a DPDP annexure covering purpose limitation, sub-processor approval, breach assistance within hours, deletion on exit and audit rights. Our vendor remediation guide sets out the clause set.

Second, declined applicants. Lenders keep declined application data for fraud analysis and model retraining, but s.8 requires erasure once the purpose is served unless retention is required by law, and KYC rules say little about people who never became customers. In our reading, a written retention rule with a defined period and deletion routine is needed.

Third, Significant Data Fiduciary exposure. In our reading, large NBFCs and payment fintechs are plausible candidates once the Central Government notifies classes. SDF status brings a DPO in India, an independent data auditor and periodic DPIAs, with penalties of up to Rs 150 crore. Run the SDF Classifier now so the board has a view before designation lands.

How the digital lending guidelines dpdp overlap limits what a lending app may collect

The Digital Lending Guidelines were, in effect, India’s first data minimisation rule for apps: need-based collection, one-time access to camera, microphone or location for KYC only, and no access to files, media, contacts, call logs or telephony. DPDP sharpens the same principle through s.4 and s.6: a specified purpose, and consent that is free, specific, informed, unconditional and unambiguous.

Two DPDP rules bite harder than the RBI text. Consent must be unconditional, so a loan cannot be refused because the borrower declined an optional purpose such as marketing. And withdrawal must be as easy as giving, so a permission granted in three taps must be reversible in three taps. Our consent UX guide covers screens that satisfy both regimes.

The s.5 notice also has to be more than the app store privacy label: what is collected, for what purpose, how to exercise rights and how to complain to the Board, in plain language at first data capture.

Account aggregator consent dpdp questions: are AA consent artefacts enough?

A borrower approves an AA artefact specifying the FIP, data types, date range, fetch frequency, purpose code and expiry, and can revoke it through the AA app. It is tempting to treat that as DPDP consent. In our reading it is close but not identical, and the difference matters for the FIU, the lender using the data.

DPDP consent under s.6 must follow a s.5 notice from the fiduciary and be specific to its purpose. The artefact describes the data flow, not what the lender does afterwards. Once statement data arrives, the lender’s purposes (underwriting, fraud checks, model training, cross-sell, collections analytics) are governed by DPDP, and only the first is plausibly covered by the purpose code.

Consent manager provisions take effect 12 months from notification of the Rules, and AAs are obvious candidates to register. Until then, treat AA consent as strong evidence for the flow and keep your own consent record for everything you do next.

Fintech data localisation india: payment data, cloud regions and Section 16

Section 16 permits transfer of personal data outside India except to countries the Central Government restricts by notification. That is permissive on its own, but it does not dilute stricter sectoral rules, and three survive DPDP untouched: the RBI payment data storage requirements, the CERT-In Directions of 28 April 2022 (logs kept 180 days within India) and the RBI outsourcing directions on offshore arrangements.

The conflict is rarely the primary database. It is the periphery: analytics warehouses in a US region, support tooling abroad, a fraud vendor’s model endpoint and crash reporting SDKs that ship device data overseas by default. Each is a s.16 transfer DPDP permits, but if the payload contains payment system data or falls within RBI outsourcing scope, the RBI rule controls.

The defensible position is a single transfer register: every dataset leaving India, the recipient, the country, the DPDP basis, the applicable RBI rule and the contractual safeguard. Our Section 16 cross-border explainer covers the register format.

Conflict table: where RBI rules and DPDP pull apart

A fifth conflict is timelines: CERT-In wants incident reports within six hours, the DPDP Rules want notice without delay with a 72-hour report, and RBI has its own reporting. One runbook with three notification tracks is the only workable answer; our 72-hour breach response guide sets out the sequencing.

NBFC-specific priorities before May 2027

Security safeguards with evidence. Up to Rs 250 crore. The Rules name encryption, access control, one-year log retention, backups and processor contracts. Most NBFCs have the controls; fewer have the evidence packaged by system.

Breach notification readiness. Up to Rs 200 crore. The obligation covers every breach and the clock runs from awareness. Test the runbook with LSPs and cloud providers in the room.

Consent and notice re-papering. Every live journey (app onboarding, AA flow, web, DSA-assisted, collections) needs a s.5 notice and a consent record producible per customer. This has the longest lead time.

Rights handling. Requests need a published response period (maximum 90 days under the Rules) and a workflow that knows which records are KYC-retained. See Your DPDP Rights.

Vendor re-papering. Prioritise LSPs, DLAs, collection agencies, cloud and SaaS by whether they hold payment or KYC data. Starter clauses are in our DPDP Starter Templates.

Indicative effort for a mid-sized NBFC is 4 to 8 months and Rs 40 lakh to Rs 1.5 crore of combined cost, depending on the number of apps and LSP relationships.

A 90-day plan for fintech and NBFC teams

Days 1 to 30: map and decide. Build the data inventory by product and system, including every LSP, DLA and AA integration. Produce the overlap map and conflict table with written positions. Run the SDF Classifier and table the results with the board. Share DPDP 101 with product and engineering leads so the vocabulary is common.

Days 31 to 60: re-paper and re-engineer. Redraft notices and consent screens per journey with optional purposes defaulted off. Strip app permissions to the table above. Issue DPDP annexures to the top 20 vendors by data risk. Define retention classes with deletion routines.

Days 61 to 90: prove it. Run the breach tabletop with three notification tracks. Test a rights request that touches KYC-retained data. Build the transfer register and check every overseas SDK and SaaS flow against it. Package security evidence per system.

Frequently Asked Questions

Does complying with the RBI Digital Lending Guidelines make a lending app DPDP compliant?

Not on its own. The guidelines cover collection limits and borrower consent, but DPDP adds a formal s.5 notice, a consent standard that includes unconditionality and easy withdrawal, rights with published timelines, breach notification to the Board and processor contracts. In our reading a guideline-compliant app is roughly two-thirds of the way there.

How can an NBFC honour an erasure request when RBI KYC rules require five-year retention?

Retention required by law is recognised under the DPDP Act, so KYC and transaction records within the mandated period can be retained and the borrower told why. The request must still be honoured for everything outside that requirement, such as marketing profiles and behavioural data. Document the record classes and their legal basis so the response is consistent.

Is Account Aggregator consent the same as DPDP consent?

They overlap but are not identical. The AA artefact authorises a specific data fetch, while DPDP consent must follow the lender’s own notice and cover every purpose pursued after the data arrives. Treat the artefact as strong evidence for the flow and keep your own consent record for underwriting, fraud, analytics and any secondary use.

Does Section 16 of the DPDP Act relax RBI data localisation for payment data?

No. Section 16 permits transfers except to restricted countries, but stricter protections under other laws continue to apply, including the RBI payment data storage requirements and outsourcing directions. Payment system data stays in India; other personal data may move under s.16 with a documented basis and processor contract.

Related explainers

• Significant Data Fiduciary (SDF) explained

• what is a Consent Manager under the DPDP Act

Next step

If you run an NBFC, a lending app or a payment platform and want the RBI-to-DPDP overlap map, conflict positions and 90-day plan built for your own products, our sector Readiness Sprint does exactly that in a fixed scope. Book a scoping conversation through our services page.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

Almost nobody publishes what DPDP compliance actually costs, so boards are budgeting blind. Based on our engagement experience, an indicative one-time programme runs Rs 8 to 25 lakh for a startup or SME, Rs 30 lakh to 1.2 crore for a mid-market company, and Rs 1.5 to 6 crore or more for an enterprise or Significant Data Fiduciary, with ongoing costs of roughly 20 to 40 percent of that figure each year. The biggest cost drivers are vendor count, legacy data, multi-sector regulation and consumer scale, not company headcount. Against penalty caps of up to Rs 250 crore per category, the case for budgeting now, ahead of the May 2027 enforcement date, is straightforward.

How much does DPDP compliance cost: the short answer by company size

Every figure on this page is an indicative range and represents Aizzentec’s estimate from readiness work with Indian companies: a starting point for a budget conversation, not a quote. We split the total into one-time programme cost, tooling and licences, and ongoing operating cost.

The SME band is wide because a 40-person B2B SaaS firm and a 150-person D2C brand with a loyalty app are very different jobs. The enterprise figure is dominated by remediation, not advisory fees. SDF status under s.10 adds a mandatory DPO in India, an independent data auditor and periodic DPIAs to the bill.

DPDP implementation budget: what the one-time programme actually includes

Most of the money goes here in the first 12 to 18 months. Percentages are of total one-time cost.

Assessment and data mapping (15 to 25 percent)

Discovery: what personal data you hold, where it sits, which lawful basis under s.4 to s.7 applies, and who you share it with. Two to four weeks for an SME; a quarter for an enterprise with 30 or more systems. Skipping it is the most common false economy we see. Our DPDP 101 explainer covers the concepts your team needs first.

Policies, notices and governance documents (10 to 15 percent)

Section 5 notices for each collection point, a privacy policy that matches actual processing, retention schedules, a breach runbook aligned to the 72-hour reporting requirement in the Rules, and grievance procedures under s.8 and s.13. Templates bring this down sharply; the 16 DPDP Starter Templates exist because most companies under 200 staff do not need bespoke drafting for every document.

Consent tooling and UX changes (15 to 30 percent)

Section 6 requires consent that is free, specific, informed, unconditional and unambiguous, with withdrawal as easy as giving it. That means engineering time: rebuilding sign-up flows, granular consent records, a withdrawal path and, for under-18 users, verifiable parental consent under s.9. For a consumer app this is the largest single line. For a B2B company relying largely on s.7 legitimate uses it is much smaller.

Vendor and processor remediation (15 to 25 percent)

A processor may be engaged only under a valid contract and the fiduciary remains responsible regardless. Every vendor with personal data access needs a contract review, a processing addendum and, for material ones, a security assessment. Cost scales almost linearly with vendor count. Our vendor remediation guidance sets out a tiering approach that keeps this proportionate.

Security safeguards uplift (10 to 25 percent)

The Rules list encryption, access control, logging and monitoring with logs retained at least one year, backups and contractual measures with processors. Companies already aligned to CERT-In’s 180-day log retention direction spend little here. Companies without central logging spend a lot, and this is where budgets most often overrun.

Training and change management (5 to 10 percent)

Role-based training for HR, marketing, engineering, support and leadership. Cheap relative to the rest, and the layer that most reduces the likelihood of a reportable incident.

DPDP consultant fees India: what advisors, auditors and vDPOs charge

Consultant fees are what clients ask about first and, for most companies, the smallest part of the total. Indicative ranges we observe:

A partner-led boutique typically charges 40 to 60 percent less than a Big Four firm for equivalent scope; freelancers charge less again but rarely cover security and legal drafting together. Ask any advisor what will still be true about your programme after they leave. Documentation you can defend before the Data Protection Board is the deliverable; certification theatre is not.

What inflates a DPDP implementation budget: the real cost drivers

Headcount is a weak predictor of cost. These four factors are much stronger. Cross-border transfers under s.16 are a lighter driver, since transfers are permitted except to restricted countries, but offshore vendors still need mapping; see our Section 16 cross-border explainer.

Vendor and processor count

A company with 12 processors can remediate in a month. A company with 300 needs a tiered programme and a contract factory. Each additional material vendor adds an indicative Rs 25,000 to 1 lakh in review, negotiation and assessment effort, more if the vendor pushes back on liability terms.

Legacy data

Section 8 requires erasure when the purpose is served, and the Rules impose a three-year inactivity erasure rule with 48 hours notice on specified large e-commerce, gaming and social media fiduciaries. Old CRM records and spreadsheets on shared drives need discovery, classification and defensible deletion. Legacy data can double the cost of an otherwise simple programme.

Multiple regulated sectors

A fintech that also distributes insurance must reconcile DPDP with the RBI Digital Lending Guidelines, the RBI Master Direction on KYC and IRDAI information and cyber security guidelines. Budget 20 to 40 percent extra per additional regulated sector.

Consumer scale and children’s data

Scale drives consent engineering, DSAR volumes and breach notification complexity: notifying 50 lakh users “without delay” under the Rules is an operational problem. Under-18 data adds verifiable parental consent and the s.9 ban on tracking and targeted advertising, with a Rs 200 crore penalty cap.

Build vs buy vs advisor: three ways to fund the programme

Most companies land on a hybrid: an advisor runs assessment and design, an internal owner carries execution, and tooling is bought only where volume justifies it. A common mistake is buying a consent platform before the data map exists. Sequence the spend: assess, decide, then tool.

Rule of thumb for companies under 200 staff: fewer than 20 vendors, no children’s data and a single sector means templates plus a short readiness sprint will get you to defensible. If any condition fails, budget for the mid-market band regardless of headcount.

DPDP audit cost and other ongoing costs after go-live

Once the programme closes, three recurring lines remain.

Virtual or in-house DPO. SDFs must appoint a DPO based in India under s.10. Everyone else needs a named owner for grievances under s.8. A vDPO retainer at Rs 1.5 to 4 lakh per month is the common mid-market answer; an in-house senior privacy hire is Rs 25 to 60 lakh per year fully loaded.

Annual audit. Mandatory independent data auditor for SDFs. For others, an annual review is the evidence you will want if the Board asks. Indicative: Rs 3 to 8 lakh for an SME review, Rs 10 to 50 lakh for an SDF-grade audit.

DPIA and reassessment. SDFs must run periodic DPIAs. Non-SDFs should run one for each new product, vendor or data use. Budget two to four per year for an active product company.

Add tooling renewals, refresher training and handling of rights requests under s.11 to s.14 within your published timeline (maximum 90 days under the Rules); our DSAR workflow guide helps size that. Planning ratio: ongoing cost runs at 20 to 40 percent of the one-time programme cost per year.

ROI framing: budget against penalty exposure, not against zero

Justify this spend against the exposure you already carry. The Schedule sets caps of up to Rs 250 crore for failure of security safeguards, Rs 200 crore for breach notification failures and for children’s obligations, Rs 150 crore for SDF obligations and Rs 50 crore for other breaches. In our reading the Board will calibrate to the nature, gravity and duration of the breach, but even a small fraction of Rs 250 crore dwarfs a Rs 50 lakh programme.

Consider a mid-market D2C company with 30 lakh customers, 80 vendors and no central logging, with an indicative programme cost of Rs 60 to 80 lakh. A security safeguards failure with a late notification spans two penalty categories with a combined cap of Rs 450 crore. At even 1 percent of the cap, the penalty is Rs 4.5 crore, roughly six times the programme cost, before churn and incident response. The Penalty Exposure Estimator runs this arithmetic against your own profile and produces a figure you can put in front of a board next to the budget.

Timing matters too. Substantive obligations become enforceable in May 2027. Starting in the second half of 2026 spreads cost over two financial years; starting in early 2027 means rush premiums.

A DPDP budget template you can adapt

Copy this into your planning sheet and fill it in after a readiness assessment.

Tie every line to a named owner, and keep the contingency: the assessment nearly always uncovers systems and vendors nobody listed at the start.

Frequently Asked Questions

What is the minimum a small company should budget for DPDP compliance?

For a company under 200 staff in a single sector with a modest vendor list, an indicative floor is around Rs 8 lakh for the one-time programme plus Rs 4 to 6 lakh per year ongoing. That assumes template-based documents, a short readiness assessment and existing basic security hygiene. Children’s data, consumer scale or a large vendor list pushes the figure into the mid-market band.

Do we need a DPO, and what does one cost?

A DPO based in India is mandatory only if you are notified as a Significant Data Fiduciary under s.10. Every fiduciary, however, must publish a contact for grievances and data principal requests under s.8. A virtual DPO retainer typically runs Rs 1.5 to 4 lakh per month on an indicative basis, while an in-house senior privacy hire is Rs 25 to 60 lakh per year fully loaded.

How does DPDP audit cost differ between SDFs and everyone else?

SDFs must engage an independent data auditor and run periodic DPIAs, which on an indicative basis costs Rs 10 to 50 lakh per year for the audit and Rs 3 to 12 lakh per DPIA. Non-SDFs have no statutory audit requirement, but an annual review at Rs 3 to 8 lakh for an SME is the evidence you will want if the Board asks how you demonstrate compliance.

Is it cheaper to wait until closer to May 2027?

No. Starting in the second half of 2026 lets you spread spend across two financial years, remediate vendors during normal renewal cycles and avoid rush premiums on advisory and engineering. Companies that start in early 2027 compete for the same limited pool of practitioners and pay more for less time.

Related explainers

• Significant Data Fiduciary (SDF) explained

• DPDP vs GDPR: key differences

Next step

Before you take a number to the board, put your own exposure next to it. Run the Penalty Exposure Estimator with your data volumes, vendor count and sector profile, and you will have both sides of the ROI case on one page.