DPDP for SaaS, IT services, cloud and BPO processors

India’s technology and services industry processes personal data for most of the economy. A bank’s call centre, a hospital’s cloud, a retailer’s CRM, a lender’s KYC vendor and a school’s learning platform are all Data Processors. The DPDP Act puts almost every duty on the Data Fiduciary, but section 8(1) makes the fiduciary responsible for what you do on its behalf, and section 8(2) lets it use you only under a valid contract. So your customers will push their DPDP duties down to you, clause by clause.

Your risk sits in two places. The first is operational: being unable to act on a single person’s withdrawal or erasure across your stack, missing a breach notice deadline that your customer’s 72-hour clock depends on, or losing control of sub-processors. The second is role drift: using customer data for your own product analytics, benchmarking or AI training, which can turn you from a processor into a Data Fiduciary with no ground. Read the Data Fiduciary playbook to understand what your customers must do; this guide covers what that means for you.

Are you a Data Fiduciary, a processor, or both?

The Act defines a Data Processor as anyone who processes personal data on behalf of a Data Fiduciary (section 2(k)), and a Data Fiduciary as anyone who determines the purpose and means of processing, alone or with others (section 2(i)). What matters is who decides why the data is used.

• SaaS platform (CRM, HRMS, helpdesk, marketing automation, LMS, EHR): a processor for the customer data your clients put in. A Data Fiduciary for your own customer account data (the client’s admins and users, billing contacts), your website visitors, your marketing leads and your employees.
• IT services and managed services: a processor when you build, run or support systems holding the client’s personal data, including when your staff have privileged access to production.
• Cloud, hosting and data-centre providers: a processor for data customers store with you, even if you never look at it. The Rules use you as the example: a company engaging a cloud provider to host customer records must make sure the provider keeps the data and logs for at least a year before erasure (rule 8(3), illustration case 2).
• BPO, KPO and call centres: a processor for the client’s customers whose calls, chats, documents and records you handle. A Data Fiduciary for your agents and staff. See the employers and HR guide.
• Analytics, AI and data enrichment vendors: a processor only while you process strictly on the client’s instructions for the client’s purposes. If you pool data across clients, build models you reuse, or sell insights, you are deciding purposes, and you are a fiduciary for that.
• Sub-processors: your own cloud host, support tools, offshore teams and subcontractors process the data on your behalf and, through you, on your client’s. The Act does not use the word “sub-processor”, but your client remains responsible for them under section 8(1), so expect the client to insist on the same terms flowing down.

The data you hold

Data category	Where it usually lives	Typical purpose	Sensitivity	Typical retention
Client customer records (names, contacts, identifiers)	Production databases, the client’s tenant	Delivering the client’s service	Varies by client; often high	As the client instructs, plus the rule 8(3) year for logs
Client sensitive records (health, financial, KYC, children’s data)	Segregated stores, document systems	Delivering the client’s service	High	As the client instructs and its sector laws require
Call recordings, chat transcripts, screen recordings	Contact-centre platform, QA tools	Customer service, quality	Medium to high	Client-defined; often 6–12 months
Documents processed in KPO work (forms, claims, invoices, IDs)	Workflow tools, shared drives, OCR pipelines	Data entry, verification, claims processing	High	Until the batch closes, then returned or erased
Processing logs, audit trails, access logs	Logging platform, SIEM	Security, investigation, proof of instructions	Medium to high	At least one year (rule 6(1)(e), rule 8(3))
Backups and snapshots	Backup systems, object storage	Recovery	Same as the source	Documented backup cycle
Support tickets and debug data containing client personal data	Ticketing, logs, engineers’ laptops	Fixing issues	Varies	Short; purge after closure
Telemetry and product analytics on client users	Analytics pipeline	Running and improving the product	Medium	Short, aggregated
AI training sets, embeddings, fine-tuned models	ML platform, vector stores	Product features	High where derived from client data	Depends on your ground; see below
Client admin and user accounts	Your identity system, CRM	Your own service and billing (you are the fiduciary)	Medium	During the contract and after as accounting needs
Prospects and marketing leads	Your CRM, marketing tools	Your sales (you are the fiduciary)	Medium	Until the lead goes cold or withdraws
Employee and agent records, background checks, monitoring data	HRMS, workforce management	Employment (you are the fiduciary)	High	As labour and tax law requires

