Responsible Disclosure Policy

1. Our commitment

In short:Report a vulnerability in good faith and we will not pursue you for it.

We hold sensitive personal data, and we would rather hear about a weakness from a researcher than from an attacker. If you have found a security issue in our platform, we want to know.

This policy explains how to tell us, what we will do, and the protections you have when you follow it.

2. How to report

In short:Email us with enough detail to reproduce it.

Send reports to [email protected].

A useful report includes: the affected URL, endpoint or component; a description of the issue and its impact; the steps needed to reproduce it; and any proof-of-concept material. Screenshots and request/response captures help.

Please report in English, and please do not disclose the issue publicly until we have had a chance to fix it — see the disclosure timeline below.

We do not currently publish a PGP key, so please send reports in plain text to the address above rather than encrypted. Please do not include live candidate data in a report — describe the issue and we will reproduce it ourselves.

3. Scope

In short:Our own systems are in scope. Third parties and social engineering are not.

In scope: gopapertrail.ai and its subdomains, the Papertrail web application and admin panel, and the public API.

Out of scope: systems operated by third parties, including our sub-processors and the registries we query; anything belonging to our customers; and the following classes of report, which we generally do not treat as vulnerabilities: missing security headers with no demonstrated impact, results from an automated scanner with no working proof of concept, denial of service, rate-limiting on non-sensitive endpoints, self-XSS, email spoofing of domains without demonstrated impact, and best-practice suggestions unaccompanied by an exploit.

4. Rules of engagement

In short:Do not access other people's data, and do not break anything.

When testing, please stay within these limits: use only accounts you own or have permission to test; do not access, modify, download or retain any personal data belonging to another person — if you encounter it, stop immediately and tell us in your report; do not degrade the availability or integrity of the service; do not run automated scans that generate significant traffic; and do not use social engineering, phishing, or physical attacks against our staff or offices.

If a proof of concept requires accessing another person's data to demonstrate impact, describe how it could be done rather than doing it. A clear explanation is sufficient — we will verify it ourselves.

5. Safe harbour

In short:Good-faith research within this policy will not lead to legal action from us.

If you make a good-faith effort to comply with this policy during your research, we will consider your activity authorised, we will not initiate or support legal action against you in relation to it, and we will say so if a third party pursues action against you for research conducted under this policy.

This undertaking is limited to action within our control. It does not authorise breaking any law, and it does not extend to systems that are not ours.

If you are unsure whether something is in scope, ask us before you test it.

6. What we will do

In short:Acknowledge, assess, fix, and credit you if you want.

We will acknowledge your report promptly, give you an assessment of severity and our intended timeline once we have triaged it, keep you updated while we work on it, and tell you when it is fixed.

With your permission we will credit you publicly once the issue is resolved. If you would rather stay anonymous, we will respect that.

We do not operate a paid bug bounty programme and do not offer monetary rewards. We would rather say that plainly than let you assume otherwise. We will credit you publicly for a valid report if you would like us to, and we will work with you in good faith throughout.

7. Coordinated disclosure

In short:Give us time to fix it before going public.

We ask that you coordinate the timing of any public disclosure with us, so that a fix is in place before the details are published. We will agree a timeline with you rather than impose one.

Where an issue is being actively exploited or the fix is straightforward, we will move faster and will say so. Where a fix is genuinely complex, we will explain why and agree an extension with you rather than going quiet.