Service Level Agreement

1. About this agreement

1.1 This Service Level Agreement (“SLA”) sets out the availability target, the way availability is measured, the support arrangements and the maintenance practices for the Classe365 platform (a student information system, learning management system and customer relationship management platform for education institutions) and the Hiree365 platform (a campus recruitment and employability platform). Together these are the “Platforms”.

1.2 The availability target in this SLA applies to Enterprise customers only.

1.3 Customers on plans below Enterprise do not receive a contractual uptime commitment. No uptime percentage is promised to them, and nothing in this SLA or in any other document gives them a contractual availability remedy. We operate the Platforms to the same technical standard for every customer and we work to keep them available for everyone, but for customers below Enterprise that is an operational practice, not a contractual commitment. A customer who requires a contractual uptime target must subscribe to an Enterprise plan. Sections 2, 5, 7, 8, 9, 10 and 11 of this SLA apply to all customers; sections 3, 4 and 6 apply only to Enterprise customers.

1.4 The customer contracts with one of two entities. Customers established in the United States contract with 365 Software, LLC (a Delaware limited liability company, 131 Continental Dr, Suite 305, Newark, DE 19713, United States). 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, 22 Palm Street, St Ives, NSW 2075, Australia). In this SLA, “Classe365”, “we”, “us” and “our” mean the customer’s contracting entity, and “Customer” means the organisation that subscribes — a K-12 school, a university or college, an academy or vocational training provider, or a corporate organisation using a Platform for corporate training.

1.5 This SLA forms part of the Master Terms and Conditions. Terms defined in those Terms have the same meaning here. Where this SLA and the Terms conflict on a matter of service levels, this SLA prevails.

1.6 A subscription is “Enterprise” only where an order form, quotation or invoice designates it as an Enterprise plan. If the Customer is unsure which plan applies, it should ask at clientservice@classe365.com before relying on this SLA.

2. Definitions

“Available” means that the production instance of a Platform is responding to correctly formed requests from the public internet and its Core Functions can be used.

“Business Day” means a day other than a Saturday, Sunday or public holiday in New South Wales, Australia, for customers contracting with Sprout On Web Pty Ltd, and a day other than a Saturday, Sunday or public holiday in the State of Delaware, United States, for customers contracting with 365 Software, LLC.

“Core Functions” means: user authentication and sign-in; reading and writing student, candidate and learner records; the learning management functions of Classe365, including course content delivery, assignment submission and gradebook; attendance recording; the administrative and reporting interface; and, for Hiree365, candidate profiles, job listings and applications. Core Functions do not include a beta, preview or early-access feature, a third-party integration, or a feature the Customer has disabled.

“Downtime” means any period of time, measured in whole minutes, during which a Core Function is not Available to the Customer, excluding any period that falls within an exclusion in section 5.

“Emergency Maintenance” means maintenance we carry out at short notice to preserve the security, integrity or stability of the Platforms, including applying a security patch, mitigating an active attack, or responding to a fault that presents a risk of data loss.

“Enterprise” has the meaning given in clause 1.6.

“Maintenance” means work we carry out on the Platforms or the infrastructure supporting them, including upgrades, patching, configuration changes, database work, migration and infrastructure changes, whether or not it makes a Core Function unavailable. Emergency Maintenance is Maintenance.

“Monthly Uptime Percentage” is calculated as set out in section 4.

“Total Minutes” means the total number of minutes in the relevant calendar month.

“Uptime Target” means the target in clause 3.1.

3. Availability target

3.1 For Enterprise customers, our availability target is a Monthly Uptime Percentage of at least 99.5% in each calendar month for each Platform to which the Customer subscribes.

3.2 The Uptime Target is a commitment we work to. It is a performance, target that we design, operate and monitor the Platforms to meet. It is not a guarantee that a Platform will be available for any particular period, and it is not a warranty of uninterrupted or error-free operation. The Platforms are provided on the “as is” and “as available” basis set out in the Master Terms and Conditions.