Risk hotspots

1. No valid contract, or the wrong one. Section 8(2) lets a fiduciary use a processor only under a valid contract. Many Indian vendors work on purchase orders, click-through terms or old NDAs. Failure: the client cannot lawfully use you, and will either renegotiate under pressure or move. Control: a DPDP addendum covering instructions, purpose limits, security (rule 6(1)(f)), breach notice, sub-processors, erasure, log retention, assistance with rights requests and audit.
2. Unable to act for one person. Clients must cease processing within a reasonable time when consent is withdrawn and make their processors cease too (section 6(6)), and must cause you to erase what they gave you (section 8(7)(b)). Failure: you can delete a whole tenant but not one person across production, analytics, search indexes, caches and sub-processors. Control: a per-person withdrawal and erasure API or job, mapped to every store, with a confirmation back to the client.
3. Erasure versus the one-year log rule. Rule 8(3) requires the client to keep personal data, traffic data and processing logs for at least a year from processing, including data processed by you, and illustration case 2 says the client must ensure its cloud provider does the same. Failure: you erase on day one and the client is in breach, or you keep everything indefinitely “for compliance”. Control: agree with each client how an erasure instruction works during that year: remove from live use, keep a restricted copy only for the Seventh Schedule purposes, and erase at the end. Confirm the approach with counsel.
4. Slow breach notice. The client must tell the Board without delay and send a detailed report within 72 hours of becoming aware (rule 7(2)), and tell affected people without delay (rule 7(1)). Failure: you take three days to tell the client, leaving it in breach before it starts. Control: a contractual deadline in hours, a 24×7 security contact, a notification template that gives the client what rule 7 needs, and drills.
5. Role drift into a fiduciary. Product analytics across tenants, benchmarking, “anonymised” data products and training AI on client data. Failure: you are deciding purposes, so you are a Data Fiduciary for that processing, with every DPDP duty and no consent from the people concerned. Control: a written list of every secondary use; aggregate data that cannot identify anyone, an explicit client instruction, or stop.
6. Uncontrolled sub-processors. Offshore delivery centres, freelancers, support tools and new AI APIs added without telling clients. Failure: data at a party the client never approved, possibly outside India. Control: a published sub-processor list, advance notice of changes with a right to object, flow-down contracts, and a register of where each sub-processor stores data.
7. Privileged access by your staff. Engineers, support agents and BPO staff can see production data. Failure: insider theft, the most common BPO breach. Control: least privilege, time-bound access with approval, session recording for privileged access, masking in support tools, no personal devices on the floor, and access logs kept a year (rule 6(1)(c), (e)).
8. Personal data in places it should not be. Client data in support tickets, debug logs, test environments and engineers’ laptops. Control: synthetic or masked data in non-production, log redaction, and short retention on tickets.
9. Mixed-residency data under section 17(1)(d). Foreign clients’ data is often assumed to be exempt. Failure: the exemption covers only Data Principals not in India, so Indian residents in the same dataset are fully covered. Control: know which data sets contain people in India and treat them under the full Act.
10. Client instructions you cannot prove. Disputes over what you were told to do. Control: written instructions, change tickets for data-handling changes, and a log of every withdrawal and erasure you received and when you confirmed it.

Legal basis, purpose by purpose

As a processor, you do not need your own legal basis for client processing; you rely on the client’s ground and its instructions. You do need one for everything you do as a fiduciary.

