Responsible disclosure

Send us a description of the issue, the steps to reproduce it, and anything that helps us understand the impact. A short proof of concept is more useful than a scanner export.

Security reports:use the contact form — a dedicated address has not been published yet

Please include how you would like to be credited, if at all. If you would prefer to remain anonymous, that is fine.

• We will acknowledge your report within five business days.
• We will tell you our assessment of the severity and our intended remediation timeline, rather than going quiet.
• We will keep you updated while we work on it.
• We will tell you when it is fixed.
• We will credit you publicly if you want that, and keep your report confidential if you do not.
• We will not take legal action, or support legal action by anyone else, against a researcher acting in good faith under this policy.

• Give us reasonable time to fix the issue before disclosing it publicly. What is reasonable depends on severity — talk to us and we will agree a date.
• Do not access, modify, download or delete data that is not yours. If you accidentally access customer data while investigating, stop, tell us, and do not retain it.
• Do not run denial-of-service testing, high-volume automated scanning, or anything that degrades the service for customers.
• Do not use social engineering, phishing or physical attempts against our staff or customers.
• Use your own test account rather than a customer’s.
• Do not demand payment in exchange for disclosure.

• The Cyber Guys web application and its API endpoints.
• Anything that breaks tenant isolation — the highest severity class for this product, given one organisation reaching another’s records is the failure that matters most.
• Authentication, session handling and privilege escalation.
• Access-control failures, including reaching a feature the organisation’s plan does not include or a record its role does not permit.
• Injection, deserialisation, server-side request forgery and similar classes.
• Anything that would let the phishing simulation subsystem be used against people outside the organisation that authorised it.
• Bypassing export controls, watermarking or share-link expiry.

These are either intentional, already known, or not something we can act on. Reporting them is not a problem, but they will not usually result in a change.

• Missing multi-factor authentication on Cyber Guys accounts — this is a known gap, documented on the security overview, and it is being worked on.
• Self-signup not requiring email verification — also known and documented in the same place.
• Missing security headers on assets that carry no security significance.
• Reports from automated scanners without a demonstrated impact.
• Software version disclosure without a working exploit.
• Rate limits you consider too generous, absent a demonstrated abuse path.
• Issues requiring physical access to a user’s unlocked device.
• Social engineering of our staff or customers, which is out of scope by design and not a testing method we consent to.

If you are an IT provider or a security consultant testing on a customer’s instruction, tell us that in your report. It changes nothing about how we handle the issue, but it helps us notify the right people and avoid duplicating an investigation you have already done.