Penetration Test Before Launch: A Go-Live Checklist

The best time is when the product is feature complete but not yet released: the login, payments, roles, integrations and settings all exist and behave the way they will in production. Testing before then covers a product that will change; testing after the date has been announced leaves no room to fix anything. Work back from your launch date and leave time for three steps: the test itself, your fixes, and a check that the fixes work. Agree the test dates when you scope the work, not after the build is done.

Use a staging environment that matches production in the ways that matter. The same software versions, the same server settings, the same login provider and the same firewall rules. A test against a thin development copy can miss a weakness that only appears with the real configuration, and it can report problems that production does not have. Keep the data fake: realistic test records, never customer data.

Name a build or release tag and hold it steady. If developers keep pushing changes during the test, findings stop matching the code and the report becomes hard to act on. Urgent fixes are fine, but tell the tester when each one lands so it can be checked. Our preparation checklist lists what else to have ready: test accounts for every role, API documentation, a named contact and a list of anything that must not be touched.

Settle this before the report arrives, when nobody is under pressure. A workable rule for most products is:

• Blocks launch: anything that lets one user reach another user's data, bypass payment, take over an account or run commands on a server.
• Fix before or soon after launch, with an owner and a date: weaknesses that need a specific condition or an existing account to use.
• Schedule normally: hardening advice, missing headers and low-impact findings.

Write the rule down and name who has the authority to accept a risk and ship anyway. That person should read the finding itself, not only its rating.

A product is more than its web pages. Include the API the mobile app calls, the admin panel, file upload paths, third-party integrations and the cloud settings behind it. Many launch problems sit in the part nobody thought to list. If the product has an app, see mobile application penetration testing; if it exposes endpoints to partners, add API security testing to the scope.

Reserve engineering time for the fixes before the test begins, and plan a check of the fixed items once they are done. A fix that is not checked is only a belief. Our article on what happens after the report explains how to run that step.

• Scope agreed in writing, including environments, roles and exclusions.
• Staging matches production; data is fake.
• Build frozen and test accounts verified.
• Release-blocking rules written, and a decision maker named.
• Time held in the team's plan for fixes and a check.
• Monitoring owners told when testing starts.

If a launch date is already set, tell us when you describe the scope so it can shape the plan. Start from our VAPT methodology or send an inquiry with the date and what ships.