TL;DR
A vulnerability scan is software checking your systems against a list of known weaknesses: outdated packages, missing patches, open ports, common misconfigurations. It runs in minutes, costs little or nothing, and you run it continuously. A penetration test is a person, usually an outside firm, trying to break into your product the way an attacker would, chaining flaws the scanner cannot see: broken authorisation, logic errors, insecure workflows. It takes one to three weeks, costs a startup roughly $5,000 to $25,000, and you do it once a year or before a major release.
They are not alternatives. A startup needs scanning from the first deploy and a penetration test at the point where someone else requires proof: the first enterprise security questionnaire, the SOC 2 observation window, or a regulator. Paying for a pen test before the scanner is clean is paying a specialist to find things a free tool would have found.
The part that matters for a founder building now: most of what a first pen test finds on an MVP is decided in the first two weeks of the build. Get those decisions right and the first test is short and cheap. Get them wrong and the test report becomes a rebuild list.
Scan versus test, in one paragraph
Both look for weaknesses in the same system. The difference is who is looking and what they can find.
A vulnerability scan is automated. A tool compares what it can see (your dependencies, your containers, your cloud configuration, your public endpoints) against a database of known vulnerabilities and known-bad settings, and produces a list ranked by severity. It finds what is already catalogued. It cannot find a flaw in how your product works, because it does not understand what your product does.
A penetration test is manual, or manual-led. A tester with credentials for your app spends days trying to do things they should not be able to do: read another customer’s data, escalate a normal account to admin, bypass a payment step, abuse an API in a way the UI never would. They use scanners along the way, but the findings that matter come from a human reasoning about your specific product. The output is a report of what they got into, how, how bad it is and what to change, followed by a retest once you have fixed it.
Everything else follows from that: scans are cheap, fast, repeatable and shallow; pen tests are expensive, slow, periodic and deep. A mature company runs both. A startup needs to know which one is being asked for, by whom, and when.
What each costs a startup
The ranges below are for a single web or mobile product on one cloud provider with an API, which is the MVP case. Larger scopes, multiple products or a mobile app plus a web app push the pen test figure up.
| Vulnerability scanning | Penetration test | |
|---|---|---|
| Who does it | A tool, on a schedule | An outside firm or a platform’s vetted testers |
| Typical cost | $0 (dependency and cloud-native scanners) to $3,000 to $10,000 a year for a commercial scanner across your stack | $5,000 to $25,000 for a startup-sized web app and API; $4,000 to $8,000 for a lightweight platform test; $30,000 and up for multiple apps or a longer engagement |
| Time | Minutes per run; set up in a day | 1 to 3 weeks of testing, plus a week for the report, plus a retest |
| Frequency | Continuous, or at least on every deploy and weekly | Annually, before a major release, or when required |
| Output | A ranked list, often hundreds of items, with false positives | A short report: what was exploitable, how, severity, fix, then a retest letter |
| What it satisfies | The “do you scan for vulnerabilities” question; SOC 2’s monitoring criteria; PCI’s quarterly scan requirement | The “date of your last third-party penetration test” question; SOC 2 auditors’ expectation; PCI’s annual test requirement; most enterprise procurement |
| Internal time | Someone triages findings, an hour or two a week | A founder or lead engineer scopes, answers questions, fixes findings: a week or two of interrupted work |
Two things in the table decide the strategy. First, scanning is close to free, so there is no reason not to have it running from the first deploy. Second, the pen test’s real cost is not the fee; it is the engineering time to fix what it finds, and that cost is set by how the product was built.
What a first penetration test costs a startup, by product shape
The vendor quotes that founders describe as “all over the place” are not random. A penetration test is priced by scope, and scope is the size of the surface a tester has to cover: how many endpoints, how many roles, how many tenants, how many integrations, and whether there is a mobile app as well as a web app. Those are architecture decisions, which is why two startups with the same revenue get quotes that differ by three times. Typical 2026 ranges for a first test, grey box with credentials, retest included:
| Product shape | Typical first-test quote | What drives it |
|---|---|---|
| Single web app plus API, one or two roles, one tenant | $4,000 to $9,000 | Under 50 endpoints, one authentication path; a platform-based test sits at the bottom of this range |
| Web app plus API, multiple roles, multi-tenant | $8,000 to $18,000 | Authorisation testing across roles and tenants is the slow part; every role multiplies the work |
| The above plus a mobile app | $12,000 to $25,000 | Mobile is a separate test: the binary, local storage, the mobile API surface |
| The above plus third-party integrations, webhooks, a public API for customers | $18,000 to $35,000 | Each integration is another trust boundary; a public API is a product in itself |
| Cloud configuration review added to any of the above | plus $3,000 to $8,000 | Accounts, IAM, network, storage; usually worth adding once, before SOC 2 |
What doubles a quote: a second application, a second technology stack, white-box source review, or a compliance-specific report format. What does not: your revenue, your team size, or your industry, except where a regulator sets the scope. What makes a quote come in at the bottom of its range: a small, well-organised surface, credentials and a walkthrough ready on day one, and scanner findings already cleared. Most of that is decided when the product is built, which is the point of the section below on what a first test usually finds.
Two rules for reading a quote. A fixed price with a retest included is the normal shape; a day-rate estimate without a cap is not. And a quote far below the ranges above is usually an automated scan with a report written around it, which is worth having but is not what a customer or auditor means by a penetration test.
Who asks for which, and when
This is the question behind the search. Nobody buys a pen test for fun; something forces it. Here is what forces each, in the order a startup meets them.
The enterprise security questionnaire
The first time most founders hear the word “pen test” is in a spreadsheet from a prospect’s security team. Standard questionnaires (SIG, CAIQ, or a company’s own) contain two lines that map to this post: “Do you perform vulnerability scanning, and how often?” and “When was your last third-party penetration test, and can you share the summary?” The first is satisfied by having a scanner running. The second is not satisfied by anything except a pen test report, or a signed engagement letter with a date if the test is in progress.
For a B2B startup, that questionnaire typically arrives with the first prospect over a few hundred employees, which is usually months after launch. That is the deadline for the first pen test, and it is a deadline you can see coming.
SOC 2
SOC 2 does not contain a line that says “you must have a penetration test”. What it contains is criteria around monitoring for and responding to vulnerabilities, and in practice every auditor treats an annual third-party pen test plus continuous scanning as the way a company demonstrates them. If you are running a SOC 2 observation window, the pen test needs to happen inside it so the report is evidence for the period. SOC 2 for an MVP covers what else the window needs; Type 1 vs Type 2 covers when the window should start. The pen test is usually the single largest external cost inside that window.
Regulated products
PCI DSS, for anything that touches card data directly, requires quarterly external scans by an approved vendor and an annual penetration test. Most fintech MVPs avoid this by never touching card numbers (a payment provider holds them), which shrinks the requirement to the provider’s questionnaire. HIPAA requires a risk analysis rather than a pen test by name, but a pen test is the standard way a healthtech startup evidences that the technical safeguards work, and hospital systems ask for one regardless of what the law says. HIPAA compliant MVP has the detail.
Investors and acquirers
Rarely at seed. Occasionally at Series A as part of technical diligence. Always at acquisition. Not a reason to buy one early, but a reason to keep the reports.
Which one a startup needs first
The honest answer for almost every startup is “both, in this order”, and the order is what matters.
Scanning first, from the first deploy. Dependency scanning in the repository, image scanning in the build pipeline, configuration scanning in the cloud account. All three have free tiers or are built into the platforms you already use. They take an afternoon to switch on and they catch the category of problem that causes most real breaches at small companies: a known-vulnerable library nobody updated, a storage bucket left public, a database reachable from the internet.
Fix the criticals before anyone tests you. A pen tester who spends day one finding that your admin panel has no MFA and your API accepts requests without a token has been paid a specialist rate to read a checklist. Clear the scanner, enforce the basics, then hire the human for the things only a human finds.
Pen test when someone needs the proof, and not before the product has settled. The two triggers above (a questionnaire or an audit window) set the date. But there is a second condition: a pen test on a product whose authorisation model changes every week is a report about last week’s product. If you are still reshaping how accounts, roles and tenants work, wait until that is stable, or the first thing you will do with the report is argue about whether the findings still apply.
Then annually, or after a major change. A new authentication system, a new public API, a new tenant model or a new payment flow each deserve a test. Otherwise once a year, timed to land inside the SOC 2 period.
What a first pen test on an MVP usually finds
This is the section only a build shop can write, and it is the reason the decision above is a build decision. Across first pen tests on products built in eight to twelve weeks, the findings cluster into a short list. Nearly all of them are decided in the first two weeks of a build, when the account model, the API conventions and the deployment are set up. On an app built with an AI tool the list is even more predictable; vibe coding security covers the eight holes and how to check them before paying for a test.
| Finding | What it looks like | When it was decided |
|---|---|---|
| Broken object-level authorisation | Change an ID in a URL or API call and read another customer’s record | When the first endpoint was written without a “does this user own this object” check, and every endpoint after it copied the pattern |
| Missing or weak MFA on privileged accounts | Admin console or cloud root behind a password alone | First week, when the identity provider was or was not set up |
| Secrets in the repository or the image | API keys, database passwords, signing keys in code, config files or Docker layers | The first time someone needed a key to work locally |
| Missing rate limiting | Login, password reset, OTP and invite endpoints that can be hammered | When the API framework was configured |
| Verbose errors and debug modes in production | Stack traces, internal hostnames, ORM queries in error responses | When the production configuration was copied from development |
| Over-permissive CORS and open redirects | Any origin can call the API with credentials; login redirects to any URL | When the first front end was connected to the API |
| Role escalation through the client | The UI hides the admin button, the API does not check the role | When role checks went into the front end instead of the server |
| Insecure file handling | Uploads with no type or size validation, served from the app domain | When the first upload feature shipped |
None of these is exotic. All of them are cheap to prevent and expensive to find later, because by then the pattern has been copied across fifty endpoints. A product built with a server-side authorisation check on every object access, a managed identity provider with MFA from day one, secrets in a vault, rate limits at the gateway and a production config that is not a copy of development will produce a short pen test report. That is the same set of week-one decisions that make SOC 2 cheap and a product production-ready; security, compliance and reliability are mostly the same decisions viewed from three sides.
This is different from MVP testing in the QA sense, which asks whether the product does what it should. A pen test asks what it does that it should not.
How to buy a first pen test without wasting it
Short, because the compliance sites cover vendor selection at length and it is not the point of this post. The parts that matter for a founder buying one for the first time:
- Scope it to what the customer will ask about. The web app, the API and the cloud configuration behind them. Not the marketing site, not the internal admin tool nobody outside can reach, unless the questionnaire names them.
- Grey box, with credentials. Give the testers accounts at each role (a normal user, an admin, two different tenants). A test without credentials is a test of your login page; the findings that matter are on the other side of it.
- Ask for a retest in the price. The deliverable a customer wants is the letter saying the findings were fixed, not the report saying they existed.
- Time it inside the audit window if you have one. A report dated two weeks before the SOC 2 period started is not evidence for the period.
- Budget the fix time, not just the fee. Block a week of engineering after the report lands. If the build was done well, you will not need it; if it was not, you will need more.
- Keep the report and the retest letter. They get sent to every prospect for the next twelve months, and to the next auditor.
If the product was built by an outside team, the development contract should say who fixes pen test findings in the first months and on what terms; it is one of the clauses founders most often wish they had.
When the advice above does not apply
Products that never expose an attack surface. An internal tool on a private network with ten users may reasonably run scanning only, until something changes.
Products that handle card numbers directly. If you store, process or transmit card data yourself rather than through a provider, PCI DSS sets the schedule and it is stricter than anything here: quarterly approved scans and an annual test are not optional. The cheaper path is to not touch card data, which most MVPs can arrange.
Products whose value is security. If you are selling a security product, a pen test before launch is table stakes, because your first prospect’s security team will do one anyway.
A product that has not settled. Repeated above because it is the mistake founders make most: paying for a test on a product that will be rearchitected next month.
Conclusion
A vulnerability scan is a tool checking for what is already known to be broken. A penetration test is a person finding what is broken about your product specifically. A startup runs the first from the first deploy because it is close to free, and buys the second when a customer or an auditor needs proof, typically with the first enterprise questionnaire or inside the first SOC 2 window.
What the first pen test finds is mostly decided in the first two weeks of the build: authorisation on the server, identity with MFA, secrets out of the repo, rate limits, production config. Get those right and the report is short, the fixes take a week, and the customer gets their retest letter on time. Get them wrong and the report is a rebuild list.
If you are building a product you expect to sell into companies that will send you a security questionnaire, that is a scoping conversation we have regularly as an MVP development company: the goal is a first version whose first pen test is boring. Start it here.
Related guides
- SOC 2 for an MVP
- SOC 2 Type 1 vs Type 2
- HIPAA compliant MVP
- Production-ready MVP
- MVP tech stack
- MVP technical debt
- MVP testing
- How much does it cost to build an MVP
Frequently Asked Questions
What is the difference between penetration testing and vulnerability scanning?
A vulnerability scan is automated: a tool checks your dependencies, images, cloud configuration and public endpoints against a database of known weaknesses and lists what matches. A penetration test is human-led: a tester with credentials tries to break your product’s logic, finding authorisation flaws, logic errors and chained weaknesses a scanner cannot see. Scans are continuous and cheap; pen tests are periodic and cost a startup roughly $5,000 to $25,000.
Does a startup need a penetration test?
Not at launch. A startup needs vulnerability scanning from the first deploy and a penetration test when someone requires proof: the first enterprise security questionnaire, the SOC 2 observation window, or a regulator such as PCI DSS. For most B2B startups that moment arrives with the first prospect over a few hundred employees.
Does SOC 2 require a penetration test?
Not by name, but in practice yes. SOC 2 requires that you monitor for and respond to vulnerabilities, and auditors treat an annual third-party penetration test plus continuous scanning as the standard evidence. The test should be dated inside the observation period so it counts for that report.
How much does a penetration test cost for a startup?
Roughly $5,000 to $25,000 for a single web app and API at startup scale, depending on scope and the firm. Lightweight platform-based tests run $4,000 to $8,000; multiple applications or longer engagements run $30,000 and up. Budget a week of engineering time for fixes on top of the fee.
How much does vulnerability scanning cost?
Often nothing: dependency scanning in the code repository, image scanning in the build pipeline and configuration scanning in the cloud account all have free tiers or are built in. A commercial scanner covering the whole stack runs a few thousand to around ten thousand dollars a year.
How often should a startup do a penetration test?
Annually, timed to fall inside the SOC 2 period if you have one, and after any major change to authentication, the public API, the tenant model or a payment flow. Vulnerability scanning should run continuously, or at minimum on every deploy and weekly.
What does a penetration test find that a vulnerability scan does not?
Flaws in how the product works rather than what it is built from: reading another customer’s data by changing an ID, escalating a normal user to admin because the role check lives in the front end, bypassing a payment or approval step, abusing an API in ways the UI never does. A scanner does not understand your product, so it cannot find these.
Should I fix scanner findings before a penetration test?
Yes. A tester who spends the first day finding a known-vulnerable library or a public storage bucket has been paid a specialist rate to find what a free tool already reported. Clear the critical and high scanner findings, enforce MFA and basic authorisation, then buy the pen test for the issues only a human finds.
Is a vulnerability assessment the same as a penetration test?
No. A vulnerability assessment is a broader, usually scanner-led review that lists and prioritises weaknesses without exploiting them. A penetration test attempts to exploit weaknesses to show what an attacker could actually reach. Questionnaires that ask for a “third-party penetration test” mean the second.
What is usually found in a first penetration test of an MVP?
The same short list nearly every time: object-level authorisation gaps, missing MFA on admin or cloud accounts, secrets in the repository, missing rate limits on login and reset endpoints, verbose production errors, over-permissive CORS, role checks in the client, and unsafe file uploads. All of them are decided in the first two weeks of a build, which is why building them right is cheaper than testing them out later.
