The questions buyers actually ask us

TATA Tele Vishwaas AI is a DPDP-native Privacy & Consent Management Platform — a single system of record for consent decisions, privacy notices, Data Principal rights requests, breach incidents, and Data Processor agreements. It is built specifically for India's Digital Personal Data Protection Act, 2023 and the DPDP Rules 2025. Multi-tenant SaaS hosted in AWS Mumbai (ap-south-1) for India data residency by default, with self-hosted Kubernetes also supported. Explore the full platform at /platform. Tagline: Trust, Built into Every Byte.

Indian Data Fiduciaries with 500K or more Data Principal records — particularly BFSI, Healthcare, Telecom, E-commerce/D2C, EdTech, Travel/Hospitality, and Public Sector. It is especially relevant for organisations that are, or will be, classified as Significant Data Fiduciaries under DPDP §10. Mid-market starting points exist for organisations with 50K–500K records. Large groups with multiple legal entities can govern member tenants centrally via Enterprise Groups, where the Group Administrator is provisioned as an independent identity in a dedicated group-identity tenant — never hosted by, or anchored to, any one member tenant, and never itself a Data Fiduciary.

Accountability & Integrity. Vishwaas is Hindi for trust; the AI stands for the properties of the codebase — hash chains, cryptographic signatures, append-only audit, deterministic verification — not for language models or machine learning. We don't run LLMs on Data Principal data.

All 22 Eighth Schedule languages plus English: Assamese, Bengali, Bodo, Dogri, Gujarati, Hindi, Kannada, Kashmiri, Konkani, Maithili, Malayalam, Manipuri, Marathi, Nepali, Odia, Punjabi, Sanskrit, Santali, Sindhi, Tamil, Telugu, and Urdu. The Data Principal portal, the DP-facing consent copy on each Processing Activity, and notice content are all multilingual end to end.

