Pen Test Planning practice questions

Black-box testing is legally prohibited under international cybersecurity standards for any application handling financial data.

Why it fails: No international standard prohibits black-box testing of financial applications; the real misalignment is that zero prior knowledge prevents testers reaching authenticated business logic paths. Black-box suits external attack-surface assessment, where simulating an uninformed adversary is precisely the objective.

Zero-knowledge assessments automatically violate standard industry rules of engagement by preventing the execution of automated scanners.

Why it fails: Zero-knowledge testing does not breach rules of engagement; automated scanners can still run against discovered in-scope targets. This misattributes a legal constraint to a methodology choice. Rules of engagement govern authorisation, timing and boundaries, and are equally applicable to black-box and white-box engagements.

Client stakeholders cannot legally authorize a penetration test without providing a complete network diagram and asset inventory.

Why it fails: Legal authorisation requires signed scope and rules of engagement, not a network diagram; a client can lawfully approve a zero-knowledge test. The objection is tempting because documented asset inventories support scoping, but that concerns test quality and coverage, not legal authority to proceed.

Perform a SYN scan against the CDN IP ranges to identify open ports.

Why it fails: Scanning CDN infrastructure typically triggers automated incident response systems maintained by the provider. This generates unnecessary noise, potentially leads to a temporary block of the testing IP addresses, and risks violating the provider's terms of service, which the client does not have the authority to override.

Incorporate the CDN provider's IP space into the primary target scope.

Why it fails: Including a third-party CDN provider in the scope without their written consent is a major operational risk. Cloud providers strictly prohibit unauthorized penetration testing against their backbone infrastructure, and the client cannot legally authorize testing on hardware or software that they do not own or manage.

Bypass the CDN by mapping the origin server's IP address directly.

Why it fails: Bypassing the CDN to attack the origin server directly often violates the implicit boundaries of the engagement. While it may reveal vulnerabilities on the origin server, it ignores the security controls provided by the CDN, which are part of the target environment the client intends to secure.

A list of all vulnerabilities found during the previous year's audit.

Why it fails: While helpful for benchmarking, historical vulnerability data belongs in the pre-engagement assessment phase or the background information gathering phase. It is not a functional component of a communication plan, which focuses on real-time interaction, notification procedures, and emergency contact details during the active testing window.

The specific exploit payloads that will be used during the test.

Why it fails: The communication plan is not intended to document technical exploit methodologies. While the RoE may restrict certain payloads, the communication plan itself is focused on administrative and operational interactions between the testing team and the client, rather than the technical specifics of the exploitation phase.

The estimated total cost of the project and payment schedule.

Why it fails: Financial terms and payment schedules are part of the legal contract or the Statement of Work (SOW). They should not be included in the Rules of Engagement, which focus on the technical and operational constraints, safety procedures, and communication workflows required during the execution of the penetration test.

Execute the SQL injection to prove the vulnerability exists.

Why it fails: Executing an exploit that causes a database lock-up directly violates the 'Forbidden_Attacks' clause regarding DoS. Even if the intent is to prove the vulnerability, the resulting service interruption is unacceptable under the provided policy, and the tester would be liable for the resulting business impact.

Attempt the exploit on the excluded host 192.168.10.50 to see if it is vulnerable.

Why it fails: The host 192.168.10.50 is explicitly listed in the 'Exclusions' field of the policy. Any interaction with this host, regardless of the vulnerability detected, constitutes a breach of the scope, which can lead to significant legal and professional repercussions for the testing team and the firm.

Extend the testing window to allow for a safer, non-disruptive exploit.

Why it fails: Extending the testing window without explicit written approval from the client is a violation of the project constraints. The methodology and timeline must be strictly followed, and modifying them unilaterally is unprofessional. The priority should always be reporting the finding within the constraints defined in the policy.

The Statement of Work (SOW).

Why it fails: The SOW outlines the business objectives, deliverables, timelines, and costs of the engagement. While it may reference the RoE, it does not contain the specific technical constraints, emergency protocols, and operational safety rules that define the day-to-day execution of the penetration test as the RoE document does.

The Non-Disclosure Agreement (NDA).

Why it fails: The NDA is a legal contract that governs the handling of confidential information between the client and the tester. It does not contain any technical information regarding the penetration test, nor does it define the scope or the operational procedures required to conduct the security assessment safely.

The Service Level Agreement (SLA).

Why it fails: An SLA is typically used to define the expected level of service, uptime, and performance metrics between a service provider and a customer. It is irrelevant to the penetration testing process, as it does not address the security, scope, or operational procedures required for conducting a penetration test.