3.3 The Uptime Target is measured separately for Classe365 and for Hiree365. Availability of one Platform is assessed independently of the other.

3.4 The Uptime Target does not apply:

1. to a customer on a plan below Enterprise (clause 1.3);

2. during a free trial;

3. to a beta, preview, pilot, sandbox, test or early-access environment or feature;

4. to a feature made available at no charge; or

5. to any period before the Customer’s Enterprise subscription started or after it ended.

3.5 Section 6 sets out the sole and exclusive remedy where the Uptime Target is not met.

4. How availability is measured

4.1 The Monthly Uptime Percentage for a Platform in a calendar month is calculated as:

Monthly Uptime Percentage = ((Total Minutes − Downtime Minutes) ÷ Total Minutes) × 100

where Downtime Minutes is the total number of whole minutes of Downtime in that month, and Total Minutes is the total number of minutes in that month.

4.2 Downtime is measured by our own monitoring systems, which check the availability of the Core Functions from multiple locations at regular intervals. A Core Function is treated as unavailable from the first failed check, and available again from the first successful check that is followed by continued successful checks.

4.3 Our monitoring records are determinative. The Monthly Uptime Percentage for a month is the figure produced by our monitoring systems, and that figure decides whether the Uptime Target was met. Where a Customer’s own monitoring, a third-party monitoring service or a user report shows a different result, the Customer may send us its evidence and we will review it in good faith and tell the Customer the outcome, but our records remain the determinative measure.

4.4 Downtime is measured in whole minutes. A period of unavailability of less than one full minute is not counted.

4.5 Where only some Core Functions are unavailable and a Platform otherwise remains usable, we measure Downtime for the affected Core Functions and, in calculating the Monthly Uptime Percentage, may apportion it by reference to the proportion of the Customer’s Authorised Users materially affected.

4.6 Periods excluded under section 5 are removed from Downtime Minutes but are not removed from Total Minutes.

4.7 For illustration only, in a 30-day month (43,200 minutes), a Monthly Uptime Percentage of 99.5% permits 216 minutes of Downtime. In a 31-day month (44,640 minutes) it permits 223 minutes.

5. Exclusions

5.1 The following are not counted as Downtime and are not taken into account in assessing whether the Uptime Target has been met:

1. Maintenance of any kind, including Emergency Maintenance, whether or not notice was given (section 8);

2. Customer-caused unavailability, including:

3. an act or omission of the Customer or an Authorised User, including a misconfiguration, an incorrect permission setting, a deleted record, or a change made by the Customer’s administrator;

2. the Customer’s configuration of a Platform, including its workflow, form, role, integration, data import and automation settings;

3. the Customer’s own equipment, devices, operating systems, browsers, local network, wireless network, firewall, proxy, content filter, VPN, DNS or internet connection;

4. the Customer’s identity provider, single sign-on service or directory service failing or being misconfigured;

5. the Customer exceeding a rate limit, storage limit or fair use threshold under the Acceptable Use Policy, or generating a load materially beyond the volume reasonably expected for its plan;

6. custom code, scripts, plug-ins, application programming interface clients or integrations built by or for the Customer;

7. the Customer’s failure to apply a change, upgrade or configuration step that we notified as necessary, within the notified period;

8. the Customer’s use of a Platform other than in accordance with the Documentation or the Master Terms and Conditions; or

9. an act or omission of a person to whom the Customer gave access, including a contractor, reseller, implementation partner or other agent of the Customer;

10. Third-party integrations the Customer enabled, including SMOWL proctoring, Zapier automation, payment gateways, single sign-on providers, learning content providers, and any other third-party product or service the Customer has connected. Where a Customer enables an integration, it contracts with that provider directly; the availability and performance of that provider’s service is outside this SLA and is not counted as Downtime, even where the failure of that service prevents the Customer from completing a task in a Platform;