Purpose	Basis	Notes
Processing client data to deliver the contracted service	The client’s ground; you act under section 8(2)	Stay within the instructions. The client stays responsible (section 8(1)).
Security monitoring, abuse prevention and logging of the service	The client’s instruction and rule 6; 17(1)(c) where you detect offences	Logs kept at least a year (rule 6(1)(e), rule 8(3)).
Keeping data and logs for a year after processing	Rule 8(3), on the client’s behalf	Restricted to the Seventh Schedule purposes.
Disclosing data to authorities on a legal demand	7(d) or 17(1)(c), coordinated with the client	Tell the client unless the law forbids it.
Running your own customer accounts and billing	7(a)	You are the fiduciary for client admins and users.
Product telemetry needed to run the service	7(a) for your account users; the client’s instruction for end users	Keep it aggregated and short-lived.
Product analytics and benchmarking across tenants	Aggregated data that cannot identify anyone, or the client’s instruction with the client’s own ground	Individual-level cross-tenant analytics makes you a fiduciary.
Training or fine-tuning AI models on client personal data	Client instruction for that client’s own model, or consent obtained by the client for that purpose	Using it for your general models makes you a fiduciary; you will rarely have a ground.
Your marketing to prospects and client contacts	Consent	Business contacts are personal data too. Also follow TRAI TCCCPR for calls and SMS.
Employees, agents, background checks, workforce monitoring	7(i)	Monitoring beyond safeguarding the employer needs care. See the employers and HR guide.
Processing foreign clients’ data of people outside India	17(1)(d)	Sections 8(1) and 8(5) still apply, so security safeguards stay. People in India in the same data are fully covered.
Enforcing your contracts, defending claims	17(1)(a)	Keep only what the claim needs.

Notices and consent: getting the screens right

As a processor, the notice to end users is your client’s. You still shape it, because your product is often where it appears, and you run your own notices as a fiduciary.

Channel	Do	Don’t
Your product’s end-user screens	Give clients configurable notice and consent components, per purpose, off by default, with their versions recorded.	Hard-code a single “I agree” checkbox for every client.
Call centre and IVR (for clients)	Read the client’s approved script before recording; give the client’s contact for rights requests.	Improvise notices or promise things the client has not approved.
Outbound calling for clients	Check the client’s consent and DND status before each campaign.	Dial lists the client cannot show consent for.
Field and KPO document handling	Handle documents only in controlled workflows; follow the client’s notice on forms.	Accept documents on agents’ WhatsApp.
Your website and sign-up	Give your own notice for visitors, leads and trial users; separate marketing consent.	Treat a free-trial sign-up as consent to marketing.
Client admin console	Show admins your sub-processors, data location and DPA terms.	Hide changes to sub-processors in release notes.
Your employees	Give a notice at hiring covering monitoring, background checks and client-site requirements.	Rely on an offer letter clause for everything.

Each notice your clients give must be readable on its own, itemise data and purposes, and explain how to withdraw consent, exercise rights and complain to the Board (rule 3), with the option to read it in English or any Eighth Schedule language (section 5(3)). If your product renders client notices, support all 22 languages, or your clients will choose a vendor that does.

Other laws you must line up with

• IT Act, 2000 and CERT-In Directions (2022): service providers, data centres and cloud providers have their own incident reporting and log retention duties, on a shorter clock than the DPDP 72 hours. These apply to you directly, not only through clients. Confirm the current requirement with counsel.
• RBI outsourcing and IT directions: banks, NBFCs and payment companies must flow down audit rights, data location, access by RBI and exit plans to vendors. Payment data localisation continues (section 16(2) keeps stricter sector rules).
• SEBI cyber security and resilience framework, IRDAI outsourcing and information security rules: similar flow-downs for capital-market and insurance clients.
• Health clients: ABDM standards and Clinical Establishments rules shape how health records are hosted and shared.
• Government clients: MeitY cloud empanelment and government security guidelines for hosting public data.
• TRAI TCCCPR: telemarketer registration, DLT, headers and consent for outbound calls and SMS by call centres.
• Labour codes and Shops & Establishments Acts: employee records, working hours and monitoring of your own staff.
• Foreign laws of your clients: GDPR, UK GDPR and US state laws arrive through contracts. Section 17(1)(d) eases DPDP for foreign clients’ non-resident data, but does not lift those contractual duties.
• Transfers abroad (section 16, rule 15): allowed unless the government restricts a country or sets requirements for making data available to foreign States. Some clients, and Significant Data Fiduciaries for specified data (rule 13(4)), will require India hosting.

Retention and erasure

