Your VDP covers a multi-tenant B2B analytics product: how do you scope tenant-isolation testing?
answer
- the test requires crossing the boundary
- two tenants the researcher owns
- synthetic data in trial accounts
- stop at first proof, minimise evidence
- accidental access still keeps safe harbour
basics
~10 sAuthorise isolation testing only between tenants the researcher controls: let them self-register a second trial account and probe across their own two. Real customer data stays out of scope, with an explicit stop-and-report rule.
solid answer
~50 sThe awkward part of isolation testing is that proving isolation fails means crossing it. Scope has to answer that before anyone touches the system. Authorise it, and give the researcher a safe way to do it: self-registered trial tenants, a documented naming convention for test accounts, synthetic data seeded in them. Then declare production tenants out of scope and write the stop rule — on the first record that proves a cross-tenant read, stop, capture the minimum evidence (one identifier, a redacted screenshot), do not enumerate, report immediately. Commit that a researcher who trips into real data in good faith and reports it at once keeps safe harbour; without that sentence the rational move is to keep digging quietly or say nothing. Exclude load testing, staff social engineering and the hosting provider. Ask for a marked user-agent or header so research traffic is distinguishable from an attack, and ask for deletion attestation for anything they did retain.
go deeper
Know that a policy's scope section lists which systems may be tested and which are off limits, and that other customers' live data is always off limits.
Explain how to make isolation testing possible without touching real data: self-registered second tenants, synthetic seed data, and an explicit rule about stopping at the first proof.
Show you have thought about the aftermath — evidence minimisation, deletion attestation, what you owe the affected customer, and keeping research traffic distinguishable from an attack so the on-call rota is not the first to react.
Frame scope as a threat-model decision the business signs off: you are choosing to invite an authenticated low-privilege attacker at the boundary that protects your customers' data, and deciding in advance what an accident there costs.
## The tension A multi-tenant B2B analytics product's most valuable security property is that tenant A cannot see tenant B's rows. It is also the property a researcher cannot verify without attempting exactly the thing you least want attempted. A scope section that says only "our production application is in scope, do not access other users' data" has forbidden the test and authorised nothing useful — so the researcher either skips your most important control or improvises, and you find out afterwards. Good scope is written so that the valuable test is possible **and** the blast radius is bounded. ## Make the test performable - **Authorise self-registration.** Say explicitly that a researcher may create additional trial tenants and that testing isolation *between tenants they control* is in scope. That single sentence turns the whole class of cross-tenant bugs from forbidden into welcome. - **Give them a convention.** Ask that test accounts use a recognisable prefix or a supplied tag. It costs the researcher nothing and lets your team tell research artefacts from real ones later. - **Seed the sandbox.** If trial tenants come with synthetic data that looks realistic, a researcher can prove impact — "I read a row belonging to a tenant that is not mine" — with no real person's data involved. - **Name the techniques.** Rate limits for automated scanning, whether the mobile client and the public API are included, whether they may test with a paid-tier feature enabled. Ambiguity here produces either timid testing or a support outage. ## Bound the damage Even with a sandbox, a researcher will sometimes land in a live tenant — that is often exactly what the bug does. Write the rule now: 1. **Stop at proof.** The first record that demonstrates the crossing is the finding. There is no additional value in the second thousand. 2. **Minimise evidence.** One identifier, a screenshot with values redacted, the request that produced it. Not a database dump. 3. **Do not enumerate, modify or delete.** Read-only, once. 4. **Report immediately**, and treat the details as confidential while the fix is prepared. 5. **Attest deletion** of any retained copy once you have confirmed the finding. And add the sentence that makes people comply: *if you follow this and report promptly, the accidental access stays inside safe harbour.* Punishing an honest report is how you train researchers to stay silent. ## Why evidence minimisation is your problem, not theirs If a researcher pulls five thousand rows from a real customer's tenant, you now hold a confirmed unauthorised access to that customer's data by an outside party. Your contract with that customer very likely requires you to tell them, and "a researcher did it with our permission" is a difficult sentence to say to an enterprise buyer. The narrower the evidence rule, the smaller that conversation. This is the practical reason scope and safe harbour must be drafted together: safe harbour cannot authorise access to data belonging to someone who never signed your policy, so scope must be built to avoid needing it to. ## Operational plumbing that scope should mention - **Traffic identification.** Ask researchers to include an agreed header or user-agent string. Otherwise the first competent tester pages your on-call at 3am as a live attack, and the second one gets their address blocked mid-test. - **Blocking policy.** Say what happens if protective controls block them — usually "tell us and we will work with you" rather than silently degrading their session, which just teaches them to evade the control and muddies your logs. - **Out of scope, explicitly.** Load and denial-of-service testing, social engineering of staff or customers, physical access, third-party services you merely consume, and any surface belonging to your hosting provider. Also list low-value finding classes you will not act on — missing hardening headers with no demonstrated impact, self-XSS, version-disclosure banners — so both sides stop spending time on them. - **Pivot rules.** A researcher who gets into one tenant may find they can reach your build or admin surfaces. State whether that path is in scope and where to stop; "stop and report the first time you reach an internal system" is the usual answer. ## Judgment to demonstrate An interviewer is watching for whether you understand that scope is a *design* task with a threat model behind it: the attacker position you are authorising is an authenticated, low-privilege tenant, and the asset at risk is another customer's data plus the contractual trust that sits on top of it. Getting that pair right produces a scope section that invites the test you most need while keeping the researcher, the other tenants, and your own legal position out of trouble.
- A researcher reports they already pulled five thousand rows from a live tenant. What now?Treat it as a confirmed unauthorised access to that customer's data: fix the flaw, get a deletion attestation, preserve your own logs, and work out what you owe that customer under your contract with them. Then fix the policy — the volume happened because the scope section never told them to stop at one record. Do not punish the report; that only buys silence next time.
- How do you stop authorised research traffic from paging your on-call as an attack?Ask for an agreed header or user-agent string in the policy, and make sure whoever watches the alerts knows the convention and where the active-research list lives. State what happens if protective controls block a researcher — contact us — rather than letting them quietly work around the control, which corrupts both the test and your logs.
- Should the scope section list finding classes you will not act on?Yes. Naming the classes you consider low value without demonstrated impact — missing hardening headers, self-XSS, banner version disclosure — saves both sides time and prevents an argument at triage. Be honest that it is a prioritisation call, and leave the door open for a convincing exploitation chain built from one of them.
saying these in an interview costs you the question
- Forbids isolation testing outright, then wonders why nobody finds those bugs
- Authorises testing against real production tenants
- Has no rule for what a researcher does after the first cross-tenant read
- Withdraws safe harbour from someone who honestly reports accidental access
- Never considers that pulled customer data creates obligations to that customer
- Leaves scanning rate and research traffic identification unstated