Trust Center

Overview

BI Pixie is operated by DataChant Consulting LLC. This page summarizes our security, privacy, and compliance posture for the four deployment models we support. It is published as a self-serve resource for customer security and procurement teams and is consistent with our Privacy Policy, Terms of Service, and the Microsoft Fabric Workload Vendor Attestation.

The trust boundary (who can access customer data and where it lives) differs significantly between deployment models. The comparison table below is the fastest way to identify which model applies to you and what controls are in place. Each model has its own detailed section further down.

For security or procurement questions not answered here, contact support@bipixie.com.

At a Glance

BI Pixie's four deployment models differ along two dimensions: who operates the platform, and where customer data lives.

• BI Pixie on Azure and BI Pixie on Power Platform keep everything inside your own Microsoft tenant. You operate the platform under your existing security policies; we have no access to your data.
• BI Pixie Cloud is the fully-managed option. We host the platform on Azure on your behalf and act as your data processor for the telemetry you collect.
• BI Pixie Workload in Microsoft Fabric runs natively inside Microsoft Fabric. Dashboard items live in your Fabric capacity; raw telemetry events go to BI Pixie's managed Azure storage.

The table below summarizes how these differences play out across the controls procurement and security teams typically evaluate.

BI Pixie on Azure

BI Pixie is deployed entirely within your own Azure subscription as an Azure Managed App. All telemetry data, configuration, and identity remain inside your Azure tenant. BI Pixie ships the deployment template; you operate the deployed resources.

Trust boundary

Your Azure subscription. The resources BI Pixie deploys (Function Apps, Storage Accounts, Event Hub, etc.) are created in your tenant under your billing, your IAM, and your security policies. Service-to-service secrets are stored as connection strings by default; you can supply your own Key Vault (existing or new) to manage them centrally instead. We have no plane of access to any of these resources. Per Privacy Policy §10.1, we act as neither a data controller nor a data processor for any data your deployment collects.

Security inheritance

All controls of your Azure tenant can be applied to the deployment: Microsoft Defender for Cloud, Entra Conditional Access (including MFA, compliant-device, named-location, sign-in risk, session controls), Azure Policy, Private Endpoints, customer-managed keys, audit log export to your SIEM, and any other Azure-native or third-party tooling you have in place. Encryption at rest and in transit is provided by the Azure platform.

Data residency

You select the Azure region(s) for deployment. Data never leaves the regions you select. This is governed entirely by your tenant configuration; BI Pixie's tooling does not introduce a residency boundary of its own.

Updates and lifecycle

Software updates are delivered through the Azure Managed App update mechanism on a cadence you approve. The Managed App publisher (DataChant) does not retain runtime access to the deployment; updates are an opt-in publisher offer that you accept through the Azure portal.

Instrumentation client

Report instrumentation is performed by BI Pixie Instrumentation, a Windows desktop application that runs in your environment. You select which reports and semantic models to instrument. You can either bring local copies of their definition files to the application, or let the application load them directly from Power BI using your az login credentials. Definition files flow only between your machine and your Power BI environment; report content and semantic-model definitions never pass through the BI Pixie cloud. The executable is first-party code with no open-source or third-party runtime dependencies, which reduces the supply-chain surface that customers must vet.

The only network call BI Pixie Instrumentation makes to the BI Pixie cloud is a license check, which transmits your account email, your license key, and license-related counters (such as the number of reports instrumented). No report data, telemetry, or end-user data is sent. New versions are distributed as installer downloads through the self-hosted user guide; you choose when to install them.

Compliance

Compliance posture is governed by your Azure tenant. BI Pixie inherits Microsoft Azure platform certifications relevant to your subscription (ISO 27001, ISO 27018, SOC 1/2/3, HIPAA BAA, FedRAMP, EU Model Clauses, etc.). DataChant does not make compliance claims about data in this model because the data is never in DataChant's possession.

Reference: Deploy on Azure · Privacy Policy §10.1

BI Pixie on Power Platform

BI Pixie is deployed inside your Microsoft Power Platform environment. All telemetry data, configuration, and identity remain inside your Power Platform tenant. Same trust posture as BI Pixie on Azure, running on Microsoft Power Platform rather than raw Azure.

Trust boundary

