Section 02

Legal & ethical foundations

The same Nmap scan is professional work or a criminal offence depending on whether the operator can produce written authorisation. This section sits ahead of every technical section in the guide on purpose — read it first, even if you own the kit, because the habit of writing down scope before opening a terminal is the single most important one you can build.

The single rule

Do not touch a system, a network, or any data on either, without written authorisation from someone with the authority to grant it, for a defined scope, within a defined window, with a defined point of contact for anything that goes wrong.

That is the whole rule. Everything below is detail.

The Computer Misuse Act 1990, in three sections

UK readers operate under the CMA 1990.¹ The three sections that most often bite during security testing are s1, s2, and s3A.

Section 1 — Unauthorised access

Causing a computer to perform any function with intent to secure access to any program or data, where the access is unauthorised and you know that it is. The bar is low: a port scan that triggers a banner grab against a host you have no permission to touch is enough. Maximum penalty: two years' imprisonment, an unlimited fine, or both.²

Section 2 — Unauthorised access with intent

s1 plus intent to commit, or facilitate the commission of, a further offence. Five years' imprisonment.³ This is the section invoked when an attacker is found to have positioned themselves for ransomware deployment or fraud.

Section 3A — Making, supplying or obtaining articles

Making, adapting, supplying or offering to supply any article intending it to be used to commit, or to assist in the commission of, an s1 or s3 offence.⁴ The article in question can be a tool — Nmap, Hydra, Metasploit, your own Python — or it can be the write-up of a technique. The defence is that the article was made or supplied for a legitimate purpose, which is precisely what authorisation paperwork establishes.

Scope drift is the failure mode

The most common way authorised work becomes unauthorised work is not malice; it is scope drift. The pattern is recognisable:

• You have authorisation to audit one IP camera at 192.168.x.201.
• The camera's banner reveals it phones home to a cloud service. The assistant proposes resolving that hostname and probing the cloud endpoint to characterise the dependency. The cloud endpoint is not yours.
• The camera shares a VLAN with a NAS. The assistant proposes an ARP sweep to map the segment. The NAS is the family's, not yours, and you did not ask them.
• You forwarded port 8080 to test the remote-access posture. The assistant proposes testing the same posture against the next IP in the ISP's range. That IP is someone else's router.

Each step looks like a small extension of the previous one. Each one is its own offence. The defence is to write the scope down before you start, and to read it back against every tool-call proposal the assistant makes during the session.

International equivalents

If your employer is multi-jurisdictional, the same authorisation paperwork has to clear the relevant equivalent statute in every country where the target sits or the operator types.

Jurisdiction	Statute	Notes
United Kingdom	Computer Misuse Act 1990 (as amended)	Sections 1, 2, 3, 3A as above.
United States	Computer Fraud & Abuse Act (18 U.S.C. §1030)5	The post-Van Buren (2021) reading narrows "exceeds authorised access" but does not narrow "without authorisation".6
European Union	NIS 2 Directive (2022/2555) and national implementations7	Imposes obligations on operators; does not replace national computer-misuse statutes.
South Africa	Cybercrimes Act 19 of 20208	Chapter 2 covers unlawful access, interception, and interference with data and computer systems.

Responsible disclosure

If during an in-house audit you discover a vulnerability that affects the vendor's product more broadly — not just your deployment — the right next step is responsible disclosure. The NCSC's Vulnerability Disclosure Toolkit is the UK reference document.⁹ The essentials:

• Report privately first. A security.txt file at the vendor's /.well-known/ path is the conventional starting point.
• Give a reasonable window. The widely-cited convention is 90 days from first contact before public disclosure, longer if the vendor is actively engaged and asks for more time. Google's Project Zero — the team that popularised the deadline — currently follows a "90+30" policy: 90 days for a fix, plus 30 more for patch adoption.¹⁰
• Keep the report defensible. Reproduction steps, affected versions, and the impact assessment — no payloads beyond what is needed to demonstrate the issue.

A one-page authorisation template

This is the minimum viable paperwork. For audits inside an employer, the security team will have a more elaborate version; for owner-operator audits on your own kit, this is enough. Save it as AUTHORISATION.md alongside your audit notes.

# Internal Security Assessment — Authorisation

**Target owner:**          [Name and role of the person authorising]
**Operator:**              [Name of the person performing the audit]
**Assessment window:**     [Start date/time] – [End date/time], [Time zone]
**Last reviewed:**         [Date]

## Scope (in)

- Device: [Device name / model / role]
- Internal address(es): [e.g. 192.168.3.201/32]
- External address(es): [e.g. <public IP>/32, single port only]
- Permitted activities:
    - Port scanning (TCP, UDP)
    - Service / version detection
    - HTTP / RTSP enumeration against the device
    - CVE verification using public proof-of-concept tooling
    - Authentication probing using credentials supplied by the owner

## Scope (out)

