Many clients on one platform, with isolation you can prove
Running several sponsors on a shared safety system is only acceptable if the separation is architectural and evidenced. This page covers how PVgenix implements tenant isolation, what each model suits, and the documentation you can hand an auditor during due diligence.
The question that decides whether you win the contract
Every sponsor due-diligence pack asks some version of the same thing: how do you guarantee our safety data is not accessible to your other clients? A vague answer loses contracts, and an answer that relies purely on user permissions does not survive a QA reviewer who has read Annex 11 or Part 11.
Permissions are not isolation
Role-based access control is necessary but not sufficient. A reviewer will ask what happens if a role is misconfigured, and whether isolation still holds. Architecture has to answer that, not administration.
Shared reference data leaks context
If code lists, datasheets, product dictionaries, or workflow definitions are global rather than tenant-scoped, one client's product and study names become visible in another client's configuration.
Wrong-tenant data entry
One processing team moving between sponsors during a shift is a real integrity exposure. The system has to scope a user's session to a tenant rather than trusting a dropdown selection.
Residency clauses that conflict
One sponsor requires EU hosting, another requires data to stay in India. On a single shared deployment with one region, those two contracts are mutually exclusive.
No evidence to hand over
Even where isolation is sound, you need documentation you are permitted to share. Being unable to produce it reads, to an auditor, exactly like not having it.
Cross-tenant reporting that should not exist
Operational dashboards are useful to you and unacceptable to a sponsor if they expose another client's volumes. Aggregate views have to be scoped deliberately.
PVgenix treats the tenant as a first-class boundary: data, configuration, reference data, dictionary versions, workflows, and reporting are all tenant-scoped, sessions are bound to a tenant, and every access and change is captured in a tamper-evident audit trail — with a dedicated single-tenant deployment available where a contract requires physical rather than logical separation.
How isolation is implemented
The controls below apply in the multi-tenant SaaS model. In a dedicated single-tenant deployment the application and database are separate instances, so isolation is physical in addition to everything here.
Tenant-scoped data partitioning
Case records, source documents, attachments, and audit entries are partitioned by tenant, so a query cannot return another tenant's rows regardless of role configuration.
Least-privilege access control
Role-based access control designed around 21 CFR Part 11 and GxP segregation of duties, scoped within the tenant — a user's permissions exist inside one client's boundary, not across it.
See how it worksPer-tenant configuration
Reporting rules, workflow states and review gates, intake forms and validation, code lists, notification and escalation rules, branding, and subscription entitlements are all held per tenant.
Per-tenant reference data
Version-controlled reference safety information (CCDS/CCSI, SmPC, USPI) and admin-controlled MedDRA and WHO Drug Dictionary versions per client, so a listedness call is always traceable to that sponsor's datasheet version.
See how it worksTamper-evident audit trail
Every create, read, update, and delete is logged with who, what, when, and before/after values, alongside electronic signature capture and verification — per tenant, and exportable as evidence.
See how it worksEncryption and secrets management
Encryption in transit and at rest, with secure credential and secrets management — the baseline controls a sponsor's security questionnaire will ask about explicitly.
See how it worksRegion hosting options
EU, US, and India region hosting to satisfy GDPR and sponsor contractual residency requirements, so conflicting clauses across your client book do not become mutually exclusive.
See how it worksScoped reporting and dashboards
Compliance and operational metrics are computed per tenant. Cross-client operational views exist for your own management purposes and are governed by role, never exposed to a client tenant.
See how it worksChoosing between the two isolation models
Both models run the same product from the same codebase, so behaviour and feature parity are identical. The difference is where the boundary sits and what it costs to operate.
Logical isolation — the default for CRO operations
One managed application and database with tenant-scoped partitioning and access control, each tenant configured independently. Fastest to provision, lowest cost per client, and no per-sponsor infrastructure for your team to maintain. Suits the large majority of sponsor relationships.
Physical isolation — for contracts that require it
An isolated application and database instance for that client, deployable in a specified environment or region. Suits sponsors with strict residency, security, or internal-hosting requirements written into the agreement, and large MAHs wanting full environment control.
Mixing models does not fork your SOPs
Because both deployments run the same product, a sponsor who demands physical isolation does not force you onto a second platform with different behaviour, different training, and a second set of procedures to maintain.
Identity integration
SAML, OIDC, and Azure AD single sign-on, so tenant access follows your existing identity governance and joiner-mover-leaver process rather than a separate user list.
Segregated training environment
A sandbox or training instance separate from production, plus training-record tracking — a standard qualification expectation and a routine sponsor-audit question.
Continuity commitments
Automated backup procedures, defined recovery objectives (RPO/RTO), retention aligned to regulatory requirements, and a stated availability target — the figures a sponsor will want in the agreement.
Answers before the demo
The questions that come up in most evaluations. If yours is not here, ask it on the call.
Browse the full FAQA multi-client (or multi-tenant) pharmacovigilance system serves several client organisations from one platform, with each client's data isolated and each tenant configured independently — separate reporting rules, workflows, code lists, dictionary versions, reference safety information, and access control. It is the architecture CROs and service providers need, because it makes onboarding a new client a provisioning task rather than a new deployment, while still keeping each client's safety data separate.
Logical isolation means one application and database instance serves multiple tenants, with data partitioned and access scoped per tenant. Physical isolation means a separate application and database instance per client, optionally in a specified region. Logical isolation is faster to provision and cheaper per client and suits most relationships; physical isolation suits sponsors whose contracts mandate separation or a specific hosting location. PVgenix supports both from the same codebase, so feature behaviour is identical either way.
Alongside an architectural description of tenant partitioning and tenant-scoped role-based access control, PVgenix provides a supporting documentation set — VMP, URS, FS, DS, IQ/OQ/PQ, RTM, and SOP templates — plus the tenant's own audit trail, which records every create, read, update, and delete with attribution and before/after values. What may be shared with a third party is agreed per engagement, so raise sponsor-audit disclosure needs during contracting rather than mid-audit.
Yes, provided scoping is enforced by the system. A user's access is granted per tenant under a least-privilege model, and every action is attributed and logged within that tenant's audit trail. Combined with per-tenant configuration — different workflows, forms, and code lists per client — the context a processor works in is defined by the platform rather than by them remembering which sponsor they are on.
Yes. Region hosting options include EU, US, and India for GDPR and sponsor contractual residency requirements. Where a single client's contract requires its data to remain in a specific jurisdiction, that client can run as a dedicated single-tenant deployment in the required region while your other clients continue on shared multi-tenant SaaS.
Compliance and operational metrics are computed per tenant, and cross-client operational dashboards are available to your own management roles for capacity and performance oversight. Those aggregate views are governed by role and are never exposed inside a client tenant, so a sponsor cannot see another sponsor's volumes.
Walk through tenant isolation with us
Request a demo and we will show tenant provisioning, per-client configuration, scoped access, and the audit trail — on real screens, not an architecture slide.