Power BI FCA compliance : Meeting FCA and SOX Audit Requirements
Compliance in Power BI is roughly 20% platform capability and 80% configuration - the platform can pass an FCA or SOX audit, but only if it's been set up to.
A financial reporting team builds a set of dashboards. Stakeholders love them. Then an auditor asks one question: can you produce an access log showing exactly which advisor viewed which client's portfolio report last quarter, and when? That single question - answerable in wildly different ways depending on how the reports were shared and configured - is where most financial services Power BI deployments quietly pass or fail an exam, long before anyone asks about the numbers in the dashboards themselves.
This guide covers what FCA and SOX actually expect from a Power BI estate specifically, why the platform's underlying capability doesn't automatically translate into compliance, and the specific configuration patterns - row-level security design, deployment pipelines, activity log retention - that separate a deployment that passes examination from one that doesn't.
The Question That Ends Most Audits Fast
Financial services firms operate under scrutiny most other industries don't face at the same intensity: regulators inspecting access patterns directly, auditors requiring user-level activity trails rather than aggregate statistics, and data residency rules that constrain where reports can even be hosted. A working dashboard that stakeholders love is not, on its own, evidence of anything to an examiner. The full delivery chain - authentication, authorisation, audit, hosting - has to withstand the same scrutiny as the underlying financial data itself, and that's precisely where a Power BI deployment configured for usability but not for audit tends to fall short.
Two Regulatory Lenses, One Platform
FCA and SOX aren't asking the same question, even though the underlying platform requirements overlap substantially. FCA, as the UK's financial conduct regulator, is primarily concerned with conduct risk, data integrity, and the ability to reconstruct records during supervisory review - it's asking whether your systems can prove what happened. SOX, under Section 404 specifically, is primarily concerned with internal controls over financial reporting - it's asking whether your systems prevent the wrong thing from happening in the first place, particularly around who can change a number that ends up in a financial statement. A Power BI estate built for one of these lenses tends to satisfy most of the other's requirements too, because both ultimately demand the same underlying capability: a complete, tamper-evident record of who did what, to which data, and when.
What FCA Actually Expects From Your BI Systems
The FCA Handbook doesn't name Power BI specifically, but its supervision expectations apply directly to any system a regulated firm uses to produce or store the data behind its regulatory reporting. The Supervision manual (SUP) sets the core expectation: firms must maintain systems capable of reconstructing records and producing audit trails on request, whether for a routine periodic report or an active investigation. SUP 15.3 goes further, imposing a duty to notify the FCA immediately of anything that could affect a firm's regulatory standing - explicitly including data integrity failures or control breakdowns, which means a governance gap in your BI estate isn't just an internal risk, it can itself become a notifiable event if discovered without warning. The General provisions module (GEN) reinforces that weak data controls carry real legal and financial weight, not just reputational risk.
What SOX Actually Expects From Your BI Systems
SOX Section 404 requires documented internal controls over any system that touches financial reporting, and a BI platform sitting between core financial systems and the numbers that ultimately reach a 10-K or board pack is squarely inside that scope. The two SOX-specific requirements that matter most for a BI deployment are separation of duties - the person who can modify a report or dataset in development should not be the same person who can push it to production without review - and audit trail immutability. A log stored in a mutable database, however detailed its entries, fails under SOX and SEC frameworks by design, because the whole point of the control is proving the record wasn't altered after the fact, not just that an entry exists somewhere.
Five Configuration Patterns That Pass Audit
Power BI has the underlying capability to satisfy both regimes - the gap is almost always configuration, not the platform itself.
The Retention Trap Most Deployments Miss
The most common gap we see in financial services Power BI deployments isn't a missing control - it's a control that exists but doesn't retain evidence long enough. Retention windows vary by regulation and by the specific record type, but they consistently run to multiple years, not the weeks Power BI's native activity data keeps by default. A firm that can demonstrate perfect row-level security and a clean deployment pipeline today, but can't produce last year's access log because it aged out of the platform's native retention, still fails the audit - the control existed, but the evidence of it having worked didn't survive long enough to prove it.
Meeting a multi-year retention requirement means extracting Power BI's Activity Events API output into permanent, external, immutable storage - not adjusting a setting inside Power BI itself, because no setting inside the platform extends its native retention that far. This is infrastructure a governance layer needs to own independently of the reporting layer it's monitoring.
A Sample Audit Response Checklist
| Examiner asks | Evidence you need ready |
|---|---|
| Who accessed this client's data last quarter, and when? | User-level activity log, exported and retained beyond Power BI's native window |
| Could Advisor A have seen Client B's portfolio? | Documented RLS design showing user-level, not role-based, filtering |
| Who approved this report's move into production? | Deployment pipeline history showing dev/test/prod separation and named approvers |
| Was this sensitive data classified before publishing? | Sensitivity label audit trail via Purview, showing mandatory not optional application |
| Can you prove this log wasn't altered after the fact? | Immutable, external storage - not a query against Power BI's own live activity data |
- FCA and SOX ask different core questions - FCA about reconstructing records and conduct risk, SOX about internal controls preventing unauthorised change - but both ultimately require the same underlying capability: a complete, tamper-evident record of who did what, to which data, and when.
- Compliance in Power BI is roughly 20% platform capability and 80% configuration - the platform can pass either audit, but only if RLS, deployment pipelines, and logging are deliberately configured for it.
- User-level row-level security is the pattern that passes financial services audits; role-based RLS ("all advisors see all clients") does not, however convenient it is to set up.
- Deployment pipelines with genuine dev/test/production separation are the most direct way Power BI satisfies SOX's separation-of-duties requirement.
- The most common gap isn't a missing control - it's Power BI's native activity log retention window expiring long before the multi-year retention most financial regulations actually require, which means extraction to external, immutable storage is a required part of the architecture, not an optional add-on.
Numlytics' Power BI Governance Intelligence Platform extracts every action from Microsoft's own Activity Events API into a permanent, audit-ready ledger in Azure Data Lake - purpose-built to close the retention gap that trips up most financial services Power BI deployments during examination. Our Power BI consulting practice has implemented regulatory reporting governance for regional banks, insurance carriers, and investment firms. Speak with a certified consultant about assessing your own FCA or SOX audit readiness.