Engagement Management practice questions

Detailed log of every command executed

Why it fails: 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 it fails: 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.

Get-out-of-jail letter

Why it fails: 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 it fails: 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 it fails: 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.

To provide emergency contact information

Why it fails: Emergency contact information is the purpose of an emergency contact list, not a penetration testing authorization letter. The authorization letter is a legal document focused on granting permission for security testing activities. While contact details might be included for convenience, the primary purpose is to establish authorization, not to provide a roster of people to call during an incident.

To outline the rules of engagement

Why it fails: Rules of engagement (RoE) are a separate document that defines the scope, timing, and allowed testing techniques for the engagement. The authorization letter simply proves that the client has consented to the testing, whereas RoE provides operational boundaries. Without a distinct RoE, the tester would not know the precise constraints on their activities, but the authorization letter itself does not outline those rules.

To ensure the tester does not steal data

Why it fails: Preventing data theft is the role of a non-disclosure agreement (NDA) and the engagement contract, not the authorization letter. The authorization letter grants permission to access systems and perform attacks, while the NDA imposes confidentiality obligations prohibiting the tester from exfiltrating or mishandling data. These two documents serve complementary but distinct purposes: consent vs. confidentiality.

Deploy USB drop attacks at the office entrance over the weekend

Why it fails: Dropping USB devices at the entrance over the weekend fails on two fronts: the rule of engagement typically limits active physical testing to business hours, and the absence of employees means the baits won't be inserted into workstations during the test window, squandering the payload and risking discovery by cleaning crews.

Conduct a phishing campaign with emails sent at 2:00 AM

Why it fails: Phishing at 2:00 AM violates the business-hours constraint in most RoE, and technically the emails will land in inboxes before employees arrive, so any clicks occur later outside the allowed testing window; this also skews reporting because the test campaign's active phase doesn't align with the authorized schedule.

Perform a tailgating attempt at 7:00 PM after most employees have left

Why it fails: Attempting to tailgate at 7:00 PM is both an RoE breach and operationally poor: with few employees leaving, there are scant legitimate badge presentations to piggyback through, so the tester's presence becomes obvious to remaining staff or security, increasing the chance of the engagement being aborted.

Statement of Work

Why it fails: A Statement of Work (SOW) is a project-level contract that defines the scope, deliverables, timeline, and cost of the penetration test, but it does not serve as a legal authorization to attack systems. Its purpose is to align business expectations about what work will be performed, not to immunize the tester from liability for unauthorized access. Even if the SOW lists IP ranges and testing windows, it lacks the explicit consent from the client's authorized representatives that would protect the tester under computer misuse statutes.

Non-Disclosure Agreement

Why it fails: A Non-Disclosure Agreement (NDA) is a confidentiality contract that prohibits the tester from disclosing client data, findings, or other sensitive information to unauthorized parties. It protects the client's proprietary business information, but it places obligations on the tester rather than granting the tester any rights. Signing an NDA does not give legal permission to perform penetration testing; it only ensures the tester will keep what they learn secret, so it cannot shield the tester from liability for unauthorized access.

Rules of Engagement

Why it fails: Rules of Engagement (RoE) are an operational document that describes the technical constraints and parameters of the test, such as allowed attack techniques, time windows, and in-scope versus out-of-scope targets. While RoE are essential for guiding the tester's actions and preventing accidental damage, they are an execution plan rather than a formal grant of legal permission. A RoE may be referenced by an authorization letter, but it does not itself satisfy the requirement of affirmative consent needed to legally justify intrusive actions.

Immediately inform law enforcement

Why it fails: The tester should first inform the client via the agreed contact.

Cease all testing and delete the evidence

Why it fails: Deleting evidence may be illegal; proper procedure is to report.

Continue testing and document the evidence for the final report

Why it fails: Continuing testing without reporting could be problematic; the client should be informed first.

The client's business goals

Why it fails: The client's business goals are strategic objectives that define why the engagement is occurring. These are captured in the statement of work (SOW) or project charter, along with scope and success criteria. The rules of engagement (RoE) focus on operational constraints, not high-level goals, so including business goals there would blur the line between contract intent and tactical authorization.

