Penetration Testing Checklist: What to Verify Before, During, and After a Pentest

Your penetration test starts Monday. Your provider is ready. Are you?

Most organisations focus on selecting the right pentest provider and negotiating scope. Then the engagement starts and things stall. Credentials weren't ready. Firewall rules blocked the testing team. Nobody told the SOC, so they spent Tuesday investigating "attacks" that were actually the pentest. The application owner was on vacation and couldn't answer questions about user roles. Two in-scope systems were down for maintenance that nobody mentioned during scoping.

After the engagement, things stall again. The report arrives and sits in someone's inbox for two weeks. Findings get assigned but nobody tracks remediation. Critical vulnerabilities stay open for months. Retesting never happens. The compliance audit six months later asks for evidence of remediation, and nobody can produce it.

The penetration test itself might be excellent. But the value your organisation extracts from it depends entirely on what happens before and after the testers do their work.

This penetration testing checklist covers everything your team needs to do at each phase of the engagement: preparation before the pentest, monitoring during testing, and follow-through after the report arrives. It's the organisational counterpart to understanding how penetration testing methodology works and the VAPT process. Those explain what testers do. This checklist explains what you do.

Phase 1: Before the Pentest

Scoping and Objective Setting

Poor scoping is the single most common reason pentests fail to deliver expected value. Scope too narrowly and you miss critical systems. Scope too broadly and testing depth suffers. Scope without compliance input and the report doesn't satisfy auditors.

Scoping checklist:

• Primary pentest objectives defined (compliance, risk assessment, pre-launch, post-incident)
• Testing type determined: external, internal, or both
• Testing approach selected: black box, white box, or grey box
• In-scope systems explicitly listed:
  • Web applications with URLs and environments (production, staging)
  • APIs with endpoint documentation
  • Mobile applications (iOS, Android) with app store links or build access
  • Cloud infrastructure (AWS, Azure, GCP)
  • Internal network segments and IP ranges
  • External IP ranges and domains
• Out-of-scope systems explicitly documented with justification
• Compliance frameworks the report must address identified (PCI DSS, SOC 2, ISO 27001, HIPAA)
• Previous pentest reports gathered for year-over-year comparison
• Known issues from previous assessments documented
• Rules of engagement drafted:
  • Testing hours defined
  • Restricted techniques identified (DoS, account lockout, production data modification)
  • Critical finding notification requirements specified
  • Escalation contacts established
• Scope document reviewed and signed by both parties

For comprehensive compliance alignment, see our penetration testing compliance guide.

Technical Preparation

Ensure the testing team can actually access and test everything in scope without delays that consume engagement hours.

Access and connectivity checklist:

• Testing team source IP addresses collected for whitelisting
• VPN access provisioned if remote internal testing is in scope
• Firewall rules updated to allow testing traffic from source IPs
• IDS/IPS whitelisting configured for testing source IPs (or detection tuning completed)
• WAF rules adjusted for testing IPs (allow through without blocking legitimate test traffic)
• Rate limiting exceptions configured for testing IPs where needed
• Network connectivity verified between testing team and all in-scope systems

Credential and account preparation (for grey box and white box testing):

• Test user accounts created at each role level (standard user, admin, privileged roles)
• Credentials securely communicated to testing team (not via unencrypted email)
• Test accounts verified as functional (login tested before engagement starts)
• Test accounts provisioned with appropriate permissions matching real users at each role
• MFA tokens or bypass configured for test accounts if MFA is deployed
• Service accounts provided for authenticated infrastructure scanning
• Cloud platform read access provisioned (AWS IAM role, Azure reader, GCP viewer)
• API keys or tokens generated for API testing if required

Environment preparation:

• Target environments confirmed as available for the testing window
• Production vs staging decision documented (testing production provides most realistic results)
• Backup verification completed before testing begins
• Change freeze communicated for the testing period (avoid confusing results with concurrent changes)
• Database snapshots taken if testing involves data manipulation
• Rollback procedures verified in case testing causes unexpected impact

Documentation for testers:

• Architecture diagrams provided (network, application, cloud)
• API documentation shared (Swagger/OpenAPI specs, Postman collections)
• User role documentation explaining permission levels
• Application business logic documentation (how key workflows function)
• Data flow diagrams showing sensitive data paths
• Cloud architecture documentation (VPC layout, IAM structure)
• Previous security assessment reports shared for context

Internal Team Preparation

Ensure your organisation's teams are ready for the engagement.

Stakeholder notification checklist:

