The EdTech Vendor Map

Cloud hosting, proctoring, CRM, and WhatsApp—your vendors are “Data Processors.” Under the DPDP Act, you are responsible for their security and breaches.

Managing Your ‘Data Processors’

EdTech stacks rely on many SaaS tools—cloud hosting, analytics, CRM, WhatsApp/SMS, video conferencing, proctoring vendors, support desks, and payment gateways. Under DPDP, these vendors often act as Data Processors because they handle personal data on your behalf. A well-maintained SaaS & Vendor Map helps you clearly identify who touches student and parent data, control what data is shared and for what purpose, enforce reasonable security safeguards through strong vendor contracts, respond quickly and accurately during a personal data breach, and prevent risks caused by “unknown sub-processors” or uncontrolled cross-border data exposure.

What this page is for

This is a practical guide for building a DPDP-ready vendor map for:

  • K–12 EdTech, coaching/test-prep, LMS platforms
  • Proctoring / identity verification systems
  • Live classes (video), chat, recordings
  • Marketing and lead funnels (Meta/Google pixels, CRM, WhatsApp)
  • Outsourced support operations

Why DPDP makes this non-negotiable

Security Safeguards

DPDP Rules explicitly require “contractual provisions” with processors to enforce security controls.

Breach Response

You cannot meet the 72-hour Board deadline if you don’t know which vendor caused the leak or who owns the logs.

Cross-Border Maps

Transfers outside India are allowed, but you must maintain an “Outbound Data Map” of regions and restrictions.

What you must capture

  • Vendor name + product
  • Category (Hosting / CRM / WhatsApp / Analytics / Proctoring / Video / Support / Payments)
  • Vendor contract owner (internal)
  • Support contacts + escalation contacts
  • What data is shared (student/parent/teacher, contact, performance, recordings, proctoring artefacts)
  • Purpose (course delivery, login, support, marketing, exam integrity)
  • Data sensitivity (Low / Medium / High)
  • Data volume (approx.)
  • Cross-border? (Yes/No + regions)
  • Encryption at rest/in transit (Yes/No)
  • Access controls (MFA, RBAC)
  • Audit logs availability + retention
  • Sub-processors list (and change notification)
  • Breach notification SLA (vendor → you)
  • Deletion/return commitment on termination
  • Evidence preservation commitment (for incidents)
  • Notice alignment: is this vendor disclosed where needed?
  • Rights request impact: can the vendor support deletion/export?
  • Retention: do they delete as per your schedule?
  • Incident response: can they support 72-hour reporting needs?

Common Vendors you must Map

Core Platform

  • AWS
  • Azure
  • Firebase (Identity & Hosting)

Learning

  • Zoom (Classes)
  • Vimeo (Content)
  • Stream (Chat)

Growth

  • WhatsApp APIs
  • Salesforce/HubSpot
  • Meta Pixels

Integrity (High Risk)

  • Proctoring tools
  • ID verification APIs

The Risk Model

Tier 1: High Risk

  • Vendors: Proctoring, Chat, Identity Verification.
  • Controls: Strong MFA, Audit Logs, Deletion Proof.

Tier 2: Medium Risk

  • Vendors: Email marketing, Engagement tools.

Tier 3: Low Risk

  • Vendors: Tools with no personal data access.

The “Processor Contract” Checklist

  • Purpose limitation (process only on your instructions)
  • Security safeguards (encryption, access control, logging, monitoring)
  • Sub-processor disclosure + change notice
  • Breach notification SLA (immediate notice, cooperation)
  • Evidence preservation (logs, timelines, artifacts)
  • Deletion/return at end of service + deletion proof
  • Support for rights requests (delete/export/rectify where applicable)
  • Cross-border disclosure (regions + conditions)

Vendor-ready Checklist

To meet DPDP breach obligations quickly, make sure your Tier 1 vendors can provide within hours:

  • incident timeline (when, how detected)
  • impacted systems and records count
  • what data types were affected
  • mitigation steps taken
  • logs/evidence snapshot
  • whether any sub-processor was involved
  • a vendor signed statement for your internal records (optional but useful)

Practical implementation

  • Update on every new tool integration
  • Quarterly review (even if nothing changes)
  • Mandatory update before audits / large releases
  • One internal owner (Compliance/Operations)
  • Engineering + Marketing must notify before adding tools
  • Procurement/legal must ensure contract clauses are present

Add a lightweight gate:

  • New vendor cannot go live until it’s entered in the map and risk-tiered.

Related pages

Need to audit your Vendor Stack?

We map your inventory, risk-rate your vendors, and draft the “Data Processor” contract addendums.

Get Vendor Map Audit