Data processing agreement — when someone else handles your customers’ data

Why this contract matters now

For years, Indian businesses shared customer lists, employee records and patient files with their vendors on the strength of a purchase order and a confidentiality clause. The Digital Personal Data Protection Act, 2023 changes the footing. It gives individuals enforceable rights over their personal data, requires the businesses that use it to protect it, and backs those duties with penalties that run into hundreds of crores. Its rules were notified in November 2025, with most obligations of businesses coming into force in stages over the following eighteen months, so the time to put contracts in order is before those obligations bite, not after an incident.

The Act’s structure makes the vendor contract central. It places the duties on the data fiduciary — the business that decides the purpose and means — and says, in substance, that the fiduciary is responsible for complying with the Act for processing done by it or on its behalf by a data processor, irrespective of any agreement to the contrary. A business cannot outsource its accountability. What it can do is make sure that each vendor is contractually bound to behave in the way the business itself must, to tell it immediately when something goes wrong, and to bear the cost of its own failures.

That is the job of the data processing agreement. It is not a formality attached to a sales contract; it is the document the business will rely on when the Data Protection Board asks what it did to protect the data it handed to someone else.

Fiduciary, processor, or both?

Before drafting, decide what role each party plays, because the terms follow from the roles. The Act defines a data fiduciary as a person who, alone or with others, determines the purpose and means of processing personal data, and a data processor as a person who processes personal data on behalf of a fiduciary. The test is about control, not about who holds the data or who is bigger.

Some practical questions help:

• Who decided to collect the data, and why? The party that chose the purpose is normally the fiduciary.
• Could the vendor use the data for its own ends? If it may, for those ends it is a fiduciary.
• Does the vendor have its own relationship with the individuals? A bank, insurer or courier often does, and acts as a fiduciary in its own right.
• Is the vendor merely following specifications? Hosting, software operation and outsourced processing to instructions point to a processor.
• Do two businesses decide the purposes together? Then they may be fiduciaries jointly, and the contract should divide their duties.

Roles are decided activity by activity. A payroll company is a processor when it calculates salaries for an employer, and a fiduciary for its own sales database. A SaaS provider is a processor for the records its customers store, and a fiduciary for the account details of the customers’ administrators. The agreement should say which activities fall on which side, so that the processor terms apply only where they belong.

Which vendors need one

A useful first step is a list of every outside party that touches personal data. The table shows common vendors and their typical role; the real answer depends on the arrangement.

Most small and mid-sized businesses find ten to thirty vendors on this list. They do not all need the same depth of contract; a vendor that stores thousands of health records needs more than one that sends appointment reminders. But each processor needs a written contract that covers the essentials. Because an individual may ask a fiduciary for the identities of the other fiduciaries and processors with whom their data has been shared, the list itself is also something the business must be able to produce.

What the Act and the rules require

The Act does not prescribe a form of contract. Its requirements for the fiduciary, which a processor contract must support, are spread across Section 8 and the rules. Our DPDP guide lists the core contract points; the table below maps each statutory duty to the clause that carries it into the vendor relationship.

The rules add detail. As notified, they describe reasonable security safeguards to include measures such as encryption, masking or tokenisation of personal data, access controls, logging and monitoring, and backups, and they expect the fiduciary’s contract with its processor to provide for appropriate safeguards. They also set out what a breach intimation must contain, with a detailed report to the Board within a fixed period after the fiduciary becomes aware of the breach. The text and the commencement dates of each rule should be checked when the agreement is signed; the point for drafting is that the processor’s obligations must be at least as demanding as the fiduciary’s, and faster, because the fiduciary cannot act until it knows.

For the scale of the penalties that sit behind these duties, see our DPDP penalties table. Significant data fiduciaries, if notified, have further duties such as audits and impact assessments; those are described in the same guide, and they usually flow into their vendor contracts too.

How the agreement is built