• SOC/security monitoring team informed of testing timeline and source IPs
  • Decision made: Informed testing (SOC knows) or blind testing (SOC doesn't know, tests detection)
• Network operations team informed of expected scanning and exploitation traffic
• Application development teams informed if their applications are in scope
• Cloud operations team informed if cloud infrastructure is in scope
• IT helpdesk informed to expect potential access issues during testing
• Management informed of timeline and expected deliverable dates
• Legal team has reviewed and approved rules of engagement

Internal response readiness:

• Primary internal contact designated for tester questions during engagement
• Backup contact designated in case primary is unavailable
• Emergency contact available for urgent issues (system impact, critical findings)
• Internal contacts have authority to make scoping decisions if questions arise
• Response SLA established: how quickly internal team responds to tester requests

Pre-Engagement Verification Call

Before testing begins, conduct a verification call between your team and the testing provider.

Verification call checklist:

• Scope reviewed and confirmed by both parties
• Rules of engagement reviewed and confirmed
• Testing timeline and milestones confirmed
• Access and connectivity verified (test VPN, confirm credentials work)
• Communication channels established (Slack, Teams, email, phone)
• Critical finding notification process agreed
• Report delivery date and format confirmed
• Retesting expectations discussed
• Any last-minute scope changes documented

Phase 2: During the Pentest

Day 1 Monitoring

The first day of testing is when access issues surface.

Day 1 checklist:

• Confirm testing team has successfully connected to the environment
• Verify credentials are working for all provided accounts
• Check that scanning traffic isn't being blocked by security controls
• Monitor for unexpected system impact from initial scanning
• Confirm communication channel is active (testers can reach internal contact)
• Verify SOC team is handling test traffic appropriately (informed or blind)

Ongoing Monitoring

Throughout the engagement, maintain active support.

Active monitoring checklist:

• Respond to tester questions within established SLA (ideally same day)
• Monitor system availability for any testing-related impact
• Track engagement progress against timeline
• Review critical findings as they're communicated (don't wait for final report)
• Begin remediation planning for critical findings surfaced during testing
• Document any scope adjustments made during engagement
• Note any systems that were unavailable during testing (may need retesting)
• Keep internal stakeholders informed of engagement progress

Quality Assurance

Verify the pentest is covering what you need.

Quality verification checklist:

• All in-scope systems are being tested (no accidental exclusions)
• Testing approach matches what was scoped (manual testing occurring, not just scanning)
• Grey box or white box testing is utilising provided credentials (authenticated testing producing results)
• Compliance-specific testing requirements are being addressed
• Business logic testing is occurring (not just automated vulnerability scanning)
• If detection testing is in scope, verify testers are simulating realistic attack patterns

Critical Finding Response

When testers communicate critical findings during the engagement, act immediately.

Critical finding response checklist:

• Critical finding acknowledged to testing team within hours
• Finding communicated to relevant internal team (development, operations, security)
• Impact assessment initiated (what data or systems does this affect?)
• Remediation priority determined
• Compensating control implemented if immediate fix isn't possible
• Decision documented: remediate immediately or address post-engagement

Phase 3: After the Pentest

Report Receipt and Initial Review

The report is delivered. What you do in the first 48 hours sets the tone for the entire remediation cycle.

Initial review checklist (first 48 hours):

• Report received and acknowledged to provider
• Executive summary read by security leadership
• Critical and high-severity findings reviewed immediately
• Finding count compared against expectations (significantly more or fewer than expected warrants discussion with provider)
• All in-scope systems represented in findings (nothing was missed)
• Report quality assessed:
  • Exploitation evidence present for every finding (screenshots, request/response)
  • Severity ratings include business context (not just CVSS)
  • Remediation guidance is specific to your technology stack
  • Compliance mapping present for identified frameworks
  • Attack chains documented showing compound risk
• Questions or concerns noted for debrief session

For report quality standards, see our penetration testing reports guide. Learn how to evaluate penetration testing quality.

Findings Debrief

Schedule and conduct a walkthrough session with the testing team.

Debrief checklist:

• Debrief session scheduled within one week of report delivery
• Security team, development leads, and operations leads invited
• Questions about specific findings prepared in advance
• Testers walk through critical and high findings with live demonstration or detailed explanation
• Remediation approaches discussed for complex findings
• Priority disagreements resolved (severity ratings vs business impact)
• Timeline for remediation agreed
• Retesting logistics discussed
• Debrief notes documented and distributed to all attendees

Remediation Planning

Convert findings into a tracked remediation programme.

Remediation planning checklist:

• Every finding assigned to a responsible team or individual
• Remediation timelines established by severity:
  • Critical: 48 to 72 hours (or compensating control immediately)
  • High: 1 to 2 weeks
  • Medium: 30 days
  • Low: 90 days (or risk acceptance with documentation)
