Whitepaper · Multi-Tenant
Multi-Tenant Readiness
How regulated institutions build and operate a scalable, auditable multi-tenant architecture. A guide for CISOs, compliance and audit.
What is Multi-Tenancy?
Multi-tenancy describes a software architecture in which a single instance of an application serves multiple organizationally separate user groups ("tenants"). Each tenant operates in its own logical area — their data is isolated, their configurations are separate, and their users are restricted to their own tenant.
For financial institutions, multi-tenancy is of strategic importance: they can use a shared platform without violating regulatory requirements for data separation and access control. The challenge lies in demonstrable, auditable tenant isolation — especially under DORA, MaRisk and ISO 27001.
Why Multi-Tenancy Matters for Regulated Institutions
Auditable Data Separation
Regulatory audits require proof that Tenant A cannot access Tenant B's data. Multi-tenancy must provide this proof at the technical level — not just organizationally.
Scalability Without Audit Gaps
Each new tenant brings new compliance requirements. A standardized multi-tenant architecture reduces the audit effort per new customer from weeks to days.
Cost Efficiency Through Shared Service
Shared infrastructure with guaranteed isolation reduces operating costs while meeting the highest security standards.
Audit Security
Auditors require evidence of tenant separation. Automated isolation tests provide this evidence in an audit-proof manner — with every deployment.
Security & Isolation – Three-Tier Security Model
Data Isolation
Every tenant-related table contains a tenant_id column. Global Scopes at the model level automatically filter for the current tenant. Accidental removal of the scope is detected and blocked by the automated isolation test suite.
Encryption
TLS 1.3 for all communication. AES-256 encryption for backups and data at rest. Each tenant can have their own encryption key (Bring-Your-Own-Key capable).
Access Control
Multi-layer access model: EnsureTenantSelected middleware checks the tenant context, policies authorize every action, and session management with tenant_id prevents cross-tenant access at the application level.
Architecture Overview (Conceptual)
The multi-tenant architecture follows a Shared-Database / Row-Level-Tenancy model. This model offers the best balance between isolation, scalability and operational complexity for regulated SaaS environments.
1
Authenticated
User → IdP → Session
2
Tenant Context
Middleware injects tenant_id
3
Isolated Query
Scope filters → Policy
Tenant Onboarding Workflow
The standardized onboarding process ensures that each new tenant is set up consistently, auditably and without security gaps.
Tenant Registration
Capture tenant master data, select modules, define the administrator account. Automatic generation of the tenant_id.
Base Configuration
Set up database scopes, activate middleware, configure roles and permissions according to tenant type.
Identity Federation
Connect the corporate identity provider (SAML 2.0 / OIDC). Configure attribute mapping and role synchronization.
Isolation Test Suite
Automated execution of isolation tests. Verification: cross-tenant access blocked, database scopes active, audit log consistent.
Go-Live & Monitoring
Release for production operation. Continuous monitoring of tenant isolation, regular re-certification.
Compliance: Regulatory Requirements for Multi-Tenant Systems
DORA — Digital Operational Resilience Act
DORA Art. 4 (ICT Strategy) requires a documented architecture with demonstrable tenant separation. Art. 9 (ICT Risk Management) mandates regular testing of access controls. The automated isolation test suite fulfills these requirements in an audit-proof manner.
MaRisk — Minimum Requirements for Risk Management
MaRisk AT 7.2 (Resources) and AT 9 (Outsourcing) require strict separation of customer and institution data. The row-level tenancy architecture with middleware protection fulfills this requirement and is validated by regular penetration tests.
ISO 27001 — Information Security
ISO 27001:2022 Annex A controls access control (A.8.2–A.8.3), logging (A.8.15) and monitoring (A.8.16). Each tenant receives isolated access structures, the audit log is tenant-granular.
BSI C5 — Cloud Computing Compliance
The BSI C5 criteria catalog requires proof of tenant separation in cloud environments (CRY-01, IDM-01). The documented architecture and automated test suite serve as audit evidence.
Roadmap to Tenant Capability
Current State — Row-Level Tenancy Active
- ✓ Row-level tenancy implemented at database level
- ✓ Global Scopes on all tenant-related models
- ✓ EnsureTenantSelected middleware active
- ✓ Policy engine for tenant-based authorization
- ✓ Automated isolation test suite in deployment pipeline
- ✓ Tenant-enabled audit logs with tenant_id
2026 H2 — Enhanced Isolation & Self-Service
- → Dedicated database instances on request (Database-per-Tenant)
- → Self-service tenant onboarding portal
- → BYOK (Bring-Your-Own-Key) per tenant
- → Cross-tenant reporting function (with explicit consent)
- → Advanced RBAC role models with custom roles
2027 — Full Tenant Autonomy
- → Hybrid model: Combination of shared database and dedicated instances
- → Tenant-enabled disaster recovery with individual RPO/RTO
- → Automated compliance reports per tenant for regulatory audits
- → API-driven tenant management for enterprise customers
- → Integration with governance frameworks (ServiceNow, Jira, SAP GRC)
Ready for Tenant Capability?
Schedule a non-binding pilot conversation — we'll show you how the multi-tenant architecture meets your compliance requirements and accelerates your scaling.
Request Pilot MeetingReifegrad
-
1 Initial
Ad-hoc-Ansätze, keine formalen Prozesse
-
2 Defined
Formale Prozesse definiert, aber nicht durchgängig umgesetzt
-
3 Implemented
Prozesse vollständig umgesetzt und dokumentiert
-
4 Monitored
Prozesse werden überwacht und gemessen
-
5 Optimized
Kontinuierliche Verbesserung und Anpassung