Tenant Data Isolation Verification (QA)

Tenant Data Isolation Verification (QA)

1. 01

   Provision two synthetic tenant accounts with overlapping record IDs before any client demo

   Seed each tenant with a customer named the same string but different primary keys, then confirm the dashboard filters on tenant ID rather than on display name.

2. 02

   Log in as tenant A and attempt to reach tenant B's dashboard by editing the URL slug

   A 403 or empty state is acceptable; a rendered chart belonging to the other account is a release blocker, not a bug ticket.

3. 03

   Test row-level security at the query layer, not just the UI layer

   Platforms such as Qrvey and Luzmo expose tenant filters in their data models, so verify the filter is enforced server-side even when a user crafts a direct API call.

4. 04

   Confirm the embedded session token expires on the schedule written into the client contract

   Reveal and Sisense both issue short-lived embed tokens; document the actual TTL and compare it against the client's stated security policy before sign-off.

5. 05

   Run the isolation test again after every schema migration or connector change

   A renamed column in Snowflake or BigQuery can silently drop the tenant predicate, so re-run the two-tenant check as a standing regression step.

6. 06

   Record the test date, tester name, and platform version in the client's QA log

   When a client's own security team asks for evidence during procurement, a dated log entry answers the question in minutes instead of a rebuild.