The Computer Misuse Act 1990 (CMA) makes it a criminal offence to access computer systems without authorisation. If you conduct penetration testing, vulnerability research, or develop security tools, you must understand the legal boundaries to avoid prosecution.

Key principle: Good intentions are not a defence. You need explicit written authorisation before testing any system you do not own.

Criminal offences and penalties

The CMA creates four main offences. The Serious Crime Act 2015 added Section 3ZA and increased penalties for serious cases.

Computer Misuse Act 1990 offences and penalties

The four main criminal offences under the Computer Misuse Act 1990 (as amended by the Serious Crime Act 2015), with maximum sentences and key elements.

The Computer Misuse Act 1990 creates criminal offences for unauthorised access to computer systems. The Serious Crime Act 2015 amended the Act to add Section 3ZA and increase some penalties.

Section 1: Unauthorised access to computer material: Up to 2 years imprisonment (summary or indictment)
Section 1 covers: Accessing programs or data without authorisation, exceeding authorised access rights
Section 2: Unauthorised access with intent to commit further offences: Up to 5 years imprisonment
Section 2 covers: Accessing systems to facilitate fraud, blackmail, or other crimes
Section 3: Unauthorised acts impairing computer operation: Up to 10 years imprisonment (14 years if causing national security or economic damage)
Section 3 covers: DDoS attacks, distributing malware, ransomware, impairing system reliability or data integrity
Section 3ZA: Unauthorised acts causing serious damage (added 2015): Up to 14 years imprisonment (life if causing death, injury, or damage to national security)
Section 3ZA covers: Unauthorised acts causing or risking serious damage to human welfare, environment, economy, or national security
Section 3A: Making, supplying or obtaining articles for computer misuse: Up to 2 years imprisonment (10 years for serious cases)
Section 3A defence: Legitimate purposes (security research, authorised testing, vulnerability disclosure)
Key principle: Good intentions alone are not a defence - written authorisation required for security activities
Territorial scope: Applies to offences with UK nexus (offender or victim in UK, or significant link to UK)

Upcoming legal reform

In December 2025, the government committed to introducing a statutory defence for legitimate security researchers. Until this reform takes effect, you must still obtain written authorisation for all security testing.

Computer Misuse Act reform - statutory defence for researchers (2025)

The UK government's December 2025 commitment to reform the Computer Misuse Act to provide legal protection for legitimate security researchers conducting vulnerability research.

In December 2025, the UK government committed to reforming the Computer Misuse Act 1990 to introduce a statutory defence for legitimate security researchers. This addresses longstanding concerns that the 35-year-old law criminalises beneficial security research.

Security Minister Dan Jarvis announced that individuals who responsibly identify and disclose vulnerabilities will be protected from prosecution, provided they comply with specific safeguards.

Government announcement: December 2025 (FT Cyber Resilience Summit)
Proposed change: Statutory defence allowing researchers to identify and report vulnerabilities without fear of prosecution
Safeguards required: Compliance with responsible disclosure practices (details to be confirmed)
What is not protected: "Hacking back" - offensive activities that disrupt or degrade systems remain illegal
Campaign background: CyberUp Campaign led the push for reform since 2020
Industry support: Backed by CREST, techUK, NCC Group, WithSecure, McAfee, Trend Micro
Survey finding (pre-reform): 60% of security professionals said CMA acted as barrier to working effectively
Competitive disadvantage: 80% of professionals said outdated law put UK at disadvantage vs countries with clearer legal frameworks
Countries with better protections: Netherlands, France, US, Belgium, Germany, Malta
Current status: Commitment made - awaiting legislative vehicle (possibly amendment to existing bill)
Until reform takes effect: Written authorisation remains essential for all security testing activities

Conduct legitimate security testing

You can conduct security testing legally if you follow proper procedures. The key requirement is written authorisation from the system owner before you begin.

Requirements for legitimate security testing under CMA

Steps to ensure penetration testing, vulnerability research, and bug bounty activities comply with the Computer Misuse Act 1990 and avoid criminal liability.

Security testing activities (penetration testing, vulnerability scanning, bug bounty research) are lawful when properly authorised. Without written authorisation, even well-intentioned security research can constitute a criminal offence.

The key principle: You must have explicit, documented permission before accessing any system you do not own or control.

