नवीन product किंवा system मध्ये privacy कशी build करायची?
Reviewed by InfraVeritas360 ResearchFirst published Last reviewed
Sources: DPDP Act, 2023 and DPDP Rules, 2025 (MeitY)
भाषांतरित मार्गदर्शन, legal advice नाही. Legal terms त्यांच्या English नावानेच दिले आहेत. शंका असल्यास English version आणि Act चा official text ग्राह्य धरा. हे पान इंग्रजीत वाचा
थोडक्यात उत्तर: Design वेळी चार प्रश्न, मग basics आतच build करा
Design stage लाच चार प्रश्न विचारा: कोणता personal data, का, किती काळ, आणि तो कोण पाहतो. मग Act जे गृहीत धरतो ते build करा: notice, गरज असेल तिथे consent, role-based access, records कोणी पाहिले याचे logs, delete करण्याची सोय, आणि requests ना उत्तर देण्याची सोय. Launch नंतर हे जोडणे खूप महाग पडते.
कायदा काय सांगतो
Sections 5 ते 12 असे गृहीत धरतात की systems notices दाखवू शकतात, 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 साठी, reasonably practicable होईल तितक्या लवकर notice द्यायची आहे.
- Section 6: Consent — वैध consent कसा असावा. Consent free, specific, informed, unconditional आणि unambiguous असावा. तो clear action ने दिलेला असावा. Purpose साठी आवश्यक तेवढ्याच data पुरता मर्यादित असावा. तो देणे जितके सोपे, तितकेच withdraw करणेही सोपे असावे.
- Section 8(5) · Rule 6: Reasonable security safeguards — data सुरक्षित ठेवणे. Personal data reasonable security safeguards ने सुरक्षित ठेवा. Rule 6 किमान गोष्टी सांगतो: 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 — लोकांचे हक्क. लोक त्यांच्या data चा summary आणि तो कोणासोबत 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 मध्ये नोंदवा.
ठेवायचा evidence
- Design review records
- Inventory entries
- Deletion चे test results
नेहमीच्या चुका
- Privacy review फक्त launch वेळी
- 'कधी लागेल म्हणून' data घेऊन ठेवणे
- Delete function नाही
कोणाची काय जबाबदारी
- CTO / Engineering Head: Privacy चे प्रश्न design review चा भाग करा, शेवटची sign-off म्हणून नाही.
- Data & Analytics Head: प्रश्नाला चालत असेल तिथे masked किंवा aggregated data वर काम करा.
- Product Head: प्रत्येक feature brief मध्ये चार प्रश्न जोडा: कोणता data, का, किती काळ, कोणाला दिसतो.
- Data आणि analytics विभाग: By default mask आणि aggregate करा.
- Software engineering विभाग: ते चार प्रश्न 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 होतात.” मेहनत आणि वेळ: प्रत्येक project साठी कमी.
तुमच्या भूमिकेसाठी पूर्ण पान उघडा →