DPDP for the Data and analytics head in Central government

Use Aadhaar only where a law or notification allows it, store the number only in an Aadhaar Data Vault, show it masked on screens and in reports, and never publish it. Core biometric information must never be shared. Authentication devices at the field level need vendor and operator controls.

Aadhaar Act Sections 7 and 29 and UIDAI rules, with DPDP Section 8(5). Section 8(5) · Rule 6 · Section 7

1. Find every place Aadhaar numbers are stored.
2. Move them to a vault with reference keys.
3. Mask on screens, reports and files.
4. Check PoS and field device vendors.
5. Log access to the vault.

• Vault design
• Masking evidence
• Access logs

• Aadhaar in spreadsheets
• Full numbers on dashboards
• Field operators keeping copies

Yes, where the scheme or a law needs it, through a written MoU or order that sets the purpose, the fields, security and retention. Share the minimum, through logged channels, and record each transfer. Bulk sharing with private parties needs a clear legal basis and should mask personal details where possible.

Section 7 bases, Section 8(1) for processors, Section 8(5) for safeguards. Section 7 · Section 8(1)–(2) · Section 8(5) · Rule 6

1. List every outgoing data flow.
2. Write an MoU or order for each.
3. Cut fields to the minimum.
4. Use logged channels.
5. Review flows yearly.

• Flow register
• MoUs
• Transfer logs

• Email attachments
• Full data when counts would do
• No MoU

Yes, where the use fits the purpose people were told, or you have consent for it. Improving the service people signed up for usually fits. Selling insights, profiling for third parties or targeting children does not. Mask or aggregate wherever the question allows, and give analysis copies their own deletion date.

Section 4 needs a lawful basis for each purpose. Section 6 needs specific consent. Section 9 bars behavioural monitoring of children. Section 8(3) asks for accuracy when data drives decisions. Section 4 · Section 6 · Section 9 · Rules 10, 12 · Section 8(3)

1. Write the question and the data needed.
2. Check the purpose people were told.
3. Mask or aggregate by default.
4. Get consent for uses outside the purpose.
5. Set a deletion date for the copy.

• Purpose checks
• Data specifications
• Retention entries

• Using all data because it is there
• Analysis copies with no end date
• Profiling children

For every use of personal data you need one basis: consent, or one of the legitimate uses in Section 7, such as a legal duty, employment, a medical emergency, or data a person gave voluntarily for a specific purpose. Anything beyond what the person expects, such as marketing, profiling or sharing with partners, usually needs consent.

Most scheme work rests on Section 7(b) or 7(c). Surveys, publicity and newsletters need consent.

Section 4 allows processing only with consent or for a legitimate use. Section 6 sets what valid consent looks like. Section 7 lists the uses that need no consent. Section 4 · Section 6 · Section 7

1. List each purpose for which you use personal data.
2. Against each purpose, write the basis: consent or the exact clause of Section 7.
3. Where the basis is consent, check that it was asked separately, with a clear action and no pre-ticked box.
4. Stop or re-paper any purpose with no basis.
5. Review the list whenever a new product, campaign or system starts.

• Purpose and basis register
• Consent records with date, version and channel
• Legal sign-off on each legitimate use relied on

• Treating account terms as consent for marketing
• Bundling several purposes in one tick-box
• Relying on 'legitimate interest', which the Indian Act does not have

Ask four questions at the design stage: what personal data, why, for how long, and who sees it. Then build in what the Act assumes: a notice, consent where needed, role-based access, logs of record views, a way to delete, and a way to answer requests. Adding these after launch costs far more.

Sections 5 to 12 assume systems that can show notices, record consent, limit access, log, delete and answer requests. Section 5 · Rule 3 · Section 6 · Section 8(5) · Rule 6 · Section 8(7) · Rule 8 · Sections 11–14 · Rule 14

1. Add the four questions to design templates.
2. Drop data you do not need.
3. Build access roles and record-view logs.
4. Build deletion and request export.
5. Register the system in the inventory at launch.

• Design review records
• Inventory entries
• Deletion tests

• Privacy review only at launch
• Collecting 'in case we need it'
• No delete function

By law, only Significant Data Fiduciaries must do a yearly impact assessment. For everyone else it is good practice for high-risk changes: new tracking, profiling, large data sharing, children's data or moving data abroad. A short assessment before the change is cheaper than fixing it later.

