Engagement Management practice questions

Black box

Why wrong: Black box testing simulates an external adversary with zero prior knowledge, forcing the tester to perform passive and active reconnaissance, fingerprinting, service enumeration, and vulnerability identification purely from an outside perspective. This approach best mimics a real-world unauthenticated attack and uniquely stresses the discovery of exposed services and misconfigurations that are visible only from the perimeter. However, it is time-intensive and may miss deep logic flaws or internal vulnerabilities that remain concealed behind proper edge defenses.

Grey box

Why wrong: Grey box testing provides partial knowledge, such as low-privileged credentials, an API specification, or network segment information, without full source code or architectural details. This middle-ground approach lets the tester concentrate on post-authentication logic, privilege escalation paths, and data exposure within specific modules, striking an efficiency balance between black and white box protocols. It is commonly chosen for web application assessments where access to a valid session is necessary to uncover flaws like broken access control or IDOR.

Red team

Why wrong: Red team is not a knowledge-level classification but rather a goal-oriented engagement that simulates a full-scale adversary attack across people, processes, and technology, often combining physical, social engineering, and technical vectors. Unlike white, black, or grey box tests, red team exercises evaluate detection, response, and defensive coordination while attempting to achieve specific objectives like data exfiltration or domain compromise without being caught. It may employ any of the three knowledge levels internally, so selecting it here confuses engagement type with testing intelligence.

Get-out-of-jail letter

Why wrong: While a get-out-of-jail letter serves as a broad authorization for the tester to perform penetration testing, it typically does not enumerate specific operational restrictions such as prohibited times, systems, or testing techniques. The client's statement that 'no testing' of certain elements should occur is a restriction that must be defined precisely, which a general authorization letter cannot provide. This makes it insufficient because it lacks the granularity needed to constrain testing activities.

Statement of work (SOW)

Why wrong: A statement of work (SOW) typically outlines the high-level objectives, deliverables, timeline, and cost of the engagement, but it does not drill down into the specific operational restrictions or testing techniques. It might mention that testing is authorized, but it does not define which assets are off-limits or what timeframes are prohibited. Since the client explicitly notes a restriction on testing, the SOW lacks the necessary detail to govern the actual testing behavior, so it is not the correct source for those constraints.

Non-disclosure agreement (NDA)

Why wrong: A non-disclosure agreement (NDA) is a legal contract designed to protect confidential data shared during the engagement, ensuring the tester does not disclose proprietary information to third parties. It does not, however, address operational boundaries such as which systems or services are excluded from testing, nor does it define acceptable testing windows or techniques. The client's restriction on testing is an activity-based constraint, not a confidentiality matter, so the NDA is not the appropriate document for this requirement.

Rules of engagement

Why wrong: Rules of engagement (RoE) establish the high-level operational boundaries for the engagement, such as acceptable testing windows, prohibited techniques, and notification procedures. While RoE might authorize the use of phishing or vishing, it does not usually enumerate the specific individuals or user groups who will receive the social engineering payloads. The 'target population' is a separate scoping concept captured in the personnel scope, so RoE is not the correct answer.

Production vs. staging environments

Why wrong: Production vs. staging environments is a system-level classification that distinguishes live enterprise systems from isolated test instances, and it is applied to infrastructure, not to people. Social engineering attacks are performed directly against real employees in their live work environment, so there is no analogous production/staging split for human targets. Thus, this option is irrelevant to defining which personnel are in scope.

Third-party services

Why wrong: Third-party services refer to external organizations, vendors, or outsourced functions that may be part of the infrastructure or service delivery, and they do not constitute the internal employee population targeted by social engineering. When a test scope mentions third-party services, it is typically to authorize testing of an external network or API, not to define who may receive a phishing email. Even if a social engineering test eventually contacts someone outside the company, the classification of that person as a target belongs in the personnel scope, not in the third-party services category.

Notify law enforcement directly

Why wrong: Directly notifying law enforcement bypasses the client's incident-response chain of command and may breach the penetration test agreement's confidentiality and scope clauses. The tester typically lacks the legal standing to file a criminal complaint on the client's behalf and may inadvertently compromise the admissibility of evidence by failing to follow proper chain-of-custody protocols. The correct channel is to escalate through the client's emergency contact, who has the authority to involve authorities and coordinate any legal holds.

