Planning and Scoping (TryHackMe)

Link to Planning and Scoping room on TryHackMe: Planning and Scoping

Introduction

You just landed your first consulting engagement. A mid-sized e-commerce company, BrightCart, has been in the news for all the wrong reasons: they suffered a data breach last quarter, and BrightCart's board is now asking a pointed question. "Could the same thing happen to us again?" They have firewalls, an antivirus solution, and a password policy in place. But are those measures actually working? The board wants proof, and that is where you come in.

Securing a company is not a one-time event; it is a continuous process of building defenses and testing them. In the analog world, you do not simply install a lock on your bicycle and unquestioningly trust it. You tug on it. You try to pick it. You act like a thief to verify that the lock does its job. The digital world follows the same logic, except the "lock" is a combination of security policies, firewalls, intrusion detection systems, and access controls, and the "thief" is a skilled professional hired to test them.

The challenge is that testing the security of computer systems is far more complex than tugging on a bicycle lock. A company's attack surface can span web applications, internal networks, cloud infrastructure, APIs, and mobile apps. Each of these requires specialized skills and tools to evaluate properly. For this reason, organizations rely on penetration testers, authorized professionals who simulate real cyber attacks to find vulnerabilities before malicious actors do.

The keyword in that definition is authorized. Without explicit, documented authorization from the client organization, a penetration test is indistinguishable from a criminal attack. As we will see throughout this room, the planning, scoping, and legal groundwork that happen before a single packet is sent are what separate a professional engagement from an illegal intrusion.

Prerequisites

This room builds on concepts introduced in the Guided Pentest: Infrastructure and Dive Into Pentesting rooms. You should be comfortable with the general idea of what a penetration test looks like from end to end before diving into the planning and scoping details covered here.

Learning Objectives

• Explain what a penetration test is and how it differs from a vulnerability assessment

• Distinguish between known environment, partially-known environment, and unknown environment approaches

• Define the scope of a penetration test and identify the risks of scoping errors

• Identify the legal documents and authorizations required before testing begins

• Describe the key components of a Rules of Engagement document

• Recognize the major regulatory frameworks that mandate or recommend penetration testing

• Apply planning and scoping concepts to a realistic client scenario

Answer the questions below

What is the keyword that separates a penetration test from a criminal cyber attack? authorization

What is Penetration Testing?

Let's return to BrightCart, the e-commerce company from the previous task. Their board has approved the budget, and they are ready to bring in a penetration testing team. But before the testers open a terminal, it is worth asking a foundational question: what exactly are they being hired to do?

A penetration test is a comprehensive security assessment in which authorized professionals simulate real cyber attacks against an organization's systems, networks, or applications. The goal is to discover security vulnerabilities and demonstrate their potential impact before a malicious actor can exploit them. Two words in that definition deserve special attention: authorized and simulate. The testers have explicit permission to attack, and they do so in a controlled manner designed to evaluate risk without causing lasting harm.

In other words, a penetration test helps evaluate an organization's security posture. More specifically, a penetration test aims to:

• Identify security vulnerabilities resulting from software flaws, misconfigurations, weak credentials, or design errors

• Assess the impact of successful exploitation so the organization can gauge the true severity of each finding

• Evaluate the effectiveness of existing security solutions and defensive measures

• Produce a report with actionable recommendations for improving the organization's defenses

From the client's perspective, the penetration test answers a simple but critical question: "Where are we exposed, how bad could it get, and what do we do about it?" The penetration tester should keep this perspective in mind throughout the engagement. Every finding, every exploit, and every recommendation ultimately serves the client's need to protect their assets and their users.

The Penetration Testing Lifecycle

A penetration test follows a structured process from start to finish. Several industry frameworks define this lifecycle; the most widely referenced is the Penetration Testing Execution Standard (PTES)(opens in new tab), which divides a penetration test into seven phases:

1. Pre-engagement Interactions: Defining scope, rules, and legal agreements before any testing begins

2. Intelligence Gathering: Collecting information about the target using passive and active reconnaissance

3. Threat Modeling: Identifying the most likely attack scenarios based on gathered intelligence

4. Vulnerability Analysis: Systematically discovering weaknesses in the target systems

5. Exploitation: Attempting to leverage discovered vulnerabilities to gain unauthorized access

6. Post Exploitation: Determining the value of compromised systems and maintaining access for further analysis

7. Reporting: Documenting findings, impact, and remediation guidance for the client

Notice that only two of these seven phases (Exploitation and Post Exploitation) involve the hands-on "hacking" that most people picture when they hear "penetration test." The bulk of a professional engagement is planning, analysis, and reporting. This room focuses on phase 1, Pre-engagement Interactions, the planning and scoping work that makes everything else possible.

It is worth noting that PTES was last updated in 2014. Despite its age, it remains the most commonly cited lifecycle framework in the industry and is referenced by compliance standards such as PCI DSS. The previous room in this path, Penetration Testing Frameworks, covers PTES and other frameworks in greater depth.

Penetration Testing vs. Vulnerability Assessment

A question that often comes up early in a cyber security career: how is a penetration test different from a vulnerability assessment? The two are complementary but distinct.

One analogy would be visiting your doctor for a routine checkup versus undergoing a cardiac stress test. The checkup (vulnerability assessment) runs a broad set of standard tests, flags anything abnormal, and hands you a list of results. The stress test (penetration test) pushes your system to its limits under controlled conditions to see exactly how and where it fails. Both are valuable; they answer different questions.

