Security and data handling

Your data is pulled into a warehouse in Microsoft Azure, Italy North (EU), isolated per tenant and encrypted in transit and at rest.

The Azure assignments grant no workload or resource-configuration write permissions; permissions lists every role action and a least-privilege custom role. If your security team is weighing whether Reader’s control-plane scope is too broad, Why Reader, and what it cannot see preserves the boundary between metadata and data-plane access.

Figure 1 shows where your data sits and the single hop that leaves the EU region.

Where your data is hosted, and how tenants are isolated. Billing and resource metadata is pulled nightly out of your Azure tenant, read-only, over cost and control-plane APIs into Infralign's warehouse. The warehouse is drawn as a labelled container marked EU region boundary: Microsoft Azure, Italy North (EU), with no shared application query path between tenants. Inside that container your tenant has its own dedicated database and its own Superset instance, and two ghosted cards beside it are other tenants, drawn only to show the isolation, each with the same dedicated database and its own Superset instance. One solid amber arrow leaves the container, labelled chatbot questions only, and lands on a card outside the region: the OpenAI API. To answer a chatbot question that call sends your question, the names and types of the warehouse columns the query may touch, the SQL that ran, and the rows that SQL returned, because the model composes the answer from those rows. That call is not region-pinned, so the inference is not guaranteed to happen in the EU. — Figure 1: Solid lines are your data path and the one annotated hop leaves the EU region. The ghosted cards are other tenants, drawn only to show the isolation.

Hosting and residency

Primary storage and processing stay in Microsoft Azure, Italy North (EU): the warehouse, the dashboards, the reports, and the audit.

The chatbot’s language-model layer is the one exception. It calls OpenAI’s API (the only language-model provider in use today), and that call is not region-pinned, so the inference is not guaranteed to happen in the EU.

Exactly what crosses that boundary when you ask the chatbot a question:

What is sent	Detail
Your question	The text as you typed it, plus the scope it runs under, which includes the subscription IDs and resource-group names in scope.
The shape of your warehouse	The allowlisted table names, and the column names and types the query may touch. Column metadata, not DDL, and not your whole schema.
The SQL that ran	The statement text, which carries those same scope identifiers.
The rows that SQL returned	Capped at 50 rows per query. The model reads those rows to compose the answer you see.

What never crosses it: credentials or the client secret, anything inside your resources (database contents, VM filesystems, application data), and anything belonging to another tenant.

Turns in a conversation are chained at the provider for the length of a session, so earlier questions and answers in the same session are retained there. Infralign has not yet documented a contract that provides zero retention, EU residency, or a customer-data training exclusion for this API path; those terms must be verified for the DPA.

The chatbot is available to every account, and there is no setting that switches it off for one account. Suppressing it would need an Infralign change on our side, agreed with you first.

If your policy requires all inference inside the EU, raise it before you connect. An EU-pinned alternative is not offered today and would need a separate written and technically verified agreement.

Per-tenant isolation

Each customer is isolated at the storage and query layer:

Each tenant has dedicated warehouse databases. The application has no shared query path across customers.
Each tenant has its own Apache Superset instance, scoped to that tenant alone.
The chatbot runs read-only, single-SELECT queries against an allowlist of your own tenant’s tables. See the chatbot.

Who can reach your data

Application access is granted one named identity at a time: an allowlist of specific email addresses, each pinned to your tenant’s directory ID, never a whole email domain. Your own admins hold that list, and may add addresses only at domains recorded for your account. See manage who has access.

A removal takes effect in about a second, including any open session. Every add, removal and role change is audited, every authorisation decision is logged, and if the allowlist cannot be read, access fails closed.

Direct warehouse access may be needed for support or delivery work. The MFA requirement, number of staff with that access, and logging and review of direct access have not yet been documented as verified controls. Confirm them during the security review before onboarding.

Incident notification

Infralign has not yet adopted a written incident-response policy or binding breach-notification window. The DPA must set those terms before onboarding; no contractual notification timeframe is claimed here.

Encryption

In transit: all connections use TLS.
At rest: data is held on Azure-managed storage with Azure storage-service encryption.

Credential custody

Your admin enters the client secret in the setup wizard over TLS. It is not transferred out of band, and no Infralign person handles it.
The stored value is encrypted at the application layer. The encryption key is held in a root-owned file on the host, outside the database, so a database copy alone decrypts nothing.
No API returns the secret. The connection page shows the credential type, the expiry date and the last validation time, and nothing else.
Rotate it at any time from the connection page. Create the new secret in Entra first. The new value is validated against Azure before it replaces the old one, and a failed check changes nothing.
Custody of the encryption key, including the planned move to Key Vault, is still to be verified during the security review.
Certificate credentials and workload-identity federation are not enabled as a standard path today. If either is required, agree and validate the authentication path before onboarding. See Entra app registration.

Sub-processors

The current documented architecture uses:

Sub-processor	What it does
Microsoft Azure	Hosts the warehouse, the BI layer, and the application, in Italy North (EU).
OpenAI	The chatbot’s language layer, and the only language-model provider in use today.
Cloudflare	Edge and tunnel for `app.infralign.ai` and the BI host.
Microsoft Teams / Power Automate	Only if you ask Infralign to post summaries or cost alerts into one of your channels. No self-service field exists for this.

Confirm the complete sub-processor schedule and any written change-notification commitment in the DPA before onboarding.

Retention and deletion

While the service is active, your data is retained so dashboards, reports, and the chatbot have history to work from. Up to 13 months of cost history is backfilled on connection.

The intended offboarding target is to delete the tenant warehouse, raw copies, and backups within 30 days and confirm completion in writing. The operational runbook behind it has not yet been finalised. Until it is, the 30 days belongs in your contract, and no reviewer should record it as a verified current process.

Revoking Azure access is separate: remove the role assignments or delete the app registration. New collection stops once Azure applies the revocation or the credential can no longer authenticate. See data sources for the revocation steps.

Certifications and DPA

Infralign does not hold a formal certification such as SOC 2 or ISO 27001 today. The DPA is being prepared and is not yet available as a reviewed agreement.