Data Processing Agreement

This DPA describes how DataChant Consulting LLC ("BI Pixie", "we") processes the Customer's engagement telemetry on the Customer's behalf in the Cloud deployment model. It governs that telemetry whether or not a given record is personal data: the security, data-residency, access-scoping, no-sale, and deletion commitments below apply to all of it, while the obligations that apply specifically to personal data (data-subject categories, data-subject rights, and breach notification) apply to any personal data the telemetry contains. This DPA applies to all three telemetry storage locations the Cloud model offers (BI Pixie storage, OneLake delivery, and Bring Your Own Storage (BYOS); see Section 4). On any conflict about the processing of Customer telemetry, this DPA governs.

What decides whether this DPA applies is BI Pixie's access to your data, not the deployment type. This DPA applies whenever you use BI Pixie Cloud and BI Pixie therefore accesses your data. That includes BYOS (Section 4.3): your data stays in your own storage and BI Pixie never stores it, but you connect BI Pixie Cloud to that storage and grant scoped access to read, search, and (if you opt in) delete, at your direction, to power the self-service Data Management features. Because BI Pixie accesses your data, this DPA governs that access (scoping, security, breach, deletion) even though the data never rests in BI Pixie storage.

This DPA does NOT apply only when you run a self-hosted deployment entirely on its own, with no connection to BI Pixie Cloud (the Self-Hosted Azure Managed App or Power Platform, used standalone). In that case BI Pixie has zero access and is neither a controller nor a processor, so no DPA from BI Pixie is required and you are solely responsible. See Privacy Policy Section 2.

1. Parties and Roles