In technical terms:

• A vulnerability assessment is broad but shallow. It primarily relies on automated scanning tools (e.g., Nessus, OpenVAS, or Qualys) to identify known vulnerabilities across a wide range of systems. The output is a categorized list of weaknesses with severity ratings. Automation does most of the work.

• A penetration test is narrow but deep. It is a predominantly manual, human-driven exercise where the tester actively exploits vulnerabilities to demonstrate real-world impact. The tester chains findings together, escalates privileges, and moves laterally, just as a real attacker would. The output is a detailed narrative of what was achieved, what data was accessed, and how far the tester got.

Organizations benefit from running vulnerability assessments frequently (quarterly or even monthly) for ongoing hygiene, then conducting penetration tests periodically (annually or after major changes) to validate which exposures translate into real risk. One does not replace the other.

Answer the questions below

According to PTES, how many phases does a penetration test have? 7

Which type of security assessment relies primarily on automated scanning tools and produces a categorized list of known weaknesses? vulnerability assessment

In the PTES lifecycle, which phase focuses on defining scope, rules, and legal agreements before any testing begins? Pre-engagement Interactions

Types and Approaches

BrightCart's board has approved a penetration test. Now the conversation shifts to specifics. The Chief Information Security Officer (CISO) asks: "What exactly are we testing, and how much should our testers know going in?" These two questions drive the design of every engagement. What determines the type of test, and how much determines the approach.

Types of Penetration Tests

Penetration tests are categorized by the target technology being assessed. Based on the client organization's needs, a penetration test might focus on one or more of the following:

• Network penetration test: Targeting the organization's internal and external network infrastructure, including routers, switches, firewalls, and servers

• Web application penetration test: Assessing websites, web portals, and their back-end services for vulnerabilities such as SQL injection, cross-site scripting (XSS), and authentication flaws

• Wireless network penetration test: Evaluating the security of Wi-Fi networks, access points, and wireless protocols

• Cloud penetration test: Examining cloud infrastructure configurations, Identity and Access Management (IAM) policies, and storage permissions across providers such as AWS, Azure, or Google Cloud Platform (GCP)

• Mobile application penetration test: Testing iOS and Android applications along with their associated APIs and back-end services

• Physical penetration test: Assessing the physical security controls of a facility, such as badge readers, locks, and surveillance systems

An organization like BrightCart, whose business revolves around an e-commerce web application, would almost certainly need a web application penetration test. If BrightCart also operates internal infrastructure and accepts payments, a network penetration test would be essential as well, particularly given the compliance requirements we will cover in Task 7.

Testing Approaches: How Much Does the Tester Know?

There are different approaches to conducting a penetration test. These approaches are based on how much information about the target environment is shared with the penetration tester before the engagement begins. The company evaluates its needs and decides accordingly.

The three approaches are:

• Known environment: Also known as white-box testing. The client shares comprehensive details about their environment, including network diagrams, system inventories, source code, credentials, and architecture documentation. This approach maximizes vulnerability discovery by allowing the tester to focus on analysis rather than on reconnaissance.

• Partially-known environment: Also referred to as gray-box testing. The tester receives partial knowledge, such as a user account, high-level architecture information, or limited documentation, but does not get full visibility into the environment. This approach balances realism with efficiency.

• Unknown environment: Also known as black-box testing. The tester is given only the minimal information needed to define the scope, often just a company name or an IP range. The tester starts from scratch, simulating an external attacker with no insider knowledge.

A note on terminology: the industry is shifting from color-based "box" labels to knowledge-based "environment" labels. You will encounter both in the field, so it is important to be fluent in either set.

Consider BrightCart's scenario again. If BrightCart wants to discover as many vulnerabilities as possible in their web application, they would opt for a known-environment approach and grant the penetration tester access to the application's source code. After all, it is better for someone working for the company to find every weakness before someone working against the company does. Sharing source code requires the proper legal agreements, specifically a Non-Disclosure Agreement (NDA).

Internal vs. External Testing

Beyond the knowledge-level approach, penetration tests are also categorized by the tester's starting position:

• An external penetration test targets the organization's internet-facing assets, such as web servers, email servers, VPN gateways, DNS infrastructure, and cloud services. The core question is: "Can an outside attacker get in?"

• An internal penetration test evaluates security from within the organization's network. The tester starts with a position that an insider or a post-breach attacker would have. The core question is: "Once an attacker is inside, how far can they go?"

One analogy would be testing the security of a building. An external test checks whether an outsider can get through the front door, the windows, or the loading dock. An internal test assumes someone is already inside the lobby and checks whether they can reach the server room, the executive floor, or the vault. Both perspectives are necessary for a complete picture. In fact, compliance standards such as PCI DSS require both internal and external penetration tests annually.

Red Team vs. Penetration Test

You will sometimes hear the term red team engagement used alongside, or confused with, penetration testing. While they share offensive security techniques, they differ in scope, duration, and objectives:

• A penetration test has a defined, specific scope (such as a web application or an IP range), typically lasts one to three weeks, and operates with the client organization's knowledge. Its goal is to identify and report as many vulnerabilities as possible within the target's scope.

• A red team engagement is organization-wide and can last weeks to months. Red teams test people, processes, and technology simultaneously, often using social engineering, physical intrusion, and technical attacks in combination. Critically, the red team operates in stealth; a key measure of success is whether the organization's defenders (the blue team) can detect the intrusion.

