Security and privacy, stated plainly.

Encryption at rest

Our database, object-storage and hosting providers encrypt stored data at rest.

SOC 2 CC6.1, C1.1 · ISO/IEC 27001 A.8.24 · DPDP Rule 6(1)(a)

Encryption of call content inside our application

Since 4 Nov 2026, the transcript, summary, analysis, extracted answers and tool-call logs in each new business call's record are encrypted in our primary database with AES-256-GCM, under one platform-wide key protected by AWS KMS. Call recordings, calls stored before that date, and the copies our services keep outside the call record are not covered by this layer and rely on our providers' encryption at rest.

SOC 2 CC6.1, C1.1 · ISO/IEC 27001 A.8.24, A.8.11 · DPDP Rule 6(1)(a)

Customer credentials in a secrets store

Carrier and in-app push credentials that customers connect are kept in AWS Secrets Manager, not in our databases, and push credentials are write-only: once saved, they are never shown again, not even to our staff.

SOC 2 CC6.1 · ISO/IEC 27001 A.5.17, A.8.24 · DPDP Rule 6(1)(a)

Transcript redaction

You can turn on redaction per agent so that identifiers such as phone numbers, Aadhaar, PAN, card numbers and email addresses are removed from transcripts before they are stored.

SOC 2 C1.1, P3.1 · ISO/IEC 27001 A.8.11, A.5.34 · DPDP Rule 6(1)(a)

Agent memory controls

Agent memory is off until you turn it on, what is saved is redacted first, it is keyed by a one-way hash of the user id, and one person's memory can be erased.

SOC 2 P4.2, C1.2 · ISO/IEC 27001 A.8.10, A.5.34 · DPDP s.8(7)

Masking on the device

The in-app SDK masks PAN, Aadhaar, card numbers, phone numbers and email addresses in the screen context, variables and user traits it sends on its own, before they leave the device.

SOC 2 C1.1, CC6.7 · ISO/IEC 27001 A.8.11 · DPDP Rule 6(1)(a)

No training on your data

Graine does not use customer data to train or fine-tune general AI models, and a custom voice is made only from recordings the customer gives us for it; speech and language vendors apply their own terms, and some run model-improvement programs.

SOC 2 P4.1 · ISO/IEC 27001 A.5.34

Private voice clones

A cloned voice is visible only to the member who made it, and no one else can put it on an agent in Graine.

SOC 2 P2.1, CC6.1 · ISO/IEC 27001 A.5.34, A.5.15 · DPDP s.6

Data requests by person

An Admin can find one person's data across calls, transcripts, recordings and contacts, export it, correct it or erase it, and each request is tracked against the dates the law sets. An erasure covers our main database and recording storage; the copy of a call kept in a separate working store is not erased by it.

SOC 2 P5.1, P5.2 · ISO/IEC 27001 A.5.34 · DPDP s.11, s.12

Retention controls

You choose how long recordings, transcripts and campaign contact details are kept; past that they are removed automatically, while the record of each call and its charge stay. The copy of a call kept in a separate working store is not removed by this.

SOC 2 P4.2, C1.2 · ISO/IEC 27001 A.8.10, A.5.33 · DPDP s.8(7), Rule 8

Workspace offboarding

When a customer leaves, their workspace's data is exported and then deleted, with a certificate of what was removed, what the law requires us to keep and what the deletion doesn't reach. The copy of each call kept in a separate working store is not deleted by this.

SOC 2 C1.2, CC6.5 · ISO/IEC 27001 A.8.10, A.5.11 · DPDP s.8(7)

Replicated primary database

Our primary database is a managed three-node replica set run by our database provider.

SOC 2 A1.2 · ISO/IEC 27001 A.8.14, A.8.13 · DPDP Rule 6(1)(d)

Production hosting

The call platform runs on AWS in Mumbai, India. The subprocessor list below says where every other kind of data is processed.

SOC 2 CC6.4, A1.2 · ISO/IEC 27001 A.5.23, A.8.14

Encryption in transit

Our website, dashboard, API and call-streaming sockets use TLS 1.2 or 1.3 (older versions are refused), and browsers are told to use HTTPS only.

SOC 2 CC6.1, CC6.7 · ISO/IEC 27001 A.8.24, A.5.14, A.8.20 · DPDP Rule 6(1)(a)

Internal routes closed to the internet

Our load balancer blocks routes meant only for our own services, and accepts phone-number lookups only from our own servers.

