PSUs serve citizens as customers at very large scale: LPG and fuel consumers, electricity and water connections, passengers, and people living in townships. Many PSUs are treated as 'the State' under Article 12 of the Constitution, which the DPDP Act uses for its own definition. Whether the State provisions apply to a given activity needs legal advice; for commercial, customer-facing work, most PSUs plan as a normal Data Fiduciary with full duties.
The first four things to sort out
Data terms in tenders.
Hosting in India.
Incident hours.
Exit.
A worked example: GeM tender for billing system
Week 1Data terms added.
Week 2Hosting in India.
Week 3Incident hours.
AfterAwarded.
Evidence kept: Tender.
Put it in the tender.
What others in the sector usually do. Tender clauses.
Distributor registers and delivery slips with addresses; Subsidy and Aadhaar data in distributor software; Consumer numbers shared with marketing partners
Short answer: Yes, you are responsible for what they do with your consumers' data
When distributors, dealers or franchisees handle consumer data for your service, they act for you, and you are responsible. Give them only what they need, add a data clause to agreements, train them, and check a sample every year. If a partner uses data for its own business, such as selling insurance, that is outside your purpose and must stop.
From your seat: Procurement department. Put the clause in every agreement.
Short answer: Yes, every vendor that touches personal data
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.
From your seat: Procurement department. Add the data-protection schedule to every purchase that involves personal data, and do not sign without it.
In PSUs and utilities
Distributors, franchisees, meter vendors, ticketing vendors and labour contractors.
Short answer: Yes, unless a sector rule says otherwise
Under DPDP, yes, unless the government restricts a country, and none had been restricted when this page was last reviewed. A sector rule can be stricter, for example RBI's rule that payment system data must be stored only in India. Remote support access from abroad also counts as data going outside India.
From your seat: Procurement department. Ask every vendor where data is hosted and where support staff sit.
In PSUs and utilities
Check vendor support access from abroad, especially for smart-meter and ticketing platforms.
What the law says
Section 16 allows transfers unless restricted, and keeps stricter sector laws in force. Rule 15 adds conditions on making data available to foreign states. Section 16 · Rule 15 · Section 8(1)–(2)
Steps
List where each system is hosted and where support teams log in from.
Check sector rules for localisation.
Put location and access terms in cloud and vendor contracts.
Keep the list current; new SaaS tools change it quietly.
Short answer: Yes, through a written backup-expiry rule
Deletion should reach every copy you control. For backups, the usual practice is to let deleted records expire with the normal backup cycle, never restore them into live use, and write this down. Test and training copies should use masked data.
From your seat: Procurement department. Add an exit clause: data returned or deleted, with a certificate.
In PSUs and utilities
Backups of billing and ticketing systems follow retention.
What the law says
Section 8(7) asks for erasure. Rule 6 asks for backups for continuity. The two meet in a backup retention rule that is short enough and written down. Section 8(7) · Rule 8 · Section 8(5) · Rule 6
Steps
List where copies live: backups, replicas, test, analytics, laptops, vendors.
Set backup retention to match the retention schedule.
Write a rule: deleted records are not restored into live systems.
Mask personal data in test and training copies.
Get deletion confirmations from vendors.
Evidence to keep
Backup retention settings
Written backup-expiry rule
Masking procedure for test data
Common mistakes
Ten-year backups for convenience
Live copies in test
Restoring old backups and bringing deleted records back
Short answer: Six hours for CERT-In; without delay for people and the Board; 72 hours for the detailed report
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.
From your seat: Procurement department. Vendor contracts need a short incident-notice time, in hours.
In PSUs and utilities
A leaked consumer list from a distributor is your breach to report.
What the law says
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
Steps
Name one incident lead and a back-up, with phone numbers that work at night.
Write the first-hour steps: isolate, preserve logs, tell the DPO and the incident lead.
Keep ready-made drafts for CERT-In, the regulator, the Board and affected people.
Decide in advance who signs off each message.
Rehearse once a year with the people who would actually be called.
Evidence to keep
Incident plan with clocks
Rehearsal record
Incident log with times of each step
Common mistakes
Waiting to finish the investigation before telling anyone
Treating a wrong email or a lost laptop as 'not a breach'
Short answer: They cover security, not the whole Act
They help a great deal with the security part. ISO/IEC 27001 and NIST CSF 2.0 are good evidence of reasonable security safeguards. They do not cover notice, consent, rights, complaints or children's data. ISO/IEC 27701 adds privacy controls, but no certificate replaces the Act.
From your seat: Procurement department. Ask for current certificates and the latest audit summary, not just a logo on a slide.
In PSUs and utilities
CEA guidelines and ISO 27001 cover much of Rule 6.
What the law says
Section 8(5) and Rule 6 ask for reasonable security safeguards. A recognised standard is strong evidence of that duty, and only of that duty. Section 8(5) · Rule 6
Steps
Map your current controls to Rule 6.
Add the DPDP-only items: notice, consent, rights, complaints, children, retention.
Use the same evidence for audits and for DPDP.
Include privacy in the scope of your next internal audit.
Consider ISO/IEC 27701 if clients ask for it.
Evidence to keep
Control map
Audit reports
Gap list for DPDP-only items
Common mistakes
Treating a certificate as DPDP compliance
Scope that leaves out the systems with the most personal data
You are a Data Fiduciary when you decide why and how personal data is used, as you do for your own staff and customers. You are a Data Processor when you handle data only on another organisation's instructions. Many organisations are both, for different data sets.
From your seat: Procurement department. Check whether the vendor will use the data for its own purposes. If yes, it is not just a processor.
In PSUs and utilities
Partners act for you when handling your consumers' data.
What the law says
Section 2(i) and 2(k) define the two roles. Section 8(1) puts the duties on the Data Fiduciary, which must use processors only under a valid contract. Section 8(1)–(2) · Section 17(1)(d)
Steps
List each data set you handle.
For each, ask: who decides the purpose?
Mark yourself as fiduciary or processor, and name the other party.
Check that contracts match the role.
Route requests about processor data to the fiduciary.
Evidence to keep
Role register by data set
Contracts matching the role
Common mistakes
Calling yourself a processor for data you use for your own purposes
