Case study · DPDPNow
Turning data protection obligations into tracked work with evidence
How statutory data protection obligations were modelled as versioned reference data and converted into assignable work with owners, evidence and deadlines.
- Client
- DPDPNow
- Industry
- Data protection and compliance
- Published
- Last updated
Executive summary
In brief
Organisations facing India's Digital Personal Data Protection Act held their obligations in legal memoranda and their remediation work in spreadsheets, with no link between the two. The platform closes that gap: an assessment determines which obligations apply, each becomes tracked work with an owner and a defined evidence requirement, and leadership gets a current view of readiness. Obligations are modelled as versioned reference data so regulatory change does not require a data migration, and AI is used to triage uploaded evidence but never to assert that an obligation is met.
Business context
The situation before the work
New statutory obligations arrived with limited implementation precedent. Legal advisers could interpret the requirements, but translating interpretation into operational work — who does what, by when, and what proves it — was left to internal teams without a system to hold it.
Problem statement
What specifically had to change
Leadership could not answer two questions on demand: which obligations currently apply to us, and what evidence exists that each is being met. Audit preparation therefore consumed weeks of senior time, and gaps were discovered under deadline pressure rather than in advance.
Approach
How the work was sequenced
Order mattered more than speed. Each step produced a decision, a prototype or a release.
- 01
Model obligations as reference data, not content
Each obligation became a structured record with applicability conditions, required evidence types and review frequency, versioned independently of any client's data.
- 02
Make the assessment produce work, not a score
Assessment answers determine applicable obligations, and each applicable obligation is created as an assignable item with an owner and deadline rather than a maturity rating.
- 03
Define evidence at obligation level
Every obligation states what would prove it operates. This removed the ambiguity that makes compliance tracking drift into self-assessment.
- 04
Use AI for triage, require humans for assertion
Uploaded documents are classified against obligations to propose matches and explain gaps. A reviewer must confirm before anything counts as evidence.
Architecture decisions
Decisions and their rationale
Recorded with reasoning, so a future team can tell whether the original constraint still applies.
- Version regulatory reference data separately from client records
- Legal updates then propagate as a new reference version rather than a migration across every tenant's data.
- Enforce tenant isolation with database row-level policies
- Isolation that depends only on application code fails the first time a query is written without the tenant filter.
- Immutable evidence records with reviewer attribution
- Evidence that can be edited after the fact has no value in an audit.
- Single-action export pipeline for the audit pack
- The measurable business outcome is time-to-evidence-pack, so export was treated as a primary feature rather than a report.
Technology choices
What was chosen, and why
- PostgreSQL with row-level security
- Multi-tenant compliance data requires isolation enforced at the data layer.
- Server-side rendering for public and marketing content
- Buyers research obligations through search; content had to be present in the HTML rather than assembled in the browser.
- Hosted language models behind an internal boundary
- Provider choice can change without altering the product, and prompts stay reviewable in one place.
- Object storage separated from application data
- Evidence documents carry different retention and access requirements from records.
Challenges
What went wrong first
Included because the response is usually more instructive than the plan.
- Regulatory interpretation still evolving during build
- Obligations kept as versioned data with effective dates, so the platform could carry more than one interpretation over time without rewriting history.
- Document classification confidence varied widely by document type
- Confidence surfaced explicitly to the reviewer, with low-confidence proposals presented as questions rather than suggestions.
- Clients wanted a readiness percentage
- A single score was declined in favour of open gaps by obligation category, because a percentage invites the wrong conversation before an audit.
Outcome
What changed
- Applicable obligations are derived from an assessment rather than interpreted per organisation.
- Each obligation carries an owner, a deadline and a defined evidence requirement.
- An audit-ready evidence pack is produced in a single action.
- Regulatory updates ship as a reference-data version rather than a migration.
Key learnings
What carries forward
- Versioning regulatory data independently is the decision that determines whether the platform survives legal change.
- Compliance tools are adopted for reducing audit preparation, not for scoring maturity.
- AI is useful for triaging evidence and unsuitable for asserting it; the confirmation step is the product.
- Refusing a single readiness score improved the quality of client conversations.
The best products begin with the right questions.
Send the business context and the constraint you are working against. I will reply with a direct read on the approach I would take, and whether I am the right person for it.