Power BI Audit – Was Unternehmen wirklich prüfen sollten

Der Vertriebsbericht zeigt einen anderen Umsatz als das Controlling. Eine Aktualisierung scheitert regelmäßig, und niemand weiß genau, wer außerhalb des Teams auf die Daten zugreifen kann. Ein Power BI Audit klärt die Zusammenhänge: Wie verlässlich ist eure Reporting-Landschaft, wo entstehen Risiken und welche Verbesserungen haben Vorrang? Hier erfährst du, welche sechs Prüffelder dazugehören, wie du Nachweise bewertest und aus Befunden konkrete Maßnahmen ableitest.

Was ist ein Power-BI-Audit?

Ein Power-BI-Audit ist eine strukturierte Prüfung von Berichten, semantischen Modellen, Berechtigungen und Betriebsprozessen. Es verbindet technische Befunde mit fachlichen Anforderungen und wirtschaftlichen Folgen. Das Ergebnis ist eine priorisierte Maßnahmenliste mit Verantwortlichen, Terminen und überprüfbaren Abnahmekriterien.

Das Power BI Activity Log ist eine Datenquelle für das Audit. Es dokumentiert Aktivitäten. Ob eine Umsatzdefinition korrekt, ein Zugriff fachlich gerechtfertigt oder ein Bericht für Entscheidungen geeignet ist, muss zusätzlich geprüft werden. Ein technisches und organisatorisches Audit ist dabei nicht automatisch eine formale Zertifizierung.

Power BI Audit vorbereiten: Prüfauftrag und Umfang festlegen

Beginnt mit den Entscheidungen, die eure Berichte unterstützen: Monatsabschluss, Vertriebssteuerung oder operative Disposition. Daraus ergeben sich Anforderungen an Richtigkeit, Aktualität, Verfügbarkeit und Vertraulichkeit. Ein selten genutzter Jahresabschlussbericht kann wichtiger sein als ein täglich geöffnetes Dashboard.

Legt Umfang und Stichprobe fest: Welche Workspaces, Apps, Modelle, Datenquellen und Nutzergruppen werden untersucht? Gehören vorgelagerte Fabric-Komponenten dazu? Welche Zeiträume decken die Protokolle ab? Dokumentiert ausgeschlossene Bereiche und fehlende Nachweise.

Prüft ihr die gesamte Umgebung, gehören relevante Tenant-Einstellungen dazu. Das sind übergreifende Regeln etwa für externe Freigaben, Exporte und API-Zugriffe. Erfasst auch technische Identitäten wie Service Principals, über die Anwendungen oder Automatisierungen zugreifen: Wer verantwortet sie, welche Rechte benötigen sie und wie werden Zugangsdaten erneuert? Bei einem begrenzten Berichtsreview müssen diese Themen zumindest als Abhängigkeit oder ausgeschlossener Prüfbereich sichtbar sein.

Jeder Befund braucht Sollzustand, Nachweis und Auswirkung. „Das Modell ist zu groß“ bleibt eine Behauptung. „Unbenötigte Detailspalten beanspruchen nachweislich Speicher; der Refresh verfehlt das vereinbarte Bereitstellungsfenster“ ist ein überprüfbarer Ausgangspunkt. Ob die Spalten das Zeitproblem verursachen, muss die Analyse erst zeigen.

Die folgenden sechs Prüffelder bilden den Orientierungsrahmen der Daten-WG. Er verbindet fachliche, technische und organisatorische Fragen; Umfang und Prüftiefe richten sich nach eurem konkreten Auftrag.

1. Kennzahlen und Datenqualität: Sind die Kennzahlen fachlich richtig?

Prüft zuerst geschäftskritische Kennzahlen. Für Umsatz, Marge oder Auftragsbestand müssen Definition, Datenquelle, zeitlicher Bezug und fachliche Verantwortung klar sein. Vergleicht ausgewählte Ergebnisse mit abgestimmten Referenzwerten aus dem Quellsystem.

