Security

Client records, message history and uploaded documents are stored in a managed PostgreSQL database and object storage hosted in Mumbai, India. A second copy of every uploaded document is kept in separate object storage, also in Mumbai.

The application that reads and writes that data runs on servers in Singapore. So while your data is stored in India, it is processed outside India. We state this plainly because a firm's own client-confidentiality obligations depend on knowing it.

These are the only third parties that touch firm or client data:

• Supabase — Database, authentication and document storage. (Mumbai (ap-south-1)).
• Amazon Web Services — The second, off-site copy of uploaded documents. Encrypted at rest and checked against a fingerprint taken when the file arrived, so a corrupted copy is refused rather than stored. (Mumbai (ap-south-1)).
• Railway — Application hosting and the scheduler. (Singapore).
• Cloudflare — DNS for tagada.in, and forwarding of email sent to hello@tagada.in. Since 27 Sep 2026 traffic to and from the site does not pass through Cloudflare: it goes straight to our servers, encrypted end to end. (Global).
• Meta (WhatsApp Business Platform) — Delivery of WhatsApp messages, when a firm has enabled real messaging. Messages and delivery receipts pass through Meta. (Global).
• Resend — Transactional email only: sign-in codes, verification, password resets, and the optional morning summary to a firm's own staff, which carries the firm's name and three counts but no client names. (United States).
• Sandbox (Quicko Infosoft) — The daily GST filing-status check, only for a firm that has switched it on. The client's GST number is sent to read the public filing record (which returns were filed, when, and the acknowledgement number). Nothing else about the client is sent. (India-based company; where it stores data is not yet confirmed in writing).

We do not use advertising, analytics or session-recording tools, and we do not sell or share data.

One more service runs alongside these but is deliberately kept outside that list. Sentry — Error diagnostics — the request path, the error, a stack trace — so a failure is noticed by us rather than reported by a firm. Configured so firm and client data is not sent: access tokens and upload links are stripped from every report before it leaves, because the link in a client's upload page is itself a credential. Stored in United States or EU — there is no India region.

We would rather state the reasoning than the reassurance: that is a promise about how we configure the tool, not a property of the tool, and it is only true because we keep making it true. It is tested in our code, and clause 7.2 of the pilot agreement holds us to it.

Every table is scoped to the firm that owns the row, and that separation is enforced by the database itself through row-level security — not only by the application. A mistake in application code cannot return another firm's clients, documents or messages.

A firm invites its own staff and grants each person a specific set of powers — managing clients, messaging clients, managing consent, managing compliances, managing the team, changing settings, exporting data and deleting clients are all separate permissions.

Every one of those is checked on the server on each request, so a permission a firm has not granted cannot be exercised by editing the page. Accounts require a verified email address, and any user can turn on two-factor authentication, which is then required at every sign-in.

Uploaded documents are stored privately. They are never publicly addressable: the dashboard fetches them through short-lived links that expire, and an upload link sent to a client is scoped to that one client and that one request.

Every document is fingerprinted (SHA-256) when it arrives. That fingerprint travels with the record and is included in a firm's data export, so a firm can prove a document is byte-for-byte what their client sent without needing us to vouch for it.

A client who has said STOP is never messaged again, on any path — not a bulk action, not a scheduled reminder, not a manual nudge. That refusal is checked in one place and there is no way around it.

Opt-in works differently, and we would rather be exact than sound stricter than we are. Anything Tagadasends on a firm's behalf requires an explicit opt-in first, decided in one place on the way out. The assisted nudge is not that: the CA sends it themselves, from their own WhatsApp, to their own client — so a client who has simply not been asked yet can still be messaged that way. A client who has refused cannot.

Reminders respect quiet hours, and there is a cap on how many times a client is chased before the work is handed back to a human.

Consequential actions — deleting a client, exporting data, changing a team member's powers, sending a message — are written to an audit log the firm can read. A message is recorded before it is sent, so a firm can never have sent something Tagada has no record of.

The database provider takes automated daily backups on our paid plan, in the same Mumbai region. Those backups cover the database but not uploaded files, which is why documents are separately copied to second storage in Mumbai — without that, a lost file would be gone permanently while its database row still said it existed.

The copying job reports its own health: whether it is configured, when it last ran, and whether anything is waiting. A mirror that quietly stopped would otherwise be invisible until the day it mattered.

We have verified that documents are copied off-site and removed on deletion. We have not yet performed a full restore drill, and will not describe one until we have.

If we become aware of a breach affecting personal data, we will notify affected firms without undue delay and report to CERT-In within the six-hour window Indian law requires. Firms are told what happened, what data was involved and what we did about it.

Found a vulnerability? Email hello@tagada.in with enough detail to reproduce it. We will acknowledge it, we will not take legal action against good-faith research, and we will tell you when it is fixed. We do not currently pay bounties.

Tagada is an early-stage product run by a small team, and it is more useful to a firm's due diligence to say so:

• We do not hold SOC 2, ISO 27001 or any comparable certification.
• We have not commissioned a third-party penetration test.
• We have not yet run a full restore drill from backup.
• We do not offer a contractual uptime guarantee or service credits.
• We are not a filing tool: Tagada never accesses the income-tax or GST portals on a firm's behalf, and never asks for a client's portal credentials.
• We do not skip Indian public holidays. Quiet hours are respected, but no national holiday calendar ships with the product, so a reminder can land on a gazetted holiday.

If any of these matter to your firm, tell us — knowing which ones are blockers is genuinely useful to how we prioritise.

Security questions, or a request about data held on your behalf? Email hello@tagada.in, or write to TAGADA, Dwarka, South West Delhi, Delhi 110077.