A working login isn't the same as a useful test account. An empty workspace can't show much about document sharing. An admin account won't explain what a restricted member is allowed to do. A webhook pointed at a real customer system creates a different problem altogether.

Give the tester a clear starting point

Preparation is mostly about removing avoidable delays and surprises. Give the tester realistic, synthetic data, a short product walkthrough, and written permission with clear limits.

You don't need to hide known issues to get an independent assessment. Share them and explain what's already being fixed. The tester can use that context without treating your internal conclusions as proof.

Do an access rehearsal. From a fresh browser, sign in as each supplied role and walk through its main tasks. Check that mail, MFA, test data, and integrations work. Do this before the paid testing window.

1. Confirm what's in scope

Check the asset list against the build you'll supply. Include the app and API URLs, staff interfaces, environment, roles, and priority workflows. Note anything added or removed since the quote.

Make exclusions equally clear. Your app calling a payment provider doesn't authorize testing that provider. The same applies to shared identity systems and customer-managed integrations.

If the boundary is still undecided, use the web and API pentest scoping guide first. Then confirm the scope in writing with the tester.

2. Prepare accounts for the roles being tested

Prepare the relationships you want assessed. For a multi-tenant app, that usually means more than one controlled tenant and more than one role. Shared projects may also need two members in the same tenant, with different permissions.

Use dedicated identities, not employee accounts. Seed records whose owner and expected permissions are known. Route emails, payments, notifications, and webhooks to controlled test resources so ordinary product actions don't reach real customers.

  • Verify every username, password, MFA path, SSO assignment, and invitation before the test window.
  • Provide a secure method for exchanging credentials; do not place passwords in the statement of work or ordinary email threads.
  • Record which team owns each test account and when it will be disabled.
  • Explain any seeded data that must not be modified, deleted, or exported.

3. Show how your product works

Share the architecture sketch, API specification, role matrix, and known issue list you actually use. Mark anything out of date. A short walkthrough of a sensitive workflow can be more helpful than a large folder of disconnected documents.

Explain what happens after the screen says "done." Does a background job build an export? Does approval send a webhook? Which service decides who may access the result? The tester needs to know where to look, not just which page starts the process.

If you share a previous report, agree whether its findings need verification in this engagement. Don't assume a new assessment automatically includes the old re-test.

4. Agree safe operating rules

The rules of engagement should tell the tester exactly what's permitted, when testing may happen, and when to stop. Include authorized people and assets, rate limits, prohibited actions, evidence handling, and urgent contacts.

Resolve the awkward questions now: may an account be locked out? Can test records be deleted? What if real customer data appears? Destructive activity, denial-of-service testing, and third-party testing need separate, explicit treatment.

Agree how the web application firewall and anti-automation controls will be handled. If allowlisting is used for coverage, record when it applies. Don't quietly change the environment halfway through the test.

5. Check the environment and monitoring

Write down the differences between staging and production: code version, identity settings, integrations, and security controls. The report needs to reflect the environment actually tested.

Check logs and alerts, and tell the defensive team what response is expected. An automatic account reset or unannounced block can interrupt the work. Use an agreed time zone so both sides can compare activity with logs.

Test VPN access, allowlists, credential delivery, and build availability before day one. Avoid unrelated releases during testing; if a release can't wait, tell the tester what changed.

6. Make sure the right people are available

Someone needs to be able to answer product questions and restore access. Someone also needs authority to pause the test or coordinate an urgent fix. Name both contacts, agree their hours, and choose a secure channel for evidence.

Finish the written authorization and other agreements before testing starts. Book the report walkthrough and reserve engineering time for fixes and the re-test. Otherwise the report can arrive just as the people who need it disappear into another release.

The final pre-test checklist

Ready to begin

  • The business objective, in-scope assets, roles, tenants, workflows, and exclusions are written down.
  • The NDA, statement of work, authorization, and rules of engagement are executed.
  • Dedicated test accounts, synthetic data, MFA, mailboxes, and integration prerequisites work.
  • Architecture, API, role, and workflow documentation is shared through an approved channel.
  • Production or staging is stable, representative, monitored, and free of surprise release changes.
  • Rate limits, WAF handling, prohibited techniques, data handling, and stop conditions are agreed.
  • Technical and urgent contacts know the test window and communication channels.
  • Engineering time is reserved for the walkthrough, remediation questions, and bounded re-test.

If an essential item is missing, tell the tester now. Agree whether to move the start date or change the plan, and record any resulting coverage gap.

Not sure your setup is ready?

Tell us what's working and what's still missing. We can discuss the accounts and environment needed for your SaaS penetration test before agreeing on a start date.

Request a pentest proposal Draft your scope first