This addendum is part of the Terms of Service between the firm that holds an account in the Confidential Dispatch application and Confidential Dispatch, a teamORQ business (registered name teamORQ Tech Solutions, GST 27AKSPR2500A1ZE; “we”, “us”, “our”). It sets out the terms on which we process personal data on the firm’s behalf, as Section 8(2) of the Digital Personal Data Protection Act, 2023 (DPDP Act) requires between a Data Fiduciary and its Data Processor. The firm accepted it when it accepted the Terms of Service, at sign-up or when a member joined; no separate signature is needed. The firm may save or print this page for its own records.
Words defined in the DPDP Act (personal data, Data Principal, Data Fiduciary, Data Processor, processing, personal data breach) have the meanings the Act gives them. “The firm” and “member” have the meanings the Terms of Service give them. The firm’s “clients” are the Data Principals whose documents and details the firm collects through the application.
1. What this addendum covers
a) Covered. Every item of personal data the firm collects, holds, views, downloads or deletes through the application: the documents its clients upload or fetch, the details its clients type in, and the names, mobile numbers and email addresses the firm enters for its clients so that a request can be sent to them. The firm enters those contact details on its own lawful basis under the DPDP Act, as data its client gave it directly; we hold them only so that the request can be sent and the record kept. This is the data for which the firm is the Data Fiduciary and we are its Data Processor.
b) Not covered. The firm’s own account data (its members’ names and email addresses, sign-in records, billing details, invoices). For that data we are the Data Fiduciary and our Privacy Policy applies. Services the firm or its clients choose outside the application (for example the firm’s own WhatsApp, or a client’s DigiLocker account) run under their own terms, as Section 7(e) of the Terms of Service says; this addendum applies from the moment data reaches the application.
2. The roles
The firm decides what to collect, from whom, for what purpose and for how long. It is the Data Fiduciary for that data and carries the duties the DPDP Act places on a fiduciary. We process that data only on the firm’s behalf and only as this addendum and the Terms of Service describe. We are the firm’s Data Processor. Nothing in this addendum makes us a fiduciary for the firm’s clients’ data, and nothing in it transfers a fiduciary’s duty to us.
If the firm, as part of its own practice, collects data through the application on behalf of another organisation, the firm is responsible for having that organisation’s authority to use us, and this addendum applies between the firm and us as if the firm were the fiduciary.
3. What we process, and why
The data. Documents and details the firm asks its clients for (identity documents, financial and other records, form fields), and the client’s name, mobile number and email address. The firm chooses the items; the application does not add to them.
The people. The firm’s clients: the people whose details the firm has entered, sends a request to, or whose consent it records.
What we do with it. Receive it through the request link, encrypt and store it, show it to the firm’s authorised members, let them download it, keep the record of what happened to it, delete it when its period ends or when a right is exercised, and carry out the rights actions the firm takes in the application.
Why. Only for the purpose the firm stated in the notice its client saw, and to operate the application for the firm. Never for a purpose of our own. We do not use the firm’s clients’ data to train models, build profiles, market anything, or for analytics beyond the aggregated, de-identified usage counts Section 16(d) of the Terms of Service describes.
For how long. For as long as the firm holds the data in the application, under the retention period the firm set for each request, and then as Sections 8 and 9 of this addendum describe.
4. Instructions
a) The application is the instruction. The firm instructs us through the application: creating a request fixes what is collected, for what purpose and for how long; sending a link, viewing or downloading a document, ending a relationship, answering a rights request and deleting data are each an instruction we carry out. We process the firm’s clients’ data only in these ways and in the ways this addendum and the Terms of Service set out.
b) Instructions outside the application. If the firm needs something the application does not provide, it writes to [email protected]. We carry out an instruction given this way where the application and the law allow it; where we cannot, we say so. We do not act on an instruction that would require us to break the law, and we tell the firm if we believe an instruction would.
c) What we do without an instruction. Only what the law compels (Section 13© of the Terms of Service), what is necessary to investigate a report under Section 13(b) of the Terms of Service, and what is necessary to keep the service secure and running. In each case we do only what the situation requires and tell the firm unless the law prevents us.
5. Confidentiality and our people
a) We do not read the firm’s documents. Documents are encrypted individually before they are stored. Nothing in the ordinary operation of the service involves anyone at Confidential Dispatch opening a firm’s documents, and we have no duty to monitor what a firm collects. We open a document only if the firm asks us to in a support request, if we must to investigate a report of unlawful use, or if the law compels us; the firm is told in each case unless the law prevents it.
b) Who can reach the systems. Access to the servers and the storage that hold the firm’s data is limited to the people who operate the service, each with their own credentials and multi-factor authentication. Each of them is bound to keep the firm’s data confidential and to use it only as this addendum allows.
c) The firm’s members. Who inside the firm can see, download, export or delete its clients’ data is set by the firm through roles in the application, and is the firm’s responsibility under Section 8(e) of the Terms of Service.
6. Security
We operate the application with reasonable security safeguards, and keep them under review. The measures in force today:
- In transit: every connection to the application is encrypted (TLS); plain HTTP is refused.
- At rest: every document is encrypted on its own with AES-256-GCM before storage. Document keys are wrapped by a key held for each firm, which is in turn protected by a master key in AWS Key Management Service in Mumbai; the master key never leaves that service. The server disks and the database are also encrypted at rest. Backup copies are encrypted.
- Separation between firms: every database query runs under row-level security as a restricted application role, so one firm’s records cannot be read through another firm’s session, by the application or by its operators acting through it.
- Sign-in: passwords are stored as Argon2 hashes; two-factor authentication is available to every member; repeated failed sign-ins pause the account; sessions expire.
- Record of access: every view, download, export and deletion of a client’s data by the firm is written to the firm’s tamper-evident record (Section 10).
- Deletion: when data is deleted, the key that protects it is destroyed, so every stored copy, including copies inside backups, becomes unreadable at once. Backup copies themselves expire within 30 days.
- Edge protection: the application is reached only through Cloudflare; requests that bypass it are refused at the server; the public endpoints are rate-limited.
- Monitoring: availability and the daily jobs (retention, anchoring, verification) are monitored, and a failure alerts us.
Our Privacy Policy and documentation describe these measures for a general reader. We will not reduce a safeguard listed here without replacing it with one at least as strong, and if we materially change how the firm’s data is protected we tell the firm’s admins by email.
7. Sub-processors
a) Who they are. We use the following providers to process the firm’s clients’ data on our behalf. Each is bound by a written contract that requires it to protect the data and to process it only on our instructions, and we remain responsible to the firm for their work.
| Sub-processor | What it does for us | Where the data is |
|---|---|---|
| Amazon Web Services | Runs the application server and database, stores the encrypted documents, holds the encryption keys, keeps the encrypted backups and the tamper-evident anchors, and delivers the emails sent to the firm’s clients (Amazon SES) | India (Mumbai region) |
| Cloudflare | Serves and protects the application: DNS, encryption of the connection, filtering of hostile traffic, rate limiting | Connection data (such as the visitor’s IP address and the page requested) passes through Cloudflare’s global network; no document, name or form content is stored by Cloudflare |
| Zoho (ZeptoMail) | Delivers the emails sent to the firm’s own members (for example the daily summary and a notification that a client has sent documents); these may name a client | India |
Our payment provider (Razorpay) handles the firm’s billing data, not its clients’ data, and is listed in the Privacy Policy rather than here.
b) Changes. A change to a sub-processor that holds the firm’s data at rest (the server, the database, the document storage, the key service or the backups) is notified to the firm’s admins by email at least 7 days before the move, with the new provider named. Any other sub-processor may be changed at once; we update the list above and tell the firm’s admins by email when the change is made.
c) Objecting. A firm that does not accept a change may end its plan by writing to [email protected] before the change takes effect, or within 30 days of our notice where the change has already been made; we refund the unused part of the period it has paid for, and Sections 11 and 12 of the Terms of Service apply to its data and its export.
8. Where the data is
The firm’s clients’ data is stored in India. Documents, the database, the keys, the backups and the tamper-evident anchors are all held in the Mumbai region, and emails to the firm’s clients are sent from India. The one category of data that is processed outside India is connection data passing through Cloudflare’s network to reach the application; it carries no document, name or form content. We do not move the firm’s clients’ data outside India, and we do not permit a sub-processor to, without first telling the firm under Section 7(b).
9. Retention, deletion and return
a) During the agreement. Data is kept for the period the firm set when it created the request, and is deleted automatically when that period ends, or earlier when the firm deletes it or a client’s right is carried out. Where the firm has recorded a legal basis to keep data longer, it is kept for that period and then deleted. Deletion is by destruction of the key, as Section 6 describes.
b) Export at any time. The firm may export all of its data and its compliance evidence from Settings at any time, as Section 12 of the Terms of Service describes. We do not prepare or hand over an export outside that route.
c) At the end. When the firm’s account ends, by its choice, by non-payment or by termination, the lifecycle in Section 11 of the Terms of Service runs, and the firm’s data is erased at its end: keys destroyed, documents deleted, personal data removed. The firm takes its export before then. After erasure nothing remains to return, and we confirm the erasure in writing on request.
d) What remains. The firm’s tamper-evident record, which is hashes, times and event names and contains no document content and no personal data; and the tax invoices Section 10(g) of the Terms of Service describes, which carry the firm’s billing details only. The record that a client gave and withdrew consent is part of that chain and is kept as the law requires.
10. Helping the firm meet its own duties
a) The record. Every request, notice version, consent, view, download, deletion and rights action is written to a tamper-evident, hash-chained record, anchored daily to write-once storage. The firm can see its record in the application and take it in its export, with what is needed to verify it without us.
b) Clients’ rights. The application gives the firm the means to carry out each right its clients have under the DPDP Act: to see and receive a copy of their data, to have it corrected, to have it erased, to withdraw consent, to raise a grievance and to nominate. A client withdraws consent on the page their receipt links to, without the firm’s involvement. The other rights are raised with the firm and answered by the firm in the application within the time the law allows. If a client writes to us about data a firm holds, we pass the request to the firm’s admins without delay and point the client to the firm; we do not answer on the firm’s behalf.
c) Breach notification. If a personal data breach in our systems affects the firm’s clients’ data, we tell the firm’s admins by email without undue delay after we become aware of it, with what we know: what happened, which data is affected as far as we can tell, what we have done and what we recommend. We keep the firm informed as we learn more. Notifying the affected clients and the Data Protection Board of India is the firm’s duty as the fiduciary; the application’s breach register and letter templates are there to help it do so, and we answer the firm’s questions for its report.
d) Showing compliance. This addendum, the Terms of Service, the Privacy Policy, the documentation and the firm’s own export are the primary way we show how we process the firm’s data. On a written request to [email protected] we answer the firm’s reasonable questions about the safeguards in Section 6 and this addendum, for the firm’s own records or for an enquiry from the Data Protection Board. Help that goes beyond this, such as a bespoke report or data prepared in a form the application does not produce, is agreed and priced in advance. We do not offer on-site audits. If the Board or another authority asks us about the firm’s data, we cooperate and tell the firm, unless the law prevents us.
11. Our duties under the law
Nothing in this addendum reduces a duty the DPDP Act or its Rules place on us directly, and nothing in it transfers to us a duty the law places on the firm as the fiduciary. Where the law changes in a way that requires a change to this addendum, we make the change under Section 12(b).
12. Term, changes and precedence
a) Term. This addendum applies from the moment the firm’s account is created and for as long as any of the firm’s clients’ data is in the application, through the lifecycle in Section 11 of the Terms of Service, until erasure.
b) Changes. We may update this addendum as the Terms of Service allow (Section 18): a change that materially affects the firm is notified by email to its admins at least 30 days before it takes effect; for other changes the “Last updated” date above is the notice. The version of the Terms of Service the firm accepted is recorded in its tamper-evident record, and this addendum is part of that version.
c) Precedence. On the processing of the firm’s clients’ personal data this addendum prevails over the Terms of Service; on everything else the Terms of Service prevail. Liability under this addendum is governed by Section 15 of the Terms of Service, including the cap and the carve-outs for a breach of our security and confidentiality obligations. Governing law and disputes are governed by Section 21 of the Terms of Service.
13. Contact
Questions about this addendum, instructions outside the application, and sub-processor objections: [email protected]. Anything about personal data we ourselves hold about the firm’s members: [email protected], as set out in our Privacy Policy.