Security Statement

Effective from September 11, 2026

Applies to: the Classe365 and Hiree365 platforms and the systems that support them, for all customer segments — K-12 schools, universities and colleges, academies and vocational training providers, and corporates using the platform for corporate training — and to the security reviewers, procurement teams, data protection officers and administrators who need to assess us.

1. About this statement

1.1 What this document is

This is our public security statement. It describes the controls we actually operate, the certifications we do and do not hold, who can access customer data, what we commit to when something goes wrong, and how to get more detail.

It is written for the person doing the assessment. It states what is true and stops there. Where we do not have something, we say we do not have it, rather than describing an aspiration in the present tense.

1.2 Which platforms it covers

Classe365 — our student information system, learning management system and CRM for education institutions.
Hiree365 — our campus recruitment and employability platform.

Both are operated by the same group and run on the same infrastructure and under the same controls.

1.3 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”.

Read this statement together with our Privacy Policy, our Children’s Privacy Policy, our Data Retention Schedule, our Sub-processor List, our AI Use and Transparency Statement, our Vulnerability Disclosure Policy and our Service Level Agreement. 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.

2. Certification status — stated plainly

2.1 SOC 2 Type II

Our SOC 2 Type II audit is in progress, with expected completion in December 2026.

We do not currently hold a SOC 2 Type II report, and we do not claim SOC 2 certification. Until the audit completes, any assessment of us should be based on the controls described in this document rather than on an attestation we do not yet have.

When the report is available, we will make it available to customers and prospective customers under the usual confidentiality arrangements, and we will update this statement.

2.2 ISO 27001

We do not hold an ISO 27001 certification, and we do not claim one.

2.3 Why we state it this way

Security claims are easy to imply and hard to withdraw. A reviewer who takes an unqualified statement at face value and later discovers a gap has been misled, whatever the wording technically allowed. We would rather be assessed accurately now than be trusted on a misunderstanding.

Classe365 and Hiree365 do not hold a SOC 2 Type II report or an ISO 27001 certification at the date of this statement. If you receive any representation to the contrary, please report it to clientservice@classe365.com.

3. Infrastructure and hosting

3.1 Amazon Web Services

The platform runs on Amazon Web Services. We use AWS infrastructure for compute, storage, databases and backups, and we build our controls on top of the physical and environmental security AWS provides for its data centres.

3.2 Where data is held

Standard customers are hosted 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.

An institution with a data location requirement should raise it before contracting, so the right arrangement is in place from the start rather than requiring a migration later.

3.3 Network segregation

The platform environment is segregated at the network level. Environments are separated from one another, and access between network segments is restricted to what the service requires. The public marketing website and the authenticated platform are separate environments, and the analytics and marketing technologies that run on the marketing website do not operate inside the platform where student, learner and candidate records live. Our Cookie Policy and Sub-processor List describe that separation from the privacy side.

3.4 DDoS protection

DDoS protection is in place at the network edge to absorb and mitigate distributed denial-of-service traffic before it reaches the application.

4. Encryption

4.1 In transit

Traffic to and from the platform is encrypted in transit using TLS. This applies to browser sessions, API traffic and the connections between the components of the service. Users connect over HTTPS.

4.2 At rest

Customer data is encrypted at rest, including data held in the platform’s storage and databases and the daily backups described in section 6.

4.3 Payment card data

We do not store full payment card numbers. Payments are processed by Stripe and PayPal, identified in our Sub-processor List, and card data is handled by those providers under their own security controls and obligations as payment providers.

5. Access control

5.1 Least privilege

Access to customer data is granted on a least-privilege basis. Personnel receive the access their role requires to do their work and no more. Administrative access to production systems is restricted to the personnel who need it.

5.2 Within a customer’s tenant

Institutions control who in their organisation can see what. Roles and permissions are configured by the institution’s administrators, and the institution decides which staff can access which records and which features. Several of the controls described in our AI Use and Transparency Statement — restricting sensitive analytics such as attrition indicators to designated staff — are exercised through these permissions.

