A financial reporting team had built their dashboards. They worked. Stakeholders loved them. Then the auditor asked one question: "can you produce an access log showing exactly which advisor viewed which client's portfolio report last quarter, and when?"

That question, answerable in different ways depending on how reports are shared, is where most financial services Power BI deployments either pass audit or don't.

This post walks through what compliant sharing actually requires in financial services, where standard Power BI Pro setups fall short, and what a compliant alternative looks like. Aimed at heads of BI, IT security leads, and compliance officers in banks, asset managers, fund administrators, and fintech firms.

Why sharing Power BI reports is difficult in financial services

Power BI handles dashboards equally well for a bank, an asset manager, or an agency. The technology isn't the problem. What surrounds the dashboard is.

Financial services firms operate under requirements that other industries don't face at the same intensity: regulators inspecting access patterns, auditors requiring user-level activity trails, data residency rules that constrain where reports can be hosted, and third-party risk assessments that determine whether a vendor is even allowed in your stack.

A working dashboard isn't enough. The full delivery chain, authentication, authorization, audit, hosting, vendor risk, needs to pass the same scrutiny as the underlying data. That delivery chain is where Power BI Pro alone often falls short.

If your firm is already evaluating these questions, our financial services overview walks through the specific patterns we see across asset managers, fund administrators, and banks.

What compliance requirements must Power BI sharing meet?

The exact requirements depend on your jurisdiction and entity type, but a typical financial services compliance baseline includes five categories:

Identity and authentication controls

Every user who accesses a financial dashboard must be authenticated against an identity system your firm controls. That means single sign-on through SAML or Azure Entra, with multi-factor authentication enforced. Username-and-password without MFA doesn't meet most compliance frameworks for sensitive data.

For external users, advisors, clients, regulators, this is where standard Power BI sharing breaks down. We'll come back to this.

Row-level security per user

A senior advisor at a wealth management firm needs to see only their own clients' holdings, not their colleagues'. A regional risk analyst sees only their region's exposure. A regulator sees only what they're entitled to under their reporting agreement.

This requires row-level security applied at the individual user level, not just at the report level. The same dashboard renders different data depending on who's looking at it, with the filtering enforced server-side, not in the browser. We covered four architecture patterns for multi-tenant RLS in a separate post, the patterns matter because some look secure but aren't.

Audit trail and logging

Auditors don't accept "users accessed reports." They want: which user, which report, which client view, what time, from which IP, for how long, and what they did during the session. Retained for a defined period (often 7 years for financial firms in the EU).

Standard Power BI Service offers some logging, but the granularity needed for financial services audits typically requires a more capable layer on top.

Data residency and tenant isolation

Where does report data physically live? Which jurisdictions can access it? Is it co-tenant with other firms' data, or isolated? Many financial services firms, especially those serving multiple jurisdictions, have strict data residency requirements. Some auditors will flag any setup where firm data could theoretically be accessed by another tenant on shared infrastructure.

The architecture of your Power BI distribution layer determines whether you can answer "where is the data" with one clear sentence or whether you have to write a memo.

Third-party vendor security

Any platform that touches financial data is subject to vendor due diligence. That typically means SOC 2 Type II certification (or ISO 27001 equivalent), security questionnaires, evidence of pen-testing, and ongoing monitoring agreements. Vendor that handles report distribution falls in this scope.

A platform "DataTako does not access the underlying report data" is a significant simplifier here, it changes the risk surface materially compared to a platform that proxies through your data.

Where Power BI Pro falls short for financial services

Power BI Pro was designed for sharing reports inside a single Microsoft 365 tenant, typically the employees of one company. For internal-only reporting in an in-house team, Pro works well. For financial services delivery to external advisors, clients, regulators, and partners, Pro has structural limits.

External users need Microsoft accounts

Pro licenses are per user, and every viewer needs a Microsoft 365 (or standalone Pro) account. For a wealth management firm with 200 advisors at partner brokerages, that means provisioning Microsoft identities for all of them, or guest-inviting them into your tenant. Both create vendor-onboarding overhead for the external users' employers.

