An enterprise customer just sent you a security questionnaire.
Somewhere in that questionnaire is a question about tenant isolation, and the honest answer is that nobody has checked since the schema changed. I go through the platform properly and tell you where you actually stand.
| Signal | Severity | Usually means |
|---|---|---|
| Tenant isolation is a WHERE clause | High | One bug leaks everything |
| Engineers share a production login | High | No attributable access |
| Deal blocked on a questionnaire | High | Revenue is waiting |
| Secrets live in environment variables | Moderate | No rotation path |
| No written incident process | Unknown | You improvise under pressure |
Multi-tenancy is the boundary everything else depends on
Most SaaS platforms enforce tenant isolation in the application layer — a tenant ID on the query, applied consistently because everyone remembers to apply it. That works right up until one query is written without it, or a new endpoint ships on a Friday, or a background job runs outside the request context where the tenant ID lives.
The failure mode is not subtle. One customer sees another customer's data, and you find out from them. It is the single incident most likely to end a B2B contract, and it almost always traces back to a boundary that depended on discipline rather than structure.
Security questionnaires are asking about this, underneath the vocabulary. It is worth being able to answer honestly.
What I actually do
- Test tenant isolation by trying to cross it — including through background jobs, exports, webhooks and admin tooling
- Review IAM across the estate: who can reach production, how access is granted, and how it is removed when someone leaves
- Set up zero-trust access so reaching production is an explicit, attributable act rather than a VPN habit
- Get security review into the pipeline — secret scanning, dependency checks, a review step people can actually complete
- Work through the questionnaire with you and write answers that are true
- Write the incident response process before you need it, including who decides to tell customers
What you end up with
- A clear statement of where tenant isolation actually holds and where it depends on someone remembering
- Findings ordered by blast radius, each with the fix and a rough cost
- Questionnaire answers you can send without hedging
- An incident runbook short enough that someone will read it at 3am
How the work runs
| Stage | What happens |
|---|---|
| Week 1 | Architecture, data model and access review. Where are the boundaries, and what enforces them? |
| Weeks 2 to 3 | Testing: isolation crossing, access paths, pipeline gaps, secret handling. |
| Weeks 4 to 5 | Written findings, questionnaire support, and the fixes that cannot wait. |
| After | Re-test on anything rated high once your team has worked through it. |
Questions people ask
Is this a SOC 2 audit?
No — I am not an auditor and cannot issue a report. This is the engineering work that makes an audit survivable, which is a different and usually earlier problem.
We already have a pen test. Is this different?
Yes. A pen test probes the perimeter from outside. This looks at the boundaries inside the platform — tenant isolation, internal access, the pipeline — which an external test rarely reaches.
Can you help with the questionnaire itself?
Yes, and it is often the fastest value. Most questions have an honest answer that is better than the hedged one, and the ones that do not become your remediation list.
What if you find something serious?
You hear about it that day, not in the report. Anything that means live customer data is reachable gets escalated immediately, along with the quickest safe fix.