• Remediation tickets created in your project management system (Jira, ServiceNow, Azure DevOps)
• Dependencies identified:
  • Findings requiring code changes (assigned to development teams)
  • Findings requiring infrastructure changes (assigned to operations)
  • Findings requiring configuration changes (assigned to relevant admin)
  • Findings requiring architectural changes (escalated to security architecture)
• Quick wins identified (fixes deployable immediately without change management)
• Resource requirements assessed (does any remediation require budget, tooling, or expertise?)
• Compensating controls documented for findings requiring extended remediation timelines
• Risk acceptance decisions documented with management sign-off for findings the organisation chooses not to remediate

Remediation Tracking

Track remediation to completion. This is where most organisations fail.

Remediation tracking checklist:

• Weekly remediation status meetings established
• Remediation dashboard or tracker created showing:
  • Total findings by severity
  • Findings resolved vs outstanding
  • Days open for each unresolved finding
  • SLA compliance (within/exceeded timeline)
• Blockers escalated to management when remediation stalls
• Each fix verified by the implementing team before marking as resolved
• Regression testing conducted (does the fix break anything?)
• Fix validation includes security verification (does the fix actually address the root cause?)
• Progress reported to stakeholders at agreed intervals

Retesting

Verify remediation actually resolved the vulnerabilities.

Retesting checklist:

• Retesting requested from pentest provider after all critical and high findings remediated
• Retesting scope includes all remediated critical and high findings
• Medium findings included in retest scope if resources allow
• Retesting scheduled with adequate notice to provider
• Environment stable during retest (no concurrent changes)
• Retest report received confirming status:
  • Resolved: vulnerability no longer exploitable
  • Partially resolved: risk reduced but not eliminated
  • Unresolved: vulnerability remains exploitable
  • Regressed: fix introduced new issues
• Unresolved findings receive updated remediation timeline or risk acceptance
• Retesting evidence archived for compliance purposes

Compliance Documentation

Package pentest results for audit and compliance requirements.

Compliance documentation checklist:

• Pentest report archived in compliance evidence repository
• Remediation evidence documented for each resolved finding
• Retesting report archived alongside original report
• Risk acceptance documented with management sign-off for unresolved findings
• Assessment timing documented (satisfies annual/quarterly requirement)
• Report format meets auditor expectations:
  • PCI DSS: Requirement 11.3 evidence package
  • SOC 2: Trust Services Criteria mapping evidence
  • ISO 27001: Annex A control mapping evidence
  • HIPAA: Risk assessment evidence
• Next pentest scheduled within required compliance window
• Compliance calendar updated with next assessment dates

Lessons Learned and Continuous Improvement

Use pentest results to improve security beyond individual findings.

Continuous improvement checklist:

• Root cause analysis conducted for recurring finding categories
• Development training updated if code-level vulnerabilities were prevalent
• Secure coding standards updated to address discovered patterns
• Configuration baselines updated to prevent infrastructure findings
• Security champion programme updated with new patterns for code review
• Secure SDLC processes reviewed (did findings indicate process gaps?)
• Assessment scope reviewed for next cycle (systems to add, areas to deepen)
• Provider feedback documented (what worked well, what could improve)
• Year-over-year finding trends analysed (are things improving?)
• Security investment decisions informed by pentest results (where to invest next)

Pentest Readiness Quick-Reference

One Month Before

• Scope finalised and documented
• Compliance requirements identified
• Provider engagement confirmed with timeline
• Previous reports gathered for comparison

Two Weeks Before

• Technical access prepared (VPN, credentials, whitelisting)
• Architecture documentation compiled
• Internal teams notified
• Rules of engagement finalised

One Week Before

• Pre-engagement verification call completed
• All access tested and confirmed working
• Emergency contacts distributed
• SOC notification or blind testing decision implemented
• Backup verification completed

Day Before

• Final confirmation with testing team
• Environment availability verified
• Internal contact available and responsive
• Communication channels tested

Day of Kickoff

• Testing team confirms connectivity and access
• Credentials verified as functional
• Monitoring active for system impact
• Communication channel live

Common Mistakes That Waste Pentest Value

Mistake 1: Not Preparing Credentials Before Kickoff

Testing teams spending the first two days troubleshooting credential issues, VPN problems, or firewall blocks is the most common engagement waste. Two days of a two-week engagement consumed by access issues means 20 percent less testing depth.

Prevention: Complete the technical preparation checklist at least one week before testing starts. Verify access works by having your internal team test from the same starting point the pentest team will use.

