Penetration Testing Fundamentals

Penetration testing is the practice of simulating an attacker's actions against a system, network, or application with the owner's explicit permission, in order to identify weaknesses before a real adversary does. The single feature that distinguishes a penetration test from a crime is authorisation. Accessing a computer system without permission is illegal in essentially every jurisdiction, regardless of intent, and 'I was just testing security' is not a defence. Laws such as the U.S. Computer Fraud and Abuse Act (CFAA), the UK Computer Misuse Act, and similar statutes elsewhere criminalise unauthorised access to computer systems even when no damage occurs.

Before a tester runs a single command against a client's infrastructure, there must be a written, signed agreement that defines exactly what may be tested, when, how, and by whom. This is not bureaucratic overhead — it is the legal instrument that converts what would otherwise be a criminal act into a professional service. Every technique taught in this course assumes it is being practised either in a lab you own, or against a target for which you hold documented, current, written authorisation.

A penetration test engagement typically begins with a scoping conversation between the testing team and the client. Scoping defines the boundaries of the assessment: which IP ranges, domains, applications, or physical locations are in scope; which are explicitly excluded; whether testing is 'black box' (no prior knowledge), 'grey box' (partial knowledge, such as user credentials), or 'white box' (full knowledge, including source code); and what testing techniques are permitted or forbidden (for example, whether denial-of-service style testing is allowed).

The Rules of Engagement (RoE) document builds on the scope to cover operational details: testing windows (can testing happen during business hours, or only overnight?), emergency contacts on both sides in case something goes wrong, how the tester should handle discovery of sensitive data such as personal records, escalation procedures if a critical vulnerability is found mid-engagement, and the 'get out of jail free' authorisation letter the tester carries to prove they are conducting sanctioned work. Third-party considerations matter too — if the target environment is hosted on cloud infrastructure (AWS, Azure, GCP), the cloud provider's own penetration testing policies must be checked, since some activities require separate provider notification.

If you want a concrete starting point for how a scoping document is structured in practice, this site's downloads section includes a Penetration Test Scope Questionnaire — a pre-engagement template covering network scope, exclusions, rules of engagement, and authorisation sign-off. Reviewing a real template like that is a good way to see how the concepts in this module translate into an actual working document.

Engagements vary by objective. A network penetration test focuses on infrastructure — servers, firewalls, routers, internal segmentation. A web application penetration test focuses on a specific application's logic, authentication, and data handling. A red team engagement is broader and more adversarial in style, often testing detection and response capabilities rather than just finding vulnerabilities, and may run over weeks with the defending 'blue team' unaware. A physical or social engineering engagement tests human and physical controls, such as tailgating into a building or phishing employees.

Understanding which type of engagement you are conducting shapes everything downstream: the reconnaissance techniques you use, the tools appropriate for the job, and how findings should be reported. This course focuses primarily on the network and web application testing path, since it forms the technical foundation that other engagement types build on.