Skip to main content

Security

We build compliance tooling, so we will not pretend our own software is free of defects. If you have found one, we want to hear about it, and this page is the channel.

Reporting

Email security@auditsu.com. Please include:

  • Where the issue is: a URL, an endpoint, or the part of the product.
  • What an attacker could do with it, and the steps to reproduce it.
  • Anything that helps us confirm it: a request and response pair, a screenshot, a short recording.

Reports in English are easiest for us to act on quickly.

What we commit to

  • We acknowledge every report within five working days.
  • We give you a substantive reply, meaning our assessment and what we intend to do, within ten working days.
  • We tell you when it is fixed.
  • If you would like credit, we will name you when we publish the fix. If you would rather not be named, we will not name you.

We do not run a paid bug bounty. We are a small company and would rather say so plainly than leave you to discover it after the work.

What we ask

  • Give us a reasonable opportunity to fix the issue before disclosing it publicly. We suggest 90 days, and will tell you if we need longer and why.
  • Use only accounts you own or have been given permission to use.
  • Do not access, modify, or retain other people's data. If you encounter customer data, stop, and tell us what you saw so we can assess the exposure.
  • Do not degrade the service for anyone else: no denial of service, no load testing, no spam.
  • Do not use social engineering, phishing, or physical access against our staff or suppliers.

Scope

In scope

  • auditsu.com
  • app.auditsu.com

Out of scope

  • Third-party services we use but do not operate. Report those to the provider, and tell us too if the exposure is ours.
  • Findings from automated scanners with no demonstrated impact. We are happy to look at scanner output, but a report that shows how the issue is exploited will always get further, faster.
  • Missing hardening headers, cookie flags, or version disclosure, unless you can show a concrete attack they enable.
  • Denial of service, volumetric testing, and anything requiring physical access.

Safe harbour

If you make a good-faith effort to comply with this policy during your research, we will treat your work as authorised, we will not pursue or support legal action against you in relation to it, and if a third party brings action against you for research conducted within this policy we will make clear that it was authorised.

This does not extend to research that breaks the conditions above, in particular accessing other people's data, degrading the service, or disclosing an unfixed issue publicly.

This page

Last reviewed: 25 August 2026. We review this page at least annually. Machine-readable contact details are published at /.well-known/security.txt.