A data processing agreement works best as a short set of main terms with detailed annexes. The main terms state the obligations in general words that do not change from vendor to vendor; the annexes contain the facts that do change.

It can be a stand-alone agreement or a schedule to the main services contract. Either way, it should say that its terms prevail over the services contract on data protection matters, and that it lasts as long as the processor holds any of the fiduciary’s personal data, even if the services contract ends earlier.

Describing the processing

Annex 1 is the most neglected part of most agreements, and the most useful. It forces both sides to write down what is actually happening. It should list:

• Individuals: customers, patients, students, employees, job applicants, website visitors, vendors’ staff.
• Categories of data: identity and contact details, financial details, health records, location, call recordings, identity document numbers, children’s data.
• Purposes: the specific services the processor performs, such as “hosting and operating the appointment system” or “inbound calls to book sample collection”.
• Operations: collection, storage, retrieval, analysis, transmission, deletion.
• Duration: the term of the services, plus any agreed retention period.
• Locations: where the data is stored and from where it is accessed, including support teams and backups.

A precise annex limits the processor to what was described, supports the fiduciary’s own records and notices, and shows immediately which vendors hold the most sensitive data — those are the ones whose contracts deserve the most attention.

Instructions and purpose limits

The defining feature of a processor is that it acts on the fiduciary’s behalf. The agreement should therefore say that the processor processes personal data only on the fiduciary’s documented instructions, which include the services contract, the annex and any later written instructions, and for no other purpose.

Three refinements are common. First, if the processor believes an instruction would breach the law, it must tell the fiduciary, and may suspend that instruction until it is clarified. Second, if the law requires the processor to process data in a way not instructed — for example, a disclosure to an authority — it must tell the fiduciary before doing so, unless the law prohibits that. Third, instructions that go beyond the agreed services, and would cost the processor more, can be handled through the ordinary change process in the services contract; the data terms should not be used to extract free work.

People and confidentiality

Most breaches involve people — a misdirected email, a shared password, an employee who copies a customer list before leaving. The agreement should require the processor to give access only to staff and contractors who need it for the services, to bind them to written confidentiality obligations that continue after they leave, to train them in data protection and security, and to remove access promptly when their role changes.

For call centres and support teams, the practical controls matter more than the legal words: clean-desk rules, no personal phones on the floor where full customer records are displayed, masking of identity numbers and card details on screen, and recorded calls stored with restricted access. These can be listed in the security annex. A general non-disclosure agreement is useful before a vendor is appointed, but it does not replace the processing terms once personal data starts to flow.

Security safeguards

A clause that says the processor “will maintain reasonable security” tells neither side what to do. Annex 2 should describe the controls actually in place, at a level of detail that could be checked. A typical list covers:

• encryption of data in transit and at rest, and masking or tokenisation where full values are not needed;
• role-based access, multi-factor authentication for administrative and remote access, and periodic access reviews;
• logging of access to personal data, monitoring for unusual activity, and retention of logs for an agreed period consistent with the rules and CERT-In directions;
• secure configuration and timely patching of systems;
• separation of each customer’s data in shared systems;
• backups, tested restoration, and a business continuity plan;
• vulnerability scanning and periodic penetration testing;
• physical security of premises and devices, including laptop encryption;
• secure deletion and disposal of media; and
• a named security contact and an incident response plan.

The processor should be free to improve its controls but not to reduce them below the annex without the fiduciary’s agreement. Where the processor holds a certification, the annex can refer to it, but a certificate describes a management system; it does not replace a description of the controls that protect this fiduciary’s data.

Logs and the evidence trail

When a breach is investigated, the first question is who accessed what, and when. If the processor’s systems do not record access to personal data, or delete the records after a few days, nobody can answer, and the fiduciary cannot show the Board what happened or that it had reasonable safeguards. The DPDP rules, as notified, expect logs and related data to be retained for a minimum period for the purpose of detecting and investigating unauthorised processing, and the CERT-In directions separately require many service providers to keep system logs in India for a stated period.

