Breach Response & Proctoring

EdTech handles high-trust data (student records) and high-risk access (cameras). Here is how to manage the risk and the 72-hour reporting deadline.

What you must do when a personal data breach happens

A) Inform affected users without delay

On becoming aware of a breach, you must inform each affected Data Principal without delay, in a concise, clear and plain manner via the user account or registered communication mode, and include: description, likely consequences, mitigation measures, safety steps for the user, and business contact info.

B) Inform the Board: immediate + detailed within 72 hours

You must intimate the Board without delay with a description (nature, extent, timing, location, likely impact), and then provide updated/detailed info within 72 hours of becoming aware (or longer if the Board allows on written request).

Who this page is for

  • K-12 EdTech, coaching/test prep, online exams
  • Proctoring (live/AI), webcam checks, mic monitoring, screen capture
  • Doubt-solving video calls, classroom recordings
  • Outsourced proctoring vendors / sub-processors

30-minute “first response” checklist

Trigger: Any suspicious access/exfiltration, ransom, leaked credentials, exposed bucket, compromised vendor.

1. Contain

  • Disable compromised keys/tokens, rotate secrets
  • Block suspicious IPs/sessions
  • Take affected service read-only if needed

2. Preserve evidence

  • Snapshot logs, access trails, alerts, configs
  • Preserve vendor communications and timeline

3. Classify impact

  • Which systems affected?
  • Which user groups affected? (students/parents/teachers)
  • Type of data affected (contact details, exam artefacts, chats, recordings)

4. Start the “DPDP breach record”

  • Awareness time (T0)
  • Incident commander
  • Severity level
  • Decision log (why you took steps)

What your user notification must contain

Your message to affected users must include all five elements below (DPDP Rules):

  1. What happened (nature, extent, timing)
  2. What it means for the user (likely consequences)
  3. What you did / are doing (mitigation)
  4. What the user should do now (safety steps)
  5. How to contact you (business contact person)

Micro-template (short, plain-English)

Your message to affected users must include all five elements below (DPDP Rules):
• What happened: [1–2 lines]
• What data may be affected: [bullet points]
• What it means for you: [1–2 lines]
• What we did: [bullets]
• What you should do now: [password reset / caution steps]
• Contact: [name/email/phone]

Your Board report sequence should cover

  1. Immediate description without delay (nature, extent, timing, location, likely impact)
  2. Within 72 hours: updated/detailed description, event facts/reasons, mitigation, findings on who caused it, steps to prevent recurrence, and a report of user intimations sent.

Proctoring done right (privacy-by-design)

Proctoring isn’t “illegal” under DPDP by default—but it’s high-risk processing because it can involve camera, mic, face data, home environment, and behavioural monitoring. Your goal is to:
(1) provide a clear notice, (2) collect only what’s necessary, (3) lock down access and vendors, (4) retain only as needed, (5) be breach-ready.

Your notice must be standalone, in clear/plain language, and include:

  • itemised personal data,
  • specified purpose(s) and what feature/service it enables,
  • and the link/means to withdraw consent, exercise rights, and complain to the Board.

Proctoring “Just-in-time” notice (recommended UX)

Show a dedicated notice right before enabling camera/mic/screen permissions:

Proctoring Notice (example copy)

  • Data used: camera video, mic audio (if enabled), exam session metadata (time, device/browser), and flagged events (if any).
  • Purpose: verify exam integrity and prevent malpractice.
  • Retention: [X days] unless longer retention is required by law or active dispute.
  • Choices: mic optional (if your exam allows), re-attempt policy, grievance channel.
  • Controls: withdraw consent (and what it means—e.g., can’t continue exam), rights request link, complaint link.

If your EdTech serves children, you must implement verifiable parental consent before processing the child’s personal data (including for account creation and high-risk flows). The Rules describe due diligence methods and verification approaches in the child/parent scenarios.

Practical rule for exams:
If the candidate is under 18, do not start proctoring capture until the parent consent status is valid and recorded.

Collect (typical minimum)

  • Session start/end time, attempt ID, device/browser details
  • Flags (tab switch, multiple faces) as events, not constant raw streams
  • Only store recordings if you genuinely need them (policy-based)

Avoid by default (unless strictly necessary)

  • Continuous audio recording for the entire session
  • Excessive room scans, background capture, unrelated biometrics
  • Storing raw video forever “just in case”

This approach reduces your breach blast radius and makes user notice simpler and more honest.

DPDP Rules require reasonable security safeguards to prevent breach, including (minimum):

  • encryption/obfuscation/masking or virtual tokens,
  • access control for computer resources,
  • logs/monitoring/review for detecting unauthorised access,
  • backups/continuity measures,
  • processor contracts requiring safeguards,
  • technical & organisational measures to ensure compliance.

Proctoring-specific hardening

  • Separate proctoring storage from core student DB
  • Strict role-based access (proctors see only assigned sessions)
  • Watermark and audit every replay/download
  • Vendor access only through approved, logged, time-bound accounts

Rules also require keeping logs for detecting unauthorised access and continued processing capability, with a one-year retention mentioned in the security safeguards baseline (unless another law requires otherwise).

Practical retention policy for proctoring

  • Event logs: keep ≥ 1 year (security baseline)
  • Recordings/screenshots: keep only as long as needed for dispute resolution/exam policy + any legal requirements (set a strict retention schedule)
  • Vendor copies: contractually prohibit “keep forever”; enforce deletion SLAsEvent logs: keep ≥ 1 year (security baseline)
  • Recordings/screenshots: keep only as long as needed for dispute resolution/exam policy + any legal requirements (set a strict retention schedule)
  • Vendor copies: contractually prohibit “keep forever”; enforce deletion SLAs

One-page operational SOP

  • Proctoring notice enabled (just-in-time)
  • Consent captured + recorded (versioned notice ID)
  • Child check + parental consent gate where relevant
  • Minimal capture approach
  • Real-time logging + monitoring
  • Auto-apply retention schedule
  • Close access to sessions (time-bound access)
  • Keep security logs per baseline
  • User intimation without delay
  • Board intimation without delay + 72-hour detailed pack

Proctoring vendor checklist

  • Data residency / storage location declared
    Access control + MFA + audit logs
  • Breach notification SLAs (vendor → you)
  • Deletion/return of proctoring artefacts
  • Sub-processor disclosure and approval
  • Incident cooperation clauses (evidence preservation)

Is your Incident Response Team ready?

We implement the Breach Response Kit: User templates, Board reporting packs, and Proctoring notices.

Get the Breach Kit