Security Insights
How to prepare for a penetration test
By John 
How to Prepare for a Penetration Test
If you’ve never commissioned a penetration test before, you probably have questions that go beyond “what does it cost?” — things like: what do I actually need to do before we start? What do I need to have ready? How do I know if we’re set up for success?
This guide answers those questions directly. The upfront work on your end isn’t heavy, but skipping it creates friction that slows down the engagement and can reduce the quality of findings.
This is the third article in a short series on penetration testing. The first, What Is Penetration Testing?, covered the fundamentals. The second, What to Expect During a Pentest, walked through the engagement itself. This piece focuses on what you need to have in place before testing begins.
What Does Preparing for a Penetration Test Actually Involve?
Prepping for a pentest isn’t about technical complexity on your side. It’s about clarity: knowing what you want tested, who needs to be available, and what environment the testers should work in. Get those things defined before the engagement kicks off, and the rest tends to follow.
The six areas worth thinking through:
- Timeframe
- Scope — what to test
- Environment — production vs. staging
- Credentials and testing approach
- Availability during the engagement
- Reviewing results
1. Set a Realistic Timeframe
Before reaching out to a provider, know when you need the test completed. Most organizations underestimate lead time.
Plan for 2–6 weeks of lead time before testing begins. This covers scoping discussions, logistics, and any internal prep — including access provisioning and environment readiness.
The testing itself typically runs 2–4 weeks, depending on scope. Set those expectations with your team before the engagement starts. Pressure to finish faster doesn’t produce faster results — it produces shortcuts and missed findings. Those findings rarely stay quiet for long.
2. Decide What to Test: Defining Scope for a Penetration Test
One of the most important decisions you’ll make before a pentest is scope. This is where a lot of first-timers struggle.
“Test everything” sounds like due diligence. In practice, it creates ambiguity, drives up costs, and makes timelines harder to manage. The goal isn’t to restrict testers — it’s to focus them on what actually needs attention.
How to define scope for a web application or SaaS pentest
Be specific about what’s included and what isn’t. A few practical examples:
- Test all functionality of the SaaS application at https://app.example.com, including related subdomains. Nothing outside this domain is in scope without explicit approval.
- Social engineering is limited to the following employee list. Only business email addresses are in scope — no personal email or social media unless separately authorized.
- No denial-of-service attacks against production infrastructure that could impact legitimate users.
- The following IP blocks are authorized for testing. IPs identified outside these ranges require approval before being accessed.
The wider the scope, the higher the cost — in both time and dollars. If you’re unsure where to draw the line, that’s exactly the conversation to have with your provider before anything is signed. A good firm will help you find a scope that’s neither too narrow to be meaningful nor so broad it becomes unmanageable.
Deciding which apps to include in your pentest
For organizations with multiple applications, prioritize by risk. Ask yourself:
- Which applications handle the most sensitive data?
- Which are customer-facing or externally accessible?
- Which have had the least security review to date?
- Which are subject to compliance requirements (SOC 2, ISO 27001, etc.)?
Start there. You don’t have to test everything at once — and a phased approach often produces better results than trying to cover everything in a single engagement.
3. Choose the Right Environment: Production vs. Staging
For corporate network tests, this question answers itself. For SaaS and web application tests, it comes up almost every time.
Most testers prefer production. Others will work with whatever you provide. My recommendation: test in an environment that reflects what your clients actually use.
If staging is configured with the same access controls, integrations, and protections as production, it’s a valid option — often the preferred one. The point of a pentest is to verify that the right controls are protecting sensitive data. If staging mirrors production on that front, the primary difference is exposure to live users.
Consider the downside scenario: if a tester crashes the environment or triggers something unexpected, what’s the business impact? For most clients, that answer pushes them toward a non-production environment — provided it genuinely mirrors production. With modern DevOps practices, maintaining production-equivalent staging is far more achievable than it used to be.
If you test in production, expect the timeline to extend. Testers move more carefully to avoid impacting live customers. If you choose staging, keep it stable — pushing new builds mid-engagement without notifying the testers can invalidate work already completed.
4. Understand Testing Approaches: Black-Box, Grey-Box, and White-Box
A question we get often at EliteSec: Do you do black-box, grey-box, or white-box testing?
For web application work, we default to grey-box. Here’s what each approach means:
| Approach | What’s provided | What gets tested |
|---|---|---|
| Black-box | Nothing | Testers attempt to gain access with no prior knowledge |
| Grey-box | User credentials | Authenticated functionality, without source code |
| White-box | Credentials + source code | Full review including code-level vulnerabilities |
We prefer grey-box because it reflects realistic attacker conditions while still allowing us to test authenticated features thoroughly. Black-box testing is useful for assessing external exposure; white-box is valuable when you want the deepest possible code review.
What credentials will you need to provide?
For grey-box and white-box engagements, plan to provide user credentials before testing begins. Many engagements also require multiple account types — different privilege levels are necessary to test access controls, privilege escalation paths, and functionality restricted to admin or power users.
Ask your provider upfront what accounts they need. Sorting this out before day one prevents a blocker from delaying the start of active testing.
5. Designate an Emergency Contact
Penetration testing isn’t entirely passive on your end. Things come up — account lockouts, aggressive scans taking a service offline, an exploit disabling part of an application. It happens, even with experienced testers.
Before the engagement starts, designate a contact person the testing team can reach quickly when something needs immediate attention. This matters especially if testing runs outside business hours.
Define how that person prefers to be contacted — email, phone, Slack, whatever fits your team. The communication channel matters less than the availability. Make sure the designated contact is actually reachable during the engagement window, not just nominally assigned.
6. Plan for the Final Report and Debrief
At the end of the engagement, you’ll receive a final report covering every finding — how to reproduce each issue, evidence it exists, severity rating, and remediation guidance.
Don’t let it sit in your inbox.
Review the report as soon as it’s delivered. The longer confirmed vulnerabilities go unaddressed, the longer your exposure window stays open. Most firms, including EliteSec, offer five free retests — so there’s every reason to remediate and validate quickly rather than queue it for later.
Also plan for a post-engagement debrief. This is the meeting to ask questions, challenge findings, and get clarity on anything that isn’t landing clearly in the written report. Think about who should attend — security, engineering, compliance, and leadership all have different stakes in the findings, and the right people in the room makes remediation faster.
Pentest Preparation Checklist
Before your engagement begins, confirm you have the following in place:
- Target date established and communicated to your provider
- Scope defined in writing — what’s included, what’s excluded
- Applications and systems prioritized by risk
- Environment decision made (production vs. staging) and provider notified
- Testing approach confirmed (black-box, grey-box, or white-box)
- Required credentials provisioned and ready
- Emergency contact designated with contact method defined
- Post-engagement debrief scheduled (or flagged to schedule on delivery)
If you’re planning a pentest and want to talk through scoping, environment decisions, or testing approach before committing, that conversation costs nothing. Reach out to EliteSec — getting the setup right is what determines whether a pentest is genuinely useful or just a checkbox exercise.
For more on what to look for when selecting a provider, see How to Choose a Reputable Penetration Testing Firm. If you want a walkthrough of the engagement itself once preparation is done, revisit What to Expect During a Pentest. And if you’re newer to the concept, What Is Penetration Testing? is the right starting point.
