Everything a pentester does—scanning, exploiting, accessing data—would be a crime if done without permission. What turns this activity into a legitimate and valuable profession is not the technique, but the framework of authorization, ethics, and legality that surrounds it. This is, without exaggeration, the most important lesson of the module: a technically brilliant professional who is careless about authorization is a danger to their client, to third parties, and to themselves. Here we will see which documents and principles underpin a responsible engagement, and we will apply them to the contract and the Rules of Engagement of TechNova S.L.

Important legal notice: this lesson is for educational purposes only and does not constitute legal advice. Laws vary enormously between countries and change over time. Before any real work, always consult a legal professional in your jurisdiction and make sure every document has been reviewed by a lawyer.

1. Written authorization: the line you don't cross
2. Contract, scope, and Rules of Engagement (RoE)
3. Legal framework: regulations and computer crimes
4. Confidentiality and data handling
5. Ethical limits and responsibility
6. TechNova's contract and RoE (scope template)

The difference between a pentester and a criminal is the explicit, informed, written consent of the system's owner (or of whoever has legal authority over it). Without that document:

• There is no pentest: there is unauthorized access, which in most jurisdictions is a crime.
• There is no possible legal defense: "I wanted to help" or "I was just looking" does not absolve you of responsibility.
• There is no protection for the pentester: if something breaks, you are the one who answers for it.

Authorization must be prior to the start of any testing, explicitly cover the systems you are going to touch, and be signed by someone with real authority to grant it. A delicate and frequent point: if an asset is hosted with an external provider (hosting, cloud), you may also need that third party's authorization. Never assume that "it belongs to the client, so I can."

Three documents (often merged into one) underpin the framework of the work:

The scope is the explicit list of what is in-scope and what is out-of-scope. Anything not clearly in is considered out. A good scope includes:

• Specific IP ranges, domains, and applications that may be tested.
• Systems or data expressly excluded (for example, critical production).
• Permitted and prohibited test types.

The RoE translate the scope into day-to-day operational rules:

• Time windows allowed for testing (for example, outside business hours).
• Prohibited techniques (typically denial-of-service attacks, which aim to take the service down).
• Handling of sensitive data: what may be viewed, what must not be extracted.
• Emergency procedure: whom to notify and how to stop if something goes wrong or a real pre-existing compromise is detected.
• Contacts for both parties, available during the test.

The pentester operates in a regulated environment. Without giving specific legal advice, it is worth knowing two broad areas:

• Computer crimes: virtually all countries criminalize unauthorized access to systems, interception of communications, or computer damage. Written authorization is what puts your work on the right side of those laws. There are well-known reference frameworks (for example, the CFAA in the US or the Budapest Convention at the international level), but what applies depends on your jurisdiction.
• Data protection: regulations such as the GDPR (General Data Protection Regulation, in the European Union) impose strict obligations on personal data. During a pentest it is very possible to run into customers' personal data (TechNova's, for one); mishandling it can lead to serious penalties, regardless of whether the test was authorized.

We repeat the warning: this is a general map, not a legal guide. Every project needs review by a legal professional in the relevant country.

A pentester accesses extremely sensitive information: vulnerabilities, credentials, customer data. Trust is part of the service. Best practices:

• Non-disclosure agreement (NDA): a formal commitment not to disclose anything that is found.
• Minimization: access only what is necessary to demonstrate the finding. If a SQL injection gives you access to the customer database, it is enough to demonstrate the access; do not download the entire table of real data.
• Secure storage: encrypt the evidence and the report; protect them as the critical asset they are.
• Destruction: when finished, securely delete the client's data as agreed.
• Secure channel for the report: the report is a map of how to attack the client; deliver it through an encrypted medium, never by unprotected email.

Beyond the law, there is a layer of professional ethics. Some principles:

