DPDP for a saas and software products

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?

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 product users 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

• When do we need consent, and when can we rely on a legitimate use?
• Someone withdraws consent. What has to stop, and how fast?
• Someone asks what data we hold about them. What do we send?

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?

Send a summary of the personal data you hold about them and what you do with it, and the names of the other organisations you shared it with and what was shared. Check the person's identity first, log the request and keep a copy of your reply.

Requests about client data go to the client. Requests from staff and candidates come to you.

Section 11 gives the right to a summary and the list of organisations it was shared with. Rule 14 asks you to publish how requests are made and to answer within the period you publish. Sections 11–14 · Rule 14 · Section 8(9)–(10) · Rules 9, 14

1. Log the request in one register the day it arrives.
2. Verify identity using details you already hold.
3. Search every system, including vendors' copies.
4. Write a plain summary: what data, why it is used, who received it.
5. Send it, and file the request, search notes and reply.

• Request register
• Search notes for each request
• Copy of each reply with date

• Sending raw database dumps
• Forgetting data held by vendors
• No identity check before sending

• How do we handle a privacy complaint within 90 days?
• Someone asks us to delete their data. Must we?
• Where does personal data live in our organisation?

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

• Someone asks what data we hold about them. What do we send?
• Someone asks us to delete their data. Must we?
• Someone withdraws consent. What has to stop, and how fast?