Penetration Test Authorisation Letter: A UK Template

A penetration test authorisation letter is the client’s written permission to test, signed by someone with authority over the systems named in it. It is short, but it is the document that keeps the work on the right side of the law: without it, the access a tester makes could be a criminal offence.

This guide explains why the letter matters under the Computer Misuse Act 1990, who can actually sign it, how to handle systems the client does not own, and where the signed copy should live. There is a free UK template at the end. This is not legal advice, and a firm should have its own terms reviewed by a solicitor.

Why the letter matters under the Computer Misuse Act 1990

The Computer Misuse Act 1990 makes it an offence under section 1 to cause a computer to perform a function with intent to secure access to a program or data, where the access is unauthorised and the person knows it is. Section 3 goes further, covering unauthorised acts that impair, or are reckless as to impairing, the operation of a computer or the reliability of data, and a temporary impairment still counts.

The word that matters is “unauthorised”. Section 17 defines access as unauthorised when the person is not entitled to control access of that kind and does not have the consent of someone who is. A penetration test is, by design, access that would be unauthorised if nobody had permitted it. The authorisation letter is that permission, recorded, from a person entitled to give it.

Reform is on the horizon. The government committed in 2026 to updating the Computer Misuse Act, and campaigners continue to press for a statutory defence for good-faith security work. As of October 2026 no such defence is in force, so written authorisation remains the thing a tester relies on. Treat any future defence as a backstop, never as a substitute for permission. Until a defence is enacted and its conditions are known, nothing about a planned reform changes what a tester should do today: hold a signed letter, scoped to named systems and a fixed window, before the first request.

Who can authorise a test

The person who signs must have authority over the systems being tested. In the language of the Act, they must be entitled to control access, or able to give consent on behalf of someone who is. In practice that is someone senior enough to speak for the organisation that owns or operates the systems: an IT director, a head of security, a company officer, or a delegate with written authority from one of them.

A letter signed by the wrong person is worse than no letter, because it looks like protection and is not. The developer who built the application cannot usually authorise a test of the production estate it runs on. A marketing manager who commissioned a website cannot authorise testing of the hosting account. Check that the signatory’s authority actually reaches every target, and say so in the letter.

Where the signer acts under a delegation, that delegation should be in writing and on file, so the chain from the person with authority to the person who signed is visible if it is ever questioned. In a group of companies, confirm that the entity giving permission is the one that actually operates the systems, not simply the parent brand, because ownership inside a group is rarely where the logo suggests.

Agreeing this early also prevents the overrun covered in how to prepare for a penetration test: a test that cannot start on the Monday because the authorisation came from someone who, it turns out, could not grant it.

Assets the client does not own or control

A client can only authorise testing of what it owns or controls. The moment a target is hosted or operated by someone else, a second permission is in play, and the client’s signature alone does not cover it.

• Cloud-hosted assets: each major provider publishes its own current testing policy. Some activity needs no approval, some needs notification, and some is prohibited outright. The client must confirm it has read the policy, obtained any required permission, and kept a dated copy. The side-by-side detail is in the guide to cloud penetration testing rules.
• Software-as-a-service components: a third-party service embedded in the client’s application is usually off limits without the vendor’s written permission.
• Managed or co-located infrastructure: a hosting company’s terms may require notice before testing, even where the client owns the servers.

What the letter must name

A letter that authorises “our systems” authorises nothing clearly. It should name, precisely:

• The testing firm, and that its named testers are covered.
• Every system, address, application or range in scope, with its environment and who owns it.
• The testing window: start, end, time zone and permitted hours.
• The third-party and cloud-hosted assets in scope, and the permission relied on for each.
• The signatory, their role, and a statement that they have authority over the systems listed.
• That the authorisation is limited to the named systems and window, and extends to nothing else.

The limiting sentence is as important as the grant. Consent scoped to a named list is consent a tester can rely on and a client can stand behind. Consent that trails off into “and related systems” invites exactly the argument the letter exists to prevent.

Physical access and social engineering

Technical testing of systems is one kind of permission. Walking into a building, or phishing a client’s staff, is another, and it should be authorised separately. The consent, the signatory and the legal considerations are different, and a single blanket permission is harder to rely on when it matters.

A physical engagement also tends to touch more than the client’s own property, and some locations carry their own criminal law that a client’s authorisation cannot override. Keep physical scopes well clear of anything the client does not itself control, agree a stand-down phrase, and give each tester a get-out-of-jail contact: a named person with a 24-hour number who can confirm the engagement if a tester is challenged. The template includes a separate annex for this, signed by someone with authority to permit entry and to represent the staff being tested.

Where the signed letter lives

The signed letter is evidence of your authority to test, so store it like it. The testing firm holds the signed original or a signed electronic copy for the duration agreed in the statement of work, under the same access controls as the engagement’s findings and evidence, and produces it if the authority to test is ever questioned. The client keeps a counterpart. A letter saved once and then lost in an inbox is not much use the day somebody asks who authorised the work.

The same discipline applies to the whole engagement. Where findings, evidence and authorisation records are kept, and who can read them, is a question clients and auditors ask, and it is the subject of the security and your database pages.

The template

The Word template below is a complete UK authorisation letter: the grant, the Computer Misuse Act framing, the signatory’s confirmation of authority, schedules for the systems, window and third-party assets, and a separate annex for physical and social engineering work. Placeholders are in square brackets and the italic guidance notes are there to be deleted.

Download the template (Word, 40 KB)

This template is not legal advice. Have your firm’s own terms, and the wording of this letter, reviewed by a solicitor before you rely on them.