The tester's background check information

Why it fails: The tester's background check information is personally identifiable data that pertains to HR vetting, not to the exercise's operational boundaries. Background checks are completed before the engagement as part of the contracting and compliance process, not documented in the RoE. Putting such PII in the RoE would be both irrelevant to authorization and a potential privacy violation.

The tester's hourly rate

Why it fails: The tester's hourly rate is a commercial term negotiated in the master services agreement or contract. RoE governs active testing behavior—like allowed techniques, target scope, and communication paths—not billing details. Including compensation data in the RoE would confuse financial governance with the operational authorization needed to conduct the test.

Exploiting a SQL injection vulnerability in the finance web app

Why it fails: Exploiting a SQL injection vulnerability in the finance web app is a purely technical attack that targets the application's database layer by injecting malicious SQL queries through unsanitized input fields. It does not involve any form of human manipulation or psychological influence over a person, which is the defining characteristic of social engineering. Instead, it relies on the existence of an unpatched software flaw, making it a web application security test rather than a social engineering technique.

Performing a vulnerability scan on the finance network

Why it fails: Performing a vulnerability scan on the finance network is an automated technical assessment that enumerates services, checks for known vulnerabilities (CVEs), and identifies misconfigurations without any human interaction. The scan does not involve deception, pretexting, or any manipulation of user behavior, so it is fundamentally an active technical reconnaissance technique rather than a social engineering attack. In a penetration test, vulnerability scanning is typically a precursor to exploitation, not a method for targeting personnel.

Ignore the third-party aspect and test as usual

Why it fails: Treating the cloud-hosted application as if it were entirely within the client's control is a legal and contractual misstep. The provider's multi-tenant infrastructure is not owned by the client, and conducting active tests—such as port scans or exploitation attempts—without the provider's authorization can violate the cloud provider's Acceptable Use Policy (AUP) and may expose the tester to civil liability or criminal charges under laws like the Computer Fraud and Abuse Act (CFAA) or the UK Computer Misuse Act. Even if the client consents, the provider is a separate party whose infrastructure you have no legal right to access for testing. A professional pentester must explicitly negotiate and document the third-party scope before any testing begins.

Ask the client to move the application to on-premises

Why it fails: Proposing an on-premises migration is not a viable or proportionate response to a third-party scope problem. It fundamentally changes the application's architecture, data flow, and security controls, meaning the test would no longer reflect the production environment that actually holds the client's data. In practice, moving a cloud-native application may take weeks or months, introduce new vulnerabilities, and may be technically impossible for SaaS offerings that the client does not control. The correct approach is not to relocate the environment but to obtain the cloud provider's written authorization, which is a standard part of third-party penetration testing governance.

Proceed with testing the application using the provided credentials

Why it fails: Using the provided credentials only authorizes access to the application layer under the client's grant; it does not extend permission to the cloud provider's underlying network, virtualization, or physical infrastructure. From the provider's perspective, the client is just a tenant, and your credentialed access does not waive the provider's terms of service or their exclusive right to authorize security testing of their systems. If your testing inadvertently triggers provider-level defenses or touches another tenant's resources, you could be held liable for unauthorized access. Written provider authorization—or following the provider's published pen-testing policy—is the only way to convert that service-level access into legal testing authority.

Privacy laws such as GDPR or HIPAA

Why it fails: Privacy laws such as GDPR and HIPAA impose strict controls on the collection, processing, and safeguarding of personal or protected health information, but they do not specifically create a universal post-engagement obligation to destroy penetration test artifacts. In a PenTest+ context, data destruction is governed by contractual clauses, not by the privacy statute itself; the law merely informs how the tester must protect data while in scope. Thus, while the tester must comply with these laws during testing, they are not the authoritative source for the required destruction actions after the engagement.

Computer Fraud and Abuse Act (CFAA)

