What 'Authorisation' Actually Means Under the Computer Misuse Act

In October 2005, Daniel Cuthbert donated 30 pounds to the Disasters Emergency Committee's tsunami appeal. The confirmation page didn't load properly, and Cuthbert, who did penetration testing for a living, got suspicious it was a phishing clone. So 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, until the bank he was working for noticed the anomalous requests in a log review, reported them, and he ended up in Horseferry Road Magistrates' Court convicted under section 1 of the Computer Misuse Act 1990. The judge found him guilty "with some considerable regret" and fined him 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 to do what you did, from someone entitled to give it. Motive, competence, and good intentions don't enter into it. That is the single fact that should shape how every penetration test in England and Wales is scoped, because it means 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

Section 1 CMA 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, which is 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, which turns out to be a much narrower question than "who works there".

The House of Lords addressed this in R (Allison) v Bow Street Magistrates' Court [2002] 2 AC 216, a case about a bank employee who 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, but it's worth being explicit about why each piece exists, 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.

Where this breaks: infrastructure the client doesn't actually own

The awkward case, and increasingly the normal case, 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, but still prohibits certain activities outright (DNS zone walking, flooding, protocol-level attacks against their infrastructure rather than the customer's instance) and other providers have different rules again. If a test plan involves anything at the platform layer rather than purely within the customer's own account and application, that needs the cloud provider's own policy checked, not just the client's sign-off, because 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 no 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 insist on verifying 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, and 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, and 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, leaving out proof-of-concept development, testing via attacker infrastructure, and supervision of junior testers, among other common parts of the job.

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.