Vid Grosek

How to Prepare for a Penetration Test

A practical guide for organizations who want to maximize the value of security testing

Most companies order a pentest and expect a report with vulnerabilities. But the real purpose of a pentest isn't just a list of vulnerabilities - it's an opportunity to learn about your actual security capabilities.

1. Types of Penetration Tests

Before ordering a pentest, you need to understand what you actually need:

By Information Level

Black box - Tester receives no information. Simulates an external attacker. Time-consuming but realistic.
Grey box - Tester receives basic information (IP addresses, user accounts). Most common approach.
White box - Tester receives full access to documentation, source code, architecture. Most thorough but least realistic.

By Target

Network pentest - Testing infrastructure, servers, network devices
Application pentest - Testing web, mobile, or desktop applications
API pentest - Testing application programming interfaces
Social engineering - Testing employees (phishing, vishing, physical access)
Red team - Full attack simulation without restrictions

Red Team vs Pentest: A pentest has defined scope and rules. A red team engagement simulates a real adversary - any technique is fair game, the goal is to test your detection and response, not just find vulnerabilities.

2. Defining Scope

Clear scope is critical for a successful pentest:

What Must Be In Scope

List of IP addresses and/or domains
Types of testing (network, application, social engineering)
Testing timeframe (business hours only? weekends?)
Is physical testing included?
Is DoS testing allowed?
Are third-party integrations in scope?

What Must Be Out of Scope

Third-party systems (unless you have authorization)
Production systems that cannot tolerate any disruption
Specific IP addresses or domains to avoid
Sensitive data that shouldn't be accessed even in testing

Warning: Poorly defined scope is the #1 cause of problems during a pentest. Be specific. "Test everything" is not a scope.

3. Legal Preparation

Without proper legal foundation, a pentest is illegal:

Required Documents

Authorization Letter - Signed by someone with actual authority. Without this, testing is a criminal offense. Period.
Rules of Engagement (RoE) - What's allowed, what's not, testing hours, emergency contacts, escalation procedures
NDA - Protects confidential information the tester will see
Statement of Work - Scope, price, timeline, responsibilities, deliverables

Questions for Legal

Do we have authority to authorize testing of all systems in scope?
Are any systems hosted by third parties (cloud, SaaS)?
Do we need to notify our insurance provider?
What's the procedure if testing causes an incident?
Who can authorize test stoppage?

Cloud Considerations

Testing cloud resources often requires additional authorization:

AWS - No longer requires pre-approval for most tests, but check current policy
Azure - Follow Microsoft's penetration testing rules
GCP - Generally allowed, but verify terms of service

4. Technical Preparation

Good preparation saves time and money:

Documentation for the Tester

Network architecture diagrams
List of applications and their URLs
Test user accounts (multiple privilege levels)
API documentation (if application test)
Source code access (if white box)
Previous pentest reports (optional but valuable)

Internal Preparation

Notify SOC/NOC - So they don't block the tester or trigger false alarms (unless you want to test their detection)
Verify backups - In case something goes wrong
Document current state - Baseline for comparison
Prepare rollback plan - For each system in scope
Whitelist tester IP - Only if you're not testing your WAF/IPS

Communication Channel

Who is the primary point of contact?
What's the expected response time?
Which channel do we use (email, phone, Signal, Slack)?
Who can authorize test changes or stoppage?
Emergency contact for critical findings?

Pro tip: Create a shared secure channel (Signal group, encrypted Slack) where the tester can share findings in real-time. This allows your team to learn as the test progresses.

5. During the Test

Daily Communication

Short daily standups (15 min) for status updates
Immediate notification for critical findings
Document everything the tester discovers
Track hours spent vs planned

Don't Fix During Testing

If the tester finds a vulnerability, don't patch it immediately. Why?

The tester needs to see the full picture
Vulnerabilities are often chained together
A fix might hide more serious issues
You're wasting testing time on remediation
The report will be incomplete

