Penetration Testing Before Product Launch: Scope, Depth and Release Criteria

Eleven days remain before the public launch. Take a hypothetical B2B invoicing platform: every customer has its own workspace, accountants upload batches as CSV files, partners connect through a public API, and support staff work in a separate console that has a "log in as customer" button for troubleshooting. Marketing is paid for, the date is announced, and the pentest is booked for the final week — "so we can test the finished thing".

On day three the tester reports that the invoice export takes the organization ID from a query parameter and never checks it against the session. Change the number and you are looking at another company's bank details and totals. The support console, meanwhile, lets staff enter any workspace without a log entry and without a second factor. The first issue can be fixed in a day. The second needs a redesign of roles, and it will not be ready by launch day.

This is a hypothetical scenario, not an account of a real engagement. But the question it raises is very real for founders, product owners and security leads: what exactly should be tested before launch, when, how deeply — and by what rule do you decide the release can ship? Below we look at how to structure a pre-launch pentest so that its result supports a decision rather than simply landing in a folder of reports.

What a pre-release penetration test gives you — and what it doesn't

A pre-launch pentest is authorized, time-boxed work: specialists look for exploitable vulnerabilities in a new product and show exactly how they can be exploited. If testing takes place before public traffic, in an isolated environment with synthetic data, fixes do not affect live customers and partner integrations do not yet depend on vulnerable behavior. Those conditions, rather than the label “pre-launch” by itself, provide the timing and testing-safety advantage.

CISA's Secure by Design initiative insists that security is built in at the design stage rather than added after a product ships. A pentest fits that logic as a check: it shows whether design decisions survive contact with someone deliberately looking for where they break. It cannot replace secure design.

The boundaries are worth agreeing on from the start. A pentest does not prove the absence of vulnerabilities. It produces evidence within an agreed scope, over an agreed period and at an agreed level of access. One confirmed finding shows that an attack is possible, but it says nothing about how often similar defects occur elsewhere in the code. Conversely, if two weeks of testing turn up nothing critical, that only means nothing critical was found in the scenarios tested.

A pentest is not certification, attestation or a compliance opinion. That is precisely why its result is best read as input to a risk decision rather than as a "secure" stamp.

How to scope a penetration test before launch

A good scope does not start with a list of IP addresses. It starts with a question: which paths in the product appeared or changed for this release, and which of them are dangerous if they behave differently from what was intended? Priority depends on potential impact and reachability; common candidates for deeper testing include authentication, customer-data separation, payments and personal-data processing, file uploads, public APIs and calls to third-party services.

Service surfaces deserve to be named explicitly. Admin consoles, support tools and internal endpoints for the operations team can hold broad privileges and still fall out of scope because “they are not for customers”.

Assets, roles and tenants

Each role in the agreed scope, from anonymous visitor to super-administrator, needs suitable test accounts or another agreed means of testing. If the product is multi-tenant, at least two test tenants make it possible to check a central question directly — whether one customer can see or change another customer's data. How tenant isolation and billing roles shape scope is covered in more detail in our piece on penetration testing for SaaS companies.

Do not underestimate "read-only" features. Even when exports, reports, search and document previews do not modify business objects, they can disclose other people's data. Read-only status by itself does not mean low risk.

Credentials come in two kinds, and the scope should treat them separately. Multi-factor authentication applies to interactive human sign-in when it is configured for the relevant flow. Service accounts, partner API keys, integration tokens and cloud role keys operate without that sign-in, and different questions apply to them: where they are stored, what permissions they carry, and how they are revoked and rotated.

Attack surface and confirming ownership

Before active testing it helps to map the actual attack surface: subdomains, public buckets, test environments, "forgotten" API versions. But discovering an asset does not mean it may be attacked. First confirm that it belongs to the client and that the client has the right to authorize testing. A domain that looks like yours may belong to a contractor, a former partner or a complete stranger. How to run that discovery and prioritize what it finds is covered in our article on external attack surface assessment.

Authorization and rules of engagement

Authorization is part of scope, not paperwork. Testing must be approved in writing by someone with authority over every system within the boundaries of the work. If some components are hosted by a cloud provider or operated by a contractor, their own testing rules may apply, and separate consent is sometimes required. Implied permission ("it's our service, after all") is not good enough.

