Multi-tenant SaaS VAPT is priced by the number of security boundaries that must be compared, not by one public hostname. A platform may contain customer workspaces, delegated administration, support tools, APIs, integrations, jobs and shared infrastructure. Each can carry tenant context differently.

The right budget starts with a tenant-and-authority model. Vendors should price the identities, object relationships, workflows and service paths that require evidence, while stating where risk-based sampling replaces full coverage.

Describe the tenant model precisely

State whether tenants represent companies, workspaces, projects, regions or resellers and whether objects can be shared or moved. Include parent-child and delegated-administration relationships.

A simple tenant ID check and a complex hierarchy are not equivalent. Ask vendors how many representative tenants and relationship states are needed to test isolation credibly.

  • Independent, parent-child and reseller tenants.
  • Shared, transferred and public objects.
  • Tenant creation, suspension and deletion.
  • Regional or data-residency partitions.

Build the role and delegation matrix

List tenant roles, platform roles, support roles and workload identities. Describe custom roles, groups and temporary privileges.

The cost comes from meaningful comparisons. A tenant administrator acting on its own user is different from a platform operator impersonating that tenant or an integration service editing many tenants.

  • Member, manager and tenant administrator.
  • Platform support and global administration.
  • Custom permissions and delegated access.
  • Service accounts and integration identities.

Inventory objects and authorization decisions

Identify sensitive object families such as users, invoices, files, secrets, reports and configurations. For each, state ownership, sharing and high-impact operations.

Vendors should explain whether they test every operation-object-role combination or sample by enforcement pattern. A low quote may assume one object proves all tenant isolation.

  • Read, update, delete, share and export.
  • Bulk and administrative variants.
  • Nested or indirectly related objects.
  • Search, analytics and reporting results.

Measure API and GraphQL breadth

SaaS platforms often expose UI APIs, public APIs, partner interfaces, GraphQL and internal services. Provide contracts and observed clients, then distinguish customer-supported from hidden routes.

One endpoint can contain many resolvers; many REST paths may share one control. Require a pricing explanation based on operations and authorization patterns, not an opaque endpoint multiplier.

  • Versions, methods and operation families.
  • Queries, mutations, fields and federation.
  • Bulk, export and file interfaces.
  • Deprecated and internal routes intentionally included.

Include identity federation and provisioning

SSO, SCIM, domain discovery, just-in-time enrolment and group mapping create tenant and privilege transitions. State supported identity providers and configuration variants.

Testing setup can require buyer-controlled directories and several accounts. Ask how vendor effort changes for multiple federation models and which configurations are sampled.

  • Tenant discovery and account linking.
  • Role and group mapping.
  • Provision, suspend and deprovision lifecycle.
  • Session and token effects after identity change.

Map integrations, webhooks and marketplaces

Connected apps may read or modify tenant data using OAuth, API keys, webhooks or embedded components. List first-party and third-party integration patterns, not every commercial partner.

Price representative authorization, installation, consent, token rotation, callback and uninstall tests. High-risk custom integrations may need separate specialist scope.

  • Installation and tenant-level consent.
  • Scope and token ownership.
  • Webhook authenticity, replay and tenant binding.
  • Uninstall, revocation and residual access.

Follow asynchronous and background work

Imports, exports, reports, notifications and provisioning may complete outside the initiating request. Tenant context can be lost in queues, workers or storage.

Ask vendors to trace selected jobs to output and verify identifiers, permissions, retries and cleanup. This requires observability and coordination that should be reflected in the quote.

  • Job ownership and status endpoints.
  • Worker identity and tenant propagation.
  • Output URLs and storage permissions.
  • Retry, duplication and stale privilege.

Test shared infrastructure assumptions

Shared caches, search indexes, object storage, logs and data pipelines can create cross-tenant exposure. Determine whether the engagement includes architectural and configuration evidence or only application behaviour.

Source- or architecture-assisted work may reveal systematic isolation risks more efficiently, but it adds reviewer skill and access. State the boundary clearly.

  • Cache and search partitioning.
  • Shared database authorization patterns.
  • Object storage and generated links.
  • Logs, analytics and support tooling.

Add production and customer-safety controls

A SaaS test can affect real tenants through email, jobs, rate limits or shared resources. Use designated test tenants, data, flags and monitoring, with explicit exclusions and stop authority.

Production-safe pacing can extend duration. A vendor that prices unrestricted automation against a staging clone may not be offering the service the buyer needs.

  • Isolated test tenants and synthetic data.
  • Resource and concurrency ceilings.
  • No interaction with real customer objects.
  • Immediate escalation and cleanup path.

Require SaaS-specific reporting and retest

Findings should name both attacker and victim tenant contexts, object relationships, route or service path and final effect. Coverage must show which roles, objects and patterns were exercised.

Retesting should verify the shared enforcement layer and representative variants. A fix to one route is not closure if the same tenant-context defect remains elsewhere.

  • Role-tenant-object evidence.
  • Systemic root-cause and variant mapping.
  • Coverage constraints and sampled families.
  • Cross-path retest acceptance criteria.

Normalize total cost to closure

Break quotations into base platform, API or GraphQL, SSO, integrations, internal services, architecture assistance, reporting and retest. Add tax, options and likely scope-change units.

Score the proposed team’s SaaS authorization capability before price. Cheap coverage that cannot distinguish tenant ownership from user authentication is false economy.

  1. Freeze a representative tenant and role matrix.
  2. Identify critical objects, workflows and integrations.
  3. Compare full coverage, sampling and exclusions.
  4. Calculate assessment plus expected closure cost.

Use a boundary-based budget model

Estimate repeated work by enforcement pattern: identity-to-tenant, tenant-to-object, role-to-function and service-to-service. Add unique workflows, integration types and shared stores.

Use the model to negotiate coverage deliberately. If budget is constrained, preserve the highest-impact cross-tenant hypotheses and document reduced assurance elsewhere.

Use the OWASP API Security Top 10 2023 for authorization and resource-risk themes, the OWASP ASVS for application control objectives and NIST SP 800-115 for assessment planning. Obtain current vendor quotations against the documented SaaS boundary model.

Price the isolation problem the platform actually has

Multi-tenant SaaS assessment cost becomes defensible when roles, objects and service paths are visible. A hostname or screen count hides the work that protects one customer from another.

WIMD scopes SaaS VAPT through tenant relationships, delegated authority, APIs, integrations, asynchronous jobs and shared infrastructure so quotations express real isolation assurance.