Acceptable use policy

Authorisation comes first

No testing begins until we hold written authorisation from someone with the authority to give it, naming the systems in scope. Not an email saying "go ahead" from an engineer, and not a verbal confirmation on a call.

If you cannot demonstrate that you own or control a target, we will not test it. That includes third-party SaaS your product depends on, shared hosting, upstream APIs, and anything belonging to a parent or subsidiary company that has not signed off separately. Testing infrastructure you do not control is unlawful in most jurisdictions and it is not a judgement call we will make on your behalf.

Work we will not take

• Testing a system whose owner has not authorised it, however the request is framed.
• "Recover" or "get me into" work against an account or device, including ones you say are your own.
• Surveillance of an individual: partners, employees, competitors, anyone. This includes tracking, monitoring, and location work.
• Building or supplying offensive tooling for deployment against systems we have not scoped.
• Denial of service, destructive testing, or anything whose objective is disruption rather than evidence.
• Work that exists to produce a certificate rather than a result - testing scoped so narrowly it cannot fail.

How we test

• We stop at proof. Once a vulnerability is demonstrated we stop. We do not see how far it goes, we do not pivot outside scope, and we do not exfiltrate data to prove we could.
• We minimise what we touch. Where a finding can be proven against a test account, it is. Where real data must be involved, we record the minimum needed and redact it in the report.
• We tell you immediately. Critical findings go to your named contact as soon as they are confirmed, not at the end of the engagement.
• We stop if asked. Any named contact can call a halt at any point, for any reason, without explanation.
• We report what we did not cover. Scope we could not reach, tests we could not run and areas we ran out of time on appear in the report. A silent gap reads as a clean result and it is not one.

What happens to findings

Findings are yours. They are delivered to your named contacts, they are never sold, shared, or used as marketing material, and nothing identifying you is published without your written permission. Our working copies - notes, captures, proof-of-concept output - are destroyed on the schedule set in the engagement agreement.

Where we publish research it is generalised: the vulnerability class and the reasoning, with every detail that could identify the client removed.

If we find something outside scope

We stop and tell you. We do not test it. If it belongs to a third party, we tell you and leave the disclosure decision with you, because it is your relationship and your call.

If we find evidence of a compromise

If testing turns up signs that someone is already inside, we stop, we contact you out of band immediately, and we preserve rather than disturb what we found. Incident response is a different engagement with different rules, and continuing to test through someone else's intrusion destroys the evidence.

Our own systems

The same standard applies in reverse. We do not run a vulnerability disclosure programme and we grant nobody permission to test our infrastructure - see the security page for what to do if you have found something anyway.