Children’s Privacy Policy
1. About this policy
1.1 Why this policy exists
Classe365 is a student information system, learning management system and CRM used by education institutions. When a school uses Classe365 for pupils in primary or middle years, the platform holds records about children under 13. Those records are protected by the United States Children’s Online Privacy Protection Act (COPPA) and the Children’s Online Privacy Protection Rule made under it, and by children’s privacy provisions in other jurisdictions.
The Federal Trade Commission amended the COPPA Rule in 2025. The Final Amendments were published at 90 FR 16918 on 22 April 2025, took effect on 23 June 2025, and carry a full compliance date of 22 April 2026. The amendments changed the definition of personal information, required that consent to non-integral third-party disclosure be given separately from consent to collection and use, required operators to maintain and publish a written data retention policy with deletion timeframes, and required a written children’s information security program. This policy is written to meet those amended requirements in the school setting, where the institution authorises collection and use on behalf of parents for its educational purpose. It replaces our previous children’s privacy policy in full.
1.2 Which platform this covers
Classe365 — covered by this policy in full. Institutions use it for learners of all ages, including children under 13.
Hiree365 — our campus recruitment and employability platform. Hiree365 has a minimum age of 16. It is not available to anyone under 16 and it has no users under 13. Section 16 sets out our position. Candidate privacy is described in the Hiree365 Candidate Privacy Notice.
1.3 Which entity contracts
We use a regional contracting model.
Customers located in the United States contract with 365 Software, LLC, a Delaware limited liability company, registered office 131 Continental Dr, Suite 305, Newark, DE 19713, New Castle County, United States; registered agent Legalinc Corporate Services Inc. Governing law: the State of Delaware. Courts of the State of Delaware.
All other customers, including those in the European Union, the United Kingdom, Australia and the rest of the world, contract with Sprout On Web Pty Ltd, ABN 72 138 602 418, registered office 22 Palm Street, St Ives, NSW 2075, Australia; business address 22 Giffnock Avenue, Macquarie Park, NSW 2113, Australia. Governing law: New South Wales, Australia. Courts of New South Wales.
Support and engineering are provided 24/7 by Classe365 group staff in Australia, India, the Philippines, Spain and the United States. Section 12 explains what that means for children’s data, and parents should read it.
In this policy, “Classe365”, “we”, “us” and “our” mean the contracting entity for the child’s institution together with the other Classe365 group companies whose staff support it.
1.4 How this policy fits with our other documents
This policy should be read with our Privacy Policy, which is the master document describing all of our processing, our two roles as processor and controller, our sub-processors, our hosting arrangements and our security controls. Where the Privacy Policy summarises children’s data, this policy governs. Where this policy summarises a topic covered in more detail in the Privacy Policy — for example the full list of sub-processors, which is kept in our Sub-processor List, or international transfer mechanisms — that more detailed document governs.
The Personal Data Processing Agreement governs our processing on behalf of an institution and sets out the transfer mechanisms we rely on. The AI Use and Transparency Statement describes our AI features. The FERPA Compliance Statement describes our position on education records under United States federal education law.
2. Who this policy applies to
This policy applies to:
Children under 13 whose records are held in Classe365 by an institution — including personal details, enrolment records, attendance, assessment and grading records, learning activity, communications and any additional field the institution has configured.
Parents and guardians of those children, whether or not the institution has issued them a parent portal account.
Institutions — schools, districts, academies and corporate training customers — that decide to place children’s records in the platform and that direct what is collected.
It does not apply to institution staff, to learners aged 13 and over, or to visitors to our marketing website. Those are covered by the Privacy Policy.
We do not offer Classe365 directly to children or to families. A child can only have a Classe365 account because an institution created one. We have no consumer sign-up route for a child, no direct-to-child marketing, and no way for a child to open an account without an institution.
3. Our role, and the institution’s role
3.1 The institution decides; we carry out
Children’s information reaches the platform because an institution decides to put it there. The institution chooses which fields to collect, designs its own admission and enrolment forms, decides which modules and features to switch on, decides which staff can see what, and decides how long to keep a record before deleting it.
Under data protection law outside the United States, the institution is the controller and we are the processor. Under United States privacy law we are a service provider to the institution. Under the Family Educational Rights and Privacy Act we act as a school official with a legitimate educational interest, under the direct control of the institution.
Under COPPA, we are the operator of the online service that collects children’s information. The institution directs that collection for a school-authorised education purpose, and we collect and handle children’s information solely on the institution’s instructions. We do not decide what is collected about a child, we do not collect anything about a child for our own purposes, and we do not use a child’s information for anything other than providing the service to the institution.
3.2 How authorisation works in the educational context
COPPA requires verifiable parental consent before a child’s personal information is collected. In the school setting, the Federal Trade Commission’s guidance recognises that a school may consent on behalf of parents where the collection is for a school-authorised education purpose and the information is not used for any commercial purpose unrelated to that education purpose. The 2025 amendments did not add this to the Rule itself and did not change that guidance.
Classe365 relies on school authorisation. That is the single basis on which children’s information is collected in Classe365:
The institution decides that the platform is needed for its school-authorised education purpose — running enrolment, teaching, assessment, attendance, reporting and communication with families.
The institution authorises us, on behalf of parents, to collect and use children’s information for that purpose. It gives that authorisation at institution level when it accepts our Terms and Conditions, and it gives a separate authorisation if and when it activates the AI add-on. Section 8 describes both.
Our use of children’s information stays limited to the institution’s educational purpose. It is never used for any commercial purpose unrelated to that purpose.
The institution is responsible for giving parents notice of what is collected and how it is used, and for obtaining any consent its own law, or its own policy, requires in addition to its authorisation.
We support the institution by publishing this policy and the Notice to Parents, which we provide to the institution to pass to parents, and by keeping a record of the institution’s authorisation.
We never treat a child’s use of the platform as consent, and we never ask a child to consent on a parent’s behalf.
We do not operate a consent process of our own with parents. Parents exercise their rights through the institution, as section 14 describes, and we act on the institution’s instruction.
3.3 What the institution must do
An institution that places children’s records in Classe365 is responsible for:
satisfying itself that it has authority under the law that applies to it, including the Federal Trade Commission’s school-authorisation guidance and, where applicable, the GDPR, to authorise the collection and use of children’s information for its educational purpose;
making the Notice to Parents we provide, or an equivalent notice, available to parents before their child’s information is collected;
obtaining any consent its own law requires in addition to its authorisation;
deciding whether to activate the AI add-on, and giving the separate authorisation described in section 8.4 before doing so;
responding to parents who ask to review, correct or delete a child’s record, or to stop further collection, and instructing us where our help is needed;
deleting records it no longer needs, which starts our deletion timeline in section 10.
The institution gives us warranties to this effect in our Terms and Conditions.
4. The categories of children’s personal information we hold
The amended COPPA Rule defines personal information broadly. We set out below every category we hold about a child, mapped to that definition. What is actually present for a particular child depends on what the institution has chosen to collect and which modules it uses; nothing in this list is collected by us on our own initiative.
4.1 Identifiers and contact information
First and last name.
Home or other physical address, including street name and city or town.
Email address, where the institution issues or records one.
Telephone number, where the institution records one.
The institution’s own student or learner reference number.
Username and hashed password for the child’s platform account.
Screen or user name where it functions as online contact information.
4.2 Persistent identifiers
Account identifiers, session identifiers, authentication tokens and single sign-on identifiers.
IP address, device and browser information, and cookie or similar identifiers used to keep the child signed in and to keep the account secure.
Persistent identifiers held for a child are used only to support the internal operation of the platform and to keep the account secure. They are never used to build an advertising profile, to serve targeted advertising, or to track a child across other websites or services.
4.3 Photographs, video and audio
A photograph of the child, where the institution uploads one to the student record.
Files a child uploads as coursework, which may include images or video the child has created.
We do not ourselves collect audio recordings of children’s voices. The platform has no voice-capture feature for children, and we hold no voiceprints. If a child uploads coursework that contains a recording of their voice, such as a video assignment, that file is personal information. It is held only as part of the child’s coursework, is used only for the education purpose for which it was submitted, is never used for voice recognition, and is deleted with the record under section 10.
4.4 Biometric identifiers
The amended Rule includes biometric identifiers that can be used for automated or semi-automated recognition within the definition of personal information. Our position is stated in full and without qualification beyond the one that follows:
Classe365 and Hiree365 do not themselves collect, store or process biometric identifiers — including fingerprints, handprints, retina or iris patterns, genetic data, voiceprints, gait patterns, facial templates or faceprints — and do not perform facial or voice recognition.
Institutions may choose to enable SMOWL, a third-party online quiz proctoring service, which they contract with directly. Any biometric processing by SMOWL occurs under SMOWL’s own terms and privacy policy, not ours.
SMOWL is not a sub-processor of ours. It is a service an institution procures for itself and switches on. If your child’s institution has enabled SMOWL for proctored assessments, ask the institution for SMOWL’s privacy notice and for the basis on which it processes your child’s information; we will point you to the right contact at the institution if you ask us.
4.5 Government-issued identifiers
We do not require any government-issued identifier — such as a national identity number, social security number, tax number, passport number or driving licence number — to provide the platform.
Where an institution configures its own admission or enrolment forms to collect one, that identifier is treated as personal information and is held under the retention schedule in section 10. It is subject to the same encryption, access control and logging as the rest of the child’s record. The institution decides whether to collect it. We do not ask for it, and we never use it for any purpose of our own.
If your child has been asked for a government-issued identifier on a form inside the platform, that requirement comes from the institution, and questions about why it is being collected should go to the institution.
4.6 Education and pastoral records
Programme, course and class enrolment, timetable and attendance.
Assessment submissions, grades, transcripts, progression and completion records, certificates and awards.
Learning activity: material accessed, submissions, discussion posts, quiz and assignment activity, and engagement data generated by use of the learning management system.
Pastoral and administrative records the institution chooses to keep, which may include behaviour and discipline notes, welfare notes, accommodation or accessibility arrangements, and health or dietary information where the institution records it.
Communications between the institution, the child and the family through the platform.
4.7 Financial records
Fees invoiced and paid, scholarships, concessions and payment plans recorded against the child’s record. The payer is usually a parent or guardian, and payment card and bank details are handled by our payment processors and are not stored by us.
4.8 Information the institution adds
Institutions frequently add fields of their own to admission, enrolment and student forms. Anything an institution adds is covered by this policy, held under the same controls, and deleted on the same schedule.
5. Why children’s information is collected and used
Children’s information is used only to provide the platform to the institution, on the institution’s instructions. Specifically:
Creating and maintaining the child’s student record.
Running admissions, enrolment, timetabling and class allocation.
Recording and reporting attendance.
Delivering learning content and managing coursework, submissions, assessment and grading.
Recording progression, completion, certificates and awards.
Managing fees, invoicing and payment records held against the child.
Enabling communication between the institution, its staff, the child and the family.
Producing reports and analytics for the institution about its own cohort.
Providing AI-assisted features the institution has enabled, within the limits in section 11.
Providing technical support to the institution, diagnosing faults and restoring data.
Keeping records of changes so the institution can see who changed what, and keeping the platform secure.
We support the internal operations of the platform — authentication, security, fault diagnosis, backup and restoration — using the minimum information needed for those purposes.
We do not use children’s information for any commercial purpose unrelated to the education purpose for which the institution collected it.
6. Support of internal operations, and what that does not include
COPPA permits an operator to use persistent identifiers for the support of internal operations. We rely on that only for what the term genuinely covers: maintaining or analysing the functioning of the platform, performing network communications, authenticating users, maintaining user-driven preferences, protecting the security and integrity of the service, and complying with law.
It does not, for us, include:
contextual or behavioural advertising of any kind;
amending a child’s profile for advertising or commercial purposes;
audience measurement across other services;
profiling a child for any purpose beyond the education purpose the institution has set.
We keep these identifiers inside the authenticated platform, do not share them with any advertising or analytics provider, and limit access to them to the staff who need them for the purposes listed above.
7. Who receives children’s information, and why
We use a small number of sub-processors to run the platform. Each is bound by a written contract that restricts its use of the information to providing its service to us and requires it to keep the information confidential and secure. Each is assessed before engagement, reviewed afterwards, and included in the due diligence described in section 13.4. The AI model providers are used only where an institution has activated the AI add-on and given the separate authorisation described in section 8.4.
7.1 Recipients of children’s personal information
| Recipient | What it is | Purpose for which it receives children’s data | Location | How the disclosure is authorised |
|---|---|---|---|---|
| Amazon Web Services | Cloud hosting and storage provider | Hosting and storing the platform and its databases, including the child’s record; running daily backups | AWS region allocated to the customer’s account, generally the nearest to the customer | Authorised by the institution as part of the service — integral; the service cannot run without it |
| Intercom | Customer support messaging platform | Handling support conversations, where a support conversation includes information about a child | United States | Authorised by the institution as part of the service — needed to support the service |
| Atlassian | Engineering issue tracking platform | Recording and diagnosing faults, where a fault report includes information about a child | United States / Australia | Authorised by the institution as part of the service — needed to operate and support the service |
| Stripe | Payment processor | Processing fee payments made against a child’s record | United States | Authorised by the institution as part of the service — needed to bill for and collect fees through the service |
| PayPal | Payment processor | Processing fee payments made against a child’s record | United States | Authorised by the institution as part of the service — needed to bill for and collect fees through the service |
| AI model providers (AI add-on only): OpenAI, Anthropic and Google | Providers of general-purpose AI models, accessed through their business API services under terms that do not permit them to use our customers’ data to train their models | Running agent automation, workflow and other features that use general-purpose AI models, where the institution has activated the AI add-on | United States | Authorised by the institution at AI add-on activation — no children’s data reaches these providers unless the institution has activated the add-on and given that authorisation |
| Classe365 group support team | Group employees providing 24/7 support and engineering | Providing support and engineering, which can require remote access to records including children’s records | Australia, India, the Philippines, Spain, United States | Not a disclosure to a third party; see section 12 |
| The child’s institution | The school, district, academy or training provider | Educating and administering the child; the institution controls the record | The institution’s own location | Not a third-party disclosure; the institution is the customer and controller |
7.2 Providers that never receive children’s information
Google Analytics, Semrush, Mailchimp and ActiveCampaign operate on the classe365.com marketing website only. They never receive student or candidate records from the platform, and they never receive information about a child.
We state this plainly because it is one of the questions school administrators and security teams ask us most often. These four tools sit on our public marketing website and support our own business marketing. They have no connection to the authenticated platform, no access to institution tenants, and no route by which a child’s record could reach them.
7.3 Optional services an institution enables and contracts for itself
SMOWL — online quiz proctoring. The institution chooses to enable it and contracts with SMOWL directly under SMOWL’s own terms. Any biometric processing occurs under SMOWL’s terms, not ours.
Zapier — customer-configured automation. The customer controls what data flows to it and is responsible for that flow.
These are not our sub-processors. When an institution turns one on, the institution takes responsibility for that provider’s handling of the data it receives, and for telling parents about it.
7.4 Legal disclosures
We may disclose information where we are legally required to — for example in response to a valid court order, warrant or regulatory demand. Where we act as processor and the law permits, we will notify the institution before disclosing its data so that it can respond, and we will disclose no more than we are legally obliged to disclose.
8. How disclosure to third parties is authorised
8.1 The rule
The 2025 amendments require that a parent be able to consent to the collection and use of a child’s personal information without also being required to consent to its disclosure to third parties, unless that disclosure is integral to the service the child is using. Consent to a non-integral disclosure must be given separately from consent to collection and use.
In the school setting, the institution gives that consent on behalf of parents for its school-authorised educational purpose, under the Federal Trade Commission’s guidance described in section 3.2. We apply the rule as follows: the institution authorises collection and use, together with the disclosures needed to operate, support and bill the service, when it accepts our Terms and Conditions; and the institution gives a separate authorisation for disclosure to the AI model providers if and when it activates the AI add-on. Neither authorisation is given by a child, and neither is inferred from a child’s use of the platform.
8.2 The integral disclosure: Amazon Web Services
Amazon Web Services is the disclosure that is integral to the platform. Classe365 runs on AWS infrastructure. The child’s record is stored there, served from there and backed up there. There is no version of the service in which the record does not reach AWS, and no configuration in which AWS can be switched off.
Standard customers’ data is hosted on Amazon Web Services in the AWS region allocated to the customer’s account at set-up, which is generally the region nearest to the customer. That region may be outside the customer’s own country. The region that applies to a particular account is confirmed on request. Enterprise customers may take an optional private cloud deployment on Amazon Web Services, Microsoft Azure or Google Cloud; where an institution has taken that option, its chosen cloud provider replaces AWS as the integral hosting disclosure for that institution’s tenant, and the institution can tell parents which provider it uses.
8.3 The core sub-processors, authorised as part of the service
When the institution accepts our Terms and Conditions, it authorises us to collect and use children’s information for its educational purpose and to disclose it to the core sub-processors needed to operate, support and bill the service. Those sub-processors, and what each is for, are:
| Sub-processor | What it is for | What it means for the child |
|---|---|---|
| Amazon Web Services — hosting and storage | Storing, serving and backing up the child’s record | The record exists on the platform; see section 8.2 |
| Intercom — customer support messaging | Handling a support conversation about the child’s record raised by the institution, so that a query about the record can be answered | Information about the child reaches Intercom only when the institution raises a support query that involves the child’s record |
| Atlassian — engineering issue tracking and fault diagnosis | Recording and diagnosing a fault affecting the child’s record | Information about the child reaches Atlassian only when a fault affecting the child’s record is investigated |
| Stripe and PayPal — online fee payments | Processing fees relating to the child that are paid online through the platform | Information about the child reaches Stripe or PayPal only when a fee relating to the child is paid online; card and bank details are held by the processor, not by us |
Each of these disclosures is limited to the purpose shown, uses no more information than that purpose needs, and is governed by the contract described in section 7. The institution’s authorisation covers these disclosures because the service cannot be operated, supported and billed without them. Institutions that do not take online fee payments do not use Stripe or PayPal, and no information about their pupils reaches those processors.
8.4 The AI model providers, authorised separately at AI add-on activation
Disclosure to OpenAI, Anthropic and Google is not part of the service the institution authorises when it accepts our Terms and Conditions. It is authorised separately, by the institution, at the point at which it activates the AI add-on.
Before the AI add-on is enabled for an institution’s account, the institution acknowledges that activating it authorises the disclosure of its students’ information, including children’s information, to those providers for the institution’s educational purpose, through their business API services under terms that do not permit the provider to use our customers’ data to train its models. Without that acknowledgement the add-on is not enabled, no child’s information is sent to those providers, and the features that depend on them do not run. Analytics features that run on models hosted in our own environment (section 11.1) do not involve these providers.
An institution that has not activated the AI add-on gets the full educational service. The child’s account, lessons, coursework, assessments, attendance, reports and communications all work exactly as they would otherwise. We do not degrade, limit or withdraw a child’s access to the platform because the institution has not activated the add-on.
8.5 How the authorisation is given
The authorisation in section 8.3 is given by an administrator of the institution, acting on its behalf, when the institution accepts our Terms and Conditions. The authorisation in section 8.4 is given by an administrator of the institution, acting on its behalf, when it activates the AI add-on. In each case the acknowledgement is presented in plain language, describes what is being authorised and for what purpose, and refers to this policy and to the Notice to Parents, which we provide to the institution to pass to parents.
Where an institution’s own law or policy requires it to obtain consent from parents in addition to its authorisation, the institution obtains that consent by its own means. We provide the Notice to Parents and the information in this policy for that purpose free of charge.
8.6 Record of authorisation
We keep a record of each authorisation the institution gives: the user who gave it, the institution, the date and time, and the version of the acknowledgement and of this policy in force at the time. The record is held at institution level. We do not hold consent records against an individual child’s record, and we do not ask the institution to enter one. The record of authorisation is kept for as long as the institution’s subscription continues and is deleted with the institution’s other data under section 10.4.
9. Withdrawal of authorisation
9.1 Withdrawal for a child
The institution may withdraw its authorisation for a particular child at any time, including where a parent asks it to. It does so by stopping further collection for that child — deactivating the child’s account — or by deleting the child’s record. Where a parent wishes to withdraw, the parent asks the institution, as section 14 describes, and the institution acts.
When the institution deactivates a child’s account, no further information about that child is collected through the platform. When the institution deletes the child’s record, the record is removed from the platform and is permanently deleted under the retention schedule in section 10, and we do not use it for any purpose in the meantime.
9.2 Deactivating the AI add-on
An institution may deactivate the AI add-on at any time, or ask us to switch specific AI features off. When it does, we stop sending its students’ information to the AI model providers as soon as reasonably practicable after the deactivation is recorded, and features that depend on those providers stop using that information. Analytics features that run on models hosted in our own environment are unaffected unless the institution asks for them to be switched off as well. Deactivation does not undo processing that was lawfully carried out before it took effect.
9.3 Refusing further collection altogether
A parent may refuse to permit any further collection or use of their child’s personal information. Because the institution controls the record, that decision has consequences for the child’s enrolment that only the institution can explain — a child’s record is how a school runs the child’s education. A parent who wants to refuse further collection should raise it with the institution, which will act and will instruct us where our help is needed. Where such a request reaches us first, we acknowledge it, identify the institution, pass it on without undue delay, and tell the parent who to expect a response from. Where the institution instructs us to stop further collection for a child, we do so, and we delete the child’s information on the institution’s instruction under section 10.
10. How long children’s information is kept, and when it is deleted
10.1 Published retention schedule
The amended Rule requires operators to maintain, and publish in their online notice, a written data retention policy that sets out the purposes for which children’s information is collected, the business need for keeping it, and the timeframe for deleting it. This section is ours. The schedule below is the same one we publish for all customer data.
| Data category | Retention |
|---|---|
| Student or candidate record after the institution deletes it | 7 days, then permanent deletion |
| All customer data after subscription termination | 30 days, then permanent deletion |
| Support correspondence | 24 months from resolution |
| Server and security logs | 30 days |
| Marketing and CRM contact data | 36 months from last engagement |
| Backups | Each daily backup retained 7 days |
Marketing and CRM contact data is never data about a child. We hold no marketing records about children, and children are never added to any marketing list.
Why we keep each category. The purposes for which children’s information is collected are those in section 5. A child’s record is kept for the institution’s education purpose until the institution deletes it. The further 7 days exist only because of the daily backup cycle that lets the institution recover from an error. Customer data is kept for 30 days after termination so that the institution can take a final export and deletion can be completed across all systems. Support correspondence is kept for 24 months so that we can investigate recurring faults and answer questions about the support we gave. Server and security logs are kept for 30 days to detect and investigate security incidents. We do not keep children’s personal information indefinitely.
10.2 We keep a child’s information only as long as it is needed
A child’s record is held for as long as the institution needs it for the education purpose it was collected for, and no longer. The institution decides when that purpose has ended and deletes the record. We do not retain a child’s information indefinitely, and we do not retain it for any purpose of our own once the institution has deleted it.
10.3 The 7-day backup consequence, stated plainly
We take daily backups. Each daily backup is retained for 7 days on a rolling basis, which gives an institution a seven-day restore window: it may request restoration from any of the preceding 7 days. Backups are maintained for the life of an active subscription.
Because of that rolling window, a child’s record deleted by an institution persists in backups for no more than 7 days. After 7 days the last backup containing it has itself expired and the record is gone. That is why the retention line for a deleted student record reads “7 days, then permanent deletion” — the 7 days is the backup tail, not a period during which we continue to use the record. Once a record is deleted from the live platform it is no longer accessible in the platform, is not used for any purpose, and is not restored except on the institution’s own request within that window.
10.4 On termination
When an institution’s subscription ends, all of its customer data, including children’s records, and all backups containing that data, are deleted within 30 days.
10.5 Longer retention where the law requires it
We keep financial and tax records for the period required by applicable tax and company law, which may be longer than the periods above. Where we are subject to a legal hold, we retain the affected records until the hold is lifted, and no longer. Neither exception is used to retain a child’s education record for a purpose of our own.
11. What we never do with children’s information
These are commitments, not aspirations.
We do not sell children’s personal information. There is no circumstance in which a child’s record is sold, licensed, rented or exchanged for value.
We do not serve targeted advertising to children. No third-party advertising is served inside the authenticated platform, and no advertising of any kind is shown to children.
We do not build advertising profiles. We do not create, buy, enrich or share a profile of a child for advertising or commercial purposes, and we do not share children’s information for cross-context behavioural advertising.
We do not use children’s data to train, fine-tune or improve any general-purpose or shared AI model. Where an AI feature uses a model that learns from data, that model is trained only on that customer’s own data — it is per-tenant — and is used only for that customer. Data is never pooled across customers, and one customer’s data is never used to improve the service for another.
We do not use children’s information for our own marketing. We send no marketing to children, and we never use a child’s record, or a parent’s details held in a child’s record, for our own marketing.
We do not ourselves require a child to disclose more information than is reasonably necessary to take part in an activity. The institution decides which fields its own forms require.
We do not collect audio recordings of children’s voices through any voice-capture feature, and we hold no voiceprints. Coursework that contains a child’s voice is handled as set out in section 4.3.
We do not perform facial or voice recognition, subject to the SMOWL qualification in section 4.4.
11.1 AI features and children
AI features are an optional add-on module. If an institution has not taken the add-on, no AI features are active and no child’s information is processed by AI. Where the institution has taken it, the institution chooses whether to use the AI features, and it may ask us to switch specific features off.
Two kinds of model are used:
Analytics features — grading analysis, attendance analysis, attrition tracking and behaviour analytics — use small language models hosted in our own environment on Amazon Web Services. The child’s information used by these features does not leave our hosting.
Agent automation and workflow features, and other features that use general-purpose AI models, use models provided by OpenAI, Anthropic and Google, accessed through their business API services under terms that do not permit the provider to use our customers’ data to train its models. Sending a child’s information to these providers is authorised separately by the institution when it activates the AI add-on, as section 8.4 describes. Without that authorisation the add-on is not enabled and no child’s information reaches these providers.
Where an AI feature operates on a child’s record, all outputs are advisory. Decisions about a child remain with the institution and its staff. No automated decision produces a legal or similarly significant effect on a child without human review.
We design our AI features so that users can recognise AI-generated output and know when they are interacting with the AI chat assistant, reflecting the transparency obligations in Article 50 of the EU AI Act, which applied from 2 August 2026. Our AI features are not designed to infer the emotions of students, learners or staff, and we do not use AI for any practice prohibited by Article 5 of the EU AI Act.
When an institution’s data is deleted at the end of its subscription, any per-tenant model trained on that data is deleted with it.
The Annex III high-risk obligations of the EU AI Act for education systems apply from 2 December 2027, following the deferral introduced by the Digital Omnibus. Attrition tracking, behaviour analytics and grading analysis fall within that scope. We commit to meeting those obligations by that date. We do not claim high-risk conformity now.
12. Global support and remote access
Classe365 provides 24/7 follow-the-sun support. Our support and engineering staff are employees of the Classe365 group, located in Australia, India, the Philippines, Spain and the United States, and they may access customer data, including children’s records, to provide support and engineering.
Customer data is hosted on Amazon Web Services and is not stored in any of those locations. Staff access it remotely, and only when needed to resolve a support request or fix a fault. It is part of the normal running of the service. A support ticket, fault diagnosis, data restoration request or configuration request may be handled by staff in any of the five locations, depending on the time of day, and doing that work can require access to the records held in an institution’s tenant, including the records of children.
That access is subject to:
role-based, least-privilege access controls, so an individual can reach only the data needed for the task at hand;
authentication controls and logging of staff access to customer environments;
written contractual confidentiality obligations binding on each group company and on individual staff members;
intra-group data transfer agreements between the Classe365 group companies;
for personal data from the European Economic Area, the United Kingdom or Switzerland, the transfer mechanisms set out in our Personal Data Processing Agreement;
the same instruction-bound limits that apply to us as processor — the data is used only to provide support and engineering, never for any other purpose of a group company or staff member.
Our support and engineering staff are group employees acting for the contracting entity, not an independent third-party recipient, and their access is part of providing the core service. We disclose it because institutions need to know it to complete their own assessments, and because parents are entitled to know who can see their child’s record.
13. Our written children’s information security program
We maintain a written children’s information security program, established, implemented and maintained to protect the confidentiality, security and integrity of children’s personal information. It is documented, it is reviewed, and its elements are set out below.
13.1 Designated coordinator
A named individual is designated as the coordinator of the children’s information security program. The coordinator is responsible for the programme’s implementation and maintenance, for the annual risk assessment, for sub-processor due diligence in relation to children’s data, for the annual testing and review, and for reporting the results of that review to management. The coordinator is the internal point of escalation for any incident involving children’s information.
13.2 Annual risk assessment
At least once a year, we carry out and document a risk assessment covering internal and external risks to the confidentiality, security and integrity of children’s personal information. The assessment considers:
employee training and management, including who has access to children’s records and why;
the design and operation of the platform, including information processing, storage, transmission, retention and disposal;
the ability to prevent, detect and respond to attacks, intrusions and other systems failures;
the risks introduced by each sub-processor that receives children’s data.
Each identified risk is assigned an owner and a remediation plan, and the plans are tracked to completion.
13.3 Safeguards
We design, implement and maintain safeguards to control the risks identified in the assessment. The technical and organisational controls in place across the platform are:
hosting on Amazon Web Services infrastructure;
encryption of data in transit using TLS;
encryption of data at rest;
network segregation between environments, and logical separation of each customer’s data from every other customer’s;
least-privilege access control, with access granted by role and reviewed;
an OWASP-aligned secure development lifecycle;
daily backups, retained for 7 days on a rolling basis;
DDoS protection;
continuous monitoring of systems and security events;
logging of staff access to customer environments and of changes to records.
13.4 Sub-processor due diligence
Before we engage a service provider or sub-processor that will receive children’s personal information, we take reasonable steps to satisfy ourselves that it is capable of maintaining the confidentiality, security and integrity of that information, and we obtain written assurances that it will do so. We do this for each of Amazon Web Services, Intercom, Atlassian, Stripe and PayPal, for OpenAI, Anthropic and Google where an institution has the AI add-on, and for the Classe365 group companies that employ our support and engineering staff.
Each provider is bound by a written contract that restricts its use of the information to providing its service to us, imposes confidentiality obligations, and requires security measures appropriate to the information it handles. We reassess each provider that receives children’s data at least annually as part of the review in section 13.6, and keep them under review in between.
13.5 Testing and monitoring
We test and monitor the effectiveness of the safeguards at least annually. Testing covers the operation of access controls, encryption, logging and monitoring, the backup and restoration process, and our incident response process. Findings are recorded, assigned an owner and remediated.
13.6 Annual evaluation and review
At least once a year, and whenever there is a material change to our business practices, our systems, our sub-processors or the risks we face, the coordinator evaluates and adjusts the programme in light of the results of the testing and monitoring, the risk assessment, and any incident. The review and its outcome are documented.
13.7 Certifications — stated accurately
A SOC 2 Type II audit is in progress and is expected to complete in December 2026. We do not hold a SOC 2 report today and do not claim one. We do not hold ISO 27001 certification and do not claim one. We will update this section when the position changes.
13.8 Breach notification
If we become aware of a personal data breach affecting customer data, including children’s records, we will notify the affected institution within 24 hours of becoming aware of it, with the information we have at that point, and will follow up as the investigation develops. Where we act as processor, the institution as controller decides whether and how to notify regulators, parents and individuals, and we support it in doing so with the information and technical assistance it needs.
14. Parental rights
A parent or guardian of a child under 13 has the right to:
Review the personal information we hold about their child, and be told what categories are held, how they are used and who receives them.
Refuse to permit further collection or use of their child’s personal information.
Direct the deletion of their child’s personal information.
Know who receives their child’s information and on what basis, as set out in sections 7 and 8, and ask the institution to withdraw its authorisation for their child, as set out in section 9.
Not be required to disclose more information than is reasonably necessary for the child to take part in an activity.
Parents in the European Union, the United Kingdom, Australia and other jurisdictions have further rights under their own law, including rights of access, correction, erasure, restriction, portability and objection. Those rights are described in the Privacy Policy and we honour them.
14.1 How to exercise these rights
These rights are exercised through the institution. The institution authorised the collection on parents’ behalf, it controls the child’s record, it holds the context, and it can act directly in the platform. Contact the school office, the registrar, student services, or the institution’s data protection contact. The institution can review, correct and delete the record, stop further collection, and withdraw its authorisation for the child, and it instructs us where our help is needed.
If you cannot reach the institution, or you want to raise something with us directly, email clientservice@classe365.com. Tell us the child’s name, the institution, your relationship to the child, and what you want. We will route your request to the institution and help it respond.
14.2 How requests are routed when we act as processor
Because the institution controls the record and authorised the collection, a request that reaches us is handled like this:
We acknowledge the request and identify the institution concerned.
We forward the request to that institution without undue delay, because the institution is the controller and the decision is legally its to make.
We tell you that we have done so, and who to expect a response from.
We do not disclose, correct or delete records inside an institution’s tenant on our own initiative, and we do not act against the institution’s instruction. Doing so would mean overriding the controller and altering a child’s education record without the school’s knowledge.
We give the institution reasonable technical help to fulfil the request, using the platform’s standard export, search, correction and deletion functions, as part of the service. Bespoke or bulk work beyond that may be charged at our then-current rates, agreed with the institution in advance. We never charge a parent.
Where the institution instructs us to act — for example to delete a child’s information, to stop further collection, or to confirm what has been deleted — we act on that instruction and confirm to the institution when it is done.
If the institution does not respond to a request we have forwarded within a reasonable time, we follow it up with the institution and tell you that we have done so.
14.3 Verification
Before a request about a child is acted on, the person making it must be shown to be the child’s parent or guardian. The institution verifies the relationship from its own records, which is usually the most reliable method available. Where a request reaches us first, we confirm the details we are given against the record held in the institution’s tenant when we forward it, and we ask the institution to confirm the relationship before it acts. We will not ask you for a government-issued identity document unless there is no other way to verify a high-risk request, and we will not create a new record of one.
14.4 Response times
We respond to requests we control within one month of receiving a verifiable request. Where a request is complex, or where we have received several from you, we may extend by up to a further two months and will tell you within the first month, with the reason. For requests we forward to an institution, the institution’s own timeframe applies, and we will have passed the request on promptly.
14.5 No charge
We do not charge a parent for reviewing, correcting or deleting a child’s information, or for asking the institution to stop further collection.
15. FERPA and other education law
Where an institution in the United States is subject to the Family Educational Rights and Privacy Act, a child’s records in the platform are education records and we act as a school official with a legitimate educational interest, under the direct control of the institution. Parents exercise inspection, correction and hearing rights through the institution. The institution designates what constitutes directory information and controls opt-outs through the platform; we do not designate or disclose directory information on our own initiative. Our full position is in the FERPA Compliance Statement.
Where an institution is subject to a state student privacy law, or to a children’s or education privacy law outside the United States, our commitments in sections 11, 13 and 14 apply regardless, and we support the institution in meeting its own obligations.
16. Hiree365 and children
Hiree365 has a minimum age of 16. It is not available to anyone under 16, and it has no users under 13. It is a campus recruitment and employability platform used by students seeking employment, by institutions running campus placement programmes, and by employers seeking candidates.
Because Hiree365 has no users under 13, COPPA’s requirements for children under 13 do not arise for it. If we became aware that a person under 16 had obtained a Hiree365 account, we would tell the institution and the account would be removed. Candidate privacy on Hiree365 is described in the Hiree365 Candidate Privacy Notice.
17. Changes to this policy
We review this policy at least annually and whenever we make a change that affects it.
Where a change materially affects how we handle children’s personal information, we will give at least 30 days’ notice before it takes effect, by email to institutional account contacts and by a notice on our website and in the platform, so that institutions can inform parents. Where a change would materially expand what is collected about a child, how it is used, or who receives it, we will ask the institution to confirm its authorisation for the change before it applies to that institution’s account, and the institution is responsible for giving parents any notice, and obtaining any consent, that its own law requires. We support it in doing so. Minor corrections — a broken link, a clarified sentence, an updated address — take effect when published.
Every version carries a “Last updated” date and an “Effective” date at the top. This version was published on 22 September 2026 and takes effect on 22 October 2026.
18. How to contact us
Privacy and children’s privacy enquiries: clientservice@classe365.com Support: clientservice@classe365.com Accessibility line: +61 2 9472 5000
Legal notices — United States customers: 365 Software, LLC 131 Continental Dr, Suite 305 Newark, DE 19713 United States
Legal notices — all other customers: Sprout On Web Pty Ltd 22 Palm Street St Ives, NSW 2075 Australia
If you write to us about a child, please tell us the child’s name, the institution the child attends, and your relationship to the child. It lets us route your request correctly the first time.
Classe365 and Hiree365 are operated by 365 Software, LLC (United States customers) and Sprout On Web Pty Ltd (all other customers), with 24/7 support and engineering provided by our group team in Australia, India, the Philippines, Spain and the United States.