At this stage, a penetration test is the right starting point for BrightCart. Red team engagements require a higher level of organizational security maturity, a mature Security Operations Center (SOC), and a blue team that is ready to be tested. Think of it as a progression: organizations typically start with vulnerability assessments, advance to penetration tests, and eventually conduct red team engagements as their security program matures.

Answer the questions below

A penetration tester is given only the company name and a target IP range, with no additional documentation. What testing approach is this? unknown environment

An organization wants to determine whether an attacker who has already breached the perimeter could reach their database servers. Should they request an internal or external penetration test? internal

Defining the Scope

Consider the following scenario. BrightCart hires a penetration testing team, and after two weeks of testing, the team delivers its report. The CISO reads through it and immediately notices a problem: the testers spent most of their time on the corporate website but never touched the payment processing API, the internal employee portal, or the cloud storage buckets where customer data is kept. Meanwhile, the testers accidentally probed a third-party logistics provider's system that shares a network segment with BrightCart, and that provider is now threatening legal action.

What went wrong? The scope was poorly defined. The testers did not have a clear map of what to test and what to leave alone. This is not a hypothetical problem; it happens in real engagements, and the consequences range from wasted budgets to lawsuits.

What Is Scope?

The scope of a penetration test defines the boundaries of the engagement. It answers two fundamental questions: what systems, networks, and applications are you authorized to test, and what is explicitly off limits?

As we mentioned in the previous task, the word "authorized" is everything in penetration testing. The scope document is where that authorization becomes specific and concrete. You need to know which assets are on the allowlist (in-scope targets you are authorized to test) and which are on the blocklist (out-of-scope assets you must not touch). Without this clarity, you risk two outcomes: skipping systems that should have been tested, leading to a poor, incomplete report, or attacking systems outside your authorization, which invites legal trouble.

What Goes Into a Scope Document?

A well-defined scope covers the following categories:

• Target systems and networks: IP address ranges (both external and internal), domain and subdomain lists, network subnets, and any private or public cloud infrastructure

• Applications and services: Web application URLs, API endpoints, mobile applications, and their associated back-end services

• Wireless networks: SSIDs, access point locations, and wireless protocols to be assessed

• Cloud infrastructure: Specific cloud accounts, regions, IAM configurations, and storage services across providers like AWS, Azure, or GCP

• User accounts and roles: Test accounts provided for authenticated testing, including the privilege levels for each account

Similarly, the scope document specifies out-of-scope assets, typically listed as IP ranges, domains, or services that must not be touched during the engagement. Common reasons for excluding assets include:

• Production databases: Containing live customer data, where any disruption would impact business operations

• Third-party systems: Hosted by vendors or partners that the client does not own and cannot authorize testing against

• Shared infrastructure: Here other tenants or organizations would be affected

• Systems under change freeze: Due to an upcoming release or regulatory audit window

Consider the following example of what a partial scope document might look like for BrightCart:

This table is simplified for illustration, but it captures the essential pattern: every category has an explicit allowlist and blocklist. There is no ambiguity about what the testers can and cannot touch.

The Two Pitfalls: Too Broad and Too Narrow

There are two common scoping errors, and both carry serious consequences.

An excessively broad scope hurts all parties involved. The penetration testing team is forced to spread their efforts across too many systems, leading either to more time to complete the engagement or, more commonly, to shallow, superficial testing that fails to delve deeply into any single target. From the client's perspective, a broad scope means higher costs, delayed reports, and findings that may lack the depth needed to prioritize remediation effectively.

An excessively narrow scope, on the other hand, creates a dangerous blind spot. It is like testing the security of your front door while ignoring the ground-floor windows. An attacker does not care which assets you choose to test; they probe everything. If the scope excludes critical attack vectors, the penetration test yields an inadequate risk assessment and leaves the client with a false sense of security. In regulated industries, an overly narrow scope can also lead to compliance failures. A PCI DSS assessor, for example, will expect the penetration test to cover the entire Cardholder Data Environment (CDE), not just the parts the client felt comfortable testing.

The optimal scope balances thoroughness with practicality. It covers all critical and high-risk assets while remaining achievable within the engagement timeline and budget. Defining that balance is a collaborative process between the penetration testing team and the client; neither side should decide it alone.

Scope Creep

One additional hazard to watch for: scope creep. This occurs when the engagement boundaries gradually expand during the test without a formal amendment to the scope document. For example, the client might casually mention mid-engagement, "Oh, while you are at it, can you also take a look at our new staging server?" Without a documented scope change, this creates ambiguity about authorization and can lead to disputes over deliverables, timelines, and billing.

The remedy is straightforward. Any change to the scope during an active engagement should be documented in writing, approved by both parties, and appended to the original scope agreement before the additional testing begins. A quick email confirmation is better than nothing, but a formal scope amendment is the professional standard.

Answer the questions below

What is the term for the list of systems and assets that the penetration tester is authorized to test? allowlist

BrightCart's penetration test covered only the customer portal but excluded the payment processing API and cloud infrastructure. Is this an example of an overly broad or an overly narrow scope? overly narrow

Pre-Engagement and Legal Foundations

In September 2019, two penetration testers from the security firm Coalfire were arrested and charged with felony burglary(opens in new tab). Their crime? Breaking into a county courthouse in Iowa, exactly as they had been hired to do. The State Court Administration had contracted Coalfire to conduct a physical penetration test of judicial buildings across the state. The testers carried a signed authorization letter. They were doing their job.

