Trust Center

BI Pixie is operated by DataChant Consulting LLC, an Illinois limited liability company. “BI Pixie” is the company’s registered assumed name. 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.

The Microsoft Entra permissions BI Pixie requests in your own tenant are listed on a separate page for each hosted deployment, with the reason each permission is needed and what BI Pixie reads and writes under it: BI Pixie Cloud and BI Pixie Workload in Microsoft Fabric. Both are written for an administrator or a security reviewer who has no BI Pixie account, so they can be forwarded to whoever approves access.

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

At a Glance

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

These are two separate choices, and most organizations do not answer them the same way. A customer can run BI Pixie on Azure inside their own subscription and still use BI Pixie Cloud for AI Readiness. Read one row from each table below, then see “Combining deployments” for what that combination means.

Who operates the platform

The platform is the software that adds Pixies to your reports, scores your semantic models, and serves the BI Pixie Dashboard.

Deployment	Operated by	Our role	AI Readiness	Authoritative reference
BI Pixie Cloud	BI Pixie	Data processor	Available	Privacy §3-9, Terms §6
BI Pixie Workload in Microsoft Fabric	BI Pixie, running inside your Fabric tenant	Software vendor, and data processor for raw telemetry	Available	BI Pixie Workload attestation
BI Pixie on Azure (managed app)	You	Software vendor only	Not available	Privacy §10.1
BI Pixie on Power Platform	You	Software vendor only	Not available	Privacy §10.2

The AI Readiness column is the one that changes your trust position, because it is the reason a customer who already runs BI Pixie inside their own tenant would add a BI Pixie-operated deployment alongside it.

Where each kind of data lives

Storage is a separate decision from the table above. Customers on BI Pixie Cloud or the Workload may keep their telemetry in their own storage instead of ours.

Data	BI Pixie storage (default)	Your Azure storage	Your OneLake
Telemetry events	Our Azure, in the region assigned to your account	Your ADLS Gen2 account	Your Fabric capacity
Report and semantic model definitions	Not stored	Not stored	Not stored
AI Readiness assessment results	Our Azure	Not written to our storage, and not written to yours: BI Pixie does not write assessment results into your ADLS Gen2 account. You see the full result when the assessment finishes, and there is nothing kept for you to reopen later. We record the score and the number of findings, and we do not record the findings themselves.	Your Fabric capacity, in the same place as your telemetry, and you can reopen the full result there. We record the score and the number of findings so you can track them over time, and we do not record the findings themselves.
BI Pixie Dashboard items	Not applicable	Not applicable	Your Fabric capacity
Our access to that store	Operations and support only, per the Privacy Policy	Write, to deliver your telemetry. Read only if you grant it, through a credential you can revoke. No delete or retention permission unless you choose to grant that too.	Write, to deliver your telemetry into your lakehouse. Read only if you grant it. No delete or retention permission.

We do not store report or semantic model definitions in any deployment. BI Pixie reads a definition in order to instrument it or score it, and does not retain it afterwards.

What the telemetry contains does not vary with where it is stored. BI Pixie collects anonymized usage events and no business data from inside your reports. End-user identity and filtered values are off by default, and enabling either requires an explicit opt-in. Raw IP addresses are never retained; they are hashed at ingestion. See Privacy §3-4. We do not mine your telemetry, train models on it, or use it for advertising or profiling.

Wherever your data lives, scoring a semantic model reads its definition through BI Pixie’s service. Where you have chosen your own storage, the assessment result is not written to ours. Those are two different statements, and both are true: we do not store your report and semantic model definitions, and we do process them in order to score them.

BI Pixie hands a finished AI Readiness result back to you through our own storage. The assessment runs in the Azure region assigned to your account, and BI Pixie writes the finished result to a job record in our storage so that the portal or the Fabric workload can collect it. For an account that has declared its own storage, BI Pixie splits that job record in two. The copy carrying your findings is deleted within one day. The copy that remains holds the score, the number of findings, and the names of the semantic model and its workspace. For those accounts that handover is the one point at which the findings rest in our storage, and they are not kept there.

