Schools & Institutions Privacy Addendum
Last updated: July 27, 2026
This addendum supplements our Privacy Policy and applies when an institution — a school, language centre, or test-preparation provider — uses the Essay Climb School Console to manage student accounts. It describes what we collect about managed students, who can see it, where it goes, and what we will and will not do with it.
Where this addendum and the main Privacy Policy differ, this addendum governs for managed student accounts. Everything not addressed here is governed by the main policy.
1. Roles — who is responsible for what
When an institution provisions student accounts through the School Console, the institution is the data controller and CanHorizon Inc. is the data processor. We process student data on the institution's documented instructions in order to provide the Service.
This means the institution decides which students are enrolled, what work is assigned, and how long accounts remain active. It also means the institution is responsible for having a lawful basis for the processing and for giving students — and, where students are minors, their parents or guardians — appropriate notice. See Section 10.
We will enter into a written data processing agreement with any institution that requests one. Contact support@essayclimb.com.
2. What we collect about a managed student
What we do collect
- Name — as entered by the institution (family and given name, or a single full name).
- A system-generated login in the form
code123@stu.essayclimb.com. This is an internal identifier, not a mailbox. - Native language and writing goal — used to tailor feedback.
- Writing submissions — the essay text, the AI-generated scores and feedback, detected errors, time spent writing, and submission history.
- Learning activity — study modules read, practice exercise scores, assignment completion.
- Teacher feedback and Q&A threads — comments a teacher leaves and questions the student asks.
What we deliberately do not collect
- No student email address. Managed students are issued a placeholder login on a domain we control. Students never receive email from us, and we hold no personal mailbox for them.
- No payment or billing data. Institutions are invoiced directly. Managed students have no payment method, and the personal billing interface is disabled on their accounts.
- No date of birth, address, phone number, or government identifier. The Console does not ask for these and there is no field to store them.
- No advertising identifiers or ad-tech cookies.
Essays are free text, so we ask institutions to instruct students not to include personal details about themselves or third parties in their writing. Writing prompts are designed not to elicit them.
3. Who can see a student's work
| Who | What they can see |
|---|---|
| The student | Their own work, scores, feedback, and progress. Nobody else's. |
| Their teacher | Submissions, scores, feedback, and progress for students in classes they teach only — enforced in the database, not just the interface. |
| School administrators | The same, across their own institution. Never any other institution. |
| Essay Climb staff | Only for support, troubleshooting, and account administration — and every view of a student submission is recorded in an audit log. See Section 4. |
| Other students | Nothing. There is no student-to-student visibility anywhere in the Service. |
Access is enforced by row-level security policies in the database, so a teacher cannot retrieve another class's data even by manipulating a request.
4. Our own access is audited
Essay Climb operators have an administrative view of institution accounts for support purposes. That view is deliberately limited and monitored:
- Every time an operator opens a student submission, we write an audit record — who accessed it, which institution, which record, and when.
- Student credentials are not surfaced in the operator view.
- An institution may request an extract of the audit log for its own accounts at any time.
5. Sub-processors and where data goes
| Provider | Purpose | Location |
|---|---|---|
| DeepSeek | AI evaluation — the essay text is sent for scoring and feedback | China |
| Supabase | Database and authentication — all account data and submissions | United States |
| Vercel | Application hosting; standard server logs | United States |
| Stripe | Institutional payments only — no student data | United States |
| Resend | Email to staff only — managed students receive no email | United States |
Please read this before you sign
Student essay text is sent to DeepSeek, an AI provider based in China, for evaluation. This is central to how the Service works — it is the step that produces the score and the feedback. What we send is the writing prompt, the essay text, and the student's stated native language, which the feedback depends on. The student's name, login, account identifier, institution, and class are never included — DeepSeek receives the writing, not the identity of the writer. Processing is subject to DeepSeek's privacy policy.
We are telling you this plainly because some institutions have policies that prohibit sending student work outside a particular jurisdiction, and we would rather you find that out now than after a pilot. If your institution requires that student work is not processed in China, contact us before signing — talk to us about it rather than assuming the answer is no.
We will give institutions advance notice of any change to this list of sub-processors.
6. International transfers
CanHorizon Inc. is established in Ontario, Canada. Data is stored in the United States and, as described in Section 5, essay text is processed in China during evaluation. Institutions in the European Economic Area, the United Kingdom, or other jurisdictions with data-transfer restrictions should review Section 5 carefully and raise any requirements with us before enrolling students.
7. Student credentials and security
Because managed students have no email address, they cannot reset their own password by email. Password recovery is therefore handled by the institution's staff. To make that possible:
- When an account is created or reset, the system generates a random temporary password and stores it so that the institution's administrators can read it back and hand it to the student.
- The stored temporary password is erased permanently the moment the student changes it in Settings.
- It is never exposed through the ordinary application interface, never shown in the Essay Climb operator view, and is readable only by the institution's own administrators.
- It is a one-time random value, not a password the student chose and may reuse elsewhere.
We recommend institutions require students to change their password at first login. Until they do, the temporary password remains readable by school administrators by design.
All connections are encrypted in transit (HTTPS/TLS). Passwords that students set themselves are stored only as salted hashes. Access between institutions is separated by database-level row security.
8. Retention, disabling, and end of contract
- While the contract is active, student data is retained so students and teachers can see progress over time.
- Disabling a student immediately revokes their access and frees the licence seat. Their work is retained and visible to the institution unless deletion is requested.
- At the end of the contract term, access ends automatically for the institution's staff and students.
- On written request from the institution, we will delete or export its student data. Deletion completes within 30 days; residual copies in encrypted backups are purged within 90 days.
Institutions should tell us at the end of a contract whether data is to be deleted or retained for a renewal. If we hear nothing, we retain it for 12 months and then delete it.
9. What we will and will not do with student work
We will not
- Use student writing to train AI models — ours or anyone else's.
- Sell or rent student data. Ever, to anyone.
- Show advertising to students, or use their data for advertising.
- Share one institution's data with another.
- Publish, quote, or reference an identifiable student's work or scores — including in case studies, marketing, or product demonstrations.
We will, on these terms
- Aggregate scores to build the institution's own dashboards and reports — this is part of delivering the Service.
- Publish aggregated outcome results in a case study only with the institution's written permission, only in aggregate, only where the group is large enough that no individual can be identified, and only after the institution has reviewed the draft and approved it. An institution may decline, and may withdraw permission for future publication at any time.
- Combine anonymised results across institutions to improve the Service or publish general benchmarks only where the institution has opted in. This is off unless it is switched on.
10. Students under 18
The Service is not intended for children under 13, and institutions must not enrol them.
For students aged 13 to 17, the institution is responsible for obtaining any parental or guardian consent its own law requires, and for giving students and parents notice that the Service is in use and what it does. We provide this addendum so that notice can be given accurately. Tell us during onboarding if the cohort includes students under 18, so we can make sure the arrangement is documented correctly.
11. The institution's responsibilities
- Enrol only students it is entitled to enrol, and remove them when they leave.
- Give students — and parents or guardians where applicable — notice that the Service is being used.
- Keep student credentials secure and distribute them only to the student concerned.
- Instruct students not to include personal details about themselves or others in their essays.
- Tell us promptly if a student's data must be deleted or exported.
12. Student and parent requests
Because the institution is the controller, a student or parent wishing to access, correct, export, or delete data should contact the institution in the first instance. If a request reaches us directly, we will refer it to the institution and assist them in responding, rather than acting on it unilaterally — except where law requires otherwise.
13. Security incidents
If we become aware of a breach affecting an institution's student data, we will notify that institution without undue delay and no later than 72 hours after becoming aware, with the facts as we know them, the likely consequences, and the steps we are taking. As the controller, the institution is responsible for any onward notification to a regulator or to affected individuals; we will support it in doing so.
14. Changes to this addendum
We may update this addendum. We will notify institutions with an active contract by email before a material change takes effect. The "Last updated" date above indicates the most recent revision.
15. Contact
CanHorizon Inc.
For data processing agreements, audit log extracts, deletion or export requests, or any question about this addendum, contact support@essayclimb.com.