11. Force majeure, meaning an event beyond our reasonable control, including natural disaster, severe weather, fire, flood, earthquake, epidemic, pandemic, war, terrorism, sabotage, civil unrest, industrial action not involving our own workforce, government or regulatory action, failure or interruption of a public telecommunications network or electricity supply, a widespread internet routing or domain name system failure, and an outage or degradation of an underlying cloud infrastructure, hosting, network or security provider;

5. a distributed denial-of-service attack, intrusion attempt, malware, ransomware or other malicious act directed at the Platforms, our infrastructure, our personnel or our upstream providers;

6. suspension of the Customer’s access under the Master Terms and Conditions or the Acceptable Use Policy, including suspension for non-payment under clause 26.1 of those Terms, suspension for breach of the Acceptable Use Policy, and suspension to protect security or safety;

7. unavailability of a feature that the Customer has disabled, has not purchased, is not entitled to use, or has not configured;

8. unavailability or malfunction of a beta, preview, pilot, sandbox, test or early-access environment or feature, and of any feature made available at no charge;

9. degraded performance that does not prevent a Core Function from being used, including slower than usual response times, delayed report generation, and delays in queued or batch processing;

10. a period during which we suspended, restricted or withdrew a Platform or a feature because we were required to do so by law, by a competent authority, or by a third party whose rights or licence terms required it;

11. time spent restoring, migrating, exporting or importing data at the Customer’s request;

12. unavailability arising from an instruction, request or approval given by the Customer; and

13. any unavailability arising from a cause that we could not reasonably have prevented, foreseen or avoided using the controls described in the Security Statement and the practices ordinarily applied by a provider of comparable services.

5.2 If a period of unavailability has more than one cause and at least one of them is excluded under clause 5.1, we will count as Downtime only the part of the period attributable to a cause that is not excluded, where that part can reasonably be identified. Where it cannot reasonably be identified, the period is excluded.

6. Remedy where the Uptime Target is not met

6.1 What the Customer receives. Where the Monthly Uptime Percentage for a Platform in a calendar month is below the Uptime Target, an Enterprise Customer may make a written request to clientservice@classe365.com with the subject line “SLA Availability Review”, identifying the Platform and the calendar month. On receiving that request we will provide the Customer, in writing:

1. a written incident summary — what happened, when it started, when it was resolved, which Core Functions were affected, and the Monthly Uptime Percentage recorded by our monitoring for that month;

2. a root cause analysis — the cause of the incident as we understand it after investigation, and any exclusions under section 5 that we applied; and

3. a remediation plan — the corrective and preventive steps we have taken or intend to take to reduce the likelihood or the impact of a recurrence, and the timeframe we are working to.

6.2 How to request it. The request must be received by us within 30 days after the end of the calendar month concerned. A request received after that period will not be actioned. We will acknowledge the request and aim to provide the material in clause 6.1 within 30 days of receiving it. Where an investigation is still open, we will provide what we have and complete the analysis when the investigation concludes.

6.3 Sole and exclusive remedy. The material provided under clause 6.1 is the sole and exclusive remedy available to the Customer for a failure to meet the Uptime Target, and is in place of all other rights and remedies in respect of that failure, whether in contract, tort (including negligence), under statute or otherwise.

6.4 No financial remedy. A failure to meet the Uptime Target does not give rise to any financial remedy. No refund, rebate, discount, waiver or reduction of Fees, damages, compensation or set-off is payable, and the Customer must not withhold, reduce or set off any Fees on account of availability. Fees remain payable in full for the month concerned.

6.5 No termination right. A failure to meet the Uptime Target does not give the Customer a right to terminate a subscription, an Order or the Master Terms and Conditions, and does not shorten a Subscription Term. The Customer’s cancellation and termination rights are those set out in the Master Terms and Conditions and are unaffected by this SLA.

6.6 Confidentiality. An incident summary, root cause analysis and remediation plan provided under clause 6.1 is our confidential information and is provided for the Customer’s internal use. The Customer may share it with its own regulators, auditors and professional advisers where required, on a confidential basis.