The rules of engagement record exclusions, testing windows, conditions for an immediate stop, emergency contacts on both sides, and how data is handled: what testers may see, how evidence is stored, who can access it and when it is deleted. Evidence is best collected on a minimum basis — exactly as much as is needed for reproduction, with real personal data masked.

If the changed product paths are clear but the scope of work is not yet, that is easier to discuss before ordering. On the pentest scoping page you can describe the product, its roles and the environment constraints, and we will suggest which boundaries and what depth of testing are worth discussing.

Staging versus production: what carries over and what doesn't

Pre-launch testing is often done in a production-like staging environment with synthetic data. When that environment is genuinely isolated from production and external integrations, testers can create and delete objects and try risky scenarios without directly affecting real customers.

But staging results do not carry over to production automatically. Production may have a differently configured reverse proxy or WAF, different feature flags, different cloud role permissions and different library versions — while staging, conversely, may have checks switched off "to make testing easier". It pays to draw up a short list of differences in advance and decide which of them matter for security.

Sometimes it makes sense to follow a staging test with a narrow, agreed check in production — of headers, TLS settings and the reachability of service paths, for example — without any actions that could disrupt the service or change data.

Every conclusion in the report should be read with the qualifier "in this environment, with this access, in these scenarios". That is not a formality; it is the honest limit of what a test can claim.

Test depth: from black box to assume breach

Depth depends on how much the testers know. A black-box test resembles the view of an external attacker, but a large share of the time goes into reconnaissance. Grey box — with accounts for every role and API documentation — lets more of the available time be directed to authorization logic and business processes. White box, with access to source code and architecture diagrams, can reveal defects that may be out of reach from the outside within the days available.

Before launch the goal is to find as many serious defects as possible while fixes do not yet affect customers, so additional access can increase depth within the same testing window. Assume-breach scenarios work differently: testing starts from a pre-agreed "compromised" state, such as an ordinary employee account or access to a single container. That is useful for understanding how far an attacker could get. But such a test does not prove that the initial access was actually achievable — it assumes it.

Grey box matters especially for business-logic abuse: negative amounts, applying a discount twice, skipping a confirmation step, race conditions under concurrent requests. A conventional pattern-based scanner generally does not validate these problems: individual requests may be technically valid while the defect lies in the meaning of the action sequence. How they are tested is covered in our piece on business logic security testing.

Grounding the method: WSTG, ASVS and the Top 10

For applicable web checks of applications and HTTP APIs, the OWASP Web Security Testing Guide can provide a methodological backbone. It helps to ask the provider to show in advance which WSTG sections they will cover, which they will deliberately exclude, and why. Before the engagement, that list records intended coverage; after the engagement, the report and test record should separately show what was actually tested and what remained excluded. Record the version of the guide — 4.2, for instance — so that a year later it is clear which edition the work followed.

The OWASP Application Security Verification Standard (ASVS) is useful for a different reason: it describes verifiable requirements for security controls. In version 5.0.0, ASVS recommends referencing requirements with a version prefix, in a format such as v5.0.0-1.2.5, because numbering changes between versions. For applicable web controls, that makes ASVS a useful language for acceptance criteria: relevant findings and passed checks can be tied to specific requirements. Mobile, cloud, infrastructure and other work needs its own explicit criteria.

The same boundary applies here. A scoped test can support a requirement being met in the scenarios tested, but it does not make the product "ASVS-certified".

The 2025 edition of the OWASP Top 10 is an awareness document about the most critical web application risks. For a launch it is a floor, not a ceiling: a test that only checks the Top 10 headings is noticeably narrower than one built on WSTG and ASVS. And if the product includes a mobile client, LLM features or industrial components, those need their own methods — a generic web checklist will not replace them.

Where to spend limited time: weakness classes

Test time is always finite, and it is sensible to allocate it by defect classes that are both dangerous and plausible for your stack. MITRE published a 2025 edition of the CWE Top 25 Most Dangerous Software Weaknesses. The 2025 release was accompanied by the CWE Top 10 KEV Weaknesses, built from CISA's Known Exploited Vulnerabilities catalog, and the "On the Cusp" list of weaknesses that narrowly missed the main ranking.

This is easy to misread. CWE is a classification of weakness types, not an estimate of the probability that a particular product will be exploited. A class position reflects the methodology and source data of the particular list: published vulnerabilities and their scores for the Top 25, and classes represented in the Known Exploited Vulnerabilities catalog for the KEV list. It does not show that your product has the defect, the probability that it will be exploited or the frequency of attacks. Use the lists as one prioritization signal, not as a forecast.

