How to Prepare for a Penetration Test: A Practical Checklist for Your Team

Start with a preparation owner

Before a penetration test begins, someone on your team needs to connect the people who own the systems, approve the work, support access, and act on the findings. That person does not need every technical answer. They need a way to obtain answers and resolve open decisions before the testing window.

The checklist below is a starting point for that coordination. Tailor it with your testing provider to the agreed engagement. It does not define a fixed package, guarantee a disruption-free test, or establish compliance with a particular framework.

1. Write down the question and the assets

Describe what you need to learn in a sentence. An application owner might need to understand whether users can access records outside their assigned permissions. An infrastructure team might need evidence about a specific network boundary. Clear objectives help the provider propose appropriate coverage.

Prepare an inventory with application URLs, network ranges, environments, owners, and important dependencies. Mark production and non-production systems clearly. Identify third-party services and anything you cannot authorize directly. Record exclusions and explain their effect on the question being tested.

Bring any assessment deadline or reporting requirement to the discussion. A penetration test may support an assessment, but its scope and report need to match the actual evidence requested.

2. Agree authorization and rules of engagement

Make the authorized targets and activities explicit in the agreed documents before testing starts. Resolve any required third-party permission or provider-policy conditions rather than assuming that ownership of an account authorizes testing of the underlying service.

Record the testing window and time zone, permitted starting access, excluded activities, and who can approve a scope change. Define the conditions that stop testing and the process for resuming it. If the team discovers an unexpected dependency, there should be a decision path instead of an improvised expansion of scope.

NIST SP 800-115 includes an assessment-planning chapter and a rules-of-engagement template. Those are useful references for the structure of this discussion; the actual agreement should reflect your environment.

Reference: NIST SP 800-115 — Section 6 and Appendix B

3. Make the right people reachable

Name a primary contact and backup for the testing window. Include someone who can investigate service health, someone who can resolve access problems, and someone with authority to pause the work. Agree how urgent findings will be communicated and acknowledged.

Coordinate with operations and the monitoring team according to the exercise objectives. Decide who is informed and what they should do when they see test activity. Routine testing should not depend on people guessing whether an alert is expected.

4. Check access before the clock starts

Where the agreed test uses supplied access, arrange dedicated accounts with the roles needed for the planned scenarios. Confirm login, MFA enrollment, remote connectivity, and any required approvals before the testing window. For an application with several user roles, explain which account represents each role.

Use an agreed secure channel for credentials. Identify who can reset access and when temporary accounts will be removed. Do not broadly disable protective controls to make testing easier. Any necessary exception should be explicitly approved, limited, documented, and considered when interpreting the result.

5. Coordinate operations and recovery

Tell the provider about fragile systems, business-critical periods, planned deployments, and changes that could affect the test. Agree how maintenance or an incident changes the schedule. Testing an environment while its configuration changes can make findings harder to interpret.

Have the responsible operations team confirm the relevant backup and recovery arrangements, including who can perform a restore. A backup job showing success is not the same as knowing how recovery will work. Agree what service-health signals will be watched and what happens if performance changes during testing.

6. Set expectations for sensitive evidence

Decide what evidence the testers may collect, where it will be stored, who may receive it, and how it will be transferred and removed. Where a demonstration can use test records or limited evidence, discuss that option instead of collecting unnecessary sensitive data.

Reports can themselves reveal sensitive system information. Identify authorized recipients and a suitable delivery channel. NIST’s data-handling guidance covers collection, storage, transmission, and destruction across the assessment lifecycle.

Reference: NIST SP 800-115 — Section 7.4, Data Handling

7. Reserve time for the findings

Before testing, agree the expected deliverables, reporting timetable, urgent-notification process, and opportunity to discuss findings. Ask how the report will describe scope, starting conditions, coverage limits, technical evidence, and recommended corrections.

Assign someone to turn findings into owned remediation work. Clarify whether retesting is included, its scope and timing, and any commercial terms. A completed engineering ticket and a verified correction are different milestones; decide how that distinction will appear in the follow-up record.

The published sample report can help you discuss the level of detail you need. It describes a particular historical assessment, so use it as a reference rather than assuming every engagement has identical scope or deliverables.

Your final readiness check

Before kickoff, confirm that these decisions have an owner and no unresolved dependency will prevent the planned work.

• Objectives, target inventory, exclusions, and third-party conditions are agreed.
• Authorization, testing windows, scope-change rules, and stop conditions are recorded.
• Primary and backup contacts can respond during the testing window.
• Any supplied access works, and temporary-access cleanup has an owner.
• Operations understands the schedule and recovery responsibilities.
• Evidence handling, report recipients, deliverables, and retest expectations are clear.