← White Coat World

Data Processing Agreement

Template version: July 2026 — not an executed agreement

Template — for discussion. This page is a starting point for institutional partners. The binding DPA is the version signed by both parties after review by counsel. To request a signable copy or negotiate terms, use our contact form. We also publish security@whitecoatworld.org, but inbound delivery to that address is still being provisioned, so please use the form if you need certainty your request arrived.

1. Roles

For student education records supplied by or generated within a partner institution, the institution is the data controller (and the FERPA record owner) and White Coat World is the data processor / School Officialunder 34 CFR § 99.31(a)(1)(i)(B). We process such data only on the institution's documented instructions and for the purpose of providing the service.

2. Scope & Purpose

We process the categories of student data described in our Privacy Policy (profile, academic metrics, application materials, and engagement data) solely to deliver gap analysis, school matching, faculty review, and outcome reporting. We do not sell, license, or use student data for advertising, and we do not use it to train third-party AI models.

3. Sub-Processors

We engage the following sub-processors under written terms that impose data-protection obligations no less protective than this agreement. The same set is described, in plainer terms, in our Privacy Policy and on our Security page; where the three differ in wording they must not differ in membership, and this list governs:

  • Supabase — database & encrypted object storage (data at rest, AES-256).
  • Vercel — application hosting.
  • Google Gemini — AI gap analysis (inputs pass through our PII scrubber / anonymizer; Google's API terms prohibit training on inputs). The AI provider can be pinned per institution where required, and a pinned provider that is not configured causes the request to fail rather than fall back to Google. An alternative Microsoft Azure OpenAI provider is implemented but has not yet been exercised in production; it would be configured and validated against the institution's tenant during onboarding.
  • Resend — transactional email (faculty notifications; account verification and password-reset links).
  • Upstash — rate limiting / ephemeral cache. Holds IP addresses, account identifiers, and phone numbers as short-lived keys; no application content.
  • PostHog — server-side, PII-free product analytics.
  • Have I Been Pwned — password breach check on credential creation. Receives only the first five characters of a SHA-1 digest (k-anonymity); no password and no identity is transmitted.
  • Google Maps / Places — browser-side autocomplete for the optional location field in the social layer.
  • YouTube — video hosting. Embedded directly on the public marketing homepage, where it loads with the page and sets Google cookies for visitors. Also used for Boards & Tests lesson videos on authenticated pages, where the player is click-to-load: nothing is requested from Google until a Data Subject presses play, and the request then carries only the video identifier — no Personal Data and no education records.
  • Twilio — SMS one-time codes. Implemented but not active: no credentials are provisioned, so no SMS is sent and no phone number reaches Twilio under the current configuration.
  • Sentry — error monitoring, PII collection disabled with an additional scrubbing pass. Implemented but not active: no DSN is configured, so no error data leaves the application under the current configuration.

The two entries marked not active are disclosed because activating them is a configuration change rather than a code change; the institution would receive notice before either is enabled. We will likewise give the institution notice of any new sub-processor and an opportunity to object.

4. Security

Encryption in transit (TLS) and at rest (AES-256); row-level security and least-privilege service-role access; audited access to student records; and defense-in-depth controls described on our Security page. We notify the institution without undue delay upon confirming a personal-data breach affecting its students.

5. Retention, Return & Deletion

Soft-deleted records are permanently purged within 30 days by a scheduled job; audit-log entries roll off after 12 months. On termination, or on the institution's request, we return or delete institutional and student data. Students may export their own data and permanently erase their account at any time (right to erasure).

6. Data-Subject Rights & Assistance

We assist the institution in responding to student/parent requests to access, correct, or delete records, and in meeting its FERPA, and where applicable GDPR/CCPA, obligations. Requests should be directed through our contact form, which is the channel we monitor. We also publish security@whitecoatworld.org, but inbound delivery to that address is still being provisioned, so please use the form if you need certainty your request arrived.

7. Term & Termination

This Agreement takes effect on the date of last signature and continues for as long as we process institutional or student data for the Institution. Either party may terminate for material breach on thirty (30) days' written notice if the breach is not cured within that period, and the Institution may terminate for convenience on thirty (30) days' written notice. On termination we stop processing, and within thirty (30) days return or delete institutional and student data at the Institution's election, except where retention is required by law. Sections 4, 5, 6, 8, and 9 survive termination.

Student accounts are not terminated by the end of this Agreement. A student's profile is their own and persists independently; what ends is the institution's access to it and our processing on the institution's behalf.

This is deliberate, and it protects the Institution as much as the student. A pre-health application runs four to eight years and routinely outlasts a student's enrolment, so tying the account's life to the contract would destroy a student's own work — their essays, their logged hours, their plan — for reasons that have nothing to do with them, and would leave the Institution explaining it. The two are separable rather than conflated: education records the Institution supplied, or that were generated within the institutional relationship, are handled under the paragraph above and are returned or deleted at the Institution's election. What persists is the student's own account, which reverts to the direct arrangement described in the Privacy Policy, with White Coat World as controller under that student's own consent and no institutional access until a new agreement and a new consent exist.

8. Liability

Liability under this Agreement is governed by the written services agreement or order form between the parties. Where none exists, Section 11f of the Terms of Use applies: institutional accounts are not subject to the consumer damages floor, disputes proceed under the AAA Commercial Arbitration Rules, and a signed agreement between the parties supersedes the online terms wherever the two conflict. Nothing in this Agreement limits either party's liability for a breach of its confidentiality or data- protection obligations, or for gross negligence or wilful misconduct.

9. Authority to Bind

Each signatory represents that they are duly authorized to enter into this Agreement on behalf of the party they represent, and that doing so does not conflict with any other obligation of that party. The individual who accepts the Institutional Account Addendum in the product makes the same representation for the account itself — that Addendum is the agreement actually accepted in-product, and this document is what the parties execute alongside it.

10. Signatures

This template becomes binding only when executed by both parties. Until then it is provided for review.

Institution

Signature
Printed name
Title
Date

White Coat World

Signature
Printed name
Title
Date

Privacy Policy · Terms of Use · Institutional Addendum · Security