Security and trust

Your data, your tenant, your region.

Enterprise buyers ask where the data lives, who can reach it, and how we prove it. This page answers in the open, and says for each control whether it is built, in development or planned. We do not claim certifications we do not hold.

Isovara is pre-pilot. Nothing here has carried customer data yet; production hardening (private networking for the data services, an identity review, backup rehearsal) is listed below as in development.

Built
exists in Isovara's environment, not yet carrying customer data
In development
being built now
Planned
designed, not yet built

Last reviewed 27 October 2026

Processed and stored in the UK. Your region, when you need one.

Isovara runs on Microsoft Azure in the United Kingdom. Customer-selectable regions and dedicated infrastructure are planned for customers whose regulators or contracts require them.

  • BuiltUK South (Microsoft Azure). Bordereaux and business data are processed and stored here.
  • BuiltEurope (EMEA): sign-in identity data only (Entra External ID).
  • PlannedEU regions, selectable per customer.
  • PlannedDedicated infrastructure or a customer-owned database.
  • Built

    UK hosting for bordereaux and business data

    Application, databases and file storage run in Azure UK South. Policies restrict resources to UK regions.

  • Built

    Sign-in identity data: Europe (EMEA)

    Who signed in (names, emails, sign-in events) is held by Microsoft Entra External ID in its Europe geography. It never holds bordereaux. Enterprise customers who need identity data in a specific region can have that arranged on an enterprise plan.

  • In development

    Where your data goes, in writing

    Which services process and store customer data, and where, is documented and available on request with the DPA.

  • Planned

    Customer-selectable regions

    Choose UK or EU at onboarding; data for that organisation, including identity data on an enterprise plan, stays in the chosen region.

  • Planned

    Dedicated and customer-managed deployment

    A dedicated database server as a paid tier, or a database the customer owns, for those who need it.

A database per tenant. A control plane that never holds your data.

Most multi-tenant software puts every customer in the same tables and relies on a filter. Isovara gives each organisation its own database and its own file container, and keeps the part that knows who you are separate from the part that holds what you uploaded.

Control plane · no customer bordereau data

Sign-in brokerEntra External ID
Organisations and rolesAdmin, member
Tenant routingAuthorised per request

  • Data plane · Organisation A

    DatabasePostgreSQL
    File containerBlob storage

  • Data plane · Organisation B

    DatabasePostgreSQL
    File containerBlob storage

  • Data plane · Organisation C

    DatabasePostgreSQL
    File containerBlob storage
  • In development

    Database per tenant

    Each organisation’s data lives in its own PostgreSQL database. Shared server by default; a dedicated server is a paid tier.

  • In development

    File container per organisation

    Uploaded bordereaux are stored in a Blob container that belongs to one organisation, with workspaces as prefixes within it.

  • In development

    Control plane apart from data planes

    Sign-in and organisation membership already live in their own control plane; routing each request to that tenant’s own database is being built with the database per tenant.

  • Built

    Tenant-aware authorisation

    Every request carries one organisation’s scope, and a lost membership is re-checked on the next refusal. People who work for several organisations: planned.

  • In development

    Private access to the data services

    Databases, file storage and queues move behind private networking before the pilot; an identity review precedes any real data.

  • In development

    Cross-tenant access tests

    Automated tests that attempt cross-tenant reads and must fail, run on every change.

Your identity provider, your rules.

Sign in with email, or federate your company directory so your joiners, leavers and MFA policy apply to Isovara automatically.

  • Built

    Email and company sign-in

    A brokered sign-in (Microsoft Entra External ID) that accepts email accounts and federated company directories.

  • Built

    One SSO connection per organisation

    An organisation admin connects their company’s directory; Microsoft directories today, with OIDC and SAML providers to follow.

  • Built

    Invitation-only onboarding

    Nobody joins an organisation without an invitation from its admin; sign-up is checked by Isovara’s API before an account is created.

  • Built

    Roles

    Organisation admin and member today.

  • Planned

    Enterprise SSO standards and MFA policy

    OIDC and SAML for any provider; MFA required per organisation; identity-provider flexibility for groups with more than one directory.

  • Planned

    Granular authorisation and workspace access

    Finer roles (for example read-only auditor) and access scoped to a workspace or a Channel.

Encrypted, logged, and yours to delete.

The evidence trail that makes bordereaux auditable also makes the platform auditable: who did what, to which file, when.

  • Built

    Encryption in transit and at rest

    TLS for every connection; Azure-managed encryption for databases and file storage.

  • Built

    Secrets management

    Credentials held in Azure Key Vault and managed identities; none in code or configuration files.

  • In development

    Audit logging and traceability

    Every submission keeps its source versions, configuration versions, runs and actors; an exportable audit record is being added.

  • Planned

    Retention and deletion controls

    Retention periods set per organisation; deletion of an organisation’s data on exit, with confirmation.

  • Planned

    Backup and disaster recovery

    Point-in-time restore per tenant database and documented recovery objectives.

Who can reach your data, and what happens when something goes wrong.

The questions every insurer’s vendor questionnaire asks, answered before you send it.

  • Built

    No standing access to customer data

    Isovara staff have no routine access to tenant databases or files; the development estate holds fictional data only.

  • In development

    Logged support access

    Any support access to a customer’s data is granted for a reason, time-limited and recorded, and the customer can see the record.

  • In development

    Incident response and breach notification

    A written incident process; customers told of a confirmed breach affecting their data within 72 hours of Isovara becoming aware.

  • Planned

    Availability, status page and support hours

    A public status page and stated support hours and response times, agreed per pilot.

  • Planned

    Data return and deletion on exit

    Your data returned in a standard format and deleted from Isovara on request, with confirmation.

Tested by someone other than us.

Independent checks are planned before the first pilot. None has happened yet, and we will say when one has.

  • Planned

    Penetration test before the first pilot

    An independent test of the application and estate, with the summary available to customers under NDA.

  • Planned

    Cyber Essentials, then Cyber Essentials Plus

    The UK government-backed baseline, before the first pilot. Not yet certified.

  • In development

    Vulnerability disclosure

    A security contact (isovara@outlook.com until a security@ mailbox exists) and a published disclosure policy.

  • Built

    Automated checks on every change

    Build, tests and secret scanning run on every change before it can reach the main branch.

Designed to align with GDPR. Working towards the rest.

We say "designed to align with" because alignment is a design approach, not a verified legal status. We hold no certifications yet and will not imply otherwise.

  • In development

    UK and EU GDPR by design

    Tenant isolation, UK hosting and minimal personal data (who signed in, what they did); the website privacy notice is drafted and is confirmed before launch.

  • In development

    Data processing agreement and subprocessors

    A DPA and the list of subprocessors (Microsoft Azure today) available on request before a pilot.

  • In development

    Security policies and governance

    Written policies for access, change, incident response and vendor management, shared with pilot customers.

  • Planned

    SOC 2 and ISO 27001 readiness

    Objectives, not attestations. We will say when an audit is scheduled and when a report exists.

For IT and security reviewers

Ask us the hard questions.

Security summary, DPA, subprocessor list and architecture walkthrough on request. We would rather answer early than surprise you later.

  • In developmentSecurity summary
  • BuiltArchitecture walkthrough
  • In developmentDPA draft
  • In developmentSubprocessor list
Request the security summary