Institutions should review their own role assignments periodically. A great deal of practical security in a student information system is decided by who inside the institution holds an administrator account.

5.3 Separation between customers

Each customer’s data is held in its own tenant, and access is scoped to that tenant. This separation also underpins our AI commitment: 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, and data is never pooled across customers.

5.4 Our own access

Our personnel access customer data only where it is needed to provide, support, maintain or secure the service, or where the institution has asked us to. We do not browse customer records, and we do not use customer data for our own purposes. Administrative actions in the platform are logged, and those logs are retained for 30 days under our Data Retention Schedule.

6. Backups and restoration

We take daily backups. Each daily backup is retained for 7 days, giving a rolling 7-day restore window.

Customers may request restoration from any of the preceding 7 days. Contact clientservice@classe365.com.
Backups are maintained for the life of an active subscription.
Backups are encrypted at rest.
A deleted record therefore persists in backups for no more than 7 days. When an institution deletes a student or candidate record, it is permanently deleted after 7 days, and the backups still containing it age out of the window within the same period.
On termination, backups are deleted together with all other customer data within 30 days. Termination leaves no backup behind.

The 7-day window is a deliberate balance: long enough that a mistaken deletion or a data corruption discovered within the week can be recovered, and short enough that a record an institution has deleted does not survive anywhere for long. Our Data Retention Schedule sets out the full position.

7. Secure development

7.1 OWASP-aligned secure development lifecycle

We operate an OWASP-aligned secure development lifecycle. Security considerations are built into how changes are designed, written, reviewed and released, rather than being applied after the fact. The OWASP guidance on common web application vulnerability classes — injection, broken access control, authentication and session weaknesses, insecure configuration and the rest — informs how the platform is built and how changes are reviewed before release.

7.2 Change management

Changes are reviewed before release. Changes that affect authentication, authorisation, tenant separation or the handling of personal data receive particular attention, because those are the areas where a defect has the widest consequences.

7.3 AI features

AI features are part of the platform and are covered by the same development, review and security controls. New AI features and material changes to existing ones are reviewed before release against the commitments in our AI Use and Transparency Statement, including the commitment that customer, student and candidate data is never used to train, fine-tune or improve any general-purpose or shared AI model.

8. Monitoring and logging

We monitor the platform and its infrastructure, covering availability, performance and security events.

Server and security logs record access and authentication events, application and error events, security events and administrative actions. They can include IP addresses, user or account identifiers, timestamps and the action performed.

Logs are retained for 30 days under our Data Retention Schedule, except where a specific entry forms part of an active security investigation or is subject to a legal hold, in which case it is preserved for the duration of that investigation or hold. Logs are used for security, integrity and reliability, and are not used to analyse individual user behaviour for any other purpose.

The 30-day window supports the investigation of reported incidents and our 24-hour breach notification commitment in section 10.

9. Written children’s information security program

9.1 That we maintain one

We maintain a written children’s information security program. It is a documented programme, not a set of general practices described after the event, and it exists because children’s personal information held by a school deserves specific and demonstrable protection.

9.2 What it contains

A designated coordinator. A named individual is responsible for the programme.
An annual risk assessment. We assess the internal and external risks to the confidentiality, security and integrity of children’s personal information at least annually.
Safeguards. We maintain safeguards designed to address the risks identified — the technical controls described in this statement, together with the access, retention and disclosure controls described in our Data Retention Schedule, our Sub-processor List and our Children’s Privacy Policy.
Sub-processor due diligence. We assess the security and privacy posture of sub-processors that may handle children’s personal information before engaging them, and periodically afterwards. Section 11 describes this.
Annual testing and review. The programme’s safeguards are tested and the programme reviewed at least annually, and adjusted where the review or a material change to our systems or practices requires it.

9.3 The commitments that go with it