The problem was that the county sheriff was unaware of the engagement, and the authorization letter did not clearly establish who had legal authority over the courthouse. The testers spent the night in jail on $50,000 bail each. The state officials who hired them initially distanced themselves from the situation. It took months for the charges to be dropped, and in 2024, Dallas County paid $600,000 to settle the wrongful arrest claim.

This case is not ancient history; it is a direct lesson in why pre-engagement planning and legal documentation are not bureaucratic formalities. They are what keep you out of handcuffs.

Why Legal Foundations Come First

Before a penetration tester opens a terminal, runs a scanner, or sends a single packet, a series of legal agreements must be in place. These documents serve two purposes: they authorize the tester to perform activities that would otherwise be illegal, and they protect both parties by defining responsibilities, boundaries, and expectations.

As we established in Task 1, the word "authorized" distinguishes a penetration test from a criminal attack. The pre-engagement phase is where that authorization becomes a signed, legally binding reality.

The Core Legal Documents

A professional penetration testing engagement typically involves four key documents, executed roughly in this order:

1. Non-Disclosure Agreement (NDA): Signed first, often before any technical details are shared. The NDA, sometimes mutual, ensures that both parties protect confidential information exchanged during scoping discussions and throughout the engagement. It typically defines the scope of confidential information (vulnerability data, network architecture, credentials, test results), the duration of the confidentiality obligation (typically 2 to 5 years), data-handling and storage requirements, and breach notification procedures.

2. Master Service Agreement (MSA): This establishes the overarching legal relationship between the client and the testing firm. It covers liability and indemnification, intellectual property rights, dispute resolution mechanisms, and insurance requirements. An MSA is negotiated once and governs all future engagements between the two parties.

3. Statement of Work (SOW): This is the engagement-specific document. Each penetration test gets its own SOW, which defines the systems to be tested (scope), the methodology and approach, the timeline and milestones, the deliverables (typically a report), and the cost. The key distinction: the MSA sets the relationship rules; the SOW details each specific test.

4. Authorization Letter: Also known as the "get-out-of-jail-free" letter, this document grants explicit written permission to conduct the test. A proper authorization letter includes the tester's full legal name and company, the specific date range of authorized testing, the systems, facilities, or networks covered, the permitted activities (network testing, physical entry, social engineering, etc.), and contact information for at least two client representatives reachable during testing hours. The letter must be signed by someone with undisputed legal authority over the assets being tested, typically a CISO, CIO, CEO, or VP of IT. As the Coalfire case demonstrates, ambiguity over who has the authority to authorize testing can have severe consequences.

The Laws That Apply

Two statutes are particularly relevant to penetration testers operating in the United States and the United Kingdom.

The Computer Fraud and Abuse Act (CFAA), codified at 18 U.S.C. § 1030, is the primary U.S. federal anti-hacking law. It prohibits unauthorized access to protected computers, a category that includes virtually any internet-connected system. Penalties range up to 10 years imprisonment for intentional unauthorized access. In 2021, the U.S. Supreme Court issued a landmark ruling in Van Buren v. United States that clarified the scope of the CFAA. The Court held in a 6-3 decision that "exceeds authorized access" applies only when someone accesses areas of a computer that are entirely off-limits to them, not when they misuse access they otherwise have. The security research community welcomed this narrower interpretation, though it does not eliminate the need for explicit written authorization. In 2022, the Department of Justice further revised its CFAA charging policy to decline prosecution of good-faith security research. This is a prosecutorial guideline, not a statutory safe harbor; a future administration could reverse it, and it does not affect civil liability.

The UK Computer Misuse Act 1990 (CMA) creates three primary offenses: unauthorized access to computer material (Section 1, up to 2 years imprisonment), unauthorized access with intent to commit further offenses (Section 2, up to 5 years), and unauthorized acts impairing computer operation (Section 3, up to 10 years). Unlike the post-Van Buren CFAA landscape, the CMA makes no explicit statutory provision for legitimate security testing. Authorization must be granted by the system owner in explicit, written form. Security industry organizations, including CREST and NCC Group, have called for CMA reform to introduce a statutory defense for good-faith testing. Still, as of early 2026, no such amendment has been enacted.

The takeaway for penetration testers is straightforward: written authorization is not optional. It is existential. Without it, every technique you use, from port scanning to exploitation, is potentially a criminal act under one or both of these statutes.

Cloud Provider Testing Policies

If the client's infrastructure includes cloud services, the penetration tester needs to verify the cloud provider's testing policies. As of 2025, all three major providers permit penetration testing of customer-owned resources without requiring prior approval:

• AWS permits testing on services including EC2, RDS, CloudFront, Aurora, API Gateway, Lambda, Lightsail, and Elastic Beanstalk. DoS testing, DNS zone walking via Route 53, and port flooding are prohibited.

• Microsoft Azure permits testing on customer-owned resources with no prior notification required. DoS testing, cross-tenant attacks, and social engineering of Microsoft staff are prohibited.

• Google Cloud Platform (GCP) has never required notification or prior approval. Tests must target only the tester's own projects and comply with the Acceptable Use Policy.

All three providers strictly prohibit Denial-of-Service (DoS) testing and any testing against other customers' resources. For BrightCart's engagement, the testing team would need to confirm that their AWS testing stays within BrightCart's us-east-1 account (as defined in the scope from Task 4) and avoids any prohibited activities.

Answer the questions below