Step 1: Written authorisation: Obtain signed authorisation specifying systems in scope, testing methods permitted, timeframe, and contact details
Who can authorise: System owner or person with legal authority to grant access (not just IT department)
Step 2: Define scope clearly: IP addresses, domains, applications, excluded systems (production data, third-party systems)
Step 3: Document test boundaries: What testing methods are permitted (automated scanning, manual testing, social engineering, physical access)
Step 4: Agree data handling: What happens if sensitive data is accessed during testing, reporting procedures, evidence retention
Step 5: Emergency contacts: Named individuals to contact if testing causes unintended disruption
Bug bounty essential terms: Explicit scope, safe harbour commitment, response timeframes, disclosure policy
Responsible disclosure timing: Typically 90 days from initial report before public disclosure (align with NCSC guidance)
What authorisation does not cover: Third-party systems (hosting providers, cloud platforms, CDNs) unless separately authorised
Cloud platform testing: AWS, Azure, GCP have specific penetration testing policies - check provider requirements
Common mistake: Assuming "we own the data" means you can test systems - must have authorisation for the systems themselves
Record retention: Keep authorisation documents for at least 3 years after testing completion

TECHNOLOGY & DIGITAL Requirement

Security testing businesses face particular CMA risks because testing is your core activity. Take these additional steps:

Professional indemnity insurance: Ensure your policy covers CMA-related claims
CREST or equivalent certification: Demonstrates industry-standard practices and may support a legitimate purpose defence
Scope validation process: Verify the person signing authorisation has legal authority to grant access
Third-party system checks: Confirm whether target systems include third-party infrastructure (cloud providers, CDNs) requiring separate authorisation
Incident escalation: Have procedures if testing reveals evidence of existing compromise or illegal activity

Consider joining the CyberUp Campaign to support ongoing legal reform efforts.

Bug bounty programmes

If you run a bug bounty programme, include clear legal terms to protect researchers:

Explicit scope: List which domains, IP addresses, and applications are in scope
Safe harbour commitment: Commit not to pursue legal action against researchers who follow your rules
Response timeframes: State how quickly you will acknowledge and triage reports
Disclosure policy: Clarify when (if ever) researchers can publicly disclose findings
Out-of-scope activities: Explicitly prohibit social engineering, physical access, denial of service testing

Use the NCSC Vulnerability Disclosure Toolkit to create your programme terms.

If you suspect a breach of your systems

When responding to suspected intrusions:

Preserve evidence: Do not modify or delete logs - these may be needed for prosecution
Document your actions: Record what you discover and when, in case you need to demonstrate you acted lawfully
Do not "hack back": Accessing the attacker's systems is itself a CMA offence, even in retaliation
Report to authorities: Report to Report Fraud (0300 123 2040) in England, Wales, and Northern Ireland, or Police Scotland (101) in Scotland
Consider personal data: If personal data was accessed, assess whether ICO notification is required within 72 hours

Get written authorisation before testing

Obtain signed authorisation specifying systems in scope, permitted methods, timeframe, and emergency contacts before any security testing
Verify authorisation authority

Confirm the person signing has legal authority to grant access - not just IT department approval
Check third-party system requirements

Identify any cloud providers, CDNs, or hosting platforms in scope and check their penetration testing policies
Document scope boundaries

Record what is in scope, what is excluded, and what testing methods are permitted
Establish responsible disclosure timelines

Agree reporting procedures and typical 90-day disclosure window aligned with NCSC guidance
Retain authorisation records

Keep authorisation documents for at least 3 years after testing completion
Review bug bounty programme terms

Ensure programmes include explicit scope, safe harbour commitment, and clear disclosure policy
Train security teams on CMA requirements

Ensure all staff conducting security testing understand legal boundaries and documentation requirements

Business Context Testing

Content Graph

Guvnor

Computer Misuse Act Compliance

Criminal offences and penalties

Upcoming legal reform

Conduct legitimate security testing

If you run a penetration testing or security consultancy business

Bug bounty programmes

If you suspect a breach of your systems

Get written authorisation before testing

Verify authorisation authority

Check third-party system requirements

Document scope boundaries

Establish responsible disclosure timelines

Retain authorisation records

Review bug bounty programme terms

Train security teams on CMA requirements

Compliance Assistant

🧪 Business Context Testing

◉ Content Graph

Criminal offences and penalties

Upcoming legal reform

Conduct legitimate security testing

If you run a penetration testing or security consultancy business

Bug bounty programmes

If you suspect a breach of your systems

Get written authorisation before testing

Verify authorisation authority

Check third-party system requirements

Document scope boundaries

Establish responsible disclosure timelines

Retain authorisation records

Review bug bounty programme terms

Train security teams on CMA requirements

Related guides in Digital & Technology

Business Context Testing

Content Graph