Your Power Platform environment. The connectors, flows, and storage that BI Pixie creates exist inside your environment under your governance. We have no plane of access. Per Privacy Policy §10.2, we are neither a data controller nor a data processor for data collected by the deployment.

Security inheritance

All controls of your Power Platform environment apply: Dataverse security roles, environment-level data loss prevention (DLP) policies, Entra Conditional Access on the underlying tenant, customer-managed keys (where supported by your Power Platform license), and Microsoft 365 audit log integration. Encryption at rest and in transit is provided by Microsoft Power Platform.

Data residency

Determined by the geography of your Power Platform environment. Microsoft's Power Platform regional model governs where data is stored and processed; BI Pixie does not introduce additional regional movement.

Instrumentation client

Same as BI Pixie on Azure: report instrumentation is performed by the BI Pixie Instrumentation Windows desktop application running on the report author's machine, with no open-source or third-party runtime dependencies and a license-check phone-home limited to account email, license key, and license-related counters. See the BI Pixie on Azure section for the full description.

Compliance

Inherits Microsoft Power Platform compliance attestations (ISO 27001, ISO 27018, SOC 1/2/3, HIPAA, GDPR, EU Model Clauses, etc.) per your tenant configuration. As with BI Pixie on Azure, DataChant does not make compliance claims about data in this model because the data is not in DataChant's possession.

Reference: Deploy on Power Platform · Privacy Policy §10.2

BI Pixie Cloud

BI Pixie operates the platform on Microsoft Azure on your behalf. You are the data controller; BI Pixie is the data processor for end-user telemetry data. This is the deployment model where the most detailed controls apply and where our public commitments are most extensive.

Trust boundary

BI Pixie's Azure tenant, in one of three production regions: East US 2, West Europe, or Central India. New customers are placed in the region closest to their Power BI home region by default; Enterprise tier customers may select a specific region to meet data-sovereignty requirements. Each customer is provisioned an isolated container in Azure Data Lake Storage Gen2; cross-customer access is not possible by application logic alone; it is enforced by Azure's identity platform via per-customer RBAC on the storage account itself. See Privacy Policy §6.2 for the data-isolation contract.

Encryption

All communication uses HTTPS with TLS 1.2 or higher. Data at rest is encrypted with AES-256 using Azure-managed keys. Encryption is enforced at the storage-account level; tracking-pixel HTTP requests, control-plane API calls, and dashboard reads are all TLS-only.

Identity and access

Customer administrators authenticate with Microsoft Entra ID. Internal service-to-service calls use Managed Identity (no shared connection strings); cross-service access is governed by Entra application roles. All admin-level mutations emit structured audit logs aligned with SOC 2 CC7.2.

Access to the customer's dedicated storage container uses two mechanisms, each scoped to a distinct consumer:

• Per-customer RBAC. Used by the BI Pixie backend and the BI Pixie Portal to act on the customer's behalf, bounded to two scopes: (a) the customer's dedicated storage container in BI Pixie Cloud, accessed via the platform's Managed Identity; and (b) the report and semantic-model definitions in Power BI Service, accessed under the user's own Power BI workspace roles. The platform reads and writes only what the signed-in user is already authorized to access in their Power BI tenant.
• Customer-scoped SAS tokens. Issued to the BI Pixie Dashboard that customers install in their Power BI tenant. The dashboard connects directly to the customer's container in BI Pixie Cloud using a scoped, expirable, revocable SAS token; no BI Pixie service is in that request path.

Enterprise tier: customers may issue separate RBAC assignments and separate SAS tokens to different teams and users within their organization, supporting least-privilege separation.

Data residency

BI Pixie Cloud operates in three production Azure regions: East US 2, West Europe, and Central India. New customers are placed in the region closest to their Power BI home region by default. Enterprise tier customers may select a specific region to meet data-sovereignty requirements (for example, an EU-based customer may choose West Europe to ensure telemetry remains within the EU/EEA). Once assigned, telemetry data is stored exclusively in that region; cross-border movement does not occur without an explicit migration request. See Privacy Policy §6.3.

Data we collect (and what we do not)

What we collect is described in detail in Privacy Policy §3 and is governed by an off-by-default privacy model (Privacy Policy §4): user identity capture, filtered values, and IP retention are all disabled unless you explicitly enable them. By the same token: we do not mine, analyze, or train AI/ML models on customer telemetry data, and we do not use it for advertising, profiling, or behavioral targeting (Privacy Policy §5.2).