Ein Beispiel: Der Vertrieb zählt Auftragseingänge, das Controlling gebuchte Rechnungen. Beide Berichte nennen die Kennzahl „Umsatz“. Keine DAX-Optimierung löst diesen Unterschied. Erst müssen Definitionen und Beschriftungen geklärt werden.

Zur Stichprobe gehören Stornos, fehlende Zuordnungen, Periodenwechsel und Filterkombinationen. Prüft die Gesamtsumme ebenso wie einzelne Gesellschaften oder Produkte. Eine passende Gesamtsumme kann Fehler in Teilmengen verdecken.

Ein erfolgreicher Refresh beweist keine fachliche Datenqualität. Dokumentiert deshalb Referenzfall, erwartetes Ergebnis, tatsächlichen Wert und Erklärung einer Abweichung.

2. Datenmodell und DAX: Ist die Logik nachvollziehbar und wartbar?

Das semantische Modell verbindet Tabellen, Beziehungen und Berechnungen. Prüft die Granularität, also was eine einzelne Datenzeile darstellt: beispielsweise einen Auftrag oder eine Rechnungsposition. Dazu kommen Filterrichtungen, Datentypen und zentrale Measures, also mit DAX definierte Berechnungen.

Ein Sternschema schafft häufig eine gut nachvollziehbare Grundlage: Dimensionstabellen wie Kunde oder Kalender strukturieren das Filtern; Faktentabellen enthalten Geschäftsvorfälle und Messwerte. Viele-zu-viele-Beziehungen oder bidirektionale Filter brauchen eine begründete Verwendung und Tests ihrer Auswirkungen. Sie sind nicht grundsätzlich falsch.

Prüft auch, warum identische Kennzahlen in mehreren Modellen existieren und wie Änderungen konsistent bleiben. Die Wahl zwischen Import, DirectQuery und gegebenenfalls Direct Lake muss zu Aktualitätsbedarf, Datenvolumen, Quellsystem und Betriebsbedingungen passen.

Im Audit zählt zusätzlich, ob ein zweites Teammitglied die wesentlichen Berechnungen erklären und sicher verändern kann.

3. Sicherheit und Berechtigungen: Wer kann tatsächlich auf welche Daten zugreifen?

Eine Rollenliste reicht nicht. Prüft Workspace-Rollen, App-Zielgruppen, direkte Freigaben, Gruppenmitgliedschaften und externe Gäste. Entscheidend ist, welche Rechte eine Person über alle Zuweisungen tatsächlich erhält.

Unterscheidet dabei die Modellberechtigungen: Read ermöglicht die Nutzung vorhandener Inhalte. Build erlaubt unter anderem eigene Auswertungen auf dem Modell und Analyze in Excel. Reshare ermöglicht die Weitergabe von Modellzugriff. Write erlaubt Änderungen am Modell. Prüft für jede Berechtigung, wer sie benötigt und wodurch sie vergeben wurde. Das Entziehen von Build allein schützt sensible Modelldaten nicht zuverlässig.

Row-Level Security, kurz RLS, begrenzt sichtbare Datenzeilen, etwa auf eine Region. RLS schränkt Workspace-Admins, Members und Contributors nicht ein. Auch Schreibrechte am Modell sind gesondert zu berücksichtigen. Der folgende Vergleich zeigt, warum eine passende RLS-Regel nur zusammen mit den effektiven Berechtigungen beurteilt werden kann.

Prüft zusätzlich Regeln der Datenquelle und den tatsächlich verwendeten Zugriffsweg.

Mehrere RLS-Rollen wirken additiv: Gehört jemand zu den Rollen Nord und Süd, können beide Datenbereiche sichtbar werden. Testet deshalb auch kombinierte Gruppenzuweisungen. Sollen bestimmte Tabellen oder Spalten verborgen bleiben, ist Object-Level Security, kurz OLS, ein eigener Prüfpunkt. Das bloße Ausblenden einer Spalte im Modell ersetzt diesen Schutz nicht.

Verwendet repräsentative Benutzerkonten und testet erlaubte ebenso wie unerlaubte Datenbereiche. Bezieht tatsächlich genutzte Exporte, Excel-Verbindungen und andere Zugriffswege ein. Ein Test als Entwickler ersetzt den Zugriffstest aus Anwendersicht nicht.