What is the abbreviation of the legal document that protects confidential information shared between the client and the penetration testing team? NDA

A penetration tester is conducting a cloud security assessment on a client's AWS environment. The client asks the tester to perform a DoS test against their EC2 instances to see how they handle the load. Should the tester proceed? (Yea/Nay) Nay

Rules of Engagement

The term "Rules of Engagement" originated in military doctrine. In that context, Rules of Engagement are the directives that specify when, where, and how military forces can engage adversaries or use force. They ensure that military actions align with strategic objectives while respecting legal and ethical boundaries. They define what can be targeted and what weapons and tactics are permitted.

Penetration testing borrows this concept directly. In a penetration test, the Rules of Engagement (RoE) are the formal agreements that define the operational boundaries of the engagement: what can be tested, when testing can occur, how the parties communicate, and what happens when something goes wrong. If the scope (Task 4) defines what is on the table, and the legal documents (Task 5) establish authorization to be at the table, then the RoE defines how you conduct yourself at the table.

Let's frame it in terms of BrightCart's engagement. The scope says the testing team can assess brightcart.thm, api.brightcart.thm, and the AWS us-east-1 environment. The legal documents authorize the engagement and protect both parties. But the scope and the contracts alone do not answer questions like: Can the testers run scans during business hours? Whom do they call if they accidentally take down the payment API? What happens if they find the CFO's credentials in a plaintext file? The RoE answers all of these.

Components of a Rules of Engagement Document

The RoE covers several operational areas. Let's walk through each one.

Timing and Duration

The RoE specifies the start and end dates of the engagement, along with any time-based restrictions on testing activity. This matters because certain testing activities, particularly aggressive scanning or exploitation attempts, can degrade system performance or trigger alerts that disrupt operations.

Consider BrightCart's situation. Their peak traffic occurs on weekday evenings between 6:00 PM and 10:00 PM, and they run a batch payment processing job every night at 2:00 AM. The RoE might specify that active exploitation testing is permitted only between 10:00 PM and 1:30 AM on weekdays, and freely during weekends, while passive reconnaissance and analysis can be conducted at any time. The exact windows depend on the client's operational needs, and getting them wrong can mean the difference between a smooth engagement and an angry phone call from the operations team.

Communication Protocols

This is not about TCP/IP or networking protocols; it is about how the client organization and the penetration testing team communicate throughout the engagement.

The communication section of the RoE designates points of contact on both sides, specifies the communication channels for different types of messages, and defines the channel for urgent communication. Consider the following contact matrix for BrightCart's engagement:

Why does this matter in practice? Consider two scenarios. In the first, the BrightCart operations team notices that the payment API is unresponsive at 11:30 PM. Is this a result of the penetration test, or is it an unrelated infrastructure failure? Without a clear communication channel, the operations team has no way to quickly confirm whether the testers caused the issue. In the second, the penetration testers discover that an unauthenticated API endpoint is exposing customer credit card numbers in real time. This is a critical finding that cannot wait for the final report; the client needs to know immediately so they can act.

This is where escalation procedures come in. The RoE should define the process for reporting critical incidents and critical findings during the engagement. A common structure includes three tiers:

1. Informational: Routine status updates delivered via the agreed-upon channel at the agreed-upon frequency (e.g., daily email summaries)

2. Urgent: Findings or incidents that require client attention within hours (e.g., a high-severity vulnerability in a production system), communicated via direct email or message to the primary contact

3. Critical: Findings or incidents that present immediate risk, such as active data exposure, evidence of a real breach, or unintended system disruption, communicated via phone call to the emergency contact

Finally, to avoid miscommunication, the RoE should specify the reporting frequency and format in writing. Will the testers provide daily status updates? Weekly summaries? Is the final report due five business days after testing ends, or ten? Both parties should know exactly what to expect and when.

Confidentiality and Data Handling

Throughout a penetration test, a significant amount of sensitive information will be uncovered about the client organization, its employees, and its users. Regardless of the type of organization, from a healthcare provider to an e-commerce company, this data must be handled with strict confidentiality. As a penetration tester, you do not want your client's private information leaked because you mishandled their data; beyond the ethical obligation, mishandling data can expose you to legal liability under laws such as GDPR or HIPAA.

Consider what a tester might stumble across during an engagement. What if you discover the client restaurant's secret sauce recipe stored in an unprotected file share? What if you find the CEO's password in a configuration file, and it is the same password they use for their personal social media accounts? What if you access a database containing employee salary records or customer health data? These are not hypothetical situations; they happen in real engagements.

The RoE should establish clear, documented rules for handling such discoveries:

• Data minimization: Testers should collect only the evidence necessary to demonstrate a vulnerability, not exfiltrate entire databases

• Encryption: All collected evidence should be encrypted at rest (AES-256 or equivalent) and in transit

• Retention and destruction: The RoE should define how long the testing firm retains engagement data after the report is delivered and how that data is destroyed. A common standard is 30 to 90 days, after which all evidence is securely wiped

• Reporting channels: There should be a documented, agreed-upon process for reporting sensitive discoveries, specifying who receives the information and how it is transmitted

Permitted and Prohibited Activities

The RoE should explicitly state which testing techniques and tools are permitted and which are off-limits. The prohibited activities list varies by engagement, but common restrictions include:

• Denial-of-Service (DoS) attacks against production systems

• Social engineering of employees (unless explicitly authorized as a separate engagement)

• Physical security testing (again, unless separately scoped and authorized)

