Version dpa@2026-08-29 · In force from 2026-08-29
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 TrustA Privacy Policy is a transparency notice to individuals. A Data Processing Agreement is a contract between two organizations that GDPR Article 28(3) requires to exist, in writing, with a specific list of terms in it. They are not substitutes. What follows is the full standard form of the agreement, published so a procurement office or Data Protection Officer can read every clause before asking for anything. It takes effect between Firma Limited and a particular school when signed, as a separate instrument — it is not accepted by clicking a box, and reading this page binds nobody. To execute it, or to have us review your own DPA template instead, write to info@taonova.com.
A school's procurement office or Data Protection Officer will know the difference between a transparency notice and an Article 28 contract within about ten seconds of looking. This is that contract. It is drafted to satisfy GDPR and UK GDPR Article 28, and to serve at the same time as the written commitment a US school district needs under FERPA's school-official exception and under COPPA's school-as-agent model, and as the assurance a New Zealand school needs under the Privacy Act 2020.
1.1 This Agreement is between Firma Limited and the school, school group, district or other organization that has subscribed to or licensed Taonova (the "Customer"). It forms part of, and is subject to, the agreement under which the Customer uses Taonova (the "Main Agreement" — the Terms of Service).
1.2 Roles. For all personal data relating to the Customer's students, their families, and the Customer's staff: the Customer is the controller (GDPR), the educational agency or institution (FERPA), the operator of the school-as-agent consent (COPPA), and the agency holding the information (NZ Privacy Act 2020); Firma Limited is the processor (GDPR) and a school official with a legitimate educational interest under FERPA, acting under the Customer's direct control.
1.3 Firma Limited is a controller only in respect of a narrow set of data it processes for its own account: the Customer's billing contact details, the account records of the individuals who administer the Customer's subscription, and Firma Limited's own security and operational logs. That processing is described in the Privacy Policy (§11) and is not governed by this Agreement.
1.4 Self-hosted installations. Where the Customer runs Taonova on its own infrastructure, Firma Limited does not process the Customer's personal data at all in the ordinary course, and most of this Agreement applies only to the extent Firma Limited is given access — for example during support. The Customer should not accept a DPA that implies otherwise, and clause 14 sets out what is actually true for self-hosted deployments.
2.1 Subject matter. Provision of Taonova, a school management, teaching and learning platform, to the Customer.
2.2 Duration. From the effective date of the Main Agreement until it terminates or expires, plus the return-and-deletion period in clause 12.
Firma Limited processes the Customer's personal data solely to provide, maintain, secure and support Taonova for the Customer. Concretely: hosting and storing records the Customer and its users create; making those records available to the users the Customer authorises; performing the functions the Customer's users invoke — recording attendance and assessment, generating reports, running the gradebook, managing groups, events, conferences, forms and the resource library; sending email the Customer's configuration and users cause to be sent; synchronising rosters with a Student Information System the Customer has connected; transmitting content to an AI provider only where the Customer's administrator has enabled one and supplied its API key (clause 8); backing up, restoring, monitoring and securing the service; and providing technical support when the Customer requests it.
Firma Limited will not process the Customer's personal data for any other purpose. In particular, and as binding commitments rather than statements of current practice:
The first three of these are the commitments COPPA's school-as-agent model requires; the fourth is what an EU school will ask about first; the fifth is what distinguishes a defensible SaaS from an extractive one.
Students (who are, in the majority of the Customer's use, children); parents, guardians and other family contacts; teaching and support staff; school administrators; and, where the Customer uses those modules, applicants for admission, applicants for employment, alumni and external contacts.
5.1 Ordinary personal data. Names; email addresses; usernames and hashed credentials; profile photographs; class, group and event memberships; year level and roll status; attendance; assessment, grades, standards achieved and course and unit completion; teacher comments and reports; student work, journal posts, project evidence and uploaded files; timetable and calendar data; conference bookings; messages and comments within the platform; and identifiers used to match against the Customer's Student Information System.
5.2 Special category and sensitive data. The Customer's use of the forms ("collectors"), student support and admissions modules can and in practice does place special category data within the meaning of GDPR Article 9 into the platform — in particular health data: medical conditions, medications, allergies and dietary requirements, together with emergency contacts and signed parental consent documents. The student support module holds counselling and pastoral case notes. This is stated explicitly rather than glossed, because it changes the analysis: it raises the Article 32 security bar, it makes a Data Protection Impact Assessment under Article 35 likely to be required of the Customer, and it means an incident affecting form attachments is materially more serious than one affecting, say, timetables. Firma Limited draws the Customer's attention to this and recommends the Customer complete a DPIA before placing health data in the platform.
5.3 Firma Limited does not require, and the schema does not contain, any date of birth, age or under-13 flag. See clause 15.
6.1 Firma Limited will process the Customer's personal data only on the Customer's documented instructions, including as to any transfer to a third country. The Main Agreement, this Agreement, and the Customer's own use and configuration of the platform together constitute those documented instructions.
6.2 Where Firma Limited is required by New Zealand law, or by the law of a country in which it or a subprocessor operates, to process the data otherwise, Firma Limited will inform the Customer of that requirement before processing, unless the law prohibits it from doing so on important grounds of public interest.
6.3 Firma Limited will inform the Customer if, in its opinion, an instruction infringes GDPR, the NZ Privacy Act 2020, or other applicable data protection law.
6.4 FERPA. The Customer designates Firma Limited as a school official with a legitimate educational interest in the Customer's education records, under 34 CFR § 99.31(a)(1)(i)(B). Firma Limited: (a) performs an institutional service the Customer would otherwise use its own employees to perform; (b) is under the direct control of the Customer with respect to the use and maintenance of education records; (c) uses education records only for the authorised purpose in clause 3; and (d) will not redisclose personal information from education records to any other party without the Customer's authorisation, except as required by law and after notifying the Customer where notification is lawful.
6.5 COPPA. Firma Limited relies on the Customer, acting as the parents' agent, to provide consent for the collection of personal information from children for school-directed educational purposes. Firma Limited's commitments in clause 3 — no advertising, no sale, no commercial profiling, no model training — are the consideration for that reliance, and are binding for as long as the Customer uses Taonova. Firma Limited will delete a child's personal information on the Customer's request in accordance with clause 12.
7.1 Firma Limited will ensure that every person it authorises to process the Customer's personal data — employee, director or contractor — is bound by a written obligation of confidentiality that survives the end of their engagement, or is under an appropriate statutory obligation of confidentiality.
7.2 Access is limited to those personnel who need it to perform clause 3, and production access is limited to the smallest number of people consistent with operating and supporting the service.
7.3 Disclosure to Firma Limited's own staff for support. Firma Limited will access Customer records only where necessary to investigate a fault or respond to a support request, and — except where immediate access is needed to prevent or contain an incident — will do so at the Customer's request or with the Customer's knowledge.
7.4 Firma Limited is a very small organization. The Customer should read clause 7.2 as a genuine statement about scale rather than as a description of a large access-management programme.
8.1 General authorisation. The Customer gives Firma Limited general written authorisation to engage subprocessors, subject to this clause.
8.2 Current list. The subprocessors and third-party recipients that may be involved are listed in the subprocessor list. That list is incorporated into this Agreement.
8.3 The structure the Customer must understand. Taonova is configured so that most third parties are enabled by the Customer, not by Firma Limited. An organization administrator must set a control flag and supply that provider's own API key before any data reaches an AI provider, a Student Information System, Pixabay, Microsoft or Google. Where the Customer supplies its own account and key — and for Microsoft and Google this includes the Customer's own tenant or Workspace and its own OAuth application, not one of Firma Limited's: (a) the Customer's own contract with that provider governs the relationship; (b) Firma Limited is not a party to it and cannot flow down the terms of this Agreement to that provider; and (c) the Customer is responsible for satisfying itself as to that provider's terms, security and transfer safeguards. Firma Limited provides the connector. The Customer provides the relationship. It would be misleading for Firma Limited to imply otherwise, and a DPO who is told otherwise will discover it.
8.4 Subprocessors Firma Limited engages. For subprocessors Firma Limited itself engages (the hosting provider, the outbound email relay, and Stripe for the hosted service), Firma Limited will impose data protection obligations no less protective than those in this Agreement, and remains fully liable to the Customer for their performance.
8.5 Notice of change. Firma Limited will give the Customer at least thirty (30) days' notice before adding or replacing a subprocessor it engages. The Customer may object on reasonable data protection grounds within that period; if the objection cannot be resolved, the Customer may terminate the affected service without penalty and receive a pro-rata refund of prepaid fees.
8.6 How that notice is actually given. By email, sent by hand, to the Customer's billing and administrative contacts. There is no in-product notification and no dedicated subprocessor-change contact field, and Firma Limited would rather say so than let "notice" imply machinery that does not exist. This is workable at the current number of Customers and will not scale; the commitment in 8.5 is unaffected either way, since a promise to give notice is a promise about the notice, not about how it is produced. A Customer who wants the notice to reach a specific mailbox — a DPO or a procurement address rather than whoever signed up — should say so, and Firma Limited will record it against the account.
9.1 Firma Limited will implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, having regard in particular to the presence of children's data and of the special category data described in clause 5.2.
9.2 Measures in place. Set out on the Security Practices page, which serves as the schedule of technical and organisational measures for this clause. In summary: transport encryption; credentials stored only as salted hashes; role- and organization-scoped access control enforced server-side on the publication and method layer; per-organization data isolation; server-side validation of method arguments; and no analytics, advertising, telemetry or session-recording component anywhere in the product.
9.3 Measures known to be missing. Firma Limited will not present clause 9.2 as complete when it is not. What remains: no database encryption at rest beyond what the hosting platform provides, and no documented key management — Firma Limited does not operate an application-level encryption layer over the database, and does not claim to; and no independent verification (clause 9.4). The Security Practices page (§10) keeps the current list, with what stands in each gap's place.
9.4 Testing. Firma Limited maintains an automated test suite covering the server method and publication layer, and an end-to-end browser suite, both run before release. There is no independent penetration test and no third-party security certification (no ISO 27001, no SOC 2). Firma Limited will say so plainly rather than gesture at "industry-standard security". See clause 15.
9.5 Monitoring. What would make Firma Limited aware that something had gone wrong is set out in clause 11.5, together with clause 11.6's statement of what that monitoring does not cover. It is stated there rather than here because the value of monitoring is entirely in the notification clock it starts.
9.6 Data Protection Officer. Firma Limited has not appointed a Data Protection Officer, and this is an assessed position rather than an omission. Article 37(1)(b) and (c) require one where core activities involve regular and systematic monitoring of data subjects on a large scale, or large-scale processing of special category data. Firma Limited processes children's health data (clause 5.2), which is special category — but "large scale" turns on the volume and geographic extent of the processing, not on sensitivity alone, and at its current number of Customers Firma Limited does not meet it. The position is reassessed when either of two things happens: the twenty-fifth Customer, or the first Customer established in the EU. Recording the trigger is the point: an assessment with no re-examination date becomes an omission by default. Data-protection enquiries reach a named human at the address in clause 16.5.
10.1 Data subject rights (Articles 12–23). Firma Limited will assist the Customer, by appropriate technical and organisational measures and insofar as possible, to respond to requests to exercise rights of access, rectification, erasure, restriction, portability and objection. Correction is satisfied by the Customer itself: staff with the appropriate permission edit records directly in the platform, which is faster than routing a request through Firma Limited.
10.4 Access, export, erasure and restriction are self-service. The Customer's own administrators can search for a data subject, preview everything held about them, export it as a file, erase, and record and lift an Article 18 restriction, from Organization settings → Data retention & privacy requests. Every one of those actions writes an audit row naming who ran it and when, including the ones that changed nothing. Where the Customer would rather Firma Limited carry out an operation, it will act on the Customer's written instruction within five (5) business days, so that the Customer can meet its own one-month deadline under Article 12(3). The Customer must read the Privacy Policy (§8) before relying on this clause. It states precisely what the export contains, what it deliberately slices rather than hands over whole, the one category it withholds and why, what erasure removes, anonymises, detaches and refuses, and that the Article 18 restriction is deliberately partial — it covers AI processing, export and outbound email, and does not reach ordinary application screens. Those limits qualify this clause.
10.2 Firma Limited will not respond directly to a data subject request relating to the Customer's data, other than to acknowledge it and refer the individual to the Customer, unless the Customer instructs otherwise or the law requires it.
10.3 Articles 32–36. Firma Limited will provide the Customer with reasonable assistance in relation to security of processing (Article 32), breach notification (Articles 33–34), data protection impact assessments (Article 35) and prior consultation with a supervisory authority (Article 36), taking into account the nature of the processing and the information available to Firma Limited.
11.1 Firma Limited will notify the Customer without undue delay and in any event within seventy-two (72) hours of becoming aware of a personal data breach affecting the Customer's personal data.
11.2 The notification will describe, to the extent known: the nature of the breach and the categories and approximate number of data subjects and records affected; the likely consequences; the measures taken or proposed; and a contact point. Where the information is not all available at once, it will be provided in phases without further undue delay.
11.3 Firma Limited will not delay notification in order to complete its investigation, and will not require the Customer to agree to confidentiality terms as a condition of being told.
11.4 New Zealand. Where a breach is a notifiable privacy breach under Part 6 of the Privacy Act 2020, Firma Limited will additionally assist the Customer with notification to the Office of the Privacy Commissioner and to affected individuals.
11.5 What makes Firma Limited "aware". The clock in 11.1 runs from awareness, so this clause states precisely what does and does not produce it. The application runs three automated detectors. Each writes a durable record and, where the record is an alert, emails the address in clause 16.5: (a) repeated failed sign-ins, counted both for a single account and — the case that matters more — for a single client address across many accounts, which is the shape a credential-stuffing attempt takes; (b) an unusual volume of data-subject operations — exports or erasures — within a short window for one Customer, which is what the misuse of the data-rights tooling looks like; and (c) a spike in unexpected server-side failures — ordinary refusals (a permission check declining a request) are deliberately not counted, only failures the application did not anticipate. The record is written before the notification is attempted, and a failure to send is itself recorded, so an unreachable mail relay produces a delayed alert rather than no alert. An administrator can read the log in the product and record that they have seen an entry; that acknowledgement is the moment of awareness this clause runs from.
11.6 What this monitoring is not, stated so that 11.5 is not read too widely. It is not intrusion detection and not a security information and event management system. It does not monitor the host, the network, the filesystem or the database directly, and it cannot detect a valid credential being used illegitimately — an attacker who signs in successfully with a stolen password triggers none of the three detectors above. Firma Limited holds no security certification (clause 9.4), and 11.5 should be read as the floor a small vendor can honestly commit to, not as an enterprise monitoring capability.
11.7 A note on the 72-hour figure. Seventy-two hours is the outer limit GDPR gives a controller; a processor's obligation is "without undue delay", and many processor DPAs commit to 24 or 48 hours. Seventy-two is chosen here deliberately, because it is a number Firma Limited can meet with the staffing it actually has. Committing to 24 hours and missing it is worse than committing to 72 and meeting it.
12.1 On termination or expiry of the Main Agreement, the Customer may within thirty (30) days request return of its personal data in a commonly used, machine-readable format. Firma Limited will provide it within a further thirty (30) days.
12.2 After that period, and in any event within ninety (90) days of termination, Firma Limited will delete the Customer's personal data from its production systems, unless required by law to retain it.
12.3 Backups. Data in encrypted backups is deleted on the ordinary backup rotation, and Firma Limited will confirm the maximum backup retention period in the order form. Restored backups remain subject to this Agreement until deleted.
12.4 During the term, deletion of an individual's data on the Customer's instruction is dealt with in the Privacy Policy (§8).
12.5 Firma Limited will certify deletion in writing on request.
12.6 Uploaded files: what is deleted, and the one case that is not. Deleting a record deletes the database row. The stored object is deleted by a housekeeping job that runs after a seven-day grace period and re-checks that nothing still references the file, so deletion is deferred rather than immediate — deliberately, because files are de-duplicated by content and a second record may point at the same object. Objects are queued for that job by: erasure and the scheduled retention purge, for every record they delete; account anonymisation, for profile and portfolio photographs; post and comment attachments; images embedded inline in a post's body; and ordinary day-to-day edits that replace or remove an image. The remaining case, stated plainly: attachments on records that erasure keeps are kept with them. Where clause 12 or the retention policy requires a record to be retained (an education record, a safeguarding record, the audit trail) or merely anonymised rather than deleted, any file attached to it survives with it. This is deliberate — a transcript or a safeguarding file with its evidence stripped out is not a record the school can rely on — but it means "delete the Customer's personal data" in clause 12.2 is subject to the same retention exceptions as everything else in this Agreement, for files as well as for database records. Firma Limited will not represent otherwise.
13.1 Firma Limited will make available to the Customer all information necessary to demonstrate compliance with Article 28, and will allow for and contribute to audits, including inspections, conducted by the Customer or an auditor it mandates.
13.2 In the first instance Firma Limited will respond to a reasonable written audit request — a security questionnaire, the processing description in clauses 3 to 5 of this Agreement, or the documents referenced here — within twenty (20) business days. An on-site or systems inspection may be requested once in any twelve-month period on thirty (30) days' notice, at the Customer's cost, subject to reasonable confidentiality and security conditions, and without access to other customers' data. Where a supervisory authority requires more, Firma Limited will comply.
13.3 Firma Limited holds no third-party audit certification. It will not substitute a certificate for an answer, because it has no certificate to substitute (clause 9.4).
14.1 Where the Customer runs Taonova on infrastructure it controls: (a) the Customer is both controller and, in substance, its own processor for the hosting, storage and backup of the data; (b) Firma Limited has no routine access to the Customer's personal data and processes it only if and when the Customer grants access for support; (c) clauses 9 (security of the hosting environment), 11 (breach detection and notification within the Customer's own estate) and 12 (deletion) are substantially the Customer's responsibility, not Firma Limited's; (d) the Customer is responsible for its own configuration choices, including which AI provider (if any) it enables, which object store and region it uses, and which email relay it configures.
14.2 Firma Limited remains responsible for the security of the software it supplies, and for notifying self-hosting customers of vulnerabilities it becomes aware of in that software.
14.3 This clause is included because a self-hosting Customer should not be sold, and should not accept, assurances about an environment Firma Limited does not operate.
This Agreement is drafted to be true. Where it describes a control that does not yet exist or is not yet verified, that is recorded in an internal gap register (available to any Customer on request) and stated here. The material ones for a Customer's DPO:
16.1 Order of precedence. In the event of a conflict between this Agreement and the Main Agreement in relation to data protection, this Agreement prevails.
16.2 Liability. Liability under this Agreement is subject to the limitations and exclusions in the Main Agreement, except to the extent applicable law does not permit that.
16.3 Governing law. New Zealand, and the courts of New Zealand have non-exclusive jurisdiction — without prejudice to the rights of a data subject or supervisory authority under GDPR Articles 79 and 77, which this clause does not and cannot restrict.
16.4 Standard Contractual Clauses. Where the Customer is established in the EEA or the United Kingdom and Firma Limited's provision of the hosted service involves a restricted transfer, the parties will enter into the European Commission's Standard Contractual Clauses (Decision 2021/914), Module Two (controller to processor), with the UK International Data Transfer Addendum where UK GDPR applies. Note that New Zealand holds an EU adequacy decision, which for a NZ-established processor is a materially better starting position than most non-EU vendors have.
16.5 Contact. 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. The contact point for data protection matters, including breach notification under clause 11 and requests under clause 10, is info@taonova.com, a monitored mailbox.
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