Pre-Pentest Checklist: Essential Questions to Answer Before Your Next Pentest

Diving into pentest readiness, this comprehensive preparation guide is adaptable to different types of pentest, regardless of the target's size or complexity.

In this Pre-Pentest Checklist Series, we explore the foundational aspects of pentesting—focusing on the what, why, when, who, and how to ensure your pentest not only meets compliance standards but also serves as a strategic asset in your security portfolio. We'll guide you through a structured checklist, equipping you with the insights needed to initiate a pentest that's tailored to your organization's unique needs and security objectives. 

"What?"

1. What is the scope?
2. What are your success criteria for the pentest?
3. What key areas would you want the pentester(s) to focus on?
4. What type of pentest would you like done?
5. What type of environment does the pentest need to be conducted on?
6. What restrictions (if any) need to be applicable?
7. What credentials/certifications should the pentester(s) possess?
8. What type of deliverables do you need out of this pentest?
9. What are your internal timelines to fix Critical and High severity vulnerabilities?

"Why?"

1. Why do you need a pentest? (e.g., compliance, security posture assessment, customer assurance)
2. Why is this the right time for a pentest in your security lifecycle?
3. Why have you chosen this particular scope for the pentest?

"When?"

1. When do you expect the pentest to kick off and conclude?
2. When do you need the final report?
3. When is the best time for your team to be involved in the pentest process?

"Who?"

1. Who should be informed about the pentest initiation, progress, and findings?
2. Who will be the primary point of contact for the pentesting team?
3. Who within your organization will be responsible for addressing the findings?

"How?"

1. How will the vendor communicate with you before, during, and after the pentest?
2. How will the pentesters access the in-scope assets?
3. How will the final deliverables be shared with you?

1. What is the scope?

First and foremost, define what needs to be tested.

Include the assets you'd want tested, and remember to call out components or features you'd like to be considered as out-of-scope of the test.

Example:

• We want to do a web app pentest on our customer-facing financial web application but exclude the payment flow involving credit cards as it touches third-party vendors.
• We want to test all subnets as part of the internal network pentest except subnets 192.168.1.0/25 and 192.168.1.128/25, which belong to the executives.

View the assets that can be tested with a HackerOne Pentest, along with their associated methodology.

2. What are your success criteria for the pentest?

Considering this question and pondering it internally with the stakeholders is essential. Once you have reached an answer, share it with your pentest vendor so they're aligned to meet your goal.

Some common responses shared with me in the past:

• "Knowledge of as many vulnerabilities as possible, especially Critical and High severity."
• “Very few or no vulnerabilities at all — validation that we are secure."
• “New vulnerabilities which could have been introduced since past pentests."
• “Well-written vulnerabilities with detailed steps to remediate each."
• “We have 10 objectives defined for the engagement and need to meet at least 4 of them."

3. What key areas would you want the pentester(s) to focus on?

This question may not apply to every customer or pentest. Still, if you recently made changes to the access control model of your web application, you'd want to call those out so the pentesters can prioritize accordingly.

For an internal network pentest, where pentesters simulate a regular employee's access, it may be worth calling out subnets or crown jewels that are typically inaccessible. If a pentester can access those, this alone is valuable information.

Another common area of focus is Personally Identifiable Information (PII) or information that can be used on its own or with other information to identify a person.

Identifying the key areas to test will guide the pentester's focus throughout the engagement and help you gain the most value out of the pentest.

4. What type of pentest would you like done?

Taking the example of web app penetration testing, would you prefer to conduct an authenticated (gray-box) or unauthenticated (black-box) test?

Authenticated Testing:

• How will accounts be provisioned? Do you need to provision accounts for the pentesters, or can they self-sign up?
• How many roles will require testing? Think about administrator vs. manager vs. user roles. Ensure that at least two accounts are available to the pentesters to test for horizontal privilege escalation.
• If you decide to provision accounts for the pentesters, consider what information you may require from them. Such as a mobile number to enable two-factor authentication (2FA).

Unauthenticated Testing:

• You may choose this route to perform real-world testing for assets on the public internet. However, there is a chance to miss vulnerabilities exploitable by users with appropriate access.

