A penetration tester starts by defining the test’s scope, objectives, and boundaries to stay aligned with regulations and industry standards. Setting clear rules of engagement, securing agreements like NDAs, and choosing the right targets ensures a legal and effective test. Different assessments—such as vulnerability, network, application, and API testing—cover specific security areas for a full risk overview. A shared responsibility model keeps everyone on the same page, while ethical and legal requirements, like authorization letters and reporting standards, are strictly followed. Careful documentation ensures a structured, transparent, and secure testing process.
<aside>
<img src="/icons/target_red.svg" alt="/icons/target_red.svg" width="40px" />
Mission Objectives
- Explain how to define the scope of a penetration test
- Compare and contrast agreement types used in preparing for a PenTest
- Describe the shared responsibility
- Discuss pre-engagement documentation and planning
</aside>
1. Define the Scope
The scope is the "North Star" of the engagement. It defines what is fair game and what is strictly off-limits to prevent downtime or legal issues.
- Asset Identification: Identifying IP addresses, CIDR blocks, domains, and physical locations.
- Exclusions: Explicitly listing "Out-of-Scope" assets (e.g., legacy servers, third-party APIs).
- Timeline: Defining start/end dates and "Restricted Windows" (e.g., no testing during peak business hours).
- Constraints: Identifying limitations like bandwidth throttling or restricted tools.
2. Compare Types of Assessments
Some of the more common types of assessments are as follows:
- Compliance-based assessments are used to fulfill the requirements of a specific law or standard, such as GDPR, HIPAA, or PCI DSS. For example, PCI DSS clearly defines what should be included in the assessment. Other standards provide guidance on how you can ensure your organization is in compliance. For example, the HIPAA Security Rule has a crosswalk that maps to the NIST Cybersecurity Framework.
- Red team/blue team-based assessments use two opposing teams in a PenTest or incident response exercise. The red team simulates the "hostile," or attacking, team, while the blue team acts as the defensive team. The goal of this assessment is to determine whether the red (attacking) team is able to circumvent security controls as well as how the blue (security) team will respond to the attack.
- Goals-based/objectives-based assessments have a particular purpose or goal. For example, a new point of sale (PoS) system that accepts credit cards might be PenTest-ed for any security issues prior to implementation.
Choosing the right "Box" determines how much information the tester starts with and how realistic the simulation is.
| Type |
Knowledge Provided |
Goal |
| Black Box |
Zero knowledge |
Simulates an external, unauthenticated attacker |
| Gray Box |
Partial knowledge |
Simulates a disgruntled employee or a focused breach. |
| White Box |
Full knowledge |
Comprehensive audit; finding "needle in the haystack" bugs. |
3. Utilize the Shared Responsibility Model
When testing Cloud environments (AWS, Azure, GCP), you must understand where the client's authority ends and the provider's begins.
- Infrastructure as a Service (IaaS): Tester can usually assess the OS and apps, but not the physical host.
- Software as a Service (SaaS): Testing is strictly limited to configurations; attacking the underlying platform is illegal.