• Exploitation of vulnerabilities that could cause data loss or permanent damage to production systems

• Use of unapproved tools that might leave persistent artifacts or backdoors

Equally important is specifying what is permitted. Can testers use automated scanners such as Nmap and Nessus? Can they attempt privilege escalation on compromised hosts? Can they attempt lateral movement to adjacent systems within the scope? If the RoE is silent on a technique, the safest assumption is that it is not authorized. Ambiguity in the RoE benefits no one.

Sample RoE Summary

Bringing it all together, here is a condensed summary of what BrightCart's RoE might look like:

This table is simplified for illustration, but it captures the essential structure. In practice, an RoE document for an enterprise engagement can run several pages.

Looking Ahead

In this task, we covered the major operational components of a Rules of Engagement document. There are additional considerations that intersect with the RoE but deserve their own treatment:

• Regulatory compliance requirements that influence what and how you test (covered in Task 7)

• Penetration testing frameworks that provide structured methodologies for conducting the test (covered in the Penetration Testing Frameworks room)

• Report deliverables and what the final output looks like (covered in the Writing Pentest Reports room)

Answer the questions below

In the context of Rules of Engagement, what is the term for the defined process of reporting critical incidents or findings to the client during an engagement? escalation procedures

During BrightCart's penetration test, the testing team discovered that an unauthenticated API endpoint is actively exposing customer credit card numbers. According to the escalation tiers described in this task, what tier does this fall under? critical

The RoE states that engagement evidence should be encrypted at rest. What is the encryption standard mentioned in this task? AES-256

Regulatory Compliance

BrightCart processes credit card payments. That single fact triggers a cascade of regulatory obligations. Because BrightCart handles cardholder data, it must comply with the Payment Card Industry Data Security Standard (PCI DSS), which has specific, non-negotiable requirements for penetration testing. If BrightCart also serves customers in the European Union, the General Data Protection Regulation (GDPR) adds another layer of obligations around data security and privacy. And if BrightCart's healthcare partner shares patient data via an integration, the Health Insurance Portability and Accountability Act (HIPAA) also applies.

The point is this: penetration testing is not always a discretionary decision. In many industries, regulations require it. As a penetration tester, understanding which compliance frameworks apply to your client helps you design an engagement that satisfies both the client's security goals and their regulatory obligations. As a client, understanding these requirements helps you ensure the penetration test you commission will actually hold up under audit.

PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) is the most prescriptive compliance framework for penetration testing requirements. Any organization that stores, processes, or transmits cardholder data must comply with PCI DSS. The current version is PCI DSS v4.0.1, which became the sole active version on December 31, 2024. All future-dated requirements became mandatory on March 31, 2025.

Penetration testing requirements live under Requirement 11.4, which mandates the following:

• External and internal penetration testing must be conducted at least once every 12 months and after any significant change to the infrastructure or applications.

• The testing methodology must be based on an industry-accepted approach, such as NIST SP 800-115, PTES, OSSTMM, or OWASP.

• Testing must cover the entire Cardholder Data Environment (CDE) and any systems connected to it.

• Both application-layer vulnerabilities (such as those listed in the OWASP Top 10) and network-layer vulnerabilities must be assessed.

• All exploitable vulnerabilities and security weaknesses discovered must be remediated and retested to confirm the fix.

That last point is worth emphasizing. PCI DSS does not just require you to find vulnerabilities; it requires you to prove they have been fixed. The penetration tester's job is not finished when the report is delivered. A retest confirming remediation is part of the compliance cycle.

For BrightCart, this means the penetration test we have been scoping throughout this room must cover all systems that touch cardholder data, use a recognized methodology, and include a remediation verification phase. The scope document from Task 4 and the RoE from Task 6 should both reflect these requirements.

HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) governs the protection of patient health information in the United States. Unlike PCI DSS, HIPAA has historically not explicitly required penetration testing. The closest provision is the Security Rule's Evaluation standard (§164.308(a)(8)), which requires "periodic technical and non-technical evaluations" of security controls, but it does not prescribe penetration testing by name.

That said, penetration testing is widely regarded as a best practice for HIPAA compliance, and many auditors expect to see evidence of it. The landscape may be shifting further: in December 2024, the U.S. Department of Health and Human Services (HHS) published a Notice of Proposed Rulemaking that, if finalized, would require penetration testing at least every 12 months for all covered entities and business associates. The proposed rule would also require vulnerability scanning every six months.

For a penetration tester, the key HIPAA consideration is data handling. If you encounter electronic Protected Health Information (ePHI) during an engagement, that data is subject to HIPAA's privacy and security rules. Your data handling procedures in the RoE (Task 6) must account for this: minimize what you collect, encrypt it in transit and at rest, and destroy it according to the agreed-upon schedule.

GDPR

The General Data Protection Regulation (GDPR) applies to any organization that processes the personal data of individuals in the European Union, regardless of its headquarters. BrightCart ships to EU customers, so GDPR applies.

GDPR does not mention penetration testing by name. However, Article 32(1)(d) requires organizations to implement "a process for regularly testing, assessing, and evaluating the effectiveness of technical and organizational measures for ensuring the security of the processing." The UK Information Commissioner's Office (ICO) has explicitly interpreted this provision to include penetration testing as a recommended practice.

For penetration testers, GDPR introduces a specific complication: if you access personal data during the engagement, you become a data processor under GDPR. This triggers several obligations:

• A Data Processing Agreement (DPA) must be in place between the tester and the client before testing begins

• Data minimization applies; collect only the evidence needed to demonstrate a vulnerability, not entire datasets

• Personal data encountered during testing must be handled with the same protections required by the regulation

• Non-compliance penalties can reach up to 20 million euros or 4% of annual global turnover, whichever is higher

In practice, this means that the NDA and data handling sections of your pre-engagement documentation (Tasks 5 and 6) must explicitly address GDPR obligations when the client's systems contain EU personal data.

SOC 2 and ISO 27001

Two additional frameworks are worth noting, though they take a softer approach to penetration testing requirements.

SOC 2 (Service Organization Control 2) is an auditing framework developed by the American Institute of Certified Public Accountants (AICPA). It evaluates an organization's controls across five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. SOC 2 does not explicitly mandate penetration testing, but its guidance for Trust Services Criterion CC4.1 mentions penetration testing as an evaluation method. In practice, auditors routinely expect to see penetration test results as evidence, and clients reviewing SOC 2 reports frequently require them.

ISO 27001:2022 is the international standard for Information Security Management Systems (ISMS). It similarly does not mandate penetration testing explicitly, but controls A.8.8 (Management of Technical Vulnerabilities) and A.8.29 (Security Testing in Development and Acceptance) are most effectively satisfied through penetration testing. Many organizations pursuing ISO 27001 certification include annual penetration testing as part of their control implementation.

The pattern is clear: even where penetration testing is not explicitly mandated, it is increasingly expected as evidence of due diligence. An organization that skips penetration testing will face harder questions from auditors, customers, and regulators than one that conducts and documents regular tests.

Summary

The following table provides a quick reference for how each framework addresses penetration testing:

Answer the questions below

Which PCI DSS requirement specifically addresses penetration testing? Requirement 11.4

Under GDPR, what role does a penetration tester assume if they access personal data belonging to EU individuals during an engagement? data processor

Putting It All Together

You have spent the last seven tasks learning what penetration testing is, how testing types and approaches differ, how to define scope, what legal foundations must be in place, how Rules of Engagement govern an engagement, and which regulatory frameworks drive testing requirements. Now it is time to apply all of that.

In this task, you will step into the role of a penetration testing consultant. BrightCart, the e-commerce company we have been following throughout this room, has sent you a preliminary request. Read the brief below carefully, then answer the questions that follow. Each question requires you to draw on concepts from multiple previous tasks; there are no single-lookup answers here.

The Client Brief

You receive the following email from BrightCart's CISO:

From: Sarah Chen, CISO, BrightCart

To: You (Lead Penetration Tester)

Subject: Penetration Testing Engagement - Initial Scoping

Hello,

Thank you for meeting with us last week. As discussed, BrightCart is requesting a penetration testing engagement to evaluate the security of our core systems ahead of our annual PCI DSS audit in June.

Here is a summary of our environment and requirements:

About BrightCart:

We are a mid-sized e-commerce company headquartered in the United States with a growing customer base in the European Union. We process approximately 50,000 credit card transactions per month through our web application.

Systems and infrastructure:

• Customer-facing web application: www.brightcart.thm

• REST API for payment processing: api.brightcart.thm

• Internal employee portal: internal.brightcart.thm (accessible only from corporate network)

• Mobile application (iOS and Android) that communicates with the REST API

• Cloud infrastructure hosted on AWS (us-east-1 region, production environment)

• Corporate Wi-Fi network at headquarters

• Third-party logistics platform operated by ShipFast Inc. (integrated via API)

What we want tested:

We want the most thorough assessment possible of our web application, payment API, and cloud infrastructure. We are also interested in testing the internal network to evaluate what an insider threat could access. The board has specifically asked whether an attacker could access our payment database from the corporate network.

What is off limits:

• The ShipFast logistics platform (we do not own it and cannot authorize testing)

• Our disaster recovery environment in AWS eu-west-1 (currently under a change freeze)

• Any form of Denial-of-Service testing (our operations team is firm on this)

Constraints:

• Testing must not disrupt operations during peak hours (weekday evenings, 6:00 PM to 10:00 PM EST)

• We run a batch payment processing job nightly at 2:00 AM EST that must not be interrupted

• We need the final report at least three weeks before our PCI DSS audit, which is scheduled for June 15, 2026

What we can provide:

We are prepared to share network diagrams, application architecture documentation, AWS configuration details, and a set of test user accounts at various privilege levels for the web application. We want the testers to have every advantage so we can find as many issues as possible.

Additional notes:

• Our legal team will require an NDA before we share any technical documentation

• We already have an MSA in place with your firm from a previous vulnerability assessment

• We would like a single point of contact on your side for daily status updates

• For critical findings, we need immediate notification — our VP of Engineering should be called directly

Please review and let us know your proposed approach, timeline, and any questions.

Best regards,

Sarah Chen

Chief Information Security Officer, BrightCart

Analysis

Let's break down this brief using the framework we have built across this room.

Testing Approach

Sarah's email states that BrightCart is prepared to share network diagrams, architecture documentation, AWS configuration details, and test accounts at various privilege levels. The CISO explicitly wants the testers to "have every advantage" to maximize vulnerability discovery. This maps directly to the known environment (white box) approach we discussed in Task 3. The testers will have comprehensive knowledge of the target environment before testing begins.

Scope

Using the categories from Task 4, we can map BrightCart's brief to a scope definition specifying what's considered "In Scope" and what's considered "Out of Scope."

