Webseiten bauen in Deutschland

Das vollständige Fakten-Dossier zu Recht, Datenschutz, Sicherheit, Barrierefreiheit und Betrieb - mit Claude Code und Vibe Coding

Stand: 8. August 2026 Zielgruppe: Menschen ohne klassische Entwicklerausbildung, die Webseiten, Webshops, Kundenportale, WordPress-Erweiterungen oder kleine Webanwendungen selbst oder für Kunden bauen wollen. Deutschland-Fokus: Deutsches und unmittelbar geltendes europäisches Recht. Technischer Fokus: Statische Websites, HTML/CSS/JavaScript, PHP, Datenbanken, WordPress, Plugins, Themes, Kundenkonten, Shops, Formulare, Schnittstellen und KI-Funktionen.

Faktenstatus FAKT kennzeichnet eine durch die angegebenen Quellen belegte Aussage. EMPFEHLUNG ist eine aus Recht, Standards und technischer Praxis abgeleitete Vorgehensweise. VORLAGE ist ein anpassbares Muster, etwa eine Checkliste, ein Prompt oder ein Skill. WARNUNG markiert ein besonders hohes Risiko. UNKLAR bedeutet: Ohne das konkrete Geschäftsmodell, die Datenflüsse, Verträge und eingesetzten Dienste lässt sich keine belastbare Einzelfallantwort geben.

Rechtliche Grenze Dieses Dossier ist allgemeine Fachinformation und keine individuelle Rechtsberatung. Es ersetzt weder die rechtliche Prüfung eines konkreten Geschäftsmodells noch einen Penetrationstest, eine Datenschutz-Folgenabschätzung, eine Sicherheitszertifizierung oder die Freigabe durch zuständige Fachpersonen. Die Verantwortung für eine veröffentlichte Website bleibt bei ihren Betreibern und den vertraglich verantwortlichen Dienstleistern.

Der wichtigste Satz Claude Code kann eine Website bauen. Es kann aber nicht automatisch entscheiden, welche Daten rechtmäßig erhoben werden dürfen, welche Vertragspflichten gelten, welche Sicherheitsmaßnahmen dem Risiko angemessen sind oder ob die Seite tatsächlich barrierefrei ist. Gute Vibe-Coding-Projekte verbinden deshalb fachliche Entscheidung, technische Schutzmaßnahmen, dokumentierte Prüfung und klaren Betrieb.

\newpage

Management-Zusammenfassung

Die zentrale Aussage

Eine Website ist nicht nur eine Ansammlung schöner Seiten. In dem Moment, in dem sie öffentlich erreichbar ist, wird sie zu einem technischen System, einem Kommunikationskanal und häufig zu einem Ort, an dem Verträge angebahnt oder abgeschlossen werden. Schon eine sehr kleine Unternehmensseite kann IP-Adressen in Serverlogs verarbeiten, Nachrichten über ein Kontaktformular entgegennehmen, externe Schriftarten laden, Analysewerkzeuge aufrufen und rechtliche Informationspflichten auslösen. [S001] [S009] [S019] [S020]

EMPFEHLUNG: Wer mit Claude Code eine Website baut, sollte nicht erst am Ende fragen: „Brauche ich jetzt noch Datenschutz?“ Die bessere Reihenfolge lautet:

``text Geschäftszweck klären → Daten und externe Dienste erfassen → Risikostufe bestimmen → technische Architektur wählen → rechtliche und Sicherheitsanforderungen festlegen → bauen und testen → Go-live freigeben → betreiben, aktualisieren und sichern ``

Claude Code kann sehr viel Arbeit in dieser Linie übernehmen: Dateien anlegen, Frameworks einrichten, Formulare implementieren, Tests schreiben, Sicherheitsheader konfigurieren, Abhängigkeiten prüfen und Dokumentation vorbereiten. Es kann aber nur mit den Anforderungen arbeiten, die der Mensch erkennt und vorgibt. Ein perfekt programmierter Datendiebstahl wäre technisch immer noch perfekt programmiert. Das Ziel ist deshalb nicht möglichst viel Automatisierung, sondern kontrollierte Automatisierung mit klaren Grenzen.

Die 25 wichtigsten Ergebnisse

1. Nicht jede Website braucht einen Cookie-Banner. Ein Banner ist nicht wegen der bloßen Existenz einer Website erforderlich. Entscheidend ist, ob Informationen im Endgerät gespeichert oder daraus ausgelesen werden und ob eine gesetzliche Ausnahme greift. Technisch notwendige Vorgänge können ohne Einwilligung zulässig sein; nicht notwendiges Tracking verlangt regelmäßig eine wirksame Einwilligung. [S019] [S020] [S021] [S022]

1. Kein Banner bedeutet nicht kein Datenschutz. Serverlogs, Kontaktformulare, Bestellungen oder eingebettete Dienste können personenbezogene Daten verarbeiten, auch wenn kein einziges Cookie gesetzt wird. [S001] [S020]

1. Eine Datenschutzerklärung ist keine technische Maßnahme. Sie informiert über Datenverarbeitung. Sie verhindert weder einen Angriff noch macht sie eine unzulässige Verarbeitung zulässig. Datenschutzinformationen, Rechtsgrundlage und technische Schutzmaßnahmen erfüllen unterschiedliche Aufgaben. [S001]

1. Ein Kontaktformular braucht nicht automatisch eine Einwilligungscheckbox. Je nach Zweck kann die Verarbeitung zur Vertragsanbahnung oder auf ein berechtigtes Interesse gestützt werden. Eine erzwungene Einwilligung kann sogar das falsche Instrument sein. Der konkrete Zweck und die anschließende Nutzung müssen getrennt bewertet werden. [S001] [S025]

1. Gesundheitsdaten sind eine andere Risikoklasse. Angaben zu Krankheiten, Diagnosen, Behandlungen oder Beschwerden gehören zu den besonderen Kategorien personenbezogener Daten. Dafür reicht eine normale Rechtsgrundlage allein nicht; zusätzlich ist eine Ausnahme nach Art. 9 DSGVO erforderlich. Bei Berufsgeheimnisträgern kann außerdem § 203 StGB relevant sein. [S001] [S007] [S008] [S133]

1. HTTPS ist Pflichtstandard, aber kein Rundumschutz. TLS schützt die Übertragung. Es schützt nicht automatisch gespeicherte Daten, schlechte Passwörter, falsche Rechte oder unsicheren Programmcode. [S083] [S103]

1. Die häufigsten Risiken sind keine exotischen Hackertricks. Fehlende Zugriffskontrolle, falsche Konfigurationen, unsichere Abhängigkeiten, schwache Kryptografie, Injection, unsicheres Design und unzureichende Protokollierung stehen im Zentrum der OWASP Top 10:2025. [S075]

1. Login bedeutet Verantwortung. Sobald Benutzerkonten existieren, müssen Registrierung, Passwortspeicherung, Kontosperren, Sitzungen, Passwort-Reset, Rechte, Löschung, Protokollierung und Wiederherstellung gemeinsam geplant werden. [S078] [S079] [S080] [S092] [S093]

1. Mandantentrennung darf nicht nur in der Oberfläche existieren. Ein Benutzer darf nicht durch Ändern einer Nummer in einer URL auf Datensätze anderer Kunden zugreifen können. Jeder Objektzugriff muss serverseitig autorisiert werden. [S075] [S077]

1. WordPress ist nicht pauschal unsicher. Es ist ein großes, erprobtes System mit Rollen, Updates, APIs und Sicherheitsfunktionen. Das reale Risiko entsteht oft durch veraltete Erweiterungen, überhöhte Rechte, schwache Administration, unsichere Plugins oder fehlende Wartung. [S116] [S117] [S121]

1. Eine individuelle Website kann eine kleinere Angriffsfläche haben. Sie kann jedoch zugleich riskanter sein, weil der Entwickler sämtliche Schutzmechanismen selbst richtig entwerfen, implementieren und warten muss. „Weniger Code“ ist kein Beweis für Sicherheit.

1. Ein selbst entwickeltes WordPress-Plugin braucht dieselben Grundregeln wie jede andere Webanwendung. Eingaben validieren, Ausgaben escapen, Rechte prüfen, Nonces richtig einsetzen und Datenzugriffe absichern. WordPress weist ausdrücklich darauf hin, dass Nonces keine Authentifizierung oder Autorisierung ersetzen. [S122] [S123] [S124] [S125] [S126]

1. Impressum und Datenschutz sind nicht dasselbe. Das Impressum nennt den verantwortlichen Anbieter und weitere gesetzlich erforderliche Unternehmensdaten. Die Datenschutzerklärung beschreibt die Verarbeitung personenbezogener Daten. Je nach journalistisch-redaktionellem Angebot kommen Anforderungen aus § 18 MStV hinzu. [S009] [S010] [S011]

1. Nicht jede Geschäftsform benötigt dieselben Pflichtangaben. Gesellschaftsform, Register, Vertretungsberechtigte, Aufsichtsbehörde und berufsrechtliche Angaben können den Inhalt verändern. [S009] [S012] [S013] [S014]

1. Barrierefreiheit betrifft seit 28. Juni 2025 viele digitale Verbraucherdienstleistungen. Besonders relevant sind Online-Shops, Buchungs- und Vertragsstrecken. Reine Informationsseiten fallen nicht automatisch in denselben Anwendungsbereich. Für Kleinstunternehmen, die Dienstleistungen erbringen, existiert im BFSG eine wichtige Ausnahme; öffentliche Stellen unterliegen eigenen Regeln. [S034] [S035] [S036] [S038] [S039] [S043] [S045]

1. Ein Overlay macht eine Website nicht automatisch barrierefrei. Die Europäische Kommission weist darauf hin, dass solche Zusatzwerkzeuge die Beseitigung von Problemen im Quellcode nicht ersetzen. [S048]

1. Seit 19. Juni 2026 kann eine elektronische Widerrufsfunktion erforderlich sein. Bei erfassten Fernabsatzverträgen über Online-Benutzeroberflächen muss die Funktion während der Widerrufsfrist leicht zugänglich sein und einen gesetzlich beschriebenen Ablauf bieten. [S050] [S056]

1. Der Kündigungsbutton ist eine andere Pflicht. § 312k BGB betrifft bestimmte online abschließbare Dauerschuldverhältnisse. Bestellbutton, Kündigungsbutton und Widerrufsfunktion dürfen nicht miteinander verwechselt werden. [S049] [S056] [S058]

1. Die frühere EU-OS-Plattform ist beendet. Alte Hinweise und Links auf die ODR-Plattform dürfen nicht ungeprüft aus historischen Rechtstexten übernommen werden. [S053]

1. Produktangebote im Shop benötigen mehr als Preis und Foto. Art. 19 GPSR verlangt bei erfassten Fernabsatzangeboten unter anderem klar sichtbare Hersteller-/Verantwortlicheninformationen, Produktidentifikation sowie Warn- und Sicherheitsinformationen. [S054] [S055]

1. Eine Website muss nicht pauschal als „KI-generiert“ gekennzeichnet werden. Art. 50 AI Act enthält konkrete Transparenzpflichten, etwa für die Interaktion mit bestimmten KI-Systemen, Deepfakes und bestimmte Texte von öffentlichem Interesse. Daraus folgt keine allgemeine Pflicht, eine mit Claude Code erstellte Website oder einen mit KI entworfenen Quellcode als solchen zu beschriften. [S065] [S066] [S067] [S068]

1. Ein Chatbot kann kennzeichnungspflichtig sein. Menschen müssen grundsätzlich darüber informiert werden, dass sie mit einem KI-System interagieren, sofern dies aus den Umständen nicht offensichtlich ist. [S066] [S067]

1. Ein KI-generiertes Impressum braucht keine KI-Kennzeichnung, aber eine echte Prüfung. Diese Schlussfolgerung ergibt sich aus dem begrenzten Anwendungsbereich der Transparenzpflichten; sie ist keine Freigabe des Inhalts. Fehlerhafte Anbieterangaben bleiben fehlerhaft, egal ob sie von einem Menschen, einem Generator oder Claude formuliert wurden. [S009] [S066] [S067]

1. Agenturen sollten Domains und Konten nicht als faktisches Druckmittel kontrollieren. Bei .de-Domains entsteht der Domainvertrag mit dem eingetragenen Domaininhaber. DENIC weist ausdrücklich auf Konflikte hin, wenn entgegen der Vereinbarung ein Dritter als Inhaber registriert wurde. Kunde, Agentur und Providerrollen müssen schriftlich geklärt werden. [S128] [S129]

1. Sicherheit endet nicht mit dem Go-live. Updates, Schwachstellenbeobachtung, Backups, Restore-Tests, Protokollierung und Incident Response sind Teil des Produkts. NIST CSF 2.0 strukturiert dies als Govern, Identify, Protect, Detect, Respond und Recover. [S089]

Die einfache Go-live-Regel

EMPFEHLUNG: Eine Website darf erst produktiv gehen, wenn fünf Fragen mit „Ja“ beantwortet werden können:

Ein grüner Lighthouse-Score, ein hübsches Design oder ein fehlerfreier Build beantwortet keine dieser Fragen vollständig.

Was Claude Code leisten kann

EMPFEHLUNG: Claude Code eignet sich besonders gut, um einen vorhandenen Standard reproduzierbar umzusetzen:

• Dateninventar als Tabelle anlegen,
• Projektstruktur und Dokumentation erzeugen,
• Cookie- und Fremddienst-Audit vorbereiten,
• Sicherheitsheader konfigurieren,
• Testfälle für Formulare und Logins schreiben,
• Abhängigkeiten und Geheimnisse prüfen,
• Barrierefreiheitsprüfungen vorbereiten,
• Deployment- und Restore-Anleitungen dokumentieren,
• Änderungen vor dem Go-live als Diff darstellen.

Es sollte nicht allein entscheiden:

• ob eine konkrete Verarbeitung rechtmäßig ist,
• ob eine Einwilligung freiwillig und wirksam ist,
• ob eine Ausnahme des BFSG greift,
• ob ein Shop sämtliche verbraucherrechtlichen Besonderheiten erfüllt,
• ob Gesundheitsdaten in der gewählten Architektur verarbeitet werden dürfen,
• ob ein Vertrag oder eine Datenschutzerklärung rechtlich vollständig ist.

Das Ergebnis des Audits

Das Dossier führt nicht zu einer einzigen universellen Website-Vorlage. Es führt zu einem Entscheidungssystem. Eine statische Seite für einen Malerbetrieb ohne Tracking braucht andere Maßnahmen als ein Kundenportal mit Rechnungen. Ein Terminformular für eine Arztpraxis ist nicht mit einem Newsletterformular gleichzusetzen. Ein Shop mit physischen Produkten löst andere Pflichten aus als ein reines B2B-Dashboard.

Die zentrale Arbeitsweise lautet daher:

Erst das Geschäftsmodell und die Daten verstehen. Dann die Technik bauen. Danach mit Nachweisen prüfen.

\newpage

Warum dieses Dossier notwendig ist

Der gefährliche Erfolg des ersten Prompts

Ein Anfänger schreibt in Claude Code:

„Baue mir eine moderne Website für meine neue Unternehmensberatung. Mit Kontaktformular, Newsletter, Kundenlogin und einem Chatbot.“

Eine Stunde später funktioniert etwas. Das Design ist sauber, das Formular versendet Nachrichten und der Login öffnet ein Dashboard. Genau dieser frühe Erfolg ist zugleich das Risiko. Die sichtbare Oberfläche vermittelt den Eindruck, das Projekt sei fast fertig. Tatsächlich sind vier sehr unterschiedliche Systeme entstanden:

1. eine öffentliche Informationsseite,
2. ein Kommunikationskanal für personenbezogene Daten,
3. ein Authentifizierungs- und Berechtigungssystem,
4. ein KI-gestützter Dienst mit eigenen Transparenz- und Datenschutzfragen.

Jede Erweiterung erhöht nicht nur den Funktionsumfang, sondern verändert die Pflichten. Das gilt unabhängig davon, ob ein Mensch oder eine KI den Code geschrieben hat.

EMPFEHLUNG: Anfänger sollten den Satz „Die Seite funktioniert“ durch vier präzisere Aussagen ersetzen:

• Die sichtbaren Funktionen arbeiten im vorgesehenen Normalfall.
• Die Datenverarbeitung ist beschrieben und geprüft.
• Fehlbedienung und Angriffe wurden in angemessenem Umfang getestet.
• Betrieb, Updates, Backups und Verantwortlichkeiten sind geregelt.

Erst zusammen ergibt das ein belastbares Produkt.

Warum klassische Baukästen vieles verstecken

WordPress, Shopify, Shopware und andere etablierte Systeme wirken manchmal unnötig groß. Sie enthalten jedoch nicht nur Designfunktionen. Sie bringen Rollen, Updateverfahren, Standardabläufe, Erweiterungsschnittstellen, Passwortfunktionen, Protokollierung und eine lange Entwicklungsgeschichte mit. Das bedeutet nicht, dass sie automatisch rechtssicher oder sicher sind. Es erklärt aber, warum eine selbst entwickelte Alternative überraschend viele unsichtbare Aufgaben übernehmen muss.

Eine individuelle Seite kann schlanker sein. Sie braucht vielleicht weder ein Redaktionssystem noch zwanzig Plugins. Dafür muss der Entwickler selbst entscheiden:

• Wie werden Eingaben geprüft?
• Wie werden Passwörter gehasht?
• Wie werden Sitzungen beendet?
• Wie werden Daten gelöscht?
• Wie werden Updates verteilt?
• Wie wird eine Sicherheitslücke gefunden?
• Wie wird nach einem Fehler zurückgerollt?

EMPFEHLUNG: „Individuell programmiert“ ist weder Qualitätsbeweis noch Warnsignal. Entscheidend ist, ob Schutzmechanismen, Betrieb und Verantwortlichkeiten dokumentiert sind.

Recht und Technik sind gekoppelt

Die DSGVO verlangt keine bestimmte Programmiersprache. Sie verlangt unter anderem angemessene technische und organisatorische Maßnahmen, Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen. Welche Maßnahmen angemessen sind, richtet sich nach Risiko, Stand der Technik, Kosten, Art, Umfang, Umständen und Zweck der Verarbeitung. [S001]

Das führt zu einem einfachen Prinzip:

```text kleines Risiko → einfache, saubere Maßnahmen können genügen

hohes Risiko → stärkere technische, organisatorische und rechtliche Prüfung ```

Eine Broschürenseite mit Öffnungszeiten und lokal eingebundenen Bildern ist nicht dasselbe wie ein Portal, in dem psychologische Befunde hochgeladen werden. Beide sind Websites. Die Bezeichnung sagt fast nichts über das reale Risiko.

Die fünf Arten von Fehlern

EMPFEHLUNG: Website-Projekte scheitern typischerweise nicht nur durch Programmierfehler. Das Audit unterscheidet fünf Fehlerarten:

Claude kann jede dieser Fehlerarten mitverursachen, wenn die Aufgabenstellung unvollständig ist. Es kann aber auch helfen, sie systematisch zu entdecken, wenn das Projekt entsprechende Prüfschritte enthält.

Was „rechtssicher“ nicht bedeutet

Der Begriff „rechtssichere Website“ wird im Marketing leichtfertig verwendet. Eine Website verändert sich durch Inhalte, Plugins, eingebettete Dienste, neue Formulare, neue Länder, geänderte Gesetze und neue Geschäftsmodelle. Eine einmalige Prüfung ist daher kein ewiges Zertifikat.

EMPFEHLUNG: Statt „rechtssicher“ sollte ein Projekt nachvollziehbare Aussagen treffen:

• Rechtsstand und Prüftermin sind dokumentiert.
• Datenflüsse und Drittanbieter sind bekannt.
• Pflichtinformationen wurden fachlich freigegeben.
• technische Kontrollen wurden durchgeführt.
• Änderungen lösen einen erneuten Audit aus.

Das ist weniger werbewirksam, aber fachlich belastbarer.

\newpage

Die sieben Risikostufen einer Website

Warum eine Risikoleiter besser ist als eine Universalliste

Eine Universalliste mit hundert Punkten überfordert den Anfänger und unterschätzt komplexe Projekte. Deshalb arbeitet dieses Dossier mit sieben Stufen. Jede höhere Stufe übernimmt die Anforderungen der niedrigeren Stufen und ergänzt neue Kontrollen.

Stufe 1: reine Informationsseite

Beispiel: Ein Handwerksbetrieb zeigt Leistungen, Telefonnummer, Adresse, Öffnungszeiten und lokal gespeicherte Bilder. Es gibt kein Formular, keine Analyse, keine externen Videos, kein Login und keinen Shop.

Typische Themen:

• Impressum,
• Datenschutzhinweis zu Hosting und Serverlogs,
• HTTPS,
• sichere Serverkonfiguration,
• lokale Einbindung von Schriften und Medien,
• Aktualisierung und Backup,
• Barrierefreiheits-Basics.

Ein Cookie-Banner kann in dieser Konfiguration entbehrlich sein, wenn tatsächlich keine nicht erforderlichen Speicher- oder Zugriffsvorgänge stattfinden. Das muss technisch geprüft werden; eine Annahme reicht nicht. [S019] [S020] [S022]

Stufe 2: Lead- und Kommunikationsseite

Zusätzlich gibt es Kontaktformular, Terminwunsch, Rückrufanfrage, Newsletter oder Bewerbungsformular.

Neue Themen:

• Rechtsgrundlage und Zweck je Formular,
• Pflicht- und freiwillige Felder,
• sichere Übertragung und Weiterleitung,
• Spam-Schutz,
• Löschfristen,
• Empfängerkreis,
• Newsletter-Einwilligung und Nachweis,
• Upload-Sicherheit bei Bewerbungen.

WARNUNG: Ein Textfeld „Ihre Nachricht“ kann unerwartet Gesundheitsdaten, Kontodaten oder andere sensible Informationen enthalten. Der Betreiber sollte nicht nur technisch fragen, was eingegeben werden *kann*, sondern durch Beschriftung und Hinweise steuern, was eingegeben werden *soll*.

Stufe 3: CMS oder WordPress

Redakteure melden sich an und verändern Inhalte. Plugins, Themes oder externe Bibliotheken erweitern das System.

Neue Themen:

• Rollen und Rechte,
• Administrationsschutz,
• Update- und Patchprozess,
• Erweiterungsauswahl,
• Staging,
• Backup vor Änderungen,
• Lieferkettenrisiken,
• Schutz von Konfigurationsdateien.

WordPress empfiehlt unter anderem regelmäßige Updates, sichere Dateirechte, Schutz der Konfiguration, HTTPS und eine Begrenzung administrativer Möglichkeiten. [S116] [S117] [S119] [S120] [S121]

Stufe 4: Shop, Buchung oder Vertrag

Die Website zeigt Preise, nimmt Bestellungen an, verkauft digitale oder physische Produkte oder ermöglicht kostenpflichtige Buchungen.

Neue Themen:

• Verbraucherinformationen,
• Bestellbutton,
• Preisangaben,
• Widerrufsrecht und Widerrufsfunktion,
• gegebenenfalls Kündigungsbutton,
• Zahlungsdienstleister,
• Produkt- und Sicherheitsinformationen,
• Bestellbestätigung,
• Barrierefreiheit nach BFSG,
• Betrugs- und Rückabwicklungsprozesse.

[S049] [S050] [S051] [S054] [S055] [S056] [S058]

Stufe 5: Kundenkonto oder internes Portal

Benutzer sehen persönliche Daten, Rechnungen, Dokumente, Projekte oder Nachrichten.

Neue Themen:

• Authentifizierung,
• Passwort-/Passkey-Strategie,
• Kontowiederherstellung,
• Sitzungsmanagement,
• serverseitige Zugriffskontrolle,
• Mandantentrennung,
• Protokollierung,
• Export und Löschung,
• Datenschutzverletzungen.

Schon ein kleines Portal kann ein hohes Risiko haben, wenn es vertrauliche Dokumente enthält.

Stufe 6: besondere Kategorien oder Berufsgeheimnisse

Die Seite verarbeitet Gesundheitsdaten, biometrische Daten, politische oder religiöse Angaben, Gewerkschaftszugehörigkeit, sexuelle Orientierung oder andere besondere Kategorien. In Arzt-, Therapie-, Beratungs- oder Kanzleikontexten können zusätzliche Geheimhaltungspflichten hinzukommen. [S001] [S007] [S008]

Neue Themen:

• Art. 9 DSGVO und zusätzliche Rechtsgrundlage,
• mögliche Datenschutz-Folgenabschätzung,
• besonders restriktive Zugriffe,
• Ende-zu-Ende- oder Inhaltsverschlüsselung je Szenario,
• sichere Kommunikation,
• Auftragsverarbeiter und Berufsgeheimnis,
• detaillierte Protokollierung,
• Notfall- und Meldestrukturen.

WARNUNG: Diese Stufe ist kein geeignetes erstes Lernprojekt, wenn echte Daten betroffen sind.

Stufe 7: Plattform, Marktplatz oder Softwareprodukt

Die Website speichert Inhalte Dritter, vermittelt Geschäfte, betreibt einen Marktplatz, bietet ein Plugin/Theme als Produkt an oder wird als Software an viele Kunden verteilt.

Neue Themen:

• Digital Services Act,
• Melde- und Beschwerdeverfahren,
• Händlernachverfolgbarkeit,
• Plattformregeln,
• Produktsicherheits- und Lieferkettenpflichten,
• Software Bill of Materials,
• Schwachstellenmanagement,
• Cyber Resilience Act je Produkt und Zeitplan,
• Support- und Updatezeitraum.

Der Cyber Resilience Act trat am 10. Dezember 2024 in Kraft. Seine Hauptpflichten gelten grundsätzlich ab 11. Dezember 2027; bestimmte Meldepflichten beginnen bereits am 11. September 2026. Ob ein konkretes Plugin, Theme oder Softwareangebot in den Anwendungsbereich fällt, muss produktbezogen geprüft werden. [S113] [S114] [S115]

Risikomatrix

VORLAGE: Im Starterkit befindet sich eine Risikofrage, die aus Funktionen und Daten eine erste Stufe ableitet. Sie ersetzt keine rechtliche Einordnung, verhindert aber, dass ein Projekt versehentlich als „einfache Website“ behandelt wird.

\newpage

Verantwortlichkeiten: Betreiber, Agentur, Entwickler und Hoster

Wer ist der Verantwortliche?

Die DSGVO knüpft Verantwortung nicht an die Person, die den Quellcode tippt. Verantwortlicher ist grundsätzlich die Stelle, die allein oder gemeinsam über Zwecke und Mittel der Verarbeitung entscheidet. Ein Auftragsverarbeiter verarbeitet personenbezogene Daten im Auftrag des Verantwortlichen. Die Rollen hängen von den tatsächlichen Entscheidungen und nicht nur von Vertragsüberschriften ab. [S001] [S002]

Beispiel:

• Der Friseurbetrieb entscheidet, dass Kunden online Termine anfragen können und welche Angaben benötigt werden. Er ist regelmäßig Verantwortlicher.
• Die Agentur hostet die Seite und wartet die Datenbank nach Weisung. Sie kann Auftragsverarbeiter sein.
• Die Agentur verwendet Formulardaten eigenständig zur Produktanalyse oder zum Training eines eigenen Systems. Für diese eigenständigen Zwecke kann sie eine zusätzliche eigene Verantwortlichkeit begründen.

UNKLAR: Mischrollen und gemeinsame Verantwortlichkeit müssen nach den realen Entscheidungsbefugnissen beurteilt werden.

Auftragsverarbeitung ist mehr als ein Vertrag

Art. 28 DSGVO verlangt bei Auftragsverarbeitung einen Vertrag oder anderen Rechtsakt mit bestimmten Inhalten. Der Verantwortliche muss einen geeigneten Auftragsverarbeiter auswählen und dessen Garantien bewerten. Unterauftragsverarbeiter gehören in die Lieferkette; der EDPB hat 2024 betont, dass der Verantwortliche Informationen über Identität und Verarbeitungskette erhalten und bewerten können muss. [S001] [S003]

EMPFEHLUNG: Für jede Website eine Dienstleistertabelle führen:

Ein unterschriebener AVV ohne Kenntnis der realen Datenflüsse ist nur Papier.

Was bleibt beim Betreiber?

Der Betreiber muss insbesondere entscheiden und nachweisen:

• warum Daten verarbeitet werden,
• welche Daten notwendig sind,
• welche Empfänger eingesetzt werden,
• wie lange Daten gespeichert werden,
• welche Risiken bestehen,
• wie Betroffenenrechte erfüllt werden,
• wie Sicherheitsmaßnahmen ausgewählt und überprüft werden.

Diese Verantwortung kann durch eine Agentur unterstützt, aber nicht vollständig wegformuliert werden. [S001]

Was schuldet eine Agentur?

Ob ein Websitevertrag rechtlich als Werk-, Dienst-, Miet-, Pflege- oder Mischvertrag zu behandeln ist, hängt vom Inhalt ab. Beim Werkvertrag schuldet der Unternehmer die Herstellung des versprochenen Werkes; das Werk muss frei von vereinbarten Sach- und Rechtsmängeln sein und wird grundsätzlich abgenommen. [S016] [S017] [S018]

EMPFEHLUNG: Agenturverträge sollten nicht nur „Website erstellen“ sagen, sondern mindestens klären:

• konkreter Funktionsumfang,
• unterstützte Geräte und Browser,
• Inhaltspflichten des Kunden,
• rechtliche Texte und Freigaben,
• Datenschutzrollen,
• Hosting und Laufzeit,
• Drittanbieter und laufende Kosten,
• Barrierefreiheitsziel,
• Sicherheitsniveau und Tests,
• Abnahmekriterien,
• Fehlerklassen und Fristen,
• Wartung und Updates,
• Backup und Restore,
• Zugänge, Domain und Quellcode,
• Lizenz- und Nutzungsrechte,
• Übergabe bei Vertragsende.

Die Vorlage ist keine Rechtsberatung. Sie ist ein Fragenkatalog, der typische Konflikte sichtbar macht.

Wer schreibt Impressum und Datenschutzerklärung?

Eine Agentur kann technische Platzhalter einbauen, vom Kunden freigegebene Texte integrieren und Datenflüsse dokumentieren. Die individuelle rechtliche Prüfung eines fremden konkreten Falls kann jedoch eine Rechtsdienstleistung im Sinne des RDG sein, wenn sie eine rechtliche Prüfung erfordert. [S015]

EMPFEHLUNG: Saubere Rollentrennung:

• Agentur erstellt Daten- und Dienstleisterinventar.
• Betreiber liefert Unternehmens- und Geschäftsangaben.
• geeigneter Rechtsdienstleister prüft individuelle rechtliche Texte, wenn das Risiko oder Geschäftsmodell es verlangt.
• Agentur setzt freigegebene Inhalte und technische Entscheidungen um.
• Betreiber bestätigt vor Go-live die Richtigkeit.

„Claude hat die Datenschutzerklärung geschrieben“ ist keine Verantwortlichkeitsregel.

Wer darf auf Produktion zugreifen?

EMPFEHLUNG: Zugriffe nach dem Prinzip der geringsten Rechte vergeben:

• Redakteure ändern Inhalte, nicht Plugins und Serverkonfiguration.
• Entwickler arbeiten bevorzugt auf Staging.
• Deployment erfolgt über definierte Verfahren.
• Datenbankzugriff ist auf notwendige Personen und Zeiten beschränkt.
• Produktions-Secrets liegen nicht in Chatprotokollen oder Git.
• ehemalige Dienstleister werden sofort entfernt.

NIST CSF 2.0 und OWASP behandeln Governance, Identitäten, Zugriffsschutz, Überwachung und Wiederherstellung als zusammenhängende Aufgaben. [S075] [S089]

\newpage

Projektdefinition und Dateninventar

Vor dem ersten Code: Was soll diese Website wirklich tun?

Ein Design-Briefing reicht nicht. Die erste technische Spezifikation sollte vier Ebenen enthalten:

1. Geschäft: Wer soll was erreichen?
2. Funktionen: Welche Aktionen sind möglich?
3. Daten: Welche Informationen entstehen, wo fließen sie hin und wann werden sie gelöscht?
4. Betrieb: Wer wartet, sichert, überwacht und aktualisiert das System?

VORLAGE: Startfragen

```text

1. Wer betreibt die Website rechtlich?
2. Richtet sie sich an Verbraucher, Unternehmen oder beide?
3. Werden Verträge online angebahnt oder geschlossen?
4. Welche Formulare gibt es?
5. Können Nutzer Dateien hochladen?
6. Gibt es Logins, Rollen oder Kundenbereiche?
7. Welche Daten sind besonders vertraulich?
8. Werden Gesundheits- oder andere Art.-9-Daten erwartet?
9. Welche Drittanbieter werden direkt im Browser geladen?
10. Welche Dienste erhalten Daten im Hintergrund?
11. Welche Länder und Gesellschaften sind beteiligt?
12. Wer benötigt administrativen Zugriff?
13. Wie lange müssen Daten bleiben?
14. Wie werden Daten gelöscht oder exportiert?
15. Wie wird die Seite wiederhergestellt?

```

Das Dateninventar

Die DSGVO verlangt Transparenz, Zweckbindung, Datenminimierung, Speicherbegrenzung und Sicherheit. Diese Grundsätze lassen sich nicht verlässlich umsetzen, wenn niemand weiß, welche Daten verarbeitet werden. [S001]

EMPFEHLUNG: Für jeden Datenfluss einen Datensatz anlegen:

Das Inventar verbindet Recht, Technik und Betrieb. Ändert sich ein Formular oder wird ein Chatbot eingebaut, muss nicht nur der Code, sondern auch diese Tabelle aktualisiert werden.

Datenminimierung praktisch

EMPFEHLUNG: Jedes Eingabefeld muss eine Begründung haben.

Schlechtes Beispiel für eine einfache Rückrufanfrage:

• Vorname,
• Nachname,
• Geburtsdatum,
• vollständige Adresse,
• Telefonnummer,
• E-Mail,
• Geschlecht,
• Freitext.

Möglicherweise ausreichend:

• Name oder gewünschte Anrede,
• Telefonnummer,
• bevorzugte Zeit,
• kurze Themenauswahl.

Weniger Daten bedeuten weniger Informationspflichten, weniger Missbrauchspotenzial, weniger Löschaufwand und geringere Folgen eines Angriffs.

Browser-Datenfluss und Server-Datenfluss

Ein wichtiger Anfängerfehler besteht darin, nur die eigene Datenbank zu betrachten.

``text Browser des Besuchers ├── eigener Webserver ├── Schriftanbieter ├── Videoanbieter ├── Kartenanbieter ├── Analyseanbieter ├── Captcha-Anbieter └── Chat-/Supportdienst ``

Jeder direkte Aufruf kann Netzwerkdaten wie IP-Adresse, Zeit, Referrer und technische Merkmale an den jeweiligen Empfänger übertragen. Ob und auf welcher Grundlage das geschieht, ist gesondert zu prüfen. [S001] [S019] [S020] [S022]

Daneben existieren serverseitige Flüsse:

``text Webserver ├── Datenbank ├── E-Mail-Dienst ├── CRM ├── Automatisierung ├── Zahlungsdienst ├── Backupziel └── Protokoll-/Monitoringdienst ``

Ein Dienst, der im Browser nicht sichtbar ist, kann datenschutzrechtlich dennoch relevant sein.

Verzeichnis der Verarbeitungstätigkeiten

Art. 30 DSGVO enthält Pflichten zu Verzeichnissen von Verarbeitungstätigkeiten. Die Ausnahme für Unternehmen mit weniger als 250 Beschäftigten greift nicht pauschal, etwa wenn Verarbeitung nicht nur gelegentlich ist, Risiken birgt oder besondere Daten umfasst. [S001]

EMPFEHLUNG: Auch kleine Betreiber sollten mindestens eine schlanke Prozessdokumentation führen. Eine dauerhaft betriebene Website mit Formularen und Kundenkonten ist typischerweise keine rein zufällige Datenverarbeitung.