The agreement should require the processor to log access to and changes of personal data by its staff and systems, to protect the logs from tampering, to keep them for at least the period the rules and directions require, and to produce the relevant logs to the fiduciary promptly on request after an incident. Where the fiduciary itself has users inside the processor’s system — staff logging in to a software platform, for example — the processor should give the fiduciary access to its own audit trail. Logs are themselves personal data about staff and users, so they should be kept only as long as needed and secured like any other record.

Breach notice from the processor

The fiduciary must intimate a personal data breach to the Board and to each affected person, as our DPDP guide on breaches explains, and the rules fix a short period for the detailed report to the Board. Separately, the CERT-In directions require many cyber security incidents to be reported within six hours of being noticed. Neither clock waits for a vendor to finish its internal investigation. The processor clause must therefore be faster and more specific than the fiduciary’s own duty.

A workable clause requires the processor to:

1. notify the fiduciary’s named contact without undue delay, and in any event within a short fixed period — many fiduciaries ask for twenty-four hours, or less where CERT-In reporting may apply — after becoming aware of a breach affecting the fiduciary’s data;
2. provide what it knows at once, and the rest as it becomes available: what happened, when, which data and individuals, likely consequences, and what has been done to contain it;
3. take immediate steps to contain the breach and preserve evidence;
4. cooperate with the fiduciary’s investigation, reports to the Board and communications to affected people;
5. not notify the fiduciary’s customers or the public itself, unless the law requires it, without agreeing the message; and
6. provide a written report of the root cause and the corrective actions.

The clause should also say who bears the cost of notifications and remediation when the breach was the processor’s fault — one of the most expensive and most frequently argued points after an incident.

Helping with individuals’ requests

Individuals may ask the fiduciary for a summary of their data and the processing, and for correction, completion, updating or erasure; they may raise grievances and nominate someone to act for them. The fiduciary must answer, but the data may sit in a vendor’s system. The agreement should require the processor to pass on any request it receives directly, without responding itself unless instructed; to provide the tools or assistance needed to find, correct, export or erase an individual’s data within a set number of days; and to tell the fiduciary which of its sub-processors hold that individual’s data. The fiduciary’s own response time under its grievance mechanism should drive the processor’s deadline.

Retention, return and erasure

The Act requires the fiduciary to erase personal data when it is no longer needed for the specified purpose, or when consent is withdrawn, unless the law requires retention, and to cause its processors to erase data made available to them — as set out in our retention section. A processor contract should provide:

• deletion of specific records on the fiduciary’s instruction, within a stated period;
• at the end of the services, return of all personal data in a usable, agreed format, followed by deletion — or deletion without return, at the fiduciary’s choice;
• deletion from backups within a stated period, or isolation of backups until they are overwritten in the normal cycle;
• retention only of what the law requires the processor to keep, with the reason stated; and
• a written certificate of deletion signed by a responsible officer.

Returning data “in a usable format” should be defined. A database dump that no other system can read is not much use; a structured export with a data dictionary is.

Suspension, termination and moving to a new vendor

The data terms need their own exit rules, because personal data does not stop being the fiduciary’s responsibility when a contract ends. The agreement should allow the fiduciary to suspend further transfers of data, and to terminate the affected services, if the processor materially breaches the data terms, suffers a serious breach, or can no longer comply because of a change in law or location. It should also survive the services contract for as long as the processor holds any of the data.

For a planned change of vendor, a short transition period is useful: the old processor continues to hold and secure the data, exports it in the agreed format, answers reasonable questions from the new vendor about structure and fields, and deletes its copy only after the fiduciary confirms the migration is complete. During transition, both old and new vendors are processors, and both need terms in place. Where the processor also provides an ongoing service with measured levels, the exit and transition terms should be consistent with the service level agreement.

Sub-processors