6.7 Non-excludable rights. Nothing in this section 6 excludes, restricts or modifies any guarantee, warranty, right or remedy that cannot lawfully be excluded, restricted or modified, including under the Australian Consumer Law where it applies. Where we are permitted to limit our liability for a breach of such a guarantee, our liability is limited as set out in the Master Terms and Conditions.

7. Support

7.1 Support is available to all customers by email at clientservice@classe365.com and through the in-platform support channel. Enterprise customers additionally receive the support arrangements recorded in their order form.

7.2 Where an order form records a support response target for an Enterprise Customer, that target applies and is contractually binding on us. Where no support response target is recorded, we prioritise and respond to requests as set out in clauses 7.3 and 7.4, and we do not give a contractual response time. We say this plainly so that no Customer relies on a response commitment we have not made.

7.3 We triage support requests by severity:

7.4 Severity is assessed by us, acting reasonably, based on the effect described by the Customer. If the Customer disagrees with the severity assigned, it should say so in the ticket and we will reassess it.

7.5 The Customer must give us the information we reasonably need to investigate — including the account, the users affected, the time the issue started, the steps to reproduce it, and any error message — and must respond to our requests for further information. Where the Customer does not, we may pause work on the ticket and will say so.

7.6 Support is provided in English.

7.7 Accessibility. Our accessibility target for the Platforms is WCAG 2.2 Level AA, and the Platforms are currently partially conformant with that standard. We aim to respond to accessibility feedback within 1 Business Day. Accessibility feedback may be sent to clientservice@classe365.com or made by telephone on +61 2 9472 5000.

7.8 Support is provided by us and by our group affiliate Classe365 India Pvt Ltd (37, Venjay Edifice Complex, 3rd Floor, JLB Road, Chamarajapuram, Mysuru – 570 005, India), whose personnel 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. Support correspondence is retained for 24 months from resolution.

8. Maintenance

8.1 We maintain the Platforms so that they remain secure, stable and current. Some Maintenance requires a Platform, or parts of it, to be unavailable.

8.2 We may carry out Maintenance at any time. This SLA does not fix a maintenance window, a maximum duration for Maintenance, a maximum amount of Maintenance in any period, or a minimum notice period, and the Customer should not plan on the basis that any of those exist.

8.3 How we approach scheduling. We aim to schedule Maintenance that is expected to make a Core Function unavailable outside peak usage hours for the majority of affected customers, and to keep the period of unavailability as short as is practical. The Platforms are used in more than 100 countries and across many time zones, so Maintenance scheduled outside peak hours for most customers will fall inside working hours for some. These are operational aims, not contractual commitments, and they do not create a right for any Customer to have Maintenance scheduled at a particular time.

8.4 Notice. Where Maintenance is expected to make a Core Function unavailable, we aim to give reasonable advance notice where it is practicable to do so, by email to the account’s nominated technical or administrative contact, by an in-platform notice, or both. What is reasonable and practicable depends on the nature and urgency of the work. No specific notice period applies.

8.5 Emergency Maintenance. We may carry out Emergency Maintenance at any time and without notice where it is necessary to preserve the security, integrity or stability of the Platforms, to apply a security patch, to mitigate an active attack, or to prevent data loss. We will give whatever notice is reasonably practicable in the circumstances, will keep the period of unavailability as short as we reasonably can, and will tell affected Customers afterwards what was done and why.

8.6 Maintenance is not Downtime. No period of Maintenance, including Emergency Maintenance and Maintenance carried out without notice, counts as Downtime or is taken into account in assessing whether the Uptime Target has been met.

8.7 Maintenance that can be carried out without making a Core Function unavailable may be carried out at any time without notice.

8.8 Enterprise private cloud deployments. Where an Enterprise Customer has a private cloud deployment on Amazon Web Services, Microsoft Azure or Google Cloud, we will discuss maintenance scheduling for that deployment with the Customer and will follow any arrangement recorded in the Order. The rest of this section 8 continues to apply.

