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

How to prepare for a penetration test comes down to five things: agree why you are testing, write down exactly what is in and out of scope, sign rules of engagement, notify anyone who hosts or monitors your systems, and have backups, test accounts, allow-listing and documentation ready before day one. Most of this takes two to four weeks, and it decides whether testers spend their paid days testing or waiting.

This checklist covers what to do before, during and after a test so your team gets full value from it.

Key takeaways

• Start with why you are testing: compliance, customer assurance and major change each need a different scope.
• Agree written rules of engagement, including exclusions, testing windows and emergency contacts.
• Brief the people who will see the test in their logs, and involve HR and legal if people are being tested.
• Have backups, accounts, allow-listing and documentation ready before day one.
• Plan remediation and a retest before the report arrives.

How to prepare for a penetration test: what to do and when

Why are you testing?

Your objective shapes everything else. Common drivers are:

• Compliance. PCI DSS Requirement 11.4 requires internal and external testing at least every 12 months and after significant change. If this test will go to your assessor, say so at scoping. PCI penetration testing has specific rules on scope, methodology and retesting.
• Customer or insurer assurance. A contract or insurance renewal may ask for independent testing.
• Change. A new application, cloud migration or acquisition introduces new risk.
• Checking earlier fixes. Confirming that remediation from a previous test worked.

Be clear about what you are buying. A vulnerability scan is automated and finds known weaknesses; a penetration test is led by a person who confirms, exploits and chains them. Our comparison of penetration testing vs vulnerability scanning explains the difference.

Decide how much information the testers will get: black box (no prior knowledge), grey box (some knowledge and user-level access, usually the best value) or white box (full documentation and sometimes source code).

How do you scope a penetration test?

Scope a penetration test by listing every target, how big each one is and any compliance requirement the test must meet, then agreeing what is excluded. Gather these details before you ask for a price, because they are what any provider needs to estimate tester-days accurately:

• Live external IP addresses, domains and hostnames.
• Internal sites, subnets and the approximate number of hosts and users.
• Web applications and APIs, with the number of user roles and main functions.
• Cloud accounts, subscriptions or projects and the platforms they run on.
• Wireless networks, physical sites or people, if relevant.
• Any compliance requirement the test must meet, and your deadline.

Our penetration testing quote form asks for exactly these details, so you can use it as a scoping worksheet even before you are ready to buy.

What should be in and out of scope?

Write down what is in scope and, just as importantly, what is not: fragile legacy systems, third-party services you do not own, and production data that must not be touched. For PCI DSS, testing must cover the whole cardholder data environment perimeter and critical systems, and should normally take place in production. If you test a separate environment, it must match production.

What goes in the rules of engagement?

The rules of engagement are the written agreement that governs the test. They should cover:

• Testing dates and times, including blackout periods such as month-end.
• Techniques that are not permitted, such as denial of service.
• Limits on password guessing, to avoid locking out real users.
• How and how fast critical findings will be reported during the test.
• Named emergency contacts on both sides, available throughout.
• How to stop testing immediately if something goes wrong.
• How test data and any sensitive data found will be handled and deleted.

The PCI SSC’s penetration testing guidance is a useful reference even if PCI DSS does not apply to you.

Who else needs to be told?

• Cloud providers. AWS, Azure and Google Cloud do not need advance notice for testing your own resources, but each publishes rules on what you may test. Our guide to AWS and Azure penetration testing rules summarises them.
• Hosting and managed service providers. Some contracts require notice, and an unannounced test can trigger their incident response.
• Managed security or SOC providers. Tell them unless you are deliberately testing their detection.
• SaaS platforms. You usually cannot test someone else’s platform without their permission.

How should you brief your people?

• Executive sponsor. Someone senior should own the test and the remediation budget, and make clear that finding serious issues is a success, not a failure of the IT team.
• IT and operations. The people who run in-scope systems should know the testing window, what unusual activity to expect and how to reach the testers.
• Security operations. Telling them avoids wasted effort; not telling them tests detection and response, but needs a senior person who can confirm the activity is authorised.
• HR and legal. If the test includes phishing, phone pretexting or physical access, involve them early. Social engineering penetration testing must respect employment policies and data protection law, and should never single out individuals.

How do you get the technical environment ready?

• Take backups of in-scope systems and confirm you can restore them.
• Create test accounts for each user role in scope, with at least two per role for applications so testers can check one user against another. Set up MFA tokens for testers rather than disabling MFA.
• Allow-list tester IP addresses where agreed, so the test examines the application rather than the edge controls.
• Stabilise the environment. Nothing mid-deployment, and realistic test data.
• Check logging and monitoring, so you can match tester activity to your logs afterwards.
• Share documentation: network diagrams, API specifications and user guides.

What happens during and after the test?

During testing, keep one named contact available, agree a short daily update on longer engagements, and avoid major changes to in-scope systems. If a critical issue is reported mid-test and you fix it, tell the testers so their results stay accurate.

Afterwards, hold a debrief with the testers and the teams who will fix the issues, assign an owner and target date to every finding, and book a retest. PCI DSS requires exploitable vulnerabilities to be corrected and testing repeated (11.4.4). Our guides on reading a penetration testing report and penetration test remediation cover this stage.

Penetration test preparation checklist

Use this penetration testing checklist in the weeks before day one. It covers your side of the work; the tester’s side follows a published methodology such as the OWASP Web Security Testing Guide, and our page on penetration testing methodology explains how a test is run. You can also download this checklist as a free spreadsheet (.xlsx) to print or share, with timings, owners and a status for every task.

• Objectives agreed and written down
• Scope and exclusions confirmed in writing
• Rules of engagement signed, with emergency contacts
• Cloud testing rules checked; hosting providers notified where contracts require it; managed security providers briefed
• Sponsor, IT, security operations, HR and legal briefed as appropriate
• Backups taken and restore tested
• Test accounts, MFA tokens and allow-listing ready
• Documentation shared with testers
• Remediation owners and a retest date pencilled in

Why Sovereign Secure

Sovereign Secure is a PCI SSC Qualified Security Assessor (QSA) company, an IASME-licensed Cyber Essentials certification body and ISO 27001 certified. We will work through this checklist with you during scoping, so the test starts on time and the report is ready to use as evidence.

Next step

Our penetration testing services UK page sets out the network, application, cloud and social engineering testing we offer. When you have the scoping details above, send them through our pen test quote form for a fixed price.