Few vendors do everything themselves. A software provider uses a cloud host; a call centre uses a telephony platform; a payroll company uses a printing and dispatch firm. Each of these is a sub-processor, and a breach in any of them is a breach of the fiduciary’s data.

Two approaches are used. Under specific authorisation, the fiduciary approves each sub-processor in advance; this suits high-risk processing but is slow. Under general authorisation, the fiduciary approves an initial list and the processor may add or replace sub-processors after giving notice, with a right for the fiduciary to object on reasonable grounds and, if the objection cannot be resolved, to terminate the affected services without penalty. General authorisation is the norm for cloud and software services.

In either case, the processor must impose on each sub-processor data protection terms no less protective than its own, check that the sub-processor can meet them, and remain fully responsible to the fiduciary for the sub-processor’s performance. The list in Annex 3 should show each sub-processor’s name, what it does, what data it touches and where.

Evidence, audits and certifications

A fiduciary that relies on its processor’s promises needs a way to check them. Large vendors will not let every customer inspect their data centres; small vendors may have nothing to show. The agreement should strike a realistic middle:

• the processor provides, on request and at least annually, evidence of compliance — a current independent certification such as ISO/IEC 27001, an independent assurance report such as a SOC 2 report where available, recent penetration test summaries, and completed security questionnaires;
• the fiduciary may audit, itself or through an independent auditor bound by confidentiality, where that evidence is insufficient, after a breach, or where a regulator requires it, on reasonable notice and not more than once a year otherwise;
• the processor fixes material findings within agreed times; and
• regulators with powers over the fiduciary can inspect the processor where sectoral rules require it.

For small vendors without certifications, a signed annual self-assessment against the security annex, backed by the right to audit, is better than nothing and often reveals gaps worth fixing.

Where the data sits, and transfers

The DPDP Act permits transfers of personal data outside India except to countries the government notifies as restricted, while preserving any stricter rules in other laws; our DPDP guide on transfers explains the approach. For a processor contract, that general permission is only the start. The fiduciary needs to know, and the agreement should state:

• the countries where the data is stored, including backups and disaster recovery sites;
• the countries from which it is accessed, including by support teams and sub-processors;
• a duty to give advance notice before adding a new location, and a right to object;
• compliance with any sectoral requirement to store data in India; and
• what happens if a destination is later restricted by notification — typically migration within a stated period at the processor’s cost, or termination.

Requests from foreign authorities for access to data held abroad are another point to cover: the processor should notify the fiduciary, where the law allows, and resist requests that are not legally binding.

European and UK data handled in India

India’s outsourcing industry processes a great deal of personal data about people in Europe and the United Kingdom — customer service, claims handling, payroll, software support, medical transcription. When an Indian company does this work for a European client, the client’s law travels with the data.

Under the EU General Data Protection Regulation, a controller may use only processors that give sufficient guarantees, under a contract that contains the terms listed in Article 28: processing on documented instructions, confidentiality, security, conditions for sub-processors, assistance with individuals’ rights and with the controller’s own security, breach and impact assessment duties, deletion or return, and information for audits. Because the European Commission has not recognised India as providing adequate protection, the transfer to India usually also needs a transfer mechanism, most commonly the standard contractual clauses adopted in 2021 — the controller-to-processor module where the Indian company works for the European controller, and the processor-to-processor module where it works as a sub-processor. The European party is also expected to assess the laws of the destination country. For UK data, the UK has its own international data transfer agreement and an addendum to the EU clauses.

In practice, the European client will send its own paper. The Indian company should check that it can actually meet each obligation, that the clauses match the real flows — including any onward transfer to its own sub-processors — and that liability terms in the commercial contract are consistent. It should also remember that its duties under Indian law continue alongside: Indian security, breach reporting to CERT-In and Indian employment law all apply to its operations here. An Indian business that offers goods or services directly to people in the EU may be subject to the GDPR itself, which is a separate question worth specific advice.

Regulated sectors

