Digitaler Samba Blog Deutsch

NIS2 und Videokonferenzen: Anforderungen & Checkliste

Geschrieben von Nina Benkotic | September 29, 2026

Der Krisen-Call ist meist das Erste, worauf es ankommt, wenn ein Sicherheitsvorfall beginnt – und oft das Letzte, was jemand sicherheitstechnisch geprüft hat. Unter NIS2 ist diese Lücke ein Prüfungsbefund. Ist Ihre Organisation eine besonders wichtige oder wichtige Einrichtung, benennt die Richtlinie gesicherte Videokommunikation ausdrücklich: Dieselben Erwartungen an Verschlüsselung, Zugriffskontrolle und Resilienz, die für den Rest Ihrer Infrastruktur gelten, decken nun auch die Plattform ab, auf der Ihr Incident-Response-Team arbeitet – und ein schwerwiegender Ausfall dieser Plattform kann selbst meldepflichtig werden.

Inhaltsverzeichnis

  1. Was ist NIS2?
  2. Umsetzung in Deutschland: das NIS2UmsuCG und das BSI
  3. Warum NIS2 Videokommunikation erfasst
  4. Fällt Ihr Videokonferenz-Anbieter selbst unter NIS2?
  5. Die Anforderungen an gesicherte Kommunikation für Videokonferenzen
  6. NIS2 vs. CRA vs. DORA: Was gilt für Ihr Video-Tool?
  7. Checkliste: Ist Ihr Videokonferenz-Tool NIS2-bereit?
  8. Sanktionen bei Nichteinhaltung
  9. Wie Digital Samba gesicherte NIS2-Kommunikation unterstützt
  10. FAQ

Was ist NIS2?

NIS2 ist die Richtlinie (EU) 2022/2555, das überarbeitete Cybersicherheitsrecht der EU, förmlich angenommen am 14. Dezember 2022 und am 27. Dezember 2022 im Amtsblatt veröffentlicht (Europäisches Parlament und Rat der Europäischen Union, 2022a). Sie ersetzte die ursprüngliche NIS-Richtlinie von 2016, erweiterte die Liste der erfassten Sektoren von 7 auf 18 und verpflichtete die Mitgliedstaaten, sie bis zum 17. Oktober 2024 in nationales Recht umzusetzen, mit Geltung der Pflichten ab dem Folgetag.

Die Richtlinie setzt eine Grundlinie an Risikomanagementmaßnahmen für die Cybersicherheit und Meldepflichten für „besonders wichtige" und „wichtige" Einrichtungen über zwei Sektorgruppen hinweg. Die erste Gruppe umfasst Energie, Verkehr, Bankwesen, Finanzmarktinfrastrukturen, Gesundheit, Trinkwasser, Abwasser, digitale Infrastruktur, Verwaltung von IKT-Diensten, öffentliche Verwaltung und Weltraum: insgesamt 11 Sektoren. Die zweite Gruppe umfasst Post- und Kurierdienste, Abfallwirtschaft, Chemie, Lebensmittel, die Herstellung kritischer Produkte, digitale Anbieter und Forschungseinrichtungen: weitere sieben, was in Summe 18 ergibt. „Digitale Anbieter" meint hier Online-Marktplätze, Suchmaschinen und Plattformen sozialer Netzwerke – eine engere Kategorie als die Betreiber digitaler Infrastruktur der ersten Gruppe.

In welche Kategorie eine Organisation fällt, ist nicht nur eine Frage der Liste, auf der sie steht. Innerhalb der ersten Gruppe entscheidet die Größe. Artikel 2 übernimmt die Standard-Größendefinitionen der EU, und diese funktionieren nicht wie ein einzelner Test aus „Beschäftigte oder Umsatz". Die Beschäftigtenzahl ist eine eigene Bedingung, und die beiden Finanzkennzahlen sind Alternativen zueinander. Eine Organisation gilt als mittelgroß, wenn sie weniger als 250 Beschäftigte hat und entweder einen Umsatz von höchstens 50 Mio. € oder eine Bilanzsumme von höchstens 43 Mio. € aufweist – und als groß, sobald sie diese Obergrenzen überschreitet. Unterhalb der Kleinstunternehmens-Schwelle, also weniger als 50 Beschäftigte mit Umsatz oder Bilanzsumme von höchstens 10 Mio. €, fällt eine Einrichtung in der Regel ganz aus NIS2 heraus. Artikel 3 wendet diese Größenklassen dann innerhalb der ersten Gruppe an: Große Organisationen gelten als besonders wichtig (essenziell), mittelgroße als wichtig. Die beiden Teile greifen an den Rändern unschön ineinander, daher sollte sich eine Grenzfall-Organisation an den Definitionen prüfen, statt von einer einzelnen Kennzahl abzuleiten.

Einrichtungen der zweiten Gruppe werden anders behandelt: Jede von ihnen gilt standardmäßig als wichtig, unabhängig von der Größe.

