Data Processing Addendum

The Customer is the Data Fiduciary, and Flincbyte is the Data Processor, for Recipient data: the personal data of people the Customer sends OTPs to through connectotp.

Terms not defined here have the meaning given in the DPDP Act, 2023, the DPDP Rules, 2025 or the Terms of Service. If this DPA and the Terms conflict on personal data, this DPA prevails.

The Customer will:

• Give Recipients notice under Section 5 of the DPDP Act, and have consent or a legitimate use under Section 7 for each OTP it sends.
• Send only numbers that asked for a code, and comply with Section 9 (children) where it applies.
• Give only lawful instructions.
• Keep its API keys secure.
• Handle Recipients’ requests to exercise their rights, as the Data Fiduciary.

Flincbyte will:

• Process Recipient data only on the Customer’s documented instructions. These are the Terms, the Customer’s API requests and its dashboard settings. Flincbyte will tell the Customer if it believes an instruction breaks the law.
• Not use Recipient data for its own purposes, except aggregated, de-identified statistics and protecting the service and other customers from abuse.
• Ensure everyone who processes Recipient data is bound by confidentiality.
• Keep the security safeguards in Annex A and review them regularly.
• Help the Customer, as reasonably needed, meet its obligations as Data Fiduciary, including breach notification and Data Principal requests.

The Customer authorises the sub-processors in Annex B.

Flincbyte will give at least 30 days’ notice, by email or in the dashboard, before adding or replacing one. The Customer may object on reasonable data-protection grounds. If the parties can’t resolve the objection, the Customer may end the Terms and receive a refund of unused, unexpired credits.

Flincbyte imposes data-protection obligations on each sub-processor that are no less protective than this DPA, and remains responsible for their performance.

Recipient data is stored in India.

When the WhatsApp or smart channel is used, the Recipient’s number and the message are transmitted to Meta, which may process them outside India. Section 16 of the DPDP Act permits this, and Flincbyte will stop any transfer to a country the Central Government restricts by notification.

The Customer can keep processing in India by sending with the SMS-only channel.

If Flincbyte receives a request from a Recipient, it will forward it to the Customer within 5 business days and will not answer it directly unless the Customer instructs it to.

Flincbyte will help the Customer access, correct or erase Recipient data within the times the DPDP Rules, 2025 allow.

Flincbyte will notify the Customer without undue delay, and in any case within 24 hours of becoming aware of a personal data breach affecting Recipient data. This gives the Customer time to meet its duties under the DPDP Act and Rules, including the detailed report to the Data Protection Board within 72 hours.

The notice will describe, as far as is known:

• The nature, extent, timing and location of the breach.
• Its likely impact.
• The steps taken to contain it.
• A contact person.

Flincbyte will report to CERT-In within 6 hours where its Directions apply. It will not notify Recipients itself unless the Customer instructs it to or the law requires it.

Flincbyte keeps Recipient data only for these periods:

After the Terms end, Flincbyte deletes Recipient data within 30 days, except logs it must keep by law, which it deletes when that period ends. Before the account closes, the Customer can export its delivery logs from the dashboard.

On request, Flincbyte will provide the information reasonably needed to show compliance with this DPA, including a summary of its security programme [TODO: and any certifications, e.g. ISO/IEC 27001].

Once a year, or after a breach, the Customer may audit, or appoint an independent auditor bound by confidentiality, on 30 days’ notice, during business hours and at the Customer’s cost.

The limitation of liability in the Terms applies to this DPA. This DPA lasts as long as the Terms do, and is governed by the law and dispute clause in the Terms.

• Encryption in transit (TLS 1.2 or higher) and at rest.
• OTP codes, API keys and passwords stored only as one-way hashes.
• Least-privilege, role-based access with multi-factor authentication. Access is reviewed regularly.
• Access and activity logs kept for one year, with monitoring and alerts.
• Rate limits per phone number, IP and API key, spend caps and SMS-pumping detection.
• Separate production and test environments, patching and vulnerability management.
• Encrypted backups, tested restores, and an incident-response plan that covers DPDP and CERT-In timelines.
• Staff confidentiality agreements and security training.
• System clocks synchronised to NIC/NPL time sources, as the CERT-In Directions require.