The DPDP Act is a general law. Several regulators impose additional or stricter requirements on the businesses they supervise, and those requirements often have to be passed down to vendors by contract. The detail changes frequently, so the table indicates areas to check rather than current text.

A fiduciary in one of these sectors should attach a sector annex listing the requirements that apply, rather than rely on a general promise to “comply with applicable law”. The vendor needs to know what it is agreeing to.

Children’s and other sensitive data at vendors

Some processing carries more risk than the rest. Schools, coaching centres and education apps hold children’s data; clinics and labs hold health records; lenders hold financial details; recruitment firms hold identity documents. The Act imposes additional duties where children are concerned — verifiable parental consent, and no tracking, behavioural monitoring or targeted advertising directed at children, subject to the exemptions in the rules — explained in our DPDP guide on children. Those duties fall on the fiduciary, but a vendor that runs analytics or advertising tools inside a school app can breach them on the fiduciary’s behalf.

For this kind of data, the agreement should go further than the standard terms: a prohibition on any profiling, advertising or analytics use beyond the instructed service; data stored only in agreed locations; stricter access controls and shorter breach notice; named staff only; and, for health and financial data, a shorter retention period after the service ends. The fiduciary should also consider whether the vendor needs the full data at all, or whether pseudonymised records would do.

Requests from police and authorities

Processors are sometimes approached directly by the police, tax authorities or regulators seeking data about the fiduciary’s customers. Indian law gives various authorities powers to require production of documents and electronic records, including under the Bharatiya Nagarik Suraksha Sanhita and the Information Technology Act, and a processor cannot ignore a lawful demand.

The agreement should require the processor to check that a request is lawful and in proper form, to disclose only what is legally required, to notify the fiduciary promptly before disclosing unless the law or the authority prohibits notification, and to keep a record of every request and disclosure. Where the request comes from a foreign authority for data stored abroad, the processor should notify the fiduciary and resist requests that are not legally binding on it. The fiduciary, as the party answerable to the individuals, should be the one to decide how to respond wherever the law allows it that choice.

AI, analytics and the processor’s own use

Vendors increasingly want to use the data they handle: to improve their products, to benchmark, to build aggregated insights, and to train machine learning models. Some of these uses are harmless when data is genuinely anonymised; others turn the vendor into a fiduciary for its own purposes, with its own duties of notice and lawful basis, and may breach the fiduciary’s promises to its customers.

The agreement should say plainly whether the processor may use the fiduciary’s personal data for any purpose of its own, including to train or fine-tune AI models, and if so, on what conditions. A common position is to prohibit use of personal data for the processor’s own purposes, to permit use of aggregated and anonymised statistics that cannot identify individuals or the fiduciary, and to require the processor to disclose any AI features that send data to third-party model providers. Our SaaS guide on AI training discusses the same question in subscription terms.

Liability, indemnities and insurance

Services contracts usually cap each party’s liability at the fees paid over a period. For data protection, that cap can be very low relative to the harm: a vendor paid a few lakh rupees a year can expose a fiduciary to investigation costs, notification costs, claims and penalties many times that. Common solutions are:

• A separate, higher cap for breaches of the data processing terms, often a multiple of annual fees or a fixed amount;
• specific heads of recoverable loss: forensic investigation, notification, call centre and credit monitoring for affected people, restoration of data, and reasonable legal costs;
• an indemnity for third-party claims caused by the processor’s breach; and
• cyber insurance of a stated amount held by the processor.

Penalties imposed by the Data Protection Board on the fiduciary raise a harder question. The penalty is for the fiduciary’s own statutory failure, and whether it can be passed on under a contract has not been settled; courts may be reluctant to allow a party to recover a penalty imposed for its own default. Drafting can still help: an indemnity expressed to cover losses “including, to the extent permitted by law, regulatory penalties” caused by the processor’s breach is common, and the negotiation usually turns on the cap. Our service level agreement guide discusses how caps and carve-outs fit together in ongoing services.

