What to Expect During a Professional Penetration Testing Engagement

You've approved the budget. You've selected a provider. The penetration testing engagement is scheduled to start next Monday. Now what?

If this is your first engagement, or your tenth, knowing what happens during each phase helps you prepare effectively, support the testers, and extract maximum value from the investment. A well-prepared client receives better testing. A client who understands the process asks better questions and makes faster decisions when the testers need input.

Most penetration testing engagements follow a consistent structure: scoping and pre-engagement planning, reconnaissance and discovery, testing and exploitation, analysis and reporting, remediation support, and retesting. Each phase has specific activities, deliverables, and things the client needs to provide or decide.

This guide walks through each phase of a professional penetration testing engagement from the client's perspective: what happens, what you'll be asked, what to prepare, what decisions you'll make, and what you'll receive at the end. For the technical methodology behind each phase, see our methodology guide.

Phase 1: Scoping and Pre-Engagement (1 to 2 Weeks Before Testing)

What Happens

Before any testing begins, the provider works with you to define exactly what will be tested, how it will be tested, and what the rules of engagement are. This is the most important phase because scope errors here cascade through the entire engagement.

What You'll Be Asked

What systems are in scope? The provider needs specific targets: URLs for web applications, IP ranges for network testing, API documentation for API testing, app store links or builds for mobile testing, and cloud account identifiers for cloud testing.

What is out of scope? Systems the testers should not touch. Third-party systems you don't own. Production databases with real customer data that cannot be modified. Specific functionality to avoid (e.g., password reset that sends real emails to customers).

What testing approach? Black box (testers receive no information), white box (testers receive full documentation and source code), or grey box (testers receive some information like user credentials). See our comparison guide.

What compliance requirements apply? If the engagement must satisfy PCI DSS, SOC 2, ISO 27001, or other frameworks, the provider needs to know during scoping so the report maps findings appropriately. See our compliance guide.

Who are the contacts? Technical point of contact (for questions during testing), management point of contact (for critical finding escalation), and emergency contact (for issues outside business hours).

What You Need to Prepare

Test accounts. Create dedicated test accounts at every user role level your application supports: unauthenticated, regular user, power user, admin, and any custom roles. Don't use production accounts. Label them clearly (e.g., pentest-user@company.com, pentest-admin@company.com).

Documentation. For grey/white box: application architecture diagrams, API documentation (Swagger/OpenAPI specs), network diagrams, cloud architecture. For black box: the provider discovers these independently.

Environment access. VPN credentials for internal testing. Cloud console access or IAM credentials for cloud testing. WiFi credentials for wireless testing.

Authorisation. Sign the rules of engagement document. This is the legal authorisation for the provider to test your systems. Cloud providers (AWS, Azure, GCP) may require notification before testing.

Internal notification. Inform your SOC, IT operations, and relevant teams that testing will occur. Provide tester IP addresses so the SOC can distinguish pentest traffic from real attacks. Decide whether the SOC should respond to pentest activity (testing detection and response) or ignore it (allowing testers maximum coverage).

Deliverable from This Phase

A signed scope document defining targets, approach, schedule, rules of engagement, contacts, and compliance requirements. Both parties agree on exactly what will happen.

Phase 2: Reconnaissance and Discovery (Days 1 to 2 of Testing)

What Happens

Testers begin by mapping your attack surface: discovering everything they can about your systems before attempting exploitation.

For external testing: DNS enumeration (discovering subdomains), port scanning (identifying open services), technology fingerprinting (identifying software versions), and OSINT gathering (publicly available information about your infrastructure).

For web application testing: Crawling every page, mapping every form and input field, identifying every API endpoint, and understanding the application's functionality and user flows.

For internal testing: Network scanning from the assumed breach position, identifying Active Directory structure, enumerating services, and mapping the internal network topology.

What You Might Notice

Increased traffic. Scanning generates traffic that may appear in your monitoring. This is expected. If your SOC flags it, the pre-engagement notification should already explain it.