Combining deployments

The two tables are independent, so a customer can appear in both. The combination that needs the clearest answer is a customer who operates BI Pixie themselves and adds a BI Pixie-operated deployment for AI Readiness.

In that case the “we have no access to your data” position of the self-operated deployments applies to that deployment only. The AI Readiness service reads semantic model definitions from your Power BI tenant under your own user’s permissions, and where you have declared your own storage it will not write the finished assessment into ours. Read the Where each kind of data lives table for the deployment you added, not the one you started with.

Platform controls

Control	Self-operated (Azure, Power Platform)	BI Pixie-operated (Cloud, Workload)
Encryption	Your own Azure-managed or Power Platform encryption	TLS 1.2 or above in transit, AES-256 at rest, Azure-managed
Sign-in	No BI Pixie sign-in. The only relevant login is the Power BI service, using your tenant’s Entra ID, to view the BI Pixie Dashboard.	Your Entra ID. The Workload inherits Conditional Access through the Fabric host.
Service-to-service access	Connection strings by default. You can supply your own Key Vault, or swap to managed identity and access controls under your tenant policies.	Per-customer access controls using a managed identity, plus customer-scoped tokens that are expirable and revocable for direct dashboard access.

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.

That statement covers this deployment on its own. If you also use BI Pixie Cloud or the BI Pixie Workload for AI Readiness, the trust position for that second deployment is described in Where each kind of data lives above, and it is not the same. See “Combining deployments”.

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 regions for deployment. Data never leaves the regions you select. This is governed entirely by your tenant configuration; BI Pixie 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. It transmits your account email, your license key, and an inventory of the reports you instrumented. That inventory lists each report by its workspace name and report name, along with the number of pages it contains. No report content, no telemetry, and no 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. The trust posture is the same as BI Pixie on Azure, with the deployment running on Microsoft Power Platform rather than on Azure directly.

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

This is the 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 limited to your account email, your license key, and an inventory of the reports you instrumented. 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 two production regions: East US 2 or West Europe. Further geographies, including India and South Asia, are provisioned on customer request within 30 business days. 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 left to application logic. It is enforced by Azure’s identity platform, through 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 two production Azure regions: East US 2 and West Europe. Further geographies, including India and South Asia, are provisioned on customer request within 30 business days. 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. We also 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: Free 30 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 · Data Processing Agreement · 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

The workload has 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 two production regions: East US 2 or West Europe, or in a further geography provisioned on request. 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: Free 30 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

Customer-Owned Storage

Customers on BI Pixie Cloud or the BI Pixie Workload may keep their telemetry in their own storage rather than ours. This is a storage decision, not a deployment change: BI Pixie still operates the platform, and the Who operates the platform table above still describes our role. What changes is where your data lives and what we are able to do to it.

Two destinations are supported: your own Azure Data Lake Storage Gen2 account, and your own OneLake in Microsoft Fabric.

What we can do to your storage

Two kinds of access are worth separating, because they are granted differently.

Writing your telemetry is what delivery means. BI Pixie writes your events into the store you chose, and that is the whole purpose of the arrangement.

Reading your telemetry is optional and is yours to grant. Without it, the self-service Data Management tools and the Event Viewer do not work over your own store, and we never read your data. See Privacy Policy §2.3 for the same statement in the policy.

Deleting your telemetry is something we cannot do. We hold no delete or retention permission, so we cannot remove your data and we cannot apply a lifecycle policy to it.

There is one exception, and it is one you choose. On your own Azure storage you may additionally grant BI Pixie delete permission so that in-product deletion works for you, for example to erase one end user’s data for a GDPR request. If you do not grant it, deletion in the product is unavailable rather than silently failing. On your own OneLake we never hold it at all, and you manage deletion yourself in your lakehouse.