Datenschutz-Folgenabschätzung

Eine Datenschutz-Folgenabschätzung ist vor einer Verarbeitung erforderlich, wenn diese voraussichtlich ein hohes Risiko für Rechte und Freiheiten natürlicher Personen zur Folge hat. Die DSGVO nennt insbesondere systematische umfangreiche Bewertung, umfangreiche Verarbeitung besonderer Kategorien und umfangreiche systematische Überwachung öffentlich zugänglicher Bereiche als Beispiele. Aufsichtsbehörden veröffentlichen zusätzliche Listen. [S001] [S005]

WARNUNG: Eine DSFA ist kein Formular, das nach dem Go-live nachgetragen wird. Sie muss vor der risikoreichen Verarbeitung erfolgen und Risiken, Notwendigkeit, Verhältnismäßigkeit und Schutzmaßnahmen bewerten.

Projektentscheidungen dokumentieren

VORLAGE: docs/decisions.md

```markdown

Projektentscheidungen

Entscheidung D-001: Analyse ohne Drittanbieter

Datum: 2026-08-08 Status: beschlossen

Anlass

Besucherstatistik wird benötigt.

Entscheidung

Zunächst nur aggregierte serverseitige Statistik ohne Nutzerprofile und ohne externes Browserskript.

Gründe

Reduzierter Drittanbieter- und Einwilligungsaufwand.

Folgen

Weniger Marketingattribute; technische Logprüfung bleibt nötig.

Refresh

Bei Einführung von Kampagnen- oder Retargetingfunktionen. ```

Solche Entscheidungen helfen Claude Code, spätere Änderungen nicht gegen frühere Schutzkonzepte umzusetzen.

\newpage

Impressum nach DDG und MStV

Das Impressum beantwortet: Wer steht hinter der Seite?

§ 5 DDG verpflichtet Anbieter geschäftsmäßiger, in der Regel gegen Entgelt angebotener digitaler Dienste zu leicht erkennbaren, unmittelbar erreichbaren und ständig verfügbaren Informationen. Dazu gehören insbesondere Name und Anschrift, bei juristischen Personen Rechtsform und Vertretungsberechtigte, Angaben zur schnellen elektronischen Kontaktaufnahme, gegebenenfalls Aufsichtsbehörde, Register und Registernummer sowie berufsrechtliche Angaben. [S009]

EMPFEHLUNG: Das Impressum von jeder Unterseite mit höchstens wenigen klaren Schritten erreichbar machen. Eine versteckte Grafik, ein nur per JavaScript erreichbares Overlay oder ein Link, der im eingeloggten Zustand verschwindet, ist keine gute Umsetzung.

Wer ist Anbieter?

Anbieter ist nicht automatisch die Agentur, der Programmierer oder der Hoster. Maßgeblich ist, wer den digitalen Dienst anbietet. Bei einer Unternehmenswebsite ist das regelmäßig das Unternehmen, dessen Leistungen und Inhalte dargestellt werden.

Typische Fehler:

• Fantasiename statt vollständiger Rechtsträger,
• Markenname ohne Gesellschaft,
• ehemalige Geschäftsführung,
• Postfach statt ladungsfähiger Anschrift,
• falsches Registergericht,
• fehlende Vertretungsangaben,
• Agenturadresse als vermeintlicher Betreiber,
• Privatperson, obwohl eine GmbH Vertragspartner ist.

Gesellschaftsform und Geschäftsbriefangaben

Für Kaufleute, GmbHs und Aktiengesellschaften enthalten HGB, GmbHG und AktG zusätzliche Pflichtangaben für Geschäftsbriefe. Welche Angaben auf einer Website oder in automatisierten E-Mails erforderlich sind, sollte zur Rechtsform und Kommunikationsart passend geprüft werden. [S012] [S013] [S014]

EMPFEHLUNG: Ein einziges Stammdatenblatt als Quelle verwenden:

``text Rechtsträger: Rechtsform: Sitz: ladungsfähige Anschrift: Vertretungsberechtigte: Register: Registergericht: Registernummer: USt-ID, falls vorhanden/relevant: zuständige Aufsichtsbehörde, falls erforderlich: berufsrechtliche Angaben, falls erforderlich: inhaltlich Verantwortliche nach MStV, falls erforderlich: ``

Claude darf das Impressum nur aus diesen freigegebenen Angaben erzeugen. Es soll keine Registernummer erraten und keine Person als Geschäftsführer annehmen.

§ 18 MStV

§ 18 MStV enthält zusätzliche Anforderungen. Für Telemedien, die nicht ausschließlich persönlichen oder familiären Zwecken dienen, müssen Name und Anschrift verfügbar sein. Für journalistisch-redaktionell gestaltete Angebote, in denen insbesondere vollständig oder teilweise Inhalte periodischer Druckerzeugnisse wiedergegeben werden, ist zusätzlich eine verantwortliche Person zu benennen, die bestimmte persönliche Voraussetzungen erfüllt. [S010] [S011]

UNKLAR: Ob ein Unternehmensblog bereits journalistisch-redaktionell im Sinne der Vorschrift ist, lässt sich nicht allein an der Überschrift „Blog“ entscheiden. Inhalt, Regelmäßigkeit, Auswahl und publizistische Gestaltung sind zu betrachten.

Telefonnummer, E-Mail und Erreichbarkeit

§ 5 DDG verlangt Angaben, die eine schnelle elektronische Kontaktaufnahme und unmittelbare Kommunikation ermöglichen, einschließlich der E-Mail-Adresse. Welche weiteren Kontaktwege im Einzelfall erforderlich sind, sollte nicht aus veralteten Impressumsgeneratoren übernommen werden. [S009]

EMPFEHLUNG: Praktisch mindestens eine überwachte E-Mail-Adresse und einen real funktionierenden Kontaktweg bereitstellen. Ein Formular ohne alternative elektronische Kontaktangabe erfüllt nicht automatisch alle Anforderungen.

Automatisierte E-Mails

Kontaktbestätigungen, Rechnungen, Bestellbestätigungen und Systemnachrichten sollten ebenfalls mit vollständigen Unternehmensangaben und klarer Absenderidentität gestaltet werden. Ein technisch korrekter Shop kann durch unvollständige oder irreführende E-Mails weiterhin Probleme erzeugen.

Impressums-Audit

VORLAGE:

``text [ ] tatsächlicher Rechtsträger genannt [ ] Rechtsform korrekt [ ] ladungsfähige Anschrift aktuell [ ] Vertretungsberechtigte aktuell [ ] E-Mail-Adresse funktioniert [ ] Register und Registernummer geprüft [ ] Aufsichtsbehörde geprüft [ ] berufsrechtliche Angaben geprüft [ ] Verantwortliche Person nach § 18 MStV geprüft [ ] Link von jeder öffentlichen Seite erreichbar [ ] mobile Ansicht geprüft [ ] strukturierte Daten und Footer widersprechen nicht [ ] automatisierte E-Mails verwenden dieselben Stammdaten [ ] Datum der letzten Prüfung dokumentiert ``

\newpage

Datenschutzerklärung und Informationspflichten

Die Datenschutzerklärung ist eine Beschreibung, kein Freifahrtschein

Die Artikel 12 bis 14 DSGVO verlangen transparente Informationen über die Verarbeitung personenbezogener Daten. Typische Inhalte sind Verantwortlicher, Zwecke, Rechtsgrundlagen, Empfänger, Drittlandtransfers, Speicherdauer oder Kriterien, Betroffenenrechte, Beschwerderecht und gegebenenfalls Pflicht zur Bereitstellung sowie automatisierte Entscheidungen. [S001]

Eine Datenschutzerklärung macht eine Verarbeitung nicht rechtmäßig. Erst müssen Zweck, Rechtsgrundlage, Erforderlichkeit, Datenminimierung, Empfänger und Schutzmaßnahmen stimmen. Danach wird darüber verständlich informiert.

Art. 13 oder Art. 14?

Art. 13 betrifft Daten, die bei der betroffenen Person erhoben werden, zum Beispiel über ein Kontaktformular. Art. 14 betrifft Daten, die aus anderen Quellen stammen, etwa wenn ein Unternehmen Kontaktdaten aus öffentlichen Verzeichnissen übernimmt oder eine Agentur eine Liste importiert. [S001]

EMPFEHLUNG: Für Websites ist Art. 13 meist zentral, aber nicht ausschließlich. CRM-Importe, Empfehlungsprogramme, Plattformdaten oder Datenanreicherungen können Art. 14 auslösen.

Aufbau nach Verarbeitungsvorgängen

Eine gute Erklärung folgt nicht der Reihenfolge zufälliger Plugins, sondern den realen Vorgängen:

1. Hosting und Serverlogs,
2. Kontaktaufnahme,
3. Terminbuchung,
4. Newsletter,
5. Kundenkonto,
6. Bestellungen und Zahlung,
7. Analyse und Marketing,
8. externe Medien,
9. Chat oder KI,
10. Bewerbungen,
11. Betroffenenanfragen.

Für jeden Vorgang sollte beantwortet werden:

• Was wird verarbeitet?
• Wozu?
• Auf welcher Grundlage?
• Wer erhält die Daten?
• Gibt es Drittlandbezug?
• Wie lange bleiben sie?
• Ist die Bereitstellung erforderlich?
• Welche besonderen Risiken bestehen?

Rechtsgrundlagen nicht als Dekoration

Art. 6 Abs. 1 DSGVO enthält mehrere Rechtsgrundlagen. Für Websites häufig relevant sind Einwilligung, Vertrag/Vertragsanbahnung, rechtliche Verpflichtung und berechtigtes Interesse. Die Auswahl richtet sich nach dem konkreten Zweck. Eine Verarbeitung kann nicht nachträglich durch eine beliebige Artikelnummer legitimiert werden. [S001] [S025]

Beispiele, jeweils projektspezifisch zu prüfen:

Speicherdauer

„Wir speichern so lange wie erforderlich“ kann in manchen Fällen als Kriterium vorkommen, ist aber allein häufig zu unbestimmt. Betreiber sollten intern konkrete Regeln besitzen: sofortige Löschung, Frist nach Bearbeitung, gesetzliche Aufbewahrung, Sperrung bei Rechtsstreit oder regelmäßige Prüfung.

EMPFEHLUNG: Jede Datenkategorie erhält:

• Regelaufbewahrung,
• Auslöser der Frist,
• mögliche Ausnahme,
• Löschverfahren,
• verantwortliche Rolle,
• technischen Löschjob oder manuellen Prozess.

Betroffenenrechte müssen praktisch funktionieren

Eine Datenschutzerklärung kann Rechte aufzählen. Der Betreiber benötigt dennoch einen Prozess für Auskunft, Berichtigung, Löschung, Einschränkung, Datenübertragbarkeit, Widerspruch und Widerruf. [S001] [S131]

EMPFEHLUNG: Vor Go-live einen Testfall durchführen:

„Eine Testperson verlangt sämtliche zu ihr gespeicherten Daten, Herkunft, Empfänger und Löschung. Können wir innerhalb des Systems alle relevanten Stellen finden?“

Wenn Daten in Webserver, Datenbank, Mailbox, CRM, Newsletterdienst, Ticketsystem und Backup verteilt sind, reicht ein Datenbankexport nicht.

Versionierung der Datenschutzerklärung

EMPFEHLUNG: Änderungen mit Datum und Grund dokumentieren. Die aktuelle Erklärung sollte nicht behaupten, ein Dienst werde verwendet, wenn er entfernt wurde. Ebenso darf ein neuer Dienst nicht monatelang unsichtbar bleiben.

```text Version 1.3 - 08.08.2026

• neuer Terminbuchungsdienst aufgenommen
• Drittlandmechanismus aktualisiert
• Löschfrist für Kontaktanfragen präzisiert
• veralteten ODR-Hinweis entfernt

```

KI-generierte Rechtstexte

Eine KI kann aus dem Dateninventar einen verständlichen Entwurf erstellen. Sie kann aber Dienste übersehen, falsche Rechtsgrundlagen wählen, veraltete Gesetze nennen oder Unternehmensdaten erfinden. Individuelle rechtliche Prüfung für Dritte kann außerdem den Bereich des RDG berühren. [S015]

EMPFEHLUNG: Rechtstext-Workflow:

``text technischer Scan → Dateninventar → Rollen- und Vertragsprüfung → Textentwurf → fachliche/rechtliche Prüfung → Betreiberfreigabe → technische Veröffentlichung → Änderungsmonitor ``

\newpage

Kontaktformulare, Serverlogs und Newsletter

Kontaktformulare

Ein Kontaktformular verarbeitet mindestens die eingegebenen Angaben. Häufig entstehen zusätzlich Zeitstempel, IP-Adresse, technische Metadaten, Spam-Signale und eine E-Mail-Kopie. Der Betreiber muss nicht nur die sichtbaren Felder, sondern den gesamten Weg erfassen. [S001]

EMPFEHLUNG: Für einfache Anfragen:

• nur notwendige Pflichtfelder,
• klare Zweckbeschreibung,
• keine pauschale Pflicht-Einwilligung, wenn eine andere Rechtsgrundlage passt,
• TLS,
• serverseitige Validierung,
• Rate Limiting und Spam-Schutz,
• keine sensiblen Angaben im Betreff,
• definierte Löschung,
• kontrollierte Empfänger.

Die Checkbox-Falle

Viele Formulare enthalten:

„Ich stimme der Datenschutzerklärung zu.“

Das ist häufig missverständlich. Eine Datenschutzerklärung wird zur Kenntnis genommen; sie ist nicht automatisch ein Vertrag, dem man zustimmen muss. Eine Einwilligung muss freiwillig, informiert, bestimmt, widerruflich und nachweisbar sein. Wenn die Verarbeitung für die Bearbeitung einer Anfrage notwendig ist, kann eine erzwungene Einwilligung die falsche Konstruktion sein. [S001]

EMPFEHLUNG: Statt automatischer Checkbox zuerst Rechtsgrundlage bestimmen. Eine Checkbox nur einsetzen, wenn tatsächlich eine Einwilligung benötigt wird, und dann Zweck, Umfang und Widerruf klar formulieren.

Freitextfelder

Freitext ist technisch bequem, fachlich unkontrolliert. Menschen schreiben dort Diagnosen, Versicherungsnummern, Kontodaten oder Vorwürfe hinein.

EMPFEHLUNG: Bei sensiblen Branchen:

• Hinweis direkt am Feld,
• strukturierte Auswahl statt unbeschränktem Text,
• minimale Zeichenzahl nicht erzwingen,
• keine Diagnoseabfrage über allgemeines Kontaktformular,
• sichere alternative Kommunikation anbieten,
• Inhalt nicht ungeprüft in Betreffzeilen, Logs oder Analysewerkzeuge übernehmen.

Serverlogs

Webserver protokollieren häufig IP-Adresse, Zeitpunkt, angeforderte Ressource, Statuscode, Referrer und User-Agent. Diese Daten können für Betrieb, Fehleranalyse und Abwehr erforderlich sein, müssen aber in Zweck, Zugriff und Löschfrist begrenzt werden. [S001] [S099]

EMPFEHLUNG: Prüfen:

• Welche Felder werden wirklich geloggt?
• Werden URL-Parameter mit personenbezogenen Daten protokolliert?
• Enthalten Fehlermeldungen Formulardaten oder Tokens?
• Wer kann Logs lesen?
• Wie lange bleiben sie?
• Werden sie an externe Monitoringdienste übertragen?
• Werden IP-Adressen gekürzt, wenn der Zweck das zulässt?

Newsletter

Werbung per elektronischer Post setzt nach § 7 UWG grundsätzlich eine vorherige ausdrückliche Einwilligung voraus, sofern nicht die enge Bestandskundenausnahme greift. [S026]

Ein Double-Opt-in-Verfahren hilft, die Zuordnung der Einwilligung zu einer Adresse nachzuweisen. Der Nachweis sollte nicht nur aus einer IP-Adresse bestehen, sondern insbesondere Zeitpunkt, verwendete Einwilligungserklärung, Quelle, Bestätigung und Widerruf dokumentieren. [S027] [S028]

EMPFEHLUNG: Newsletterfelder vom Kontaktformular trennen. Die Anfrage darf nicht davon abhängen, dass Werbung akzeptiert wird.

Bewerbungsformulare

Bewerbungen enthalten häufig Lebensläufe, Fotos, Zeugnisse und weitere vertrauliche Informationen. Datei-Uploads erhöhen zusätzlich das Sicherheitsrisiko. Die Verarbeitung benötigt eine passende arbeitsrechtliche/datenschutzrechtliche Grundlage, begrenzte Zugriffe, definierte Löschfristen und Schutz vor Schadsoftware. [S001] [S081]

WARNUNG: Bewerbungsdateien nicht in einem öffentlich erreichbaren Uploadordner speichern und nicht über erratbare URLs ausliefern.

E-Mail-Weiterleitung

Ein Formular, das Nachrichten nur per E-Mail versendet, vermeidet nicht automatisch Speicher- und Sicherheitsfragen. E-Mail-Postfächer, Weiterleitungen, Spamfilter, Archivierung und mobile Geräte werden Teil des Datenflusses. Die DSK empfiehlt ein risikoorientiertes Schutzniveau bei E-Mail-Übermittlungen. [S132]

EMPFEHLUNG: Für hochsensible Inhalte ein spezialisiertes Portal oder eine geeignete sichere Kommunikationslösung statt normaler Formular-E-Mail verwenden.

\newpage

Cookies, Local Storage, Tracking und Einwilligungsbanner

Das Gesetz spricht nicht nur von Cookies

§ 25 TDDDG schützt Informationen in Endeinrichtungen. Die Regel erfasst nicht nur klassische Cookies, sondern grundsätzlich auch andere Speicher- und Zugriffstechniken. Der EDPB erläutert 2024 unter anderem URL-/Pixeltracking, lokale Verarbeitung, IP-basierte Techniken, Gerätekennungen und weitere Verfahren. [S019] [S022]

Daher ist diese Frage falsch:

„Setzen wir Cookies?“

Besser:

„Speichern wir Informationen im Endgerät oder greifen wir auf dort gespeicherte bzw. erzeugte Informationen zu?“

Wann Einwilligung erforderlich ist

§ 25 Abs. 1 TDDDG verlangt grundsätzlich Einwilligung. Abs. 2 enthält Ausnahmen, insbesondere wenn Speicherung oder Zugriff unbedingt erforderlich ist, damit der Anbieter einen vom Nutzer ausdrücklich gewünschten digitalen Dienst bereitstellen kann. [S019]

FAKT: Die technische Anwendbarkeit von Art. 5 Abs. 3 ePrivacy bzw. § 25 TDDDG bedeutet nicht automatisch, dass stets Einwilligung erforderlich ist. Die Ausnahme muss aber konkret geprüft werden. [S022]

Typischerweise eher erforderlich:

• Warenkorbstatus,
• Login-Sitzung,
• Sicherheits-/Lastverteilung, soweit wirklich notwendig,
• vom Nutzer gewählte Sprache für die konkrete Funktion.

Typischerweise nicht allein dadurch notwendig:

• Reichweitenmessung für allgemeine Marketinginteressen,
• Retargeting,
• plattformübergreifende Profile,
• Werbenetzwerke,
• Komfortfunktionen, die für den ausdrücklich gewünschten Dienst nicht erforderlich sind.

Die konkrete Einordnung hängt von Technik und Zweck ab.

Das Zwei-Ebenen-Modell

EMPFEHLUNG: Immer zwei Fragen trennen:

1. Darf auf die Endeinrichtung zugegriffen oder dort gespeichert werden? - TDDDG/ePrivacy.
2. Darf die anschließend entstehende personenbezogene Information verarbeitet werden? - DSGVO.

Eine Einwilligung nach TDDDG beantwortet nicht automatisch sämtliche DSGVO-Fragen. Umgekehrt ersetzt ein berechtigtes Interesse nicht automatisch eine nach TDDDG erforderliche Einwilligung. [S001] [S019] [S020]

Wann kein Banner sinnvoll ist

Eine technisch schlanke Seite kann ohne nicht erforderliche Browserzugriffe auskommen. Dann kann ein Einwilligungsbanner unnötig sein. Ein dekoratives Banner, das nur „Alles akzeptieren“ anbietet, schafft keine Rechtmäßigkeit und verschlechtert die Bedienung.

EMPFEHLUNG: Erst Technik reduzieren, dann Banner entscheiden:

• Schriften lokal hosten,
• Videos erst nach Klick laden,
• Karten als Link oder lokale Vorschau,
• serverseitige Statistik statt Werbetracking,
• keine unnötigen Social-Media-Skripte,
• funktionales Consent-Management nur für reale Wahlmöglichkeiten.

Anforderungen an eine Einwilligung

Eine Einwilligung muss freiwillig, spezifisch, informiert, eindeutig und nachweisbar sein. Vorgekreuzte Kästchen genügen nicht. Der EuGH stellte dies im Planet49-Verfahren für Cookies klar. [S001] [S023]

Der EDPB Cookie Banner Taskforce Report behandelt verbreitete Fehler wie fehlende Ablehnmöglichkeit, irreführende Gestaltung, vorangekreuzte Optionen und schwer auffindbaren Widerruf. [S021]

EMPFEHLUNG: Erste Ebene:

• „Alle akzeptieren“ und „Ablehnen“ gleichwertig erreichbar,
• Zweckkategorien verständlich,
• keine vorausgewählten optionalen Zwecke,
• Einstellungen dauerhaft wieder aufrufbar,
• Dienste erst nach passender Entscheidung laden,
• Einwilligungsnachweis versioniert speichern.

Consent Mode ist kein Einwilligungsersatz

Technische Modi, die Signale reduzieren oder modellierte Daten liefern, sind kein automatischer Beweis, dass der konkrete Zugriff einwilligungsfrei ist. Entscheidend ist, welche Informationen tatsächlich gespeichert, gelesen oder übertragen werden.

Der technische Cookie-Audit

VORLAGE:

```text

1. Browser in frischem Profil öffnen.
2. Speicher vor Seitenaufruf leeren.
3. Netzwerk- und Storage-Ansicht öffnen.
4. Seite ohne Interaktion laden.
5. Cookies, Local Storage, IndexedDB und Cache prüfen.
6. sämtliche Fremddomains notieren.
7. Banner ablehnen und erneut prüfen.
8. einzelne Kategorien akzeptieren und vergleichen.
9. Widerruf ausführen und erneuten Zustand prüfen.
10. mobile Ansicht, Unterseiten, Formulare und Login separat testen.
11. Ergebnisse mit Diensteliste und Datenschutzerklärung abgleichen.

```

Claude Code kann automatisierte Browserprüfungen vorbereiten. Die rechtliche Bewertung der gefundenen Technologien bleibt ein gesonderter Schritt.

Häufige Fehler

• Tracker lädt bereits vor Zustimmung.
• Ablehnen ist nur nach mehreren Klicks möglich.
• Banner nennt „notwendig“, obwohl der Dienst Marketingzwecken dient.
• Widerruf entfernt das Cookie, beendet aber nicht die weitere Profilverarbeitung.
• Skript wird über Tag Manager nachgeladen und im Code-Audit übersehen.
• Bannertext nennt Anbieter, technische Konfiguration nutzt jedoch weitere Subdienste.
• Consent-ID enthält mehr personenbezogene Daten als nötig.

\newpage

Fremddienste: Schriften, Videos, Karten, Captcha, Chat und Analyse

Das unsichtbare Adressbuch der Website

Eine moderne Seite kann beim ersten Laden Verbindungen zu zehn oder mehr Domains aufbauen. Jede Verbindung sollte einen fachlichen Grund besitzen. Ein CDN, eine Schrift, eine Kartenkachel oder ein Fehlerdienst ist nicht „nur Technik“, wenn dabei Daten an einen anderen Empfänger fließen.

Webfonts

EMPFEHLUNG: Wenn Lizenz und Technik es erlauben, Schriften lokal ausliefern. Das reduziert externe Verbindungen und Abhängigkeiten. Dabei sind Lizenzbedingungen und Updates zu beachten. Ein lokales Hosting beseitigt nicht alle Datenschutzfragen der Website, aber diesen konkreten Fremdaufruf.

Videos

Direkt eingebettete Videos können beim Seitenaufruf Ressourcen des Plattformanbieters laden. Eine datensparsame Variante verwendet zunächst ein lokales Vorschaubild und lädt den Player erst nach bewusster Aktion. Ob dafür Einwilligung erforderlich ist, hängt von der konkreten Technik ab. [S019] [S020] [S022]

Karten

Eine interaktive Karte ist komfortabel, aber nicht immer notwendig. Alternativen:

• Adresse als Text,
• statische lokal gespeicherte Skizze,
• externer Link „Route öffnen“,
• Karte erst nach Freigabe laden.

EMPFEHLUNG: Funktionalen Nutzen gegen Datenfluss, Barrierefreiheit, Ladezeit und Ausfallrisiko abwägen.

Captcha und Bot-Schutz

Ein Captcha kann externe Skripte, Geräteinformationen und Verhaltensdaten verarbeiten. Es ist nicht automatisch die einzige Möglichkeit gegen Spam.

Alternativen oder Ergänzungen:

• Honeypot-Feld,
• zeitbasierte Plausibilitätsprüfung,
• Rate Limiting,
• serverseitige Mustererkennung,
• E-Mail-Bestätigung,
• risikobasierte Eskalation.

EMPFEHLUNG: Der Bot-Schutz darf das Formular nicht für Menschen mit Behinderungen unbenutzbar machen. Barrierefreiheit und Datenschutz gehören in dieselbe Entscheidung.

Analyse

Analysewerkzeuge unterscheiden sich stark:

• lokale oder serverseitige Zählung,
• pseudonyme Reichweitenmessung,
• Sitzungsaufzeichnung,
• Nutzerprofile,
• Werbenetzwerke,
• geräteübergreifende Zuordnung.

Der Begriff „Analytics“ sagt nicht, ob Einwilligung erforderlich ist oder welche Risiken bestehen. Zweck und konkrete Konfiguration sind maßgeblich.

Chat und Support

Ein Livechat verarbeitet Kommunikationsinhalte. Ein KI-Chat kann zusätzlich Eingaben an Modellanbieter oder weitere Dienste übermitteln. Zu klären sind:

• Wer ist Anbieter?
• Welche Daten soll der Nutzer eingeben?
• Werden Gespräche gespeichert?
• Werden sie zu Training oder Verbesserung genutzt?
• Gibt es Unterauftragnehmer oder Drittlandzugriffe?
• Kann der Chat verbindliche Entscheidungen treffen?
• Wie erkennt der Nutzer, dass er mit KI spricht?

Ab 2. August 2026 gelten Art.-50-Transparenzpflichten des AI Act. Bei direkter Interaktion mit einem KI-System ist die Information grundsätzlich vor oder bei der ersten Interaktion bereitzustellen, soweit die KI-Natur nicht offensichtlich ist. [S066] [S067] [S069]

Tag Manager

Ein Tag Manager zentralisiert Skripte, kann aber zugleich Kontrollen umgehen. Neue Tags können ohne Code-Deployment aktiv werden. Deshalb gehören Tag-Manager-Zugänge, Freigaben, Versionierung und Audit in den Betriebsprozess.

EMPFEHLUNG: Produktive Tags nur nach Vier-Augen-Freigabe. Jede Änderung aktualisiert Diensteliste, Consent-Matrix und Datenschutzhinweise.

Fremddienst-Audit

\newpage

Hosting, Auftragsverarbeitung und Drittlandtransfers

„Server in Deutschland“ ist gut, aber nicht die ganze Prüfung

Der physische Serverstandort ist relevant, beantwortet aber nicht alle Fragen. Auch die Gesellschaft des Anbieters, Fernwartung, Supportzugriffe, Unterauftragnehmer, Backups, Protokolldienste und konzerninterne Zugriffe können Datenflüsse erzeugen. [S002] [S003]

EMPFEHLUNG: Nicht nur „Region Frankfurt“ prüfen, sondern:

• Vertragspartner,
• Rechenzentrumsstandorte,
• Supportstandorte,
• Unterauftragnehmer,
• Verschlüsselung und Schlüsselkontrolle,
• Backupregionen,
• Löschverfahren,
• Exportmöglichkeit,
• Zertifizierungen als Indiz, nicht als Ersatz eigener Prüfung.

AVV

Bei Auftragsverarbeitung muss der Vertrag nach Art. 28 DSGVO unter anderem Gegenstand, Dauer, Art, Zweck, Datenarten, Betroffenenkategorien sowie Pflichten und Rechte regeln. Er enthält Vorgaben zu Weisungen, Vertraulichkeit, Sicherheit, Unterauftragnehmern, Unterstützung, Löschung/Rückgabe und Nachweisen. [S001]

WARNUNG: Ein Klick auf „AVV akzeptiert“ genügt organisatorisch nicht, wenn niemand die Leistungsbeschreibung, Unterauftragnehmer und Konfiguration kennt.

Gemeinsame und eigene Verantwortlichkeit

Drittanbieter sind nicht automatisch Auftragsverarbeiter. Ein Zahlungsdienst, Social-Media-Netzwerk oder Analyseanbieter kann eigene Zwecke und Mittel bestimmen. Die Rollen müssen dienstbezogen bewertet werden. [S002]

Drittlandtransfers

Kapitel V DSGVO regelt Übermittlungen in Drittländer. Mögliche Instrumente sind Angemessenheitsbeschlüsse, geeignete Garantien wie Standardvertragsklauseln oder eng begrenzte Ausnahmen. [S001] [S029] [S030]

Beim EU-US Data Privacy Framework muss geprüft werden, ob die konkrete US-Organisation in der offiziellen Liste für die passende Datenart zertifiziert ist. [S031] [S032]

Standardvertragsklauseln können zusätzliche Bewertung und Maßnahmen erfordern. Der EDPB beschreibt ergänzende Maßnahmen und die Prüfung des Drittlandrechts. [S030] [S033]

Verschlüsselung und Schlüssel

Verschlüsselung hilft nur, wenn der Bedrohungsfall verstanden wird. Wenn Anbieter und Angreifer denselben Schlüsselzugriff haben, schützt „verschlüsselt gespeichert“ nicht gegen jeden Zugriff. OWASP empfiehlt, Daten nur zu speichern, wenn sie wirklich benötigt werden, etablierte Algorithmen und Bibliotheken zu nutzen und Schlüssel getrennt und kontrolliert zu verwalten. [S083]

Exit-Fähigkeit

EMPFEHLUNG: Vor Vertragsbeginn prüfen:

• vollständiger Datenexport,
• Formate und Dokumentation,
• Dauer und Kosten des Exports,
• Löschbestätigung,
• Domain- und DNS-Unabhängigkeit,
• Wiederherstellung bei neuem Anbieter,
• Übergabe von Schlüsseln und Konfiguration,
• Frist nach Vertragsende.

Vendor Lock-in ist nicht nur ein Preisproblem. Er kann die Erfüllung von Lösch-, Auskunfts- und Verfügbarkeitsanforderungen erschweren.

\newpage

Gesundheitsdaten und andere besonders sensible Daten

Was Gesundheitsdaten sind

Die DSGVO zählt Gesundheitsdaten zu besonderen Kategorien personenbezogener Daten. Ihre Verarbeitung ist grundsätzlich untersagt, sofern keine Ausnahme nach Art. 9 Abs. 2 greift. Zusätzlich benötigt die Verarbeitung eine Rechtsgrundlage nach Art. 6. Der EuGH hat diese zweistufige Prüfung im Urteil C-667/21 bestätigt. [S001] [S133]

Gesundheitsdaten entstehen nicht nur durch ein Feld „Diagnose“. Auch Angaben wie „Termin für Chemotherapie“, „brauche barrierefreien Zugang wegen Multipler Sklerose“ oder eine hochgeladene Verordnung können Gesundheitsinformationen sein.

Das medizinische Kontaktformular

Ein allgemeines Formular einer Praxis sollte nicht unkontrolliert vollständige Krankengeschichten entgegennehmen.

EMPFEHLUNG: Drei Kommunikationsklassen trennen:

1. Allgemein: Öffnungszeiten, Adresse, Rückrufwunsch ohne Gesundheitsinhalt.
2. Terminbezogen: minimale Termin- und Kontaktdaten mit klarer Beschränkung.
3. Medizinisch: gesicherter, speziell geprüfter Kanal mit restriktiven Zugängen und geeigneter Architektur.

Ein Freitextfeld mit dem Hinweis „Bitte schildern Sie Ihre Beschwerden ausführlich“ hebt das Risiko erheblich an.

Berufsgeheimnisse

§ 203 StGB schützt Privatgeheimnisse in bestimmten beruflichen Kontexten. Mitwirkende Personen und Dienstleister müssen in die Geheimhaltungskette passend eingebunden sein. [S008]

WARNUNG: Ein normaler Agentur-AVV beantwortet nicht automatisch alle Fragen des Berufsgeheimnisses. Vertrag, Zugriff, Support, Unterauftragnehmer und technische Kenntnisnahme sind gesondert zu prüfen.

Sicherheitsniveau

Art. 32 DSGVO nennt risikoadäquate Maßnahmen einschließlich Pseudonymisierung und Verschlüsselung, dauerhafter Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit, Wiederherstellungsfähigkeit sowie regelmäßiger Tests. [S001]

Für hochsensible Portale bedeutet das typischerweise:

• getrennte Umgebungen,
• minimale Datenerhebung,
• starke Authentifizierung,
• restriktive Rollen,
• Verschlüsselung bei Transport und Speicherung,
• getrennte Schlüsselverwaltung,
• detaillierte Protokollierung,
• kurze Sitzungen und sichere Abmeldung,
• gesicherte Backups,
• regelmäßige Wiederherstellungstests,
• Schwachstellen- und Penetrationstests,
• Incident-Plan,
• mögliche DSFA.

Dies ist eine Risikovorlage, keine pauschale gesetzliche Checkliste.

E-Mail und Gesundheitsdaten

Die DSK fordert ein dem Risiko angemessenes Schutzniveau für E-Mail-Übermittlung. Transportverschlüsselung allein schützt nicht vor jedem Zugriff, insbesondere nicht an Endgeräten oder in Postfächern. [S132]

EMPFEHLUNG: Medizinische Dokumente nicht automatisch als unverschlüsselte E-Mail-Anhänge weiterleiten. Geeignete Portale, Inhaltsverschlüsselung oder andere geprüfte Kommunikationswege verwenden.

DSFA und hohe Risiken

Bei umfangreicher Verarbeitung besonderer Kategorien oder anderen voraussichtlich hohen Risiken ist eine DSFA erforderlich. Sie muss vor Beginn der Verarbeitung erfolgen und Schutzmaßnahmen dokumentieren. [S001] [S005]

Ein Projekt, das ein Anfänger ablehnen sollte

WARNUNG: Ein erstes Claude-Code-Projekt sollte keine produktive Plattform für psychologische Befunde, genetische Daten, medizinische Bilddaten oder vertrauliche Anwaltskommunikation sein. Ein Prototyp mit vollständig fiktiven Daten kann zum Lernen dienen. Der produktive Betrieb verlangt fachkundige Architektur-, Datenschutz- und Sicherheitsprüfung.

\newpage

Sicherheitssteuerung mit NIST, BSI, OWASP und MITRE

Vier Namen, vier unterschiedliche Aufgaben

OWASP, NIST, BSI und MITRE werden häufig in einen Topf geworfen. Für ein Website-Projekt erfüllen sie unterschiedliche Funktionen:

[S075] [S076] [S089] [S090] [S094] [S096] [S097] [S098] [S100] [S101]

NIST CSF 2.0 für kleine Website-Projekte

NIST CSF 2.0 verwendet sechs Funktionen: Govern, Identify, Protect, Detect, Respond und Recover. [S089]

Einfach übersetzt:

• Govern: Wer entscheidet, bezahlt und trägt Verantwortung?
• Identify: Welche Systeme, Daten, Dienstleister und Risiken existieren?
• Protect: Welche Schutzmaßnahmen verhindern oder begrenzen Schäden?
• Detect: Wie bemerken wir Fehler und Angriffe?
• Respond: Was tun wir, wenn etwas passiert?
• Recover: Wie stellen wir Betrieb und Daten wieder her?

EMPFEHLUNG: Selbst eine kleine Agentur sollte zu jeder Funktion mindestens eine dokumentierte Antwort besitzen.

NIST SSDF für Vibe Coding

Der Secure Software Development Framework beschreibt Praktiken für Vorbereitung, Schutz der Software, sichere Produktion und Reaktion auf Schwachstellen. [S090]

Für Claude-Code-Projekte bedeutet das:

``text Anforderungen und Sicherheitsziele festlegen → Entwicklungsumgebung und Zugänge schützen → Abhängigkeiten kontrollieren → Code und Konfiguration prüfen → reproduzierbares Release erzeugen → bekannte Schwachstellen beobachten → Fehler beheben und Nutzer informieren ``

NIST SP 800-218A ergänzt Aspekte für generative KI und Modelle. Es unterstreicht, dass KI-gestützte Entwicklung keine Ausnahme vom sicheren Entwicklungsprozess ist. [S091]

OWASP Top 10 und ASVS

Die OWASP Top 10 beschreibt besonders wichtige Risikokategorien. Sie ist ein Bewusstseinsdokument, kein vollständiger Abnahmekatalog. Das OWASP ASVS bietet wesentlich detailliertere Verifikationsanforderungen für Webanwendungen. [S075] [S076]

EMPFEHLUNG:

• Informationsseite: schlanke technische Baseline plus relevante ASVS-Bereiche.
• Shop/Portal: strukturierte ASVS-basierte Prüfung.
• sensible/geschäftskritische Anwendung: unabhängige Sicherheitsprüfung und risikobasiertes höheres Verifikationsniveau.

BSI

Das BSI behandelt Webanwendungen als eigene Angriffsziele und stellt IT-Grundschutz-Bausteine für Betrieb und Entwicklung bereit. [S099] [S100] [S101]

Der Nutzen für deutsche Unternehmen liegt nicht darin, jede Grundschutzanforderung ungeprüft zu kopieren. Die Dokumente helfen, Themen wie Architektur, Entwicklung, Tests, Authentisierung, Protokollierung, Fehlerbehandlung und Betrieb systematisch abzudecken.

MITRE richtig verwenden

Beispiel:

• CWE-79 beschreibt die Schwachstellenklasse Cross-Site Scripting.
• Eine konkrete Schwachstelle in Version 1.2 eines Plugins kann eine CVE-ID erhalten.
• Ein Angreifer kann ein passendes CAPEC-Angriffsmuster nutzen.
• Nach dem Einbruch können Aktivitäten in ATT&CK-Techniken eingeordnet werden.

Die Systeme beantworten also verschiedene Fragen:

``text Welche Fehlerart? → CWE Welche konkrete bekannte Lücke? → CVE Wie wird sie angegriffen? → CAPEC Wie verhält sich ein Angreifer im System? → ATT&CK ``

Was ein Anfänger wirklich braucht

Ein kleiner Unternehmensauftritt braucht keinen eigenen Security Operations Center. Er braucht aber:

• bekannte Verantwortliche,
• aktuelles Inventar,
• sichere Standardkonfiguration,
• Updateprozess,
• Backups und Restore,
• minimierte Zugänge,
• Überwachung kritischer Fehler,
• Notfallkontakt,
• dokumentierte Änderungen.

Frameworks helfen beim Denken. Sie ersetzen kein Handeln.

\newpage

Secure by Design und der sichere Entwicklungsprozess

Sicherheit ist keine Abschlusskosmetik

CISA beschreibt Secure by Design als Ansatz, bei dem Hersteller Verantwortung für Sicherheitsfolgen übernehmen, Transparenz schaffen und Sicherheit von Beginn an priorisieren. [S107]

Für Websites heißt das:

Schlecht:

``text Funktion bauen → veröffentlichen → später Sicherheitspaket installieren ``

Besser:

``text Risiko und Missbrauchsfälle definieren → sichere Architektur wählen → mit sicheren Defaults bauen → automatisiert prüfen → kontrolliert veröffentlichen → überwachen und aktualisieren ``

Missbrauchsfälle statt nur Normalfälle

Eine klassische User Story lautet:

„Als Kunde möchte ich meine Rechnung herunterladen.“

Eine Sicherheits-Story ergänzt:

„Ein Kunde darf durch Ändern der Rechnungsnummer keine Rechnung eines anderen Kunden sehen.“

Weitere Missbrauchsfälle:

• Bot sendet 50.000 Formularanfragen.
• Angreifer lädt eine ausführbare Datei als Profilbild hoch.
• Nutzer manipuliert Preis oder Produkt-ID im Browser.
• Mitarbeiter exportiert sämtliche Kundendaten.
• Passwort-Reset verrät, welche E-Mail-Adressen registriert sind.
• Chatbot wird dazu gebracht, interne Anweisungen oder Daten auszugeben.

EMPFEHLUNG: Für jede zentrale Funktion mindestens einen Missbrauchsfall dokumentieren.

Sichere Voreinstellungen

Sichere Defaults bedeuten zum Beispiel:

• neue Konten haben minimale Rechte,
• optionale Analyse ist deaktiviert,
• Debugmodus ist in Produktion aus,
• Verzeichnisse sind nicht auflistbar,
• Fehlermeldungen zeigen keine internen Pfade,
• Datei-Uploads sind standardmäßig restriktiv,
• Administration ist nicht öffentlich unnötig offen,
• Sitzungen laufen ab,
• Zugangsdaten werden nicht mit Standardwerten ausgeliefert.

Entwicklungs-, Test- und Produktionsumgebung

EMPFEHLUNG: Mindestens drei logische Zustände unterscheiden:

Produktionsdaten sollten nicht bequem in lokale KI- oder Testumgebungen kopiert werden. Für Tests sind synthetische oder wirksam anonymisierte Daten vorzuziehen.

Pull Request, Diff und Vier-Augen-Prinzip

Claude Code kann große Änderungen schnell erzeugen. Deshalb ist eine sichtbare Änderungsliste wichtig.

EMPFEHLUNG: Vor Merge oder Deployment:

1. Anforderungen und Akzeptanzkriterien prüfen.
2. Diff anzeigen.
3. Tests ausführen.
4. Abhängigkeiten und Migrationen prüfen.
5. Sicherheitsrelevante Änderungen markieren.
6. zweiten Prüfer bei Auth, Zahlung, Rechte, Datenmigration und Secrets einbeziehen.

Abhängigkeiten und Lieferkette

Moderne Websites verwenden Pakete, Plugins, Themes, Container-Images und externe Buildaktionen. Ein kleines Projekt kann dadurch Tausende indirekte Komponenten enthalten.

Eine Software Bill of Materials beschreibt Komponenten und Lieferkettenbeziehungen. CISA bezeichnet SBOMs als wichtigen Baustein für Softwarelieferkettensicherheit und veröffentlichte im Juli 2026 aktualisierte Mindestelemente. [S108] [S109]

EMPFEHLUNG: Für professionelle Agenturprojekte mindestens erfassen:

• direkte Abhängigkeiten,
• Lockfiles,
• Versionen,
• Herkunft,
• Lizenz,
• bekannte Schwachstellen,
• Updateverantwortung,
• End-of-Life.

Geheimnisse

API-Keys, Datenbankpasswörter, private Schlüssel und Tokens gehören nicht in Quellcode, Screenshots, öffentliche Logs, CLAUDE.md oder Git.

EMPFEHLUNG:

• Umgebungsvariablen oder Secret-Manager,
• getrennte Werte je Umgebung,
• minimale Rechte,
• Rotation,
• Ablaufdaten,
• Protokollierung der Nutzung,
• sofortige Sperrung bei versehentlicher Veröffentlichung.

Ein aus Git gelöschtes Secret gilt weiterhin als kompromittiert, weil es in Historie, Klonen oder Caches vorhanden sein kann.

Release-Nachweis

VORLAGE: Jede Veröffentlichung erhält:

``text Release: Datum/Uhrzeit: Commit/Version: Freigegeben von: Tests: Migrationen: Backup vor Deployment: Rollback-Schritt: Änderungen an Datenschutz/Tracking: Änderungen an Abhängigkeiten: Ergebnis des Smoke-Tests: ``

\newpage

OWASP Top 10:2025 verständlich erklärt

A01 Broken Access Control

Zugriffskontrolle entscheidet, wer welche Aktion mit welchem Objekt ausführen darf. Fehler entstehen, wenn die Anwendung nur die Oberfläche versteckt, aber den Serverzugriff nicht prüft.

Beispiel:

``text /kunden/rechnung/4711.pdf ``

Ein Nutzer ändert 4711 zu 4712 und erhält eine fremde Rechnung.

Schutz: serverseitige Autorisierung bei jedem Zugriff, standardmäßig verweigern, Mandanten-/Eigentumsprüfung, Tests mit fremden Rollen und IDs. [S075] [S077]

A02 Security Misconfiguration

Fehlkonfiguration umfasst Debugmodus, Standardpasswörter, offene Speicher, unnötige Dienste, zu breite CORS-Regeln, Verzeichnisauflistung oder detaillierte Fehlermeldungen.

Schutz: gehärtete Baseline, Infrastructure as Code, automatische Konfigurationsprüfung, getrennte Umgebungen, keine Standardzugänge. [S075]

A03 Software Supply Chain Failures

Risiken entstehen durch verwundbare, manipulierte oder nicht mehr gepflegte Komponenten und Buildprozesse.

Schutz: Abhängigkeitsinventar, Lockfiles, vertrauenswürdige Quellen, signierte/verifizierte Releases soweit verfügbar, Update- und Schwachstellenprozess, SBOM. [S075] [S108] [S109] [S110]

A04 Cryptographic Failures

Beispiele sind fehlende TLS-Verschlüsselung, Klartextpasswörter, selbst erfundene Kryptografie, hart codierte Schlüssel oder veraltete Algorithmen.

Schutz: etablierte Bibliotheken, aktuelle BSI-/NIST-Empfehlungen, getrennte Schlüsselverwaltung, nur notwendige Daten speichern. [S083] [S102] [S103]

A05 Injection

Unkontrollierte Eingaben verändern Befehle oder Abfragen. Bekannte Varianten sind SQL Injection, Command Injection und Code Injection.

Schlecht:

``php $sql = "SELECT * FROM users WHERE email = '" . $_GET['email'] . "'"; ``

Besser: parametrisierte Abfragen und Frameworkfunktionen verwenden. Eingaben validieren und Ausgaben kontextgerecht kodieren. [S075] [S095]

A06 Insecure Design

Eine Anwendung kann fehlerfrei programmiert und trotzdem unsicher entworfen sein. Beispiel: Ein Passwort-Reset sendet ein neues Passwort unverschlüsselt per E-Mail. Der Code tut genau, was geplant wurde; der Plan ist schlecht.

Schutz: Threat Modeling, Missbrauchsfälle, sichere Standardabläufe und risikobasierte Architektur. [S075]

A07 Authentication Failures

Dazu gehören schwache Passwortregeln, unsichere Resetprozesse, fehlender Schutz gegen automatisierte Versuche, lange Sitzungen oder falsche MFA-Implementierung.

Schutz: etablierte Auth-Bibliotheken, Rate Limiting, sichere Passwortspeicherung, MFA/Passkeys nach Risiko, generische Fehlermeldungen, sichere Recovery. [S078] [S079] [S092] [S093]

A08 Software or Data Integrity Failures

Die Anwendung vertraut Updates, Daten oder Buildschritten ohne ausreichende Prüfung. Beispiele: unsignierte Updates, manipulierte CI-Abhängigkeiten oder unsichere Deserialisierung.

Schutz: kontrollierte Pipeline, vertrauenswürdige Quellen, Freigaben, Integritätsprüfungen, minimale Buildrechte. [S075]

A09 Security Logging and Alerting Failures

Ein Angriff kann wochenlang unbemerkt bleiben, wenn Loginfehler, Rechteverletzungen, Massenexporte oder Konfigurationsänderungen nicht protokolliert und ausgewertet werden.

Schutz: relevante Ereignisse definieren, Logs schützen, Alarmgrenzen festlegen, Uhrzeiten synchronisieren, sensible Inhalte nicht unkontrolliert loggen. [S075]

A10 Mishandling of Exceptional Conditions

Fehlerbehandlung kann Informationen preisgeben, Sicherheitsprüfungen überspringen oder Systeme in unsichere Zustände bringen.

Schutz: sicher scheitern, Transaktionen, Rollback, generische externe Fehler, detaillierte interne Diagnose ohne Secrets, Tests für Ausfälle. [S075]

Top 10 als Gesprächsgrundlage

EMPFEHLUNG: Claude Code vor Go-live nicht einfach fragen „Ist die Seite sicher?“. Besser:

```text Prüfe das Projekt systematisch gegen alle Kategorien der OWASP Top 10:2025.

Für jede Kategorie:

1. nenne relevante Angriffsflächen,
2. verweise auf konkrete Dateien und Funktionen,
3. führe vorhandene Schutzmaßnahmen auf,
4. markiere fehlende Nachweise,
5. schlage reproduzierbare Tests vor,
6. ändere noch nichts.

Bewerte keine Kategorie als bestanden, wenn nur Annahmen vorliegen. ```

Das Ergebnis ist ein Auditentwurf, kein Penetrationstest.

\newpage

Technische Baseline für jede produktive Website

TLS und HTTPS

TLS schützt Daten während der Übertragung. Das BSI veröffentlicht aktuelle Empfehlungen zu Protokollen, Algorithmen und Schlüssellängen. [S102] [S103]

EMPFEHLUNG:

• HTTP konsequent auf HTTPS umleiten,
• gültige Zertifikate und automatische Erneuerung,
• moderne TLS-Konfiguration,
• Mixed Content vermeiden,
• Zertifikatsablauf überwachen,
• HSTS erst aktivieren, wenn HTTPS zuverlässig funktioniert.

HSTS

HTTP Strict Transport Security weist Browser an, die Domain für einen Zeitraum nur über HTTPS aufzurufen. Eine falsche Konfiguration kann die Erreichbarkeit beeinträchtigen. [S086] [S137]

EMPFEHLUNG: Zunächst kurze Laufzeit testen. includeSubDomains und Preload nur aktivieren, wenn wirklich sämtliche Subdomains dauerhaft HTTPS unterstützen.

Content Security Policy

CSP begrenzt, aus welchen Quellen Skripte, Stile, Bilder, Frames und andere Inhalte geladen werden dürfen. Sie kann XSS-Folgen reduzieren, ersetzt aber keine sichere Programmierung. [S085] [S136]

EMPFEHLUNG:

1. reale Quellen inventarisieren,
2. Richtlinie im Report-Only-Modus testen,
3. Inline-Skripte reduzieren,
4. Nonces/Hashes statt breiter Ausnahmen,
5. Berichte überwachen,
6. schrittweise erzwingen.

Eine CSP mit unsafe-inline und beliebigen Wildcards kann einen falschen Sicherheitsgefühl erzeugen.

Weitere Header

Je nach Anwendung sind unter anderem relevant:

• X-Content-Type-Options: nosniff,
• Frame-Schutz über CSP frame-ancestors,
• Referrer-Policy,
• Permissions-Policy,
• sichere Cookie-Attribute.

OWASP stellt dazu eine Header-Übersicht bereit. [S084]

Cookies für Sitzungen

Sitzungscookies sollten je nach Einsatz insbesondere Secure, HttpOnly und eine geeignete SameSite-Einstellung verwenden. Die Domain- und Path-Reichweite soll so eng wie möglich sein. [S080]

CORS

Cross-Origin Resource Sharing darf nicht pauschal auf * gesetzt werden, wenn sensible authentifizierte Zugriffe erfolgen. Erlaubte Ursprünge, Methoden, Header und Credentials müssen bewusst definiert werden.

Fehlermeldungen

Produktive Fehlerseiten dürfen keine Stacktraces, Datenbankzugänge, interne Dateipfade, Tokens oder SQL-Abfragen zeigen. Intern braucht das Team dennoch eine korrelierbare Fehler-ID und sichere Diagnoseinformationen.

Dateirechte und Prozesse

Der Webprozess soll nur auf Verzeichnisse schreiben können, die er tatsächlich benötigt. Uploads, Anwendungscode und Konfiguration sollten getrennt werden. Datenbankbenutzer erhalten nur notwendige Rechte.

Backoffice und Administration

EMPFEHLUNG:

• MFA/Passkeys für Administratoren,
• eigene Konten statt gemeinsamer Zugang,
• minimale Rollen,
• Login-Rate-Limiting,
• administrative Aktionen protokollieren,
• ungenutzte Konten sperren,
• Zugang über VPN oder zusätzliche Schutzschicht bei hohem Risiko,
• keine Administration über öffentliche Standardpasswörter.

Sicherheitsscan richtig einordnen

Tools wie Mozilla Observatory prüfen Header und bestimmte Konfigurationen. Ein guter Score ist nützlich, aber keine vollständige Sicherheitsprüfung. [S104]

Automatisierte Scanner finden:

• bekannte Muster,
• fehlende Header,
• einige verwundbare Komponenten,
• offensichtliche Fehlkonfigurationen.

Sie finden nicht zuverlässig:

• falsche Geschäftslogik,
• Mandantentrennungsfehler,
• unzulässige Datenverarbeitung,
• unsichere Recovery-Prozesse,
• fehlende Rechte im Einzelfall.

Baseline-Checkliste

``text [ ] HTTPS erzwungen [ ] Zertifikatsüberwachung aktiv [ ] TLS-Konfiguration geprüft [ ] HSTS kontrolliert eingeführt [ ] CSP getestet [ ] Sicherheitsheader gesetzt [ ] Debugmodus aus [ ] Secrets getrennt [ ] minimale Datei-/DB-Rechte [ ] sichere Sitzungs-Cookies [ ] Admin-MFA/Passkeys [ ] Updates automatisiert beobachtet [ ] Backup vorhanden [ ] Restore getestet [ ] Logs und Alarmierung definiert [ ] Abhängigkeiten inventarisiert [ ] Staging von Produktion getrennt ``

\newpage

Login, Passwörter, Passkeys, Sitzungen und Kontowiederherstellung

Login ist ein System, kein Formular

Das sichtbare Loginformular ist nur der Eingang. Ein vollständiges Identitätssystem umfasst:

• Registrierung oder Einladung,
• Identitätsprüfung,
• Passwort-/Passkey-Anlage,
• Anmeldung,
• Rate Limiting,
• MFA,
• Sitzungsverwaltung,
• Gerätewechsel,
• Reset/Recovery,
• Sperrung,
• Rollen,
• Löschung,
• Audit.

Passwörter speichern

Passwörter dürfen nicht entschlüsselbar als Klartext gespeichert werden. OWASP empfiehlt spezielle Passwort-Hashing-Verfahren und aktuelle Parameter; allgemeine schnelle Hashfunktionen wie SHA-256 allein sind dafür ungeeignet. [S079]

EMPFEHLUNG: Framework- oder etablierte Bibliotheksfunktionen verwenden. Parameter regelmäßig gegen aktuelle Empfehlungen prüfen. Keine eigene Kryptografie entwickeln.

Passwortregeln

NIST 800-63B-4 betont unter anderem Länge, Blocklisten kompromittierter/gebräuchlicher Passwörter und praktikable Nutzerführung statt willkürlicher Komplexitätsrituale. [S093]

EMPFEHLUNG:

• ausreichend lange Passphrasen erlauben,
• Passwortmanager unterstützen,
• keine unnötig kurzen Maximalgrenzen,
• kompromittierte Passwörter blockieren,
• Änderung nicht ohne Anlass periodisch erzwingen,
• MFA/Passkeys für höhere Risiken.

Passkeys

Passkeys basieren auf Public-Key-Kryptografie und WebAuthn. Der private Schlüssel bleibt beim Authenticator; der Server speichert einen öffentlichen Schlüssel. Das kann Phishing- und Passwortwiederverwendungsrisiken reduzieren. [S105] [S106]

WARNUNG: Passkeys lösen nicht automatisch Kontowiederherstellung, Geräteverlust, geteilte Geräte oder interne Berechtigungsfehler. Recovery darf nicht schwächer sein als der normale Login.

Benutzererkennung verhindern

Fehlermeldungen wie „E-Mail nicht vorhanden“ erlauben die Ermittlung registrierter Konten. Besser sind generische Antworten, soweit dies mit Nutzerfreundlichkeit und Prozess vereinbar ist. [S078]

Rate Limiting

Login, Reset, Registrierung, SMS- oder E-Mail-Codes und API-Zugänge benötigen Schutz gegen automatisierte Versuche. Rate Limits sollten Kombinationen aus Konto, IP, Gerät und Risiko berücksichtigen, ohne legitime Nutzer dauerhaft auszusperren.

Sitzungsmanagement

OWASP empfiehlt ausreichend zufällige Sitzungskennungen, sichere Cookies, Ablaufzeiten, Regeneration nach Authentifizierung/Privilegwechsel und zuverlässige serverseitige Invalidierung. [S080]

EMPFEHLUNG:

• kurze Inaktivitätszeit bei sensiblen Portalen,
• absolute Maximaldauer,
• Abmeldung invalidiert serverseitig,
• „alle Geräte abmelden“ anbieten,
• Sitzungen nach Passwortänderung/Account-Recovery beenden,
• keine Token in URLs,
• Refresh-Tokens geschützt und rotierbar.

Kontowiederherstellung

Recovery ist häufig der schwächste Punkt. Sicherheitsfragen wie „Geburtsort der Mutter“ sind leicht recherchierbar.

EMPFEHLUNG:

• zeitlich begrenzter Einmal-Link,
• Token nur gehasht speichern,
• generische Antwort,
• Rate Limiting,
• Nutzer informieren,
• aktive Sitzungen je Risiko beenden,
• Supportprozess für Identitätsprüfung dokumentieren,
• Änderungen an E-Mail/MFA besonders schützen.

Administratoren

Admin-Konten verdienen eine eigene Klasse:

• starke MFA oder Passkeys,
• keine Alltagsnutzung als Administrator,
• keine gemeinsamen Konten,
• separate Recovery,
• Protokollierung privilegierter Aktionen,
• regelmäßige Rechteprüfung.

\newpage

Rechte, Mandantentrennung, APIs und Objektzugriffe

Authentifiziert ist nicht autorisiert

Authentifizierung beantwortet: „Wer bist du?“ Autorisierung beantwortet: „Darfst du diese konkrete Aktion mit diesem konkreten Objekt ausführen?“

Ein eingeloggter Kunde darf nicht automatisch alle Kundenobjekte lesen.

Rollen reichen nicht immer

Ein System kann Rollen admin, mitarbeiter, kunde besitzen. Dennoch muss beim Zugriff geprüft werden:

• gehört das Objekt zum Mandanten?
• ist der Benutzer Eigentümer oder ausdrücklich berechtigt?
• ist die Aktion für diesen Zustand erlaubt?
• gelten zusätzliche Einschränkungen?

Insecure Direct Object Reference

Beispiel:

``http GET /api/invoices/8842 ``

Der Server darf nicht nur prüfen, ob jemand eingeloggt ist. Er muss prüfen, ob diese Person Rechnung 8842 lesen darf.

EMPFEHLUNG: Autorisierungsprüfung zentralisieren und negativ testen:

• fremde Objekt-ID,
• fremder Mandant,
• deaktivierter Nutzer,
• alte Sitzung,
• niedrigere Rolle,
• direkte API statt Oberfläche,
• Exportfunktion,
• Suchfunktion.

Mandantentrennung

Mögliche Architekturen:

• eigene Datenbank je Kunde,
• eigenes Schema je Kunde,
• gemeinsame Tabellen mit tenant_id,
• getrennte Instanzen.

Keine Variante ist automatisch sicher. Bei gemeinsamer Tabelle muss jede Abfrage zuverlässig den Mandantenkontext berücksichtigen. Bei getrennten Datenbanken werden Betrieb und Migration komplexer.

WARNUNG: Mandanten-ID niemals nur aus einem vom Browser steuerbaren Feld übernehmen. Der serverseitig authentifizierte Kontext ist maßgeblich.

APIs

OWASP API Security Top 10 behandelt insbesondere Objekt- und Funktionsebenen-Autorisierung, Ressourcenverbrauch, sensible Geschäftsflüsse, SSRF, Fehlkonfiguration und unsichere API-Nutzung. [S077]

EMPFEHLUNG:

• explizite API-Spezifikation,
• Authentifizierung und Autorisierung je Endpunkt,
• Schemaprüfung,
• Rate Limits und Größenlimits,
• keine Massenattribute ungeprüft übernehmen,
• sichere Fehlermeldungen,
• Versionierung,
• Inventar sämtlicher Endpunkte,
• alte Endpunkte abschalten.

Exporte

CSV-/Excel-Exporte sind häufig besonders sensibel, weil sie viele Datensätze bündeln. Schutz:

• eigene Berechtigung,
• begrenzter Umfang,
• Bestätigung bei Massenexport,
• Protokollierung,
• sichere Bereitstellung,
• zeitlich begrenzte Downloads,
• Formelschutz bei CSV-Inhalten.

Rechte-Audit

VORLAGE: Für jede Rolle eine Matrix:

Jede Zelle muss durch serverseitige Tests abgesichert werden.

\newpage

Formulare, Datenbankabfragen, Datei-Uploads und Schnittstellen

Validieren, normalisieren, speichern, ausgeben

Ein sicherer Datenweg trennt vier Schritte:

1. Validieren: Entspricht der Wert dem erwarteten Typ und Bereich?
2. Normalisieren: Wird er in ein einheitliches Format gebracht?
3. Speichern: Erfolgt die Ablage mit passenden Rechten und Parametern?
4. Ausgeben: Wird der Wert passend zum Ausgabekontext kodiert?

Sanitizing und Escaping sind nicht dasselbe. WordPress dokumentiert diese Trennung ausdrücklich. [S125] [S126]

SQL Injection

Parametrisierte Abfragen trennen Daten von Befehlen. Eingabefilter allein sind kein zuverlässiger Ersatz.

EMPFEHLUNG: ORM oder vorbereitete Statements korrekt nutzen. Dynamische Tabellen-/Spaltennamen nur aus festen Allowlists. Datenbankkonto mit minimalen Rechten.

Cross-Site Scripting

XSS entsteht, wenn untrusted content als ausführbarer Browserinhalt interpretiert wird. Schutz hängt vom Kontext ab: HTML, Attribut, URL, JavaScript oder CSS brauchen unterschiedliche Kodierung. CSP ist eine zusätzliche Schicht, kein Ersatz. [S075] [S085] [S095]

CSRF

Cross-Site Request Forgery bringt einen eingeloggten Browser dazu, ungewollte Aktionen auszuführen. Schutzmaßnahmen umfassen CSRF-Tokens, geeignete SameSite-Cookies, Origin-/Referer-Prüfung und keine zustandsändernden GET-Anfragen. [S087]

Datei-Uploads

OWASP empfiehlt eine Kombination aus Erweiterungs-Allowlist, Typ- und Signaturprüfung, generierten Dateinamen, Größenlimits, separater Speicherung, Zugriffssteuerung und gegebenenfalls Malware-/Content-Prüfung. [S081]

WARNUNG: Der vom Browser gesendete MIME-Typ ist kein zuverlässiger Sicherheitsbeweis.

EMPFEHLUNG:

• nur benötigte Typen,
• keine ausführbaren Dateien,
• zufälliger interner Dateiname,
• Originalname nur als Metadatum,
• außerhalb des Webroots oder über kontrollierten Download,
• Bilddateien neu dekodieren/erzeugen, wenn passend,
• Archive restriktiv behandeln,
• Größen-/Anzahl-/Zeitlimits,
• Upload und Download autorisieren,
• Löschfristen.

SSRF

Server-Side Request Forgery entsteht, wenn der Server vom Nutzer steuerbare URLs abruft und dadurch interne Dienste, Cloud-Metadaten oder andere Ziele erreicht.

EMPFEHLUNG: Wenn Nutzer eine URL eingeben dürfen:

• erlaubte Protokolle,
• DNS/IP-Prüfung,
• interne/private Bereiche blockieren,
• Redirects kontrollieren,
• Timeouts und Größenlimits,
• separater Netzwerkzugang,
• Antwortinhalt begrenzen.

Webhooks

Webhooks sind eingehende automatisierte Aufrufe. Schutz:

• Signaturprüfung,
• Zeitstempel und Replay-Schutz,
• Geheimnisrotation,
• Idempotenz,
• Größenlimits,
• Queue statt langer Verarbeitung,
• sichere Protokollierung,
• nicht allein auf Quell-IP vertrauen.

Zahlungsdaten

EMPFEHLUNG: Kreditkarten- und Zahlungsdaten möglichst bei spezialisierten Zahlungsdienstleistern belassen. Eigene Speicherung erhöht Sicherheits- und Complianceumfang erheblich. Auch bei gehosteten Zahlungsseiten müssen Manipulation, Rückmeldung, Webhooks, Bestellstatus und Betrug sicher behandelt werden.

KI-Schnittstellen

Prompts können personenbezogene oder vertrauliche Daten enthalten. Zu prüfen:

• Modellanbieter und Vertrag,
• Training/Retention,
• Region und Unterauftragnehmer,
• Prompt Injection,
• Ausgabefilter,
• Rechte des Agenten,
• Protokollierung,
• menschliche Kontrolle.

NIST SP 800-218A überträgt sichere Entwicklungspraktiken auf generative KI und dual-use foundation models. [S091]

\newpage

WordPress sicher betreiben

WordPress ist ein Betriebssystem für Inhalte

WordPress besteht aus Core, Themes, Plugins, Datenbank, Medien, Benutzerkonten, Konfiguration und Hostingumgebung. Sicherheit hängt vom gesamten System ab, nicht nur vom Core.

Updates

WordPress dokumentiert Updateverfahren und empfiehlt vor Updates Backups. Core, Plugins und Themes müssen regelmäßig aktualisiert werden. [S121]

EMPFEHLUNG:

• Sicherheitsupdates beobachten,
• Staging für größere Änderungen,
• Backup vor Update,
• automatisierte Smoke-Tests,
• verlassene Plugins ersetzen,
• nicht benötigte Plugins/Themes löschen, nicht nur deaktivieren,
• PHP- und Datenbankversionen im Support halten.

Plugin-Auswahl

Prüffragen:

• Ist das Plugin aktiv gepflegt?
• Ist es mit aktueller WordPress-/PHP-Version kompatibel?
• Gibt es nachvollziehbaren Anbieter und Support?
• Welche Daten verarbeitet es?
• Welche externen Dienste lädt es?
• Welche Rollen/Rechte verlangt es?
• Gibt es bekannte Schwachstellen?
• Kann die Funktion mit weniger Erweiterungen erreicht werden?

Viele Plugins erhöhen nicht nur Angriffsfläche, sondern auch Konflikt- und Wartungsrisiko.

Administratorrechte

WordPress verfügt über Rollen und Capabilities. Plugins sollen Fähigkeiten statt nur Rollennamen prüfen. [S123]

EMPFEHLUNG:

• Redakteure nicht als Administratoren,
• individuelle Konten,
• MFA/Passkeys für Admins,
• keine gemeinsamen Agenturlogins,
• ehemalige Nutzer entfernen,
• Plugin-/Theme-Dateieditor in Produktion deaktivieren, wenn der Betriebsprozess das erlaubt,
• administrative Aktionen nachvollziehbar machen.

wp-config.php

Die Konfiguration enthält sensible Angaben und Sicherheitsoptionen. WordPress dokumentiert Schutz und Einstellungen. [S119]

EMPFEHLUNG:

• nicht öffentlich auslieferbar,
• minimale Leserechte,
• Secrets nicht in Tickets/Chat kopieren,
• Debugausgabe in Produktion deaktiviert,
• getrennte Umgebungswerte,
• Salts/Keys bei Kompromittierung rotieren.

Dateirechte und Webserver

Der Webserver soll nicht beliebig Anwendungscode verändern können. Automatische Updateverfahren müssen mit der Rechtearchitektur abgestimmt werden. WordPress Hardening gibt Hinweise, warnt aber zugleich davor, einzelne Snippets blind zu übernehmen. [S116]

Backups

Ein WordPress-Backup umfasst mindestens:

• Datenbank,
• Uploads,
• Themes/Plugins bzw. reproduzierbare Versionen,
• Konfiguration und externe Umgebungswerte,
• Webserver-/DNS-/Mail-relevante Einstellungen,
• Dokumentation des Restore.

Das Backup-Plugin im selben Hostingkonto ist keine ausreichende einzige Kopie.

Staging und Datenschutz

Produktionsdaten nicht ungeprüft nach Staging kopieren. Falls realistische Daten nötig sind, minimieren/anonymisieren und Zugriffe begrenzen.

WordPress-Audit

``text [ ] Core aktuell [ ] PHP/DB unterstützt [ ] Plugins/Themes inventarisiert [ ] ungenutzte Erweiterungen entfernt [ ] Pflegezustand geprüft [ ] Rollen minimal [ ] Admin-MFA/Passkeys [ ] wp-config geschützt [ ] Debug aus [ ] HTTPS vollständig [ ] Datei-Editor/Berechtigungen geprüft [ ] Backup extern [ ] Restore getestet [ ] Staging getrennt [ ] Fremddienste/Tracking geprüft [ ] Datenschutzfunktionen der Plugins geprüft ``

\newpage

Eigene WordPress-Plugins und Themes entwickeln

WordPress-APIs statt eigene Umwege

WordPress empfiehlt, vorhandene APIs und Sicherheitsfunktionen zu verwenden. Themes sollen dynamische Ausgaben escapen; Datenbankzugriffe sollen die vorgesehenen APIs und vorbereiteten Funktionen nutzen. [S118] [S122]

Capability Checks

Jede privilegierte Aktion benötigt eine serverseitige Capability-Prüfung. Das bloße Verstecken eines Menüpunkts reicht nicht. [S123]

Nonces

WordPress-Nonces helfen gegen bestimmte Missbrauchsformen wie CSRF. WordPress warnt ausdrücklich, dass sie nicht für Authentifizierung, Autorisierung oder Zugriffskontrolle verwendet werden dürfen. [S124]

EMPFEHLUNG: Für eine administrative Aktion:

``text Benutzer angemeldet? → passende Capability? → korrekter Nonce? → Eingabe validiert? → Objektzugriff erlaubt? → Aktion durchführen → Ergebnis und Fehler sicher behandeln ``

Eingaben und Ausgaben

• Validierung bevorzugen, wenn ein klarer Wertebereich existiert.
• Sanitizing bereinigt Eingaben, wenn strengere Validierung nicht möglich ist.
• Escaping erfolgt möglichst spät und passend zum Ausgabekontext. [S125] [S126]

REST-Endpunkte

Eigene WordPress-REST-Routen benötigen permission_callback, Eingabeschema, Authentifizierung und objektbezogene Rechteprüfung. Öffentliche Endpunkte dürfen nicht versehentlich sensible Daten ausgeben.

Datenbanktabellen und Deinstallation

Ein Plugin muss dokumentieren:

• welche Tabellen/Optionen es anlegt,
• wie Migrationen funktionieren,
• welche Daten bei Deaktivierung bleiben,
• was bei Deinstallation gelöscht wird,
• wie Export-/Löschanforderungen unterstützt werden.

WordPress stellt Privacy-Hooks und Mechanismen für Export und Löschung bereit. [S127]

Updates und Signierung

Ein eigenes Plugin wird zum dauerhaft zu wartenden Produkt. Sicherheitsupdates, kompatible Versionen, Migrationsfehler, Rollback und Support müssen geregelt werden. Bei kommerzieller Bereitstellung kann der Cyber Resilience Act perspektivisch relevant werden; Scope und Zeitplan sind fachlich zu prüfen. [S113] [S114] [S115]

