A new EdTech contract rarely feels like a data decision. It arrives as a tool that solves a scheduling or admissions problem. But the moment a vendor’s platform holds applicant records, internal marks, guardian contacts, hostel allocations or staff documents, your institution has handed part of its record-keeping to a third party.

Under India’s data protection framework, that does not transfer the responsibility. The Digital Personal Data Protection Act, 2023 (DPDP Act) places its obligations on the Data Fiduciary — the institution that decides why and how personal data is processed. The vendor, acting on your instructions, is a Data Processor. When something goes wrong, the questions arrive at the institution, not at the vendor.

What follows is a due-diligence question set for before signature. It is not legal advice. Everything here is current as of 6 October 2026 and drawn from the DPDP Act, 2023 and the Digital Personal Data Protection Rules, 2025, notified in the Gazette on 13 November 2025 as G.S.R. 846(E). Rules 3 and 5 to 16 come into force eighteen months after that publication date, so the compliance clock is already running. Read the gazette itself and take qualified legal advice.

Who owns the data, and what the vendor may do with it

Ask for the sentence that says the institution’s records remain the institution’s. Ownership language often appears in a service description but not in the agreement governing processing.

Then go deeper, because “your data” is defined more narrowly in the contract than in the sales conversation:

  • What may the vendor do with derived data — aggregated analytics, benchmark datasets, usage telemetry, model improvement sets — and who verifies any de-identification?
  • Can the vendor use your institution’s name or non-aggregated figures in marketing?
  • Who owns configuration, templates, question banks, report formats and uploaded files — as distinct from student records?

If the answer to any of these is “it depends on the scenario”, the contract needs an annexure, not a verbal reassurance.

Many colleges run a school wing, a bridge programme, a coaching arm or a summer school with minors. Personal data of a child carries additional obligations: Rule 10 requires verifiable consent of the parent before processing, including due diligence that the person consenting is an identifiable adult.

The exemption is narrower than it is often described. Rule 12 read with Part A of the Fourth Schedule exempts an educational institution from the parental-consent requirement and from the prohibition on tracking and behavioural monitoring, but only where that processing is restricted to the institution’s own educational activities, or to the safety of children enrolled with it. Part B of the same schedule treats real-time location of a child for safety as a separate case.

Questions worth asking in writing:

  • Does the platform hold data of anyone under eighteen, including enquiries from prospective students?
  • How is parental consent captured, dated, evidenced and withdrawn — and can you export that evidence?
  • If the vendor uses behavioural monitoring for engagement scoring, is that within the education exemption or outside it?
  • If the tool is used by a coaching arm that is a separate legal entity, whose exemption is being relied on?

Do not assume the exemption covers a product feature simply because the customer is a college.

Retention, erasure and the exit you did not plan for

Section 8(7) of the Act requires a Data Fiduciary to erase personal data once consent is withdrawn or as soon as it is reasonable to assume the purpose is no longer served, and to make its Data Processor erase the data it was given. Rule 8 adds a floor in the other direction: personal data, associated traffic data and processing logs must be retained for a minimum of one year, unless another law requires longer.

Both directions need a contractual answer:

  • What is the vendor’s default retention period, per record type, and can it be configured to your academic cycle?
  • What happens to a student’s records when they graduate, transfer, drop out or withdraw an application?
  • What survives legal hold, audit or statutory requirements, and who decides?
  • On termination, in what format and within what period does data come back — and when is the vendor’s copy actually destroyed?
  • For how long do backups retain records after the live system has deleted them?

Test the last one before signing: ask for a full export of a sample semester and have the admissions office try to read it. An export only an engineer can decode is not portability.

Access, subprocessors and where the data actually lives

Rule 6 sets out minimum safeguards: protecting personal data through encryption, obfuscation, masking or virtual tokens; controls on access to computer resources; logs and monitoring sufficient to detect unauthorised access; and reasonable backups.

That turns “is it secure?” into a structured list:

  • Which subprocessors are involved — hosting, email, SMS, payment, analytics, support tooling — and how are you notified before that list changes?
  • Where is data stored and processed, and does any of it leave India? Rule 15 governs transfers outside the territory.
  • Can vendor staff reach production data, under what approval, and is that access logged and time-bound?
  • Does the platform support single sign-on and role-scoped permissions, so an examinations clerk and a dean do not see the same records? Our role-based access guide covers how to scope that.
  • What happens to access on the day a staff member leaves, and on the day a semester-end temporary account should expire?

Breach notification: what you will be told, and when

Rule 7 requires the Data Fiduciary to inform each affected Data Principal without delay — in concise, clear and plain language — of the nature, extent and timing of the breach, the likely consequences for that person, the measures taken, the safety steps the person can take, and a contact who can answer questions. In parallel, the Board must be told without delay, with fuller detail within seventy-two hours.

Your institution carries that duty toward students, guardians and staff. The vendor is the only party that knows what actually happened. So:

  • What is the vendor’s contractual notification clock to you, and is it measured from detection or from confirmation?
  • Who decides which individuals are “affected”, and will you be told how that determination was made?
  • Will you receive a written incident summary you can forward in substance — or only a press-style holding statement?
  • Who is the named contact, and is that business contact information published as Rule 9 requires?

A vendor that cannot answer these is not necessarily unsafe. A vendor never asked them is unprepared.

The question set to put in writing

  • Ownership, derived data and marketing use are stated in the agreement, not the proposal.
  • Parental consent capture, evidence and withdrawal are defined where minors may be involved.
  • Retention defaults, graduation and withdrawal handling, and the erasure path are specified.
  • Exit format, timeline, deletion certificate and backup residual period are agreed before signature.
  • The subprocessor list, data locations and support access rules are documented.
  • Access is role-scoped, SSO-ready, logged and tied to joining, moving and leaving.
  • Breach notification to the institution is contractually timed and evidenced.
  • Every integration has a named system of record and an owner.
  • Change notification covers security-relevant changes to the above.

If a vendor resists giving you a breach notification timeline in writing, that single answer tells you more than the rest of the questionnaire combined. An EdTech tool rarely sits alone: it syncs with an admissions CRM, a fee gateway or a messaging tool, and each connection is a new route for personal data.

Make diligence a renewal habit, not a one-time event

Vendors change hosting providers, add AI features and update subprocessor lists mid-term, so procurement answers go stale within a year. Review alongside the renewal, and require notification of material changes.

Our school data-security checklist for software vendors goes deeper into the security evidence to collect at that point, and Scholva’s security page describes our own controls — a useful template for the answers you should expect.

A contract you can read, and a vendor that answers precisely, will protect your institution more than any feature list.