Continue testing and document the evidence for later reporting

Why wrong: Continuing to interact with systems or individuals involved in ongoing criminal activity risks altering volatile forensic evidence and may transform the tester's legally authorized actions into unauthorized access under statutes like the CFAA, exposing the tester to civil and criminal liability. Further testing could also disrupt the client's ability to contain the incident and preserve evidence for prosecution. The engagement must stop immediately, and any evidence already gathered should be sealed and time-stamped without further analysis.

Ignore the activity and proceed as planned

Why wrong: Ignoring proven criminal activity while retaining unauthorized access, even within a permitted test, creates a legal and ethical conflict because the tester could be viewed as an aider or abetter or as failing to exercise reasonable care to prevent ongoing harm. Proceeding with the test plan also risks corrupting evidence that law enforcement may later need, and it violates professional codes of conduct (e.g., (ISC)² Code of Ethics) that mandate safeguarding public welfare. The tester must act immediately to notify the client and stand down all further probing.

NIST SP 800-115

Why wrong: NIST SP 800-115 is a technical guide for security testing and assessment primarily used by federal agencies, but it does not prescribe a structured penetration testing methodology. It covers broad assessment techniques such as network mapping, vulnerability scanning, and password cracking, yet leaves the sequencing and deliverables open-ended. As a result, it lacks the comprehensive, phase-driven framework that PTES provides.

OWASP Testing Guide

Why wrong: The OWASP Testing Guide is narrowly scoped to web application security, providing checklists and techniques for identifying flaws like SQL injection, cross-site scripting, and broken authentication. It does not address network infrastructure, wireless, social engineering, or physical penetration testing, which are integral to full-scope penetration tests. Consequently, while useful for application assessments, it cannot serve as a general penetration testing standard.

OSSTMM

Why wrong: OSSTMM is a peer-reviewed manual for verifying operational security controls through scientific metrics, such as trust boundaries and loss potential, rather than a step-by-step penetration testing standard. It emphasizes measuring security properties (confidentiality, integrity, availability) with specific formulas and does not delineate exploitation or post-exploitation activities. Thus, its focus on security metrics makes it a complementary resource, not a replacement for a penetration testing methodology.

Network penetration test

Why wrong: A network penetration test is a technical assessment of network infrastructure, targeting issues like misconfigured firewalls, unpatched servers, weak protocol settings, and improper network segmentation. Its scope and rules of engagement typically limit activities to specified IP ranges and system layers, and it usually does not involve attempting to trick employees through social engineering. While the test can reveal exploitable network vulnerabilities, it does not simulate a realistic, multidimensional attack that combines human interaction and social manipulation.

Wireless penetration test

Why wrong: A wireless penetration test is narrowly scoped to the radio-frequency environment, evaluating WPA2/WPA3 weaknesses, rogue access points, evil twin deployments, deauthentication attacks, and client misassociation. This assessment does not include social engineering, physical entry, or other organizational attack surfaces, so its results are limited to the wireless domain. It can support a red team operation but is not equivalent to a real-world scenario involving phishing or human deception.

Web application penetration test

Why wrong: A web application penetration test focuses exclusively on application-layer flaws such as SQL injection, cross-site scripting, broken authentication, and access control failures, typically aligned with the OWASP Top 10. Because the test is scoped to the web application's code, configuration, and business logic, it does not evaluate human susceptibility to phishing or the physical security of a facility. Thus, it cannot represent a real-world attack that uses social engineering as a primary entry vector.

Add the cloud provider to the scope without notifying the client

Why wrong: Adding the cloud provider to scope unilaterally circumvents the client-approved engagement boundaries; a pen test's scope is a contractual agreement between the tester and the client, and expanding it to include a third party's infrastructure requires the client's explicit sign-off and typically a separate authorization document from the provider. Unilaterally modifying scope exposes you to breach-of-contract liability and could invalidate your legal protections, so any scope change must be routed through the client and documented in writing.

Continue testing because the application is owned by the client