Kontrolliert außerdem „Publish to web“-Freigaben. Diese machen Inhalte ohne Anmeldung öffentlich zugänglich; betroffen sein können auch nicht sichtbar dargestellte Modelldaten. Vertrauliche Unternehmensdaten gehören dort nicht hinein.

4. Performance und Betrieb: Funktioniert Power BI unter realen Bedingungen?

Messt typische Nutzeraktionen: Bericht öffnen, Zeitraum wechseln, Detailansicht aufrufen. Dokumentiert Datenstand, Filter, Benutzerrolle und ob zwischengespeicherte Ergebnisse verfügbar waren. Ergänzt gleichzeitige Nutzung und kritische Lastfenster, beispielsweise den Monatsabschluss mit parallel laufenden Aktualisierungen. Vereinbart dafür realistische Antwortzeiten und Bereitstellungsfristen mit dem Fachbereich.

Der Performance Analyzer hilft, Ladezeiten nach Abfrage und Darstellung einzugrenzen. Die Server Timings in DAX Studio liefern zusätzliche Informationen zu Abfragen, sofern Verbindung und erforderliche Rechte verfügbar sind. Solche Einzelmessungen müssen im Zusammenhang mit der produktiven Gesamtlast beurteilt werden.

Untersucht Refresh-Verläufe, Gateway-Abhängigkeiten und gegebenenfalls inkrementelle Aktualisierung. Gateways verbinden den Dienst mit bestimmten Datenquellen, etwa im Unternehmensnetz. Wird der benötigte Datenstand rechtzeitig erreicht? Wer reagiert auf Fehler, und funktioniert die Vertretung?

Zum Betrieb gehören kontrollierte Änderungen und ein erprobter Wiederherstellungsweg. Lasst für ein kritisches Modell oder einen Bericht zeigen, wie eine geprüfte Version wiederhergestellt wird und welche Verbindungen oder Einstellungen danach erforderlich sind.

Wie ihr technische Engpässe eingrenzt, beschreibt unser Beitrag Power BI Performance optimieren. Das Audit ergänzt diese Diagnose um Betriebsverantwortung und Geschäftsauswirkung.

5. Nutzung und Governance: Helfen die Berichte im Arbeitsalltag?

Kombiniert Nutzungsdaten mit Gesprächen im Fachbereich. Welche Entscheidung unterstützt der Bericht? Sind Zeitraum, Einheit und Datenstand erkennbar? Können Anwender Abweichungen erklären? Entstehen daneben Excel-Auswertungen, weil Begriffe oder Filter unverständlich bleiben?

Viele Aufrufe beweisen keinen Nutzen; wenige Aufrufe beweisen keine Überflüssigkeit. Klärt bei selten genutzten Inhalten zunächst saisonale Aufgaben, Empfängerkreise und Abhängigkeiten. Erst danach lässt sich über Zusammenlegen oder Stilllegen entscheiden.

Zur Governance gehören benannte Verantwortliche für Bericht, Modell und Kennzahlen, verständliche Freigaberegeln und der geregelte Umgang mit veralteten Inhalten. Ein kritischer Bericht, den nur eine Person warten kann, bleibt betrieblich anfällig.

6. Lizenzen und Kapazität: Passt der Aufwand zum tatsächlichen Bedarf?

Prüft Lizenzzuweisungen und Kapazitäten zusammen mit Nutzerrollen, Inhaltsverteilung und Lastprofilen. Wo vorhanden, unterstützt die Fabric Capacity Metrics App die Untersuchung von Verbrauch, Lastspitzen und Drosselungen.

Betrachtet auch wiederholte Datenaufbereitung, unnötige Aktualisierungen und parallel gepflegte Modelle. Bevor mehr Kapazität gekauft wird, braucht es eine Erklärung des Engpasses. Umgekehrt darf eine Sparmaßnahme die vereinbarte Verfügbarkeit nicht gefährden.

Unser Beitrag Microsoft Fabric Kosten verstehen vertieft die Einordnung. Einsparpotenziale sollten im Audit als belegte Szenarien mit Annahmen ausgewiesen werden.