Hier gibt es eine Unterscheidung, die mehr wiegt, als sie klingt: NIS2 ist eine Richtlinie, keine Verordnung. Die in diesem Beitrag durchgehend zitierten Artikelnummern sind nicht selbst das Recht, das Sie einhalten müssen. Eine Richtlinie setzt ein Ziel, das jeder Mitgliedstaat in seine eigene nationale Gesetzgebung umsetzt – und es ist dieser nationale Umsetzungsakt, nicht der Richtlinientext, den eine Aufsichtsbehörde oder ein Prüfer auf Sie anwendet. Die Umsetzung verlief uneinheitlich: Mehrere Mitgliedstaaten arbeiteten weit über die Frist vom Oktober 2024 hinaus daran. NIS2 läuft zudem über ein Selbstidentifizierungsmodell: Sobald Sie ermittelt haben, wo Sie stehen, wird von Ihnen erwartet, dass Sie Ihren Status bei Ihrer zuständigen nationalen Behörde registrieren, statt darauf zu warten, informiert zu werden. Bestätigen Sie sowohl diese Behörde als auch den auf Sie anwendbaren nationalen Rechtsakt, bevor Sie alles andere in diesem Artikel als gesichert behandeln.

Zwei Dinge unterscheiden NIS2 von der DSGVO, die viele Compliance-Teams bereits gut kennen. Erstens geht es um die Sicherheit von Netz- und Informationssystemen und nicht speziell um personenbezogene Daten, auch wenn sich beide Regime überschneiden, sobald Videocalls personenbezogene Daten übertragen. Zweitens führt NIS2 eine direkte, persönliche Verantwortlichkeit der Leitungsorgane ein (Artikel 20), zusammen mit Bußgeldern, die mit dem weltweiten Umsatz skalieren (Artikel 34).

Umsetzung in Deutschland: das NIS2UmsuCG und das BSI

Für Organisationen in Deutschland ist nicht die Richtlinie selbst maßgeblich, sondern das deutsche Umsetzungsgesetz. Deutschland setzt NIS2 mit dem NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) um, das die Vorgaben in nationales Recht überführt – unter anderem durch Änderungen am BSI-Gesetz (BSIG). Zuständige Behörde ist das Bundesamt für Sicherheit in der Informationstechnik (BSI), bei dem sich betroffene Einrichtungen registrieren. Das deutsche Recht spricht dabei von „besonders wichtigen Einrichtungen" (was den essenziellen Einrichtungen der Richtlinie entspricht) und „wichtigen Einrichtungen", und es arbeitet mit Paragrafen (§§) statt der hier zur Orientierung zitierten Artikel der Richtlinie.

Speziell für Videokonferenzen stellt das BSI zudem einen „Mindeststandard für Videokonferenzdienste" als konkreten Referenzrahmen bereit. Prüfen Sie dessen aktuellen Stand und rechtliche Verankerung direkt beim BSI, da sich diese mit dem NIS2UmsuCG geändert hat. Bestätigen Sie Ihre konkreten Pflichten, Ihre Einstufung und Ihre Meldewege stets anhand des geltenden deutschen Rechts und beim BSI, bevor Sie auf die in diesem Artikel genannten Artikel der Richtlinie abstellen.

Warum NIS2 Videokommunikation erfasst

Artikel 21 Absatz 2 Buchstabe j ist ausdrücklich: Neben der Anforderung einer Multifaktor- oder kontinuierlichen Authentifizierung verpflichtet er Einrichtungen, „soweit angemessen", gesicherte Sprach-, Video- und Textkommunikation sowie gesicherte Notfallkommunikationssysteme umzusetzen. Videocalls sind der Ort, an dem Incident-Response-Teams während eines laufenden Ransomware-Vorfalls koordinieren, an dem Vorstandsmitglieder einen Sicherheitsvorfall besprechen, bevor er offengelegt wird, und an dem Ärztinnen, Ingenieure oder Amtsträger sensible operative Details austauschen. Ist dieser Kanal kompromittiert, ist auch die Vertraulichkeit von allem, was darüber besprochen wird, kompromittiert.

Ein Ausfall der Videokonferenz kann in bestimmten Fällen selbst zum „erheblichen Sicherheitsvorfall" werden, der die Melduhr von NIS2 in Gang setzt – auch wenn die Schwelle in Artikel 23 Absatz 3 hoch liegt: Sie erfordert eine schwere Betriebsstörung oder einen finanziellen Verlust für die Einrichtung selbst oder einen erheblichen materiellen oder immateriellen Schaden für andere, und sie wird am ehesten dort erreicht, wo der Videokanal zentral für die regulierte Leistung der Einrichtung ist (etwa eine Telemedizin-Plattform statt eines Herstellers, dessen Mitarbeitende Video schlicht zum Reden untereinander nutzen). Deshalb ist Videokonferenz zu einem benannten Kontrollbereich unter NIS2 geworden und nicht nur zu einer beiläufigen Sicherheitsposition. Das erklärt auch, warum Prüfer heute fragen, wie Meeting-Plattformen bereitgestellt werden – und nicht nur, wie Laptops gepatcht werden.

