DPDP for the IT department in Healthcare

Imaging and lab devices store names, ages and results, often on old operating systems. Put them on a separate network, control vendor remote access, change default passwords, and wipe disks before a device is returned or scrapped.

Rule 6 safeguards apply to devices that store personal data. Section 8(5) · Rule 6 · Section 8(7) · Rule 8

1. List devices that store patient data.
2. Segment them.
3. Control vendor remote access.
4. Change default passwords.
5. Wipe before disposal.

• Device list
• Network diagram
• Wipe certificates

• Devices on the general network
• Vendor modems always on
• Disks leaving with old machines

• Who should be able to see personal data in our systems?
• What must a vendor contract say about personal data?
• Does deletion have to reach backups and test copies?

Snooping on VIP, celebrity, colleague or neighbour records is a common problem. Give access by role, mark sensitive records, ask for a reason before opening them, allow break-glass access in emergencies, and review those logs every week.

Rule 6 requires access control and monitoring. Section 8(5) · Rule 6 · Section 8(6) · Rule 7

1. Flag VIP, staff and sensitive records.
2. Ask for a reason to open them.
3. Allow break-glass with review.
4. Review logs weekly.
5. Act on misuse consistently.

• Flag settings
• Review records
• Action records

• Everyone can see everything
• Break-glass never reviewed
• No action on misuse

• Who should be able to see personal data in our systems?
• Which logs must we keep, for how long, and where?
• Which records need extra protection under other health laws?

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.

HIS, PACS, LIS, pharmacy, billing, apps, ABDM gateway and devices.

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

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

• How long can we keep personal data?
• Can personal data be stored or accessed outside India?
• Someone asks what data we hold about them. What do we send?

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.

HIS and PACS access logs show who opened which record; keep them a year.

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

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.

• Log source list
• Retention settings
• Alert review records

• 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

• Something has gone wrong. What happens in the first 72 hours?
• Who should be able to see personal data in our systems?
• Where does personal data live in our organisation?

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.

End shared ward logins; flag VIP and staff records.

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

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.

• Role matrix
• Quarterly review sign-offs
• Leaver removal report

• Generic logins on shared machines
• Access that only grows
• No review of vendor accounts

• Which logs must we keep, for how long, and where?
• Something has gone wrong. What happens in the first 72 hours?
• What must a vendor contract say about personal data?

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.

Offline backups decide whether care continues during ransomware.

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

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.

• Backup retention settings
• Written backup-expiry rule
• Masking procedure for test data

• Ten-year backups for convenience
• Live copies in test
• Restoring old backups and bringing deleted records back

• Someone asks us to delete their data. Must we?
• How long can we keep personal data?
• Where does personal data live in our organisation?

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.

Teleradiology and some software vendors use teams abroad; this is a transfer.

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)

1. List where each system is hosted and where support teams log in from.
2. Check sector rules for localisation.
3. Put location and access terms in cloud and vendor contracts.
4. Keep the list current; new SaaS tools change it quietly.
5. Tell people in your notice if data goes abroad.

• Hosting and access-location list
• Contract clauses
• Sector rule check

• Forgetting email, CRM and helpdesk SaaS
• Ignoring overseas support logins
• Assuming 'Indian vendor' means 'data in India'

• What must a vendor contract say about personal data?
• Where does personal data live in our organisation?
• Which logs must we keep, for how long, and where?

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 ransomware attack on the HIS needs a CERT-In report in six hours and the DPDP messages.

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?

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.

Labs, teleradiology, HIS vendors, TPAs and ambulance services.

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

• Something has gone wrong. What happens in the first 72 hours?
• Can personal data be stored or accessed outside India?
• Does deletion have to reach backups and test copies?