What should you check before launch?
Your launch date is getting closer. The product works, the team has tested the main journeys, and customers are ready to use it. One question still needs a clear answer: what evidence do you have that their accounts and information are protected?
Start with access controls, sensitive data, deployment settings and a plan for responding when something goes wrong. Then test the risks specific to your product, fix the findings that matter and verify those fixes. A useful security review gives the person approving release an understandable decision, including what remains unresolved.
This is our practical starting checklist for a product team. Adapt the scope to the data you hold, your architecture and the consequences of failure.
1. Agree what the review covers
List the web app, mobile apps, APIs, administration tools and external integrations. Include different user roles and the systems holding customer data. Record the release being assessed so the findings can be connected to what you actually deploy.
Agree who authorises testing, which environments can be tested and when testing must stop. Use synthetic customer records wherever possible. For production work, agree safeguards with the people responsible for the service.
Use OWASP ASVS to help select verifiable application security requirements. State the version and scope in the assessment. It gives your team a shared reference for what needs evidence.
2. Check what each person can access
A successful login is only the beginning. A customer should only reach their own records, and a support account should only have the permissions its work requires. Enforce those decisions on the server for every relevant request, including requests made directly to an API.
OWASP recommends least privilege, denying access by default and validating permissions on every request. Build checks around the actual relationships in your product. See OWASP’s authorisation guidance.
- Test access between two customer accounts and, where applicable, two organisations.
- Check what happens after a role changes or an account is disabled.
- Review administrator access and account recovery with the same care as login.
3. Follow sensitive data through the system
Trace a typical customer request from the browser or app to the API, database and third-party service. Identify where personal information and credentials are stored, copied or logged. This often makes the review easier to explain to both engineers and the business owner.
Keep service secrets out of frontend bundles and source control. Limit each credential’s permissions, separate environments and establish how credentials are rotated or revoked. If a credential has been exposed, removing it from the latest file does not invalidate it: revoke or rotate it and investigate its use. OWASP’s secrets management guidance covers the credential lifecycle.
4. Combine scanning with a focused assessment
Dependency and configuration scans are useful inputs. Also review the workflows where your product makes consequential decisions: approving an action, sharing a document, changing account ownership or accepting a payment. A finding only becomes useful when the team can understand its impact and reproduce it safely.
The OWASP Web Security Testing Guide provides structured testing guidance. Agree which areas apply to your product and record any exclusions. For a mobile product, include the mobile clients and their APIs in the scope rather than assuming a web review covers them.
Request an executive summary, technical evidence, affected components, remediation guidance and an agreed retest. Set dates from the actual scope and available test access.
5. Make sure someone can see and respond
Decide which events need attention, who receives alerts and what they should do next. Useful security events can include denied access, changes to privileges and administrative actions. Protect the logs themselves and avoid recording credentials or unnecessary personal information. OWASP’s logging guidance explains the balance between useful evidence and sensitive data.
For your release plan, identify the person who can disable an integration, revoke access or roll back a deployment. Exercise a restore using a recent backup in an appropriate test environment. Record the result and how long recovery actually took.
6. Verify fixes and record the release decision
Give each finding an owner and a target date. Prioritise it using its technical severity alongside exposure, the data involved and the effect on customers. Retest the change and related behaviour before marking the finding resolved.
Our recommended release record is short: what was assessed, which version was tested, what was fixed, what remains open and who accepted the remaining risk. Keep monitoring and review ownership in place after launch; a review is evidence about a particular scope and point in time.
Questions product teams ask
Does a penetration test guarantee that a product is secure?
No. It can uncover weaknesses within an agreed scope and test window. Secure development, maintenance, monitoring and follow-up checks remain part of operating the product.
Does a VPN make an application secure?
A VPN can protect a network connection and restrict access to private services. Your application still needs its own authentication, authorisation, secure configuration and review.
When should security testing start?
Start discussing risks while architecture and product decisions are still being made. Schedule scoped testing early enough to fix and retest findings before release, and revisit the scope when important features or integrations change.
Need a clear view of your product’s risks? Explore CloudCoder’s security and testing services. We connect technical findings with practical engineering fixes and a plan for checking them.