Fällt Ihr Videokonferenz-Anbieter selbst unter NIS2?

Bevor Sie fragen, ob Ihr Video-Tool die NIS2-Anforderungen erfüllt, prüfen Sie, ob Ihr Anbieter selbst eine in den Anwendungsbereich fallende Einrichtung ist. Anhang I der Richtlinie führt digitale Infrastruktur sowie – separat – die Verwaltung von IKT-Diensten (B2B) als Sektoren auf, die unabhängig von der Branche des Käufers erfasst sind. Anbieter von Cloud-Computing-Diensten, Rechenzentrumsbetreiber, Anbieter von Content-Delivery-Networks sowie Managed-Service- und Managed-Security-Service-Provider sind ausdrücklich benannt, und die Durchführungsverordnung (EU) 2024/2690 der Kommission legt technische und methodische Anforderungen fest, die mehrere dieser Kategorien unmittelbar binden. Eine Handvoll Kategorien, darunter DNS-Diensteanbieter und qualifizierte Vertrauensdiensteanbieter, gelten unabhängig von der Größe als besonders wichtige Einrichtungen. Ob ein bestimmter Anbieter als „Managed-Service-Provider" zählt oder die Definition eines Cloud-Computing-Dienstanbieters erfüllt, ist von außen nicht immer offensichtlich, und es lohnt sich, eine fokussierte rechtliche Analyse dieser Grenze zu lesen, statt zu raten (Kemp IT Law, 2025).

Eine Videokonferenz-Plattform, die eine eigene Infrastruktur betreibt, statt die eines anderen weiterzuverkaufen, erfüllt oft die Definition eines Cloud-Computing-Dienstanbieters, sobald sie die oben dargelegten Größenschwellen des Artikels 2 überschreitet – wobei große Anbieter in diesem Sektor als besonders wichtig und mittelgroße als wichtig gelten. In der Praxis heißt das, dass Ihr Anbieter unter NIS2 eigenständig verpflichtet sein kann, was in der Due Diligence zu bestätigen sich lohnt. Das ist allerdings eher nützlicher Kontext als Compliance-Gutschrift: Es gibt kein NIS2-Zertifizierungsschema, auf das man verweisen könnte, so wie man auf das ISO-27001-Zertifikat eines Anbieters verweist – und der eigene Status Ihres Anbieters mindert nicht die Lieferketten-Due-Diligence, die Artikel 21 von Ihnen als Käufer verlangt.

Die Anforderungen an gesicherte Kommunikation für Videokonferenzen

Artikel 21 Absatz 2 legt 10 Kategorien von Risikomanagementmaßnahmen fest, die besonders wichtige und wichtige Einrichtungen in verhältnismäßiger Weise – auf Basis ihrer Größe und ihres Risikoprofils – anwenden müssen. Mehrere davon lassen sich direkt darauf abbilden, wie ein Videokonferenz-Tool konfiguriert und genutzt wird.

Verschlüsselung von Audio- und Videoströmen

Bei Video braucht das etwas Genauigkeit, denn „verschlüsselt" wird in der Branche locker verwendet. Artikel 21 Absatz 2 Buchstabe h verlangt Konzepte für den Einsatz von Kryptografie und, „soweit angemessen", Verschlüsselung. WebRTC-basierte Plattformen verschlüsseln das Signalling standardmäßig mit TLS und die Medienströme mit DTLS-SRTP. Das ist Transportverschlüsselung: Die Verbindung zwischen jedem Gerät und dem Server ist geschützt, aber der Media-Server selbst entschlüsselt die Ströme und verschlüsselt sie neu, während er sie routet. Das gibt dem Anbieter während des Calls technischen Zugriff auf Klartext-Audio und -Video. Ende-zu-Ende-Verschlüsselung (E2EE) ist eine separate, stärkere Eigenschaft: Schlüssel werden auf dem Gerät des Teilnehmers erzeugt und verlassen es nie, sodass die Infrastruktur (Signalling-Server, Media-Server und Hosting-Anbieter) nur Chiffretext verarbeitet, den sie nicht lesen kann.

NIS2 schreibt E2EE nicht für jeden Call vor. Artikel 21 Absatz 2 Buchstabe h setzt einen „angemessenen" und verhältnismäßigen Maßstab, sodass die richtige Kontrolle davon abhängt, was besprochen wird. Für routinemäßige interne Meetings reicht Transportverschlüsselung oft aus. Für Vorstandsberatungen, Rechtsberatungen, Incident-Response-Calls und alles, was unter Artikel 23 als erheblicher Sicherheitsvorfall gilt, schließt E2EE die Lücke, die die Transportverschlüsselung am Server offenlässt. Das kommt mit einem Kompromiss, den man vor dem Einschalten kennen sollte: Weil der Server nie entschlüsselte Medien sieht, kann er weder eine Aufzeichnung noch ein Transkript noch irgendeinen anderen inhaltsbezogenen Nachweis dieser Sitzung erzeugen. Metadaten wie Zeitstempel und wer wann beigetreten oder gegangen ist, werden weiterhin protokolliert; wenn Ihr Incident-Response-Prozess jedoch darauf angewiesen ist, dass der Anbieter Sitzungsinhalte für die Meldung nach Artikel 23 liefert, vereinbaren Sie mit dem Anbieter im Voraus, welche Nachweise E2EE überstehen und welche nicht – und wählen Sie die Kontrolle für den jeweiligen Call entsprechend.

