← Back to Work
7UNIT / CASE STUDY 006
EDTECH · INDIA · DPDP · 2025–ongoing
IN PROGRESS
Consent architecture · Encryption · PII controls · Multi-tenant SaaS

They thought they were compliant.The systems said otherwise.

An Indian EdTech platform serving schools and colleges. A privacy policy on the website. Checkbox consent in the product. Leadership believed they were ready for the DPDP Act. Technical analysis showed they were not — and that their school tenants inherited the same risk.

THE SITUATION

The product was already live. Schools and colleges across India were running learner, parent, and staff workflows through the platform. Personal data — including data of children — moved through enrolment, attendance, communication, and reporting every day.

From the outside, the compliance story looked tidy. There was a published privacy policy. There were consent checkboxes. There was a sense that “we have a policy, so we are covered.” That is a common posture in Indian SaaS — especially when the product grew faster than the control plane around personal data.

What the client asked for was confirmation. What the engagement required was an engineering-led DPDP gap assessment — not a policy memo — followed by remediation where the systems themselves failed the Act and the 2025 Rules.

WHAT THE ASSESSMENT FOUND

Policy language and UI checkboxes are not the same as enforceable controls. The assessment mapped collection, storage, sharing, and tenant boundaries against DPDP obligations. The material gaps were not cosmetic.

  • MINORS' DATA

    EdTech is not a generic SaaS category under DPDP. Processing personal data of children raises a higher bar — verifiable parental consent, purpose limits, and safeguards that must hold in the product, not only in a PDF.

    The platform handled learner data for minors without a coherent, enforceable minors workflow. Consent was not structured as a durable, auditable control. Age-sensitive paths were not designed as first-class product logic. That gap alone would have been enough to reopen the “we are compliant” assumption.

  • PII HANDLING

    Personally identifiable information was collected and stored across product surfaces without a clear data map, classification model, or operational rule for what is retained, who can access it, and how it is deleted on request.

    Without PII treated as a controlled asset — labelled, access-scoped, and deletable — Data Principal rights become tickets and improvisation. Under DPDP, that is not a process problem you can paper over later. It is a product failure.

  • ENCRYPTION AND SYSTEM SECURITY

    Security posture was uneven. Encryption strength and key handling did not match the sensitivity of the data the platform held. Broader system security — access control, environment hygiene, and protective controls around personal data stores — had gaps that a policy review would never surface.

    DPDP readiness is not only consent language. If personal data is weakly protected at rest or in transit, the compliance story collapses under technical scrutiny.

  • THE SCHOOL-TENANT CASCADE

    This was the finding that reframed the engagement. The platform is used by many schools and colleges. Each institution operates as a tenant — and each tenant's learners and parents are Data Principals whose data flows through the same product.

    If the platform is not DPDP-ready, the schools and colleges running on it inherit that exposure. Product compliance is not a single-company checkbox. It is a multi-tenant control problem: the SaaS provider's architecture either enables tenant compliance or quietly undermines it at scale.

WHAT WE ARE BUILDING

The assessment delivered a readiness view, an evidenced gap report, and a priced remediation roadmap. Remediation is in progress — shipping controls into the product, not filing recommendations in a slide deck.

CONSENT ARCHITECTURE

Consent is being rebuilt as a product control: purpose-bound, withdrawable, and recorded with an audit trail. For minors, parental consent paths are designed as enforceable workflows — not a checkbox that disappears after signup.

PII CONTROLS AND RIGHTS

Personal data is being classified and mapped. Data Principal rights — access, correction, erasure, withdrawal — are moving from ad-hoc support handling into defined product and operational workflows with evidence trails.

ENCRYPTION AND SECURITY HARDENING

Data protection controls are being raised to match the sensitivity of learner and parent data: stronger encryption posture, tighter access boundaries, and security safeguards that can be demonstrated — not only asserted.

RETENTION, DELETION, BREACH READINESS

Retention rules and deletion paths are being made real in the system. Breach readiness is moving from a paper plan toward operational workflow — detection, containment, notification posture, and evidence — so the organisation can act under pressure.

TENANT COMPLIANCE SURFACE

