InfraVeritas360InfraVeritas360हिन्दीमराठीதமிழ்DPDPiq

DPDP Insights › Public sector undertakings and utilities › Software engineering department

DPDP for the Software engineering department in PSUs and utilities

Reviewed by InfraVeritas360 ResearchFirst published Last reviewed

Sources: DPDP Act, 2023 and DPDP Rules, 2025 (MeitY) · MeitY · CERT-In · NCIIPC · Central Electricity Authority

Engineering builds the apps, portals and integrations used by consumers, staff and partners.

Written for: Software engineering department, Public sector undertakings and utilities. Open this seat in the interactive tool

What is different here

Distributor and vendor integrations are data flows you must control. Build masking and logging into them.

The first four things to sort out

  1. Give partner integrations masked fields only.
  2. Log record views, not only errors.
  3. Make deletion reach partner copies.
  4. Keep Aadhaar in a vault.

A worked example

Software engineering department

Ticketing vendor integration

  1. DesignThe ticketing vendor's API returns full passenger details for every query.
  2. ChangeThe API is limited to fields each screen needs, with ID numbers masked.
  3. BuildRecord views and exports are logged; old reservation data is deleted on a schedule.
  4. AfterDeletion is tested on one booking across the vendor and backup copies.

Evidence kept

  • API specification
  • Log settings
  • Deletion test

Limit the fields at the API, not on the screen.

What others in the sector usually do. Teams commonly build masked APIs for partners.

Where it usually goes wrong, by organisation type

Organisation typeHotspots
Oil and gas marketingDistributor registers and delivery slips with addresses; Subsidy and Aadhaar data in distributor software; Consumer numbers shared with marketing partners
Power generation and transmissionContract labour gate passes and biometrics; PSU hospital records of employees and families; Township allotment and resident records
Electricity distribution (state discoms)Smart-meter data held by the meter vendor; Billing files shared with collection agencies; Consumer lists exposed on public bill lookup pages
Transport undertakings (rail PSUs, metro, state road transport)Passenger lists and reservation charts; Concession passes with ID copies; CCTV and travel-card data
Steel, mining, defence production and heavy industryMedical surveillance records of workers; Township and school records; Resettlement and compensation records of affected families
State development corporations and boardsLottery and allotment lists published with full details; Ration and supply records; Old paper files in record rooms

7 questions the Software engineering department asks, answered in full

What about distributors, dealers and franchisees?

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.

What the law says

Section 8(1) and 8(2) cover processors. Section 8(1)–(2) · Section 8(5) · Rule 6 · Section 6

Steps
  1. List partner types and numbers.
  2. Issue a standard data clause.
  3. Give masked views where possible.
  4. Train partners.
  5. Check samples yearly.
Evidence to keep
  • Partner list
  • Signed clauses
  • Training and check records
Common mistakes
  • Full consumer exports to partners
  • No clause
  • No checks

How do we build privacy into a new product or system?

Short answer: Four questions at design, then build the basics in

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.

From your seat: Software engineering department. Build the four questions into design review.
What the law says

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

Steps
  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.
Evidence to keep
  • Design review records
  • Inventory entries
  • Deletion tests
Common mistakes
  • Privacy review only at launch
  • Collecting 'in case we need it'
  • No delete function

Does deletion have to reach backups and test copies?

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: Software engineering department. Deletion and backup expiry together.
Example 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
  1. List where copies live: backups, replicas, test, analytics, laptops, vendors.
  2. Set backup retention to match the retention schedule.
  3. Write a rule: deleted records are not restored into live systems.
  4. Mask personal data in test and training copies.
  5. 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

Which logs must we keep, for how long, and where?

Short answer: At least one year; 180 days of ICT logs in India

Keep logs that show who accessed personal data and what they did, for at least one year under the DPDP Rules. CERT-In separately asks for ICT system logs to be kept for 180 days within India. Logs must be protected so nobody can quietly change them.

From your seat: Software engineering department. Log record views.
Example in PSUs and utilities

Consumer systems and township systems both need logging.

What the law says

Rule 6 lists logs and monitoring as a minimum safeguard. Rule 8(3) asks for logs to be kept for at least one year. The CERT-In Directions of 2022 ask for 180 days of ICT logs kept within India. Section 8(5) · Rule 6 · Section 8(7) · Rule 8

Steps
  1. List systems holding personal data and what each logs today.
  2. Turn on access logging where it is missing.
  3. Send logs to one protected store, with at least one year of retention.
  4. Keep a copy of ICT logs in India for at least 180 days.
  5. Sync clocks and review alerts every day.
Evidence to keep
  • Log source list
  • Retention settings
  • Alert review records
