Vulnerability Disclosure Policy

Effective from September 11, 2026

Applies to: security researchers and anyone else who discovers a potential security vulnerability in the Classe365 or Hiree365 platforms or in the classe365.com marketing website, and to the customers of those platforms — K-12 schools, universities and colleges, academies and vocational training providers, and corporates using the platform for corporate training — whose data this policy exists to protect.

1. About this policy

1.1 Our position

If you have found a security vulnerability in our systems, we want to hear from you. We would rather learn about a weakness from a researcher who reports it than from an incident.

This policy tells you what you may test, what you must not do, how to report what you find, what we will do in response, and the protection that applies to good-faith research. It is written so that a researcher can act on it without having to guess at our intentions.

1.2 Read this before you test

The systems covered by this policy hold the education records of students, including children. A test that would be harmless against a retail website can expose a child’s record here. Section 4 sets out the rules that matter most, and we ask you to read it before you begin.

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”. This policy is issued by both contracting entities and applies to the systems of each.

Read this policy together with our Security Statement, which describes the controls we operate, our Acceptable Use Policy, our Terms and Conditions and our Privacy Policy.

2. Scope

2.1 In scope

The classe365.com marketing website, including its subdomains operated by us.
The authenticated Classe365 platform as delivered to customers — the student information system, learning management system and CRM.
The authenticated Hiree365 platform as delivered to customers — the campus recruitment and employability platform.
The application programming interfaces we publish for use with those platforms.
The supporting infrastructure operated by us for those services.

If you are unsure whether something is in scope, ask us at clientservice@classe365.com before testing. We would far rather answer that question in advance than deal with its consequences afterwards.

2.2 Out of scope

The following are not in scope, and you must not test them under this policy.

Any customer’s tenant, data or account that is not yours and that you have not been authorised in writing by that customer to test. An institution’s tenant belongs to that institution. Our permission is not theirs to give, and this policy does not grant it.
Third-party services and sub-processors, including Amazon Web Services, Intercom, Atlassian, Stripe, PayPal, Google Analytics, Semrush, Mailchimp and ActiveCampaign. Each runs its own disclosure programme. Report vulnerabilities in their systems to them.
Optional integrations that institutions enable and contract for directly, including SMOWL (online quiz proctoring) and Zapier (customer-configured automation). These are the institution’s contracts with those providers, and their systems are not ours to authorise testing against.
Systems and integrations built or configured by a customer, including a customer’s own integrations, automations, single sign-on configuration, or connected systems.
Enterprise private cloud deployments operated for a specific customer on AWS, Microsoft Azure or Google Cloud, unless that customer has authorised the testing in writing and we have confirmed it.
Our physical premises, our staff, our contractors and our suppliers. Social engineering of any kind is out of scope and is prohibited by section 4.
Our corporate systems, including email, and any system not used to deliver the services listed in section 2.1.

2.3 Findings we generally do not treat as vulnerabilities

We will read every report, but the following are unlikely to be treated as vulnerabilities unless you can demonstrate a realistic exploitation path, and we ask you to include that demonstration if you report one:

Missing security headers with no demonstrated impact.
Reports produced solely by an automated scanner, with no verification and no working proof of concept.
Weaknesses that require a fully compromised device, a rooted or jailbroken device, or a physically present attacker.
Self-inflicted issues that require a user to paste an attacker’s code into their own browser console.
Vulnerabilities in outdated browsers or software versions we do not support.
Missing rate limiting with no demonstrated impact.
Reports about email configuration with no demonstrated exploitation.
Content spoofing or text injection with no demonstrated security consequence.
Publicly disclosed vulnerabilities in third-party software, within a reasonable period for us to apply the vendor’s fix.
The absence of a feature you consider a best practice, where there is no demonstrated weakness.

Behaviour that is functioning as designed is not a vulnerability, but if you think a design is unsafe, tell us anyway — we would rather have that conversation than not.

3. Safe harbour for good-faith research

3.1 What we commit to

Where you conduct security research in accordance with this policy, we will treat it as authorised, and:

we will not pursue civil action against you in relation to that research;
we will not report you to law enforcement in relation to that research, and will not support a prosecution arising from it;
we will not treat your activity as a breach of our Terms and Conditions or Acceptable Use Policy; and
if a third party brings a claim against you in relation to research you carried out in accordance with this policy, we will make it known that your activity was authorised by us.

3.2 What “in accordance with this policy” requires

The safe harbour applies where you:

stay within scope (section 2);
comply with every prohibition in section 4;
act in good faith, without intent to harm us, our customers, or any student, learner or candidate;
stop as soon as you have demonstrated a vulnerability, rather than continuing to explore it;
do not access, copy, modify, retain or disclose any data that is not yours;
report promptly through section 5; and
observe the coordinated disclosure timeline in section 7.