Zugriffskontrolle und Multifaktor-Authentifizierung

Buchstabe j des Artikels 21 Absatz 2 – derselbe Buchstabe, der gesicherte Sprach-, Video- und Textkommunikation abdeckt – benennt auch die Multifaktor- oder kontinuierliche Authentifizierung ausdrücklich; die zugehörigen Pflichten zur Zugriffskontrolle und zur Sicherheit im Personalbereich stehen in Buchstabe i. Für Videokonferenzen bedeutet das rollenbasierte Berechtigungen, die Hosts, Co-Hosts und Teilnehmende trennen; eine Lobby oder einen Warteraum, sodass nicht authentifizierte Nutzer einer laufenden Sitzung nicht ungeprüft beitreten können; sowie Single Sign-on (SSO) mit auf Ebene des Identitätsanbieters erzwungener Multifaktor-Authentifizierung (MFA), statt sie einzelnen Nutzern zu überlassen. Meeting-Links, die erraten, unbegrenzt wiederverwendet oder ohne jede Host-Freigabe betreten werden können, sind ein wiederkehrender Befund in NIS2-Gap-Analysen – gerade weil sie eine andernorts solide Zugriffskontrollrichtlinie der Organisation untergraben.

Resilienz, Verfügbarkeit und Geschäftskontinuität

Eine Videoplattform braucht Redundanz über Regionen oder Rechenzentren hinweg, damit ein einzelner Ausfall der Organisation nicht die Fähigkeit zu kommunizieren nimmt – genau in dem Moment, in dem ein Vorfall Koordination verlangt. Das zählt am meisten während eines Ransomware-Vorfalls, wenn E-Mail und interner Chat kompromittiert oder nicht vertrauenswürdig sein können und ein resilienter, unabhängig gehosteter Videokanal zur Ausweich-Kommunikationsmethode wird, auf die sich das Krisenteam tatsächlich verlässt. Artikel 21 Absatz 2 Buchstabe c deckt die Geschäftskontinuität ab, einschließlich Backup-Management und Notfallwiederherstellung, und Buchstabe a verlangt umfassender Risikoanalyse- und Informationssystem-Sicherheitskonzepte.

Behandlung und Meldung von Sicherheitsvorfällen

Eine Kompromittierung oder ein längerer Ausfall des Videokonferenz-Tools, das für die Vorstands-, klinische oder operative Kommunikation genutzt wird, kann die Schwelle für einen „erheblichen Sicherheitsvorfall" erreichen, wenn er eine schwere Betriebsstörung verursacht – dieselbe Schwelle, die weiter oben in diesem Artikel beschrieben ist. Artikel 23 setzt eine dreistufige Meldefrist für erhebliche Sicherheitsvorfälle: eine Frühwarnung innerhalb von 24 Stunden nach Kenntnisnahme, eine ausführlichere Vorfallmeldung innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats nach dieser 72-Stunden-Meldung. Einrichtungen müssen im Voraus wissen, ob ihr Anbieter zeitgerechte Nachweise – etwa Logs, Zeitstempel und Daten betroffener Sitzungen – für diesen Meldezyklus unterstützt. Erst im Vorfall einen Anbieter nach diesen Informationen zu fragen, ist ein häufiger und vermeidbarer Schwachpunkt.

Lieferketten- und Drittparteien-Sicherheit

Artikel 21 Absatz 2 Buchstabe d und Artikel 21 Absatz 3 verlangen von Einrichtungen, die Cybersicherheitspraktiken direkter Zulieferer zu bewerten, einschließlich der Qualität ihrer Produkte und ihrer sicheren Entwicklungsprozesse. Ihr Videokonferenz-Anbieter ist in diesem Sinne ein Zulieferer, und die Due Diligence sollte sich auf seine Unterauftragsverarbeiter erstrecken (Hosting-Anbieter, CDN-Betreiber und TURN/STUN-Relay-Infrastruktur – die Server, die Medien übertragen, wenn keine direkte Verbindung zwischen Geräten hergestellt werden kann), nicht nur auf die Vordertür des Anbieters. Leserinnen und Leser aus dem Finanzsektor sollten beachten, dass dies mehr ist als ein paralleler Standard. DORA, der Digital Operational Resilience Act, ist durch seinen eigenen Artikel 1 Absatz 2 als sektorspezifischer Unionsrechtsakt im Sinne des Artikels 4 der NIS2 bestimmt, und diese Bestimmung schaltet die Artikel 21 und 23 der NIS2 für Einrichtungen im Anwendungsbereich von DORA ab. Das bedeutet, dass DORAs eigene Regeln die Risikomanagementmaßnahmen der NIS2 – einschließlich der hier beschriebenen Lieferkettenbewertung – und ihre Meldepflichten ersetzen, statt eine zweite Schicht darüberzulegen. DORA fügt außerdem ein eigenes Resilienztest-Regime und eine eigene Drittparteien-Aufsicht hinzu, ohne direktes NIS2-Äquivalent. Einrichtungen außerhalb des Anwendungsbereichs von DORA bleiben unter NIS2.