Why wrong: The fact that the application itself is owned by the client does not grant permission to test the cloud provider's underlying infrastructure. In a typical IaaS/PaaS engagement, the provider retains responsibility for the host, network, and virtualization layers, and testing those layers without the provider's explicit, written authorization is outside the engagement and potentially illegal—even if the application lives in that environment.

Obtain verbal permission from the cloud provider and proceed

Why wrong: Verbal permission from the cloud provider is not legally enforceable and fails to meet the standard of documented authorization required for penetration testing. A proper authorization must be a written agreement (often a Pen Test Authorization Addendum) issued by the provider's security or legal team, and it must also be incorporated into the client's scope change—otherwise, the tester remains exposed to civil and criminal liability while probing the provider's infrastructure.

HIPAA

Why wrong: HIPAA, the Health Insurance Portability and Accountability Act, governs the privacy and security of protected health information by covered entities and their business associates. Its rules mandate administrative, physical, and technical safeguards for medical records, but they do not establish a general prohibition on unauthorized computer access. While a violation involving unlawful access to health data could trigger HIPAA penalties, the statute is not the federal framework designed to address hacking or unauthorized system access broadly.

GLBA

Why wrong: The Gramm-Leach-Bliley Act (GLBA) imposes data privacy and security obligations specifically on financial institutions, including the Safeguards Rule that requires a written information security program. GLBA also prohibits 'pretexting,' a form of social engineering used to obtain customer financial information. However, GLBA is not an anti-hacking statute; it focuses on regulating the collection, sharing, and protection of consumer financial data rather than providing a broad prohibition against unauthorized computer access.

SOX

Why wrong: The Sarbanes-Oxley Act (SOX) was enacted to restore investor confidence after corporate accounting scandals by tightening corporate governance, audit independence, and financial disclosure requirements for public companies. It establishes penalties for financial fraud and requires management to assess internal controls, but it has no provisions addressing unauthorized computer access or network intrusion. SOX is irrelevant here because it deals with financial reporting integrity, not cybercrime.

The tester's personal notes and observations

Why wrong: The tester's personal notes and observations are informal, unstructured, and may contain assumptions, hunches, or partially verified information that was not intended for client review. Including them in a formal report could expose raw testing methodology, unvalidated false positives, or sensitive data, damaging credibility and potentially breaching confidentiality. Professional deliverables require a curated, evidence-based narrative, not a stream-of-consciousness log.

Only the technical findings

Why wrong: A report containing only technical findings gives engineers the raw vulnerabilities and proof-of-concept details but omits the executive summary that translates risk into business impact and the remediation guidance needed to fix the issues. Without prioritization or context, management cannot assess organizational exposure, and IT staff are left without clear, actionable next steps. This incomplete format fails the client's need for both strategic and tactical direction.

Only the executive summary

Why wrong: An executive summary alone provides a high-level risk overview and metrics, but it lacks the technical evidence, reproduction steps, and detailed remediation instructions that engineers require to validate and resolve each vulnerability. It may highlight risk trends, but without the underlying technical details, the client's security team cannot act on the findings. The report would be frustratingly vague for the technical audience, undermining its usefulness as a decision-support and action document.

Assume the client has permission and scan all IPs

Why wrong: Assuming the client has permission to authorize scans of every IP in a target range is a dangerous unsafe assumption. In penetration testing, authorization is strictly limited to assets owned or explicitly approved for testing by the client; third-party IPs, such as cloud-hosted services or partner infrastructure, require separate permission from the entity that controls them. Scanning IPs without that authorization can violate laws like the Computer Fraud and Abuse Act (CFAA) or equivalent statutes, potentially exposing both the tester and the client to legal liability. You must verify scope in the rules of engagement and never rely on assumptions when adding assets to the scope.

Scan the IPs because they are on the client's list

Why wrong: Simply having the IPs included in the client's provided list does not automatically grant authorization to scan them, especially when those addresses are owned by a third party. The client may not be aware that certain IPs fall outside their control, or they may have acquired a list of IPs without verifying ownership. Performing the scan based on the list alone transfers legal responsibility to the tester, who is still liable for unauthorized access. The tester must verify ownership, identify third-party assets, and confirm explicit written authorization beyond a simple list entry before conducting the scan.

Scan only the third-party IPs that respond to ping