3.3 What the safe harbour does not cover

It does not cover activity outside this policy: testing an out-of-scope system, exfiltrating data, denial of service, social engineering, accessing another user’s records, extortion, or research conducted for a purpose other than reporting a vulnerability to us.

We cannot waive the rights of third parties. The safe harbour is given by us. It cannot bind our customers, our sub-processors, or any other party whose systems or data you touch, and it cannot displace the criminal law of any jurisdiction. That is a real limit, and we state it rather than implying a protection we are not able to give.

3.4 If you are unsure

If you are partway through and unsure whether what you are about to do is within this policy, stop and ask us at clientservice@classe365.com. Asking first will never count against you. We would much rather receive a question than a report describing something we wish had not happened.

4. What researchers must not do

These prohibitions are absolute. Breaching any of them takes your activity outside this policy and outside the safe harbour.

4.1 Do not exfiltrate data

Do not download, copy, transfer, retain or disclose any data that is not yours. If a vulnerability gives you access to data, stop immediately. Record only what is necessary to demonstrate the vulnerability — a screenshot showing a single redacted record, or the count of records the flaw exposed — and nothing more.

If you have inadvertently obtained data that is not yours, tell us in your report, do not disclose it to anyone, and delete it when we confirm you may.

4.2 Do not perform denial of service

Do not carry out denial-of-service or distributed denial-of-service testing, load testing, stress testing, resource exhaustion testing, or any activity intended or likely to degrade the availability of the service. Schools depend on the platform on a school day, and taking it down does not demonstrate anything we could not have been told.

Do not attempt social engineering of any kind against our staff, our contractors, our suppliers, our customers, or their staff or students. This includes phishing, pretexting, vishing, baiting, physical intrusion and any attempt to obtain credentials from a person. Testing people is not authorised under this policy in any circumstances.

4.4 Do not access other users’ data

Do not access, or attempt to access, the account, tenant, records or data of any other user, customer, student, learner or candidate. Where a vulnerability could give you such access, demonstrate it with your own test accounts, or stop at the point at which the access is proven and report it without exercising it.

4.5 Do not test on production student data

Do not conduct testing against live customer tenants or production student, learner or candidate data. Use accounts and data that are your own. If you are a member of staff at a customer institution, you must have your institution’s written authorisation before testing anything, and you must not test against records belonging to real students.

4.6 Do not do any of the following

Do not modify, corrupt or delete data.
Do not create a persistent backdoor, implant or account to maintain access.
Do not pivot into other systems or networks from a foothold you obtain.
Do not use automated scanning at a volume or intensity likely to affect service performance.
Do not attempt to intercept the traffic of other users.
Do not use a vulnerability to extract further information beyond what is needed to prove it exists.
Do not demand payment, and do not attach conditions to disclosure. A report withheld pending payment is extortion, is not covered by the safe harbour, and will be treated accordingly. See section 8 on our position on bounties.
Do not publish before the coordinated disclosure timeline in section 7 has run.
Do not violate any law, or the privacy of any person, in the course of your research.

5. How to report

5.1 Where to send it

Send your report to clientservice@classe365.com with “Security vulnerability report” at the start of the subject line, so that it is routed to our security process rather than handled as a general support enquiry.

5.2 What to include

The more of the following you can give us, the faster we can validate and fix the issue:

A clear summary of the vulnerability in one or two sentences.
The affected system — which platform, which domain, which endpoint or screen.
The vulnerability type — for example broken access control, injection, authentication weakness, insecure direct object reference.
Reproduction steps, numbered and complete enough for our engineers to follow without guessing.
A proof of concept — a request, a script, a screenshot or a short video. Redact any data that is not yours.
The impact — what an attacker could actually do, and to whom. This is the part that most often determines how quickly a fix is prioritised.
The date and time of your testing, with a time zone, and the source IP addresses you tested from, so we can match your activity in our logs and distinguish it from a real attack.
Any accounts you created or used during testing.
How you would like to be credited, if you would like recognition under section 9.
How to reach you, and whether you are happy for us to contact you for clarification.

5.3 Language and format

Write in English. Plain email is fine — there is no form to complete and no portal to register with. One clear report is worth more than a scanner export.

5.4 One report per issue

Please send one report per vulnerability. Where several findings share a single root cause, say so and describe them together.

5.5 If you have obtained data

If your research has resulted in you holding data that is not yours, say so in the first paragraph of your report. Do not attach it. We will tell you how to handle it, and we will not treat a candid disclosure of this kind as a breach of this policy.