Potential service impact. Aggressive scanning can occasionally affect sensitive services. Quality providers throttle scanning to avoid disruption. If you have fragile systems, communicate this during scoping.

What You Need to Do

Be available. Testers may have questions during reconnaissance: "Is this subdomain yours?" "Is this third-party service in scope?" "This application requires a specific client certificate; can you provide it?" Responsive clients enable faster, more thorough testing.

Don't fix things mid-test. If you notice the testers have found a vulnerability, resist the urge to fix it immediately. Let the testers complete their assessment so you receive a comprehensive picture. Fixing mid-test can hide related vulnerabilities the testers would have found through the original weakness.

Phase 3: Testing and Exploitation (The Core Engagement)

What Happens

This is the heart of the engagement. Testers systematically attempt to exploit vulnerabilities across your in-scope systems.

Web application testing covers the OWASP Top 10 and beyond: injection vulnerabilities, authentication bypass, broken access control (IDOR), business logic flaws, SSRF, CSRF, session management, and file upload vulnerabilities.

API testing covers BOLA/BFLA (the top API risks), injection, authentication flaws, rate limiting bypass, and data exposure. See our API security best practices.

Network testing covers service exploitation, privilege escalation, lateral movement, Active Directory attacks, and credential harvesting.

Cloud testing covers IAM misconfigurations, storage bucket exposure, cross-account access, and cloud-native service exploitation.

What You Might Experience

Critical finding alerts. Quality providers escalate critical findings immediately, not at the end of the engagement. If testers discover unauthenticated access to customer data or a path to complete system compromise, expect a call or email within hours. You'll need to decide whether to remediate immediately (stopping the bleeding) or let testers continue exploring the impact (understanding the full scope). Ask your provider about their escalation policy during scoping.

Questions from testers. "This account is locked out, can you reset it?" "We found what appears to be a test environment, is this in scope?" "We can see another tenant's data through this endpoint, please confirm this isn't expected behaviour." Quick responses keep testing productive.

Periods of quiet. Don't interpret silence as inactivity. Testers may spend hours methodically testing hundreds of parameters for injection, or days working through Active Directory attack paths. Testing is methodical and often invisible to the client during execution.

Typical Testing Timeline

Engagement TypeTypical DurationSingle web application5 to 10 business daysAPI (50 to 100 endpoints)5 to 10 business daysExternal network3 to 5 business daysInternal network5 to 10 business daysCloud infrastructure5 to 10 business daysMobile application5 to 10 business daysComprehensive (multi-scope)10 to 20 business daysRed team15 to 30 business days

For how often these engagements should occur, see our frequency guide.

Phase 4: Analysis and Reporting (Final Week)

What Happens

After testing completes, the testers analyse their findings, validate exploitation evidence, assign severity ratings, and produce the engagement report. This is where raw testing notes become the actionable deliverable your team will work from.

What the Report Contains

Executive summary. A 1 to 2 page overview written for non-technical leadership. Overall risk rating (Critical, High, Medium, Low). Key findings summarised in business language. Strategic recommendations.

Scope confirmation. What was tested, when, from where, using which methodology. This section confirms the engagement covered what was agreed during scoping.

Findings. Each vulnerability documented with:

Description: what the vulnerability is and why it matters. Severity: Critical, High, Medium, or Low (typically using CVSS scoring). Evidence: screenshots, request/response pairs, and proof-of-concept demonstrating the vulnerability is real. Affected systems: which specific URLs, IPs, or endpoints are vulnerable. Business impact: what an attacker could achieve through this vulnerability. Remediation: specific steps to fix the vulnerability, tailored to your technology stack. References: CWE, OWASP mapping, and industry guidance.

Methodology. Reference to testing standards used (PTES, NIST SP 800-115, OWASP Testing Guide, CREST methodology). Tester qualifications. Tools used.

For report quality expectations, see our penetration testing reports guide. For evaluating report quality across providers, see our testing quality guide.

The Debrief Call

Quality providers conduct a debrief call walking through the findings with your technical team and leadership. This is the most valuable hour of the entire engagement.

