Security testing that ships with your product

You ship too fast to wait for a pentest

Manual engagements take 3–6 weeks from scoping to report. By the time findings arrive, the code has already shipped to a hundred customers.

Multi-tenant IDOR is your highest risk

One customer accessing another customer's data is the breach scenario that ends SaaS companies. It's also the vulnerability class automated scanners miss most often, so Penetrify's AI tests authorization systematically across every user role.

SOC 2 requires penetration testing evidence

Auditors want to see that you test regularly, not just once. Penetrify produces structured reports that satisfy SOC 2 Type II security testing controls, and the evidence trail grows with every scan.

CC6.1: Logical and physical access controls, including penetration testing evidence

A.12.6: Technical vulnerability management and security testing

Article 32: Regular testing of technical security measures

Articles 28–30: financial-entity customers must manage ICT third-party risk, which lands in your security questionnaires

Security Testing for a Fast-Shipping SaaS Without a Security Team

The honest starting point: you do not need a security team to get tested, you need testing that produces findings a developer can act on without translation. What sinks small teams is not the absence of a CISO, it is a 60-page PDF landing in a Slack channel where nobody owns it.

The sequence that works. First, scan production or a production-shaped staging environment once, authenticated, with credentials for every role you have. Fix the criticals — there will be fewer than you fear and they will be more boring than you hope, usually an authorisation check missing on an endpoint someone added in a hurry. Second, wire the same test into CI so a regression is caught by the pipeline rather than by someone remembering. Third, only then start caring about the medium findings.

What to skip until later: a vulnerability management platform, a formal risk register, and any tool that requires a dedicated owner to tune. If a control needs a person you do not have, it is not a control, it is a plan.

Enterprise-Grade Coverage With a Small Security Team

One or two security engineers supporting thirty developers cannot manually review every release, and hiring is not the fix — the ratio never improves fast enough. What changes the arithmetic is moving the repetitive part to automation and spending human attention on the parts that need judgement: threat modelling a new payment flow, deciding whether a finding is exploitable in your specific architecture, arguing for the refactor that removes a class of bug rather than one instance.

Practically, that means the pipeline owns regression testing and the humans own novel surface. A team of two can run a credible programme this way, and enterprise reviewers accept it when you can show the evidence trail: what was tested, when, what was found, what closed. That trail is easier to produce with continuous testing than with two engagements a year, because it accumulates on its own.

The failure mode to avoid is buying tooling that adds triage work. A scanner that reports 400 findings, 380 of which are informational, converts your two engineers into a filtering service. Validate what you buy against that: how many findings did it produce, and how many were actually true and actionable?

What SaaS Penetration Testing Costs, and What Drives the Number

A manual engagement against a SaaS application is commonly quoted at $15,000 to $50,000, and multi-tenancy pushes you up the range: every additional role and every tenant boundary is more scope. PTaaS platforms sell annual credit packages instead, with reported entry pricing around $8,500 and a typical web app engagement consuming 10 to 20 credits at roughly $1,800 each. Continuous platforms price as a subscription; Penetrify starts at $100 a month with retests included.

Three things drive your quote more than application size: the number of authentication roles you want covered, whether the API surface is documented, and how much of your functionality sits behind a paywall the tester needs access to. Handing over credentials for every role and an OpenAPI or GraphQL schema up front is the cheapest thing you can do to reduce a scoping estimate.

The mistake worth naming: buying one large annual engagement to cover a codebase that deploys weekly. You are paying premium rates for coverage of a single day, and the fifty other releases are untested. Split the budget — continuous coverage for cadence, a human engagement for depth and for the signature an enterprise contract may name.

How to Choose a Provider: Questions That Actually Separate Vendors

Skip the feature grid and ask these. Do you test as multiple authenticated roles, and will you attempt cross-tenant access explicitly? Anything less leaves the highest-severity class in SaaS untested. Is retesting included, or billed? A vendor charging for the verification of their own finding is charging you for their workflow. What do I get when you find nothing — a report saying so, or silence?