Common mistakes
  • Logging only failures, not who viewed a record
  • Logs stored on the same server they describe
  • Clocks out of sync, so timelines cannot be built

Who should be able to see personal data in our systems?

Short answer: Only those who need it, reviewed every quarter

Only people who need it for their job, and only the part they need. Use named accounts, give access by role, review it every quarter and remove it on the day someone leaves. Watch privileged accounts closely.

From your seat: Software engineering department. Roles in the architecture.
Example in PSUs and utilities

Partner and franchisee logins are the weak point.

What the law says

Rule 6 names access control as a minimum safeguard, along with logs and monitoring that can detect misuse. Section 8(5) · Rule 6

Steps
  1. Write a role matrix for each key system.
  2. Replace shared logins with named accounts.
  3. Use multi-factor sign-in for admin and remote access.
  4. Review access every quarter with each manager.
  5. Remove access on the last working day.
Evidence to keep
  • Role matrix
  • Quarterly review sign-offs
  • Leaver removal report
Common mistakes
  • Generic logins on shared machines
  • Access that only grows
  • No review of vendor accounts

Do we process children's data, and what changes if we do?

Short answer: Check every channel; children often appear where you least expect

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.

From your seat: Software engineering department. Age checks and tracking switches.
Example in PSUs and utilities

PSU schools and hospitals handle children's data.

What the law says

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

Steps
  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.
Evidence to keep
  • Channel-by-channel note on children's data
  • Parent-consent records
  • Ad and tracking settings
Common mistakes
  • 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

Someone asks us to delete their data. Must we?

Short answer: Yes, unless a law requires you to keep it

You must erase data that you no longer need for the purpose it was collected for, unless a law requires you to keep it. Where a law does require it, keep the data, stop using it for anything else, and tell the person why it is being kept and until when.

From your seat: Software engineering department. Make deletion an API, not a manual task.
Example in PSUs and utilities

If State provisions do not apply to the activity, normal erasure applies after legal retention.

What the law says

Section 12 gives the right to correction and erasure. Section 8(7) allows retention only where a law requires it. Rule 8(3) asks every organisation to keep personal data and logs for at least one year first. Sections 11–14 · Rule 14 · Section 8(7) · Rule 8

Steps
  1. Log the request and verify identity.
  2. Check the retention schedule for each record type involved.
  3. Delete what has no legal reason to stay, including copies with vendors and in test systems.
  4. Mark what must stay, with the law and the end date.
  5. Reply in plain words: what was deleted, what is kept, why and until when.
Evidence to keep
  • Erasure log
  • Vendor deletion confirmations
  • Reply to the person
Common mistakes
  • Refusing every erasure request 'because of backups'
  • Deleting records a law requires
  • Not telling vendors

The sections you will use most

Other rules that sit alongside DPDP

RuleWhat it saysWhat it means alongside DPDPSource
DPDP Act, Section 2(x) and Article 12 of the ConstitutionThe Act defines 'State' with the meaning in Article 12. Many PSUs have been treated as 'the State' by courts, depending on government control.Get a legal view on which activities can rely on Section 7(b), 7(c) and 17(4). Customer-facing commercial work usually follows full duties.MeitY
CERT-In Directions, 2022Report specified cyber incidents within six hours; keep ICT logs 180 days in India.Applies to every PSU.CERT-In
IT Act, Section 70 and NCIIPCSystems notified as protected systems come under NCIIPC's critical information infrastructure framework.Plant control, grid and pipeline systems may be notified; personal data in them follows DPDP too.NCIIPC
CEA (Cyber Security in Power Sector) Guidelines, 2021Cyber security requirements for power sector utilities, including incident reporting and supply chain controls.Power PSUs and discoms can use this evidence for DPDP Rule 6.Central Electricity Authority
Aadhaar Act, 2016Aadhaar-linked subsidies such as LPG must store Aadhaar numbers securely and limit sharing.Distributor systems and counters must not keep Aadhaar copies.UIDAI
Labour Codes (in force from 21 November 2025)Registers for workers and contract labour, health and safety records for hazardous work.Set retention for worker and contract labour records against the codes and state rules.Ministry of Labour
SEBI LODR Regulations (listed PSUs)Listed PSUs follow disclosure and governance rules.Board-level reporting on data protection fits into existing risk committee work.SEBI
RTI Act, Section 8(1)(j) as amendedPersonal information is exempt from RTI disclosure since 13 November 2025.PSU CPIOs should apply the new wording with reasoned orders.SFLC.in summary
Explore our research-built assessment platformsDPDP Insights helps you understand the law. DPDPiq is where an organisation's evidence is assessed. Each platform comes out of the same Foundation Layer research. No AI, API or outside service is used when you use this site. Everything runs from InfraVeritas360's own server.