DPDP for the Legal department 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

• Are we a Data Fiduciary or a Data Processor?
• What must a vendor contract say about personal data?
• Does ISO 27001 or NIST CSF cover our DPDP duties?

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

• Something has gone wrong. What happens in the first 72 hours?
• Which logs must we keep, for how long, and where?
• How should our people access client systems?

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

• What should our privacy notice say, and where must people see it?
• Someone withdraws consent. What has to stop, and how fast?
• Can we send offers to past customers and leads?

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.

Sub-contractors working on client data need the same terms you signed with the client.

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?

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.

You are usually a processor for client data and a fiduciary for staff and candidates.

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)

1. List each data set you handle.
2. For each, ask: who decides the purpose?
3. Mark yourself as fiduciary or processor, and name the other party.
4. Check that contracts match the role.
5. Route requests about processor data to the fiduciary.

• Role register by data set
• Contracts matching the role

• Calling yourself a processor for data you use for your own purposes
• No contract when you act as processor
• Answering requests that belong to your client

• What must a vendor contract say about personal data?
• Someone asks what data we hold about them. What do we send?
• Can personal data be stored or accessed outside India?

Check that the request is in writing, comes from the right authority and cites the legal power. Share only what is asked for, record what you sent and to whom, and keep the request on file. The Act allows processing to meet a legal duty, but it does not mean sharing everything on a phone call.

Section 7(d) and 7(e) allow processing to meet a legal duty to disclose to the State, or to comply with a judgment or order. Section 17(1)(c) exempts processing for preventing, detecting or investigating offences. Section 7 · Section 8(5) · Rule 6

1. Route every such request to Legal.
2. Check the authority, the legal power and the scope.
3. Share only what is asked, by a secure method.
4. Log the request, what was sent, by whom and when.
5. Tell the person, unless the law or the authority says you must not.

• Authority request log
• Copies of requests
• Record of what was sent

• Sharing on a phone call
• Sending whole files when a few lines were asked
• No log

• Someone asks what data we hold about them. What do we send?
• How long can we keep personal data?
• Something has gone wrong. What happens in the first 72 hours?

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.

Global HR and collaboration tools are often hosted abroad. Clients may restrict where their data goes.

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?

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.

Usually only if a client's service involves children, or in staff dependants' records.

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

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.

• Channel-by-channel note on children's data
• Parent-consent records
• Ad and tracking settings

• 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

• When do we need consent, and when can we rely on a legitimate use?
• What should our privacy notice say, and where must people see it?
• Can we send offers to past customers and leads?