For regulators or one-off audit access, the friction is higher, temporary Microsoft accounts feel disproportionate to the task.

Microsoft branding undermines client trust

Reports shared via Power BI Service show up inside the Power BI Service interface, with Microsoft branding, Microsoft URLs, and Microsoft navigation. For a private bank delivering monthly portfolio statements to clients, this conflicts with the white-glove brand experience clients are paying for. The client wonders why their wealth manager's reports look like a Microsoft product.

This isn't aesthetic, it's a positioning problem in an industry where presentation signals professionalism.

Limited audit log granularity

Power BI Pro's audit logs cover broad events (a user accessed a workspace). For financial audits that need to demonstrate user-by-user access to specific report views with timestamps and session durations, you typically need to combine Power BI logs with Azure Monitor and other Microsoft logs, which is doable but expensive in setup and maintenance time.

No native row-level security at the multi-tenant level

Pro supports RLS within a single dataset, but managing RLS across many client populations, each advisor seeing only their own clients, isolated from other advisors, typically requires architecture work beyond what Pro provides natively. For a deeper comparison of how the licensing models compare, see our Pro vs Premium vs Embedded breakdown.

Beyond compliance, there's also a cost dimension to the per-user model that we covered separately in the hidden cost of Power BI Pro for BI agencies, the same per-user math applies to financial services firms with large external user populations.

What does compliant Power BI sharing actually look like?

The pattern that consistently passes audit in financial services has five components:

Use Power BI Embedded instead of Pro for external sharing

Power BI Embedded uses an "App owns data" authentication model: the application (your distribution platform) holds the Power BI license, and end users authenticate against your identity system, not Microsoft's. This eliminates the per-user Microsoft account requirement for external viewers entirely.

For the full technical picture, see our Power BI Embedded in 2026 guide.

Implement RLS at the user level, not just the role level

Role-based RLS ("all advisors see all clients") is easier to set up but doesn't meet financial services audit standards. User-level RLS ("advisor X sees only clients assigned to advisor X") is the pattern that passes. For multi-tenant architectures, common in fund administration, wealth management, and outsourced reporting, you also need clean separation between client populations, not just rows.

Microsoft's RLS documentation covers the basic model. Where it gets complex is when one user belongs to multiple client populations, or when access changes mid-quarter.

Use enterprise authentication

SAML 2.0 or Azure Entra integration with MFA enforced. Email-and-password without MFA doesn't typically pass financial services security review. The authentication layer should sit between your identity provider and the report, meaning if you revoke a user in your IdP, their access disappears immediately across all reports.

Maintain detailed audit logs with retention policies

Audit logs should capture user identity, report identity, view timestamp, session duration, source IP, and any actions taken in the session. Retention should match your firm's compliance retention requirements (typically 5-7 years for financial firms in the EU under MIFID II).

Vet your distribution platform's own security posture

The platform that distributes your reports is part of your vendor risk surface. Key questions: Does it access the underlying data, or just embed the rendered report? What certifications does it hold (SOC 2, ISO 27001)? Where does it host data? What's the breach notification protocol? Is the architecture multi-tenant or dedicated?

Our security and privacy page covers DataTako's posture on these questions in detail.

How DataTako helps financial services meet these requirements

DataTako is a distribution layer on top of Power BI Embedded, designed for organizations that need to share reports externally without per-user Microsoft accounts and with stronger control over identity, security, and branding.

For financial services specifically, four design choices matter:

Embedded distribution without Microsoft accounts for viewers

End users authenticate against whichever identity system your firm uses, Azure Entra, SAML 2.0, Google, email-and-password with MFA. No Microsoft account required for advisors, clients, or regulators. Onboarding a new external user is provisioning in your IdP, not a Microsoft licensing transaction.

Sub-organizations for client and advisor separation

DataTako's sub-organization model lets you create isolated environments per client, per fund, per advisor team, or per jurisdiction. Each sub-organization can have its own branding, its own user population, its own access rules. From a compliance perspective, this provides clear tenant isolation without architectural complexity.

Built-in audit logging

