SaaS penetration testing: scope, prices and offers compared

By The PenTest Index · Offer terms checked October 8, 2026

SaaS penetration testing is an authorized attack on your own software product (web app, API, user roles and the walls between customers) that ends in a report for a customer or auditor. For one app, Astra publishes $5,999 a year with human testers and Pentest-Tools.com starts at $3,400 plus $900 per user role. Roles, API scope and retest date change the total.

Only use other companies' SaaS tools and were told to "pen test our SaaS"? Jump to testing a SaaS app you only subscribe to. Everything else here is for a product you build and own.

Below, we run six published offers against one example product and show which term rules each one in or out.

Which offers fit a typical SaaS product?

For our example, three offers are worth a written quote, one needs a contract change first, one does not fit, and one remains unresolved. The term that decides it is the date you can ask for fixes to be rechecked.

The example (made up, so you can compare your own product to it): Say you run a 30-person B2B SaaS. Customers use one web app. Your staff use a separate admin console on its own subdomain with its own login. One API serves the web app and a few partners. There are three user roles. Many customers share the same system, so one customer must never see another's data. A customer's security questionnaire asks for a penetration test done by people, not only by software. You will not share source code. Your team expects to have fixes ready 45 days after the findings arrive.

Offers are listed A to Z. This is not a ranking of testing quality.

All six rows are provider-published terms that we read on October 8, 2026. The dollar amounts are our arithmetic on those terms, not quotes. No provider has priced this example. Prices appear with the "$" sign each provider uses, so confirm currency and taxes in your quote.

One more offer comes up often. Intruder's AI web app pentest includes a "Connect your codebase" step in its workflow (pricing). If you will not share source code, ask Intruder whether it can test without repository access before you spend time on it.

Where we would start

For this example, ask three providers for a written quote: Cobalt, Pentest-Tools.com and Bright Defense. Each one covers something the others leave open.

• Cobalt is the only one of the six whose published recheck window covers day 45 if it falls within both the tier and contract cutoffs. What you do not know is the price. Ask how many credits your scope uses and what the full yearly commitment is.
• Pentest-Tools.com gives you a formula you can run yourself: $3,400 + (3 roles × $900) = $6,100 to start. What you do not know is whether your API and admin console are included, and how long you have to ask for the recheck.
• Bright Defense Elevate publishes a flat $5,250 with a role limit that matches the example's count. What you do not know is the recheck deadline, what counts as a "web endpoint" or "API endpoint," and whether the scope stays within 40 pages or modules.

Add Astra Pentest Expert if your fixes will land inside 30 days, or if Astra will extend the rescan window in writing. Also ask whether your admin console is a second target. In its DAST scanner target definition, Astra's pricing page says a customer dashboard and an admin dashboard with different login pages need two targets, and its help center says each subdomain you want tested on its own needs its own target (help article). Two targets is 2 × $5,999 = $11,998 a year.

Skip Astra Pentest Auto and Intruder's listed offer for this example. One is AI-run and the other needs your code. Both can be right for a different buyer.

Already have a provider? Put their offer through the same questions before you look elsewhere. See the section on existing tests.

Ready to ask for quotes? These go straight to each provider. We have no paid relationship with any of them.

View Cobalt pricing

View the managed web app test

View Bright Defense plans

View Astra pricing

How we checked this example

We call this a Purchase Check. We take one buyer's must-haves and hold each offer's published terms against them, one condition at a time.

• Fits means the published terms meet that one condition. It says nothing about how good the testing is.
• Mismatch means the published terms fail a must-have. That rules the offer out for this buyer unless the provider changes the term in writing.
• Unresolved means the provider's public pages do not answer the question. It is never treated as a yes, and never as zero dollars.

We read each provider's own pages. We did not buy any of these tests, and we did not ask providers for quotes. More on the method is on how the site works, and how we make money is on its own page.

What should SaaS penetration testing cover?

It should cover every way a signed-in user could reach something that is not theirs. A plain website test checks the front door. A SaaS test also checks whether one customer's key opens another customer's door.

That second part matters most. OWASP's guidance on multi-tenant apps warns that a single flaw can expose every customer's data (OWASP cheat sheet). Its list of top API risks starts with broken object-level authorization, which means a user changes an ID in a request and gets someone else's record (OWASP API1:2023).

Use this table to write down what your test needs to include.

Not every row is required for every buyer. Mark each one "must have," "nice to have" or "not applicable" based on what your customer or auditor asked for.

Accounts, roles, tenants and targets are four different things

Quotes go wrong when these get mixed up.

• An account is one login.
• A role is a set of permissions, like viewer or admin.
• A tenant is one customer's space inside your product.
• A target is the unit a provider bills by. Each provider defines it differently.

Here is a starting setup for the example. It is an illustration, not a minimum standard.

Seven accounts, three roles. If a provider prices per role, you pay for three, not seven. The second member in Tenant A lets a tester check whether two people with the same role can see each other's private items.

The same product gets counted in very different ways:

This is why two quotes for "the same" SaaS can be thousands of dollars apart. Send every provider the same written scope so their answers line up.

