Responsible vulnerability disclosure
TL;DR — If you have found a security vulnerability in a NexCyber service, we want to hear from you, and we commit to handling your report seriously, promptly, and without legal threat when you act in good faith. This page explains how to report, what to expect, and the rules of the road for coordinated disclosure. It reflects the same coordinated-vulnerability-disclosure discipline we help our own customers build.
Why we publish this
A published disclosure policy is a hallmark of a mature security programme — and, increasingly, a regulatory expectation under frameworks like the CRA. We hold ourselves to the standard we advocate. If you can reach us easily and trust that we will act, everyone's security improves.
Scope
In scope — security vulnerabilities in NexCyber's production services and public-facing surfaces that could affect the confidentiality, integrity, or availability of customer data or the platform.
Out of scope — issues that are not security-relevant, such as:
| ▸ Reportable | ▸ Not a vulnerability |
|---|---|
| Authentication or authorisation flaws | Missing "best practice" headers with no exploit |
| Data exposure between tenants | Self-XSS requiring victim to paste code |
| Injection, SSRF, RCE, and similar | Rate-limiting suggestions with no security impact |
| Cryptographic weaknesses | Reports from automated scanners with no validation |
| Broken access control | Social-engineering of our staff |
If you are unsure whether something qualifies, report it — we would rather triage a non-issue than miss a real one.
How to report
Send your report to the security contact published in our security.txt file (/.well-known/security.txt), which is the canonical, machine-readable source for how to reach us.
A good report includes:
- What — a clear description of the vulnerability
- Where — the affected service, URL, or component
- How — steps to reproduce, ideally with a minimal proof of concept
- Impact — what an attacker could achieve
- Your contact — so we can coordinate
Important: do not include real customer data, live credentials, or private keys in your report. Describe the issue; do not exfiltrate to prove it.
What to expect — the disclosure timeline
You report We acknowledge We triage & We fix & Coordinated
the issue ──▶ receipt ──▶ assess severity ─▶ validate ──▶ disclosure
(promptly) (with you) (with updates) (by agreement)
Day 0 ~1-2 business days days days-weeks* when safe
*Remediation time depends on severity and complexity; we keep you updated throughout.
Our commitments to you:
- ▸ We acknowledge your report promptly.
- ▸ We triage and assess severity, and share our assessment.
- ▸ We keep you updated as we work toward a fix.
- ▸ We credit you, with your permission, once the issue is resolved.
- ▸ We practise coordinated disclosure — we agree timing with you rather than racing to publish or to silence.
Severity, at a glance
We assess severity by real-world impact, not by category label alone:
| Severity | Typical characteristics | Our response posture |
|---|---|---|
| 🔴 Critical | Tenant isolation break, RCE, mass data exposure | Immediate mobilisation, fastest remediation |
| 🟠 High | Significant data exposure, auth bypass | Prioritised remediation |
| 🟡 Medium | Limited exposure, requires conditions | Scheduled remediation |
| ⚪ Low | Minimal impact, defence-in-depth | Addressed in normal cycle |
Safe harbour — acting in good faith
If you make a good-faith effort to comply with this policy during your research, we will:
- ▸ Consider your research authorised and not pursue legal action against you.
- ▸ Work with you to understand and resolve the issue quickly.
- ▸ Recognise your contribution.
Good faith means: you do not access more data than necessary to demonstrate the issue, you do not degrade our service, you do not exfiltrate or retain customer data, and you give us reasonable time to fix before any public disclosure.
Actions that fall outside good faith — data theft, extortion, service disruption, or accessing other customers' data beyond what is needed to prove a flaw — are not protected.
For our customers
If you are a NexCyber customer and you discover a security concern, the same channel applies — report via security.txt, or through your support contact for account-specific issues. For questions about how we handle vulnerabilities in the components inside our platform, our security posture article covers our internal vulnerability-handling discipline.
What makes a great report
The best reports make it fast for us to confirm and fix an issue — which is also what gets you credited soonest. A strong submission typically has:
| ▸ Element | Why it helps |
|---|---|
| A clear, single-issue title | We route it correctly on arrival |
| Precise reproduction steps | We confirm without guessing |
| A minimal proof of concept | We see impact without you exfiltrating data |
| An impact statement | We assess severity accurately |
| Suggested remediation (optional) | We move faster, and it shows good faith |
A weak report — "your site is hackable," no detail — forces a slow back-and-forth and delays everyone. Precision is a courtesy that pays you back.
Recognition
With your permission, we credit researchers who responsibly disclose valid issues. Recognition is a small thing that matters: it acknowledges real work, and it signals to the wider community that engaging with us in good faith is worthwhile. If you prefer to remain anonymous, we respect that too — just tell us in your report.
Why coordinated disclosure benefits everyone
Uncoordinated disclosure — dropping details publicly before a fix exists — puts every user at risk during the window between publication and patch. Coordinated disclosure closes that window. It is the model regulators increasingly expect, the model we operate, and the model we help our customers build for their own products.
The same principle sits at the heart of the CRA's vulnerability-handling expectations: know how to receive a report, act on it promptly, and disclose responsibly once users are protected. By running this process ourselves, we practise what the frameworks we support require — and we invite you to hold us to it.
→ Related: Our security posture · The CRA explained · What is NexCyber?
NexCyber provides a readiness analysis, not legal advice. This policy describes NexCyber's own vulnerability-handling practice and does not constitute legal advice about your organisation's disclosure obligations.
Last reviewed 2026-07-10.