Data security policy

Section 43A of the Information Technology Act, 2000 makes a company that handles sensitive personal data liable if it fails to keep “reasonable security practices and procedures”, and Rule 8 of the 2011 Rules requires those practices to be documented. This is that document. It says what we do, what the law requires of us, what we ask of you, and — in section 11 — what we do not yet claim.

1. What we protect

• Account and team data: names, work emails, phone numbers, roles.
• Business verification documents, including the authorised signatory’s identity document, which is sensitive personal data.
• Call records, call recordings, WhatsApp and SMS content, contacts and notes.
• Transcripts and caller summaries produced by the voice AI agent, where a business enables it.
• The carrier credentials that allow calls and messages to be placed on a business’s account.
• Billing records and invoices.

2. Isolation between businesses

Every business runs in its own workspace. The separation is not a filter in the application: it is a set of row-level security policies on every table, evaluated by the database itself on every query. A signed-in person can read only rows their workspace and role allow. Functions that run with elevated privilege derive the workspace from the caller’s verified identity, never from a value the client sends, so a request cannot name another business’s workspace and be believed.

3. Encryption

• In transit. Every connection to the console, the API and the database uses TLS. Media between the telephone network and our platform is carried on the carrier’s encrypted channels.
• At rest. The database and file storage are encrypted at rest by our cloud provider.
• Credentials. The carrier credentials for each business are held in an encrypted vault inside the database and decrypted only at the moment a call or message needs them. They are never sent to a browser and never appear in a page or a log.

4. Access control

• Roles. An agent sees their own calls; a manager sees the team’s; an owner sees everything, including billing and the ability to add and remove people. The business assigns these roles and can change them at any time.
• Recordings and documents live in private storage that has no public address. Playback and download use a signed link that expires shortly after it is issued, so a link that leaks is a link that has already stopped working.
• Staff. SyncTalk staff can enter a business’s workspace only to investigate a support request or a security event. Every such entry is written to an audit log that the person making the access cannot edit or delete, and the business can see it.
• Secrets. Service keys and provider secrets are held in the platform’s secret store, never in source code, and the built console is checked for accidental inclusion of any privileged key before each release.

5. Retention and deletion

• Call recordings are kept for the retention period each business sets, 90 days by default. A job runs nightly and permanently deletes anything older. Nothing is archived.
• Diagnostic call events are pruned on a rolling schedule and are never kept beyond what the workspace needs.
• When a business closes its account, its workspace — contacts, recordings, transcripts, settings — is deleted, other than records a law names and requires us to keep.
• Server and access logs are kept for 180 days, as CERT-In directs, and then removed.

6. Where data lives

The database and file storage are hosted in the Singapore region of our cloud provider, on infrastructure that publishes its own physical, environmental and personnel security controls. Backups are taken by the provider and are encrypted. The DPDP Act permits this location today; if the Central Government restricts it, we will relocate the affected data within the period the notification allows.

7. Monitoring and instrumentation

Anything on the platform that can silently fail is required to write an event. When a call or a message misbehaves we read those events first, which means faults are found from the record rather than from a customer’s complaint. Failed logins, privilege changes and staff access are logged in the same way.

8. Incidents and breach notification

If we discover or are told of a security incident affecting your data, we will:

• contain it and preserve the evidence;
• report it to CERT-In within six hours of noticing it, as the directions issued under section 70B of the IT Act on 28 April 2022 require;
• notify the Data Protection Board of India and every affected person, in the form and time the DPDP Act and its rules require, where personal data is involved;
• tell the affected business what happened, what was touched, what we have done and what it should do — as soon as we know it, not once the story is tidy;
• write up the cause and change whatever let it happen.

9. What we ask of you

Security is shared. A business using SyncTalk is responsible for:

• keeping its users’ credentials private and removing people who leave;
• assigning roles to the least access each person needs;
• choosing a recording retention period that fits its own legal obligations;
• telling callers that calls may be recorded, where the law that applies to it requires;
• obtaining the consent its own customers’ data requires, and registering SMS headers and templates on the DLT platform as TRAI rules require;
• keeping any API keys or webhook secrets it is issued as private as a password.

10. Reporting a vulnerability

If you find a security weakness in SyncTalk, tell us before telling anyone else, through the contact page. Give us reasonable time to fix it, do not access data that is not yours, and do not test in a way that degrades the service for others. We will acknowledge within two working days and keep you informed until it is resolved. We will not take action against anyone who reports in good faith within these limits.

11. What we do not claim

We do not currently hold a third-party security certification such as ISO/IEC 27001 or a SOC 2 report, and we do not publish an uptime commitment or a latency figure, because none has been independently assessed. Our practices are modelled on the ISO/IEC 27001 controls that Rule 8 of the 2011 Rules points to, but modelling on a standard is not certification against it, and we will not describe it as such. If your evaluation needs one of these, ask us directly and we will tell you exactly where we stand.

12. Changes

We review this policy at least once a year and after any material incident. Account holders are told of material changes by email before they take effect.