Data Processing Agreement
Document revision: 23 September 2026
This standalone DPA is available for separately agreed arrangements. Our School Subscription Agreement already includes data-protection terms and does not require a second DPA signature.
Australian sovereign inference is available on request. To enable it for your school, arrange an executed agreement or request supporting security evidence, contact letterbox@leibniz.com.au.
Between:
Leibniz Education Pty Ltd (ABN 18 692 154 162)
36 Bangalla St, Warrawee 2074, NSW, Australia
("Processor", "Leibniz", "we", "us")
and
_____________________________________________
("Controller", "School", "you")
Date: ___________________
1. Definitions
Personal Data means any information relating to an identified or identifiable individual, as defined under the Privacy Act 1988 (Cth).
School Data means all Personal Data provided by or on behalf of the School in connection with the School's use of the Platform, including student and teacher names, email addresses, and any data generated through use of the Platform.
Learning Data means question attempts, typed and handwritten answers, AI-generated grades and feedback, time spent, mastery estimates, and adaptive learning parameters generated through student use of the Platform.
Platform means the Leibniz adaptive mathematics learning platform, including the web application, server-side APIs, and associated services.
Sub-processor means any third party engaged by the Processor to process School Data on behalf of the Controller.
Data Breach means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, School Data.
Privacy Act means the Privacy Act 1988 (Cth), including the Australian Privacy Principles (APPs).
2. Scope and Purpose
2.1. The School is the Controller of School Data. Leibniz is the Processor and processes School Data solely on behalf of the School and in accordance with this Agreement.
2.2. Leibniz processes School Data for the following purposes only:
- Providing the adaptive mathematics learning platform to the School's students and teachers
- Authenticating users and enforcing role-based access control
- Administering School subscriptions, orders, renewals, invoicing and support using authorised purchasing and billing contacts
- AI-assisted grading of student answers (typed and handwritten)
- Generating teacher-facing analytics and progress reports
- Operating the adaptive learning system to personalise question difficulty
- Delivering transactional communications (e.g., authentication emails)
- Sending teachers factual communications about platform features, important workflow changes and service operation, using staff contact and school/pilot relationship details, subject to applicable School instructions and communication preferences. Teacher newsletters include an unsubscribe option; student records and Learning Data are not used to select recipients.
2.3. Leibniz will not process School Data for any purpose other than those specified in this Agreement, unless required by law.
3. Categories of Data Processed
| Category | Data Elements | Purpose |
|---|---|---|
| Account | Email, full name, school, year level, courses | Authentication, access control |
| Learning | Attempts, typed/handwritten answers, AI grades, time spent | Grading, progress tracking |
| Mastery | Concept understanding estimates (pseudonymised UUIDs) | Adaptive question selection |
| Match Mode | Match history, skill ratings, outcomes (pseudonymised UUIDs) | Competitive practice |
| Class | Class names, enrolments, assignments, class codes | Organising students, tasks |
| Usage | Daily question counts, AI token consumption | Rate limiting, monitoring |
| Teacher communications | Staff name/email, school/pilot relationship, permission evidence and unsubscribe status | Teacher service communications and delivery/suppression records |
| School subscription | Purchasing and billing contacts, accepted-order/terms records, licence counts, purchase-order references and invoice/payment status | Subscription administration, renewals, invoicing and support |
3.1. The core school service does not require student phone numbers, residential addresses or government identifiers. Uploaded work and free-text fields may nevertheless contain personal information supplied by a user. Hosting, security and product-analytics services process connection, device and usage metadata, including network addresses where required for delivery or abuse prevention. Leibniz minimises this information and does not use it for advertising.
3.2. Learning records are linked to internal user identifiers rather than using names or email addresses as their keys. These records remain personal information where Leibniz can associate them with an account; pseudonymisation does not make them anonymous.
4. Data Subjects
The categories of data subjects whose Personal Data is processed under this Agreement are:
- Students enrolled in the School's classes on the Platform (minimum age 13)
- Teachers and school administrators using the Platform
- School purchasing and billing contacts
4.1. The Platform is designed for students aged 13 and above. For school subscriptions and pilots, the School must provide required notices and obtain student or parent/guardian permissions where required by law. Purchasing access does not itself establish individual consent or remove Leibniz's privacy obligations. Individual users under 18 require parental or guardian consent.
5. Duration of Processing
5.1. Leibniz will process School Data for the duration of the School's use of the Platform.
5.2. Upon termination of the School's use of the Platform, Leibniz will delete or return School Data in accordance with Section 12 of this Agreement.
6. Obligations of the Processor
Leibniz undertakes to:
6.1. Process School Data only on documented instructions from the School, including with respect to transfers of Personal Data outside Australia, unless required to do so by law. In such a case, Leibniz will inform the School of that legal requirement before processing, unless prohibited from doing so by law.
6.2. Ensure that persons authorised to process School Data have committed themselves to confidentiality.
6.3. Take all measures required pursuant to Section 9 (Security Measures) of this Agreement.
6.4. Not engage another processor (Sub-processor) without prior written authorisation of the School, subject to the pre-approved Sub-processors listed in Section 8.
6.5. Assist the School, taking into account the nature of processing, by appropriate technical and organisational measures, in fulfilling the School's obligations to respond to requests from individuals exercising their rights under the Privacy Act.
6.6. Assist the School in ensuring compliance with obligations related to security of processing, notification of Data Breaches, and data protection impact assessments.
6.7. At the choice of the School, delete or return all School Data to the School after the end of the provision of services, and delete existing copies unless retention is required by law.
6.8. Make available to the School, upon reasonable request, information reasonably necessary to demonstrate compliance with the obligations laid down in this Agreement, and allow for and contribute to audits conducted by the School or another auditor mandated by the School, subject to the terms of Section 11.
6.9. Not use School Data for marketing, advertising, unrelated commercial profiling or any secondary commercial purpose. Teacher service communications, educational personalisation and progress reporting are limited to the purposes in Section 2; this Agreement does not authorise promotional offers or sales campaigns.
6.10. Not sell or disclose School Data to any third party except as specified in this Agreement.
6.11. Not use School Data to train AI models. AI providers engaged by Leibniz are contractually prohibited from using API data for model training.
7. Obligations of the Controller
The School undertakes to:
7.1. Ensure that it has a lawful basis for providing School Data to Leibniz for processing.
7.2. Provide clear instructions to Leibniz regarding the processing of School Data.
7.3. Notify Leibniz promptly of any changes to the School's data processing requirements.
7.4. Ensure that all required consents and authorisations have been obtained from students, parents, or guardians as appropriate under applicable law and the School's own policies.
8. Sub-processors
8.1. The School hereby authorises the following Sub-processors for the relevant features supplied under this Agreement:
| Sub-processor | Purpose and data processed | Region and retention |
|---|---|---|
| Supabase | Purpose. Primary database, authentication and uploaded-work storage Data processed. Account, school, class, learning and submission records | Region. Sydney, Australia for the primary project Retention. Active-service lifecycle; seven rolling daily database backups |
| Vercel | Purpose. Web hosting, server-side API execution, content delivery, website usage and performance analytics Data processed. Request content needed to execute features, page/device and connection metadata, performance measurements and operational logs | Region. Sydney production functions; global delivery/security edge and analytics processing Retention. Runtime logs: 30 days under Vercel Observability Plus; analytics provider lifecycle |
| SCX | Purpose. Optional Australian sovereign inference, enabled by Leibniz at the School's request Data processed. Minimum question, marking and response context; text and uploaded work needed for covered grading, OCR, annotation and mapping features | Region. Australia Retention. Zero data retention |
| OpenRouter and eligible downstream inference providers | Purpose. Global-path inference, summaries and content generation Data processed. Feature-specific question, curriculum, marking, response and selected learning context; uploaded work where needed | Region. United States gateway; eligible downstream endpoints may process outside Australia Retention. ZDR-eligible endpoints required; provider data collection denied |
| Google / Microsoft / Apple | Purpose. User-selected sign-in services Data processed. Identity attributes required for sign-in | Region. Global Retention. Provider account lifecycle |
| Amazon Web Services (AWS), planned | Purpose. Replacement infrastructure and SES email Data processed. Data necessary for activated workloads; email recipient, message and delivery metadata | Region. Sydney services; onward email delivery may be overseas Retention. Applicable service retention and deletion requirements; configuration confirmed before activation |
| Mailgun | Purpose. Transactional email and teacher service communications Data processed. Recipient address, message content and delivery metadata | Region. United States and global email delivery Retention. Provider delivery/log lifecycle |
| Stripe | Purpose. Web payment for individual subscriptions Data processed. Customer, payment and subscription metadata | Region. Global Retention. Contractual/statutory retention |
| Apple / Google Play | Purpose. Mobile purchases for individual subscriptions Data processed. Purchase receipts and transaction/subscription metadata | Region. Global Retention. Provider platform and statutory retention |
AI providers are contractually prohibited from using API data for model training. Individual payment processing does not receive student learning content. Customer-selected school or learning-management integrations are documented during onboarding, including the authorised records exchanged. A model's name does not identify the entity or location hosting that model.
8.2. AWS infrastructure and SES email are planned replacements, not a statement of completed cutover. Mailgun remains the email provider until cutover is confirmed. Activation of planned processing is subject to the notice and objection rights in Section 8.3. School Data is processed only by the services needed to deliver the authorised feature and its supporting hosting, storage and security functions. Australian sovereign inference is available on request as described in Section 13.2. Once enabled, requests covered by that setting use SCX and do not fall back to OpenRouter or another global inference provider.
8.3. Leibniz will give the School at least seven calendar days' advance written notice before any intended change that would relocate or expand into another country:
- cloud infrastructure or a data-hosting environment used to process School Data; or
- Leibniz staff, contractors or other personnel authorised to access unencrypted School Data.
The notice will identify the new country, the affected service or personnel access, and the planned effective date. Changes involving the addition or replacement of a Sub-processor will also give the School an opportunity to object. If the School objects on reasonable grounds, Leibniz will either not make the proposed change or the School may terminate this Agreement. Urgent security remediation that does not change a processing or personnel-access country may proceed without this notice.
8.4. Leibniz will impose data protection obligations on each Sub-processor no less protective than those set out in this Agreement.
9. Security Measures
Leibniz implements the following technical and organisational security measures:
9.1. Encryption
| Layer | Method |
|---|---|
| In transit | TLS 1.2+ on all connections |
| At rest | AES-256 (managed by database provider) |
| Auth tokens | Signed JWTs, server-side validation |
| Cookies | HTTP-only, Secure, SameSite |
9.2. Access Control
- All sensitive data access is mediated by authenticated, server-side API routes. Where limited client-side database access exists (e.g., user profile reads), Row-Level Security policies restrict queries to the authenticated user's own data.
- Role-based access control enforces student, teacher, and school admin boundaries.
- Student access is limited to their own records and the shared information authorised for the relevant feature. Teacher access to student records is restricted by class, enrolment and the applicable permissions.
- Students can only join classes belonging to their own school. Cross-school access is blocked.
- Row-Level Security (RLS) at the database layer provides defence-in-depth.
- Teacher access is granted only to approved, school-provided email addresses. Users cannot self-select or elevate their role.
9.3. Vendor Access Controls
- Production infrastructure access is restricted to a minimal number of authorised personnel on a need-to-know basis.
- The privileged-access policy requires multi-factor authentication (MFA) for infrastructure accounts.
- Database credentials and API keys are rotated periodically in accordance with Leibniz's internal security policies.
- Administrative activity is recorded through the applicable application and provider audit trails. Access to these records is restricted.
9.4. Pseudonymisation
- Internal identifiers link learning records to the authorised account. Identifiable account records are protected separately through access controls; linked learning records remain subject to this Agreement.
- AI requests omit direct account identifiers where they are unnecessary for the feature. The teacher-summary request uses a generic student label and selected concept-mastery information. Personal information may still be present in uploaded work or free text.
9.5. Data Minimisation
- AI request content is limited to the selected educational task. Depending on the feature, this includes the question, response or uploaded work, marking criteria, expected solution, curriculum context, relevant hints, grading feedback or selected mastery information.
- The production OpenRouter workspace applies sensitive-information detection and prompt-injection redaction before forwarding matched request content to a downstream model provider. This filtering takes place within OpenRouter; it is not a claim that OpenRouter never receives the original request. Detection reduces exposure but does not guarantee removal of every identifier or information embedded in images and PDFs.
- SCX is a separate Australian inference path with zero data retention. OpenRouter-specific filtering is not represented as an SCX control.
- PostHog collection is disabled. Vercel provides website usage and performance analytics without advertising cookies; the processing remains subject to the purpose, minimisation and deletion obligations in this Agreement, separately from inference-provider zero data retention.
- Class codes are random alphanumeric strings with no identifying information.
9.6. AI Request and Output Controls
- Direct OCR, grading and answer-validation endpoints require a verified user or a short-lived signed demo credential. Demo credentials do not grant access to stored school or student records. The public submission workflow may issue a demo credential for a guest request; a demo credential does not establish the School's identity or activate its sovereign-inference setting.
- Application controls include feature-specific request limits, server-controlled prompts, authorised context lookups and structured-response validation. Supported question fields are filtered for specified instruction-override patterns.
- OpenRouter grading retries retain mandatory ZDR and denial of provider data collection. Controlled multimodal grading retries exclude Flex capacity. An unavailable eligible endpoint does not authorise a non-ZDR retry.
- On the main grading response path, a deterministic filter removes specified irrelevant personal or protected-characteristic commentary from reasoning and feedback points while preserving awarded marks. This is a bounded output control, not a guarantee that every generated field is free of personal information.
- AI-assisted results remain reviewable and correctable. The School may request human review through its normal support channel; AI output must not be the sole unreviewable basis for a material adverse student decision.
9.7. Security Assurance and Operational Handling
- The web application uses a per-request script nonce and Content Security Policy, including nonce handling for supported learning-management-system responses. Public question generation uses server-issued guest sessions and atomic quotas with a separate network abuse ceiling.
- The independent penetration test dated 29 August 2026 reported no Critical or High findings and two Medium findings. Leibniz's remediation record documents both Medium findings as remediated and deployed. The original report, scope limitations and remediation evidence are available on request; this does not represent a new independent retest or certification.
- Routine development, testing and AI evaluation do not use production student submissions. School-authorised onboarding and necessary support or incident access are limited to an identified purpose, authorised personnel, minimum required data and controlled retention. Approved company-owned, non-personal educational catalogue content may be used with fictional test accounts in non-production environments.
10. Data Breach Notification
10.1. If Leibniz becomes aware of a Data Breach affecting School Data, Leibniz will promptly assess whether the breach is likely to result in serious harm to any affected individual, in accordance with the Notifiable Data Breaches (NDB) scheme under Part IIIC of the Privacy Act. This assessment will be completed as quickly as practicable, and in any event within 30 days.
10.2. Leibniz will notify the School without undue delay, and within 24 hours of becoming aware of a Data Breach affecting School Data, including while its impact is being assessed. This contractual deadline is separate from statutory notification requirements.
10.3. The notification will include, to the extent available:
- A description of the nature of the Data Breach, including the categories and approximate number of data subjects and records concerned
- The name and contact details of the point of contact from whom more information can be obtained
- A description of the likely consequences of the Data Breach
- A description of the measures taken or proposed to be taken to address the Data Breach, including measures to mitigate its possible adverse effects
- Recommendations about the steps affected individuals should take in response to the Data Breach
10.4. Leibniz maintains a documented incident response process covering detection, containment, notification and remediation.
10.5. Where the Data Breach constitutes an eligible data breach under the NDB scheme, Leibniz will cooperate with the School in:
- Preparing and submitting a notification to the Office of the Australian Information Commissioner (OAIC) via the Notifiable Data Breach statement
- Notifying affected individuals, including providing recommendations about steps they should take in response to the breach
11. Audit Rights
11.1. Leibniz will make available to the School, on reasonable request, all information necessary to demonstrate compliance with this Agreement.
11.2. The School may, with reasonable prior notice (not less than 14 days) and during normal business hours, conduct or commission an audit of Leibniz's processing activities to verify compliance with this Agreement. Audits will be limited to once per 12-month period unless a Data Breach has occurred.
11.3. Leibniz will cooperate with such audits and provide reasonable assistance, including access to relevant documentation and summary reports. The School shall bear its own costs of any audit. Audit access shall be limited to compliance-related documentation; direct access to production systems is not included.
11.4. The School may also request Leibniz to provide a written summary of the security measures in place, the results of any internal security assessments, and evidence of Sub-processor compliance. Supporting material is identified by document title, date and evidence reference in the Security Assurance Evidence Index. Copies are supplied on request subject to confidentiality and protection of third-party information; access to the source-code repository is not required.
12. Data Return and Deletion
12.1. Upon termination of the School's use of the Platform, or upon written request at any time during the term, Leibniz will:
- Return or delete School Data without undue delay, as instructed by the School. Account deletion removes or detaches the associated relational records and authentication identity transactionally. School termination includes an inventory of the relevant accounts, tenancy and downstream services; it is not treated as complete merely because one school record has been removed.
- Uploaded-work deletion is attempted immediately and retained in a durable retry queue until the relevant storage locations have been verified empty. Pending cleanup is reported as pending. Applicable downstream deletion or a documented retention exception is included in the completion record.
- Encrypted database backups expire through the seven-day rolling backup lifecycle. Outstanding deletion requests must be reapplied to a restored copy before it returns to service.
- Runtime logs are retained for 30 days under Vercel Observability Plus and then expire through the provider retention lifecycle. Logging is subject to minimisation requirements and is separate from inference-provider zero data retention.
- Operational records follow the Data Retention and Secure Deletion Schedule: AI operational events for 90 days, resolved or accepted AI alerts for 365 days, and completed storage-deletion receipts for 90 days with raw user identifiers removed on completion.
- Temporary operational files are deleted after verified onboarding import and within seven days. Support exports are retained for 24 hours by default, with a documented exception permitting up to seven days.
12.2. Individual accounts can be deleted through the authenticated self-service workflow, subject to resolving active individual subscriptions. Shared school records may be retained with the deleted account's association removed where needed to preserve other users' records. Storage and downstream cleanup remain subject to the verified completion process in Section 12.1.
12.3. Leibniz may retain only:
- Irreversibly anonymised or aggregated statistics that contain no identifiable information about any individual (e.g., "X% of students answered this question correctly")
- Data required to be retained by applicable law
12.4. Leibniz will provide written confirmation of deletion upon request.
13. Cross-Border Data Transfers
13.1. The primary application database and uploaded-work storage are located in Sydney, Australia. This primary-storage location is distinct from the processing and retention performed by hosting, delivery, inference and other Sub-processors in Section 8.
13.2. Australian sovereign inference is available on request. The School may request this option by contacting Leibniz at letterbox@leibniz.com.au. Leibniz will enable it for the School and confirm activation and the covered features. For covered requests, SCX processes the necessary inference content in Australia with zero data retention. Covered requests do not fall back to a global inference provider when SCX is unavailable.
The available coverage includes the school-routed submission-grading, OCR, annotation, structural-mapping and supported idea-grading workflows. The setting applies to requests associated with the School through the authenticated service. It does not automatically relocate every Platform feature or identify signed-out public-demo use as belonging to the School.
The default global inference path uses OpenRouter's United States-operated gateway and eligible downstream endpoints, which may process content outside Australia. Separate global features, including teacher summaries, content generation and compatibility validation, remain subject to the disclosed processing arrangements unless Leibniz confirms their inclusion in the School's Australian configuration. Leibniz will confirm the applicable feature coverage when enabling the option. Request minimisation and filtering are described in Sections 9.4-9.6.
13.3. User-selected sign-in flows may involve communication with Google, Microsoft or Apple servers located outside Australia, limited to the sign-in process.
13.4. Planned AWS infrastructure and SES email use Sydney services, subject to Section 8.2; onward email delivery may involve overseas recipient systems. Until email cutover, transactional emails and teacher service communications are processed by Mailgun through United States and global delivery infrastructure. Processing includes the recipient address, message content and delivery metadata.
13.5. Payment processing for individual web subscribers (not school-provisioned accounts) is handled by Stripe (global). Email and payment details are disclosed.
13.6. In-app purchases for individual mobile subscribers (not school-provisioned accounts) are handled by Apple or Google Play (global). Relevant account identifiers, receipts and transaction/subscription metadata are disclosed.
13.7. These cross-border disclosures are made in compliance with APP 8 (Cross-border disclosure) of the Privacy Act.
14. Adaptive Learning and Anonymised Data
14.1. Leibniz uses an adaptive learning system to personalise question difficulty. Its learner models use internal user identifiers and mathematical parameters representing estimated mastery per concept. The associated attempts, grades and other learning records are retained for the service as described in Sections 3 and 12. Identifiable or linkable learner records are not treated as anonymous.
14.2. Leibniz does not use School Data or Learning Data to train or tune models, including when anonymised or aggregated. Processing needed to provide personalised practice, grading and authorised school reporting remains permitted under this Agreement.
15. Liability and Indemnity
15.1. Each party's total aggregate liability under this Agreement shall not exceed the greater of (a) the total fees paid by the School to Leibniz in the 12 months preceding the event giving rise to the claim, or (b) AUD $10,000.
15.2. Neither party shall be liable to the other for any indirect, incidental, special, consequential, or punitive damages, including loss of revenue, loss of data (except to the extent caused by a breach of this Agreement), or reputational harm, regardless of whether such damages were foreseeable.
15.3. Each party will indemnify the other against direct losses, damages, or costs arising from the indemnifying party's breach of this Agreement or failure to comply with its obligations under the Privacy Act in relation to the processing of School Data, subject to the liability cap in Section 15.1.
15.4. Nothing in this Agreement excludes or limits liability that cannot be excluded or limited under applicable law, including liability for fraud or wilful misconduct.
16. Term and Termination
16.1. This Agreement commences on the date first written above and continues for the duration of the School's use of the Platform.
16.2. This Agreement will automatically terminate upon the termination or expiry of the School's use of the Platform.
16.3. Sections 10 (Data Breach Notification), 12 (Data Return and Deletion), 15 (Liability and Indemnity), 17.3 (Confidentiality), and this Section 16 will survive termination of this Agreement.
17. General
17.1. This Agreement is governed by the laws of New South Wales, Australia. The parties submit to the exclusive jurisdiction of the courts of New South Wales.
17.2. Neither party shall be liable for any failure or delay in performance due to causes beyond its reasonable control, including but not limited to acts of God, government actions, natural disasters, pandemics, internet or telecommunications failures, or third-party service provider outages.
17.3. Each party agrees to keep confidential any information obtained through audits, security documentation, or the performance of this Agreement that is not otherwise publicly available. This obligation survives termination of this Agreement.
17.4. This Agreement may be amended only by written agreement signed by both parties.
17.5. If any provision of this Agreement is found to be invalid or unenforceable, the remaining provisions will continue in full force and effect.
17.6. This Agreement constitutes the entire agreement between the parties with respect to the processing of School Data and supersedes all prior agreements, representations, and understandings relating to such processing.
18. Contact
For questions regarding this Agreement, data processing, or to exercise any rights under this Agreement:
Leibniz Education Pty Ltd
ABN 18 692 154 162
36 Bangalla St, Warrawee 2074, NSW
letterbox@leibniz.com.au
Signatures
Leibniz Education Pty Ltd
Name: ___________________________
Title: ___________________________
Signature: ___________________________
Date: ___________________________
School
School Name: ___________________________
Name: ___________________________
Title: ___________________________
Signature: ___________________________
Date: ___________________________