You've signed the contract. The pentest is scheduled. Now what? If you've never been through a penetration test before, the process can feel like a black box. You hand over access, wait a week or two, and hope the report doesn't contain anything catastrophic.
It doesn't have to be that way. A good penetration test follows a structured methodology with clear phases, regular communication, and no surprises at the end. Here's exactly what happens from the first call to the final report, so you know what to expect at every step.
This is different from a vulnerability scan, which is automated and surface-level. A penetration test is a manual, adversarial exercise conducted by security professionals who think like attackers. Understanding the process helps you get more value from it.
Phase 1: Scoping and pre-engagement
Every pentest starts with scoping. This is the most important phase of the entire engagement, and it happens before anyone touches your systems. Bad scoping leads to bad results, wasted time, and findings that don't match what you actually needed tested.
During scoping, you and the testing team define exactly what's being tested. That means identifying the target environment: is this a web application, an API, cloud infrastructure, an internal network, or some combination? Each has different methodologies, tooling, and time requirements.
You'll also establish the rules of engagement. This covers the testing window (business hours only, or 24/7?), whether social engineering is included, which systems are explicitly off-limits, and how the testers should handle sensitive data if they find it. If you have a staging environment, this is typically the preferred target so production traffic isn't affected.
The scoping call also covers access requirements. For a white-box or gray-box test, testers need credentials, API documentation, architecture diagrams, and network access. For a black-box test, they need as little as possible, simulating an external attacker. Most modern pentests are gray-box because it's the most efficient use of time and budget.
Finally, you'll designate a point of contact and establish communication channels. If the testers find a critical vulnerability mid-engagement, they need to be able to reach someone immediately rather than waiting for the final report.
Key takeaway: Spend time on scoping. A well-scoped engagement means testers focus on what matters most to your business. If you rush through this phase, you'll get generic results instead of targeted findings.
Phase 2: Reconnaissance and information gathering
Once the engagement officially starts, testers don't immediately begin attacking your systems. They start by gathering intelligence, just like a real attacker would.
Passive reconnaissance comes first. This involves collecting publicly available information about your organization without directly touching your systems: DNS records, WHOIS data, SSL certificate details, technology fingerprinting from HTTP headers, job postings that reveal your tech stack, code repositories, and leaked credentials from previous breaches. You'd be surprised how much an attacker can learn without sending a single packet to your infrastructure.
Active reconnaissance follows. This is where testers begin interacting with your systems directly: subdomain enumeration, port scanning, service identification, and mapping the application's attack surface. For a web application, this means crawling every page, identifying all input fields, mapping API endpoints, and understanding the authentication and authorization model.
Experienced testers spend a significant portion of the engagement in this phase. The better the reconnaissance, the more targeted and effective the testing that follows. A tester who understands your application's architecture, business logic, and data flows will find vulnerabilities that a surface-level scan would miss entirely.
Phase 3: Vulnerability discovery
This is the phase most people think of when they hear "penetration test." Testers systematically probe your systems for security weaknesses using a combination of manual techniques and automated tools.
The core of vulnerability discovery is manual testing. Professional pentesters work through established methodologies, primarily the OWASP Testing Guide for web applications, which covers injection flaws, broken authentication, access control failures, security misconfigurations, and dozens of other vulnerability categories. This is skilled, hands-on work that requires understanding how your application is supposed to function so testers can identify where it can be made to behave unexpectedly.
Automated scanning supplements manual testing but never replaces it. Scanners are effective at finding known vulnerabilities in software components, missing security headers, outdated libraries, and common misconfigurations. But they generate false positives, miss business logic flaws, and can't understand context. A scanner can't tell you that your "admin" role can access another tenant's data because it doesn't understand your authorization model. A human tester can.
Business logic testing is where manual testing truly shines. Can a user manipulate a price field during checkout? Can someone skip steps in a multi-stage workflow? Can a regular user access admin functionality by modifying a request? These are the vulnerabilities that matter most to your business, and no automated tool can find them. This is also what distinguishes a penetration test from a code review, which analyzes source code rather than testing running applications.
Authentication and authorization testing gets particular attention. Testers check for weak password policies, session management flaws, token predictability, privilege escalation paths, and insecure direct object references. These findings tend to have the highest business impact because they directly affect who can access what.
Phase 4: Exploitation and validation
Finding a potential vulnerability is only half the job. The exploitation phase is about proving that a weakness is real and demonstrating its actual impact.
There's an important distinction between "this could be exploited" and "we proved it can be exploited." A vulnerability scanner might flag a potential SQL injection based on an unusual response. A penetration tester will craft a specific payload, extract data from the database, and document exactly what an attacker could access. That proof-of-concept turns a theoretical risk into a concrete business problem that demands attention.
During exploitation, testers develop proof-of-concept demonstrations for each confirmed vulnerability. These are carefully constructed to prove the vulnerability exists and show its impact without causing damage. A tester proving a data exposure issue might extract a single record to demonstrate access, not dump the entire database. The goal is evidence, not destruction.
Responsible handling of sensitive data is critical during this phase. If testers encounter personally identifiable information, financial data, or credentials, they document the access path and immediately notify the point of contact. Professional firms have strict data handling policies. Any sensitive data encountered during testing is reported, not retained.
Exploitation also helps determine accurate severity ratings. A cross-site scripting vulnerability that only works in a rarely-used browser is less severe than one that works everywhere and can steal session tokens. Actual exploitation provides the context needed to rate findings appropriately, which matters when your engineering team is prioritizing remediation work.
Phase 5: Post-exploitation and lateral movement
Not every pentest includes this phase. It depends on the scope you agreed to in Phase 1. But when it's included, post-exploitation answers the question: "What happens after an attacker gets in?"
Privilege escalation is the first objective. If testers gained access as a regular user, can they elevate to an administrator? Can they access the underlying server? Can they reach the database directly? Each step of escalation represents a compounding increase in business impact.
Lateral movement explores how far an attacker could spread from the initial point of entry. From a compromised web server, can they reach internal systems? Can they pivot to other applications, databases, or cloud resources? This phase often reveals that what looked like a moderate-severity web vulnerability is actually a gateway to your entire infrastructure.
Demonstrating business impact is the goal. Testers document what sensitive data they could access, what systems they could control, and what damage an attacker could realistically cause. This narrative, the chain from initial vulnerability to business-critical impact, is often the most valuable part of the entire engagement because it tells a story that executives and board members understand.
For organizations pursuing SOC 2 compliance, post-exploitation findings often highlight gaps in network segmentation and access controls that auditors specifically look for.
Phase 6: Reporting and debrief
The report is the deliverable. Everything else leads to this. A good pentest report is not a list of scanner output; it's a structured document that serves multiple audiences and drives remediation.
Every quality report includes an executive summary written for non-technical stakeholders. This section covers the overall risk posture, the most significant findings, and strategic recommendations in plain language. Your CISO, CTO, or board should be able to read this section and understand the situation without wading through technical details.
The methodology section documents what was tested and how. This provides assurance that the testing was thorough and follows recognized standards. It also helps auditors understand the scope and approach if you're using the report for compliance purposes.
Each individual finding includes a severity rating (typically using the CVSS scoring system), a detailed description of the vulnerability, step-by-step reproduction instructions with screenshots, the demonstrated impact, and specific remediation guidance. Your developers should be able to pick up a finding, understand what's wrong, and know exactly how to fix it.
Remediation guidance goes beyond "fix the SQL injection." Good reports explain the root cause, provide specific code-level or configuration-level recommendations, reference relevant security standards, and prioritize fixes based on risk. Strategic recommendations address systemic issues: if the testers found five different access control failures, the report should recommend improving the authorization framework, not just patching five individual bugs.
The debrief call is where the testers walk your team through the findings in person. This is your opportunity to ask questions, understand the attack chains, discuss remediation approaches, and clarify anything in the report. Make sure your developers attend this call, not just management. The people who need to fix the issues should hear directly from the people who found them.
How long does a pentest take?
Timeline and cost vary significantly based on scope, complexity, and the depth of testing required. Here's a general guide:
| Scope | Duration | Typical Cost Range |
|---|---|---|
| Web Application | 1-2 weeks | $5,000 - $15,000 |
| API | 1 week | $5,000 - $10,000 |
| Mobile App | 1-2 weeks | $8,000 - $15,000 |
| Cloud Infrastructure | 1-2 weeks | $8,000 - $20,000 |
| Internal Network | 1-2 weeks | $10,000 - $25,000 |
These ranges reflect the active testing phase. Add 1-2 weeks for scoping and pre-engagement, and another week for report delivery and debrief. The total end-to-end timeline from first call to final report is typically 4-6 weeks.
Cost is driven by scope and complexity, not just time. A simple web application with a handful of user roles is faster to test than a complex SaaS platform with multi-tenant architecture, dozens of API endpoints, and integrations with third-party services. If you need help understanding what preparation looks like, we've written a detailed guide.
How to prepare your team
The best pentests happen when the client is prepared. Here's what you should have ready before the engagement starts:
Pentest preparation checklist:
1. Provision test accounts with multiple roles. Create dedicated accounts for each user role in your application (admin, regular user, read-only, etc.). Don't reuse real accounts.
2. Prepare a staging environment. Ideally, testers work against a staging or pre-production environment that mirrors production. This avoids risk to real users and data.
3. Share architecture docs and API specs. Swagger/OpenAPI docs, architecture diagrams, data flow diagrams, and network topology information help testers focus on what matters.
4. Designate a point of contact. Someone who can answer questions during the engagement and respond quickly if a critical vulnerability is found.
5. Brief your SOC/monitoring team. Your security operations team needs to know a pentest is happening so they don't block the testers or trigger an incident response. Whitelist testing IPs if needed.
6. Don't fix things mid-test. If testers report a finding during the engagement, resist the urge to patch it immediately. Let the test complete so the report captures the full picture. You can remediate afterward and request a retest.
Preparation directly affects the quality of your results. A tester who spends the first two days troubleshooting access issues is a tester who isn't finding vulnerabilities. The more friction you remove up front, the more value you get from the engagement.
A penetration test is a structured, professional engagement with clear phases and predictable outputs. There's no reason to go into one blind. Understanding the process helps you prepare better, communicate more effectively with the testing team, and ultimately get a report that drives real security improvements instead of collecting dust in a shared drive.
The organizations that get the most value from pentests are the ones that treat them as collaborative exercises rather than pass/fail exams. Your testers are on your side. The goal isn't to embarrass your engineering team; it's to find the weaknesses before someone with bad intentions does.
Ready for Your First Pentest?
We walk you through every step, from scoping to final report. No jargon, no surprises, just clear results.
Book a Consultation How to Choose a Vendor