1. On the client’s instruction (section 8(7)(b)): the client must cause you to erase personal data it made available to you, when consent is withdrawn or the purpose is over. Build per-person and per-tenant erasure, and confirm each instruction in writing or through the client’s system.
2. The one-year minimum (rule 8(3)): the client must keep personal data, associated traffic data and processing logs for at least a year from processing, including processing you do, and illustration case 2 says it must ensure its cloud provider does the same. Agree how this sits with erasure instructions, and erase at the end of the year unless another law requires more.
3. Logs for security (rule 6(1)(e)): keep logs and personal data needed to detect, investigate and recover from unauthorised access for one year, unless a law requires otherwise.
4. Legal holds: a client may place a hold for litigation or a regulator; record the hold and its owner, and stop it when released.
5. At contract end: return or erase all client data on a fixed timeline, including sub-processors, and give a certificate of erasure. Keep only what rule 8(3) or another law requires, restricted.
6. Third Schedule: this applies to your client if it is a large e-commerce, online gaming or social media platform, not to you. If you host one, expect instructions to run three-year inactivity erasure with a 48-hour warning (rule 8(2)), excluding data needed for account access and virtual tokens.
7. Backups: document backup cycles, make sure erased records do not return on restore, and tell clients how long backups persist.

Rights requests and grievances

The rights belong to the client’s Data Principals, and the client must answer them. Your job is to make that possible.

• Routing: when an end user contacts you directly, pass the request to the client promptly and tell the person you have done so. Do not answer on the client’s behalf unless the contract says you should.
• Assistance: give clients tools or APIs to export, correct and erase one person’s data, and to list which of your sub-processors received it, so the client can answer section 11(1)(b), which requires it to name the processors it shared data with.
• Correction (section 12(2)): correct on instruction and push corrections to sub-processors. Where your system drives decisions, help the client meet section 8(3) on accuracy.
• Erasure (section 12(3)): erase on instruction across all stores, then confirm.
• Withdrawal (section 6(6)): stop processing for the withdrawn purpose within the time the contract sets, and confirm.
• Your own users and staff: for data where you are the fiduciary, publish a contact person (rule 9), request channels and identifier (rule 14(1)), and a grievance period within the 90-day ceiling (rule 14(3)); 15–30 days is good practice. Support nomination (section 14).

Breach readiness

Likely scenarios:

• an agent at a BPO copying customer records or recording screens on a phone
• a misconfigured storage bucket or exposed database in one tenant or across tenants
• compromised engineer or support credentials with production access
• ransomware in a delivery centre
• a sub-processor breach, such as a support tool or AI API
• client data leaked through a test environment or a debug log

Run-book:

1. Contain within hours: revoke credentials, isolate affected systems, stop the sub-processor’s access, and preserve evidence.
2. Tell each affected client at once, within your contractual deadline. Give what the client needs for rule 7: the nature, extent, timing and location of the breach; the likely impact; the data and people affected; your mitigation; and what you know about who caused it.
3. Support the client’s notices: the client must tell each affected person without delay (rule 7(1)) and the Board without delay, then send the detailed report within 72 hours (rule 7(2)). Keep updating the client as facts change so the 72-hour report is accurate.
4. Report to CERT-In where its directions apply to you directly, and coordinate wording with clients.
5. Where you are the fiduciary (your own users, staff or leads), notify affected people and the Board yourself.
6. Learn: root cause, fixes, and a written report for each client; update sub-processor terms if they caused it.

The checklist

Phase 1: discover (days 0–30)

• [Leadership] Name an executive owner for DPDP and a security contact reachable 24×7.
• [Legal] Collect every client contract and list which have no data processing terms, old terms or only a purchase order.
• [Eng] Map where client personal data lives: production, replicas, analytics, search indexes, caches, logs, backups, test environments, support tools.
• [Eng] Test whether you can find, export, correct and erase one person’s data across all of those stores.
• [Legal] List every sub-processor, what it receives and where it stores data.
• [Product] List every secondary use of client data: analytics, benchmarking, AI training, data products, sales insights.
• [Legal] Identify foreign-client data sets, and whether they contain people in India.
• [Security] Review who has privileged access to client data and how it is logged.
• [Legal] List the sector flow-downs your clients impose: RBI, SEBI, IRDAI, health, government.
• [HR] Map your own employee data, monitoring and background checks, where you are the fiduciary.
• [Finance] Check your cyber insurance covers client notification costs and breach response at your processing volumes.
• [Legal] Record, for each product and service line, whether you act as processor, fiduciary or both.