• Customer: the controller of the engagement telemetry collected by their Power BI reports (the data subjects are the Customer's report viewers, "end users").
• DataChant Consulting LLC ("BI Pixie", "we"): a processor acting on the Customer's documented instructions for end-user telemetry data, and an independent controller for Customer administrator account data (e.g. admin email, display name, tenant ID, audit logs) that we need to operate the service. That controller processing is governed by the Privacy Policy, not this DPA.

2. Subject Matter, Nature, and Purpose

• Subject matter: processing of end-user engagement telemetry (and the narrow operational metadata BI Pixie writes to render its surfaces).
• Nature & purpose: collecting, storing (or, for OneLake delivery / BYOS, optionally reading at the Customer's direction), and surfacing telemetry so the Customer can analyze report engagement (Event Viewer, Data Management, dashboards) and count reports + end users for license enforcement. For OneLake delivery / BYOS, the dashboard analytics run on the Customer's own Fabric capacity using items BI Pixie instantiates (see Section 4), not on BI Pixie's infrastructure.
• Duration: for the term of the subscription, until the Customer revokes access or closes the account.

3. Categories of Data and Data Subjects

• Data subjects: the Customer's Power BI report viewers ("end users").
• Categories: engagement telemetry (page views, visual clicks, filter selections, NPS/feedback), report/workspace identifiers, and end-user identifiers. Not all of this is personal data: aggregate metrics and report/workspace identifiers may not identify an individual, whereas end-user identifiers do. The handling commitments in this DPA apply to all of it; the personal-data-specific obligations apply to the end-user identifiers and any other personal data it contains. End-user identifiers may be email-shaped or hashed depending on the Customer's configuration. BI Pixie applies PII-minimizing handling (for example, identifiers are truncated in operational logs), consistent with the BI Pixie security documentation, which is available to customers on request.

4. Telemetry Storage Location (Cloud)

The Cloud model offers three locations for where the Customer's telemetry is stored. The Customer chooses; the processing role above is unchanged, but who holds the data at rest differs:

4.1 BI Pixie storage (default)

BI Pixie stores the telemetry in a dedicated, RBAC-isolated Azure Storage container per customer. BI Pixie automatically places it in the BI Pixie region closest to the Customer's Power BI home region (Cloud) or Fabric capacity region (Fabric workload), from BI Pixie's available regions; the Customer does not pick the region. No other customer can access it; isolation is enforced by the Azure identity platform. This is the default and the scope of Privacy Policy Sections 3–9.

4.2 OneLake delivery

BI Pixie's pipeline collects the telemetry and delivers it to the Customer's own Microsoft Fabric OneLake (their lakehouse) instead of retaining it in BI Pixie storage. The data at rest lives in the Customer's Fabric tenant; BI Pixie does not store it. The Customer may optionally grant scoped, revocable read-only access so BI Pixie can power the self-service Data Management tools and Event Viewer over the Customer's own data. That access is opt-in; without it, BI Pixie never reads the data. For OneLake delivery this access is read-only: BI Pixie can view and search the telemetry but never deletes or alters it, and the Customer manages any deletion in their own lakehouse.

4.3 Bring Your Own Storage (BYOS)

The Customer hosts their own telemetry web trigger and the events land directly in the Customer's own Azure Data Lake Storage Gen2 account; the telemetry never enters BI Pixie infrastructure and BI Pixie does not store it. The Customer may optionally grant the scoped read / operational-write access described in Section 7 so BI Pixie can power the self-service Data Management tools and Event Viewer over the Customer's store. That access is opt-in and revocable. BYOS is available on Enterprise plans.

BI Pixie performs no destructive operations (delete, retention cleanup, auto-trim, archive) against a Customer's own store unless explicitly enabled; the Customer owns their data lifecycle. These limits are enforced by technical controls in BI Pixie's software, and BI Pixie never deletes a Customer's own data to enforce a usage or license limit.

How deletion and retention work depends on the surface:

• SaaS portal (BYOS): a BYOS Customer MAY explicitly opt into a "read + delete" tier so they can use BI Pixie's Data Management tools to delete events in their own store (e.g. GDPR erasure of a data subject, or removing a report's history). When and only when the Customer grants delete (a SAS with delete permission, or the Storage Blob Data Contributor RBAC role) and opts in, BI Pixie may issue delete operations against the Customer's store at the Customer's direction. The Customer remains the controller of the deletion decision; BI Pixie supplies the controls. The grant is revocable and exists only while granted.
• Fabric Workload (BYOS and OneLake delivery): the Customer's telemetry is also processed into a Lakehouse and a Power BI semantic model on the Customer's own capacity (next paragraph), so deleting only the raw store would be incomplete. BI Pixie therefore offers no deletion in the Workload and does not ask for delete permission there. Instead, BI Pixie provides customer-run notebooks that the Customer runs on their own Fabric capacity to delete, and to apply retention, across all layers (raw + Lakehouse + model). BI Pixie does not perform that deletion or retention and is not a processor for it.
• OneLake delivery: BI Pixie's access is read-only; the Customer manages deletion and retention in their own Fabric environment (the customer-run notebooks above).

Analytics and dashboards run on your own Fabric capacity (OneLake delivery / BYOS). For these options, the dashboards and analytics are produced by Microsoft Fabric items that BI Pixie installs into the Customer's own Fabric workspace: a notebook reads the telemetry from the Customer's OneLake, processes it, and writes the results to the Customer's own lakehouse, and a Power BI semantic model the Customer owns then consumes that lakehouse. These items run on the Customer's own Fabric capacity, not on BI Pixie's infrastructure. BI Pixie only provides and instantiates the item definitions (their logic); it does not itself read or process the Customer's data through them, and is not a processor for that processing (comparable to software the Customer runs in their own tenant). The same applies to the customer-run deletion/retention notebooks. BI Pixie acts as a processor only for the optional self-service access it performs from its own side (Event Viewer and search; and, in the SaaS portal only, BYOS deletion per Section 7), and only while the Customer grants that access.

5. Sub-processors

BI Pixie will give the Customer prior notice of any new sub-processor with access to Customer telemetry and an opportunity to object.

6. Confidentiality, Security, and Logging

• Telemetry at rest is encrypted (Azure Storage Service Encryption, AES-256); all transit uses TLS 1.2+. Service-to-service auth uses Azure Managed Identity (no stored connection strings); secrets use Azure Key Vault with soft-delete.
• BI Pixie never logs event content or full storage paths; audit logs record only the action, a truncated license key, the actor, and (for OneLake delivery / BYOS) the storage account host.
• Personnel with access are bound by confidentiality obligations.

7. Optional Access: Mechanism, Scoping, and Revocation (OneLake delivery / BYOS)

This Section applies where the Customer's telemetry lives in the Customer's own store (OneLake delivery or BYOS). Granting BI Pixie access to that store is entirely optional. A Customer can use OneLake delivery or BYOS with no grant at all, in which case the telemetry simply lands in the Customer's own store and BI Pixie never reads it. A Customer grants access only to turn on the optional self-service Data Management features (Event Viewer and search; plus deletion for BYOS in the SaaS portal only; the Workload offers no deletion) over their own data. The read + delete tier (BYOS, SaaS portal only) is a further, separate opt-in.

• Access is granted by the Customer to a storage-scoped principal: either a federated (RBAC) role assignment (recommended; secret-free, true-revoke) or a Customer-supplied, container-scoped, read+list SAS capped at 90 days (validated server-side: account/service-level SAS rejected, sr=c, sp includes r+l, future se).
• For the optional read + delete tier (BYOS, SaaS portal only), the Customer widens the grant they choose: a SAS that also includes delete (sp includes d, still container-scoped and capped at 90 days, validated server-side), or the Storage Blob Data Contributor RBAC role. (The Workload never requests delete; OneLake delivery has no delete tier; both are read-only, with deletion via the customer-run notebooks.) The heightened access is exactly what the Customer grants and is revocable the same way.
• A SAS, if used, is held only in BI Pixie's access-controlled storage / secret store, is never returned to any client and never logged. RBAC is the secret-free primary method (BI Pixie stores no Customer credential at rest for an RBAC grant).
• Confused-deputy controls: the storage account host is validated against an exact <account>.(dfs|blob).core.windows.net allow-pattern at save time and re-validated at use time; an account already registered to a different customer is rejected; a live tenant-equality probe (from the serving identity) confirms the account belongs to the Customer's home tenant before access is exercised.
• Revocation: the Customer may revoke at any time by removing the RBAC role or letting the SAS expire, and (for BYOS) may switch the account back to BI Pixie storage in-product, which also revokes BI Pixie's read access. Effective revocation latency for RBAC is governed by Azure (typically minutes).

8. Data Residency and International Transfer

• BI Pixie storage: BI Pixie automatically assigns the region closest to the Customer's Power BI home region (Cloud) or Fabric capacity region (Fabric workload), from BI Pixie's available regions; all telemetry is stored exclusively in that region and does not cross regional boundaries.
• OneLake delivery / BYOS: the Customer's telemetry remains in the Customer's own storage account / Fabric tenant and region. BI Pixie reads it from its own region via scoped credentials and does not copy or relocate it into BI Pixie storage. (Event history that predates a switch to OneLake delivery or BYOS is not migrated; new telemetry flows only to the Customer's store.)
• For international transfers, BI Pixie relies on Microsoft's Data Processing Agreement and Standard Contractual Clauses where applicable.

9. Personal Data Breach

If BI Pixie becomes aware of a personal data breach affecting Customer telemetry it holds (BI Pixie storage), or of a breach affecting the credentials it holds for the Customer's own store (OneLake delivery / BYOS), or of unauthorized access exercised through them, it will notify the Customer without undue delay (and within any period required by applicable law), describe the scope, and (for OneLake delivery / BYOS) revoke the affected credential.

For OneLake delivery / BYOS the breach scope is bounded to the access the Customer granted:

• Read / read + list (default; the only mode for OneLake delivery): the exposure is limited to reading the Customer's telemetry; a compromised credential cannot delete or alter the Customer's data.
• Read + delete (BYOS, SaaS portal only, where the Customer opted into self-service deletion): the credential the Customer granted also carries delete, so a compromise could additionally delete events in the Customer's store. BI Pixie holds such a credential only while the Customer keeps the tier enabled; the Customer can shrink the scope at any time by revoking delete (narrowing the SAS, or removing the Contributor role) while keeping read access. (The Workload never holds a delete-capable credential.)

10. Return and Deletion

• BI Pixie storage: on termination, BI Pixie permanently deletes the Customer's dedicated storage container and all telemetry within it after the grace period described in the Terms of Service. The Customer may also delete individual end users' data through the self-service Data Management tools at any time.
• OneLake delivery / BYOS: BI Pixie does not hold the Customer's telemetry, so there is nothing to return or delete in BI Pixie storage; on termination BI Pixie's access is revoked and no further reads occur. The Customer retains and controls their own data throughout.

11. Audit

The Customer may, on reasonable notice, request information sufficient to demonstrate compliance with this DPA (the capability policy, validation rules, and logging posture described above), consistent with the BI Pixie security documentation.