How to prepare for a pentest

You’ve decided to conduct a penetration test (pentest) on your system to evaluate its security, identify potential gaps, and improve your overall security posture. But what should you know before starting the assessment? This article will guide you on how to prepare for a pentest, ensuring you get the maximum benefit from the assessment.

Objectives: Know Your “Why”

The first step is to define your objectives and understand the reasons behind the pentest. This clarity will help guide your decision-making throughout the process and ensure that the assessment meets your specific needs.

If the primary goal of your pentest is to meet compliance requirements, it’s crucial to understand the specific standards associated with the compliance you’re aiming for. For example, while there is no explicit rule for SOC 2 that mandates penetration testing, it is highly recommended to assess all public or internet-facing applications. On the other hand, PCI DSS compliance is more stringent and requires testing of all components that handle customer financial and cardholder data, including networks.

But here’s where many organizations miss the mark: compliance-focused pentesting that doesn’t integrate with your broader security program often creates gaps down the line. The most effective approach combines compliance requirements with genuine security improvement objectives.

If your focus extends beyond compliance and is aimed at enhancing the overall security of your entire system, there are several other assessments to consider. These might include phishing and social engineering tests, internal network penetration tests, cloud security assessments, and more, depending on the scope and complexity of your system.

Pre-Work: The Foundation of Success

Scope and Assets

Once you’ve determined which type of assessment you want to conduct, the next step is defining the scope and identifying the assets to be tested. This is where preparation pays dividends—unclear scoping leads to missed vulnerabilities, budget overruns, and findings that don’t align with your actual risk profile.

For example, if you’ve chosen a web application penetration test, you will need to specify which applications will be tested. A common scenario might include testing the following assets: a user-facing application, an admin dashboard accessible over the internet, and an API that is integrated with these applications. If you’re opting for a network pentest, you’ll need to select the specific network ranges to be tested, whether they are external or internal networks.

Pro tip: The organizations that get the most value from pentesting think holistically about their attack surface. Don’t just test what’s easy to scope—consider what attackers would actually target.

Type of Pentest

What type of pentest do you want to conduct: white-box, gray-box, or black-box?

Here’s a quick summary:

• White-box testing provides the pentester with full access to the system, including source code, architecture diagrams, and credentials.
• Black-box testing involves no prior knowledge provided to the pentester, simulating an external attacker with no internal access.
• Gray-box testing is a hybrid approach where the pentester is given partial access, such as user credentials, but not full access to the source code or internal systems.

The type of pentest you choose will determine what information you need to provide to the pentesters and influence the pre-work phase. The key is matching the testing approach to your actual risk scenarios—not just following what everyone else does.

Pre-Work Information

Now that you’ve determined the type of pentest, you can proceed to gathering the necessary pre-work information.

Black-box: This is straightforward—just provide the IPs or URLs you want tested, and you’re ready to go.

Gray-box: For gray-box testing, the primary information you’ll need to provide includes user accounts, API documentation, system architecture diagrams, and user role breakdowns. User accounts are crucial, and typically, you’ll need to supply two accounts for each user role. If your application supports multiple organizations or tenants, make sure to provide accounts from different organizations. Adding dummy data is essential to simulate real user interactions within the application.

For an internal network penetration test, access credentials are required to connect to the scoped network. This may include SSH credentials for logging into physical or virtual machines or VPN access to establish a secure connection to the network. Alternatively, the penetration testing provider may deliver a pre-configured machine that can be plugged into the network, allowing remote access for testing.

White-box: In addition to the information required for gray-box testing, white-box testing typically involves providing the pentester with access to source code, configuration files, and sometimes CI/CD environments. The goal is to give the pentester full visibility into the system, enabling a deeper, more thorough assessment.

For a Cloud Security Assessment, you will need to provide a user account with access to your cloud tenant, granting read-only permissions for all components. This allows the pentester to evaluate the security posture of your cloud assets effectively.

Environment: Production vs. Staging Dilemma

A common question when preparing for a pentest is which environment should be tested: staging, production, or development?

The answer depends on your specific needs, but this decision often makes or breaks the value of your assessment. For compliance purposes, the primary consideration is that when testing in a non-production environment, you must provide proof to the auditor that the test environment mirrors the production environment exactly. This means the code, features, and authentication mechanisms should be identical. It is common for customers to mirror the production environment in a dedicated test environment for the pentest.

While testing in a production environment can be more straightforward, it often raises concerns, particularly for companies who are worried about availability and handling real customer data. Here’s the reality: typically, pentesters do not conduct Denial of Service (DoS) attacks, so there should be no intentional disruption. To avoid interference with real customer data, it’s recommended to provide test accounts for different organizations. This allows pentesters to focus on issues such as Broken Access Control, IDOR (Insecure Direct Object References), and unauthorized access, without compromising actual customer information. Additionally, the scans performed by pentesters are not excessive, and any well-architected application should be capable of handling the traffic generated by these tools—because your application is likely to face real-world scanning and testing by attackers at some point anyway.

Disabling the WAF: A Counterintuitive Must-Do

Another common request from pentesters is to temporarily disable the Web Application Firewall (WAF). While this may seem counterintuitive, as it appears to reduce the security of your application during the test, the reason behind this request is to evaluate the core security of your application, rather than the WAF or other firewall technologies in place.

This is where many organizations get tripped up. For example, if there’s a potential SQL injection vulnerability in your system, but the WAF is effectively protecting that endpoint, the pentester won’t be able to identify the core vulnerability if the WAF is active. WAFs are frequently tested and bypassed, so if a bypass is discovered for the technology you’re using, the underlying vulnerability remains. By testing without the WAF, the pentester can confirm whether the vulnerability exists at the application level, independent of the protection mechanisms in place.

During the Pentest: Communication is Critical

It is important to inform your team that a pentest is taking place, so they are aware of the process and potential impacts. Designate a point of contact who will be responsible for answering the pentester’s questions promptly.

During the pentest, the pentester may encounter issues such as broken features, application-related doubts, or technical challenges. Having a reliable point of contact ensures that these questions are addressed in a timely manner, as pentests are typically time-limited.

Additionally, it’s crucial to schedule time for remediation after the pentest is complete. Make sure your team is prepared to address the findings promptly, as this will help improve your security posture and close any identified gaps.

Conclusion

The level of preparation required can vary based on the type of assessment, the assets you want to test, and the size of your environment. Proper preparation is what transforms pentesting from a compliance requirement into genuine security improvement.

At Thoropass, we’ve seen how proper preparation enhances pentesting outcomes. We provide clear instructions on what you need to do and provide well in advance of your pentest, giving you ample time to gather the necessary information and ensure a successful assessment. More importantly, our integrated approach means your pentest results feed directly into your broader compliance and security program—no gaps, no handoffs, just continuous improvement.

Book a penetration test with Thoropass today to strengthen your security posture while meeting compliance