Early-stage teams usually meet penetration testing through a customer: an enterprise prospect sends a security questionnaire, and one line asks for a recent pentest report. That's a fine reason to test — but testing only when asked means testing later than you should, under deadline, with the easy findings still in place.
When you actually need one
- Before you store other people's sensitive data at any real scale — payments, health, identity documents.
- Before a major launch or a move into enterprise sales.
- When a customer, investor or auditor (SOC 2, ISO 27001) asks for evidence.
- After a significant change to authentication, permissions or your multi-tenant model.
What to put in scope first
Budget is finite, so scope where breaches actually happen in young products:
- Access control between users and tenants — can one customer read another's data by changing an id? This is the most common serious finding in SaaS.
- Authentication flows — sign-up, login, password reset, invitations, SSO.
- The API behind your front end, including endpoints the UI no longer uses.
- Anything that moves money or changes permissions.
Clear the easy findings first
A manual test is expensive time. Don't spend it on issues automation can find in minutes: exposed .env or .git files, API keys in JavaScript bundles, missing security headers, tokens stored in localStorage, outdated libraries with known CVEs. Run an automated pentest first — MyPentest is free during launch — fix what it finds, then let the human testers start from a cleaner baseline.
Give testers two accounts in each role. Most of the valuable findings in SaaS come from comparing what user A and user B can see.
How to prepare
- Provide a staging environment that mirrors production, with realistic data that isn't real customer data.
- Create test accounts for every role, in at least two separate tenants.
- Share API documentation, if you have it — it saves discovery time.
- Agree rules of engagement in writing: scope, testing windows, who to call if something critical turns up.
- Plan time to fix, and make sure retesting is included in the quote.
What a good report gives you
Each finding should have a severity with its reasoning, clear reproduction steps, and a specific fix for your stack — plus an executive summary you can share with the customer who asked. If a report reads like an export from a scanner, it probably is one.