Data Retention Schedule

1. About this schedule

1.1 What this document is

This is our published retention schedule. It sets out, for each category of personal information we hold:

1. the purpose for which it is collected;
2. the specific business need that justifies keeping it for the period stated; and
3. the timeline on which it is deleted.

All three are stated for every category, because a retention schedule that gives only a period explains nothing about why that period is the right one.

1.2 Why it is published

The amended Children’s Online Privacy Protection Rule requires an operator to publish its retention policy for children’s personal information, including the purpose of collection, the business need for retention, and the deletion timeline. The FTC’s Final Amendments were published at 90 FR 16918 on 22 April 2025, took effect on 23 June 2025, with a compliance date of 22 April 2026.

Rather than publishing a separate schedule for children and keeping everything else private, we publish one schedule covering everything. Institutions, parents, students, candidates and reviewers can therefore see the whole picture in one place.

1.3 Which platforms it covers

• Classe365 — our student information system, learning management system and CRM for education institutions.
• Hiree365 — our campus recruitment and employability platform. Hiree365 has a minimum age of 16 and is not available to anyone under 16.

Both are operated by the same group and this schedule covers both.

1.4 Which entity is responsible

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.

Customers located anywhere else — including 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.

Support and engineering services are provided by Classe365 India Pvt Ltd, 37, Venjay Edifice Complex, 3rd Floor, JLB Road, Chamarajapuram, Mysuru – 570 005, India.

Together we are “Classe365”, “we”, “us” and “our”.

1.5 The role the institution plays

For student, learner and candidate records, the institution is the controller and we are the processor. The institution decides what to collect, how long to keep it while its subscription is active, and when to delete it. This schedule describes what happens on our side once the institution has made that decision, and what happens to data we hold in our own right.

The periods in this schedule are maximums measured from the trigger stated. An institution can delete a record sooner, and many do.

1.6 Related documents

Read this schedule together with our Privacy Policy, our Children’s Privacy Policy, our US State Privacy Notice, our Sub-processor List, our Security Statement and our AI Use and Transparency Statement. Where a term is defined in the Privacy Policy, it has the same meaning here.

2. Our retention principles

2.1 We do not retain personal information indefinitely

We do not hold personal information indefinitely. Every category in this schedule has a defined end point, and information is permanently deleted when it is reached. There is no category of personal information that we keep forever “in case it is useful”, and there is no archive of former customers’ student records sitting behind the platform.

2.2 We do not retain personal information for secondary purposes

We retain personal information only for the purpose for which it was collected. We do not keep it, after the point at which it should be deleted, in order to:

• train, fine-tune or improve any general-purpose or shared AI model;
• build a product, a benchmark, a dataset or an analytics offering;
• market to the individuals concerned;
• build advertising profiles or serve targeted advertising; or
• sell, licence or otherwise make it available to a third party.

Where a feature uses a model that learns from data, that model is trained only on that customer’s own data and used only for that customer. Data is never pooled across customers. Our AI Use and Transparency Statement explains this in full.

2.3 Deletion means deletion

When we say permanent deletion, we mean the record is removed from the production systems and ceases to exist in them. The only remaining copy is in a backup, which is itself deleted on the timeline in section 5. We do not retain a “deleted” record in a hidden state, and we do not de-identify a record and keep it as a substitute for deleting it.

2.4 We collect what the service needs

We do not require any government-issued identifier 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 held under this schedule like any other field. We do not collect audio recordings of children’s voices. Classe365 and Hiree365 do not themselves collect, store or process biometric identifiers, and do not perform facial or voice recognition; where an institution enables the third-party proctoring service SMOWL, it contracts with SMOWL directly and any biometric processing occurs under SMOWL’s own terms and privacy policy.

3. The retention schedule

3.1 The table

3.2 How to read it

Each period runs from the trigger named in the category — deletion by the institution, termination of the subscription, resolution of a support matter, creation of a log entry, the individual’s last engagement with us, or the date a backup was taken. The sections that follow set out the purpose, the business need and the deletion timeline for each category in turn.

4. Each category explained

4.1 Student or candidate record after the institution deletes it — 7 days, then permanent deletion

