Reicht ein ISMS als Verfügbarkeitsnachweis?

Nein. Ein ISMS nach ISO/IEC 27001 dokumentiert, dass du Verfügbarkeit organisatorisch steuerst — mit Richtlinien, Risikoanalysen, definierten Schutzzielen und Wiederanlaufplänen. Es belegt aber nicht, ob dein Dienst im fraglichen Zeitraum tatsächlich erreichbar war. Genau diese Messung liefert kontinuierliches Verfügbarkeitsmonitoring: zeitgestempelte Uptime-Werte, eine klassifizierte Vorfall-Historie und exportierbare Reports. ISMS und Monitoring beantworten zwei verschiedene Fragen — das eine 'Haben wir einen Prozess?', das andere 'War der Dienst erreichbar?'. Für einen Audit brauchst du beides; das eine ersetzt das andere nicht. Im Einzelfall rechtlich prüfen.

Braucht eine DiGA ein BSI-TR-03161-Zertifikat?

Ja. Seit dem 1. Januar 2025 muss eine DiGA ein Zertifikat über die Datensicherheit gegen die BSI-Technische Richtlinie TR-03161 'Anforderungen an Anwendungen im Gesundheitswesen' vorweisen. Das ergibt sich aus § 4 Abs. 7 DiGAV. Dieses Zertifikat ist eine eigenständige Herstellerpflicht und wird durch ein Verfügbarkeitsmonitoring nicht ersetzt. Monitoring liefert den Verfügbarkeitsnachweis; das TR-03161-Zertifikat adressiert die Datensicherheit der Anwendung selbst. Beide Bausteine stehen nebeneinander. Im Einzelfall rechtlich prüfen.

Welche ISMS-Norm akzeptiert das BfArM?

Anlage 1 zur DiGAV verlangt vom Hersteller ein Informationssicherheits-Managementsystem entweder nach ISO/IEC 27001 oder nach ISO 27001 auf Basis des BSI IT-Grundschutzes (BSI-Standard 200-2). Ein anerkanntes Zertifikat muss dem BfArM auf Anforderung vorgelegt werden können. Der Hersteller hat damit zwei gangbare Wege — die ISO-Norm direkt oder den BSI-Grundschutz-Weg. Maßgeblich ist der Wortlaut der Anlage 1 zur DiGAV. Im Einzelfall rechtlich prüfen.

Was gehört in einen Verfügbarkeits-Report fürs Audit?

Ein belastbarer Verfügbarkeits-Report deckt einen klar benannten Zeitraum ab und enthält die gemessene Uptime in Prozent, das vereinbarte Verfügbarkeitsziel zum Abgleich, die Anzahl der Vorfälle, die Gesamt-Ausfallzeit, die mittlere Wiederherstellungszeit (MTTR) sowie eine zeitgestempelte, klassifizierte Vorfall-Historie mit Beginn, Ende und Ursachenart je Vorfall. Wichtig ist die Exportierbarkeit als PDF oder CSV, damit der Report an Prüfer oder Einkauf weitergegeben werden kann. Eine Richtlinie aus dem GRC-Tool ergänzt das, ersetzt es aber nicht — sie beschreibt die Absicht, der Report belegt das Ergebnis. Im Einzelfall rechtlich prüfen.

Verfügbarkeitsnachweis für DiGA: Was ISMS und GRC-Tools nicht abdecken

Du hast ein ISMS nach ISO 27001, ein GRC-Tool mit gepflegtem Risiko- und Maßnahmenregister, und trotzdem fragt der Auditor nach „dem Verfügbarkeitsnachweis”. Das ist kein Widerspruch — es ist die Folge einer Unterscheidung, die viele DiGA-Hersteller übersehen: GRC- und ISMS-Tools dokumentieren, dass du Verfügbarkeit sicherstellen willst. Monitoring misst und belegt, ob dein Dienst tatsächlich erreichbar war. Das eine ist eine Absichtserklärung mit Prozess, das andere ein Messergebnis mit Zeitstempel.

Dieser Artikel ordnet ein, warum beide Ebenen nötig sind, wo dein ISMS endet und der Verfügbarkeitsnachweis beginnt — und was in einen Report gehört, den du einem Prüfer oder dem Einkauf einer Klinik vorlegst. Er ersetzt keine Rechtsberatung; die individuelle Pflichtenlage ist im Einzelfall rechtlich zu prüfen.

Warum verlangt überhaupt jemand einen Verfügbarkeitsnachweis?

Weil Verfügbarkeit kein freiwilliges Qualitätsmerkmal mehr ist, sondern an mehreren Stellen rechtlich und vertraglich verankert. Drei Quellen wirken bei DiGA-Herstellern zusammen.