Section 10 and Rule 13 require a yearly impact assessment for Significant Data Fiduciaries. Section 10 · Rule 13 · Section 9 · Rules 10, 12 · Section 16 · Rule 15

1. Define what counts as a high-risk change for you.
2. Use a two-page template.
3. Record the data, purpose, risks and safeguards.
4. Get the DPO's view before approval.
5. Keep it with the project record.

• Assessment template
• Completed assessments
• DPO views

• Treating it as paperwork after launch
• A 40-page template nobody completes
• No trigger list

Anyone under 18 is a child under the Act. For a child's data you need verifiable consent from a parent or lawful guardian, and you must not track, behaviourally monitor or show targeted ads to children. Some classes and purposes are exempt under Rule 12 and the Fourth Schedule, for example healthcare to the extent needed to protect the child's health, and educational institutions for their educational work.

Scholarship, nutrition and school schemes involve children; Fourth Schedule exemptions may apply to some purposes.

Section 9 sets the duties. Rule 10 explains how to verify the parent. Rule 12 and the Fourth Schedule list the exemptions. Section 9 · Rules 10, 12 · Section 6

1. Find where children's data enters: customers, dependants, interns, visitors, scholarships, app sign-ups.
2. Decide whether an exemption in the Fourth Schedule applies to that purpose.
3. Where none applies, add an age question and a parent-consent step.
4. Switch off tracking and targeted ads for under-18 users.
5. Record the decision for each channel.

• Channel-by-channel note on children's data
• Parent-consent records
• Ad and tracking settings

• Assuming 'we are B2B, so no children'
• Using the age 13 or 16 from foreign laws
• Treating a tick-box from the child as parental consent

Keep data for as long as its purpose needs, or as long as a law requires, and then erase it. Every organisation must keep personal data and logs for at least one year under Rule 8(3). Write a retention schedule by record type, with the law or reason against each period.

Record retention schedules under public records rules decide periods.

Section 8(7) asks for erasure when the purpose is over, unless a law requires retention. Rule 8(3) sets a one-year minimum for personal data, traffic data and logs. Section 8(7) · Rule 8 · Section 8(5) · Rule 6

1. List the record types you hold.
2. Write the period for each, with the law, regulator rule or business reason.
3. Set a trigger for the period to start: end of relationship, date of transaction, exit date.
4. Automate deletion where you can; for paper, schedule shredding.
5. Keep a deletion log.

• Retention schedule approved by Legal
• Deletion log
• Shredding or disposal certificates

• 'Keep everything forever' because storage is cheap
• Deleting before the legal minimum
• Forgetting email, shared drives and backups

Usually in more places than anyone expects: core systems, email, shared drives, laptops, vendor systems, backups, test copies, spreadsheets and paper. A simple inventory, one row per system, is the base for every other duty.

Start from the scheme list and the systems behind each.

Every duty in Sections 5 to 12 assumes you know where the data is. Rule 6 needs safeguards for each system, and Section 11 needs you to find the data when someone asks. Section 8(5) · Rule 6 · Sections 11–14 · Rule 14 · Section 8(7) · Rule 8 · Section 3

1. List systems, then shared drives, email, spreadsheets and paper stores.
2. For each one, note whose data, which items, purpose, owner, hosting location and vendors.
3. Add copies: backups, test, analytics.
4. Get each owner to confirm their rows.
5. Update it whenever a system is bought or retired.

• Data inventory
• Owner confirmations
• Change log

• A 200-column spreadsheet nobody finishes
• Leaving out SaaS tools bought by departments
• No owner for each row

You stay responsible for what your vendors do with personal data. The contract should say what data they get, for what purpose, the security they must keep, how fast they must tell you about an incident, that sub-contractors need your approval, and how data is returned or deleted at the end.

System integrators, NIC, state agencies and field operators process data for the department.

Section 8(1) keeps responsibility with you. Section 8(2) allows a processor only under a valid contract. Rule 6 asks for security terms in that contract. Section 8(1)–(2) · Section 8(5) · Rule 6 · Section 8(6) · Rule 7 · Section 8(7) · Rule 8

1. List vendors who receive or can see personal data.
2. Rank them by how much and how sensitive.
3. Add a data-protection schedule to each contract, starting with the top ten.
4. Ask for evidence: certificates, test results, deletion confirmations.
5. Review the top vendors every year.

• Vendor register
• Signed data-protection schedules
• Annual review notes

• Relying on the vendor's standard terms
• No incident-notice time
• No exit and deletion clause