What We Do
Every DPDP obligation your product has. What we build for each one.
The DPDP Act places eight categories of obligation on every Data Fiduciary. Each one is a legal requirement. Each one is also an engineering problem. Here is what the law requires, and what exists in your product when we are done.
Where we fit in the DPDP ecosystem
The DPDP system has four distinct layers.
The law
The DPDP Act 2023 and Rules 2025, notified by MeitY — defines what every Data Fiduciary must do.
The regulator
The Data Protection Board of India — enforces the Act and investigates complaints.
The infrastructure
Consent Managers, registered platforms that store and manage consent artefacts on behalf of Data Fiduciaries.
The implementation layer
Us. We build the systems inside your product that connect to the infrastructure above. Consent Managers manage the consent record. We build the consent system inside your product that talks to them.
Without the implementation layer, the infrastructure has nothing to connect to.
Consent collection
What the law requires
Free, specific, informed, and unambiguous consent before processing any personal data. As easy to withdraw as to give. Pre-ticked boxes and bundled opt-ins do not qualify.
What we build
Explicit opt-in flows at the right moment in your user journey, purpose-specific language written to Rule 3 standard, consent state stored and versioned, one-click withdrawal wired to your backend so withdrawal actually stops processing.
Notice
What the law requires
A clear, itemised notice in plain language before data collection — what you collect, why, who you share it with, and how users exercise their rights.
What we build
A privacy notice rewritten to Rule 3 standard, wired into the right touchpoints in your product. Not a footer link. A real notice that appears at collection, in language users can read.
Re-consent for existing users
What the law requires
Consent collected through legacy sign-up flows, pre-ticked boxes, or bundled terms is almost certainly invalid under the new standard. Your existing user base needs fresh, verifiable, purpose-specific consent.
What we build
A re-consent architecture — a triggered communication, a clear consent moment in your product, and backend logic to capture and version the new consent state without breaking your existing user experience.
Data principal rights
What the law requires
Every user has the right to access a summary of their data, correct inaccuracies, erase their data when purpose is served or consent is withdrawn, and nominate someone to act on their behalf.
What we build
A data principal rights portal connected to your live data layer. Access requests return the right data. Erasure requests trigger real deletion. Every request is logged with a timestamp. Not a form that emails support and disappears.
Grievance redressal
What the law requires
A published grievance officer contact, acknowledgement of complaints, and resolution within defined timeframes.
What we build
A grievance intake workflow, a published contact point, an acknowledgement system, and an internal SOP that defines who handles what and by when.
Breach detection and notification
What the law requires
Notification to the Data Protection Board within 72 hours of becoming aware of a personal data breach. Notification to affected users.
What we build
Detection hooks in your product, a documented 72-hour breach runbook, and notification templates ready for the Board and for affected users. Built before a breach happens.
Data retention and erasure
What the law requires
No retention of personal data beyond the period necessary for the purpose it was collected. Erasure when purpose is served or consent is withdrawn.
What we build
A retention schedule mapped to every data category in your product, with automated deletion logic built into your system and audit logs to prove it ran.
Security safeguards
What the law requires
Reasonable security safeguards to prevent personal data breaches. Adequacy assessed against the nature and volume of data you hold.
What we build
A targeted review of your data layer — access controls, encryption at rest and in transit, staff access logging, backup verification — scoped to the surfaces the DPDP Act scrutinises.
Processor and vendor governance
What the law requires
A valid Data Processing Agreement with every third-party vendor or platform that processes personal data on your behalf. You remain liable for how they handle the data.
What we build
A full inventory of every app and vendor in your stack that touches user data, each one classified, data flows mapped, and DPA templates reviewed against the actual data they receive.
Children's data
What the law requires
Verifiable parental consent before processing data of anyone under 18. No behavioural tracking or targeted advertising to children.
What we build
Age verification flows and parental consent architecture for any product where children may be users, configured without unnecessary friction for adult users.
What you receive when we are done
A compliance evidence pack. The complete documentation set that answers every question the Data Protection Board could ask — your data inventory, flow map, gap analysis, consent artefacts, rights workflow documentation, breach runbook, retention schedule, processor inventory, DPA records, and a plain-English compliance summary for your leadership team and investors.
Not a report about what you should do. Proof of what you have done.