DPDP vendor questionnaire

1. Who is your privacy contact?

Privacy questions: [privacy contact name and email]. Our Grievance Officer for account holders is named in the privacy policy [Grievance Officer name and email].

Security reports go to hello@chumbaq.com with “Security” in the subject. The contracting entity is [Qleverlabs Technologies Pvt Ltd or Qleverlabs Technologies Inc, and for which customers].

2. Do you support withdrawal of consent?

Yes. Your app or backend sends each person's choices to Chumbaq, and Chumbaq checks them when it picks who a message goes to.

• Email, SMS and WhatsApp sends skip anyone who opted out. By default they go only to people who opted in; a project can change that per channel.
• Every campaign email has a one-click unsubscribe link. A STOP reply stops SMS or WhatsApp to that number.
• Push sends skip devices whose user turned push off in your app, on every kind of send, test sends included.
• Do-not-track stops Chumbaq storing that device's behaviour and using it to pick audiences. When the project owner records an objection for a signed-in user (through the dashboard API; there is no screen for it yet), it covers all of their devices.

3. How quickly will you tell us about a personal data breach?

Section 7 of our draft DPA commits us to tell you without undue delay, and within [number of hours] hours, with what happened, who and what is affected, what we are doing about it and a contact person. That is so you can inform affected users and send the Data Protection Board of India the report Rule 7 asks for within 72 hours.

4. Do you transfer personal data outside India?

Our cloud service is hosted by [hosting provider] in [hosting region]. Section 10 of the draft DPA says we will not process your users' data in, or transfer it to, a country the Government of India restricts under section 16 of the Act. Where each of our sub-processors processes data is on the sub-processor list.

Data you send through your own push, email, SMS and WhatsApp providers goes where those providers process it. If you self-host Chumbaq in an Indian region, the data stays there and never reaches us.

5. Can you delete a person's data on request?

Yes, and you can do it yourself. The project owner can delete a person from their page in the dashboard, or your backend can call POST /api/privacy/erasures with a user id or device id and a server-only privacy key. POST /api/privacy/exports and the dashboard's Export data button give you a JSON copy of what we hold, for access requests.

A deletion is one transaction and safe to repeat. Opt-outs are kept as one-way hashes so the person isn't messaged again, campaign totals are kept as anonymous numbers, and the request is logged with ids stored only as keyed hashes. Database backups keep data until they expire, after [backup retention period]. The full list of what is kept is on our DPDP page.

6. Do your sub-processors have data processing agreements?

Section 9 of the draft DPA commits us to bind each sub-processor by a written contract with duties no weaker than ours, and to stay responsible to you for them. [confirm a signed DPA is in place with each sub-processor listed]. The sub-processor list names them. The push, email, SMS, WhatsApp and analytics providers you connect with your own accounts are your processors, under your own contracts with them.

7. Can you demonstrate compliance?

We have no certification to show you: there is no official DPDP certification, and we have no SOC 2 or ISO report yet. What we can show:

• The draft DPA, with an audit clause: once a year, or after a breach, on [notice period] notice.
• The security page, which lists what we store and how we protect it.
• A log of every deletion and export request in your project, with ids stored only as keyed hashes.
• A record of every consent change, with its time and source. There is no screen or export for it yet.
• The code itself: the SDKs and the server are open source.

8. What security measures do you have?

• Provider credentials, webhook signing secrets and Mixpanel credentials are encrypted with AES-256-GCM.
• API keys are stored as SHA-256 hashes, belong to one project, and can be revoked at once.
• Passwords are stored as bcrypt hashes; passkeys and authenticator apps are supported; failed sign-ins are rate limited.
• Staff access to an account is written to an append-only audit log, and viewing an account as its owner is read-only.
• The privacy key that can delete or export people is refused on every endpoint an app uses.

Encryption of the database and backups at rest, TLS on the hosted service, backups and monitoring: [confirm and describe the hosted deployment]. Section 6 of the DPA and the security page have the full list.

9. How long do you keep logs?

• Sign-in and security events: 365 days by default. The service refuses a setting below 180 days.
• Your users' events, clicks and message records: until you delete the person or the project. They don't expire on their own today.
• Deletion and export requests: kept as a log with ids stored only as keyed hashes.
• Database backups and application logs: [retention periods for backups and application logs].
• The DPDP Rules ask for processing logs to be kept for at least a year. How that applies after an erasure is with our lawyer [lawyer to confirm].

10. How do you handle children's data?

Chumbaq doesn't ask for or store your users' ages, so it can't tell who is a child. Section 4 of the draft DPA sets out your duty under section 9 of the Act: get verifiable consent from a parent before processing a child's data, and don't use Chumbaq to track, monitor the behaviour of, or target advertising at anyone under 18 unless an exemption applies to you.

If you know a user is a child, setting do-not-track on their device stops Chumbaq storing their behaviour.