SOC 2 CC6.6 · ISO/IEC 27001 A.8.20, A.8.22 · DPDP Rule 6(1)(b)

Service-to-service authentication

Our services prove themselves to each other with a shared secret compared in constant time; where none is configured, a route refuses every request instead of opening up.

SOC 2 CC6.1, CC6.6 · ISO/IEC 27001 A.8.5, A.8.20 · DPDP Rule 6(1)(b)

Rate limits

The public API is rate-limited per organisation and shows your limit in its response headers; the SDK's session routes and our public forms are rate-limited too, and our sign-in provider limits sign-in attempts.

SOC 2 CC6.1, CC7.2 · ISO/IEC 27001 A.8.6, A.8.20 · DPDP Rule 6(1)(g)

Browser security headers

The dashboard and the API tell browsers to use HTTPS only (HSTS), not to sniff content types and not to let other sites frame them; a content-security policy is running in report-only mode.

SOC 2 CC6.6, CC6.7 · ISO/IEC 27001 A.8.20, A.8.26 · DPDP Rule 6(1)(g)

Outbound request protection

Webhook deliveries and agent API tools refuse private and internal network addresses.

SOC 2 CC6.6 · ISO/IEC 27001 A.8.20, A.8.26

Health monitoring

Our services expose health checks and metrics, and send heartbeats to an external uptime monitor.

SOC 2 CC7.2, A1.1 · ISO/IEC 27001 A.8.16, A.8.6 · DPDP Rule 6(1)(c)

Roles

Every workspace member is an Admin, a Member or View only, and Admins can create custom roles that hold exactly the permissions they choose; a role is read live, so a change applies without a sign-out.

SOC 2 CC6.1, CC6.3 · ISO/IEC 27001 A.5.15, A.5.18, A.8.2 · DPDP Rule 6(1)(b)

Per-agent access

A person can be limited to chosen agents, and anything outside their access is hidden from them.

SOC 2 CC6.3 · ISO/IEC 27001 A.5.15, A.8.3 · DPDP Rule 6(1)(b)

Maker–checker approvals

A Member's go-live, change to a live agent or campaign launch can wait for another person's approval, and nobody can approve their own request.

SOC 2 CC6.3, CC8.1 · ISO/IEC 27001 A.5.3, A.8.32

A passing test run before go-live

An Admin can require an agent's latest test run to pass before the agent goes live, whether it goes live from the dashboard or through the API.

SOC 2 CC8.1 · ISO/IEC 27001 A.8.29, A.8.32

Workspace isolation

Every request acts only on the caller's own workspace, another workspace's data answers "not found", and an automated test sends a foreign id to every route that takes one.

SOC 2 CC6.1, CC6.3 · ISO/IEC 27001 A.8.3, A.5.15 · DPDP Rule 6(1)(b)

Sub-account isolation

Each sub-account is a separate workspace with its own data and people, and only its parent organisation can manage it.

SOC 2 CC6.1 · ISO/IEC 27001 A.5.15, A.8.3

Scoped API keys

API keys carry scopes, and a key a Member creates can never do more than a Member can.

SOC 2 CC6.1, CC6.2 · ISO/IEC 27001 A.5.16, A.5.17, A.8.2 · DPDP Rule 6(1)(b)

Two-step sign-in

A password sign-in asks for a one-time code sent to the member's email before the session starts.

SOC 2 CC6.1 · ISO/IEC 27001 A.8.5 · DPDP Rule 6(1)(b)

Access reviews

Admins review who has access (roles, agents, sub-accounts and API keys) and record that the review was done.

SOC 2 CC6.2, CC6.3 · ISO/IEC 27001 A.5.18 · DPDP Rule 6(1)(b)

Verifiable audit trail

Changes in your workspace are written to an append-only, hash-chained audit trail that you can verify yourself, in the dashboard or through the API.

SOC 2 CC7.2, CC4.1 · ISO/IEC 27001 A.8.15 · DPDP Rule 6(1)(c)

Complete audit export

A complete export of your audit trail, with a check that its chain is unbroken, for your own archive or SIEM; the dashboard also downloads the Activity log with its proof.

SOC 2 CC7.2 · ISO/IEC 27001 A.8.15, A.5.33 · DPDP Rule 6(1)(c), Rule 6(1)(e)

Security log

A log shows every security check each of your agents makes, with its result and reason, and every change to an agent's security settings with the member who made it; rows are kept for a year.

SOC 2 CC7.2 · ISO/IEC 27001 A.8.15, A.8.16 · DPDP Rule 6(1)(c)