• Act only within scope. Curiosity does not justify going outside; if you see something interesting out of scope, you document it and ask—you don't exploit it.
• Do no unnecessary harm. Minimize the impact on the systems and on business availability.
• Report honestly. Don't exaggerate severity to impress, nor hide flaws for convenience.
• Responsible disclosure. If you discover a serious vulnerability, report it first to the person responsible and give them time to fix it before making it public.
• Know your limits. If a finding exceeds your competence, say so. Honesty protects the client.

Responsibility is personal: the framework protects you if you act within it, but it does not absolve you if you deliberately breach it.

Let's apply all of this to our case. Below is a simplified template of the scope and RoE for TechNova's engagement. It is an educational example, not a legal document ready to use.

Notice how this template captures the decisions we had been making: the test type from lesson 01-02 (gray box, external + internal) appears in point 2; the authorized, lab-based nature, in point 1. The scope is not a formality: it is the boundary that makes your work legal. Everything you do on TechNova, from Module 2 onward, must fit within this document.

• Starting before you have the signature. Not a single ping before the authorization is signed. It is the most serious and most common mistake.
• Ambiguous scope. "The company network" is not a scope; "10.10.10.0/24, excluding X" is. Ambiguity is interpreted against you.
• Going out of scope out of curiosity. Seeing an interesting system out of scope and "taking a look" can turn a legal job into a crime.
• Downloading real data. Demonstrating access is enough; exfiltrating real personal data can violate the GDPR even if the test is authorized.
• Treating the template as a final legal document. Every template must go through review by a lawyer before being used in a real project.
• Tip: when in doubt about whether something is in scope, the default answer is no: stop, document the doubt, and ask the client in writing.

Exercise 1. During the TechNova test you discover that the store links to a payment gateway hosted at pagos.otroproveedor.com, which does not appear in the scope. Can you test it? Justify your answer.

Exercise 2. Explain why it is bad practice to download the full table of real customers after finding a SQL injection, even though the pentest is authorized. What would you do instead?

Exercise 3. Draft three additional Rules of Engagement you would add to the TechNova document and briefly explain which risk each one mitigates.

Solution 1. No. pagos.otroproveedor.com is out of scope and, moreover, belongs to a third party. Testing it without that provider's authorization would be unauthorized access, regardless of whether TechNova is their customer. The right thing to do is to stop, document the finding (the existence of the link), and ask the client in writing whether they want to expand the scope and arrange the third party's authorization.

Solution 2. Because exfiltrating real personal data unnecessarily increases risk: it may breach data-protection regulations such as the GDPR, it exposes the client if that data leaks from your systems, and it goes against the principle of minimization. Authorization to test is not authorization to take data away. Instead, it is enough to demonstrate access: for example, showing the number of records, a few anonymized fields, or a query that proves the table could be read, without downloading it in full.

Solution 3. Valid examples (three are enough): 1) "All evidence containing personal data will be anonymized in the report" — mitigates the exposure of customer data in the deliverable. 2) "The pentester will notify within 2 hours any critical vulnerability that allows full compromise" — reduces the exposure time to serious flaws. 3) "Exploits of dubious reliability will not be run against production systems without prior written authorization" — protects business availability against exploits that could take a service down. (Other reasonable answers about time windows, contacts, or prohibited techniques are also valid.)

We have seen that ethics and legality are not an appendix to pentesting, but its foundation: written authorization, an unambiguous scope, clear Rules of Engagement, respect for the legal framework (computer crimes, GDPR), and honest professional conduct are what separate a legitimate audit from a crime. We have captured all of this in TechNova's scope and RoE template, which will govern every action for the rest of the course. And we have stressed the key warning: all of this requires review by a legal professional in your jurisdiction.

With the ethical-legal framework in place, we are missing only one piece to complete the preparation: how we will work methodically and in a way recognized by the industry. In the next lesson, 01-05 Industry Methodologies and Standards, we will look at the reference frameworks (PTES, OWASP, OSSTMM, NIST, MITRE ATT&CK) that will give TechNova's audit professional rigor and structure.