A practical guide for SaaS teams preparing scope, test environments, user access, documentation, timelines, and communication before a penetration test begins.
What Preparation Actually Means
Preparation is not paperwork. It is making sure the right application areas, user roles, environments, and business workflows are ready before testing starts.
Clear scope
Know which product areas, APIs, portals, roles, and workflows are included before testing begins.
Working access
Prepare realistic test accounts and remove avoidable login, allowlist, and permission blockers.
Useful output
Good preparation leads to stronger findings, clearer evidence, and actionable remediation.
Turn the Product Into a Testable Surface
A penetration test becomes more valuable when the tester can see how users, roles, APIs, and business-critical actions connect.
Scope
Application, API, portal, or workflow.
Access
Accounts, roles, tenants, and authentication paths.
Context
Important business workflows and sensitive actions.
Testing
Manual validation of reachable risk and exploitability.
From Request to Testing
This is the simple path most teams follow before a focused penetration test starts.
Initial Discussion
Share product area, objective, and security concern.
Scope Review
Confirm targets, environments, exclusions, and roles.
Access Setup
Prepare accounts, tenants, allowlists, and documentation.
Testing Begins
Manual testing starts against the agreed scope.
What Your Team Should Have Ready
You do not need perfect documentation. You need enough context for the engagement to begin cleanly.
Scope definition
- Application, API, portal, or workflow
- In-scope and excluded areas
- High-risk workflows
Testing environment
- Production or staging decision
- Stable representative build
- Features deployed and reachable
Access and accounts
- Accounts for relevant roles
- Tenant or organization setup
- Allowlisting and restrictions
Documentation
- Entry points and URLs
- API collections if available
- Recent changes or sensitive areas
Communication
- Main point of contact
- Access issue owner
- Urgent finding path
Role coverage
Authorization testing is stronger when admin, manager, member, viewer, guest, or tenant-specific accounts are available.
Why Role Coverage Matters More Than Account Count
Access control bugs only appear when one account tries something that belongs to another. A tester with a single login sees what that account may do, but has nothing to compare it against, so the whole class of issue stays invisible. Ten accounts in one role reveal less than three accounts chosen to cover these pairings.
Two users in the same role
Shows whether one user can read or change another user’s records at the same privilege level.
One user per privilege level
Shows whether a lower role can reach actions reserved for a higher one, such as billing or user management.
Two separate tenants
Shows whether one customer can reach another customer’s data. On a multi-tenant product this is usually the finding that matters most.
Scope Decisions That Change the Result
These choices decide what the report can and cannot tell you.
Third party integrations
Excluding them keeps testing inside systems you own. Including them covers webhooks, OAuth grants and data syncs, where trust between systems is often assumed rather than checked.
Authenticated or not
An unauthenticated test sees the login page and public endpoints. Most serious SaaS findings sit behind login, so an unauthenticated test on its own misses them.
Business logic in scope
Logic testing means learning your workflows: pricing, approvals, invitations, refunds. Without it, the report covers technical flaws but not misuse of the product’s own rules.
What Goes Wrong
Test data unlike production
Empty accounts with no records hide issues that depend on real data relationships. Seed the environment with data shaped like production.
An environment that changes mid test
A deployment during testing can open or close issues and make findings impossible to reproduce. Freeze the build or share the deploy schedule.
A WAF or rate limit blocking the tester
Blocked requests look like secure endpoints. Decide whether the test measures the application or the WAF in front of it, and allowlist the tester if it is the application.
Approvals that arrive late
Accounts, allowlisting or sign off that land after the start date eat into testing time. Settle them before the agreed start.
What Happens After You Contact THF
Kickoff
Confirm scope, environment, and point of contact.
Testing
Validate access, test workflows, and confirm findings.
Reporting
Prepare evidence, impact, and remediation guidance.
Retesting
Validate fixes and document final status.
Preparation Readiness Matrix
What You Receive After Testing
The value of a penetration test is the combination of validated findings, clear evidence, business impact, remediation guidance, and retesting support.
Validated findings
Confirmed issues, not scanner noise.
Technical evidence
Requests, responses, screenshots, and reproduction context.
Remediation guidance
Practical next steps your team can act on.
Triage and Remediation
Triage findings by what they expose and who can reach them, not by how many there are. One cross-tenant read usually outranks several minor issues. While fixes are built, I answer questions on individual findings so each fix addresses the root cause rather than the single example reported. Retesting then confirms which findings are closed.
Common Questions
Answers for teams preparing for SaaS, API, GraphQL, and access-control-focused penetration testing.
Should we test production or staging?+
Do we need to provide test accounts?+
Can APIs and web app flows be covered together?+
How long does preparation usually take?+
What if our team is non-technical?+
Need a Penetration Test Built Around Your Product?
The Hidden Finds helps SaaS teams scope focused manual testing across web applications, APIs, GraphQL, access control, business logic, and multi-tenant risk.