The compliance question isn't rhetorical
Every institution using online proctoring is a data controller under GDPR. The proctoring vendor is a data processor (or sub-processor). This distinction matters: the institution is ultimately responsible for what happens to student data.
Most proctoring vendors provide a Data Processing Agreement (DPA) and a lengthy privacy policy. These documents are necessary — but they're also insufficient. They describe what the vendor promises to do. They don't change what's technically possible under the architecture they've built.
This article breaks down the GDPR articles that are most directly relevant to online exam proctoring, what each one actually requires, and how ProctorSafe's on-device architecture addresses them structurally.
Article 5(1)(c): Data Minimisation
The text: "Personal data shall be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed."
What it means for proctoring: The only data that should be collected is data that is actually needed to assess exam integrity. If video recordings are stored for 90 days "just in case" of a dispute, that storage must be justified — and in most cases, it isn't. Event metadata (timestamps, flag types, trust scores) is directly relevant. Raw video of the candidate's home environment is not.
ProctorSafe's approach: The SDK collects behavioral signals only — focus events, tab switches, interaction density. Nothing is collected that isn't directly relevant to the question of exam integrity. Event logs are retained for a configurable period (default: 30 days) and then automatically purged. No video, audio, or images are ever collected.
Article 5(1)(b): Purpose Limitation
The text: "Personal data shall be collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes."
What it means for proctoring: Data collected for exam integrity assessment should not be used for anything else — not student profiling, not behavioral analytics beyond the exam context, not training AI models. Institutions should verify that their vendor isn't using session data for secondary purposes.
ProctorSafe's approach: The purpose of processing is defined at session start: assessment integrity only. Event logs are signed and time-bound. They are not used to build behavioral profiles across sessions or shared with third parties. The institution retains full control over how data is used and retained.
Article 5(1)(e): Storage Limitation
The text: "Personal data shall be kept in a form which permits identification of data subjects for no longer than is necessary."
What it means for proctoring: Retention periods must be justified and proportionate. 90-day video retention for every session, including the vast majority that conclude without incident, is difficult to justify under this principle. Event logs for sessions without flags have little ongoing value beyond the grade submission period.
ProctorSafe's approach: Logs are retained for a configurable period (default: 30 days). Institutions can set shorter periods for sessions that close without flags — at which point the data has no ongoing purpose. Sessions that generate flags are retained longer to support review, but only for as long as the review process requires.
Article 9: Processing of Special Category Data
The text: "Processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or biometric data... shall be prohibited."
Biometric data — including face geometry used for identity verification — is a special category under Article 9. Processing it is prohibited unless a specific exemption applies (e.g., explicit consent, or necessity for a legitimate interest with appropriate safeguards).
What it means for proctoring: Many proctoring platforms extract face vectors or perform facial recognition as part of identity verification. Under GDPR, this requires explicit consent (which is questionable when the alternative is being barred from your exam) and a documented lawful basis. The data may also need to be retained to demonstrate the verification occurred.
ProctorSafe's approach: ProctorSafe does not perform facial recognition. Identity is verified via LTI launch context — the candidate's identity is asserted by the institution's LMS at session start. No biometric data is collected, stored, or processed. This sidesteps the Article 9 question entirely.
Article 25: Data Protection by Design and by Default
The text: "The controller shall... implement appropriate technical and organisational measures... such as data minimisation."
Article 25 requires that data protection be built into the architecture of a system, not added as an afterthought. The concept of "privacy by design" — embedded in the GDPR from its 2012 origins — is enforceable here.
What it means for proctoring: A privacy policy that promises data is minimised is not sufficient if the technical architecture collects more than it needs. If a breach of the vendor's servers would expose student video recordings, that risk exists regardless of what the policy says. Data protection by design means the architecture itself enforces the principle.
ProctorSafe's approach: This is the core differentiator. The on-device SDK architecture is not a policy — it is a technical enforcement. There is no server that holds video because there is no video to hold. The event log is the only data transmitted, and it is HMAC-signed and encrypted. Data protection is built into the architecture, not layered on top of it.
Article 32: Security of Processing
The text: "The controller and processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk."
What it means for proctoring: The risk of storing video of students' homes and biometric data is high. A breach would expose not just identity, but intimate details of a person's living situation. This requires commensurate security measures.
ProctorSafe's approach: Because video, audio, and biometric data are not collected, the attack surface is fundamentally smaller. The only data stored server-side is signed event metadata — not images of students, not face vectors, not private home environments. Even in the event of a server breach, the exposure is limited to a log of session events, not personal or biometric data.
Article 17: Right to Erasure
The text: "The data subject shall have the right to obtain from the controller the erasure of personal data concerning them."
What it means for proctoring: If a student requests deletion of their proctoring data, the institution must be able to comply. With video-based proctoring, this means identifying all footage of that student, across all sessions, and ensuring it is deleted from primary storage, backups, and any vendor systems. This is operationally complex and frequently neglected.
ProctorSafe's approach: Because the only server-side data is event logs — which contain no images, no biometric data, and no content — erasure is straightforward. The session can be marked for deletion, and all associated event records are purged from the system. No video archival to locate and remove.
Summary: Architecture vs. Policy
| GDPR Article | What it requires | Traditional proctoring | ProctorSafe |
|---|---|---|---|
| Art. 5(1)(c) Data minimisation | Collect only what's necessary | Video + audio + biometrics stored | Behavioral signals only |
| Art. 5(1)(b) Purpose limitation | Don't repurpose data | Often unclear in vendor policies | Explicit purpose at session start |
| Art. 5(1)(e) Storage limitation | Don't retain beyond necessity | 30–90 day video archives | Configurable log retention |
| Art. 9 Biometric data | High bar; special category | Face vectors often collected | Not collected |
| Art. 25 Privacy by design | Build it in, don't add it on | Policy-layer privacy | Architecture-layer privacy |
| Art. 32 Security | Appropriate to risk | High risk — large sensitive data surface | Low risk — no sensitive data stored |
| Art. 17 Erasure | Deletable on request | Complex — locate video across systems | Simple — purge event log |
The institutional question
When you're evaluating a proctoring platform, the right question isn't "do they have a GDPR DPA?" Every vendor can produce a DPA. The right question is: what would a data breach of their system expose?
If the answer is video of your students' homes, face scans, and behavioral logs — the DPA is a legal document covering a risk that should never have been created.
If the answer is a timestamped, HMAC-signed event log with no images or biometric content — the compliance posture is structurally different. The risk is lower by design, not by promise.