Privacy by Design vs. Privacy Policy: The Technical Difference That Matters for Assessment Programs

Every proctoring vendor has a privacy policy. What differs from one vendor to the next is whether the product itself is built so that the policy is hard to break. A privacy policy describes what a vendor intends to do with personal data, while privacy by design determines what the vendor is technically able to do with it. For an assessment program that carries the compliance liability, the second matters far more than the first.

What a Privacy Policy Can and Can't Do

A privacy policy is a statement of intent. It tells test takers what a vendor says it collects, how long it says it keeps that data, and who it says can see it. That has real value for transparency, but it comes with three limits worth understanding.

First, a policy only works as long as everyone behaves as written, including every engineer, support agent, and subcontractor who touches the data. Second, a policy can change, so the version a candidate agreed to may not be the version in force a year later. Third, a policy says nothing about what the system collects in the first place. A tool can describe modest data practices in its policy while its architecture still captures far more than the exam requires.

What Privacy by Design Means in Practice

Privacy by design moves protection out of the document and into the system. GDPR treats this as a legal expectation under Article 25, which calls for data protection to be built into processing from the outset. PIPEDA doesn't use the phrase, but its principles on limiting collection, limiting retention, and safeguards point in the same direction.

A useful test is to imagine the privacy policy disappearing tomorrow and ask what would still stop the system from over-collecting or over-retaining. If the honest answer is that the team would simply have to remember, the protection lives in the policy. If the honest answer is that the system can't do it, the protection lives in the design.

Four Design Choices That Make the Difference

Collect less at the source. Identity verification at Integrity Advocate uses OCR to read the name on a government ID and nothing else. The platform doesn't collect learners' programs, browsing history, or desktop files, so that data never exists to be misused. This is also why automated identity checks alone aren't enough for high-stakes exams: collecting less only works when the checks that remain are reviewed by a person.

Process on the device. Biometric processing happens on the test taker's own device rather than being sent to servers for processing. That reduces the amount of data in transit and the amount that ever reaches a database.

Delete automatically. Identification images and media for compliant sessions are deleted within 24 hours of session completion. Deletion timelines are applied programmatically as each session ends, so the schedule doesn't depend on someone remembering to run a cleanup. Data kept to support a finding is held for a limited, defined period.

Build consent and access into the flow. Test takers give positive consent to a privacy statement, offered in both summary and full form, before every use. After a session, a post-event email lets them review the data retained about them and the decisions made.

Underneath all four sits standard security, with data encrypted in transit and at rest and hosted on secure servers in Canada.

Why This Matters for Assessment Programs

Your organization is the data controller, which means accountability for how a vendor handles candidate data sits with you. Data that was never collected can't be breached, subpoenaed, or mishandled, so design choices that reduce what exists reduce your exposure directly. Our compliance brief on what your vendor must be able to prove under GDPR and PIPEDA covers the accountability side in more detail.

There is a test taker side to this as well. Less intrusion means less anxiety, and less anxiety means more trust in the program and in the results it issues.

Collecting less also doesn't weaken defensibility. When a session is flagged, the evidence and the reviewer's reasoning are retained so the outcome can be explained and defended, while routine data from compliant sessions is not kept. Privacy and defensibility rest on the same principle, which is to keep what you need to stand behind a result and nothing beyond that.

Integrity Advocate has operated for more than 12 years without a data breach, and part of the reason is straightforward: personal data that was never collected can't be taken.

Questions That Separate Design From Policy

When you evaluate a proctoring vendor, these questions show where the protection actually lives:

1. What does the system collect at identity verification, field by field, and what is it technically unable to collect?
2. Where does biometric processing happen, on the test taker's device or on your servers?
3. Is deletion scheduled and enforced by the system, or does it depend on someone acting?
4. If your privacy policy changed tomorrow, which protections would remain because of how the product is built?
5. Can a test taker see what data you hold about them without filing a request?

Clear, specific answers to these tell you far more than a compliance badge or a policy link in the footer.

{{post-cta}}