DPDP for the Scheme or programme head in Central government

Usually not. Section 7(b) allows the State to process personal data to give a subsidy, benefit, service, certificate, licence or permit, and Section 7(c) covers functions under law. Rule 5 then asks that this processing meet the Second Schedule standards. Consent is still needed for uses outside these, such as publicity stories or surveys not tied to the scheme.

Section 7(b) and 7(c) set the bases. Rule 5 and the Second Schedule set the standards. Section 7 · Section 4

1. Write the basis for each scheme: 7(b), 7(c) or consent.
2. Check each scheme against the Second Schedule standards.
3. Remove fields not needed for the benefit.
4. Publish a contact for questions and rights.
5. Take consent for extra uses.

• Basis register
• Standards check
• Published contact

• Taking 'consent' that citizens cannot refuse
• Collecting extra fields 'for analysis'
• No contact for questions

• What do the Second Schedule standards ask of a scheme?
• Must a ministry delete data when a citizen asks?
• What should our privacy notice say, and where must people see it?

Process lawfully and only for the scheme's purpose, collect only the data needed, keep it accurate, keep it only as long as needed or required by law, protect it with reasonable safeguards, give people a contact for questions and rights, and be accountable for meeting these standards.

Rule 5 and the Second Schedule apply to State processing under Section 7(b). Section 7 · Section 8(5) · Rule 6 · Section 8(3)

1. Field review: needed or not.
2. Accuracy: how errors are corrected.
3. Retention: which schedule applies.
4. Security: who can access.
5. Contact: published on the portal.
6. Accountability: a named officer.

• Standards checklist per scheme
• Correction process
• Retention schedule

• Treating standards as a formality
• No correction route
• No named officer

• Do we need citizens' consent to run a scheme?
• Who should be able to see personal data in our systems?
• How long can we keep personal data?

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

• Who should be able to see personal data in our systems?
• What must a vendor contract say about personal data?
• What do the Second Schedule standards ask of a scheme?

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

• What must a vendor contract say about personal data?
• What do the Second Schedule standards ask of a scheme?
• How should scheme systems handle Aadhaar numbers?

Sending personal data to the wrong chat or a personal account is one of the most common breaches. Banning messaging rarely works. Give staff an approved tool that is easy to use, set simple rules, and make it safe to report a wrong send at once.

Government email and e-Office are the approved routes; WhatsApp groups are not.

Section 8(5) asks for reasonable safeguards. A wrong send is a breach under Section 2(u), and Section 8(6) applies. Section 8(5) · Rule 6 · Section 8(6) · Rule 7

1. Ask teams how they actually share files and photos today.
2. Provide an approved tool for that job.
3. Set three simple rules: approved tool, no personal accounts, report wrong sends.
4. Teach the rules with real examples from your own work.
5. Treat a quick report as good behaviour, not a disciplinary case.

• Approved-tool policy
• Training record
• Incident reports of wrong sends

• A ban with no alternative
• Punishing people who report
• Ignoring group chats with vendors

• Something has gone wrong. What happens in the first 72 hours?
• Who needs DPDP training, and what should it cover?
• Who should be able to see personal data in our systems?

Send a summary of the personal data you hold about them and what you do with it, and the names of the other organisations you shared it with and what was shared. Check the person's identity first, log the request and keep a copy of your reply.

A beneficiary can ask what the department holds and who it was shared with, such as states and banks.

Section 11 gives the right to a summary and the list of organisations it was shared with. Rule 14 asks you to publish how requests are made and to answer within the period you publish. Sections 11–14 · Rule 14 · Section 8(9)–(10) · Rules 9, 14

1. Log the request in one register the day it arrives.
2. Verify identity using details you already hold.
3. Search every system, including vendors' copies.
4. Write a plain summary: what data, why it is used, who received it.
5. Send it, and file the request, search notes and reply.

• Request register
• Search notes for each request
• Copy of each reply with date

• Sending raw database dumps
• Forgetting data held by vendors
• No identity check before sending

• How do we handle a privacy complaint within 90 days?
• Someone asks us to delete their data. Must we?
• Where does personal data live in our organisation?

Contain it, then tell people. A reportable cyber incident goes to CERT-In within six hours of being noticed. Under DPDP, each affected person and the Data Protection Board must be told without delay, and the Board needs a detailed report within 72 hours. Sector regulators may have their own clock too.

A leaked beneficiary list is a breach; CERT-In and the Data Protection Board both need to hear.

Section 8(6) and Rule 7 set the DPDP steps. The CERT-In Directions of 28 April 2022 set the six-hour report. A breach includes accidental disclosure and loss of access, not only hacking. Section 8(6) · Rule 7 · Section 8(5) · Rule 6

1. Name one incident lead and a back-up, with phone numbers that work at night.
2. Write the first-hour steps: isolate, preserve logs, tell the DPO and the incident lead.
3. Keep ready-made drafts for CERT-In, the regulator, the Board and affected people.
4. Decide in advance who signs off each message.
5. Rehearse once a year with the people who would actually be called.

• Incident plan with clocks
• Rehearsal record
• Incident log with times of each step

• Waiting to finish the investigation before telling anyone
• Treating a wrong email or a lost laptop as 'not a breach'
• Only IT knowing the plan

• Which logs must we keep, for how long, and where?
• What must a vendor contract say about personal data?
• Does deletion have to reach backups and test copies?

Everyone who handles personal data needs short, practical training on what to do in their own job. Front-line staff need examples from their counter or desk. Managers need to know the clocks and their own duties. Management needs to know what to ask.

Short sessions for section staff on files, e-Office and chat apps.

Section 8(4) and 8(5) ask for appropriate technical and organisational measures. Training is part of showing those measures work. Section 8(5) · Rule 6

1. Group staff by what they handle: front line, back office, IT, managers, management.
2. Write three to five real scenarios for each group.
3. Keep sessions short: 20 to 30 minutes.
4. Test with a few questions, and record attendance.
5. Repeat every year, and at joining.

• Training plan by group
• Attendance and test results
• Scenario material

• One long legal lecture for all
• Training once and never again
• No record of attendance

• Staff share personal data on WhatsApp and personal email. What do we do?
• Something has gone wrong. What happens in the first 72 hours?
• Someone asks what data we hold about them. What do we send?

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

• What should our privacy notice say, and where must people see it?
• Someone withdraws consent. What has to stop, and how fast?
• Can we send offers to past customers and leads?

All three are personal data. Put a clear notice where people are recorded, collect only what you need at reception, keep footage and registers for a set period, and protect biometric templates carefully. Do not keep copies of ID documents unless you must.

Office CCTV and visitor passes need notices and limits.

Section 5 needs notice. Section 8(5) needs safeguards. Section 8(7) needs erasure after the purpose. For staff, Section 7(i) can cover security and attendance. Section 5 · Rule 3 · Section 8(5) · Rule 6 · Section 8(7) · Rule 8 · Section 7

1. Put notices at CCTV points and reception, in the local language.
2. Ask visitors only for name, phone and whom they are meeting, unless security needs more.
3. Set a period for footage and registers, then delete.
4. Restrict who can view footage, and log viewing.
5. Check the vendor contracts for CCTV, guards and attendance systems.

• Notices in place
• Retention settings on the recorder
• Viewing log

• Photocopying visitor IDs as routine
• Footage kept until the disk fills
• Biometric systems with vendor default passwords

• Are contract and agency workers our responsibility?
• How long can we keep personal data?
• What must a vendor contract say about personal data?