Theme-Sicherheit

Themes verarbeiten viele Ausgaben. Dynamische Inhalte müssen kontextgerecht escaped werden. SQL-Abfragen und benutzerdefinierte Funktionen dürfen nicht an den vorgesehenen WordPress-Sicherheitsmechanismen vorbeigehen. [S118]

Plugin-Review-Prompt

```text Analysiere dieses WordPress-Plugin ohne Änderungen.

Prüfe insbesondere:

• Capability Checks,
• Nonces und ihre Grenzen,
• Eingabevalidierung und Sanitizing,
• kontextgerechtes Escaping,
• SQL-Abfragen,
• REST- und AJAX-Endpunkte,
• Datei-Uploads,
• CSRF, XSS und Zugriffskontrolle,
• Secrets und externe Dienste,
• Datenschutz-Export/Löschung,
• Installations-, Update- und Deinstallationspfad.

Nenne je Befund Datei, Funktion, Risiko, Angriffsszenario, Nachweis und sichere Abhilfe. Verändere noch nichts. ```

\newpage

Individuelle HTML-, PHP- und Datenbankprojekte

Die Vorteile einer schlanken eigenen Website

Eine statische Seite ohne CMS kann sehr wenige Komponenten besitzen:

• HTML,
• CSS,
• wenige lokale Skripte,
• Webserver,
• keine Datenbank,
• kein Login,
• keine Plugins.

Das reduziert Wartungs- und Angriffsfläche. Inhalte sind jedoch weniger bequem pflegbar, und jede Erweiterung muss bewusst entwickelt werden.

Wann PHP und Datenbank hinzukommen

Kontaktformulare, dynamische Inhalte, Konten, Bestellungen und Verwaltungsbereiche benötigen serverseitige Logik und häufig eine Datenbank. Dann entstehen dieselben Grundrisiken wie in großen Systemen: Authentifizierung, Eingaben, Rechte, Sitzungen, Updates und Backups.

Framework oder selbst gebaut?

Ein etabliertes Framework bringt Routing, Templates, ORM, CSRF-Schutz, Auth-Bausteine, Migrationen und Tests mit. Es erhöht Abhängigkeiten, reduziert aber die Notwendigkeit, grundlegende Sicherheitsmechanismen selbst zu erfinden.

EMPFEHLUNG: Kein eigenes Passwortsystem, Sessionformat oder Kryptoprotokoll bauen, wenn etablierte, gepflegte Komponenten existieren.

PHP-Baseline

• unterstützte PHP-Version,
• display_errors in Produktion aus,
• Fehler sicher loggen,
• vorbereitete Datenbankabfragen,
• Composer-Lockfile,
• Secrets außerhalb Webroot/Git,
• sichere Session-Cookies,
• Output Escaping,
• CSRF-Schutz,
• Datei-Upload-Grenzen,
• minimale Dateirechte.

Datenbank

EMPFEHLUNG:

• getrennte Benutzer je Anwendung/Umgebung,
• keine Root-Zugangsdaten im Webprozess,
• nur notwendige Rechte,
• Migrationen versionieren,
• Backup vor destruktiven Migrationen,
• Transaktionen,
• Fremdschlüssel/Constraints soweit passend,
• persönliche Daten klassifizieren,
• Lösch- und Aufbewahrungslogik.

Statische Seite plus Formularservice

Ein externer Formularservice reduziert eigenen Backendcode, wird aber zum Datenempfänger und Dienstleister. Vertrag, Datenstandort, Unterauftragnehmer, Spam-Schutz, Löschung und Drittlandtransfers sind zu prüfen. Weniger Code bedeutet nicht automatisch weniger Verantwortung.

Serverless und Edge

Serverless-Funktionen können Betrieb vereinfachen. Gleichzeitig verteilen sich Daten, Logs, Regionen, Secrets und Abhängigkeiten über Plattformdienste. Die Datenschutz- und Exitprüfung bleibt erforderlich.

Eigener Code und Langzeitwartung

Die größte Frage lautet nicht: „Kann Claude das heute bauen?“

Sondern:

„Kann jemand in zwei Jahren verstehen, aktualisieren, testen und sicher betreiben, was heute gebaut wurde?“

EMPFEHLUNG: Für jede individuelle Anwendung:

• README,
• Architekturübersicht,
• Datenmodell,
• lokale Startanleitung,
• Testbefehl,
• Deployment,
• Backup/Restore,
• Secrets-Liste ohne Werte,
• Abhängigkeitsinventar,
• bekannte Grenzen,
• Übergabedokumentation.

\newpage

Webshops und Verbraucherpflichten

Ein Shop ist kein Kontaktformular mit Warenkorb

Sobald Verbraucher online Waren oder Dienstleistungen bestellen können, greifen zahlreiche Informations- und Gestaltungspflichten. Die technische Bestellstrecke muss mit Produktdarstellung, Preisen, Vertragstext, Zahlungsarten, Lieferbedingungen, Widerruf und Bestätigung zusammenspielen. [S049] [S050] [S051] [S059] [S061]

EMPFEHLUNG: Die Bestellstrecke als rechtlich-technischen Prozess modellieren:

``text Produktinformation → Warenkorb → Identität/Lieferdaten → Versand und Zahlung → gesetzlich geforderte Zusammenfassung → eindeutig beschriftete Bestellschaltfläche → Bestellbestätigung → Widerrufs-/Kündigungsfunktionen je Vertrag → Erfüllung, Support und Rückabwicklung ``

Informationspflichten

Art. 246a § 1 EGBGB enthält umfangreiche Informationspflichten für außerhalb von Geschäftsräumen geschlossene Verträge und Fernabsatzverträge. Je nach Angebot gehören dazu unter anderem wesentliche Eigenschaften, Identität und Kontakt, Gesamtpreis, Zahlungs-/Lieferbedingungen, Laufzeit, Kündigung, Widerrufsrecht und weitere Angaben. [S050]

WARNUNG: Die Pflichtinformationen unterscheiden sich nach Waren, Dienstleistungen, digitalen Inhalten, Abonnements, Finanzdienstleistungen und weiteren Sonderfällen. Eine generische Shopvorlage kann nicht jede Variante abdecken.

Preise

Die Preisangabenverordnung regelt unter anderem Gesamtpreise, Grundpreise und weitere Darstellungsanforderungen. [S051]

EMPFEHLUNG: Für jede Produktart prüfen:

• Gesamtpreis einschließlich Umsatzsteuer,
• zusätzliche Liefer-/Versandkosten,
• Grundpreis,
• Preis je Abrechnungszeitraum,
• Laufzeit und Mindestdauer,
• Preisänderungsmechanismus,
• Rabatte und vorheriger Preis,
• B2B-/B2C-Zielgruppe.

Button-Lösung

§ 312j BGB verlangt bei zahlungspflichtigen Verbraucherverträgen eine klare Bestellsituation und eine eindeutig beschriftete Schaltfläche. Die gesetzliche Formulierung „zahlungspflichtig bestellen“ ist der sichere Referenzpunkt; gleichwertige eindeutige Formulierungen können möglich sein. [S049]

Problematische Beschriftungen:

• „Weiter“,
• „Registrieren“,
• „Bestätigen“,
• „Loslegen“,
• „Jetzt testen“, wenn unmittelbar Zahlungspflicht entsteht.

EMPFEHLUNG: Direkt vor dem Button die gesetzlich wesentlichen Informationen vollständig und hervorgehoben anzeigen. Keine Ablenkung oder nachträgliche Kostenänderung.

Bestellbestätigung und Vertragstext

Die Bestätigung muss den tatsächlichen Vertrag reproduzierbar dokumentieren. Produkt, Preis, Laufzeit, Bedingungen und Widerrufsinformationen dürfen nicht nur als veränderliche Website existieren.

EMPFEHLUNG: Versionierte AGB-/Informationsstände und eine unveränderliche Bestellzusammenfassung speichern, soweit rechtlich und datenschutzrechtlich erforderlich.

Zahlungsdienstleister

Zahlungsdienste können eigene Verantwortlichkeiten, Auftragsverarbeitungsanteile, Drittlandtransfers, Betrugsprüfungen und technische Webhooks mitbringen. Der Shop muss Statusänderungen zuverlässig und idempotent behandeln.

WARNUNG: Der Browser darf nicht allein bestätigen, dass eine Zahlung erfolgreich war. Maßgeblich ist eine serverseitig verifizierte Rückmeldung des Zahlungsdienstes.

Widerruf

Bei vielen Verbraucherverträgen besteht ein Widerrufsrecht. § 312g BGB enthält Ausnahmen. Informationen, Musterformular und nun gegebenenfalls die elektronische Widerrufsfunktion müssen zur konkreten Vertragsart passen. [S050] [S056] [S060]

Streitbeilegung und ODR

§ 36 VSBG kann Informationspflichten zur Teilnahmebereitschaft oder -verpflichtung an Verbraucherschlichtung auslösen. [S052]

Die frühere EU-Plattform zur Online-Streitbeilegung wurde durch Verordnung (EU) 2024/3228 eingestellt; Beschwerden konnten ab 20. März 2025 nicht mehr eingereicht werden, die Plattform endete im Juli 2025. Alte Mustertexte mit ODR-Link müssen entfernt oder aktualisiert werden. [S053]

Shop-Audit

``text [ ] Zielgruppe B2C/B2B klar [ ] Produktart rechtlich eingeordnet [ ] wesentliche Eigenschaften vollständig [ ] Gesamt-/Grundpreise korrekt [ ] Versand-/Zusatzkosten vor Bestellung [ ] Lieferzeiten realistisch [ ] Bestellzusammenfassung vollständig [ ] Button eindeutig [ ] Bestätigung dauerhaft verfügbar [ ] Widerrufsbelehrung passend [ ] Widerrufsfunktion geprüft [ ] Kündigungsbutton bei Dauerschuldverhältnis geprüft [ ] VSBG-Information geprüft [ ] ODR-Altlink entfernt [ ] Zahlungswebhooks serverseitig geprüft [ ] GPSR-Produktinformationen vollständig [ ] Barrierefreiheit der gesamten Vertragsstrecke geprüft ``

\newpage

Widerrufs-, Kündigungs- und Bestellfunktionen ab 2026

Drei verschiedene Schaltflächen

[S049] [S056] [S058]

Diese Funktionen sind nicht austauschbar. Ein Shop kann mehrere davon benötigen.

Elektronische Widerrufsfunktion

§ 356a BGB gilt seit 19. Juni 2026 für erfasste Fernabsatzverträge, die über eine Online-Benutzeroberfläche geschlossen werden. Die Funktion muss während der Widerrufsfrist ständig verfügbar, hervorgehoben und leicht zugänglich sein. Die erste Schaltfläche muss „Vertrag widerrufen“ oder eine entsprechend eindeutige Formulierung tragen. Der Nutzer gelangt zu einer Bestätigungsfunktion, die „Widerruf bestätigen“ oder gleichwertig bezeichnet ist. Anschließend ist der Eingang auf einem dauerhaften Datenträger zu bestätigen. [S050] [S056]

EMPFEHLUNG: Technisch ohne Loginzwang zugänglich machen, wenn der Nutzer sonst praktisch am Widerruf gehindert würde. Gleichzeitig Missbrauch durch Vertragsidentifikation und sichere Zustellung der Bestätigung begrenzen.

Minimale Datenerhebung

§ 356a beschreibt die Angaben, die verlangt werden können: Name, Angaben zur Identifizierung des Vertrags und ein elektronisches Kommunikationsmittel für die Bestätigung. Zusätzliche Hürden sollten nicht eingebaut werden. [S056]

Problematisch:

• Pflicht zur Angabe eines Widerrufsgrundes,
• versteckter Link nur im Kundenkonto,
• telefonische Bestätigung als zusätzliche Bedingung,
• Captcha, das viele Nutzer ausschließt,
• unnötige Datenfelder,
• Funktion nur während Geschäftszeiten.

Kündigungsschaltfläche

§ 312k BGB betrifft bestimmte online abschließbare entgeltliche Dauerschuldverhältnisse. Die Website muss eine gut lesbar mit „Verträge hier kündigen“ oder gleichwertig beschriftete Schaltfläche anbieten, die zu einer Bestätigungsseite führt. Die Bestätigungsseite und abschließende Schaltfläche müssen gesetzliche Anforderungen erfüllen; der Zugang ist unmittelbar elektronisch zu bestätigen. [S058]

Technische Anforderungen

EMPFEHLUNG: Für beide Funktionen:

• unabhängig vom Marketing-CMS testen,
• 24/7 erreichbar,
• mobil bedienbar,
• Tastatur und Screenreader unterstützt,
• keine unnötigen Cookies,
• Zeitstempel serverseitig,
• unveränderliche Eingangsbestätigung,
• redundante Zustellung und internes Ticket,
• Fehleralarm, wenn Zustellung scheitert,
• keine Offenlegung, ob fremde Vertragsnummern existieren,
• Protokollierung ohne übermäßige Daten.

Testfälle

```text

1. korrekter Vertrag und korrekte E-Mail
2. Tippfehler in Vertragsnummer
3. fremde Vertragsnummer
4. Vertrag ohne Widerrufsrecht
5. Frist abgelaufen
6. mehrfacher Widerruf
7. E-Mail-Zustellung fehlschlägt
8. Seite mit JavaScript blockiert
9. mobile Tastaturnavigation
10. Screenreader-Beschriftung
11. hoher Bot-Traffic
12. Zeitzonen-/Datumsgrenze

```

Keine Rechtslogik nur im Frontend

Der Browser darf nicht allein entscheiden, ob ein Vertrag widerrufbar ist. Serverseitige Logik, dokumentierte Regeln und menschliche Eskalation bei unklaren Fällen sind notwendig.

\newpage

Produktsicherheit, Marktplätze und Nutzerinhalte

GPSR im Online-Angebot

Die Verordnung (EU) 2023/988 gilt seit 13. Dezember 2024. Art. 19 verlangt bei Online- oder anderen Fernabsatzangeboten klar und sichtbar mindestens:

• Name/Handelsname/Marke des Herstellers sowie Post- und elektronische Adresse,
• bei Hersteller außerhalb der EU Angaben zur verantwortlichen Person,
• Informationen zur Produktidentifikation einschließlich Bild, Typ und weiterer Kennung,
• Warn- und Sicherheitsinformationen in verständlicher Sprache. [S054] [S055]

EMPFEHLUNG: Diese Angaben als strukturierte Produktdaten modellieren, nicht in freie Beschreibungstexte verstecken.

Marktplatz statt eigener Shop

Ein Shop verkauft eigene Waren. Ein Marktplatz bringt Händler und Verbraucher zusammen oder hostet Angebote Dritter. Dann können zusätzliche Pflichten aus GPSR und Digital Services Act hinzukommen. [S062] [S063] [S135] [S140]

Mögliche zusätzliche Themen:

• Händlernachverfolgbarkeit,
• Melde- und Abhilfeverfahren,
• Umgang mit illegalen oder unsicheren Angeboten,
• Transparenz über Ranking und Werbung,
• Beschwerdesystem,
• Moderation,
• Aufbewahrung von Nachweisen.

UNKLAR: Der DSA enthält differenzierte Dienstekategorien und teilweise Ausnahmen. Die konkrete Rolle muss vor Entwicklung fachlich eingeordnet werden.

Nutzerinhalte

Sobald Nutzer Bewertungen, Bilder, Kommentare, Kleinanzeigen oder Dateien veröffentlichen, entstehen Risiken:

• Persönlichkeitsrechte,
• Urheberrechte,
• illegale Inhalte,
• Malware,
• Betrug,
• Veröffentlichung personenbezogener Daten,
• Moderation und Löschanträge.

EMPFEHLUNG: Vor Freischaltung definieren:

• zulässige Inhalte,
• technische Größen-/Typgrenzen,
• Meldeweg,
• Moderationsregeln,
• Eskalation,
• Sperr- und Einspruchsprozess,
• Protokollierung,
• Reaktionszeiten,
• Zuständigkeit.

Plugin oder Theme als Produkt

Wer ein Plugin, Theme oder eigenständige Software kommerziell bereitstellt, wird nicht nur Agentur. Er kann zum Hersteller eines Produkts mit digitalen Elementen werden. Der Cyber Resilience Act bringt gestaffelte Pflichten. Bestimmte Meldepflichten starten am 11. September 2026; Hauptpflichten folgen am 11. Dezember 2027. [S113] [S114] [S115]

EMPFEHLUNG: Schon heute:

• Komponentenliste/SBOM,
• sichere Defaults,
• Supportzeitraum,
• Schwachstellenkontakt,
• Updatekanal,
• signierte/prüfbare Releases,
• Sicherheitsdokumentation,
• Meldungs- und Incidentprozess.

NIS2/BSIG

Das BSIG 2025 setzt NIS2 in Deutschland um und gilt seit 6. Dezember 2025. Nicht jede Agentur und nicht jeder Shop ist erfasst. Sektor, Tätigkeit, Größe und weitere Kriterien entscheiden. [S111] [S112] [S134]

EMPFEHLUNG: Bei größeren Kunden oder kritischen Branchen einen Scope-Check als Vertragsfrage einbauen. Auch wenn die Agentur selbst nicht reguliert ist, kann der Kunde Sicherheitsanforderungen an Lieferanten weitergeben.

\newpage

Barrierefreiheit nach BFSG, BGG, BITV und WCAG

Nicht jede Website fällt unter dasselbe Gesetz

Seit 28. Juni 2025 gelten wesentliche Pflichten des BFSG. Erfasst sind bestimmte Produkte und Dienstleistungen, darunter Dienstleistungen im elektronischen Geschäftsverkehr, die über Websites oder mobile Dienste im Hinblick auf den Abschluss eines Verbrauchervertrags erbracht werden. [S034] [S035] [S036]

Reine Informationsseiten fallen nicht automatisch allein deshalb unter das BFSG. Online-Shops, Buchungs- und Vertragsstrecken sind dagegen besonders relevant. [S038] [S039]

Kleinstunternehmen

Das BFSG enthält für Kleinstunternehmen, die Dienstleistungen anbieten oder erbringen, eine Ausnahme. Ob sie greift, hängt von Unternehmensgröße und konkreter Leistung ab. Produkte sind anders zu behandeln. [S034] [S040]

WARNUNG: „Wir sind klein“ ist keine ausreichende Prüfung. Beschäftigte, Umsatz/Bilanz und Rolle als Dienstleistungs- oder Produktanbieter müssen betrachtet werden.

Öffentliche Stellen

Öffentliche Stellen des Bundes unterliegen BGG und BITV 2.0. Dazu gehören Anforderungen an barrierefreie Informationstechnik und eine Erklärung zur Barrierefreiheit. Länder und Kommunen haben entsprechende landesrechtliche Regelungen. [S043] [S044] [S045]

WCAG 2.2

WCAG 2.2 ist eine W3C Recommendation vom 5. Oktober 2023. Sie strukturiert Anforderungen nach den vier Prinzipien wahrnehmbar, bedienbar, verständlich und robust sowie den Konformitätsstufen A, AA und AAA. [S041] [S042]

WICHTIG: Der aktuelle rechtliche Referenzstandard und harmonisierte Normenstand kann von der jeweils neuesten WCAG-Version abweichen. Die Europäische Kommission und Bundesfachstelle veröffentlichen den Harmonisierungsstand. [S046] [S047]

EMPFEHLUNG: WCAG 2.2 AA als Entwicklungsziel verwenden, die konkrete gesetzliche Normverweisung vor Abnahme separat prüfen.

Praktische Grundregeln

Wahrnehmbar

• Textalternativen für informative Bilder,
• Untertitel/Transkripte für Medien,
• ausreichende Kontraste,
• Inhalte nicht allein durch Farbe erklären,
• Zoom und Reflow unterstützen.

Bedienbar

• vollständige Tastaturbedienung,
• sichtbarer Fokus,
• keine Tastaturfallen,
• ausreichend große Ziele,
• Zeitlimits steuerbar,
• keine gefährlichen Flackerinhalte.

Verständlich

• klare Sprache,
• konsistente Navigation,
• verständliche Feldbeschriftungen,
• Fehler erklären und Korrektur ermöglichen,
• wichtige Folgen vor Abschluss bestätigen.

Robust

• semantisches HTML,
• korrekte Namen/Rollen/Werte,
• kompatibel mit Assistenztechnik,
• Statusmeldungen zugänglich.

[S041]

Formulare

EMPFEHLUNG:

• sichtbares Label statt nur Placeholder,
• Pflichtfelder programmatisch erkennbar,
• Fehler am Feld und als Zusammenfassung,
• Fokus zum Fehler,
• Eingabezweck über passende Attribute,
• keine unnötigen Zeitlimits,
• verständliche Bestätigung.

Shops und Vertragsstrecken

Barrierefreiheit muss die vollständige Strecke umfassen:

• Produktsuche,
• Filter,
• Warenkorb,
• Login/Gastbestellung,
• Adresse,
• Zahlung,
• Bestellübersicht,
• Bestellbutton,
• Widerrufs- und Kündigungsfunktionen,
• Bestätigung.

Ein barrierefreier Startbereich hilft nicht, wenn der Zahlungsdialog unbedienbar ist.

Overlays

Automatische Overlays oder Widgets können einzelne Anpassungen anbieten, ersetzen aber nicht die Behebung von Problemen im Quellcode. Die Europäische Kommission weist ausdrücklich darauf hin. [S048]

Automatisierte Tests

Tools finden einen Teil der Probleme, etwa fehlende Labels, bestimmte Kontrastfehler oder ungültige ARIA-Nutzung. Sie prüfen nicht vollständig:

• Sinn von Alternativtexten,
• logische Fokusreihenfolge,
• verständliche Sprache,
• tatsächliche Screenreader-Nutzung,
• komplexe Bedienabläufe.

EMPFEHLUNG: Kombination aus automatisierten Tests, Tastaturtest, Screenreader-Stichprobe und manueller Fachprüfung.

Barrierefreiheits-Audit

``text [ ] Anwendungsbereich BFSG/BGG/BITV geprüft [ ] Zielstandard dokumentiert [ ] semantische Struktur [ ] Tastatur vollständig [ ] sichtbarer Fokus [ ] Kontrast [ ] Zoom/Reflow [ ] Bilder/Icons [ ] Medien [ ] Formulare/Fehler [ ] Dialoge/Overlays [ ] Shop-/Vertragsstrecke [ ] Widerruf/Kündigung [ ] PDF-Dokumente [ ] Drittanbieter-Widgets [ ] automatisierte Prüfung [ ] manueller Test [ ] Erklärung/Information, falls erforderlich [ ] Prozess für neue Inhalte ``

\newpage

KI-Funktionen und Kennzeichnung nach dem AI Act

Seit 2. August 2026 besonders aktuell

Die Transparenzpflichten aus Art. 50 AI Act gelten seit 2. August 2026. Die Europäische Kommission veröffentlichte im Juli 2026 FAQ und Leitlinien. [S065] [S066] [S067] [S068] [S069]

Website mit Claude Code gebaut

FAKT/ABLEITUNG: Art. 50 enthält konkrete Transparenzpflichten für bestimmte KI-Systeme und KI-generierte/manipulierte Inhalte. Er enthält keine pauschale Pflicht, eine Website, deren Quellcode, Design oder Texte mit KI-Unterstützung erstellt wurden, mit „KI-generiert“ zu kennzeichnen. Diese Aussage ist eine Auslegung des begrenzten Tatbestands, keine individuelle Rechtsprüfung. [S066] [S067] [S068]

Folglich braucht ein normaler Footer nicht:

„Diese Website wurde mit Claude Code programmiert.“

Eine freiwillige Information ist möglich, aber keine allgemeine Art.-50-Pflicht.

Chatbots

Bei Systemen, die direkt mit natürlichen Personen interagieren, muss grundsätzlich offengelegt werden, dass es sich um ein KI-System handelt, sofern dies aus Sicht einer angemessen informierten, aufmerksamen und verständigen Person nicht offensichtlich ist. Die Information soll spätestens bei der ersten Interaktion erfolgen. [S066] [S067]

EMPFEHLUNG: Direkt im Chatkopf:

„Sie schreiben mit einem KI-gestützten Assistenten. Bitte geben Sie keine vertraulichen oder medizinischen Informationen ein.“

Zusätzlich erklären:

• Zweck und Grenzen,
• Speicherung,
• menschliche Eskalation,
• keine verbindliche Beratung, falls zutreffend,
• Datenempfänger.

Deepfakes

Wer ein KI-System einsetzt, um Bild-, Audio- oder Videoinhalte zu erzeugen oder zu manipulieren, die Deepfakes darstellen, muss grundsätzlich offenlegen, dass der Inhalt künstlich erzeugt oder manipuliert wurde. Für künstlerische, satirische oder ähnliche Werke gelten besondere Ausgestaltungen. [S066] [S067] [S068]

EMPFEHLUNG: Ein realistisches KI-Video eines vermeintlich sprechenden Geschäftsführers klar kennzeichnen. Ein abstraktes dekoratives Hintergrundbild ist nicht automatisch ein Deepfake.

Texte von öffentlichem Interesse

Art. 50 enthält eine Offenlegungspflicht für KI-generierte oder manipulierte Texte, die veröffentlicht werden, um die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse zu informieren. Es bestehen Ausnahmen, wenn menschliche Überprüfung oder redaktionelle Kontrolle stattgefunden hat und eine Person die redaktionelle Verantwortung trägt. [S066] [S067] [S068]

UNKLAR: Ob ein konkreter Blogbeitrag, Ratgeber oder Unternehmensartikel eine Angelegenheit von öffentlichem Interesse betrifft, ist inhaltlich zu prüfen.

Technische Markierung

Art. 50 verpflichtet Anbieter bestimmter generativer KI-Systeme, Ausgaben in einem maschinenlesbaren Format zu markieren und als künstlich erzeugt oder manipuliert erkennbar zu machen, soweit technisch machbar. Das ist von den Offenlegungspflichten des Websitebetreibers als Deployers zu unterscheiden. [S066] [S068] [S070]

KI im Kundenservice

EMPFEHLUNG: Keine automatische Entscheidung über Kündigung, Leistungsablehnung, Kredit, medizinische Dringlichkeit oder andere folgenreiche Vorgänge ohne gesonderte Prüfung. Ein Chatbot sollte bei Unsicherheit an Menschen übergeben und keine internen Daten ohne Berechtigung abrufen.

KI-Audit

\newpage

KI-generierte Texte, Bilder, Code und rechtliche Dokumente

Urheberrechtsschutz des Outputs

§ 2 UrhG schützt persönliche geistige Schöpfungen. Reine maschinelle Erzeugnisse ohne hinreichenden menschlichen schöpferischen Beitrag können deshalb keinen klassischen Werksschutz erhalten. Die Bewertung hängt von den konkreten menschlichen Beiträgen ab. [S071] [S072] [S074]

UNKLAR: Die Grenze zwischen bloßer Eingabe, Auswahl, Bearbeitung und eigener schöpferischer Gestaltung ist einzelfallabhängig.

Fremde Rechte bleiben relevant

Auch wenn ein KI-Output selbst nicht geschützt ist, kann er bestehende Rechte verletzen, wenn er geschützte Werke, Marken, Personen oder Designs übernimmt oder stark ähnelt. Das DPMA weist auf dieses Risiko hin. [S073]

EMPFEHLUNG: Für jedes Website-Asset dokumentieren:

• Quelle,
• Lizenz,
• Erstellungswerkzeug,
• menschliche Bearbeitung,
• Freigabe,
• zulässige Nutzungen,
• Namensnennung,
• Ablauf/Kündigung der Lizenz.

KI-Bilder

Prüffragen:

• zeigt das Bild eine reale Person oder täuscht es ein reales Ereignis vor?
• liegt ein Deepfake vor?
• enthält es Marken, Produkte oder erkennbare Werke?
• besitzt der Generator ausreichende Nutzungsbedingungen für kommerzielle Verwendung?
• müssen Metadaten oder Markierungen erhalten bleiben?
• ist das Bild barrierefrei beschrieben?

KI-Texte

KI kann falsche Fakten, erfundene Quellen und unzulässige Werbeaussagen erzeugen. Der Websitebetreiber trägt die Verantwortung für veröffentlichte Aussagen.

EMPFEHLUNG: Faktenworkflow:

``text Entwurf → Behauptungen markieren → Primärquellen prüfen → rechtliche/medizinische Aussagen fachlich freigeben → Ton und Verständlichkeit bearbeiten → Veröffentlichungsdatum und Verantwortlichen dokumentieren ``

Impressum und Datenschutzerklärung

Es besteht keine allgemeine Pflicht, ein mit KI vorbereitete Impressum oder eine Datenschutzerklärung als KI-generiert zu kennzeichnen. Die Inhalte müssen dennoch korrekt sein. Der Betreiber darf keine Registernummer, Rechtsgrundlage oder Empfängerliste übernehmen, die das Modell erfunden hat. [S009] [S001] [S066] [S067]

WARNUNG: Eine Agentur, die individuell rechtlich prüft und fremde Rechtstexte erstellt, muss die Grenzen des RDG beachten. KI ändert diese Grenze nicht. [S015]

KI-Code

KI-generierter Code kann:

• falsche Bibliotheksfunktionen verwenden,
• veraltete Pakete einführen,
• Lizenztexte übersehen,
• Tests passend zum Fehler statt zur Anforderung schreiben,
• Sicherheitsprüfungen nur oberflächlich implementieren.

EMPFEHLUNG: Code nicht nach Herkunft, sondern nach Nachweis behandeln. Jeder produktive Code braucht Review, Tests, Komponenteninventar und Betriebspfad.

Kennzeichnung freiwillig nutzen

Freiwillige Transparenz kann Vertrauen schaffen, etwa:

„Der Artikel wurde mit KI-Unterstützung vorbereitet und fachlich durch [Rolle] geprüft.“

Sie sollte nur verwendet werden, wenn die behauptete Prüfung tatsächlich stattgefunden hat.

\newpage

Agenturgeschäft: Verträge, Abnahme, Rechte und Übergabe

Das Geschäftsmodell ist möglich - aber nicht durch den Prompt abgeschlossen

Claude Code senkt die technische Einstiegshürde. Dadurch können Einzelpersonen Webseiten für andere bauen. Wer Geld dafür verlangt, übernimmt jedoch eine andere Rolle als beim privaten Experiment. Kunden erwarten Funktion, Verfügbarkeit, Rechte, Übergabe und Fehlerbehebung.

Leistungsbeschreibung

EMPFEHLUNG: Die Leistungsbeschreibung enthält konkrete Ergebnisse:

• Anzahl/Art der Seiten,
• CMS und Rollen,
• Formulare,
• Schnittstellen,
• Shopfunktionen,
• Login/Portal,
• Migration,
• Texte/Bilder,
• Barrierefreiheitsziel,
• Datenschutz-/Sicherheitsleistungen,
• Hosting,
• Wartung,
• Schulung,
• Dokumentation.

Nicht ausreichend:

„Moderne, rechtssichere und DSGVO-konforme Website.“

Diese Aussage ist zu pauschal und schafft unklare Erwartungen.

Mitwirkung des Kunden

Der Kunde muss häufig liefern:

• Unternehmensstammdaten,
• Inhalte und Freigaben,
• Produktinformationen,
• Preise und Vertragsbedingungen,
• Dienstleisterverträge,
• berechtigte Nutzer,
• Aufbewahrungsregeln,
• rechtliche Fachtexte,
• Zugang zu bestehenden Konten.

Fristen und Folgen fehlender Mitwirkung sollten geregelt werden.

Abnahmekriterien

Beim Werkvertrag ist die Abnahme ein zentraler Punkt. [S016] [S017] [S018]

VORLAGE:

```text Abnahme erfolgt anhand von:

• freigegebener SPEC,
• Funktionsmatrix,
• Browser-/Gerätematrix,
• Testprotokoll,
• Daten-/Trackinginventar,
• Sicherheitsbaseline,
• Barrierefreiheitsziel,
• Inhaltsfreigabe,
• dokumentierten Restpunkten.

```

Rechtliche Prüfungen

EMPFEHLUNG: Vertraglich trennen:

• technische Erfassung und Umsetzung,
• allgemeine Fachinformation,
• individuelle rechtliche Beratung,
• Freigabe durch Kunde/Rechtsberater.

Keine Garantiezusage, die die Agentur real nicht prüfen kann.

Quellcode und Nutzungsrechte

Klären:

• wem gehört individueller Code?
• welche Nutzungsrechte werden eingeräumt?
• welche Open-Source-/Drittkomponenten gelten?
• darf die Agentur Module wiederverwenden?
• erhält der Kunde Repository und Historie?
• wann werden Rechte übertragen - sofort oder nach Zahlung?
• welche Schrift-/Bild-/Template-Lizenzen sind übertragbar?

Wartung

Ein Go-live ohne Wartungsvereinbarung erzeugt ein Loch:

• Wer beobachtet Sicherheitsmeldungen?
• Wer aktualisiert?
• Wer bezahlt Breaking Changes?
• Welche Reaktionszeit gilt?
• Was ist ein Notfall?
• Wer erneuert Domains/Zertifikate?
• Wer kontrolliert Backups?

EMPFEHLUNG: Wartung als eigene Leistung mit klaren Grenzen anbieten, nicht als unausgesprochene lebenslange Pflicht.

Haftungs- und Sicherheitskommunikation

Kein System ist absolut sicher. Professionell ist nicht die Behauptung „unkaputtbar“, sondern:

• dokumentiertes Sicherheitsniveau,
• bekannte Grenzen,
• vereinbarte Prüfungen,
• Meldeweg,
• Updateprozess,
• angemessene Reaktion.

Übergabe

VORLAGE: Übergabepaket:

``text [ ] Domaininhaberschaft [ ] Registrar-/DNS-Zugänge [ ] Hostingvertrag [ ] Repository und Historie [ ] Deploymentanleitung [ ] Admin- und Redakteurskonten [ ] Secret-Übergabe über sicheren Kanal [ ] Dienstleister-/Lizenzliste [ ] Dateninventar [ ] Datenschutz-/Cookie-Matrix [ ] Backup- und Restore-Anleitung [ ] Monitoring/Alarmierung [ ] Updateplan [ ] offene Risiken [ ] Abnahmeprotokoll [ ] Löschung der Agenturkopien nach Vereinbarung ``

\newpage

Domains, Zugänge und technische Eigentumsfragen

Domaininhaber ist eine reale Rechtsposition

Bei einer .de-Domain entsteht der Domainvertrag zwischen DENIC und dem eingetragenen Domaininhaber, auch wenn die Registrierung über einen Provider läuft. DENIC beschreibt ausdrücklich Konflikte, wenn eine vermeintlich für den Kunden registrierte Domain tatsächlich auf einen Dritten eingetragen ist. [S128] [S129]

EMPFEHLUNG: Die Kundengesellschaft oder der vereinbarte Betreiber wird Domaininhaber. Die Agentur erhält technische Verwaltungsrechte, nicht unbeabsichtigt Eigentumsmacht.

Provider, Registrar, DNS und Hosting

Diese Rollen sind verschieden:

• Registry: verwaltet Top-Level-Domain, bei .de DENIC.
• Registrar/Provider: registriert und verwaltet Domain.
• DNS: ordnet Namen technischen Zielen zu.
• Hosting: betreibt Website/Server.
• E-Mail: kann separat laufen.

Ein Hostingwechsel muss nicht automatisch Domain- oder E-Mail-Wechsel bedeuten.

Domainnamen und Rechte Dritter

DENIC weist darauf hin, dass Domaininhaber selbst prüfen müssen, ob Registrierung oder Nutzung Rechte Dritter verletzt. Marken-, Namens- und Firmenrechte können betroffen sein. [S128]

EMPFEHLUNG: Vor Registrierung mindestens Marken-/Firmen-/Webrecherche; bei Konfliktrisiko fachliche Rechtsprüfung.