Mistake 2: Not Responding to Tester Questions

Testers discover applications, configurations, or behaviours they need context on. If nobody responds for two days, testing stalls or proceeds without context, potentially missing business logic flaws that require understanding intended behaviour.

Prevention: Designate a responsive internal contact with authority to answer questions. Establish a same-day response SLA.

Mistake 3: Treating the Report as the Finish Line

The report arriving doesn't mean the pentest is complete. The pentest is complete when critical findings are remediated and retested. Reports without remediation follow-through produce security theatre: documented awareness of vulnerabilities without actual security improvement.

Prevention: Complete the entire Phase 3 checklist. Track remediation to retesting completion.

Mistake 4: Not Scheduling Retesting

Many organisations remediate findings but never validate that fixes work. Without retesting, you're assuming your remediation is effective without evidence. Some "fixes" address the specific test case but not the root cause. Others introduce new issues.

Prevention: Schedule retesting as part of the initial engagement. Include retesting in your budget and timeline planning.

Mistake 5: Losing Findings in Email

The report arrives as a PDF attachment. Someone forwards it. It ends up in three people's inboxes. Six months later, nobody can find the retesting evidence. Compliance audit asks for documentation, and the team spends days reconstructing the remediation timeline.

Prevention: Archive all pentest documentation (reports, remediation evidence, retesting results, risk acceptances) in a centralised compliance repository from day one.

Mistake 6: Not Comparing Year-Over-Year

Each pentest in isolation tells you what's wrong now. Year-over-year comparison tells you whether your security programme is actually working. Are finding counts decreasing? Are severity levels trending downward? Are the same vulnerability categories recurring? Trend analysis is where pentest investment produces strategic programme improvement.

Prevention: Maintain a tracking spreadsheet or dashboard comparing findings, severity distribution, remediation timelines, and retest results across all assessments.

Penetration Testing Checklist by Testing Type

External Pentest Preparation

• All public IP ranges in scope documented
• All external domains and subdomains listed
• External DNS records reviewed (nothing accidentally excluded)
• Cloud-hosted external services included
• Third-party hosted services in scope identified

See our external penetration testing guide.

Internal Pentest Preparation

• Domain-joined workstation or VPN access prepared for testers
• Standard domain user credentials created
• Internal network segments in scope documented
• Active Directory domain structure documented
• Decision on SOC informed vs blind testing confirmed

See our internal penetration testing guide.

Web Application Pentest Preparation

• Application URLs confirmed (production or staging)
• User accounts at each role level created
• Application functionality documentation provided
• Test data available (avoiding real customer data where possible)
• Payment processing test environment configured if payment testing in scope

API Pentest Preparation

• API documentation shared (Swagger/OpenAPI, Postman collections)
• API authentication credentials or tokens provided
• Rate limiting exceptions configured for testing
• API environments confirmed (production or staging)

Cloud Pentest Preparation

• Cloud platform read access provisioned
• Subscription/account IDs documented
• Cloud provider's pentest rules of engagement reviewed (AWS, Azure, GCP)
• Multi-account or multi-subscription scope confirmed

Mobile App Pentest Preparation

• Test devices available or app builds provided
• Test accounts with various role levels
• Backend API access confirmed
• Test environment configured (not testing against production user data)

How AppSecure Makes the Checklist Easier

AppSecure's engagement process addresses every phase of this checklist, reducing the preparation burden on your team.

Structured Scoping

AppSecure conducts thorough scoping calls understanding your environment, objectives, and compliance requirements before testing begins. Scoping produces a clear scope document covering everything in the preparation checklist, ensuring nothing is missed.

Pre-Engagement Verification

Before testing starts, AppSecure verifies all access, credentials, and connectivity work correctly. Access issues are resolved before the testing clock starts, ensuring engagement hours produce testing depth rather than troubleshooting.

Real-Time Critical Finding Notification

Critical vulnerabilities are communicated within hours of discovery, not saved for the final report. Your team begins remediation planning while testing continues, accelerating the finding-to-fix timeline.

Zero False Positives

Every finding is manually validated through exploitation. Your remediation checklist contains only genuine, exploitable vulnerabilities. Zero wasted cycles validating whether findings are real.

Compliance-Mapped Reports

Reports map findings to PCI DSS, SOC 2, ISO 27001, HIPAA, and other frameworks. Your compliance documentation checklist items are handled within the standard deliverable.

90-Day Remediation Support

Post-delivery support includes findings debrief, developer Q&A, fix review, and complimentary retesting. The entire Phase 3 after-pentest checklist is supported by AppSecure throughout the 90-day window.