6. What we will do

6.1 Acknowledgement

We will acknowledge your report within 2 business days of receiving it. The acknowledgement confirms we have it and gives you a reference to use in further correspondence.

6.2 Initial assessment

We will complete an initial assessment within 5 business days of acknowledgement, and tell you whether we have been able to reproduce the issue, whether we consider it a vulnerability, and how we have assessed its severity. If we cannot reproduce it, we will say what we tried, so that you can tell us what we missed rather than being left with a bare rejection.

6.3 Progress updates

We will update you at least every 14 days while the issue is open, until it is resolved or we agree with you that no further action is needed. You do not need to chase us for these updates, and you are welcome to ask for one at any time.

6.4 Remediation

We prioritise remediation by severity and exploitability. A vulnerability that exposes student, learner or candidate data, or that permits access across tenants, receives the highest priority and is treated as an incident, not a backlog item. We will tell you when a fix is deployed, and you are welcome to verify it — within the same rules that governed your original testing.

6.5 Where customer data has been affected

If our investigation shows that a vulnerability has resulted in unauthorised access to customer data, our incident process applies, including our commitment to notify affected customers within 24 hours of becoming aware of a personal data breach. Our Security Statement sets out that process.

6.6 What we will not do

We will not take action against you for a good-faith report made in accordance with this policy, and we will not tell you a real issue is not a real issue in order to close a report. If we disagree with your assessment, we will explain why.

7. Coordinated disclosure

7.1 The timeline

We ask you to keep the vulnerability confidential until the earlier of:

the date we confirm a fix has been deployed; or
90 days from the date we acknowledge your report.

After that point you are free to publish. We ask that you tell us before you do, so that we can prepare, and that you give us the opportunity to review your write-up for anything that would identify a customer or expose data.

7.2 Extensions

Some fixes take longer than 90 days — a change deep in a data model, or one that requires coordinated action by customers. If we need more time, we will ask you before the 90 days expire, explain why, and tell you what remains. We will not ask repeatedly to avoid publication, and we will not treat a refusal as a breach of this policy.

7.3 What to leave out of a publication

Whenever you publish, please do not include: any customer, student, learner or candidate data; anything that identifies a specific institution; or a working exploit against a vulnerability that has not been fixed. Describe the class of issue and the impact rather than handing a reader an exploit.

7.4 Active exploitation

If you find evidence that a vulnerability is already being exploited, tell us immediately and say so in the subject line. We will treat it as an active incident and respond accordingly, and the ordinary timelines in section 6 give way to that response.

8. We do not operate a paid bounty programme

We do not currently operate a paid bug bounty programme, and we do not offer monetary rewards for vulnerability reports.

We state this at the outset so that no researcher spends time on our systems in the expectation of a payment. It is not a reflection of how seriously we take reports — reports are triaged, investigated and fixed under the commitments in section 6 whether or not anyone is paid for them.

Do not attach payment demands or conditions to a disclosure. A report withheld pending payment falls outside this policy and outside the safe harbour in section 3.

If we introduce a paid programme in future, we will say so in this policy.

9. Recognition

What we can offer is credit, and we offer it gladly.

If you report a valid vulnerability and would like to be recognised, tell us in your report how you would like to be named. Once the issue is resolved, we will:

acknowledge your contribution by name, handle or organisation, as you prefer;
confirm in writing what you reported and when — a letter you can use with an employer, a client or a certification body; and
name you in any public advisory or write-up we publish about the issue, where you want to be named.

You may also choose to remain anonymous, and we will respect that. We will not name you without your agreement.

10. If you are a customer rather than a researcher

If you are an administrator at a customer institution and you have noticed something that looks like a security weakness, you do not need to conduct research or follow the testing rules in this policy. Simply write to clientservice@classe365.com, describe what you saw and where, and we will investigate.

If you believe your institution’s data has already been affected by a security incident, say so in the first line of your message so that it is triaged as an incident immediately.

11. Changes to this policy

We review this policy at least annually, and whenever our scope, our process or our disclosure practice changes.

Where a change materially affects researchers — a change to scope, to the safe harbour, or to the disclosure timeline — we will publish the updated policy on classe365.com. A report made under an earlier version of this policy is assessed under the version in force when it was submitted, so that no researcher is disadvantaged by a change made after they acted.

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

Vulnerability reports: clientservice@classe365.com — subject line beginning “Security vulnerability report” Scope questions before testing: clientservice@classe365.com Suspected security incident affecting your data: 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

Thank you for taking the time to report responsibly. The people whose records are protected by the work you do are, in most cases, students — and often children — who will never know you did it.

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.