What to Expect From a Penetration Test: The Complete Engagement Lifecycle

Why the Process Matters as Much as the Testing

Most organizations commissioning a penetration test for the first time focus on the testing itself -- the phase where someone is actively trying to break into their systems. But the testing phase is only one part of a structured engagement lifecycle, and arguably not the most important one. Poor scoping leads to gaps in coverage. Unclear rules of engagement create legal risk. Inadequate reporting renders the entire effort useless for remediation planning.

Understanding the complete lifecycle helps you prepare effectively, set accurate expectations for your team, and extract maximum value from the engagement. This guide walks through each phase in the order you will experience it.

Phase 1: Scoping

Scoping is where the engagement is defined. It determines what gets tested, how deeply it gets tested, and what the provider needs from you. Insufficient scoping is the single most common cause of unsatisfactory pentest outcomes.

What the Provider Needs From You

Target inventory. Provide specific URLs, IP addresses, IP ranges, and environment details for everything in scope. For web applications, include the production URL, any staging environments that should be tested, and API documentation if available. For network assessments, provide CIDR ranges and indicate which subnets are in scope.

Application context. For application-level testing, explain what the application does, who its users are, and what data it handles. A payment processing platform requires different testing priorities than an internal knowledge base. The more context the tester has about your business logic, the more effectively they can test it.

User roles and credentials. If testing includes authenticated access, provide test accounts for each distinct user role. A SaaS platform with admin, manager, and regular user roles needs all three to properly test authorization controls. Do not provide production accounts with real user data -- create dedicated test accounts in a staging environment when possible.

Compliance requirements. If the pentest must satisfy specific compliance obligations -- PCI DSS Requirement 11.4, SOC 2 CC7.1, or a client contract -- state this upfront. It affects the methodology, scope, and reporting format.

Constraints and exclusions. Explicitly define what is out of scope. Third-party services your application integrates with, production databases that should not be modified, and specific testing techniques that are prohibited (denial-of-service testing, social engineering) should all be documented before the engagement begins.

What You Should Receive

A formal scope document or proposal that includes the targets, testing type, estimated duration, methodology reference, deliverables, and price. Review this carefully. If the scope does not match your expectations, clarify before signing. Adding scope mid-engagement is expensive and disruptive.

Phase 2: Rules of Engagement

The rules of engagement (RoE) are the legal and operational framework for the test. They protect both parties and establish clear boundaries.

Key Elements

Authorization. A formal, signed document authorizing the provider to test the specified targets. This is not optional -- testing without written authorization is legally indistinguishable from an attack. The authorization should be signed by someone with the authority to grant it (typically CTO, CISO, or VP of Engineering).

Testing window. When testing is permitted. Some organizations restrict testing to business hours for monitoring visibility. Others require off-hours testing to avoid user impact. 24/7 authorization is common for external web application testing where the risk of disruption is low.

