A useful SaaS pentest begins with testable business questions and working access. Preparation determines whether the assessor can examine role boundaries, tenant isolation, and critical workflows rather than spend the engagement recreating accounts.
The example below is a fictional reporting SaaS. Its domains and accounts are placeholders for a scoping document, not systems to test. NIST SP 800-115 provides a reference for planning assessments, analyzing findings, and developing mitigation strategies; the practical matrix here is an illustrative application.
Define the decision and the version
Replace “test the application” with a decision: can this release safely expose report exports to enterprise customers? Identify the journeys supporting that decision: login, invitations, report creation, publication, export generation, and download.
Record the release/build, deployed configuration, feature flags, and relevant differences between staging and production. A staging assessment does not silently establish the security of a different production identity provider, storage policy, or worker deployment.
Make the scope concrete
For our example, assessment takes place in staging with synthetic data. Production and third-party providers are excluded. Client-side integrations remain in scope where they run in the assessed application; testing a payment or identity provider's own infrastructure is not included.
| Surface | Preparation and boundary |
|---|---|
app.example.test |
Access: member A, admin A, member B. Objective: login, invitations, roles. No real customer accounts. |
api.example.test |
Separate tokens for all three identities. Objective: report isolation and privileged fields. Seeded A/B objects only. |
| export worker | Enqueue access and log correlation. Objective: authorization before artifact creation. Bounded synthetic jobs. |
| download storage | Application-issued test links. Objective: artifact isolation and expiry. Designated test bucket only. |
List API base paths, protocols, and owners alongside these assets. A wildcard domain is not enough to identify outsourced services or shared infrastructure. Agree explicitly on excluded actions and permitted evidence collection.
Build the account and data matrix
A role name alone is insufficient. Prepare memberships and owned objects so the assessor can distinguish role-based from object-based failures:
| Identity | Membership, rights, and data |
|---|---|
member_A |
A; read A and edit own drafts. Prepare an owned draft and another A report. |
admin_A |
A; publish/export A. Prepare an A draft ready for publication. |
member_B |
B; read B and edit own drafts. Prepare a B draft with a known identifier. |
These fictional rights match the multi-tenant testing example. Also prepare an invitation, a removable membership, and disposable export artifacts for state-transition tests.
Use dedicated accounts with realistic MFA and recovery flows. Deliver secrets through the agreed secure channel, never inside a public report or issue. Confirm refresh-token behavior and a way to revoke accounts at the end.
Agree on testing conditions
Document time windows, source IPs, request/concurrency limits, WAF and rate-limit behavior, permitted uploads, and handling of asynchronous jobs. Avoid globally disabling controls without recording the resulting blind spot. If production rate limiting cannot be represented in staging, state that limitation.
Name an application contact and a backup contact who can stop testing. Define observable stop conditions, such as unintended customer-data access or unexpected resource pressure. Specify who decides when testing resumes and how pending jobs are cancelled or drained.
Preserve logs with correlation IDs, verify backups where relevant, and establish cleanup ownership. “Delete test data afterward” must include artifacts, queued messages, invitations, and temporary credentials.
Use a readiness gate
Before assessment begins, perform these preparation checks:
- Each identity can complete its intended login and MFA flow.
- Positive read/write operations succeed against seeded fixtures.
- A and B have distinct objects with known ownership and state.
- The deployed build, scope, exclusions, and testing limits are recorded.
- The assessor can correlate a request to an export job and its artifact.
- Emergency contacts and the stop procedure have been exercised.
- Cleanup, remediation ownership, and retest access are agreed.
An unavailable admin account blocks meaningful admin-boundary testing; do not count that as a passed security control. Start independent testing where possible, but record the reduced coverage and restore access before declaring that objective assessed.
Prepare remediation before the report
Agree how a finding becomes a ticket: affected build, minimal sanitized evidence, root cause, impact, owner, and closure conditions. Preserve test accounts long enough to retest the corrected release, then revoke them and remove fixtures.
Use the finding-to-retest guide to define closure evidence. Preparation succeeds when the engagement can test the intended boundaries, explain its limitations, and leave the team with work that can be verified.