Why wrong: Scanning only the third-party IPs that respond to ping does not avoid the core legal problem, because responding to an ICMP echo request is not the same as granting permission to scan. Even if a host answers ping, active service discovery and vulnerability scanning against that host constitute unauthorized network activity under the third party's exclusive control. Additionally, limiting the scan to responsive hosts is not a valid scoping method; it omits potentially critical assets while still violating third-party rights. The only acceptable action is to exclude these IPs entirely or obtain explicit third-party authorization before any scanning occurs.

Ignore the issue and complete the test

Why wrong: Ignoring the disruption and completing the test violates the Rules of Engagement (RoE) and professional conduct. Any unintentional availability impact, such as a guest Wi-Fi outage, must be reported immediately and trigger the agreed-upon emergency procedures. Continuing the test without addressing the issue could also invalidate findings, since the environment has changed, and expose the tester to legal liability for the disruption.

Reduce the intensity of the attack

Why wrong: Lowering the attack intensity is insufficient because the emergency stop procedure requires fully halting testing activities, not just dialing them back. As long as the attack continues, even at a reduced rate, it can still cause further availability degradation or unpredictable side effects, which may continue to violate the RoE. The tester must completely stop the attack and then coordinate with the client to assess whether the impact has subsided before considering any resumption.

Continue testing because guest Wi-Fi is not critical

Why wrong: Deeming guest Wi-Fi as non-critical does not excuse the disruption; the RoE typically prohibits any denial-of-service impact unless explicitly authorized. Even a non-critical network may be used by employees or partners, and the outage could have broader operational consequences that the tester is unaware of. The tester must always respect the agreed scope and impact thresholds, and any unforeseen disruption requires an immediate halt and client notification.

To protect the client from legal liability

Why wrong: The authorization letter is designed to shield the tester from criminal prosecution, not to indemnify the client. A client's legal liability is typically governed by the services agreement, master service agreement, or mutual indemnification clauses, whereas the letter itself is evidence that the client consented to intrusive security testing. Thus, the purpose is to protect the tester, not the client.

To document emergency contacts

Why wrong: While the authorization letter may include contact information for the engagement, its primary purpose is not to document emergency contacts. Emergency points of contact for incidents or critical vulnerabilities are normally recorded in the Rules of Engagement or an incident response call tree. The letter's legal function is to grant permission to perform otherwise unlawful access, which is unrelated to operational emergency procedures.

To outline the scope of the test

Why wrong: The scope of a penetration test—target networks, systems, testing windows, and allowed techniques—is comprehensively defined in the Rules of Engagement or Statement of Work. Although the authorization letter may reference this scope to bound the granted permission, it is not a scoping document itself. Its core purpose is to provide legal authorization and prevent prosecution, not to outline the technical parameters of the assessment.

Including all third-party services

Why wrong: In penetration testing scoping, third-party services are typically outside the authorized boundary unless explicitly listed and approved by their owners. Testing them without written authorization from the provider violates contracts and can lead to legal action, and their inclusion often exposes data flows where the client has no direct control or visibility. Scoping should restrict testing to assets owned by the client or those with explicit third-party consent.

Allowing unlimited testing hours

Why wrong: Unlimited testing hours remove time-based controls that prevent testers from performing intrusive actions during business hours, increasing the chance of service disruption and inadvertently triggering defenders. Scoping should define clear start and end times along with blackout windows to avoid impact on critical operations. Without such limits, testing becomes harder to contain and more likely to escalate into a denial-of-service situation.

Testing all IP addresses in the organization

Why wrong: Not all IP addresses are appropriate targets; testing the entire range could inadvertently hit production systems, partner infrastructure, or network devices that are outside the agreed scope. Even if ownership is confirmed, broad scanning can cause significant downtime and violate service-level agreements. Scoping should identify specific, authorized targets, explicitly excluding anything that could affect production or third-party environments.

Detailed log of every command executed

Why wrong: A detailed log of every command executed is unsuitable for a final client deliverable because it exposes internal tooling, attack paths, and potentially sensitive data that the client does not need for remediation. It also contains extensive operational noise—such as false starts, recon pings, and test modifications—that obscures the actual security findings. Such logs belong in the tester's working notes or an appendix for audit purposes, not in the executive- or technical-facing report, as they provide little actionable value to the client's security team.

