NIS2 und DORA auf WordPress: was eine Website 2026 erfüllen muss
Zwei EU-Rechtsakte definieren 2026, was aus Sicht der Cybersicherheit von einer WordPress-Website verlangt wird, die in der Union einer regulierten Tätigkeit nachgeht: die NIS2-Richtlinie (2022/2555) und die DORA-Verordnung (2022/2554). Sie sind nicht austauschbar. NIS2 ist eine Richtlinie mit breitem sektoralen Anwendungsbereich, die in nationales Recht umzusetzen ist. DORA ist eine sektorale Verordnung (Finanzwesen), die unmittelbar gilt. Beide gelten für WordPress nur dann, wenn der Betreiber der Website in den Anwendungsbereich fällt.
Der Artikel verbindet sich mit dem Pillar zu Headless-WordPress-Leistungen, wo die technische Schicht beschrieben ist, und mit dem Pillar zu WCAG, BFSG und EAA, denn Barrierefreiheits- und Cybersicherheits-Konformität landen zunehmend in derselben Beschaffungsanfrage.
TL;DR
- NIS2-Umsetzungsfrist: 2024-10-17. DORA gilt seit 2025-01-17.
- NIS2: 18 Sektoren, Aufteilung in wesentliche und wichtige Einrichtungen.
- DORA: Finanzsektor plus kritische IKT-Dienstleister.
- Anforderungen: dokumentiertes Risikomanagement, Vorfallsmeldungen (24/72/30), Audits.
- WordPress selbst fällt nicht in den Anwendungsbereich; in den Anwendungsbereich fällt der Betreiber der Website, sofern er reguliert ist.
Drei Punkte, die sofort zu wissen sind
Erstens, NIS2 und DORA gelten für den Akteur, nicht für die Technologie. WordPress ist als CMS weder “compliant” noch “non-compliant”. Compliant oder nicht ist die Einrichtung, die die Website betreibt. Wenn ein Krankenhaus, eine Bank, ein Cloud-Anbieter oder ein E-Commerce-Betreiber oberhalb des Schwellenwerts in den Anwendungsbereich fällt, dann fällt auch die WordPress-Website als Teil der Infrastruktur dieser Einrichtung darunter.
Zweitens, die nationale Umsetzung von NIS2 ist in vielen Mitgliedstaaten verzögert. Die Frist 2024-10-17 ist abgelaufen, aber mehrere Länder befanden sich auch danach noch in unterschiedlichen Phasen des Gesetzgebungsverfahrens. Der Umsetzungsstand variiert zwischen den Mitgliedstaaten; vor dem finalen Audit ist die jeweilige nationale Rechtsdatenbank zu prüfen. Der deutsche Stand zum NIS2-Umsetzungsgesetz ist gesondert unter gesetze-im-internet.de zu verifizieren. Für den polnischen Mitgliedstaaten-Stand ist der Entwurf zur Änderung des Gesetzes über das nationale Cybersicherheitssystem öffentlich zugänglich und sein aktueller Stand ist im ISAP zu verifizieren. Der Stand zum 2026-04 erfordert eine eigene rechtliche Prüfung; dieser Artikel ersetzt keine Rechtsberatung.
Drittens, DORA gilt unmittelbar. Die Verordnung verlangt keine Umsetzung. Wenn eine Finanzeinrichtung oder ein kritischer IKT-Dienstleister eine WordPress-Website betreibt, gelten die DORA-Pflichten ab 2025-01-17 unabhängig von einem nationalen Gesetzgebungsstand.
NIS2: Anwendungsbereich
Die NIS2-Richtlinie nennt 18 Sektoren. Die häufigsten Fälle, in denen WordPress in den Anwendungsbereich fällt:
Wesentliche Einrichtungen (essential entities):
- Energie (Strom, Gas, Öl, Wärme, Wasserstoff).
- Verkehr (Luft, Schiene, Wasser, Straße).
- Bankwesen.
- Finanzmarktinfrastrukturen.
- Gesundheitssektor (Krankenhäuser, Referenzlabore, Arzneimittelhersteller, Medizinprodukte).
- Trinkwasser und Abwasser.
- Digitale Infrastruktur (DNS-Anbieter, Domain-Registrierungsstellen, Cloud-Computing-Anbieter, Rechenzentrumsdienstleister, Content Delivery Networks, Vertrauensdiensteanbieter, Anbieter öffentlicher elektronischer Kommunikationsnetze).
- Verwaltung von IKT-Diensten (B2B).
- Öffentliche Verwaltung (Bedingungen gemäß Artikel 2).
- Weltraum.
Wichtige Einrichtungen (important entities):
- Post- und Kurierdienste.
- Abfallwirtschaft.
- Herstellung, Verarbeitung und Vertrieb von Chemikalien.
- Herstellung, Verarbeitung und Vertrieb von Lebensmitteln.
- Herstellung in den Sektoren: Medizin, Computer und Elektronik, Maschinenbau, Automobil.
- Anbieter digitaler Dienste (Online-Marktplätze, Suchmaschinen, soziale Plattformen).
- Forschungseinrichtungen.
Grundschwelle: mittleres Unternehmen (50+ Beschäftigte oder Jahresumsatz oder Bilanzsumme über 10 Mio. EUR). Kleinst- und Kleinunternehmen sind in der Regel nicht im Anwendungsbereich, mit Ausnahmen (z. B. Vertrauensdiensteanbieter, TLD-Registrierungsstellen, bestimmte DNS-Anbieter).
Eine wesentliche Einrichtung hat strengere Pflichten. Eine wichtige Einrichtung hat dieselben technischen Anforderungen, aber mit weniger intensiver Aufsicht.
DORA: Anwendungsbereich
DORA gilt für rund 20 Arten von Finanzeinrichtungen:
- Kreditinstitute.
- Zahlungsinstitute.
- E-Geld-Institute.
- Wertpapierfirmen.
- Anbieter von Krypto-Dienstleistungen.
- Zentralverwahrer.
- Zentrale Gegenparteien.
- Handelsplätze (Börsen).
- Transaktionsregister.
- Versicherungs- und Rückversicherungsunternehmen.
- Versicherungs- und Rückversicherungsvermittler.
- Einrichtungen der betrieblichen Altersversorgung.
- Ratingagenturen.
- Prüfer von Jahresabschlüssen der unter DORA fallenden Einrichtungen.
- Administratoren kritischer Referenzwerte.
- Investmentfonds (OGAW, AIFM).
- Crowdfunding-Dienstleister.
- Verbriefungsregister.
Hinzu kommen kritische IKT-Drittanbieter (Critical ICT Third-Party Providers, CTPP), die von der europäischen Aufsicht benannt werden. Das ist der Mechanismus, über den DORA Geschäftspartner in seinen Anwendungsbereich zieht, ohne dass diese sich selbst als Finanzeinrichtung registrieren müssten.
Eine WordPress-Website, die von einer Bank, einem Versicherer oder einem Investmentfonds betrieben wird, fällt als Teil der IKT-Systeme der Einrichtung in den Anwendungsbereich von DORA.
Was konkret zu tun ist: der gemeinsame Kern
NIS2 und DORA haben einen konvergenten Kern technischer und organisatorischer Anforderungen. Umsetzung auf WordPress:
Cyber-Risikomanagement. Dokumentiertes Risikoregister, Verfahren zur Risikobewertung und -akzeptanz, vom Vorstand genehmigte Sicherheitsrichtlinien. Das sind Dokumente, nicht nur Serverkonfiguration.
Zugriffskontrolle und Authentifizierung. Multi-Faktor-Authentifizierung (MFA) für WordPress-Administratoren erforderlich. Starke Passwörter erforderlich. Sitzungsbeendigung erforderlich. Alle Administrator-Konten müssen personenbezogen sein, nicht geteilt.
Vorfallsmanagement. Verfahren zur Erkennung, Klassifizierung und Meldung von Vorfällen. Ein wesentlicher Vorfall im Sinne von NIS2 ist ein Vorfall mit erheblichen Auswirkungen auf die Diensterbringung. Meldung an das CSIRT oder die zuständige Behörde innerhalb von 24 Stunden nach Feststellung (Frühwarnung), in 72 Stunden mit erster Bewertung, in einem Monat mit Abschlussbericht.
Sicherheit der Lieferkette. Ein WordPress-Plugin, Hosting, CDN, Anbieter für transaktionale E-Mails, SMS-Anbieter, KI-Anbieter. Jeder davon ist Teil der Kette. Es braucht ein Register, Risikobewertungen und Vertragsklauseln.
Geschäftskontinuität und Notfallwiederherstellung. Backup, Kontinuitätsplan, Notfallwiederherstellung, regelmäßig getestet, nicht nur durchgeführt.
Personalschulungen. Erforderlich auf Vorstandsebene und in der breiteren Organisation. Eine “interne Präsentation” reicht nicht; ein dokumentierter Schulungsplan ist erforderlich.
Sicherheit im Entwicklungs- und Wartungsprozess. Richtlinien für Softwareentwicklung, Tests und Schwachstellenmanagement. WordPress-Core wird aktualisiert; Plugins müssen es ebenfalls werden, mit Tests auf Staging vor der Produktion.
Kryptografie. Eine Kryptografierichtlinie, einschließlich TLS, Verschlüsselung von Daten im Ruhezustand, digitale Signaturen. WordPress verschlüsselt die Datenbank standardmäßig nicht; die Lösung ist Verschlüsselung auf Dateisystem- oder Datenbankebene.
DORA-spezifisch: Management von IKT-Drittanbietern
DORA enthält einen Abschnitt in Kapitel V, der dem Management von IKT-Drittanbietern gewidmet ist. Erforderlich sind:
- Ein Register aller Verträge mit IKT-Anbietern.
- Klassifizierung der Verträge (kritisch, nicht kritisch).
- Verbindliche Vertragsklauseln in Verträgen mit Anbietern kritischer Funktionen.
- Beendigungsverfahren mit Migrationsplan.
- Bedrohungsorientierte Penetrationstests (TLPT) mindestens alle 3 Jahre für ausgewählte Einrichtungen.
Für einen WordPress-Betreiber bedeutet dies, dass der Hosting-Anbieter und kritische Plugins (Security-Plugin, Backup-Plugin, Payment-Gateway-Plugin) in das IKT-Register aufgenommen werden.
NIS2-spezifisch: Sanktionen und Aufsicht
Die NIS2-Richtlinie sieht administrative Sanktionen vor, die die nationalen Umsetzungen in konkrete Beträge übersetzen. Die Obergrenzen in der Richtlinie selbst:
- Wesentliche Einrichtung: bis zu 10 Mio. EUR oder 2 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Wert höher ist.
- Wichtige Einrichtung: bis zu 7 Mio. EUR oder 1,4 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Wert höher ist.
Nationale Umsetzungen können eigene Obergrenzen einführen; in der jeweils aktuellen Fassung des Gesetzes der zuständigen Jurisdiktion zu prüfen.
Ergänzende Sanktionen: vorübergehende Aussetzung der Zertifizierung, vorübergehende Verbote der Wahrnehmung von Leitungsfunktionen für die verantwortliche Person. Letzteres ist die auffälligste Änderung in NIS2: die Geschäftsleitung trägt persönliche Verantwortung für das Cyber-Risikomanagement.
Artikel 20 der NIS2-Richtlinie verankert das direkt: die Leitungsorgane müssen die Maßnahmen zum Cyber-Risikomanagement genehmigen, ihre Umsetzung überwachen und an entsprechenden Schulungen teilnehmen. Die deutsche Umsetzung erfolgt über das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) mit dem Bundesamt für Sicherheit in der Informationstechnik (BSI) als zentraler Aufsichtsbehörde. In der Praxis trifft die persönliche Verantwortung nicht nur den Vorstand, sondern auch die operative Führungsebene, die in den NIS2-Geltungsbereich fallende Bereiche verantwortet: IT-Direktor, CISO, Konformitäts-Leiter, Datenschutzbeauftragter und Operations-Direktor. Für eine WordPress-Agentur verschiebt das den Adressaten der Lieferung auf der Kundenseite: Risikoregister, Incident-Runbook und Lieferantenverzeichnis müssen von dieser breiteren Führungsebene abgenommen werden, in einer Form, die einer Prüfung durch das BSI standhält.
Praktische Umsetzungslandkarte für WordPress
Vier Arbeitsbereiche, ein Audit:
Schicht 1, Infrastruktur. Konformes Hosting. Off-Site-Backup. TLS 1.3. WAF. 24/7-Monitoring oder SOC-Vertrag. Update-Richtlinie für Core, Themes, Plugins.
Schicht 2, Anwendung. MFA für Administratoren. Starke Passwörter. Protokollierung aller administrativen Aktionen in einen separaten Stream. Anti-CSRF. Anti-XSS auf Template-Ebene. Eingabevalidierung. Begrenzung der Anmeldeversuche.
Schicht 3, Organisation. Sicherheitsrichtlinien. Risikoregister. IR-Plan. BCDR-Plan. IKT-Anbieter-Register. Verfahren zur Meldung von Vorfällen an CSIRT/Aufsicht. Schulungen.
Schicht 4, Dokumentation und Audit. Prozessdokumentation. Audit-Logs. Periodisches externes oder internes Audit. DSGVO-konforme Aufbewahrung.
WordPress als CMS deckt etwa 30 Prozent der technischen Anforderungen “out of the box” ab, nach Hardening und Plugins etwa 60 Prozent. Die verbleibenden 40 Prozent sind Organisation, Dokumentation und Verfahren.
Geltungsbereich vor der technischen Arbeit klären
Die Einordnung beginnt beim Rechtsträger, nicht beim CMS. Dokumentieren Sie Tätigkeit, Sektor, Größe, betroffene Jurisdiktionen, Konzernbeziehungen sowie eine mögliche Benennung oder Registrierung durch die zuständige Behörde. Zu unterscheiden sind eine wesentliche oder wichtige Einrichtung nach nationaler NIS2-Umsetzung, ein DORA-Finanzunternehmen, ein IKT-Drittanbieter und ein nicht direkt erfasstes Unternehmen mit vertraglichen Pflichten gegenüber einem regulierten Kunden. Nationale Definitionen und der aktuelle Umsetzungsstand brauchen eine juristische Prüfung für die jeweilige Jurisdiktion.
Anschließend wird die WordPress-Systemgrenze beschrieben: Produktion und Staging, Hosting, DNS, CDN, WAF, Identitätsdienst, Quellcodeverwaltung, CI/CD, Backup, Monitoring, E-Mail, Consent-Lösung, Zahlungsanbindung und Support-Zugänge. Ordnen Sie jeder Abhängigkeit die unterstützte Geschäftsleistung und die Folgen eines Verlusts von Vertraulichkeit, Integrität oder Verfügbarkeit zu. Eine öffentliche Informationsseite und ein angemeldetes Kundenportal können dieselbe Installation nutzen, aber eine völlig andere Kritikalität haben.
Das Ergebnis ist eine freigegebene Umfangsnotiz mit Annahmen, Ausschlüssen, offenen Fragen und benanntem Risikoeigentümer. Sie ist keine Aussage, dass die Organisation NIS2 oder DORA erfüllt.
Artikel, Kontrollen und Nachweise verbinden
Ein belastbares Readiness-Programm verknüpft Pflicht, Kontrollziel, Eigentümer und Beleg. Bei NIS2 betrifft Artikel 20 Genehmigung, Überwachung und Schulung der Leitungsorgane, Artikel 21 die Maßnahmen zum Cyber-Risikomanagement und Artikel 23 die Meldung erheblicher Sicherheitsvorfälle. Registrierung, Aufsicht, Sanktionen und Verfahrensdetails ergeben sich aus dem anwendbaren nationalen Recht.
Bei DORA sollten IKT-Risikomanagement nach Artikeln 5 bis 16, Vorfallsmanagement und Meldung nach Artikeln 17 bis 23, Resilienztests nach Artikeln 24 bis 27 und IKT-Drittparteirisiko nach Artikeln 28 bis 44 getrennt betrachtet werden. Nicht jede Vorschrift wird zu einer Einstellung in WordPress. Viele Maßnahmen liegen auf Ebene von Unternehmen, Governance, Vertrag oder Gesamtarchitektur.
Eine Nachweismatrix kann folgende Spalten führen:
- Rechtsquelle und gegebenenfalls einschlägige nationale Vorschrift;
- Kontrollziel und geschützte Geschäftsleistung oder Risiko;
- verantwortlicher Eigentümer und ausführende Rolle;
- Umsetzungsort, etwa Identitätsdienst, Hosting, WordPress oder SOC;
- Nachweisartefakt, Ablageort und Prüfkadenz;
- letzter Test, Ergebnis, Ausnahme, Reparaturverantwortlicher und Zieltermin.
Geeignete Belege sind unter anderem Managementfreigaben, aktuelle Asset- und Lieferantenregister, Zugriffsprüfungen, Wiederherstellungstests, Schwachstellen-Tickets, Change-Freigaben, Monitoring-Alarme, Übungsberichte und vereinbarte Lieferantenklauseln. Ein Screenshot eines Security-Plugins kann eine einzelne technische Kontrolle stützen, aber kein Risikomanagementsystem belegen.
Vorfallsbereitschaft auf Programmebene
Dieser Pillar wiederholt nicht das detaillierte NIS2-Meldeverfahren für 24 Stunden, 72 Stunden und einen Monat. Auf Programmebene muss feststehen, dass Monitoring-Signale eine benannte Bereitschaftsrolle erreichen, ein Ereignis von einem möglicherweise erheblichen Vorfall unterschieden werden kann und technische Helfer Zeitpunkte, betroffene Dienste, Indikatoren, Maßnahmen und Geschäftsauswirkung sichern, ohne die Eindämmung zu verzögern.
WordPress-nahe Quellen sind Webserver- und WAF-Ereignisse, Anmelde- und Administratoraktionen, Dateiintegritätsänderungen, Deployment-Verlauf, Datenbankaktivität, auffälliger E-Mail-Versand sowie Meldungen von Host oder CDN. Protokolle werden vor beiläufiger Änderung geschützt und Zeitquellen angeglichen. Aufbewahrung und Erhebung müssen zugleich Datenschutzvorgaben berücksichtigen; unbegrenztes Speichern ist keine gute Sicherheitskontrolle.
Eine Tabletop-Übung kann ein kompromittiertes Administratorkonto, ein schädliches Plugin-Update oder einen ausgefallenen Checkout durchspielen. Geprüft wird, wer den Vorfall ausruft, Meldepflicht bewertet, Kunden und Lieferanten informiert und die Abschaltung autorisiert. Die formale Entscheidung zur Behördenmeldung bleibt bei der dafür bestimmten Rolle der Organisation.
Lieferantenkontrollen für die WordPress-Kette
Das Abhängigkeitsregister umfasst mehr als Anbieter mit einer Rechnung. Hosting, DNS, CDN, Support, Plugins, Themes, Zahlung, E-Mail, Analytics, Identität, Backup-Speicher und Quellcodeplattform können die Leistung beeinflussen. Erfassen Sie Eigentümer, Daten und Zugriffe, unterstützten Dienst, Kritikalität, Unterauftragnehmer, Betriebsort, Meldeweg, Wiederherstellungserwartung, Vertragsende und einen realistischen Ausstieg.
Die Prüfung muss verhältnismäßig sein. Zahlungsanbindung und Managed Hosting verdienen mehr Tiefe als ein nicht ausführbares Design-Asset. Vertrag und Betriebsprozess sollten bei Vorfallmeldung, Schwachstellenbehandlung, Zugriff, Prüfunterlagen, Kontinuität, Datenrückgabe oder -löschung und Kündigungshilfe zusammenpassen. Die rechtliche Prüfung DORA-spezifischer Klauseln gehört zu Beschaffung und Rechtsberatung. Der Leitfaden zu DORA Artikel 28 und das DORA-Informationsregister behandeln diese Arbeitsergebnisse im Detail.
Das technische Team braucht dennoch einen ausführbaren Exit. Quellcode, Konfiguration, Inhalte, Medien, DNS-Einträge, Zertifikate, Backups und nötige Lizenzen müssen übertragbar oder reproduzierbar sein. Wo es die Risikobewertung verlangt, wird die Wiederherstellung außerhalb der primären Umgebung getestet.
Abnahme und laufende Steuerung
Readiness braucht eindeutige Abnahmekriterien. Alle erfassten Assets und Lieferanten haben Eigentümer; privilegierte Konten sind personenbezogen und geprüft; MFA und Wiederherstellungswege wurden getestet; unterstützte Software hat einen Update- und Notfall-Patchprozess; Hochrisikobefunde sind entschieden; Backups erreichen beim Restore das vereinbarte Ziel; Monitoring alarmiert die Reaktionsrolle; und Maßnahmen aus der Vorfallsübung werden bis zum Abschluss verfolgt. Ausnahmen benötigen Risikoeigentümer, Begründung, Ersatzkontrolle und Ablaufdatum.
Die Managementabnahme erhält eine knappe Risikosicht mit Verweisen auf Belege, keine Liste von Plugin-Einstellungen. Im Betrieb werden privilegierte Zugriffe, Lieferanten, Schwachstellen, Restore-Ergebnisse, Vorfälle und Ausnahmen nach festgelegter Kadenz geprüft. Nach Übernahmen, neuen regulierten Leistungen, einem Hostingwechsel oder einer wesentlichen Neugestaltung wird der Umfang neu bewertet. Reaktions- und Wiederherstellungsabläufe werden geübt und die Ergebnisse samt Nachbesserung aufbewahrt.
Diese Maßnahmen verbessern Betriebsbereitschaft und Prüfbarkeit. Sie garantieren weder Konformität noch Vorfallsfreiheit und entscheiden nicht, ob eine Behörde ein Ereignis als erheblich einstuft. Rechtsauslegung, Behördenmeldung und formale Assurance bleiben bei entsprechend qualifizierten Rollen.
Schriftliches Readiness-Briefing senden
Für eine abgegrenzte technische und evidenzbezogene Prüfung nutzen Sie den NIS2- und DORA-Readiness-Service für WordPress. Schicken Sie eine schriftliche Kurzbeschreibung mit Rechtsträgern und Zieljurisdiktionen, vorhandener Umfangseinschätzung, Produktions- und Staging-URLs, den durch WordPress unterstützten Geschäftsleistungen, Hosting- und Deployment-Modell, Administrator- und Lieferantenmodell, vorhandenen Richtlinien oder Prüfberichten, bekannten Terminen sowie den Verantwortlichen für Risiko, Sicherheit und Beschaffung. Zugangsdaten und sensible Vorfallsbelege gehören nicht in die erste Nachricht.
Das erste Ergebnis sollte Systemgrenze, Nachweislücken und eine priorisierte Umsetzungsliste festhalten. Es ist weder Rechtsgutachten noch Zertifizierung. Ist der Geltungsbereich ungeklärt, liefern technisches Inventar und Abhängigkeitskarte konkrete Tatsachen für Rechtsberatung und Managemententscheidung.
Wie es weitergeht
Praktische Konsequenzen für die Wahl des WordPress-Teams: eine Agentur, die die Website für eine unter NIS2 oder DORA fallende Einrichtung betreibt, tritt selbst in die Lieferkette ein. Unsere Karriereseite nennt EU-Jurisdiktion und Konformität als Standard, weil dies 2026 ein Beschaffungsfilter ist.
Vertiefende Artikel in diesem Cluster
Fünf praxisorientierte Vertiefungen liegen unter diesem Pillar; jede behandelt eine operative Delta, die ein reguliertes WordPress-Mandat tatsächlich liefern muss:
- NIS2 Anhang II für WordPress-Agenturen: Geltungsbereich, Fristen, Nachweispfad
- NIS2 Incident-Meldepflicht WordPress: 24 Stunden, 72 Stunden, ein Monat
- DORA Artikel 28 IKT-Drittparteirisiko: WordPress-Hosting und WAF-Lieferantenprüfung
- DORA Informationsregister für WordPress-Lieferanten: Pflichtfelder
- NIS2 vs DORA Geltungsbereich-Überschneidung für WordPress-Agenturen 2026
- WordPress-Vorfallsreaktion unter NIS2: 24-Stunden-Frühwarnungs-Playbook
Wo dieser Artikel hingehört
Der Artikel verbindet sich mit dem Pillar zu Headless-WordPress-Leistungen (technische Schicht), dem Pillar zu WCAG/BFSG/EAA (Barrierefreiheits-Konformität auf demselben Beschaffungs-Scoreboard), dem EU-Konformitätsaudit für WordPress (ein konsolidiertes Audit für EAA, NIS2/DORA und AI Act), der Karriereseite von WPPoland (Signal EU-Jurisdiktion) und dem Artikel zu Nearshore Polen (EU-Jurisdiktion als Wert für den westlichen Käufer).