Reviewing a vendor’s addendum

Many businesses will never draft their own agreement for large vendors; they will be offered the vendor’s standard addendum, often written for European law. Reading it against a checklist is the practical answer.

Where a global vendor will not negotiate, record the gaps in an internal note, decide whether they are acceptable for the data involved, and compensate where possible — for example, by not sending that vendor sensitive data, or by encrypting data before it leaves your systems. Our DPDP compliance review includes a review of key vendor contracts.

If you are the processor

Indian SaaS companies, IT service providers, BPOs, payroll firms and agencies are processors for their clients, and larger clients now ask for data processing terms at every tender. A processor benefits from having its own standard agreement ready, because a reasonable standard document is accepted more quickly than a client’s draft is negotiated.

A processor’s standard terms should promise what it can actually deliver, describe its real security controls in an annex it can keep up to date, publish a sub-processor list, set breach notice at a period it can meet in practice, offer evidence of compliance in a standard form, limit audits to reasonable frequency and scope, provide assistance with requests at no charge for routine cases and at agreed rates for unusual volumes, and cap liability in a way its insurance supports. It should also map its own role: for any data it uses for its own purposes, it is a fiduciary and needs its own privacy notice.

Data sharing between two fiduciaries

Not every arrangement is fiduciary to processor. When a lender shares applicant data with a co-lending partner, a hospital refers patients to a diagnostic centre, an education consultant passes student details to universities, or two companies run a joint loyalty programme, each party may decide its own purposes. A data processing agreement is then the wrong document; the parties need a data sharing agreement.

A data sharing agreement records what data is shared, for which purposes each party may use it, who gives notices and obtains consents, how each will handle requests from individuals and how they will refer requests to each other, security expectations, breach cooperation, retention, and what happens when an individual withdraws consent. If the two parties decide purposes jointly, the agreement should allocate duties clearly between them, because each will be answerable for its own compliance.

Employee data and HR vendors

Employee data is often handled more casually than customer data, and it is sensitive: salaries, bank details, identity numbers, health information for insurance, background verification results, performance records. The Act allows an employer to process employee data for employment purposes without consent, but that does not relieve the employer of its duties to protect it or to control its processors.

HR vendors — payroll processors, attendance systems, insurance brokers, background verification agencies, recruitment platforms, learning platforms — should each be under processing terms. Background verification deserves particular care: the agency may contact previous employers, courts or police records, and the contract should require it to follow the law on each check and keep results confidential. The employer’s own HR policy should tell employees which vendors process their data and why.

A lean approach for small businesses

A shop, clinic or firm with a handful of vendors does not need a thirty-page agreement for each. A practical approach is:

1. list every vendor that touches personal data, and what data;
2. for global software and cloud vendors, accept their addendum after checking it against the table above, and keep a copy;
3. for local vendors, use a short standard processing schedule, of three or four pages, attached to the purchase order or service agreement;
4. send the most sensitive data only to vendors that have signed; and
5. review the list once a year.

This does not remove the fiduciary’s responsibility, but it puts in place the valid contract the Act requires and gives the business something to show if it is ever asked.

Finding every vendor that touches personal data is one step of a wider exercise; our DPDP compliance review guide explains how a business builds its vendor register as part of a full review.

Keeping it current

A data processing agreement describes a relationship that changes: new features, new sub-processors, new locations, new data. The agreement should require the processor to notify changes that affect the annexes, and the fiduciary should review its key agreements at least once a year, when the law or rules change, and after any incident. Version the annexes, and keep previous versions, because in an investigation the question will be what was agreed at the time.

Stamp duty and signing

A stand-alone data processing agreement is an agreement under state stamp law, and signed paper or electronic versions should be stamped in the state of execution at the rate for general agreements, which is usually small; in Delhi, through e-stamp paper. Where the processing terms are a schedule to a services agreement that is already stamped, no separate duty is normally needed. Electronic signatures are valid, and a vendor’s online addendum accepted by clicking through binds in the same way as other online terms.

