Einleitung
Einführung: Schulwebsites sollen attraktiv und informativ sein – Videos, Karten oder Social-Media-Feeds lockern die Seiten auf. Doch sobald externe Dienste eingebunden werden, stellen sich Datenschutz-Fragen (Stichwort DSGVO) und Anforderungen an die Barrierefreiheit. Öffentliche Schulen in Deutschland müssen personenbezogene Daten schützen und ihre Websites barrierefrei gestalten. Was im allgemeinen Web üblich ist, ist nicht automatisch schulkonform: Eine „coole“ Einbettung kann schnell zum Datenschutzverstoß werden. In diesem Artikel erfahren Schulleitungen, Sekretariate, Schulträger und Admins, welche Drittanbieter-Tools auf Schulhomepages erlaubt sind – und wie man sie datenschutzgerecht und barrierefrei umsetzt. Wir geben praxisnahe Entscheidungshilfen, Risiko-Einstufungen und sichere Alternativen für typische Fälle von „Externe Inhalte auf der Schulwebsite“.
Warum sind externe Dienste problematisch?
Datenabfluss an Dritte: Sobald Ihre Schulwebsite Inhalte von Drittanbietern lädt (z.B. per <iframe> oder Skript), verbindet sich der Browser der Besucher mit fremden Servern. Dabei übermittelt er mindestens die IP-Adresse und oft weitere Informationen (z.B. die aufgerufene Seite als Referrer). Ist der Nutzer gerade bei dem Drittanbieter eingeloggt (z.B. Google/Konto oder Facebook), kann dieser den Webseitenbesuch personenbezogen zuordnen. Selbst ohne Login ermöglichen Cookies oder Gerätekennungen ein Profiling über Webseiten hinweg. Kurz: Durch jede externe Einbindung erlauben Sie dem Drittanbieter, Besucherdaten zu sammeln und zu verknüpfen – ähnlich, als würde ein lokaler Laden einem Werbekonzern gestatten, jeden Kundenbesuch zu verfolgen.
Verantwortung der Schule: Für die Schulwebsite ist die Schule (Schulleitung) rechtlich der Verantwortliche im Sinne der DSGVO. „Das machen doch alle Webseiten so“ schützt nicht: Schulen unterliegen dem Datenschutzrecht und müssen Rechtmäßigkeit, Transparenz und Zweckbindung jeder Datenverarbeitung nachweisen. Ein externer Dienst auf der Schulhomepage ist nur zulässig, wenn alle Vorgaben erfüllt sind – von der Rechtsgrundlage (z.B. Einwilligung oder öffentliches Interesse) über Informationspflichten bis zu technischen Schutzmaßnahmen. Zudem fordert das TTDSG (§25) für viele Fälle (Cookies, Tracking) vorherige Einwilligung der Nutzer – was gerade bei Schulen streng gehandhabt wird. Öffentliche Stellen sind angehalten, Datenminimierung zu betreiben und möglichst auf nicht notwendige Drittanbieter zu verzichten.
Barrierefreiheit nicht vergessen: Externe Plugins sind nicht nur datenschutz-, sondern oft auch barrierefreiheitskritisch. Viele eingebettete Medien und Widgets sind nicht vollständig nach BITV 2.0/WCAG zugänglich (z.B. per Tastatur steuerbar oder mit Untertiteln versehen). Schulen müssen jedoch ihre Webangebote barrierefrei gestalten, andernfalls verstoßen sie gegen gesetzliche Pflichten (Behindertengleichstellungsgesetz und BITV). Das heißt: Jede fancy Einbettung, die z.B. für Screenreader-Nutzer*innen unbedienbar ist, kann problematisch sein.
Fazit: Externe Inhalte sind nicht grundsätzlich verboten, aber „einfach machen“ geht nicht. Man braucht klare Entscheidungskriterien, technische Schutzlösungen und ggf. Einwilligungsmechanismen, um Schulwebsites rechtssicher (DSGVO-konform) und zugänglich zu gestalten. Im Folgenden betrachten wir gängige Kategorien von Drittinhalten mit Praxisempfehlungen.
Kategorien externer Dienste auf der Schulwebsite
Video- und Audio-Einbindungen (YouTube, Vimeo, Soundcloud & Co.)
Typische Nutzung: Schulen präsentieren gerne Videos – vom Schulkonzert auf YouTube bis zur Erkläranimation auf Vimeo – oder binden Audio-Streams (z.B. Podcasts über SoundCloud) ein. Multimedia macht die Seite lebendiger und kann Informationen anschaulich vermitteln.
Risiko: Hoch. Videoplattformen wie YouTube und Vimeo sowie Audioplayer von SoundCloud etc. setzen bei direkter Einbettung Cookies und melden jeden Aufruf an ihre Server. Damit fließen personenbezogene Daten (IP, ggf. Nutzer-ID) an US-Unternehmen. Ohne Schutzmaßnahmen ist das einwilligungspflichtig und nach Auffassung der Aufsichtsbehörden nicht zulässig, solange keine vorherige informierte Einwilligung erfolgt. Zudem sind Videos häufig ohne Untertitel eingebunden, was Barrieren für hörbehinderte Nutzer schafft.
Häufige Fehler: Das YouTube-Video einfach per
<iframe>einbetten, sodass es beim Laden der Seite automatisch Kontakt zu YouTube herstellt – oft sogar ohne Nutzung des YouTube-Datenschutzmodus. Dabei werden schon beim Seitenaufruf Cookies gesetzt und Daten an Google gesendet, noch bevor der Nutzer das Video startet. Weiterhin problematisch: Fehlende Untertitel oder Transkripte; kein Hinweis für Nutzer, was mit ihren Daten passiert; und Videos, die sich ohne Bedienmöglichkeit per Tastatur abspielen lassen (YouTube-Player ist nur bedingt barrierefrei).
Sicherere Alternative: Selbst hosten oder verlinken. Optimal ist es, Videos/Audios direkt auf dem Schulserver bereitzustellen (sofern dieser die nötige Bandbreite hat). Ein im eigenen Webspace eingebundenes HTML5-Video oder Audio sendet keine Daten an Dritte. Allerdings müssen Sie dann selbst für verschiedene Auflösungen/Streaming sorgen. Ist Selbsthosting nicht praktikabel, ziehen Sie in Erwägung, nur eine Vorschau oder ein Standbild zu zeigen und auf die externe Plattform zu verlinken, statt sie einzubetten. Beispiel: Ein Thumbnail des YouTube-Videos mit Play-Button, das per Klick auf youtube.com weiterleitet. So entscheidet der Nutzer bewusst, YouTube zu besuchen.
Empfohlene Umsetzung: Wenn Einbettung externer Videos unvermeidbar ist, nutzen Sie mindestens den erweiterten Datenschutzmodus von YouTube (
youtube-nocookie.com) und implementieren Sie eine Zwei-Klick-Lösung. Bei der Zwei-Klick-Methode wird zunächst nur ein Platzhalter (Vorschau-Bild) geladen, ohne Verbindung zu YouTube. Erst wenn der Besucher aktiv auf „Video abspielen“ klickt, wird das eigentliche Video nachgeladen – damit gilt der Klick als Einwilligung, und erst dann fließen Daten an YouTube. Wichtig: Blenden Sie einen kurzen Hinweis ein, z.B. „Durch das Starten des Videos willigen Sie ein, dass Daten an YouTube übertragen werden.“, und verlinken Sie Ihre Datenschutzerklärung für Details. Technisch lässt sich das in gängigen CMS oft per Plugin lösen (für WordPress z.B. Embed videos and respect privacy oder WP YouTube Lyte). Vimeo bietet keinen offiziellen Nocookie-Modus; hier sollten Sie ebenfalls nur via Vorschau und Link arbeiten. Prüfen Sie außerdem Barrierefreiheit: Stellen Sie Untertitel für Videos bereit oder zumindest ein Transkript zum Download. Videos ohne Ton benötigen ggf. eine Audiodeskription für visuelle Infos. Autoplay sollte aus sein (verwirrt Screenreader und Nutzer). Durch diese Maßnahmen können Schulen YouTube & Co. eingeschränkt DSGVO-konform nutzen, sollten aber generell sparsam damit umgehen.
Karten und Routenplaner (Google Maps, OpenStreetMap etc.)
Typische Nutzung: Viele Schulwebsites haben eine „Anfahrt“-Seite, auf der eine Karte mit dem Schulstandort eingebettet ist – häufig via Google Maps. Besucher können reinzoomen, Routen planen oder den Standort direkt in ihrer Maps-App öffnen.
Risiko: Hoch (für Google Maps). Eine direkt eingebettete Google Maps Karte ruft Inhalte von Google-Servern ab und übermittelt dabei Nutzerinformationen (IP, Gerätekennung etc.) in die USA. Google setzt Cookies und kann Nutzeraktivitäten nachvollziehen. Ohne besonderen Schutz ist das nicht zulässig ohne vorherige Einwilligung
. Die Datenschutzkonferenz verlangt auch hier eine Zwei-Klick-Lösung: Keine Kartendaten laden, bevor der Nutzer zugestimmt hat
. Barrierefreiheits-Aspekt: Interaktive Karten sind für viele Nutzer*innen schwer bedienbar – z.B. können Screenreader die grafische Karte nicht „lesen“, und per Tastatur lassen sich viele Karten-Widgets schlecht steuern. Dadurch entstehen Barrieren, wenn die Karte die einzige Anfahrtsinfo ist.
Häufige Fehler: Google Maps ungefragt einbinden, sodass schon beim Seitenaufruf Google-Daten fließen. Oft fehlt ein Hinweis, und Nutzer werden nicht informiert, dass ihre Daten an Google gehen. Zudem versäumen viele Schulen, eine Alternative für Sehbehinderte bereitzustellen – z.B. zumindest die Adresse in Textform. Eine weitere Falle: Der Kartenausschnitt ist nicht korrekt für alle Nutzer zugänglich (fehlende Alt-Texte oder Titel fürs
<iframe>).Safer Alternative: OpenStreetMap (OSM) anstelle von Google Maps nutzen. OSM ist ein freies Kartenprojekt mit europäischen Servern. Schon die Verwendung von OSM reduziert das Tracking-Risiko, da OSM keine kommerziellen Tracker einbindet. Allerdings erfolgt auch bei Standard-OSM-Embed ein Verbindungsaufbau zu fremden Servern (z.B. den Tile-Servern). Am datenschutzfreundlichsten ist es, OSM-Karten über einen Proxy oder eigenen Server bereitzustellen
. Große Organisationen (oder Schulträger mit IT-Kapazität) könnten sogar einen eigenen OSM-Tile-Server betreiben – dann werden keinerlei Daten an Dritte übermittelt und die Karte kann einwilligungsfrei dargestellt werden. Für den Schulgebrauch dürfte das selten umsetzbar sein; aber es gibt Community-Projekte und regionale OSM-Dienste (z.B. Maps4BW für Baden-Württemberg)
. Alternativ zur interaktiven Karte können Sie auch einfach ein statisches Kartenausschnitt-Bild (Screenshot) der Umgebung einfügen – versehen mit einer Markierung der Schule – und darunter Adresse und Wegbeschreibung in Textform. Ein statisches Bild (auf dem eigenen Server gehostet) verursacht keinen externen Datentransfer. Nutzer, die interaktiv navigieren möchten, können dann z.B. den Link „Größere Karte auf OpenStreetMap öffnen“ anklicken – das ist ein bewusster Schritt, vergleichbar mit der Zwei-Klick-Lösung.
Empfohlene Umsetzung: Wollen Sie auf Google Maps nicht verzichten (z.B. wegen Street View oder vertrauter Bedienung), richten Sie mindestens eine Zwei-Klick-Lösung ein
. Das heißt: Binden Sie initial kein aktives Google-Map-Objekt ein, sondern vielleicht ein Kartenvorschaubild mit einem Hinweis. Beispiel: „Karte: [Button] Anzeigen“, und darunter: „Beim Aktivieren wird eine Karte von Google Maps geladen; dabei können personenbezogene Daten an Google übermittelt werden.“ Erst nach Klick laden Sie per Skript die echte Google-Map. So stellen Sie sicher, dass vorher Einwilligung eingeholt wurde (der Klick dient als Zustimmung). Besser noch, überlegen Sie den Wechsel zu OSM: Mit Tools wie Leaflet (JavaScript-Bibliothek) lässt sich OSM elegant einbinden. Sie können die Kartendaten über einen europäischen Dienst laden oder – für völlige DSGVO-Konformität – im Hintergrund durch einen eigenen Server proxyen. Dokumentieren Sie in der Datenschutzerklärung klar, welchen Kartendienst Sie nutzen und dass ggf. eine Datenübertragung erfolgt. Aus Barrierefreiheits-Sicht sollten Sie immer alternative Wegbeschreibungen anbieten: Nennen Sie die Adresse der Schule im Klartext und ggf. wichtige Orientierungspunkte. So können Nutzer die Infos auch ohne Karte nutzen (z.B. jemand kann die Adresse ins Navi eingeben). Vergessen Sie nicht, dem Karten-<iframe> ein title-Attribut zu geben (z.B. title="Karte des Schulstandorts") – das hilft Screenreadern zu verstehen, was das Objekt ist. Zusammengefasst: Karten nur mit Einwilligung laden, datensparsame Dienste bevorzugen und immer eine barrierefreie Alternative (Textinfo) bereitstellen.
Schriften und Content-Delivery-Netzwerke (Google Fonts, CDN-Skripte)
Typische Nutzung: Um das Design der Schulhomepage ansprechend zu gestalten, werden oft Web-Schriften von externen Anbietern eingebunden – klassisches Beispiel: Google Fonts. Auch andere statische Ressourcen (CSS-Frameworks, JavaScript-Bibliotheken wie jQuery, Icons) bindet man gerne bequem über ein CDN (Content Delivery Network) ein. Das spart lokalen Speicher und galt lange als Performance-Trick.
Risiko: Hoch (für externe Fonts/CDNs). Jede Einbindung einer Ressource von einem fremden Server überträgt die IP-Adresse des Seitenbesuchers an diesen Drittanbieter
. Bei Google Fonts bedeutete dies bislang: Jeder Besucher einer Schulwebsite, die Google-Fonts remote lädt, meldet unbewusst seine IP an Google. Aus Datenschutz-Sicht ist das unnötig und mittlerweile abgemahnt worden – es gab Fälle, in denen Website-Betreiber wegen extern geladenen Google Fonts Schadenersatz zahlen mussten, weil dadurch ohne Einwilligung personenbezogene Daten an Google flossen. Ähnlich bei CDN-Skripten (Bootstrap, jQuery via Cloudflare/Google CDN): Hier erfährt ein Dritter, welche Seiten besucht werden. Rechtlich sind externe Fonts nur mit Einwilligung zulässig, da weder berechtigte Interessen noch öffentliche Aufgabe das Nachladen einer Schrift rechtfertigen – zumal es einfache Alternativen gibt. Aus Nutzersicht bringen externe Fonts zudem keine Vorteile mehr: Moderne Browser cachen nicht mehr domainübergreifend, d.h. den früher angenommenen Performance-Vorteil (Schrift evtl. schon im Cache) gibt es kaum noch
.
Häufige Fehler: Google Fonts aus dem Web einbinden (per
<link>auf Google-APIs). Viele Schulen nutzten einfach Templates oder Themes, die das standardmäßig tun, und bemerkten gar nicht, dass damit bei jedem Seitenaufruf „nach Hause telefoniert“ wird. Oft fehlt in solchen Fällen jeglicher Hinweis in der Datenschutzerklärung – ein klarer Verstoß, da selbst IP-Adressen personenbezogen sind. Ein weiterer Fehler: Auch andere Libraries gedankenlos vom CDN laden (z.B.<script src="https://code.jquery.com/...">im Quellcode). Das ist datenschutztechnisch genauso unnötig riskant.Safer Alternative: Fonts und Scripte lokal hosten. Die Lösung ist hier einfach: Alle erforderlichen Schriften können von den Anbieterseiten heruntergeladen und auf dem eigenen Webspace gespeichert werden. Für Google Fonts z.B. gibt es Tools wie den Google Web Fonts Helper, der die gewünschten Schriftarten inkl. aller Formate bereitstellt
. Die CSS-Datei verlinkt man dann lokal. Ergebnis: Die Seite sieht identisch aus, aber ohne jede externe Verbindung
. Gleiches Prinzip für JS/CSS-Libraries: Statt über z.B.
cdnjs.cloudflare.comeinzubinden, hosten Sie die Dateien selber (bei vielen CMS kann man das in den Theme-Einstellungen oder durch Plugins steuern). So bleiben alle Website-Ressourcen unter Ihrer Kontrolle.Empfohlene Umsetzung: Prüfen Sie zunächst, ob Ihre Website externe Fonts oder Skripte lädt – Hinweise darauf finden sich im HTML-Code oder mittels Browser-Entwicklertools (Netzwerkanalyse). Bei Google Fonts: Nutzen Sie am besten keine Online-Einbindung. Laden Sie die benötigten Font-Dateien herunter (beachten Sie die Lizenz, aber Google-Fonts sind in der Regel Open-Source) und binden Sie sie per
@font-facein Ihre CSS ein. Das Online-Tool google-webfonts-helper bietet hierzu komfortabel den CSS-Code an
. Entfernen Sie alle <link>-Tags zu Google-Fonts-URLs. Damit ist Ihr „Google Fonts DSGVO Schule“-Problem gelöst – keine IP geht mehr an Google, und es gibt keinen optischen Unterschied. Andere CDNs: Für häufige Bibliotheken (jQuery, Bootstrap etc.) laden Sie die Minified-Dateien von der offiziellen Quelle herunter und laden Sie auf Ihren Webserver hoch. Passen Sie die HTML-Referenzen an, damit sie auf die lokale Datei zeigen. Achten Sie darauf, diese Ressourcen bei Software-Updates synchron zu aktualisieren (z.B. wenn Sie WordPress nutzen, vermeiden Sie Plugins, die wieder extern laden). Insgesamt gilt: Externe CDNs sind auf Schulhomepages meist unnötig. Die paar Kilobyte mehr Traffic für lokale Dateien sind in Kauf zu nehmen, dafür entfallen Cookie-Banner-Pflichten und rechtliche Risiken. Schließlich sollten Sie in der Datenschutzerklärung vermerken, dass Sie Webfonts lokal einsetzen – so zeigen Sie proaktiv, dass keine Daten an Dritte fließen (was Besucher und Datenschutzbeauftragte beruhigt).
Besucher-Analyse und Tracking (Analytics, Statistik-Tools)
Typische Nutzung: Website-Betreiber möchten oft wissen, wie viele Besucher sie haben und welche Seiten besonders beliebt sind. Auch Schulen haben bis 2018 teils Google Analytics genutzt, um Zugriffszahlen zu erheben. Nach DSGVO-Einführung wurde das aber vielerorts abgeschaltet
. Heute fragen Schulen: „Dürfen wir Google Analytics auf der Schulwebsite nutzen?“ – oder welche Tracking-Alternative es gibt. Gängig sind datenschutzfreundlichere Tools wie Matomo (ehemals Piwik), die man selbst hosten kann, oder Simple Analytics/Plausible als Dienste ohne persönliche Profile.
Risiko: Hoch (für klassische Tracker). Google Analytics z.B. setzt mehrere Cookies, erfasst umfangreiche Nutzerdaten und sendet diese in die USA – laut Behörden derzeit nicht legal einsetzbar, selbst mit Einwilligung nicht, da die Datenübertragung nicht ausreichend abgesichert ist
. Französische und österreichische Aufsichtsbehörden haben 2022 klar festgestellt, dass GA gegen die DSGVO verstößt. In Deutschland ist man ebenfalls sehr skeptisch. Grundsätzlich erfordert jedes Tracking über das technisch Notwendige hinaus eine informierte Einwilligung vorab (TTDSG §25). Das heißt, ohne Consent-Banner geht nichts, wenn Sie Nutzer über Cookies oder Fingerprinting wiedererkennen wollen
. Schulen als öffentliche Stellen sollten hier besonders streng sein – schließlich geht es oft um Daten von Minderjährigen und Eltern.
Häufige Fehler: Einsatz von Google Analytics mit Standard-Einstellungen, ohne Einwilligung einzuholen. Das ist ein klarer DSGVO-Verstoß. Selbst wer ein Cookie-Banner schaltet, macht Fehler: Häufig ist das Banner nicht korrekt (z.B. voreingestelltes „OK“ oder unvollständige Infos). Andere vergessen den AV-Vertrag mit dem Analytics-Anbieter – Google verlangt z.B. einen Vertrag zur Auftragsverarbeitung, wenn eine Schule Analytics nutzt
, was oft übersehen wird. Ein weiterer Fehler: Überhaupt mehr Daten zu sammeln als nötig. Viele Schulen brauchen gar keine detaillierte Webanalyse; manchmal reicht der Server-Log oder eine simple Besucherzählung.
Safer Alternative: Verzicht oder lokal begrenzte Analyse. Fragen Sie zunächst: Brauchen wir detaillierte Statistiken? Wenn nein, schalten Sie alle Tracking-Tools ab – das erspart viel Aufwand und die Website kommt vermutlich auch ohne Cookies aus (was wiederum die Nutzer freut und den Cookie-Hinweis erspart)
. Falls doch, greifen Sie zu datenschutzfreundlichen Tools. Matomo ist eine gute Wahl, denn es kann vollständig auf dem Schulserver oder einem deutschen Server gehostet werden und lässt sich so einstellen, dass keine persönlichen Profile entstehen. Zum Beispiel können Sie Matomo ohne Cookies betreiben und IP-Adressen anonymisieren (kürzen), sodass keine personenbezogenen Daten dauerhaft gespeichert werden. Eine solche Reichweitenanalyse, die nur aggregierte Statistiken erstellt, ist vom strengen Tracking abzugrenzen. Erfasst man nur totalisierte Seitenaufrufe und verzichtet auf Wiedererkennungs-IDs, lässt sich argumentieren, dass keine Einwilligung nötig ist – da kein Zugriff auf Endeingerätinformationen erfolgt (TTDSG) und die Daten anonym sind (DSGVO). Beachten Sie aber: Sobald irgendeine Form von Cookie oder Fingerprint genutzt wird (z.B. um „Unique Visitors“ über Tage zu zählen), sind wir wieder im einwilligungspflichtigen Bereich
.
Empfohlene Umsetzung: Für eine DSGVO-konforme Schulwebsite ist es ideal, gar kein externes Tracking einzusetzen – dadurch vermeiden Sie Risiken und zeigen, dass Datenschutz Schule macht. Wenn Sie zumindest grobe Zugriffszahlen möchten, nutzen Sie die Webserver-Logs (diese enthalten Seitenabrufe und IPs, die man z.B. monatlich auswerten kann, wobei IPs sofort zu anonymisieren sind). Alternativ installieren Sie Matomo on-premises: Hier richten Sie in den Einstellungen maximalen Datenschutz ein (IP-Anonymisierung, „DoNotTrack“ respektieren, keine Cookies oder nur ein technisch notwendiges Opt-Out-Cookie). So ein Setup hat das Bayerische Landesamt für Datenschutzaufsicht früher als zulässig erachtet, ohne Einwilligungspflicht
– wohlgemerkt vor den Schrems-II-Problematiken. Wichtig: Wenn Sie Matomo oder ein anderes Tool verwenden, schließen Sie einen Auftragsverarbeitungsvertrag mit dem Anbieter ab (bzw. stellen Sie sicher, dass bei Selbsthosting die Schule selbst Verantwortliche bleibt). Dokumentieren Sie in Ihrer Datenschutzerklärung die Art der Auswertung, anonymisierte Verfahren und dass keine Daten an Dritte fließen. Finger weg von Google Analytics – selbst in der neuesten Version (GA4) bleiben die Grundprobleme (USA-Transfer, personenbezogenes Nutzungsprofil). Selbst wenn man GA konfigurieren kann, dass keine Datenweitergabe an Google erfolgt, bleibt ein Restrisiko und der Aufwand ist hoch. Als öffentliche Schule sollte man sich dieses Streitfeld sparen. Zu guter Letzt: Cookies auf das Nötigste beschränken. Idealerweise kommt Ihre Website ohne nicht essentielle Cookies aus – dann brauchen Sie auch keine nervigen Cookie-Banner. Reduzieren Sie also Tracking und Third-Party-Tools, und Sie ersparen sich komplexe Einwilligungs-Mechanismen.
Social-Media-Integrationen (Instagram-Feeds, Facebook-Plugins, Twitter-Timeline)
Typische Nutzung: Viele Schulen betreiben eigene Social-Media-Kanäle (z.B. einen Instagram-Account für Schulnews). Verständlich ist der Wunsch, diese Inhalte auch auf der Schulhomepage zu zeigen – z.B. eine Instagram-Bildergalerie im Seitenlayout oder einen eingebetteten Twitter-Tweet mit Anerkennung. Ebenso gibt es „Like“ oder „Share“-Buttons für Facebook, Twitter & Co., um das Teilen zu erleichtern.
Risiko: Hoch. Eingebettete Social Media Inhalte führen unweigerlich zu Datenabflüssen, als ob der Nutzer direkt die Plattform besucht
. Beispiel: Ein Instagram-Feed-Widget lädt Skripte von instagram.com, setzt Cookies und übermittelt Informationen über den Besuch. Der LfDI Baden-Württemberg stellte klar: Solche Einbindungen sind unzulässig ohne vorherige, ausdrückliche Einwilligung. Praktisch bedeutet das: Sie dürfen einen Instagram-Feed nicht einfach anzeigen, ohne dass der Nutzer dem zugestimmt hat – ein Hinweis allein reicht nicht, es muss ein Opt-In erfolgen. Tracking-Potenzial: Social-Media-Plug-ins erkennen oft, wenn ein Besucher bei dem Dienst eingeloggt ist, und können so dessen Identität und Verhalten verknüpfen. Selbst ohne Login werden Nutzungsprofile erstellt (z.B. Facebook erstellt „Schattenprofile“ auch von Nicht-Mitgliedern)
. Kurzum: Social Embeds sind datenschutzrechtlich sehr heikel. Dazu Barrierefreiheit: Die eingebetteten Inhalts-Widgets (z.B. ein scrollbarer Instagram-Frame) sind oft nicht barrierefrei – keine ordentlichen Labels, per Tastatur schlecht navigierbar, und externe Inhalte wie Videos darin sind wieder ohne Untertitel.
Häufige Fehler: Direkte Einbindung von Social Feeds – z.B. ein Instagram-Plugin, das automatisch die neuesten Posts anzeigt, oder ein Twitter-Timeline-Embed. Diese laden beim Seitenaufruf sofort externe Inhalte und tracken Nutzer im Hintergrund. Ein weiterer Fehler: Teilen-/Like-Buttons im Original von Facebook/Twitter einbauen. Die klassischen Like-Buttons übermitteln schon beim Laden (ohne Anklicken) Nutzerdaten an Facebook. Hier haben viele zwar von der Problematik gehört, aber setzen die Buttons trotzdem ein. Außerdem versäumen Schulen oft, ihre Datenschutzerklärung entsprechend zu ergänzen. Es müsste genau erläutert werden, was passiert, wenn etwa ein Instagram-Frame aktiviert wird
– doch häufig steht dazu nichts Konkretes im Datenschutzhinweis.
Safer Alternative: Kein automatisches Embed, stattdessen Verlinkungen oder Proxy-Lösungen. Die datenschutzfreundlichste Variante ist, auf der Schulhomepage nur Verlinkungen zu den offiziellen Social-Media-Auftritten zu bieten (z.B. kleine Icons „Folgen Sie uns auf Instagram/Facebook“). Das Öffnen erfolgt dann auf Wunsch in einem neuen Tab – solange der Nutzer nicht klickt, bleibt die Schulwebsite tracker-frei. Alternativ kann man die Social-Posts manuell spiegeln: Wichtige Ankündigungen, die auf Instagram gepostet wurden, zusätzlich als Beitrag oder News auf der Schulwebsite veröffentlichen. So müssen Besucher keine Social-Media-Dienste nutzen, um relevante Infos zu erhalten
. Für Share-Buttons (Teilen in sozialen Netzwerken) gibt es das bekannte Shariff-Konzept vom c’t Magazin: Hier werden statt Original-Buttons nur statische Grafiken angezeigt, die erst beim Klick den echten Share-Link aufrufen. Dadurch fließt bis zum Klick keine Nutzerinfo an die Plattform. Shariff kann für Facebook, Twitter, WhatsApp etc. eingesetzt werden. Für eingebettete Posts (z.B. konkrete Tweets oder YouTube-Videos – hier überschneidet es sich mit Video-Kategorie) gibt es Tools wie Embetty (ebenfalls von Heise/c’t). Embetty zeigt einen externen Inhalt auch erst nach aktivem Klick an und kann sogar serverseitig vorsorgen, dass keine direkten Verbindungen vom Client zum Drittanbieter entstehen. Allerdings ist Embetty etwas aufwendiger (benötigt z.B. einen kleinen Proxy-Server)
.
Empfohlene Umsetzung: Vermeiden Sie Social-Embeds im Default. Fragen Sie sich, ob es wirklich notwendig ist, z.B. den Instagram-Feed live auf der Homepage zu haben. Oft genügt ein hübsches Bild mit Link: „Schauen Sie auf unserem Instagram-Kanal vorbei“. Dadurch entscheiden die Nutzer selbst. Wenn Sie Social-Inhalte einbinden möchten, setzen Sie unbedingt eine Zwei-Klick-Lösung um (analog wie bei Videos): Erst eine Vorschau oder ein Symbol, und nach Klick wird der Inhalt geladen
. Weisen Sie die Nutzer vorher gut sichtbar darauf hin, welche Daten dann fließen. Ein Beispiel: „Tweets von unserem Twitter-Kanal – durch Anklicken werden Daten an Twitter gesendet, siehe Datenschutzerklärung.“ Nach dem Klick könnte man den echten Twitter-Embed anzeigen. Technisch lässt sich das je nach CMS durch Plugins lösen, oder man verlinkt zunächst auf eine eigene Seite mit dem Feed. Wichtig ist, dass kein Social-Skript ohne Opt-In lädt. Informationspflicht: In der Datenschutzerklärung braucht es einen Abschnitt zu Social-Media-Einbindungen. Dort sollten Sie erläutern, dass z.B. beim Besuch der Seite mit Instagram-Feed schon Daten an Facebook/Instagram gehen (wenn es denn so umgesetzt ist), und welche Risiken das birgt (Profilbildung, Identifizierung eingeloggter Nutzer etc.). Beschreiben Sie auch, dass die Schule für ihre Social-Media-Kanäle ggf. mitverantwortlich ist (Stichwort gemeinsame Verantwortlichkeit nach Art. 26 DSGVO für Fanpages – Facebook verlangt das). Apropos Fanpage: Das BayLDA hält Facebook-Fanpages derzeit für nicht rechtmäßig betreibbar (wegen der Unmöglichkeit, die Rechenschaftspflichten zu erfüllen). Eine schulische Facebook-Seite ist also datenschutzrechtlich ein heißes Eisen. Wenn Ihre Schule Social Media nutzt, sollten Sie zumindest alle notwendigen Informationen auch anders bereitstellen (kein Zwang für Eltern/Schüler, sich dort zu registrieren). Konkret: Posten Sie News parallel auf der Homepage, bieten Sie ggf. einen Newsletter an oder nutzen Sie schulinterne Kanäle. Spezialfall WhatsApp: Manche Schulen haben versucht, einen „WhatsApp-Kontakt“ anzubieten (z.B. eine Nummer für Elternfragen). Davon ist dringend abzuraten – WhatsApp ist aus Datenschutzsicht nicht schulkonform. Das BayLDA betont, dass bei WhatsApp die Metadaten in den USA verarbeitet werden und Adressbuchdaten Dritter hochgeladen werden, was nicht rechtmäßig erfolgt; man empfiehlt Alternativen wie Threema oder Signal. Auf der Website sollte höchstens ein WhatsApp-Link angeboten werden, wenn überhaupt, und dann mit dem Hinweis, dass die Kommunikation freiwillig und auf eigenes Risiko erfolgt. Besser: Offizielle Kommunikationswege nutzen (E-Mail, Telefon oder datenschutzgeprüfte Messenger-Lösungen, die in manchen Bundesländern für Schulen bereitgestellt werden). Zusammengefasst: Social Media Einbindungen nur, wenn unvermeidlich – dann mit Opt-In (2-Klick) und voller Transparenz. Lieber verlinken statt einbetten, um Ihre Schulhomepage rechtssicher und schlank zu halten.
Formulare, Kontakt & Kommunikationstools (Kontaktformular, Newsletter, Captcha, Messenger)
Typische Nutzung: Schulwebsites haben oft ein Kontaktformular (z.B. für allgemeine Anfragen oder Krankmeldungen online). Ebenso können Newsletter-Anmeldungen oder Umfrage-Formulare eingebunden sein. Zur Spam-Abwehr findet man häufig CAPTCHAs (etwa Googles reCAPTCHA). Außerdem verlinken einige Schulen Kommunikationsdienste wie Eltern-Chatgruppen oder bieten einen „WhatsApp-Kontakt“ (siehe oben).
Risiko: Mittel bis hoch, je nach Umsetzung. Ein einfaches Kontaktformular, das direkt an die Schul-E-Mail sendet und sonst nichts, ist an sich unkritisch – wenn die Daten über SSL übertragen werden und nur intern verwendet. Allerdings werden hier personenbezogene Daten aktiv von Nutzern eingegeben, oft auch sensible (z.B. Gesundheitsinfo bei Krankmeldungen). Das erfordert hohe Sorgfalt: Rechtsgrundlage und Zweckbindung müssen klar sein, eventuell ist eine Einwilligung nötig, und die Daten dürfen nicht länger als nötig gespeichert werden
. Wird ein externer Dienst genutzt (z.B. ein Formular über Google Forms oder ein Newsletter-Service aus USA), steigt das Risiko: Dann fließen die eingegebenen Daten an Drittanbieter, oft außerhalb der EU. Das ist nur zulässig, wenn die strengen Auflagen (AV-Vertrag, ggf. SCC für Drittland, Einwilligung) erfüllt sind – was in der Schulpraxis schwer zu gewährleisten ist. CAPTCHAs wie Google reCAPTCHA sind hochproblematisch: Hierbei werden zum Zweck der Bot-Abwehr zahlreiche Nutzerinformationen an Google gesendet (Mausbewegungen, ggf. Cookies, Google-Login-Status). Laut bayerischer Aufsicht muss man unbedingt Alternativen prüfen und darf reCAPTCHA nur einsetzen, wenn man den rechtmäßigen Einsatz nachweisen kann
. Praktisch bedeutet das, reCAPTCHA nur mit Einwilligung zu verwenden und die Schrems-II-Anforderungen (Datenübertragung USA) zu erfüllen – sehr aufwändig und deshalb nicht empfehlenswert. Newsletter-Tools (z.B. Mailchimp) wiederum erfordern Einwilligung der Abonnenten (Double-Opt-In) und einen AV-Vertrag; zudem sind US-Dienste problematisch. Kurz: Formulare brauchen besonderen Datenschutz-Fokus, da hier aktiv Daten gesammelt werden, nicht nur passiv mitgeloggt.
Häufige Fehler: Kontaktformular ohne Hinweis und Absicherung. Viele Schulhomepages hatten (oder haben) ein einfaches Formular „Nachricht an uns“, ohne jeglichen Datenschutzhinweis. Nutzer füllen Name, E-Mail, Nachricht aus – im Hintergrund wird alles in der Web-Datenbank gespeichert und per Mail versendet, aber die Schule hat weder eine Einwilligung eingeholt noch in der Datenschutzerklärung erklärt, was mit den Daten passiert. Das ist seit DSGVO ein Abmahnrisiko
. Ein weiteres Problem: Google reCAPTCHA ungefragt einsetzen. Häufig wird reCAPTCHA „mal eben“ aktiviert, um Spam zu verhindern, ohne den Nutzern was zu sagen. Das kleine unscheinbare reCAPTCHA-Badge unten rechts wird übersehen, dabei bedeutet es: Google überprüft gerade den Nutzer. Ohne Einwilligung ist das unzulässig. Bei Newsletter-Anmeldungen sieht man Fehler wie fehlende Double-Opt-In oder keine Erwähnung des Dienstleisters in der Datenschutzerklärung. Auch gern vergessen: AV-Verträge. Wenn das Website-Hosting bei einem externen Dienst liegt oder ein externer Formulardienst genutzt wird, benötigt die Schule einen Vertrag zur Auftragsverarbeitung mit dem Anbieter
– sonst verarbeitet ein Dritter Schul-Daten ohne klare rechtliche Basis.
Safer Alternative: Eigenes Kontaktformular DSGVO-konform gestalten. Anstatt einen externen Formulardienst (wie Google Forms, Microsoft Forms etc.) zu nutzen, richten Sie ein internes Formular in Ihrem CMS ein. Alle gängigen Systeme (WordPress, Joomla, Typo3, Drupal etc.) bieten Formulare, die entweder per E-Mail versenden oder in der Datenbank speichern. Wichtig: Datensparsamkeit – fragen Sie nur wirklich nötige Infos ab. Für eine Krankmeldung z.B. genügen Name, Klasse, Datum – Gesundheitsdetails lieber nicht online erfassen (oder dann sehr gut schützen)
. Keine externen Ressourcen im Formular: Verwenden Sie kein Google reCAPTCHA. Alternative Spamabwehr: Es gibt datenschutzfreundliche Captcha-Alternativen: z.B. hCaptcha (Sitz in EU wählbar) oder Friendly Captcha (ein europäischer Dienst, der ohne Tracking auskommt). Diese können eingebunden werden, aber auch hier sollte man in der Datenschutzerklärung darauf hinweisen und möglichst einen AV-Vertrag abschließen. Noch besser: eigene Lösungen wie eine einfache Rechenaufgabe („Wieviel ist 3 plus 1?“) oder ein sogenanntes Honeypot-Feld (ein verstecktes Feld, das Bots ausfüllen, Menschen aber nicht – so filtert man Bots raus ohne Nutzerinteraktion). Diese Methoden kommen ohne externe Anbieter aus. Für Newsletter empfehlen sich EU-basierte Services (z.B. Sendinblue ehemals Newsletter2Go, oder CleverReach), mit denen man AV-Verträge schließen kann, oder man betreibt einen einfachen Verteiler selbst (z.B. via EduMailinglisten). WhatsApp & Co.: Wie oben erwähnt, besser Alternative Messenger nutzen. Manche Schulen verlinken etwa auf einen Telegram-Channel oder nutzen datenschutzkonforme Lösungen wie SchoolFox oder EDU Messenger – diese sollten aber nicht über die öffentliche Website laufen, sondern in geschützten Bereichen.
Empfohlene Umsetzung: Bei jedem Formular auf Ihrer Website gilt: Transparenz und Einwilligung. Platzieren Sie unter dem Abschicken-Button eine Checkbox, mit der der Absender bestätigt, dass seine Angaben verarbeitet werden dürfen
. Das Feld darf nicht vorab angehakt sein. Formulieren Sie einen kurzen Einwilligungstext, z.B.: „Mit dem Absenden erkläre ich mich einverstanden, dass die Daten zur Bearbeitung meiner Anfrage elektronisch verarbeitet werden. Hinweise zum Datenschutz und Widerruf finden Sie in unserer Datenschutzerklärung.“. Ohne Häkchen darf das Formular nicht versendet werden. Außerdem braucht Ihre Datenschutzerklärung einen Abschnitt zum Kontaktformular: Welche Daten werden erhoben, wofür, wie lange gespeichert, wer empfängt sie (z.B. Mail wird an sekretariat@schule geschickt), auf welcher Rechtsgrundlage (i.d.R. Einwilligung oder bei schulischen Anfragen ggf. auch öffentliche Aufgabe), und Hinweis auf Widerrufsmöglichkeit. Speicherdauer minimieren: Stellen Sie technisch sicher, dass Formulareinträge nicht unnötig lang gespeichert bleiben. Ideal: Die Formulardaten werden nur per E-Mail versendet und gar nicht dauerhaft auf dem Webserver gespeichert. Falls Ihr System sie speichert, richten Sie regelmäßige Löschung ein. Löschen Sie alte Kontakt-E-Mails, sobald sie erledigt sind. Auftragsverarbeiter-Verträge: Betreiben Sie die Website bei einem Webhoster (was üblich ist), schließen Sie mit diesem einen AV-Vertrag ab. Stellen Sie sicher, dass der Hoster Daten in der EU speichert (besser noch: in Deutschland). Wenn Sie externe Tools wie einen Newsletter-Dienst einsetzen, ebenfalls Vertrag und EU-Server nutzen. Keine Google Forms: Das hat eine Datenschutz-Expertin mal auf den Punkt gebracht: „Wer für die Krankmeldung ein Google Formular nutzen möchte, sollte davon besser Abstand nehmen.“ – d.h. vermeiden Sie, dass Schüler- oder Elterndaten über Google-Server laufen. Schließlich: SSL-Verschlüsselung ist Pflicht – Ihr Formular muss über https:// laufen, damit die eingegebenen Daten nicht als Klartext abfließen. Zusammengefasst: Kontaktformulare sind nützlich, aber nur DSGVO-konform mit informierter Einwilligung, sicherer Übertragung und minimaler Datenerhebung/-speicherung. Dann können sie auch auf Schulwebsites rechtssicher eingesetzt werden.
Kalender und Terminplanung (Google Calendar, Buchungstools, Terminfindung)
Typische Nutzung: Schulen veröffentlichen Termine für Veranstaltungen, Ferien, Elternabende etc. Manche nutzen dazu einen eingebetteten Kalender – z.B. einen öffentlichen Google Calendar iframe oder einen Outlook.com-Kalender. Andere bieten Online-Terminreservierung (z.B. für Elternsprechtage via Doodle-Link oder Buchungs-Plugins).
Risiko: Mittel. Ein eingebetteter Google Calendar funktioniert technisch ähnlich wie Google Maps – er lädt fremde Inhalte von Google und überträgt dabei Daten an US-Server. Somit ist er ohne Opt-In nicht DSGVO-konform (siehe Karten) und einzeln betrachtet einwilligungsbedürftig. Die Sensibilität ist etwas geringer als bei Videos, aber dennoch: Es fließen Meta-Daten (welche Seite wurde besucht und wann) an Google. Bei Online-Buchungstools (Doodle, Calendly o.ä.) werden oft Nutzerdaten direkt beim Drittanbieter erfasst, was Auftragsverarbeitung und Einwilligung bedingt. Barrierefreiheit: Kalender-Widgets sind oft nicht barrierefrei – z.B. kleine Monatsübersichten, die nur via Maus bedienbar sind, oder Termin-Auswahldialoge, die Screenreader-Nutzer vor Probleme stellen. Wenn wichtige Termine nur in einer Grafik/Agenda ohne Text verfügbar sind, entsteht ein Hindernis.
Häufige Fehler: Google Calendar Embed ohne Hinweis – viele Schulen betten einfach ihren Google-Kalender ein, damit die Website automatisch alle Termine anzeigt. Dabei denken sie nicht daran, dass schon beim Laden Google nach Hause „funkt“. Zudem sind diese Kalenderframes oft schlecht lesbar für alle (kleine Scrollfenster) und für Screenreader unbrauchbar. Weiterer Fehler: Terminfindungstools wie Doodle einzusetzen, ohne zu prüfen, wo die Daten der Eltern landen (Doodle ist zwar Schweizer Anbieter, aber free-Versionen sind öffentlich einsehbar und werbefinanziert). Oft fehlt ein Hinweis im Voraus, dass man dafür z.B. auf doodle.com weitergeleitet wird – plötzlich befinden sich Eltern auf einer externen Seite, evtl. verwirrt über Datenschutz.
Safer Alternative: Interne Kalender oder statische Terminübersichten. Statt einen externen Kalenderdienst einzubetten, können Sie Termine manuell auf der Website pflegen – z.B. als einfache Liste oder Tabelle mit Datum und Ereignis. Das verursacht keinerlei Datenabfluss und kann barrierefrei formatiert werden (HTML-Tabelle mit Kopfzeilen, etc.). Sie können diese Liste monatlich aktualisieren. Alternativ bieten manche Schul-CMS Plugins oder Module für Veranstaltungen, die auf dem Server laufen (z.B. in Typo3 eine Extension, in WordPress ein Calendar-Plugin – darauf achten, dass dieses keine externen Abhängigkeiten hat). iCal/ICS-Downloads: Ein praktischer Mittelweg: Stellen Sie einen ICS-Kalender (iCalendar-Datei) mit allen Terminen zum Download bereit. Eltern können diese Datei in ihr Kalenderprogramm importieren. Das ist datenschutzfreundlich, da die Datei vom Schulserver geladen wird ohne Tracking. Der Nachteil ist, dass Benutzer manuell aktualisieren müssten bei Änderungen – sofern Sie nicht einen abonnierten ICS-Feed einrichten. Einige Lösungen (Nextcloud z.B.) erlauben einen öffentlichen schreibgeschützten Kalender-Link, den Eltern abonnieren können. Das wäre auch denkbar, sofern Nextcloud/Server datenschutzkonform gehostet ist (z.B. beim Schulträger).
Empfohlene Umsetzung: Verzichten Sie möglichst auf eingebettete externe Kalender. Die wichtigsten Schultermine (Ferien, Prüfungen, Events) lassen sich gut in einer Übersicht auf der Website darstellen – das ist 100% DSGVO-konform und auch für alle zugänglich. Wenn Sie auf interaktive Kalender setzen wollen, prüfen Sie Open-Source-Lösungen: Es gibt z.B. Teamup (EU-Server Option) oder Nextcloud Calendar wie erwähnt. Sollte dennoch ein Google Calendar genutzt werden, dann analog zu Maps nur als Link oder Zwei-Klick-Embed: Also vielleicht ein Button „Kalender anzeigen (Google)“, der dann auf eine separate Seite mit dem richtigen Google-Embed führt – und auf dieser Seite klar sagen, dass jetzt Google-Daten geladen werden. So wird vermieden, dass auf jeder Seite direkt Google mitschnüffelt. Buchungstools: Falls Sie Terminreservierungen online ermöglichen (für Elternsprechtag etc.), bevorzugen Sie Lösungen innerhalb der Schulwelt. Einige Schulverwaltungsportale bieten Terminverwaltung, oder Sie nutzen Umfragetools, die datenschutzgeprüft sind (manche Bundesländer stellen Nextcloud oder LimeSurvey bereit). Wenn externe Dienste wie Doodle eingesetzt werden, dann nicht direkt einbetten, sondern maximal verlinken mit Hinweis („Sie verlassen unsere Website“). Und nur wenn es wirklich nötig ist – oft geht es auch per altmodischer Anmeldung via Sekretariat. Barrierefreiheitshinweis: Stellen Sie sicher, dass Termine auch im Klartext auffindbar sind. Eine eingebettete Kalender-Grafik ohne Textalternative wäre ein No-Go. Wenn Sie PDF-Terminkalender anbieten, achten Sie darauf, dass das PDF barrierefrei ist (getaggte Tabellen etc.) oder bieten Sie alternativ HTML an. Zusammengefasst: Termine lieber direkt auf der Website pflegen oder als Download, statt Dritten wie Google & Co. die Daten anzuvertrauen.
Dokumente, Downloads und eingebettete Dateien (PDFs, Cloud-Hosting)
Typische Nutzung: Schulen stellen diverse Dokumente online: Elternbriefe als PDF, Anmeldeformulare, Lehrpläne, manchmal auch Präsentationen oder Fotosammlungen. Mitunter werden solche Inhalte bei externen Diensten gehostet – z.B. ein PDF via Google Drive/Dropbox geteilt, Videos über YouTube (s.o.) oder Präsentationen per Slideshare eingebettet.
Risiko: Mittel. Ein Download-Link auf ein PDF, das auf dem eigenen Server liegt, ist unproblematisch. Problematisch wird es, wenn externe Cloud-Dienste genutzt werden: Beispielsweise ein OneDrive-Embed eines Word-Dokuments oder ein PDF-Viewer von Google. Dann gilt wieder: Beim Laden der Seite fließen Daten an den Cloud-Anbieter. Zudem könnten die extern gehosteten Dateien gegen Datenschutz verstoßen, falls z.B. personenbezogene Daten ungeschützt abrufbar sind. Barrierefreiheit: PDFs und Dokumente sind ein eigenes Thema – viele PDFs sind nicht barrierefrei (nicht durchsuchbar, keine Tags, schlecht formatiert). Einfache Scans können von Screenreadern nicht gelesen werden
. Eingebettete Dokument-Viewer sind oft ebenfalls nicht barriereoptimal (z.B. kein ausreichender Zoom, Tastatursteuerung fehlt).
Häufige Fehler: Dokumente bei externen Hosts lagern. Z.B. ein Elternbrief wird in Google Drive hochgeladen und auf der Website nur verlinkt. Wer das PDF öffnet, tut dies via Google-Viewer im Browser – Google sieht die IP und eventuell den Google-Account der Person. Außerdem riskant: unverschlüsselte personenbezogene Daten in Downloads. Manche Schulen stellen Listen oder Fotos online, ohne zu bedenken, dass diese öffentlich abrufbar sind. Auch fehlende Alternativen sind ein Fehler: Ein PDF-Formular ohne barrierefreie Version bereitstellen verstößt gegen die Pflicht zur barrierefreien Zugänglichkeit (dokumente müssen laut BITV zugänglich sein, es sei denn unverhältnismäßige Belastung wird geltend gemacht)
.
Safer Alternative: Dateien auf dem Schulserver hosten. Nutzen Sie möglichst immer das eigene Webhosting für Downloads. Dann haben Sie volle Kontrolle: Kein Dritter erhält beim Abruf Infos. Moderne Schul-Webserver können PDF/DOC-Dateien problemlos ausliefern. Wenn die Datei zu groß/sensibel ist, überlegen Sie, ob sie überhaupt öffentlich sein sollte. Passwortgeschützte Bereiche: Falls Ihre Website einen geschützten Login-Bereich für z.B. Lehrer oder Eltern hat, laden Sie sensible Dokumente dort hoch statt auf die offene Homepage. So sind sie nur für Berechtigte zugänglich. Keine unnötigen Embeds: Ein PDF muss nicht im Browser via Google-Viewer eingebettet werden – ein normaler Link zum PDF reicht, die meisten Browser haben einen eigenen PDF-Viewer integriert. Für Bildergalerien verwenden Sie lieber lokale Lightbox-Skripte als externe Plugins von z.B. Adobe.
Empfohlene Umsetzung: Halten Sie eine zentrale Download/Medien-Richtlinie ein: Alle Dokumente/Medien werden auf schulischen Systemen gespeichert (Schulwebsite, Schulserver, Nextcloud der Schule, etc.). Vermeiden Sie es, Schulmaterial auf privaten Cloud-Accounts abzulegen und zu verlinken. Sollte Cloud-Speicher nötig sein (z.B. große Dateien, Videostreams), nutzen Sie datenschutzkonforme Lösungen – einige Bundesländer bieten Schulen eigene Cloud-Dienste an. Barrierefreiheit sicherstellen: PDFs barrierefrei machen ist Pflicht für neu eingestellte Dokumente. Nutzen Sie die Barrierefreiheitsfunktionen in Word/Acrobat (Überschriften, Alternativtexte, Lesereihenfolge). Testen Sie PDF-Dateien mit dem PDF Accessibility Checker. Für wichtige Inhalte überlegen Sie, HTML-Alternativen anzubieten – z.B. statt eines reinen PDF-Rundbriefs den Inhalt auch als Webseite oder zumindest als barrierearmes PDF. In Ihrer Barrierefreiheitserklärung sollten Sie deklarieren, welche Inhalte evtl. (noch) nicht barrierefrei sind und wie man alternative Zugänge erhält
. In Summe: Dokumente am besten intern hosten, gut absichern (Passwort falls nötig) und barrierefrei bereitstellen. So bleiben Sie auf der sicheren Seite.
Zahlungsabwicklung, Spenden und Ticketing
Typische Nutzung: Manche Schulen sammeln Spenden über die Website (z.B. per „Donate“-Button via PayPal), verkaufen Tickets für Schulveranstaltungen oder betreiben vielleicht einen kleinen Shop (Jahrbücher, T-Shirts). Solche Funktionen sind selten, aber kommen vor, meist initiiert vom Förderverein o.Ä.
Risiko: Mittel. Zahlungsabwicklung erfordert immer personenbezogene Daten (Name, evtl. Adresse, Zahlungsinfos). Wenn Sie einen externen Zahlungsdienst einbinden (PayPal, Stripe, Betterplace etc.), werden diese Daten an den Dienst übertragen. Das ist in der Regel gewollt (der Nutzer zahlt ja darüber), aber muss datenschutzrechtlich sauber erfolgen: Rechtsgrundlage (z.B. Vertragserfüllung bei Ticketkauf oder Einwilligung), AV-Vertrag wenn der Dienst als Auftragsverarbeiter agiert, und Information der Nutzer. Bei Spenden über PayPal z.B. gilt PayPal als eigener Verantwortlicher für die Zahlung – die Schule muss aber transparent machen, dass sie PayPal nutzt und welche Daten ggf. fließen. Barrierefreiheit: Zahlungsformulare von Dritten könnten Barrieren haben (aber große Anbieter wie PayPal sind meist relativ barrierefrei gestaltet). Trotzdem sollte man darauf achten, dass der Prozess auch für Menschen mit Behinderungen nutzbar ist (z.B. keine CAPTCHA-Hürden beim Zahlungsformular).
Häufige Fehler: Einbettung eines kompletten Spendenformulars mittels iframe von Spendenplattformen, ohne Hinweis. Auch hier: So ein Widget lädt externe Ressourcen und trackt Nutzer, evtl. schon wenn sie nur die Seite aufrufen. Oder man integriert ein PayPal-Bezahlfenster direkt – was wiederum Cookies setzt. Oft fehlen Datenschutzhinweise („Wenn Sie spenden, gelten die Datenschutzbestimmungen von …“). Ein weiteres Versäumnis: Keine Klarheit über Verantwortlichkeit – bei Spenden könnte es sein, dass z.B. der Förderverein der eigentliche Verantwortliche ist, nicht die Schule. Das sollte dann auch so kommuniziert werden (Impressum/Datenschutzhinweis des Vereins).
Safer Alternative: Externe Zahlungsseiten nur verlinken. Statt ein Zahlungsformular auf der Schulwebsite einzubetten, nutzen Sie einen einfachen Button oder Link: „Spenden via PayPal“ – dieser führt dann auf die PayPal-Seite oder öffnet PayPal in neuem Fenster. So findet die eigentliche Datenverarbeitung (Eingabe von Betrag, Login etc.) direkt bei PayPal statt und nicht eingebettet auf Ihrer Seite. Ihre Website hat dann nur die Rolle des „Vermittlers“ und speichert keine Zahlungsdaten. Für Ticketing könnten Sie ähnlich verfahren: Auf die externe Ticket-Plattform verlinken. Noch besser wäre es natürlich, Zahlungen offline oder per Überweisung abzuwickeln (gerade Schulen könnten bei Spenden einfach ihre Bankverbindung angeben – das ist zwar weniger komfortabel, aber datenschutztechnisch simpel).
Empfohlene Umsetzung: Wenn Ihre Schule oder Ihr Förderverein unbedingt Online-Zahlungen anbietet, klären Sie vorher die Zuständigkeiten und Verträge. Ist die Schule selbst der Anbieter, brauchen Sie einen AV-Vertrag mit dem Zahlungsdienstleister, falls dieser in Ihrem Auftrag Daten verarbeitet (z.B. bei einem Ticketshop, wo Sie als Verkäufer auftreten)
. Bei PayPal-Spenden hingegen agiert PayPal meist als eigenständiger Verantwortlicher für die Zahlung – die Schule muss aber trotzdem die Nutzer informieren, dass deren Daten an PayPal übermittelt werden. Schreiben Sie in die Datenschutzerklärung einen Abschnitt „Spenden und Online-Zahlungen“, in dem Sie erklären, welchen Dienst Sie nutzen und dass dort ggf. weitere Daten erhoben werden. Keine Einbettung: Platzieren Sie Spendenbuttons als normale Links. Nutzen Sie ggf. das offizielle PayPal-Button-HTML (das lädt zwar auch ein kleines Bild von PayPal-Servern – hier könnten Sie alternativ ein eigenes Bild/Icon verwenden, um das zu vermeiden). Ticketing: Falls Sie Event-Seiten haben, bieten Sie die Ticketbuchung durch klare Links an: z.B. „Ticket kaufen über Eventbrite“ – und erwähnen Sie, dass beim Klick der externe Anbieter genutzt wird. Intern alternative anbieten: Vielleicht kann man Tickets auch im Sekretariat kaufen oder per E-Mail reservieren – nicht jeder will seine Daten online eingeben. In jedem Fall: Halten Sie die Grundsätze der DSGVO ein – Datenminimierung (fordern Sie nur die Daten, die nötig sind), Zweckbindung (Zahlungsdaten nur für den Spendenzweck nutzen), Speicherbegrenzung (Löschen Sie z.B. Listen der Spender nach Abschluss des Projekts, soweit nicht Buchhaltung dem entgegensteht). Mit einem durchdachten Vorgehen bleiben auch solche Online-Transaktionen im Rahmen des Erlaubten.
Sonstige Einbindungen (Übersetzungs-Widgets, Chat-Funktionen, Cookie-Banner)
Typische Nutzung: Unter „Sonstiges“ fallen diverse Tools: Übersetzungs-Widgets (z.B. Google Translate Plugin) für mehrsprachige Infos, Live-Chat-Fenster für Besucheranfragen, aber auch Cookie-Consent-Tools selbst sind kleine Einbindungen. Schulen haben seltener Chats, aber manche Webseiten von Schulprojekten oder Bibliotheken könnten sowas haben. Ein Übersetzungs-Plugin könnte an internationale Eltern gedacht sein.
Risiko: Variabel. Ein Google-Translate-Plugin, das die Seite automatisch übersetzt, sendet im Hintergrund den ganzen Seiteninhalt an Google zur Analyse – damit gehen u.U. personenbezogene Inhalte durch die Übersetzungs-API. Das ist datenschutzrechtlich problematisch, vor allem ohne Hinweis. Chat-Widgets von Drittanbietern (wie tawk.to, Userlike etc.) sammeln oft Daten der Besucher (Name, Chatverlauf) und brauchen AV-Verträge und Einwilligung, wenn z.B. Tracking-Funktionen eingebaut sind. Cookie-Banner/CMPs: Ironischerweise können auch diese Tools selbst Daten abziehen. Manche Consent-Management-Plattformen laden z.B. Scripts von deren Server oder analysieren Klicks.
Häufige Fehler: Automatische Übersetzung einbinden (Google Translate Script), ohne zu beachten, dass Google dann alles mitlesen kann. Hier fehlen fast immer Hinweise, und streng genommen darf man das nicht ohne Einwilligung tun (da Inhalt und ggf. Nutzerdaten an Google übermittelt werden). Chat-Plugin live schalten ohne zu prüfen, ob der Anbieter DSGVO-konform arbeitet. Z.B. ein Schulhomepage-Design übernimmt mal eben ein Chat-Fenster (vielleicht versehentlich von der Template-Vorlage) – plötzlich können Besucher Nachrichten eintippen, die dann über fremde Server laufen. Cookie-Banner: Viele Schulen setzen einen vorgefertigten Cookie-Banner ein, der z.B. von einem Dienstleister gehostet wird (wie Cookiebot). Dabei wird oft nicht beachtet, dass dieser Dienstleister zumindest die IP der Besucher sieht. Zudem sind Cookie-Banner selbst oft nicht barrierefrei: Häufig lässt sich der Banner schwer per Tastatur schließen oder die Kontrastverhältnisse sind schlecht – was gegen die Barrierefreiheitsregeln verstößt.
Safer Alternative: Übersetzung: Statt eines automatischen Tools könnte man zumindest für Hauptsprachen (Englisch, Türkisch etc.) einige Kerninformationen manuell übersetzen und als PDF oder extra Seite anbieten. Wenn ein Tool, dann besser nur ein Link zu Google Translate: z.B. „Diese Seite auf Englisch anzeigen (via Google Translate)“. Das öffnet Google Translate in einem neuen Tab mit Ihrer URL – der Nutzer initiiert es bewusst. Besser als automatisches Skript. Chat: Bei Bedarf lieber einen einfachen Kontaktweg anbieten (Kontaktformular, Sprechzeiten) als einen unsicheren Chat. Wenn Chat, dann vlt. Open-Source-Lösungen hosten (schwieriger) oder sicherstellen, dass der Anbieter Sitz in EU hat und AV-Vertrag bietet. Cookie-Banner: Wenn Sie um Cookies nicht herumkommen, nutzen Sie am besten selbst gehostete Consent-Tools (es gibt Open-Source-Lösungen) oder implementieren Sie eine einfache Eigenlösung (z.B. ein simpler Hinweis + Auswahl ohne ganze Tracking-Suite). So bleiben die Daten lokal. Auf jeden Fall designen Sie das Banner barrierefrei: Klare Fokus-Reihenfolge, sichtbarer „Ablehnen“-Button, Beschreibung für Screenreader, kein Timeout.
Empfohlene Umsetzung: Übersetzungsangebote: Weisen Sie im Impressum oder Header darauf hin, welche Sprachen es gibt. Wenn Sie Google Translate nutzen wollen, nicht automatisch laden, sondern beispielsweise kleine Flaggen oder Links setzen: „Englisch“ -> beschreibt, dass bei Klick ein externer Übersetzungsdienst genutzt wird. Chat-Funktion: Prüfen Sie, ob der Nutzen den Aufwand rechtfertigt. In Schulen wahrscheinlich weniger nötig. Wenn ja, holen Sie vor Start des Chats eine Einwilligung ein („Mit Start des Chats willigen Sie in die Verarbeitung Ihrer Daten durch [Anbieter] ein…“). Bieten Sie alternativ eine E-Mail an. Cookie-Consent: Falls Ihre Seite ohne Cookies von Drittanbietern auskommt, schalten Sie den Banner ab! Ein Hinweis in der Datenschutzerklärung reicht dann. Viele Schulen haben aus Unwissenheit einen Cookie-Banner, obwohl gar keine Cookies gesetzt werden außer vielleicht einem Session-Cookie – das verwirrt nur. Wenn Sie einen Consent-Banner benötigen (weil externe Dienste drauf sind), halten Sie ihn schlank: keine vorangekreuzten Optionen, „Ablehnen“ gleichwertig anbieten, und nur wirklich notwendige Kategorien auflisten. Testen Sie das Banner mit Tastatur und Screenreader – er darf nicht zur unüberwindbaren Barriere werden, die Nutzer vom eigentlichen Inhalt abhält. Oft liegt hier der Teufel im Detail: Ein Overlay ohne Fokus-Management kann z.B. Screenreader-Nutzer einsperren. Also im Zweifel lieber minimalistisch.
Zwischenfazit
Zwischenfazit: Die obigen Kategorien decken die häufigsten Drittanbieter-Inhalte auf Schulhomepages ab – von YouTube-Videos über Google Maps und Fonts bis Social Media, Formularen & Co. Generell lässt sich sagen: Risiko hoch ist alles, was Tracking oder externe Verbindungen ohne Nutzeraktion auslöst (Video, Social, Analytics, fremde Widgets). Risiko mittel sind Dienste, die zwar Daten senden, aber ggf. auch datenschutzfreundlich konfigurierbar sind (z.B. Matomo, OSM, interne Formulare). Risiko niedrig sind Dinge wie rein lokale Lösungen oder statische Inhalte. Die folgende Tabelle fasst einige gängige Dienste, ihr Risiko, Alternativen und empfohlene Einbindungsweise zusammen:
| Dienst (Kategorie) | Risiko | Alternative | Empfohlene Umsetzung |
|---|---|---|---|
| YouTube (Video) | Hoch | Selbsthosting oder Vimeo<sup>*</sup> (ähnl. Problem) | Nur mit youtube-nocookie + 2-Klick-Lösung einbetten |
. Hinweis auf DSGVO, Untertitel bereitstellen. Alternativ: Vorschau-Bild mit Link auf YouTube.Google Maps (Karten)HochOpenStreetMap (EU)2-Klick-Embed mit Hinweis. Oder statische Karte/Adressangabe statt Live-Map. OSM via eigenem Tile-Server proxyen für volle DSGVO-Konformität
| . |
| Google Fonts (Schrift) | Hoch | Lokales Hosting der Fonts | Lokal einbinden statt extern |
. Font-Dateien downloaden (z.B. über Google Webfonts Helper)
| . Keine externen CSS/Font-Links mehr. |
| Google Analytics (Tracking) | Hoch | Matomo (selbst gehostet) | Nicht nutzen, besser Matomo o.ä. mit IP-Anonymisierung und ohne Cookies konfigurieren |
. Consent-Banner nötig falls Tracking über notwendiges hinausgeht
| . |
| Instagram Feed (Social) | Hoch | Nur Link auf Instagram-Seite | Nicht automatisch einbetten |
| . Wenn überhaupt, dann mit Platzhalter und erst nach Klick laden. Besser: statische Galeriebilder manuell einpflegen oder einfach verlinken. |
| Facebook „Like“-Button (Social) | Hoch | Shariff-Button oder Link | Keine originalen Plugins einbinden. Stattdessen Shariff nutzen für Share/Like |
| , oder einfach Icon mit Link auf Ihre FB-Seite. |
| Twitter-Tweets (Social) | Hoch | Screenshot/Zitat | Nicht direkt einbetten – entweder per Embetty/2-Klick laden |
oder den Tweet-Inhalt als Text/Zitat einfügen
| . |
| reCAPTCHA (Spam-Schutz) | Hoch | z.B. hCaptcha, Friendly Captcha (EU) oder Frage-Captcha | Nur falls nötig – besser einfache Captcha-Fragen nutzen. Wenn Einsatz, dann Einwilligung erforderlich vor Aktivierung |
| . Alternativen ohne Tracking bevorzugen, AV-Vertrag abschließen. |
| WhatsApp-Link (Kontakt) | Mittel | Threema, Signal oder nur E-Mail/Telefon | Offiziell meiden (WhatsApp ist datenschutzrechtlich nicht sauber für Schulen) |
| . Falls dennoch Nummer angeben, klarstellen, dass externer Dienst WhatsApp genutzt wird (freiwillig). | |||
| Google Calendar (Kalender) | Mittel | ICS Download, interner Kalender | Nicht direkt einbetten. Termine lieber manuell auflisten. Wenn Google-Cal, dann nur als Link oder 2-Klick-Embed mit Hinweis (Datenübertragung zu Google). |
| PDF via Drive/Dropbox (Dokument) | Mittel | PDF auf Schulwebserver | Keine extern gehosteten PDFs einbetten. Dateien direkt von eigener Website anbieten (sofern DSGVO-konform veröffentlicht). Alternativ Nextcloud mit EU-Hosting. |
| Cookiebot Cookie-Banner (Consent) | Mittel | Klaro (self-hosted) o.ä. | Consent-Tool auf eigenem Server hosten. Bei externen CMPs prüfen, ob Datenübermittlung erfolgt. Banner barrierefrei gestalten (Fokus, Labels). |
| Google Translate Widget (Übersetzung) | Hoch | Manuelle Übersetzungen | Nicht automatisch laden. Allenfalls Link auf Google Translate anbieten. Hinweis: maschinelle Übersetzung, Daten an Google. |
| Live-Chat (z.B. tawk.to) | Hoch | Kontaktformular/Telefon | Wenn nötig, EU-basierten Chat mit AV wählen. Vor Chatstart Einwilligung abfragen. Sonst lieber klassische Kontaktwege nutzen. |
<small><sup>*</sup> Hinweis: Auch Vimeo, SoundCloud etc. sind Drittanbieter mit ähnlichen Datenschutzfragen – die Empfehlungen (2-Klick, Hinweis) gelten analog.</small>
Diese Tabelle zeigt: Oft gibt es datenschutzfreundliche Alternativen (lokal hosten, verlinken statt einbetten, EU-Dienste statt US-Dienste). Und wo man Drittinhalte nutzt, gibt es bewährte Muster: Zwei-Klick-Lösungen, Einwilligung einholen, AV-Verträge schließen, transparente Informationen geben. Im nächsten Abschnitt zeigen wir, wie Schulen eine Entscheidung treffen können, ob und wie ein externer Dienst zum Einsatz kommen darf.
Entscheidungsframework: Brauchen wir diesen Dienst – und wenn ja, wie?
Bevor Sie einen Drittanbieter-Dienst auf der Schulhomepage einsetzen, lohnt es sich, ein paar Schlüssel-Fragen durchzugehen. Diese kann man als kleine Checkliste oder Entscheidungsbaum nutzen:
Ist der externe Inhalt wirklich notwendig? – Frage Nr. 1: Geht es auch ohne? Wenn der Mehrwert gering ist oder die Infos anders bereitgestellt werden können, verzichten Sie lieber. Jede Einbindung erhöht Komplexität und Risiko. Beispiel: Statt einem Twitter-Feed könnten Sie einfach aktuelle News direkt auf der Website veröffentlichen. Faustregel: Nur was einen echten Mehrwert bietet und anders nicht erreichbar ist, sollte eingebunden werden.
Gibt es eine datenschutzfreundliche Alternative oder Eigenlösung? – Wenn Sie den Dienst benötigen, prüfen Sie: Muss es dieser Anbieter sein? Kann ich die Funktion anders erfüllen? Vielleicht gibt es ein Open-Source-Tool oder eine Selbsthosting-Möglichkeit. Beispiel: statt Google Maps die OSM-Karte verwenden; statt YouTube-Video hochladen, selbst hosten; statt reCAPTCHA ein eigenes Quiz nutzen. Oft lässt sich so der Drittanbieter ganz vermeiden oder zumindest auf einen DSGVO-konformen Anbieter ausweichen.
Welche Daten fließen wohin? – Machen Sie sich klar, welche personenbezogenen Daten der Dienst erfassen könnte (IP-Adresse, Cookies, Eingaben der Nutzer, Nutzungsstatistiken etc.) und in welches Land sie fließen. Ist ein Drittland (außerhalb EU/EWR) dabei – z.B. USA – müssen Sie besonders strenge Anforderungen beachten (Stichwort Schrems II)
. D.h. prüfen, ob der Anbieter Standardvertragsklauseln anbietet, ob das Risiko vertretbar ist etc. Für Schulen heißt das meist: wenn US-Transfer, dann lieber lassen, es sei denn unbedingt nötig. Zeichnen Sie im Datenschutzkonzept auf, welcher Dienst was empfängt.
Benötigen wir eine Einwilligung der Nutzer? – Checken Sie rechtlich: Fällt die Nutzung des Dienstes unter einen nicht einwilligungsbedürftigen Tatbestand? Im öffentlichen Schulbereich gibt es als Rechtsgrundlage oft Art. 6 Abs.1e DSGVO (Aufgabe im öffentlichen Interesse). Aber ist z.B. ein Facebook-Feed wirklich Teil des öffentlichen Bildungsauftrags? Meist nein, sprich: Einwilligung wäre erforderlich. Als grobe Regel: Alles was nicht unbedingt technisch/funktional nötig ist, um die Website bereitzustellen, erfordert Einwilligung (laut TTDSG schon wegen Cookies etc.)
. Also planen Sie: Wenn externes Element → in aller Regel brauchen wir vorheriges Opt-In. Das können Sie durch eine Consent-Banner-Lösung erledigen oder – benutzerfreundlicher – durch einen Click-to-Load Mechanismus direkt am Inhalt. Überlegen Sie, welche Variante praktikabler ist. Wichtig: Einwilligung muss freiwillig, informiert und vor Verarbeitung erfolgen
. D.h. transparente Info und Möglichkeit, auch abzulehnen. In der Praxis heißt das 2-Klick-Modelle oder Cookie-Banner mit „Ablehnen“-Button.
Wie dokumentieren wir die Einwilligung? – Gerade wenn Sie keinen klassischen Cookie-Banner nutzen (der oft die Auswahl speichert), sondern z.B. per Klick auf einen Embed die Einwilligung einholen, sollten Sie sich überlegen, wie Sie das festhalten. Reicht ein Log-Eintrag? Oder ist es okay, es nicht individuell zu speichern (bei reiner Einwilligung in Drittinhalt ist Nachweis nicht so kritisch wie z.B. bei sensiblen Daten). Auf jeden Fall: Transparenz nach außen (Schulwebsite-Besucher müssen verstehen, was passiert) und Nachweisbarkeit intern (Schule kann zeigen, wir haben Opt-In eingebaut) sollte gegeben sein.
Benötigen wir einen Auftragsverarbeitungs-Vertrag? – Prüfen Sie, ob der externe Dienst als Auftragsverarbeiter für die Schule agiert. Das ist z.B. bei Webhosting immer der Fall (der Hoster verarbeitet Zugriffsdaten für Sie) – daher brauchen Sie dort einen AV-Vertrag
. Ebenso bei einem Newsletter-Dienst, Statistik-Dienst oder Formular-Service, der in Ihrem Auftrag Daten verarbeitet. Schließen Sie schriftliche AV-Verträge ab, bevor der Dienst aktiv Daten erhält. Viele Anbieter haben Vorlagen oder Online-Abschluss. Ein fehlender AV-Vertrag kann bei Prüfungen sofort negativ auffallen.
Sind technische und organisatorische Maßnahmen bedacht? – Stellen Sie sicher, dass Sie genügend Schutzmaßnahmen ergreifen (hier kommt Datenschutz durch Technikgestaltung ins Spiel). Z.B.: Externer Inhalt nur über HTTPS laden; wenn Inhalte gecached werden können, tun Sie das (um ständige Verbindungen zu reduzieren); Einstellungen des Dienstes datenschutzfreundlich setzen (z.B. Analytics: IP-Anonymisierung aktivieren
, bei Videoplayer: kein Autoplay). Auch Zugriffsbeschränkungen intern gehören dazu – wer kann die Daten einsehen, wer administriert den Dienst? Halten Sie solche Maßnahmen schriftlich fest (für Rechenschaftspflicht).
Ist der Inhalt barrierefrei zugänglich? – Bevor Sie „Go“ sagen, prüfen Sie die Barrierefreiheit: Kann ein Nutzer mit Behinderung die Information erhalten, auch wenn der Drittinhalt evtl. nicht barrierefrei ist? Wenn nein, sorgen Sie für eine Alternativlösung. Beispiel: Ein Video ohne Untertitel → erstellen Sie zumindest eine Textzusammenfassung des Gesagten, die daneben steht. Eine Karte → Adresse und Beschreibung daneben angeben. Ein grafisches Social-Media-Feed → wichtige Inhalte auch anders bereitstellen. Achten Sie auf Tastaturbedienbarkeit: Testen Sie mal ohne Maus, ob man alles bedienen kann (inkl. eingebettete Elemente). Falls das externe Element nicht BITV-konform ist und Sie es trotzdem nutzen wollen, müssen Sie das in der Barrierefreiheitserklärung der Website angeben (inkl. Begründung, warum noch nicht barrierefrei, und wie man alternativ Infos bekommt)
.
Schulleitung/Datenschutzbeauftragten einbinden? – Holen Sie bei Unsicherheiten den behördlichen oder örtlichen Datenschutzbeauftragten zurate, falls vorhanden. Auf jeden Fall sollte die Schulleitung über die Einbindung externer Dienste entscheiden bzw. es genehmigen, denn sie trägt am Ende die Verantwortung
. Es empfiehlt sich, einen internen Prozess festzulegen: z.B. „Wer neue Inhalte/Plugins einbauen will, muss vorher diese Checkliste durchgehen und die Schulleitung informieren“. Lieber eine Minute mehr Abstimmung als später eine Beschwerde am Hals.
Dokumentation und Datenschutzerklärung anpassen. – Jede Nutzung externer Dienste muss transparent dokumentiert werden. Passen Sie Ihre Datenschutzerklärung an: alle eingesetzten externen Tools aufführen, deren Anbieter (mit Adresse), welche Daten übermittelt werden, zu welchem Zweck, auf welcher Rechtsgrundlage, und falls relevant Hinweis auf gemeinsame Verantwortlichkeit oder AV-Vertrag
. Auch im Verzeichnis der Verarbeitungstätigkeiten (sofern die Schule eines führt) sollten Sie solche Website-Dienste eintragen – z.B. Verarbeitung „Betrieb der Schulwebsite“ mit Unterpunkten für jedes Tool (Analytics, Video-Plattform, etc.). Dies hilft, intern einen Überblick zu behalten. Ebenso: Zuständigkeiten benennen – wer ist Administrator für die Website, wer kümmert sich um Cookie-Banner, wer aktualisiert die Rechtstexte. All das sollte schriftlich fixiert oder zumindest klar kommuniziert sein.
Diese Fragen helfen, eine sinnvolle Entscheidung zu treffen: Do we need it? Can we make it safer? Under what conditions? So bleibt man Herr der Lage und kann im Zweifel begründen, warum man etwas einsetzt oder eben darauf verzichtet hat.
DSGVO-Checkliste für externe Dienste (Praxis-Schritte)
Wenn Sie bereits bestehende externe Einbindungen auf Ihrer Schulhomepage haben oder neue einführen möchten, gehen Sie diese Checkliste durch, um nichts Wesentliches zu übersehen:
(1) Bestandsaufnahme aller Drittinhalte: Verschaffen Sie sich einen Überblick: Welche externen Dienste, Plugins, Frames, Skripte sind auf der Website eingebunden? Nutzen Sie Entwickler-Tools oder Online-Scanner (z.B. Webbkoll, CSP-Reporter) um alle externen Requests zu erkennen. Führen Sie eine Liste: z.B. „YouTube-Video auf Startseite, Google Fonts im Theme, Twitter-Button im Footer…“.
(2) Bewertung und Priorisierung: Schätzen Sie pro Eintrag ein: Ist das notwendig? Ist es hoch riskant (Tracking, personenbezogene Daten)? Priorisieren Sie, welche sofort ersetzt oder entfernt werden sollten (z.B. Google Fonts extern – das ist einfach lösbar und sollte sofort gemacht werden). Weniger kritisches (z.B. ein Link auf Google Maps, der erst bei Klick Daten sendet) kann tiefer eingestuft werden.
(3) Rechtsgrundlage klären: Legen Sie für jeden Dienst fest, auf welcher Rechtsgrundlage er betrieben wird. Oft wird das Einwilligung sein (Art. 6 Abs.1a DSGVO) – z.B. bei YouTube-Videos, Social-Embeds, Cookies. Manchmal könnte ein berechtigtes Interesse (Art. 6 Abs.1f) argumentiert werden, aber bei öffentlichen Schulen ist das selten passend, weil deren Handeln meist entweder öffentliches Interesse (6(1)e) oder eben einwilligungsbasiert ist. Öffentliches Interesse könnte für Sachen gelten, die zum Bildungsauftrag gehören – aber z.B. ein Instagram-Feed zählt nicht dazu, das ist eher Öffentlichkeitsarbeit (wo oft lieber Einwilligung genommen wird). Dokumentieren Sie diese Entscheidung für sich.
(4) Consent-Mechanismus umsetzen: Für alle Dienste, die einwilligungspflichtig sind, implementieren Sie einen Mechanismus zur Einwilligungseinholung. Das kann zentral via Cookie-Banner/Consent-Manager geschehen, oder dezentral via Zwei-Klick an den jeweiligen Inhalten (beides hat Vor- und Nachteile). Wichtig ist: Beim ersten Besuch darf keine Datenübertragung stattfinden, bevor der User zugestimmt hat
. Bei Cookie-Bannern achten Sie auf korrekte Gestaltung (kein Nudging, echte Wahlmöglichkeit) – die DSK-Orientierungshilfe Telemedien gibt hier klare Anforderungen vor. Speichern Sie die Entscheidung des Nutzers (Cookie oder im LocalStorage), damit nicht bei jedem Besuch neu gefragt wird (außer er löscht Cookies). Bieten Sie auch Widerrufsmöglichkeiten: z.B. über einen „Cookie-Einstellungen“-Link, wo man Einwilligungen ändern kann.
(5) Verträge mit Dienstleistern abschließen: Identifizieren Sie alle externen Partner, die als Auftragsverarbeiter agieren. Typische Fälle: Webhoster (Serverbetreiber), Website-Dienstleister (Agentur, die die Seite wartet und dabei Zugriff auf personenbezogene Daten haben kann), Analytics- oder Newsletter-Anbieter. Schließen Sie schriftliche AV-Verträge nach Art. 28 DSGVO
. Viele Hoster haben online abrufbare AV-Vertragsmodule – nutzen Sie diese. Haben Sie eine Agentur beauftragt, sorgen Sie dafür, dass ein Vertrag existiert, der regelt, was die Agentur mit den Daten (z.B. Zugriff auf CMS mit Nutzerdaten) tun darf und welche Schutzmaßnahmen gelten.
(6) Drittlands-Check: Prüfen Sie bei jedem Dienst, ob Daten in ein Nicht-EU-Land fließen könnten (USA, Russland, etc.). Falls ja, müssen Sie zusätzliche Maßnahmen ergreifen: Entweder Ersatz durch EU-Dienst, oder falls unvermeidbar, Standardvertragsklauseln vereinbaren und eine sog. Transfer-Folgenabschätzung durchführen. Beispiel: Wenn Ihre Schule Office 365 für die Website nutzt und Inhalte über SharePoint Online teilt, wäre zu prüfen: Daten in USA? Wenn ja, SCC nötig + Bewertung. In der Praxis ist es oft einfacher, solche Dienste ganz zu meiden, weil die Auflagen sehr hoch sind
. DSK sagt: Wenn die Anforderungen (Art. 44 ff DSGVO) nicht eingehalten werden können, ist die Nutzung „auch mit Einwilligung nicht zulässig“
. Also eventuell Plan B: EU-Alternativen nutzen.
(7) Sicherheit überprüfen: Stellen Sie sicher, dass die IT-Sicherheit bei der Einbindung stimmt. Lade ich externe Skripte? Dann sollte ich Subresource Integrity (SRI) verwenden oder besser lokal hosten (um Manipulation vorzubeugen). Läuft alles über HTTPS? Ist die Website auf aktuellem Stand (damit z.B. kein veraltetes Plugin von einem Drittanbieter kompromittiert werden kann)? Sicherheit ist Teil des Datenschutzes (Art. 32 DSGVO verlangt angemessene Schutzmaßnahmen). Ein Beispiel: Wenn Sie ein Kontaktformular haben, muss SSL aktiv sein, sonst würden die Daten abgefangen werden können – wäre ein DSGVO-Verstoß.
(8) Datenschutzerklärung aktualisieren: Passen Sie Ihre Datenschutzerklärung der Schulwebsite an die aktuelle Lage an. Listen Sie jede externe Komponente auf: Was ist es, wer stellt sie bereit (Name/Firma, Adresse), was macht sie (z.B. „zeigt Videos von YouTube“), welche Daten werden dabei verarbeitet (IP-Adresse, evtl. Cookies, evtl. Nutzerkonto-Infos bei Login), wohin werden die Daten gesendet (z.B. USA), auf welcher Rechtsgrundlage (z.B. Einwilligung, nennen Sie idealerweise Art. 6 Abs.1a DSGVO), und weisen Sie auf die Möglichkeit zum Widerruf hin. Zudem verlinken Sie die Datenschutzerklärungen der Drittanbieter, wo möglich
. Beispiel: „Wir binden Videos der Plattform YouTube ein. Anbieter ist Google Ireland… Wenn Sie ein Video abspielen, wird eine Verbindung zu Google-Servern hergestellt. Dabei werden personenbezogene Daten (IP, evtl. Cookies) an Google übermittelt. Dies erfolgt erst nach Ihrer Einwilligung (Art. 6 Abs.1a DSGVO). Weitere Informationen finden Sie in der Datenschutzerklärung von YouTube…“. – Formulieren Sie es einfach und klar, damit auch Nicht-Juristen verstehen. Schulen in einigen Bundesländern haben dafür Mustertexte (z.B. aus NRW oder SH); nutzen Sie diese als Grundlage.
(9) Barrierefreiheitserklärung anpassen: Ergänzen Sie in Ihrer Erklärung zur Barrierefreiheit (die für öffentliche Stellen Pflicht ist) Angaben zu nicht barrierefreien Inhalten aufgrund externer Dienste. Beispiel: „Eingebettete YouTube-Videos verfügen teilweise nicht über Untertitel oder Audiodeskriptionen. Die YouTube-Player-Oberfläche ist nicht in allen Punkten barrierefrei bedienbar…“
. So etwas sollten Sie dort offenlegen, inklusive dem Plan, wie Sie dem abhelfen (z.B. „Wir bemühen uns, Untertitel bereitzustellen“
). Das zeigt, dass Sie sich des Problems bewusst sind. Außerdem kann man angeben, wie Betroffene alternativ Infos bekommen (z.B. können sie das Video-Transkript anfordern). Das ist wichtig, um der gesetzlichen Pflicht nachzukommen und verhindert evtl. formale Beanstandungen.
(10) Schulung und Zuständigkeit: Sorgen Sie dafür, dass alle, die an der Website arbeiten (Lehrer-Redakteure, Sekretariat, evtl. Schüler-AG), zumindest die Grundprinzipien kennen. Machen Sie klar: „Wir dürfen nicht einfach HTML von irgendwo kopieren und einfügen, ohne Absprache.“ Etablieren Sie eine Netiquette für Ihre Website: Externe Inhalte nur nach Freigabe, regelmäßige Checks. Benennen Sie jemanden, der die Federführung hat (oft der Website-Administrator oder Datenschutzkoordinator der Schule). Diese Person hält die Checkliste aktuell, überwacht Änderungen (z.B. wenn ein externer Dienst seine Bedingungen ändert, muss man reagieren) und ist Ansprechpartner bei Fragen. Letztlich braucht es einen laufenden Prozess – Datenschutz und Barrierefreiheit sind keine einmaligen Projekte, sondern müssen im Betrieb mitgedacht werden.
Mit dieser Checkliste bringen Sie Struktur ins Thema und stellen sicher, dass Sie nichts Wichtiges übersehen, wenn Sie mit Drittanbietern hantieren.
Barrierefreiheit: Anforderungen an eingebettete Inhalte
Neben dem Datenschutz müssen Schulen gesetzlich sicherstellen, dass ihre Websites barrierefrei zugänglich sind (siehe z.B. § 10 Behindertengleichstellungsgesetz und die BITV 2.0). Das schließt externe Inhalte mit ein: Auch eingebettete Videos, Karten, PDFs etc. dürfen keine unüberwindbaren Barrieren darstellen. Worauf sollten Sie achten?
1. Tastaturbedienbarkeit: Alle Funktionen auf der Website – auch eingebettete Player, Karten-Navigation oder Formulare – sollten ohne Maus, nur mit Tastatur bedienbar sein. Testen Sie: Können Sie mit Tab/Tasten zum Video-Play-Button gelangen und ihn auslösen? Lässt sich ein Karten-Ausschnitt fokussieren und scrollen? Oft hapert es hier: Viele iframes fangen zwar Maus-Ereignisse ab, sind aber für Tastatur nicht optimiert
. Wenn ein eingebettetes Element gar nicht per Tastatur bedienbar ist (z.B. ein nicht barrierefreier PDF-Viewer), müssen Sie eine Alternative bieten. Das kann bedeuten: einen direkten Download-Link neben dem PDF-Embed anbieten, damit Nutzer das PDF im eigenen Reader öffnen (der eventuell barrierefreier ist). Oder bei einer Karte: Bieten Sie Adress-Infos und „Route per Telefon erfragen“ Option an. In Ihrer Barrierefreiheitserklärung sollten Sie solche Einschränkungen benennen (z.B. „Inhalte über iFrames sind zum Teil nicht vollständig barrierefrei…“ und warum)
.
2. Beschreibung und Alternativtexte: Für Bilder, Grafiken und Medien gilt: Informationstragende Inhalte brauchen Alternativtexte. Wenn Sie externe Medien einbinden, verlieren Sie manchmal die direkte Kontrolle (z.B. ein Instagram-Embed – haben die Bilder Alt-Texte? meistens nicht). Daher müssen Sie im umgebenden Kontext erklären, was wichtig ist. Beispiel: Bei einem Twitter-Embed können Sie den Tweet-Text ggf. zusätzlich in Klarschrift angeben oder zusammenfassen. Bei einem Video-Embed sollte zumindest der Titel oder eine Beschreibung in Text in der Seite stehen. Für Karten: Geben Sie die Adresse der Schule als Text an, evtl. ergänzt um „Unsere Schule ist im Stadtplan etwa bei [Beschreibung der Lage]“. So haben z.B. Sehbehinderte Nutzer eine Chance, die Info zu erhalten, die die Karte liefern soll.
3. Untertitel und Transkripte für Medien: Videos müssen laut WCAG/BitV mit Untertiteln versehen sein (für hörbehinderte Menschen)
. Achten Sie daher darauf, dass alle Videos, die Sie einbinden (gerade selbst erstellte, z.B. Schulvideos), mit Untertiteln versehen sind. YouTube bietet automatische Untertitel – die sollten Sie nachbearbeiten und als stabile Untertitel aktivieren. Oder laden Sie eigene Untertitel-Dateien hoch. Audio-Inhalte (z.B. Podcasts) sollten Sie als Transkript (Wortlaut zum Nachlesen) zur Verfügung stellen. Das ist nicht nur barrierefrei, sondern hilft auch Eltern, die z.B. kein Audio abspielen können. Audiodeskription: Wenn Videos wichtige visuelle Infos haben (z.B. Folien in einem Vortrag), sollten diese für Blinde aufbereitet werden – entweder durch eine Audiodeskription oder zumindest durch eine schriftliche Zusammenfassung. In der Praxis ist das bei Schulen oft die Kür, aber nehmen Sie es in die Planung neuer Videos mit auf.
4. Zugänglichkeit von Widgets und Overlays: Viele externe Tools bringen eigene User Interfaces mit (Cookie-Banner, Chat-Popups, Social-Media-Feeds). Prüfen Sie diese auf Barrierefreiheit. Z.B. Cookie-Banner: Kann man es per Tab erreichen, wird es vorgelesen, sind die Buttons beschriftet? Overlay-Fenster (wie Video-Player oder Lightbox): Schließen sie korrekt per Esc-Taste? Ist der Fokus eingeschränkt, solange das Overlay offen ist (damit Screenreader nicht hinter den Overlay springt)? Falls ein externes Widget unverbesserlich ist (z.B. weil es vom Anbieter kommt), erwägen Sie, es lieber nicht zu verwenden oder es nur zu zeigen, wenn der Nutzer es anfordert. Notfalls erwähnen Sie in der Barrierefreiheitserklärung, dass dieses Element noch optimiert werden muss.
5. PDFs und herunterladbare Dokumente: Extern eingebettete Dokumente (z.B. PDF-Viewer) sind oft kritisch. Wir empfehlen eh, PDFs eher zum Download anzubieten. Aber egal wie: alle neu veröffentlichten PDFs müssen barrierefrei sein (Struktur, Tags, Lesereihenfolge) – das ist für öffentliche Stellen seit 2019 Pflicht, sofern keine unverhältnismäßige Belastung geltend gemacht wird. Viele Schulen haben historische PDFs, die nicht barrierefrei sind – diese sollten in der Barrierefreiheitserklärung als Ausnahme gelistet sein, mit Hinweis, dass man auf Anfrage eine barrierefreie Fassung erhält
. Wenn Sie zukünftig PDF-Dokumente (Formulare, Merkblätter) online stellen, verwenden Sie die Funktionen in Word/Acrobat zur Erstellung barrierefreier PDFs oder fragen Sie ggf. beim Schulträger nach Unterstützung. So schließen Sie eine große Lücke.
6. Externe Inhalte außerhalb Einflussbereich: Es gibt Fälle, da müssen Sie externe Inhalte nutzen (z.B. vorgeschriebenes Statistik-Tool vom Ministerium, oder ein vorgeschriebenes Anmeldeportal). Wenn diese nicht barrierefrei sind, dokumentieren Sie das und drängen Sie bei den Verantwortlichen auf Verbesserungen. Immer gilt: Sie müssen zumindest eine alternative Zugänglichkeit anbieten. Z.B. wenn ein Bewerbungsportal nicht barrierefrei ist, müssen Sie alternative Bewerbungswege eröffnen.
Fazit Barrierefreiheit: Planen Sie Embed-Inhalte immer mit der Frage: Wie mache ich das verständlich für jemanden, der es nicht sehen/hören/bedienen kann? Das kann heißen, zusätzlichen Text bereitzustellen, Alternativen anzubieten oder im schlimmsten Fall auf etwas zu verzichten, das unersetzbar Barrieren erzeugt. Denken Sie daran: Eine Schulwebsite muss für alle nutzbar sein – inklusiv und zugänglich. Das ist nicht nur Gesetzesvorgabe, sondern auch im Sinne der Schulgemeinschaft (Eltern, Schüler mit Behinderung sollen nicht ausgeschlossen werden).
Betriebsmodelle: Website-Pflege intern vs. extern
Jede Schule organisiert die Betreuung ihrer Website etwas anders. Grundsätzlich gibt es zwei Modelle: Entweder die Schule pflegt die Website selbst (mit eigenen Kräften), oder ein externer Dienstleister unterstützt (z.B. eine Webagentur oder der Schulträger-IT). Beide Modelle können funktionieren – wichtig ist, wie Datenschutz und Barrierefreiheit dabei gewahrt werden. Hier ein Blick auf beide Ansätze:
Schulwebsite intern aktualisieren
Viele Schulen haben einen oder mehrere Webseiten-Verantwortliche im Kollegium oder Sekretariat. Das kann der/die Medienkoordinator sein, ein engagierter Lehrer, manchmal auch eine Arbeitsgruppe mit Schüler-Beteiligung (für Inhalte). In diesem Modell sollte die Schule einige Punkte klären:
Rollen und Rechte: Legen Sie fest, wer welche Berechtigungen hat. Z.B.: Herr X administriert das CMS (Updates, Plugins installieren), Frau Y darf Inhalte posten (Artikel, Bilder hochladen) aber keine technischen Änderungen. So minimieren Sie die Gefahr, dass jemand versehentlich unsichere Plugins einbaut. Die Schulleitung sollte die übergeordnete Aufsicht haben.
Interne Richtlinien: Erstellen Sie einen Leitfaden für Web-Redakteure an der Schule. Darin z.B.: „Keine Einbettung fremder Inhalte ohne Rücksprache mit Admin/Schulleitung“, „Beim Hochladen von Bildern immer auf Datenschutz (Einwilligungen für Schülerfotos) achten“, „PDFs nur barrierefrei“. Dieser Leitfaden muss nicht lang sein, aber klar die Do’s and Don’ts kommunizieren. Schließen Sie damit Wissenslücken – viele Kollegen sind keine Datenschutzexperten, aber wenn im Leitfaden steht „YouTube nur über datenschutzkonformen Player einbinden, siehe Anleitung…“, werden sie es beherzigen oder Hilfe holen.
Freigabeprozesse: Etablieren Sie ggf. einen kleinen Freigabe-Prozess für kritische Änderungen. Beispiel: Ein Lehrer möchte ein neues Plugin installieren, um eine schicke Slideshow einzubinden. Statt dass er das direkt tut, sollte er erst den Admin fragen, der z.B. prüft, ob das Plugin datenschutzkonform ist (lädt es externe Skripte? wohin sendet es Daten?). Oder wenn das Sekretariat einen neuen Kontaktformularfeld hinzufügen will, sollte man kurz checken, ob das noch datensparsam ist. Solche Prozesse klingen aufwändig, lassen sich aber formlos gestalten – z.B. per kurzen Dienstweg (E-Mail/Chat an Admin: „Ist das okay, wenn wir …?“). Hauptsache, es denkt jemand mit Know-how drüber nach.
Schulleitung einbeziehen: Die Schulleitung muss sich ihrer Verantwortung bewusst sein und sollte wichtige Entscheidungen abzeichnen. Es muss nicht jede kleine Änderung genehmigt werden, aber Grundsatzfragen („Dürfen wir einen Facebook-Feed einbauen?“) sollten nur mit OK der Schulleitung umgesetzt werden – am besten schriftlich protokolliert. So ist klar, dass die Leitung involviert ist, wie es die DSGVO verlangt (Verantwortlichkeit nach Art. 5(2) DSGVO)
.
Regelmäßige Überprüfung: Führen Sie intern eine jährliche oder halbjährliche Datenschutz-Barrierefreiheits-Prüfung der Website durch. Checken Sie: Sind neue externe Inhalte dazugekommen? Stimmt die Datenschutzerklärung noch? Gibt es neue Tools (z.B. ein neuer Kalender-Embed)? Ist die Barrierefreiheitserklärung aktuell? Ein kleiner Audit in den Sommerferien oder zum Jahresbeginn hilft, den Überblick zu behalten. Am besten mit der Schulleitung und ggf. dem behördlichen Datenschutzbeauftragten abstimmen.
Schulungen & Sensibilisierung: Halten Sie das Thema bei allen Beteiligten präsent. Eine jährliche kurze Fortbildung „Website und Datenschutz“ im Kollegium (10 Minuten in einer Konferenz) kann Wunder wirken – z.B. um klarzustellen, dass man keine urheberrechtlich geschützten Inhalte oder keine fremden Videos ohne Prüfung einbauen darf. Der Hinweis auf Fälle (Google Fonts Abmahnungen, Barrierefreiheit als Pflicht) schafft Bewusstsein.
Kurzum: Beim internen Betrieb muss die Schule selbst Kompetenz aufbauen. Das ist machbar, wenn ein paar Technik-affine Personen sich einlesen (zur Not kann man sich auch beraten lassen von Landesmedienzentren etc.). Wichtig ist, dass es kein Wildwuchs gibt – alle arbeiten nach denselben Datenschutz- und Qualitätsregeln. So bleibt die Schulhomepage intern gut handhabbar und rechtssicher im Griff der Schule.
Externer Website-Dienstleister unterstützt
Einige Schulen – gerade solche ohne eigenen Webmaster – beauftragen externe Unterstützung. Das kann eine Agentur sein, ein Freelancer oder auch der IT-Dienstleister des Schulträgers. Diese externen Profis kümmern sich um Technik und oft auch um inhaltliche Pflege nach Vorgaben der Schule. In diesem Modell sind ein paar spezielle Punkte zu beachten:
Vertragliche Grundlagen: Zwingend erforderlich ist ein Vertrag zur Auftragsverarbeitung (AVV) mit dem Dienstleister
, wenn dieser Zugriff auf personenbezogene Daten hat (was fast immer der Fall ist, z.B. Zugriff auf CMS mit Nutzerdaten, oder Hosting). Im AV-Vertrag muss geregelt sein, was der Dienstleister darf und welche Maßnahmen er ergreifen muss. Viele Webagenturen bieten von sich aus so einen Vertrag an – falls nicht, bestehen Sie darauf. Ohne AVV wäre die Zusammenarbeit ein DSGVO-Problem. Zusätzlich sollte natürlich ein Dienstvertrag vorliegen, der Verantwortlichkeiten klärt (wer ist für inhaltliche Richtigkeit, Aktualität etc. verantwortlich? In der Regel die Schule).
Weisungsrecht und Abstimmung: Die Schule bleibt der Verantwortliche im Sinne DSGVO, der Dienstleister ist weisungsgebunden. Daher muss die Schule dem Dienstleister klare Anweisungen geben, was erlaubt ist und was nicht. Zum Beispiel: Im Pflichtenheft festhalten „Keine Einbindung von Tracking-Tools ohne Absprache“, „Bei neuen Plugins zuerst die Schule informieren“. Der Dienstleister sollte die Datenschutzrichtlinien der Schule kennen und sich danach richten. Praktisch empfiehlt es sich, einen Ansprechpartner auf Seiten der Schule und einen beim Dienstleister festzulegen, die sich regelmäßig austauschen.
Technische Umsetzung von Datenschutz durch Dienstleister: Eine gute Webagentur wird proaktiv datenschutzfreundliche Lösungen vorschlagen – z.B. gleich Google Fonts lokal hosten, Standard-YouTube-Embeds durch datenschutzkonforme Varianten ersetzen, eine Consent-Lösung einbauen usw. Fragen Sie ruhig nach Referenzen: Hat der Dienstleister Erfahrung mit öffentlichen Einrichtungen? Kennt er BITV-Anforderungen? Idealerweise wählt man jemanden, der nachweislich barrierefreie, DSGVO-konforme Websites bauen kann (viele Agenturen werben damit heute, achten Sie auf solche Merkmale).
Laufende Betreuung und Updates: Legen Sie fest, wie Updates gehandhabt werden. Externe Dienste ändern sich; z.B. könnte ein eingebetteter Service plötzlich seine API ändern. Der Dienstleister sollte die Website technisch aktuell halten (CMS-Updates) und Sicherheitspatches einspielen. Im Vertrag sollte stehen, in welchem Rhythmus das passiert. Ebenso: Wenn sich gesetzliche Vorgaben ändern (z.B. neue Cookie-Richtlinien), sollte der Dienstleister darauf hinweisen und Änderungen vorschlagen. Trotzdem liegt es an der Schule, informiert zu bleiben – verlassen Sie sich nicht blind darauf, dass der Dienstleister an alles denkt. Ein guter Dienstleister wird aber mitdenken.
Inhaltliche Verantwortung: Auch wenn jemand extern die Inhalte einpflegt, muss die Schule inhaltlich alles freigeben und verantworten. Das heißt, der Prozess könnte sein: Die Schule liefert z.B. einen neuen Elternbrief als PDF, der Dienstleister lädt ihn hoch. Die Schule sollte vorher sich vergewissern, dass das PDF barrierefrei ist und keine unzulässigen Daten enthält. Der Dienstleister kann auf solche Dinge hinweisen, aber die Entscheidung liegt bei der Schule. Daher empfiehlt sich intern trotzdem eine Person, die alle vom Dienstleister gemachten Änderungen kurz prüft (Redaktionsdurchsprache).
Monatliche Reports/Routine: Vereinbaren Sie ggf., dass der Dienstleister monatlich einen kurzen Report schickt: Welche externen Komponenten sind aktiv, gab es Auffälligkeiten (z.B. versuchte Hacks), wie ist der Stand der Barrierefreiheit. Viele Agenturen machen so etwas aber nur auf Anfrage/gegen Aufpreis. Mindestens sollte es aber einen jährlichen Review-Termin mit der Agentur geben, wo man auch Datenschutz/Accessibility evaluiert.
Notfall-Plan: Falls es Datenpannen oder dringende Probleme gibt (z.B. „Oh, wir haben bemerkt, dass seit gestern ein YouTube-Video ohne Opt-In lädt – Bug nach Update“), muss klar sein, wie schnell der Dienstleister reagieren muss und wie man ihn erreicht. Legen Sie fest, wer im Notfall befugt ist, Dienste temporär abzuschalten (lieber mal ein Video deaktivieren, bis der Fix kommt, als das Risiko laufen).
Positiv an einem externen Profi ist: Er/sie bringt Know-how mit, sodass Dinge wie datenschutzkonformes Einbinden technisch oft gleich richtig gelöst werden. Aber die Verantwortung bleibt bei der Schule – das heißt, Sie müssen den Dienstleister auch steuern. Rechtssicher wird die Schulwebsite in diesem Modell dann, wenn der externe Partner vertraglich gebunden ist, die Schule die Leitplanken vorgibt und regelmäßig kontrolliert.
Viele Kommunen haben Rahmenverträge mit Agenturen, die Schulhomepages betreuen – erkundigen Sie sich ggf., ob es Vorgaben oder Checklisten von Seiten des Schulträgers gibt. Möglicherweise übernimmt auch der Schulträger-Datenschutzbeauftragte eine prüfende Rolle bei extern betreuten Websites.
Zusammengefasst: Egal ob intern oder extern – klar geregelte Zuständigkeiten, feste Abläufe für Änderungen und regelmäßige Checks sind der Schlüssel. Schulen sollten das Website-Thema nicht dem Zufall überlassen, sondern organisatorisch verankern („Wer macht was wann“). So vermeiden Sie, dass z.B. eine Praktikantin mal schnell etwas Unsicheres einbaut, was dann jahrelang unbemerkt bleibt. Mit einer guten Organisationsform bleibt Ihre Seite nachhaltig rechtssicher und barrierefrei.
Typische Fehler – und wie man sie vermeidet
Am Ende wollen wir noch einige „Klassiker“ aufzählen – häufige Fehler auf Schulhomepages in Bezug auf externe Inhalte. Vielleicht erkennen Sie den einen oder anderen und können so gleich gegensteuern:
YouTube-Video direkt eingebunden ohne Schutz: Ein absolut häufiges Muster. Das Video vom letzten Schulfest wird per Embed-Code eingebettet – und schon fließen bei jedem Laden der Seite Daten an Google, inkl. Cookies etc., ohne dass Nutzer zugestimmt haben. Besser: Verwendung des erweiterten Datenschutzmodus (
youtube-nocookie) und einer Vorschaugrafik mit Klick. Nie Videos „auto-play“ oder unsichtbar laden. Immer einen Hinweis dazu setzen.
Google Fonts über Google-Server laden: Viele ältere Schulwebsites tun das noch und verletzen damit die DSGVO – man hat es lange nicht gewusst, aber inzwischen hat es sich „herumgesprochen“
. Dennoch schlummern auf manchem Webserver noch externe Font-Aufrufe, vielleicht in Templates. Besser: Einmalig alle Webfonts herunterladen und lokal einbinden
. Das ist leicht und behebt das Problem komplett.
Kontaktformular ohne Datenschutzhinweis/Einwilligung: Nutzer senden persönliche Nachrichten (vielleicht inklusive sensibler Infos) und die Schule hat keine ausdrückliche Erlaubnis dafür eingeholt. Besser: Unter dem Formular eine Einwilligungs-Checkbox einbauen und in der Datenschutzerklärung genau erklären, was mit Formular-Daten passiert
. Das hat sich mittlerweile gebessert, aber prüfen Sie Ihre Seite – insbesondere wenn das Formular schon vor DSGVO bestand.
Google reCAPTCHA ungefragt eingesetzt: Manchmal aktiviert ein Webmaster reCAPTCHA, um Spam zu stoppen – verständlich, aber ohne Einwilligung unzulässig und es werden viele Daten an Google geschickt
. Besser: Alternativen (Friendly Captcha etc.) nutzen oder Einwilligung einbauen („Bitte bestätigen Sie, dass wir zur Spamabwehr Google reCAPTCHA laden dürfen“ – was natürlich viele abschrecken könnte). Überlegen, ob es auch ohne geht (manuelle Freischaltung von Einträgen, falls es um Kommentare ginge, etc.).
Social-Media-Plugins (Like-Button, Feed) aktiv ohne Opt-In: Ein Facebook-Like-Button, der auf jeder Seite lädt, oder ein Instagram-Feed, der unten eingebettet ist – das übermittelt permanent Daten an Facebook/Instagram, selbst wenn keiner draufklickt
. Besser: Solche Plugins nicht nutzen. Shares über Shariff, Feeds nur als Link oder mit Zwei-Klick-Lösung. Viele Aufsichtsbehörden sehen klassische Social-Plugins als nicht zulässig an, also hier aufpassen.
Inhalte nicht barrierefrei aufbereitet: Beispielsweise PDF-Dokumente auf der Website, die nur aus gescannten Bildern bestehen (nicht vorlesbar), oder Videos ohne Untertitel. Auch gerne übersehen: Farbkontraste in eingebetteten Widgets (z.B. Twitter-Feed in der Seite – ist der Kontrast ausreichend? oft nicht). Besser: Vor Upload von PDF diese durch einen Accessibility-Check laufen lassen, ggf. Hilfe vom Schulträger holen. Untertitel für Videos erstellen (vielleicht Projekt für eine AG?). Für vorhandene alte Videos zumindest ein Hinweis „Kein Untertitel verfügbar“ in der Barrierefreiheitserklärung
. Kontrast notfalls per CSS überschreiben, falls Widget zu blass (das geht aber nicht immer).
Veraltete oder fehlende Rechtstexte: Datenschutz- und Barrierefreiheitserklärung nicht aktualisiert, obwohl neue Dienste hinzugekommen sind. Oder Impressum unvollständig (z.B. Schulträger vergessen). Besser: Nach jeder größeren Änderung an der Website (neues Plugin, neuer externer Inhalt) Datenschutzerklärung updaten. Auch die Barrierefreiheitserklärung jährlich prüfen – sind neue Barrieren hinzugekommen oder behoben?
Keine klare Verantwortlichkeit intern: Der „Webmaster“ hat die Schule verlassen, niemand fühlt sich zuständig – die Seite läuft weiter, aber keiner kontrolliert z.B. ob ein YouTube-Embed noch datenschutzkonform ist nach irgendeinem Update. Besser: Mindestens zwei Personen mit dem Wissen haben, Dokumentation führen (Passwörter etc.) und offiziell in der Schulorganisation die Aufgabe „Website-Betreuung“ benennen.
„Cookie-Wahn“ oder Ignoranz: Zwei gegensätzliche Fehler: Entweder überall unnötige Cookie-Einwilligungen holen (obwohl man gar keine Cookies nutzt – schlecht für UX und Akzeptanz) oder gar keine Einwilligungen holen, obwohl Tracker da sind (rechtlich riskant). Besser: Nur da Einwilligungen abfragen, wo nötig (siehe TTDSG Kriterien). Und dort aber konsequent. Weglassen, wo nicht nötig (viele Schulwebsites kommen mit 0 Cookies aus und brauchen dann gar kein Banner).
Wenn Sie diese typischen Fallen meiden, sind Sie schon auf einem guten Weg. Oft sind es historisch gewachsene Kleinigkeiten, die man bereinigen kann – und damit viel Ärger vorbeugt.
Quick Wins – die ersten 60 Minuten Verbesserungen
Zum Abschluss noch eine Soforthilfe-Liste: Angenommen, Sie möchten sofort mit wenig Aufwand Ihre Schulwebsite datenschutz- und barrierefreundlicher machen – was können Sie innerhalb einer Stunde erreichen?
Lokale Einbindung von Webfonts prüfen und umstellen: Finden Sie heraus, ob Ihre Seite externe Schriften lädt (insbesondere Google Fonts). Falls ja, nutzen Sie sofort einen Dienst wie Google Webfonts Helper, laden Sie die Schriftpakete herunter und binden Sie sie lokal ein
. Löschen Sie den Google-Font-Link aus dem Code. Zeitaufwand: ca. 15-30 Minuten. Effekt: Keine Font-Abmahnung mehr möglich, Datenschutz deutlich verbessert.
Externe Skripte und Frames identifizieren & entfernen (wenn entbehrlich): Öffnen Sie Ihre Homepage und Unterseiten, schauen Sie in der Browser-Konsole (Netzwerk) welche Domains aufgerufen werden. Alles, was nicht Ihre Schuldomain ist, ist verdächtig. Haben Sie z.B. ein
<iframe>von YouTube oder ein<script src="https://...">von Drittseiten – überlegen Sie: Brauche ich das wirklich jetzt? Wenn nein, werfen Sie es raus (oder kommentieren Sie es temporär aus). Z.B. dieser Wetter-Widget von Wetter.com im Seitenrand – not needed? Weg damit = keine externe Verbindung mehr. Zeitaufwand: 10-15 Minuten pro überflüssigem Element. Effekt: Weniger Angriffspunkte, weniger Cookies.2-Klick für bestehende Medien umsetzen: Finden Sie die auffälligsten Stellen, wo externe Inhalte ohne Opt-In laden (typischerweise Videos, Social-Feeds auf der Startseite). Sie müssen keine perfekte Lösung gleich programmieren – als Quickfix können Sie z.B. statt des iframes einen statischen Platzhalter setzen: ein Bild mit Play-Button-Icon für Videos oder ein Hinweis „Instagram-Feed hier – klicken zum Laden“. Verlinken Sie diesen Platzhalter auf die externe Seite oder eine Unterseite, wo dann das Original eingebettet ist mit Hinweis. Das ist zwar im Moment noch nicht „perfekt elegant“, aber in <60 min umsetzbar: Der Besucher muss dann klicken, landet evtl. auf YouTube – aber nichts mehr automatisch. Später können Sie das durch eine richtige Zwei-Klick-Lösung ersetzen. Zeitaufwand: ~30 Minuten für 1-2 Inhalte. Effekt: Besucher werden nicht mehr ungefragt getrackt; Sie gewinnen Zeit, um eine schönere Lösung zu entwickeln.
Datenschutzerklärung updaten: Öffnen Sie Ihre Datenschutzerklärung und gleichen Sie sie gegen die aktuelle Realität ab. Ist dort z.B. noch Google Analytics erwähnt, obwohl längst entfernt? Streichen Sie Altlasten. Fehlt ein Hinweis auf einen noch vorhandenen Dienst (z.B. YouTube-Videos)? Fügen Sie 2-3 Sätze dazu ein. Achten Sie auch auf die kontaktdaten Datenschutzbeauftragter (falls Ihre Schule einen hat) – muss aktuell sein – und ggf. Stand-Datum der Erklärung aktualisieren. Zeitaufwand: 30-60 Minuten (je nach Änderungen, Formulierungen übernehmen). Effekt: Besucher sind korrekt informiert, Sie schließen eine Angriffsfläche (eine unrichtige Datenschutzerklärung kann abgemahnt werden).
Top-5 Seiten überprüfen (Inhalte und Technik): Sehen Sie sich die meistbesuchten Seiten Ihrer Schulhomepage an – oft: Startseite, Kontakt, Termine, evtl. Bildergalerien, News. Gehen Sie diese durch auf offensichtliche Datenschutz- oder Barriere-Verstöße. Z.B.: Auf der Kontakt-Seite ist ein Kontaktformular – steht direkt drunter ein kurzer Datenschutzhinweis? Wenn nein, fügen Sie zumindest einen Satz + Link Datenschutzerklärung hinzu („Ihre Daten werden zur Bearbeitung Ihrer Anfrage verwendet… siehe Datenschutz“). Oder: In der Schulprofil-Seite ist eine eingebettete Karte – ersetzen Sie die fix durch ein statisches Bild und Adresse. Frage bei Bildern: Haben die wichtigen Bilder Alt-Texte? Falls nein, schnell im CMS nachtragen für die wichtigsten (Logo der Schule usw.). Diese kleinen Korrekturen auf den meistgenutzten Seiten erhöhen sofort die Konformität für den Großteil der Besucher.
Cookie-Banner optimieren oder entfernen: Falls Ihre Seite derzeit einen Cookie-Banner zeigt, aber Sie beim Check feststellen „Wir haben gar keine externen Cookies mehr!“ (was nach den obigen Maßnahmen sein kann), dann deaktivieren Sie das Banner. Es erspart den Nutzern Klickaufwand und Sie wirken nicht fälschlich so, als würden Sie Daten sammeln. Wenn Sie das Banner brauchen, prüfen Sie schnell: Sind Ablehnen/Annehmen beide vorhanden? Wenn nein, konfigurieren Sie das um – viele Tools bieten diese Einstellung.
Barrierefreiheitserklärung erstellen/prüfen: Wenn Ihre Schule noch gar keine Barrierefreiheitserklärung auf der Website veröffentlicht hat – das wäre eine Baustelle, denn seit 2019 ist das Pflicht (für staatliche Schulen auf Landesrecht basierend). Als Quick Win: Schreiben Sie zumindest eine vorläufige Erklärung: „Wir bemühen uns um barrierefreie Zugänglichkeit. Folgende Inhalte sind nicht barrierefrei: [z.B. Videos ohne UT, PDF xy]. Diese Erklärung wurde am <Datum> erstellt.“ Sie können sich an Vorlagen im Web orientieren. Schon das Vorhandensein einer Erklärung zeigt, dass Sie das Thema ernst nehmen. Zeitaufwand: 60 min, um ein Grundgerüst zu kopieren und anzupassen. Effekt: Rechtspflicht erfüllt, Nutzer informiert.
Mit diesen Quick Wins werden Sie in kurzer Zeit einige der größten Risiken abstellen. Natürlich ersetzt das keine umfassende Optimierung, aber es ist ein guter Start. Danach können Sie in Ruhe die tiefergehenden Punkte (Zwei-Klick-Skripte, Alternative Inhalte erstellen etc.) angehen.