Verantwortlichkeit der Leitungsorgane

Die Verantwortlichkeit der Leitungsorgane ist keine der zehn oben behandelten Maßnahmen des Artikels 21 Absatz 2. Sie beruht auf Artikel 20, der regelt, wer diese Maßnahmen genehmigt und wer für sie geradesteht. Ein Vorstand oder eine leitende Führungskraft, der oder die die Weiternutzung eines Video-Tools ohne MFA billigt oder das Aufzeichnungen außerhalb vereinbarter Rechtsräume speichert, trifft eine Risikomanagemententscheidung, für die er oder sie nun persönlich verantwortlich ist. Artikel 20 verlangt von den Leitungsorganen, die Risikomanagementmaßnahmen des Artikels 21 zu genehmigen, ihre Umsetzung zu überwachen und selbst Schulungen zu durchlaufen. Für besonders wichtige Einrichtungen – nicht jedoch für wichtige – geht der Einsatz weiter: Artikel 32 Absatz 5 verlangt von den Mitgliedstaaten, ihren zuständigen Behörden die Befugnis zu geben, einer Person bei schwerwiegender oder wiederholter Nichteinhaltung vorübergehend die Wahrnehmung von Leitungsaufgaben auf Ebene des CEO oder gesetzlichen Vertreters zu untersagen. Die Richtlinie nimmt Einrichtungen der öffentlichen Verwaltung von dieser besonderen Befugnis aus. Ansonsten ist sie keine nationale Option: Die Richtlinie verlangt, dass die Befugnis besteht, auch wenn jeder Mitgliedstaat das Verfahren selbst ausgestaltet.

NIS2 vs. CRA vs. DORA: Was gilt für Ihr Video-Tool?

NIS2, der Cyber Resilience Act (CRA) und DORA werden miteinander verwechselt, weil sie sich thematisch überschneiden und weil NIS2 und DORA am selben Tag angenommen wurden. Sie regeln unterschiedliche Dinge.

Rechtsakt Was er regelt Für wen er gilt Relevanz für Videokonferenzen
NIS2 (Richtlinie (EU) 2022/2555) Cybersicherheits-Risikomanagement und Vorfallmeldung für Organisationen Besonders wichtige und wichtige Einrichtungen über 18 Sektoren, darunter digitale Infrastruktur und Verwaltung von IKT-Diensten Regelt, wie die Einrichtung, die das Video-Tool nutzt oder bereitstellt, es absichert (Artikel 21)
Cyber Resilience Act (Verordnung (EU) 2024/2847) Security-by-Design und Umgang mit Schwachstellen für Produkte mit digitalen Elementen Hersteller, Importeure und Händler von Hardware/Software, die auf dem EU-Markt bereitgestellt wird Kann auf die Videokonferenz-Software selbst als Produkt anwendbar sein, getrennt davon, wie der Käufer sie betreibt. Software, die als gehosteter Dienst bereitgestellt und genutzt wird, liegt in der Regel außerhalb des CRA; der Test der „Fernverarbeitung von Daten" greift dort, wo Software in ein auf dem EU-Markt bereitgestelltes Produkt eingebettet oder mit ihm ausgeliefert wird – die Antwort hängt also davon ab, wie ein bestimmtes Tool verpackt und verkauft wird
DORA (Verordnung (EU) 2022/2554) Digitale operative Resilienz für den Finanzsektor Banken, Versicherer, Wertpapierfirmen, Zahlungs- und Kryptowerte-Unternehmen sowie ihre kritischen IKT-Anbieter Für Finanzunternehmen in ihrem Anwendungsbereich ersetzt DORA die Risikomanagementmaßnahmen des Artikels 21 und die Meldepflichten des Artikels 23, die sie sonst unter NIS2 schulden würden – einschließlich derer, die einen Video-Anbieter betreffen – und fügt ein eigenes Resilienztest-Regime hinzu; Einrichtungen außerhalb des Anwendungsbereichs von DORA bleiben unter NIS2

Eine nützliche Faustregel: NIS2 fragt, ob die Organisation Risiken gut managt; der CRA fragt, ob das Produkt sicher gebaut wurde; DORA fragt, ob der Betrieb eines Finanzunternehmens – einschließlich seiner IKT-Zulieferer – Störungen standhalten kann. Eine regulierte Bank, die ein Videokonferenz-Produkt kauft, könnte im Prinzip alle drei berühren.