Does a web app test include your whole API?

Often only the part the web app itself calls. Cobalt's method page says its standard web tests include APIs that serve application content, and that deeper API testing needs a dedicated API test or a combined Web + API test. Astra counts "all APIs consumed" by the app inside one target. Pentest-Tools.com's web app page does not mention APIs at all.

If partners or a mobile app use operations that your web app never calls, list them. Otherwise they may never be tested.

Know your surfaces but not sure what to ask your customer, or how to line up provider answers? Find My PenTest Match has the scoping questions for a web app and its API, the questions for the person who will read your report, and a checklist you can copy or print. It is free and asks for no contact details. It does not pick a provider for you.

Find My PenTest Match

How much does it cost?

For the example above, the published starting amounts run from $5,250 to $11,998, and two offers cannot be totaled from public pages.

These are not like-for-like. One is a yearly subscription, two are single projects, and two use credits. The lowest number here is not "the cheapest SaaS pentest."

You will also see ranges on vendor blogs. Astra's cost article, for example, gives "$5,000 – $30,000 per pentest" for SaaS. That is Astra's own estimate of the market, with no scope attached. Treat ranges like that as a vendor's opinion, not a price.

Before you approve any quote, get these lines in writing:

Renewal deserves a second look on subscriptions. Astra's terms say services renew automatically unless you turn renewal off first, and that the remaining term is not refunded once a manual pentest has been used (Astra terms). Your signed order may differ, so read it.

Is a scan or an AI-led test enough?

Only the person who will read the report can answer that. Ask them before you compare prices, because the answer changes the whole list.

Three things get sold under similar names:

• A vulnerability scan is software checking for known problems. You usually run it yourself.
• An AI-led or autonomous test is software that tries attacks by itself. People may set it up or check the fixes afterward.
• A human-led test is people working through your product, usually with tools helping.

The labels blur. Here is a real case. Astra's article on SaaS pentesting lists its own price as "Starting at $1999/yr" (article). On Astra's pricing page, $1,999 a year is the Scanner plan. Pentest Auto is $2,999 a year and Pentest Expert is $5,999 a year. A buyer who budgets from the article has budgeted for a scanner.

So ask each provider one plain question: "In this offer, what do people do, what does software do, and who checks the findings?"

Be careful with promises about acceptance. Astra's pricing page says its reports are "recognized by all auditors." Intruder says it will refund the test in full if your auditor rejects the report. The first is a company's claim and the second is a refund policy. Neither is your auditor saying yes.

What does your customer or auditor actually require?

Less is written down than most people assume. Your contract or your auditor decides, so ask them directly.

SOC 2. The AICPA's criteria name penetration testing as one example of the kinds of evaluation a company may use. It appears in a "point of focus" under criterion CC4.1. The same document says some points of focus may not be suitable or relevant to every company (AICPA criteria, red-lined version). In plain terms, it is listed as an option, and your auditor decides what evidence they need from you.

PCI DSS. This one is specific, and it applies if you handle payment card data or could affect the security of a cardholder data environment. The PCI Council's self-assessment form for service providers calls for penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change. It asks that the tester be qualified and organizationally independent, and says the tester does not need to be a QSA or ASV. Service providers have extra duties, including testing segmentation controls at least every six months and after any changes to those controls or methods if segmentation is used to isolate the cardholder data environment from other networks, and one requirement applies only to multi-tenant service providers (PCI SSC form for PCI DSS v4.0.1). That form is for version 4.0.1, so confirm the current version and what applies to you with your QSA.

ISO 27001 and others. Ask your certification auditor what evidence they expect. We do not summarize a standard we have not read.

Customer contracts and questionnaires. Read your own clause. It usually says how recent the test must be, whether an outside party must do it, and what you have to hand over.

Send the person who asked this question:

"Will a report covering this app, this API, these roles and checks between customer accounts meet your request? Does the testing need to be done by people? And do you need proof that fixes were rechecked, or only the first report?"

We are not auditors, and nothing here is compliance advice.

Do you need permission from AWS, Azure or Google Cloud?

Usually not, when you test your own application. All three publish rules that you and your tester must follow.

The cloud company's rules are not your permission slip. Your written agreement with the tester has to name the systems and the activities.

Can you test a SaaS app you only subscribe to?

Only inside that vendor's written rules, and only on your own account. You do not own the product, so you cannot authorize a test of it.

Salesforce is a clear example. Since January 31, 2023, customers no longer need prior approval, but every test must follow Salesforce's Security Assessment Agreement (Salesforce notice). That agreement allows testing of your own accounts only, bars testing of Salesforce IP addresses, and limits automated testing to Friday 21:00 PST through Sunday 23:59 PST. If you hire a tester, the agreement requires prior written Salesforce approval for subcontracting, and you are responsible for what they do (agreement). Microsoft's rules likewise prohibit testing tenants you do not own without explicit permission.

For most teams the better route is this:

1. Ask the vendor for its own penetration test summary and SOC 2 report.
2. Test what you control: your settings, your user permissions, and the connections between the tool and your systems.
3. Read the vendor's testing policy before anyone runs a tool against it.

