Vulnerability Disclosure Policy

Version 1.0 · Last updated: 21 September 2026

We are grateful to the security researchers who take the time to report weaknesses in our products. This policy explains how to reach us, what we commit to in return, and what we ask of you while you are testing.

1. How to report

Email [email protected]. A machine-readable contact is published at /.well-known/security.txt in line with RFC 9116.

Please include enough detail for us to reproduce the issue:

  • The product, URL or endpoint affected
  • A description of the weakness and its likely impact
  • Steps to reproduce, including any proof-of-concept request or payload
  • The date and time of your testing, and the source IP address you tested from
  • How you would like to be credited, if at all

You may report anonymously. We accept reports in English.

2. What we commit to

  • Acknowledgement within two business days of your report reaching the mailbox.
  • A triage decision within five business days, telling you our assessed severity and whether we are treating the report as in scope.
  • Remediation of High and Critical issues within 14 days of triage. Medium and Low issues are scheduled into our normal release cycle, and we will tell you the target.
  • Progress updates at least every 14 days until the issue is resolved or we agree with you that it is closed.
  • Credit where you want it. We will name you when we publish a fix, or keep you anonymous, entirely as you prefer.
  • No legal action against researchers who follow this policy. See section 5.

Where a reported vulnerability involves personal data we process on a client's behalf, your report starts our controller notification clock: we notify affected controllers within 24 hours of becoming aware.

3. Scope

In scope: any internet-facing service operated by Exyon Ltd, including our website, ExyonID, ExyonLearn, ExyonPulse, ExyonPanel, ExyonSupport and HRoix, together with the infrastructure that serves them.

Out of scope:

  • Systems operated by our sub-processors — please report those to the provider directly
  • Findings from automated scanners without a demonstrated exploitable impact
  • Missing security headers, cookie flags or TLS configuration with no demonstrated impact
  • Rate limiting or brute force on endpoints without authentication impact
  • Social engineering, phishing, or physical attacks against our staff or offices
  • Denial of service, volumetric testing, and any test that degrades service for others
  • Reports of outdated software versions without a working exploit path

4. What we ask of you

  • Give us a reasonable opportunity to fix the issue before disclosing it publicly. We aim to agree a disclosure date with you, and we default to 90 days from triage.
  • Use only your own test accounts. Do not access, modify, download or retain data belonging to anyone else, and stop as soon as you have established that access is possible.
  • If you do encounter personal data, stop testing, do not retain a copy, and tell us in your report.
  • Do not degrade, disrupt or interrupt our services or our clients' use of them.
  • Do not use the finding to extract further access, and do not leave a persistent backdoor.
  • Comply with applicable law, including the Computer Misuse Act 1990.

5. Safe harbour

If you make a good-faith effort to comply with this policy during your research, we will consider your research to be authorised, we will work with you to understand and resolve the issue quickly, and we will not pursue or support any civil or criminal action against you in connection with it. If a third party brings legal action against you in relation to research you conducted under this policy, we will make it known that your actions were authorised.

If at any point you are unsure whether an action is consistent with this policy, ask us first at [email protected]. We would much rather answer a question than receive a report of testing that went further than we could authorise.

6. Rewards

We do not operate a paid bug bounty programme. We offer public credit and our thanks.

7. Review

This policy is reviewed annually, together with the Expires field of our security.txt, which must be kept current.

For our security controls, data residency and sub-processor register, see Trust & Security. For contractual data protection terms, see our Data Processing Agreement.