Agree to use the tool but run it only during off-peak hours.

Why it fails: Running a tool that causes instability during off-peak hours is still risky and does not address the fundamental issue of the tool's unreliability. Even during off-peak hours, a system crash can have downstream effects on databases or linked services, violating the requirement to maintain system integrity.

Refuse the request and insist on using your own proprietary toolset.

Why it fails: A blunt refusal without explanation is unprofessional. The client may have specific regulatory or compliance reasons for requesting that specific tool. The goal is to collaborate, not to mandate, so providing a technical justification for why an alternative tool is safer and more effective is necessary.

Use the requested tool but ignore the potential instability issues.

Why it fails: Ignoring known risks is a direct violation of professional standards. If the tool is known to cause instability, the tester is obligated to address this before proceeding. Proceeding anyway could result in a service outage, for which the tester and their organization would be held fully accountable.

The personal email addresses of the IT administrators.

Why it fails: Personal email addresses are sensitive information and are not necessary for the technical scope of a penetration test. The focus of the scope should be on infrastructure, applications, and services, not the personal contact details of the staff involved, which should be handled as confidential information.

The specific passwords used for internal testing accounts.

Why it fails: Passwords should never be included in the scope documentation or any plaintext document. If credentials are required for the engagement, they should be exchanged using secure methods, such as a secure vault or encrypted communication, to prevent them from being intercepted or exposed during the project planning.

Ensure that the entire IT staff is informed of the test dates.

Why it fails: Informing the entire IT staff defeats the purpose of an unannounced test, which is designed to assess the readiness of the response team under stress. If everyone knows, the realism of the simulation is compromised, and the team will not act as they would during a real incident.

Launch the test during a holiday weekend to minimize user disruption.

Why it fails: Launching a test during a holiday weekend does not solve the risk of an unannounced test. The primary concern is not user disruption, but rather the potential for incident responders to react to the attack as if it were a genuine threat, potentially causing unnecessary service downtime.

Use only low-impact passive scanning to avoid triggering alarms.

Why it fails: The goal of an unannounced test is to trigger the incident response team. Using only passive scanning will not trigger the alerts necessary to assess the team's response capabilities. The test must be active and realistic to provide the intended value for the client's incident response training.

Continue testing until you have fully compromised the system.

Why it fails: Continuing the test after the agreed-upon hours violates the 'Testing_Time' constraint. This is a breach of the contract and the Rules of Engagement. The tester must stop all activities immediately to remain within the authorized operational window and avoid potential conflicts with the client's scheduled maintenance or monitoring.

Wait until 08:00 the next day to report the vulnerability.

Why it fails: A critical vulnerability requires immediate attention. Waiting until the next day to report it ignores the urgency of the finding and the potential risk to the client's infrastructure. The established 'Escalation' procedure should be used to report the issue as soon as possible, regardless of the testing hours.

Run a full vulnerability scan on the remaining hosts to finish early.

Why it fails: Running additional scans outside the 'Testing_Time' window is a violation of the RoE. The tester must strictly adhere to the operational windows defined in the configuration. Furthermore, running unauthorized scans after hours can disrupt system backups or batch processing that typically occur during these times.

Complete lack of knowledge about the target environment.

Why it fails: This describes black-box testing. In black-box testing, the tester operates without any internal knowledge of the systems, networks, or applications, simulating an external attacker who has no prior information and must perform all reconnaissance and target identification from scratch without any guidance from the client.

Full access to source code, network diagrams, and documentation.

Why it fails: This describes white-box testing. In white-box testing, the tester has total visibility into the target environment, including source code, architecture diagrams, and configuration files. This allows for the most thorough analysis of the system's security but is not the definition of gray-box testing.

Testing only the physical security controls of a facility.

Why it fails: Physical security testing is a specific type of engagement, not a methodology for system-level penetration testing. While physical security can be part of a larger assessment, the term 'gray-box' refers to the level of technical knowledge the tester has about the digital assets they are evaluating.

To outline the payment terms for the penetration test.

Why it fails: Payment terms belong in the Statement of Work or the Master Service Agreement. Including financial details in the Rules of Engagement is inappropriate, as the RoE should be focused strictly on the technical and operational guidelines for the security assessment, keeping the administrative and financial aspects separate.

To detail the specific tools to be used by the tester.

Why it fails: While the RoE may restrict certain types of tools, it is not the place to list every tool that will be used. The tester should have the professional autonomy to choose the appropriate tools for the job, provided they comply with the safety and operational rules outlined in the RoE.