We do not sell children’s data.
We do not permit targeted advertising to children and do not build advertising profiles of children.
Children’s data is not used to train, fine-tune or improve any general-purpose or shared AI model.
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. Institutions may choose to enable SMOWL, a third-party proctoring service, which they contract with directly; any biometric processing by SMOWL occurs under SMOWL’s own terms and privacy policy, not ours.
Hiree365 has a minimum age of 16 and is not available to anyone under 16. There are no under-13 users.

9.4 The regulatory background

The programme reflects the requirements of the amended Children’s Online Privacy Protection Rule. The FTC’s COPPA 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. Our Children’s Privacy Policy covers consent, separate consent for optional third-party disclosures, and parental rights; our Data Retention Schedule publishes the retention position the Rule requires to be disclosed.

10. Incident response and breach notification

10.1 The 24-hour commitment

We will notify affected customers within 24 hours of becoming aware of a personal data breach affecting their data.

This is a short window by any standard, and we state it because institutions need to start their own processes quickly. A school may have its own regulator to notify, its own parents to inform, and its own decisions to make, and it cannot begin any of that until it hears from us.

10.2 What we tell you

Our notification will describe, so far as we know it at the time: what happened; when we became aware; the categories of data and the categories of individuals affected; the likely consequences; what we are doing in response; and what we recommend the institution consider doing. Where the full picture is not yet available, we will send what we have within 24 hours rather than waiting for completeness, and follow up as the investigation develops. A late complete notification is worse than a prompt partial one.

10.3 How we respond

Our response covers detection and triage, containment, investigation using the monitoring and logging described in section 8, remediation, notification under section 10.1, and a review afterwards to address the cause. Where a sub-processor is the source of an incident, we invoke the assistance obligations in our contract with it.

10.4 Your obligations and ours

Where the institution is the controller and we are the processor, the decision whether to notify a regulator or affected individuals is the institution’s. Our job is to inform the institution promptly and give it the information it needs to make that decision, and to assist it as our Personal Data Processing Agreement requires.

10.5 Reporting something to us

If you believe there has been a security incident affecting your data, contact clientservice@classe365.com immediately. If you are a security researcher reporting a vulnerability, section 15 and our Vulnerability Disclosure Policy explain how.

11. Sub-processor due diligence

Before engaging a sub-processor, we assess its security and privacy posture, and we reassess periodically while the engagement continues. This due diligence is part of our written children’s information security program.

Every sub-processor is bound by a written contract requiring: data protection obligations no less protective than those we owe our customers; processing only for the purpose we engaged it for and only on our instructions; appropriate technical and organisational security measures; confidentiality obligations binding on its personnel; assistance with data subject requests and with our security and breach obligations; and deletion or return of personal information when we instruct it or when the engagement ends. No sub-processor may use customer, student or candidate data to train, fine-tune or improve any general-purpose or shared AI model, sell it, or use it for advertising.

We keep the list short deliberately. The sub-processors that receive student or candidate data are Amazon Web Services (hosting and storage), Intercom (support messaging), Atlassian (engineering issue tracking and fault diagnosis), Stripe and PayPal (payment processing). Google Analytics, Semrush, Mailchimp and ActiveCampaign operate on the classe365.com marketing website only and never receive student or candidate records. Our Sub-processor List sets out the full position, including the optional integrations — SMOWL and Zapier — that institutions enable and contract for directly.

12. Access from India

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.

We disclose this directly, near the front of the document rather than in a footnote, because it is exactly the kind of fact a security reviewer must have and is too often buried.

That access is subject to:

access controls — least-privilege access as described in section 5, granted for the purpose and no wider;
contractual confidentiality obligations binding on the entity and on its personnel; and
intra-group data transfer agreements governing the transfer of personal data within the group.

The same monitoring and logging described in section 8 applies to this access, and administrative actions are logged in the same way. Classe365 India Pvt Ltd is a group affiliate rather than a third-party sub-processor, and appears in its own section of our Sub-processor List. Where a transfer of personal data to India requires a transfer mechanism, the mechanisms in our Personal Data Processing Agreement and on our International Data Transfers page govern.

