Sicherheit & Vertrauen

1. Zusammenfassung auf einer Seite

Unser ehrlicher aktueller Stand, mit Datum 2026-07-08: horsenose ist ein Produkt in einem frühen Entwicklungsstadium, das von einem Einzelunternehmer betrieben wird. Wir verfügen derzeit WEDER über eine SOC-2- noch über eine ISO-27001-Zertifizierung, und es hat noch kein externer Penetrationstest stattgefunden. Diese Seite beschreibt, was wir tun, welche Daten wir vorhalten und was uns noch fehlt. Wir legen unseren aktuellen Stand lieber offen dar, als ihn zu beschönigen.

• Wer wir sind. horsenose ist eine Software für den Betrieb einer Reitschule — Unterrichtsplanung, Anwesenheits- und Zahlungserfassung, Verwaltung von Reitkarten und Gutscheinen, Berechnung der Einnahmen von Reitlehrern und ein Einblick für die Kunden eines Stalls in ihre eigenen Buchungen. Betrieben wird es von DF Daniel Fojcik, einem polnischen Einzelunternehmen (NIP 6472592229 / REGON 387798601, Marklowice), das unter Nose / horsenose firmiert.
• Unsere zwei Rollen. Für unsere eigenen Konto-, Analyse- und Sicherheitsdaten sind wir Verantwortlicher; für die Reiter-/Kundendaten, die ein Stall einträgt, handeln wir als Auftragsverarbeiter nach dessen Weisungen. Das Auftragsverarbeitungsverhältnis wird durch unseren Auftragsverarbeitungsvertrag (AVV) geregelt. Siehe „Compliance-Einordnung" unten.
• Was wir vorhalten. Konto-E-Mail-Adresse und optionaler Profilname/Telefonnummer; Einladungs-E-Mail-Adressen; die operativen Datensätze, die ein Stall über seine Reiter einträgt (Namen, Kontaktdaten, Unterrichtsteilnahme, Reitkarten/Gutscheine, Kennzeichnungen zur Zahlungsverfolgung, Freitextnotizen); mit bcrypt gehashte Kalender-PINs; mit SHA-256 gehashte Einladungstoken. Wir halten keine Zahlungskarten- oder Bankdaten und keine Gesundheitsdaten vor. Vollständige Übersicht in „Daten, die wir vorhalten" unten.
• Was die Daten schützt. TLS für den gesamten Datenverkehr mit HSTS-Preload; Verschlüsselung im Ruhezustand (AES-256); datenbankseitig erzwungene Row-Level-Security zur Isolierung jedes Stalls; serverseitige Sitzungsvalidierung; erneute Authentifizierung (Step-up) bei destruktiven und administrativen Aktionen; eine strikte Content-Security-Policy; Ratenbegrenzung und Bot-Schutz; sowie ein unveränderliches (append-only) Audit-Protokoll. Vollständige Liste in „Technische Maßnahmen" unten.
• Wo die Verarbeitung stattfindet. Über mehr als eine Region hinweg, und wir fügen mit unserem Wachstum weitere Regionen hinzu — die aktuelle primäre Region jedes Anbieters ist unter „Infrastruktur — wer betreibt was, und wo" unten aufgeführt und kann sich mit unserer Expansion ändern. Heute findet der Großteil der Kernverarbeitung im EWR statt (Datenbank, E-Mail-Versand, Analyse, Fehlerüberwachung und der Ratenbegrenzungsspeicher), wobei einige Komponenten bereits außerhalb liegen (Cloudflares globales Edge-Netzwerk; Google-Anmeldung und Teile von Stripe in den USA; Dodo Payments weltweit). Jeder regionsübergreifende Weg ist durch einen geeigneten Übermittlungsmechanismus abgesichert — das EU-US Data Privacy Framework, die Standardvertragsklauseln der EU, das UK-Addendum oder das gleichwertige Instrument, das eine hinzugefügte Region verlangt.
• Was uns noch fehlt. Keine SOC-2- oder ISO-27001-Zertifizierung, kein externer Penetrationstest, kein Bug-Bounty-Programm. Wenn Ihr Beschaffungsprozess heute eine SOC-2-Zertifizierung voraussetzt, sind wir noch nicht der richtige Anbieter für Sie.
• So erreichen Sie uns in Sicherheitsfragen. E-Mail an support@horsenose.eu mit `Security` in der Betreffzeile. Siehe „Reaktion auf Vorfälle (72-Stunden-Meldung von Verletzungen)" und „Verantwortungsvolle Offenlegung" unten.