Zugangsmodell

EMPFEHLUNG:

• Kunde besitzt Hauptkonto,
• Agentur erhält eigenes Benutzerkonto,
• MFA aktiviert,
• Recovery beim Kunden und dokumentiert,
• keine gemeinsamen Passwörter per E-Mail,
• Rollen minimal,
• Zugriffsentzug bei Vertragsende,
• Notfallkontakt.

API- und Deployment-Zugänge

Separate Tokens für:

• CI/CD,
• DNS-Automation,
• Backup,
• Monitoring,
• E-Mail,
• Zahlungswebhooks.

Jeder Token nur mit erforderlichen Rechten, Ablauf und Rotation.

Bus-Faktor

Ein Projekt ist gefährdet, wenn nur eine Person weiß:

• wo die Domain liegt,
• wie Deployment funktioniert,
• wo Backups sind,
• welche Secrets benötigt werden,
• wie Datenbankmigrationen laufen.

EMPFEHLUNG: Mindestens eine zweite verantwortliche Person oder versiegelte Notfalldokumentation.

Agenturwechsel

Ein guter Vertrag ermöglicht Anbieterwechsel:

• AuthInfo/Transfer,
• DNS-Export,
• Codeexport,
• Datenbankexport,
• Medien,
• Konfiguration,
• Lizenzübersicht,
• aktuelle Dokumentation,
• Übergangsfrist,
• Löschung alter Kopien.

Eine Agentur gewinnt Kunden durch Leistung, nicht durch technische Geiselnahme.

\newpage

Backups, Restore, Protokollierung und Incident Response

Eine Website ist erst sicher betreibbar, wenn sie wiederherstellbar ist

Viele Projekte enden gedanklich beim erfolgreichen Go-live. Die Seite ist erreichbar, das Zertifikat funktioniert und das Formular sendet Nachrichten. Technisch beginnt jetzt jedoch der längste Teil des Projekts: der Betrieb.

Eine produktive Website verändert sich ständig. Inhalte werden ergänzt, Benutzerkonten entstehen, Bestellungen gehen ein, Dateien werden hochgeladen, Softwarepakete erhalten Updates und Konfigurationen werden angepasst. Ein Fehler, Angriff oder Bedienfehler kann deshalb nicht nur den Programmcode treffen, sondern auch Daten, Zugänge und den laufenden Geschäftsbetrieb.

EMPFEHLUNG: Eine Website darf erst produktiv gehen, wenn mindestens diese Fragen beantwortet sind:

``text Was muss gesichert werden? Wo liegen die Sicherungen? Wer kann sie wiederherstellen? Wie lange dauert die Wiederherstellung? Wie viel Datenverlust ist höchstens vertretbar? Wann wurde der Restore zuletzt tatsächlich getestet? Wer reagiert bei einem Sicherheitsvorfall? ``

NIST ordnet Wiederherstellung als eigene Funktion des Cybersecurity Framework ein. Incident Handling umfasst außerdem Vorbereitung, Erkennung und Analyse, Eindämmung, Beseitigung sowie Wiederherstellung. [S089] [S138]

Git, Deployment, Snapshot und Backup sind vier verschiedene Dinge

Diese Begriffe werden in kleinen Projekten oft vermischt.

WARNUNG: Ein nächtlicher Snapshot auf demselben Server kann bei einem Totalausfall, kompromittiertem Administratorkonto oder Ransomware unbrauchbar werden. Eine Sicherung muss gegen das konkrete Ausfallszenario bestehen, nicht nur als Datei mit dem Namen „Backup“ existieren.

Was zu einer vollständigen Website-Sicherung gehört

Je nach Projekt gehören mindestens folgende Bestandteile in das Sicherungskonzept:

1. Quellcode und Build-Konfiguration – Git-Repository, Tags, Releases, Abhängigkeitsdateien.
2. Datenbank – konsistenter Dump oder datenbankspezifische Sicherung.
3. Benutzeruploads – Bilder, Dokumente, Avatare, Rechnungen, Exportdateien.
4. Umgebungs- und Serverkonfiguration – Webserver, Reverse Proxy, Container, Dienste, Cronjobs.
5. Secrets und Schlüssel – getrennt und besonders geschützt; nicht einfach in das normale Repository legen.
6. DNS- und Domaininformationen – Provider, Zonen, wichtige Einträge, Wiederherstellungszugänge.
7. Zertifikate und Automatisierung – soweit sie nicht reproduzierbar neu erzeugt werden können.
8. E-Mail- und Transaktionskonfiguration – Absender, DNS-Einträge, Webhooks, Vorlagen.
9. Externe Dienste – dokumentieren, welche Daten ausschließlich bei Drittanbietern liegen und wie sie exportiert werden können.
10. Betriebsdokumentation – Restore-Anleitung, Ansprechpartner, Abhängigkeiten und Reihenfolge.

EMPFEHLUNG: Für jedes Element festhalten:

``text Quelle → Sicherungsverfahren → Ziel → Rhythmus → Aufbewahrung → Verschlüsselung → Verantwortlicher → letzter Restore-Test ``

RPO und RTO ohne Fachchinesisch

Zwei Begriffe helfen, ein Backup nicht nur nach Gefühl zu planen.

RPO – Recovery Point Objective: Wie viele Daten dürfen im schlimmsten Fall verloren gehen?

Wenn ein Shop alle sechs Stunden gesichert wird, können theoretisch bis zu sechs Stunden Bestellungen fehlen. Ist das akzeptabel? Bei einem kleinen Blog vielleicht. Bei einem stark genutzten Shop eher nicht.

RTO – Recovery Time Objective: Wie lange darf das System höchstens ausfallen?

Eine Vereinsseite kann möglicherweise einen Tag offline sein. Ein Buchungsportal oder Shop benötigt eventuell eine deutlich kürzere Wiederherstellungszeit.

VORLAGE:

Die Werte sind EMPFEHLUNGSBEISPIELE, keine gesetzlichen Vorgaben. Sie müssen aus Geschäftsrisiko, Verträgen und Datenschutzanforderungen abgeleitet werden.

Eine verständliche 3-2-1-Logik

Als robuste Grundidee kann gelten:

• drei Datenkopien,
• auf mindestens zwei unterschiedlichen technischen Zielen,
• davon eine räumlich oder administrativ getrennt.

Das ist keine Zauberformel. Es zwingt aber dazu, nicht alles auf dasselbe Gerät und unter dasselbe Administratorkonto zu legen. BSI-Grundschutz behandelt Datensicherung und Wiederherstellung als geplante organisatorische und technische Aufgabe. [S139]

EMPFEHLUNG für ein kleines Webprojekt:

```text

1. produktives System
2. verschlüsselte automatisierte Sicherung beim Hoster oder auf separatem Speicher
3. zusätzliche versionierte Offsite-Kopie unter getrenntem Zugang

```

Backup-Verschlüsselung und Schlüsselverwaltung

Ein Backup enthält oft mehr Daten als die sichtbare Website. Es kann vollständige Datenbanken, persönliche Nachrichten, Passwort-Hashes, interne Konfiguration und historische Inhalte enthalten.

EMPFEHLUNG:

• Backups bei Übertragung und Speicherung verschlüsseln.
• Schlüssel nicht ausschließlich auf dem zu sichernden Server lagern.
• Zugriff auf wenige Rollen begrenzen.
• Wiederherstellungszugänge in einem Notfallverfahren dokumentieren.
• Ausscheidende Mitarbeitende und Agenturen aus Backup-Systemen entfernen.
• Löschfristen auch bei Sicherungen berücksichtigen, soweit technisch und rechtlich umsetzbar.

OWASP weist für kryptografische Speicherung darauf hin, dass die Auswahl von Algorithmen, Schlüsselverwaltung und der tatsächliche Schutzbedarf zusammengehören. [S083]

Der Restore-Test ist der eigentliche Beweis

Ein Backup-Job mit grünem Haken beweist nur, dass ein Prozess ohne gemeldeten Fehler beendet wurde. Er beweist nicht, dass alle benötigten Daten enthalten sind oder dass eine Wiederherstellung gelingt.

EMPFEHLUNG: Mindestens regelmäßig einen vollständigen Test in einer getrennten Umgebung durchführen:

``text leere Testumgebung bereitstellen → Programmversion einspielen → Datenbank wiederherstellen → Uploads einspielen → Konfiguration setzen → Anwendung starten → Login und Kernprozesse testen → Ergebnis und Dauer dokumentieren ``

Prüffragen:

• Sind Datenbank und Dateien aus demselben Zeitpunkt konsistent?
• Sind alle Schlüssel und Umgebungsvariablen verfügbar?
• Sind Passwörter oder API-Schlüssel inzwischen rotiert?
• Funktionieren geplante Aufgaben und E-Mail-Versand?
• Sind externe Webhooks nach dem Restore doppelt ausgelöst worden?
• Ist klar, wie DNS bei einem Notfall umgestellt wird?
• Können mehrere Mandanten weiterhin nur ihre eigenen Daten sehen?

Rollback ist nicht Restore

Ein Rollback stellt eine frühere Programmversion wieder her. Ein Restore stellt verlorene oder beschädigte Daten wieder her.

Beispiel:

Ein neues Release enthält einen Fehler und löscht bei jeder Anmeldung einen Datensatz. Ein Code-Rollback stoppt den Fehler. Die bereits gelöschten Datensätze kommen dadurch nicht zurück. Dafür ist ein Daten-Restore oder eine fachliche Rekonstruktion nötig.

EMPFEHLUNG: Bei Datenbankänderungen immer gemeinsam planen:

• Vorwärtsmigration,
• Rückwärtskompatibilität,
• Rollback der Anwendung,
• Wiederherstellung von Daten,
• Umgang mit Einträgen, die während der Fehlerphase entstanden sind.

Protokollierung: sehen, was passiert – ohne neue Datensammlung zu schaffen

Logs helfen bei Fehlern, Angriffserkennung und Nachweisen. Zu wenig Protokollierung macht einen Vorfall unsichtbar. Zu viel Protokollierung kann jedoch sensible Daten vervielfältigen.

Nicht ungeprüft protokollieren:

• Passwörter und Reset-Tokens,
• vollständige Session-IDs,
• API-Schlüssel,
• Zahlungsdaten,
• medizinische Freitexte,
• komplette Formularinhalte,
• Authorization-Header,
• private Schlüssel,
• unbearbeitete Datei-Uploads.

Sinnvoll können sein:

• Zeitstempel,
• Ereignistyp,
• technische Fehler-ID,
• betroffener Dienst,
• pseudonymisierte oder gekürzte Benutzerkennung,
• administrative Änderungen,
• fehlgeschlagene und erfolgreiche sicherheitsrelevante Aktionen,
• Quelle und Ergebnis von Rechteprüfungen,
• Deployment- und Konfigurationsänderungen.

OWASP führt unzureichendes Logging und Monitoring als sicherheitsrelevanten Themenbereich. [S075] Das Datenschutzprinzip der Datenminimierung gilt auch für Protokolle. [S001]

Aufbewahrung und Zugriff auf Logs

EMPFEHLUNG: Für jede Logart festlegen:

``text Zweck → Inhalt → Rechtsgrundlage → Zugriff → Speicherort → Schutz → Aufbewahrungsdauer → Löschung ``

Debug-Logs sollten nicht unbegrenzt in Produktion laufen. Ein Entwickler darf nicht automatisch dauerhaften Zugriff auf alle Kundendaten und produktiven Logs erhalten. Für Supportfälle können zeitlich begrenzte, protokollierte Zugänge sinnvoll sein.

Wann liegt ein Datenschutzvorfall vor?

Ein Datenschutzvorfall ist nicht nur ein erfolgreicher Hackerangriff. Die DSGVO spricht von einer Verletzung des Schutzes personenbezogener Daten, die zur unbeabsichtigten oder unrechtmäßigen Vernichtung, zum Verlust, zur Veränderung, unbefugten Offenlegung oder zum unbefugten Zugang führt. [S001] [S004]

Beispiele:

• Kundendatenbank öffentlich erreichbar.
• Backup wird unverschlüsselt gestohlen.
• E-Mail mit personenbezogener Anlage geht an falschen Empfänger.
• Fehler zeigt Kunden Dokumente eines anderen Mandanten.
• Admin-Konto wird übernommen.
• Ransomware verschlüsselt personenbezogene Daten.
• Protokolle enthalten versehentlich Passwörter oder Gesundheitsangaben.
• Ein Dienstleister meldet eine kompromittierte Subverarbeitung.

Die 72-Stunden-Regel richtig verstehen

Art. 33 DSGVO verlangt grundsätzlich eine Meldung an die zuständige Aufsichtsbehörde möglichst binnen 72 Stunden nach Bekanntwerden, wenn die Verletzung voraussichtlich zu einem Risiko für Rechte und Freiheiten natürlicher Personen führt. Ist die Meldung verspätet, ist die Verzögerung zu begründen. Nicht jeder Vorfall ist meldepflichtig, aber jeder relevante Vorfall muss fachlich bewertet und dokumentiert werden. [S001] [S004]

Bei voraussichtlich hohem Risiko kann zusätzlich eine Benachrichtigung der betroffenen Personen erforderlich sein. [S001]

WARNUNG: Die 72 Stunden beginnen nicht erst, wenn die Technik vollständig verstanden wurde. Deshalb braucht ein Unternehmen vor dem Vorfall einen Meldeweg.

Incident-Response-Ablauf für kleine Teams

Schritt 1: Alarm ernst nehmen

Quelle, Zeitpunkt und erste Beobachtung sichern. Nicht reflexartig sämtliche Logs löschen oder das System neu installieren.

Schritt 2: Eindämmen

Je nach Lage:

• kompromittierte Konten sperren,
• Schlüssel und Tokens rotieren,
• verwundbare Funktion abschalten,
• betroffenen Server isolieren,
• fehlerhaftes Release stoppen,
• externe Integrationen begrenzen.

Schritt 3: Beweise sichern

Logs, Zeitpunkte, betroffene Versionen, Konfigurationen und relevante Systeme nachvollziehbar sichern. Zugang nur für berechtigte Personen.

Schritt 4: Umfang bestimmen

• Welche Systeme?
• Welche Daten?
• Welche Personen?
• Welche Zeitspanne?
• Wurde nur Verfügbarkeit gestört oder wurden Daten gelesen/verändert?
• Bestehen besondere Kategorien von Daten?
• Gibt es Mandanten- oder Kundenüberschneidungen?

Schritt 5: rechtlich bewerten

Datenschutz, Verträge, Versicherungen, mögliche behördliche oder branchenspezifische Pflichten und gegebenenfalls Strafverfolgung prüfen. EDPB-Leitlinien helfen bei der strukturierten Bewertung von Datenschutzverletzungen. [S004]

Schritt 6: beseitigen und wiederherstellen

Ursache entfernen, Systeme aus einem vertrauenswürdigen Zustand wiederherstellen, Schlüssel erneuern, Updates einspielen und Kernfunktionen testen.

Schritt 7: kommunizieren

Sachlich, konsistent und ohne Spekulation. Nicht behaupten, es seien „keine Daten betroffen“, solange dies nicht belegt ist.

Schritt 8: nachbereiten

Ursache, Wirkung, Reaktionszeit, Lücken und Maßnahmen dokumentieren. NIST behandelt diese Lernphase als Teil eines wirksamen Incident-Prozesses. [S138]

Vorfallkarten

VORLAGE: kompromittiertes Administratorkonto

``text [ ] Konto sperren [ ] aktive Sitzungen widerrufen [ ] Passwort und MFA/Passkey neu einrichten [ ] Tokens und API-Schlüssel prüfen/rotieren [ ] letzte administrative Aktionen untersuchen [ ] neue Benutzer, Weiterleitungen und Plugins prüfen [ ] Datenzugriffe und Exporte bewerten [ ] Datenschutz-Risikobewertung dokumentieren [ ] Ursache schließen ``

VORLAGE: fehlerhafte Veröffentlichung personenbezogener Daten

``text [ ] öffentliche Erreichbarkeit sofort stoppen [ ] Suchmaschinen/CDN/Caches berücksichtigen [ ] Inhalt und Zeitraum dokumentieren [ ] Zugriffslogs sichern [ ] Zahl und Art betroffener Personen bestimmen [ ] Sensibilität und Missbrauchsrisiko bewerten [ ] Melde- und Benachrichtigungspflichten prüfen [ ] korrigierte Version veröffentlichen [ ] Ursache im Entwicklungsprozess beheben ``

VORLAGE: Ransomware oder Serverkompromittierung

``text [ ] System isolieren [ ] keine unüberlegte Bereinigung [ ] Identitäten und Zugänge sichern [ ] unabhängige Hilfe einbeziehen [ ] Backup-Integrität prüfen [ ] Datenabfluss zusätzlich zur Verschlüsselung prüfen [ ] vertrauenswürdige Neuinstallation/Restore planen [ ] betroffene Dienste und Personen bewerten ``

Was Claude Code im Notfall tun darf

Claude Code kann bei der Auswertung technischer Informationen helfen, Checklisten abarbeiten, Konfigurationsunterschiede suchen, Logs strukturieren und Wiederherstellungsschritte in einer Testumgebung vorbereiten.

WARNUNG: Im echten Vorfall darf ein Agent nicht eigenmächtig:

• produktive Systeme löschen oder neu installieren,
• Beweise überschreiben,
• öffentliche Aussagen veröffentlichen,
• Behördenmeldungen absenden,
• Backups überschreiben,
• alle Schlüssel gleichzeitig rotieren, ohne Abhängigkeiten zu verstehen,
• Daten exportieren oder an externe Dienste übertragen.

EMPFEHLUNG: Incident- und Restore-Skills ausschließlich manuell auslösbar gestalten und standardmäßig nur lesende Analyse erlauben.

Sieben vollständige Projektszenarien

Szenario 1: Die schlanke Website eines Handwerksbetriebs

Ausgangslage

Ein regionaler Betrieb möchte Leistungen, Referenzen, Öffnungszeiten und Kontaktdaten zeigen. Die Seite besteht aus HTML, CSS und etwas JavaScript. Es gibt kein Login, keinen Shop, kein Tracking und keine extern eingebetteten Videos.

Risikostufe

Stufe 1 bis 2: reine Informationsseite mit einem einfachen Kontaktweg.

Sinnvolle Architektur

``text statische Dateien → deutscher oder europäischer Webhoster → HTTPS → lokal eingebundene Schriften und Bilder → kein Tag-Manager → kein Analysewerkzeug ``

Recht und Datenschutz

• Impressum nach § 5 DDG prüfen. [S009]
• Bei redaktionellen Inhalten § 18 MStV prüfen. [S010] [S011]
• Datenschutzhinweise für Hosting, Serverlogs und Kontaktwege erstellen. [S001]
• Bild- und Nutzungsrechte dokumentieren.
• Kein Cookie-Banner allein aus Vorsicht einbauen, wenn technisch keine einwilligungspflichtigen Zugriffe stattfinden. [S019] [S020] [S022]

Sicherheitsminimum

• HTTPS und automatische Zertifikatserneuerung.
• Nur benötigte Dateien veröffentlichen.
• Keine .env, Backups, Git-Verzeichnisse oder Quelldateien ausliefern.
• Sicherheitsheader prüfen.
• Hosting-Zugang mit MFA/Passkey.
• Versionsverwaltung und Offsite-Backup.

Was Claude Code gut übernehmen kann

• Seitenstruktur und responsive Darstellung.
• semantisches HTML.
• lokale Bildoptimierung.
• einfache Barrierefreiheitsprüfungen.
• Link- und Formularprüfungen.
• Deployment-Anleitung und technische Dokumentation.

Was der Mensch entscheiden muss

• Wer ist der rechtliche Anbieter?
• Welche Leistungen werden tatsächlich angeboten?
• Dürfen alle Fotos und Texte verwendet werden?
• Welche Kontaktwege werden wirklich überwacht?
• Soll überhaupt ein Formular eingebaut werden?

Typischer Fehler

Der Entwickler bindet aus Bequemlichkeit Google Fonts, YouTube und eine Kartenansicht direkt ein. Aus einer fast datenarmen Seite wird plötzlich ein Verbund mehrerer Drittanbieter mit zusätzlichen Datenflüssen und möglichen Einwilligungsfragen.

Vernünftige Lösung

Schriften lokal hosten, Karte nur verlinken oder datenschutzgerecht nachladen, Videos mit bewusster Aktivierung integrieren und jeden Fremddienst im Diensteverzeichnis dokumentieren.

Szenario 2: Lead-Website mit Kontaktformular und Newsletter

Ausgangslage

Eine Unternehmensberatung möchte Anfragen gewinnen. Besucher können ein Formular senden und einen Newsletter abonnieren. Zusätzlich sollen Kampagnen gemessen werden.

Risikostufe

Stufe 2 bis 3: aktive Datenerhebung, Marketing und Drittanbieter.

Neue Fragen

• Welche Pflichtfelder sind wirklich nötig?
• Wird die Nachricht per E-Mail übertragen oder in einer Datenbank gespeichert?
• Wer hat Zugriff?
• Wie lange bleiben Anfragen gespeichert?
• Werden Newsletter-Anmeldung und allgemeine Anfrage getrennt?
• Welche Analyse- und Werbedienste laufen?
• Werden URL-Parameter, IP-Adressen oder Gerätekennungen verarbeitet?

Recht und Datenschutz

Eine allgemeine Kontaktanfrage kann je nach Inhalt der Vertragsanbahnung oder einem berechtigten Interesse dienen. Eine pauschale Pflicht-Einwilligungscheckbox ist nicht automatisch erforderlich. [S001] [S025]

Werbliche E-Mails erfordern regelmäßig eine belastbare Einwilligung oder eine eng auszulegende gesetzliche Ausnahme. § 7 UWG und die Nachweisbarkeit der Anmeldung sind zu berücksichtigen. [S026] [S027] [S028]

Technische Architektur

``text Formular im Browser → serverseitige Validierung → Spam-Schutz → E-Mail oder CRM/API → protokollierter Versand → definierte Löschung ``

Cookie- und Trackingentscheidung

Für jede Technologie getrennt prüfen:

[S019] [S020] [S021] [S022]

Sicherheitsminimum

• serverseitige Validierung und Längenlimits,
• CSRF-Schutz,
• Rate Limits und Spam-Schutz,
• keine Formularinhalte in URL oder Fehlerlogs,
• sichere Übertragung und Mailkonfiguration,
• keine offene Weiterleitungsfunktion,
• Trennung zwischen Newsletter und Kontaktzweck.

Was Claude Code leisten kann

Claude kann eine technische Datenflusskarte erstellen, alle Skripte und Netzwerkaufrufe inventarisieren, Formulare gegen typische Fehler testen und ein Consent-System technisch so anbinden, dass optionale Dienste erst nach Freigabe laden.

Was Claude nicht entscheiden sollte

Ob eine konkrete Marketingverarbeitung auf Einwilligung, Vertrag oder berechtigtes Interesse gestützt wird, ist eine fachliche und rechtliche Entscheidung. Claude darf dafür Fakten und offene Punkte strukturieren, aber keine erfundene Freigabe aussprechen.

Szenario 3: WordPress-Unternehmensseite mit Plugins

Ausgangslage

Eine Agentur setzt WordPress ein. Die Website nutzt ein Theme, Formularplugin, SEO-Plugin, Backupplugin, Sicherheitsplugin und eventuell einen Page Builder.

Risikostufe

Stufe 2 bis 4: abhängig von Plugins, Accounts, E-Commerce und Datenflüssen.

Der Vorteil

WordPress liefert ein etabliertes Redaktionssystem, Benutzerrollen, Updatewege, Medienverwaltung und große Erweiterbarkeit. Viele Aufgaben müssen nicht neu erfunden werden.

Der Nachteil

Jedes zusätzliche Plugin erweitert Codebasis, Datenflüsse und Wartungsbedarf. Ein Sicherheitsplugin kompensiert keine veralteten oder schlecht ausgewählten Erweiterungen.

Pflichtinventar

``text Plugin/Theme → Anbieter → Version → Zweck → Daten → externe Verbindungen → Benutzerrollen → Updatequelle → Lizenz → Ersatz-/Deinstallationsplan ``

WordPress stellt offizielle Hinweise zu Hardening, HTTPS, Updates und Plugin-Sicherheit bereit. [S116] [S117] [S120] [S121]

Sicherheitsminimum

• Core, Themes und Plugins zeitnah aktualisieren.
• Nicht benötigte Erweiterungen vollständig entfernen.
• individuelle Admin-Konten statt gemeinsamer Logins.
• MFA/Passkeys, sofern unterstützt.
• Dateieditor und Schreibrechte risikobasiert begrenzen.
• XML-RPC, REST-Endpunkte und Benutzerenumeration projektbezogen prüfen.
• regelmäßige Backups und Restore-Tests.
• Staging für Updates.
• keine Entwicklung direkt auf Produktion.

Eigenes Plugin mit Claude Code

Claude kann ein Plugin-Grundgerüst erstellen, muss aber WordPress-Sicherheitsmechanismen korrekt einsetzen:

• Capability-Checks,
• Nonces gegen bestimmte CSRF-Szenarien,
• Eingabevalidierung und Sanitizing,
• kontextbezogenes Escaping bei Ausgabe,
• vorbereitete Datenbankabfragen,
• Datenschutz-Hooks, wenn das Plugin personenbezogene Daten speichert.

WordPress betont, dass Nonces keine Authentifizierung oder Autorisierung ersetzen. [S122] [S123] [S124] [S125] [S126] [S127]

Typischer Fehler

Claude erstellt eine Admin-Funktion, prüft aber nur, ob eine Nonce vorhanden ist. Jeder eingeloggte Benutzer könnte die Funktion erreichen, obwohl nur Administratoren berechtigt sein sollen.

Lösung

Nonce und Capability serverseitig prüfen; zusätzlich direkte Objektberechtigungen kontrollieren.

Szenario 4: B2C-Webshop

Ausgangslage

Ein Unternehmen verkauft Waren an Verbraucher in Deutschland. Produkte, Warenkorb, Zahlung, Versand und Kundenkonto werden online abgewickelt.

Risikostufe

Stufe 4 bis 5: Verträge, Zahlungen, personenbezogene Daten und dauerhafter Betrieb.

Rechtlich-technische Strecke

``text Produktinformation → Preis und Grundpreis → Warenkorb → Liefer- und Zahlungsdaten → Pflichtinformationen unmittelbar vor Bestellung → eindeutig beschrifteter Bestellbutton → Bestätigung → Lieferung → Widerruf/Kündigung je Vertragsart ``

§ 312j BGB, Art. 246a EGBGB, PAngV und weitere Vorschriften müssen zur konkreten Produkt- und Vertragsart passen. [S049] [S050] [S051] [S059] [S061]

Seit 19. Juni 2026 ist für erfasste Fernabsatzverträge eine elektronische Widerrufsfunktion nach § 356a BGB zu berücksichtigen. Für bestimmte Dauerschuldverhältnisse besteht bereits die Kündigungsschaltfläche nach § 312k BGB. [S056] [S058]

Zusätzliche Bereiche

• Produktsicherheitsinformationen nach GPSR bei erfassten Angeboten. [S054] [S055]
• Barrierefreiheit für erfasste Dienstleistungen im elektronischen Geschäftsverkehr nach BFSG/BFSGV; Ausnahmen und Übergänge prüfen. [S034] [S035] [S036] [S038]
• Zahlungsdienstleister, Betrugsprüfung und Webhooks.
• Steuer-, Rechnungs- und Aufbewahrungsthemen.
• Versand- und Retourenprozesse.
• Consent und Marketing.

Sicherheitsminimum

• keine Speicherung vollständiger Kartendaten, wenn ein spezialisierter Zahlungsdienst verwendet werden kann,
• signierte/verifizierte Webhooks,
• idempotente Bestellstatusverarbeitung,
• serverseitige Preisberechnung,
• Schutz vor Gutscheincode- und Mengenmanipulation,
• Rechteprüfung bei Bestellungen und Rechnungsdownloads,
• getrennte Rollen für Shopverwaltung und technische Administration,
• Monitoring für fehlgeschlagene Zahlungen und ungewöhnliche Bestellmuster.

Was Claude Code leisten kann

• Bestellprozess implementieren und testen,
• Pflichtinformationen an definierten Positionen anzeigen,
• Webhook-Signaturen prüfen,
• End-to-End-Tests für Warenkorb und Bestellung schreiben,
• Barrierefreiheitsfehler in Formularen finden,
• technische Dienste- und Dateninventare aktualisieren.

Was nicht automatisch freigegeben ist

AGB, Widerrufsinformation, Produktsicherheitsangaben, Preislogik, steuerliche Behandlung und konkrete Barrierefreiheitsausnahme müssen fachlich geprüft werden.

Szenario 5: Kundenportal mit mehreren Mandanten

Ausgangslage

Eine Agentur baut ein Portal. Jeder Unternehmenskunde sieht eigene Projekte, Rechnungen, Dokumente und Benutzer. Mitarbeiter des Betreibers können Support leisten.

Risikostufe

Stufe 5 bis 6: Login, umfangreiche Daten, Mandantentrennung und geschäftskritischer Betrieb.

Kernrisiko

Die Oberfläche zeigt zwar nur Daten des angemeldeten Kunden. Die API prüft aber nicht bei jedem Objektzugriff, ob der Datensatz wirklich zu diesem Mandanten gehört. Ändert ein Benutzer /invoice/4821 zu /invoice/4822, erhält er eine fremde Rechnung.

OWASP API Security führt fehlerhafte objektbezogene Autorisierung als zentrales API-Risiko. [S077]

Architekturregeln

• Mandantenzugehörigkeit serverseitig erzwingen.
• Nie auf versteckte Buttons oder Frontend-Filter vertrauen.
• Rollen und Objektberechtigungen getrennt modellieren.
• Supportzugriff zeitlich und protokolliert gestalten.
• Exporte, Suche und Statistiken ebenfalls mandantenfest entwickeln.
• Caches und Hintergrundjobs dürfen Daten nicht vermischen.
• Testdatensätze mit mindestens zwei Mandanten verwenden.

Testmatrix

``text Benutzer A liest Objekt A → erlaubt Benutzer A ändert Objekt A → je Rolle erlaubt/verboten Benutzer A liest Objekt B → immer verboten Benutzer A errät Objekt-ID → verboten Support greift auf A zu → nur nach Freigabe/Regel, protokolliert abgemeldeter Benutzer nutzt alte URL → verboten ``

Datenschutz und Verträge

Rollen von Betreiber, Kunden, Hoster und weiteren Dienstleistern klären. Je nach Modell kann Auftragsverarbeitung vorliegen; Verantwortlichkeiten dürfen nicht nur in einer Datenschutzerklärung behauptet werden. [S001] [S002] [S003]

Sicherheitsminimum

• MFA/Passkey für privilegierte Rollen,
• sichere Sitzungen und Reset-Verfahren,
• Rate Limits,
• zentrale Autorisierungsschicht,
• Audit-Logs für administrative Aktionen,
• verschlüsselte Übertragung und angemessener Schutz gespeicherter Daten,
• Backups mit getesteter Mandantenwiederherstellung,
• Datenschutz- und Löschkonzept.

Claude-Code-Regel

Kein Feature gilt als fertig, bevor negative Rechteprüfungen automatisiert getestet wurden. „Benutzer darf sehen“ ist nur die Hälfte. „Alle anderen dürfen nicht sehen“ ist der sicherheitsrelevante Teil.

Szenario 6: Medizinisches Termin- und Aufnahmeformular

Ausgangslage

Eine Praxis möchte Termine anfragen lassen. Der ursprüngliche Wunsch lautet: Name, E-Mail, Telefonnummer, Diagnose, Medikamente, Beschwerden und Versicherungsstatus sollen in einem normalen Webformular abgefragt und per E-Mail versendet werden.

Risikostufe

Stufe 7: besondere Kategorien personenbezogener Daten, potenzielles Berufsgeheimnis und hohe Schadensfolgen.

Erste Entscheidung

Nicht fragen: „Wie verschlüsseln wir das Formular?“

Zuerst fragen:

Müssen diese medizinischen Angaben vor dem Termin überhaupt über die öffentliche Website erhoben werden?

Datenminimierung ist häufig die stärkste Schutzmaßnahme. [S001]

Rechtliche Besonderheit

Gesundheitsdaten fallen unter Art. 9 DSGVO. Neben einer Rechtsgrundlage nach Art. 6 ist eine passende Ausnahme nach Art. 9 erforderlich. Der EuGH hat dies für Gesundheitsdaten ausdrücklich getrennt betrachtet. [S001] [S133] Zusätzlich kann § 203 StGB für Berufsgeheimnisse relevant sein. [S008]

Vernünftige Varianten

Variante A: reine Terminanfrage

``text Name Kontaktweg gewünschter Zeitraum allgemeiner Anlass ohne medizinischen Freitext ``

Variante B: spezialisiertes Portal

Nur wenn fachlich nötig, mit klarer Rechtsgrundlage, starken Zugriffsregeln, geeigneter Verschlüsselung, Protokollierung, Auftragsverarbeitung und gegebenenfalls DSFA.

Warum normale E-Mail problematisch sein kann

Medizinische Inhalte in Klartext-E-Mail können je nach Risiko und Transportweg unzureichend geschützt sein. Die DSK stellt risikobasierte Hinweise zur E-Mail-Verschlüsselung bereit. [S132]

Technische Mindestmaßnahmen bei notwendiger Verarbeitung

• ausschließlich erforderliche Felder,
• keine medizinischen Angaben in URL, Analytics oder Fehlerlogs,
• transportverschlüsselte Übertragung,
• angemessene Verschlüsselung gespeicherter Daten,
• streng begrenzte Rollen,
• MFA/Passkeys für Mitarbeitende,
• kurze Aufbewahrung oder direkte Übernahme in ein geeignetes Fachsystem,
• sichere Benachrichtigungen ohne sensible Inhalte,
• protokollierte Zugriffe,
• unabhängige Sicherheits- und Datenschutzprüfung,
• belastbarer Incident- und Restore-Prozess.

Was Claude Code nicht allein freigeben darf

• Rechtsgrundlage und Art.-9-Ausnahme,
• DSFA-Notwendigkeit,
• Berufsgeheimnis-Konzept,
• Angemessenheit der Verschlüsselung,
• Auswahl des Fachsystems,
• medizinische Aufbewahrungsregeln.

Typischer Anfängerfehler

„Wir verschlüsseln die Datenbank, dann ist alles erlaubt.“

Korrektur: Verschlüsselung ist eine Schutzmaßnahme. Sie ersetzt weder Erforderlichkeit noch Rechtsgrundlage, Transparenz, Löschkonzept und Zugriffskontrolle.

Szenario 7: KI-Chatbot, Nutzerplattform oder kleines SaaS-Produkt

Ausgangslage

Ein Anbieter baut eine Plattform mit Registrierung. Kunden können Inhalte hochladen und einen KI-Chatbot verwenden. Antworten werden aus Kundendokumenten generiert. Manche Inhalte werden öffentlich geteilt.

Risikostufe

Stufe 6 bis 7: Plattformbetrieb, Nutzerinhalte, KI, Mandanten, externe Modelle und umfangreiche Datenflüsse.

Mehrere Regelbereiche treffen zusammen

• DSGVO und TDDDG,
• Auftragsverarbeitung und Drittlandtransfers,
• DSA bei vermittelnden/Hosting-/Plattformfunktionen je Modell,
• AI Act bei KI-Systemen und konkreten Transparenzpflichten,
• Urheber- und Nutzungsrechte,
• Cybersecurity und Software-Lieferkette,
• möglicherweise BFSG bei elektronischen Dienstleistungen für Verbraucher,
• bei vermarkteter Software möglicherweise zukünftige CRA-Pflichten.

[S001] [S019] [S062] [S063] [S065] [S066] [S067] [S068] [S071] [S113] [S114]

Architekturfragen