- Any host not listed above.
- Denial-of-service or load-generation attacks.
- Any modification of stored data (recordings, configuration).
- Pivoting from the target to any other device on the network.
- Credential dictionaries against accounts not in scope.

## Point of contact

- During the window:   [Name, phone, email]
- Out of hours:        [Name, phone, email]

## Sign-off

Authorised by: __________________________   Date: __________
Operator:      __________________________   Date: __________

How to read this before every tool call

Pin the authorisation file open in a second VS Code pane while you run the audit. When the assistant proposes a command, the question to ask is not "does this command achieve what I want?". The question is "is the target of this command inside my scope?". If you cannot point at a line in the authorisation file that covers the host and the activity, decline the proposal and rewrite the prompt.

Sources & footnotes

1. Computer Misuse Act 1990, c. 18. UK Public General Acts. legislation.gov.uk/ukpga/1990/18/contents ↩
2. Computer Misuse Act 1990, section 1 — Unauthorised access to computer material. Penalty on indictment of two years' imprisonment or a fine, or both, as amended by Police and Justice Act 2006 s. 35. legislation.gov.uk/ukpga/1990/18/section/1 ↩
3. Computer Misuse Act 1990, section 2 — Unauthorised access with intent to commit or facilitate commission of further offences. Penalty on indictment of five years' imprisonment or a fine, or both. legislation.gov.uk/ukpga/1990/18/section/2 ↩
4. Computer Misuse Act 1990, section 3A — Making, supplying or obtaining articles for use in offence under section 1, 3 or 3ZA. Inserted by Police and Justice Act 2006 s. 37. legislation.gov.uk/ukpga/1990/18/section/3A ↩
5. 18 U.S.C. §1030 — Fraud and related activity in connection with computers (the Computer Fraud and Abuse Act). Legal Information Institute, Cornell Law School. law.cornell.edu/uscode/text/18/1030 ↩
6. Van Buren v. United States, 593 U.S. 374 (2021), opinion of the Court delivered by Barrett, J. Slip opinion No. 19–783, decided 3 June 2021. supremecourt.gov/opinions/20pdf/19-783_k53l.pdf ↩
7. Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). EUR-Lex. eur-lex.europa.eu/eli/dir/2022/2555 ↩
8. Cybercrimes Act 19 of 2020 (Republic of South Africa). Assented to 26 May 2021; selected provisions in force from 1 December 2021. gov.za — Cybercrimes Act 19 of 2020 ↩
9. The NCSC's Vulnerability Disclosure Toolkit. National Cyber Security Centre (UK). ncsc.gov.uk/information/vulnerability-disclosure-toolkit ↩
10. Project Zero: Vulnerability Disclosure Policy. Google Project Zero — the "90+30" policy: 90 days for a fix, plus a 30-day window for patch adoption. googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html ↩

Check yourself

Three questions on getting the law right

Pick the option you think is right and expand it to see the verdict. Getting any of these wrong is the kind of mistake that turns a professional engagement into a criminal offence.

Q1 / 3

What is the dividing line between a professional audit and a Computer Misuse Act offence?

Whether the operator holds a recognised pen-testing certification.

No A certification establishes competence, not authority. An uncertificated operator with written authorisation is acting lawfully; a certificated one without it is not.

Whether the tools used are open-source and freely available.

No Nmap is on the front page of every Kali install; the lawfulness of running it against a host has nothing to do with where the binary came from.

Whether the operator can produce written authorisation from someone with the authority to grant it, for a defined scope, within a defined window.

Yes The single rule from Section 02: authority + scope + window + contact, in writing. Everything else is detail.

Q2 / 3

You are authorised to audit one device. The assistant proposes an ARP sweep of the VLAN "to characterise the segment context". The most accurate description of what is happening is:

A reasonable scoping refinement — segment context is part of any audit.

No "Reasonable in general" is not the test. The test is whether the segment is named in your authorisation file. If it isn't, neighbouring devices aren't yours to probe.

Scope drift — the proposal extends the engagement to hosts you have no authorisation to touch.

Yes Each step looks like a small extension of the previous one. Each one is its own potential offence. Deny the proposal and rewrite the prompt.

Acceptable so long as no findings against the neighbours appear in the final report.

No The CMA s1 offence is in causing the function to be performed, not in publishing the result. Omitting findings doesn't unscan the hosts.

Q3 / 3

When does Computer Misuse Act 1990 s3A apply to a tool like Nmap or a script you wrote?

It applies whenever the tool is installed on a computer.

No s3A is concerned with intent. Possession of dual-use security tools is not by itself an offence.

It applies to making, supplying or obtaining articles intending them to be used to commit, or assist in, an s1 or s3 offence.

Yes The article — tool or write-up — plus the intent. Authorisation paperwork is what evidences a legitimate purpose if the question is ever asked.

It applies only to tools sold commercially, not free or open-source ones.

No s3A makes no distinction by price or licence. A bash one-liner, a Metasploit module, and a paid commercial scanner are equivalent for its purposes.