LinkedInInstagramXTikTok

Penetration testing and the law: getting authorisation and scope right

Penetration testing — deliberately probing your systems for weaknesses before attackers find them — is one of the most effective ways to improve security. But the same activity that is valuable when authorised can be a criminal offence when it is not. Getting the legal framework right is as important as the testing itself. This guide explains the rules and how to commission a test safely.

Why the law is involved at all

Accessing a computer system without authorisation is a criminal offence across the EU. In Sweden it is captured by the offence of unlawful data intrusion (dataintrång) in the Criminal Code, and the EU Directive on attacks against information systems requires all member states to criminalise unauthorised access and interference. The decisive factor is authorisation: the identical technical act is lawful when the system owner has genuinely agreed to it and unlawful when they have not.

Authorisation must be clear and in writing

A verbal “go ahead” is not enough. Before any test begins, the tester and the client should agree written terms that record who has authorised the work, exactly which systems and addresses are in scope, what techniques are permitted, and the time window for the activity. This is often set out in an engagement contract together with a specific authorisation letter, sometimes called a rules-of-engagement document. It protects both sides: the tester has a defence to any allegation of unauthorised access, and the client keeps control of what is done to its systems.

Scope: define what is in, and what is out

Scope is where most problems arise. A test that strays onto systems that were not authorised — a neighbouring server, a shared platform, an unexpected connected service — can cause outages and cross the line into unlawful access. The scope document should list targets precisely, identify anything expressly off-limits, and set escalation contacts so the tester can pause and check rather than press on when something unexpected appears.

Testing systems you do not own

Many businesses run on cloud and third-party platforms. You cannot authorise testing of infrastructure you do not control. Where a target is hosted by a provider, check the provider’s terms and obtain any consent or notification they require before testing. Ignoring this can breach the provider’s contract as well as the law.

Data protection during and after the test

A test may expose the tester to personal data held in your systems. Treat that as a processing activity: put a data processing agreement in place, limit what data the tester handles, and require secure handling and deletion of findings that contain personal or sensitive information. The final report itself is sensitive — it is a map of your weaknesses — and should be stored and shared with care.

After the test

The value of a test lies in what you do with it. Agree in advance how vulnerabilities will be reported, prioritised and retested once fixed, and how long the tester may retain evidence. Feeding results into your remediation and governance processes turns a one-off exercise into lasting improvement.

How Lawgent can help

Lawgent helps businesses put the right legal framework around security testing — from engagement terms and authorisation to data-protection and provider considerations. Contact us to make sure your testing programme is both effective and lawful.

0Varukorg0,00 €

Inga produkter i varukorgen.

Gå tillbaka till butiken