Communication protocols. How the tester communicates during the engagement. This typically includes a primary point of contact on your side, an emergency contact for critical findings or accidental disruption, and a secure communication channel (encrypted email, Signal, or the provider's platform).

Critical finding notification. An agreement that the tester will immediately notify you if they discover a critical vulnerability that poses imminent risk -- an actively exploited backdoor, exposed credentials, or a vulnerability severe enough to warrant immediate action. Critical findings should not wait for the final report.

Data handling. How the provider will handle any sensitive data encountered during testing. This is particularly important for environments containing PII, financial data, or healthcare records. The provider should specify their data retention and destruction policies.

Escalation procedures. What happens if testing causes unintended disruption. The tester should have a direct line to someone who can make real-time decisions about pausing or adjusting the test.

Phase 3: Reconnaissance

Once the engagement officially begins, the tester starts by gathering information about the target environment. This phase mirrors what a real attacker would do and establishes the foundation for the testing phases that follow.

Passive Reconnaissance

The tester collects information without directly interacting with the target systems:

• DNS enumeration -- Discovering subdomains, mail servers, and infrastructure relationships through DNS records.
• OSINT gathering -- Searching public sources for information about the organization's technology stack, employee details, exposed credentials in data breaches, and infrastructure details.
• Certificate transparency logs -- Identifying all SSL/TLS certificates issued for the organization's domains, revealing subdomains and services that may not be publicly documented.
• Technology fingerprinting -- Identifying frameworks, CMS platforms, and server software from publicly visible indicators.

Active Reconnaissance

The tester interacts directly with the target systems to map the attack surface:

• Port scanning -- Identifying open ports and running services across all in-scope IP addresses.
• Service enumeration -- Determining specific service versions, supported protocols, and configuration details.
• Web application mapping -- Crawling the application to discover all pages, forms, API endpoints, and functional areas.
• Authentication mechanism analysis -- Understanding how the application handles login, session management, password reset, and multi-factor authentication.

This phase typically takes one to two days for a web application engagement and may be longer for network assessments with large IP ranges.

Phase 4: Testing

This is the core of the engagement -- the phase where the tester actively identifies and exploits vulnerabilities. The specific activities depend on the test type, but the general approach follows established penetration testing methodologies.

Web Application Testing

For web application engagements, testing typically covers:

• Authentication testing -- Brute force resilience, credential stuffing defenses, password policy strength, account lockout behavior, MFA bypass attempts, and session fixation.
• Authorization testing -- Horizontal privilege escalation (accessing another user's data), vertical privilege escalation (accessing admin functions as a regular user), and insecure direct object references.
• Input validation -- SQL injection, cross-site scripting (XSS), command injection, LDAP injection, XML external entity (XXE) processing, and server-side request forgery (SSRF) across all input vectors.
• Business logic testing -- Workflow bypasses, price manipulation, rate limiting effectiveness, race conditions, and abuse of intended functionality.
• API security -- Authentication and authorization on API endpoints, parameter tampering, mass assignment, and API-specific vulnerabilities.
• Session management -- Session token entropy, session fixation, cookie security attributes, and session timeout behavior.

Network Testing

For network engagements, testing includes:

• Service exploitation -- Attempting to exploit vulnerabilities in identified services to gain initial access.
• Credential attacks -- Testing default credentials, brute forcing weak passwords, and attempting credential reuse from any discovered credentials.
• Lateral movement -- Moving from the initially compromised system to other systems within the network.
• Privilege escalation -- Escalating from a standard user to administrative access on compromised systems and within Active Directory.
• Data access -- Demonstrating what sensitive data an attacker could reach from the achieved access level.

What You Should Expect During Testing

Testing typically runs for three to ten business days depending on scope. During this period:

• You may notice unusual traffic in your logs and monitoring systems. This is expected. Your security team should be aware that testing is occurring so they do not waste time investigating legitimate test traffic.
• The tester may contact you with questions about intended application behavior. Respond promptly -- delays cost testing time.
• If a critical vulnerability is discovered, you will be notified immediately per the rules of engagement.
• The tester may request additional credentials, access to documentation, or clarification on scope boundaries. Having a responsive point of contact significantly improves engagement quality.

Phase 5: Reporting

The report is the tangible deliverable of the engagement. A professional pentest report should contain several distinct sections, each serving a different audience within your organization.

Executive Summary

A two-to-three page overview written for non-technical stakeholders. It should communicate the overall risk level, the most significant findings in business terms, and strategic recommendations. A board member or CFO should be able to read only this section and understand whether the organization's security posture is acceptable.

Methodology

A description of the testing approach, tools used, and frameworks followed. This section provides audit evidence that the testing was conducted professionally and thoroughly. It also helps technical reviewers understand the coverage of the assessment.

Detailed Findings

Each vulnerability documented with:

• Description -- What the vulnerability is, explained clearly enough that a developer who is not a security specialist can understand it.
• Severity rating -- CVSS score with vector string and justification for the rating.
• Evidence -- Screenshots, request/response pairs, and proof-of-concept demonstrations that confirm the vulnerability exists. This evidence should be sufficient for a developer to reproduce the finding.
• Impact analysis -- What an attacker could achieve by exploiting this vulnerability in the context of your specific environment.
• Remediation recommendation -- Specific, actionable guidance on how to fix the issue. Not generic advice, but a recommendation tailored to your technology stack and architecture.

For more detail on what distinguishes a good report from a poor one, see our guide to pentest report quality.

Risk Rating Summary

A consolidated view of all findings organized by severity, with a risk matrix or heatmap that helps prioritize remediation efforts. This view is useful for project planning and resource allocation.

Phase 6: Remediation

After receiving the report, your development and operations teams address the findings. This phase is entirely on your side, but a good provider supports it.

Prioritization

Not all findings need to be fixed immediately. Prioritize based on:

• Severity and exploitability -- Critical and high findings that are easily exploitable should be addressed first.
• Business impact -- A medium-severity finding on a system handling payment data may warrant faster remediation than a high-severity finding on an internal-only tool.
• Remediation effort -- Quick wins that take minutes to fix (adding security headers, removing exposed files) should be done immediately regardless of severity.
• Dependencies -- Some findings share a root cause. Fixing the underlying issue resolves multiple findings at once.

Timeline

Set realistic remediation timelines. A common approach:

• Critical findings -- Remediation initiated within 48 hours, resolved within one to two weeks.
• High findings -- Resolved within 30 days.
• Medium findings -- Resolved within 60-90 days.
• Low and informational -- Addressed in the next development cycle or accepted with documented risk acceptance.

Provider Support

Quality providers are available to answer questions during remediation. If your development team is unsure how to implement a recommended fix, the tester who found the vulnerability is the best person to clarify. Some providers include a fixed number of consultation hours for remediation support. Others charge separately. Either way, use this resource.

Phase 7: Retesting

Retesting verifies that your remediation efforts actually fixed the vulnerabilities. This is not optional -- it is the step that closes the loop and provides evidence that your security posture has improved.

What Retesting Covers

The tester re-examines each finding that was marked as remediated and verifies that:

• The vulnerability is no longer exploitable.
• The fix did not introduce new vulnerabilities (a common occurrence with hasty patches).
• The remediation is complete, not partial. For example, fixing SQL injection on the login form but not on the search form is incomplete remediation.

Retesting Timeline

Schedule retesting after your remediation sprint is complete. Most providers offer retesting within a defined window (typically 30-90 days after the initial report). Retesting outside this window may incur additional costs because the tester needs to re-familiarize themselves with the environment.

The Deliverable

A retesting report or addendum that updates the status of each finding: remediated, partially remediated, or not remediated. This document serves as compliance evidence that you acted on the pentest findings and verified the results.

How to Prepare Your Team

Preparing your internal team before the engagement reduces friction and improves outcomes.

Notify your security operations team. If you have a SOC or security monitoring, they need to know testing is occurring. Without notification, they may block the tester's traffic, trigger incident response procedures, or waste time investigating legitimate test activity.

Prepare test accounts. Create dedicated accounts for each user role before the engagement starts. Do not make the tester wait for credentials during the testing window -- every hour spent waiting is an hour not spent testing.

Brief your development team. Developers should know a pentest is happening and should be prepared to answer questions about application behavior. They should also be prepared to begin remediation work when the report arrives.

Designate a responsive point of contact. The tester will have questions. A responsive contact who can provide answers, grant additional access, or clarify scope boundaries within hours (not days) directly impacts the quality of the engagement.

Review your logging and monitoring. A pentest is an excellent opportunity to test whether your detection capabilities actually work. Can your team distinguish pentest traffic from real attacks? If not, that is a finding in itself.

Timeline Summary

A typical web application penetration test engagement follows this approximate timeline:

Phase	Duration	Your Involvement
Scoping	1-2 weeks	High -- providing target details and requirements
Rules of engagement	3-5 days	Medium -- reviewing and signing documents
Reconnaissance	1-2 days	Low -- answering occasional questions
Testing	3-10 days	Low-medium -- responsive contact available
Reporting	3-5 days	None -- waiting for deliverable
Remediation	30-90 days	High -- your team fixes findings
Retesting	1-3 days	Low -- confirming fixes are deployed

Total elapsed time from kickoff to retesting completion is typically two to four months, though the active testing and reporting phases take only two to three weeks.

Next Steps

If you are ready to scope a penetration testing engagement, our PT Scoping Wizard guides you through defining your requirements and produces a structured scope document.

To understand the methodologies that drive professional penetration testing, read our penetration testing methodology guide. And if you are still evaluating providers, our guide on how to choose a penetration testing company covers the criteria that matter most.

View our security assessment services to discuss your specific testing needs.