In its Secure by Design alert series, CISA has discussed how to eliminate cross-site scripting, OS command injection and directory traversal at the class level, and together with the FBI it issued an alert on buffer overflow vulnerabilities. ASVS contains a requirement on protection against OS command injection.

The practical conclusion: the test scope should state explicitly how each of these classes will be checked for the real stack. If the product calls system utilities to convert uploaded files, test for command injection and path traversal. If the interface renders user-supplied HTML, test for cross-site scripting and the CSP. If the stack contains C or C++ code, look at memory safety, which CISA addresses in its material on memory-safe roadmaps.

Web and APIs: sessions, browser policies and secure defaults

HTTP as a protocol is stateless: each request is independent in itself. Session state is built on top of it — through cookies, tokens and server-side session stores. That is an ordinary, working design, and the protocol itself does not stand in its way.

But that is exactly why session management, token issuance and revocation, cookie attributes and authentication flows remain key testing areas for almost any web product and API. Errors arise not in the protocol but in how the application ties a request to a user and that user's permissions.

Browser security mechanisms are easier to configure before launch and awkward to introduce later, once integrations already depend on the old behavior. They need to be understood precisely, not by their names.

Content Security Policy defines where a page may load scripts and other resources from, and helps detect and mitigate cross-site scripting and data injection. CORS governs whether the browser lets a script from another origin read a response. It is not a server-side authorization mechanism: the request can still reach the API, and the server must check for itself who is asking for what. Cross-Origin Resource Policy lets a resource owner tell the browser not to hand the resource's content to pages from other origins on no-cors requests; it does not stop the request from being sent. Permissions Policy restricts page code's access to browser features such as the camera or geolocation.

You can check the baseline header configuration yourself, for example with HTTP Observatory, which MDN offers to developers and administrators. Do it before the engagement starts: correcting the baseline headers may leave more of the agreed time for authorization, tenant isolation and process abuse, although the provider should still verify in-scope settings.

CISA also expects products to be secure by default, with multi-factor authentication, logging and single sign-on available at no extra cost. A pre-launch test is a good moment to confirm that these defaults are actually enabled and working: the second factor cannot be bypassed through an alternative sign-in flow, the log records the actions of administrators and support staff, and the SSO integration does not accept someone else's assertions.

From planning to retest

NIST SP 800-115 is a technical guide to information security testing and assessment, published in 2008 and superseding SP 800-42. It describes the assessment phases as planning, execution and post-execution, with the latter covering analysis of findings, reporting and development of mitigation actions. The guide treats vulnerability scanning, penetration testing, security assessment and security examination as distinct activities.

That distinction is useful when buying. Automated scanning provides breadth and repeatability; manual penetration testing adds depth, an understanding of business logic and the ability to link small issues into a real attack path. The document is many years old, so its approach to planning is best combined with current web methodologies such as OWASP's.

On top of these phases it is convenient to build a practical cycle that stops the project from ending in a report with no consequences.

1. Planning and authorizationScope by changed product paths, written authorization from empowered owners, rules of engagement, stop conditions and release criteria — all before testing starts.
2. Test executionManual and automated testing against the agreed method in a production-like environment; critical issues are reported at once, not in the final report.
3. Analysis and reportReproducible evidence with minimal sensitive data, root cause, an applicable CWE class and, for suitable web controls, a reference to a versioned ASVS requirement.
4. Fix and retestThe team fixes root causes; the provider re-verifies the fixes under comparable conditions and records exactly what was retested.
5. Release decisionAn accountable executive signs off the launch, the list of accepted risks with remediation dates and the plan for the next test.

Two details of this cycle are easy to miss. The first is a channel for immediate reporting. If an authorization bypass is found on day two, the product team should hear about it the same day, not three weeks later along with the report. The second is the rule for destructive actions: anything that could disrupt the service or change data is allowed only with explicit permission in the rules of engagement.

Release-readiness criteria: blockers, exceptions and the risk owner

Readiness criteria must be defined before testing begins, not after the report arrives. Answer three questions in advance: which severity levels block the release; which issues may ship with a dated remediation plan and compensating controls; and who signs the decision.