Checkliste: Ist Ihr Videokonferenz-Tool NIS2-bereit?

Ein anbieterneutraler Weg, eine Plattform zu bewerten, ist, das Folgende durchzuarbeiten und jeden Punkt anhand eigener Nachweise statt der Marketingaussagen eines Anbieters zu beurteilen. Das meiste bildet Artikel 21 ab, die Unterstützung bei der Vorfallmeldung folgt Artikel 23, und der letzte Punkt liegt aus dem unten genannten Grund ganz außerhalb von NIS2. Behandeln Sie es als eine gegen Ihre eigene Risikoeinschätzung und Größe abzuwägende Auswahl – nicht als einheitliches Minimum, das jede Einrichtung vollständig erfüllen muss.

  • Verschlüsselung. Sind Medien nur während der Übertragung geschützt (TLS/DTLS-SRTP), oder ist Ende-zu-Ende-Verschlüsselung verfügbar? Unter welchen Bedingungen wird sie aktiv, und wer kontrolliert die Schlüssel?
  • Zugriffskontrolle und Authentifizierung. Ist MFA über SSO verfügbar? Sind Warteräume und Host-Freigabe standardmäßig aktiviert? Lassen sich Berechtigungen nach Rolle zuschneiden, statt sie einheitlich zu vergeben?
  • Resilienz. Welche Redundanz besteht über Regionen hinweg? Welche veröffentlichte oder vertraglich zugesicherte Verfügbarkeit gilt? Wie kommuniziert der Anbieter während seiner eigenen Vorfälle?
  • Unterstützung bei der Vorfallmeldung. Liefert der Anbieter zeitgestempelte Logs und Sitzungsdaten schnell genug, um Ihre 24- und 72-Stunden-NIS2-Fristen einzuhalten – und ist das vertraglich festgehalten statt vorausgesetzt?
  • Lieferkette. Wo werden Daten gehostet, wer sind die benannten Unterauftragsverarbeiter, und sind diese Unterauftragsverarbeiter selbst unabhängig bewertet?
  • Datenresidenz und Rechtsraum. Keine NIS2-Anforderung, aber sie kommt im selben Beschaffungsgespräch auf: Hält die Plattform EU-Meeting-Daten, Aufzeichnungen und Metadaten innerhalb der EU, und passt das zu Ihren eigenen Datensouveränitätspflichten unter der DSGVO und etwaigen sektorspezifischen Regeln?

Einen Anbieter anhand dieser Liste zu prüfen und Ihre Begründung zu dokumentieren – einschließlich dessen, was Sie als nicht anwendbar einstufen und warum –, erzeugt einen belastbaren Nachweis für die Freigabe durch das Leitungsorgan, die Artikel 20 verlangt. Es kommt auch der praktischen Definition von sicherer Videokonferenz nahe, nach der NIS2-Prüfer bei einer Überprüfung suchen werden.

Sanktionen bei Nichteinhaltung

Artikel 34 setzt Mindestniveaus, die die Mitgliedstaaten erreichen müssen, wobei nationale Gesetze höher gehen können. Besonders wichtige Einrichtungen drohen Geldbußen von bis zu 10 Mio. € oder 2 Prozent des gesamten weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist; wichtigen Einrichtungen drohen bis zu 7 Mio. € oder 1,4 Prozent des Umsatzes (Europäisches Parlament und Rat der Europäischen Union, 2022a). Das sind keine einmaligen Strafen, die auf die normale Aufsicht aufgesetzt werden: Besonders wichtige Einrichtungen unterliegen einer proaktiven Ex-ante-Aufsicht, das heißt, nationale Behörden können Nachweise der Einhaltung ohne vorherigen Vorfall anfordern, während wichtige Einrichtungen reaktiv beaufsichtigt werden, typischerweise nach einer Verletzung oder Beschwerde. Besonders wichtige Einrichtungen tragen zudem das oben unter „Verantwortlichkeit der Leitungsorgane" beschriebene Risiko persönlicher Haftung: ein mögliches vorübergehendes Verbot der Wahrnehmung von Leitungsaufgaben nach Artikel 32 Absatz 5 bei schwerwiegender oder wiederholter Nichteinhaltung. Die genauen Bußgeldobergrenzen, der Durchsetzungsansatz und die Regelungen zur persönlichen Haftung variieren je Mitgliedstaat; bestätigen Sie daher die für Ihre Organisation geltenden Einzelheiten mit Ihrer Compliance- oder Rechtsabteilung.

Wie Digital Samba gesicherte NIS2-Kommunikation unterstützt