Power BI Audit Checkliste: Prüffragen und Nachweise

Die folgende Checkliste übersetzt die sechs Prüffelder in überprüfbare Aufgaben. Übertragt relevante Zeilen in euren Maßnahmenplan und ergänzt Zuständigkeit, Termin und Status. Ein Prüfpunkt ist erst abgeschlossen, wenn sein Kriterium nachgewiesen ist. Nicht anwendbare Punkte brauchen eine Begründung; fehlende Nachweise bleiben offen.

Prüffrage	Erforderlicher Nachweis	Erledigungskriterium
Stimmen kritische Kennzahlen?	Abgestimmte Referenzfälle mit Soll- und Istwerten	Werte stimmen innerhalb fachlich vereinbarter Toleranzen; Abweichungen sind geklärt.
Ist das Modell nachvollziehbar?	Prüfung von Zeilenebene, Beziehungen und Berechnungen	Zentrale Logik ist erklärt; kritische Filterfälle sind getestet.
Passen die effektiven Zugriffe?	Berechtigungsmatrix und Tests mit Zielkonten	Erlaubte Daten sind erreichbar; unzulässige Zugriffe scheitern.
Wirken RLS und gegebenenfalls OLS wie vorgesehen?	Tests der Rollen, Kombinationen und geschützten Datenbereiche	Sichtbare Zeilen, Tabellen und Spalten entsprechen dem Soll.
Passen übergreifende Freigaben und technische Zugriffe?	Relevante Tenant-Einstellungen und Identitäten mit Rechtebegründung	Unzulässige Freigaben sind beseitigt; notwendige Rechte und Verantwortung sind dokumentiert.
Ist der Betrieb unter Last verlässlich?	Messungen bei vereinbarter gleichzeitiger Nutzung, Refresh- und Kapazitätsdaten	Antwortzeiten und Datenbereitstellung erfüllen die vereinbarten Anforderungen.
Funktionieren Fehlerreaktion und Wiederherstellung?	Dokumentierter Alarmierungs- und Wiederherstellungstest	Zuständige reagieren; die geprüfte Version funktioniert wieder.
Sind Nutzen und Verantwortung geklärt?	Nutzungsdaten, Fachgespräch und benannte Zuständige	Entscheidung, Pflege und Vertretung sind nachvollziehbar geregelt.
Passen Lizenzen und Ressourcen?	Zuordnung von Nutzern, Lizenzen und Last sowie Vergleichsszenario	Bedarf ist begründet; Anpassungen gefährden vereinbarte Leistungen nicht.

Für das Inventar können Scanner APIs Berichte, Modelle und verfügbare Metadaten erfassen. Sie benötigen eine administrative Einrichtung und liefern je nach Konfiguration unterschiedliche Details. Fachlich korrekte Kennzahlen bestätigen sie nicht.

Plant auch die Protokollhistorie: Die Activity-Events-API erlaubt Abfragen innerhalb der letzten 28 Tage, jeweils innerhalb desselben UTC-Tages. Für längere Analysen muss die Historie rechtzeitig gesichert werden. Diese API-Grenze beschreibt nicht sämtliche Aufbewahrungsfristen anderer Audit-Dienste.

Vom Befund zur Maßnahme: Was kommt zuerst?

Bewertet Geschäftsauswirkung, betroffenen Nutzerkreis, Dringlichkeit und Abhängigkeiten. Erst danach folgt der Umsetzungsaufwand. Das nächste Schaubild ordnet typische Befunde nach ihrem Handlungsbedarf ein. Es hilft bei der Priorisierung; konkrete Fristen ergeben sich aus dem jeweiligen Risiko.

Maßnahmen können parallel laufen, wenn Zuständigkeiten und Abhängigkeiten geklärt sind.

Wie daraus ein nachverfolgbarer Auftrag wird, zeigt dieser vollständig fiktive Fall. Die Namen und Termine dienen nur der Veranschaulichung und sind keine allgemeine Fristvorgabe.

