In this guide 6 sections
Buy a penetration test first when the system is live and the source is out of reach. Buy a secure code review first when you own the source and plan to keep building on it for years. For a handover, do both: review, then test.
What each one looks at
A secure code review reads the source. A reviewer follows data from input to database. Login, sessions and permissions get a close read, along with hard coded keys and outdated libraries that the running app never shows. Tools help, but a person judges what matters. Static analysis tools such as Semgrep flag patterns, yet a person judges which pattern is a real hole.
A penetration test attacks the running system from outside. It behaves like a hostile user. The tester probes forms, APIs, file uploads and login flows, then chains several small weaknesses into one real way in that a scanner would never connect on its own. Think of a burglar trying every window.
They answer different questions. One asks how the code is built. The other asks what an attacker can do today.
Custom app with the source in house
If your team or a vendor wrote the app and you hold the repository, start with the code review. Fix first. Flaws cost less to fix in the editor than after release; a reviewer can read the permission checks line by line, where a black box test only samples them.
Follow with a penetration test before a major launch. It proves the fixes hold in the deployed environment, where reverse proxies, TLS settings and cloud firewall rules change the picture. Expect the tester to ask for two accounts per role, one admin login and a list of the third party services your app calls.
Small budget? Review the riskiest modules only. Start with login and payments. Say which ones in the brief.
- Authentication and password reset code
- Authorization checks on every route
- Payment and webhook handlers
- File upload and export features
Bought package or hosted product
With a package you do not own the source. A code review is usually impossible. A penetration test of your own installation fits better. It covers your configuration, your plugins and your user roles. Plugins from a marketplace are a frequent weak spot, and so are default admin URLs and unchanged setup passwords.
Define the scope with the vendor’s written consent, because many hosted products forbid testing without notice and may block the tester’s address mid way. Ask for their own test reports too. They are no substitute for yours. Staging copies are a safer target.
Send anything found back to the vendor with exact steps. They hold the only copy of the fix.
App about to be handed over, or live without source
Before a handover you inherit every flaw the old team left behind; run the code review first, because it exposes hard coded secrets, dead admin routes and copied snippets. Then test the staging build. Do not skip it.
For a live system whose source was lost or sits with a former vendor, the test is your only lens. Pair it with a review of the server and cloud settings, which stay readable even when the source does not, covering open ports, storage permissions and admin accounts. Cloud audits look at storage buckets, security groups and who holds the root account.
Whatever you find, record it in a register. A handover without one leaves the next owner blind. The register lists each finding, its owner and its status.
- Handover: review first, test second
- Live, no source: test plus configuration audit
- Pre launch: test on a staging copy
- Merger or vendor change: both, with a findings register
A simple way to decide this week
Ask three questions. Do you hold the source? Is the system live to customers? Is a launch or handover due within the quarter? Source held with a launch ahead points to review. Live with no source points to a test.
Unsure? Ask the provider for a short scoping call and a written scope for each option, naming the modules, roles and environments covered. Compare what each covers. Note what it leaves out.
Write down your three answers. Send them with your request for a quote. A clear brief gets a clear quote.
First security engagement chooser
A single page decision sheet. The top block asks four yes or no questions: source held, system live, launch or handover within a quarter, vendor consent to test. The middle grid maps each pattern to review, test or both. The bottom block lists scope notes, the modules to review, the environments to test and the report format you require, such as a PDF plus a spreadsheet of findings.
Open a blank worksheet to printQuestions owners ask
Is a vulnerability scan the same as a penetration test?
No. A scan runs automated checks for known issues. A test adds a human who judges real impact.
Can one provider do both?
Yes, and it helps, since review findings guide the test. For independence, some owners prefer different people for each.
What do I receive at the end?
A written report with findings, evidence, severity and fix advice. Ask for a retest to be included.
How often should we repeat them?
After major changes and before big launches. Repeat both yearly for systems that hold customer data.