To list the names of all employees who will be interviewed.

Why it fails: An engagement might include social engineering or interviews, but listing specific employees in the scope section is not standard practice. This information is usually handled in the project management or human resources planning phase, as it involves privacy considerations and does not relate to the technical scope.

Contact the third-party service provider immediately to warn them.

Why it fails: Contacting a third-party provider directly violates the contractual relationship with the client. The tester does not have an agreement with the third party, and any unauthorized contact could lead to legal issues or misaligned security efforts. All communication must flow through the client as the primary stakeholder.

Ignore the finding as it is outside the client's direct control.

Why it fails: Ignoring a vulnerability that affects the client's environment is unprofessional. If the vulnerability poses a risk to the client's data or security, it must be reported, regardless of who owns or hosts the infrastructure. The client needs to know about all identified risks to make informed decisions.

Publish the finding on a public bug bounty site for remediation.

Why it fails: Publishing the finding publicly is a severe breach of the Non-Disclosure Agreement and professional ethics. It exposes the client and the third-party vendor to unnecessary risk before they have had the opportunity to remediate the vulnerability. This behavior would effectively end the tester's career and lead to lawsuits.

The public keys of all developers involved in the project.

Why it fails: Public keys are meant for encryption, but there is no need to list them in a data handling plan. The plan should focus on the procedures and policies for securing the data itself, rather than managing the cryptographic assets of the personnel involved in the development process.

The names of all servers used to store the data.

Why it fails: Listing the specific names of servers in a data handling plan provides unnecessary operational information that could become an attack vector if the plan itself is compromised. The focus should be on the security controls, such as encryption and retention policies, not on the physical or logical server names.

A list of all public websites the testers use for research.

Why it fails: Researching public websites is a standard part of the testing process, but it has nothing to do with the data handling plan for sensitive client data. Including such a list is irrelevant and does not address the security requirements for protecting the client's confidential information during the project.

A liability waiver transferring all damages from the testing firm to the hospital.

Why it fails: A liability waiver addresses financial responsibility after an incident, not the ability to stop testing the moment a life-safety system is touched. It is a legal instrument that shifts costs but gives no operational mechanism, contact list, or communication path, so it cannot satisfy counsel's demand for immediate suspension during active testing.

A requirement that all findings be delivered in a written report within thirty days of testing.

Why it fails: A reporting deadline governs post-engagement documentation and has no bearing on controlling activity while testers are on the network. It does nothing to prevent or halt impact to life-safety systems, provides no authority structure, and leaves the immediate-suspension requirement entirely unmet despite being a useful deliverable expectation.

An expanded scan window that limits intrusive testing to overnight hours only.

Why it fails: Restricting testing to overnight hours reduces exposure to clinical staff, but it does not guarantee an immediate stop when a life-safety system is affected mid-scan. A time window is a scheduling control, not a kill switch, and it fails to identify who can order a halt or how that order is verified and acknowledged during the engagement.

A get-out-of-jail-free authorization letter signed only by the tester's project manager.

Why it fails: An authorization letter signed only by the testing side is worthless because the tester cannot grant permission to test the client's own assets. The party that owns or controls the systems must sign; otherwise the tester has no lawful authority and the document offers no protection if law enforcement or a third party challenges the activity during the engagement.

A confidentiality clause that allows the tester to publish anonymized findings at will.

Why it fails: A clause permitting unilateral publication of findings increases exposure rather than limiting it, because it may breach the client's regulatory or contractual obligations. Financial services clients are heavily regulated, so disclosure terms must restrict publication and require written approval, not grant the tester discretion to release anonymized results after the engagement ends.

A verbal agreement recorded in meeting minutes that testing may proceed as discussed.

Why it fails: Verbal permission captured only in minutes is not a reliable legal instrument because it lacks signatures, precise scope language, and an auditable record of consent. If activity is later challenged, minutes are weak evidence compared with a signed authorization, and they typically omit the asset list and time boundaries that define what was actually permitted.

A vulnerability assessment that enumerates and rates missing patches across the environment.

Why it fails: A vulnerability assessment identifies and prioritizes weaknesses but generates no adversary activity for the SOC to detect, so it cannot measure detection or response capability. The client's stated objective is about blue-team performance under attack, and scanning output alone provides no signal about alerting, triage, or escalation effectiveness during an operation.

A wireless survey mapping access point coverage and rogue device presence.

Why it fails: A wireless survey focuses on radio frequency coverage, interference, and unauthorized access points, which is unrelated to assessing detection and response processes. It produces a physical-layer and configuration view, not adversary activity, so it cannot reveal whether analysts notice, prioritize, or escalate an intrusion attempt in progress.