Phase 2: design and build (days 31–90)

• [Legal] Publish a standard DPDP addendum: instructions, purpose limits, security, breach notice in hours, sub-processors, erasure, one-year logs, rights assistance, audit, return at exit.
• [Legal] Prepare fallback positions for clauses clients will push: unlimited liability, on-site audits, India-only hosting.
• [Eng] Build per-person withdrawal and erasure jobs or APIs covering every store, with idempotent retries.
• [Eng] Return a confirmation to the client for every withdrawal and erasure, with a timestamp and scope.
• [Eng] Implement the rule 8(3) year: restricted retention after erasure instructions, then automatic erasure.
• [Eng] Keep access and processing logs for at least one year, tamper-evident and with synchronised clocks.
• [Security] Encrypt client data at rest and in transit; offer customer-managed keys for sensitive clients.
• [Security] Enforce least privilege, time-bound production access with approval, MFA and session recording for privileged users.
• [Security] Mask personal data in support and QA tools; block copy, print and downloads on BPO floors.
• [Eng] Replace production data in test and development with synthetic or masked data.
• [Eng] Redact personal data from application logs and error trackers.
• [Security] Write a breach run-book with a client notification template matching rule 7 fields, and name decision-makers.
• [Legal] Publish a sub-processor list with locations, give advance notice of changes, and flow down terms.
• [Product] Stop or redesign secondary uses: aggregate analytics, per-client models only on instruction, no cross-client training on personal data.
• [Product] Give clients configurable notice and consent components, with versions recorded, if your product collects end-user data.
• [Product] Support notices in English and the 22 Eighth Schedule languages in client-facing screens.
• [Eng] Offer India-region hosting and document data flows for clients that need it.
• [Ops] Build a route for end-user requests that reach you to go to the right client within a day.
• [Ops] For call centres, check client consent and DND status before outbound campaigns.
• [Legal] Publish your own privacy notice, contact person and grievance period as a fiduciary.
• [HR] Give employees a notice covering monitoring, background checks and client-site requirements.
• [Eng] Verify webhook signatures on every withdrawal and erasure instruction you receive, and alert on failures.
• [Legal] Write an exit plan for each client: data return format, erasure timeline, certificate of erasure.

Phase 3: operate (ongoing)

• [Security] Drill a breach every year with a client, from detection to the client’s 72-hour report.
• [Security] Run penetration tests every year and share summaries with clients under NDA.
• [Security] Maintain ISO 27001 or SOC 2, and consider ISO 27701, to answer audits once rather than for each client.
• [Legal] Review client contracts and renewal dates every quarter.
• [Legal] Review sub-processors every year: security reports, contracts, locations.
• [Ops] Track withdrawal and erasure instructions every month: received, completed, confirmed, overdue.
• [Security] Review privileged access lists every quarter and revoke leavers the same day.
• [Ops] Train delivery, support and BPO staff every year on handling client data.
• [DPO] Review new features and AI integrations for role drift before launch.
• [DPO] Keep evidence: instructions, confirmations, logs, audit reports and breach records.
• [Ops] Purge client personal data from closed support tickets and debug logs every month.

Where myconsentapp comes in

If your client uses myconsentapp, you will usually meet it as an entry in the client’s processor registry. This is how withdrawals and erasures reach you, and how you prove you acted on them.