Tester's hourly billing breakdown

Why wrong: An hourly billing breakdown is a contractual and administrative document, not part of the technical penetration test report. It contains sensitive financial information that is irrelevant to the security findings and could distract from the technical and business messages the report is meant to convey. Billing details are typically handled by the consulting firm's accounting department and delivered separately, ensuring the report remains focused on security outcomes rather than vendor commercial arrangements.

Social engineering

Why wrong: Social engineering is an attack vector or engagement technique, not a knowledge-based testing classification. While it can be incorporated into a penetration test engagement, it does not define the amount of prior information provided to the tester. In PenTest+ terminology, types such as black, white, and gray box refer to the tester's knowledge level, not the attack methods used.

Network penetration test

Why wrong: A network penetration test is an engagement type that focuses specifically on network infrastructure, servers, and endpoints. It describes the scope of the assessment, not the information asymmetry between the tester and the target. The knowledge-based categories (black/white/gray box) classify how much reconnaissance and internal detail the tester receives before the test, making this option incorrect.

Red team

Why wrong: Red team is an engagement type that simulates a full-scale adversarial attack, often combining technical exploits, social engineering, and physical intrusion. It is not a classification based on the level of knowledge given to the tester; rather, it defines the objective and breadth of the operation. PenTest+ distinguishes red teaming from the knowledge-based 'box' types used to categorize testing approaches.

Grey box

Why wrong: Grey box testing is incorrect here because it involves only partial knowledge of the system, such as a set of low-privileged credentials or a subset of network diagrams. In a grey box engagement, the tester must still perform enumeration and privilege escalation to uncover vulnerabilities, whereas the prompt explicitly states that full knowledge and credentials are provided. This level is typically used to simulate an authenticated insider or a user with specific, limited access, not the complete access described in the assessment.

Black box

Why wrong: Black box testing is incorrect because it simulates an external attacker with zero prior knowledge of the target environment. The tester must rely solely on OSINT, port scanning, service enumeration, and manual exploitation to discover entry points, which is the opposite of being provided full knowledge and credentials. Since the prompt specifies that the assessor receives complete architectural information and valid credentials, the scenario cannot be classified as black box, as that would obscure the very information that has been explicitly granted.

Red team

Why wrong: Red team is incorrect because it refers to an engagement type that simulates real-world adversarial attacks to test detection and response capabilities, not a classification of the tester's knowledge level. A red team operation can be performed as black, grey, or white box depending on the client's objectives, such as testing how well the blue team detects an attack. The prompt asks for a testing knowledge level, and while a red team may be given full knowledge, the term itself does not inherently define the level of access or information provided, making it an unsuitable answer.

Get-out-of-jail letter

Why wrong: The get-out-of-jail letter (or authorization letter) grants the tester legal permission to perform the engagement and protects the tester from criminal or civil prosecution. It identifies the client and the tester's activities, but it does not inventory the precise address space under test, such as specific CIDR blocks or individual host IPs. Those technical scope boundaries belong in the Rules of Engagement, not in a legal authorization artifact.

Non-Disclosure Agreement (NDA)

Why wrong: The Non-Disclosure Agreement (NDA) is a confidentiality contract that restricts the tester from disclosing the client's sensitive data, findings, or trade secrets to third parties. It addresses how information is handled and protected, but it contains no operational details such as target network address ranges or allowed testing hours. Scope boundaries are defined in the Rules of Engagement, not in a confidentiality clause.

Statement of Work (SOW)

Why wrong: The Statement of Work (SOW) is a high-level contract that describes the services, deliverables, timeline, and cost for the penetration test. It may mention the general target environment, but it normally does not enumerate the exact IP ranges, CIDR notation, or exclusion lists that are necessary for test execution. Those precise technical parameters are reserved for the Rules of Engagement, which operationalizes the SOW's broad intent.

IP address range

Why wrong: An IP address range defines the network hosts and subnets eligible for infrastructure scanning or exploitation, but social engineering manipulates human users rather than network services. Since the target is people—employees with specific roles and access—an IP scope provides no information about which individuals, departments, or identities may be approached. Consequently, specifying an IP range would be a technical network-scoping step that does not support planning a phishing or vishing campaign.