8.9 Backups and restoration. We take daily backups. Each daily backup is retained for 7 days, giving a rolling 7-day restore window, and Customers may request restoration from any of the preceding 7 days. Restoration requests should be sent to clientservice@classe365.com. A restoration overwrites current data with the data as it stood at the time of the backup, so the Customer must confirm the request in writing before we proceed. Time spent restoring data at the Customer’s request is not Downtime.

9. Incident communication and breach notification

9.1 Incident communication. During an incident that materially affects the availability of a Core Function, we will notify affected Customers and will provide updates until the incident is resolved. After a Critical incident, we will provide affected Enterprise customers, on request, with a written summary of what happened, the cause as we understand it, and what we are doing to reduce the chance of it happening again.

9.2 Breach notification — 24 hours. Where we become aware of a personal data breach affecting a Customer’s data, we will notify that Customer within 24 hours of becoming aware of it. The notification will include the information reasonably available to us at that time — what we know about the nature of the breach, the categories and approximate volume of data affected, the likely consequences, and the steps we are taking — and we will provide further information as the investigation progresses. This commitment is set out in the Security Statement and in clause 12.8 of the Master Terms and Conditions, and is repeated here so that it appears in the operational commitments the Customer relies on. Where the Personal Data Processing Agreement applies to the Customer, it governs the parties’ respective obligations following a breach.

9.3 A security incident, and any notification given under clause 9.2, does not by itself constitute Downtime. Where a security incident also makes a Core Function unavailable, that unavailability is assessed under sections 4 and 5 in the usual way.

9.4 The security controls that support this SLA — including hosting on Amazon Web Services infrastructure, encryption of data in transit using TLS, encryption of data at rest, network segregation, least-privilege access control, an OWASP-aligned secure development lifecycle, daily backups, distributed denial-of-service protection and monitoring — are described in the Security Statement. A SOC 2 Type II audit is in progress and is expected to be completed in December 2026; we do not hold a SOC 2 Type II report at the date of this SLA, and we do not hold an ISO 27001 certification.

10. General

10.1 Limitation of liability. This SLA is subject to the limitation of liability in the Master Terms and Conditions, including the exclusion of indirect and consequential loss and the cap on aggregate liability. Nothing in this SLA increases, extends or varies that limitation, and no obligation in this SLA is to be read as an acceptance of liability beyond it.

10.2 Changes to this SLA. We may update this SLA from time to time. The version of this SLA published on our website at the relevant time is the version that applies, and it replaces all earlier versions. Each version carries a “Last updated” date and an “Effective” date. Changes are notified in accordance with clause 28 of the Master Terms and Conditions. Continued use of a Platform after the effective date of a change means the updated SLA applies.

10.3 No implied commitment. Nothing in this SLA, in our marketing material, in a proposal, in a response to a tender or request for proposal, or in any statement made by our personnel creates an availability commitment beyond the Uptime Target, creates any availability commitment for a customer on a plan below Enterprise, or creates any financial remedy for availability. If another document appears to suggest otherwise, this clause prevails.

10.4 No third-party rights. This SLA is for the benefit of the Customer only. No Authorised User, student, candidate, parent, employer or other third party may make a claim under it.

10.5 Severability. If a provision of this SLA is held to be unenforceable, it is severed to the minimum extent necessary and the rest of this SLA continues in force.

10.6 Governing law. This SLA is governed by the law that governs the Master Terms and Conditions: the laws of the State of Delaware, United States, for Customers contracting with 365 Software, LLC, and the laws of New South Wales, Australia, for all other Customers.

11. Contact

Availability reviews under section 6, support requests and questions about this SLA: clientservice@classe365.com Accessibility: clientservice@classe365.com or +61 2 9472 5000

365 Software, LLC — 131 Continental Dr, Suite 305, Newark, DE 19713, United States
Sprout On Web Pty Ltd — ABN 72 138 602 418, 22 Palm Street, St Ives, NSW 2075, Australia