Erstens das neue BSI-Gesetz. Mit dem NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (in Kraft seit dem 6. Dezember 2025) nennt § 30 Abs. 1 BSIG die Verfügbarkeit ausdrücklich als Schutzziel. § 30 Abs. 2 listet zehn Risikomanagement-Maßnahmen — darunter Nr. 1 die Risikoanalyse, Nr. 3 die Aufrechterhaltung des Betriebs (Business Continuity) und Nr. 4 die Sicherheit der Lieferkette. Über diese Lieferketten-Pflicht erreicht der Verfügbarkeitsdruck auch Hersteller, die selbst nicht direkt NIS2-pflichtig sind — wir haben das in DiGA & NIS2: Betroffenheit ausführlicher eingeordnet.

Zweitens die gematik und die Telematikinfrastruktur. Die gematik definiert in ihrer Richtlinie zum Betrieb der TI verbindliche Service Level mit Verfügbarkeitszielen für TI-Dienste, misst diese monatlich über ein zentrales TI-Monitoring und sieht bei Unterschreitung vertragliche Pönalen vor. Über die NIS2-Lieferkettenpflicht setzt sich dieser Verfügbarkeitsdruck bis in die zuliefernde Software fort.

Drittens der Audit- und Vergabeprozess selbst. Eine Klinik oder ein anderer institutioneller Abnehmer fragt im Einkauf zunehmend: „Belegen Sie, dass Ihr Dienst sein Verfügbarkeitsziel im letzten Quartal erreicht hat.” An dieser Stelle nützt die schönste Richtlinie nichts, wenn die Messung fehlt.

Was deckt mein ISMS ab — und was nicht?

Dein ISMS deckt die organisatorische Steuerung der Informationssicherheit ab. Für DiGA ist das keine Kür: Die Anlage 1 zur DiGAV (abgeleitet aus § 4 DiGAV) verlangt vom Hersteller ein Informationssicherheits-Managementsystem nach ISO/IEC 27001 oder nach ISO 27001 auf Basis des BSI IT-Grundschutzes (BSI-Standard 200-2), mit einem anerkannten Zertifikat, das dem BfArM auf Anforderung vorgelegt werden kann.

Ein ISMS legt fest, dass Verfügbarkeit ein Schutzziel ist, ordnet Verantwortlichkeiten zu, dokumentiert Risikoanalysen und Wiederanlaufpläne und sorgt dafür, dass diese Prozesse regelmäßig überprüft werden. Das ist die Grundlage — aber es ist eine Aussage über deine Prozesse, nicht über die tatsächliche Erreichbarkeit deines Dienstes an einem bestimmten Tag um eine bestimmte Uhrzeit.

Genau hier liegt die Lücke. Ein ISMS-Dokument sagt: „Wir betreiben ein Verfügbarkeitsmanagement mit dem Ziel 99,9 %.” Es sagt nicht: „Im Q2 2026 lag die gemessene Verfügbarkeit bei 99,94 %, mit zwei Vorfällen und einer Gesamt-Ausfallzeit von 26 Minuten.” Den zweiten Satz kann nur ein Messsystem belegen.

GRC dokumentiert, Monitoring misst — die konkrete Abgrenzung

Stell die beiden Ebenen nebeneinander, dann wird die Aufgabenteilung sofort sichtbar:

Was GRC/ISMS dokumentiert	Was Monitoring misst und nachweist
Richtlinie: „Verfügbarkeit ist ein Schutzziel”	Gemessene Uptime in Prozent über einen Zeitraum
Risikoanalyse und Maßnahmenregister	Tatsächlich aufgetretene Vorfälle mit Zeitstempel
Definiertes Verfügbarkeitsziel (SLO/SLA)	Abgleich Ist-Verfügbarkeit gegen das Ziel
Business-Continuity- und Wiederanlaufplan	Reale Wiederherstellungszeit je Vorfall (MTTR)
Verantwortlichkeiten und Freigaben	Klassifizierte Vorfall-Historie (Ursachenart)
Audit-Vorbereitung, Kontroll-Nachweise	Exportierbarer Report (PDF/CSV) als Beleg

Die linke Spalte beantwortet „Haben wir einen Prozess, der Verfügbarkeit sicherstellen soll?“. Die rechte Spalte beantwortet „War der Dienst tatsächlich erreichbar — und können wir das belegen?“. Ein GRC-Tool ist exzellent für die linke Spalte und konstruktionsbedingt blind für die rechte: Es führt Register, keine Messreihen. Ein Monitoring liefert die rechte Spalte und ersetzt keine der organisatorischen Pflichten der linken.

Wie sieht so ein Audit konkret aus?

Ein Beispiel aus der Praxis. Ein Auditor — oder der Einkauf einer Klinik, die deine DiGA als Versorgungsbaustein prüft — stellt eine einzige, klare Frage:

„Belegen Sie, dass Ihr Dienst im letzten Quartal sein Verfügbarkeitsziel erreicht hat.”

Du öffnest dein GRC-Tool und zeigst die Richtlinie: Schutzziel Verfügbarkeit, definiertes SLO von 99,9 %, Wiederanlaufplan, letzte Review-Freigabe. Der Auditor nickt — und sagt: „Das ist die Absicht. Ich brauche den Beleg, dass es auch eingetreten ist.”