Because schools and colleges run on the same platform, remediation includes the multi-tenant surface: how tenant admins configure consent and access, what evidence the platform can produce per institution, and how one tenant's posture does not silently fail the others.

ARCHITECTURE DECISIONS

Each decision below is documented with its rationale. This is how we work — every decision has a reason, and that reason is recorded.

Engineering-led assessment before remediation

The first impulse in compliance work is often to rewrite policies. We started by mapping the running systems — collection points, stores, vendors, tenant boundaries, and security controls — against DPDP obligations.

Rationale: Policies describe intent. Systems describe reality. This client already had policy language and UI consent. The failures lived in minors' data handling, PII controls, encryption, and multi-tenant cascade risk — none of which a policy rewrite alone would have fixed.

Trade-off accepted: A longer discovery phase before “fixes ship” in exchange for a remediation roadmap grounded in evidence rather than assumptions.

Minors' data as a first-class product path

We rejected treating children's data as a special case bolted onto generic consent later. Parental consent, purpose limits, and safeguards are being designed into the learner data path itself.

Rationale: EdTech platforms that process children's data cannot treat DPDP as a marketing-site problem. If minors' flows are not enforceable in the product, the platform fails the highest-risk obligation in the portfolio.

Trade-off accepted: More complex consent and identity flows early in remediation in exchange for a defensible posture where the risk is highest.

Rights as workflows, not support tickets

Access, correction, erasure, and withdrawal are being modelled as operational workflows with audit evidence — not as email requests that depend on whoever is on shift.

Rationale: Under DPDP, Data Principal rights must be fulfilable. Ticket-based improvisation does not produce consistent outcomes or evidence. Workflow design is the only way rights survive volume and employee turnover.

Trade-off accepted: More product and ops engineering upfront in exchange for rights handling that can scale with the school network.

Treat school tenants as part of the compliance surface

Remediation is not scoped only to the SaaS company's own corporate website. It includes the multi-tenant product surface that schools and colleges use every day.

Rationale: If the platform enables institutions to process learner data without adequate controls, the provider's “we are compliant” claim is incomplete. Product architecture either carries tenant compliance or spreads the gap across every school on the network.

Trade-off accepted: Broader remediation scope and tenant UX work in exchange for a platform that can support institutional readiness — not just a single company's privacy page.

OUTCOMES SO FAR

Assumed
Compliance myth broken

Leadership entered believing the product was ready. Technical analysis proved the controls did not match the claim.

Mapped
Minors, PII, encryption gaps

Highest-risk failures identified with evidence — not generic checklist findings.

Cascade
School-tenant risk surfaced

Multi-school usage reframed DPDP as a platform control problem, not a single-entity policy task.

Live
Remediation in progress

Consent, rights, security hardening, retention, and breach workflows shipping into the product — engagement ongoing.

WHAT THIS IS NOT

This engagement is an engineering and process audit plus remediation of product controls. It is not a legal opinion, and it does not replace counsel.

Statutory interpretation and formal legal sign-off sit with the client's lawyers. 7Unit owns the systems work: data mapping, control design, evidence, and implementation of consent, rights, security, retention, and breach readiness in the product.

Remediation is ongoing. We do not claim the platform is “fully DPDP compliant” while controls are still shipping. We claim the honest posture: the gap was real, the work is underway, and the architecture is being corrected where it failed.

ENGAGEMENT SURFACE

Assessment: DPDP Act + 2025 Rules mapped to live systems

Focus: Minors' data · PII · Encryption · System security · Tenant cascade

Remediation: Consent architecture · Rights workflows · Retention/deletion · Breach readiness

Delivery model: Fixed-scope gap assessment → priced remediation roadmap → build

Assessment reports are engineering and process audits, not legal opinions. For statutory legal sign-off we work alongside counsel.

IF THIS SOUNDS LIKE YOUR PROBLEM

If your product already has a privacy policy and consent checkboxes — and you still cannot show enforceable minors' consent, PII controls, strong encryption, or a clean rights path — you are in the same place this client was.

If you sell to schools, colleges, or any multi-tenant network, the cascade risk is yours whether you named it or not. We assess the systems first, then build the fix.

Book a 30-min call →Explore DPDP Gap Assessment →
CONTINUE EXPLORING

Related case studies

← Back to all work