The Legal Framework of Penetration Testing

You now have a lab, a good grasp of networks, Linux, Windows and cryptography. The next courses of this track teach you how to test systems the way an attacker would, in order to protect them. Before taking that step, you must master the one thing that separates a penetration tester from a criminal: the law. This lesson is the detailed legal briefing, and it is the most important lesson of the course. Read it twice.

We have repeated a rule since chapter 1: never test a system that you do not own or are not explicitly authorised to test. Here we see where that rule comes from, what exactly the law says, what a valid authorisation looks like, and what to do when you discover something you were not looking for.

The principle in one sentence

An action on a computer system is lawful when the owner of that system has authorised it, within a defined scope; outside that authorisation, it may be a criminal offence, whatever your intentions. Penetration testing is therefore not a special exemption from the law: it is ordinary activity made legal by a contract and an explicit permission.

France: the Code pénal, articles 323-1 to 323-8

The French Code pénal groups the offences against automated data processing systems (in French, "systèmes de traitement automatisé de données", STAD) in Chapter III of Title II of Book III. The main articles are:

Article	What it punishes, in plain language
323-1	Fraudulently accessing, or remaining, in all or part of a STAD. Penalties are increased when the access results in the deletion or modification of data, or in an alteration of the system's operation, and are higher again when the system processes personal data implemented by the State.
323-2	Hindering or distorting the operation of a STAD. Denial-of-service attacks and destructive tests fall here.
323-3	Fraudulently introducing, extracting, holding, reproducing, transmitting, deleting or modifying data in a STAD.
323-3-1	Importing, holding, offering, giving or making available, without legitimate reason (notably research or computer security), equipment, an instrument, a program or data designed or specially adapted to commit the offences above.
323-4	Participating in a group or an agreement formed to prepare one of these offences.
323-7	The attempt is punished like the offence itself.

Several lessons follow from this table:

• Access alone is enough. Article 323-1 does not require damage or theft. Entering a system you are not allowed to enter, or staying in after you realise you should not be there, is the offence.
• "Fraudulently" is the key word: the access is without right, or against the owner's will. Courts have looked at whether security measures were circumvented, but a system does not need to be protected for unauthorised access to be an offence. A password is not a condition of illegality.
• Attempts count. A failed attempt, such as a scan that tries to enter, can still be punished.
• Tools can be an offence when held without legitimate reason. Your lab, your notes and your training platforms are your legitimate reason: keep them clearly tied to learning or to a contract.
• Penalties include imprisonment and fines and, for the more serious cases, supplementary penalties. For current values, read the texts on Légifrance rather than relying on any summary.

Other articles may apply to the same behaviour: the violation of the secrecy of correspondence (intercepting messages), and the rules on the protection of personal data, which carry heavy sanctions in their own right. And remember that civil liability exists too: a tester who breaks something can be asked to pay for the damage.

Responsible reporting in France

What if you find a vulnerability by chance, in good faith? French law offers one specific channel: a person acting in good faith who reports a vulnerability to the national authority, ANSSI, has a mechanism provided by the Code de la défense (article L. 2321-4) that allows the information to be sent to ANSSI, which can handle it with confidentiality. This is not a licence to hunt for flaws on systems you do not own. It is a way to report what you stumbled upon without making things worse. Find the current contact procedure on cyber.gouv.fr. The platform cybermalveillance.gouv.fr helps victims of cyberattacks find assistance.

Many organisations publish a vulnerability disclosure policy, often in a file named security.txt at a standard location of their website, describing how to report an issue and what is allowed. Reading and following such a policy is the baseline. Organisations that run a bug bounty programme explicitly define the scope, the rules and the rewards. Testing outside that scope is still unauthorised, and the next courses return to this subject. The principle known as coordinated disclosure means you report the issue privately to the owner, give them a reasonable time to fix it, and do not publish exploitation details before then.

International frameworks

You will not always work under French law. Some well-known texts, to be aware of:

• European Union: a directive on attacks against information systems asks member states to criminalise illegal access, illegal system interference, illegal data interference and the misuse of tools. French law transposes it, so the logic is the same across the EU, with national differences in details.
• The Budapest Convention on cybercrime, a Council of Europe treaty signed by many countries worldwide, which harmonises these offences and facilitates international cooperation.
• United States: the Computer Fraud and Abuse Act, which criminalises access "without authorisation" or "exceeding authorised access", with civil liability too.
• United Kingdom: the Computer Misuse Act, with similar categories of offences.

The important consequence: an action can be illegal in several countries at once, for instance when you are in one country and the target is in another. "I did it from abroad" is not a defence. When you work on cloud environments, you must also respect the terms of the provider, which often require notification or approval before security testing and forbid certain tests such as denial of service.

What makes an authorisation valid?

A verbal "go ahead" is not enough. A professional penetration test starts with documents, which you will write in detail in course 4. At minimum:

• Written authorisation signed by someone who has the authority to grant it for these systems. Be careful about ownership: the person you speak to may not own the servers (they may belong to a hosting company or a cloud provider, whose agreement is also needed), or the web application may include third-party components.
• A precise scope: the list of systems, addresses, domains and applications that you may test, and, as importantly, what is out of scope.
• The rules of engagement: which techniques are allowed or forbidden, the testing hours, the maximum intensity (for example, no denial-of-service tests), and how to handle sensitive data.
• Contacts and an emergency procedure: who to call immediately if something breaks, or if you find evidence of a real attacker already inside.
• The duration of the authorisation: start and end dates.
• Confidentiality and data-handling clauses, consistent with data protection rules such as the GDPR.
• The liability and insurance framework.

Some people call the written permission a "get out of jail free" letter. It is not: it will not protect you if you go beyond it. The scope is the boundary. Anything you do outside it is on you.

What to do when things go wrong

• You reach something out of scope (a neighbouring server, a system of a third party): stop, do not explore, document what happened, and tell your client contact promptly.
• You find personal data or sensitive documents: access only what is strictly needed to demonstrate the flaw, do not copy it, and report it.
• You find signs of a real attacker: stop and use the emergency contact immediately; this is an incident, not a test.
• You are asked to do something outside the agreement: refuse, or have the authorisation updated in writing first.

The ethics behind the law

Law is a minimum. Professionals also follow ethical commitments: minimise harm, protect confidential information, be honest in reports, and not exploit what they find for any personal gain. Certification bodies and professional organisations publish codes of ethics that members commit to follow, and breaking them can end a career as surely as breaking the law. The reputation of a tester is their main asset.

Your turn: classify these situations

For each case below, decide whether it is acceptable, and justify your answer with the principles of this lesson.

1. You scan the IP addresses of your own lab network (10.10.10.0/24) from your Kali VM.
2. A friend runs a small online shop and says "go ahead, tell me if you find anything". There is no document, and the shop is hosted by a third-party company.
3. While browsing a public website, you notice that changing a number in the address shows another customer's invoice. You are curious and try a few more numbers to see how far it goes.
4. You practise a web exercise on a deliberately vulnerable application running in your lab, and on a training platform that explicitly allows attacks on its challenges.
5. During an authorised test, you notice that an IP address just next to your target range responds, and is not listed in the scope.

See a solution

1. Acceptable. It is your own isolated lab. 2. Not acceptable as it stands. The friend may not have the authority over the hosting platform, and an oral approval is not a written, scoped authorisation; the hosting company's rules and agreement may be required. The right way is to get a written agreement covering the exact systems, with the host's approval if needed. 3. The first observation was accidental, but trying more numbers is unauthorised access to other people's personal data and potentially an offence. The responsible action is to stop, not to access further invoices, and to report the flaw to the site owner (or to ANSSI for France), describing only what you saw. 4. Acceptable, within the rules of the platform. 5. Out of scope: do not touch it. Note it and inform your client contact, who can extend the scope in writing if they want it tested.