Multi-tenant security, enforced where it counts.
MedRep is built so that tenant isolation, least-privilege access and accountability are properties of the platform — not promises in a policy document. Isolation lives in the database, identity comes from the session, and every sensitive action is logged.
Security that’s engineered in, not bolted on.
Each capability below is part of how the platform is built. They reinforce one another so that no single mistake exposes another tenant’s data.
Row-level tenant isolation
Every tenant-scoped table enforces row-level security in the database itself. Queries are filtered by tenant at the engine, not just in application code, so an ordinary query cannot return another tenant’s rows.
Session-derived tenant context
A request’s tenant is derived from the authenticated session — never from a request body, query string or URL. There is no parameter a caller can tamper with to reach data that isn’t theirs.
Governed cross-tenant access
Cross-tenant access is restricted to super-administrators, scoped tightly, and written to an immutable audit log every time it is used. Privileged access is the exception, and it is always accountable.
Managed-identity service auth
Services authenticate to each other and to platform resources using managed identities. There are no service credentials in source code, environment files or pipelines to leak, rotate by hand, or lose.
Secrets in a managed key vault
Connection strings, API keys and signing material live in a managed key vault with access policies and audit logging — pulled at runtime by identity, never baked into builds or container images.
Encryption in transit and at rest
Traffic is encrypted in transit with modern TLS, and data is encrypted at rest across databases, storage and backups using platform-managed keys. Encryption is on by default, everywhere.
Enterprise identity
Your staff sign in through your enterprise identity provider with workforce SSO, while your end users authenticate through a separate external identity directory — keeping internal and external populations cleanly apart.
Full audit trail
Sensitive actions — privileged access, data exports, permission changes and configuration edits — are recorded to a tamper-evident audit trail with actor, tenant, timestamp and context, ready for review and export.
Regional data residency
Workloads run in the Azure region you choose, with backups to a paired region in the same geography. Your data stays where your compliance team expects it to stay.
Layers, not a single line of defence.
If one control fails, the next still holds. Each layer is independent, and a tenant boundary has to be crossed at every level before any data is exposed — which, by design, it never is.
- 1Edge & WAF
A global edge with a web application firewall fronts every request before it reaches an origin.
- 2Identity
Enterprise SSO for staff and a separate external directory for end users gate who gets in at all.
- 3Session-bound tenant context
The tenant is fixed from the verified session and cannot be overridden by request input.
- 4Managed-identity service auth
Internal calls authenticate by identity, with no shared secrets to intercept or replay.
- 5Row-level security
The database itself filters every tenant-scoped table — the final, non-negotiable boundary.
- 6Audit & monitoring
Sensitive actions are logged and observable, so anomalies surface and access stays accountable.
A tenant boundary you don’t have to trust us to remember.
The strongest isolation is the kind a developer can’t accidentally switch off. That’s why ours lives in the database and is set from the session on every connection — not in a code path that has to be remembered on each query. Privileged access exists, but it is rare, scoped and always written to the audit log.
- Isolation enforced by the database engine, not application convention
- No service secrets in code — managed identity throughout
- Encryption in transit and at rest, by default, everywhere
- Cross-tenant access limited to super-admins and fully audited
Your data, in your region, on terms your compliance team will recognise.
MedRep is built on Azure, so residency, resilience and governance come from a foundation your auditors already understand.
Regional residency
Deployed to the Azure region you choose, with backups to a paired region in the same geography. Data stays where you need it to live.
GDPR-ready handling
Lawful-basis-aware data handling with support for data-subject access requests and deletion, so you can meet your obligations to your own users.
Resilient by design
Paired-region backups and platform-managed redundancy underpin recovery objectives, with restores you can verify rather than assume.
Certifications and assurance, stated honestly.
We run GDPR-ready data handling and ISO-aligned operational practices, and we’re glad to share SOC 2 readiness details, data-processing terms and a completed security questionnaire on request. We won’t claim a certificate we don’t hold — ask us, and we’ll tell you exactly where we stand.
Security questions we hear most.
Isolation is enforced in the database with row-level security on every tenant-scoped table, and the active tenant is set from the authenticated session on each connection. Even a buggy query cannot return another tenant’s rows, because the filter is applied by the database engine rather than trusted to application code.
From the authenticated session only. Tenant context is never taken from a request body, query parameter or path segment, so there is no input a caller can manipulate to cross a tenant boundary.
Only super-administrators, for a narrow set of platform-operations tasks, and every cross-tenant action is written to the audit log with the actor and context. Day-to-day roles are confined to their own tenant by design.
Through managed identities issued by the platform. There are no shared secrets or service passwords in code or configuration to be exposed, and access can be revoked centrally.
In transit with modern TLS and at rest across databases, storage and backups using platform-managed keys. Application secrets are held in a managed key vault and fetched at runtime by identity.
We follow GDPR-ready data handling — including data-subject access requests and deletion — and ISO-aligned operational practices. We are happy to walk through SOC 2 readiness, data-processing terms and a security questionnaire on request.
Yes. Workloads are deployed to the Azure region you select, with backups to a paired region in the same geography for residency and disaster recovery.
Put our security posture in front of your reviewers
Book a working session with our team. We’ll walk your security and compliance reviewers through the architecture, the controls and the evidence — on your real requirements.