Standardmäßig nutzen Calls über die Videokonferenz-API und das SDK von Digital Samba die in WebRTC eingebauten Schutzmechanismen der Transportschicht: TLS für das Signalling und DTLS-SRTP für die Medien. Wir bieten außerdem optionale Ende-zu-Ende-Verschlüsselung für Sitzungen, in denen diese stärkere Garantie angebracht ist. Schlüssel werden lokal auf dem Gerät jedes Teilnehmers mit der Web Crypto API erzeugt und niemals an unsere Server übertragen oder dort gespeichert. Medien werden mit AES-128 im Counter-Modus mit HMAC-SHA256 geschützt, sodass unsere Infrastruktur nach dem Aktivieren nur Chiffretext weiterleitet, den sie nicht lesen kann. Das gibt Sicherheits- und Compliance-Teams unter Artikel 21 Absatz 2 Buchstabe h eine echte Wahl, statt einer einzigen festen Verschlüsselungsposition. E2EE ist eine sitzungsbezogene Einstellung, nicht unser Standardzustand – entscheiden Sie daher vorab, wie bei jedem Anbieter, welche Sitzungen sie brauchen und welche stattdessen erfordern, dass wir Aufzeichnungs- oder Transkriptionsfunktionen verfügbar halten.

Bei der Zugriffskontrolle unterstützen wir rollenbasierte Berechtigungen, Warteräume und API-gesteuerte Authentifizierung, die sich in das bestehende Identitäts- und SSO-Setup einer Organisation integriert, sodass die MFA-Durchsetzung auf der Ebene des Identitätsanbieters sitzen kann, wie es Artikel 21 Absatz 2 Buchstabe j erwartet. Als REST-API und einbettbares SDK statt einer festen Endkundenanwendung ist unsere Plattform darauf ausgelegt, in die eigenen Governance-, Logging- und Zugriffsmanagement-Werkzeuge einer Einrichtung integriert zu werden – was die Art von Nachweiskette unterstützt, die sowohl das Risikomanagement nach Artikel 21 als auch die Vorfallmeldung nach Artikel 23 verlangen.

Die Datenresidenz selbst ist eine DSGVO- und Souveränitätsfrage und keine NIS2-Anforderung, aber sie ist meist Teil desselben Due-Diligence-Gesprächs. Unsere Produktionsinfrastruktur läuft in den Niederlanden, mit Backup-Infrastruktur in Deutschland; Überlaufkapazität bei Spitzenlast umfasst einen Schweizer Anbieter, dessen Standort auf einem Angemessenheitsbeschluss statt auf einer EU- oder EWR-Residenz beruht. DSGVO-konforme Datenverarbeitung ist in unsere Architektur eingebaut und nicht nachträglich hinzugefügt.

Wir halten zum Zeitpunkt der Erstellung dieses Artikels keine direkte ISO-27001- oder SOC-2-Zertifizierung. Unsere Kontrollen sind dokumentiert statt zertifiziert: Das Informationssicherheits-Managementsystem von Digital Samba nutzt ISO 27001:2022 als Referenzrahmen, und wir arbeiten auf eine formale Zertifizierung danach hin. Wo Zertifizierungen für Ihren Beschaffungsprozess wichtig sind, fragen Sie jeden Anbieter – auch uns – direkt nach seinem aktuellen Stand und den Zertifizierungen seiner Unterauftragsverarbeiter, statt sich auf allgemeine Marketingaussagen zu verlassen.

Für Teams, die eine vollständige NIS2-Bewertung erstellen, gehen unser WebRTC-Sicherheitsleitfaden und unser Erklärstück zur Ende-zu-Ende-Verschlüsselung tiefer auf die zugrunde liegende Mechanik ein, und unser Artikel zur Datensouveränität behandelt die Souveränitätsseite desselben Due-Diligence-Prozesses.

FAQ

Gilt NIS2 für Videokonferenzen?

Ja, indirekt und direkt. Indirekt, weil besonders wichtige und wichtige Einrichtungen die Werkzeuge absichern müssen, die ihre Mitarbeitenden für Sprach-, Video- und Textkommunikation nutzen, nach Artikel 21 Absatz 2 Buchstabe j. Direkt, weil ein Videokonferenz-Anbieter, der seine eigene Cloud-Infrastruktur in großem Maßstab betreibt, selbst ein in den Anwendungsbereich fallender Anbieter digitaler Infrastruktur oder von IKT-Diensten sein kann.

Was verlangt Artikel 21 der NIS2 für Videokommunikation?

Artikel 21 Absatz 2 listet 10 Kategorien verhältnismäßiger Risikomanagementmaßnahmen auf, von denen mehrere direkt auf eine Videoplattform anwendbar sind: Kryptografie- und Verschlüsselungskonzept, Zugriffskontrolle und Multifaktor-Authentifizierung, Geschäftskontinuität und Resilienz, Behandlung von Sicherheitsvorfällen sowie die Lieferketten-Sicherheitsbewertung des Anbieters selbst.

Ist ein Videokonferenz-Anbieter eine besonders wichtige oder wichtige Einrichtung unter NIS2?

