How should teams scope a penetration test for a new application before release?

Scope the test around a feature-complete build, not a partial prototype. The goal is to let testers exercise the major functionality and expose serious issues before users are affected. Communicate clearly that the assessment should prioritize finding as many bugs as possible before release, especially if the build is close to a customer-ready candidate or an unpolished but complete MVP.

Why Release-Ready Scope Matters in a Pen Test

A pre-release penetration test should be aimed at what is actually going to ship, not at a partial build that still has placeholder flows, missing controls, or unfinalised business logic. If the test is too early, findings can be misleading; if it is too late, the team loses the chance to fix serious issues before users or customers are exposed.

That means scope should track the application’s real attack surface, including the core workflows, authentication paths, role boundaries, API behaviour, file handling, and any integrations that will exist at launch. A tester cannot meaningfully assess risk if the build does not yet reflect the intended production design.

For a release candidate, the most useful scope is the one that lets testers exercise the same features, trust boundaries, and data paths an attacker would encounter after release. That is why mature teams usually scope against a feature-complete candidate or a complete MVP, then explicitly state any temporary exclusions or known deviations from the final design.

How to Define the Test Boundary Without Missing the Real Risk

Start with the application’s intended user journeys and the controls that protect them, then map the pen test to the highest-risk entry points and privilege transitions. That normally includes sign-up and login, session handling, object access, admin functions, sensitive APIs, and anything that stores, transmits, or transforms protected data.

The scope should also name what is out of scope with precision. For example, if the build is front-end complete but an internal service is still stubbed, say so. Clear exclusions prevent wasted effort, but they should not be used to hide unfinished security-critical areas that will exist by release.

Where the application depends on external services, identity providers, or platform controls, include them only when they materially affect the question the test is trying to answer. The goal is not to test every dependency in isolation, but to include any dependency that changes whether the application can be abused, escalated, or made to disclose data.

What “Find as Many Bugs as Possible” Means in Practice

The phrase is useful only if it is translated into an aggressive, realistic objective for the test team. In practice, that means authorising depth over checkbox coverage, encouraging chained findings, and making sure the tester can probe beyond single-request flaws into workflow abuse, privilege escalation, and post-authentication paths.

When the build is close to release, the highest-value bugs are often the ones that combine several weaknesses into a business-impacting outcome. A test scope that only covers superficial endpoints will miss how a modest flaw in one feature can become a full compromise when paired with weak access control or unsafe administrative functions.

For applications with modern service integrations, that also means checking whether API access, token handling, and third-party callbacks behave the same way under the final release configuration. The tester should be able to validate whether the application’s intended access boundaries actually hold when the system is used as designed.

Risk and Threat Considerations

A weak or premature scope can create false confidence, because the team may fix issues in a prototype that never reach production while missing the flaws introduced by the real release build. It can also understate risk if the final candidate contains new workflows, roles, or integrations that were absent during testing.

Failure mechanism: The test is run against an incomplete or unrepresentative build, so the tester cannot exercise the true attack surface, cannot chain issues through final workflows, and cannot validate the controls that will actually protect users at release.

Impact: Serious defects can survive into launch, including access-control failures, broken business flows, unsafe integrations, and data exposure that only appears in the feature-complete version.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP ASVS	V4 — API and Web Service	Release testing must cover the final API surface and service paths.
	V8 — Authorization	Pre-release scope must include role and object-access boundaries that affect exploitability.
	V6 — Authentication	The release candidate should include real login and session paths for meaningful testing.
Recommendation — Test the final API and service flows for access-control and input-handling failures. Verify object, function, and role access against the release build’s authorization model. Exercise the final authentication flow, including MFA, recovery, and session handling.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Pen tests are part of verifying exploitable weaknesses before release.
	CA-8 — Penetration Testing	This question is directly about how to scope a penetration test before release.
Recommendation — Use pre-release testing to identify and track exploitable weaknesses before deployment. Scope the test to the release candidate and document any exclusions that reduce coverage.

Practitioner Guidance

What to prioritise: Scope the test to the release candidate that best matches the final production design, then give the tester permission to follow findings across related workflows instead of stopping at the first obvious flaw. That is especially important for applications where auth, admin functions, or API behaviour determine the real blast radius.

What to verify: Confirm that the build under test includes the final authentication paths, role model, privileged features, integrations, and data-handling logic. If any of those are still provisional, either delay the test or document exactly how the delta affects coverage.

Practitioner takeaway: The best pre-release pen test scope is the smallest scope that still represents the real application, because realism drives finding quality and incomplete builds drive blind spots.