In this guide 6 sections
Fix the scope in writing, create test logins for each user role and choose staging or production. Agree quiet hours, tell the people who watch your alerts and decide how findings will be handed over. Most delays come from missing accounts. The test itself is rarely the problem.
Write the scope down first
List every system the testers may touch. Give hostnames, API base addresses, mobile app builds and cloud accounts. Then list what they must not touch, such as the payroll vendor’s portal or a shared SMS gateway you only rent.
Be honest about what you cannot authorise. If your site sits on a shared host or behind a content delivery network, the provider may have its own testing policy. Read it before the test date, not after the first alert.
Name one owner on your side. Questions come up mid test, and a tester waiting two days for an answer loses two days of a paid engagement.
- Hostnames, IP ranges and API addresses
- App versions and store links
- Cloud accounts and regions
- Third party services excluded
- One named owner and a backup
Prepare test logins for every role
Testers learn most by acting as different users. Create one account for each role: ordinary customer, branch clerk, accounts staff, manager and administrator. Two accounts per role let them check whether user A can read user B’s records.
Fill those accounts with believable but fake data. A dummy order, an invoice PDF and a support ticket give the testers real screens to work on. Never hand over a real customer’s login.
Decide how multi factor sign in is handled. Either exempt the test accounts or give the testers a way to receive codes. Otherwise day one disappears into locked screens.
Choose staging or production
Staging is safer, but only if it truly matches production. Check that the same code version, the same user roles and the same third party connections are present. A staging site with the payment step switched off hides the riskiest part.
Production testing finds what staging cannot, such as a misconfigured firewall rule or a forgotten admin page. If you choose it, take a fresh backup, reduce the test’s rate of requests and agree which actions are forbidden, for example sending real emails or placing real orders.
Many teams do both. The wide sweep runs on staging, and a short, careful pass confirms the key findings on production.
- Same code version on both
- Payment and email set to sandbox on staging
- Fresh backup before production work
- Rate limits agreed with the testers
Agree quiet hours and tell the right people
Choose test windows that avoid month end, a sale, payroll day or a release. Share the source addresses the testers will use so your team can tell a test from a real attack.
Tell your hosting provider, your managed security service if you have one, and the two or three staff who watch alerts. Do not tell the whole company. A tester sees how well your team notices strange traffic only if someone is watching normally.
Agree a stop word or phone number. If a dashboard turns red or customers complain about slowness, someone must be able to pause the test in minutes.
Decide how findings are handed over
Ask how serious findings arrive. A critical hole in a login page should not wait for the final report. Agree an encrypted channel and a named recipient for urgent items.
Plan the fix side too. Set aside developer time in the week after the report, and open a ticket board where each finding becomes a task with an owner. Findings left in a PDF tend to stay there.
Book the retest before the first test ends. Put its date in the calendar today.
- Urgent findings sent the same day
- Encrypted file sharing for the report
- Developer time reserved after delivery
- Ticket per finding with an owner
- Retest date fixed
Penetration test preparation checklist
A single page checklist in five blocks: scope, accounts, environment, communication and handover. Scope lists hosts, apps and exclusions. Accounts has a table of roles against usernames and the multi factor setting. Environment records staging or production and backup time. Communication holds contacts and test windows. Handover lists the urgent channel and the retest date.
Open a blank worksheet to printQuestions owners ask
How far ahead should we start preparing?
Allow at least two weeks. Writing the scope and creating test accounts for every role takes longer than most teams expect, and approvals from hosting providers can be slow.
Should we warn our IT staff before the test?
Tell the few people who run alerts and hosting, so a stop request can be acted on. Keeping everyone else unaware shows how your normal monitoring behaves.
Do we need a backup before testing?
Yes, particularly if production is in scope. A recent, restorable copy means a stray test record or a crashed service is an inconvenience and not a crisis.
What if the testers find something serious on day one?
A good provider reports it at once through the channel you agreed. You can then fix it while the test continues, and the retest will confirm the fix.