Jetzt exportierst du aus deinem Monitoring einen Verfügbarkeits- und Vorfall-Report für das Quartal. Dieser Report ist der eigentliche Nachweis. Er enthält:

Bestandteil des Reports	Beispiel-Inhalt
Berichtszeitraum	01.04.2026 – 30.06.2026
Überwachter Dienst / Endpunkt	api.beispiel-diga.de (HTTP, 60-s-Intervall)
Gemessene Verfügbarkeit	99,94 %
Verfügbarkeitsziel zum Abgleich	99,9 % (Ziel erreicht)
Anzahl Vorfälle	2
Gesamt-Ausfallzeit	26 Minuten
Mittlere Wiederherstellungszeit (MTTR)	13 Minuten
Vorfall-Historie (zeitgestempelt)	12.05. 02:14–02:31 (Timeout), 03.06. 21:40–21:49 (5xx)

Der Unterschied ist greifbar: Das GRC-Tool zeigt, dass du das Ziel anstrebst; der Report zeigt zeitgestempelt, dass du es erreicht hast — und falls nicht, wann es warum nicht erreicht wurde und wie schnell du wiederhergestellt hast. Genau diese klassifizierte, exportierbare Evidenz ist es, die § 30-nahe Pflichten, gematik-Service-Level und institutionelle Einkäufer einfordern.

Wo passt FoundersDeck hier hinein — und wo nicht?

Klar zur Einordnung, ohne Übertreibung: FoundersDeck liefert die nachweisbare Verfügbarkeits-Evidenz und die Vorfall-Historie, die Audits und § 30-nahe Pflichten von dir verlangen. Kontinuierliche Überwachung deiner Endpunkte, automatische Vorfall-Erkennung mit Zeitstempel, eine durchsuchbare und klassifizierte Incident-Historie sowie exportierbare Reports — das ist die rechte Spalte der Tabelle oben.

Was FoundersDeck nicht ist und nicht behauptet zu sein:

kein ISMS. Dein ISMS nach ISO/IEC 27001 oder BSI-Grundschutz bleibt eine eigenständige Herstellerpflicht (Anlage 1 zur DiGAV).
kein TR-03161-Zertifikat. Seit dem 1. Januar 2025 muss deine DiGA ein Datensicherheits-Zertifikat gegen die BSI TR-03161 „Anforderungen an Anwendungen im Gesundheitswesen” vorweisen (§ 4 Abs. 7 DiGAV). Das ist eine separate Pflicht, die kein Monitoring abdeckt.
keine Compliance-Gesamtleistung. Ob du DiGA- oder NIS2-konform bist, entscheidet die organisatorische Gesamtleistung deines Unternehmens, nicht ein einzelnes Tool.

FoundersDeck unterstützt also gezielt einen Baustein — den Verfügbarkeitsnachweis — und ersetzt weder ISMS noch Zertifikat noch die organisatorische Compliance.

Was wir zusätzlich mitbringen, passt zur Sensibilität des Gesundheitswesens: FoundersDeck ist ein inhabergeführtes deutsches Unternehmen, gehostet bei Netcup in Nürnberg, damit ohne CLOUD-Act-Exposition. Die öffentlichen Status-Seiten sind cookie-frei, und der AVV ist sofort verfügbar — ohne Vertriebsgespräch. Wer prüfen will, welche Tools überhaupt unter EU-Recht stehen, findet das in unserer EU Jurisdiction Database; wie das für Anbieter und Einrichtungen im Gesundheitswesen zusammenkommt, zeigt unsere Seite zu Monitoring fürs Gesundheitswesen.

Die Quintessenz für DiGA-Hersteller

Dein ISMS und dein GRC-Tool sind notwendig — und sie bleiben notwendig. Aber sie dokumentieren deine Absicht, Verfügbarkeit sicherzustellen. Sobald jemand den Nachweis verlangt, dass dein Dienst tatsächlich erreichbar war, brauchst du eine Messung: zeitgestempelt, klassifiziert, exportierbar. Das ist keine Frage des Geschmacks, sondern die Lücke zwischen „Wir steuern Verfügbarkeit” und „Hier ist der Beleg, dass sie eingetreten ist”.

Wenn du dich gerade neu mit den DiGA-Pflichten rund um Verfügbarkeit befasst, ist unsere DiGA-Übersichtsseite der beste Einstieg. Und falls noch unklar ist, ob und wie dich NIS2 als Hersteller erreicht, beginne mit DiGA & NIS2: Betroffenheit.

Dieser Artikel gibt den Rechtsstand zum Stand: Juni 2026 wieder und dient der Orientierung, nicht der Rechtsberatung. Maßgeblich sind die jeweiligen Gesetzes- und Verordnungstexte sowie die individuelle Prüfung — im Einzelfall rechtlich prüfen. Quellen: § 30 BSIG (2025), Anlage 1 zur DiGAV, BSI TR-03161, gematik Richtlinie zum Betrieb der Telematikinfrastruktur.