Four things, in weight order. (1) The RoPA (Record of Processing Activities) module — a continuously-running Compliance Gap Engine over your Processing Activities register (event-driven plus a nightly cron, with 15 registered detectors monitoring all 15 declared gap types — including untracked_processing, live since v3.1 — covering DPDP §§5, 6, 7, 8(2), 8(7), 16), a 12-field RoPA register exportable as a branded 16-column PDF/CSV/Excel with a tamper-evident export audit trail, an interactive 5-lane Data Flow Map that flags unsafeguarded cross-border transfers, and a backend-authoritative compliance score. (2) Data Discovery — a read-only PII discovery engine that connects to your data stores across AWS, Azure and Google Cloud, databases, file shares and on-prem systems, and finds Aadhaar/PAN/mobile/email/GSTIN/card/UPI data at rest, with every finding held behind a DPO approval gate before anything downstream acts on it. (3) Enterprise Groups rebuilt on an Independent Identity model — the group admin is a genuinely independent identity in a dedicated group-identity tenant, not hosted by a member tenant. (4) DPBI escalation extended — all six Data Principal rights request types can now escalate to the DPBI once the applicable SLA elapses without resolution, not grievances only. (v2.9's headline — Offline Consent Collection, format-tolerant identity disambiguation, and VAPT hardening — all remain fully shipped.)

Yes — this was the v2.9 headline and it remains fully shipped. Offline Consent Collection ingests one CSV that mirrors the online portal: each row carries an action of grant or withdraw (mixed batches allowed in a single upload). Each person is resolved against your existing Data Principals by email/phone, with date-of-birth and name as disambiguators; ambiguous rows go to a Review queue rather than being guessed. Channels are limited to paper and verbal, both requiring a proof attachment, and a notice anchor is mandatory for every grant. Batches run up to 1 lakh (100,000) rows / 50 MB, processed in the background with live per-row status. Every grant passes the same six-step pre-collection chain as an online grant, and the CSV is hardened against formula injection because it is evidence you may need to rely on.

Yes — a dedicated module, not a re-badged export of an activities register. A Compliance Gap Engine runs continuously (event-driven plus a nightly cron) over your Processing Activities with 15 registered detectors actively monitoring all 15 declared gap types — including untracked_processing, live since v3.1 — covering DPDP §§5, 6, 7, 8(2), 8(7), and 16. It is a standing monitor, not a report you run once. The RoPA Register is a 12-field record, exportable as a branded 16-column PDF/CSV/Excel with an immutable, tamper-evident export audit trail (who/when/filter/row-count) that survives even after the 7-day download-link TTL expires. An interactive Data Flow Map (5 lanes: Data Principals → Activities → Systems → Processors → Cross-Border Destination) auto-lays-out your processing landscape and flags unsafeguarded cross-border transfers (§16) with a red dashed edge (truncating, with disclosure, at very large node counts). The compliance score is backend-authoritative and severity-weighted over open and acknowledged gaps, with a two-scan auto-resolve safety guard so a transient bad scan can't silently mass-close real gaps.

Yes — Data Discovery, shipped and generally available. It connects read-only to your data stores across AWS, Azure and Google Cloud, databases, file shares and on-prem systems (via an agent), samples content in memory, runs PII detectors (Aadhaar with Verhoeff checksum, PAN, mobile, email, GSTIN, payment card/Luhn, UPI, and more), and discards the raw sample immediately: only a fingerprint and location are stored. Every finding is a proposal, not a fact, until a DPO approves it — nothing downstream acts on an unapproved finding — with findings grouped for review (one row per container × file × category with an occurrence count) so a DPO reviews dozens of things, not thousands. Decisions: approve / reject / override / accept-risk (DPO-only, justification required, auto-returns after 90 days). The Findings & Gaps report cross-checks every system and data category against your Processing Activities. A minor-detector flags reliably-aged-under-18 values for DPDP §9 review — it detects children's data and routes it to a guardian-consent resolution path; verifiable parental-consent capture remains on our roadmap.

An 8-step onboarding wizard with live database checks. First tenant in production in 1–2 sprints (2–4 weeks). Source Binding and Downstream Binding integrations add 2–4 weeks per integration. Time-to-first-consent-record on a new tenant is typically same-day.

DPDP requires the Data Fiduciary to comply, not the platform. We are DPDP-native — every feature is mapped to a DPDP section, every default is set to DPDP standards, and several obligations are enforced as guardrails you can't accidentally skip: the Rule 3 publish gate, the mandatory minimisation rationale per attribute, the automatic breach clock, and the RoPA Compliance Gap Engine watching §§5/6/7/8(2)/8(7)/16 in the background. Customers using TATA Tele Vishwaas AI as their consent system of record have a substantially easier path to compliance than customers adapting GDPR-shaped tooling. New to the Act itself? Start at /dpdp-act.

It's hard-coded at the service layer. Grievance-type requests receive a 30-day SLA deadline from creation, per §13. All other Data Principal rights types (access, correction, erasure, nomination) get the 90-day statutory window. The SLA dashboard alerts at 75% / 90% / 100% of the window. DPBI escalation is available for every one of the six rights request types — once the applicable SLA elapses without resolution, escalation to the DPBI is one click; grievances additionally get an early escalation trigger the moment the organisation formally responds (completed/rejected), so a Data Principal doesn't have to run the full 30-day clock before escalating a grievance that's already been answered unsatisfactorily.

Every breach incident carries an 8-milestone tracker: discovery, assessment, containment, DPBI Tier-1 ≤ 72h, CERT-In ≤ 6h, DPBI Tier-2 ≤ 30d, remediation, closure. The breach clock starts automatically at discovery; the dashboard surfaces incidents past deadline. "Assess Scope from RoPA" on the breach screen resolves affected activities, data categories, estimated principal count, processors, and cross-border exposure in seconds and persists it to the incident record — turning the 72-hour clock into a scoped response instead of a manual scramble. Notification routes for Tier-1, Tier-2, CERT-In, and affected principals are first-class, driven by customisable multilingual templates.

Partially — and we're explicit about the boundary. The schema supports minor flags and guardian linkage; consent records can be linked to a guardian. Data Discovery adds a detector that flags reliably-aged-under-18 values found in your data stores and raises a gap asking whether verifiable parental consent exists — it detects children's data and routes it to a guardian-consent resolution path. Verifiable parental-consent capture remains on our roadmap, not yet shipped. Customers with paediatric-heavy practices should treat this as a near-term commitment, not a current capability.

Tenants can be flagged as Significant Data Fiduciaries, which surfaces §10-specific obligations: a DPO appointment workflow, a full DPIA register (inherent vs residual risk scoring, DPO approval guards, auditor findings), and independent-audit support (an auditor role with read-and-export-only access). SDF-specific dashboards and the DPBI ID requirement in the Rule 3 gate are conditionally rendered on the SDF flag. The RoPA Compliance Gap Engine's continuous coverage of §§5–8 and §16 is a natural fit for an SDF's higher accountability bar.

Four layers. (1) Every record carries a SHA-256 hash anchored to a tenant-specific genesis, chained to the previous record's hash, and signed with per-tenant RSA keys held in a dedicated key-management layer. (2) Each consent is anchored to the exact notice version, content-hash, and language the person saw. (3) Records carry an RFC 3161 trusted timestamp — on by default for new tenants — making them trusted-timestamped and cryptographically verifiable. (4) The consent-records table has UPDATE and DELETE revoked at the PostgreSQL role level, so application code cannot mutate history. The result is a tamper-evident, independently verifiable chain — see /trust and /why-vishwaasai-proof for the full evidence model.

Defence in depth. Layer 1 — service-layer isolation on every tenant-scoped table: every query is scoped to the tenant identity derived from the JWT, which is the only trusted source. Layer 2 — database-level PostgreSQL Row-Level Security on the most sensitive data — consent records, rights requests, breach incidents, data principals, notice deliveries, and the Data Discovery tables — enforced through a non-superuser application role as a fail-closed backstop, so a missing tenant filter returns zero rows instead of leaking. Layer 3 — attribute-based access control (CASL) denies even platform super-admins access to tenant data. We deliberately do not claim RLS on every table: it is the database-level backstop on the most sensitive data, with service-layer isolation everywhere.

OTP-only — no passwords are stored anywhere. Admins authenticate via email OTP; Data Principals via email OTP, SMS OTP, or single-use magic links. Shared-identifier disambiguation is symmetric: a shared phone routes to email-OTP and a shared email routes to phone-OTP, rather than either case being guessed. For enterprise admin access we also support SSO over SAML and OIDC — Cross Identity, Microsoft Entra ID, Okta, Ping, and ADFS — plus SCIM 2.0 for automated user provisioning and deprovisioning, so joiner/leaver changes in your IdP flow through automatically. (Group-level SSO/SCIM for Enterprise Groups is on our roadmap.) Authorisation is attribute-based across 11 customer-tenant roles plus platform roles, with step-up auth and rate-limiting.

Three complementary controls. "Reference, Don't Replicate" lets the platform keep only the control plane — the consent ledger, the attribute schema, and reference rows recording that an attribute exists, where it lives, and an integrity hash — while the actual values stay in your source systems and are fetched live, shown masked, once, and never stored. This is a per-tenant opt-in capability with an instant global kill-switch. The Primary-Identifier Vault keeps each phone/email in a dedicated encryption vault; the master database keeps only non-reversible hashes, values resolve on demand, and plaintext is redacted from logs and previews. Data Discovery follows the same discipline for content it scans: it stores only a fingerprint and location, never the raw PII value, and shows the DPO a masked value for review, not a hash.

Our security posture is positioned on verifiable architecture and controls — the cryptographic consent chain, database-level RLS on the most sensitive data, append-only audit, and OTP-only authentication described above — rather than on certificates alone; a certification roadmap is available under NDA. The platform undergoes an annual VAPT by a CERT-In empanelled firm. See /trust for the architecture-level detail.

AWS Mumbai (ap-south-1) for the SaaS tier — India data residency by default. For self-hosted deployments, customers run in their own Kubernetes (EKS / OpenShift) — typically in their own data centre or cloud region.

Yes. The full stack is Docker-Compose-able for development and Kubernetes-deployable for production: PostgreSQL 16, Redis 7, Kafka (KRaft), object storage, and nginx. Customers running on EKS, OpenShift, or hardened Kubernetes distributions are supported. Air-gapped deployment is on our roadmap — genuinely air-gapped installs are a custom delivery engagement today.

Every system that holds personal data is registered as a Processing System. Data flows in via Source Bindings (REST / SFTP / CSV) and out via Downstream Bindings in three modes: Push — HMAC-SHA256-signed webhooks with retry and dead-letter; Pull — your systems query our Redis-cached Consent Status API (sub-50 ms point lookup); SDK — embedded enforcement. For systems behind a firewall, the on-prem agent uses an outbound-only WebSocket, so no inbound firewall holes are needed. Data Discovery adds a second, strictly read-only integration surface for content scanning — across AWS, Azure and Google Cloud, databases, file shares and on-prem systems via the agent — kept separate from the propagation architecture, with its own scan credentials (separate from read credentials, expiry warnings, hard TTL destruction).

No first-party native connectors today — we'd rather tell you that plainly. We ship HMAC-signed webhooks (most CRMs accept them), a REST pull API, and on-prem agent plugin slots for on-premises CRM. Integration is typically 1–2 weeks for cloud CRMs. Native connectors are on our roadmap.

The web SDK (~20 KB gzipped) ships today, and the schema supports iOS, Android, and React Native platforms. The mobile SDK is on our roadmap — we recommend calling our REST API directly from the mobile app in the meantime.

Tiered SaaS pricing — Starter / Professional / Enterprise — based on Data Principal volume, tenant count, and feature scope, with self-hosted licensing available on the Enterprise tier. See /pricing for the tier framework; pricing is finalised per deal in the commercial conversation, so talk to us for a quote matched to your volumes.

Production rollout for the consent ledger, rights-request queue, and breach tracker — the heart of DPDP — takes 2–4 weeks from kickoff for a single tenant. Adding identity unification, propagation via Downstream Bindings, and Source Binding integration adds 2–4 weeks per integration. A 4-week production timeline for the core DPDP modules is realistic.

An onboarding wizard guides 8 setup steps with live database checks. Dedicated customer success management on the Enterprise tier. A sandbox tenant for dev/QA. A pre-deployment workshop covering role configuration, SSO/SCIM setup, and Downstream Binding integration. Post-deployment support via a dedicated channel for the first 90 days.

Yes. We run 90-day pilots for Enterprise prospects. Pilot scope: one tenant, a real consent capture flow, webhook delivery to one Downstream Binding, and a rights-request queue with verifiable SLA tracking. Success criteria are co-defined at kickoff, and pilots are structured commercial engagements so both sides have skin in the game. Start the conversation.

OneTrust has deeper GDPR coverage and a longer global track record — if your scope is multinational with significant EU exposure, it may fit you well. Where TATA Tele Vishwaas AI is strong: DPDP-native depth (every section, SLA, and language is DPDP-shaped); India data residency by default; all 22 Eighth Schedule languages plus English out of the box; cryptographic non-repudiation as a standard capability; an outbound-only on-prem agent; offline and branch consent brought into the same ledger; DPB-grade RoPA exports and lineage comparable to leading global privacy platforms — built DPDP-native, with a continuously-running Compliance Gap Engine rather than a static export; and a Data Discovery engine that finds PII at rest behind a mandatory DPO approval gate. If your scope is Indian-led, we believe we're the stronger fit — see the detailed side-by-sides at /compare.

The platform spans a hash-chain crypto core, an identity-resolution engine, real-time propagation, and a multi-layer tenant-isolation architecture — conservatively a multi-engineer-year build. A portal in all 22 Eighth Schedule languages plus English is a real ongoing cost. Offline consent that is still cryptographically anchored, and an append-only ledger enforced at the database level, are both harder than they look. The RoPA Compliance Gap Engine (15 gap checks running continuously) and the Data Discovery PII-detection pipeline — Aadhaar Verhoeff validation, GSTIN/PAN/UPI/card detectors, a DPO-gated approval workflow — are each a further multi-engineer-quarter build on top of that baseline. Run a build-vs-buy analysis at that estimate before committing.

The self-host option means your data stays in your own data centre — it survives our absence. Multi-tenant SaaS escrow is available for the Enterprise tier. The hash chain is open-spec (SHA-256 + RSA) — receipts remain cryptographically verifiable using public-key cryptography, regardless of our software. No vendor lock-in on the receipt format.