User-level access logs across all reports, with timestamps, session details, and retention controls. Exportable for audit responses. Configurable retention periods to match your firm's requirements.

DataTako does not access underlying report data

This is the design choice that materially changes vendor risk. DataTako proxies the rendered embed token, it doesn't read, store, or process the data inside your reports. From an auditor's perspective, this narrows the scope of vendor risk substantially compared to a platform that accesses or caches data.

For a fuller product overview, see how DataTako works.

Compliance checklist for sharing Power BI in financial services

A pragmatic checklist to evaluate any Power BI distribution setup against financial services compliance baselines:

• Authentication runs through your IdP (SAML, Azure Entra, or equivalent) with MFA enforced
• Row-level security is configured at user level, not just role level
• External users do not require Microsoft accounts to view reports
• Audit logs capture user, report, timestamp, IP, and session for every view
• Audit log retention matches your firm's compliance retention requirement
• Data residency is documented and matches your regulatory obligations
• Vendor holds current SOC 2 Type II or ISO 27001 certification
• Vendor architecture isolates your data from other tenants
• Vendor does not access, store, or process your report data
• Revoking a user in your IdP immediately revokes report access
• White-label delivery is supported per client or fund
• Multi-jurisdiction reporting can be separated cleanly (sub-organizations per region)

If your current setup fails three or more of these, the gap to audit-ready is meaningful, and worth evaluating alternatives before your next compliance review.

Frequently asked questions

Is Power BI Embedded GDPR-compliant?

Power BI Embedded can be configured to meet GDPR requirements, but compliance is a property of the full deployment, not the technology alone. Key GDPR considerations include data residency (where reports are hosted and processed), the lawful basis for processing personal data shown in reports, data subject rights (access, deletion), and breach notification capabilities. DataTako runs on Microsoft Azure infrastructure with EU data residency available, and does not access underlying report data, which simplifies the GDPR data processor analysis materially.

How do I implement RLS for advisors with overlapping clients?

User-level RLS in Power BI handles this through filter expressions tied to user identity. The pattern: a security table maps user IDs to client IDs, and the RLS rule on the client dimension filters to clients linked to the current user. Advisors with multiple clients see all of theirs; clients aren't visible to advisors who don't manage them. The setup is straightforward technically, the complexity is keeping the user-client mapping in sync with your CRM or internal directory as advisor assignments change. DataTako's sub-organization model can simplify this when advisor teams correspond to distinct client populations.

What audit logs does DataTako provide?

User-level access logs covering: which user authenticated, which report they viewed, when the session started and ended, source IP, and any export actions taken. Logs are retained according to configurable retention policies and are exportable for audit response. For deeper questions about audit log capabilities, see our security and privacy page.

Where is the report data stored, does it leave our tenant?

Report data stays in your Power BI environment. DataTako does not access, store, or cache the underlying data, it proxies the embed token that authorizes your authenticated user to view a report rendered from your own Power BI capacity. From a data residency perspective, your data never leaves your Microsoft tenant. Vendor due diligence reviewers typically find this materially easier to assess than a platform that processes data server-side.

Does DataTako have SOC 2 or ISO 27001 certification?

This is one of the standard questions in financial services vendor due diligence. Reach out via the contact form or your account team for current certification status, security questionnaire responses, and supporting documentation.

What about MIFID II reporting requirements?

MIFID II imposes transaction reporting and record-keeping requirements that are largely about the data captured and reported, not about the visualization layer. However, MIFID II's record-keeping requirements (typically 5-7 year retention) extend to records of who accessed what reporting, when. Setting up audit log retention to match MIFID II requirements and confirming your distribution layer's retention capabilities is a standard part of MIFID II-aligned Power BI deployments.

Can we revoke a user's access mid-quarter without rebuilding our setup?

Yes, if your access flow runs through your IdP. Revoking the user in Azure Entra (or your SAML provider) immediately revokes their access across all DataTako-distributed reports. This is one of the practical reasons IdP-integrated authentication beats per-user Microsoft account provisioning: revocation is a single action in one system, not a coordinated change across vendors.

‍