• Wo werden Eingaben und hochgeladene Dokumente gespeichert?
• Werden sie an ein Modell außerhalb der EU übermittelt?
• Trainiert ein Anbieter mit den Daten?
• Wie werden Mandanten technisch getrennt?
• Kann ein Prompt Daten anderer Kunden abrufen?
• Welche Inhalte werden moderiert?
• Wie werden Löschung und Export umgesetzt?
• Werden Antworten als KI-Interaktion erkennbar gemacht?
• Kann der Bot Entscheidungen mit erheblicher Wirkung treffen?

AI-Act-Transparenz

Art. 50 enthält spezifische Pflichten, etwa zur Information natürlicher Personen bei direkter Interaktion mit bestimmten KI-Systemen sowie Kennzeichnungspflichten für bestimmte synthetische Inhalte. Daraus folgt keine pauschale Pflicht, jede mit KI erstellte Website oder jeden KI-unterstützt formulierten Absatz zu kennzeichnen. Die konkrete Funktion und Inhaltsart sind entscheidend. [S065] [S066] [S067] [S068] [S069] [S070]

Prompt-Injection und Dokumente

Hochgeladene Dokumente können manipulierte Anweisungen enthalten. Ein KI-Agent darf daraus nicht ungeprüft Befehle ableiten, Secrets lesen oder Aktionen in anderen Systemen durchführen. Die OWASP GenAI LLM Top 10 2026 und das OWASP MCP Top 10 behandeln solche GenAI-, Tool- und Berechtigungsrisiken als eigene, schnelllebige Sicherheitsfelder. [S141] [S142]

EMPFEHLUNG:

• Inhalte als Daten, nicht als vertrauenswürdige Systemanweisung behandeln,
• Toolrechte minimal halten,
• Aktionen mit Außenwirkung bestätigen lassen,
• Mandantenkontext technisch binden,
• Ausgaben filtern und protokollieren,
• Geheimnisse niemals in Promptvorlagen einbetten,
• Red-Team-Tests mit indirekten Prompt-Injections durchführen.

Plattformfunktionen

Wenn Nutzer öffentlich Inhalte einstellen oder verkaufen können, sind Meldewege, Moderation, Beschwerdeprozesse, Sperrungen und rechtliche Rollen zu prüfen. Der DSA enthält abgestufte Pflichten je Dienstetyp. [S062] [S063] [S064] [S135]

Was Claude Code gut kann

• Datenfluss und Rollenmodell dokumentieren,
• Mandantentests erzeugen,
• Upload- und API-Grenzen implementieren,
• technische Transparenzhinweise an definierten Stellen einbauen,
• Audit-Logs und Löschjobs erstellen,
• Bedrohungsmodelle und Missbrauchstests vorbereiten.

Was der Betreiber festlegen muss

• zulässige Nutzung,
• Rechtsrollen und Verträge,
• Modell- und Hostinganbieter,
• Moderationsregeln,
• Aufbewahrung und Training,
• Hochrisiko- oder sensible Anwendungsgrenzen,
• menschliche Eskalation,
• Incident-Kommunikation.

Go-live-Audit und Entscheidungsampel

Der Go-live ist eine bewusste Freigabe

Eine Website sollte nicht live gehen, nur weil der Entwickler keine offenen Tickets mehr sieht. Die Freigabe verbindet fachliche, rechtliche, technische und betriebliche Entscheidungen.

EMPFEHLUNG: Eine namentlich benannte Person gibt den Go-live frei. Die Agentur dokumentiert, was geprüft wurde, welche Annahmen gelten und welche offenen Punkte ausdrücklich akzeptiert wurden.

Die Ampel

Rot – nicht veröffentlichen

Mindestens einer dieser Punkte blockiert den Go-live:

• Zugangsdaten, private Schlüssel oder .env öffentlich erreichbar.
• Test- oder Kundendaten sind ungeschützt veröffentlicht.
• Fremde Mandantendaten können abgerufen werden.
• Login ohne funktionierende Rechteprüfung.
• bekannte kritische Schwachstelle in produktiver Abhängigkeit.
• kein HTTPS für Login, Formular, Shop oder andere personenbezogene Verarbeitung.
• produktive Backups fehlen vollständig.
• Impressum fehlt bei bestehender Pflicht.
• Shop-Button oder Pflichtinformationen sind offensichtlich unvollständig.
• notwendige Einwilligungssteuerung lädt Dienste bereits vorher.
• wesentliche Barrieren verhindern bei erfasstem E-Commerce die Nutzung.
• medizinische oder andere hochsensible Daten werden ohne geklärtes Schutz- und Rechtskonzept erhoben.
• Verantwortlicher, Domaininhaber oder produktive Zugänge sind ungeklärt.

Gelb – nur mit dokumentierter Entscheidung

• Restfehler ohne unmittelbares hohes Risiko.
• einzelne Inhalte oder Alt-Texte noch nicht vollständig.
• Performance-Ziel knapp verfehlt.
• neue, nicht sicherheitskritische Funktion wird nach Go-live ergänzt.
• rechtliche Einzelfrage wurde als begrenztes Risiko akzeptiert und terminierter Prüfung zugeführt.
• Restore-Test liegt zurück, Backup ist jedoch vorhanden und überwacht.

Grün – freigabefähig

• Kernprozesse funktionieren,
• rechtliche Basisangaben sind geprüft,
• Datenflüsse und Dienste sind dokumentiert,
• Sicherheitsbaseline ist erfüllt,
• Barrierefreiheit wurde passend zum Scope geprüft,
• Backups und Restore sind vorbereitet,
• Verantwortlichkeiten und Übergabe sind geklärt,
• keine roten Punkte offen.

Auditblock A: Eigentum und Zugänge

``text [ ] Domaininhaber ist der richtige Rechtsträger [ ] Registrarzugang liegt beim Betreiber oder ist vertraglich abgesichert [ ] Hostingvertrag und Abrechnung sind geklärt [ ] produktive Admin-Konten sind personenbezogen [ ] MFA/Passkey für kritische Zugänge aktiv [ ] Agenturzugänge sind getrennt und widerrufbar [ ] Recovery-Codes sicher hinterlegt [ ] DNS-Zone und wichtige Einträge dokumentiert [ ] Quellcode-Repository und Rechte geklärt [ ] Lizenz- und Nutzungsrechte dokumentiert ``

Auditblock B: Rechtliche Anbieterinformationen

``text [ ] Impressum nach aktuellem Rechtsträger geprüft [ ] § 18 MStV geprüft [ ] berufsrechtliche Sonderangaben geprüft [ ] Datenschutzhinweise entsprechen realen Datenflüssen [ ] Pflichtinformationen sind dauerhaft erreichbar [ ] veralteter ODR-Link entfernt [ ] automatisierte E-Mails enthalten korrekte Absender-/Unternehmensangaben [ ] AGB/Widerruf/Preis-/Produktinformationen fachlich freigegeben, falls relevant [ ] Rechtsdokumente nicht blind aus KI-Ausgabe übernommen ``

Auditblock C: Datenschutz und Dienste

``text [ ] Dateninventar aktuell [ ] Diensteregister aktuell [ ] Zwecke und Rechtsgrundlagen zugeordnet [ ] Auftragsverarbeiter und Unterauftragnehmer geprüft [ ] Drittlandtransfers und Transferinstrumente geprüft [ ] Pflichtfelder minimiert [ ] Lösch- und Aufbewahrungsregeln definiert [ ] Betroffenenrechte technisch unterstützbar [ ] Gesundheits-/Spezialdaten gesondert bewertet [ ] DSFA-Prüfung dokumentiert [ ] keine sensiblen Daten in URLs, Analytics oder Logs ``

Auditblock D: Cookies und Browsertechnologien

``text [ ] alle Cookies, Speicherzugriffe, Fingerprinting- und Trackingmechanismen inventarisiert [ ] technische Notwendigkeit je Vorgang bewertet [ ] optionale Dienste laden erst nach wirksamer Auswahl [ ] Ablehnen ist leicht erreichbar [ ] Einwilligung ist granular und widerrufbar [ ] Banner und Datenschutzhinweise stimmen technisch überein [ ] Änderung eines Dienstes löst erneute Prüfung aus [ ] Consent-Protokollierung enthält nur Erforderliches [ ] Seite funktioniert ohne Marketingeinwilligung in ihren Kernfunktionen ``

Auditblock E: Anwendungssicherheit

``text [ ] keine Secrets im Repository oder Webroot [ ] Abhängigkeiten und Versionen inventarisiert [ ] bekannte kritische Schwachstellen bewertet [ ] Eingaben serverseitig validiert [ ] Ausgaben kontextgerecht escaped [ ] Datenbankzugriffe parametrisiert [ ] Uploads nach Typ, Größe, Name und Inhalt begrenzt [ ] Rechte bei jedem geschützten Objekt geprüft [ ] Session- und Reset-Prozess getestet [ ] Rate Limits für kritische Endpunkte [ ] CSRF-, XSS- und Clickjacking-Schutz passend umgesetzt [ ] Sicherheitsheader und TLS geprüft [ ] Fehlermeldungen geben keine Interna preis [ ] Admin- und Debugfunktionen in Produktion deaktiviert [ ] automatische und manuelle Sicherheitstests dokumentiert ``

OWASP Top 10 und ASVS eignen sich als Struktur, ersetzen aber keinen risikogerechten Test. [S075] [S076]

Auditblock F: Shop und Kundenkonto

``text [ ] Preise werden serverseitig berechnet [ ] Bestellbutton entspricht § 312j BGB [ ] Pflichtinformationen stehen am richtigen Ort [ ] Widerrufsfunktion nach § 356a BGB geprüft [ ] Kündigungsschaltfläche nach § 312k BGB geprüft [ ] Bestellbestätigung reproduziert den Vertrag [ ] Webhooks werden authentifiziert und idempotent verarbeitet [ ] Rechnungen sind nur für Berechtigte erreichbar [ ] Konto- und Gastbestellung fachlich entschieden [ ] Produktsicherheitsinformationen geprüft [ ] Rückgabe-, Support- und Fehlerprozesse getestet ``

[S049] [S050] [S054] [S055] [S056] [S058]

Auditblock G: Barrierefreiheit

``text [ ] Tastaturbedienung der Kernprozesse [ ] sichtbarer Fokus [ ] semantische Überschriftenstruktur [ ] Formularlabels und verständliche Fehlerhinweise [ ] Kontrast und Vergrößerung [ ] Alternativtexte für informative Bilder [ ] dekorative Bilder korrekt behandelt [ ] Dialoge, Menüs und Statusmeldungen zugänglich [ ] Checkout/Login/Kündigung/Widerruf vollständig prüfbar [ ] automatisierte Tests durch manuelle Prüfung ergänzt [ ] BFSG/BGG/BITV-Scope und Erklärungspflichten geprüft [ ] Overlay nicht als Ersatz für Quellcode-Reparatur eingesetzt ``

[S034] [S036] [S041] [S043] [S044] [S045] [S048]

Auditblock H: Betrieb

``text [ ] Monitoring für Erreichbarkeit und Kernfunktion [ ] Fehleralarme erreichen eine verantwortliche Person [ ] Logs enthalten keine unnötigen Secrets oder sensiblen Inhalte [ ] Backup umfasst Code, Datenbank, Uploads und Konfiguration [ ] Offsite- oder administrativ getrennte Kopie vorhanden [ ] Restore-Anleitung aktuell [ ] Restore-Test durchgeführt und dokumentiert [ ] Rollback für Releases vorbereitet [ ] Update- und Patchprozess definiert [ ] Incident-Kontakte und 72-Stunden-Bewertung bekannt [ ] Dienstleister-Eskalation dokumentiert ``

Testkonten und Testdaten

EMPFEHLUNG: Produktive Prüfung nur mit künstlichen oder ausdrücklich freigegebenen Testdaten. Keine echten Patientendaten, Ausweiskopien oder Kundendokumente in Entwicklungs- und Screenshotsysteme kopieren.

Mindestens folgende Konten anlegen:

• nicht angemeldet,
• normaler Benutzer,
• zweiter Mandant,
• Supportrolle,
• Administrator,
• gesperrtes oder gelöschtes Konto.

Damit können positive und negative Rechtefälle getestet werden.

Die ersten 24 Stunden

Nach dem Go-live:

• Erreichbarkeit und Zertifikat prüfen.
• zentrale Formulare selbst absenden.
• Bestell-/Login-/Reset-Prozess kontrollieren.
• Fehlerlogs auf neue Ausnahmen prüfen.
• externe Dienste und Einwilligungsstatus kontrollieren.
• keine Testkonten oder Debugdaten offenlassen.
• Suchmaschinensteuerung und Canonicals prüfen.
• Monitoring und Backup-Lauf bestätigen.

Die ersten sieben Tage

• Fehlermuster und Abbrüche auswerten.
• Supportmeldungen sammeln.
• Bot-, Spam- und Angriffslast beobachten.
• Performance unter realer Nutzung prüfen.
• Consent- und Trackingkonfiguration gegen tatsächliche Netzwerkaufrufe kontrollieren.
• Rechte- und Mandantentests nach ersten Änderungen erneut ausführen.
• offene gelbe Punkte schließen.

Nach 30 Tagen

• Diensteregister aktualisieren.
• Abhängigkeiten und Updates prüfen.
• Backup-Wiederherstellung oder Teilrestore testen.
• Barrierefreiheitsfeedback auswerten.
• Löschjobs und Aufbewahrungsfristen prüfen.
• Agentur- und temporäre Zugänge bereinigen.
• dokumentieren, welche Annahmen sich geändert haben.

Änderungen, die ein neues Audit auslösen

Nicht jede Textänderung braucht eine vollständige Neufreigabe. Folgende Änderungen sind jedoch risikorelevant:

• neues Formular oder neues Pflichtfeld,
• neues Tracking-, Chat-, Karten-, Video- oder Captcha-System,
• neue API oder neuer Zahlungsdienst,
• Login, Rollen oder Kundenkonto,
• Uploadfunktion,
• neue Produkt- oder Vertragsart,
• neue Länder oder Zielgruppen,
• Gesundheits- oder andere sensible Daten,
• KI-Chatbot oder automatisierte Entscheidung,
• neues WordPress-Plugin/Theme,
• Hoster- oder Datenbankwechsel,
• größere Framework- oder Versionsmigration,
• Plattform- oder Nutzerinhalte,
• neue Subunternehmer oder Drittlandübermittlungen.

Freigabeprotokoll

VORLAGE:

```text Projekt: Version/Commit: Zielumgebung: Freigabedatum:

Fachliche Freigabe durch: Technische Freigabe durch: Datenschutzprüfung durch: Rechtliche Prüfung, soweit erfolgt, durch: Barrierefreiheitsprüfung durch:

Rote Punkte: keine / siehe Anlage Gelbe Punkte: Akzeptierte Restrisiken: Fristen und Verantwortliche:

Backup-Stand: letzter Restore-Test: Rollback-Verfahren: Incident-Kontakt:

Unterschrift/elektronische Bestätigung: ```

Das Protokoll beweist nicht automatisch Rechtskonformität oder Sicherheit. Es schafft aber Verantwortlichkeit und verhindert, dass ein Projekt „irgendwie live“ geht.

Promptbibliothek für Claude Code

Wozu diese Prompts dienen

Die folgenden Texte sind VORLAGEN. Sie stammen nicht als verbindliche Vorgabe von Anthropic, einer Behörde oder einem Gesetzgeber. Sie übersetzen die Anforderungen dieses Dossiers in wiederverwendbare Arbeitsaufträge für Claude Code.

Ein guter Audit-Prompt soll nicht behaupten, eine Website sei „DSGVO-konform“ oder „hackerfest“. Er soll:

• den tatsächlichen Projektbestand untersuchen,
• Fakten und Annahmen trennen,
• Fundstellen in Dateien nennen,
• Risiken priorisieren,
• fehlende Informationen offen ausweisen,
• keine produktiven Änderungen ohne Freigabe durchführen,
• konkrete Prüf- und Korrekturschritte vorschlagen.

EMPFEHLUNG: Jeder Prompt beginnt mit einer klaren Rolle und endet mit einem überprüfbaren Ausgabeformat. Bei rechtlichen Themen soll Claude technische Tatsachen ermitteln und offene Rechtsfragen markieren, nicht eigenmächtig Rechtsfreigaben erteilen.

Masterprompt: Projekt zuerst verstehen

```text Du arbeitest als technischer Projektanalyst für eine Website in Deutschland.

Projektidee: [HIER BESCHREIBEN]

Implementiere noch nichts. Führe zuerst eine strukturierte Projektdefinition durch.

Ziele:

1. Verstehe den Geschäftszweck und die Zielgruppen.
2. Ermittle alle geplanten Funktionen.
3. Erfasse alle Daten, die eingegeben, erzeugt, übertragen, gespeichert oder veröffentlicht werden.
4. Erfasse externe Dienste, Plugins, APIs, Hosting, E-Mail, Analyse, Werbung, Karten, Videos, Captcha, Zahlungsdienste und KI-Anbieter.
5. Bestimme eine vorläufige Risikostufe von 1 bis 7 nach diesem Schema:

1 = rein statische Information, 2 = Kontakt/Leads, 3 = Tracking/Marketing/mehrere Drittanbieter, 4 = Shop/Verträge/Zahlung, 5 = Login/Kundenkonto, 6 = Plattform/Mandanten/KI, 7 = besondere Kategorien personenbezogener Daten oder sehr hohe Schadensfolgen.

1. Ermittle offene Entscheidungen zu Datenschutz, Sicherheit, Barrierefreiheit, Shoprecht, AI Act, Betrieb, Backup und Verantwortlichkeiten.
2. Schlage erst danach eine möglichst einfache Architektur vor.

Arbeitsregeln:

• Keine Tatsachen erfinden.
• FAKT, ANNAHME, EMPFEHLUNG und UNKLAR deutlich trennen.
• Keine pauschale Aussage wie „DSGVO-konform“, „rechtssicher“ oder „vollständig barrierefrei“.
• Keine Zugangsdaten anfordern oder in Dokumente schreiben.
• Keine Produktion verändern.
• Jede technische Feststellung mit Datei, Konfiguration oder beobachtetem Verhalten belegen.
• Frage nur nach Informationen, die eine technische oder fachliche Entscheidung verändern.

Erzeuge anschließend:

• WEBSITE-SPEC.md
• DATA-INVENTORY.md
• SERVICE-REGISTER.md
• RISK-REGISTER.md
• DECISIONS.md
• eine Liste der Go-live-Blocker
• einen Umsetzungsplan in kleinen, testbaren Schritten.

```

Dateninventar-Prompt

```text Analysiere dieses Website-Projekt und erstelle ein vollständiges technisches Dateninventar.

Untersuche:

• Formulare und Eingabefelder,
• URL-Parameter,
• Cookies, Local Storage, Session Storage, IndexedDB und andere Endgerätezugriffe,
• Serverlogs und Fehlerlogs,
• Datenbanktabellen und Dateien,
• Benutzerkonten, Rollen und Sitzungen,
• E-Mails, Benachrichtigungen und Exporte,
• externe APIs und Webhooks,
• Analyse-, Marketing-, Karten-, Video-, Schrift-, Captcha-, Zahlungs- und KI-Dienste,
• Backups, Staging, Testsysteme und Supportzugänge.

Erstelle für jeden Datenfluss eine Tabellenzeile mit: ID, Quelle, betroffene Personen, Datenkategorien, Zweck, Empfänger, Speicherort, Übertragungsziel, Aufbewahrung, Löschung, Schutzmaßnahmen, Fundstelle, offene Frage.

Besondere Regeln:

• Markiere Gesundheitsdaten, biometrische Daten, politische/religiöse Angaben, Gewerkschaftsdaten, Sexualleben/-orientierung und andere besondere Kategorien deutlich.
• Markiere Secrets, Tokens, Passwörter und Session-IDs gesondert.
• Nenne keine Rechtsgrundlage als sicher, wenn sie nicht fachlich festgelegt wurde. Schreibe dann UNKLAR.
• Prüfe, ob Daten in URLs, Browserhistorie, Analytics oder Logs landen können.
• Prüfe Entwicklungs-, Test- und Backupkopien mit.
• Verändere keine Dateien.

Ausgabe:

1. Kurzfazit.
2. vollständige Tabelle.
3. unbekannte Datenflüsse.
4. rote Risiken.
5. konkrete nächste Prüfungen.

```

Prompt zur technischen Impressumsprüfung

```text Führe keine individuelle Rechtsberatung durch und erfinde keine Pflichtangaben. Prüfe ausschließlich die technische und inhaltliche Konsistenz der vorhandenen Anbieterkennzeichnung.

Aufgaben:

• Finde alle Impressumsseiten, Footerangaben, strukturierten Unternehmensdaten und Angaben in automatisierten E-Mails.
• Vergleiche Name, Rechtsform, Anschrift, Vertretungsberechtigte, Register, Registernummer, E-Mail und weitere vorhandene Angaben.
• Prüfe, ob das Impressum von jeder öffentlichen Seite leicht erreichbar ist, auch mobil.
• Prüfe tote Links, Weiterleitungen und widersprüchliche Angaben.
• Markiere mögliche Prüfbereiche nach § 5 DDG und § 18 MStV, ohne eine rechtliche Vollständigkeit zu behaupten.
• Markiere berufsrechtliche oder aufsichtsrechtliche Sonderfragen als UNKLAR.
• Prüfe, ob veraltete Hinweise auf die frühere EU-ODR-Plattform vorhanden sind.

Ausgabeformat:

• FAKTISCHE FUNDSTELLEN mit Datei/URL.
• WIDERSPRÜCHE.
• FEHLENDE EINGABEN, die der Betreiber prüfen muss.
• TECHNISCHE FEHLER.
• keine automatische Änderung ohne Freigabe.

```

Datenschutz- und Dienste-Audit

```text Prüfe die Website technisch darauf, ob Datenschutzhinweise und tatsächliche Datenverarbeitung zusammenpassen.

Schritte:

1. Inventarisiere alle Datenquellen und externen Dienste.
2. Suche die Datenschutzerklärung und ordne vorhandene Abschnitte den realen Diensten zu.
3. Markiere:

• Dienst technisch vorhanden, aber nicht beschrieben,
• Dienst beschrieben, aber technisch nicht gefunden,
• Anbieter/Empfänger widersprüchlich,
• Speicher- oder Löschangabe nicht technisch nachvollziehbar,
• Drittlandübermittlung oder Subdienst unklar,
• Formularzweck und Folgeverwendung unklar,
• Gesundheits- oder andere besonders sensible Daten.

1. Prüfe, ob personenbezogene Daten in Logs, URLs, Fehlermeldungen oder clientseitigem Code erscheinen.
2. Prüfe, ob Test-, Staging- und Backup-Systeme einbezogen wurden.

Regeln:

• Gib keine pauschale DSGVO-Freigabe.
• Rechtsgrundlagen nur als „vom Verantwortlichen zu prüfen“ ausgeben, sofern nicht verbindlich dokumentiert.
• Keine erfundenen Aufbewahrungsfristen.
• Keine Daten oder Prompts an zusätzliche externe Dienste senden.
• Verändere nichts.

Ausgabe: A. Management-Fazit in zehn Sätzen. B. Fundstellenmatrix. C. Rote, gelbe und grüne Punkte. D. Fragen für Betreiber/Datenschutz/Fachbereich. E. technische Korrekturempfehlungen. ```

Cookie- und Browser-Speicher-Audit

```text Untersuche die Website im Browser und im Quellcode auf Zugriffe auf Endeinrichtungen und Tracking.

Prüfe vor einer Auswahl, nach „Ablehnen“, nach „Alle akzeptieren“ und nach einer individuellen Auswahl.

Erfasse:

• Cookies mit Name, Domain, Pfad, Laufzeit, SameSite, Secure, HttpOnly,
• Local Storage, Session Storage, IndexedDB und Service Worker,
• Pixel, Beacons, Fingerprinting- oder Gerätekennungen,
• nachgeladene Skripte, Frames und Netzwerkziele,
• Tag-Manager und dynamisch geladene Tags,
• Einwilligungsstatus und Widerruf,
• Dienste, die bereits vor einer Einwilligung senden,
• Kernfunktionen, die ohne Marketingeinwilligung blockiert sind.

Bewerte technische Notwendigkeit nicht pauschal. Begründe sie anhand der vom Nutzer ausdrücklich angeforderten Funktion. Markiere rechtliche Einordnung als zu prüfen.

Ausgabe:

1. vollständige technische Liste,
2. Verhalten je Consent-Zustand,
3. mögliche Verstöße gegen die eigene Konfiguration,
4. Dark-Pattern- und UX-Hinweise,
5. reproduzierbare Testschritte,
6. keine automatische Änderung.

```

OWASP-Websecurity-Review

```text Führe ein defensives Sicherheitsreview des Projekts durch. Grundlage sind die für das Projekt relevanten Kategorien der OWASP Top 10:2025 und passende ASVS-Prüfpunkte.

Scope: [ORDNER/ANWENDUNG]

Prüfe mindestens:

• Zugriffskontrolle,
• sicherheitsrelevante Fehlkonfiguration,
• Software-Lieferkette und Abhängigkeiten,
• kryptografische Fehler,
• Injection,
• unsicheres Design,
• Authentisierung,
• Integrität von Code und Daten,
• Logging/Alerting,
• Fehlerbehandlung.

Arbeitsweise:

• Beginne nur lesend.
• Für jedes Finding: Titel, Schweregrad, CWE/OWASP-Bezug, Fundstelle, Angriffsvoraussetzung, mögliche Wirkung, Reproduktionsschritte in sicherer Testumgebung, konkrete Abhilfe, Test nach Behebung.
• Keine produktiven Exploits, keine Datenexfiltration, keine destruktiven Befehle.
• Keine Schwachstelle behaupten, die nicht reproduzierbar belegt ist. Sonst „Verdacht“.
• Geheimnisse in Ausgaben maskieren.
• Drittanbieterpakete nur über offizielle Advisories/CVE-Quellen bewerten.

Erzeuge:

• SECURITY-REPORT.md,
• priorisierte Remediation-Liste,
• vorgeschlagene automatisierte Regressionstests,
• Liste nicht geprüfter Bereiche.

```

Login-, Session- und Mandanten-Audit

```text Prüfe Registrierung, Anmeldung, MFA/Passkey, Session, Logout, Passwort-/Kontowiederherstellung, Rollen und Mandantentrennung.

Erstelle zunächst eine Rollen- und Objektmatrix. Nutze mindestens zwei getrennte Mandanten und mehrere Rollen mit ausschließlich künstlichen Testdaten.

Teste:

• Zugriff ohne Anmeldung,
• Zugriff mit normalem Benutzer,
• Zugriff auf fremde Objekt-IDs,
• Änderung von URL-/API-IDs,
• Such-, Export-, Download- und Statistikfunktionen,
• direkte API-Aufrufe unabhängig vom Frontend,
• Sitzungsablauf und Logout,
• Session-Fixation und Cookieattribute,
• Reset-Tokens, Ablauf, Einmaligkeit und Nutzerenumeration,
• Sperr-/Rate-Limit-Verhalten,
• Support- und Administratorzugriffe,
• gelöschte/gesperrte Konten,
• Hintergrundjobs und Caches.

Regeln:

• Keine echten Nutzerkonten übernehmen.
• Keine produktiven Daten verändern.
• Jede erlaubte Aktion benötigt einen passenden negativen Test.
• Frontend-Verstecken gilt nie als Autorisierung.

Ausgabe:

• Rechte-Matrix,
• Testprotokoll,
• Findings mit Fundstellen,
• fehlende Tests,
• vorgeschlagene Korrekturen.

```

Datei-Upload-Audit

```text Prüfe alle Datei-Upload- und Importfunktionen defensiv.

Untersuche:

• erlaubte Dateitypen und MIME-Prüfung,
• Dateiendungen und Mehrfachendungen,
• Größen-, Mengen- und Zeitlimits,
• Dateinamen und Pfadbehandlung,
• Speicherung außerhalb des ausführbaren Webroots,
• zufällige serverseitige Namen,
• Zugriffskontrolle bei Download und Vorschau,
• Bild-/Dokumentenverarbeitung,
• Archive und Dekompressionsbomben,
• Malware- oder Inhaltsprüfung,
• Metadaten,
• öffentliche URLs und Suchmaschinenindexierung,
• Löschung und Backups,
• Fehlermeldungen und Logs.

Führe keine schädlichen Payloads gegen Produktion aus. Verwende nur sichere Testdateien in einer isolierten Umgebung.

Ausgabe:

• Uploadpfade,
• Risiken,
• sichere Zielarchitektur,
• Testfälle,
• notwendige manuelle Sicherheitsprüfung.

```

WordPress-Audit

```text Analysiere diese WordPress-Installation nur lesend.

Erfasse:

• WordPress-Version,
• PHP- und Datenbankversion,
• aktive und inaktive Plugins,
• Themes und Child Themes,
• Benutzer/Rollen ohne personenbezogene Details auszugeben,
• Updatezustand und Herkunft der Pakete,
• Cronjobs, REST-Endpunkte, XML-RPC, Datei- und Verzeichnisrechte,
• wp-config.php und Secrets nur auf Fehlplatzierung prüfen, Werte maskieren,
• Debugmodus, Fehleranzeige und Logging,
• Backups, Staging und Wiederherstellungsweg,
• externe Dienste und Datenverarbeitung.

Für eigene Plugins/Themes prüfe:

• Capability-Checks,
• Nonces,
• Sanitizing,
• Escaping,
• vorbereitete Datenbankabfragen,
• direkte Dateizugriffe,
• REST-Berechtigungsrückrufe,
• Datenschutz-Export/-Löschung, soweit erforderlich.

Regeln:

• Kein blindes Auto-Update.
• Keine Deinstallation.
• Keine Sicherheitsplugin-Werbung.
• Bekannte Schwachstellen nur mit offizieller oder belastbarer Quelle und betroffener Version nennen.

Ausgabe:

• Inventar,
• kritische Findings,
• Wartungsrückstand,
• empfohlene Testreihenfolge auf Staging,
• Abhängigkeiten, die ersetzt werden sollten.

```

Barrierefreiheits-Audit

```text Prüfe die Website anhand der für das Projekt relevanten WCAG-2.2-Anforderungen und der tatsächlichen Nutzerwege.

Automatisierte Werkzeuge sind nur der Anfang. Führe zusätzlich manuelle Prüfungen durch:

• vollständige Tastaturbedienung,
• sichtbarer Fokus,
• logische Fokusreihenfolge,
• Zoom und Reflow,
• Screenreader-orientierte Semantik,
• Überschriften und Regionen,
• Namen, Rollen und Zustände interaktiver Elemente,
• Formulare, Labels, Pflichtfelder und Fehlermeldungen,
• Kontrast,
• Alternativtexte,
• Dialoge, Menüs und Statusmeldungen,
• Zeitlimits,
• Checkout, Login, Kündigung und Widerruf,
• mobile Bedienung.

Klassifiziere jedes Finding mit: WCAG-Kriterium, Level, Seite/Komponente, Reproduktionsschritt, Auswirkung, Codefundstelle, Korrektur, Retest.

Regeln:

• Behaupte nicht „vollständig barrierefrei“ allein aufgrund eines Scanners.
• Ein Overlay gilt nicht als Ersatz für Quellcodekorrekturen.
• BFSG/BGG/BITV-Anwendbarkeit als fachlich zu prüfenden Scope ausgeben.

Erzeuge ACCESSIBILITY-REPORT.md und eine priorisierte Maßnahmenliste. ```

Shop- und Verbraucherprozess-Audit

```text Prüfe den vollständigen B2C-Kaufprozess technisch und inhaltlich. Führe keine rechtliche Freigabe durch.

Teste:

• Produktdetail und wesentliche Eigenschaften,
• Gesamt- und Grundpreise,
• Versandkosten und Lieferinformationen,
• Warenkorbmanipulation,
• serverseitige Preisberechnung,
• Gutscheine und Mengen,
• Bestellzusammenfassung,
• Beschriftung und Position des Bestellbuttons,
• Bestellbestätigung und reproduzierbaren Vertragsstand,
• Zahlungswebhooks und Mehrfachzustellung,
• Rechnung/Downloadberechtigung,
• Widerrufsfunktion nach dem dokumentierten Scope,
• Kündigungsschaltfläche bei entsprechenden Dauerschuldverhältnissen,
• Produktsicherheitsinformationen,
• Barrierefreiheit der gesamten Strecke.

Erzeuge:

• Prozessdiagramm,
• Fundstellen der Pflichtinformationen,
• technische Fehler,
• fachlich/rechtlich offene Punkte,
• End-to-End-Testfälle,
• rote Go-live-Blocker.

```

AI-Act- und KI-Funktionsaudit

```text Analysiere alle KI-Funktionen dieser Website oder Plattform.

Erfasse je Funktion:

• Anbieter und Modell,
• Zweck,
• Eingaben und Ausgaben,
• betroffene Personen,
• gespeicherte Prompts/Antworten,
• Training oder Weiterverwendung,
• Tool- und Systemzugriffe,
• menschliche Kontrolle,
• mögliche Wirkung auf Personen,
• Kennzeichnung und Nutzerinformation,
• Fehlermodi, Halluzination und Prompt Injection.

Prüfe als offene Rechtsfragen insbesondere:

• direkte Interaktion eines Menschen mit einem KI-System,
• synthetische Audio-, Bild-, Video- oder Textinhalte,
• Deepfake-Konstellationen,
• Text zur Information der Öffentlichkeit über Angelegenheiten von öffentlichem Interesse,
• mögliche Hochrisiko- oder verbotene Nutzung,
• AI-Literacy und Verantwortlichkeiten.

Regeln:

• Keine pauschale Kennzeichnungspflicht für die gesamte Website erfinden.
• Stand der Art.-50-Leitlinien und des Kennzeichnungskodex mit Datum nennen.
• Technische Fakten und rechtliche Einordnung trennen.
• Keine echten Kundendaten an zusätzliche Modelle senden.

Ausgabe:

• KI-Inventar,
• Transparenzmatrix,
• Datenschutz-/Sicherheitsfragen,
• technische Schutzmaßnahmen,
• Themen für fachliche Rechtsprüfung.

```

Pre-Launch-Masteraudit

```text Führe vor dem Go-live ein zusammengeführtes Audit durch. Arbeite zunächst ausschließlich lesend.

Prüfbereiche:

1. Projekt- und Eigentumsverhältnisse.
2. Impressum und technische Erreichbarkeit der Pflichtinformationen.
3. Dateninventar, Datenschutzhinweise und externe Dienste.
4. Cookies und Browser-Speicher in allen Consent-Zuständen.
5. OWASP-/ASVS-orientierte Sicherheitsbaseline.
6. Login, Rollen, Mandanten und Uploads.
7. WordPress oder individuelle Architektur.
8. Shop-, Widerrufs-, Kündigungs- und Produktsicherheitsfunktionen.
9. Barrierefreiheit der Kernwege.
10. KI-Funktionen und Transparenz.
11. Backup, Restore, Monitoring, Logging und Incident-Prozess.
12. Übergabe, Zugänge und Wartung.

Ausgabe:

• ROT: Go-live blockieren.
• GELB: nur mit dokumentierter Risikoentscheidung.
• GRÜN: geprüft und ohne gefundenen Blocker.
• UNGEPRÜFT: außerhalb des Scopes oder technisch nicht zugänglich.

Für jeden Punkt Fundstelle, Test, Ergebnis und Verantwortlichen nennen. Niemals aus dem Fehlen eines Findings auf vollständige Rechtskonformität oder Sicherheit schließen. Keine produktiven Änderungen oder Deployments durchführen. ```

Incident-Assistent