Production vs. staging

Why wrong: Production versus staging distinguishes live, user-facing systems from isolated test environments, a distinction that applies to software deployment and change management—not to personnel targeting. Social engineering engagements are concerned with the people who operate or use those systems, and whether a server is in production or staging rarely affects whether an employee can be tricked into revealing credentials. Therefore, this environmental classification is a red herring when defining the human scope of an engagement.

Third-party services

Why wrong: Third-party services refer to external vendors or cloud providers whose infrastructure or offerings may be used by the target organization, but such entities are separate legal and operational units. A social engineering engagement against the organization targets its own employees, partners, or contractors, not the external provider's staff unless supply-chain pretexting is explicitly authorized. So listing third-party services as part of the engagement scope would incorrectly broaden the target set beyond the client's personnel.

Continue the test as planned and include the findings in the final report

Why wrong: Continuing the test as planned while possessing evidence of criminal activity violates the fundamental incident-handling principle that certain findings require immediate escalation, not deferred reporting. The Rules of Engagement (RoE) typically specify a mandatory notification trigger for illegal content or acts, and postponing that notification until the final report could allow ongoing harm or the destruction of forensic evidence. Moreover, the tester's continued activity might contaminate the crime scene, jeopardizing any subsequent legal investigation and potentially exposing the tester or client to liability for failure to act.

Document the evidence and destroy it after the engagement to protect the client

Why wrong: Destroying evidence after documenting it is a severe breach of forensic best practices and legal obligations, as it destroys any potential chain of custody and renders the evidence inadmissible in court. A penetration tester's role includes preserving artifacts that may be relevant to criminal investigations, not unilaterally deciding to dispose of them. Furthermore, such destruction could constitute spoliation, exposing the test firm and client to legal penalties and damaging the client's ability to pursue remediation or prosecution, so the only proper course is to secure and hand over the evidence intact.

Immediately stop testing and notify law enforcement without client approval

Why wrong: Unilaterally stopping the test and contacting law enforcement bypasses the client's authority and the agreed-upon incident response framework, potentially breaching confidentiality and the RoE. In a penetration test, the client is the legal owner of the environment and the party entitled to make decisions about external notifications, especially since apparent 'criminal' activity could, in some cases, be a previously authorized test component or a false positive. The tester should instead escalate through the designated emergency contact, allowing the client's incident response team to verify the finding, preserve evidence, and engage law enforcement through proper legal channels while maintaining chain of custody.

Proceed with testing but use only passive techniques on the gateway

Why wrong: Passive techniques such as traffic sniffing, response analysis, or metadata inspection still involve interacting with or capturing data from a third-party payment gateway system. These actions can violate the gateway provider's terms of service and may run afoul of computer misuse laws (e.g., CFAA) because the tester lacks explicit authorization from the gateway owner. Furthermore, the client's engagement scope does not cover a third party's infrastructure, and passive testing rarely yields actionable security findings for a gateway, so the risk outweighs any potential benefit.

Test the gateway without informing the client to avoid delays

Why wrong: Proceeding without the client's or gateway provider's explicit written permission constitutes unauthorized access and could be prosecuted under statutes like the U.S. Computer Fraud and Abuse Act (CFAA) or the UK Computer Misuse Act. Even well-intentioned testing can trigger fraud detection systems, disrupt live payment processing, and cause financial harm to the client's customers and business. It is both an ethical violation and a breach of the engagement's legal boundaries; the tester must formally notify the client of the missing scope and obtain a separate signed authorization before testing the gateway.

Include the payment gateway in scope because it is part of the application

Why wrong: The payment gateway is a software-as-a-service (SaaS) endpoint owned and operated by a third-party provider, not the client, so including it in scope without permission constitutes unauthorized testing of a separate legal entity. Active testing techniques such as injecting malicious payloads or attempting to bypass authentication on the gateway would be an attack on infrastructure the client has no authority to grant access to, potentially violating terms of service and computer crime statutes. Even though the gateway appears in the application flow, scope is defined by ownership and contractual boundaries rather than user-visible functionality; the correct action is to confirm the client's authorization explicitly covers the gateway before any test is performed.