Proctoring and Biometric Data: DPDP, GDPR Article 9, and BIPA

Why proctoring data is biometric data

A proctored exam does more than take a photo. To tell whether the person on camera is the registered candidate, ProctorLink derives a face template from each keyframe and matches it against a reference photo. That template, a mathematical representation of a face used to identify a specific person, is what the law treats as biometric data, and it is held to a higher standard than an ordinary photograph. The ProctorLink API reference states the position plainly: facial images are biometric data under India’s DPDP Act, GDPR Article 9, and similar laws, and you must obtain the candidate’s explicit consent before starting a session.

Because the classification attaches at the moment of capture, you cannot treat a frame as ordinary data and reclassify it later. The reference photo, every captured keyframe, and the match scores in the report are all biometric from the start. For what those frames can and cannot actually establish, read what browser-based proctoring can and cannot detect, and for how the match becomes a verdict, read how to design an exam integrity score.

Consent has to come before the first frame

Every one of these laws treats consent as the usual lawful basis for processing biometric data, and all of them want it before capture, not after. The trap is to lean on the browser’s camera permission prompt as if it were consent. It is not. A candidate clicking Allow grants the browser camera access; it records nothing about whether they understood what is collected, why, and for how long. That understanding is what consent means, and it is yours to obtain and to log.

In practice this means a consent step in your own flow, before you call start() on the SDK. Capture, and the face template, only begin once start() runs, so the consent gate sits cleanly in front of it.

// Legal consent is yours to collect and record, before capture begins.
// The camera permission prompt is not consent — it only grants access.
if (!candidate.hasGivenBiometricConsent) {
  return showConsentScreen();   // explain what, why, how long; record the answer
}

const session = ProctorLink.createSession({ jwt, sessionId });
await session.start();   // first frame — and the face template — only after consent

Keep a record of the consent you collected, tied to the same attempt. If a candidate declines, do not start the session. For how a session is minted and run end to end, see proctoring SDK vs API vs LMS plugin.

Retention, deletion, and sub-processors: who owns what

Collecting biometric data lawfully is the start; what you do with it afterwards is the rest. Three obligations sit with you as the institution running the exam, and the architecture is built to support each. Retention is configurable, and ProctorLink supports deletion on request, but the period you choose and the deletion requests you honour are decisions you own, scoped to your regulator and your appeals window.

One detail worth knowing for data handling: when you fetch the report, each evidence frame’s image_url is a short-lived signed URL, not a permanent link. Fetch or copy the image promptly rather than storing the URL, and treat the images you pull down as biometric data inside your own retention policy. For the specific retention options, a data processing agreement, and the current sub-processor list, talk to sales. This page does not assert certifications or a named data-residency region, because those are commitments that belong in a contract, confirmed in writing, not on a knowledge page.

Common mistakes

• Treating the camera prompt as consent. Clicking Allow grants browser access, not informed consent. Fix: collect explicit, purpose-specific consent in your own flow and record it before you call start().
• Sending names or emails as the user ID. It puts identifying data where it does not need to be. Fix: pass an opaque internal identifier as external_user_id and resolve it to a candidate in your own records.
• Leaving retention undefined. “Keep it indefinitely” is not a policy and fails under all three laws. Fix: choose a retention period scoped to your appeals window, document it, and configure it with sales.
• Scoping only to GDPR when candidates sit from Illinois. BIPA’s per-violation statutory damages apply regardless of where you are based. Fix: scope consent and retention to the strictest regime your cohort touches.
• Overstating what a flag proves. Reporting “the candidate cheated” from a probabilistic score invites a challenge you cannot win. Fix: report frames where no face was detected and match scores as evidence for human review.

Frequently Asked Questions

Next steps

Want to see exactly what a session captures and stores before you write your consent and retention policy? Sign up at app.proctorlink.com to get your API keys, run a session, and read the report end to end.

More Proctoring Guides