A compliance audit against a regulatory framework with control-by-control evidence collection.

Why it fails: A compliance audit checks whether documented controls exist and are implemented as required, but it does not simulate an attacker or exercise detection paths. The requirement here is to evaluate live SOC reaction to adversarial behavior, which an audit's evidence review and interviews cannot accomplish because no attack activity is generated.

Encrypt all test data at rest and in transit, and avoid accessing any real patient data by using synthetic records.

Why it fails: Encryption and synthetic data are good practices, but they do not replace the legal requirement for a BAA when a business associate may access PHI. Even with strong technical controls, if real PHI is encountered, the lack of a BAA is a compliance violation. The question asks for the most appropriate action before testing begins.

Obtain written authorization from the client's CEO and proceed with testing without additional agreements.

Why it fails: While written authorization is essential for penetration testing, it does not fulfill HIPAA requirements for handling PHI. A CEO's authorization alone does not establish the legal safeguards required when a third party accesses protected health information. Without a BAA, the engagement could violate HIPAA and expose both parties to penalties.

Conduct the test only after hours to minimize the risk of encountering live patient data.

Why it fails: Testing after hours does not eliminate the possibility of encountering PHI, nor does it satisfy HIPAA's contractual requirements. Timing is an operational consideration, but it does not address the legal obligation to have a BAA in place. The client's legal team is concerned with compliance, not just risk reduction.

A clause allowing the tester to disable antivirus software on the mainframe during testing.

Why it fails: Disabling antivirus on a production mainframe is highly risky and unlikely to be permitted. It does not address batch processing concerns and could introduce security vulnerabilities. The RoE should focus on scheduling and communication rather than disabling protective controls.

A provision to use only automated scanning tools to minimize manual intervention.

Why it fails: Automated scanning can still disrupt batch processing if run at the wrong time, and it may not be suitable for mainframe environments. The choice of tools does not mitigate the risk of interfering with scheduled jobs. The key is to control when testing occurs and ensure rapid communication, not to restrict tool usage.

A requirement that all testing be conducted from an external IP address.

Why it fails: External testing may not be relevant or sufficient for a mainframe environment, and it does not directly address the risk of disrupting batch processing. The source of testing traffic is less important than when and how it is conducted. This requirement could even limit the effectiveness of the test if internal access is needed.

Simulate an insider threat by deploying a physical implant in the data center to test physical security controls.

Why it fails: This scenario is about external perimeter testing, not physical security. Deploying a physical implant is unrelated to the stated scope and introduces unnecessary risk and legal complexity. It does not address the client's concern about disrupting production trading systems during external testing. Such an activity would require separate authorization and is not the most appropriate recommendation for this engagement.

Conduct a vulnerability assessment with authenticated scans during off-peak hours and manually validate only critical findings.

Why it fails: While off-peak authenticated scanning reduces some risk, a vulnerability assessment alone does not validate exploitability. The client wants to validate exploitable vulnerabilities, which typically requires penetration testing techniques. Manual validation of only critical findings may miss exploit chains. This option is safer than a full penetration test but does not fully meet the objective of validating exploitable vulnerabilities while managing risk.

Perform a full-scale denial-of-service test against the trading platform to assess resilience under attack conditions.

Why it fails: A denial-of-service test directly threatens the availability of production trading systems, which the client explicitly wants to avoid disrupting. This approach contradicts the stated risk tolerance and could cause financial loss and contractual breaches. It is not a risk-mitigating recommendation; it is a high-risk activity that should only be performed with explicit written authorization and in a controlled maintenance window, not as a general perimeter test.

It is a liability waiver that absolves the tester of any responsibility for system damage.

Why it fails: A liability waiver may be included in a contract, but it does not define scope or authorize testing. The document described is about limiting testing to certain IP addresses, which is a scope definition. A waiver alone would not protect the tester if they tested outside the agreed scope.

It is a service level agreement outlining the expected uptime of the target systems during testing.

Why it fails: A service level agreement (SLA) defines performance and availability guarantees, not testing boundaries. The document in question restricts testing to specific IPs, which is unrelated to uptime commitments. An SLA would not typically list target addresses or authorize testing activities.

It serves as a non-disclosure agreement to protect the client's confidential information.

Why it fails: While an NDA is often part of a penetration testing contract, it does not define the scope of testing. The document described specifically limits testing to certain IP addresses, which is a scope limitation, not a confidentiality agreement. Confusing the two could lead to legal misunderstandings about what is authorized.