Choose an application security testing company for a complex SaaS platform by testing whether it can reason about your architecture—not by counting certifications, scanners or pages in a sample report. The right provider should be able to map tenants, roles, APIs, asynchronous jobs, integrations and privileged support paths into explicit attack hypotheses, then return evidence that developers can reproduce and leaders can use.

Why complex SaaS needs a different vendor test

A brochure-style web application can often be described by pages and endpoints. A modern SaaS product is a relationship system. One person may belong to several organisations; the same role may have different entitlements by plan; a support user may impersonate a customer; an API may enqueue work completed by another service; and an integration may act with a long-lived token. Security depends on whether those relationships remain valid through every state change.

A provider that tests only unauthenticated inputs or isolated endpoints can produce a technically neat report while missing the failures that matter most: cross-tenant object access, privilege retained after a role change, replayed approval steps, unsafe exports, weak integration scoping, orphaned sessions and internal services that trust caller-supplied identity.

  • Tenant boundaries: same-role users in different organisations must not read, modify, export or infer each other’s data.
  • Role boundaries: administrators, operators, finance users, viewers, support staff and service accounts need different allowed actions.
  • Workflow boundaries: invitations, approvals, refunds, exports, account recovery and offboarding must preserve business invariants.
  • Channel boundaries: web, mobile, public APIs, internal APIs, webhooks and background jobs should enforce consistent decisions.

Prepare a one-page selection brief

Before speaking to vendors, create a concise brief that lets them show their reasoning without exposing secrets. Describe the product shape, the assurance decision, the desired environment and the constraints. Include approximate numbers of roles, tenants, interfaces and high-value workflows. State whether the result supports a launch, enterprise customer, regulatory programme or recurring security baseline.

  1. Name the business decisions the assessment must support. “Find vulnerabilities” is too vague; “demonstrate tenant isolation before enterprise rollout” is testable.
  2. Sketch trust boundaries and data flows. Identify identity providers, gateways, worker queues, storage, third parties and administrative planes.
  3. List representative identities and test data that can be supplied. Deep authorization testing is impossible with one account and one tenant.
  4. State safety constraints, approved hours, escalation contacts and prohibited actions. A mature provider plans around them instead of discovering them during testing.
  5. Define deliverables and closure: coverage record, findings, debrief, remediation support and independent retest evidence.

Ask candidates to reason through one realistic scenario

Give each shortlisted company the same anonymised scenario. For example: a platform has owner, analyst and billing roles; users can join multiple tenants; bulk reports are generated asynchronously; partners receive scoped API keys; and support can assume a customer context after approval. Ask how the first two days of testing would be organised.

A strong answer starts by asking what must always remain true. It proposes account pairs, tenant pairs, objects and state transitions; identifies browser, API and worker paths; and separates safe discovery from higher-impact validation. A weak answer immediately lists tools, promises complete OWASP coverage or treats the number of endpoints as the scope.

Listen for hypotheses rather than tool names

  • Can a member change an object identifier and cross a tenant boundary?
  • Can a user retain access after removal, downgrade or session refresh?
  • Can a support workflow bypass customer approval or create an unlogged privileged action?
  • Can an asynchronous export be requested by one tenant and fetched by another?
  • Can an integration token call capabilities that were never granted in the user interface?

Review the provider’s mapping against the OWASP Application Security Verification Standard and the OWASP Web Security Testing Guide. The useful question is not whether the logos appear in a proposal, but how controls become evidence in your product.

Verify manual depth before accepting the claim

“Manual testing” can mean anything from a human clicking a scanner finding to a practitioner modelling abuse across identities, timing and state. Ask to see a redacted finding that could not have been produced by a generic scan. It should show preconditions, identity context, request or workflow evidence, the violated security rule, impact, remediation direction and the boundary of what was proven.

Then ask who performs the work, who reviews it and how disagreements are resolved. Certifications may indicate study and baseline knowledge, but the proposed team’s SaaS experience, reasoning and communication matter more. Confirm whether delivery is subcontracted and whether a named reviewer remains accountable.

Inspect coverage transparency

No penetration test covers every possible state. Trustworthy providers make sampling visible. They record roles used, tenants paired, workflows exercised, APIs reached, limitations encountered and hypotheses deferred. This allows you to distinguish “no issue found” from “the path was not observable or accessible.”

  • An asset and interface inventory reconciled with the scope.
  • A role-and-tenant matrix showing representative relationship pairs.
  • A workflow list with normal, prohibited and edge-state tests.
  • A record of blocked, unavailable, rate-limited or excluded paths.
  • A limitation statement explaining residual uncertainty without hiding it.

Evaluate evidence and remediation usefulness

A finding should help the engineering team reproduce the unsafe condition and fix the control, not merely recognise a vulnerability name. Review a sample for clear steps, affected identity and tenant, observed response, business consequence, root-cause direction and safe retest criteria. Evidence should be sufficient but minimised so reports do not become a new store of sensitive data.

Treat operational safety as a technical capability

Complex SaaS testing can affect queues, notifications, metered services and customer-visible audit trails. Request written rules of engagement covering source addresses, test identities, data markers, rate limits, destructive actions, third parties, stop conditions and critical escalation. The provider should be able to explain how it will prove impact without creating unnecessary customer risk.

Also inspect evidence handling: encryption, least-privilege access, transfer method, retention, deletion, personnel locations and incident notification. A technically skilled tester operating through uncontrolled screenshots, personal storage or indefinite report retention is not a safe partner.

Compare proposals using gates and scored criteria

Use pass/fail gates for legal authority, confidentiality, conflicts, data handling and minimum delivery controls. Then score the remaining providers against architecture fit, manual depth, team quality, evidence, coverage transparency, communication, safety and retesting. This prevents a low price or polished presentation from compensating for a failed mandatory control.

  • Architecture fit: can the team reason about multi-tenancy, distributed services and identity lifecycles?
  • Testing depth: does the method include authorization, business logic, chaining and alternative channels?
  • Team: are the actual practitioners and reviewer suitable, available and accountable?
  • Outputs: will both engineers and decision-makers receive usable, bounded evidence?
  • Closure: are clarification, remediation consultation and retesting defined rather than left as sales promises?

Red flags that should pause the decision

  • A fixed test plan created before the vendor understands roles, tenants, workflows or architecture.
  • Claims of complete coverage, zero false positives or guaranteed absence of vulnerabilities.
  • A manual-testing claim supported only by a tool list or certifications.
  • One account requested for a system whose security depends on relationships between accounts.
  • Sample findings without reproducible evidence, limitations or a clear affected context.
  • Unclear subcontracting, uncontrolled evidence storage or no defined deletion period.

Make the final decision defensible

Select the application security testing company whose delivery model best matches the assurance decision and architecture—not necessarily the largest or cheapest provider. Preserve the selection brief, scenario responses, scorecard, exceptions and approval limits. For a strategic relationship, use a bounded pilot and judge scoping quality, safety, evidence and collaboration under real conditions.

WIMD approaches complex SaaS assessments as a set of trust relationships to validate. The engagement is shaped around identities, tenants, critical workflows, interfaces and lifecycle states; findings are manually validated and connected to developer-ready evidence; and closure requires a retest of the original condition plus meaningful nearby variants.