Guides

Why a security tester needs your permission, and who can give it

It may seem like red tape, but it's what separates a security review from a criminal offence. And for a home-grown system, the right person to ask isn't always obvious.

An old wooden door standing open in a sunlit brick wall, with a large iron key in its lock

In the UK, the Computer Misuse Act 1990 makes it an offence to access a computer’s programs or data when you know the access is unauthorised. There’s no exception for doing it to be helpful.

This is our plain-English reading and not legal advice. Reform of the Act has been reported as under way, so check the current position if it matters to you.

What makes access unauthorised?

Section 17 of the Act says, in effect, that an act is unauthorised if the person isn’t themselves entitled to decide whether it may be done, and doesn’t have consent from someone who is. So two things matter:

  • there has to be consent;
  • it has to come from someone actually entitled to give it.

The Act doesn’t say that consent must be in writing. But writing is how everybody proves what was agreed, so any professional tester will insist on it, and so should you.

Who can say yes?

For a traditional company system, it’s usually simple: a director says yes. A home-grown system is less tidy.

The business owner

Normally the right starting point. But check that the business really does control the system.

A member of staff

Their say-so may not be enough. Get it from someone with authority to decide for the business.

A freelancer or builder

They might hold the accounts in their own name, so they may also need to agree, and you might not have the authority you assume. Who owns your system?

Other companies

Your app sits on someone else’s platform, such as a builder, database or host. You can give permission for your own app and data, but that doesn’t cover attacking their infrastructure. Their terms apply too.

What good permission looks like

Whoever you use, get these in writing before anything starts:

  1. Which systems and web addresses are in scope, and which aren’t.
  2. What the tester may do, and what they must ask about first.
  3. When it will happen, and who to ring if something goes wrong.
  4. How your data will be handled, what they’ll keep, and when they’ll delete it.
  5. Confirmation that whoever signs has the authority to do so.

Going beyond the agreed scope can be a problem in itself, so a good tester will stick to it and stop if they find they’re somewhere they shouldn’t be. Ours is set out in clause 3 of our terms of business.

What about checking your own app?

You can test systems you control. Our 10 checks are for that. Be careful about the edges: if your builder’s personal account is involved, or you’re poking at your provider’s systems and not just your own app, stop and ask. And never try these things on anyone else’s system, including a competitor’s or a supplier’s, however curious you are.

If you think you’ve found a problem in somebody else’s system by accident, stop and tell them. Don’t test further to prove it.

Questions

What if the builder has left, and the accounts are in their name?

Sort out the ownership first, and take legal advice if there’s a dispute. Don’t try to get into an account that isn’t yours, even if you’re sure the system should be. When the builder leaves sets out what to do.

Is a free online scanner OK to use?

Only on systems you control or have permission to test. Be careful about what you hand over too: you’re giving a stranger information about your weak points.

By Selwyn Doling, VibeTend. Last updated 6 November 2026.

Find out where you stand.

Tell us what you’ve built. We’ll agree the scope and the price with you before anything starts.

Talk to usSee an example report