Data Processing Agreement
v1.0 · Effective 1 August 2026 · Last updated 29 July 2026
This document is published in English only. The English version is the one that applies.
In plain English
Your renters' details belong to your shop, not to us.
You decide what to collect and why. We only hold it and do what you tell us to do with it.
We do not use it for our own purposes, we do not sell it, and we do not train artificial intelligence on it.
If something goes wrong we tell you quickly, so you can do what the law asks of you.
When you leave, you can export it, and then we delete it.
A summary to help you read this. It is not the agreement — the sections below are.
1. What this agreement is, and who it binds
This Data Processing Agreement ("DPA") is part of the Terms of Service at https://vaadify.com/legal/terms-of-service. You accept it when you accept those terms. There is nothing extra to sign.
It is between:
- You — the business that uses Vaadify, called the "Shop" here; and
- Anbu Gnana Durai, sole proprietor trading as Rani Software Labs, who operates Vaadify, called "we", "us" and "our".
If this DPA and the Terms of Service disagree about the handling of personal data, this DPA wins.
2. Who is who
Under the Digital Personal Data Protection Act, 2023:
- The Shop is the Data Fiduciary for the personal data of its own customers and anyone else whose data it enters into Vaadify. The Shop decides what to collect, why, and for how long.
- We are the Data Processor. We hold and process that data only to provide Vaadify to the Shop, and only on the Shop's instructions.
We are not a Data Fiduciary for that data, we do not decide the purpose of it, and we do not use it for our own purposes.
Personal data about the Shop's own account — the owner, the staff, the billing details — is a different thing. For that we are the Data Fiduciary, and our Privacy Policy at https://vaadify.com/legal/privacy-policy applies.
3. What we process, and for whom
Whose data. The Shop's customers and renters, the people they name as contacts, and anyone else whose details the Shop chooses to enter.
What kinds of data.
| Category | Examples |
|---|---|
| Contact details | Name, phone number, alternative phone, email, postal address |
| Business identifiers | Company name, contact person, GSTIN |
| Transaction records | Bookings, items rented, dates, prices, deposits, payments, notes |
| Documents | Invoices, quotes, receipts and files the Shop uploads |
| Messages | WhatsApp and email messages the Shop sends its customers, and the record of consent to receive them |
| Government identity documents | Aadhaar, PAN, driving licence and voter ID numbers, where the Shop chooses to record them |
The last row is the sensitive one. Whether the Shop may lawfully collect and keep a government identity number is the Shop's decision and the Shop's responsibility. The field existing in Vaadify is not our advice that it should be used. Some identity numbers are restricted by law in ways that consent alone does not cure.
What we do with it. Store it, organise it, show it back to the Shop's own staff, produce documents from it, send messages the Shop asks us to send, back it up, keep it secure, and delete it. Nothing else.
How long. For as long as the Shop's account is open, and then as set out in section 10.
4. We act only on your instructions
We process the Shop's data only on the Shop's documented instructions. Those instructions are:
- this DPA and the Terms of Service;
- the Shop's own use of Vaadify — every setting chosen, message sent and record created is an instruction; and
- any further written instruction the Shop sends us, provided it is lawful and technically possible.
If we believe an instruction breaks the law, we will tell the Shop and may pause that instruction until it is resolved.
If the law requires us to process the data in some other way — a court order, for example — we will tell the Shop before we do, unless the law forbids us from telling.
We will not: sell the Shop's data, share it for anyone else's marketing, use it to train artificial-intelligence models, or use it to build a product for someone else.
5. Confidentiality
Everyone with access to the Shop's data is bound to keep it confidential, and that duty continues after they stop working with us.
Access is limited to those who need it to run or support the service. Today that is a very short list. We look at a Shop's data only when the Shop asks us to help with a problem, when we must to keep the service running or secure, or when the law requires it.
6. Security — what we actually do
These are the measures in place today. We have stated them narrowly on purpose: a security section is worth nothing if it describes an aspiration.
- Separation between shops is enforced by the database, not just the application. Every tenant-owned table carries a Postgres row-level security policy keyed to the shop, so one shop's query cannot return another shop's rows even if application code has a bug. The application connects with a restricted database role that cannot bypass those policies; the unrestricted role is used only for migrations.
- Government identity numbers are encrypted at rest with AES-256-GCM at the application layer. They are unreadable in the database and in any backup taken from it, and are shown masked in list views.
- Data in transit is protected with TLS, between the browser and us and between us and every service we depend on.
- Authentication is handled by Clerk, a specialist identity provider. We never hold passwords.
- Card and bank details never reach us. Payments run through Razorpay, which holds them.
- Backups are taken by our database provider and are encrypted.
- Access is role-based inside a shop. A shop keeper cannot see billing, and an owner controls who is in the workspace.
What we do not have, stated as plainly. We hold no security certification — not SOC 2, not ISO 27001. We have not commissioned an independent penetration test. We do not offer a bug bounty. We are a small company and would rather the Shop knew that than infer otherwise from a longer list.
7. Other companies we use
We use other companies to run Vaadify — hosting, the database, file storage, authentication, payments, email and messaging. Each of them is a sub-processor.
Every one is named at https://vaadify.com/legal/sub-processors, together with what it does and the country its data sits in. Some of them hold data outside India. Indian law permits that except to countries the government restricts.
Before we add a new sub-processor, we publish it on that page with a new date, at least 30 days before it starts handling Shop data. The page can be watched for changes. If the Shop objects on reasonable grounds within those 30 days, it may raise it with us; if we cannot resolve it, the Shop may cancel without penalty for the remainder of its paid period.
Where a sub-processor must be replaced urgently — it stops trading, is withdrawn, or fails in a way that threatens the service or its security — we may replace it with less notice, publish the change as soon as we make it, and tell the Shop what happened. The right to object and cancel then applies afterwards rather than before.
Each sub-processor is bound by terms no weaker than these, and we remain responsible to the Shop for what they do with the Shop's data.
8. Helping you answer your customers
If one of the Shop's customers contacts us directly to see, correct or delete their data, we will not answer for the Shop. We will tell them to contact the Shop, and tell the Shop that they asked.
We will give the Shop reasonable help in answering such requests, and the product itself is the main way we do it: the Shop can view, correct, export and delete a customer's record without asking us for anything.
We will also give reasonable help with the Shop's own obligations around security and breach reporting, and with any assessment the Shop must carry out, so far as the information is ours to give.
9. If something goes wrong
If we become aware of a personal data breach affecting the Shop's data, we will tell the Shop without undue delay, and in any event within 72 hours of becoming aware of it.
What we will tell the Shop, as far as we know it at the time:
- what happened and when;
- which categories of data and roughly how many people are affected;
- what the likely consequences are;
- what we have done and are doing about it;
- who to contact for more.
If we do not know everything at first, we will send what we have and follow up rather than wait.
The Shop is the Data Fiduciary, so the duty to notify the Data Protection Board of India and the affected people is the Shop's. We will give the Shop what it needs to do that. We will not notify the Shop's customers ourselves unless the Shop asks us to or the law makes us.
We keep an internal record of every breach and what was done about it.
10. When the agreement ends
When the Shop's account is closed, cancelled, or its plan ends without renewal:
- the workspace becomes read-only and exportable for 90 days;
- during that window the Shop can export its data at any time;
- after 90 days we permanently delete the Shop's data from our live systems. Copies inside encrypted backups age out on the backup provider's normal cycle and are not restored into service;
- deletion cannot be undone.
There are two exceptions, and both are our own records rather than the Shop's data. Neither contains anything about the Shop's customers.
Our billing records — our invoices to the Shop, the payments behind them, and the Shop's name, GSTIN and address on them. Tax and company law requires us to keep those for eight years.
The record that the Shop accepted these agreements — which documents, which version, the date and time, the email address of the person who accepted, and the IP address and browser their device reported. We keep this for eight years too. It is the only proof that this agreement existed at all, and the parts of it that matter most — the limit on our liability in section 24 of the Terms of Service, and the refund position — are the parts that only ever come up after a Shop has left. Deleting the proof along with the account would leave both sides unable to show what was agreed.
If the Shop wants deletion sooner than 90 days, write to [email protected] and we will do it, subject to those same two exceptions.
11. Checking that we do what we say
The Shop may satisfy itself that we are meeting this DPA by sending us a written questionnaire, once in any twelve months, and we will answer it within 30 days. We will also share whatever current security information we have.
We do not offer on-site inspection or a live audit of our systems, and we would rather say so than promise an audit right that a company of this size cannot honestly service. If a genuine incident affects the Shop, we will answer questions about it fully and outside that annual limit.
12. Liability, and the rest
Our liability under this DPA is subject to the limit in section 24 of the Terms of Service.
This DPA lasts as long as we process the Shop's data, and the parts that are meant to survive — confidentiality, deletion, liability — survive its end.
It is governed by the laws of India, and the courts at Chennai, Tamil Nadu have exclusive jurisdiction, as under the Terms of Service.
If the law about data protection changes in a way that means this DPA is no longer enough, we will publish an updated version under section 26 of the Terms of Service.
13. Who to contact about this agreement
Anbu Gnana Durai, for Rani Software Labs Email [email protected] 26/1 Ellaya Mudali Street, Korukkupet, Chennai, Tamil Nadu 600021, India
We acknowledge within two working days and resolve within fifteen working days. Full details at https://vaadify.com/legal/contact-and-grievance.