For CIOs, CTOs and security teams
Technical architecture
What runs where, what data we hold, how it is protected and how your systems connect. Everything below is described from the code and infrastructure we run today; planned items are marked as such.
- Hosting
- Mumbai, India
- We hold
- Consent records, not your customer data
- Signing
- ECDSA P-256 + ML-DSA-65 (post-quantum) in a hardware security module (HSM)
- Database
- Managed relational database, multi-zone
System overview
Three kinds of caller reach one platform through the edge. Application services run in private subnets; data, keys and logs never leave the Mumbai region.
One consent, end to end
- 1
Request
Your backend calls POST /v1/consent-requests with a notice and your customer reference, and gets a hosted consent link.
- 2
Notice
The person opens the link, reads the itemised notice (before signing in), signs in with a code and chooses each purpose separately.
- 3
Record
In one database transaction we store the consent and append a signed, hash-chained ledger event. The person gets a receipt.
- 4
Check
Before processing, your systems call POST /v1/consents/verify for that person and purpose.
- 5
Withdraw
The person withdraws in one tap. A signed webhook reaches you; your acknowledgement is recorded on their timeline.
Technology stack
-
Consent API
Python 3.12, Django and Django REST Framework on gunicorn. A modular monolith: identity, tenants, catalogue, consent, ledger, receipts, verification, rights and interop are separate modules with their own routes, jobs and SQL schema.
-
Worker
The same codebase as a separate service: consent expiry, webhook delivery from a transactional outbox, ledger integrity checks and anchoring.
-
Data
A managed relational database, accessed through plain SQL with versioned migrations. Background work runs from a transactional outbox in the same database, so no event is lost between services.
-
Web app
React and Vite single-page app: the person’s dashboard, the hosted consent page, the business console and the developer portal.
-
Mobile app
Expo / React Native for Android and iOS, at feature parity with the web dashboard.
-
Infrastructure
Every cloud resource is defined in Terraform, with separate dev, sandbox and production stacks.
Data residency and what we store
All personal data, backups and logs are stored and processed in India (Mumbai). The API refuses to start in any other region. We carry consent records, not the customer data you process. The only global components are the CDN’s web firewall rules and TLS certificate; they hold no personal data.
| Data | Where | Protection |
|---|---|---|
| Person’s mobile number (for sign-in) | Database | AES-256-GCM envelope encryption with a data key from the key management service; looked up by keyed hash |
| Console user name and email | Database | Same envelope encryption |
| Your customer reference | Database | Keyed hash scoped to your organisation; the plain value is never stored |
| Consent ledger | Database + immutable storage | Pseudonyms only, append-only, signed and hash-chained |
| Sessions, codes, API keys | Database | Only SHA-256 or HMAC hashes of secrets |
| Application logs | Log service | Personal data redacted, ids only, encrypted, kept 400 days |
Security controls
-
Encryption
TLS 1.2+ (1.3 preferred) at the CDN and the load balancer, TLS to the database. Field-level AES-256-GCM for personal data; database, storage, logs and backups encrypted with managed keys.
-
Key management
Ledger signing keys never leave hardware security modules. Secrets live in a managed secrets vault. Production refuses to start with development keys or without a live WhatsApp sign-in code provider.
-
Strong sign-in
Console sessions need a strong factor: passkey, authenticator app or a code to a verified mobile. Passwords are hashed with argon2id. SSO over OpenID Connect or SAML 2.0.
-
API access
256-bit API keys, stored only as hashes, scoped and revocable, with separate sandbox and live keys. Webhooks are HMAC-signed.
-
Tenant isolation
Every query is scoped to the calling organisation or person, with automated isolation tests. Pseudonyms differ per organisation, so records cannot be linked across businesses.
-
Abuse protection
A web application firewall at the edge, per-IP and per-number limits on sign-in codes, and idempotency keys on writes.
-
Secure delivery
Every change runs Bandit, Semgrep, pip-audit, pnpm audit, Trivy and Terraform validation. Distroless containers run as non-root with a read-only filesystem in private subnets.
-
Assurance pack
STRIDE threat model, OWASP ASVS Level 2 checklist, DPIA template and penetration-test scope, shared with your security team under NDA.
Evidence anyone can verify
-
Hash-chained ledger
Every notice served, grant, change, withdrawal and acknowledgement is appended in the same transaction as the change itself, canonicalised (RFC 8785), hashed and chained to the event before. Database triggers block any update or delete, and the whole chain is re-verified every 10 minutes.
-
Signed in hardware
Each event hash is signed with ECDSA P-256 inside a hardware security module. Public keys are published as JWKS, so signatures can be checked by anyone, even in a browser.
-
Quantum-ready signatures
The same hash is also signed with ML-DSA-65, the NIST post-quantum standard (FIPS 204). ECDSA is what every browser verifies today; ML-DSA stays secure against a future quantum computer that could break ECDSA. Forging a receipt means breaking both.
-
Anchored and time-stamped
Events are batched into RFC 6962 Merkle trees, written to write-once (WORM) storage with seven-year retention and time-stamped (RFC 3161), with inclusion proofs for each event. For now, timestamps come from a local development authority; external RFC 3161 timestamping starts with the live API.
-
Independent verification
People get JSON and PDF/QR receipts. An auditor, the Board or a court can check any receipt on the public verifier or with the open-source cmverify tool, without trusting us.
How your systems connect
-
REST API
Versioned /v1 JSON API with an OpenAPI document, RFC 7807 errors and idempotency keys.
-
SDKs
Node.js, Python, Java and Go, with retries, typed errors and webhook signature checks.
-
Webhooks
HMAC-SHA256-signed events with retries for about two days and a dead-letter state, delivered from a transactional outbox so none are lost.
-
Hosted page and widget
Send people to our hosted consent page, or drop the consent widget into your site.
-
Sandbox
Identical to live, with separate keys and a separate stack, so tests never mix with real records.
-
Enterprise sign-in
Your staff sign in to the console through your own identity provider.
Availability and operations
-
Stateless services
The API and worker run as managed containers across three availability zones behind a load balancer, with CPU-based autoscaling.
-
Database resilience
A multi-zone managed database with 35 days of point-in-time recovery and deletion protection; no cross-region replication, so backups stay in India. Targets: RPO 5 minutes or less, RTO one hour or less.
-
Logging and audit
Structured JSON logs with request ids, an infrastructure audit trail, an append-only audit log of every console and operator action, and alarms on errors, latency, database load and queue depth paged to on-call. Logs are kept 400 days.
-
Capacity
Consent checks are reads and scale with the API tier. Writes go through one signed chain, roughly 100–200 per second today; chain sharding and batch signing are planned for higher volumes.
How it maps to the DPDP Act
Notice (s.5)
Itemised, versioned notices per purpose, in English and all 22 Eighth Schedule languages. Each consent points to the exact version shown.
Consent (s.6)
Each purpose chosen separately; withdrawal as easy as giving, propagated to you by webhook with acknowledgement.
Children and guardians (s.9)
Age gate, guardian adulthood verified through DigiLocker, and no tracking or targeted-ads purposes for children.
Security and breach (s.8)
The controls above, plus a breach register with notices to people and 72-hour Board report tracking.
Rights and grievances (ss.11–14)
Access, correction and erasure requests, grievances with response deadlines, and nomination.
Consent Manager records
Signed, verifiable records designed to be kept for at least seven years.
Status and what comes next
- myconsentapp is a proposed Consent Manager: not yet registered with the Data Protection Board, and applying when registration opens on 13 November 2026.
- Interoperability with other Consent Managers is demonstrated against a simulated Consent Manager; live links need partner agreements.
- Independent certification of the platform is being scoped with an auditor.
- Chain sharding for write volumes above a few hundred per second.
Planning an architecture or security review?
We walk your team through the design and share the threat model, ASVS checklist, DPIA template and pentest scope under NDA.