DPDP for the Chief compliance officer in IT and ITeS

Mostly not. Section 17(1)(d) exempts processing of personal data of people outside India when you do it under a contract with a party outside India. Security safeguards and responsibility for your processors still apply. The exemption does not cover your Indian staff, Indian customers, or Indian data mixed into the same work.

Section 17(1)(d) sets the exemption. Section 8(5) and 8(1) still apply. Section 17(1)(d) · Section 8(5) · Rule 6 · Section 8(1)–(2)

1. Tag each project by where the people live.
2. Find mixed projects with Indian data.
3. Keep security controls the same for all.
4. Record which contracts rely on the exemption.
5. Review when projects change.

• Project tagging
• Contract list

• Assuming all client work is exempt
• Lower security for exempt data
• Missing Indian data in global data sets

Tell the client first, within the time your contract sets, because the client is the fiduciary and must tell its own customers and the Board. Report to CERT-In within six hours if the incident is reportable. Give the client logs and facts quickly; do not contact the client's customers yourself unless the client asks.

Section 8(6) puts the duty to tell people on the fiduciary. As processor, your contract decides your duty to the client. Section 8(6) · Rule 7 · Section 8(1)–(2)

1. Keep a list of client notice times.
2. Name who calls each client.
3. Prepare a client incident template.
4. File CERT-In if reportable.
5. Share logs and a written account.

• Client notice list
• Incident timeline
• CERT-In record

• Waiting to finish the investigation before telling the client
• Contacting the client's customers directly
• Missing the CERT-In clock

The organisation is accountable under the Act, and management decides who answers for each duty inside it. In practice that means a named owner for each duty and each major system, written down and accepted by that person. An owner whose name was typed in by someone else, without their agreement, is not really an owner.

Section 8(1) puts responsibility on the Data Fiduciary. Section 8(9) asks for a published contact person. Section 8(1)–(2) · Section 8(9)–(10) · Rules 9, 14 · Section 10 · Rule 13

1. List duties and major systems.
2. Propose an owner for each.
3. Ask each owner to accept in writing.
4. Publish the overall contact person.
5. Review owners when people move.

• Owner register with acceptances
• Published contact
• Review dates

• Owners assigned without telling them
• One person owning everything
• Owners who left the organisation

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

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.

Payroll and background checks are employment purposes. Newsletters to prospects 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

A notice must tell people, in plain words, what data you collect, why, how they can withdraw consent, how they can use their rights and how they can complain to the Data Protection Board. It has to stand on its own, separate from long terms and conditions, and be shown at the point where data is collected.

Your careers page, candidate portal, employee onboarding and website forms need notices. For client data, the client gives the notice.

Section 5 and Rule 3 ask for a notice that can be understood on its own, with an itemised list of the data and the purpose for each item. Data you already hold from before the Act also needs a notice, as soon as reasonably practicable. Section 5 · Rule 3 · Section 6 · Sections 11–14 · Rule 14

1. List every point where personal data comes in: forms, apps, counters, calls, emails, partner feeds.
2. Write one short notice per collection point, with the data items and purpose side by side.
3. Add how to withdraw consent, how to make a request and the DPO or contact person's details.
4. Offer the notice in English and in the languages your client customers actually use.
5. Keep each version with the date it went live.

• Screenshots or copies of the notice at each collection point, with dates
• Notice version history
• Translations, where used

• Hiding the notice inside terms and conditions
• One notice for everything, with no link between data items and purposes
• Forgetting old data collected before the Act

Publish one clear way to complain, log every complaint, give it an owner and reply within the period you publish, never more than 90 days. People can go to the Data Protection Board only after using your process, so a good process keeps most matters with you.

Most complaints come from staff, ex-staff and candidates. Tag them.

Section 8(10) requires a working grievance process. Rule 14(3) caps the reply time at 90 days. Section 13 says people must use your process before approaching the Board. Section 8(9)–(10) · Rules 9, 14 · Sections 11–14 · Rule 14 · Sections 18–26

1. Publish one contact for privacy complaints on your website, app and notices.
2. Log each complaint with the date, channel and a named owner.
3. Acknowledge within a few days, and set an internal target well under 90 days.
4. Find and fix the cause, not just the single case.
5. Reply in writing and close the entry with the date.

• Complaint register with dates
• Replies sent
• Monthly summary to management

• Mixing privacy complaints into general complaints with no tag
• No owner, so nobody counts the days
• Closing a complaint without fixing the cause

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.

If client data is involved, the client contract sets your first deadline, often a few hours.

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

By law, only Significant Data Fiduciaries must do a yearly impact assessment. For everyone else it is good practice for high-risk changes: new tracking, profiling, large data sharing, children's data or moving data abroad. A short assessment before the change is cheaper than fixing it later.

Section 10 and Rule 13 require a yearly impact assessment for Significant Data Fiduciaries. Section 10 · Rule 13 · Section 9 · Rules 10, 12 · Section 16 · Rule 15

1. Define what counts as a high-risk change for you.
2. Use a two-page template.
3. Record the data, purpose, risks and safeguards.
4. Get the DPO's view before approval.
5. Keep it with the project record.

• Assessment template
• Completed assessments
• DPO views

• Treating it as paperwork after launch
• A 40-page template nobody completes
• No trigger list

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.

Link client contract clauses to control owners.

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