What it covers. The records an institution holds about a student, learner or candidate in the platform: identity and contact details, enrolment and programme records, attendance, assessment results and grades, submitted work, behaviour and engagement records, fee and payment records, communications held in the record, documents uploaded to it, and Hiree365 candidate profiles and placement records. Where an institution’s own forms collect a government-issued identifier, that field is part of the record.

Purpose of collection. These records exist so that the institution can run its educational or placement programme: admit and enrol students, deliver and assess learning, record attendance, communicate with students and parents, administer fees, support students who need support, meet its own reporting obligations, and — in Hiree365 — run a campus placement programme. We hold them solely to provide the platform to the institution, on the institution’s instructions.

Specific business need for retaining it after deletion. Once the institution deletes a record, we no longer need it to provide the service. We keep it for 7 days, and no longer, for one reason: deletion mistakes are common and irreversible if acted on immediately. A record deleted by the wrong staff member, deleted in the wrong bulk operation, or deleted through a misconfigured integration is usually noticed within days. The 7-day window matches our rolling backup restore window (section 5) and gives the institution a realistic opportunity to ask for a restoration before the record is gone for good. Beyond 7 days we have no business need for it at all.

Deletion timeline. Permanently deleted 7 days after the institution deletes it. Because our daily backups are each retained for 7 days, a deleted record persists in backups for no more than 7 days and is then gone from those too.

Under FERPA, we act as a school official with a legitimate educational interest under the school official exception, under the direct control of the institution. We use education records only to provide the service, on the institution’s instructions. We do not use education records for advertising, we do not sell them, and we do not use them to train shared AI models.

4.2 All customer data after subscription termination — 30 days, then permanent deletion

What it covers. Everything held in the customer’s tenant at the point the subscription ends: all student, learner and candidate records; staff and user accounts; configuration; uploaded documents and course material; institutional records; and the backups of that tenant.

Purpose of collection. The data was collected and held to provide the platform to that customer for the duration of its subscription.

Specific business need for retaining it after termination. Once the subscription ends, the only legitimate need is an orderly handover. Institutions need a defined window in which to export their records — a student information system holds the institution’s operating records, and losing them at the moment of termination would harm the institution and the students whose records they are. Institutions also sometimes terminate in error, reverse a decision, or resolve a billing dispute shortly after termination. 30 days is enough for an export and a reversal, and short enough that we are not holding another organisation’s student records long after our relationship with it has ended.

Deletion timeline. Permanently deleted within 30 days of termination. This includes backups — on termination, backups are deleted together with all other customer data within that 30-day period. After it, we hold no copy of the customer’s records.

Export before you go. Institutions should export their data before or during the 30-day window. We will help with an export on request. Once the period has passed the data cannot be recovered, by us or by anyone else, because it no longer exists.

4.3 Support correspondence — 24 months from resolution

What it covers. Correspondence with our support team: messages, tickets, email threads, the description of the problem, and any screenshots or files a user attaches to explain it. Support messaging is provided through Intercom, and engineering fault diagnosis is tracked in Atlassian; both are identified in our Sub-processor List.

Purpose of collection. To answer the question that was asked, diagnose and fix faults, and keep a record of what was advised, changed or agreed.

Specific business need for retaining it. Support history has a real working life beyond the day a ticket closes. A recurring fault is diagnosed by looking at what happened last time. A configuration change made at an institution’s request is evidenced by the correspondence in which the institution requested it. A question raised at the start of an academic year is raised again at the start of the next one, often by different staff. Institutions also ask us, sometimes long after the event, what was done and when. 24 months from resolution covers two academic cycles, which is the period over which this history is genuinely useful. After that its value falls away and we delete it.

Deletion timeline. Deleted 24 months after the support matter is resolved.

Please keep student data out of support tickets. Support correspondence is retained for longer than a deleted student record, so we ask institutions not to attach or paste student personal information into support messages where a reference or an account identifier will do. Where a user does include student information in a ticket, it is held under this category and deleted on this timeline; if you tell us it is there, we will remove it sooner.

4.4 Server and security logs — 30 days

What it covers. The technical logs generated by the platform and its infrastructure: access and authentication events, application and error logs, security events, and administrative actions. These records can include IP addresses, user or account identifiers, timestamps and the action performed.

