How to prepare for a penetration test

Start with the change or concern behind it: a new customer portal, an authentication rewrite, a multi-tenant API, or an upcoming launch. That gives us a way to prioritize the workflows people rely on, rather than treating every URL as equally important.

List the domains, apps, APIs, and environments to include. Call out third-party systems, live customer records, destructive actions, and endpoints that cannot handle a high request rate. Give us a contact for questions and urgent findings. We confirm the boundaries and reporting path before work begins.

The OWASP Web Security Testing Guide starts with identifying the applications, hosts, and endpoints to test.

Create accounts for the roles you want checked, such as an ordinary user and an administrator. If the product has tenants, use two test organizations so a tester can check whether one can reach the other's records. These accounts avoid employee credentials and live customer data.

A short walkthrough is enough. Show how users invite teammates, switch organizations, export data, or reach other sensitive actions. Share API documentation if you have it. Point out actions that send email, charge cards, or need a restricted test window or request rate.

Name someone who can receive an urgent finding during testing and someone who can own the fix. We report reproducible issues with evidence, observed impact, and steps your team can evaluate. After a fix, we retest the affected path. Review the sample report if you want to see the format; its example assets are fictional.

• The product change or concern driving the test.
• URLs, APIs, environments, and exclusions.
• Test roles and organizations you can provide.
• Actions and data to avoid, plus any rate or time limits.
• Contacts for urgent findings and fixes.

See what we test in web applications and APIs.