3-Week Delivery

Standard engagements complete within three weeks. Continuous penetration testing and pentesting as a service provide ongoing testing beyond annual engagements. Application security assessment and offensive security testing provide comprehensive coverage.

Ready for a penetration test where every phase is handled professionally?

Contact AppSecure:

• Schedule Penetration Testing
• Application Security Assessment
• Penetration Testing Methodology

Frequently Asked Questions

1. What should I prepare before a penetration test?

Prepare a complete inventory of in-scope systems (IPs, domains, applications, cloud resources). Create test accounts at each user role level for authenticated testing. Configure firewall and IDS/IPS whitelisting for the testing team's source IPs. Gather architecture documentation and API specs. Identify compliance frameworks the report must address. Designate an internal contact for tester questions. Inform your SOC and IT teams. Verify backups. Conduct a pre-engagement verification call confirming all access works before testing begins.

2. How long before a pentest should preparation start?

Start preparation one month before the engagement. Finalise scope and compliance requirements first. Two weeks before, complete technical preparation (credentials, whitelisting, documentation). One week before, conduct the pre-engagement verification call and confirm everything works. Day before, verify environment availability and contact readiness. Adequate preparation prevents the most common pentest waste: engagement hours consumed by access issues instead of testing.

3. What should I do during a penetration test?

Monitor for unexpected system impact. Respond promptly to tester questions (same-day SLA recommended). Review critical findings as they're communicated during testing. Begin remediation planning for critical issues immediately. Track engagement progress against timeline. Verify all in-scope systems are being assessed. Document any scope changes or systems unavailable during testing.

4. What should I do immediately after receiving a pentest report?

Within 48 hours: read the executive summary, review all critical and high-severity findings, verify report quality (exploitation evidence, compliance mapping, specific remediation guidance), note questions for the debrief session. Within one week: conduct the findings debrief with the testing team. Assign every finding to a responsible team. Create remediation tickets with severity-based timelines. Identify quick wins fixable immediately.

5. How should I track penetration test remediation?

Create tickets in your project management system for every finding. Establish severity-based remediation timelines (critical: 48-72 hours, high: 1-2 weeks, medium: 30 days, low: 90 days). Hold weekly remediation status meetings. Maintain a dashboard tracking findings resolved vs outstanding, days open, and SLA compliance. Escalate blockers to management. Verify each fix addresses root cause before marking as resolved. Request retesting after remediation completion.

6. Is retesting included in penetration testing engagements?

Quality pentest providers include retesting as part of the engagement. Retesting validates that remediated vulnerabilities are genuinely resolved and that fixes haven't introduced regression issues. Penetration testing without retesting leaves remediation unvalidated. Confirm retesting inclusion, scope (all findings or selected findings), and timing when evaluating providers. AppSecure includes complimentary retesting within 90-day post-delivery support.

7. What compliance documentation should I maintain from a pentest?

Archive the pentest report, remediation evidence for each resolved finding, retesting report confirming resolution, risk acceptance documentation with management sign-off for unresolved findings, and assessment timing records satisfying frequency requirements. Format documentation for your applicable frameworks: PCI DSS Requirement 11.3 evidence, SOC 2 Trust Services Criteria mapping, ISO 27001 Annex A control mapping, or HIPAA risk assessment evidence. Store everything in a centralised compliance repository.

8. How do I compare penetration test results year over year?

Track total finding count by severity across assessments. Monitor whether critical and high-severity findings decrease over time. Identify recurring vulnerability categories indicating systemic issues. Compare remediation timelines (are you fixing things faster?). Track retest pass rates (are fixes more effective?). Note new finding categories that may indicate expanding attack surface or emerging threats. Year-over-year trend analysis demonstrates whether your security programme is producing measurable improvement.

9. What is the most common mistake organisations make with pentests?

The most common mistake is treating report delivery as the engagement endpoint. The pentest delivers maximum value only when findings are remediated and retested. Reports that sit unactioned in shared drives produce zero security improvement regardless of testing quality. The second most common mistake is inadequate preparation: credentials not ready, access blocked, contacts unavailable, causing engagement hours to be consumed by troubleshooting instead of testing.

10. How often should penetration testing be conducted?

Annual penetration testing satisfies most compliance framework minimums (PCI DSS, SOC 2, ISO 27001). Critical systems processing sensitive data warrant semi-annual or quarterly testing. Organisations with high deployment velocity benefit from continuous testing through PTaaS. Additional testing should follow major application releases, infrastructure changes, third-party integrations, and security incidents. Testing frequency should be proportionate to risk, deployment velocity, and compliance requirements.