What happens during the debrief:

Testers explain each finding, demonstrate exploitation, and answer questions about impact and remediation. Your team asks "how did you find this?" and "what's the best way to fix it?" Leadership asks "what are the three things we should fix first?" Prioritisation discussion: which findings create the most risk and which are the quickest wins.

How to prepare for the debrief: Have your development lead, security team, and a management representative present. Review the report before the call so questions are specific. Come prepared with questions about your remediation approach.

Phase 5: Remediation Support (30 to 90 Days Post-Report)

What Happens

After receiving the report, your development and infrastructure teams fix the identified vulnerabilities. Quality providers include remediation support as part of the engagement.

What Remediation Support Includes

Technical guidance. When your team has questions about how to implement a fix, the testing provider should be available to advise. "The report says to implement output encoding; should we use this specific library?" "We're not sure how to fix this IAM misconfiguration without breaking our deployment pipeline."

Priority guidance. If your team can't fix everything immediately, the provider helps prioritise: which findings create the most risk, which have the quickest fixes, and which can wait.

Architecture advice. Some findings require architectural changes rather than code fixes. The provider can advise on the security architecture that prevents the vulnerability class from recurring.

How to Maximise Remediation Value

Assign owners immediately. Every finding should have a named person responsible for remediation within 48 hours of receiving the report.

Set SLAs by severity. Critical: 14 days. High: 30 days. Medium: 90 days. Low: next development cycle. Track adherence to these SLAs. See our security remediation maturity guide and security SLA framework.

Fix root causes, not just instances. If the report shows SQL injection in three endpoints, don't just fix those three. Implement parameterised queries across the entire application. Fix the pattern, not the occurrence. See our secure SDLC framework for building security into development.

Track in your existing tools. Create tickets in your issue tracker (Jira, Linear, etc.) for every finding. Track remediation alongside feature development so it doesn't get deprioritised.

Phase 6: Retesting (After Remediation)

What Happens

After your team remediates findings, the testing provider retests to verify fixes work. Retesting confirms that the vulnerability is resolved, not just that code was changed.

Why Retesting Matters

Fixes sometimes don't work. A developer may implement an input filter that's bypassable. An IAM policy change may not propagate to all resources. A WAF rule may block the specific payload from the report but not variations.

Compliance requires proof. Auditors reviewing pentest evidence want to see both the finding and the retesting confirmation that it's resolved. Without retesting, your compliance evidence is incomplete. See our compliance guide.

Fixes can introduce new issues. Code changes to fix one vulnerability occasionally create another. Retesting catches this before the new vulnerability reaches the next annual test cycle.

What Retesting Covers

The tester re-executes the specific exploitation technique that confirmed the original vulnerability. If the fix works, the test fails (the vulnerability is resolved). If the fix doesn't work, the tester documents why and provides additional remediation guidance.

What You Receive