Notice that the ShipFast logistics platform is out of scope because BrightCart does not own it and cannot authorize testing against it. As we covered in Task 5, the authorization letter must be signed by someone with legal authority over the assets being tested. BrightCart has no such authority over ShipFast's systems.

Testing Type

This engagement combines multiple testing types from Task 3:

• Web application penetration test for www.brightcart.thm and internal.brightcart.thm

• Network penetration test covering both external (internet-facing) and internal (corporate network) perspectives

• Cloud penetration test for the AWS us-east-1 environment

• Mobile application penetration test for the iOS and Android applications

The board's specific question, whether an attacker could reach the payment database from the corporate network, calls for an internal penetration test focused on lateral movement and privilege escalation.

Legal Documents

Sarah's email gives us the legal document status:

• NDA: Not yet signed. BrightCart's legal team requires it before sharing technical documentation. This must be executed first.

• MSA: Already in place from a previous vulnerability assessment. No new negotiation needed.

• SOW: Drafted for this specific engagement, defining scope, methodology, timeline, deliverables, and cost.

• Authorization letter: Not mentioned in the email, but required before testing begins. Must be signed by someone with authority over all in-scope assets.

Rules of Engagement

From the constraints in Sarah's brief, we can draft the key RoE components:

• Testing window: Avoid weekday evenings (6:00 PM - 10:00 PM EST) and the nightly batch job at 2:00 AM EST

• Prohibited activities: DoS/DDoS testing (explicitly prohibited by the client)

• Communication: Daily status updates to a single point of contact; critical findings escalated immediately via phone call to the VP of Engineering

• Report deadline: At least three weeks before June 15, 2026, meaning the final report must be delivered by May 25, 2026, at the latest

Regulatory Compliance

Two compliance frameworks apply to BrightCart (as we covered in Task 7):

• PCI DSS v4.0.1: BrightCart processes credit card transactions and is scheduled for an upcoming PCI DSS audit. The penetration test must cover the entire Cardholder Data Environment (CDE), use an industry-accepted methodology, and include remediation retesting.

• GDPR: BrightCart serves EU customers, meaning any personal data encountered during testing triggers data processor obligations, including data minimization, encryption, and a Data Processing Agreement.

Answer the questions below

Based on Sarah's email, BrightCart is willing to share network diagrams, architecture documentation, and test accounts at various privilege levels. What testing approach does this describe? known environment

BrightCart's legal team requires a specific document to be signed before any technical documentation is shared with the penetration testing team. What document is this? NDA

The board wants to know whether an attacker could reach the payment database from the corporate network. This requires the penetration tester to begin from within BrightCart's network. What type of penetration test addresses this question? internal penetration test

Go through the attached static site. What is the flag?

Conclusion

Let's retrace the journey. When this room began, BrightCart's board was asking a simple question: "Could a data breach happen to us?" By the end of Task 8, you had translated that question into a fully scoped penetration testing engagement, complete with a defined testing approach, a scope document, legal agreements, Rules of Engagement, and alignment with compliance. No scanner was launched. No exploit was fired. And yet, the work you did in these eight tasks is what makes everything that follows possible.

That is the central lesson of this room: the planning and scoping phase is where penetration tests succeed or fail. A poorly scoped engagement wastes time and money. A missing authorization letter can end a career. A RoE that does not address escalation procedures leaves both parties exposed when something goes wrong. The technical skills you will built throughout this learning path are powerful, but they are only as effective as the planning that directs them.

What We Covered

Here is a summary of the ground we covered, mapped to the learning objectives from Task 1:

Explain what a penetration test is and how it differs from a vulnerability assessment (Task 2). A penetration test is an authorized, simulated cyber attack designed to identify and exploit vulnerabilities. Unlike a vulnerability assessment, which is broad and automated, a penetration test is deep, manual, and demonstrates real-world impact through active exploitation.

Distinguish between the known, partially known, and unknown environment approaches (Task 3). These three approaches define the amount of information the tester receives before the engagement. The industry is transitioning from the older white/gray/black box terminology to the knowledge-based environment labels, but both sets remain in active use.

Define the scope of a penetration test and identify the risks of scoping errors (Task 4). The scope defines the boundaries of the engagement through explicit allow and blocklists. An overly broad scope leads to shallow testing; an overly narrow scope creates dangerous blind spots and potential compliance failures.

Identify the legal documents and authorizations required before testing begins (Task 5). Four core documents govern a professional engagement: the NDA, MSA, SOW, and authorization letter. The CFAA (United States) and the Computer Misuse Act (United Kingdom) make unauthorized access a criminal offense; written authorization is what keeps a penetration test on the right side of the law.

Describe the key components of a Rules of Engagement document (Task 6). The RoE defines the operational boundaries of the engagement: timing and duration, communication protocols, escalation procedures, confidentiality and data handling requirements, and permitted and prohibited activities.

Recognize the major regulatory frameworks that mandate or recommend penetration testing (Task 7). PCI DSS v4.0.1 explicitly requires annual penetration testing of the Cardholder Data Environment. HIPAA, GDPR, SOC 2, and ISO 27001 each address penetration testing with varying degrees of specificity, but the industry trend is toward making it a universal expectation.

Apply planning and scoping concepts to a realistic client scenario (Task 8). The BrightCart engagement exercise brought together every concept: translating a client email into a testing approach, a scope document, a legal document checklist, a RoE framework, and compliance mapping.