Why it fails: The Computer Fraud and Abuse Act (CFAA) is a U.S. criminal statute that punishes unauthorized access to protected computers; it neither establishes a duty to destroy test artifacts nor provides a framework for post-engagement cleanup. Even if a tester exceeded authorization, the CFAA's remedial focus is on liability and penalties, not on data handling or disposal requirements. Therefore, citing the CFAA as the reason for destroying evidence is a category error—the obligation stems instead from the engagement's contractual terms.

Vulnerability disclosure responsibilities

Why it fails: Vulnerability disclosure responsibilities concern ethically notifying the client or affected vendors about identified security flaws, following responsible disclosure policies or coordinated disclosure timelines; they do not dictate how test artifacts, credentials, or exploited data are destroyed. Disclosure obligations typically require detailed proof-of-concept files and evidence of impact, which the tester might need to preserve until the report is finalized rather than immediately delete. Since the question asks about submitting requirements after the test, vulnerability disclosure is a separate process that runs parallel to but does not govern the destruction of test-generated artifacts.

Raw vulnerability scan output

Why it fails: Raw vulnerability scanner output is not a deliverable in itself: it lists a high volume of unverified detections, duplicates, and non-contextualized CVSS scores that often include false positives (e.g., missing headers, TLS cipher checks that are not exploitable). Unlike a pentest report, raw output lacks business context, proof-of-concept validation, and actual exploitation severity, so handing it directly to IT staff shifts the burden of triage onto them and can lead to wasted remediation effort or alert fatigue.

Full source code of the application

Why it fails: Full source code of the application is not a standard pentest deliverable — and including it would actually be a liability, as source code is proprietary intellectual property and may expose secrets, hardcoded credentials, business logic, or underlying infrastructure to unauthorized readers. A pentest report should include only evidence artifacts (specific snippets, request/response pairs, logs) that prove the vulnerability, not the entire codebase. Unlike raw scan output, source code does not communicate test results; it would require additional analysis to map code to findings, and it dramatically widens the report's exposure risk if the document is shared.

Exploit the vulnerability to demonstrate impact

Why it fails: Exploiting the vulnerability without authorization may violate the testing scope and legal agreements, and could cause unintended damage.

Include the finding in the final report without further action

Why it fails: Including the finding in the report is necessary, but the tester should first inform the client and obtain proper authorization to investigate further.

Notify law enforcement of the criminal activity

Why it fails: Notifying law enforcement is not the immediate priority; the vulnerability does not necessarily indicate criminal activity, and the tester should first report to the client and seek proper authorization.

All employees including the CEO

Why it fails: Scoping all employees, including the CEO, is overly broad and often impractical for a controlled engagement. Executives may have special security controls or legal protections, and targeting them without explicit, separate consent could create contractual or reputational risks. The broader the scope, the greater the potential for operational disruption and unintended consequences, so this approach contradicts the core principle of defining a manageable, agreed-upon population.

External contractors only

Why it fails: Limiting the scope to external contractors is inappropriate because contractors are typically not the client's direct employees and may be covered by separate legal agreements or employment contracts. Without their explicit consent, testing them could lead to privacy violations or breach of contract, and the results would not accurately reflect the client's internal employee security posture. A social engineering assessment is meant to evaluate the client's own workforce, not third parties.

Only non-technical staff

Why it fails: Targeting only non-technical staff ignores that technical staff, such as system administrators and IT helpdesk personnel, often have elevated privileges and access to critical systems, making them prime targets for real-world attackers. Excluding them would leave gaping holes in the assessment, as advanced persistent threats frequently use spear-phishing against technical users to gain initial footholds. Scope decisions should be driven by risk and business objectives, not by arbitrary assumptions about who is 'susceptible' to social engineering.

OSSTMM

Why it fails: OSSTMM (Open Source Security Testing Methodology Manual) emphasizes a scientific and metrics-based approach to security audits, covering operational security across human, physical, and data channels. Its focus is on continuous security validation and measurement, not on end-of-engagement data handling or destruction. Thus, it does not specify procedures for sanitizing test artifacts, making it incorrect for this requirement.

OWASP Testing Guide

