Pre-Release Penetration Testing Checklist for SaaS Teams

A new API is ready for release. Its scanner report looks clean, but can a user from one customer account retrieve another customer’s invoice? Questions about roles, data boundaries and business logic often need a human tester who understands what the application is supposed to do.

Agree on the question before testing begins

A useful test starts with the systems, roles and assets you need confidence in. Choose the appropriate level of access for the tester and agree safe testing windows, excluded activities, data handling and escalation. OWASP’s testing guidance is a useful reference for web and API coverage. The actual test plan should reflect your application and its most important workflows.

If targets run on AWS, check the AWS penetration testing policy for permitted services and restricted activities before finalising scope. If the underlying concern is excessive cloud permissions or deployment configuration, CyberSeal Cloud Security Services can help assess those controls.

How CyberSeal works with your engineers

CyberSeal scopes web and mobile applications, APIs, networks and cloud environments according to the engagement. Its approach can include manual validation, testing how weaknesses combine and showing evidence of impact. Deliverables described on the service page include an executive brief, proof of concept, remediation guidance and a tester debrief. Set the retest scope in advance so teams know what will be verified after remediation.

Explore CyberSeal’s Penetration Testing.

Use a release test to validate a defined set of attack paths. To track newly discovered exposures and verify fixes across your wider estate between tests, see CyberSeal Vulnerability Management as a Service.

From discovery to delivery

From test authorisation to the release decision

1 Authorise
Confirm ownership, scope, test windows, and stop conditions.
2 Prepare
Provide test roles, synthetic data, and the release build.
3 Test
Follow agreed attack paths and document reproducible findings.
4 Debrief
Review business impact, fixes, and priorities with engineering.
5 Retest
Check the patched build with authorised and unauthorised roles.
6 Decide
Record what was verified, open risks, and who owns sign-off.

What CyberSeal penetration testing onboarding looks like

Kickoff and scope. Bring the release plan, authorised target list, API specification, and a diagram showing identity, tenant boundaries, and key data flows. Include the application owner, platform lead, and release decision-maker. Agree what to test first, whether the tester starts with public information or supplied accounts, and which third-party systems are excluded.

Prepare the environment. Agree on the build, testing window, emergency contact, and stop conditions. For a multi-tenant SaaS test, supply synthetic records and two test tenants with comparable roles. Add a restricted role where it matters. Record differences between staging and production, such as identity rules or exposed endpoints, so readers of the report understand its coverage.

Validate and debrief. CyberSeal can manually validate suspected issues and test how weaknesses combine within the rules of engagement. Its deliverables include an executive brief, proof of concept, code or configuration remediation guidance, and a call with the lead tester. Use the debrief to agree which findings affect the release and who owns the changes.

Retest and hand over. Share the patched build and the affected workflows. CyberSeal lists a free retest for Critical and High findings on its service page. Confirm which findings, environment, and retest window are included in your scope. Record the verified fixes and give unresolved items an owner, a due date, and a release decision.

What to check: A report should connect each serious finding to a real consequence and an actionable fix. A long list of tool output does not do that on its own.

Practical details and examples

Scope the test around the decisions it should inform

Tell the tester why the work is happening now. A SaaS launch may need confidence in account boundaries. A merger might require understanding what access an acquired environment could have to the rest of the network. A board may want evidence that a specific class of control is working. Each decision changes which assets, users and workflows should be included. Agree which tests are out of scope, which systems share infrastructure with production and who can authorise changes to the rules during the engagement.

Give the team enough context to distinguish a serious finding from an expected feature. For a multi-tenant application, supply test accounts representing different roles and organisations, and tell the testers which records are safe to use. For a network review, identify sensitive systems and agree where testing must stop. CyberSeal’s service can cover web and mobile applications, APIs, networks and cloud environments. The engagement still needs explicit boundaries so that the depth of testing matches both the customer’s objective and its operational risk.

Example: Test whether a user can cross a customer boundary

Imagine a customer portal in a controlled test environment with two fictitious accounts. Both accounts can see their own invoices. A useful test checks whether someone signed into the first account can reach an invoice belonging to the second through an application or API workflow. The test should be authorised, use the agreed data and stop at the point where the team has enough evidence to explain the issue. Demonstrating the broken boundary is sufficient; collecting more sensitive material does not make the report more useful.

The written finding should show the affected role, the action that was possible, why the business cares and what a fix would need to prevent. In this example, the team should not rely on hiding an invoice link if the underlying service still accepts an unauthorised request. Engineering needs enough context to add a suitable authorisation check and test related paths. Leadership needs to understand which customers or workflows could be affected. The same evidence can support both conversations, with different levels of technical detail.

Retest evidence: On the patched build, confirm the test user can retrieve their own invoice and is denied access to the other tenant’s invoice. Repeat the check for any in-scope export endpoint that uses the same access rules. Record the build, roles, endpoint, and observed result using synthetic data. PortSwigger Web Security Academy’s access-control guide explains related test scenarios.

Agree how urgent issues are raised during delivery

Define a contact path before the test starts. If the tester finds an issue that exposes sensitive information, who should receive the first notification? What level of evidence can be included in email, and what belongs in a restricted channel? If the application slows down, who can pause testing and how will the tester confirm that work has stopped? Put these questions in the rules of engagement, along with time windows and any service dependencies. This gives both sides a way to act without improvising under pressure.

During testing, keep a record of what was covered, what could not be reached and what assumptions apply. If a feature is unavailable during the test, do not let the final report imply that it was checked. The customer can decide whether to extend coverage, test a representative environment or document the limit. A useful status update distinguishes completed work, open blockers and decisions the customer needs to make before the next phase.

Turn the report into a remediation and retest plan

The CyberSeal service page describes an executive brief, evidence, remediation guidance and a debrief with the tester. Use the debrief to map findings to owners and decide what can be fixed together. An application with several access-control issues might benefit from one shared design change and regression tests rather than separate workarounds for individual screens. Discuss compensating controls if a permanent fix cannot be delivered before the release. Give leadership a clear decision about what risk remains and why.

Define retest scope and timing while the context is still fresh. The tester should confirm that the original path is closed and report whether the result is fixed, partially fixed or still reproducible in the retested scope. A retest does not automatically cover every new feature that shipped after the first assessment. If the project is going into continuous delivery, agree what changes should trigger a focused follow-up test and who will retain the evidence safely.

What a good scoping conversation sounds like

Bring one system diagram, the important user roles and a short list of the outcomes you want evidence for. Ask the provider to explain what it would test manually, what it would verify with tools and what it would avoid without separate approval. Ask for a sanitised sample finding to see whether the report helps your engineers fix the issue. Set expectations for debrief and retest before agreeing to the work.