Retention and deletion

Retention is plan-controlled and self-service. Maximum retention by tier: Trial 14 days, Standard 30 days, Pro 1 year, Enterprise 3 years (see Privacy Policy §8). Events past your retention window are deleted daily. Account-level deletion is supported on request; backup copies are retained briefly per Terms §7. End-user-level deletion (for GDPR DSARs) is supported via the Data Management view in the BI Pixie Portal; see the Data Management user guide.

Compliance

We implement SOC 2-aligned controls in the Security and Confidentiality trust service categories. CC7.2 (system monitoring) is implemented per our audit-logging architecture. DataChant has not engaged a third-party auditor for SOC 2 Type II at this time and will reassess as customer requirements warrant. We inherit Microsoft Azure's compliance posture (ISO 27001, ISO 27018, SOC 1/2/3, HIPAA BAA, FedRAMP, EU Model Clauses, GDPR DPA) for the underlying platform. GDPR data subject rights are supported per Privacy Policy §11.3; CCPA rights per §11.4.

Reference: Privacy Policy · Terms of Service · Cloud FAQ

BI Pixie Workload in Microsoft Fabric

BI Pixie ships as a native Microsoft Fabric workload, published through the Fabric Workload Hub. The workload code is hosted by BI Pixie (frontend rendered as an iFrame inside the Fabric portal; backend in BI Pixie's Azure tenant); the BI Pixie Dashboard items it produces (Lakehouse, Semantic Model, Report) live in your Fabric tenant; and raw telemetry events ingest to vendor-managed Azure storage in one of BI Pixie's production regions. This is the architecture summarized in our Microsoft Fabric Vendor Attestation.

Trust boundary

Three surfaces. (1) The workload code runs in BI Pixie's hosting: the frontend is served from BI Pixie's infrastructure and rendered as an iFrame inside the Fabric portal, and the backend runs in BI Pixie's Azure tenant. (2) The BI Pixie items in your workspaces, including the BI Pixie Dashboard's native Fabric items (Lakehouse, Semantic Model, Report), live in your Fabric tenant under Fabric workspace RBAC and Microsoft Entra Conditional Access; once installed, BI Pixie has no plane of access to these items (analogous to a Power BI template app installed in your tenant). (3) Raw telemetry events from instrumented Power BI reports ingest to vendor-managed Azure Data Lake Storage Gen2 in per-customer isolated containers, in one of BI Pixie's three production regions: East US 2, West Europe, or Central India. New customers are placed in the region closest to the Fabric capacity assigned to the first workspace from which the customer created the BI Pixie Workload item; Enterprise tier customers may select a specific region for vendor-managed storage to meet data-sovereignty requirements. The BI Pixie Cloud isolation and encryption commitments apply to this storage.

Identity and Conditional Access

The workload uses Microsoft Entra ID exclusively. Frontend tokens are acquired through the Fabric Workload Client SDK and exchanged via the standard On-Behalf-Of (OBO) flow against Entra. The workload frontend contains no MSAL library, no third-party cookies, and no custom OAuth flows; the backend OBO exchange uses Microsoft's standard MSAL library against the Entra token endpoint. Because every token operation goes through Entra, the Conditional Access policies your tenant applies (MFA, compliant-device, named-location, sign-in risk, session controls) are evaluated at session acquisition and at each OBO exchange. See Attestation §2.1 and §2.3.

Data storage

Dashboard semantic model and report items live in your Fabric workspace per Microsoft's standard storage model for Fabric items. A per-customer per-workspace Lakehouse provides a OneLake shortcut to your telemetry for queryability inside Fabric. The item-definition JSON, which enables automatic provisioning of the BI Pixie Dashboard's Fabric items into your workspace, contains only scope and tenant pointers (never the full tracking configuration) and is stored via Fabric's control-plane item-definition API. Raw telemetry events at rest are documented in Attestation §2.2, including why the vendor-managed storage is used for the ingest path.

Storage access

Access to the customer's dedicated vendor-managed container uses two mechanisms, each scoped to a distinct consumer:

• Per-customer RBAC. Used by the BI Pixie backend to act on the customer's behalf when serving requests from the workload UI inside the Fabric portal, bounded to two scopes: (a) the customer's dedicated container in the vendor-managed storage, accessed via the backend's Managed Identity; and (b) the report and semantic-model definitions in Power BI Service, accessed under the user's own Power BI workspace roles via the standard On-Behalf-Of flow. The backend reads and writes only what the signed-in user is already authorized to access in their Power BI tenant.
• Customer-scoped SAS tokens. Issued to the BI Pixie Dashboard items that are auto-provisioned in your Fabric workspace when you create a BI Pixie item. The dashboard connects directly to the customer's container in the vendor-managed storage using a scoped, expirable, revocable SAS token; no BI Pixie service is in that request path.

Enterprise tier: customers may issue separate RBAC assignments and separate SAS tokens to different teams and users within their organization, supporting least-privilege separation.

B2B and cross-tenant collaboration

B2B guest users in a Fabric workspace authenticate exactly as native users. The OBO token reflects the guest user's home tenant; Fabric workspace RBAC governs whether they see the BI Pixie item. Per-license RBAC inside the BI Pixie data plane is granted to the AAD object IDs of users your admin authorizes, so guests gain access through the same flow as primary users. See Attestation §2.5.

Retention and deletion

Retention is plan-controlled and self-service. Maximum retention by tier: Trial 14 days, Standard 30 days, Pro 1 year, Enterprise 3 years (see Privacy Policy §8). Telemetry events in the vendor-managed storage are automatically deleted daily once they exceed your retention window. Dashboard and report items live in OneLake under your Fabric tenant and remain under your control; BI Pixie does not initiate deletion of those items. End-user-level deletion (for GDPR DSARs) is supported via the Data Management view in the BI Pixie Portal; see the Data Management user guide.

Business continuity

Customer-portal monitoring and diagnostics are surfaced for the workload variant. BCDR plans and Service Health and Availability are documented in the Attestation under §2.6 and §5.3.

Compliance and certification

BI Pixie implements SOC 2-aligned controls in the Security and Confidentiality trust service categories (Attestation §4.4). The workload is published per the Microsoft Fabric Workload Hub vendor attestation requirements; the full attestation document is the authoritative source.

Reference: Microsoft Fabric Workload Vendor Attestation (full document) · BI Pixie Workload FAQ: Data and Privacy

Sub-Processors

Sub-processors are third parties we engage to process customer data on our behalf. The list below applies to the BI Pixie Cloud and BI Pixie Workload deployment models. For BI Pixie on Azure and BI Pixie on Power Platform deployments, we have no access to customer data and therefore engage no sub-processors on the customer's behalf. Your own sub-processor relationships govern.

The authoritative sub-processor list and the customer-data scope it applies to are maintained in our Privacy Policy §7. We will provide reasonable advance notice of any material changes to this list.

Audits and Assessments

We maintain an internal security-assessment program covering dependency scanning, static analysis (SAST), Azure posture review, dynamic scanning (DAST), API security, multi-tenant isolation, and GDPR controls. Continuous-integration gates enforce the dependency-scan and SAST baselines on every pull request:

• Dependency Audit: pip-audit on all backend Python services and npm audit on the customer portal and Fabric workload frontend, blocking on high-severity findings.
• Static Analysis: Semgrep on application code (Python and TypeScript, with OWASP Top 10 + secrets rule packs) and Checkov on Bicep infrastructure templates; baselines are triaged with documented suppressions for each accepted-risk finding.

For the BI Pixie Workload variant, our compliance posture is published in detail in the Microsoft Fabric Workload Vendor Attestation per Microsoft's publishing requirements.

DataChant has not engaged a third-party auditor for SOC 2 Type II at this time and will reassess as customer requirements warrant. Under a non-disclosure agreement, we can share additional artifacts from the internal assessment program with prospective enterprise customers on request. Email support@bipixie.com.

Vulnerability Disclosure

If you believe you have discovered a security vulnerability in BI Pixie, please report it to support@bipixie.com. We will acknowledge receipt within two business days. Please do not publicly disclose the issue until we have had a reasonable opportunity to investigate and remediate.

We do not currently operate a paid bug-bounty program. We do gratefully acknowledge responsible disclosure on request.

Contact

• Security and procurement questions: support@bipixie.com
• Privacy inquiries: support@bipixie.com (per Privacy Policy §15)
• General support: support@bipixie.com

BI Pixie is operated by DataChant Consulting LLC.