DPDP for the Internal audit department in Healthcare

Yes, for a claim the patient has asked for, because that is part of the purpose. Share only what the claim needs, through the TPA portal or a secure channel, and keep a record of what was sent. Sharing for anything else, such as an insurer's own marketing, needs consent.

Section 7(a) covers the claim purpose; Section 8(1) and 8(5) apply to how data is sent. Section 7 · Section 8(5) · Rule 6 · Sections 11–14 · Rule 14

1. Use TPA portals, not email.
2. Send only claim documents.
3. Log what was sent, to whom, when.
4. Answer patient questions about sharing.
5. Check TPA agreements.

• Sharing log
• TPA agreement

• Full case files by email
• No record of what was sent
• Insurer representatives reading records on wards

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

No. A policy shows what an organisation intends. It does not show that the control runs. To show operation you need records: a deletion log, an access review sign-off, a drill report, a sample of requests answered on time. Auditors and regulators look for these.

Section 8(4) asks for appropriate technical and organisational measures to ensure compliance. Being able to show those measures work is part of meeting that duty. Section 8(5) · Rule 6 · Section 8(1)–(2)

1. For each policy, write the record that would show it working.
2. Check whether that record exists for the last quarter.
3. Where it does not, start producing it.
4. Sample a few records every quarter.
5. Keep the samples with the policy.

• Policy-to-record map
• Quarterly samples
• Gaps and actions

• Approving policies with no record behind them
• Showing a policy when asked for evidence
• Records that exist only before an audit

Before accepting a readiness statement, management should see evidence for each duty: dated notices, consent records, a request register with replies, signed vendor terms, access review sign-offs, log settings, a breach drill report and a deletion log. A status colour without these is a statement, not evidence.

The Act places duties on the Data Fiduciary as an organisation. Management is accountable for whether they are actually met. Section 8(1)–(2) · Section 8(5) · Rule 6 · Section 8(6) · Rule 7 · Section 8(9)–(10) · Rules 9, 14

1. List the duties that apply.
2. For each, name the piece of evidence that would satisfy an auditor.
3. Ask owners to attach it.
4. Mark duties without evidence as open, not ready.
5. Review the list before each management sign-off.

• Duty-to-evidence list
• Attached evidence
• Sign-off record

• Accepting 'done' without seeing anything
• Counting policies as evidence
• One sign-off and no review after

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

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

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

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.

Indoor records at least 3 years (2002 regulations), PCPNDT 2 years, MTP 5 years, Schedule H1 3 years.

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

Turn each duty into a risk line with an owner, a control, evidence and a review date. Map controls you already run for your regulator, auditors or certifications, so the same evidence serves several purposes. Track vendor risk separately.

Add downtime and wrong-send lines.

The Act sets duties in Sections 5 to 12. A risk register shows management where each duty stands. Section 8(1)–(2) · Section 8(5) · Rule 6 · Section 8(6) · Rule 7 · Section 10 · Rule 13

1. List the duties that apply to you.
2. For each, write the risk in plain words, the control and the owner.
3. Link existing controls and audits as evidence.
4. Rate likelihood and impact in your usual way.
5. Review every quarter with management.

• Risk register extract
• Linked evidence
• Quarterly review minutes

• One line saying 'DPDP compliance'
• No owners
• Evidence that is only a policy document

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