Penetration Testing for SaaS: A Practical Guide for Product Teams

by Rebecca Sutton

Penetration testing for SaaS is a controlled attack on your application, your APIs and your cloud setup, carried out by security specialists who try to break in before a real attacker does. If you sell software as a service, it is the most direct way to show customers that their data is safe with you. Most SaaS firms run one before a big enterprise deal, a compliance audit or a major release.

Engineers and product staff reviewing plans before penetration testing for SaaS scoping

This guide explains what penetration testing for SaaS covers, when to book one, what it costs you in time, and how to get a report that actually helps your sales team and your engineers.

Why does penetration testing for SaaS matter?

Three pressures push SaaS teams towards penetration testing, and most firms feel all of them at once.

  • Customer questionnaires. Larger buyers send security questionnaires, and “when did you last have an independent test?” is nearly always on them.
  • Compliance. Frameworks such as SOC 2 and ISO 27001 expect you to show that you check your own defences.
  • Shared risk. One flaw in a multi-tenant app can expose every customer at the same time. That makes your product a richer target than a typical company website.

The NCSC describes a penetration test as a method for gaining assurance in the security of an IT system by attempting to breach it, using the same tools and techniques as an adversary might. That is the right mental model. You are not buying a scan. You are hiring someone to think like an attacker.

What does penetration testing for SaaS actually cover?

A good scope follows the way your product is built. Here are the usual pieces.

The web application

Testers log in as a normal user, then try to do things they should not. They look for broken access control, injection flaws, weak session handling and logic errors. The OWASP Application Security Verification Standard, a free and open framework, is a common yardstick for this work. OWASP describes it as a basis for testing web application technical security controls.

The APIs behind it

Most SaaS products are really a set of APIs with a front end on top. The OWASP API Security Top 10 (2023 edition) puts broken object level authorization first, followed by broken authentication. In plain terms: can user A read user B’s records by changing an ID in a request? That question sits at the heart of tenant isolation, so API work deserves its own line in your scope. Our API testing service covers it in detail.

Tenant isolation

This is the SaaS-specific part. Testers create two or more customer accounts and try to cross the boundary between them, through the app, the API, file storage, exports and background jobs. Findings here are often the most serious in the whole report.

Cloud configuration and infrastructure

Storage buckets, identity roles, secrets in code repositories and exposed admin panels all belong in scope if they touch customer data. A test of the app alone can miss a misconfigured cloud account that hands over everything.

When should you book penetration testing for SaaS?

Timing matters more than most teams expect. These are the moments that make sense.

  1. Before your first enterprise customer signs, so you can answer the questionnaire with evidence.
  2. Ahead of a SOC 2 or ISO 27001 audit. Our guide to SOC 2 penetration testing requirements explains what auditors tend to ask for.
  3. After a major change, such as a new authentication system, a new API version or a move to a different cloud platform.
  4. On a regular schedule, commonly once a year, so the report never goes stale.

Test a stable build in a staging environment that mirrors production. Testing a half-finished feature wastes money, because the code will change before the report lands.

How do you scope penetration testing for SaaS without overspending?

Scope is where budgets go wrong. The NCSC advises involving risk owners, technical staff and the testing team to define the technical boundaries, test types and timeframe. For a SaaS firm, that means a short list of decisions.

  • Which apps, APIs and environments are in scope, and which are not.
  • How many user roles to test (admin, standard user, read-only, API client).
  • Whether you want a black box test with no inside knowledge, or a grey box test with test accounts and documentation. Grey box usually finds more for the same money.
  • Any no-go areas, such as third-party payment pages you do not control.

Give the testers good documentation, such as API specifications and a list of roles. Time spent working out how your product behaves is time not spent finding flaws.

How is this different from a vulnerability scan?

A scanner checks known issues quickly and cheaply. It will not notice that a customer can read another customer’s invoices by editing a URL. Human testers find those logic and authorization flaws. Scans are a good habit between tests, but they do not replace one.

Can you test continuously as you ship code?

Many SaaS teams release weekly or daily, so a once-a-year test covers only a snapshot. Two habits help. First, run automated checks in your build pipeline to catch the easy problems early. Second, schedule a short targeted test whenever you change something risky, such as login, billing or permissions. A full annual test then confirms the whole picture.

What should a SaaS test report give you?

You need two documents in effect: a technical report for engineers and a summary a customer will accept. A strong report ranks each finding by severity, shows how to reproduce it, and gives a clear fix. Read our piece on what a good test report looks like to judge one before you buy.

Good penetration testing for SaaS does not end at the report. After it comes the fix. Plan engineering time for it, and ask for a retest so you can show customers the issues are closed. Our guide to remediation and retesting covers that stage.

How do you choose a provider for penetration testing for SaaS?

The NCSC points to the CHECK scheme for qualified, experienced testers, and notes that the quality of a test depends heavily on tester expertise. CHECK is aimed mainly at government and public sector work, but the principle carries over. Ask who will actually do the work, what certifications they hold, and whether they have tested multi-tenant products before. Ask for a sample report. Be wary of anyone who promises a fixed result before they have seen your app.

If you want a scoped quote for your product, Aardwolf Security’s penetration testing team can help, and you can get in touch to talk through your setup.

Frequently asked questions

How long does a SaaS test take?

It depends on the number of roles, endpoints and environments. A focused app and API test often takes one to three weeks of testing, plus time for reporting. Your provider should give a firm estimate after scoping.

Do customers accept a summary instead of the full report?

Often yes. Many buyers ask for a short letter or executive summary, because the full report lists weaknesses you would rather not share widely. Check what your customers ask for before you commission the work.

Does Cyber Essentials cover this?

Not on its own. The NCSC says Cyber Essentials focuses on five technical controls: firewalls, secure configuration, security update management, user access control and malware protection. Cyber Essentials Plus adds independent technical testing, but it does not replace an application test of your product.

Is testing in production safe?

It can be, with care, but staging is safer. Agree rules up front about test accounts, data and timing so no real customer is affected.

Who should own the results?

Give one named engineer ownership of the findings list. Without an owner, reports tend to sit in a shared folder.

Subscribe to our newsletter

Honest updates, straight to your inbox. Unsubscribe any time.

You may also like