Enterprise security reviews pass faster when multi-tenancy, RBAC and audit trails are defaults rather than roadmap items. Dual7 builds schema-per-tenant isolation, data-layer access control and audit logging into every certified feature — so a security questionnaire points at what's already there.
What's on by default
- Multi-tenant Postgres with schema-per-tenant isolation and row-level security — the boundary is enforced by the database, not by remembering a WHERE clause.
- Role-based access control wired into the data model, not bolted on top.
- A security audit on every certified change at the Build stage, with mandatory human sign-off.
- Audit logs recording who changed what, when, and who approved it — no setup.
- Typed integrations with proper secret hygiene; credentials are never hard-coded.
Mapped to the questionnaire you'll actually get
Security reviews are questionnaires before they are conversations. Most of them walk the same ground — access control, isolation, logging, SDLC controls, the areas standards like the OWASP Application Security Verification Standard formalize. Here's how the defaults answer the usual asks:
| The questionnaire asks | The default answer |
|---|---|
| How is customer data isolated? | Schema-per-tenant Postgres plus row-level security — isolation enforced at the database layer, verifiable in the schema and policies you can read. |
| What is your access control model? | RBAC enforced in the data layer; roles and permissions live in the model, so UI bypass doesn't bypass authorization. |
| What gets logged, and for how long? | Every change records actor, timestamp and approver by default; logs ship with the app you own, so retention is your policy on your infrastructure. |
| What are your SDLC controls? | A staged pipeline with approval gates: reviewed spec, reviewed migrations, security audit on every build, mandatory human sign-off before release — see the seven stages. |
| How do you manage secrets? | Injected from environment/vault, never hard-coded or logged; integrations use typed clients. |
| Can we audit the code ourselves? | Yes — the full source exports as a standard repository, so your reviewers read the actual code, not a compliance summary. |
Built in, not bolted on
The difference between 'we support that' and 'that's the default' is the difference between a review that drags for a quarter and one that moves. Because Governed Mode produces these controls as part of how it builds, a security questionnaire is mostly a matter of pointing at what's already there.
And because you own the code, the buyer's team can verify it directly rather than taking your word for it. SOC 2 is in progress; the underlying posture is in place now. More on the program itself at security.
Every line traceable to where it began. Auditors get a graph, not a guess.
Frequently asked questions
What is multi-tenancy in SaaS?
Multi-tenancy is one application serving many customers (tenants) whose data must remain strictly separated. The strongest common pattern combines per-tenant schemas with database-enforced row-level security, so isolation holds even if application code has a bug.
What's the difference between RBAC and row-level security?
RBAC decides what a role may do (permissions on actions and resources); row-level security decides which rows a query can ever see, enforced by the database itself. They're complementary layers — Dual7 ships both by default, so authorization failures in app code don't become data leaks.
Is Dual7 SOC 2 compliant?
SOC 2 certification is in progress. The controls SOC 2 examines — access control, change management with approvals, audit logging, secure SDLC — are already structural defaults of the platform, and because you own the exported code, your team can verify them directly.
Want something like this built for your business?
Book a DemoArticle Authors
More posts from this author
Related posts