Version privacy@2026-09-07 · In force from 2026-09-07
In force, and prepared in-house.This document is binding on Firma Limited from the date shown above. It was written by Firma Limited from the source code of the product, and has not yet been reviewed by an independent lawyer — we say that plainly rather than imply a review that has not happened. When that review takes place, no commitment made to schools, families or students will be weakened without the notice process each document describes.
Terms of Service Privacy Policy For students Data Processing Agreement Subprocessors Security TrustStudents: there is a version written for you at Your privacy, explained simply.
Firma Limited is a company incorporated in New Zealand. "Taonova" is a product name; Firma Limited is the entity responsible.
The New Zealand Privacy Act 2020 and its Information Privacy Principles are our home regime. Where a school is in the EU or the UK, GDPR / UK GDPR applies and we act as processor. Where a school is in the US, FERPA and COPPA apply and we act as a school official and as the school's agent respectively.
This policy is written to satisfy the strictest applicable requirement rather than the average. New Zealand holds an EU adequacy decision, which for an EU school is a better starting position than most non-EU vendors offer.
Your school decides which modules it uses, so not every school holds all of this.
Where a school uses the forms, student support or admissions modules, Taonova can hold, and in practice does hold, health information (medical conditions, medications, allergies, dietary requirements), emergency contact details and signed parental consent documents, and pastoral and counselling case notes, support-register entries, flags and concerns.
Under GDPR this is special category data. It raises the security bar, it means a school should complete a Data Protection Impact Assessment before putting it in, and it is why the retention rules for safeguarding records are deliberately different from everything else.
What is not collected: no location tracking, no device fingerprinting, no biometrics, no advertising identifiers, no cross-site tracking cookies, and no payment card details — card handling for the hosted service is entirely Stripe's, and we never see a card number. The only cookies are the ones needed to keep you logged in.
Mostly not from the student. It comes from the school's staff (enrolment, class lists, attendance, grades, comments, reports); from the student (their own work, uploads, messages, profile); from parents and guardians (form responses, emergency and medical details, consents, conference bookings); from the school's Student Information System where one is connected; and automatically from use of the service (login times, IP address, and server logs kept for security and troubleshooting).
For most of this the school is the controller and it is the school's basis that governs. In outline:
We do not rely on legitimate interests for anything involving an AI provider, and we do not rely on it for any form of marketing to students.
Inside the school: staff, according to the roles and permissions the school configures. Access is scoped server-side to the user's organization and role — it is not a matter of hiding menu items.
Parents and guardians, where the school has given them access, typically to their own child's records. Other students, only for content shared by design — group work, class discussions, published showcase or portfolio content.
Almost every third party in Taonova is switched on by your school, not by us. An organization administrator must set a control flag and supply that provider's own API key before anything is sent. The list applying to your school is the subset your administrator has enabled — and where your school supplies its own key, your school's contract with that provider governs, not ours.
| Recipient | What | When |
|---|---|---|
| Hosting provider and database | Everything | Always (your own, if self-hosted) |
| Email relay — on this installation, Twilio SendGrid (United States) | Recipient address and message body, which usually contains a student's name | Always, whenever email is sent |
| AI providers — OpenAI, Anthropic, Google Gemini, OpenRouter (pinned to a fixed set of upstreams: openai, anthropic, google-vertex, google-ai-studio), DeepSeek | See section 6 | Only if enabled by your school |
| AWS S3 or S3-compatible storage | Uploaded files, including form attachments containing health data | Only if configured; your school picks the region |
| Microsoft Graph / OneDrive / Teams | Documents the user opens or saves | Only if enabled; your school's own tenant |
| Student Information System — Clever, Wonde, PowerSchool, generic REST | Roster data: student and staff names and identifiers | Only if connected |
| Stripe | Organization name and billing-contact email — no student data | Hosted service only |
| Pixabay | Image search terms only | Only if enabled |
| Open Library | Book search terms only | Resource library |
| The OneDrive picker script, plus last-resort CDN fallbacks that log loudly if ever reached — the maths editor, PDF annotator and charting libraries are served from this installation's own origin | The viewer's IP address and browser — these serve scripts; we send them nothing | When the OneDrive picker loads; fallbacks only if this installation's vendored copies are missing |
We may disclose information where the law requires it, and where we are lawfully able to we will tell the school first. If Firma Limited is acquired, information may transfer to the successor, which will remain bound by this policy or one no less protective; schools will be told.
We do not sell personal information. There is no mechanism in the product by which it could be sold.
Read this before enabling one. This section is deliberately precise, because "we protect your data with AI" is the kind of sentence that is technically true and practically worthless. There are three different levels of protection depending on which feature is used, and a school should know which is which.
Every request the help assistant makes passes through a pseudonymiser first: the names of people in your organization are replaced with bracketed stand-ins — ⟦P1⟧, ⟦P2⟧ and so on — before the request leaves, and the mapping is reversed in the answer you read. The mapping is held in memory for the life of one request and is never stored or transmitted. The provider sees "⟦P1⟧ was absent 4 times", not the child's name. The stand-in is a bracketed token rather than a phrase such as "Person 1" for a specific reason: a provider asked to translate or rewrite the text will translate a phrase, and a stand-in that has been translated can no longer be swapped back — the reader would be shown the stand-in where the name should be. A token is not language, and is reproduced unchanged.
Two honest limits, both of which matter: it maps names, it does not make free text anonymous — a student's essay, a teacher's written feedback or a counselling note can identify its subject perfectly well without naming anyone; and short or word-like names are deliberately not mapped, so that a student called Grace or May does not turn every occurrence of those words into a placeholder. The full display name, which is what actually goes into these prompts, is always mapped.
Report-comment generation, feedback notes, independent-learning feedback, per-question AI comments, curriculum import and roughly seventy other places in the product all go out through one function, which builds the same shield and fails closed: if the names in a request cannot be protected, the request is not sent at all rather than sent unprotected. There is deliberately no way for a feature to opt out, because a protection each new feature has to remember is one that will eventually be forgotten.
What the shield does not do matters more than what it does. It replaces the names of people in your organization. It does not anonymise the text itself — and the text is where most of the exposure actually is. An essay, a counselling note or a report comment identifies the student it is about to anyone who knows the class, without a name appearing anywhere in it. So the honest sentence is “names are pseudonymised, content is not”, not “the data is anonymous”.
Three things cannot be pseudonymised even in principle: a voice recording sent for transcription is a child's actual voice, and a spreadsheet or document import is routinely a roster carrying names, dates of birth and medical notes. Rather than offer a fake assurance, these are switched off until an administrator explicitly allows un-redactable AI content, having been told in the interface exactly what leaves.
On top of all three, a consent gate applies. Where a request is marked as being about a particular person's data, it is refused unless consent permits it — and for a student treated as a minor, that requires the organization-level decision described in section 11. The consent gate fires wherever a request identifies whose data it is about, and not every internal call site passes that identification yet — most carry no personal data at all, and deciding which ones do is live work. The name shield above carries no such qualification: it applies to all of them unconditionally.
DeepSeek is hosted in the People's Republic of China. We do not enable it, and we recommend that EU and UK schools do not.
OpenRouter forwards requests to an upstream provider it selects, and we pin which ones. Every request carries a routing constraint limiting the upstream to a fixed set, with re-routing disabled and retention or training refused, so the recipient list is closed and enumerable. On this installation the permitted upstreams are openai, anthropic, google-vertex, google-ai-studio. It is a broker in front of providers you could also select directly, which is one more company in the path.
The retention engine, its daily scheduled job, and the screen that records a school's decision are at Organization privacy → Data retention & privacy requests, administrator-only. The categories and periods below are what the engine applies once your school records its decision.
The school decides, and until it decides, nothing is deleted. There is deliberately no default retention period. An organization that has not recorded a decision is never purged. "Keep everything" is available — but only as a recorded choice with a name and a timestamp against it, never as the state you drift into by not opening the settings page. A default that silently starts deleting school records would be worse than having no policy at all.
Retention is set per category, because a school reasons about categories, not database tables:
| Category | Recommended | Clock starts |
|---|---|---|
| AI assistant logs — questions put to the assistant and the answers returned, including any student text in them | 90 days | When the entry is created |
| Day-to-day operational data — attendance, sign-ups, timetable participation, transport rosters, messages, calendar entries | 2 years | When the person leaves the school |
| Student work and formative records — projects, posts, comments, goals, notebooks, gradebook working data, teacher feedback notes | 3 years | When the person leaves the school |
| Education records — awarded grades, completed units and courses, standards achieved, issued reports | 7 years | When the person leaves the school |
| Safeguarding and pastoral records — flags, concerns, confidential notes, support-register entries | No recommendation; kept indefinitely unless the school sets a period | When the person leaves the school |
| Not subject to retention limits — curriculum, configuration, and the data-rights audit trail itself | — | — |
Why safeguarding has no recommended number. Safeguarding retention is set by statute or by the local authority, and in several jurisdictions runs to the subject's 25th birthday — which Taonova cannot compute, because it holds no date of birth. Recommending a number we cannot justify would be worse than recommending none.
Why seven years for education records. Seven is the common floor across the jurisdictions Taonova ships into, and several require longer for a leaving transcript. A school with a longer obligation sets a longer number.
A person who has not left is never purged, however old their records are. A school can also place a legal hold suspending all purging, and the reason must be stated — the record of why deletion stopped is part of the point. Deleted data persists in encrypted backups until they rotate.
Search, preview, export, erasure, restriction and the retention policy are reachable by your own organization's administrators at Organization privacy → Data retention & privacy requests.
Ask the school first. This is not a brush-off — it is the fastest route, because the school holds the records and can see them. Correction genuinely is self-service today: staff with the right permission edit records directly, as part of ordinary use. Access, export, erasure and restriction are self-service for your school's administrators too. Where your school would rather we carried out an operation, we assist within five business days, so the school can meet its own one-month statutory deadline.
| Right | How it works today |
|---|---|
| Know what is held and get a copy (GDPR Art 15; NZ IPP 6) | An export is run for that person — see its limits below |
| Data portability (Art 20) | The same export, as structured data |
| Correction (Art 16; NZ IPP 7) | Directly in the platform, by staff with permission |
| Erasure (Art 17) | An erasure is run — see below |
| Restrict processing (Art 18) | Recorded, but only partly effective — see below |
| Object (Art 21) | Via the school, which decides as controller |
| Withdraw consent (Art 7(3)) | For consent-based processing — AI processing, media — effective from that point |
| Complain to a regulator | See section 13 |
What an export contains, and what it does not. It gathers the person's records across the collections classified as exportable and returns them as structured data. It downloads as a file. Three things we would rather state than have discovered: uploaded files are referenced, not included — the export carries links, not the files themselves; some records are deliberately sliced rather than handed over whole, and the export names every one it did that to, because a class group carries your membership row and the whole class roster, and you are entitled to your part of it and not to theirs; and one category is withheld outright with its reason attached — a pastoral, counselling or learning-support record is not released through an administrator-run export, because such records routinely name other people, so the export tells you it exists and to ask the school's safeguarding lead.
What erasure actually does. It is not a single delete. For each record it does one of four things, and reports the counts: removed (deleted outright — a real delete, not a hidden-but-retained flag); anonymised (kept but stripped of the person's identity and of denormalised copies of their name, where a record must survive for someone else's sake, such as a group discussion others contributed to — the account itself is anonymised this way rather than deleted); detached (the person removed from a membership array or recipient list, without deleting the document); or retained.
What happens to uploaded files. They are not deleted on the spot. A file is queued for deletion and removed by a housekeeping job after a grace period, and only once nothing else still refers to it — deliberately, because deleting an image that another person's post also displays would be its own kind of data loss. Journal and comment attachments, profile photographs, group banners and logos, project images and images embedded inline in the body of a post are all queued: on erasure, on the scheduled purge, and on the ordinary everyday path where somebody simply replaces their photo.
One deliberate exception, stated as an exception rather than a failure: attachments on records that are themselves retained or anonymised survive. A transcript or a safeguarding file with its evidence stripped out is not a record a school can rely on.
Erasure is sometimes refused, and we say so. The law permits, and sometimes requires, retention despite an erasure request. Taonova refuses erasure for education records, safeguarding records and the data-rights audit trail itself, and reports the refusal, the category, the count and the reason back rather than silently keeping the data. A system that quietly ignores part of an erasure request is worse than one that declines it openly. Education records can be force-deleted if the school explicitly asks and states a reason; safeguarding records and the audit trail can never be overridden.
Restriction of processing, stated honestly. A restriction recorded against a person now has four real effects: erasure refuses to run while it is in force; the scheduled retention purge skips them, and records that it skipped them; no AI provider receives their data, enforced at two independent points so that no individual feature can forget; and outbound email to or about them is suppressed and logged, matched by address rather than by an identifier a caller has to remember to pass. An export is not refused but requires an explicit confirmation, which is recorded — a request made by the restricted person themselves is exactly the case Article 18(2) permits, and refusing it would be its own breach.
What it deliberately does not do, because Article 18 read at its widest would require it: a restriction does not withdraw the person from ordinary screens, class lists, publications or reports, and it does not stop a teacher editing a record in the normal course of their work. Doing that at the display layer touches every screen in the product and can silently blank a real class list. An administrator recording a restriction should also remove the person from active groups.
Actions are audited — what was done, for whom, by whom, who asked for it, why, when it started and finished, whether it succeeded, and the per-collection counts. Erasure writes its audit row before it starts and marks it successful only after re-counting what actually changed, so a failure cannot look like a success. Erasure dry runs are audited too. The read-only summary view writes an audit row, because an unaudited full read is the one thing an audit trail exists to prevent; and a purge that deleted nothing writes a positive “ran, nothing was out of policy” row, which is what you need in order to show the job ran at all. The trail keeps the subject's identifier, never their name: a trail that proves a record was deleted must not itself become a copy of it.
What is in place. Encryption in transit. Passwords stored only as salted hashes. Access control enforced server-side, on the data-publication and method layer, scoped to the user's organization and role. Per-organization data isolation. Server-side validation of method arguments. No analytics, advertising, telemetry, session-recording or error-reporting component anywhere in the product — a whole category of leak that does not exist because the component does not exist. An automated test suite covering the server method and publication layer, plus an end-to-end browser suite, run before release.
What is not in place, stated rather than glossed. No independent penetration test and no third-party security certification — no ISO 27001, no SOC 2. No encryption at rest beyond what the hosting platform provides, and no documented key management. Monitoring exists but is narrow, and section 10 says exactly what it covers and what it cannot see.
Self-hosted installations. The school controls the environment — hosting, database, backups, encryption at rest, network security, patching. We are responsible for the security of the software we supply and for telling self-hosting customers about vulnerabilities we learn of in it.
Reporting a vulnerability. Please tell us privately. We will not pursue anyone who reports in good faith and does not access other people's data in the process.
If there is a breach of personal data we will notify the affected school without undue delay and in any event within seventy-two hours of becoming aware of it, with what we know: what happened, who and how many are affected, the likely consequences, what we are doing, and who to contact. We will not wait until the investigation is complete before telling the school.
The school, as controller, decides on notification to individuals and to its regulator; we will assist. Where a breach is notifiable under Part 6 of the New Zealand Privacy Act 2020, we will assist with notification to the Office of the Privacy Commissioner and to affected individuals.
How we find out. “Within 72 hours of becoming aware” is only worth something if something makes us aware, so here is what does. Taonova watches three things about itself and records each one where a person can read it: repeated failed sign-ins (both for one account and from one address across many accounts); an unusual number of data-request operations — exports or erasures — in a short window; and a spike in unexpected server errors. Where those cross a threshold an alert is emailed to the address in section 13. The record is written before the email is attempted, so a mail problem delays the alert rather than losing it.
The same log also keeps a record of the passkey security check described in Security Practices section 3, where a school has switched it on — who enrolled a passkey, whose confirmation succeeded or failed, and any administrator who cleared somebody's credentials. Those are records rather than detectors: they raise no alarm by themselves. The three things above are still the whole of the monitoring.
What that does not cover, because it matters more than what it does. This is not intrusion detection. It does not watch the server, the network or the database directly, and it cannot tell that someone signed in with a stolen password — a successful sign-in looks like a successful sign-in. It is the honest floor for a small company, not an enterprise security operation, and section 9 says plainly that we hold no security certification.
For a narrow set of data we are the controller, not the processor: the billing contact's name and email, the account details of the people who administer a subscription, correspondence with us, and our own security and operational logs. We use it to run the account, take payment, provide support and secure the service. We keep it for the life of the relationship plus seven years for tax and legal purposes. We do not use it for advertising and we do not sell it.
Children are the main data subjects here, and the design assumption throughout is that a student may be a child.
COPPA — school as agent. For US schools we operate on the standard edtech basis: the school contracts with us and provides consent on parents' behalf for school-directed educational use. The commitments that make that proper — no advertising, no sale, no commercial profiling, no model training, deletion on request, a stated retention period — are contractual and binding.
FERPA — school official. For US schools we act as a school official with a legitimate educational interest, under the school's direct control, and we do not redisclose education records.
Age of digital consent. The default is 13, and a school may set a higher threshold where its member state requires it. Because the product has held no date of birth for anybody, a student whose age nobody has recorded is presumed to be a minor — the privacy-safe reading, and the only default that works in a product with no date of birth. Supplying an age can therefore only ever relax that presumption, never tighten it. Staff are exempt, because they hold a staff role; an adult-education institution can opt out of the presumption entirely.
A student cannot consent to AI processing of their own work. Asking a child to do that is not a defensible consent under GDPR Article 8 or under COPPA, so the product refuses it: the student-facing setting is a "don't ask me again" preference that grants nothing, and an attempt to self-consent as a minor is rejected outright.
What this means for your school: AI processing of a student's work requires the school to have recorded its own decision, as the party able to consent on parents' behalf. An organization that has never recorded one will find AI for students does not run — that is the safeguard working, not a fault.
The school determines what consent its law requires; Taonova does not set the standard. Whether school-recorded consent suffices, whether verifiable parental consent must be obtained from each parent directly, and what age thresholds apply are determinations for the school under its own law. Taonova's part is mechanical: it records the school's decision, enforces it, and applies its own stricter default only where no decision has been recorded at all.
Automated decision-making. Two things in Taonova happen without a person: a scheduled job can mark a student's unit or course complete based on entered grades; and AI can give feedback on student work, where a school has enabled it.
The safeguard is human intervention, and it is real: auto-completion is subject to a staff confirm/veto step, and a teacher can review and change any outcome. A computer does not have the final say about a student's progress. Neither produces a legal effect on the student in the Article 22 sense, in our view — a unit completion is a school record a teacher can change. But we document them as automated processing with a human safeguard rather than argue the point silently, and a student or parent may always ask a teacher to review any outcome.
The honest qualification: the veto is post-hoc. The completion takes effect before any human sees it, and is then reviewed. That is defensible for a completion marker — it is a school record a teacher can change, not a decision about a student's rights — but it is not prior human review, and we would rather say so than let the phrase “confirm/veto” imply otherwise.
Firma Limited, a company incorporated in New Zealand. New Zealand Business Number 9429036053421.
Registered office and address for formal service:
64 Ngatiawa St, One Tree Hill, Auckland 1061, New Zealand
For privacy questions, data-subject requests, security reports and legal notices: info@taonova.com, a monitored mailbox. We acknowledge within five business days and respond substantively within one month.
Ask your school first. For anything about a student's records the school is the controller, and they can usually act faster than we can — see section 8.
EU representative (Article 27). None is designated today, because we have no EU-established school. One will be appointed before the first EU school is onboarded — we are not willing to rely on the “occasional, low-risk” exemption for children's education records. Until then the address above is the contact for all notices.
Data Protection Officer. We have not appointed one, and that is an assessed position rather than an oversight. A DPO is required for large-scale monitoring or large-scale special-category processing; we do process children's health data, but “large scale” turns on volume and reach rather than sensitivity alone, and at our current size we do not meet it. We reassess at the twenty-fifth school, or at the first EU school, whichever comes first.
Raise it with your school first — as controller, most matters are theirs to resolve. If that does not resolve it, contact us; we will acknowledge within five business days and respond substantively within one month.
You may complain to a regulator without going through us first, and nothing in our terms restricts that. In New Zealand, the Office of the Privacy Commissioner. In the EU, your national supervisory authority. In the UK, the Information Commissioner's Office. In the US, the Department of Education for FERPA and the Federal Trade Commission for COPPA.
Each version has an identifier and a date it came into force. We will give at least thirty days' notice of a material change, by email to the school's billing contact and by a notice in the product. We record which version each organization accepted, and when. Superseded versions are kept, so it is always possible to establish what a school agreed to.
Taonova is a product of Firma Limited, a company incorporated in New Zealand. Governing law: New Zealand.
New Zealand Business Number 9429036053421. Registered office: 64 Ngatiawa St, One Tree Hill, Auckland 1061, New Zealand.
Privacy questions, data-subject requests, security reports and legal notices: info@taonova.com.
Terms of Service Privacy Policy For students Data Processing Agreement Subprocessors Security Trust