What 'Authorisation' Actually Means Under the Computer Misuse Act

In 2005 a penetration tester was convicted under the Computer Misuse Act for checking whether a tsunami charity's donation site was a phishing clone. It wasn't. Nothing broke. The judge found him guilty anyway, "with some considerable regret".

The Cuthbert case in five steps

In October 2005, Daniel Cuthbert donated 30 pounds to the Disasters Emergency Committee's tsunami appeal. What happened next:

The confirmation page didn't load properly, and Cuthbert, who did penetration testing for a living, got suspicious it was a phishing clone.
He did what any of us would recognise as basic due diligence: he tried a couple of directory traversal strings in the URL to see if the site was what it claimed to be.
It was. Nothing broke. He told no one and thought nothing more of it.
The bank he was working for noticed the anomalous requests in a log review and reported them.
He ended up in Horseferry Road Magistrates' Court, convicted under section 1 of the Computer Misuse Act 1990, and fined 400 pounds.

That regret is the whole story. Nobody involved thought Cuthbert was a criminal; he thought he was protecting a charity from fraud. The CMA didn't care.

Section 1 asks one question: did you have authorisation, from someone entitled to give it? Motive, competence, and good intentions don't enter into it.

That single fact should shape how every penetration test in England and Wales is scoped. The legality of the entire engagement rests on a piece of paper, not on the tester's judgement or the client's gratitude afterwards.

The offence has no "but I meant well" clause

Two sections matter for testers:

Section 1 makes it an offence to cause a computer to perform a function with intent to secure unauthorised access to a program or data, knowing at the time that the access is unauthorised.
Section 3 covers unauthorised acts that impair the operation of a computer. That's what typically applies to anything more aggressive than a passive scan: exploitation, lateral movement, denial-of-service testing, anything that changes state on the target.

What counts as "unauthorised" is defined in section 17(5). Access is unauthorised unless the person doing it is themselves entitled to control access to the data, or has consent from someone who is.

That sounds simple until you ask who, precisely, is entitled to control access to a given system. It turns out to be a much narrower question than "who works there".

Allison: a valid login isn't blanket authorisation

Quick detour into case law, because it settles this. The House of Lords addressed it in R (Allison) v Bow Street Magistrates' Court [2002] 2 AC 216. A bank employee had legitimate access to some customer accounts, but used it to pull data on accounts outside her remit and passed the details to a card fraud ring.

The Lords held that her employer's authorisation was scoped, not blanket. Being an employee with a valid login didn't make every access authorised, only access within whatever limits the employer had actually defined.

The corollary for pentesting is uncomfortable if you think it through. A signature from someone in IT doesn't automatically authorise anything. It authorises whatever that specific person had the actual authority to consent to, on behalf of the actual owner of the data and the system, and not one byte more.

What the authorisation actually has to cover

None of this is exotic to anyone who has run a professional engagement. It's worth being explicit about why each piece exists, though, because "we signed a contract" is not the same as "we had section 17(5) authorisation".

A named signatory with actual authority. Not a procurement contact, not whoever replied to the email fastest: someone who is entitled to control access to the specific systems and data in scope, or who can demonstrate a documented delegation from someone who is. For a company's own infrastructure this is usually straightforward. It stops being straightforward the moment any part of the estate is hosted, managed, or owned by someone else.
A precise scope: IP ranges, hostnames, applications, and an explicit exclusion list. "The website" is not a scope. A CIDR block, a list of FQDNs, and a note on what's deliberately excluded (a payment gateway you don't want touched, a production database you want read-only access to) is. Anything found reachable from an in-scope host that wasn't explicitly listed is a decision point, not an invitation.
A time window and rules of engagement. Dates, permitted hours, whether social engineering or physical access is in play, whether denial-of-service style testing is permitted at all (usually not, given section 3's focus on impairment), and an emergency contact who can be reached if something goes wrong mid-test.
A "get out of jail" letter. A document the tester can produce on the spot if an incident responder, a managed SOC, or a police officer starts asking why there's exploitation traffic hitting a production host. It doesn't need to be dramatic, it just needs to exist and be carryable.
Change control for scope creep. Real engagements drift: a tester finds a related subdomain, an API that clearly belongs to the same client, a staging environment nobody mentioned. Testing it anyway because it's "obviously theirs" is exactly the assumption that got Cuthbert convicted. Get it added to scope in writing, even if that just means a one-line email exchange with the named signatory, before touching it.

Your client can't authorise testing of the cloud underneath them

The awkward case, and increasingly the normal one, is when the thing being tested isn't hosted on infrastructure the client controls. A client can authorise testing of their own application logic all day long.

They cannot authorise testing of the underlying cloud platform, because they are not entitled to control access to it. They're a tenant.

AWS relaxed its blanket pre-authorisation requirement in 2019 for eight core services. It still prohibits certain activities outright:

DNS zone walking
flooding
protocol-level attacks against their infrastructure rather than the customer's instance

Other providers have different rules again. If a test plan touches the platform layer, rather than purely the customer's own account and application, check the cloud provider's own policy too. The client's sign-off doesn't reach that far.

The same problem shows up with anything white-labelled, subcontracted, or running on shared multi-tenant infrastructure where testing one tenant's slice risks touching another's.

If the entity signing your authorisation letter isn't the entity entitled to control access to the system in question, section 17(5) isn't satisfied. It doesn't matter how sincerely everyone believed it was fine.

This is precisely why CREST and NCSC's CHECK scheme require accredited testers to hold documented scope agreements and verify ownership before work starts. It isn't bureaucratic box-ticking. It's the only thing standing between the engagement and a section 1 offence.

There still isn't a public interest defence

It's worth being clear about where the law currently stands rather than where people wish it stood. The CyberUp Campaign has spent years pushing for a statutory defence covering good-faith security research. The government has been reviewing the CMA alongside the Cyber Security and Resilience Bill.

As of early 2026, a proposed limited defence has been under development but not enacted. In February 2026 the government rejected an amendment that would have required a formal review of whether a broader statutory defence should protect cyber security professionals.

Commentary on the proposal as drafted suggests it would only cover scanning of internet-facing systems. Among other common parts of the job, it would leave out:

proof-of-concept development
testing via attacker infrastructure
supervision of junior testers

Until something changes, "I was doing legitimate security work" is mitigation you might raise at sentencing, the way it visibly softened Cuthbert's outcome to a fine rather than anything worse. It is not a defence to the charge itself.

The contract, the scope document, and the signature from someone who actually had the authority to give it are not paperwork wrapped around the real protection. For now, in England and Wales, they are the real protection.