Purpose of collection. Security, integrity and reliability. Logs are how we detect unauthorised access, investigate a suspected incident, diagnose an outage or a data fault, and confirm who did what inside an account.

Specific business need for retaining it. Security investigations are retrospective. When something is reported — a suspicious login, a record that changed unexpectedly, a report from a security researcher — the evidence needed to understand it was created before anyone knew there was a problem. Without a log window, the answer to “what happened?” is unavailable. 30 days is long enough to investigate the incidents that are actually reported, and to support our commitment to notify a breach within 24 hours of becoming aware of it, while keeping a body of identifiable technical data short-lived. Logs are not used to analyse individual user behaviour for any purpose other than security, integrity and reliability.

Deletion timeline. Deleted 30 days after the log entry is created.

One exception. Where a specific log entry forms part of an active security investigation or is subject to a legal hold (section 7), it is preserved for the duration of that investigation or hold and deleted when it ends. This is the only circumstance in which a log entry outlives 30 days, and it applies to the specific entries concerned, not to logs generally.

4.5 Marketing and CRM contact data — 36 months from last engagement

What it covers. Business contact information for people who deal with us commercially: prospective and existing institutional contacts, demonstration and trial requests, enquiries, event and content registrations, and marketing engagement records. This is business-to-business marketing data about staff at institutions and organisations.

This category never contains student, learner or candidate records. The marketing website and the marketing tools that run on it — Google Analytics, Semrush, Mailchimp and ActiveCampaign — operate on classe365.com only and never receive student or candidate records from the platform. Our Sub-processor List makes this separation explicit.

Purpose of collection. To respond to enquiries, run free trials, and carry out business-to-business marketing and relationship management with institutions and organisations.

Specific business need for retaining it. Education procurement moves slowly. An institution that requests a demonstration may run a budget cycle, a committee process and a tender before it makes a decision, and the same contact often returns a year or two later. Deleting a business contact’s history after a few months would mean asking the same organisation the same questions repeatedly and failing to honour preferences they have already expressed — including a preference not to be contacted. 36 months from last engagement matches the real length of these cycles. The period restarts on each engagement, so an active relationship is retained while it is active; a contact who does not engage with us for three years is deleted.

Deletion timeline. Deleted 36 months after the individual’s last engagement with us.

Unsubscribing. Every marketing email carries an unsubscribe link, and you can ask us to stop at clientservice@classe365.com. If you ask us to erase your details, we will (section 6), keeping only the minimal suppression record needed to make sure we do not contact you again — a record of that kind exists to honour your objection, and holding it is the only way to give effect to it.

4.6 Backups — each daily backup retained 7 days

What it covers. The daily backups of the platform.

Purpose of collection. Resilience. Backups exist so that customer data can be restored after a hardware failure, a data corruption, a security incident or a mistaken deletion.

Specific business need for retaining it. A backup is only useful if it predates the problem it is being used to fix. Deletion mistakes, data corruption and integration faults are typically discovered within a few days. A rolling 7-day window gives institutions a real choice of restore points across the preceding week, while keeping the period in which a deleted record survives anywhere as short as it can sensibly be. A longer window would mean deleted student records lingering longer, which we regard as the greater harm.

Deletion timeline. Each daily backup is deleted 7 days after it is taken. Section 5 sets out the full backup position.

5. The backup position, precisely

This is the part of a retention schedule that is most often left vague, so we state it exactly.

1. We take daily backups of the platform.
2. Each daily backup is retained for 7 days. Backups are held on a rolling 7-day window, so at any time there are backups covering each of the preceding 7 days.
3. Customers may request restoration from any of the preceding 7 days. Contact clientservice@classe365.com to request a restoration.
4. Backups are maintained for the life of an active subscription. While the subscription is active, the rolling 7-day set is continuously maintained.
5. Therefore, a deleted record persists in backups for no more than 7 days. When an institution deletes a student or candidate record, it is removed from the production system and permanently deleted after 7 days; the backups that still contain it age out of the window within the same 7 days. After 7 days it exists in no backup.
6. On termination, backups are deleted together with all other customer data within 30 days. Termination does not leave a backup behind. All data, including backups, is permanently deleted within 30 days of termination.

