After you agree a statement of work, the days before the testing window decide whether testers spend that window testing or waiting on access. The PenTesting Company tests only with written authorization. This post is a practical checklist for getting access, accounts, the window, and contacts ready so authorized testing can start on time. A penetration test is not a compliance certification.
Short answer
What the statement of work and rules of engagement cover
You are not ready to start until the written agreement matches what your team can actually provide. The statement of work is the engagement agreement. It usually lists scope, windows, deliverables, and retest terms. Retest terms set in the statement of work.
Rules of engagement describe how testing is allowed to proceed inside that scope: which techniques are agreed, what is excluded (denial-of-service is a common exclusion), how test data is handled, and who can pause the test. Some teams keep both in one document. Authorized testing only happens inside that written scope.
Before the window, read that writing and check that authorization has come from whoever controls each asset, including a hosting, cloud, or managed-service provider when their terms require it.
Access
Testers need a way to reach every system in scope on the first day of the window, not on the second. For an internet-facing application that usually means a URL that resolves and a login that works. For an internal network test, it usually means a VPN account or a connected device, checked end to end before the window opens. For a mobile test, it means the agreed builds install and the test accounts can sign in on the test devices.
MFA and SSO are part of access. Decide how test identities enroll: a real MFA method on those accounts, or another approach you agree in writing. If testers cannot complete login, the window is spent on identity rather than on the application.
Documentation you already have (OpenAPI or Swagger files, a short product walkthrough, architecture notes) helps testers spend the window on the system instead of reverse-engineering it. You do not need a complete pack. What you already use internally is enough to share.
Test accounts
Broken access control is often found by comparing what one role or tenant can reach with what another can. A single standard-user account is not enough for that comparison. For a web application test, that usually means an account for each role in scope, and two separate tenants when the product is multi-tenant.
Use dedicated test accounts and test data, not a real customer's live records. Confirm that those accounts are not subject to an aggressive lockout that a tester cannot recover from without you, or name a contact who can unlock them quickly.
A useful last check is to sign in as each test account and load the in-scope hosts the morning the window opens, so a stale password or a broken MFA enrollment is found before testing hours start.
Testing window and contacts
The window is the start and end dates, the hours testing may run, and any times that are off limits (a known deploy, a peak trading hour, a freeze). Some teams pause non-urgent deploys during the window so the system under test stays stable. That is a choice, not a requirement. Name it in writing either way.
Name a primary contact and a backup. Both should be reachable during the agreed hours, able to pause testing, and able to unlock access. If a critical-severity issue is confirmed, that named contact is told during testing rather than waiting for the report.
If you have a security operations or monitoring team, tell them the window and the tester source IPs. Otherwise tester traffic can be treated as an incident, accounts can be locked, and the rest of the window is spent restoring access. Listing those IPs in the statement of work also lets you decide whether to allowlist them in a WAF, firewall, or rate-limit control. Allowlisting means more of the window is spent on the application or network. Leaving protections in place measures the stack as users see it. Neither choice is required. Agree which one you want.
Worked example: Example Corp prepares for a test
Illustrative only. Example Corp, example.com, and the details below are placeholders, not a client. This is not a past engagement. It shows how one hypothetical team might prepare once a statement of work is agreed.
Example Corp runs a business-to-business product at app.example.com, with a JSON API at api.example.com. They agree an authorized web application test of staging, which they treat as close to production. The statement of work names three roles (standard user, organization admin, and platform admin), a Tuesday-through-Thursday window, and a named contact. Out of scope: the marketing site, the third-party identity provider, other customers' real data, social engineering, and denial-of-service testing.
In the week before the window, Example Corp works through the checklist below so testing can start on Tuesday morning.
| Prep item | What Example Corp has ready |
|---|---|
| Authorization | Written approval from Example Corp, which controls app.example.com and api.example.com. Hosting-provider terms are checked and recorded in the statement of work. |
| Access | Testers can reach staging.example.com from the internet. Each test account has MFA enrolled. API documentation for api.example.com is shared. |
| Accounts | Two tenants (Tenant A and Tenant B), each with a standard user and an organization admin, plus one platform admin. Logins are checked the morning the window opens. |
| Testing window | Tuesday through Thursday, 09:00 to 18:00 US Eastern. The usual Friday deploy is held until after the window. Denial-of-service testing is out of scope. |
| Contacts | Primary: the application engineering lead. Backup: the on-call security person. Both can pause testing. The security operations team has the window and the tester source IPs. |
| Allowlisting | Tester source IPs are listed in the statement of work. For this window, Example Corp allowlists them on the staging WAF so the test measures the application. |
On Tuesday morning, Example Corp signs in as each test account and loads staging.example.com before testers begin. If a login fails, the named contact can reset it without waiting for a ticket queue. If the statement of work also includes an internal network test, they confirm the VPN or device before that window, not on the first morning.
After the report, they use the readout to turn findings into tickets. Retest terms set in the statement of work. A penetration test is not a compliance certification. The report can support a customer review. It does not make Example Corp compliant on its own.
If you want to see how an engagement runs after you are ready, read the worked example on web application security testing or network penetration testing. For what the report looks like when it arrives, see how to read a penetration test report. Contact us to agree a scope.
Frequently asked questions
What should we have ready before testing starts?
Written authorization from whoever controls each asset, working access to the systems in scope, test accounts for each role (two accounts or two tenants when the test needs to compare them), a named testing window, and a primary and backup contact who can pause testing and unlock access. Share any API docs, architecture notes, or product walkthrough you already have. Authorized testing only happens inside the written scope.
Should we allowlist tester IP addresses?
It depends on what you want the test to measure. Allowlisting tester source IPs in a WAF, firewall, or rate-limit control means more of the window is spent on the application or network, rather than on those protections. Leaving protections in place measures the stack as users see it. Agree which approach you want in writing, and list the tester source IPs in the statement of work either way so your team can recognize the traffic.
Who needs to be available during the testing window?
A primary contact and a backup who can be reached during the agreed hours, unlock a test account, confirm a scope question, and pause testing if needed. If you have a security operations or monitoring team, tell them the window and the tester source IPs so they can check with that named contact before treating tester traffic as an incident. A critical-severity issue is raised with the named contact during testing rather than waiting for the report.
What if a test account locks or access breaks during the test?
Have a contact who can unlock or reset the agreed test accounts quickly, and say so in the statement of work. Aggressive lockout on those accounts can stop testing until someone is reached. A useful last check is to sign in as each test account and load the in-scope hosts the morning the window opens.
After we fix findings, is a retest automatic?
Retest terms set in the statement of work. In most engagements a retest is a return to the original confirmed findings, not a second full test of everything in scope. Recurring full tests are a separate conversation, based on how much the system changes, vendor reviews, and your release cadence.
Is a penetration test a compliance certification?
No. A penetration test is not a compliance certification. The report can support a compliance program or a vendor review by providing independent evidence of testing. It does not make you compliant on its own.
Have a system you want tested?
Tell us what you are working with and we will follow up with next steps.