A retesting report confirming the status of each remediated finding: Resolved, Partially Resolved (still exploitable through a different path), or Unresolved (fix didn't address the vulnerability). Quality providers include retesting at no additional cost.

What Makes a Good Engagement Experience

From the Provider Side

Communication. Regular status updates during testing. Immediate escalation of critical findings. Responsive to client questions. Clear, jargon-free reporting.

Manual testing depth. Expert-led testing that discovers business logic flaws, access control failures, and vulnerability chains that automated tools miss.

Zero false positives. Every finding validated through exploitation. No scanner output dressed up as a pentest report. See our evaluating quality guide.

Actionable remediation. Fix guidance specific to your stack, not generic "apply vendor patch." Code examples where helpful. Architecture recommendations for systemic issues.

From the Client Side

Preparation. Test accounts ready. Documentation available. Contacts responsive. Authorisation signed. SOC notified.

Availability. Answer tester questions within hours, not days. Quick responses keep the engagement productive.

Engagement. Attend the debrief. Ask questions. Challenge findings you don't understand. The debrief is where the most value transfers.

Follow-through. Assign remediation owners. Track fixes. Complete retesting. The report is only valuable if findings are fixed.

Engagement Models: One-Time vs Continuous

Annual Engagement

The traditional model. One comprehensive pentest per year covering agreed scope. Satisfies minimum compliance requirements. Leaves 11 months between tests where new vulnerabilities go undiscovered. See our annual vs continuous comparison.

Continuous Penetration Testing

Ongoing testing triggered by code deployments, infrastructure changes, and new feature releases. Testing stays current with your application's change velocity. Best for organisations deploying frequently.

PTaaS (Penetration Testing as a Service)

Combines scheduled testing with on-demand access to testers. Your team can request ad-hoc testing of new features, changed infrastructure, or specific areas of concern between scheduled engagements. See our PTaaS guide.

Red Team Engagements

Different from penetration testing. Red teams simulate realistic adversary campaigns testing your entire security programme: people, process, and technology. The SOC isn't informed. Social engineering may be in scope. The objective is testing organisational resilience, not just finding technical vulnerabilities. See our red teaming vs pentesting comparison.

Preparing Your Team

For Security Teams

Understand the scope so you can support the testers. Be ready to provide access, answer questions, and make decisions about critical findings. Plan remediation capacity for the 30 to 90 days after the report arrives.

For Development Teams

Don't deploy code changes to in-scope systems during testing (unless coordinated with the testers). Be prepared to receive findings and begin remediation. Understand that pentest findings are opportunities to improve, not criticisms.

For Leadership

Expect a request to participate in the debrief (or review the executive summary). Be ready to approve remediation resources for critical findings. Understand that finding vulnerabilities through testing is dramatically better and cheaper than finding them through a breach. See our penetration testing ROI guide.

Client-Side Checklist

Before Testing Starts

• Scope document signed by both parties
• Test accounts created at every role level
• API documentation provided (grey/white box)
• VPN/access credentials provisioned (internal testing)
• Cloud provider notification submitted (if required)
• SOC and IT operations team notified with tester IPs
• Emergency contacts exchanged
• Testing window confirmed on both calendars
• Out-of-scope exclusions explicitly documented

During Testing

• Technical contact available to answer tester questions
• Critical finding escalation response process ready
• No uncoordinated code deployments to in-scope systems
• SOC treating pentest traffic per agreed approach

After Testing

• Debrief attended by security, development, and management
• Findings assigned to remediation owners within 48 hours
• Remediation SLAs set by severity
• Tickets created in issue tracker for every finding
• Remediation progress tracked weekly
• Root cause analysis completed for recurring finding patterns
• Retesting scheduled after remediation complete

Ongoing

• Next engagement scheduled per testing frequency
• Year-over-year findings compared for posture improvement
• Lessons learned incorporated into secure development
• Provider feedback provided (what worked, what could improve)

Choosing the Right Provider

Selecting the right provider determines the value you receive. See our how to choose a penetration testing company guide and penetration testing companies evaluation guide for detailed selection criteria.

Key factors: CREST certification (quality assurance). Zero false positive commitment. Remediation support included. Retesting included. Compliance mapping capability. Communication quality during engagement.

For understanding penetration testing costs, see our cost guide.

How AppSecure Engagements Work

AppSecure follows every phase described in this guide with structured communication, expert manual testing, and comprehensive deliverables.

Scoping Support. We help you define the right scope based on your risk profile, compliance requirements, and budget. No underscoping that misses critical systems. No overscoping that dilutes testing depth.

Expert Testing. Web application, API, cloud, network, mobile, and AI penetration testing. Application security assessment and offensive security testing for comprehensive coverage.

Zero False Positives. Every finding validated through exploitation with evidence.

3-Week Delivery. Report delivered within three weeks. Debrief scheduled promptly. 90-Day Remediation Support. Your team has access to testers for guidance throughout remediation. Complimentary Retesting. Verification that fixes work at no additional cost.

Continuous Testing and PTaaS for ongoing security validation beyond annual engagements.

Contact AppSecure:

• Schedule Your Engagement
• What Is Penetration Testing?
• Penetration Testing Cost Guide

Frequently Asked Questions

1. How long does a penetration testing engagement take?

A single-scope engagement (one web application, one network assessment) typically takes 5 to 10 business days of active testing plus 1 to 2 weeks for scoping and 1 week for reporting. Comprehensive multi-scope engagements take 10 to 20 business days. Red team engagements take 15 to 30 business days. End-to-end from scoping to report delivery: typically 3 to 5 weeks for standard engagements. Factor in 30 to 90 additional days for remediation and retesting.

2. What do I need to prepare before testing starts?

Create dedicated test accounts at every user role level. Provide API documentation and architecture diagrams (for grey/white box testing). Provision VPN access for internal testing. Submit cloud provider notifications if required. Notify your SOC and IT operations team with tester IP addresses. Sign the scope and rules of engagement document. Designate technical and management contacts who can respond to tester questions and critical finding escalations.

3. Will penetration testing disrupt our production systems?

Professional testers are trained to avoid disruption. Scanning is throttled to prevent service impact. Exploitation is controlled to demonstrate vulnerabilities without causing damage. Denial-of-service testing is typically excluded from scope unless specifically requested. However, fragile or legacy systems may be sensitive to testing traffic. Communicate any system fragility during scoping so testers can adjust their approach.

4. What should I do if testers find a critical vulnerability mid-engagement?

Quality providers escalate critical findings immediately rather than waiting for the final report. When notified of a critical finding, assess the immediate risk. If the vulnerability is actively exposable to attackers (unauthenticated access to customer data, for example), consider implementing a quick fix or compensating control immediately. Discuss with the testers whether fixing it will affect their ability to assess related vulnerabilities.

5. What does a penetration testing report look like?

Reports include an executive summary (overall risk rating and key findings for leadership), scope confirmation, detailed findings (each with description, severity, exploitation evidence, business impact, and remediation steps), methodology documentation, and tester qualifications. Quality reports include compliance mapping to applicable frameworks and provide remediation guidance specific to your technology stack, not generic advice.

6. How is penetration testing different from vulnerability scanning?

Vulnerability scanning runs automated tools that check for known weaknesses. Penetration testing uses expert human testers who exploit vulnerabilities, test business logic, validate access controls, and chain findings into real attack paths. Scanners produce potential findings (with false positives). Pentests produce validated findings (zero false positives). Compliance frameworks that require penetration testing expect manual expert-led testing, not just automated scanning.

7. Should our SOC be informed about the penetration test?

Typically yes, but with nuance. Inform the SOC so they don't treat pentest traffic as a real attack and waste incident response resources. Provide tester IPs for whitelisting in monitoring (optional). Some organisations choose not to inform the SOC to test whether detection capabilities identify the pentest activity. Discuss the approach during scoping. Red team engagements specifically keep the SOC uninformed.

8. What happens after we receive the report?

Attend the debrief call where testers walk through findings. Assign each finding to a remediation owner within 48 hours. Set remediation SLAs by severity. Create tickets in your issue tracker. Track remediation weekly. Use the provider's remediation support when your team has implementation questions. After fixes are complete, schedule retesting to verify vulnerabilities are resolved. Compare findings to previous engagements to measure posture improvement.

9. Is retesting included in penetration testing engagements?

It should be. Quality providers include complimentary retesting as part of the engagement. Retesting verifies that remediated vulnerabilities are actually fixed. Without retesting, you have no confirmation that fixes work and your compliance evidence is incomplete. If a provider charges separately for retesting, consider that when evaluating total engagement cost.

10. How often should we conduct penetration testing?

Annual testing is the minimum for compliance (PCI DSS, SOC 2, ISO 27001). Semi-annual for organisations with significant code changes. After major releases, architecture changes, or cloud migrations. Continuous testing through PTaaS for organisations deploying code frequently. Testing frequency should match your change velocity because each deployment potentially introduces new vulnerabilities.