Das hängt davon ab, wie der Dienst erbracht wird, und von der Größe des Anbieters. Ein Anbieter, der seine eigene Hosting-Infrastruktur betreibt, kann unter die Kategorien „Cloud-Computing-Dienstanbieter" oder „Verwaltung von IKT-Diensten" in Anhang I fallen – eingestuft als besonders wichtig, sobald er die Obergrenzen für mittelgroße Unternehmen überschreitet (also 250 Beschäftigte oder mehr oder ein Umsatz über 50 Mio. € zusammen mit einer Bilanzsumme über 43 Mio. €), und als wichtig darunter, aber oberhalb der Kleinstunternehmens-Schwelle. Ein Anbieter, der lediglich die Infrastruktur eines anderen Unternehmens weiterverkauft, wird anders bewertet, daher sollte dies je Anbieter bestätigt werden.

Verlangt NIS2 Ende-zu-Ende-Verschlüsselung für Videocalls?

Nein. Artikel 21 Absatz 2 Buchstabe h verlangt einen „angemessenen" Einsatz von Kryptografie und Verschlüsselung, keinen bestimmten technischen Standard. Transportverschlüsselung (TLS und DTLS-SRTP) ist der Standard für WebRTC-basierte Plattformen und für viele Anwendungsfälle ausreichend; Ende-zu-Ende-Verschlüsselung ist eine stärkere, zusätzliche Kontrolle, die Einrichtungen dort anwenden sollten, wo die Sensibilität der Besprechung – etwa Vorstandsangelegenheiten, Incident-Response und regulierte Daten – es rechtfertigt.

Was ist der Unterschied zwischen NIS2, DORA und dem Cyber Resilience Act bei Video-Tools?

NIS2 regelt, wie eine in den Anwendungsbereich fallende Organisation Cybersicherheitsrisiken managt und Vorfälle meldet. Für die Finanzunternehmen in ihrem Anwendungsbereich ersetzt DORA die Risikomanagement- und Meldepflichten der NIS2, statt neben ihnen zu stehen, und fügt ein eigenes Resilienztest- und Drittparteien-Aufsichtsregime hinzu. Der Cyber Resilience Act regelt die Sicherheit des Software- oder Hardwareprodukts selbst und legt Pflichten dem Hersteller statt dem Käufer auf. Ein reguliertes Finanzinstitut, das ein Videokonferenz-Produkt kauft, könnte je nach eigenem Status und dem des Anbieters von allen dreien betroffen sein.

Wer muss NIS2 einhalten?

Besonders wichtige und wichtige Einrichtungen über die 18 in den Anhängen I und II der Richtlinie (EU) 2022/2555 gelisteten Sektoren, im Allgemeinen bestimmt nach Sektor und nach den Größenschwellen des Artikels 2 (grob: mittelgroße Einrichtungen sind wichtig und größere besonders wichtig, wobei mittelgroß weniger als 250 Beschäftigte mit einem Umsatz bis 50 Mio. € oder einer Bilanzsumme bis 43 Mio. € bedeutet; Organisationen unterhalb der Kleinstunternehmens-Schwelle liegen meist außerhalb des Anwendungsbereichs), wobei bestimmte Kategorien wie DNS-Diensteanbieter und qualifizierte Vertrauensdiensteanbieter unabhängig von der Größe erfasst sind.

Welche Sanktionen drohen bei Nichteinhaltung von NIS2?

Nach Artikel 34 drohen besonders wichtigen Einrichtungen Geldbußen von bis zu 10 Mio. € oder 2 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist; wichtigen Einrichtungen drohen bis zu 7 Mio. € oder 1,4 Prozent des Umsatzes. Die Mitgliedstaaten können im nationalen Recht höhere Obergrenzen festlegen. Artikel 20 fügt eine persönliche Verantwortlichkeit der Leitungsorgane hinzu, und speziell für besonders wichtige Einrichtungen erlaubt Artikel 32 Absatz 5 den zuständigen Behörden, bei schwerwiegender oder wiederholter Nichteinhaltung vorübergehende Leitungsverbote zu verhängen.

Dieser Artikel bietet allgemeine Informationen und stellt keine Rechtsberatung dar. Bestätigen Sie die konkreten NIS2-Pflichten, die Einstufung und die Meldepflichten Ihrer Organisation mit Ihrer Compliance- oder Rechtsabteilung.

Quellen

  1. Europäisches Parlament und Rat der Europäischen Union. (2022a). Richtlinie (EU) 2022/2555 vom 14. Dezember 2022 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union (NIS-2-Richtlinie). Amtsblatt der Europäischen Union, L 333.
  2. Europäische Kommission. (2024). Durchführungsverordnung (EU) 2024/2690 der Kommission zur Festlegung von Vorschriften für die Anwendung der Richtlinie (EU) 2022/2555 im Hinblick auf technische und methodische Anforderungen. Shaping Europe's Digital Future.
  3. Kemp IT Law. (2025). Navigating NIS 2: a guide to applicability for 'managed service providers'.
  4. Europäisches Parlament und Rat der Europäischen Union. (2024). Verordnung (EU) 2024/2847 vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyber Resilience Act).
  5. Europäisches Parlament und Rat der Europäischen Union. (2022b). Verordnung (EU) 2022/2554 vom 14. Dezember 2022 über die digitale operationale Resilienz im Finanzsektor (DORA).