An institution with a specific requirement about support access should raise it with us at clientservice@classe365.com before contracting. We will tell you plainly what we can and cannot accommodate.

13. Business continuity and disaster recovery

13.1 Our approach

Continuity rests on the infrastructure and backup controls already described: AWS infrastructure, network segregation, DDoS protection at the edge, monitoring that detects failure, and daily backups with a rolling 7-day restore window.

13.2 Recovery from data loss or corruption

Where data is lost or corrupted — through a system fault, a mistaken deletion or a security incident — recovery is by restoration from backup. Customers may request restoration from any of the preceding 7 days by contacting clientservice@classe365.com. Restoring from a backup restores the state of the data at the time that backup was taken.

13.3 Availability

Enterprise customers have a 99.5% monthly uptime service level. Our Service Level Agreement sets out how it is measured and what happens if it is not met. Below the Enterprise tier there is no contractual uptime commitment. We say so here because a security review usually asks the availability question, and the honest answer for a non-Enterprise customer is that availability is a commitment we make in the Enterprise agreement and not elsewhere.

13.4 Incidents affecting availability

Where an incident affects availability, we work to restore service and keep affected customers informed. Where the incident also involves personal data, the notification commitment in section 10.1 applies in addition.

13.5 Continuity of the business

The platform is operated by a group, and support and engineering capability is deliberately not held in a single location — the arrangement described in section 12 also means engineering and support capability exists in more than one place and time zone.

14. What we ask of institutions

Security in a student information system is shared, and some of the most consequential controls are the institution’s, not ours.

Manage administrator accounts carefully. An administrator account can see and change a great deal. Grant it sparingly, review it termly, and remove it promptly when someone changes role or leaves.
Remove accounts when people leave. Departing staff accounts are the most common route to unauthorised access in any organisation.
Use the roles and permissions available. Configure who can see sensitive records and analytics rather than granting broad access by default.
Keep student data out of support tickets where a reference will do. Support correspondence is retained for 24 months from resolution — longer than a deleted student record.
Govern your integrations. Where you connect the platform to another system — through Zapier or your own integration — you control what leaves the platform and where it goes.
Review what you enable. Optional third-party services, including proctoring, are your choice and your contract.
Tell us quickly. If you suspect an incident, a compromised account or a vulnerability, contact us immediately.

15. Reporting a security concern

If you are a security researcher and you have found a vulnerability, please report it under our Vulnerability Disclosure Policy. That policy sets out what is in scope, the safe harbour that applies to good-faith research, what researchers must not do, how to report, and our acknowledgement and response commitments. Please read it before testing.

If you are a customer and you believe your data has been affected by a security incident, contact clientservice@classe365.com immediately and say so in the first line of your message, so that it is triaged as an incident rather than a support question.

We do not take action against anyone who reports a genuine security concern to us in good faith.

16. Requesting further detail

Security reviews often need more than a public document provides. Write to clientservice@classe365.com and tell us what you need. We will:

answer specific questions about the controls described here;
complete a reasonable security questionnaire as part of a procurement process;
discuss data location, including hosting in the nearest available AWS region and private cloud deployment for enterprise customers;
discuss the support access arrangement in section 12;
provide our Personal Data Processing Agreement and discuss the arrangements in it; and
make our SOC 2 Type II report available once the audit completes, expected December 2026, under the usual confidentiality arrangements.

Where a request goes beyond what we can share — because it would itself create a security risk, or because it is subject to obligations we owe a third party — we will say so and explain why, rather than leaving the request unanswered.

17. Changes to this statement

We review this statement at least annually, and whenever a material control, certification status or hosting arrangement changes. We will update it when the SOC 2 Type II audit completes.

Where a change materially affects the security commitments made here, 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. Where a change is required urgently to protect the security of the service, we may make it immediately and update this statement as soon as we reasonably can.

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.

18. Contact us

Security questions, questionnaires and requests for further detail: clientservice@classe365.com Suspected security incident affecting your data: clientservice@classe365.com Vulnerability reports: see our Vulnerability Disclosure Policy 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

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.