Backups are encrypted at rest and held under the controls described in our Security Statement. Restoring from a backup restores the state of the data at the time the backup was taken; it does not resurrect records that had already been permanently deleted before that point.

6. Deletion on request

6.1 Institutions

An institution can delete a student, learner or candidate record from the platform at any time. The record is then permanently deleted after 7 days, as described in section 4.1.

An institution can also ask us to delete data directly, at clientservice@classe365.com — including a targeted deletion, a bulk deletion, or the deletion of an entire tenant. We action deletion requests from an institution’s authorised contacts and confirm when the deletion is complete.

6.2 Parents, students, learners and candidates

If you are a parent, a student, a learner or a candidate, your records belong to your institution, and it is the institution — not us — that decides whether they are deleted. Send your request to your institution. Under FERPA, parents and eligible students exercise inspection, correction and hearing rights through the institution, and we support the institution in fulfilling them.

Under the amended COPPA Rule, a parent may direct the operator to delete their child’s personal information. Where a parent contacts us directly, we will pass the request to the institution and support the institution in acting on it, because the institution is the controller and holds the relationship with the family. We will not delete an institution’s records on the instruction of someone other than the institution — doing so would let one person remove another’s education record — but we will make sure the request reaches the right place and is acted on.

If you contacted us directly for a non-student reason — a demonstration request, a marketing enquiry, a support message — that information is ours to delete, and we will delete it on request under section 4.5 or 4.3.

6.3 What we do when a deletion request arrives

We confirm the requester is entitled to make the request; we identify everywhere the data is held, including in support correspondence and marketing systems where relevant; we delete it and instruct our sub-processors to do the same where they hold a copy; and we confirm completion. Data in backups is deleted on the backup timeline in section 5 rather than being extracted from an existing backup, because selectively editing a backup would compromise its integrity — the 7-day window is short by design for exactly this reason.

Our Privacy Policy and US State Privacy Notice explain the individual rights available in particular jurisdictions and how to exercise them.

7. Legal holds and exceptions

7.1 When retention is extended

Very occasionally, information that would otherwise be deleted must be preserved. This happens only where we are required or legally permitted to preserve it — for example where it is relevant to actual or reasonably anticipated legal proceedings, a regulatory investigation, a law enforcement request that we are legally obliged to comply with, or the investigation of a security incident or fraud.

7.2 How a hold works

A legal hold is:

• narrow — it applies to the specific information that must be preserved, not to a whole tenant or category;
• documented — the reason and the scope are recorded when it is applied;
• reviewed — we check periodically whether it is still needed; and
• temporary — when it ends, the information is deleted immediately, or on its normal timeline if that has not yet passed.

7.3 What a hold is not

A legal hold is not a route around this schedule. Held data is not used for any purpose other than the matter for which it is preserved. It is not analysed, not used in AI features, not used for marketing, and not used to improve the service. We do not apply a hold because information might one day be useful.

7.4 Telling the institution

Where information belonging to a customer is placed under a legal hold, we will tell the customer unless we are legally prohibited from doing so.

7.5 Financial records

Payment processing is carried out by Stripe and PayPal, identified in our Sub-processor List. Records of transactions with a customer — invoices and payment records held for tax, accounting and audit purposes — are kept for the period required by the applicable law in the jurisdiction of the contracting entity. These are records of a commercial transaction with the institution or organisation. They are not student, learner or candidate records, and they are not used for any purpose beyond financial administration and compliance.

8. Configuring or requesting different periods

8.1 What an institution can decide for itself

Within its own tenant, the institution controls what is collected, what is entered on its own forms, when a record is deleted, and how long its own working data is kept before deletion. Nothing in this schedule requires an institution to keep a record for any period — an institution that wants shorter retention can delete records sooner, and the 7-day rule in section 4.1 then runs from that earlier deletion.

8.2 What can be arranged with us

An institution may need retention periods different from those published here — because its own regulator requires a specific period, because its jurisdiction imposes a rule, or because its internal records policy demands a shorter one. Write to clientservice@classe365.com to discuss it. We will tell you plainly what we can and cannot accommodate. Some periods are constrained by how the platform is built, and we would rather say so than agree to something we cannot deliver.