The credential, and how you revoke it

For your own Azure storage you choose the mechanism:

Mechanism	What it is	How you revoke it
Federated identity (default)	A cross-tenant federated credential. No secret is stored on our side.	Remove the role assignment in your own tenant.
Shared access signature	A token you generate and give us.	Rotate the storage key, or let the token expire.

For your own OneLake, access runs through your Fabric workspace and is governed by your Fabric permissions.

Where an AI Readiness result goes when you have declared your own storage

This is the control that most often goes unstated, so it is worth stating plainly. When you have declared your own storage, BI Pixie does not write a finished AI Readiness assessment into BI Pixie storage. Where it goes instead depends on which storage you chose, and the two answers are genuinely different.

On your own OneLake, BI Pixie writes the full result into your lakehouse, in the same place as your telemetry, and reads it back from there whenever you open it. The only lasting copy is the one in your own Fabric capacity, under your own Fabric permissions.

On your own Azure storage, BI Pixie writes the result nowhere. We do not write assessment results into your ADLS Gen2 account, so you see the full result when the assessment finishes and there is nothing to reopen afterwards. If keeping your assessments is what you want, your own OneLake is the option that does it.

In both cases we record the score and the number of findings, and never the findings themselves. The one exception is the handover described in Where each kind of data lives above: the job record that carries a finished result back to you is deleted within one day, and what remains after that holds the score and the counts.

If you have declared your own storage and BI Pixie cannot reach it at that moment, the assessment is still not written to ours. It is skipped, and you can run it again.

The honest boundary: scoring a semantic model means reading its definition through BI Pixie’s service, so the definition is processed by us even where the result is never stored with us. We do not retain the definition afterwards, in any deployment.

Sub-Processors

Sub-processors are third parties that process customer data through BI Pixie. 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.

Microsoft Azure and Stripe are companies we engage. OpenAI and Anthropic are AI providers you can connect yourself, and BI Pixie calls neither of them until an administrator on your account has connected one.

Sub-Processor	Purpose	Data involved	Applies to
Microsoft Azure	Infrastructure hosting, storage, identity, monitoring	All customer data in scope	BI Pixie Cloud, BI Pixie Workload
Stripe	Payment processing	Billing contact and payment metadata only; card details are never stored on BI Pixie servers	BI Pixie Cloud, BI Pixie Workload (Stripe-billed plans only)
OpenAI	Drafting AI Readiness text and reviewing AI benchmark answers, for the semantic models you select	Semantic model definition content, plus the specific business data values listed in Privacy §3.7. No telemetry event records and no end-user identifiers	BI Pixie Cloud, BI Pixie Workload, and only while you have connected your own OpenAI key
Anthropic	Drafting AI Readiness text and reviewing AI benchmark answers, for the semantic models you select	Semantic model definition content, plus the specific business data values listed in Privacy §3.7. No telemetry event records and no end-user identifiers	BI Pixie Cloud, BI Pixie Workload, and only while you have connected your own Anthropic key

OpenAI and Anthropic are engaged by you, not by us. You decide whether to connect either company, you hold the account with it, you supply the credential, and your own agreement with that company governs what it does with the request. They are listed here so that your reviewers can see every third party that receives your content through BI Pixie, whoever engaged it. Removing the connection on the Account page stops every such call.

Two further AI provider options are not listed above, because neither sends your content to a company outside Microsoft. Azure AI Foundry runs in your own Azure subscription, and the BI Pixie data agent runs on your own Microsoft Fabric capacity.

The authoritative sub-processor list and the customer-data scope it applies to are maintained in our Privacy Policy §7, and Privacy §3.7 states in full what BI Pixie sends to a connected AI provider and what it never sends. 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, an Illinois limited liability company. “BI Pixie” is the company’s registered assumed name, filed with the Illinois Secretary of State on 2026-09-02.

---