नए product या system में privacy शुरू से कैसे डालें?
Reviewed by InfraVeritas360 ResearchFirst published Last reviewed
Sources: DPDP Act, 2023 and DPDP Rules, 2025 (MeitY)
यह translated guidance है, legal advice नहीं। Legal terms उनके English नाम के साथ दिए गए हैं। कोई शक हो तो English version और Act का official text ही मान्य है। यह पेज अंग्रेज़ी में पढ़ें
छोटा जवाब: Design पर चार सवाल, फिर basics अंदर build कीजिए
Design stage पर चार सवाल पूछिए: कौन-सा personal data, क्यों, कितने समय के लिए, और कौन देखेगा। फिर वह सब build कीजिए जो Act मानकर चलता है: notice, जहाँ ज़रूरी हो वहाँ consent, role-based access, record देखने के logs, delete करने का तरीका, और requests का जवाब देने का तरीका। Launch के बाद यह जोड़ना कहीं ज़्यादा महँगा पड़ता है।
कानून क्या कहता है
Sections 5 से 12 ऐसे systems मानकर चलते हैं जो notice दिखा सकें, consent record कर सकें, access सीमित कर सकें, log कर सकें, delete कर सकें और requests का जवाब दे सकें।
- Section 5 · Rule 3: Notice — consent माँगने से पहले साफ़ जानकारी. Consent माँगते समय एक साफ़ notice दें, जो अपने आप में पूरा हो। उसमें बताएँ: कौन-सा data, किस purpose के लिए, consent कैसे withdraw करें, rights कैसे इस्तेमाल करें, और Data Protection Board को complaint कैसे करें। Act से पहले लिए गए data के लिए भी notice देना है, जितनी जल्दी reasonably practicable हो।
- Section 6: Consent — साफ़ और अपनी मर्ज़ी से दी गई हाँ. Consent free, specific, informed, unconditional और unambiguous होना चाहिए। यह किसी clear action से दिया जाए और purpose के लिए ज़रूरी data तक ही सीमित रहे। Consent withdraw करना उतना ही आसान हो, जितना देना था।
- Section 8(5) · Rule 6: Reasonable security safeguards — data को सुरक्षित रखना. Personal data को reasonable security safeguards से सुरक्षित रखें। Rule 6 में minimum बताया गया है: encryption, masking या tokenisation; access control; logs और monitoring; continuity के लिए backups; logs कम से कम एक साल रखना; और processors के contracts में security terms।
- Section 8(7) · Rule 8: Erasure and retention — data कब delete करना है. Purpose पूरा होने पर या consent withdraw होने पर personal data delete करें, जब तक कोई कानून उसे रखने को न कहे। अपने processors से भी delete करवाएँ। Rule 8(3) के तहत हर Data Fiduciary को Rules में दिए purposes के लिए personal data, traffic data और logs कम से कम एक साल रखने हैं।
- Sections 11–14 · Rule 14: Rights of Data Principal — लोगों के rights. लोग अपने data का summary माँग सकते हैं, और यह भी कि data किसके साथ share हुआ। वे correction, completion, updating या erasure माँग सकते हैं, complaint कर सकते हैं, और अपनी जगह काम करने के लिए किसी को nominate कर सकते हैं। यह सब कैसे करना है, आपको publish करना होगा।
Steps
- चारों सवाल design templates में जोड़िए।
- जो data ज़रूरी नहीं, उसे हटाइए।
- Access roles और record-view logs build कीजिए।
- Deletion और request export build कीजिए।
- Launch पर system को inventory में register कीजिए।
कौन-सा evidence रखना है
- Design review records
- Inventory entries
- Deletion tests
आम गलतियाँ
- Privacy review सिर्फ़ launch पर
- 'शायद काम आए' सोचकर data लेना
- कोई delete function नहीं
किसकी क्या ज़िम्मेदारी
- CTO / Engineering Head: Privacy के सवाल design review का हिस्सा बनाएँ, आखिर में sign-off नहीं।
- Data और Analytics Head: जहाँ सवाल allow करे, वहाँ masked या aggregated data से काम करें।
- Product Head: हर feature brief में चार सवाल जोड़ें: कौन-सा data, क्यों, कितने समय, कौन देखेगा।
- Data और analytics department: Default में mask और aggregate करें।
- Software engineering department: चारों सवाल design review में शामिल करें।
उदाहरण (अंग्रेज़ी में)
A bank's new app feature would collect location all the time. Design review asks why; location is needed only at KYC. The permission is limited to that step before build.
Management का अच्छा जवाब कैसा होता है
“हर design review में चारों सवालों के जवाब होते हैं, और नए systems access roles, logs और deletion के साथ launch होते हैं।” Effort और समय: हल्का · हर project के लिए.
अपनी भूमिका के लिए पूरा पेज खोलें →