8.3 What is agreed contractually

Where a retention arrangement differs from this schedule, it is recorded in writing between the institution and the contracting entity, and in our Personal Data Processing Agreement where it concerns processing on the institution’s instructions. Where a written agreement with a customer specifies a different period, that agreement governs for that customer. This schedule states our standard position.

8.4 Deletion instructions during a subscription

An institution can instruct deletion at any time during its subscription, not only at the end. Institutions running a rolling records policy — for example, deleting records a fixed period after a student leaves — should apply it in the platform, and each deletion then follows the 7-day rule in section 4.1.

9. Where the data is held while we hold it

Standard customers’ data is hosted on Amazon Web Services in us-east-1 (Northern Virginia, United States). On request, data can be located in the nearest available AWS region to the customer. Enterprise customers may opt for a private cloud deployment on AWS, Microsoft Azure or Google Cloud.

Personnel of Classe365 India Pvt Ltd in Mysuru, India provide support and engineering services and may access customer data, including student data, for those purposes. That access is subject to access controls, contractual confidentiality obligations and intra-group data transfer agreements. We disclose it here because a retention schedule that told you when data is deleted but not who can see it in the meantime would be incomplete.

The sub-processors that receive student or candidate data — Amazon Web Services, Intercom, Atlassian, Stripe and PayPal — are listed in our Sub-processor List, together with the providers that operate on the marketing website only and never receive student or candidate records. Sub-processors hold data only for as long as they need it to perform their service for us, and are contractually required to delete it when we instruct them to.

Where personal data is transferred across borders, the mechanisms set out in our Personal Data Processing Agreement and described on our International Data Transfers page govern, and we do not restate their terms here.

10. Children’s personal information

The categories in section 4 apply to children’s personal information in the same way they apply to everyone else’s, and the published purpose, business need and deletion timeline for each category are those stated there.

In addition:

• We do not retain children’s personal information indefinitely, and we do not retain it for any secondary purpose.
• Children’s data is not used to train, fine-tune or improve any general-purpose or shared AI model.
• We do not sell children’s data, we do not permit targeted advertising to children, and we do not build advertising profiles of children.
• We do not collect audio recordings of children’s voices.
• We maintain a written children’s information security program, with a designated coordinator, an annual risk assessment, safeguards, sub-processor due diligence, and annual testing and review. Our Security Statement describes it.
• Under the amended COPPA Rule, parents may consent to collection and use without consenting to third-party disclosure, except where the disclosure is integral to the service. The only integral disclosure is Amazon Web Services, for hosting. Disclosures to Intercom (support), Atlassian (engineering), and Stripe and PayPal (payments) are optional and require separate consent. Our Children’s Privacy Policy explains how that consent is obtained and how it can be withdrawn.
• Hiree365 has a minimum age of 16 and is not available to anyone under 16. There are no under-13 users.

11. Review of this schedule

We review this schedule at least annually, and whenever we change a retention period, add a data category, change a sub-processor that holds data on our behalf, or change how backups are taken or retained.

Where a change materially affects how long personal information is retained, we will give at least 30 days’ notice before it takes effect, by a notice on classe365.com and by email to institutional account contacts. Minor corrections — a clarified sentence, a fixed link — take effect when published.

Each version carries a “Last updated” date and an “Effective” date at the top. The current version is dated 15 September 2026 and takes effect on 15 October 2026.

12. Contact us

Questions about retention, or to request deletion: clientservice@classe365.com Support: clientservice@classe365.com Accessibility line: +61 2 9472 5000

By post — United States customers: 365 Software, LLC 131 Continental Dr, Suite 305 Newark, DE 19713 United States

By post — all other customers: Sprout On Web Pty Ltd 22 Palm Street St Ives, NSW 2075 Australia

If you are a parent and you want to know how long your child’s information is held, this schedule is the answer, and your institution can tell you what it holds and when it deletes it. If you are a school administrator preparing a records policy or answering a parent, you are welcome to share this document directly.

Classe365 and Hiree365 are operated by 365 Software, LLC (United States customers) and Sprout On Web Pty Ltd (all other customers), with support and engineering services provided by Classe365 India Pvt Ltd.