Security and data handling

Your data is pulled into a warehouse in Microsoft Azure, Italy North (EU), isolated per tenant, encrypted in transit and at rest, and deleted within 30 days of offboarding. The access side — the read-only roles and the service principal — is covered in permissions and data sources. If your security team is weighing whether the Reader role is too broad, Why Reader, and what it cannot see sets out a least-privilege alternative. Figure 1 draws where your data sits, and marks the single hop that leaves the EU region.

Figure 1 — Key: solid = your data path · dashed amber = the one hop that leaves the EU region · dashed grey = other tenants, drawn only to show the isolation.

How to reach us

Questions, a data processing agreement, an offboarding deletion confirmation, or anything else this documentation says is provided “on request” or “in writing”: email [email protected]. Privacy and data-protection requests go to [email protected].

Hosting and residency

Primary storage and processing stay in Microsoft Azure in the EU — the Italy North region: 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 write the answer you see — the answer is composed from real result rows, not from a code template.

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.

If your policy requires all inference inside the EU, raise it before you connect.

Per-tenant isolation

Each customer is isolated at the storage and query layer:

• Each tenant has dedicated warehouse databases. There is 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. A name taken off that list loses access within about a second, an unreadable allowlist fails closed rather than open, and every authorisation decision is logged. Direct access to a tenant’s warehouse for support or delivery work is held by named Infralign engineers, not by a shared account.

Incident notification

If we become aware of a personal-data breach affecting your tenant, we notify your named contact without undue delay. The data processing agreement sets the binding notification terms.

Encryption

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

Credential custody

• The service-principal secret you share sits in access-controlled configuration on Infralign’s infrastructure — encrypted at rest, scoped to the ingestion runtime, and never logged.
• Rotate it at any time: issue a new secret, share it, and let the old one expire.
• Certificate credentials or workload-identity federation are available for security-sensitive tenants — see Entra app registration.

Sub-processors

Your data is processed by:

• Microsoft Azure — hosting for the warehouse, BI, and the application, in Italy North (EU).
• OpenAI — the chatbot’s language layer, and the only language-model provider in use today. Named here so you can put it in front of your own security review.
• Cloudflare — edge and tunnel for app.infralign.ai and the BI host.
• Microsoft Teams / Power Automate — only if you connect the optional Teams webhook for pipeline summaries.

We notify you in writing before adding or replacing a sub-processor.

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.

On offboarding, your tenant warehouse, the raw copies, and backups are deleted within 30 days, confirmed to you in writing. Revoking access is separate and immediate: remove the role assignments or delete the app registration and ingestion stops the same moment. 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. A data processing agreement (DPA) is available on request.

---

Next: Data sources — every source the platform reads, with its endpoint and purpose.