It is common to see a combination of authenticated and unauthenticated testing, depending on the use case and maturity of the assets in scope for testing.

5. What type of environment does the pentest need to be conducted on?

Again, taking the example of web app penetration testing, you'd want to decide whether a staging (also referred to as non-production, QA, or test) environment, set up identically to the production, is best for testing needs or a production environment will be best suited for the type of testing that you'd like conducted.

If a Web Application Firewall (WAF) is enabled, ensure the pentester's IP address is added to an allow-list to paint an accurate state of security of the tested web application unless your goal is to test the effectiveness of the WAF.

6. What restrictions (if any) need to be applicable?

• Time of testing: If the asset being tested is a part of your daily operations, conducting the pentest outside of business hours may be necessary. To ensure that the testing does not cause any disruption to your operations, it is advisable to have a team member or members on standby in case any operational resources experience downtime during the test.
• Days of testing: The pentest may need to be performed on weekdays only so your internal team can support it if things go south.
• Specialized skills: It's crucial to identify the specialized skills required for the pentest upfront, such as Web 3.0, Azure, AWS, Google Cloud, etc.

Side note: Define the requests per minute (rpm) threshold in advance to ensure the pentesters are aware before starting the pentest if you foresee resource exhaustion as a concern.

7. What credentials/certifications should the pentester(s) possess?

It may be driven by compliance or due diligence efforts to ensure qualified and professional pentesters touch your assets.

Certifications such as OffSec's OSCP, OSCE, OSWA, and others, CREST Registered Penetration Tester (CRT), and CREST Certified Tester — Infrastructure (CCT-INF) are popular mentions.

Meet our elite Community of pentesters.

8. What type of deliverables do you need out of this pentest?

Deliverables are the tangible products received at the end of the pentest. This can include:

• Penetration Test Report — Initial vs. Final (includes retesting results)
• Letter of Attestation
• Executive Summary
• CSV format tracker of the number of identified vulnerabilities

Review your pentest vendor's sample deliverables to understand if they meet your needs. If something does not match, be open to asking them if they can accommodate your requirements. More often than not, any reasonable requests will be accommodated.

View deliverables with your HackerOne Pentests.

9. What are your internal timelines to fix Critical and High severity vulnerabilities?

Defining timelines in advance will help set expectations with the internal team and stakeholders, avoid delays, and ensure timely retesting requests are made to the pentesters.

"Why?"

1. Why do you need a pentest?

Companies conduct penetration tests for various reasons. Here's a list of popular reasons:

• To meet and demonstrate compliance with specific regulations, such as PCI DSS.
• Ensure that any changes made to the product do not introduce new vulnerabilities.
• Ensure the detection tools, such as IDS, IPS, SIEM, SOAR, and UEBA, promptly identify, notify, and take actions (where applicable) regarding the pentest in motion.
• Validate results from a vulnerability scanner.
• Tap into a talent pool and get more eyes with fresh perspectives on their assets.

The answer to this question will guide the goals you want to achieve out of the pentest.

2. Why is this the right time for a pentest in your security lifecycle?

The response is closely linked with the purpose of the pentest, and here are some common reasons:

• Before a major launch or update: Before the launch of a new application, website, or any significant update to an existing system, a pentest can be critical. 
• After significant code changes: A pentest can help validate that any major changes to an application’s source code did not introduce new security vulnerabilities.
• Continuous improvement: A pentest should not be a one-time event. Ideally, it should be integrated into a security program and conducted regularly (e.g., quarterly or annually) to proactively identify and address vulnerabilities before they can be exploited.
• Following a security incident: If you've recently experienced a security incident, a pentest can help identify any underlying vulnerabilities that may have contributed to the breach. 

3. Why have you chosen this particular scope for the pentest? 

Scoping a pentest accurately is essential, given the time-bound nature of the assessment. Additionally, it sheds a spotlight on the key areas that require the most attention. A few examples:

• Risk prioritization: Driven by the most critical assets/features in an application or carefully testing the crown jewels of the organization.
• Implementation of security controls: With a newly installed SIEM solution, you may consider running specific attacks against the network infrastructure to observe how they respond and if they are working as intended.
• Phased Approach: If a pentest is part of a larger security assessment, explain how the chosen scope lays the foundation and how it fits in your overall pentest strategy.

"When?"

1. When do you expect the pentest to kick off and conclude?

Defined timelines are crucial to meeting deadlines, especially when a pentest is part of a broader risk management strategy and impacts subsequent projects.

2. When do you need the final report?

On a similar note to the previous question, it is critical to inform the vendor as soon as possible of any deadlines to meet for the final report. It is standard to share the final report within a week of the pentest’s conclusion.

3. When is the best time for your team to be involved in a pentest?

Pentests are time-bound; therefore, ensuring that all key and relevant team members are available, have time to dedicate to and promptly respond to any questions before launching and during the pentest.

"Who?"

1. Who should be informed about the pentest?

If maintaining a low profile is not a primary objective, such as in a Red Team engagement, it is advisable to inform your organization's defenders about an upcoming penetration test. This will enable them to concentrate on actual threats rather than the traffic generated by an authorized penetration test.

It is common that pentesting teams will share the testing IP addresses so you can inform the appropriate individuals protecting your organization’s infrastructure, such as your Security Operations Centre (SOC) teams. This is expected, so feel free to ask the pentesting team for them.

2. Who will be the primary point of contact for the pentesting team?

Designating a person for this role can significantly improve the efficiency of the process and enhance collaboration throughout the pentest. 

Although it is preferable that this person be a Subject Matter Expert (SME) of the product or asset being tested, it is not mandatory. They will be responsible for addressing questions that the pentesters may have about the in-scope assets and how the different components interact and if they do not have the answers they should know who to contact within the organization to get the answers.

Furthermore, they can serve as a point of escalation for the pentesters in case a critical or high-severity vulnerability is discovered.

3. Who within your organization will be responsible for addressing the findings?

Identifying product owners and teams responsible for the asset being tested is crucial to address reported vulnerabilities during the pentest, especially the critical and high-severity ones requiring immediate attention.

"How?"

1. How will the vendor communicate with you before, during, and after the pentest?

Establishing open communication channels and promptly responding to any pentester questions is vital to a successful experience with your chosen pentest vendor.

This could be as simple and efficient as creating Slack channels for quick chat among members involved in the pentest. This is the most effective form of communication with a pentesting team and how we connect pentesting teams with customers at HackerOne. Slack communication can be both synchronous and asynchronous depending on availability, and it provides a documented timeline. Emails can be a slow means of communication while the pentest is ongoing, and phone calls are beholden to limitations of availability and scheduling.

2. How will the pentesters access the in-scope assets?

It is critical that the pentesters can hit the ground running on day 1 of the pentest; hence, validating that they can successfully access the in-scope assets is crucial.

• Are the assets Internet-facing or internal-only?
• Will the mobile apps be available in their respective stores? Alternatively, will they be available via TestFlight or as a .apk file?
• Do the pentesters need a VPN to connect and access the assets?
• Do you need to add their IP address to an allow-list on your perimeter devices?
• Will they need credentials to test? How will these be provisioned?

3. How will the final deliverables be shared with you?

Now, let's be very careful about how this occurs. You do not want to receive an unprotected PDF over email as the final report.

Ensure that the report is securely shared with you. Vendors are known to share these:

• Host it on their trusted pentest platform, which you can access and download.
• Use a mutually agreed upon secure file-share platform.
• A password-protected PDF is sent over email or other communication channels, where the password is shared out-of-band.

The Ease of HackerOne Pentest 

The right preparation can transform your pentest from a compliance checkbox into a pivotal component of your strategic security planning. The path to optimized pentesting doesn't end here. HackerOne Pentest simplifies the pentest process, combining operational efficiency with unmatched support by expert Technical Engagement Managers (TEMs) to enhance your experience in each and every security testing engagement. 

Are you ready to take the next step with Pentest as a Service (PTaaS)? Share your pentesting requirements with us, and let our experts tailor a strategy that aligns with your security goals.