```text Du unterstützt ein menschliches Incident-Team. Du triffst keine rechtlichen Entscheidungen und führst keine destruktiven Aktionen ohne ausdrückliche Freigabe aus.

Vorfall: [BEOBACHTUNG]

Ziele:

• Fakten, Zeitpunkte und Annahmen trennen.
• betroffene Systeme und Daten eingrenzen.
• Beweissicherung vor Bereinigung priorisieren.
• sichere Eindämmungsoptionen vorschlagen.
• mögliche Datenschutzverletzung für fachliche Bewertung markieren.
• Restore- und Kommunikationsabhängigkeiten aufzeigen.

Arbeitsregeln:

• Secrets maskieren.
• keine Logs an externe Dienste übertragen.
• keine Systeme löschen, neu installieren oder Backups überschreiben.
• keine Meldung an Behörden oder Betroffene absenden.
• jede vorgeschlagene Aktion mit möglichem Nebeneffekt beschreiben.

Ausgabe:

1. bestätigte Fakten,
2. offene Hypothesen,
3. Sofortmaßnahmen,
4. zu sichernde Beweise,
5. betroffene Daten/Systeme,
6. 72-Stunden-Prüfpunkt,
7. Wiederherstellungsplan,
8. Kommunikationsentwurf als nicht freigegebene Vorlage,
9. Nachbereitung.

```

Übergabe-Prompt

```text Erstelle eine vollständige technische Projektübergabe für den Betreiber.

Dokumentiere:

• Architektur und Dienste,
• Repository, Branch- und Releaseprozess,
• Domain, DNS und Hosting ohne Secrets offenzulegen,
• Benutzerrollen und Administrationswege,
• Umgebungsvariablen als Namen, nicht als Werte,
• Deployment, Rollback, Backup und Restore,
• Monitoring, Logs und Incident-Kontakte,
• Abhängigkeiten, Lizenzen und Updateprozess,
• Dateninventar und externe Dienste,
• offene Risiken und Fristen,
• Tests und letzter geprüfter Stand,
• Entfernen/Übertragen von Agenturzugängen.

Erzeuge: HANDOVER.md, OPERATIONS.md, BACKUP-RESTORE.md, ACCESS-REGISTER-TEMPLATE.md und OPEN-RISKS.md.

Markiere alles, was nicht anhand des Projekts belegt werden kann, als UNKLAR. Erfinde keine Zugangsdaten, Verträge oder Ansprechpartner. ```

Skillbibliothek für Website-Projekte

Warum Skills sinnvoller sind als immer neue Mega-Prompts

Ein Skill ist eine wiederverwendbare Arbeitsanweisung. Er kann Checklisten, Referenzen, Vorlagen und Skripte bündeln. Im Website-Projekt verhindert das, dass zentrale Prüfungen bei jedem Auftrag neu formuliert oder vergessen werden.

EMPFEHLUNG: Projektwissen und Arbeitsabläufe trennen:

```text CLAUDE.md = dauerhafte Kernregeln und Projektbesonderheiten

SPEC- und Inventardateien = fachlicher und technischer Projektstand

Skills = wiederverwendbare Arbeitsabläufe

Permissions/Hooks/Sandbox = technische Grenzen ```

Ein Skill ist keine Sicherheitsbarriere. Kritische Aktionen müssen zusätzlich über Berechtigungen und technische Schranken begrenzt werden.

Empfohlene Verzeichnisstruktur

``text .claude/ ├── settings.json └── skills/ ├── website-project-init/ │ └── SKILL.md ├── data-inventory/ │ └── SKILL.md ├── privacy-audit/ │ └── SKILL.md ├── cookie-audit/ │ └── SKILL.md ├── security-baseline/ │ └── SKILL.md ├── owasp-review/ │ └── SKILL.md ├── accessibility-audit/ │ └── SKILL.md ├── shop-audit/ │ └── SKILL.md ├── prelaunch/ │ └── SKILL.md ├── incident-pack/ │ └── SKILL.md └── handover/ └── SKILL.md ``

Gemeinsame Regeln für alle Audit-Skills

Jeder Skill sollte mindestens enthalten:

• Zweck und Scope,
• erforderliche Eingaben,
• erlaubte Werkzeuge,
• verbotene Aktionen,
• Reihenfolge,
• Ausgabeformat,
• Stop-Bedingungen,
• Verweis auf Projektdateien,
• Kennzeichnung FAKT/ANNAHME/UNKLAR,
• keine pauschale Rechts- oder Sicherheitsfreigabe.

VORLAGE: Sicherheitskopf

```yaml

name: example-audit description: Führt eine lesende, dokumentierte Projektprüfung durch. disable-model-invocation: false

```

Danach:

```text SICHERHEITSREGELN

• Starte lesend.
• Keine Produktion verändern.
• Keine Secrets ausgeben.
• Keine Daten an zusätzliche externe Dienste übertragen.
• Keine rechtliche Konformität behaupten.
• Bei fehlenden Fakten UNKLAR ausgeben.
• Kritische Aktionen nur nach ausdrücklicher Freigabe.

```

Die genaue Frontmatter-Unterstützung und Skill-Syntax sind schnell veraltend und müssen vor Verwendung gegen die aktuelle Claude-Code-Dokumentation geprüft werden.

Skill /website-project-init

Zweck: Aus einer Idee ein geordnetes Projekt machen, ohne sofort Code zu erzeugen.

```markdown

name: website-project-init description: Initialisiert ein deutsches Website-Projekt mit Spezifikation, Dateninventar, Sicherheits- und Betriebsgrundlagen.

Aufgabe

1. Prüfe den aktuellen Ordner und Git-Status.
2. Implementiere noch keine Website-Funktion.
3. Führe das Projektinterview aus references/project-interview.md durch.
4. Bestimme die vorläufige Risikostufe.
5. Erzeuge nur fehlende Dateien:

• WEBSITE-SPEC.md
• DATA-INVENTORY.md
• SERVICE-REGISTER.md
• SECURITY-BASELINE.md
• ACCESSIBILITY-CHECK.md
• PRELAUNCH-CHECKLIST.md
• docs/decisions.md
• docs/deployment.md
• docs/backup-restore.md

1. Prüfe .gitignore und .env.example.
2. Suche nach vorhandenen Secrets. Werte niemals anzeigen.
3. Erzeuge einen kleinen Umsetzungsplan.
4. Führe keine Installation und keinen Commit ohne Bestätigung aus.

Ergebnis

Berichte:

• vorhandener Projektstand,
• erzeugte Dateien,
• rote Risiken,
• offene Entscheidungen,
• nächster sinnvoller Schritt.

```

Skill /data-inventory

```markdown

name: data-inventory description: Erstellt oder aktualisiert das technische Daten- und Diensteinventar einer Website.

Ablauf

1. Lies WEBSITE-SPEC.md und vorhandene Inventare.
2. Suche Formulare, Datenmodelle, Logs, Cookies, Browser-Speicher, APIs, E-Mail, Uploads, Backups und externe Dienste.
3. Aktualisiere DATA-INVENTORY.md und SERVICE-REGISTER.md.
4. Markiere besondere Kategorien personenbezogener Daten.
5. Markiere Daten in URLs, Logs und Clientcode.
6. Erfinde keine Rechtsgrundlagen oder Fristen.
7. Verändere keinen Produktivcode.
8. Erzeuge eine Diff-Zusammenfassung.

```

Skill /cookie-audit

```markdown

name: cookie-audit description: Prüft Cookies, Browser-Speicher und Netzwerkaufrufe in verschiedenen Einwilligungszuständen.

Voraussetzungen

• Testumgebung oder lokale Umgebung.
• Browserautomation darf nur sichere Testdaten verwenden.

Testzustände

1. vor Interaktion,
2. alles abgelehnt,
3. nur notwendige Auswahl,
4. einzelne Kategorie,
5. alles akzeptiert,
6. Einwilligung widerrufen.

Ausgabe

• technische Speicher- und Netzwerkliste,
• Abweichungen vom Consent-Zustand,
• Screenshots/Logs mit maskierten Identifikatoren,
• konkrete Reproduktionsschritte,
• keine rechtliche Endfreigabe.

```

Skill /security-baseline

```markdown

name: security-baseline description: Prüft die technische Mindestabsicherung einer Website vor der Veröffentlichung.

Prüffelder

• HTTPS/TLS,
• Sicherheitsheader,
• Secrets und Debugmodus,
• Abhängigkeiten,
• Eingabe/Ausgabe/Datenbank,
• Authentisierung und Sitzungen,
• Rechte und Mandanten,
• Uploads,
• Fehlerbehandlung,
• Logging,
• Backup und Restore,
• Deployment und Rollback.

Regeln

• Beginne lesend.
• Keine destruktiven Tests.
• Findings nur mit Fundstelle.
• Sicherheitslücke vs. Verdacht unterscheiden.
• Schweregrad begründen.
• Erzeuge Regressionstests als Vorschlag.

```

Skill /owasp-review

Der Baseline-Skill prüft Mindestanforderungen. Der OWASP-Skill untersucht tiefer und sollte für Shops, Portale, APIs und Plattformen eingeplant werden.

```markdown

name: owasp-review description: Führt ein OWASP-Top-10- und ASVS-orientiertes defensives Review durch.

Vorgehen

1. Scope und Vertrauensgrenzen dokumentieren.
2. Angriffsflächen inventarisieren.
3. Relevante OWASP-Kategorien auswählen.
4. statische Analyse und sichere Tests durchführen.
5. Findings mit CWE-Bezug dokumentieren.
6. keine produktive Ausnutzung oder Datenexfiltration.
7. nicht geprüfte Bereiche ausdrücklich nennen.
8. Remediation nach Risiko und Aufwand priorisieren.

```

Skill /accessibility-audit

```markdown

name: accessibility-audit description: Prüft die Kernwege manuell und automatisiert anhand WCAG 2.2.

Pflicht

• Tastaturtest,
• Fokus,
• Zoom/Reflow,
• Semantik,
• Formulare,
• Fehlermeldungen,
• Kontrast,
• Alternativtexte,
• Statusmeldungen,
• Checkout/Login/Kündigung/Widerruf.

Ergebnis

Jedes Finding enthält Kriterium, Auswirkung, Reproduktionsweg, Fundstelle, Korrektur und Retest. Kein pauschales Zertifikat ausgeben. ```

Skill /shop-audit

```markdown

name: shop-audit description: Prüft den technischen B2C-Bestellprozess und markiert rechtlich offene Pflichtbereiche.

Prüfen

• Produkt-/Preisangaben,
• Warenkorb und serverseitige Berechnung,
• Pflichtinformationen vor Bestellung,
• Bestellbutton,
• Bestätigung,
• Zahlung/Webhooks,
• Rechnungszugriff,
• Widerrufsfunktion,
• Kündigungsschaltfläche,
• Produktsicherheit,
• Barrierefreiheit.

Grenze

Keine AGB, Widerrufsbelehrung oder Rechtsfreigabe erfinden. ```

Skill /prelaunch

Dieser Skill bündelt alle Teilprüfungen und erzeugt die Ampel. Er darf nicht automatisch deployen.

```markdown

name: prelaunch description: Erstellt die dokumentierte Go-live-Ampel für eine Website. disable-model-invocation: true

Ablauf

1. Projektversion/Commit festhalten.
2. alle vorhandenen Auditberichte lesen.
3. fehlende Pflichtprüfungen markieren.
4. rote, gelbe, grüne und ungeprüfte Punkte zusammenführen.
5. PRELAUNCH-REPORT.md erstellen.
6. kein Deployment.
7. keine rote Feststellung eigenmächtig herabstufen.
8. Freigabe durch benannte Menschen verlangen.

```

EMPFEHLUNG: Manuell auslösbar, weil die Freigabe Außenwirkung hat.

Skill /incident-pack

```markdown

name: incident-pack description: Unterstützt Beweissicherung, Eingrenzung und Dokumentation eines Sicherheitsvorfalls. disable-model-invocation: true

Harte Grenzen

• keine Produktion löschen,
• keine Logs überschreiben,
• keine Backups ersetzen,
• keine externe Kommunikation absenden,
• keine Behördenmeldung absenden,
• keine Secrets ausgeben.

Ergebnisdateien

• INCIDENT-TIMELINE.md
• AFFECTED-SYSTEMS.md
• DATA-BREACH-ASSESSMENT-INPUT.md
• CONTAINMENT-OPTIONS.md
• RESTORE-PLAN.md
• COMMUNICATION-DRAFTS.md

```

Skill /handover

```markdown

name: handover description: Erstellt die technische und organisatorische Übergabe eines Website-Projekts. disable-model-invocation: true

Inhalte

• Architektur,
• Repository/Release,
• Hosting/Domain/DNS,
• Zugänge als Rollen und Speicherorte, nie als Geheimwerte,
• Dienste und Verträge,
• Dateninventar,
• Deployment/Rollback,
• Backup/Restore,
• Monitoring/Incident,
• Updates/Lizenzen,
• offene Risiken,
• Entfernung von Agenturzugängen.

```

Hooks und technische Stopps

Eine Textregel wie „Lösche niemals die Datenbank“ ist hilfreich, aber nicht ausreichend. Kritische Aktionen sollten technisch begrenzt werden.

EMPFEHLUNG für lokale Entwicklung:

• .env und Schlüsseldateien gegen Änderung oder Ausgabe sperren,
• Befehle mit Datenlöschung bestätigen lassen,
• Produktionshosts nicht als Standardziel konfigurieren,
• vor Commit Tests und Secret-Scan ausführen,
• vor Deployment Prelaunch-Bericht verlangen,
• Produktion nur mit getrenntem Konto und minimalen Rechten,
• Restore und Deployment nur manuell auslösbar.

WARNUNG: Konkrete Hook- und Permission-Syntax verändert sich. Vor Übernahme immer die aktuelle Claude-Code-Dokumentation und die tatsächlich installierte Version prüfen.

Was ein Skill niemals versprechen sollte

Nicht:

``text Dieser Skill macht jede Website DSGVO-konform. Dieser Skill schützt zuverlässig vor allen Hacks. Dieser Skill erstellt ein rechtssicheres Impressum. Dieser Skill zertifiziert WCAG-Konformität. ``

Besser:

``text Dieser Skill inventarisiert technische Datenflüsse. Dieser Skill prüft definierte Sicherheitskontrollen. Dieser Skill markiert Pflichtfelder für fachliche Prüfung. Dieser Skill erzeugt reproduzierbare Testfälle. Dieser Skill dokumentiert ungeprüfte Bereiche. ``

Grenzen, Vor- und Nachteile und vernünftige Risikohaltung

Individuell bauen oder vorhandenes System verwenden?

Die Frage lautet nicht: „Was kann Claude Code bauen?“

Die bessere Frage lautet:

Welche Lösung lässt sich für diesen Zweck dauerhaft sicher, wirtschaftlich und verständlich betreiben?

Statische individuelle Website

Vorteile:

• kleine Codebasis,
• sehr gute Performance möglich,
• wenig Serverlogik,
• geringe Angriffsfläche,
• Tracking und Fremddienste vollständig kontrollierbar,
• einfach versionierbar und auslieferbar.

Nachteile:

• redaktionelle Pflege kann ohne CMS umständlich sein,
• Formulare und Suche benötigen zusätzliche Dienste oder Backend,
• jede Komfortfunktion muss bewusst gebaut werden,
• Agenturabhängigkeit möglich, wenn Dokumentation fehlt.

Geeignet für: schlanke Unternehmensseiten, Kampagnenseiten und Dokumentationen mit seltenen Änderungen.

WordPress

Vorteile:

• etabliertes Redaktionssystem,
• Rollen und Medienverwaltung,
• große Auswahl an Erweiterungen,
• viele Dienstleister verfügbar,
• redaktionelle Nutzung ohne Code möglich.

Nachteile:

• Wartung von Core, Plugins und Themes,
• Lieferketten- und Kompatibilitätsrisiken,
• unnötige Erweiterungen erhöhen Komplexität,
• Page Builder können Performance und Barrierefreiheit erschweren,
• Datenschutz hängt stark von Plugins und Konfiguration ab.

Geeignet für: redaktionell aktive Websites, wenn Betrieb und Updates organisiert sind.

Gehostete Shop-/Website-Plattform

Vorteile:

• Betrieb, Updates und Teile der Sicherheit beim Anbieter,
• schnelle Einführung,
• standardisierte Funktionen,
• Support und Ökosystem.

Nachteile:

• Anbieterbindung,
• laufende Kosten und Transaktionsgebühren,
• begrenzte Architekturkontrolle,
• Daten- und Drittlandfragen,
• Anpassungen können gegen Plattformgrenzen laufen,
• Export und Wechsel müssen früh geprüft werden.

Geeignet für: Standardprozesse, wenn der Funktionsumfang wirklich passt.

Individuelle Webanwendung

Vorteile:

• genau auf den Prozess zugeschnitten,
• klare Daten- und Rollenmodelle möglich,
• eigene Integrationen,
• Differenzierung und Automatisierung,
• keine unnötigen Standardfunktionen.

Nachteile:

• sämtliche Schutzmechanismen müssen entworfen und getestet werden,
• dauerhafte Wartungsverantwortung,
• höhere Anforderungen an Dokumentation, Tests und Betrieb,
• Schlüsselpersonenrisiko,
• Aufwand wächst mit jedem Login, Mandanten, Upload und Zahlungsprozess.

Geeignet für: klar definierte Prozesse mit echtem Nutzen, ausreichendem Budget und langfristigem Betriebskonzept.

Vibe Coding als Agenturmodell

Claude Code senkt den Aufwand für Prototypen, Standardkomponenten, Tests und Dokumentation. Dadurch können kleine Agenturen mehr individuelle Lösungen anbieten.

Der wirtschaftliche Fehler wäre jedoch, nur die erste Erstellung zu kalkulieren.

Ein professionelles Angebot muss berücksichtigen:

• Projektdefinition,
• Gestaltung und Inhalte,
• Entwicklung,
• Test und Abnahme,
• Datenschutz-/Rechtsinputs,
• Sicherheitsprüfung,
• Barrierefreiheit,
• Hosting und Deployment,
• Backups und Monitoring,
• Updates und Support,
• Incident-Reaktion,
• Übergabe und Exit.

EMPFEHLUNG: Erstellung und Betrieb vertraglich trennen. Der Kunde muss wissen, ob nach dem Go-live nur Gewährleistung, ein Wartungsvertrag, ein Hostingpaket oder laufende Weiterentwicklung enthalten ist.

Der gefährliche Festpreis

„Komplette Website mit Shop und Kundenlogin für 1.500 Euro“ klingt verkaufsstark. Er lässt aber kaum Raum für sichere Authentisierung, Rechte, Tests, Shoprecht, Barrierefreiheit, Backup und Betrieb.

EMPFEHLUNG: Scope in Stufen anbieten:

``text Phase 1: fachliche und technische Spezifikation Phase 2: Prototyp Phase 3: produktive Umsetzung Phase 4: Sicherheits-/Datenschutz-/Barrierefreiheitsaudit Phase 5: Go-live und Stabilisierung Phase 6: Wartung und Weiterentwicklung ``

Was eine Agentur ablehnen sollte

• Gesundheitsdaten über ein ungesichertes Standardformular.
• gemeinsame Admin-Passwörter per E-Mail.
• Deployment ohne Backup und Rollback.
• Shop ohne fachlich geprüfte Verbraucherinformationen.
• „Cookie-Banner wegklicken“, obwohl Tracking weiterläuft.
• Veröffentlichung fremder Bilder oder Texte ohne geklärte Rechte.
• versteckte Backdoors für Support.
• Kundenportal ohne negative Rechte- und Mandantentests.
• Produktion mit Testdaten oder Debugmodus.
• pauschales Versprechen „100 Prozent rechtssicher“ oder „unknackbar“.
• Rechtsdokumente allein aus einem KI-Prompt als Agenturleistung verkaufen, ohne die Grenze des RDG und die konkrete Verantwortlichkeit zu beachten. [S015]

Was Claude Code besser macht

• schneller vom Problem zum funktionierenden Prototyp,
• konsistente Projektvorlagen,
• wiederholbare Audits,
• automatisierte Tests,
• Dokumentation parallel zur Entwicklung,
• Unterstützung bei Code- und Konfigurationsprüfungen,
• bessere Übergabe, wenn das System bewusst genutzt wird.

Was Claude Code verschärfen kann

• Fehler werden schneller und über viele Dateien verteilt,
• unsichere Muster wirken professionell,
• Abhängigkeiten werden ungeprüft installiert,
• Berechtigungen und Serverzugriffe erhalten zu viel Macht,
• Betreiber glauben an eine nicht vorhandene Rechtsfreigabe,
• Prototypen werden zu früh produktiv,
• Wartungskosten werden unterschätzt.

Reifegradmodell

Stufe A – Experiment

Lokale Testseite, keine echten Daten, keine Produktion.

Stufe B – kontrollierter Prototyp

Git, Spezifikation, Testdaten, definierte Umgebung, keine öffentliche kritische Funktion.

Stufe C – kleine produktive Website

Impressum/Datenschutz, HTTPS, Diensteinventar, Backup, Monitoring, sichere Veröffentlichung.

Stufe D – transaktionales System

Shop, Login, Rechte, Tests, Betrieb, Incident-Prozess, fachliche Rechtsprüfung.

Stufe E – sensibles oder geschäftskritisches System

Bedrohungsmodell, unabhängige Sicherheitsprüfung, strengere Identitäten, DSFA-/Compliance-Prüfung, robuste Wiederherstellung und klare Verantwortlichkeiten.

EMPFEHLUNG: Erst in die nächste Stufe wechseln, wenn die Betriebsfähigkeit der vorherigen steht.

Die vernünftige Grundhaltung

Nicht Angst vor jeder Website.

Nicht blindes Vertrauen in KI.

Sondern:

``text klein beginnen → Daten minimieren → bekannte Standards verwenden → Rechte eng halten → Ergebnisse testen → Wiederherstellung vorbereiten → Verantwortung benennen → bei hohem Risiko Fachleute einbeziehen ``

Das ist kein Bremsklotz für Vibe Coding. Es ist die Voraussetzung dafür, dass aus einem beeindruckenden Prototyp eine belastbare Website oder ein seriöses Agenturprodukt wird.

Refresh-Liste: Was schnell veraltet

Warum dieses Kapitel wichtig ist

Gesetze, technische Standards und Herstellerdokumentationen verändern sich nicht im selben Tempo. Die Grundprinzipien der DSGVO, serverseitige Rechteprüfung oder die Trennung von Git und Backup bleiben stabil. Konkrete Claude-Code-Funktionen, WordPress-Versionen, Browserunterstützung, Sicherheitsheader, Zertifikatsempfehlungen und behördliche Auslegungshilfen können sich dagegen innerhalb weniger Monate ändern.

EMPFEHLUNG: Dieses Dossier ist eine belastbare Wissensbasis mit Stand 8. August 2026. Vor einer Buchveröffentlichung, einem Kundenaudit oder dem Go-live eines risikoreichen Projekts müssen die schnelllebigen Bereiche gegen die aktuelle Primärquelle geprüft werden.

Drei Aktualitätsklassen

Klasse A – vor jedem Go-live prüfen

• konkrete Anbieter, Subunternehmer und Hostingstandorte,
• DPF-Teilnehmerstatus eines US-Anbieters,
• eingesetzte Software- und Pluginversionen,
• bekannte Schwachstellen und Sicherheitsupdates,
• tatsächliche Cookies, Browser-Speicher und Netzwerkziele,
• TLS-Konfiguration und Zertifikatsstatus,
• Shoptexte, Preise, Produktangaben und Vertragsprozesse,
• Datenschutzhinweise im Verhältnis zur realen Technik,
• Domain-, DNS- und Administrationszugänge.

Klasse B – mindestens quartalsweise prüfen

• Claude-Code-Skills, Permissions, Hooks und Sicherheitsfunktionen,
• WordPress-Core, Plugins, Themes und PHP-Unterstützung,
• OWASP-Projekte, ASVS und GenAI-/MCP-Risikolisten,
• Sicherheitswarnungen für Frameworks und Bibliotheken,
• AI-Act-Leitlinien, Codes und Behörden-FAQ,
• NIS2-/BSI-Portale und nationale Aufsichtspraxis,
• CRA-Durchführungsinformationen,
• BFSG-Normen und behördliche FAQ,
• Drittlandtransfer- und Angemessenheitsentscheidungen.

Klasse C – jährlich oder bei Rechtsänderung prüfen

• DDG und MStV,
• TDDDG und Cookie-Auslegung,
• DSGVO-/BDSG-Rechtsprechung,
• Verbraucherrecht und EGBGB,
• PAngV, GPSR und DSA,
• BFSG/BFSGV/BGG/BITV,
• AI Act und delegierte/implementierende Rechtsakte,
• Urheberrecht und Rechtsprechung zu KI-Inhalten,
• NIST-, BSI- und W3C-Standards.

Rechtsstand, der unmittelbar vor Veröffentlichung erneut geprüft werden muss

Elektronische Widerrufsfunktion

§ 356a BGB regelt die elektronische Widerrufsfunktion. Die für dieses Dossier relevante Anwendung begann am 19. Juni 2026. Technische Gestaltung, betroffene Vertragsarten und Zusammenspiel mit Widerrufsinformationen müssen im konkreten Shop geprüft werden. [S056] [S057]

AI Act, Artikel 50

Die Transparenzpflichten nach Art. 50 AI Act gelten grundsätzlich seit 2. August 2026. Die Kommission veröffentlichte am 20. Juli 2026 Leitlinien und ergänzende FAQ; der freiwillige Code of Practice konkretisiert Markierung und Kennzeichnung bestimmter KI-generierter Inhalte. [S065] [S066] [S067] [S068] [S069] [S070]

Vor einer Veröffentlichung prüfen:

• wurde die Leitlinie geändert oder ergänzt,
• welche Behörden sind zuständig,
• welche Übergangsregel gilt für vor dem 2. August 2026 in Verkehr gebrachte Systeme,
• wurden maschinenlesbare Markierungsstandards konkretisiert,
• wurde der Code unterzeichnet oder durch andere Maßnahmen ersetzt.

BFSG

Wesentliche Pflichten des BFSG gelten seit 28. Juni 2025. Anwendungsbereich, Kleinstunternehmerausnahme für Dienstleistungen, Übergangsregeln und harmonisierte Standards müssen für das konkrete Angebot geprüft werden. [S034] [S035] [S036] [S037] [S038] [S039] [S040] [S047]

Cyber Resilience Act

Der CRA trat 2024 in Kraft und gilt gestaffelt. Nach dem von der Kommission dokumentierten Zeitplan beginnen bestimmte Meldepflichten am 11. September 2026, während wesentliche Hauptpflichten am 11. Dezember 2027 anwendbar werden. [S113] [S114] [S115]

Für eine Website-Agentur wird der CRA nicht automatisch durch jede einzelne Website ausgelöst. Wer jedoch Softwareprodukte, Plugins, Themes, Gerätekomponenten oder digitale Produkte auf dem Markt bereitstellt, muss Scope und Rollen rechtzeitig fachlich prüfen.

NIS2 und deutsches BSIG

Ob ein Unternehmen in den Anwendungsbereich fällt, hängt unter anderem von Sektor, Größe und Funktion ab. Das deutsche BSIG und die aktuellen BSI-Informationen sind maßgeblich. [S111] [S112] [S134]

WARNUNG: Eine kleine Agentur darf aus der eigenen Unternehmensgröße nicht folgern, dass alle Kundenprojekte außerhalb regulierter Lieferketten liegen.

Sicherheitsstandards

OWASP Top 10

Die aktuelle Webanwendungsfassung ist OWASP Top 10:2025. Sie ist ein Awareness-Dokument und kann künftig erneut ersetzt werden. [S075]

ASVS

Version, Levels und konkrete Verifikationsanforderungen vor einem vertraglichen Audit aktuell abrufen. [S076]

OWASP GenAI und MCP

Die OWASP GenAI LLM Top 10 2026 wurde am 4. August 2026 veröffentlicht. MCP- und agentische Toolrisiken entwickeln sich schnell. [S141] [S142]

NIST

Für Incident Response ist NIST SP 800-61 Rev. 3 vom 3. April 2025 die aktuelle finale Fassung und auf CSF 2.0 ausgerichtet. [S138]

NIST-Digital-Identity- und Authenticator-Empfehlungen sowie BSI-Kryptografie- und TLS-Empfehlungen müssen wegen technischer Entwicklung jeweils in aktueller Fassung geprüft werden. [S092] [S093] [S102] [S103]

MITRE

CWE, CVE, CAPEC und ATT&CK sind laufend gepflegte Wissensbasen. Eine im Buch genannte Kategorie bleibt erklärend nützlich; konkrete Einträge, Versionen und Zuordnungen müssen aktuell abgerufen werden. [S094] [S096] [S097] [S098]

Browser, TLS und Webstandards

Folgende Angaben sind besonders schnelllebig:

• unterstützte TLS-Protokolle und Cipher,
• HSTS- und CSP-Empfehlungen,
• Browserunterstützung einzelner Header,
• Cookieattribute und Privacy-Sandbox-/Trackingmechanismen,
• Passkey- und WebAuthn-Unterstützung,
• automatische Zertifikatsverfahren,
• HTTP-Versionen und Proxykonfiguration.

BSI, W3C, MDN, OWASP und Herstellerdokumentationen sind direkt vor technischer Umsetzung zu prüfen. [S041] [S084] [S085] [S086] [S102] [S103] [S105] [S136] [S137]

WordPress und Abhängigkeiten

Vor jedem Release:

``text Core-Version → PHP-/Datenbankunterstützung → Plugin-/Theme-Versionen → Sicherheitsmeldungen → Changelog → Kompatibilität → Staging-Test → Backup → Rollout ``

Offizielle WordPress-Dokumentation beschreibt Prinzipien; die tatsächliche Sicherheit hängt von der konkreten Version und Erweiterung ab. [S116] [S117] [S121]

Datenschutz und internationale Dienste

Vor Nutzung eines externen Dienstes prüfen:

• aktueller Anbieter und Vertragspartner,
• Rolle als Verantwortlicher/Auftragsverarbeiter,
• Subunternehmer,
• Verarbeitungsorte,
• Transferinstrument,
• DPF-Status am Tag der Prüfung,
• Löschung und Training,
• technische Netzwerkaufrufe,
• Änderungen seit der letzten Prüfung.

Die Kommissionslisten und das offizielle DPF-Register sind laufend. [S029] [S031] [S032]

Refresh-Protokoll

VORLAGE:

```text Dokument/Projekt: Prüfdatum: Prüfende Person:

Bereich: verwendete Primärquelle: Stand/Version: Änderung seit letzter Prüfung: Auswirkung auf Text/Code/Vertrag: Maßnahme: Verantwortlich: Frist:

Keine Änderung festgestellt / Änderung umgesetzt / fachliche Prüfung offen ```

Buch-Freeze-Checkliste

Unmittelbar vor finalem PDF-/KDP-Export:

``text [ ] alle URLs stichprobenartig aufrufbar [ ] Veröffentlichungs-/Abrufdaten korrekt [ ] AI-Act-Art.-50-Leitlinie aktuell [ ] Widerrufsfunktion und § 356a BGB aktuell [ ] BFSG-FAQ und Normenstand aktuell [ ] CRA-/NIS2-Zeitplan aktuell [ ] OWASP Top 10/ASVS/GenAI aktuell [ ] NIST Incident Response aktuell [ ] BSI TLS/Kryptografie aktuell [ ] WordPress- und Claude-Code-spezifische Hinweise aktuell [ ] keine veraltete ODR-Plattform empfohlen [ ] keine pauschale KI-Kennzeichnungspflicht behauptet [ ] alle Empfehlungen als Empfehlungen erkennbar [ ] alle unklaren Einzelfragen als UNKLAR markiert ``

Quellenverzeichnis

Quellenmethodik

Das Dossier bevorzugt Rechtsnormen, EU-/Bundesbehörden, Datenschutzaufsicht, Gerichte, Standards und offizielle Herstellerdokumentationen. Sekundärquellen werden nur ergänzend eingesetzt. Bei laufend gepflegten Webseiten ohne verlässlich ausgewiesenes Veröffentlichungsdatum wird der Abrufstand genannt, statt ein Datum zu erfinden.

Die Quellenkennungen [S001] bis [S142] im Text verweisen auf das folgende Register. Die Aufnahme einer Quelle bedeutet nicht, dass jede dort veröffentlichte Aussage für jedes Projekt gilt. Gesetze und Standards müssen auf den konkreten Anwendungsbereich angewendet werden.

S001 - Europäische Union

Datenschutz-Grundverordnung (EU) 2016/679 URL: https://eur-lex.europa.eu/eli/reg/2016/679/oj/deu Datum/Stand: 27.04.2016; ABl. 04.05.2016 Typ: Gesetz/Primärquelle. Hinweis: In Kraft; Abruf 08.08.2026.

S002 - EDPB

Guidelines 07/2020 on the concepts of controller and processor in the GDPR, Version 2.0 URL: https://www.edpb.europa.eu/system/files/2021-07/eppb_guidelines_202007_controllerprocessor_final_en.pdf Datum/Stand: 07.07.2021 Typ: Behördenleitlinie/Primärquelle. Hinweis: Finale Fassung.

S003 - EDPB

Opinion 22/2024 on certain obligations following from reliance on processor(s) and sub-processor(s) URL: https://www.edpb.europa.eu/system/files/2024-10/edpb_opinion_202422_relianceonprocessors-sub-processors_en.pdf Datum/Stand: 07.10.2024 Typ: Behördenstellungnahme/Primärquelle. Hinweis: Finale Fassung.

S004 - EDPB

Guidelines 9/2022 on personal data breach notification under GDPR, Version 2.0 URL: https://www.edpb.europa.eu/system/files/2023-04/edpb_guidelines_202209_personal_data_breach_notification_v2.0_en.pdf Datum/Stand: 28.03.2023 Typ: Behördenleitlinie/Primärquelle. Hinweis: Finale Fassung.

S005 - EDPB

Data Protection Impact Assessment - Themen- und Leitlinienseite URL: https://www.edpb.europa.eu/sme-data-protection-guide/be-compliant/data-protection-impact-assessment-dpia_en Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Aktuell prüfen.

S006 - Bundesministerium der Justiz

Bundesdatenschutzgesetz (BDSG) URL: https://www.gesetze-im-internet.de/bdsg_2018/ Datum/Stand: 30.06.2017; geltende Fassung, Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S007 - Bundesministerium der Justiz

§ 22 BDSG - Verarbeitung besonderer Kategorien personenbezogener Daten URL: https://www.gesetze-im-internet.de/bdsg_2018/__22.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S008 - Bundesministerium der Justiz

§ 203 StGB - Verletzung von Privatgeheimnissen URL: https://www.gesetze-im-internet.de/stgb/__203.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S009 - Bundesministerium der Justiz

§ 5 Digitale-Dienste-Gesetz (DDG) - Allgemeine Informationspflichten URL: https://www.gesetze-im-internet.de/ddg/__5.html Datum/Stand: DDG vom 06.05.2024; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S010 - Die Medienanstalten

Medienstaatsvertrag (MStV), konsolidierte Fassung URL: https://www.die-medienanstalten.de/fileadmin/user_upload/Rechtsgrundlagen/Gesetze_Staatsvertraege/Medienstaatsvertrag_MStV.pdf Datum/Stand: Fassung seit 01.12.2025; Abruf 08.08.2026 Typ: Staatsvertrag/Primärquelle. Hinweis: Aktuelle Fassung.

S011 - Freistaat Bayern / Gesetze-Bayern

§ 18 MStV - Informationspflichten und journalistisch-redaktionelle Angebote URL: https://www.gesetze-bayern.de/Content/Document/MStV-18 Datum/Stand: Fassung seit 01.12.2025; Abruf 08.08.2026 Typ: Staatsvertrag/Primärquelle. Hinweis: Aktuelle Fassung.

S012 - Bundesministerium der Justiz

§ 37a HGB - Pflichtangaben auf Geschäftsbriefen URL: https://www.gesetze-im-internet.de/hgb/__37a.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S013 - Bundesministerium der Justiz