2. Daten, die wir vorhalten

Wir erheben nur das Minimum, das für den Betrieb des Dienstes erforderlich ist. Die folgenden Kategorien sind die personenbezogenen Daten, die mit horsenose in Berührung kommen.

Was wir nicht vorhalten

• Keine Zahlungskarten- oder Bankdaten. horsenose ist niemals Partei einer Zahlung und verarbeitet niemals Kartendaten. Offline-Methoden („Bar“, „Reitkarte“, „Gutschein“, „Überweisung“) sind Kennzeichnungen zur Nachverfolgung, die ein Stall erfasst — keine Transaktionen, die horsenose ausführt. Sowohl bei der Abonnementabrechnung des Stalls (Stripe für polnische Ställe, Dodo Payments als Merchant of Record für nicht-polnische Ställe) als auch bei Online-Zahlungen von Reitern, wenn ein Stall diese aktiviert (Stripe, mit Abrechnung auf das eigene Konto des Stalls), werden die Kartendaten vollständig über die eigene Kasse des Zahlungsanbieters abgewickelt und erreichen uns nie — sodass wir außerhalb des Anwendungsbereichs von PCI DSS bleiben (siehe „Compliance-Einordnung" unten).
• Keine Ausweisdokumente oder Adressen. Wir erheben keine Wohnadressen, Ausweisnummern oder staatlichen Identifikatoren.
• Keine besonderen Kategorien personenbezogener Daten (Gesundheitsdaten). Wir beabsichtigen nicht, Daten nach Art. 9 DSGVO zu erheben, und das Produkt ist nicht darauf ausgelegt, solche zu speichern. Ställe werden (im AVV) angewiesen, keine besonderen Kategorien personenbezogener Daten in Freitextfelder einzutragen. Notizen zu einem Pferd betreffen ein Tier, keine Person, und fallen daher nicht unter die DSGVO.
• Keine Werbeprofile, Retargeting-Kennungen oder seitenübergreifendes Tracking. Keine Meta/LinkedIn/X/TikTok-Pixel; kein Browser-Fingerprinting.
• Keine Daten werden verkauft, vermietet oder an Dritte verliehen.
• Kein Training von KI-/ML-Modellen mit Ihren Daten. Wir trainieren, feinjustieren oder evaluieren kein KI- oder Machine-Learning-Modell mit personenbezogenen Daten aus horsenose. Die `pgvector`-Erweiterung ist in unserem Postgres für künftige interne Suchanwendungsfälle aktiviert, wird aber derzeit nicht mit aus personenbezogenen Daten abgeleiteten Embeddings befüllt.

3. Infrastruktur — wer betreibt was, und wo

horsenose ist eine Next.js-Anwendung, die auf Vercel gehostet wird, mit einer Supabase-Postgres-Datenbank im Hintergrund und einer kleinen Anzahl spezialisierter Anbieter („Unterauftragsverarbeiter“), von denen jeder einen eng begrenzten Ausschnitt übernimmt. Keiner von ihnen hat durchgängigen Zugriff auf alles. Wir laufen über mehr als eine Region hinweg und fügen mit unserem Wachstum weitere Regionen hinzu, daher beschreiben wir, wo die Dinge heute liegen, statt einen einzigen dauerhaften Standort zu versprechen: Der Großteil der Kernverarbeitung — Datenbank, E-Mail-Versand, Produktanalyse und Fehlerüberwachung — findet im EWR statt, während einige Komponenten bereits außerhalb laufen (Cloudflares globales Edge-Netzwerk; die optionale Google-Anmeldung und Teile von Stripe in den USA; Dodo Payments auf weltweiter Merchant-of-Record-Basis). Die aktuelle primäre Region jedes Anbieters steht in der Tabelle unten und wird bei Änderungen aktuell gehalten; jeder regionsübergreifende Weg ist durch einen geeigneten Übermittlungsmechanismus abgesichert (das EU-US Data Privacy Framework, die Standardvertragsklauseln, das UK-Addendum oder das gleichwertige Instrument, das eine hinzugefügte Region verlangt).

Die maßgebliche, stets aktuelle Fassung dieser Tabelle — mit anbieterbezogenen Kategorien personenbezogener Daten und Übermittlungsmechanismen — wird auf der Seite Unterauftragsverarbeiter gepflegt; die Datenschutzerklärung und der AVV verweisen auf dieselbe Quelle, anstatt abweichende Kopien vorzuhalten.

4. Technische Maßnahmen

Dies sind die Kontrollen, die heute tatsächlich vorhanden sind. Dies ist zugleich die inhaltliche Grundlage hinter dem AVV → „Vertraulichkeit, Sicherheit und Unterauftragsverarbeiter", der für unsere technischen und organisatorischen Maßnahmen auf diese Seite verweist.

Netzwerk und Übertragung

• TLS für den gesamten Datenverkehr, durchgesetzt von Vercel und Supabase. HSTS ist gesetzt mit `max-age=63072000; includeSubDomains; preload`.
• Keine gemischten Inhalte — die Content-Security-Policy lehnt `http://`-Ressourcen ab.

Mandantentrennung und Autorisierung

• Row-Level-Security (RLS), auf jeden Stall begrenzt, für jede operative Tabelle, durchgesetzt in der Datenbank selbst — die Daten eines Stalls können nicht von einem anderen gelesen werden, selbst wenn der Anwendungscode fehlerhaft wäre. Dies ist die primäre Verteidigung gegen mandantenübergreifenden Zugriff.
• Anwendungsseitige Rollenschranken (authentifiziert / stall-gebunden / Instructor-oder-Admin / Super-Admin) als zusätzliche Verteidigungsebene zur RLS, niemals als einzige Sicherung.
• Prüfungen auf Routenebene verlangen eine aktive Sitzung für geschützte Pfade und Super-Admin-Status für die Admin-Oberfläche.

Authentifizierung

• Passwortlose Anmeldung — E-Mail-Magic-Link (verwaltet von Supabase Auth) oder optionale Google-Anmeldung (OAuth). Es werden keine Passwörter gespeichert.
• Serverseitige Sitzungsvalidierung bei jeder geschützten Anfrage — dem Anmelde-Cookie allein wird nie vertraut.
• Erneute Authentifizierung (Step-up) für destruktive und administrative Aktionen — ein kurzlebiges, separat signiertes Step-up-Cookie ist erforderlich für Vorgänge wie Kontolöschung, Änderungen der letzten Admin-Rolle, Massendeaktivierung, Stallarchivierung und alle Super-Admin-Schreibvorgänge; ein fehlendes oder abgelaufenes Step-up führt zur Ablehnung (fail closed).
• Die Plattform-Admin-Oberfläche liefert 404, wenn kein Super-Admin konfiguriert ist, sodass ihre Existenz nicht offengelegt wird.

Geheimnisse und Zugangsdatenverwaltung

• Kalender-PINs werden als bcrypt-Hashes gespeichert; Einladungstoken werden als SHA-256-Hashes gespeichert — einmalig verwendbar, zeitlich begrenzt (7 Tage Gültigkeit) und an eine E-Mail-Adresse gebunden; Roh-Token werden nie dauerhaft gespeichert.
• Der Datenbank-Service-Role-Key ist ausschließlich serverseitig — er wird nie in Client-JavaScript eingebettet; ein Build-Time-Validator lässt den Build fehlschlagen, wenn eine sensible Variable falsch präfixiert ist.

Eingabe- und Ausgabeverarbeitung

• Schemavalidierung an jeder serverseitigen Eingabegrenze — clientseitige Validierung wird nur als UX behandelt; der Server ist die Vertrauensgrenze.
• Eine strikte Content-Security-Policy mit einem Nonce pro Anfrage, zusammen mit einem restriktiven Satz von Sicherheits-Headern (`X-Content-Type-Options`, `X-Frame-Options` / `frame-ancestors`, `Referrer-Policy`, Cross-Origin-Isolation-Header und eine restriktive `Permissions-Policy`).
• Automatisches Escaping der Ausgabe; von Nutzern verfasste Inhalte sind derzeit reiner Text.

Missbrauchs- und Bot-Schutz

• Ratenbegrenzung bei Anmeldung, Registrierung, Magic-Link, Einladungsannahme, Export/Löschung und weiteren sensiblen Endpunkten (je nach Aktion pro E-Mail, pro IP, pro Nutzer oder pro Stall; jede Richtlinie ist gezielt entweder fail-open oder fail-closed konzipiert).
• Cloudflare Turnstile-Bot-Schutz auf dem Anmeldeformular, dem Registrierungsformular, der Magic-Link-Anforderung, der Einladungsannahmeseite und der PIN-Eingabe des öffentlichen Kalenders.

Daten im Ruhezustand und Audit-Trail

• Verschlüsselung im Ruhezustand über Supabase (AES-256).
• Ein unveränderliches (append-only) Audit-Protokoll erfasst sicherheitsrelevante Ereignisse (Authentifizierung, Rollen- und Mitgliedschaftsänderungen, finanzielle Ereignisse, Exporte, Löschungen). Es wird immer geschrieben und ist von der operativen Telemetrie getrennt.
• Fehlerüberwachung mit Bereinigung personenbezogener Daten — bevor ein Fehler an Sentry gesendet wird, entfernt ein eigens entwickelter Bereinigungsmechanismus E-Mail-Adressen, Telefonnummern, Nachrichtentexte, Notizen und jedes Feld, das wie ein Token aussieht. Was übrig bleibt, ist technischer Kontext zusammen mit einer pseudonymen Nutzer-UUID, der Stall-Kennung, der Sprache und dem Namen des fehlgeschlagenen Vorgangs.

Backups und Wiederherstellung

• Supabase stellt automatisierte tägliche Backups bereit (7 Tage Aufbewahrung in der aktuellen Stufe; eine längere Aufbewahrung ist geplant, sobald der Dienst reift). Vercel behält frühere Deployments für ein nahezu sofortiges Rollback einer fehlerhaften Version vor.

5. Organisatorische Maßnahmen

• Einzelunternehmer. horsenose wird von einer Person betrieben (Daniel Fojcik). Derzeit gibt es keine Angestellten mit Produktionszugriff. Sollte sich dies ändern — etwa durch die Einbindung eines Auftragnehmers mit Produktionszugriff — wird diese Seite aktualisiert und aktive Ställe werden benachrichtigt.
• Produktionsdaten verbleiben auf verwalteter Infrastruktur. Produktions-Datenbankdumps werden nicht auf lokalen Rechnern gespeichert; die lokale Entwicklung nutzt eine separate Datenbank mit synthetischen Daten.
• Minimalprinzip für Dienstkonten. Der Datenbank-Service-Role-Key ist ausschließlich für den serverseitigen Einsatz vorgesehen; der Datenbankzugriff aus dem Browser erfolgt über einen eingeschränkten Schlüssel hinter der Row-Level-Security.
• Verwaltung von Geheimnissen. Geheimnisse befinden sich in der Umgebungskonfiguration des Hosting-Anbieters und in einer lokalen, von der Versionskontrolle ausgeschlossenen Datei — sie werden nie in das Repository übernommen. Produktionsgeheimnisse werden nicht auf lokale Rechner kopiert.
• Anbieterseitige Zugriffsprotokollierung. Administrative Aktionen bei unseren Anbietern werden von diesen protokolliert; wir prüfen sie anlassbezogen.
• Vertraulichkeit. Das Personal (derzeit der Inhaber) ist hinsichtlich der über den Dienst verarbeiteten personenbezogenen Daten zur Vertraulichkeit verpflichtet, wie im AVV festgehalten.
• Änderungsdisziplin. Codeänderungen durchlaufen vor der Bereitstellung eine strikte Typ-, Lint- und automatisierte Testprüfung, und Datenbankmigrationen werden vor der Produktivsetzung in einer Staging-Umgebung angewendet.

6. Reaktion auf Vorfälle (72-Stunden-Meldung von Verletzungen)

Überwachung. Fehler fließen an Sentry (mit der unter „Technische Maßnahmen" oben beschriebenen Bereinigung personenbezogener Daten); Diagnosedaten auf Anfrageebene sind in den Hosting-Protokollen verfügbar; ein Uptime-Monitor und Alarmierung bei erhöhter Fehlerrate sind Teil der Baseline-Härtung. Das unveränderliche Audit-Protokoll liefert eine dauerhafte Aufzeichnung sicherheitsrelevanter Ereignisse für Untersuchungen.

Unsere Verpflichtung zur Meldung von Datenschutzverletzungen. Kommt es zu einer Verletzung des Schutzes personenbezogener Daten, die voraussichtlich ein Risiko für die Rechte und Freiheiten betroffener Personen zur Folge hat, werden wir:

• Die zuständige Aufsichtsbehörde benachrichtigen — den Präsidenten der UODO in Polen — unverzüglich und, soweit möglich, innerhalb von 72 Stunden, nachdem uns die Verletzung bekannt wurde (Art. 33 DSGVO).
• *Besteht voraussichtlich ein hohes* Risiko für die betroffenen Personen, werden wir diese unverzüglich benachrichtigen und dabei die Art der Verletzung, die betroffenen Datenkategorien, die wahrscheinlichen Folgen und die ergriffenen Maßnahmen beschreiben (Art. 34 DSGVO**).
• Handeln wir als Auftragsverarbeiter für einen Stall, benachrichtigen wir diesen Stall (den Verantwortlichen) unverzüglich, damit er seinen eigenen Pflichten nach Art. 33/34 gegenüber seinen Reitern nachkommen kann.

Dies entspricht der Datenschutzerklärung und dem AVV. Es beschreibt, wie wir eine ohnehin durch die DSGVO auferlegte Pflicht umzusetzen beabsichtigen — es handelt sich nicht um ein zusätzliches vertragliches Versprechen über die DSGVO hinaus. Ein formal dokumentiertes Incident-Response-Runbook ist in Planung; bis dahin reagiert ein Ein-Personen-Team anlassbezogen innerhalb der oben genannten Fristen.

Kontakt. Nicht dringend: support@horsenose.eu. Sicherheit (dringend): E-Mail an support@horsenose.eu mit `Security` in der Betreffzeile.

7. Compliance-Einordnung

DSGVO (Verordnung 2016/679). horsenose agiert in einer doppelten Rolle: als Verantwortlicher für die Daten, deren Zwecke und Mittel es selbst festlegt (Besucher der Marketing-Website, die Konto-/Kontaktdaten von Stall-Administratoren und Reitlehrern, einwilligungsabhängige Produktanalyse sowie Sicherheits-/Missbrauchspräventionsdaten), und als Auftragsverarbeiter für die operativen Reiter-/Kundendaten, die ein Stall einträgt — dort ist der Stall Verantwortlicher, und horsenose verarbeitet nach dessen dokumentierten Weisungen gemäß AVV (Art. 28 DSGVO). Unterauftragsverarbeiter unterliegen Verträgen nach Art. 28 (AVV + SCCs/DPF, das UK-Addendum oder ein gleichwertiger Mechanismus, sofern eine Übermittlung Regionen überschreitet) — siehe die Seite Unterauftragsverarbeiter.

Daten von Kindern. Reitschulen unterrichten regelmäßig Kinder, daher verarbeitet horsenose wissentlich Daten Minderjähriger im Auftrag eines Stalls (zum Beispiel ein als Unterrichtsteilnehmer eingetragenes Kind, häufig durch einen Elternteil, der Kunde des Stalls ist). Der Stall ist verantwortlich für die Rechtsgrundlage und jede nach dem für ihn geltenden Recht erforderliche elterliche Einwilligung oder Befugnis (Art. 8 DSGVO in der EU und im Vereinigten Königreich; COPPA und bundesstaatliches Recht in den Vereinigten Staaten); horsenose minimiert die über ein Kind gespeicherten Daten und richtet sich nicht direkt an Kinder oder bewirbt diese nicht. Siehe die Datenschutzerklärung → „Datenschutz von Kindern".

Betroffenenrechte werden unterstützt, einschließlich des Self-Service-Zugriffs/der Datenübertragbarkeit über einen JSON-Export unter /account/export und der Löschung über /account/delete (eine 30-tägige, umkehrbare Karenzzeit und eine erneute Authentifizierung per Step-up gelten dabei; bei Löschung entfernen wir direkte Identifikatoren, statt hart zu löschen — Pseudonymisierung nach Art. 4 Abs. 5 DSGVO, keine vollständige Anonymisierung nach Erwägungsgrund 26; siehe die Aufbewahrungstabelle in der Datenschutzerklärung → „Wie lange wir Daten aufbewahren" für die Einzelheiten auf Feldebene). Für Reiterdaten ist der Stall Verantwortlicher, sodass ein Reiter seine Rechte gegenüber seinem Stall geltend macht und horsenose als Auftragsverarbeiter unterstützt.

PCI DSS — nicht anwendbar auf horsenose. Wir verarbeiten, speichern oder übermitteln keine Kartendaten. Bei der Abonnementabrechnung des Stalls wird der Kartendatenpfad vollständig vom Zahlungsanbieter über dessen gehostete Kasse abgewickelt — Stripe (Zahlungsdienstleister) für polnische Ställe, wobei horsenose als Händler auftritt, und Dodo Payments als Merchant of Record für nicht-polnische Ställe. Bei Online-Zahlungen von Reitern, wenn ein Stall diese aktiviert, werden die Daten von Karte, Wallet oder (in Polen) BLIK vollständig von Stripe (über Stripe Connect) abgewickelt und auf das eigene Stripe-Konto des Stalls abgerechnet — Verkäufer ist der Stall, und Stripe ist der PCI-konforme Zahlungsdienstleister, während horsenose lediglich Anweisungen weiterleitet und nie Kartendaten erhält. In jedem Fall erhält horsenose nie Kartendaten und bleibt außerhalb des PCI-Anwendungsbereichs.

EU-KI-Verordnung — nicht anwendbar. horsenose ist ein Betriebswerkzeug für Reitschulen; es trainiert, entwickelt oder betreibt keine KI-Modelle, und keine Komponente nutzt maschinelles Lernen oder generative KI zur Verarbeitung personenbezogener Daten. Die Postgres-Erweiterung `pgvector` ist für mögliche künftige interne Suchanwendungsfälle aktiviert, wird aber heute nicht mit aus personenbezogenen Daten abgeleiteten Embeddings befüllt; sollte sich dies ändern, werden wir vor Einführung der Funktion eine Position zur EU-KI-Verordnung und eine Verpflichtung „kein Training mit personenbezogenen Daten“ veröffentlichen.

ePrivacy / Cookies. Optionale Analyse (PostHog) wird nur mit Einwilligung geladen; unbedingt erforderliche Cookies sind nach Art. 5 Abs. 3 der ePrivacy-Richtlinie ausgenommen. Siehe die Cookie-Richtlinie.

8. Verantwortungsvolle Offenlegung

Wenn Sie glauben, eine Sicherheitslücke in horsenose gefunden zu haben:

• Schreiben Sie eine E-Mail an [support@horsenose.eu](mailto:support@horsenose.eu) mit `Security` in der Betreffzeile. (Eine dedizierte `security@`-Adresse und ein PGP-Schlüssel sind geplant.)
• Fügen Sie ausreichend Details bei, um das Problem nachvollziehen zu können.
• Geben Sie uns einen angemessenen Zeitraum zur Untersuchung und Behebung, bevor Sie das Problem öffentlich machen.

Was Sie von uns erwarten können:

• Eine Bestätigung und eine erste Einschätzung, sobald dies vernünftigerweise möglich ist. horsenose wird von einer einzelnen Person betrieben und kann keine Antwort am selben Tag garantieren; wir lassen einen glaubwürdigen Bericht jedoch nicht unbeachtet.
• Statusaktualisierungen in angemessenen Abständen, während das Problem geprüft oder behoben wird.
• Nennung in einer Offenlegung nach der Behebung, falls von Ihnen gewünscht (optional).

Was wir derzeit nicht anbieten können: Wir zahlen in diesem Stadium keine finanziellen Bug-Bounties. Wir werden dies klar mitteilen, sobald ein Bounty-Programm verfügbar wird.

Umfang und sicherer Hafen. Sicherheitsforschung in gutem Glauben, die dieser Richtlinie folgt, sich auf Ihre eigenen Konten beschränkt, den Dienst für andere nicht beeinträchtigt und nicht auf andere Daten als Ihre eigenen zugreift, wird nicht als Verstoß gegen unsere Richtlinie zur zulässigen Nutzung oder unsere Nutzungsbedingungen gewertet. Versuchen Sie nicht, auf die Daten eines anderen Stalls oder eines anderen Reiters zuzugreifen, und führen Sie kein automatisiertes Scraping oder Denial-of-Service-Testing gegen den Dienst durch.

9. Änderungsprotokoll