Bestandteil	Beispielbefund
Sollzustand	Regionalleitungen dürfen ausschließlich Vertriebsdaten ihrer eigenen Region lesen.
Beleg	Am 8. September 2026 zeigt die Berechtigungsprüfung Contributor-Rechte über eine Gruppe. Ein Test mit dem Nord-Konto liefert auch Datensätze der Region Süd. Rollenstand, Konto, Testzeit und Ergebnis sind dokumentiert.
Auswirkung und Priorität	Vertrauliche Vertriebsdaten sind außerhalb des vorgesehenen Empfängerkreises zugänglich. Akuter Handlungsbedarf.
Maßnahme	Betroffenen Zugriff sofort eindämmen. Anschließend direkte und geerbte Bearbeitungsrechte korrigieren, benötigten Lesezugriff einrichten und RLS-Zuweisungen prüfen.
Verantwortlicher	Anna Beispiel, verantwortlich für den Workspace; der Vertriebsbereich bestätigt die fachliche Zugriffsmatrix.
Termin	Eindämmung am 8. September; Korrektur und dokumentierter Nachtest bis 9. September 2026, 12 Uhr.
Nachtest und Abnahme	Das Nord-Konto sieht über alle freigegebenen Zugriffswege die erwarteten Nord-Daten. Süd-Daten bleiben gesperrt, auch bei kombinierten Gruppenmitgliedschaften. Testergebnis und fachliche Abnahme werden abgelegt.

Ein Befund ist erst nach erfolgreichem Nachtest erledigt. Zum Audit-Abschluss gehören außerdem der geprüfte Umfang, offene Einschränkungen und eine Maßnahmenliste, deren Bearbeitung jemand nachhält.

Häufige Fragen zum Power-BI-Audit

Wie oft sollte ein Audit stattfinden?

Plant wiederkehrende Prüfungen nach Kritikalität und Änderungstempo. Größere Modelländerungen, neue externe Empfänger oder Plattformwechsel können zusätzliche Reviews auslösen. Laufendes Monitoring ergänzt diese Prüfungen.

Lässt sich das Audit automatisieren?

Inventarisierung, Log-Auswertung und Teile der technischen Prüfung lassen sich automatisieren. Fachliche Kennzahlendefinitionen und geschäftlich gerechtfertigte Berechtigungen verlangen zusätzlich Abstimmung und Tests.

Wie lange dauert ein Power-BI-Audit?

Das hängt von Umfang, Modellkomplexität, verfügbaren Nachweisen und Prüftiefe ab. Vereinbart zunächst Stichprobe und erwartete Ergebnisse. Ein Einzelberichtsreview und eine Prüfung der gesamten Umgebung sind unterschiedlich große Aufgaben.

---

Fazit: Verlässlichkeit braucht überprüfbare Nachweise

Ein Power BI Audit zeigt, ob Kennzahlen fachlich stimmen, Zugriffe zum tatsächlichen Bedarf passen und der Betrieb zuverlässig funktioniert. Dazu gehören auch klare Verantwortlichkeiten, nachvollziehbare Modelle und ein begründeter Ressourceneinsatz. Ein technisches Inventar allein beantwortet diese Fragen noch nicht.

Entscheidend ist, was aus den Befunden folgt. Ein wirksames Audit verbindet jedes relevante Problem mit einer konkreten Maßnahme, einer verantwortlichen Person und einem überprüfbaren Ergebnis. Erst der Nachtest zeigt, ob die Verbesserung im Arbeitsalltag trägt.

---

Nächste Schritte: Mit einem kritischen Bericht starten

Wenn Kennzahlen widersprüchlich sind, Zugriffe unklar bleiben oder Aktualisierungen wiederholt scheitern, beginnt mit einem geschäftskritischen Bericht samt Modell, Datenversorgung und Berechtigungen. Nutzt die Checkliste und leitet daraus wenige klar verantwortete Maßnahmen ab.

Im Power BI Coaching arbeiten wir mit euch an diesen konkreten Berichten und Modellen. Gemeinsam klären wir Ursachen, setzen Verbesserungen um und verankern das Wissen im Team, damit aus einem Audit-Befund eine dauerhaft verlässlichere Lösung wird.