The only exception: A critical vulnerability that's actively being exploited in the wild.

Monitor Your Systems

A pentest is an excellent opportunity to test your detection capabilities:

Did your SIEM detect the activity?
Did alerts fire? Which ones?
How long until detection?
Would your SOC have responded appropriately?
Did your WAF/IPS block any attacks?

Ask the tester for timestamps of specific attacks so you can correlate with your logs.

Handling Critical Findings

When the tester reports something critical:

Acknowledge receipt immediately
Assess business impact
Decide: continue testing or pause?
Document the decision and reasoning
If critical and actively exploitable, consider emergency patch

6. After the Test

Report Review

Request a walkthrough meeting - don't just read the PDF
Ask for clarification on anything unclear
Verify all findings are reproducible
Request evidence (screenshots, logs, PoC code)
Challenge severity ratings if you disagree (with reasoning)

Prioritization

Not all vulnerabilities are equally important. Consider:

CVSS score - But don't follow blindly, context matters
Exposure - Internet-facing vs internal only
Data at risk - What data could be compromised?
Exploitation complexity - Does it require authentication? Special conditions?
Chain potential - Is this a stepping stone to something worse?
Business impact - What happens if this is exploited?

Example: A SQL injection on an internal admin panel (CVSS 9.8) might be lower priority than an IDOR on your customer-facing API (CVSS 6.5) that exposes PII of millions of users.

Remediation Planning

For each finding, document:

Who is responsible for the fix?
What is the deadline?
How will you verify it's fixed?
Does the fix affect other systems?
What's the rollback plan if the fix breaks something?

Retest

After fixes are applied, always order a retest. Why?

Fixes often don't work correctly
A new fix can introduce new vulnerabilities
Documentation for auditors and compliance
Closure for the security team

Most pentest providers offer retesting at reduced cost. Budget for it from the start.

Lessons Learned

Schedule a post-mortem meeting:

What categories of vulnerabilities were found?
What does this say about our development practices?
Did our detection capabilities work?
How can we prevent similar issues in the future?
Should we add these checks to our CI/CD pipeline?

7. Common Mistakes

"We pentest once a year for compliance"

If you're testing just to check a box, you won't get real value. A pentest is a learning opportunity, not just a document for auditors. Your attack surface changes constantly - annual testing misses most of it.

"Everything is in scope"

Without clear scope, the tester can't allocate time effectively. Result: shallow testing of everything instead of thorough testing of what matters. "Everything" usually means "nothing done well."

"We don't need documentation, let the tester figure it out"

Time spent discovering basics is time not spent finding vulnerabilities. Black box has its place, but only if you explicitly want to test from an external attacker's perspective. Otherwise, you're paying for reconnaissance you could provide for free.

"We fixed it, so it's secure now"

Without retesting, you don't know if the fix actually works. I've seen "fixes" that made the situation worse. Trust, but verify.

"We'll just use automated scanners"

Scanners find the obvious stuff. They miss business logic flaws, complex attack chains, and anything requiring human intuition. Scanners are a complement to pentesting, not a replacement.

"Our developers will fix things eventually"

Without clear ownership and deadlines, findings languish in a backlog forever. Every vulnerability in your report is a vulnerability an attacker can exploit tomorrow.

Getting Maximum Value

A pentest should leave you with:

Clear understanding of your actual security posture
Prioritized list of vulnerabilities with business context
Actionable remediation guidance - not just "fix the vulnerability"
Knowledge transfer - your team should learn from the findings
Improved detection - you should know how well your monitoring works
Baseline for measuring improvement over time

If you're not getting all of these, you're not getting full value from your pentest.

Need a Penetration Test?

With 18+ years of experience and certifications including OSCE3, OSCP+, I can help identify and remediate security vulnerabilities in your organization.

Get in Touch

Learn more about my areas of expertise:

Table of Contents