You need to	With myconsentapp	You still own
Know what you are allowed to process	The client links your entry in its processor registry to specific purposes and data items, with your contract (DPA) dates and expiry flags.	Reading and signing the contract.
Receive withdrawals in real time	When a person withdraws consent for a purpose linked to you, myconsentapp sends a signed webhook to your endpoint, with retries if delivery fails.	Building the endpoint and acting on the instruction in your systems.
Receive erasure instructions	Erasure requests the client opens, including erase-on-withdrawal and retention job expiries, reach you through your per-processor webhook.	Erasing across your stores and sub-processors.
Prove you acted	You confirm each withdrawal and erasure back to the client’s registry. The client’s erasure is not complete until you confirm, or until the client records an override.	Making sure the confirmation is true.
Avoid missing deadlines	The client sees acknowledgements with overdue alerts when a withdrawal has not been acted on in time, so slow confirmations are visible.	Meeting the timeline in your contract.
Trust that instructions are genuine	Webhooks are signed, with secret rotation, so you can verify each one came from the client’s account.	Verifying signatures and keeping secrets safe.
Help the client answer access requests	Your registry entry and the client’s record of processing (JSON, CSV or PDF) show which data the client shares with you, so it can list you under section 11(1)(b).	Telling the client about your own sub-processors.
Support the client in a breach	The client’s breach register runs the 72-hour clock and generates Rule 7 notices and Board documents.	Getting the facts to the client fast.
Collect consent for your own uses as a fiduciary	Use myconsentapp as your own fiduciary account for your website, trial users and any consent-based product analytics: hosted consent page, widget or SDKs (TypeScript, Python, Java, Go), with purposes off by default.	Deciding whether you have a ground at all.

Not included: myconsentapp does not erase data inside your systems, discover where client data lives, run your security programme or write your DPA; it records instructions and confirmations through the API and webhooks. It is a proposed Consent Manager, not legal advice.

Common mistakes

• Signing every client’s DPA as drafted, including breach notice deadlines you cannot meet.
• Being able to delete a whole tenant but not one person.
• Erasing everything on day one, or keeping everything forever, instead of agreeing how the one-year rule 8(3) retention works.
• Telling clients about a breach after your own investigation finishes.
• Training a shared AI model on client personal data and calling it “product improvement”.
• Adding a new AI API or offshore team without updating the sub-processor list.
• Assuming section 17(1)(d) covers the whole of a foreign client’s data set, including people in India.
• Leaving client data in test environments, tickets and engineers’ laptops.

Frequently asked questions

Does the DPDP Act apply to us directly as a processor? Most duties sit with the Data Fiduciary, but the fiduciary is responsible for your processing (section 8(1)), may use you only under a valid contract (section 8(2)), and must make you cease processing and erase data (sections 6(6) and 8(7)(b)). In practice the Act reaches you through every client contract. Laws such as the IT Act and CERT-In directions apply to you directly.

How fast must we tell a client about a breach? The Act does not set a processor deadline. Your client must tell the Board without delay and send a detailed report within 72 hours of becoming aware (rule 7(2)), so expect contracts to ask for hours. Agree a deadline you can meet, and send what you know early rather than everything late.

A client asks us to erase a person’s data, but rule 8(3) says keep it for a year. What do we do? Agree the approach with the client in the contract. A common answer is to remove the data from live use at once, keep a restricted copy and the logs only for the purposes the Seventh Schedule names, and erase them when the year ends. Confirm the approach with counsel.

When do we become a Data Fiduciary? When you decide why personal data is used. Using client data for your own product analytics at individual level, cross-client benchmarking, data products or training general AI models makes you a fiduciary for that processing, and you will need your own ground, which you usually will not have.

We process data of US and UK customers for foreign clients. Does DPDP apply? Mostly not. Section 17(1)(d) lifts most of the Act for personal data of people outside India processed under a contract with a person outside India. Sections 8(1) and 8(5) still apply, so you must keep reasonable security safeguards. Any people in India in that data are covered in full.

Do we need to keep data in India? Not under DPDP generally. Transfers abroad are allowed unless the government restricts them (section 16, rule 15). Sector rules such as RBI payment data localisation still apply (section 16(2)), and Significant Data Fiduciary clients may have specified data that must stay in India (rule 13(4)).

Our clients want to audit us. Do we have to agree? DPDP does not set processor audit rights, but your client must be able to show it took reasonable security safeguards (section 8(5)), and regulated clients have their own audit duties. Independent certifications and a shared audit report reduce the number of on-site audits you face.