When something goes wrong

Most disputes arise after a breach, when the fiduciary wants information and money, and the processor wants to limit both. The agreement helps most if it has settled the practical points in advance: the timeline and content of notice, cooperation, who pays for notifications and investigation, and the cap. It should also give the fiduciary the right to suspend transfers of data, or to terminate, where the processor materially breaches the data terms, and require the processor’s full cooperation with any inquiry by the Data Protection Board.

Commercial disputes above the specified value generally require pre-institution mediation before a suit, and many services contracts choose arbitration. We prepare the agreement, breach and cooperation letters and legal notices. Representation before the Board, an arbitrator or a court is for your advocate, whose fee is engaged and paid by you directly; we do not quote, collect or share it. You can find an advocate through our directory.

An example: a diagnostic lab and its vendors

The West Delhi lab chain from the top of this page listed its vendors and found fourteen that touched patient or employee data. The laboratory software provider, the cloud host behind it, the SMS company, the call centre and the payroll processor were processors; the payment gateway and the courier that carried samples were treated as fiduciaries in their own right, and the lab adjusted its privacy notice to say so.

For the laboratory software, the lab negotiated a full agreement: reports and personal data stored in India, including backups; breach notice to the lab’s named officer within twelve hours with an initial report and full detail as it emerged; no use of patient data for the vendor’s own analytics or model training; a published sub-processor list with notice and a right to object; an annual security report; and a separate liability cap for data breaches, backed by cyber insurance. The call centre’s agreement added masking of test results on agents’ screens and a ban on personal phones on the floor. The SMS company’s standard addendum was accepted after the lab confirmed that message templates never included test results. The investigation into the leaked report found that a call centre agent had forwarded a screenshot; the contract’s notice, cooperation and cost clauses allowed the lab to meet its own reporting duties and recover its notification costs.

An example: a Noida BPO serving European clients

A customer service company in Noida handling calls and emails for retailers in Germany and the Netherlands kept receiving its clients’ long processing agreements, each slightly different, with standard contractual clauses attached. Negotiating each took weeks.

It prepared its own processor pack: a data processing agreement that met the Article 28 requirements and Indian law together; a security annex describing its real controls, updated every six months; a sub-processor list covering its telephony, ticketing and cloud providers with their locations; a standard evidence set including its certification and penetration test summary; and a completed version of the controller-to-processor clauses ready for the client’s signature, with the details of processing prefilled. Its breach notice commitment was set at a period its incident team could meet at night and on holidays. New clients began accepting the pack with small changes, and the company’s sales cycle shortened. It also found, while preparing the annex, that one team was exporting customer lists to spreadsheets on personal laptops, and stopped it.

Where data processing agreements go wrong

• No contract at all with local vendors, only a purchase order.
• A confidentiality clause mistaken for a processing agreement.
• Roles not analysed, so a vendor acting for itself is treated as a processor, or the reverse.
• An empty Annex 1, so nobody knows what data the vendor holds.
• “Reasonable security” with no description of controls.
• Breach notice “promptly” with no fixed period and no contact.
• No control of sub-processors or their locations.
• Silence on AI training and the vendor’s own use of data.
• Deletion at the end not verified, and backups forgotten.
• A liability cap too small to cover even notification costs.
• A GDPR template used for Indian processing, or Indian terms used for European data.

Our fee and what you get

A data processing agreement from us costs ₹3,999 and is ready in 2 – 5 days. We start from the actual data flows — what data, which vendor, for what, where — and draft for your side, whether you are handing data to a vendor or receiving it from clients.

We also review a vendor’s addendum against the checklist above. If a signed agreement needs stamping, the duty is charged at actual cost, and we tell you the total before we start. Should a dispute reach an arbitrator or a court, it is for your advocate, whose fee is engaged and paid by you directly; we do not quote, collect or share it.