Der entscheidende Punkt: Power Pages ist ein Datenportal-Werkzeug, keine Homepage-Software. Wo ein gewöhnlicher Webbaukasten dafür gemacht ist, Marketing-Seiten, Blogs und Broschüren-Websites zu erstellen, liegt die Stärke von Power Pages darin, externe Nutzer mit Ihren strukturierten Daten interagieren zu lassen: Sie füllen Formulare aus, sehen den Status ihres Anliegens, laden Dokumente hoch, verwalten ihr Konto. Diese Ausrichtung auf datengebundene, transaktionale Portale ist der größte praktische Unterschied zu allem, was man umgangssprachlich als „Website-Baukasten“ kennt – und die Quelle vieler Missverständnisse, denn Power Pages ist weder ein Ersatz für die klassische Unternehmenswebsite noch ein simples Klick-Werkzeug ohne konzeptionellen Aufwand.
Power Pages ist kein isoliertes Produkt, sondern ein Baustein der Microsoft Power Platform – der Low-Code-Familie, zu der auch Power Apps für Anwendungen, Power Automate für Automatisierung und Power BI für Auswertungen gehören. Was diese Bausteine verbindet, ist die gemeinsame Datenplattform Dataverse. In Power Apps entstehen die internen Anwendungen für die eigenen Mitarbeitenden, in Power Pages die externe Öffnung derselben Datenwelt für Menschen außerhalb der Organisation. Beide arbeiten auf denselben Daten – das ist der eigentliche Hebel.
Der Kern des Nutzens lässt sich in einem Satz fassen: Power Pages schließt die Lücke zwischen den Daten, die ohnehin im Unternehmen liegen, und den Menschen außerhalb, die mit diesen Daten arbeiten sollen. In vielen Organisationen bleiben Vorgänge an der Unternehmensgrenze stehen: Kunden rufen an, um den Status einer Bestellung zu erfragen, Partner schicken Formulare per E-Mail, Antragsteller warten auf Rückmeldung, weil niemand ihnen einen Selbstbedienungs-Zugang bieten kann. Power Pages öffnet genau diese Grenze kontrolliert: Ein externer Nutzer meldet sich an, sieht nur die für ihn bestimmten Daten und erledigt sein Anliegen selbst.
Besonders wertvoll ist das für Vorgänge, die heute manuell und telefonisch abgewickelt werden: Statusabfragen, Terminanfragen, Formularabgaben, Dokumenten-Uploads. Aus einem Telefonanruf im Service wird ein Self-Service-Vorgang im Portal – und aus einer E-Mail-Flut mit Anhängen ein strukturierter Datensatz in Dataverse, der direkt weiterverarbeitet werden kann.
Wer sich mit der Materie beschäftigt, stößt schnell auf einen älteren Namen: Power Apps Portals. Das ist kein anderes Produkt, sondern der Vorläufer von Power Pages. Microsoft hat die Portal-Fähigkeiten der Power Platform, die zuvor als Teil von Power Apps unter dem Namen „Portals“ vermarktet wurden, in ein eigenständiges Produkt namens Power Pages überführt und dabei die Erstellungsumgebung modernisiert. Die technische Grundlage – die Bindung an Dataverse, das Konzept externer Nutzer, die Authentifizierung – blieb dabei im Kern erhalten. Für die Praxis heißt das: Vieles, was zu Power Apps Portals dokumentiert ist, gilt sinngemäß weiter, und bestehende Portale wurden auf die neue Plattform überführt. Wer historische Anleitungen liest, sollte diese Umbenennung im Hinterkopf behalten.
Das Herzstück der Erstellung ist das Design Studio – eine visuelle Oberfläche, in der ein Portal Schritt für Schritt zusammengesetzt wird. Statt HTML und CSS von Hand zu schreiben, arbeitet man mit Abschnitten und Komponenten: Man zieht eine Textspalte auf eine Seite, fügt ein Formular ein, das an eine Dataverse-Tabelle gebunden ist, oder eine Liste, die Datensätze anzeigt. Gestaltung, Datenanbindung, Seitenstruktur und Sicherheitseinstellungen werden in einer zusammenhängenden Umgebung bearbeitet. Das ist der Low-Code-Kern: Der Weg vom leeren Portal zur ersten funktionierenden Formularseite ist kurz.
Zugleich hat das Design Studio eine wichtige Eigenschaft, die es von reinen No-Code-Baukästen unterscheidet: Es öffnet sich nach unten zum Pro-Code. Wer über die vorgefertigten Komponenten hinaus will, kann eigenes HTML, CSS und JavaScript ergänzen und über die Template-Sprache der Plattform auf Daten zugreifen. Für den Mittelstand bedeutet das ein realistisches Modell: Die einfachen Fälle entstehen im Baukasten, für die anspruchsvollen steht der Weg zum Code offen – idealerweise mit fachlicher Begleitung.
Power Pages bringt Vorlagen mit, die typische Portal-Szenarien vorstrukturieren – etwa ein Kundenservice-Portal, ein Self-Service-Bereich oder eine Antrags- und Registrierungsstrecke. Eine Vorlage liefert eine sinnvolle Ausgangsstruktur aus Seiten, Formularen und Berechtigungen, die man an die eigenen Bedürfnisse anpasst, statt jeden Baustein selbst zu erfinden. Das beschleunigt den Einstieg spürbar – ist aber kein fertiges Produkt: Jede Vorlage muss auf das eigene Datenmodell, die eigenen Prozesse und die eigenen Datenschutz-Anforderungen zugeschnitten werden. Die Vorlage ist der Startpunkt, nicht das Ziel.
Die wichtigste Positionierungs-Aussage lautet: Power Pages ist untrennbar mit Dataverse verbunden. Ein Power-Pages-Portal ist im Kern eine sichere, externe Sicht auf Daten, die in Dataverse liegen. Wenn ein Kunde im Portal ein Formular ausfüllt, entsteht daraus ein Datensatz in einer Dataverse-Tabelle; wenn er seinen Status sieht, liest das Portal aus Dataverse. Diese Bindung ist der Grund, warum die eigentliche Arbeit an einem Portal weniger in der Gestaltung liegt als im Datenmodell und im Sicherheitskonzept dahinter. Wer das Datenmodell sauber aufsetzt, hat den größten Teil der Arbeit geleistet; das Portal ist dann die kontrollierte Oberfläche darauf.
Auf der sichtbaren Seite besteht ein Portal aus Seiten und den Elementen darauf. Seiten werden im Design Studio aus Abschnitten und Komponenten zusammengesetzt – Text, Bilder, Navigation. Die wirklich funktionalen Elemente sind aber die Formulare und Listen: Ein Formular ist an eine Dataverse-Tabelle gebunden und verwandelt die Eingaben eines externen Nutzers in einen strukturierten Datensatz, mit Pflichtfeldern, Validierung und – bei komplexeren Vorgängen – mehrstufigen Strecken über mehrere Schritte hinweg. Eine Liste zeigt umgekehrt Datensätze aus Dataverse an, gefiltert auf das, was der jeweilige Nutzer sehen darf.
Diese Bindung an Daten ist der springende Punkt: Ein Power-Pages-Formular ist kein Kontaktformular, das eine E-Mail verschickt, sondern eine kontrollierte Schreiboperation in Ihre Geschäftsdatenbank. Damit lassen sich echte Vorgänge abbilden – ein Antrag, eine Anmeldung, eine Statusänderung –, die nahtlos in die interne Weiterverarbeitung übergehen.
Die weniger sichtbare, aber sicherheitskritische Hälfte ist die Zugriffs- und Authentifizierungs-Schicht. Bevor ein externer Nutzer geschützte Daten sieht, muss er sich anmelden. Power Pages unterstützt dafür verschiedene Anmeldeverfahren – von der lokalen Registrierung über geschäftliche Konten bis zu externen Identitätsanbietern. Erst nach der Anmeldung greift die Zugriffssteuerung: Über Berechtigungen wird festgelegt, welche Seiten und welche Datensätze ein angemeldeter Nutzer sehen und bearbeiten darf. Ein Kunde soll seine eigenen Vorgänge sehen, nicht die eines anderen; ein Partner nur seine Aufträge.
Diese Berechtigungssteuerung ist der Punkt, an dem die größte Sorgfalt gebraucht wird – und an dem in der Praxis die folgenreichsten Fehler passieren. Ein falsch gesetztes Recht kann dazu führen, dass ein externer Nutzer Daten sieht, die nicht für ihn bestimmt sind. Weil es sich um externe, oft personenbezogene Daten handelt, ist ein solcher Fehler nicht nur ein Bug, sondern potenziell ein Datenschutz-Vorfall. Die Zugriffssteuerung gehört deshalb konzeptionell durchdacht und vor dem Produktivstart gründlich getestet – idealerweise mit realistischen Testnutzern in unterschiedlichen Rollen.
Die erste und unkritischste Rolle des Copilot ist die des Erstellungs-Assistenten. Statt jede Seite manuell aus Komponenten zusammenzusetzen, kann ein Maker in natürlicher Sprache beschreiben, was er braucht – etwa ein Portal, über das Kunden Serviceanfragen einreichen und ihren Status verfolgen –, und der Copilot schlägt eine Struktur vor: Seiten, Texte, passende Datentabellen und Formulare. Das verkürzt den Weg vom leeren Portal zum ersten funktionierenden Entwurf erheblich und senkt die Einstiegshürde für Fachbereiche, die kein Web-Wissen mitbringen.
Entscheidend ist die richtige Erwartung: Der Copilot liefert einen Entwurf, keine fertige Lösung. Er nimmt die mühsame Grundarbeit ab, aber die Feinarbeit an Datenmodell, Berechtigungen, Validierung und Erscheinungsbild bleibt Aufgabe des Menschen. Für den Mittelstand ist das genau die richtige Arbeitsteilung: schneller Start durch KI, verantwortete Fertigstellung durch die Fachkraft.
Die zweite Rolle ist heikler. Power Pages erlaubt es, einen Chat-Assistenten in das fertige Portal einzubetten, mit dem externe Nutzer interagieren – um Fragen zu beantworten oder durch Vorgänge zu führen, auf Basis hinterlegter Inhalte oder Daten. Der Nutzen liegt auf der Hand: Ein Self-Service-Portal, das Fragen selbst beantwortet, entlastet den Service. Der Vorbehalt ebenso: Sobald externe, oft nicht der eigenen Organisation zugehörige Personen mit einem KI-Assistenten interagieren, werden deren Eingaben verarbeitet – und je nach Konfiguration erhält der Assistent Zugriff auf Daten, die er den richtigen Personen zeigen und den falschen vorenthalten muss.
Für den DACH-Mittelstand heißt das: Ein nutzerseitiger Copilot im Portal ist kein Feature, das man einfach einschaltet, sondern eine Entscheidung mit Datenschutz-Dimension. Was darf der Assistent sehen? Was gibt er preis? Werden die Eingaben externer Nutzer gespeichert, und wenn ja, wie und wie lange? Diese Fragen gehören geklärt, bevor der Assistent live geht. Der Grundsatz ist derselbe wie bei der Zugriffssteuerung: Was nach außen offen ist, muss besonders sorgfältig eingegrenzt werden.
Neben der KI ist die Automatisierung der zweite Hebel, der ein Portal von einer Sammelstelle zu einem echten Prozess-Werkzeug macht. Über Power Automate lassen sich Portal-Ereignisse mit Abläufen verknüpfen: Reicht ein Kunde ein Formular ein, kann automatisch eine Benachrichtigung an den zuständigen Mitarbeitenden gehen, eine Freigabe angestoßen oder der Vorgang an ein internes System weitergereicht werden. So entsteht aus der reinen Datenerfassung ein durchgängiger, weitgehend automatischer Vorgang – vom externen Antrag bis zur internen Bearbeitung. Diese Verzahnung ist einer der stärksten Gründe, ein Portal überhaupt auf der Power Platform statt als isolierte Insellösung zu bauen.
Die wichtigste Integration ist zugleich die grundlegendste: Power Pages und die internen Power-Apps-Anwendungen greifen auf dieselben Dataverse-Daten zu. Das klingt technisch, hat aber eine enorme praktische Konsequenz. Wenn ein Kunde extern über das Portal einen Serviceantrag stellt, entsteht der zugehörige Datensatz nicht in einer separaten Portal-Datenbank, die später mit dem internen System abgeglichen werden müsste, sondern direkt in Dataverse – dort, wo die interne Bearbeitung ohnehin stattfindet. Es gibt keine Schnittstelle zu pflegen, keine Datenkopie, keinen Synchronisations-Aufwand. Was außen hereinkommt, ist innen sofort da.
Für den Mittelstand ist das der entscheidende Unterschied zu einer isolierten Portal-Lösung. Ein separat gebautes Kundenportal müsste über Schnittstellen an die internen Systeme angebunden werden – ein klassischer Kostentreiber und eine ständige Fehlerquelle. Power Pages umgeht das, weil die Datenwelt von vornherein geteilt ist.
Auf dieser geteilten Datenbasis entfaltet sich das Zusammenspiel mit den übrigen Power-Platform-Bausteinen. Power Apps liefert die interne Sicht: Mitarbeitende bearbeiten dort die Vorgänge, die extern über Power Pages hereinkommen, auf denselben Datensätzen. Power Automate verbindet beide Welten mit Abläufen: Eine externe Formularabgabe kann automatisch eine interne Aufgabe erzeugen, eine Freigabe anstoßen oder eine Benachrichtigung auslösen. So entsteht ein durchgängiger Prozess, der die Unternehmensgrenze überbrückt – von der externen Erfassung über die automatische Weiterleitung bis zur internen Bearbeitung, ohne Medienbruch.
Schließlich erbt Power Pages die Sicherheits-, Identitäts- und Compliance-Basis der Microsoft-Cloud. Anmeldung über geschäftliche Konten, die Verwaltung im vertrauten Administrations-Umfeld, die Compliance-Werkzeuge – all das stammt aus derselben Welt wie Ihre bestehende Microsoft-365-Umgebung. Für Häuser, die bereits auf Microsoft setzen, bedeutet das weniger neue Werkzeuge, weniger separate Verträge und einen konsistenten Sicherheits- und Datenschutz-Rahmen. Genau das macht Power Pages für M365-Häuser zur naheliegenden Wahl – während es für ein Unternehmen ganz ohne jede Microsoft-Bindung deutlich weniger überzeugt.
Die häufigste Fehleinschätzung entsteht aus dem Wort „Website“. Weil Power Pages Websites erstellt, wird es mit den Werkzeugen verglichen, die man für die Unternehmens-Homepage kennt – ein Content-Management-System wie die verbreiteten Redaktionssysteme oder ein Website-Baukasten. Diese Werkzeuge sind aber für einen ganz anderen Zweck gemacht: das Veröffentlichen und Pflegen von Inhalten – Seiten, Artikel, Bilder, Marketing-Botschaften, für ein breites, meist anonymes Publikum. Ihre Stärke liegt in der redaktionellen Arbeit und im Erscheinungsbild.
Power Pages ist für das Gegenteil optimiert: datengebundene Interaktion mit angemeldeten, externen Nutzern. Nicht das Veröffentlichen von Inhalten steht im Zentrum, sondern das kontrollierte Lesen und Schreiben von Geschäftsdaten durch bestimmte Personen. Ein CMS ist gut darin, hundert Blog-Artikel zu verwalten; Power Pages ist gut darin, tausend Kunden ihren jeweils eigenen Vorgangsstatus anzuzeigen. Wer diese Zweckbestimmung verwechselt, wählt das falsche Werkzeug.
Die Logik der Werkzeugwahl folgt dem Zweck, nicht dem Namen. Power Pages ist die richtige Wahl, wenn externe Menschen mit Ihren Geschäftsdaten interagieren sollen – ein Kundenportal mit Statusabfrage, ein Partner-Bereich mit Auftragsübersicht, eine Antrags- oder Registrierungsstrecke, ein Self-Service-Portal, über das Anliegen eingereicht und verfolgt werden. Überall dort, wo es um angemeldete Nutzer, strukturierte Daten und Vorgänge geht, spielt Power Pages seine Stärken aus, besonders wenn die Daten ohnehin in der Power Platform liegen.
Umgekehrt gilt: Für die klassische Marketing- und Unternehmenswebsite – die öffentliche Homepage mit Produktseiten, Blog, Referenzen und Kontaktformular – ist Power Pages das falsche Werkzeug. Diese Aufgabe erledigen ein Content-Management-System oder ein Website-Baukasten besser, schneller und günstiger, weil sie genau dafür gebaut sind: für redaktionelle Inhalte, gutes Erscheinungsbild und einfache Pflege durch Marketing-Teams. Ein reines Broschüren-Portal auf Power Pages zu bauen, wäre unnötig aufwändig und würde Stärken verschenken, die dort gar nicht gebraucht werden.
In vielen Mittelständlern ist deshalb die saubere Antwort keine Entweder-oder-Entscheidung, sondern eine Arbeitsteilung: Die öffentliche Website läuft auf einem CMS oder Baukasten, das datengebundene Kundenportal auf Power Pages. Beide erfüllen unterschiedliche Aufgaben und schließen sich nicht aus. Die Kunst liegt darin, den jeweiligen Zweck sauber zu trennen und das passende Werkzeug zuzuordnen.
Ein Vorteil, den viele unterschätzen, ist das Hosting-Modell. Power Pages ist ein von Microsoft betriebener Cloud-Dienst – Sie müssen keinen Webserver bereitstellen, keine Betriebssystem-Updates einspielen, keine Sicherheits-Patches selbst nachziehen. Die Infrastruktur, die Skalierung und die grundlegende Absicherung stellt Microsoft. Für den Mittelstand ohne große IT-Abteilung ist das ein echter Entlastungsfaktor: Man kümmert sich um das Portal und seine Daten, nicht um die Server darunter.
Der Preis dieser Bequemlichkeit ist die Cloud-Abhängigkeit: Das Portal läuft in Microsofts Umgebung, mit deren Vor- und Nachteilen. Wer aus regulatorischen Gründen zwingend selbst hosten muss, findet in Power Pages nicht das passende Werkzeug. Für die große Mehrheit der Mittelständler ist der betriebene Cloud-Dienst jedoch genau das, was gebraucht wird – vorausgesetzt, die Datenschutz- und Regions-Fragen aus Kapitel 09 sind geklärt.
Die Lizenzierung von Power Pages folgt einer eigenen Logik, die sich von der reinen Nutzerlizenz anderer Power-Platform-Produkte unterscheidet. Vereinfacht gilt: Ein Portal wird kapazitätsbasiert lizenziert, orientiert an der Nutzung – etwa daran, wie viele authentifizierte oder anonyme Besucher es hat. Die genaue Metrik und die Grenzen ändern sich und sollten aktuell bei Microsoft geprüft werden; die verlässliche Erkenntnis ist, dass die Kosten mit der Portal-Nutzung skalieren und nicht schlicht pro internem Mitarbeitenden abgerechnet werden. Das ist für die Planung wichtig, weil ein erfolgreiches, stark genutztes Portal auch entsprechend zu Buche schlägt. Details dazu im Kosten-Kapitel.
Im Mittelstand versickert viel Zeit an der Unternehmensgrenze: Kunden rufen an, um Auskünfte zu erfragen, die eigentlich in den Systemen stehen; Anträge kommen als E-Mail mit Anhängen und müssen manuell erfasst werden; Partner schicken Excel-Listen hin und her. Genau hier setzt Power Pages an – es automatisiert nicht den Vorgang selbst, sondern verlagert die Erfassung und Auskunft an den externen Nutzer, kontrolliert und strukturiert. Aus dem Telefonanruf wird ein Self-Service-Vorgang, aus der E-Mail ein sauberer Datensatz. Das macht Power Pages zu einem der Werkzeuge, deren Nutzen sich sowohl beim Kunden als auch im eigenen Team unmittelbar zeigt – ein starker Treiber für Akzeptanz.
Zugleich gilt für alle Szenarien dieselbe Grundregel: Ein Portal entlastet nur dann, wenn Datenmodell, Berechtigungen und Prozesse dahinter stimmen. Ein hübsches Portal auf einem chaotischen Datenmodell erzeugt neue Arbeit, statt sie zu sparen. Der Gewinn entsteht durch die saubere Konzeption, nicht durch das Portal allein.
Eine ehrliche Beratung benennt auch das Risiko. Ein externes Portal ist per Definition nach außen offen – es ist damit angreifbarer und sensibler als eine interne Anwendung. Es will nicht nur gebaut, sondern dauerhaft betrieben, überwacht und in seinen Berechtigungen regelmäßig geprüft werden. Wer ein Portal als einmaliges Projekt behandelt und danach sich selbst überlässt, riskiert veraltete Zugriffsrechte, unbemerkte Sicherheitslücken und Datenschutz-Probleme. Power Pages senkt die Hürde, ein Portal zu bauen – die Verantwortung für seinen sicheren Betrieb bleibt bestehen. Der größte Hebel ist deshalb nicht das schnelle Aufsetzen, sondern der disziplinierte Betrieb danach.
Bewusst nennt dieser Artikel keine konkreten Beträge. Microsofts Preise, Kapazitäts-Metriken und die Zuordnung von Funktionen zu Lizenzen ändern sich regelmäßig, unterscheiden sich nach Region und Vertragsform und sind über Rahmenvereinbarungen individuell verhandelbar. Jede hier genannte Zahl wäre womöglich morgen falsch und würde eine Scheingenauigkeit vortäuschen. Verlässlich ist die Kosten-Logik: eine kapazitätsbasierte Portal-Lizenz je Website, die Dataverse-Kapazität für die Daten, die einmaligen Umsetzungskosten für Konzeption und Bau sowie die laufenden Betriebs- und Governance-Kosten. Für eine belastbare Kalkulation gehört die aktuelle Preisliste – idealerweise über den eigenen Microsoft-Partner oder das Vertragswerk – in die Rechnung, nicht ein Wert aus einem Artikel.
Der Ausgangspunkt jeder datenschutzrechtlichen Betrachtung ist simpel und folgenreich: Ein Power-Pages-Portal verarbeitet personenbezogene Daten von Menschen außerhalb Ihrer Organisation – von Kunden, Antragstellern, Partnern. Diese Personen geben ihre Daten ein, laden Dokumente hoch, hinterlassen Spuren. Damit sind die Regeln der DSGVO einschlägig, und es braucht eine Rechtsgrundlage für diese Verarbeitung, eine klare Zweckbindung, Transparenz gegenüber den Betroffenen sowie ein Konzept, wie deren Rechte – Auskunft, Berichtigung, Löschung – erfüllt werden. Anders als bei internen Anwendungen, wo es um die eigenen Mitarbeitenden geht, stehen hier externe Personen im Zentrum, für deren Daten Sie als verantwortliche Stelle einstehen.
Die Betroffenen müssen deshalb erkennbar wissen, welche Daten zu welchem Zweck verarbeitet werden. Dazu gehören eine passende Datenschutzerklärung im Portal, ein durchdachter Umgang mit Einwilligungen, wo sie nötig sind, und ein Prozess, mit dem Betroffenenrechte praktisch bedient werden können. Wer ein Portal öffnet, ohne diese Fragen zu klären, riskiert nicht nur Vertrauen, sondern einen Rechtsverstoß.
Ein Punkt verdient besondere Betonung, weil er technische und rechtliche Ebene verbindet: Das Berechtigungskonzept ist zugleich ein Datenschutz-Konzept. Wenn ein Fehler in den Zugriffsrechten dazu führt, dass ein externer Nutzer die Daten eines anderen sieht, ist das kein bloßer Bug, sondern eine unbefugte Offenlegung personenbezogener Daten – also potenziell ein meldepflichtiger Datenschutz-Vorfall. Weil ein Portal per Definition nach außen offen ist, wiegt ein solcher Fehler besonders schwer. Deshalb gehört die Zugriffssteuerung nicht nur getestet, sondern regelmäßig überprüft – und die Datenschutzfunktion sollte in die Konzeption eingebunden sein, nicht erst nach dem Live-Gang informiert werden.
Zur Datenhoheit gehören mehrere Aspekte, die man auseinanderhalten sollte. Erstens: Microsoft bietet die Möglichkeit, die Verarbeitung in einer EU-Region anzusiedeln und im Rahmen der EU Data Boundary Kundendaten innerhalb der EU zu verarbeiten – das stärkt die Datenresidenz und sollte bewusst konfiguriert werden, statt sich auf eine Voreinstellung zu verlassen. Zweitens: Als US-Konzern unterliegt Microsoft dennoch dem US Cloud Act, sodass ein Restrisiko eines behördlichen Zugriffs bestehen bleibt – die EU-Verarbeitung reduziert dieses Risiko deutlich, hebt es aber nicht vollständig auf. Für die meisten Mittelständler ist das bei bewusster Konfiguration akzeptabel; für besonders sensible Daten oder regulierte Bereiche gehört diese Frage in eine sorgfältige, fallbezogene Bewertung.
Drittens: Weil es sich um ein externes Portal mit Daten Dritter handelt, ist die Verantwortung hier größer als bei einer internen Anwendung. Sie sind gegenüber den externen Betroffenen die verantwortliche Stelle und müssen deren Rechte gewährleisten. Der Auftragsverarbeitungsvertrag mit Microsoft, die Wahl der Region, das Aufbewahrungs- und Löschkonzept und die Transparenz gegenüber den Nutzern gehören deshalb geklärt, bevor das Portal produktiv Daten sammelt – nicht danach.