Then ask about output rather than process. Can I see a real redacted report, not a sample deck? How are findings delivered: a PDF, a dashboard, or into the tools my developers already use? What is your false-positive rate and how do you measure it? A vendor who cannot answer the last question is telling you they do not track it.

Finally, get the compliance answer in writing before you buy. Ask your auditor whether they require a human-led test with a named tester, and take the vendor answer that matches. Both exist for good reasons; buying the wrong one is an expensive way to discover which you needed.

Multi-Tenant Isolation: The Test That Matters Most and Gets Skipped

In a multi-tenant application, the single worst outcome is one customer reading another customer's data, and it is structurally invisible to unauthenticated scanning. A scanner without two accounts in two tenants cannot even formulate the test, which is why so many SaaS products pass a scan and fail a real assessment.

What thorough testing looks like: an object in tenant A is requested with tenant B's session, on every enumerable identifier and every export path; identifiers are swapped in nested payloads, not just URLs; shared infrastructure is probed for tenant leakage (cache keys, search indices, background jobs, webhook targets, file storage prefixes); and invitation, role-change and impersonation flows are tested for cross-tenant escalation, because support tooling is where the boundary is usually thinnest.

Row-level security helps and does not finish the job. A policy on the database does nothing for an endpoint that queries with a service role, and it does nothing for the report generator that builds a PDF from a tenant ID passed in a query string. Test the paths, not the policy.

SOC 2: What Auditors Actually Accept as Testing Evidence

SOC 2 Type II reports cover a period, typically 6 to 12 months, and that is exactly the trap for testing evidence: a single pentest report from one date does not demonstrate that your controls operated throughout the period. Auditors evaluating CC6.1 (logical access) and CC7.1 (vulnerability identification) increasingly ask what testing ran between the annual engagements and after significant changes.

A scan history is the strongest answer. Penetrify produces a timestamped, severity-ranked report on every run, so the evidence you hand your auditor is a continuous record across the audit window: what was tested, what was found, when it was fixed, and the retest that proves it. Teams that adopt this pattern stop scrambling before audits, because the evidence accumulates as a by-product of shipping.

One honest caveat: some auditors and enterprise customers still expect an annual test signed by a certified human tester. The pragmatic setup is continuous automated testing as the baseline plus one manual engagement a year; the automated history also makes that engagement cheaper, because the easy findings are already gone.

Selling to Banks? DORA Reaches You Through Your Customers

Since 17 January 2025, EU financial entities operate under DORA (Regulation (EU) 2022/2554), and its Articles 28–30 make them responsible for the ICT risk of their third-party providers, which is what you are if a bank, insurer, or payment institution runs on your SaaS. In practice this arrives as heavier security questionnaires, contractual audit rights, and requests for security testing evidence tied to their DORA obligations.

You do not need to run your own TLPT (that obligation belongs to designated financial entities themselves under Article 26), but you do need to show a credible, ongoing testing programme. A continuous pentest history answers the "how do you test, how often, show us" questionnaire section far better than a twelve-month-old PDF.

Add a single step to your GitHub Actions or GitLab CI pipeline. Penetrify scans every deployment automatically and fails the build if it finds a critical vulnerability. Security becomes part of your definition of done.

Penetrify tests authorization across multiple user roles and tenant boundaries: the exact attack surface that manual scanners and traditional DAST tools miss. IDOR in a multi-tenant SaaS is one of the most common causes of customer data exposure.

Every Penetrify scan produces a timestamped, severity-ranked report. When your SOC 2 auditor asks for penetration testing evidence, you can produce a full history of scans across the audit period, not just one document from a single engagement.

Penetrify starts at $100/month, less than an hour of manual consulting time. The Professional plan ($1,700/month) covers 20 scans, making it practical to test staging, production, and every significant feature branch.