You may not need to buy anything.

How long does it take, and will the recheck fit your deadline?

Plan backward from the day your customer or auditor needs the report, and leave room for fixes and a recheck. Starting fast, finishing the test and getting the final report are three different dates.

Here is what providers say about timing. These are their estimates, not booked dates.

The recheck window is where deadlines slip. Two examples from published terms:

• Astra: the clock starts on the date vulnerabilities are reported. With a 30-day window, findings reported on March 1 must have their rescan requested by March 31. A fix that ships on April 14 is too late unless you get an extension.
• Cobalt: the window is 6 or 12 months, but it also closes 10 days before your contract ends. Say your contract ends December 31. Your last day to ask for a retest is December 21, at 23:59 UTC, even if your tier's window would have run longer.

A recheck looks at the fixes for findings already reported. It is not a fresh test of new features.

Get these five dates from any provider in writing: booked start, first report, your earliest and latest recheck request dates, and the day you receive the updated report.

Should testing happen in staging or production?

Pick the one your report reader will accept as the real product. Many SaaS teams use a staging copy that matches production, loaded with made-up data.

If you use staging, write down how it differs from production. Differences limit what the findings prove about the live product, and some customers will ask.

Give testers what they need to do the job:

• Two test customer accounts, so access between customers can be tried
• One login per role
• API documentation, if you have it
• Times when testing must pause, and a person to call if something breaks
• A list of outside services that must not be touched

Share passwords and keys through a secure channel you agree with the provider, never in the scope document.

Already have a test or a provider?

Then you may not need a new one. Check what you have against the request before you spend anything.

Ask yourself four things:

1. Does the existing report cover the app, API and roles your customer asked about?
2. Is it recent enough for them?
3. Have you added roles, API operations, SSO or a new way customers share data since then?
4. Do they need proof that the fixes were rechecked?

If the answers are yes, yes, no and no, send the report you have. If one area is missing, ask your current provider to quote only that piece. A test bundled with a compliance platform deserves the same four questions, plus one more: who did the testing, and what did the people do?

Copy a SaaS testing brief

Send every provider the same brief so their quotes answer the same question. Fill this in using your own document.

SaaS testing brief

Why we need the test, and who will read the report:
[Purpose. Who asked. Their exact request, if you have it.]

Our product:
[The application and environment we own and want tested.]

Web front ends and APIs:
[Each hostname. API operations used by the web app. Operations used only by partners or mobile apps. Anything not yet listed: write "Unknown, to confirm."]

Roles and customer accounts:
[Number of roles. Test accounts per role. Number of test customer accounts. Any sharing between customers that is meant to work.]

Workflows that must be covered:
[Sign-in and SSO. Invites. Permission changes. Sharing. Exports. Billing. Others.]

Access and environment:
[Staging or production. How staging differs. Documentation we can share. Whether source code will be shared. Access will be handed over separately.]

Other scope:
[Admin console. Cloud account settings. Mobile apps. AI features. Mark each: must have, nice to have, or not applicable.]

Report and dates:
[Who the report is for. Date the first report is needed. Date we expect fixes to be ready. Date proof of rechecked fixes is needed.]

Please itemize in your quote:
[What is included and excluded. What people do and what software does. Full price and currency. Taxes. Amount due now. Payment dates. Renewal terms. Recheck: how many, done by whom, when the window starts, the last day to request, and the cost after that. Who may see the report.]

What we already have:
[Any existing test, provider or quote.]

Open questions:
[Write "Unknown, to confirm" wherever an answer is missing.]

This brief is not permission to test. Testing needs written authorization that names the actual systems and activities. Do not put passwords, keys, customer data or details of known weaknesses in this document.

Copy SaaS testing briefPrint brief

Prepared with The PenTest Index: https://thepentestindex.com/saas-penetration-testing/

Common questions

How often should a SaaS company run a penetration test?

As often as your obligations and your product changes call for. If PCI DSS's penetration-testing requirements apply to you, the PCI Council's form says at least once every 12 months and after significant changes. If a contract sets a schedule, follow it. Beyond that, test again when you add roles, change sign-in, open new API operations or change how customers share data.

Is this the same as PTaaS?

No. PTaaS (penetration testing as a service) is a way of buying and receiving a test through an online platform, often by subscription. A SaaS company can buy its test as PTaaS or as a one-off project. You can compare both kinds of offer in our main comparison.

Can a bug bounty replace a penetration test?

Only if the person who asked for a penetration test says so. A bug bounty pays outside researchers for what they find, when they find it. It can produce a dated report on a defined scope, which is usually what a questionnaire is asking for. Ask the question from the requirements section.

We are five people with one customer asking. Do we need the full version?

Maybe not. Ask that customer exactly what they will accept, then scope to that. One web app with a handful of roles is a small test. Several of the offers above publish prices you can check today, and the brief will keep the quotes comparable.

Sources and check dates

We read each page below on October 8, 2026. Provider terms change, so check the live page before you buy.

The PenTest Index does not perform, authorize or certify penetration testing. None of these organizations endorses this site.