CISA stresses that responsibility for product security should sit at the level of the supplier's top leadership. In practice, the organization designates a decision owner at the appropriate level in advance, and material residual risk is recorded and accepted by an authorized executive rather than left as a ticket quietly sitting in the backlog. NIST Cybersecurity Framework 2.0 does not prescribe penetration testing, but it helps fit test results into the wider risk management process — alongside governance, detection and response.

What the report should contain

For each finding, a useful report states the severity, the affected asset, reproducible steps and evidence, the root cause mapped to CWE where a suitable category exists, specific recommendations and, for an applicable web control, a versioned ASVS requirement or another technical criterion. Evidence should be minimal and de-identified: a screenshot with masked bank details may be sufficient when it preserves context and reproducibility; a full data dump is unnecessary for that purpose and adds risk. Agree in advance who gets access to the report and how long it is kept.

Fix root causes, not individual instances. MITRE notes that understanding common root causes feeds back into the development lifecycle and architectural planning. If the export did not check object ownership, the same pattern may turn up in other endpoints as well — so it is more reliable to fix the shared access-control mechanism than a single parameter.

Retesting and its limits

A retest confirms that specific blocking issues are closed under specific conditions. It should record which scenarios were repeated, on which build and in which environment. If a fix was verified in staging but a different build is rolled out to production, the conclusion that the issue is closed applies to staging. How to turn a retest into convincing evidence rather than a "fixed" checkbox is covered in our article on penetration test remediation validation.

Timing trade-offs and what happens after launch

The central tension is time. Test too early and you check features that will still change. Test too late and findings are left with no time for fixes. A practical approach is to test once the release feature set has stabilized, and to build a window for fixes and retesting into the plan before the release date. That is a planning decision, not a hard rule: a lighter check can be justified only after considering exposure, privileges, data, potential impact and the scale of change, not audience size alone.

A one-off pre-launch test is a snapshot of a single date. CISA's guidance on safe software deployment calls for release processes with robust testing and measurement components. After launch it makes sense to move on to regression checks of fixed issues, automated scanning in the pipeline and retesting after changes that genuinely affect security: a new role model, a new integration, a change of authentication mechanism, a newly exposed API.

That does not mean every commit needs a paid pentest. How to tie test scope to specific changes is described in our article on change-triggered penetration testing.

How to choose a pre-launch penetration testing provider

Once scope, depth and readiness criteria are defined, choosing a provider becomes simpler: every proposal can be compared against the same requirements. In its Secure by Demand guide, CISA encourages software buyers to ask suppliers concrete, verifiable questions; the same discipline works when buying security testing.

Ask each candidate for substantive answers. Which WSTG sections will be covered, and how are exclusions recorded? Will applicable web findings and passed checks reference versioned ASVS requirements, will suitable weaknesses be mapped to CWE, and which criteria will cover the rest of the scope? How are authorization, rules of engagement, stop conditions and emergency contacts handled? How are test data and any sensitive information found stored and deleted? Is a retest included, and within what time after fixes? What is the ratio of manual work to automated scanning? Can you see a de-identified sample report to judge the quality of evidence and recommendations?

Verify the team's qualifications and references independently rather than from marketing material. The warning signs are not hard to spot: a proposal with no discussion of scope, scanner output passed off as a pentest, a promise to declare the product "vulnerability-free", and vague answers about who authorized testing of each system.

If you want someone to have that conversation with, describe your product and constraints on the scoping page or see how penetration testing works at Pentest.red. We can discuss which boundaries, depth and evidence format make sense for your particular release. If your project needs a legally significant attestation or an auditor's compliance opinion, that is separate work requiring an appropriately qualified assessment, and a pentest does not replace it.

Conclusion: a release decision you can explain

A pre-launch pentest supports the release decision when it is built into the release process rather than bolted on in the last week. The scope follows the changed and risky paths in the product, authorization comes from those entitled to give it, the depth is chosen for the task, and priorities follow the weakness classes relevant to your stack. Where findings require action, the work continues through agreed root-cause fixes and retesting; the release decision separately records open issues, compensating controls and the authorized decision owner’s acceptance of residual risk.

Such a result is honestly bounded: it speaks about the environment tested, the access granted and the scenarios covered. But it can be explained to engineers, to leadership and later to customers — and that is what separates evidence from a claim of security.