When the DPBI asks "prove this person consented", your answer cannot be a database flag. Vishwaas AI gives you cryptographic consent proof, defence-in-depth security, and a non-repudiated audit trail — built on the same engineering standards your security team already demands.
6-Layer Security Architecture
Every layer independently verifiable
As CISO, you've solved encryption, access controls, and breach response. But the DPDP Act introduces a security challenge that network monitoring cannot solve:
When a data principal files a DPBI complaint, can you prove — cryptographically — that consent was genuine, unaltered, and recorded at the exact moment claimed?
Even an encrypted database record can be altered by any DBA with access. Without cryptographic non-repudiation, your organisation's DPDP defence collapses the moment a sophisticated adversary or legal challenge questions record integrity.
Four independent, interlocking proof layers that any party — including the DPBI — can verify using only OpenSSL and your organisation's public key. No dependency on Vishwaas AI infrastructure required.
Every consent record carries four proof layers. Each defeats a distinct class of attack. All four together make any post-hoc alteration — including by a database superuser — independently detectable by the DPBI or any third party.
record_hash
SHA-256 of deterministic JSON
Defeats post-hoc record modification. Any change to any field produces a different hash.
chain_hash
SHA-256(record_hash + prev_chain_hash)
Defeats record insertion, deletion, and reordering. The chain is a linked structure — any gap breaks verification.
digital_signature
RSA-2048 via AWS KMS HSM
Defeats fabricated records from outside the system. Private key never leaves KMS — signs but cannot be extracted.
tsa_token
RFC 3161 · DigiCert / GlobalSign
Defeats backdated records and server clock manipulation. Issued by a trusted third party your organisation cannot control. No other DPDP compliance platform in India provides RFC 3161 TSA tokens on consent records.
Court-admissible · No Vishwaas AI dependencyAttack Surface Coverage
| Proof | Defeats |
|---|---|
| record_hash | Post-hoc record modification |
| chain_hash | Insertion, deletion, reordering |
| digital_signature | Fabricated external records |
| tsa_token | Backdating · clock manipulation |
Independent Verification
Any party — including the DPBI — can verify a consent record's integrity using only OpenSSL and the organisation's public key. Zero dependency on Vishwaas AI infrastructure.
# Verify consent record integrity with OpenSSL openssl dgst -sha256 -verify pubkey.pem \ -signature signature.bin record.json # Verified OK — no Vishwaas AI dependency
DPBI Investigation Response Time
Application-layer guards can be bypassed. Vishwaas AI enforces immutability at the database permission level — the database itself rejects modification attempts regardless of what the application code requests.
-- Applied at schema provisioning time REVOKE UPDATE, DELETE ON consent_records FROM crosstrust_app; REVOKE UPDATE, DELETE ON audit.events FROM crosstrust_app; -- Any UPDATE/DELETE attempt returns: -- ERROR: permission denied for table consent_records
The application role (crosstrust_app) cannot issue UPDATE or DELETE SQL statements against consent records or audit events. This eliminates the insider-SQL-injection attack surface entirely.
Threat Model Coverage
Even if an attacker injects UPDATE consent_records SET... through the API — the database rejects it with a permission error. The application role simply cannot execute that statement.
Application-layer code changes cannot unlock permissions — only PostgreSQL superuser credentials can modify the REVOKE, and superuser credentials are held only by the DBA, not the application runtime.
A superuser can bypass REVOKE — but any such operation is visible in the PostgreSQL server log. The hash chain and RFC 3161 TSA timestamps will still expose the tampering externally.
Every PII field uses a split-storage pattern: encrypted ciphertext for data retrieval, SHA-256 hash for indexed lookups — plaintext is never persisted anywhere in the system.
| Scope | Algorithm | Key Management |
|---|---|---|
| PII at rest | AES-256-GCM | AWS Secrets Manager |
| Sensitive PII | AES-256-GCM | AWS KMS · per-tenant CMK |
| S3 objects | SSE-S3 / SSE-KMS | Per-bucket policy |
| Data in transit | TLS 1.3 | All API + web traffic |
| Consent signing keys | RSA-2048 | AWS KMS — never leaves HSM |
| Webhook secrets | AES-256-GCM | Encrypted at rest; revealed once |
-- PII storage pattern (no plaintext persisted) CREATE TABLE data_principals ( id UUID PRIMARY KEY, -- Ciphertext for retrieval email_encrypted BYTEA, -- Hash for indexed lookup email_hash VARCHAR(64), -- Aadhaar: hash only, never plaintext aadhaar_hash VARCHAR(64) );
Aadhaar handling
Stored only as SHA-256 hash — never as plaintext, not even in staging records. The hash allows identity verification without ever exposing the actual number to the application layer.
Vishwaas AI is passwordless throughout. Every admin user and data principal authenticates via email OTP only — there is no credential database to breach.
// Cryptographically secure OTP generation const otp = crypto.randomInt(100000, 999999); // Stored in Redis — never in the database await redis.set( `otp:${sha256(email)}`, // key hashedOtp, // hashed value 'EX', 600 // 10-minute TTL ); // Deleted from Redis after successful verify // Rate limits: 3 requests/5min, 5 attempts/OTP
What doesn't exist in Vishwaas AI
JWT Tenant Isolation
JWT payload carries tenant_id, ensuring super admins have zero access to any customer tenant's data — a hard boundary enforced in every API guard, not just at the application layer.
No single layer is the only defence. Three complementary isolation mechanisms ensure cross-tenant leakage is impossible even via direct SQL, accidental code omissions, or API layer bypass.
Injects tenant_id into every request context before it reaches any controller or service. No cross-tenant query can be formed.
Wraps all queries with AND tenant_id = :id automatically. Prevents accidental omission of the tenant filter in any query across the entire codebase.
RLS on all app schema tables prevents cross-tenant data leakage even if a direct SQL connection is somehow obtained.
| Layer | Mechanism | Prevents |
|---|---|---|
| API | TenantContextMiddleware | Cross-tenant queries |
| ORM | Prisma extension → AND tenant_id = :id | Accidental filter omission |
| Database | PostgreSQL Row-Level Security | Cross-tenant leakage via direct SQL |
DPDP Act §8(6) and Rule 8 impose a 72-hour DPBI notification obligation. Vishwaas AI enforces this operationally — the countdown starts automatically, there is no manual tracking.
Countdown clock starts at incident creation — automatic, not manual
Structured notification editor with all Rule 8(2) mandatory fields enforced
Multi-authority workflow: DPBI + RBI/IRDAI/CERT-In for BFSI organisations
Append-only breach activity timeline — immutable post-incident record
Signed PDF breach register export for DPBI submission
72-Hour DPBI Notification Clock
57:23 remaining before DPBI deadline
Without Vishwaas AI: legal team manually tracking on a spreadsheet. One missed Slack message and the 72-hour window closes unnoticed. Penalty: up to ₹200 Crores for failure to notify.
# AWS ap-south-1 (Mumbai) — 100% India residency
CloudFront CDN + AWS WAF + Shield Standard
│
Kong / AWS API Gateway
├── Next.js pods (EKS · HPA)
└── NestJS API pods (EKS · HPA)
├── PostgreSQL 16 RDS Multi-AZ
│ └── + 2 read replicas
├── Redis 7 ElastiCache
│ └── 3-node cluster · AOF
├── Kafka / MSK
│ └── 3-broker · KRaft mode
└── AWS S3 + AWS KMS
| Security Control | Detail |
|---|---|
| Cloud | AWS Mumbai (ap-south-1) — 100% India data residency |
| Network | AWS WAF + Shield Standard; Kong API Gateway |
| Compute | EKS (Kubernetes) — containerised, distroless production images |
| Key Management | AWS KMS per-tenant CMK for consent signing; rotation support |
| Observability | Prometheus + Grafana + Loki + OpenTelemetry + Jaeger |
| Secrets | AWS Secrets Manager — no secrets in code or env vars |
| CI/CD | GitHub Actions → ECR → ArgoCD GitOps; no manual prod deployments |
The audit.events table captures every administrative action across all 15 modules — with the same SHA-256 hash chain design as the consent ledger.
Actor identity (user ID + role)
IP address and timestamp on every event
SHA-256 hash chain — same design as consent ledger
Chain verification endpoint for any date range
# Verify audit chain for any date range GET /api/v1/audit/verify-chain ?from=2026-01-01 &to=2026-03-31 # Returns: { "integrity_valid": true, "events_checked": 14872, "chain_intact": true }
All exports RFC 3161-timestamped at generation time
During a DPBI investigation, your legal team can produce complete, RFC 3161-signed evidence packages with end-to-end chain integrity proof — in minutes, not days.
Technical questions from CISOs and security architects evaluating Vishwaas AI.
All data — including all PII, consent records, audit logs, and documents — is stored exclusively in AWS Mumbai (ap-south-1). No cross-region replication of personal data. No processing in US or EU data centres.
Yes. Enterprise plan supports customer-managed keys (CMK) in your own AWS KMS account for consent signing keys. You retain full control over the cryptographic material.
ISO 27001 and SOC 2 Type II certification are in progress for Q3 2026. Current controls align with both frameworks. Contact us for the current security posture documentation.
Available under NDA for Enterprise plan evaluations.
Contact: security@crossidentity.in
Consent signing uses RSA-2048 keys stored in AWS KMS HSMs. Private key material never leaves the HSM. A KMS compromise would require compromising AWS's HSM infrastructure — an independent event detectable by the RFC 3161 TSA token timestamps, which are maintained by third-party TSAs (DigiCert, GlobalSign), not AWS. The TSA chain remains intact and verifiable even in a KMS compromise scenario.
No. The crosstrust_app database role has UPDATE and DELETE revoked on consent_records and audit.events at the PostgreSQL permission level. Only a PostgreSQL superuser (separate credentials, held only by the DBA) can modify these tables — and such operations would be visible in the PostgreSQL server log, and would still break the RFC 3161 TSA timestamp chain.
Our technical team will walk you through the full security architecture — cryptographic proof layers, encryption controls, multi-tenancy isolation, and incident response capabilities. 60 minutes with our engineering team.