§ 35a GmbHG - Angaben auf Geschäftsbriefen URL: https://www.gesetze-im-internet.de/gmbhg/__35a.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S014 - Bundesministerium der Justiz

§ 80 AktG - Angaben auf Geschäftsbriefen URL: https://www.gesetze-im-internet.de/aktg/__80.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S015 - Bundesministerium der Justiz

§ 2 Rechtsdienstleistungsgesetz (RDG) - Begriff der Rechtsdienstleistung URL: https://www.gesetze-im-internet.de/rdg/__2.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S016 - Bundesministerium der Justiz

§ 631 BGB - Vertragstypische Pflichten beim Werkvertrag URL: https://www.gesetze-im-internet.de/bgb/__631.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S017 - Bundesministerium der Justiz

§ 633 BGB - Sach- und Rechtsmangel beim Werkvertrag URL: https://www.gesetze-im-internet.de/bgb/__633.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S018 - Bundesministerium der Justiz

§ 640 BGB - Abnahme URL: https://www.gesetze-im-internet.de/bgb/__640.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S019 - Bundesministerium der Justiz

§ 25 TDDDG - Schutz der Privatsphäre bei Endeinrichtungen URL: https://www.gesetze-im-internet.de/ttdsg/__25.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S020 - Datenschutzkonferenz (DSK)

Orientierungshilfe für Anbieter:innen von Telemedien, Version 1.1 URL: https://www.datenschutzkonferenz-online.de/media/oh/20221130_OH_Telemedien_2021_Version_1_1.pdf Datum/Stand: 30.11.2022 Typ: Behördenleitlinie/Primärquelle. Hinweis: Weiterhin relevant; nationalen Rechtsstand aktualisieren.

S021 - EDPB

Report of the work undertaken by the Cookie Banner Taskforce URL: https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf Datum/Stand: 17.01.2023 Typ: Behördenbericht/Primärquelle. Hinweis: Final.

S022 - EDPB

Guidelines 2/2023 on Technical Scope of Article 5(3) ePrivacy Directive, Version 2.0 URL: https://www.edpb.europa.eu/system/files/2024-10/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_v2_en_0.pdf Datum/Stand: 07.10.2024; veröffentlicht 16.10.2024 Typ: Behördenleitlinie/Primärquelle. Hinweis: Finale Fassung.

S023 - EuGH

Urteil C-673/17 - Planet49 URL: https://curia.europa.eu/juris/liste.jsf?num=C-673/17 Datum/Stand: 01.10.2019 Typ: Gerichtsentscheidung/Primärquelle. Hinweis: Rechtsgrundlage für Einwilligungsanforderungen.

S024 - LfDI Baden-Württemberg

FAQ zu Cookies und Tracking URL: https://www.baden-wuerttemberg.datenschutz.de/faq-zu-cookies-und-tracking-2/ Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Schnell veraltend.

S025 - EDPB

Guidelines 1/2024 on processing of personal data based on Article 6(1)(f) GDPR URL: https://www.edpb.europa.eu/system/files/2024-10/edpb_guidelines_202401_legitimateinterest_en.pdf Datum/Stand: 08.10.2024 Typ: Behördenleitlinie/Primärquelle. Hinweis: Finale Fassung.

S026 - Bundesministerium der Justiz

§ 7 UWG - Unzumutbare Belästigungen URL: https://www.gesetze-im-internet.de/uwg_2004/__7.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S027 - Datenschutzkonferenz (DSK)

Orientierungshilfe der Aufsichtsbehörden zur Verarbeitung personenbezogener Daten für Zwecke der Direktwerbung URL: https://www.datenschutzkonferenz-online.de/media/oh/20181107_oh_werbung.pdf Datum/Stand: 07.11.2018 Typ: Behördenleitlinie/Primärquelle. Hinweis: Zeitlose Grundsätze; Rechtsstand prüfen.

S028 - Bundesgerichtshof

Urteil I ZR 164/09 - Double-Opt-in-Einwilligung URL: https://www.bundesgerichtshof.de/SharedDocs/Entscheidungen/DE/Zivilsenate/I_ZS/2009/I_ZR_164-09.pdf?__blob=publicationFile&v=3 Datum/Stand: 10.02.2011 Typ: Gerichtsentscheidung/Primärquelle. Hinweis: Weiterhin als Nachweisprinzip relevant.

S029 - Europäische Kommission

Adequacy decisions - international data transfers URL: https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/adequacy-decisions_en Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Schnell veraltend.

S030 - Europäische Kommission

Standard Contractual Clauses - Durchführungsbeschluss (EU) 2021/914 URL: https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj/deu Datum/Stand: 04.06.2021 Typ: EU-Beschluss/Primärquelle. Hinweis: In Kraft.

S031 - Europäische Kommission

EU-US Data Privacy Framework - Angemessenheitsbeschluss und Information URL: https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers_en Datum/Stand: 10.07.2023; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Teilnehmerstatus jeweils prüfen.

S032 - U.S. Department of Commerce

Data Privacy Framework List URL: https://www.dataprivacyframework.gov/list Datum/Stand: laufendes Register; Abruf 08.08.2026 Typ: Offizielles Register/Primärquelle. Hinweis: Teilnehmerstatus tagesaktuell prüfen.

S033 - EDPB

Recommendations 01/2020 on supplementary measures for transfer tools, Version 2.0 URL: https://www.edpb.europa.eu/system/files/2021-06/edpb_recommendations_202001vo.2.0_supplementarymeasurestransferstools_en.pdf Datum/Stand: 18.06.2021 Typ: Behördenleitlinie/Primärquelle. Hinweis: Finale Fassung.

S034 - Bundesministerium der Justiz

Barrierefreiheitsstärkungsgesetz (BFSG) URL: https://www.gesetze-im-internet.de/bfsg/ Datum/Stand: 16.07.2021; Anwendung wesentlicher Pflichten seit 28.06.2025 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S035 - Bundesministerium der Justiz

§ 2 BFSG - Begriffsbestimmungen, insbesondere Dienstleistungen im elektronischen Geschäftsverkehr URL: https://www.gesetze-im-internet.de/bfsg/__2.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S036 - Bundesministerium der Justiz

§ 19 BFSGV - Dienstleistungen im elektronischen Geschäftsverkehr URL: https://www.gesetze-im-internet.de/bfsgv/__19.html Datum/Stand: 15.06.2022; Abruf 08.08.2026 Typ: Verordnung/Primärquelle. Hinweis: Aktuelle Fassung.

S037 - Bundesministerium für Arbeit und Soziales

Barrierefreiheitsstärkungsgesetz - Überblick URL: https://www.bmas.de/DE/Service/Gesetze-und-Gesetzesvorhaben/barrierefreiheitsstaerkungsgesetz.html Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Aktuell prüfen.

S038 - Bundesfachstelle Barrierefreiheit

E-Commerce / Online-Shops nach dem BFSG URL: https://www.bundesfachstelle-barrierefreiheit.de/DE/Barrierefreiheitsstaerkungsgesetz/E-Commerce/online-shops_node Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Aktuell prüfen.

S039 - Bundesfachstelle Barrierefreiheit

FAQ zum elektronischen Geschäftsverkehr URL: https://www.bundesfachstelle-barrierefreiheit.de/DE/Barrierefreiheitsstaerkungsgesetz/FAQ-elektronischer-Geschaeftsverkehr/faq-elektronischer-Geschaeftsverkehr_node Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Aktuell prüfen.

S040 - Bundesfachstelle Barrierefreiheit

FAQ zum Barrierefreiheitsstärkungsgesetz URL: https://www.bundesfachstelle-barrierefreiheit.de/DE/Barrierefreiheitsstaerkungsgesetz/FAQ/faq_node Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Aktuell prüfen.

S041 - W3C

Web Content Accessibility Guidelines (WCAG) 2.2 URL: https://www.w3.org/TR/WCAG22/ Datum/Stand: 05.10.2023; Korrekturen laufend Typ: Standard/Primärquelle. Hinweis: Aktuelle W3C Recommendation.

S042 - W3C Web Accessibility Initiative

What’s New in WCAG 2.2 URL: https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/ Datum/Stand: 05.10.2023; aktualisiert 12.12.2024 Typ: Standardinformation/Primärquelle. Hinweis: Aktuell.

S043 - Bundesministerium der Justiz

Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) URL: https://www.gesetze-im-internet.de/bitv_2_0/ Datum/Stand: 12.09.2011; geltende Fassung, Abruf 08.08.2026 Typ: Verordnung/Primärquelle. Hinweis: Für Bundesstellen.

S044 - Bundesministerium der Justiz

§ 7 BITV 2.0 - Erklärung zur Barrierefreiheit URL: https://www.gesetze-im-internet.de/bitv_2_0/__7.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Verordnung/Primärquelle. Hinweis: Für Bundesstellen.

S045 - Bundesministerium der Justiz

§ 12 BGG - Barrierefreie Informationstechnik URL: https://www.gesetze-im-internet.de/bgg/__12.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Für öffentliche Stellen des Bundes.

S046 - Europäische Kommission

Web Accessibility Directive - standards and harmonisation URL: https://digital-strategy.ec.europa.eu/en/policies/web-accessibility-directive-standards-and-harmonisation Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Harmonisierungsstand schnell veraltend.

S047 - Bundesfachstelle Barrierefreiheit

Normen und Standards zum BFSG URL: https://www.bundesfachstelle-barrierefreiheit.de/DE/Barrierefreiheitsstaerkungsgesetz/Normen-und-Standards/normen-und-standards_node Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Schnell veraltend.

S048 - Europäische Kommission

Web accessibility - overlays are not a substitute for fixing source accessibility URL: https://digital-strategy.ec.europa.eu/en/policies/web-accessibility Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Aktuell.

S049 - Bundesministerium der Justiz

§ 312j BGB - Besondere Pflichten im elektronischen Geschäftsverkehr gegenüber Verbrauchern URL: https://www.gesetze-im-internet.de/bgb/__312j.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Button-Lösung.

S050 - Bundesministerium der Justiz

Art. 246a § 1 EGBGB - Informationspflichten bei Fernabsatzverträgen URL: https://www.gesetze-im-internet.de/bgbeg/art_246a__1.html Datum/Stand: geltende Fassung seit 19.06.2026; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S051 - Bundesministerium der Justiz

Preisangabenverordnung (PAngV) URL: https://www.gesetze-im-internet.de/pangv_2022/ Datum/Stand: 12.11.2021; in Kraft seit 28.05.2022; Abruf 08.08.2026 Typ: Verordnung/Primärquelle. Hinweis: Aktuelle Fassung.

S052 - Bundesministerium der Justiz

§ 36 VSBG - Allgemeine Informationspflicht URL: https://www.gesetze-im-internet.de/vsbg/__36.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S053 - Europäische Union

Verordnung (EU) 2024/3228 zur Aufhebung der ODR-Verordnung URL: https://eur-lex.europa.eu/eli/reg/2024/3228/oj/deu Datum/Stand: 19.12.2024 Typ: EU-Verordnung/Primärquelle. Hinweis: ODR-Plattform beendet 2025.

S054 - Europäische Union

Verordnung (EU) 2023/988 über die allgemeine Produktsicherheit (GPSR) URL: https://eur-lex.europa.eu/eli/reg/2023/988/oj/deu Datum/Stand: 10.05.2023; anwendbar seit 13.12.2024 Typ: EU-Verordnung/Primärquelle. Hinweis: Aktuelle Fassung prüfen.

S055 - Europäische Union

GPSR, konsolidierte Fassung - Art. 19 Fernabsatzangebote URL: https://eur-lex.europa.eu/eli/reg/2023/988/2026-05-29/deu Datum/Stand: konsolidiert 29.05.2026 Typ: EU-Verordnung/Primärquelle. Hinweis: Aktuelle konsolidierte Fassung.

S056 - Bundesministerium der Justiz

§ 356a BGB - Elektronische Widerrufsfunktion bei Fernabsatzverträgen URL: https://www.gesetze-im-internet.de/bgb/__356a.html Datum/Stand: in Kraft seit 19.06.2026 Typ: Gesetz/Primärquelle. Hinweis: Neu und schnell praktisch zu prüfen.

S057 - Verbraucherzentrale

Widerrufsbutton im Online-Handel - praktische Einordnung URL: https://www.verbraucherzentrale.de/wissen/vertraege-reklamation/kundenrechte/widerrufsbutton-fuer-onlinevertraege-das-gilt-ab-juni-2026-107991 Datum/Stand: 19.06.2026 Typ: Verbraucherinformation/Sekundärquelle. Hinweis: Praxisquelle; Gesetz ist maßgeblich.

S058 - Bundesministerium der Justiz

§ 312k BGB - Kündigung von Verbraucherverträgen im elektronischen Geschäftsverkehr URL: https://www.gesetze-im-internet.de/bgb/__312k.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Kündigungsschaltfläche.

S059 - Bundesministerium der Justiz

§ 312d BGB - Informations- und Gestaltungspflichten bei Fernabsatzverträgen URL: https://www.gesetze-im-internet.de/bgb/__312d.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S060 - Bundesministerium der Justiz

§ 312g BGB - Widerrufsrecht und Ausnahmen URL: https://www.gesetze-im-internet.de/bgb/__312g.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S061 - Bundesministerium der Justiz

Art. 246a § 4 EGBGB - Formale Anforderungen an Informationen URL: https://www.gesetze-im-internet.de/bgbeg/art_246a__4.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S062 - Europäische Union

Verordnung (EU) 2022/2065 - Digital Services Act URL: https://eur-lex.europa.eu/eli/reg/2022/2065/oj/deu Datum/Stand: 19.10.2022; grundsätzlich anwendbar seit 17.02.2024 Typ: EU-Verordnung/Primärquelle. Hinweis: Scope abhängig vom Dienst.

S063 - Europäische Kommission

Digital Services Act - Auswirkungen auf Online-Plattformen URL: https://digital-strategy.ec.europa.eu/en/policies/dsa-impact-platforms Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Aktuell prüfen.

S064 - Bundesnetzagentur

Digital Services Coordinator für Deutschland URL: https://www.bundesnetzagentur.de/SharedDocs/Pressemitteilungen/EN/2024/20240514_DSC.html Datum/Stand: 14.05.2024 Typ: Behördeninformation/Primärquelle. Hinweis: Zuständigkeit Deutschland.

S065 - Europäische Union

Verordnung (EU) 2024/1689 - Artificial Intelligence Act URL: https://eur-lex.europa.eu/eli/reg/2024/1689/oj/deu Datum/Stand: 13.06.2024; ABl. 12.07.2024 Typ: EU-Verordnung/Primärquelle. Hinweis: Gestaffelte Geltung.

S066 - Europäische Union

AI Act, konsolidierte Fassung URL: https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX%3A02024R1689-20260727 Datum/Stand: konsolidiert 27.07.2026 Typ: EU-Verordnung/Primärquelle. Hinweis: Aktueller Stand 08.08.2026.

S067 - Europäische Kommission

FAQ zu Transparenzpflichten nach Art. 50 AI Act URL: https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act Datum/Stand: 24.07.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Aktuell.

S068 - Europäische Kommission

Guidelines on transparency obligations for providers and deployers of AI systems URL: https://digital-strategy.ec.europa.eu/en/library/guidelines-transparency-obligations-providers-and-deployers-ai-systems Datum/Stand: 20.07.2026; ergänzende Veröffentlichung 29.07.2026 Typ: Behördenleitlinie/Primärquelle. Hinweis: Schnell veraltend.

S069 - Europäische Kommission

Commission starts enforcing AI Act rules and new transparency requirements on 2 August URL: https://digital-strategy.ec.europa.eu/en/news/commission-starts-enforcing-ai-act-rules-and-new-transparency-requirements-2-august Datum/Stand: 31.07.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Aktueller Vollzugsstand.

S070 - Europäische Kommission

Code of Practice on marking and labelling AI-generated content URL: https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content Datum/Stand: laufende Fassung; Abruf 08.08.2026 Typ: Behörden-/Brancheninstrument. Hinweis: Schnell veraltend.

S071 - Bundesministerium der Justiz

§ 2 UrhG - Geschützte Werke und persönliche geistige Schöpfung URL: https://www.gesetze-im-internet.de/urhg/__2.html Datum/Stand: geltende Fassung; Abruf 08.08.2026 Typ: Gesetz/Primärquelle. Hinweis: Aktuelle Fassung.

S072 - Deutsches Patent- und Markenamt

Geistiges Eigentum digital - KI und Schutzrechte URL: https://www.dpma.de/service/schutzrechte_kurz_erklaert/geistigeseigentumdigital/index.html Datum/Stand: 2026; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Aktuell.

S073 - Deutsches Patent- und Markenamt

Broschüre Geistiges Eigentum in der digitalen Welt URL: https://www.dpma.de/docs/dpma/veroeffentlichungen/broschueren/bro_ip_welt_dt.pdf Datum/Stand: laufende Broschüre; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Hinweise zu KI-Output und Rechtsverletzungen.

S074 - EUIPO

Study on Generative Artificial Intelligence and Copyright URL: https://www.euipo.europa.eu/en/news/euipo-releases-study-on-generative-artificial-intelligence-and-copyright Datum/Stand: 2025/2026; Abruf 08.08.2026 Typ: EU-Studie/Primärquelle. Hinweis: Aktuell.

S075 - OWASP

OWASP Top 10:2025 URL: https://owasp.org/Top10/2025/ Datum/Stand: 2025 Typ: Sicherheitsstandard/Primärquelle. Hinweis: Aktuelle Ausgabe.

S076 - OWASP

Application Security Verification Standard (ASVS) URL: https://owasp.org/www-project-application-security-verification-standard/ Datum/Stand: laufende Fassung; Abruf 08.08.2026 Typ: Sicherheitsstandard/Primärquelle. Hinweis: Version vor Verwendung prüfen.

S077 - OWASP

OWASP API Security Top 10 - 2023 URL: https://owasp.org/www-project-api-security/ Datum/Stand: 2023 Typ: Sicherheitsstandard/Primärquelle. Hinweis: Aktuelle Ausgabe.

S078 - OWASP

Authentication Cheat Sheet URL: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html Datum/Stand: laufende Dokumentation; Abruf 08.08.2026 Typ: Sicherheitsleitlinie/Primärquelle. Hinweis: Aktuell prüfen.

S079 - OWASP

Password Storage Cheat Sheet URL: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html Datum/Stand: laufende Dokumentation; Abruf 08.08.2026 Typ: Sicherheitsleitlinie/Primärquelle. Hinweis: Parameter schnell veraltend.

S080 - OWASP

Session Management Cheat Sheet URL: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html Datum/Stand: laufende Dokumentation; Abruf 08.08.2026 Typ: Sicherheitsleitlinie/Primärquelle. Hinweis: Aktuell prüfen.

S081 - OWASP

File Upload Cheat Sheet URL: https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html Datum/Stand: laufende Dokumentation; Abruf 08.08.2026 Typ: Sicherheitsleitlinie/Primärquelle. Hinweis: Aktuell prüfen.

S082 - OWASP

REST Security Cheat Sheet URL: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html Datum/Stand: laufende Dokumentation; Abruf 08.08.2026 Typ: Sicherheitsleitlinie/Primärquelle. Hinweis: Aktuell prüfen.

S083 - OWASP

Cryptographic Storage Cheat Sheet URL: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html Datum/Stand: laufende Dokumentation; Abruf 08.08.2026 Typ: Sicherheitsleitlinie/Primärquelle. Hinweis: Algorithmen und Parameter refreshen.

S084 - OWASP

HTTP Headers Cheat Sheet URL: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html Datum/Stand: laufende Dokumentation; Abruf 08.08.2026 Typ: Sicherheitsleitlinie/Primärquelle. Hinweis: Aktuell prüfen.

S085 - OWASP

Content Security Policy Cheat Sheet URL: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html Datum/Stand: laufende Dokumentation; Abruf 08.08.2026 Typ: Sicherheitsleitlinie/Primärquelle. Hinweis: Aktuell prüfen.

S086 - OWASP

HTTP Strict Transport Security Cheat Sheet URL: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html Datum/Stand: laufende Dokumentation; Abruf 08.08.2026 Typ: Sicherheitsleitlinie/Primärquelle. Hinweis: Aktuell prüfen.

S087 - OWASP

Cross-Site Request Forgery Prevention Cheat Sheet URL: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html Datum/Stand: laufende Dokumentation; Abruf 08.08.2026 Typ: Sicherheitsleitlinie/Primärquelle. Hinweis: Aktuell prüfen.

S088 - OWASP

Clickjacking Defense Cheat Sheet URL: https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html Datum/Stand: laufende Dokumentation; Abruf 08.08.2026 Typ: Sicherheitsleitlinie/Primärquelle. Hinweis: Aktuell prüfen.

S089 - NIST

Cybersecurity Framework 2.0 URL: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf Datum/Stand: 26.02.2024 Typ: Standard/Primärquelle. Hinweis: Final.

S090 - NIST

SP 800-218 - Secure Software Development Framework (SSDF) Version 1.1 URL: https://csrc.nist.gov/pubs/sp/800/218/final Datum/Stand: 03.02.2022 Typ: Standard/Primärquelle. Hinweis: Final; Version 1.2 als Entwurf beobachten.

S091 - NIST

SP 800-218A - Secure Software Development Practices for Generative AI and Dual-Use Foundation Models URL: https://csrc.nist.gov/pubs/sp/800/218/a/final Datum/Stand: 26.07.2024 Typ: Standard/Primärquelle. Hinweis: Final.

S092 - NIST

SP 800-63-4 - Digital Identity Guidelines URL: https://csrc.nist.gov/pubs/sp/800/63/4/final Datum/Stand: 31.07.2025 Typ: Standard/Primärquelle. Hinweis: Final.

S093 - NIST

SP 800-63B-4 - Authentication and Authenticator Management URL: https://csrc.nist.gov/pubs/sp/800/63/b/4/final Datum/Stand: 31.07.2025 Typ: Standard/Primärquelle. Hinweis: Final.

S094 - MITRE

Common Weakness Enumeration (CWE) URL: https://cwe.mitre.org/ Datum/Stand: laufende Wissensbasis; Abruf 08.08.2026 Typ: Sicherheitswissensbasis/Primärquelle. Hinweis: Aktuell.

S095 - MITRE

2025 CWE Top 25 Most Dangerous Software Weaknesses URL: https://cwe.mitre.org/top25/archive/2025/2025_cwe_top25.html Datum/Stand: 2025 Typ: Sicherheitsranking/Primärquelle. Hinweis: Jährlich refreshen.

S096 - MITRE

Common Attack Pattern Enumeration and Classification (CAPEC) URL: https://capec.mitre.org/ Datum/Stand: laufende Wissensbasis; Abruf 08.08.2026 Typ: Sicherheitswissensbasis/Primärquelle. Hinweis: Aktuell.

S097 - MITRE

Common Vulnerabilities and Exposures (CVE) - Overview URL: https://www.cve.org/About/Overview Datum/Stand: laufendes Register; Abruf 08.08.2026 Typ: Vulnerabilitätsregister/Primärquelle. Hinweis: Tagesaktuell.

S098 - MITRE

ATT&CK - Enterprise Matrix URL: https://attack.mitre.org/matrices/enterprise/ Datum/Stand: laufende Wissensbasis; Abruf 08.08.2026 Typ: Bedrohungswissensbasis/Primärquelle. Hinweis: Version schnell veraltend.

S099 - BSI

Webanwendungen - Informationen und Empfehlungen URL: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Webanwendungen/webanwendungen_node.html Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördenleitlinie/Primärquelle. Hinweis: Aktuell.

S100 - BSI

IT-Grundschutz-Baustein APP.3.1 Webanwendungen URL: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2021/06_APP_Anwendungen/APP_3_1_Webanwendungen_Edition_2021.pdf?__blob=publicationFile&v=2 Datum/Stand: Edition 2021 Typ: Behördenstandard/Primärquelle. Hinweis: Neuere Edition vor Einsatz prüfen.

S101 - BSI

IT-Grundschutz-Baustein CON.10 Entwicklung von Webanwendungen URL: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/03_CON_Konzepte_und_Vorgehensweisen/CON_10_Entwicklung_von_Webanwendungen_Edition_2023.pdf?__blob=publicationFile&v=4 Datum/Stand: Edition 2023 Typ: Behördenstandard/Primärquelle. Hinweis: Neuere Edition vor Einsatz prüfen.

S102 - BSI

Technische Richtlinie TR-02102 - Kryptographische Verfahren: Empfehlungen und Schlüssellängen URL: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html Datum/Stand: laufende Richtlinie; Abruf 08.08.2026 Typ: Technische Richtlinie/Primärquelle. Hinweis: Mindestens jährlich refreshen.

S103 - BSI

TR-02102-2 - Verwendung von TLS URL: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.html Datum/Stand: laufende Richtlinie; Abruf 08.08.2026 Typ: Technische Richtlinie/Primärquelle. Hinweis: Mindestens jährlich refreshen.

S104 - Mozilla

MDN HTTP Observatory URL: https://developer.mozilla.org/en-US/observatory Datum/Stand: laufender Dienst; Abruf 08.08.2026 Typ: Prüfwerkzeug/Primärquelle. Hinweis: Automatisierter Hinweis, keine Zertifizierung.

S105 - W3C

Web Authentication: An API for accessing Public Key Credentials - Level 3 URL: https://www.w3.org/TR/webauthn-3/ Datum/Stand: laufender Standardisierungsstand; Abruf 08.08.2026 Typ: Webstandard/Primärquelle. Hinweis: Status vor Implementierung prüfen.

S106 - FIDO Alliance

Passkeys URL: https://fidoalliance.org/passkeys/ Datum/Stand: laufende Brancheninformation; Abruf 08.08.2026 Typ: Branchenstandard/Primärquelle. Hinweis: Implementierungsdetails prüfen.

S107 - CISA et al.

Secure by Design URL: https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf Datum/Stand: 25.10.2023 Typ: Behördenleitlinie/Primärquelle. Hinweis: Grundprinzipien.

S108 - CISA

Software Bill of Materials (SBOM) URL: https://www.cisa.gov/topics/information-communications-technology-supply-chain-security/sbom Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördenleitlinie/Primärquelle. Hinweis: Aktuell.

S109 - CISA

2026 Minimum Elements for a Software Bill of Materials URL: https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom Datum/Stand: 29.07.2026 Typ: Behördenleitlinie/Primärquelle. Hinweis: Neu; schnell veraltend.

S110 - CISA

Securing the Software Supply Chain - Recommended Practices URL: https://www.cisa.gov/resources-tools/resources/securing-software-supply-chain-recommended-practices-guide-suppliers-and Datum/Stand: laufende Behördenleitlinie; Abruf 08.08.2026 Typ: Behördenleitlinie/Primärquelle. Hinweis: Aktuell.

S111 - Bundesministerium der Justiz

BSIG 2025 URL: https://www.gesetze-im-internet.de/bsig_2025/ Datum/Stand: in Kraft seit 06.12.2025; Fassung 23.07.2026 Typ: Gesetz/Primärquelle. Hinweis: NIS2-Umsetzung; Scope prüfen.

S112 - BSI

NIS-2-regulierte Unternehmen URL: https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/NIS-2-regulierte-Unternehmen/nis-2-regulierte-unternehmen_node.html Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Scope und Portal aktuell prüfen.

S113 - Europäische Union

Verordnung (EU) 2024/2847 - Cyber Resilience Act URL: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/deu Datum/Stand: 23.10.2024; in Kraft seit 10.12.2024 Typ: EU-Verordnung/Primärquelle. Hinweis: Gestaffelte Anwendung.

S114 - Europäische Kommission

Cyber Resilience Act - Zeitplan und Überblick URL: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act Datum/Stand: 27.07.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Meldepflichten ab 11.09.2026; Hauptpflichten ab 11.12.2027.

S115 - Europäische Kommission

Cyber Resilience Act - Reporting obligations URL: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Ab 11.09.2026 relevant.

S116 - WordPress.org

Hardening WordPress URL: https://developer.wordpress.org/advanced-administration/security/hardening/ Datum/Stand: laufende Herstellerdokumentation; Abruf 08.08.2026 Typ: Herstellerdokumentation/Primärquelle. Hinweis: Hinweise projektbezogen prüfen.

S117 - WordPress.org

Security - Advanced Administration Handbook URL: https://developer.wordpress.org/advanced-administration/security/ Datum/Stand: laufende Herstellerdokumentation; Abruf 08.08.2026 Typ: Herstellerdokumentation/Primärquelle. Hinweis: Aktuell.

S118 - WordPress.org

Security - Theme Handbook URL: https://developer.wordpress.org/themes/advanced-topics/security/ Datum/Stand: laufende Herstellerdokumentation; Abruf 08.08.2026 Typ: Herstellerdokumentation/Primärquelle. Hinweis: Aktuell.

S119 - WordPress.org

Editing wp-config.php URL: https://developer.wordpress.org/advanced-administration/wordpress/wp-config/ Datum/Stand: laufende Herstellerdokumentation; Abruf 08.08.2026 Typ: Herstellerdokumentation/Primärquelle. Hinweis: Aktuell.

S120 - WordPress.org

HTTPS - Advanced Administration Handbook URL: https://developer.wordpress.org/advanced-administration/security/https/ Datum/Stand: laufende Herstellerdokumentation; Abruf 08.08.2026 Typ: Herstellerdokumentation/Primärquelle. Hinweis: Aktuell.

S121 - WordPress.org

Updating WordPress URL: https://developer.wordpress.org/advanced-administration/upgrade/upgrading/ Datum/Stand: laufende Herstellerdokumentation; Abruf 08.08.2026 Typ: Herstellerdokumentation/Primärquelle. Hinweis: Aktuell.

S122 - WordPress.org

Security - Common APIs Handbook URL: https://developer.wordpress.org/apis/security/ Datum/Stand: laufende Herstellerdokumentation; Abruf 08.08.2026 Typ: Herstellerdokumentation/Primärquelle. Hinweis: Aktuell.

S123 - WordPress.org

Checking User Capabilities - Plugin Handbook URL: https://developer.wordpress.org/plugins/security/checking-user-capabilities/ Datum/Stand: laufende Herstellerdokumentation; Abruf 08.08.2026 Typ: Herstellerdokumentation/Primärquelle. Hinweis: Aktuell.

S124 - WordPress.org

Nonces - Common APIs Handbook URL: https://developer.wordpress.org/apis/security/nonces/ Datum/Stand: laufende Herstellerdokumentation; Abruf 08.08.2026 Typ: Herstellerdokumentation/Primärquelle. Hinweis: Nonces ersetzen keine Autorisierung.

S125 - WordPress.org

Sanitizing Data - Common APIs Handbook URL: https://developer.wordpress.org/apis/security/sanitizing/ Datum/Stand: laufende Herstellerdokumentation; Abruf 08.08.2026 Typ: Herstellerdokumentation/Primärquelle. Hinweis: Aktuell.

S126 - WordPress.org

Escaping Data - Common APIs Handbook URL: https://developer.wordpress.org/apis/security/escaping/ Datum/Stand: laufende Herstellerdokumentation; Abruf 08.08.2026 Typ: Herstellerdokumentation/Primärquelle. Hinweis: Aktuell.

S127 - WordPress.org

Privacy - Plugin Handbook URL: https://developer.wordpress.org/plugins/privacy/ Datum/Stand: laufende Herstellerdokumentation; Abruf 08.08.2026 Typ: Herstellerdokumentation/Primärquelle. Hinweis: Aktuell.

S128 - DENIC

FAQs zu Rechtsthemen - Domaininhaberschaft und Rechte Dritter URL: https://www.denic.de/faq/faqs-zu-rechtsthemen/ Datum/Stand: laufende Registerinformation; Abruf 08.08.2026 Typ: Registerinformation/Primärquelle. Hinweis: Für .de-Domains.

S129 - DENIC

Alle FAQs - Domainvertrag, Provider und Inhaberschaft URL: https://www.denic.de/faq/alle-faqs/ Datum/Stand: laufende Registerinformation; Abruf 08.08.2026 Typ: Registerinformation/Primärquelle. Hinweis: Für .de-Domains.

S130 - CISA

Secure by Demand Guide URL: https://www.cisa.gov/resources-tools/resources/secure-demand-guide Datum/Stand: laufende Behördenleitlinie; Abruf 08.08.2026 Typ: Behördenleitlinie/Primärquelle. Hinweis: Beschaffung und Agentursteuerung.

S131 - EDPB

SME Data Protection Guide - Be compliant URL: https://www.edpb.europa.eu/sme/be-compliant/be-compliant_en Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Praxisorientiert.

S132 - Datenschutzkonferenz (DSK)

Orientierungshilfe Maßnahmen zum Schutz personenbezogener Daten bei der Übermittlung per E-Mail URL: https://www.datenschutzkonferenz-online.de/media/oh/20200526_orientierungshilfe_e_mail_verschluesselung.pdf Datum/Stand: 26.05.2020 Typ: Behördenleitlinie/Primärquelle. Hinweis: Risikoabhängig anwenden.

S133 - EuGH

Urteil C-667/21 - Verarbeitung von Gesundheitsdaten URL: https://curia.europa.eu/juris/liste.jsf?num=C-667/21 Datum/Stand: 21.12.2023 Typ: Gerichtsentscheidung/Primärquelle. Hinweis: Art. 9 Ausnahme plus Art. 6 Rechtsgrundlage.

S134 - BSI

NIS-2 Pflichten für registrierte Einrichtungen URL: https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/NIS-2-regulierte-Unternehmen/Pflichten-fuer-regulierte-Unternehmen/pflichten-fuer-regulierte-unternehmen_node.html Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Nur bei Anwendbarkeit.

S135 - Europäische Kommission

Digital Services Act - Überblick URL: https://digital-strategy.ec.europa.eu/en/policies/digital-services-act Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördeninformation/Primärquelle. Hinweis: Aktuell.

S136 - Mozilla

Content-Security-Policy - MDN URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy Datum/Stand: laufende Webstandard-Dokumentation; Abruf 08.08.2026 Typ: Webstandard-Dokumentation/Primärquelle. Hinweis: Browserunterstützung prüfen.

S137 - Mozilla

Strict-Transport-Security - MDN URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security Datum/Stand: laufende Webstandard-Dokumentation; Abruf 08.08.2026 Typ: Webstandard-Dokumentation/Primärquelle. Hinweis: Browserunterstützung prüfen.

S138 - NIST

SP 800-61 Rev. 3 - Incident Response Recommendations and Considerations for Cybersecurity Risk Management URL: https://csrc.nist.gov/pubs/sp/800/61/r3/final Datum/Stand: 03.04.2025 Typ: Standard/Primärquelle. Hinweis: Aktuelle finale Fassung; CSF-2.0-Bezug.

S139 - BSI

IT-Grundschutz: Backup und Wiederherstellung - allgemeine Empfehlungen URL: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html Datum/Stand: laufende Behördeninformation; Abruf 08.08.2026 Typ: Behördenstandard/Primärquelle. Hinweis: Bausteinstand prüfen.

S140 - Europäische Kommission

General Product Safety Regulation - Übersicht URL: https://eur-lex.europa.eu/EN/legal-content/summary/general-product-safety-regulation-2023.html Datum/Stand: laufende Zusammenfassung; Abruf 08.08.2026 Typ: EU-Zusammenfassung/Primärquelle. Hinweis: Verordnung ist maßgeblich.

S141 - OWASP GenAI Security Project

OWASP GenAI LLM Top 10 2026 URL: https://genai.owasp.org/llm-top-10/ Datum/Stand: 04.08.2026 Typ: Sicherheitsstandard/Primärquelle. Hinweis: Aktuelle GenAI-Risiken; schnell veraltend.

S142 - OWASP

OWASP MCP Top 10 URL: https://owasp.org/www-project-mcp-top-10/ Datum/Stand: laufende Projektdokumentation; Abruf 08.08.2026 Typ: Sicherheitsstandard/Primärquelle. Hinweis: MCP- und Tool-Risiken; schnell veraltend.