Evidence that a VAPT vendor can test complex business logic and multi-tenant authorization appears before the engagement: the questions they ask, the models they build, the sample evidence they show and the effort they allocate. A capable provider will discuss objects, actors, state transitions, tenant ownership and privileged support paths—not only OWASP categories and scanner coverage.

The goal is not to find a vendor that claims to test “everything manually.” It is to verify that the team can understand your product rules, generate abuse hypotheses, compare identities systematically and prove business impact without exposing real tenant data.

What multi-tenant testing actually requires

Tenant isolation is more than changing an identifier in a URL. Data and actions may be exposed through search, exports, background jobs, caches, files, notifications, analytics, support tools and bulk APIs. Membership, invitation, ownership transfer and delegated administration can change which tenant context applies.

  • Horizontal checks between users with the same role in different tenants.
  • Vertical checks between customer, manager, support and administrator roles.
  • Cross-tenant membership and invitation transitions.
  • Object creation, transfer, sharing, export and deletion across tenant contexts.
  • Machine identities, integrations and jobs that operate for many tenants.
  • Caches, files, reports and notifications that may retain the wrong tenant context.

A provider should request enough accounts and synthetic tenant data to test these relationships. One administrator and one ordinary user rarely establish meaningful isolation coverage.

What business-logic testing actually requires

Business logic is the product’s intended rule set: who may perform an action, in which sequence, under what limit and with which resulting state. Testing therefore begins with workflow understanding. The tester should identify assets, invariants and prohibited outcomes, then vary identity, order, quantity, timing and state.

State and sequence

Can an approval be skipped, repeated or reversed? Can a cancelled object still be acted upon? Can a user call a later API step without completing the earlier control?

Limits and economic rules

Can credits, discounts, bookings, exports or quotas be replayed, raced or applied in the wrong context? Can client-side limits be bypassed through direct API use?

Cross-channel inconsistency

Do web, mobile, partner and internal APIs enforce the same authorization and state rules? Older or undocumented endpoints often preserve assumptions that newer clients no longer expose.

Evidence to request during vendor selection

  1. A redacted sample finding that demonstrates an authorization or workflow flaw with identities, preconditions and state.
  2. A proposed role-and-tenant matrix for your architecture.
  3. A description of how testers learn product rules and convert them into abuse hypotheses.
  4. An explanation of how automated tooling supports discovery without replacing manual reasoning.
  5. A safe evidence standard that avoids unnecessary access to real tenant data.
  6. A final coverage record showing tested combinations, sampling and limitations.

Look for precise, product-aware answers. Certifications, methodology logos and tool lists are supporting evidence, not proof that the assigned team can reason about your system.

Questions for the technical evaluation call

  • How many users and tenants do you need, and why?
  • How do you identify objects that are reachable outside the visible UI?
  • How do you test server-side authorization without relying on client controls?
  • How do you model state transitions and race conditions safely?
  • How do you examine support impersonation and delegated administration?
  • How do you handle GraphQL, bulk APIs, webhooks and asynchronous jobs?
  • How do you state untested combinations without implying full coverage?

What a strong answer sounds like

The vendor explains that it will map actors, objects and actions; establish the expected policy; create controlled identities in separate tenants; capture client and API behaviour; replay and modify requests; test alternate sequences; inspect secondary effects; validate impact with minimal data; and record which combinations were sampled. It also names constraints and asks how support or machine identities cross tenant boundaries.

A weak answer says the scanner will test IDOR, lists OWASP Top 10 and promises complete coverage with two accounts and a fixed short duration.

Use a practical evaluation exercise

For a high-value engagement, provide a sanitized architecture slice and ask shortlisted vendors to outline a test strategy. Do not share secrets or ask for free exploitation. Evaluate the questions, assumptions and coverage model they produce. A competent team will identify ambiguities and request the information needed to resolve them.

Meet the delivery lead or tester, not only sales. Confirm who performs the work, who reviews findings and whether the proposed effort matches the role and tenant matrix.

Red flags

  • The quote is final before roles, tenants, workflows or APIs are discussed.
  • “Manual testing” is defined only as a human running tools.
  • The methodology treats IDOR as a single endpoint check rather than a policy problem.
  • The provider needs production customer accounts because it has no synthetic-data plan.
  • Every SaaS application receives the same account count and duration.
  • The sample report hides coverage limitations or lacks reproducible evidence.

Connect OWASP to the product without becoming checklist-led

OWASP resources provide useful testing vocabularies. The OWASP Web Security Testing Guide includes authorization and business-logic areas, but the provider must translate them into your roles, tenant model, state and impact. The framework does not perform that reasoning on its own.

The practical decision

Choose the team that can demonstrate a repeatable way to learn product rules, model tenant policy, test identity combinations and produce safe, reproducible evidence. The best signal is not a claim of OWASP coverage; it is a product-specific coverage model with honest limits.

Ask WIMD to review your tenant and role model before finalizing a SaaS penetration-testing scope.