Skip to content
Full-Stack Developer

Projects/dpdpa-trustos

Professional / Company project

DPDPA TrustOS

DPDPA consent and enforcement SaaS

Multi-tenant platform for India’s DPDPA: purposes and notices, hash-chained consent, principal rights, PII discovery, and erasure jobs across connected systems. Four Next.js surfaces sit on a NestJS REST API and PostgreSQL.

  • Next.js
  • React
  • Node.js
  • NestJS
  • PostgreSQL
  • Prisma
  • REST APIs
  • Redis
  • Passport JWT
  • Nodemailer

Consent · Discovery · DSR · Enforcement · Multi-tenant APIs

Overview

DPDPA TrustOS is a compliance operations product for data fiduciaries. Principals use a Privacy Centre and embeddable SDKs to grant or withdraw consent. Operators use a dashboard for consent, DSR, discovery, incidents, vendors, and enforcement connectors. A NestJS /v1 API stores a per-principal consent ledger, runs in-process workers for scans, messaging, and erasure, and encrypts identifiers at rest. A separate marketing app handles public content, gap assessment, and search metadata. SMS, WhatsApp, Razorpay, DigiLocker, and eSign paths exist in code and stay SANDBOX-labelled until live credentials are configured.

Problem

Organisations processing personal data in India need to show who consented to what, honour access and erasure, find personal data in their stores, and keep evidence — without treating a simulated connector run as regulatory proof.

Solution

Tenant-scoped PostgreSQL via Prisma; versioned purposes and notices; hash-chained ConsentEvents with idempotent public APIs; DPI-classified discovery scans (live Postgres or labelled simulation); DSR and grievance workflows that can fan out to webhook/DB/S3 connectors with read-back or honest SIMULATED labels; JWT plus HttpOnly sessions, RBAC, and optional SAML/OIDC; email via tenant or platform SMTP.

Key features

  • Privacy Centre: consent, OTP, DSR, grievances, published policies, locales
  • JS/server/Android/iOS consent SDKs and WordPress cookie-banner plugin
  • Versioned purposes and notices; Consent Builder; ledger chain verify
  • DSR desk with SLA, assign, and fulfilment artefacts
  • PII discovery batch pipeline and DPI regex classification
  • ROPA, DPIA, vendors/DPAs, breach desk, evidence packs
  • Enforcement connectors and job centre (erase/suppress/retain)
  • Email/SMS/WhatsApp queue with retries, DLQ, and suppression
  • Team RBAC, auditor and consultant grants, SSO/SCIM
  • Razorpay billing with GST invoice fields and signed webhooks
  • Platform admin: tenants, leads, cross-tenant audit
  • Marketing site with structured data, robots/sitemap, IndexNow

Technical challenges

Problem

Consent records must be auditable under retry and concurrent channels.

Approach

Per-principal hash chain plus tenant-scoped idempotency keys; verify-chain walks previousHash/eventHash and can rebuild derived records.

Problem

Discovery and erasure against real stores can be slow, partial, or fake.

Approach

Sampled scans in chunks with retry then pause; decrypt credentials before planning; simulated inventories and dry-run connectors are labelled and must not be shown as verification.

Problem

Identifiers and connector secrets cannot sit in plaintext, including in DevTools.

Approach

AES-GCM at rest with blind indexes for lookup; RSA bootstrap plus per-session AES for dashboard request/response bodies.

Problem

Marketing must be crawlable while principal privacy pages must not be.

Approach

Marketing emits sitemap, JSON-LD, and IndexNow; Privacy Centre sends noindex robots meta and X-Robots-Tag.

Problem

Time-boxed auditors and consultants must not inherit OWNER powers.

Approach

Grants in the database; guards block auditor writes and consultant writes unless the grant scope is DELIVERY; consultant requests swap tenant via header only when a grant exists.

What this demonstrates

A multi-app DPDPA compliance SaaS: consent ledger, rights workflows, PII discovery, and enforcement jobs on NestJS, Next.js, and PostgreSQL, with explicit sandbox vs live integrity labels.