Why it fails: OWASP Testing Guide is tailored for web application security, offering a detailed catalog of active and passive tests for vulnerabilities like SQL injection and broken access control. While it includes a reporting section, it has no dedicated post-test data destruction process; its emphasis is on discovering and fixing vulnerabilities rather than managing residual test data. Therefore, it does not address the tester's cleanup obligations.

PTES

Why it fails: PTES (Penetration Testing Execution Standard) provides a high-level framework for all penetration testing phases, including pre-engagement, intelligence gathering, and reporting. Its reporting phase focuses on communicating findings and risk to stakeholders, not on data destruction protocols. While it mentions protecting data during the test, it lacks the detailed sanitization and disposal guidance needed for post-test data retirement.

The exact wording of phishing emails

Why it fails: While the precise content of phishing messages is often reviewed in a separate test plan or by a point of contact, the rules of engagement are not a script repository. RoE focuses on authorization boundaries such as target geography, permitted techniques, and prohibited actions (e.g., 'no CEO fraud'), whereas exact wording is mutable and generally left to the tester's discretion. Listing word-for-word copy would inappropriately constrain the simulation and is not necessary for legal authorization.

The tester's personal email address for replies

Why it fails: The tester's personal reply-to mailbox is an operational implementation detail, not a formal authorization boundary, and it does not appear in rules of engagement because it has no bearing on scope or consent. Beyond that, using a personal address raises trust and attribution concerns; a professional engagement would typically use a controlled domain or designated infrastructure endpoint defined in the test plan. RoE documentation is reserved for high-level constraints, not individual tactical tools.

The email addresses of employees to be targeted

Why it fails: Listing specific target email addresses in RoE would inappropriately transform the document from an authorization boundary into a data inventory, creating privacy and handling concerns. Instead, RoE should define categories of targets—such as all non-IT staff in finance—so the authorization is clear without enumerating personally identifiable information. Individual recipient lists are generated during the engagement plan and should not be part of the formal rules of engagement.

The Statement of Work (SOW)

Why it fails: The SOW defines the specific tasks, deliverables, and timeline for the engagement. While it may include the scope, it does not typically contain the legal authorization language that protects the tester from prosecution. The get-out-of-jail letter is the document that grants permission and indemnifies the tester for authorized activities, including accidental out-of-scope access.

The Master Service Agreement (MSA)

Why it fails: The MSA is a contract that outlines the general terms and conditions of the business relationship, such as payment terms and liability limitations. It does not specifically authorize the tester to perform penetration testing activities or protect against prosecution for accessing out-of-scope systems. The get-out-of-jail letter is the document that provides explicit authorization and legal protection for the testing activities.

The non-disclosure agreement (NDA)

Why it fails: The NDA is a legal contract that prohibits the tester from disclosing confidential information obtained during the engagement. It does not authorize testing activities or protect the tester from prosecution for accessing out-of-scope systems. The get-out-of-jail letter is specifically designed to provide legal authorization and protection for the testing activities.

Perform a UNION-based SQL injection to retrieve the database schema and table names

Why it fails: Performing a UNION-based SQL injection to retrieve database schema and table names involves extracting metadata, which may be considered data exfiltration. This could violate the RoE if it prohibits accessing any data. The tester should use a blind technique that does not extract any information, only confirms the vulnerability. This avoids crossing ethical and legal boundaries.

Exploit the SQL injection to extract a small sample of data to prove the vulnerability

Why it fails: Extracting data, even a small sample, may violate the RoE if it involves accessing sensitive information. The RoE typically prohibits data exfiltration or modification. The tester should instead use a non-invasive method, such as time-based blind SQL injection, to demonstrate the vulnerability without extracting actual data. This approach complies with the RoE and avoids potential legal issues.

Launch a DoS attack against the web server to demonstrate the impact of the SQL injection

Why it fails: Launching a DoS attack directly violates the RoE, which explicitly prohibits denial-of-service attacks. This action could cause operational disruption and legal consequences. The tester must never perform DoS attacks unless explicitly authorized. The goal is to demonstrate the vulnerability without causing harm, so a non-disruptive technique like time-based blind SQL injection is appropriate.

Black box

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.