Signed webhooks

Webhooks we send are signed with HMAC-SHA256 over a timestamp and the exact bytes sent, so your systems can check they came from us.

SOC 2 CC6.7 · ISO/IEC 27001 A.8.24, A.5.14

Allow-listed SDK keys

Publishable keys for the in-app SDK and the web widget work only from the websites and apps you allow, and are rate-limited.

SOC 2 CC6.1, CC6.6 · ISO/IEC 27001 A.5.15, A.8.5 · DPDP Rule 6(1)(b)

Verified apps and verified users

For an in-app agent you can require proof of the app (Apple App Attest or Google Play Integrity) and proof of the user (a signed identity or your own sign-in); each is off until you turn it on, with a report-only stage first.

SOC 2 CC6.1, CC6.2 · ISO/IEC 27001 A.5.16, A.8.5 · DPDP Rule 6(1)(b)

Consent for WhatsApp calls

A WhatsApp call goes out only when a consent from the person being called is on record.

SOC 2 P2.1 · ISO/IEC 27001 A.5.34 · DPDP s.6

Cookie consent

Analytics and the support chat on our website load only after you agree, and you can change your choice at any time.

SOC 2 P2.1 · ISO/IEC 27001 A.5.34 · DPDP s.6

Privacy notice

Our privacy policy says what we collect, why, who processes it, how long we keep it and how to use your rights.

SOC 2 P1.1, CC2.3 · ISO/IEC 27001 A.5.34 · DPDP s.5, Rule 3

Grievance and rights requests

Anyone can raise a grievance or a data-rights request on our website or by email, gets a ticket number, and gets a reply within 30 days; we never take longer than 90.

SOC 2 P8.1, P5.1 · ISO/IEC 27001 A.5.34 · DPDP s.8(10), s.13, Rule 14

A permission on every route

Every route in our API and dashboard declares the permission it needs, and an automated test fails the build for any route that doesn't.

SOC 2 CC6.1, CC8.1 · ISO/IEC 27001 A.8.26, A.8.29

Isolation and audit tests

Automated suites check workspace isolation, the audit chain, webhook signing and fail-closed internal routes.

SOC 2 CC4.1, CC8.1 · ISO/IEC 27001 A.8.29, A.8.25

Tests in the build pipeline

Every service's test suite runs in our build pipeline on each change, and a failing suite marks the change as failed.

SOC 2 CC8.1 · ISO/IEC 27001 A.8.25, A.8.29, A.8.32

Dependency and secret scanning

Scans for vulnerable dependencies, committed secrets, code weaknesses and misconfiguration run on every change and every week, and report what they find to our engineers.

SOC 2 CC7.1, CC8.1 · ISO/IEC 27001 A.8.8, A.8.29

Subprocessor inventory

We keep a list of every subprocessor that handles customer data, with what each one processes and where, and publish it on this page.

SOC 2 CC9.2 · ISO/IEC 27001 A.5.19, A.5.21 · DPDP s.8(2)

Published data locations

We publish where each subprocessor processes data. A location we have not confirmed shows "On request" instead of a guess.

SOC 2 CC9.2 · ISO/IEC 27001 A.5.19, A.5.23 · DPDP s.16, Rule 15

Processor terms

Customers can ask for our data processing agreement, which sets out how we process personal data on their behalf.

SOC 2 P6.1, CC9.2 · ISO/IEC 27001 A.5.19, A.5.34 · DPDP s.8(2), Rule 6(1)(f)

Incident register

Security incidents are kept in a register with clocks for telling customers and regulators on time.

SOC 2 CC7.3, CC7.4 · ISO/IEC 27001 A.5.24, A.5.26 · DPDP s.8(6), Rule 7

Staff access logging

Each access by Graine staff to a customer workspace is recorded in that workspace's audit trail, with who acted.

SOC 2 CC6.2, CC7.2 · ISO/IEC 27001 A.8.15, A.5.18 · DPDP Rule 6(1)(c)

Vulnerability disclosure

Anyone can report a security issue to us; the contact is published on this page and in our security.txt file.

SOC 2 CC2.3, CC7.1 · ISO/IEC 27001 A.8.8, A.6.8

Internal security review

In October 2026 we reviewed the security of in-app chat and calls against ISO/IEC 27001, SOC 2 and DPDP controls, and fixed in code what the review found that code could fix.

SOC 2 CC4.1, CC3.2 · ISO/IEC 27001 A.5.35, A.8.8