trustspace

Author: admin@trustspace.io

  • Datenpanne melden: der 72-Stunden-Guide nach Art. 33 DSGVO

    Datenpanne melden: der 72-Stunden-Guide nach Art. 33 DSGVO

    Das Wichtigste in Kürze

    • 72-Stunden-Frist: Eine meldepflichtige Datenpanne müssen Sie der zuständigen Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden melden, nachdem sie Ihnen bekannt geworden ist (Art. 33 DSGVO).
    • Nicht jede Panne ist meldepflichtig: Nur wenn ein Risiko für die Rechte und Freiheiten der betroffenen Personen besteht. Dokumentieren müssen Sie aber jede Panne.
    • Bei hohem Risiko müssen Sie zusätzlich die betroffenen Personen benachrichtigen (Art. 34 DSGVO).
    • Ablauf: erkennen → eindämmen → Risiko bewerten → melden → ggf. Betroffene informieren → dokumentieren.

    Eine E-Mail mit Kundendaten ging an den falschen Verteiler, ein Laptop wurde gestohlen, ein Verschlüsselungstrojaner hat zugeschlagen: In dem Moment, in dem so etwas passiert, tickt eine Uhr. Die DSGVO gibt Ihnen nur 72 Stunden, um eine meldepflichtige Datenpanne bei der Aufsichtsbehörde anzuzeigen. Dieser Guide zeigt Schritt für Schritt, wann Sie melden müssen, wie der Ablauf aussieht und welche Angaben in die Meldung gehören – inklusive ausfüllbarer Vorlage.

    Was ist eine Datenpanne im Sinne der DSGVO?

    Der umgangssprachliche Begriff „Datenpanne” heißt in der DSGVO Verletzung des Schutzes personenbezogener Daten. Nach Art. 4 Nr. 12 DSGVO ist das jede Verletzung der Sicherheit, die zur Vernichtung, zum Verlust, zur Veränderung oder zur unbefugten Offenlegung von bzw. zum unbefugten Zugang zu personenbezogenen Daten führt. Fachlich unterscheidet man drei Ausprägungen:

    • Verletzung der Vertraulichkeit – Unbefugte erhalten Zugang zu Daten (z. B. Fehlversand, Hackerangriff, gestohlener Datenträger).
    • Verletzung der Integrität – Daten werden unbefugt oder versehentlich verändert.
    • Verletzung der Verfügbarkeit – Daten gehen verloren oder sind nicht mehr zugänglich (z. B. Ransomware, gelöschtes Backup).

    Typische Beispiele aus der Praxis sind der Versand einer E-Mail mit offenem Empfängerverteiler (CC statt BCC), ein verlorener USB-Stick mit Personaldaten, ein Ransomware-Angriff oder ein an die falsche Adresse verschickter Bescheid. Ob es sich zugleich um eine Verletzung der Informationssicherheit handelt, ist eine verwandte, aber eigene Frage – die Abgrenzung zwischen Datenschutz und Informationssicherheit hilft, beide Perspektiven auseinanderzuhalten.

    Die 72-Stunden-Frist: Was Art. 33 DSGVO verlangt

    Fristbeginn: Die 72 Stunden laufen ab dem Zeitpunkt, zu dem Ihnen die Verletzung bekannt wird – also sobald Sie mit hinreichender Sicherheit wissen, dass ein Sicherheitsvorfall zu einer Datenpanne geführt hat. Die Frist läuft kalendarisch, also auch über Wochenenden und Feiertage.

    Der Verantwortliche meldet die Verletzung der zuständigen Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden. Zwei Punkte sind dabei entscheidend:

    • Ausnahme „kein Risiko”: Eine Meldung ist entbehrlich, wenn die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. Diese Einschätzung müssen Sie begründen und dokumentieren.
    • Verspätete Meldung: Schaffen Sie die 72 Stunden nicht, ist die Meldung trotzdem nachzuholen – dann aber mit einer Begründung für die Verzögerung.

    Wenn Sie als Auftragsverarbeiter eine Panne feststellen, melden Sie diese nicht selbst an die Behörde, sondern unverzüglich an den Verantwortlichen, für den Sie die Daten verarbeiten. Dieser entscheidet über die Meldung.

    Der Melde-Ablauf in sechs Schritten

    Ein klarer Ablauf verhindert, dass in der Hektik des Vorfalls Zeit verloren geht. Die folgende Reihenfolge hat sich bewährt:

    # Schritt Was zu tun ist
    1 Erkennen & eindämmen Vorfall stoppen (z. B. Zugang sperren), Ausmaß sichern, Beweise nicht überschreiben. Zeitpunkt des Bekanntwerdens festhalten – hier startet die Frist.
    2 Risiko bewerten Welche Daten, wie viele Personen, welche möglichen Folgen? Ergebnis: kein Risiko / Risiko / hohes Risiko.
    3 An Behörde melden Bei Risiko: binnen 72 Stunden an die zuständige Aufsichtsbehörde, in der Regel über deren Online-Meldeformular.
    4 Betroffene informieren Bei hohem Risiko zusätzlich die betroffenen Personen benachrichtigen (Art. 34 DSGVO), in klarer Sprache.
    5 Dokumentieren Jede Panne intern dokumentieren – Sachverhalt, Auswirkungen, ergriffene Maßnahmen (Art. 33 Abs. 5).
    6 Nachbereiten Ursache beheben und Schutzmaßnahmen verbessern, damit sich der Vorfall nicht wiederholt.

    Wer die Meldung übernimmt und die Bewertung verantwortet, hängt von Ihrer Organisation ab. In vielen Unternehmen ist das der Datenschutzbeauftragte – wann dieser überhaupt Pflicht ist, klärt unser Beitrag zur DSB-Pflicht. Fehlt intern die Kapazität, übernimmt oft ein externer Datenschutzbeauftragter für KMU die Fristenkontrolle und die Kommunikation mit der Behörde.

    Ob sich ein externer gegenüber einem internen Datenschutzbeauftragten rechnet, hängt von Unternehmensgröße und Fallzahl ab – ein Kosten-Nutzen-Vergleich beider Modelle schafft hier Klarheit.

    Muss ich auch die betroffenen Personen informieren?

    Nicht immer – aber immer dann, wenn die Datenpanne voraussichtlich ein hohes Risiko für die Rechte und Freiheiten der betroffenen Personen zur Folge hat. In diesem Fall verlangt Art. 34 DSGVO, dass Sie die Betroffenen unverzüglich und in klarer, einfacher Sprache benachrichtigen, damit sie sich schützen können (etwa Passwörter ändern oder Konten überwachen).

    Die Benachrichtigung der Betroffenen kann entfallen, wenn eine der folgenden Bedingungen erfüllt ist:

    • Die betroffenen Daten waren durch geeignete Maßnahmen wie eine starke Verschlüsselung für Unbefugte unbrauchbar.
    • Sie haben durch nachträgliche Maßnahmen dafür gesorgt, dass das hohe Risiko aller Wahrscheinlichkeit nach nicht mehr eintritt.
    • Die individuelle Benachrichtigung wäre mit unverhältnismäßigem Aufwand verbunden – dann ist eine öffentliche Bekanntmachung zulässig.

    Melde-Vorlage: diese Angaben braucht die Aufsichtsbehörde

    Die Meldung nach Art. 33 Abs. 3 DSGVO muss einen Mindestinhalt haben. Nutzen Sie die folgende Vorlage, um im Ernstfall keine Angabe zu vergessen – die meisten Aufsichtsbehörden fragen genau diese Felder in ihrem Online-Formular ab:

    Pflichtangabe Ihre Eintragung
    Art der Verletzung (was ist passiert)
    Kategorien betroffener Daten (z. B. Kontaktdaten, Gesundheitsdaten)
    Ungefähre Zahl betroffener Personen und Datensätze
    Kontaktstelle (Datenschutzbeauftragter oder andere Anlaufstelle)
    Wahrscheinliche Folgen der Verletzung
    Ergriffene / vorgeschlagene Maßnahmen zur Behebung und Schadensbegrenzung

    Liegen noch nicht alle Informationen vor, dürfen Sie die Angaben schrittweise nachreichen. Wichtig ist, die 72-Stunden-Meldung nicht zu verzögern, nur weil einzelne Details noch offen sind.

    An welche Behörde wird gemeldet?

    Zuständig ist die Datenschutz-Aufsichtsbehörde des Bundeslandes, in dem Ihr Unternehmen seinen Sitz hat. Die Landesbehörden stellen dafür in der Regel ein Online-Meldeformular bereit, das Sie direkt ausfüllen können. Für Unternehmen mit Niederlassungen in mehreren EU-Staaten gilt das Prinzip der federführenden Behörde am Ort der Hauptniederlassung.

    Die DSGVO ist nicht das einzige Regelwerk mit engen Meldefristen: Für Betreiber wichtiger oder besonders wichtiger Einrichtungen gelten unter der NIS2-Richtlinie eigene, teils noch kürzere Fristen. Wie diese aussehen, zeigt unsere Checkliste zur NIS2-Meldepflicht mit Fristen.

    Bußgelder und Dokumentationspflicht: was auf dem Spiel steht

    Wer eine meldepflichtige Datenpanne nicht, zu spät oder unvollständig meldet, riskiert ein Bußgeld von bis zu 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes (Art. 83 Abs. 4 DSGVO) – je nachdem, welcher Betrag höher ist. Kommt ein zugrunde liegender Datenschutzverstoß hinzu, kann der Rahmen sogar bei 20 Mio. Euro bzw. 4 % liegen.

    Unabhängig davon gilt die Dokumentationspflicht nach Art. 33 Abs. 5 DSGVO: Sie müssen jede Datenpanne intern erfassen – auch die, die Sie als nicht meldepflichtig einstufen. Diese Dokumentation ist Ihr Nachweis gegenüber der Aufsichtsbehörde, dass Sie den Vorfall bewertet und richtig gehandelt haben. Wie sich solche Nachweis- und Datenschutzpflichten im Mittelstand mit vertretbarem Aufwand erfüllen lassen, ordnet unser Überblick zu Datenschutz im Mittelstand – Kosten und Pflichten ein.

    Datenpannen vorbeugen statt nur melden

    Vorbeugung heißt vor allem, die passenden technischen und organisatorischen Maßnahmen nach Art. 32 DSGVO festzulegen und aktuell zu halten – von Zugriffskontrolle über Verschlüsselung bis zum getesteten Backup.

    Die beste Meldung ist die, die nie nötig wird. Die meisten Datenpannen entstehen nicht durch spektakuläre Hackerangriffe, sondern durch Alltagsfehler: falsche Empfänger, verlorene Geräte, schwache Zugriffsrechte. Wer technische und organisatorische Maßnahmen systematisch steuert, senkt sowohl die Häufigkeit als auch die Schwere solcher Vorfälle – und hat im Ernstfall Ablauf, Zuständigkeiten und Dokumentation bereits geregelt. Eine ISMS-Software hilft dabei, Risiken, Maßnahmen und Meldeprozesse an einer Stelle zu bündeln, statt sie im Vorfall erst zu improvisieren.

    Häufige Fragen (FAQ)

    Wie lange habe ich Zeit, eine Datenpanne zu melden?

    Grundsätzlich unverzüglich und möglichst binnen 72 Stunden, nachdem Ihnen die Datenpanne bekannt geworden ist. Die Frist läuft kalendarisch, also auch über Wochenenden und Feiertage.

    Muss ich jede Datenpanne melden?

    Nein. Meldepflichtig ist sie nur, wenn ein Risiko für die Rechte und Freiheiten der betroffenen Personen besteht. Dokumentieren müssen Sie aber jede Panne, auch die nicht meldepflichtige.

    Was passiert, wenn ich die 72 Stunden verpasse?

    Die Meldung ist dennoch nachzuholen, dann mit einer Begründung für die Verzögerung. Ein Versäumnis kann mit einem Bußgeld von bis zu 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes geahndet werden.

    Wann muss ich die betroffenen Personen informieren?

    Wenn die Datenpanne voraussichtlich ein hohes Risiko für die betroffenen Personen mit sich bringt (Art. 34 DSGVO). Waren die Daten etwa stark verschlüsselt oder wurde das hohe Risiko nachträglich beseitigt, kann die Benachrichtigung entfallen.

    Wer meldet die Panne, wenn ein Dienstleister sie verursacht?

    Der Auftragsverarbeiter meldet die Verletzung unverzüglich an den Verantwortlichen. Die Meldung an die Aufsichtsbehörde verantwortet der Verantwortliche, nicht der Dienstleister.

  • Was ist ein ISMS? Definition, Bestandteile und Nutzen

    Was ist ein ISMS? Definition, Bestandteile und Nutzen

    Das Wichtigste in Kürze

    • Definition: Ein ISMS (Informationssicherheits-Managementsystem) ist der geregelte Rahmen, mit dem ein Unternehmen Informationssicherheit systematisch steuert – über Prozesse, Verantwortlichkeiten und Maßnahmen statt über Einzelaktionen.
    • Grundlage: Der internationale Standard ISO/IEC 27001 beschreibt die Anforderungen an ein ISMS. Kern ist der PDCA-Zyklus (Plan-Do-Check-Act).
    • Nutzen: Ein ISMS senkt Risiken, erfüllt regulatorische Pflichten (u. a. NIS2, DSGVO) und schafft Vertrauen bei Kunden und Partnern.
    • Für wen: Nicht nur für Konzerne – auch der Mittelstand profitiert, wenn das ISMS auf die eigene Größe zugeschnitten ist.

    Was ist ein ISMS? Die Definition

    Die Abkürzung ISMS steht für Informationssicherheits-Managementsystem (englisch: Information Security Management System). Ein ISMS ist kein Produkt und keine Software allein, sondern ein Managementsystem: ein festgelegter Satz aus Leitlinien, Prozessen, Rollen und Maßnahmen, mit dem eine Organisation die Sicherheit ihrer Informationen plant, umsetzt, überprüft und laufend verbessert.

    Der entscheidende Unterschied zu einzelnen IT-Sicherheitsmaßnahmen liegt im Wort „System”: Eine Firewall oder ein Passwortkonzept sind Einzelmaßnahmen. Ein ISMS sorgt dafür, dass solche Maßnahmen aus einer bewussten Risikobewertung abgeleitet, dokumentiert, Verantwortlichen zugeordnet und regelmäßig auf Wirksamkeit geprüft werden. Ziel ist der Schutz der drei klassischen Schutzziele der Informationssicherheit: Vertraulichkeit, Integrität und Verfügbarkeit.

    Warum braucht ein Unternehmen ein ISMS?

    Ein ISMS beantwortet drei Fragen, die sich jedes Unternehmen früher oder später stellen muss: Welche Informationen sind schützenswert? Welche Risiken bedrohen sie? Und welche Maßnahmen sind angemessen? Der Nutzen ist dabei zugleich strategisch und regulatorisch:

    • Risiken reduzieren: Sicherheitsvorfälle werden seltener und weniger folgenschwer, weil Risiken systematisch erkannt und behandelt werden.
    • Pflichten erfüllen: Regelwerke wie die NIS2-Richtlinie oder die DSGVO verlangen nachweisbare technische und organisatorische Maßnahmen – ein ISMS liefert genau diesen Nachweis.
    • Vertrauen schaffen: Ein zertifiziertes ISMS nach ISO 27001 ist im B2B-Geschäft oft Voraussetzung, um überhaupt als Lieferant infrage zu kommen.

    Die Bestandteile eines ISMS im Überblick

    Ein ISMS besteht aus mehreren aufeinander aufbauenden Elementen. Die folgende Übersicht zeigt, woraus sich ein Managementsystem zusammensetzt – die Umsetzung jedes Bausteins vertiefen wir in eigenen Beiträgen.

    Baustein Was dahintersteckt
    Geltungsbereich (Scope) Festlegung, welche Bereiche, Standorte und Prozesse das ISMS umfasst.
    Asset- und Strukturanalyse Erfassung der schützenswerten Werte (Daten, Systeme, Prozesse). Details in der ISMS-Strukturanalyse.
    Risikomanagement Bewertung von Bedrohungen und Festlegung, wie mit ihnen umgegangen wird.
    Maßnahmen (Controls) Technische und organisatorische Maßnahmen, abgeleitet aus dem Anhang A der ISO 27001.
    Dokumentation und Rollen Richtlinien, Verantwortlichkeiten und Nachweise – von der Leitlinie bis zum Informationssicherheitsbeauftragten.
    Audit und Verbesserung Regelmäßige Überprüfung der Wirksamkeit. Mehr dazu unter ISMS-Audits.

    ISMS und ISO 27001: Wie hängen sie zusammen?

    ISMS und ISO 27001 werden oft synonym verwendet, meinen aber nicht dasselbe. Das ISMS ist das Managementsystem in Ihrem Unternehmen. ISO/IEC 27001 ist der internationale Standard, der die Anforderungen an ein solches System definiert. Man kann ein ISMS betreiben, ohne es zertifizieren zu lassen – die Zertifizierung nach ISO 27001 macht die Konformität jedoch offiziell nachweisbar. Wie ein ISMS konkret nach diesem Standard aufgebaut wird, zeigt unser Praxis-Guide zum Aufbau eines ISMS nach ISO 27001.

    Ein ISMS lebt: der PDCA-Zyklus

    Ein ISMS ist kein einmaliges Projekt, sondern ein fortlaufender Kreislauf. Die ISO 27001 folgt dem PDCA-Zyklus:

    • Plan: Geltungsbereich, Risiken und Ziele festlegen.
    • Do: Maßnahmen umsetzen und dokumentieren.
    • Check: Wirksamkeit durch Audits und Kennzahlen überprüfen.
    • Act: Aus Erkenntnissen lernen und nachsteuern.

    Dieser Kreislauf sorgt dafür, dass ein ISMS mit neuen Bedrohungen und Anforderungen mitwächst, statt zu veralten.

    ISMS für den Mittelstand: pragmatisch statt überdimensioniert

    Ein häufiges Missverständnis ist, ein ISMS lohne sich nur für Großkonzerne. Tatsächlich lässt sich der Umfang an die Unternehmensgröße anpassen: Der Geltungsbereich, die Tiefe der Dokumentation und die eingesetzten Werkzeuge skalieren mit dem Bedarf. Wie ein schlankes, aber wirksames ISMS im Mittelstand gelingt, beschreibt unser Beitrag ISMS für KMU.

    Software oder Beratung: Wie setzt man ein ISMS um?

    In der Praxis führt ein hybrider Ansatz am schnellsten zum Ziel: Eine ISMS-Software automatisiert wiederkehrende Aufgaben wie Asset-Erfassung, Risikobewertung und Nachweisführung, während Beratung die richtigen Entscheidungen absichert. Unternehmen, die eine Zertifizierung anstreben, kombinieren das häufig mit einer strukturierten ISO-27001-Zertifizierungsberatung, um Aufwand und Zeit bis zum Audit zu reduzieren.

    Welche Funktionen eine solche Plattform mitbringen sollte, von der zentralen Dokumentenlenkung über das Compliance-Cockpit bis zur automatisierten Auditvorbereitung, ordnet unser Überblick zu den Vorteilen einer ISMS-Software ein.

    Häufige Fragen (FAQ)

    Was ist ein ISMS einfach erklärt?

    Ein ISMS ist ein geregeltes System aus Prozessen und Verantwortlichkeiten, mit dem ein Unternehmen dafür sorgt, dass seine Informationen dauerhaft vertraulich, korrekt und verfügbar bleiben – nicht durch Einzelaktionen, sondern systematisch und überprüfbar.

    Was ist der Unterschied zwischen ISMS und ISO 27001?

    Das ISMS ist das Managementsystem im Unternehmen. ISO 27001 ist der Standard, der beschreibt, wie ein solches System aussehen muss. Die Zertifizierung nach ISO 27001 weist nach, dass das ISMS diese Anforderungen erfüllt.

    Ist ein ISMS Pflicht?

    Es gibt keine allgemeine gesetzliche Pflicht zum ISMS. Regelwerke wie NIS2 verlangen aber nachweisbare Sicherheitsmaßnahmen, die sich am einfachsten über ein ISMS umsetzen und belegen lassen. Für viele betroffene Unternehmen ist es damit faktisch unverzichtbar.

    Was kostet ein ISMS?

    Die Kosten hängen von Unternehmensgröße, Geltungsbereich und Umsetzungsweg ab. Software und ein pragmatischer Scope senken den Aufwand deutlich gegenüber einer rein manuellen Einführung.

  • SOC 2 Compliance für Unternehmen erklärt

    SOC 2 Compliance für Unternehmen erklärt

    Das Wichtigste in Kürze

    • SOC 2 ist ein vom AICPA entwickeltes Rahmenwerk, das die Sicherheit, Verfügbarkeit und Vertraulichkeit von Kundendaten bei Dienstleistern überprüft.
    • Die SOC 2 Compliance basiert auf fünf Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality und Privacy.
    • Beim SOC 2 Type 1 wird das Kontrolldesign zu einem Stichtag geprüft, beim SOC 2 Type 2 zusätzlich die Wirksamkeit über einen Zeitraum von mindestens sechs Monaten.
    • Besonders relevant ist SOC 2 für SaaS-Anbieter, Cloud-Dienstleister und IT-Unternehmen, die Kundendaten verarbeiten – insbesondere bei US-amerikanischen Geschäftsbeziehungen.
    • Eine strukturierte Vorbereitung mit geeigneten Compliance-Tools reduziert Kosten und verkürzt den Audit-Prozess erheblich.

     

    Was ist SOC 2 und warum ist es wichtig?

    SOC 2 (System and Organization Controls 2) ist ein Prüfstandard des American Institute of Certified Public Accountants (AICPA). Er definiert Anforderungen an Dienstleistungsunternehmen hinsichtlich des Umgangs mit Kundendaten. Anders als etwa ISO 27001 handelt es sich bei SOC 2 nicht um eine Zertifizierung im klassischen Sinne, sondern um einen Prüfbericht (Audit Report), der von einem unabhängigen Wirtschaftsprüfer (CPA) erstellt wird.

    Die SOC 2 Compliance hat sich in den vergangenen Jahren zum De-facto-Standard für Dienstleister entwickelt, die Kundendaten verarbeiten – insbesondere im US-amerikanischen Markt. Immer häufiger verlangen auch europäische Unternehmen von ihren Anbietern einen SOC-2-Bericht als Nachweis angemessener Sicherheitskontrollen. Nicht zu verwechseln ist SOC 2 mit einem Security Operations Center (SOC) – dieses ist die organisatorische Einheit für die laufende Bedrohungsüberwachung, während SOC 2 den Prüfstandard für den Nachweis wirksamer Kontrollen bezeichnet.

    Konkret beantwortet ein SOC-2-Bericht die Frage: Verfügt das geprüfte Unternehmen über wirksame Kontrollen, um die Sicherheit, Verfügbarkeit und Vertraulichkeit von Kundendaten zu gewährleisten?

     

    Für wen ist SOC 2 relevant?

    Die SOC 2 Anforderungen richten sich primär an Unternehmen, die Dienstleistungen erbringen und dabei Zugriff auf Kundendaten haben. Typische Zielgruppen sind:

    • SaaS-Anbieter: Cloud-basierte Softwarelösungen, die Kundendaten speichern oder verarbeiten
    • Cloud-Dienstleister: Infrastructure-as-a-Service (IaaS) und Platform-as-a-Service (PaaS) Provider
    • Managed Service Provider (MSP): IT-Dienstleister, die Systeme und Netzwerke für Kunden betreiben
    • Rechenzentren und Hosting-Anbieter: Unternehmen, die physische oder virtuelle Infrastruktur bereitstellen
    • Finanzdienstleister und FinTechs: Anbieter von Zahlungs-, Buchhaltungs- oder Bankdienstleistungen
    • HR- und Payroll-Anbieter: Unternehmen, die sensible Mitarbeiterdaten verarbeiten

    In der Praxis wird SOC 2 Compliance zunehmend zur Voraussetzung für Geschäftsbeziehungen: Große Unternehmenskunden, insbesondere aus den USA, fordern einen aktuellen SOC-2-Bericht, bevor sie einen Vertrag abschließen. Wer keinen vorweisen kann, verliert potenzielle Deals – besonders im Enterprise-Segment.

     

    Die 5 Trust Service Criteria im Detail

    Die Trust Service Criteria (TSC) bilden das inhaltliche Fundament der SOC 2 Compliance. Sie definieren, welche Kontrollbereiche geprüft werden. Das Kriterium Security ist verpflichtend, die übrigen vier werden je nach Geschäftsmodell und Kundenanforderungen hinzugewählt.

     

    1. Security (Sicherheit) – verpflichtend

    Das Security-Kriterium – auch als Common Criteria bezeichnet – bildet die Basis jeder SOC-2-Prüfung. Es umfasst Kontrollen zum Schutz von Systemen und Daten vor unbefugtem Zugriff. Typische SOC 2 Kontrollen in diesem Bereich sind:

    • Zugriffskontrollen und Berechtigungsmanagement
    • Firewalls, Intrusion Detection und Netzwerksicherheit
    • Verschlüsselung von Daten (in Transit und at Rest)
    • Multi-Faktor-Authentifizierung (MFA)
    • Incident-Response-Prozesse
    • Sicherheitsbewusstsein und Mitarbeiterschulungen

     

    2. Availability (Verfügbarkeit)

    Dieses Kriterium prüft, ob Systeme und Dienste gemäß den vereinbarten Service Level Agreements (SLAs) verfügbar sind. Relevant für Anbieter, die hohe Uptime-Garantien geben. Kontrollen umfassen unter anderem Disaster-Recovery-Pläne, Monitoring, Kapazitätsmanagement und Redundanzkonzepte.

     

    3. Processing Integrity (Verarbeitungsintegrität)

    Hier wird überprüft, ob die Datenverarbeitung vollständig, korrekt, zeitnah und autorisiert erfolgt. Besonders wichtig für Unternehmen, die Finanztransaktionen, Berechnungen oder datengesteuerte Entscheidungen verarbeiten.

     

    4. Confidentiality (Vertraulichkeit)

    Das Vertraulichkeitskriterium adressiert den Schutz von Informationen, die als vertraulich klassifiziert sind – etwa Geschäftsgeheimnisse, geistiges Eigentum oder vertragliche Informationen. Kontrollen umfassen Datenklassifizierung, Zugriffsbeschränkungen und sichere Datenvernichtung.

     

    5. Privacy (Datenschutz)

    Das Privacy-Kriterium bezieht sich auf den Schutz personenbezogener Daten gemäß den Datenschutzrichtlinien des Unternehmens. Es orientiert sich an international anerkannten Datenschutzprinzipien wie Zweckbindung, Datenminimierung und Betroffenenrechte. Für europäische Unternehmen besteht hier eine enge Verbindung zur DSGVO.

     

    SOC 2 Type 1 vs. SOC 2 Type 2: Die Unterschiede

    Ein zentraler Aspekt der SOC 2 Compliance ist die Unterscheidung zwischen Type 1 und Type 2. Beide Prüfungen folgen denselben Trust Service Criteria, unterscheiden sich aber grundlegend in Umfang und Aussagekraft.

    Kriterium SOC 2 Type 1 SOC 2 Type 2
    Prüfungsgegenstand Design der Kontrollen Design und operative Wirksamkeit der Kontrollen
    Zeitraum Stichtagsbezogen (Point in Time) Prüfungszeitraum von mindestens 6 Monaten (häufig 12 Monate)
    Aussagekraft Kontrollen sind angemessen gestaltet Kontrollen funktionieren nachweislich über einen Zeitraum
    Dauer der Prüfung Wenige Wochen Mehrere Monate (je nach Prüfungszeitraum)
    Kosten Geringer (ca. 20.000–50.000 USD) Höher (ca. 30.000–100.000+ USD)
    Marktakzeptanz Einstieg, aber zunehmend nicht ausreichend Branchenstandard, von den meisten Kunden gefordert
    Empfehlung Als erster Schritt oder bei Zeitdruck Langfristiges Ziel für nachhaltigen Nachweis

    Praxisempfehlung: Viele Unternehmen starten mit einem SOC 2 Type 1-Bericht, um kurzfristig die Kontrollen nachzuweisen, und arbeiten parallel daran, die operative Wirksamkeit für den SOC 2 Type 2-Bericht zu dokumentieren. Langfristig erwarten die meisten Kunden und Partner einen aktuellen Type-2-Bericht.

     

    Der SOC-2-Audit-Prozess: Phasen und Ablauf

    Ein SOC2 Audit ist ein strukturierter Prozess, der sich in mehrere Phasen gliedert. Eine sorgfältige Vorbereitung ist entscheidend, um den Prüfungsprozess effizient zu durchlaufen und ein positives Ergebnis zu erzielen.

     

    Phase 1: Scoping und Readiness Assessment

    Im ersten Schritt wird der Prüfungsumfang festgelegt. Dabei werden folgende Fragen beantwortet:

    • Welche Systeme und Dienste sind im Scope des SOC-2-Berichts?
    • Welche Trust Service Criteria sind relevant?
    • Welche bestehenden Kontrollen gibt es bereits?
    • Wo bestehen Lücken (Gap-Analyse)?

    Ein Readiness Assessment durch einen erfahrenen Berater oder Prüfer hilft, Schwachstellen vor dem eigentlichen Audit zu identifizieren und zu beheben.

     

    Phase 2: Kontrollimplementierung und Dokumentation

    Auf Basis der Gap-Analyse werden fehlende Kontrollen implementiert und bestehende Kontrollen dokumentiert. Zentrale Elemente sind:

    • Erstellung und Formalisierung von Richtlinien und Verfahren (Policies & Procedures)
    • Implementierung technischer Kontrollen (z.B. Zugriffsmanagement, Monitoring, Verschlüsselung)
    • Einrichtung von Prozessen für Change Management, Incident Response und Risikobewertung
    • Aufbau einer lückenlosen Nachweisdokumentation (Evidence Collection)

     

    Phase 3: Beobachtungszeitraum (nur Type 2)

    Beim SOC 2 Type 2 müssen die implementierten Kontrollen über einen definierten Zeitraum – in der Regel sechs bis zwölf Monate – nachweislich wirksam betrieben werden. Während dieses Zeitraums sammelt das Unternehmen kontinuierlich Nachweise: Logdateien, Genehmigungsprotokolle, Screenshots, Ticketsysteme und weitere Dokumentation.

     

    Phase 4: Das eigentliche Audit

    Ein zugelassener CPA (Certified Public Accountant) oder eine CPA-Firma führt die Prüfung durch. Der Auditor:

    • Prüft das Design der Kontrollen (Type 1 und Type 2)
    • Testet die operative Wirksamkeit durch Stichproben und Nachweisanalyse (nur Type 2)
    • Führt Interviews mit verantwortlichen Mitarbeitern
    • Dokumentiert Feststellungen und mögliche Abweichungen (Exceptions)

     

    Phase 5: Berichterstellung und Nachbereitung

    Der Auditor erstellt den SOC-2-Bericht, der eine Beschreibung des Systems, die Stellungnahme des Prüfers (Opinion), die geprüften Kontrollen und deren Testergebnisse enthält. Ein unqualified opinion (uneingeschränktes Prüfurteil) bestätigt, dass die Kontrollen den Anforderungen entsprechen. Der Bericht wird anschließend an Kunden und Partner weitergegeben – in der Regel unter einer Vertraulichkeitsvereinbarung (NDA).

     

    SOC 2 Anforderungen: Kontrollen und Nachweise

    Die konkreten SOC 2 Anforderungen variieren je nach gewählten Trust Service Criteria und Geschäftsmodell. Es gibt jedoch Kernbereiche, die in nahezu jedem SOC-2-Audit geprüft werden. Eine strukturierte SOC 2 Compliance Checklist hilft bei der systematischen Vorbereitung:

     

    Organisatorische Kontrollen

    • Sicherheitsrichtlinien: Dokumentierte Information Security Policy, Acceptable Use Policy, Data Classification Policy
    • Risikomanagement: Formaler Risikobewertungsprozess mit regelmäßiger Aktualisierung
    • Governance: Definierte Rollen und Verantwortlichkeiten für Informationssicherheit
    • Vendor Management: Bewertung und Überwachung von Drittanbietern
    • Mitarbeiterschulungen: Regelmäßige Security-Awareness-Trainings mit Teilnahmeprotokollen

     

    Technische Kontrollen

    • Zugriffsmanagement: Rollenbasierte Zugriffskontrollen (RBAC), regelmäßige Access Reviews, Offboarding-Prozesse
    • Verschlüsselung: TLS/SSL für Daten in Transit, AES-256 für Daten at Rest
    • Monitoring und Logging: Zentralisiertes Logging, SIEM-Systeme, Alerting bei Anomalien
    • Schwachstellenmanagement: Regelmäßige Vulnerability Scans und Patch-Management
    • Netzwerksicherheit: Firewalls, Netzwerksegmentierung, VPN für Remote-Zugriff
    • Endpoint Security: Antivirus, EDR-Lösungen, Mobile Device Management

     

    Operative Kontrollen

    • Change Management: Dokumentierte Prozesse für Änderungen an Systemen und Code
    • Incident Response: Formaler Plan mit definierten Eskalationsstufen und Kommunikationswegen
    • Business Continuity: Disaster-Recovery-Pläne mit regelmäßigen Tests
    • Backup-Management: Automatisierte Backups mit getesteter Wiederherstellung

     

    Häufige Fehler und Kostentreiber bei der SOC-2-Umsetzung

    Die Vorbereitung auf ein SOC2 Audit birgt typische Stolperfallen. Wer diese kennt, spart Zeit, Geld und vermeidet unangenehme Überraschungen während der Prüfung.

     

    1. Zu breites Scoping

    Ein häufiger Fehler ist ein zu weit gefasster Prüfungsumfang. Nicht alle Systeme und Dienste müssen im SOC-2-Scope liegen. Eine klare Abgrenzung reduziert den Aufwand erheblich – ohne die Aussagekraft des Berichts zu schmälern.

     

    2. Fehlende oder inkonsistente Dokumentation

    SOC-2-Auditoren prüfen nicht nur, ob Kontrollen existieren, sondern ob sie dokumentiert, kommuniziert und nachweisbar sind. Unternehmen, die ihre Richtlinien und Prozesse erst kurz vor dem Audit formalisieren, stoßen häufig auf Inkonsistenzen.

     

    3. Manuelle Evidence Collection

    Die Nachweissammlung ist einer der größten Kostentreiber. Wer Screenshots manuell erstellt, Logdateien einzeln exportiert und Nachweise in Ordnerstrukturen ablegt, investiert unverhältnismäßig viel Zeit. Automatisierte Lösungen können diesen Aufwand um bis zu 80 Prozent reduzieren.

     

    4. Keine kontinuierliche Compliance

    SOC 2 ist kein einmaliges Projekt. Der Bericht gilt in der Regel für zwölf Monate und muss dann erneuert werden. Unternehmen, die Kontrollen nur für das Audit betreiben, statt sie in den Arbeitsalltag zu integrieren, haben beim nächsten Audit erneut den vollen Aufwand.

     

    5. Unterschätzung der Kosten

    Die Kosten einer SOC 2 Zertifizierung (im Sinne des Berichts) setzen sich aus mehreren Komponenten zusammen: Auditor-Honorare, interne Personalkosten, Toolkosten und gegebenenfalls Beratungsgebühren. Je nach Unternehmensgröße und Scope liegen die Gesamtkosten zwischen 50.000 und 200.000 USD – ein Readiness Assessment und geeignete Tools können jedoch erheblich zur Kostenkontrolle beitragen.

     

    SOC 2 Compliance für kleinere Teams: Praxistipps

    Auch Startups und kleinere Teams können die SOC 2 Anforderungen erfolgreich umsetzen – wenn sie strategisch vorgehen. Die folgenden Empfehlungen helfen, den Aufwand handhabbar zu halten:

    • Klein starten: Beginnen Sie mit SOC 2 Type 1 und dem Security-Kriterium. Erweitern Sie den Scope erst, wenn Kunden es explizit fordern.
    • Compliance-Plattform nutzen: Tools wie TrustSpace automatisieren die Nachweissammlung, Richtlinienverwaltung und Audit-Vorbereitung – ein enormer Vorteil für kleine Teams mit begrenzten Ressourcen.
    • Bestehende Frameworks nutzen: Wenn Sie bereits eine ISO 27001-Zertifizierung besitzen, decken viele Kontrollen auch SOC-2-Anforderungen ab. Vermeiden Sie Doppelarbeit durch ein integriertes Managementsystem.
    • Security-by-Design: Integrieren Sie Sicherheitskontrollen von Anfang an in Ihre Entwicklungs- und Betriebsprozesse, statt sie nachträglich aufzusetzen.
    • Verantwortlichkeiten klar zuordnen: Auch ohne dediziertes Compliance-Team sollte eine Person als SOC-2-Projektleitung benannt werden.
    • Frühzeitig mit dem Auditor sprechen: Ein Vorgespräch mit der Prüfungsgesellschaft klärt Erwartungen und verhindert Missverständnisse.

     

    SOC 2 und andere Frameworks: Synergien nutzen

    Die SOC 2 Compliance steht nicht isoliert. Unternehmen, die bereits andere Sicherheitsstandards umgesetzt haben, profitieren von erheblichen Überschneidungen:

    • ISO 27001: Hohe Überlappung bei Kontrollen zu Zugriffsmanagement, Risikobewertung, Incident Response und Dokumentation. Eine ISO-27001-Zertifizierung bildet eine starke Basis für SOC 2.
    • DSGVO: Das Privacy-Kriterium der Trust Service Criteria korreliert mit zentralen DSGVO-Anforderungen. Bestehende technisch-organisatorische Maßnahmen (TOM) sind direkt verwertbar.
    • TISAX: Unternehmen mit TISAX-Assessment verfügen bereits über fundierte Informationssicherheitskontrollen, die für SOC 2 adaptiert werden können.
    • SOC 1 vs. SOC 2: SOC 1 fokussiert auf Kontrollen, die für die Finanzberichterstattung der Kunden relevant sind. SOC 2 ist breiter gefasst und adressiert die allgemeine Informationssicherheit.

     

    Häufig gestellte Fragen (FAQ)

     

    Was ist SOC 2 und für wen ist es relevant?

    SOC 2 ist ein Prüfstandard des AICPA, der die Wirksamkeit von Sicherheitskontrollen bei Dienstleistungsunternehmen bewertet. Relevant ist SOC 2 vor allem für SaaS-Anbieter, Cloud-Dienstleister, IT-Outsourcing-Unternehmen und alle Organisationen, die Kundendaten verarbeiten oder hosten. Besonders im US-amerikanischen Markt ist ein aktueller SOC-2-Bericht häufig Voraussetzung für Geschäftsabschlüsse.

     

    Was ist der Unterschied zwischen SOC 2 Type 1 und Type 2?

    SOC 2 Type 1 prüft, ob angemessene Kontrollen zu einem bestimmten Stichtag implementiert sind (Designprüfung). SOC 2 Type 2 geht darüber hinaus und testet, ob diese Kontrollen über einen Zeitraum von mindestens sechs Monaten tatsächlich wirksam betrieben werden (Wirksamkeitsprüfung). Type 2 hat eine deutlich höhere Aussagekraft und wird von den meisten Kunden und Partnern bevorzugt.

     

    Wie läuft ein SOC-2-Audit ab?

    Ein SOC2 Audit durchläuft typischerweise fünf Phasen: Scoping und Readiness Assessment, Kontrollimplementierung und Dokumentation, Beobachtungszeitraum (bei Type 2), die eigentliche Prüfung durch einen CPA-Auditor sowie die Berichterstellung. Die Gesamtdauer beträgt je nach Type und Vorbereitungsstand zwischen drei Monaten (Type 1) und zwölf bis achtzehn Monaten (Type 2 inklusive Beobachtungszeitraum).

     

    Welche Anforderungen und Kontrollen sind entscheidend?

    Die SOC 2 Anforderungen orientieren sich an den fünf Trust Service Criteria. Entscheidend sind vor allem Kontrollen in den Bereichen Zugriffsmanagement, Verschlüsselung, Monitoring, Change Management, Incident Response und Vendor Management. Alle Kontrollen müssen nicht nur implementiert, sondern auch dokumentiert und durch Nachweise belegbar sein.

     

    Fazit: SOC 2 Compliance strategisch angehen

    Die SOC 2 Compliance ist mehr als eine regulatorische Pflichtübung – sie ist ein strategischer Wettbewerbsvorteil. Unternehmen, die einen aktuellen SOC-2-Bericht vorweisen können, signalisieren Kunden und Partnern, dass sie den Schutz von Daten ernst nehmen. Gerade für den US-Markt und Enterprise-Kunden ist SOC 2 heute oft eine Grundvoraussetzung.

    Der Schlüssel zum Erfolg liegt in einer strukturierten Vorbereitung: Definieren Sie einen klaren Scope, führen Sie eine Gap-Analyse durch, nutzen Sie Synergien mit bestehenden Frameworks und setzen Sie auf Automatisierung bei der Nachweissammlung. So reduzieren Sie Kosten, vermeiden typische Fehler und schaffen eine Compliance-Grundlage, die auch langfristig tragfähig ist. Eine zentrale ISMS-Software wie TrustSpaceOS automatisiert die Nachweissammlung und führt SOC-2-Kontrollen, Richtlinien und Audit-Evidence an einem Ort zusammen.

     

    SOC 2 Compliance effizient umsetzen – mit TrustSpace

    TrustSpace unterstützt Sie als integrierte ISMS-Plattform bei der systematischen Umsetzung Ihrer SOC 2 Compliance. Von der automatisierten Nachweissammlung über die Richtlinienverwaltung bis zur Audit-Vorbereitung – alles in einer Lösung. Nutzen Sie Synergien mit ISO 27001, DSGVO und weiteren Frameworks und behalten Sie den Überblick über alle Kontrollen und Nachweise.

    Jetzt Demo vereinbaren und SOC 2 Readiness beschleunigen.

  • KI-Risikomanagement strukturiert aufbauen

    KI-Risikomanagement strukturiert aufbauen

    Das Wichtigste in Kürze

    • Ein strukturiertes KI-Risikomanagement ist für Unternehmen unverzichtbar – der EU AI Act macht es für eigenständige Hochrisiko-KI-Systeme (Anhang III) ab Dezember 2027 zur Pflicht (durch den Digital Omnibus vom August 2026 verschoben).
    • Typische KI-Risiken umfassen Bias, mangelnde Transparenz, Datenschutzverstöße, Sicherheitslücken und ungeklärte Haftungsfragen.
    • Unternehmen, die bereits ein ISMS nach ISO 27001 oder ein DSGVO-Compliance-Programm betreiben, können KI-Risikomanagement in bestehende Strukturen integrieren.
    • Klare Rollen und Verantwortlichkeiten sowie ein minimaler Governance-Prozess sind die Grundlage für ein wirksames AI Risk Management.
    • Sofort umsetzbare Maßnahmen: KI-Systeme inventarisieren, Risikokategorien definieren und Verantwortlichkeiten festlegen.

     

    Warum KI-Risikomanagement jetzt relevant ist

    Künstliche Intelligenz verändert Geschäftsprozesse in nahezu jeder Branche. Unternehmen setzen KI-Systeme ein, um Entscheidungen zu automatisieren, Kundeninteraktionen zu personalisieren oder große Datenmengen auszuwerten. Mit der wachsenden Verbreitung steigen jedoch auch die Risiken – und der regulatorische Druck nimmt zu.

    Der EU AI Act (Verordnung (EU) 2024/1689) verpflichtet Anbieter und Betreiber eigenständiger Hochrisiko-KI-Systeme (Anhang III) zur Einführung eines umfassenden Risikomanagementsystems; diese Pflichten wurden durch den EU Digital Omnibus von August 2026 auf Dezember 2027 verschoben. Doch auch unabhängig von der Regulierung ist ein systematisches KI-Risikomanagement strategisch sinnvoll: Es schützt vor Reputationsschäden, reduziert Haftungsrisiken und schafft Vertrauen bei Kunden, Partnern und Aufsichtsbehörden.

    Unternehmen, die jetzt handeln, verschaffen sich einen doppelten Vorteil: Sie erfüllen kommende regulatorische Anforderungen frühzeitig und bauen intern die Kompetenz auf, KI verantwortungsvoll und sicher einzusetzen.

     

    Was KI-Risikomanagement im Unternehmenskontext bedeutet

    KI-Risikomanagement (englisch: AI Risk Management) beschreibt den systematischen Prozess, mit dem Unternehmen Risiken identifizieren, bewerten, steuern und überwachen, die durch den Einsatz von KI-Systemen entstehen. Es umfasst technische, organisatorische, rechtliche und ethische Dimensionen.

    Im Unterschied zum klassischen IT-Risikomanagement berücksichtigt das Risikomanagement für KI-Systeme spezifische Eigenschaften künstlicher Intelligenz:

    • Probabilistisches Verhalten: KI-Systeme treffen Entscheidungen auf Basis statistischer Modelle – ihre Ergebnisse sind nicht immer deterministisch oder vollständig vorhersagbar.
    • Datenabhängigkeit: Die Qualität und Repräsentativität der Trainingsdaten beeinflusst direkt die Fairness und Zuverlässigkeit des Systems.
    • Dynamische Entwicklung: KI-Modelle können sich durch kontinuierliches Lernen verändern, was laufende Überwachung erfordert.
    • Erklärbarkeit: Viele KI-Systeme – insbesondere Deep-Learning-Modelle – arbeiten als sogenannte Black Boxes, deren Entscheidungslogik schwer nachvollziehbar ist.

    Ein wirksames AI Risk Management integriert diese Besonderheiten in bestehende Governance-Strukturen, anstatt ein vollständig neues System aufzubauen.

     

    Typische Risikokategorien für KI-Systeme

    Um KI-Risiken strukturiert zu erfassen, empfiehlt sich die Gliederung in klar definierte Kategorien. Die folgenden fünf Bereiche decken die wesentlichen KI-Risiken ab, die Unternehmen adressieren müssen.

     

    1. Bias und Diskriminierung

    KI-Systeme können bestehende gesellschaftliche Vorurteile reproduzieren oder verstärken, wenn ihre Trainingsdaten verzerrt sind. Das betrifft insbesondere Anwendungen im Personalwesen, bei der Kreditvergabe oder im Kundenservice. Ein diskriminierendes KI-System kann erhebliche rechtliche und reputationsbezogene Konsequenzen haben – und verstößt potenziell gegen das Allgemeine Gleichbehandlungsgesetz (AGG) sowie die DSGVO.

    Maßnahmen: Regelmäßige Bias-Audits, diverse Trainingsdatensätze, Fairness-Metriken definieren und überwachen.

     

    2. Mangelnde Transparenz und Erklärbarkeit

    Wenn Entscheidungen von KI-Systemen nicht nachvollziehbar sind, wird es für Unternehmen schwierig, diese gegenüber Betroffenen, Aufsichtsbehörden oder Gerichten zu rechtfertigen. Der EU AI Act fordert für Hochrisiko-KI-Systeme explizit Transparenz und eine verständliche Dokumentation.

    Maßnahmen: Einsatz erklärbarer KI-Methoden (Explainable AI), technische Dokumentation gemäß Artikel 11 EU AI Act, Gebrauchsanweisungen für Betreiber.

     

    3. Datenschutz und Datenqualität

    KI-Systeme verarbeiten häufig große Mengen personenbezogener Daten. Dabei entstehen Risiken in Bezug auf die DSGVO-Compliance: unzureichende Rechtsgrundlagen, fehlende Datenschutz-Folgenabschätzungen oder mangelnde Datenminimierung. Zudem kann schlechte Datenqualität zu fehlerhaften Ergebnissen führen.

    Maßnahmen: Datenschutz-Folgenabschätzung (DSFA) durchführen, Daten-Governance-Richtlinien etablieren, technische und organisatorische Maßnahmen (TOM) implementieren.

     

    4. IT-Sicherheit und Robustheit

    KI-Systeme sind anfällig für spezifische Angriffsformen wie Adversarial Attacks (gezielte Manipulation von Eingabedaten), Model Poisoning (Vergiftung von Trainingsdaten) oder Model Extraction (Abschöpfung des Modellwissens). Diese Bedrohungen gehen über klassische IT-Sicherheitsrisiken hinaus und erfordern spezialisierte Schutzmaßnahmen.

    Maßnahmen: KI-spezifische Bedrohungsmodellierung, Adversarial Testing, Monitoring der Modell-Performance, Integration in das ISMS nach ISO 27001.

     

    5. Haftung und rechtliche Risiken

    Die Frage, wer haftet, wenn ein KI-System Schaden verursacht, ist rechtlich komplex. Die europäische KI-Haftungsrichtlinie und die neue Produkthaftungsrichtlinie schaffen zwar klarere Regeln, doch Unternehmen müssen ihre Haftungsrisiken proaktiv bewerten. Fehlende Dokumentation oder unzureichende menschliche Aufsicht können die Haftungssituation erheblich verschärfen.

    Maßnahmen: Haftungsszenarien dokumentieren, Verantwortlichkeiten klar definieren, Protokollierung und Auditierbarkeit sicherstellen, vertragliche Regelungen mit KI-Anbietern prüfen.

     

    Rollen und Verantwortlichkeiten im KI-Risikomanagement

    Ein funktionierendes AI Risk Management erfordert klare Zuständigkeiten. Ohne definierte Rollen verteilt sich die Verantwortung, und Risiken fallen durch die Lücken. Die folgende Rollenverteilung hat sich in der Praxis bewährt:

    • Geschäftsführung / Vorstand: Trägt die Gesamtverantwortung für das KI-Risikomanagement, gibt die Risikobereitschaft (Risk Appetite) vor und stellt Ressourcen bereit.
    • KI-Verantwortlicher / AI Officer: Koordiniert die KI-Governance im Unternehmen, pflegt das KI-Inventar und stellt die Einhaltung regulatorischer Anforderungen sicher. In kleineren Unternehmen kann diese Rolle vom CISO oder Compliance-Beauftragten übernommen werden.
    • Fachabteilungen: Identifizieren KI-Anwendungsfälle, bewerten fachliche Risiken und stellen die korrekte Nutzung gemäß interner Richtlinien sicher.
    • IT-Sicherheit / CISO: Bewertet technische Risiken, integriert KI-spezifische Bedrohungen in das bestehende Risikomanagement und überwacht die KI-Sicherheit.
    • Datenschutzbeauftragter: Prüft die DSGVO-Konformität von KI-Systemen, begleitet Datenschutz-Folgenabschätzungen und berät zu Fragen der Datenverarbeitung.
    • Rechtsabteilung: Bewertet Haftungsrisiken, prüft Verträge mit KI-Anbietern und überwacht regulatorische Entwicklungen.

    Entscheidend ist, dass diese Rollen nicht nur formal definiert, sondern mit konkreten Aufgaben, Berichtswegen und Eskalationsmechanismen hinterlegt sind.

     

    Minimaler Governance-Prozess für KI-Risikomanagement

    Nicht jedes Unternehmen benötigt von Anfang an ein umfassendes KI-Governance-Framework. Ein minimaler Governance-Prozess bildet die Grundlage, auf der sich das Risikomanagement für künstliche Intelligenz schrittweise erweitern lässt.

     

    Schritt 1: KI-Systeme inventarisieren

    Erstellen Sie ein vollständiges Verzeichnis aller KI-Systeme, die Ihr Unternehmen einsetzt, entwickelt oder bereitstellt. Erfassen Sie dabei mindestens:

    • Name und Beschreibung des Systems
    • Einsatzbereich und Zweck
    • Anbieter (intern oder extern)
    • Verarbeitete Datenarten (insbesondere personenbezogene Daten)
    • Betroffene Personengruppen
    • Vorläufige Risikoeinstufung gemäß EU AI Act Risikostufen

     

    Schritt 2: Risikobewertung durchführen

    Bewerten Sie für jedes KI-System die identifizierten Risiken nach Eintrittswahrscheinlichkeit und potenzieller Schadenshöhe. Nutzen Sie dabei die fünf Risikokategorien (Bias, Transparenz, Datenschutz, Sicherheit, Haftung) als Strukturierungshilfe. Dokumentieren Sie die Ergebnisse in einer KI-Risikomatrix.

     

    Schritt 3: Maßnahmen definieren und priorisieren

    Leiten Sie aus der Risikobewertung konkrete Maßnahmen ab. Priorisieren Sie dabei nach Risikohöhe und Umsetzbarkeit. Typische Maßnahmen umfassen:

    • Technische Schutzmaßnahmen (z. B. Monitoring, Zugriffskontrollen)
    • Organisatorische Maßnahmen (z. B. Schulungen, Richtlinien)
    • Prozessuale Maßnahmen (z. B. Freigabeprozesse, regelmäßige Audits)
    • Vertragliche Maßnahmen (z. B. Anforderungen an KI-Anbieter)

     

    Schritt 4: Überwachen und iterieren

    KI-Risikomanagement ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess. Etablieren Sie einen regelmäßigen Review-Zyklus – mindestens halbjährlich – um Risikobewertungen zu aktualisieren, die Wirksamkeit von Maßnahmen zu prüfen und neue KI-Systeme in den Prozess aufzunehmen.

     

    Integration in bestehende Compliance-Strukturen

    Unternehmen, die bereits über ein Informationssicherheits-Managementsystem (ISMS) oder ein DSGVO-Compliance-Programm verfügen, müssen das Rad nicht neu erfinden. KI-Risikomanagement lässt sich effizient in bestehende Strukturen integrieren.

     

    Anbindung an das ISMS nach ISO 27001

    Ein ISMS nach ISO 27001 bietet den idealen Rahmen für die Integration von KI-Risiken:

    • Asset-Management: KI-Systeme als Informationswerte im Asset-Inventar erfassen.
    • Risikobeurteilung (Klausel 6.1.2): KI-spezifische Bedrohungen und Schwachstellen in die bestehende Risikobeurteilung aufnehmen.
    • Risikobehandlung: KI-Maßnahmen in den Risikobehandlungsplan integrieren.
    • Annex A Controls: Relevante Controls (z. B. A.8.28 Secure Coding, A.5.8 Informationssicherheit im Projektmanagement) auf KI-Kontexte anwenden.
    • Interne Audits: KI-Systeme in den internen Audit-Plan aufnehmen.

     

    Verbindung zur DSGVO-Compliance

    KI-Risikomanagement und Datenschutz-Compliance überlappen in wesentlichen Bereichen:

    • Datenschutz-Folgenabschätzung (DSFA): Für KI-Systeme mit hohem Risiko für Betroffene ist eine DSFA gemäß Art. 35 DSGVO ohnehin verpflichtend – die Ergebnisse fließen direkt in das KI-Risikomanagement ein.
    • Verarbeitungsverzeichnis: KI-gestützte Verarbeitungstätigkeiten müssen im Verarbeitungsverzeichnis dokumentiert sein.
    • Automatisierte Einzelentscheidungen: Art. 22 DSGVO gibt Betroffenen das Recht, nicht einer ausschließlich automatisierten Entscheidung unterworfen zu werden – ein zentraler Aspekt der AI Compliance.
    • Technische und organisatorische Maßnahmen: Die TOM-Anforderungen der DSGVO lassen sich auf KI-spezifische Risiken erweitern.

     

    Bezug zum EU AI Act

    Der EU AI Act fordert für Hochrisiko-KI-Systeme explizit ein Risikomanagementsystem (Art. 9), das den gesamten Lebenszyklus abdeckt. Unternehmen, die ihr KI-Risikomanagement jetzt auf Basis bewährter Standards aufbauen, erfüllen wesentliche Anforderungen des AI Act bereits vorab. Die Verordnung verlangt unter anderem:

    • Identifikation und Analyse bekannter und vorhersehbarer Risiken
    • Bewertung von Risiken, die bei bestimmungsgemäßer Nutzung und bei vernünftigerweise vorhersehbarer Fehlanwendung auftreten können
    • Geeignete Risikomanagementmaßnahmen unter Berücksichtigung des Stands der Technik
    • Systematisches Testen des KI-Systems zur Bestimmung der geeignetsten Maßnahmen

     

    Häufig gestellte Fragen (FAQ)

     

    Was ist KI-Risikomanagement?

    KI-Risikomanagement ist der systematische Prozess, mit dem Unternehmen Risiken identifizieren, bewerten und steuern, die durch den Einsatz künstlicher Intelligenz entstehen. Es umfasst technische Risiken (z. B. Bias, mangelnde Robustheit), rechtliche Risiken (z. B. Datenschutzverstöße, Haftung) und organisatorische Risiken (z. B. fehlende Kompetenzen, unklare Verantwortlichkeiten). Ziel ist es, den Nutzen von KI-Systemen zu maximieren und gleichzeitig potenzielle Schäden für das Unternehmen und betroffene Personen zu minimieren.

     

    Welche Risiken entstehen durch KI-Systeme?

    KI-Systeme können vielfältige Risiken verursachen. Dazu gehören algorithmische Diskriminierung (Bias), die zu unfairen Entscheidungen führt, Datenschutzverletzungen durch die Verarbeitung sensibler Daten, Sicherheitslücken durch KI-spezifische Angriffsvektoren wie Adversarial Attacks, mangelnde Transparenz bei automatisierten Entscheidungen sowie Haftungsrisiken bei fehlerhaften KI-Ergebnissen. Hinzu kommen Risiken durch Abhängigkeit von einzelnen Anbietern (Vendor Lock-in), unzureichende Datenqualität und die unkontrollierte Nutzung von KI-Tools durch Mitarbeitende (Shadow AI).

     

    Wie passt KI-Risikomanagement zum EU AI Act?

    Der EU AI Act verlangt in Artikel 9 von Anbietern und Betreibern von Hochrisiko-KI-Systemen die Einführung eines Risikomanagementsystems, das den gesamten Lebenszyklus des KI-Systems abdeckt. Unternehmen, die ein strukturiertes KI-Risikomanagement aufbauen, legen damit die Grundlage für die Compliance mit dem EU AI Act. Die Anforderungen des AI Act lassen sich dabei nahtlos in bestehende Managementsysteme wie ein ISMS nach ISO 27001 integrieren. Die vollständigen Pflichten für eigenständige Hochrisiko-KI-Systeme (Anhang III) treten nach der Verschiebung durch den EU Digital Omnibus ab Dezember 2027 in Kraft (für in Produkte eingebettete Hochrisiko-KI nach Anhang I ab August 2028).

     

    Welche Maßnahmen sind für Unternehmen sofort umsetzbar?

    Unternehmen können bereits heute konkrete Schritte unternehmen, um sich auf die Anforderungen des EU AI Act vorzubereiten und KI-Risiken zu minimieren:

    • KI-Inventar erstellen: Alle im Unternehmen eingesetzten KI-Systeme systematisch erfassen und dokumentieren.
    • Risikoeinstufung vornehmen: Jedes KI-System anhand der EU AI Act Risikostufen vorläufig klassifizieren.
    • Verantwortlichkeiten festlegen: Einen KI-Verantwortlichen benennen und Zuständigkeiten definieren.
    • KI-Richtlinie verabschieden: Interne Regeln für den Einsatz von KI-Systemen formulieren.
    • Mitarbeitende schulen: KI-Kompetenz aufbauen – der EU AI Act fordert dies in Artikel 4 bereits seit Februar 2025.
    • Bestehende Prozesse nutzen: KI-Risiken in vorhandene ISMS- oder DSGVO-Prozesse integrieren.

     

    KI-Risikomanagement als Wettbewerbsvorteil

    Unternehmen, die KI-Risikomanagement als rein regulatorische Pflicht betrachten, verschenken Potenzial. Ein strukturierter Umgang mit KI-Risiken schafft Vertrauen – bei Kunden, Geschäftspartnern und Aufsichtsbehörden. Er ermöglicht es, KI-Systeme schneller und sicherer in Betrieb zu nehmen, weil Risiken frühzeitig erkannt und adressiert werden. Und er verhindert kostspielige Nachbesserungen, wenn sich regulatorische Anforderungen verschärfen.

    Der Schlüssel liegt darin, AI Governance nicht als separate Disziplin aufzubauen, sondern in bestehende Compliance- und Sicherheitsstrukturen zu integrieren. Wer bereits ein ISMS betreibt, hat die organisatorischen Grundlagen dafür geschaffen. Eine ISMS-Software wie TrustSpaceOS bündelt KI-Inventar, Risikobewertung und Nachweisführung in einer Plattform und macht diese Integration im Arbeitsalltag handhabbar.

     

    KI-Risikomanagement mit TrustSpace integrieren

    TrustSpace unterstützt Unternehmen dabei, KI-Risikomanagement nahtlos in bestehende ISMS- und Compliance-Strukturen zu integrieren. Mit der TrustSpace-Plattform erfassen Sie KI-Systeme systematisch, bewerten Risiken nach bewährten Standards und dokumentieren Maßnahmen revisionssicher – alles in einer zentralen Lösung. So erfüllen Sie die Anforderungen des EU AI Act, ohne parallele Strukturen aufbauen zu müssen.

    Jetzt unverbindlich beraten lassen →

  • Risikobewertung nach ISO 27001 in der Praxis

    Risikobewertung nach ISO 27001 in der Praxis

    Das Wichtigste in Kürze

    • Die Risikobewertung nach ISO 27001 bildet das Herzstück eines funktionierenden ISMS (Information Security Management System).
    • Der Prozess basiert auf einer klaren Bewertung von Eintrittswahrscheinlichkeit und Auswirkung (Schadenspotenzial).
    • Die Definition einer nachvollziehbaren Risikomatrix hilft bei der objektiven Priorisierung der Risikobehandlung.
    • Ohne pragmatische Methodik verstricken sich viele Unternehmen im Detailgrad – der Fokus sollte auf geschäftskritischen Assets liegen.

    Der Aufbau eines ISO 27001-konformen Informationssicherheits-Managementsystems (ISMS) beginnt und endet mit der richtigen Einschätzung von Risiken. Die Risikobewertung zeigt auf, wo Ihre sensibelsten Werte (Assets) liegen und welche Bedrohungen die größten Schäden anrichten könnten. Doch wie übersetzen Sie die abstrakten Normvorgaben in einen handhabbaren Prozess für den Mittelstand, ohne sich in endlosen Excel-Tabellen zu verlieren?

    In diesem Leitfaden erklären wir Ihnen eine klare Schritt-für-Schritt-Methode für die ISO 27001 Risikoanalyse, zeigen die zugrunde liegende Bewertungslogik und geben Ihnen eine beispielhafte Risikomatrix an die Hand. Warum die Risikoanalyse das Fundament jedes ISMS bildet, erläutert unser Grundlagenbeitrag.

     

    Schritt-für-Schritt-Methode für die Risikobewertung

    Die ISO 27001 schreibt keinen starren, detaillierten Bewertungsprozess vor, verlangt aber eine reproduzierbare und nachvollziehbare Methodik. Ein praxiserprobter Ablauf gliedert sich in folgende Phasen:

    1. Identifikation der Informationswerte (Assets): Erfassen Sie geschäftskritische Systeme, Daten, Hardware, aber auch Lieferanten und Schlüsselpersonal. Nicht jedes Laptop muss einzeln bewertet werden – fassen Sie gleichartige Assets in Clustern zusammen. Wie diese Bestandsaufnahme methodisch sauber gelingt, zeigt die ISMS-Strukturanalyse.
    2. Identifikation von Bedrohungen und Schwachstellen: Welche Gefahren (z. B. Ransomware, Phishing, Hardwareausfall, menschliches Versagen) drohen den identifizierten Assets und durch welche internen Schwachstellen (z. B. fehlende Multi-Faktor-Authentifizierung) könnten diese ausgenutzt werden?
    3. Risikoanalyse und Risikobewertung: Ordnen Sie jedem Risiko einen konkreten Wert zu, basierend auf der Eintrittswahrscheinlichkeit und der Auswirkung (siehe Bewertungslogik).
    4. Priorisierung und Risikobehandlung: Entscheiden Sie anhand der festgelegten Risikotoleranz des Unternehmens, welche Risiken gemindert, vermieden, transferiert oder akzeptiert werden.

     

    Die Bewertungslogik: Eintrittswahrscheinlichkeit und Auswirkung

    Die objektive Einschätzung eines IT-Risikos erfolgt klassischerweise über die Multiplikation oder Matrix-Addition von zwei Dimensionen:

    • Eintrittswahrscheinlichkeit: Wie realistisch ist es, dass eine Bedrohung eintritt und eine Schwachstelle ausnutzt? (z. B. auf einer Skala von 1 bis 5, von “sehr unwahrscheinlich” bis “sehr wahrscheinlich”).
    • Auswirkung (Schadenspotenzial): Welcher Schaden entsteht, wenn das Risiko Realität wird? Hierbei werden die Grundwerte der Informationssicherheit betrachtet: Vertraulichkeit, Integrität und Verfügbarkeit (CIA-Triade). (Skala von 1 bis 5, von “vernachlässigbar” bis “existenzbedrohend”).

    Der daraus resultierende Risikowert bestimmt, ob ein Risiko tolerierbar ist oder sofortigen Handlungsbedarf auslöst.

     

    TrustSpace Profi-Tipp:

    Beziehen Sie bei der Bestimmung der Auswirkung nicht nur direkte finanzielle Schäden ein. Reputationsverluste, regulatorische Bußgelder (z. B. DSGVO oder NIS2) sowie der Vertrauensverlust bei Kunden können weitaus gravierendere Folgen für die Geschäftsführung und den Unternehmensfortbestand haben.

     

    Beispielhafte Risikomatrix (5×5)

    Eine 5×5 Risikomatrix ist der Standard in der Praxis, da sie genug Granularität bietet, um Risiken sauber zu trennen, ohne unnötig komplex zu sein. Der Risikowert ergibt sich hier aus der Multiplikation: Wahrscheinlichkeit x Auswirkung = Risiko.

    Auswirkung Wahrscheinlichkeit 1 – Sehr gering 2 – Gering 3 – Mittel 4 – Hoch 5 – Sehr hoch
    5 – Existenziell 5 (Mittel) 10 (Hoch) 15 (Kritisch) 20 (Kritisch) 25 (Kritisch)
    4 – Gravierend 4 (Gering) 8 (Mittel) 12 (Hoch) 16 (Kritisch) 20 (Kritisch)
    3 – Spürbar 3 (Gering) 6 (Mittel) 9 (Mittel) 12 (Hoch) 15 (Kritisch)
    2 – Geringfügig 2 (Gering) 4 (Gering) 6 (Mittel) 8 (Mittel) 10 (Hoch)
    1 – Vernachlässigbar 1 (Gering) 2 (Gering) 3 (Gering) 4 (Gering) 5 (Mittel)

    Ableitung der Maßnahmen:

    • 1-4 (Gering): Risikobereitschaft hoch, Risiko wird meist dokumentiert und akzeptiert.
    • 5-9 (Mittel): Risikobehandlung ist im normalen Betriebsablauf einzuplanen.
    • 10-12 (Hoch): Zeitnahe Implementierung von Maßnahmen (Controls) erforderlich.
    • 15-25 (Kritisch): Akuter Handlungsbedarf durch die Geschäftsführung, sofortige Risikominimierung zwingend.

     

    Häufige Fehler und wie man sie vermeidet

    Bei der Einführung einer ISO 27001-konformen Risikobewertung laufen KMU und IT-Leiter häufig in typische Fallen:

    • Analyse-Paralyse (Over-Engineering): Der Versuch, jedes noch so kleine Asset einzeln zu bewerten. Lösung: Clustern Sie Assets (z.B. “Alle Windows-Laptops der Mitarbeiter” statt 50 Einzelgeräte) und bewerten Sie das Cluster als Ganzes.
    • Fehlende Einbindung des Managements: IT-Abteilungen bewerten Risiken oft rein technisch. Die wahre geschäftliche Auswirkung (Business Impact) kann jedoch nur das Management beurteilen. Lösung: Nutzen Sie Workshops, um die Geschäftsführung in die Festlegung der Risikotoleranz zu integrieren.
    • Statische Listen (Excel-Chaos): Risikomanagement ist ein fortlaufender Prozess. Statische Excel-Tabellen veralten extrem schnell und erzeugen hohen Dokumentationsaufwand für das Audit. Lösung: Nutzen Sie spezialisierte Plattformen zur Dokumentenlenkung und Risikoverwaltung; welche Vorteile eine ISMS-Software gegenüber statischen Listen bietet, haben wir im Detail aufgeschlüsselt.

     

    TrustSpace Profi-Tipp:

    Eine reine Risikobewertung bringt keine Sicherheit – erst die Risikobehandlung schützt Ihr Unternehmen. Ordnen Sie jedem nicht-akzeptierten Risiko eine klare Maßnahme aus dem Anhang A der ISO 27001 zu und vergeben Sie verbindliche Verantwortlichkeiten und Deadlines.

     

    Fazit und nächste Schritte zur Umsetzung

    Die Risikobewertung nach ISO 27001 muss nicht kompliziert sein, wenn Sie einer klaren Methode folgen und sich auf die wirklich wesentlichen Werte Ihres Unternehmens konzentrieren. Ein strukturiertes Vorgehen schützt vor Audit-Fehlern, entlastet Ihr IT-Team und gibt der Geschäftsführung die nötige Rechtssicherheit für Compliance-Anforderungen. Wie die dokumentierte Risikobewertung später im internen und externen ISMS-Audit geprüft wird, zeigt unser Überblick zum Auditprozess.

    Um den Spagat zwischen hohem administrativem Aufwand und effektiver Sicherheit zu meistern, empfiehlt sich der Einsatz von spezialisierter Software und Expertenwissen. Wenn Sie den Weg zur Zertifizierung abkürzen und den Dokumentationsaufwand massiv reduzieren wollen, werfen Sie einen Blick auf unsere ISO 27001 Beratung und entdecken Sie, wie TrustSpaceOS Ihre IT-Compliance als zentrale Steuereinheit automatisiert.

     

  • Wie lange dauert TISAX wirklich? Realistischer Zeitplan für Unternehmen

    Wie lange dauert TISAX wirklich? Realistischer Zeitplan für Unternehmen

    Das Wichtigste in Kürze

    • Die TISAX Dauer von der ersten Entscheidung bis zum fertigen Label beträgt typischerweise 4 bis 12 Monate – abhängig vom Reifegrad, der Unternehmensgröße und dem Assessment Level.
    • Die längste Phase ist die Umsetzung der Maßnahmen. Unternehmen mit bestehendem ISMS (z. B. nach ISO 27001) können den Zeitrahmen erheblich verkürzen.
    • Häufige Verzögerungen entstehen durch fehlende Management-Unterstützung, unklare Scope-Definition und unterschätzte Dokumentationsanforderungen.
    • Die Registrierung bei der ENX Association und die Verfügbarkeit geeigneter Prüfdienstleister können zusätzliche Wartezeiten verursachen.
    • TrustSpace unterstützt Unternehmen dabei, den TISAX-Zeitplan effizient zu gestalten und typische Verzögerungsfaktoren zu vermeiden.

     

    Warum Dauer und Ablauf bei TISAX entscheidend sind

    Die Frage „Wie lange dauert TISAX?“ ist für die meisten Unternehmen eine der ersten – und eine der wichtigsten. Denn der TISAX-Prozess hat direkte Auswirkungen auf Geschäftsbeziehungen, Projektplanungen und Ressourcen.

    Wenn ein OEM oder Tier-1-Zulieferer ein TISAX-Label fordert, steht dahinter in der Regel ein konkreter Zeitdruck: Ein neuer Auftrag, eine Lieferantenqualifizierung oder eine vertragliche Frist. Wer den Zeitbedarf unterschätzt, riskiert Verzögerungen – im schlimmsten Fall den Verlust des Auftrags.

    Ein realistischer TISAX Zeitplan hilft, Erwartungen zu steuern, Ressourcen richtig zu planen und den Prozess effizient zu gestalten. Wie viel Vorlauf nötig ist, hängt dabei maßgeblich vom geforderten Prüfniveau ab: Ein Vor-Ort-Audit nach den Anforderungen für Assessment Level 3 bindet spürbar mehr Ressourcen als eine Remote-Prüfung.

     

    Typischer TISAX Zeitplan in Phasen

    Der TISAX-Prozess lässt sich in fünf klar abgrenzbare Phasen unterteilen. Die folgenden Zeitangaben basieren auf Erfahrungswerten für mittelständische Unternehmen mit 50 bis 500 Mitarbeitern:

    Phase 1: Initialisierung und Scope-Definition (2–4 Wochen)

    • Festlegung des Geltungsbereichs (Scope): Standorte, Systeme, Informationsflüsse
    • Bestimmung des benötigten Assessment Levels und der Prüfziele
    • Sicherung der Management-Unterstützung und Budgetfreigabe
    • Benennung eines Projektleiters und – falls noch nicht vorhanden – eines ISB

    Phase 2: Gap-Analyse und Maßnahmenplanung (4–6 Wochen)

    • Systematischer Abgleich des Ist-Zustands mit dem VDA ISA Katalog
    • Identifikation aller Lücken (Gaps) und Bewertung des Handlungsbedarfs
    • Priorisierung der Maßnahmen nach Aufwand und Kritikalität
    • Erstellung eines detaillierten Projektplans mit Meilensteinen

    Phase 3: Maßnahmenumsetzung (8–24 Wochen)

    Diese Phase ist typischerweise die längste und aufwändigste. Der tatsächliche Zeitbedarf hängt stark vom Ausgangszustand ab:

    • Erstellung und Verabschiedung fehlender Richtlinien und Prozesse
    • Implementierung technischer Maßnahmen (z. B. Verschlüsselung, Zugriffssteuerung, Netzwerksegmentierung)
    • Aufbau der erforderlichen Dokumentation und Nachweise
    • Schulung und Sensibilisierung aller relevanten Mitarbeiter
    • Anpassung von Lieferantenverträgen und Durchführung von Lieferantenbewertungen

    Phase 4: Internes Audit und Assessment-Vorbereitung (4–8 Wochen)

    • Durchführung eines internen Audits (Pre-Assessment) zur Prüfungsbereitschaft
    • Behebung identifizierter Schwachstellen
    • Registrierung bei der ENX Association (Wartezeit: typischerweise 1–2 Wochen)
    • Auswahl und Beauftragung eines zugelassenen TISAX-Prüfdienstleisters
    • Terminfindung (Wartezeit beim Prüfdienstleister: 2–6 Wochen)

    Phase 5: Externes Assessment und Abschluss (2–6 Wochen)

    • Durchführung des externen Assessments (Level 2: remote, Level 3: vor Ort)
    • Auswertung und Erhalt des Assessment-Berichts
    • Bearbeitung eventueller Feststellungen (Corrective Actions, Frist: meist 9 Monate)
    • Freigabe des TISAX-Labels auf der ENX-Plattform

     

    TISAX Dauer nach Ausgangslage

    Die Gesamtdauer variiert erheblich in Abhängigkeit von der Ausgangslage des Unternehmens:

    Unternehmen mit bestehendem ISMS (z. B. ISO 27001)

    Typische Dauer: 3–5 Monate

    Wer bereits ein ISMS nach ISO 27001 betreibt, hat die meisten Anforderungen bereits umgesetzt. Die Zusatzaufwände beschränken sich auf automobilspezifische Anforderungen (insbesondere Prototypenschutz) und die TISAX-spezifische Registrierung und Assessment-Durchführung.

    Unternehmen mit grundlegenden IT-Sicherheitsmaßnahmen

    Typische Dauer: 6–9 Monate

    Wenn grundlegende Sicherheitsmaßnahmen vorhanden sind (Firewall, Passwortrichtlinien, grundlegendes Backup), aber kein systematisches ISMS, liegt der Hauptaufwand in der Prozessdefinition, Dokumentation und Schulung.

    Unternehmen ohne etablierte Informationssicherheit

    Typische Dauer: 9–12+ Monate

    Wenn Informationssicherheit bisher nicht systematisch adressiert wurde, müssen Prozesse, Dokumentation und technische Maßnahmen weitgehend von Grund auf aufgebaut werden. Eine externe TISAX-Beratung ist in diesem Fall dringend empfohlen.

     

    Einflussfaktoren auf die TISAX-Dauer

    Die folgenden Faktoren haben den größten Einfluss auf die Projektdauer:

    Unternehmensgröße und Komplexität

    Mehr Standorte, mehr Systeme und mehr Mitarbeiter bedeuten mehr Aufwand – sowohl in der Analyse als auch in der Umsetzung. Besonders Unternehmen mit mehreren Standorten oder komplexen IT-Landschaften benötigen mehr Zeit.

    Assessment Level

    Ein Level-3-Assessment erfordert eine umfassendere Vorbereitung und ein intensiveres Audit als Level 2. Die Anforderungen an die Nachweistiefe sind deutlich höher. Für den überwiegenden Teil der Zulieferer ist jedoch das Level-2-Assessment maßgeblich, das remote und mit spürbar geringerem Audit-Aufwand abläuft.

    Verfügbarkeit interner Ressourcen

    TISAX erfordert die aktive Mitarbeit von IT, Management, Personalwesen und ggf. Facility Management. Wenn diese Personen neben dem Tagesgeschäft nur begrenzt verfügbar sind, verzögert sich das Projekt.

    Externe Unterstützung

    Die Einbindung einer erfahrenen TISAX-Beratung kann den Prozess erheblich beschleunigen – durch strukturierte Vorgehensweise, Templates und Best Practices aus vergleichbaren Projekten.

    Verfügbarkeit der Prüfdienstleister

    Die Anzahl zugelassener TISAX-Prüfdienstleister ist begrenzt. Insbesondere in Stoßzeiten (Q4, Jahresanfang) können Wartezeiten von mehreren Wochen entstehen.

     

    Häufige Verzögerungen und wie man sie vermeidet

    1. Unterschätzte Dokumentationsanforderungen

    Problem: Viele Unternehmen unterschätzen den Aufwand für Richtlinien, Prozessbeschreibungen und Nachweise.

    Lösung: Frühzeitig eine Dokumentationsstruktur aufbauen und Templates nutzen. Plattformlösungen wie TrustSpace bieten vorgefertigte Dokumentenvorlagen.

    2. Fehlende Management-Unterstützung

    Problem: Ohne aktive Unterstützung der Geschäftsleitung fehlen Budgets, Weisungsbefugnisse und Priorisierung.

    Lösung: Die Geschäftsleitung von Anfang an einbinden und über Geschäftsrisiken aufklären (Auftragsverlust, Lieferkettenausschluss).

    3. Zu breiter oder unklarer Scope

    Problem: Ein zu weit gefasster Scope erhöht den Aufwand unnötig, ein zu enger Scope führt zu Nachfragen im Assessment.

    Lösung: Den Scope gemeinsam mit dem Auftraggeber präzise definieren und dokumentieren.

    4. Paralleler Betrieb und Projektarbeit

    Problem: Die TISAX-Verantwortlichen sind gleichzeitig im Tagesgeschäft gebunden.

    Lösung: Feste Zeitblöcke und realistische Meilensteine einplanen. Lieber den Zeitplan verlängern als die Qualität gefährden.

    5. Unterschätzte Lieferantenanforderungen

    Problem: Auch die eigenen Dienstleister müssen angemessene Sicherheitsmaßnahmen nachweisen. Das erfordert Kommunikation und Koordination.

    Lösung: Lieferanten frühzeitig einbinden und bei Bedarf durch das Vendor Risk Management systematisch steuern.

     

    Checkliste: Interne TISAX-Planung

    Die folgende Checkliste hilft bei der internen Planung des TISAX-Projekts:

    • Management-Commitment und Budgetfreigabe eingeholt
    • Projektleiter und ISB benannt
    • Scope (Standorte, Systeme, Informationsarten) definiert
    • Assessment Level und Prüfziele mit dem Auftraggeber abgestimmt
    • Gap-Analyse gegen VDA ISA durchgeführt
    • Maßnahmenplan mit Prioritäten und Verantwortlichkeiten erstellt
    • Zeitliche Meilensteine und Deadlines definiert
    • Externe Unterstützung (Beratung) bewertet und ggf. beauftragt
    • Registrierung bei ENX Association geplant
    • Prüfdienstleister identifiziert und frühzeitig kontaktiert
    • Internes Audit (Pre-Assessment) eingeplant
    • Kommunikationsplan für betroffene Mitarbeiter erstellt

     

    Häufig gestellte Fragen zur TISAX Dauer

    Wie lange dauert eine TISAX-Zertifizierung?

    Von der Entscheidung bis zum TISAX-Label vergehen typischerweise 4 bis 12 Monate. Bei bestehendem ISMS kann der Prozess deutlich kürzer sein.

    Welche Phasen hat der TISAX-Prozess?

    Der Prozess umfasst fünf Phasen: Initialisierung, Gap-Analyse, Maßnahmenumsetzung, internes Audit und externes Assessment.

    Welche Faktoren verlängern den Ablauf?

    Die häufigsten Verzögerungsfaktoren sind fehlende Management-Unterstützung, unterschätzte Dokumentationsanforderungen, unklare Scope-Definition und begrenzte interne Ressourcen.

    Was kostet TISAX je nach Ausgangslage?

    Die TISAX Kosten variieren erheblich: Die ENX-Registrierungsgebühr, die Prüfdienstleisterkosten und die internen Aufwände hängen von Unternehmensgröße, Assessment Level und Reifegrad ab. Eine pauschale Angabe ist nicht seriös möglich – eine individuelle Aufwandsschätzung auf Basis der Gap-Analyse ist der sinnvollste Weg.

     

    Fazit: Frühzeitig planen, realistisch kalkulieren

    Die TISAX Dauer ist beherrschbar – wenn der Prozess frühzeitig gestartet, realistisch geplant und konsequent umgesetzt wird. Der größte Fehler ist es, das Projekt zu unterschätzen oder erst unter Zeitdruck zu beginnen.

    Unternehmen, die den TISAX-Prozess effizient gestalten wollen, profitieren von einer strukturierten Projektsteuerung, einer ehrlichen Gap-Analyse und – bei Bedarf – externer Unterstützung. Am Ende steht das TISAX®-Label mit seiner dreijährigen Gültigkeit – ein Termin, den Unternehmen für die Rezertifizierung frühzeitig wieder einplanen sollten.

    TrustSpace bietet eine Plattformlösung für die TISAX-Vorbereitung, die den Zeitplan transparent macht, Maßnahmen trackt und den Fortschritt messbar hält. So wird aus einem komplexen Compliance-Projekt ein planbarer Prozess.

  • TISAX Assessment Level 2 einfach erklärt

    TISAX Assessment Level 2 einfach erklärt

    Das Wichtigste in Kürze

    • TISAX Assessment Level 2 ist eine Plausibilitätsprüfung, bei der ein zugelassener Prüfdienstleister die Selbstauskunft des Unternehmens auf Nachvollziehbarkeit und Konsistenz überprüft.
    • Die Prüfung erfolgt in der Regel remote – per Dokumentenprüfung und Interview, ohne vollständige Vor-Ort-Begehung.
    • Level 2 ist ausreichend, wenn der Auftraggeber einen normalen Schutzbedarf festlegt – etwa bei allgemeinen vertraulichen Informationen ohne Prototypenbezug.
    • Im Vergleich zu Level 3 ist der Prüfaufwand geringer, die inhaltlichen Anforderungen an das ISMS bleiben jedoch identisch.
    • TrustSpace unterstützt Unternehmen bei der gezielten Vorbereitung auf das TISAX Assessment Level 2 – von der Gap-Analyse bis zur Assessment-Begleitung.

     

    Was bedeutet TISAX Assessment Level 2?

    TISAX (Trusted Information Security Assessment Exchange) kennt drei Assessment Levels, die sich in der Prüftiefe und Prüfmethodik unterscheiden. Das TISAX Assessment Level 2 steht für eine sogenannte Plausibilitätsprüfung: Ein von der ENX Association zugelassener Prüfdienstleister überprüft die vom Unternehmen eingereichte Selbstauskunft auf Nachvollziehbarkeit, Vollständigkeit und Konsistenz.

    Konkret bedeutet das: Das Unternehmen füllt zunächst den VDA ISA Fragenkatalog im Rahmen einer Selbstbewertung aus und dokumentiert den Reifegrad seiner Informationssicherheitsprozesse. Der Prüfdienstleister analysiert anschließend diese Angaben, prüft eingereichte Nachweisdokumente und führt ergänzende Interviews mit den Verantwortlichen durch – in der Regel remote per Videokonferenz.

    Im Unterschied zu einer reinen Selbstauskunft (Level 1) findet beim TISAX Level 2 also eine externe Bewertung statt. Im Unterschied zum Level-3-Assessment erfolgt diese Bewertung jedoch ohne umfassende Vor-Ort-Prüfung und ohne die detaillierte Inspektion technischer Systeme vor Ort.

     

    Die drei TISAX Assessment Levels im Vergleich

    Um die Einordnung des TISAX Assessment Level 2 zu verstehen, ist ein Blick auf alle drei Levels hilfreich. Die TISAX Level Unterschiede betreffen ausschließlich die Prüfmethodik – nicht die inhaltlichen Anforderungen des VDA ISA Katalogs.

    Level 1: Selbstauskunft

    Bei Level 1 führt das Unternehmen eine reine Selbstbewertung ohne externe Prüfung durch. Es findet keine Verifizierung durch einen Prüfdienstleister statt. Level 1 erzeugt kein TISAX-Label und wird in der Praxis von OEMs und Tier-1-Zulieferern nicht als ausreichender Nachweis akzeptiert. Es dient lediglich der internen Standortbestimmung.

    Level 2: Plausibilitätsprüfung

    Das TISAX Level 2 Assessment umfasst eine externe Plausibilitätsprüfung. Der Prüfdienstleister verifiziert die Selbstauskunft durch Dokumentenprüfung und Interviews, typischerweise remote. Die TISAX Prüftiefe bei Level 2 ist so ausgelegt, dass der Prüfer die Plausibilität der Angaben beurteilen kann, ohne jede technische Maßnahme vor Ort zu inspizieren.

    Level 3: Vollständige Vor-Ort-Prüfung

    Level 3 ist die umfassendste Prüfform. Der Prüfdienstleister führt ein vollständiges Vor-Ort-Audit durch. Dabei werden Dokumente, Prozesse und technische Implementierungen im Detail begutachtet. Begehungen der Räumlichkeiten, Einsicht in Systeme und ausführliche Interviews mit verschiedenen Funktionsträgern sind Standard. Welche Nachweise dabei im Einzelnen erwartet werden, ist in den Level-3-Anforderungen ausführlich beschrieben.

     

    TISAX Level 2 vs. Level 3: Die wesentlichen Unterschiede

    Die Frage nach TISAX Level 2 vs. 3 ist eine der häufigsten im Kontext der TISAX-Vorbereitung. Die folgende Gegenüberstellung zeigt die zentralen Unterschiede:

    • Prüfmethodik: Level 2 basiert auf einer Remote-Plausibilitätsprüfung, Level 3 erfordert ein vollständiges Vor-Ort-Audit mit physischer Begehung.
    • Prüftiefe: Bei Level 2 prüft der Auditor, ob die Angaben im VDA ISA plausibel und nachvollziehbar sind. Bei Level 3 werden Prozesse und technische Maßnahmen vor Ort detailliert verifiziert.
    • Aufwand und Dauer: Das Level-2-Assessment ist in der Regel kürzer und kosteneffizienter. Level-3-Assessments erfordern mehr Audittage und eine aufwändigere Vorbereitung.
    • Nachweisführung: Bei Level 2 reichen in der Regel Dokumente und mündliche Erläuterungen. Bei Level 3 müssen Nachweise vor Ort vorgezeigt und technische Umsetzungen demonstriert werden.
    • Einsatzbereich: Level 2 wird bei normalem Schutzbedarf eingesetzt, Level 3 bei hohem oder sehr hohem Schutzbedarf sowie bei Prototypenschutz.

    Wichtig: Die inhaltlichen TISAX Anforderungen – also die Kontrollfragen des VDA ISA Katalogs – sind bei Level 2 und Level 3 identisch. Der Unterschied liegt ausschließlich in der Art und Tiefe, wie deren Umsetzung geprüft wird.

     

    Wann ist TISAX Assessment Level 2 ausreichend?

    Ob ein TISAX Assessment Level 2 ausreicht oder Level 3 gefordert wird, entscheidet nicht das Unternehmen selbst. Die Festlegung erfolgt durch den Auftraggeber – also den OEM oder Tier-1-Zulieferer, der den TISAX-Nachweis verlangt.

    Die Auswahl des Assessment Levels orientiert sich am Schutzbedarf der Informationen, die mit dem Zulieferer geteilt werden (eine Übersicht bieten die TISAX® Klassifizierungsstufen):

    Level 2 ist typischerweise ausreichend bei:

    • Verarbeitung von allgemein vertraulichen Geschäftsinformationen (z. B. Einkaufsdaten, Projektpläne, technische Spezifikationen ohne Prototypenbezug)
    • Normalem Schutzbedarf ohne Anforderungen an Prototypenschutz
    • Dienstleistern, die zwar Zugang zu vertraulichen Informationen haben, aber nicht mit hochsensiblen Entwicklungsdaten arbeiten
    • Szenarien, in denen das Prüfziel ausschließlich Informationssicherheit oder Datenschutz (ohne Prototypenschutz) umfasst

    Level 3 wird in der Regel gefordert bei:

    • Hohem oder sehr hohem Schutzbedarf
    • Zugang zu Prototypen (physisch oder virtuell) oder vorserienrelevanten Informationen
    • Prüfziel Prototypenschutz
    • Unternehmen, die tief in die Fahrzeugentwicklung eingebunden sind

    In der Praxis wird bei vielen Zulieferern und IT-Dienstleistern ein TISAX Level 2 Assessment angefordert, da der überwiegende Teil der Geschäftsbeziehungen keinen Prototypenbezug hat. Die genauen Anforderungen ergeben sich aus der Registrierung auf der ENX-Plattform, wo der Auftraggeber das gewünschte Assessment Level und die Prüfziele hinterlegt.

     

    Anforderungen und Prüftiefe bei TISAX Level 2

    Auch wenn die TISAX Prüftiefe bei Level 2 geringer ist als bei Level 3, sollten Unternehmen die Anforderungen nicht unterschätzen. Der Prüfdienstleister bewertet die Angaben kritisch und erwartet eine nachvollziehbare Darstellung der Informationssicherheitsprozesse.

    Was der Prüfer bei Level 2 konkret prüft

    • Vollständigkeit der Selbstauskunft: Alle relevanten Kontrollfragen des VDA ISA müssen beantwortet und mit einem Reifegrad bewertet sein.
    • Nachweisdokumente: Für zentrale Bereiche werden Dokumente angefordert – darunter die Informationssicherheitspolitik, Risikoanalysen, Richtlinien zur Zugangssteuerung, Notfallpläne und Schulungsnachweise.
    • Konsistenz der Angaben: Der Prüfer gleicht die Selbstbewertung mit den eingereichten Dokumenten und den Aussagen in den Interviews ab. Widersprüche führen zu Rückfragen oder Feststellungen.
    • Interviews mit Schlüsselpersonen: Typischerweise werden der Informationssicherheitsbeauftragte (ISB), IT-Verantwortliche und Vertreter der Geschäftsleitung befragt.
    • Reifegradnachweise: Jede Kontrollfrage muss mindestens Reifegrad 3 (Etabliert) erreichen. Das bedeutet: Der Prozess ist nicht nur dokumentiert, sondern wird standardmäßig und nachweislich gelebt.

    Typische Nachweisdokumente für Level 2

    Folgende Dokumente sollten Unternehmen für ein TISAX Assessment Level 2 vorbereitet haben:

    • Informationssicherheitspolitik und daraus abgeleitete Sicherheitsrichtlinien
    • Risikoanalyse mit dokumentiertem Risikobewertungsverfahren und Risikobehandlungsplan
    • Asset-Inventar mit Klassifizierung und Verantwortlichkeiten
    • Berechtigungskonzept und Nachweise über regelmäßige Access Reviews
    • Schulungsnachweise zur Informationssicherheit für Mitarbeiter
    • Dokumentation des Incident-Management-Prozesses
    • Business-Continuity-Plan und Notfallkonzept
    • Lieferantenbewertung und Vereinbarungen zur Informationssicherheit mit Dienstleistern
    • Nachweis über interne Audits und Managementbewertungen
    • Dokumentation des Change-Management-Prozesses und des Patch-Managements

     

    Ablauf eines TISAX Level 2 Assessments

    Der Ablauf eines TISAX Assessment Level 2 folgt einem strukturierten Prozess, der sich in mehrere Phasen gliedert:

    1. Registrierung bei der ENX Association

    Das Unternehmen registriert sich auf dem ENX-Portal und legt den Scope (Geltungsbereich), die Prüfziele und die betroffenen Standorte fest. Anschließend wird ein zugelassener Prüfdienstleister ausgewählt.

    2. Selbstbewertung anhand des VDA ISA

    Das Unternehmen füllt den VDA ISA Fragenkatalog aus, bewertet den Reifegrad der eigenen Prozesse und kompiliert die zugehörigen Nachweisdokumente. Diese Selbstbewertung wird dem Prüfdienstleister übergeben.

    3. Dokumentenprüfung durch den Prüfdienstleister

    Der Prüfer analysiert die eingereichte Selbstauskunft und die Nachweisdokumente. Er prüft auf Vollständigkeit, Konsistenz und Plausibilität der angegebenen Reifegrade.

    4. Remote-Interviews

    In Ergänzung zur Dokumentenprüfung führt der Prüfdienstleister Interviews mit relevanten Ansprechpartnern im Unternehmen durch. Dabei werden Rückfragen zu den Dokumenten geklärt und die tatsächliche Umsetzung der Prozesse erfragt.

    5. Bewertung und Ergebnisbericht

    Der Prüfer erstellt einen Ergebnisbericht mit der Bewertung aller Kontrollfragen. Werden Abweichungen (Non-Conformities) festgestellt, muss das Unternehmen innerhalb einer definierten Frist Korrekturmaßnahmen (Corrective Actions) einreichen und umsetzen.

    6. Erteilung des TISAX-Labels

    Nach erfolgreicher Prüfung – gegebenenfalls einschließlich der Nachbearbeitung von Feststellungen – wird das TISAX-Label erteilt. Es ist drei Jahre gültig und über die ENX-Plattform für berechtigte Partner einsehbar. Welche TISAX-Labels je nach Prüfziel vergeben werden, ergibt sich aus dem bei der Registrierung festgelegten Scope.

     

    Vorbereitung auf TISAX Assessment Level 2: Empfehlungen

    Eine strukturierte Vorbereitung ist der Schlüssel zu einem erfolgreichen TISAX Assessment. Die folgenden Empfehlungen helfen Unternehmen, den Aufwand realistisch zu planen und typische Fallstricke zu vermeiden:

    Frühzeitig beginnen

    Auch wenn der Aufwand bei Level 2 geringer ist als bei Level 3, sollten Unternehmen mindestens 3 bis 6 Monate für die Vorbereitung einplanen. Wer bisher kein strukturiertes ISMS betreibt, benötigt unter Umständen mehr Zeit für den Aufbau grundlegender Prozesse. Einen vollständigen Fahrplan dafür liefert unser Leitfaden zur Vorbereitung auf das TISAX®-Assessment.

    Gap-Analyse durchführen

    Bevor Maßnahmen umgesetzt werden, sollte eine systematische Gap-Analyse anhand des VDA ISA Katalogs durchgeführt werden. So wird transparent, in welchen Bereichen bereits ein ausreichender Reifegrad erreicht ist und wo Handlungsbedarf besteht.

    Dokumentation konsolidieren

    Beim Level-2-Assessment ist die Dokumentation der zentrale Prüfgegenstand. Alle Richtlinien, Prozessbeschreibungen und Nachweise sollten aktuell, konsistent und leicht zugänglich sein. Veraltete oder widersprüchliche Dokumente sind ein häufiger Grund für Feststellungen.

    Interviews vorbereiten

    Die Schlüsselpersonen – insbesondere der ISB, IT-Leiter und Geschäftsführung – sollten auf die Interviews vorbereitet sein. Sie müssen in der Lage sein, die dokumentierten Prozesse zu erläutern und mit Beispielen aus der Praxis zu belegen.

    Interne Vorprüfung durchführen

    Ein internes Pre-Assessment deckt Schwachstellen auf, bevor der externe Prüfer sie findet. Dabei wird die Selbstauskunft kritisch hinterfragt und die Dokumentation auf Lücken geprüft.

    Reifegrad realistisch bewerten

    Eine zu optimistische Selbstbewertung führt im Assessment zu Abweichungen. Unternehmen sollten ihre Reifegrade ehrlich und nachvollziehbar einschätzen. Es ist besser, einen niedrigeren Reifegrad anzugeben und einen Maßnahmenplan vorzulegen, als eine nicht belegbare Einschätzung abzugeben.

    ISMS-Tool nutzen

    Ein dediziertes ISMS-Tool erleichtert die Verwaltung von Richtlinien, Risiken, Maßnahmen und Nachweisen erheblich. Es schafft Transparenz über den Umsetzungsstand und beschleunigt die Zusammenstellung der Dokumentation für den Prüfer.

     

    Kosten und Zeitaufwand bei TISAX Level 2

    Die Kosten für ein TISAX Assessment Level 2 setzen sich aus mehreren Komponenten zusammen:

    • ENX-Registrierungsgebühr: Die Registrierung bei der ENX Association ist kostenpflichtig. Die Gebühr richtet sich nach Unternehmensgröße und Anzahl der Standorte.
    • Prüfdienstleister: Die Kosten für den Prüfdienstleister variieren je nach Scope und Komplexität. Bei Level 2 sind die Auditkosten typischerweise niedriger als bei Level 3, da weniger Audittage benötigt werden.
    • Interne Aufwände: Die Vorbereitung bindet interne Ressourcen – insbesondere den ISB, die IT-Abteilung und die Geschäftsleitung. Dieser Aufwand wird häufig unterschätzt.
    • Externe Beratung (optional): Viele Unternehmen nutzen externe TISAX Beratung, um die Vorbereitung zu beschleunigen und Fehler zu vermeiden.

    Der Zeitaufwand für das eigentliche Level-2-Assessment (Dokumentenprüfung und Interviews) beträgt in der Regel wenige Tage. Die Vorbereitung ist jedoch der zeitintensivere Teil und sollte, wie beschrieben, mit 3 bis 6 Monaten eingeplant werden.

     

    Häufig gestellte Fragen zu TISAX Assessment Level 2

    Was bedeutet Assessment Level 2 bei TISAX?

    TISAX Assessment Level 2 bezeichnet eine Plausibilitätsprüfung, bei der ein zugelassener Prüfdienstleister die Selbstauskunft eines Unternehmens anhand von Dokumenten und Interviews verifiziert. Die Prüfung erfolgt in der Regel remote und erzeugt bei Bestehen ein gültiges TISAX-Label.

    Wann reicht Level 2 aus?

    Level 2 ist ausreichend, wenn der Auftraggeber (OEM oder Tier 1) einen normalen Schutzbedarf festlegt. Das betrifft typischerweise Unternehmen, die mit allgemein vertraulichen Informationen arbeiten, aber keinen Zugang zu Prototypen oder hochsensiblen Entwicklungsdaten haben. Die Festlegung des Levels erfolgt durch den Auftraggeber bei der Scope-Definition.

    Was ist der Unterschied zwischen Level 2 und Level 3?

    Der Hauptunterschied liegt in der Prüfmethodik: Level 2 ist eine Remote-Plausibilitätsprüfung auf Basis von Dokumenten und Interviews. Level 3 ist eine vollständige Vor-Ort-Prüfung mit Begehung, Systeminspektion und umfassender Verifikation. Die inhaltlichen Anforderungen des VDA ISA sind bei beiden Levels identisch – nur die TISAX Prüftiefe unterscheidet sich.

    Welche Nachweise sind für Level 2 wichtig?

    Zentrale Nachweise sind die ausgefüllte Selbstauskunft (VDA ISA), die Informationssicherheitspolitik, Risikoanalysen, Richtlinien zu Zugangssteuerung und Kryptografie, Schulungsnachweise, Incident-Management-Dokumentation, Business-Continuity-Pläne und Nachweise über interne Audits. Die Dokumente müssen aktuell, konsistent und aussagekräftig sein.

    Wie lange ist ein TISAX-Label gültig?

    Ein TISAX-Label ist drei Jahre gültig. Nach Ablauf muss ein erneutes Assessment durchgeführt werden, um das Label zu verlängern. Es empfiehlt sich, die Rezertifizierung frühzeitig zu planen, um Lücken in der Gültigkeit zu vermeiden.

    Kann ich das Assessment Level selbst wählen?

    Nein. Das Assessment Level wird vom Auftraggeber festgelegt und orientiert sich am Schutzbedarf der Informationen, die mit dem Unternehmen geteilt werden. Das gewünschte Level wird bei der Registrierung auf der ENX-Plattform hinterlegt.

     

    Fazit: TISAX Assessment Level 2 effizient bestehen

    Das TISAX Assessment Level 2 ist für viele Unternehmen in der Automobilzulieferkette der relevante Prüfstandard. Es bietet einen ausgewogenen Kompromiss zwischen Prüftiefe und Aufwand und erzeugt ein vollwertiges TISAX-Label, das über die ENX-Plattform mit Geschäftspartnern geteilt werden kann.

    Der Schlüssel zum Erfolg liegt in einer strukturierten Vorbereitung: Eine ehrliche Gap-Analyse, eine konsolidierte Dokumentation und gut vorbereitete Ansprechpartner für die Interviews sind die wichtigsten Erfolgsfaktoren. Unternehmen, die bereits ein ISMS betreiben, haben einen erheblichen Vorsprung – die TISAX Anforderungen bauen auf etablierten Standards wie ISO 27001 auf.

    TrustSpace begleitet Unternehmen bei der gesamten TISAX-Vorbereitung – von der initialen Gap-Analyse über den Aufbau der erforderlichen Dokumentation bis zur Assessment-Begleitung. Mit der ISMS-Plattform von TrustSpace lassen sich alle Anforderungen zentral verwalten, Fortschritte nachverfolgen und Nachweise effizient zusammenstellen. So wird die TISAX Zertifizierung Level 2 planbar und ressourcenschonend.

  • TISAX Anforderungen verständlich erklärt

    TISAX Anforderungen verständlich erklärt

    Das Wichtigste in Kürze

    • TISAX (Trusted Information Security Assessment Exchange) ist der branchenspezifische Standard für Informationssicherheit in der Automobilindustrie, verwaltet von der ENX Association.
    • Grundlage aller TISAX Anforderungen ist der VDA ISA Katalog – ein Fragenkatalog, der auf ISO 27001 basiert und um branchenspezifische Module erweitert ist.
    • Die Anforderungen decken drei Prüfziele ab: Informationssicherheit, Prototypenschutz und Datenschutz.
    • Je nach Schutzbedarf des Auftraggebers müssen Unternehmen ein Assessment auf Level 2 oder Level 3 durchführen.
    • TrustSpace unterstützt Unternehmen bei der strukturierten Umsetzung der TISAX Anforderungen und der effizienten Vorbereitung auf das Assessment.

     

    Was ist TISAX und für wen ist es relevant?

    TISAX steht für „Trusted Information Security Assessment Exchange“ und ist ein Prüf- und Austauschverfahren für Informationssicherheit in der Automobilindustrie. Es wurde vom Verband der Automobilindustrie (VDA) initiiert und wird seit 2017 von der ENX Association betrieben.

    TISAX ist keine Zertifizierung im klassischen Sinne, sondern ein standardisiertes Assessment-Verfahren, dessen Ergebnis (Label) über die ENX-Plattform mit anderen Teilnehmern geteilt werden kann. Das vermeidet redundante Prüfungen durch verschiedene OEMs und Tier-1-Zulieferer. Welches TISAX®-Label ein Unternehmen am Ende erhält, hängt von den geprüften Prüfzielen und dem festgelegten Schutzbedarf ab.

    Wer braucht TISAX?

    TISAX ist relevant für alle Unternehmen, die in der automobilen Lieferkette tätig sind und von einem OEM oder Tier-1-Zulieferer aufgefordert werden, ihre Informationssicherheit nach TISAX nachzuweisen. Das betrifft:

    • Zulieferer aller Ebenen (Tier 1 bis Tier n)
    • Engineering-Dienstleister und Entwicklungspartner
    • IT-Dienstleister der Automobilindustrie
    • Logistik- und Servicepartner mit Zugang zu schützenswerten Informationen
    • Beratungsunternehmen, die mit vertraulichen Daten der OEMs arbeiten

    In der Praxis wird TISAX von den großen deutschen OEMs (Volkswagen, BMW, Mercedes-Benz, Porsche) und vielen internationalen Herstellern als Voraussetzung für die Geschäftsbeziehung verlangt.

     

    Der VDA ISA Katalog: Grundlage aller TISAX Anforderungen

    Die inhaltliche Basis für alle TISAX Anforderungen bildet der VDA ISA (Information Security Assessment) Katalog. Dieser Fragenkatalog definiert die Prüfkriterien, gegen die ein Unternehmen bewertet wird.

    Aufbau des VDA ISA

    Der VDA ISA gliedert sich in mehrere Module:

    • Informationssicherheit: Kernmodul, das auf ISO 27001 basiert und Themen wie Zugangssteuerung, Kryptografie, physische Sicherheit, Incident Management und Business Continuity abdeckt
    • Prototypenschutz: Zusatzmodul für Unternehmen, die mit physischen oder virtuellen Prototypen und vorserienrelevanten Informationen arbeiten
    • Datenschutz: Zusatzmodul, das die Einhaltung datenschutzrechtlicher Anforderungen (insbesondere DSGVO) im Rahmen der Auftragsverarbeitung prüft

    Bewertungssystematik: Reifegrade

    Jede Kontrollfrage im VDA ISA wird anhand eines Reifegradmodells bewertet:

    • Reifegrad 0: Unvollständig – kein Prozess vorhanden
    • Reifegrad 1: Durchgeführt – Prozess wird ad hoc durchgeführt, ist aber nicht dokumentiert
    • Reifegrad 2: Gesteuert – Prozess ist dokumentiert und wird regelmäßig durchgeführt
    • Reifegrad 3: Etabliert – Standardprozess ist definiert, wird konsequent angewandt und gemessen
    • Reifegrad 4: Vorhersagbar – Prozess wird quantitativ gesteuert
    • Reifegrad 5: Optimierend – kontinuierliche Verbesserung ist systematisch etabliert

    Für ein erfolgreiches TISAX Assessment müssen alle relevanten Kontrollfragen mindestens Reifegrad 3 erreichen. Einzelne Abweichungen auf Reifegrad 2 können unter bestimmten Bedingungen akzeptiert werden, erfordern aber einen konkreten Maßnahmenplan.

     

    Die zentralen Anforderungsbereiche im Detail

    Die folgenden Bereiche bilden den Kern der TISAX Anforderungen:

    1. Informationssicherheits-Richtlinien

    Das Unternehmen muss eine dokumentierte Informationssicherheitspolitik haben, die von der Geschäftsleitung verabschiedet und kommuniziert wurde. Daraus abgeleitet werden spezifische Richtlinien für einzelne Sicherheitsbereiche.

    2. Organisation der Informationssicherheit

    Klare Rollen und Verantwortlichkeiten für Informationssicherheit müssen definiert sein. Das umfasst einen Informationssicherheitsbeauftragten (ISB), Berichtslinien zur Geschäftsleitung und die Integration in die Organisationsstruktur.

    3. Personalsicherheit

    Anforderungen an Mitarbeitersensibilisierung, Schulungen, Vertraulichkeitsvereinbarungen und Prozesse bei Eintritt, Wechsel und Austritt von Mitarbeitern.

    4. Asset Management

    Alle Informationswerte (Assets) müssen inventarisiert, klassifiziert und einem Verantwortlichen zugeordnet sein. Dazu gehören IT-Systeme, Anwendungen, Daten und physische Medien.

    5. Zugangssteuerung

    Umfassende Anforderungen an Benutzerregistrierung, Zugangsrechte, privilegierte Zugänge und die regelmäßige Überprüfung von Berechtigungen (Access Reviews).

    6. Kryptografie

    Anforderungen an den Einsatz von Verschlüsselung für Daten in Transit und at Rest sowie an das Management von kryptografischen Schlüsseln.

    7. Physische Sicherheit

    Schutz von Gebäuden, Räumen und Einrichtungen, in denen Informationen verarbeitet oder gespeichert werden. Besonders relevant bei Prototypenschutz.

    8. Betriebssicherheit

    Anforderungen an Change Management, Kapazitätsplanung, Schutz vor Schadsoftware, Patch-Management, Logging und die Trennung von Entwicklungs-, Test- und Produktionsumgebungen.

    9. Kommunikationssicherheit

    Schutz von Netzwerken, Netzwerkdiensten und der Informationsübertragung (E-Mail, Datentransfer, Cloud-Dienste).

    10. Lieferantenbeziehungen

    Anforderungen an die Sicherheitsbewertung und -steuerung von Lieferanten und Dienstleistern, die Zugang zu Informationen des Unternehmens haben.

    11. Incident Management

    Dokumentierte Prozesse für die Erkennung, Meldung, Eskalation und Behandlung von Informationssicherheitsvorfällen.

    12. Business Continuity Management

    Anforderungen an Notfallpläne, Wiederherstellungsverfahren und deren regelmäßige Übung und Aktualisierung.

    13. Compliance

    Identifikation und Einhaltung aller relevanten gesetzlichen, vertraglichen und regulatorischen Anforderungen an die Informationssicherheit.

     

    Assessment Levels: Prüftiefe und Vorgaben

    TISAX unterscheidet drei Assessment Levels, die sich in der Prüftiefe und -methodik unterscheiden:

    Level 1: Selbstauskunft

    Reine Selbstbewertung ohne externe Prüfung. Level 1 wird in der Praxis kaum gefordert und erzeugt kein TISAX-Label.

    Level 2: Plausibilitätsprüfung

    Der Prüfdienstleister führt eine Plausibilitätsprüfung der Selbstauskunft durch. Dies geschieht in der Regel remote per Dokumentenprüfung und Interview. Geeignet für Unternehmen mit normalem Schutzbedarf. Was der Prüfer dabei im Detail verlangt und welche Nachweise vorliegen müssen, zeigt der Überblick zum Assessment Level 2.

    Level 3: Vollständige Vor-Ort-Prüfung

    Der Prüfdienstleister führt ein umfassendes Vor-Ort-Audit durch, bei dem Dokumente, Prozesse und technische Implementierungen detailliert geprüft werden. Erforderlich für Unternehmen mit hohem Schutzbedarf oder bei Prototypenschutz. Welche zusätzlichen Nachweise dafür zu erbringen sind, fasst der Beitrag zu den Anforderungen an Level 3 zusammen.

    Welches Level gefordert wird, wird vom Auftraggeber (OEM oder Tier 1) festgelegt und hängt vom Schutzbedarf der geteilten Informationen ab. Wie diese Einstufung im Detail funktioniert, erklärt unser Leitfaden zu den TISAX® Klassifizierungsstufen. Die meisten Assessment-Anforderungen in der Praxis liegen bei Level 2 oder Level 3.

     

    Typische Fehler bei der TISAX-Vorbereitung

    Aus der Praxis lassen sich wiederkehrende Stolpersteine identifizieren, die Unternehmen bei der Vorbereitung auf TISAX vermeiden sollten:

    1. Zu späte Vorbereitung

    Viele Unternehmen beginnen erst mit der Vorbereitung, wenn der OEM das Assessment fordert. Eine solide Vorbereitung benötigt typischerweise 3 bis 12 Monate – je nach Reifegrad und Assessment Level. Wie ein realistischer Vorlauf praktisch aussieht, beschreibt unser Leitfaden zur Vorbereitung auf die TISAX®-Zertifizierung.

    2. Fokus nur auf Dokumentation

    TISAX prüft nicht nur, ob Richtlinien und Prozesse dokumentiert sind, sondern ob sie tatsächlich gelebt werden. Rein formale Dokumentation ohne gelebte Praxis führt zu Feststellungen im Assessment.

    3. Unterschätzung der Scope-Definition

    Der Geltungsbereich (Scope) des Assessments muss sorgfältig definiert werden. Alle Standorte, Systeme und Prozesse, die mit den prüfungsrelevanten Informationen in Kontakt kommen, müssen einbezogen werden.

    4. Fehlende Management-Unterstützung

    TISAX ist kein reines IT-Projekt. Ohne aktive Unterstützung der Geschäftsleitung fehlen die notwendigen Ressourcen und die organisatorische Verbindlichkeit.

    5. Vernachlässigung der Lieferantenkette

    Die Anforderungen an Lieferantenmanagement werden häufig unterschätzt. Unternehmen müssen nachweisen, dass auch ihre eigenen Dienstleister angemessene Sicherheitsmaßnahmen umsetzen.

     

    Praxisnaher Fahrplan für die TISAX-Vorbereitung

    Ein strukturierter Ansatz für die Umsetzung der TISAX Anforderungen umfasst folgende Phasen:

    Phase 1: Initialisierung (2–4 Wochen)

    • Scope-Definition: Welche Standorte, Systeme und Informationen sind betroffen?
    • Festlegung des Assessment Levels und der Prüfziele
    • Sicherung der Management-Unterstützung und Ressourcen
    • Benennung eines Projektleiters und eines Informationssicherheitsbeauftragten

    Phase 2: Gap-Analyse (4–6 Wochen)

    • Systematische Bewertung des Ist-Zustands gegen den VDA ISA Katalog
    • Identifikation von Lücken (Gaps) und Priorisierung der Handlungsfelder
    • Erstellung eines realistischen Maßnahmenplans

    Phase 3: Umsetzung (8–24 Wochen)

    • Implementierung fehlender Prozesse, Richtlinien und technischer Maßnahmen
    • Schulung und Sensibilisierung der Mitarbeiter
    • Aufbau der erforderlichen Dokumentation
    • Regelmäßige Fortschrittskontrolle

    Phase 4: Internes Audit und Assessment-Vorbereitung (4–6 Wochen)

    • Durchführung eines internen Audits (Pre-Assessment)
    • Behebung identifizierter Schwachstellen
    • Registrierung bei der ENX Association
    • Auswahl eines zugelassenen Prüfdienstleisters

    Phase 5: Assessment (2–4 Wochen)

    • Durchführung des externen Assessments
    • Bearbeitung eventueller Feststellungen (Corrective Actions)
    • Erhalt des TISAX-Labels

    TrustSpace begleitet Unternehmen durch alle Phasen der TISAX-Vorbereitung – von der Gap-Analyse über die Maßnahmenumsetzung bis zur Assessment-Begleitung.

     

    Häufig gestellte Fragen zu TISAX Anforderungen

    Welche Anforderungen gelten für TISAX konkret?

    Die Anforderungen basieren auf dem VDA ISA Katalog und umfassen die Bereiche Informationssicherheit, optional Prototypenschutz und Datenschutz. Jede Kontrollfrage muss mindestens Reifegrad 3 erreichen.

    Was ist der VDA ISA Katalog?

    Der VDA ISA ist ein Fragenkatalog, der die Prüfkriterien für TISAX definiert. Er basiert auf ISO 27001, wurde aber um automobilspezifische Anforderungen erweitert – insbesondere zum Prototypenschutz.

    Welche Nachweise werden im Assessment erwartet?

    Je nach Assessment Level werden Dokumente (Richtlinien, Prozessbeschreibungen, Nachweise), Interviews mit Verantwortlichen und bei Level 3 eine Vor-Ort-Begehung mit technischer Überprüfung erwartet.

    Was ist der Unterschied zwischen Level 2 und Level 3?

    Level 2 ist eine Plausibilitätsprüfung (meist remote), Level 3 eine vollständige Vor-Ort-Prüfung mit höherer Prüftiefe. Welches Level erforderlich ist, bestimmt der Auftraggeber.

    Wie lange dauert die Vorbereitung auf TISAX?

    Je nach Ausgangslage und Assessment Level zwischen 3 und 12 Monaten. Bei einem realistischen TISAX Zeitplan ist eine frühzeitige Planung entscheidend.

     

    Fazit: TISAX Anforderungen systematisch erfüllen

    Die TISAX Anforderungen sind umfassend, aber bei strukturierter Herangehensweise gut beherrschbar. Der Schlüssel liegt in einer sauberen Scope-Definition, einer ehrlichen Gap-Analyse, konsequenter Umsetzung und ausreichend Zeit für die Vorbereitung. Wie Unternehmen TISAX® und NIS2 parallel meistern, besprechen unsere Experten auch im Podcast zu NIS2 und TISAX.

    Unternehmen, die bereits ein ISMS nach ISO 27001 betreiben, haben einen erheblichen Vorsprung – viele Anforderungen sind bereits abgedeckt. TrustSpace hilft dabei, die Lücken zu identifizieren und die automobilspezifischen Zusatzanforderungen effizient umzusetzen.

  • IT-Sicherheit im Mittelstand: Schwachstellen erkennen und Maßnahmen schnell umsetzen

    IT-Sicherheit im Mittelstand: Schwachstellen erkennen und Maßnahmen schnell umsetzen

    Das Wichtigste in Kürze

    • Mittelständische Unternehmen sind überdurchschnittlich häufig Ziel von Cyberangriffen – oft fehlen Ressourcen, Strukturen und Bewusstsein für systematische IT-Sicherheit.
    • Typische Schwachstellen sind veraltete Systeme, fehlende Netzwerksegmentierung, mangelnde Mitarbeitersensibilisierung und unzureichendes Patch-Management.
    • Regulierungen wie die DSGVO und die NIS-2-Richtlinie verpflichten Unternehmen zunehmend zu konkreten Sicherheitsmaßnahmen – auch KMU.
    • Ein strukturiertes IT-Sicherheitskonzept für KMU beginnt mit einer Risikoanalyse und wird idealerweise als fortlaufender Prozess in einem ISMS gebündelt.
    • TrustSpace unterstützt mittelständische Unternehmen dabei, ein ISMS aufzubauen und gesetzliche Anforderungen effizient zu erfüllen.

     

    Warum IT-Sicherheit im Mittelstand besonders kritisch ist

    Cyberangriffe treffen längst nicht mehr nur Großkonzerne. Im Gegenteil: Der Mittelstand rückt zunehmend in den Fokus professioneller Angreifer. Die Gründe dafür sind systemisch.

    Mittelständische Unternehmen verfügen häufig über wertvolle Datenbestände – von Kundendaten über Konstruktionszeichnungen bis hin zu Finanzinformationen –, betreiben aber selten ein vergleichbares Sicherheitsniveau wie größere Organisationen. Die IT-Abteilung besteht oft aus wenigen Personen, die neben dem Tagesgeschäft auch die Sicherheit verantworten. Dedizierte Security-Teams oder ein Chief Information Security Officer (CISO) sind die Ausnahme. Wo genau ein angemessenes Sicherheitsniveau liegt, lässt sich ohnehin erst bestimmen, wenn die Schutzziele der Informationssicherheit für das eigene Unternehmen konkret definiert sind.

    Hinzu kommt: Viele KMU unterschätzen das eigene Risiko. Sie gehen davon aus, für Angreifer uninteressant zu sein. Dabei zeigt die Statistik das Gegenteil. Laut Bitkom-Studien waren in den letzten Jahren mehr als 80 % aller deutschen Unternehmen von Cyberangriffen betroffen – mit einem Gesamtschaden im dreistelligen Milliardenbereich. Welche Grundlagen der IT-Cyber-Security vor Cyberangriffen schützen, haben wir separat zusammengefasst.

    Cybersecurity für KMU ist daher keine optionale Investition, sondern eine betriebswirtschaftliche Notwendigkeit. Wer IT-Sicherheit vernachlässigt, riskiert nicht nur finanzielle Schäden, sondern auch Reputationsverluste, Betriebsunterbrechungen und regulatorische Sanktionen. Wie sich der Aufbau eines belastbaren Schutzniveaus fachlich begleiten lässt, zeigen unsere Leistungen rund um die Cybersecurity mit TrustSpace.

     

    Typische Schwachstellen der IT-Sicherheit im Mittelstand

    Die Schwachstellen mittelständischer Unternehmen sind oft struktureller Natur. Sie resultieren weniger aus technischer Inkompetenz als aus fehlenden Prozessen, Ressourcen und Priorisierung.

    1. Fehlendes oder veraltetes Patch-Management

    Ungepatchte Software und Betriebssysteme gehören zu den häufigsten Einfallstoren für Cyberangriffe. Viele KMU setzen Legacy-Systeme ein, für die keine Sicherheitsupdates mehr verfügbar sind, oder versäumen es, verfügbare Patches zeitnah einzuspielen.

    2. Unzureichende Netzwerksegmentierung

    In vielen mittelständischen Unternehmen existiert ein flaches Netzwerk, in dem alle Systeme im selben Segment kommunizieren. Gelingt es einem Angreifer, einen Endpunkt zu kompromittieren, kann er sich nahezu ungehindert lateral im Netzwerk bewegen.

    3. Mangelnde Mitarbeitersensibilisierung

    Phishing und Social Engineering sind nach wie vor die erfolgreichsten Angriffsvektoren. Ohne regelmäßige Security-Awareness-Trainings werden Mitarbeiter unwissentlich zum größten Sicherheitsrisiko.

    4. Fehlende oder ungetestete Backups

    Backups existieren zwar in vielen Unternehmen, werden aber selten auf Wiederherstellbarkeit getestet. Im Ernstfall – etwa bei einem Ransomware-Angriff – zeigt sich dann, dass die Sicherungen unvollständig, veraltet oder kompromittiert sind.

    5. Keine klaren Verantwortlichkeiten

    Wenn IT-Sicherheit nicht organisatorisch verankert ist, fehlen definierte Zuständigkeiten, Eskalationswege und Reaktionspläne. Die Folge: Im Ernstfall wird wertvolle Zeit verloren. Welche Rollen dabei zu besetzen sind und wer im Unternehmen tatsächlich von Informationssicherheit betroffen ist, sollte schriftlich festgehalten sein.

    6. Unzureichendes Zugriffsmanagement

    Übertriebene Berechtigungen, geteilte Passwörter und fehlende Multi-Faktor-Authentifizierung (MFA) machen es Angreifern leicht, privilegierte Zugänge zu erlangen.

    7. Keine Übersicht über die eigene IT-Landschaft

    Viele KMU wissen nicht exakt, welche Systeme, Anwendungen und Schnittstellen in ihrer IT-Umgebung aktiv sind. Ohne ein aktuelles Asset-Inventar können Schwachstellen nicht systematisch identifiziert werden.

     

    IT-Sicherheitskonzept für KMU: Der Maßnahmen-Rahmen

    Ein wirksames IT-Sicherheitskonzept für KMU muss nicht die Komplexität eines Großkonzern-Ansatzes haben. Es muss aber systematisch, nachvollziehbar und an die individuellen Risiken angepasst sein.

    Schritt 1: Bestandsaufnahme und Risikoanalyse

    Am Anfang steht die Identifikation der schützenswerten Assets: Welche Daten, Systeme und Prozesse sind geschäftskritisch? Welche Bedrohungsszenarien sind realistisch? Wie hoch wäre der Schaden bei einem erfolgreichen Angriff?

    Eine strukturierte Risikobewertung bildet die Grundlage für alle weiteren Maßnahmen.

    Schritt 2: Technische Basismaßnahmen implementieren

    Die folgenden technischen Maßnahmen sollten in jedem mittelständischen Unternehmen umgesetzt sein:

    • Firewalls und Netzwerksegmentierung: Trennung von internen Netzwerken, Gastnetzwerken und kritischen Systemen
    • Endpoint Protection: Aktuelle Antivirus- und EDR-Lösungen auf allen Endgeräten
    • Patch-Management: Automatisierte und dokumentierte Update-Prozesse für alle Systeme
    • Verschlüsselung: Daten im Transit (TLS) und at Rest (Festplattenverschlüsselung)
    • Multi-Faktor-Authentifizierung: Für alle externen Zugänge und privilegierte Konten
    • Backup-Strategie: 3-2-1-Regel mit regelmäßigen Restore-Tests
    • E-Mail-Security: Spamfilter, DMARC, DKIM und SPF-Konfiguration
    • Protokollierung: Zentrale Log-Sammlung und -auswertung (SIEM oder vergleichbar)

    Schritt 3: Organisatorische Maßnahmen verankern

    Technik allein reicht nicht. Entscheidend sind die begleitenden organisatorischen Maßnahmen:

    • Sicherheitsrichtlinien: Dokumentierte Policies für Passwörter, Mobile Devices, Remote Work und Datenklassifizierung
    • Rollenbasiertes Berechtigungskonzept: Least-Privilege-Prinzip mit regelmäßigen Reviews
    • Security Awareness: Regelmäßige Schulungen und simulierte Phishing-Kampagnen
    • Incident-Response-Plan: Dokumentierter Ablauf für die Reaktion auf Sicherheitsvorfälle
    • Dienstleistersteuerung: Sicherheitsanforderungen und vertragliche Regelungen für IT-Dienstleister und Cloud-Anbieter
    • Business Continuity Planning: Notfallpläne für den Ausfall geschäftskritischer Systeme

    Schritt 4: Kontinuierliche Überprüfung und Verbesserung

    IT-Sicherheit ist kein Projekt, sondern ein fortlaufender Prozess. Die Bedrohungslandschaft verändert sich ständig, ebenso wie die eigene IT-Umgebung. Deshalb müssen Maßnahmen regelmäßig überprüft und angepasst werden – idealerweise im Rahmen eines Informationssicherheits-Managementsystems (ISMS).

     

    Maßnahmen-Checkliste: IT-Sicherheit für den Mittelstand

    Die folgende Checkliste fasst die wichtigsten Maßnahmen zusammen, die jedes mittelständische Unternehmen adressieren sollte:

    Infrastruktur und Netzwerk:

    • Aktuelle Firewall mit regelmäßig überprüftem Regelwerk
    • Netzwerksegmentierung nach Schutzbedarf
    • VPN für alle Remote-Zugriffe
    • WLAN-Sicherheit mit WPA3 und separatem Gastnetz
    • Vollständiges und aktuelles IT-Asset-Inventar

    Endgeräte und Software:

    • Automatisiertes Patch-Management für Betriebssysteme und Anwendungen
    • Endpoint Detection and Response (EDR) auf allen Geräten
    • Festplattenverschlüsselung auf Laptops und mobilen Geräten
    • Mobile Device Management (MDM) für dienstliche Mobilgeräte

    Identitäts- und Zugriffsmanagement:

    • Multi-Faktor-Authentifizierung für alle kritischen Systeme
    • Zentrales Identity Management (idealerweise SSO)
    • Dokumentiertes Berechtigungskonzept mit regelmäßigen Reviews
    • Automatische Deprovisionierung bei Mitarbeiteraustritt

    Datensicherung und Wiederherstellung:

    • Backup-Strategie nach 3-2-1-Prinzip
    • Regelmäßige Restore-Tests (mindestens quartalsweise)
    • Offline- oder immutable Backups zum Schutz vor Ransomware
    • Dokumentierte Recovery-Zeiten (RTO/RPO)

    Organisation und Awareness:

    • Benannter Verantwortlicher für Informationssicherheit
    • Jährliche Security-Awareness-Schulungen für alle Mitarbeiter
    • Dokumentierter Incident-Response-Plan
    • Regelmäßige Sicherheitsaudits (intern oder extern)

     

    Regulatorische Anforderungen: DSGVO und NIS-2

    Die IT-Sicherheit im Mittelstand wird nicht nur durch wirtschaftliche Überlegungen, sondern zunehmend auch durch gesetzliche Anforderungen getrieben. Den systematischen Umgang mit diesen Vorgaben fasst der Begriff IT Compliance zusammen. Zwei Regulierungen sind dabei besonders relevant.

    DSGVO: Technische und organisatorische Maßnahmen

    Die Datenschutz-Grundverordnung (DSGVO) verpflichtet in Art. 32 jeden Verantwortlichen und Auftragsverarbeiter, „geeignete technische und organisatorische Maßnahmen” zum Schutz personenbezogener Daten zu treffen. Die TOMs nach DSGVO müssen dem jeweiligen Verarbeitungsrisiko angemessen sein.

    Für den Mittelstand bedeutet das konkret:

    • Personenbezogene Daten müssen durch angemessene Schutzmaßnahmen gesichert sein
    • Die Maßnahmen müssen dokumentiert und ihre Wirksamkeit nachweisbar sein
    • Bei Datenpannen besteht eine Meldepflicht innerhalb von 72 Stunden
    • Verstöße können mit Bußgeldern von bis zu 20 Millionen Euro oder 4 % des Jahresumsatzes geahndet werden

    NIS-2-Richtlinie: Erweiterte Pflichten für KMU

    Die NIS-2-Richtlinie der EU weitet die Anforderungen an Cybersicherheit erheblich aus. Im Vergleich zur Vorgängerrichtlinie NIS-1 sind nun deutlich mehr Unternehmen betroffen – auch viele mittelständische Betriebe.

    Kernpunkte der NIS-2-Anforderungen:

    • Risikomanagement: Unternehmen müssen ein systematisches Risikomanagement für Cybersicherheit implementieren
    • Incident Handling: Pflicht zur Erkennung, Meldung und Behandlung von Sicherheitsvorfällen
    • Lieferkettenmanagement: Sicherheitsanforderungen müssen auch auf Zulieferer und Dienstleister ausgedehnt werden
    • Geschäftskontinuität: Business-Continuity- und Krisenmanagement-Pläne werden Pflicht
    • Geschäftsführerhaftung: Die Unternehmensleitung haftet persönlich für die Umsetzung der Sicherheitsmaßnahmen

    Unternehmen ab 50 Mitarbeitern oder 10 Millionen Euro Jahresumsatz in den betroffenen Sektoren fallen unter NIS 2. Die Umsetzung in nationales Recht erfolgt über das NIS2UmsuCG, das am 6. Dezember 2025 in Kraft getreten ist. In einzelnen Sektoren kommen weitere Vorgaben hinzu: Wie eng der Rahmen etwa in der IT-Sicherheit im Gesundheitswesen gesteckt ist, zeigt das Zusammenspiel aus KRITIS-Pflichten, B3S und KBV-Richtlinie.

    Weitere regulatorische Rahmenwerke

    Je nach Branche und Geschäftstätigkeit können weitere Anforderungen relevant sein:

    • BSI IT-Grundschutz: Umfassender Maßnahmenkatalog für Informationssicherheit
    • ISO 27001: Internationaler Standard für Informationssicherheits-Managementsysteme
    • TISAX: Branchenstandard für die Automobilindustrie
    • KRITIS-Verordnung: Anforderungen für Betreiber kritischer Infrastrukturen

     

    Der Weg zum ISMS: IT-Sicherheit systematisch aufbauen

    Einzelne Maßnahmen allein ergeben noch kein kohärentes Sicherheitskonzept. Mittelständische Unternehmen, die ihre IT-Sicherheit nachhaltig verbessern wollen, sollten ein Informationssicherheits-Managementsystem (ISMS) aufbauen.

    Ein ISMS integriert alle Sicherheitsmaßnahmen in einen strukturierten Rahmen mit:

    • Definierten Verantwortlichkeiten und Rollen
    • Regelmäßiger Risikoanalyse und -bewertung
    • Dokumentierter Maßnahmenumsetzung und -überwachung
    • Kontinuierlicher Überprüfung und Verbesserung (PDCA-Zyklus)
    • Nachweis der Compliance gegenüber Kunden, Partnern und Behörden

    Softwaregestützt lässt sich ein solches System deutlich schneller aufbauen und dauerhaft betreiben als über verteilte Dokumentenvorlagen – genau diesen Weg deckt die TrustSpace ISMS-Software ab.

    Der internationale Standard ISO 27001 bietet dafür ein bewährtes Rahmenwerk, das auch für mittelständische Unternehmen skalierbar ist.

     

    Häufig gestellte Fragen zur IT-Sicherheit im Mittelstand

    Wie starte ich mit IT-Sicherheit in meinem Unternehmen?

    Der erste Schritt ist eine Bestandsaufnahme: Welche IT-Systeme und Daten gibt es? Wo liegen die größten Risiken? Darauf aufbauend werden priorisierte Maßnahmen definiert. Ein externer Security-Check oder eine Gap-Analyse kann als Ausgangspunkt dienen.

    Braucht ein mittelständisches Unternehmen ein ISMS?

    Ein ISMS ist nicht für jedes Unternehmen gesetzlich vorgeschrieben, aber in den meisten Fällen sinnvoll. Spätestens wenn Kundenanforderungen, regulatorische Vorgaben (NIS 2, DSGVO) oder Zertifizierungen wie ISO 27001 relevant werden, ist ein strukturiertes ISMS der effizienteste Weg.

    Was kostet IT-Sicherheit für KMU?

    Die Kosten hängen von Unternehmensgröße, Branche und Reifegrad ab. Als Richtwert empfehlen Branchenexperten, 10–15 % des IT-Budgets für Sicherheitsmaßnahmen zu kalkulieren. Die Kosten eines erfolgreichen Cyberangriffs übersteigen diese Investition regelmäßig um ein Vielfaches.

    Ist mein Unternehmen von NIS 2 betroffen?

    NIS 2 betrifft Unternehmen ab 50 Mitarbeitern oder 10 Millionen Euro Jahresumsatz in definierten Sektoren (u. a. Energie, Gesundheit, digitale Infrastruktur, verarbeitendes Gewerbe, IKT-Dienstleistungen). Auch kleinere Unternehmen können betroffen sein, wenn sie als kritischer Zulieferer fungieren.

     

    Fazit: IT-Sicherheit im Mittelstand ist kein Luxus

    Die Bedrohungslage für mittelständische Unternehmen ist real und wächst. Gleichzeitig steigen die regulatorischen Anforderungen durch DSGVO, NIS 2 und branchenspezifische Standards. Wer jetzt nicht handelt, riskiert nicht nur Cyberangriffe, sondern auch Bußgelder, Haftungsrisiken und den Verlust von Kundenvertrauen.

    Die gute Nachricht: Cybersecurity für KMU muss nicht unbedingt teuer oder komplex sein. Mit einem strukturierten Ansatz, den richtigen Prioritäten und den passenden Werkzeugen lässt sich ein wirksames Sicherheitsniveau aufbauen.

    TrustSpace bietet mittelständischen Unternehmen eine Plattform, die den Aufbau eines ISMS nach ISO 27001 effizient und skalierbar macht – inklusive Risikomanagement, Maßnahmentracking, Audit-Vorbereitung und automatisiertem Compliance-Nachweis. So wird IT-Sicherheit vom Kostenfaktor zum Wettbewerbsvorteil.

  • TOM Maßnahmen DSGVO: Technische und organisatorische Maßnahmen mit Praxisbeispielen

    TOM Maßnahmen DSGVO: Technische und organisatorische Maßnahmen mit Praxisbeispielen

    Das Wichtigste in Kürze

    Pflichtprogramm: Technische und organisatorische Maßnahmen (TOMs) sind nach Art. 32 DSGVO für alle Verantwortlichen und Auftragsverarbeiter zwingend erforderlich.
    Risikobasierter Ansatz: Das Schutzniveau muss dem Risiko angemessen sein, wobei Stand der Technik, Implementierungskosten und Verarbeitungsrisiken zu berücksichtigen sind.
    Vier Schutzziele: Im Fokus stehen Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme.
    Nachweispflicht: Eine lückenlose Dokumentation der TOMs ist obligatorisch für Behördenanfragen.
    Kontinuierlicher Prozess: Statische Dokumentationen genügen nicht; TOMs erfordern regelmäßige Überprüfung und Aktualisierung.

    Was sind TOM Maßnahmen nach der DSGVO?

    Die Abkürzung TOM steht für technische und organisatorische Maßnahmen. Der Begriff bezeichnet die Gesamtheit aller Vorkehrungen, die ein Unternehmen treffen muss, um den Schutz personenbezogener Daten bei deren Verarbeitung sicherzustellen.

    Die rechtliche Grundlage findet sich in Artikel 32 DSGVO (Sicherheit der Verarbeitung). Dort heißt es:

    „Unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen treffen der Verantwortliche und der Auftragsverarbeiter geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten.”

    TOMs sind damit kein optionaler Bestandteil des Datenschutzes, sondern eine verbindliche Pflicht. Sie betreffen jedes Unternehmen, das personenbezogene Daten verarbeitet – vom Einzelunternehmer bis zum Konzern, vom Auftragsverarbeiter bis zum Verantwortlichen.

    Die vier Schutzziele der TOM Maßnahmen

    Artikel 32 Abs. 1 DSGVO nennt vier zentrale Schutzziele, an denen sich die TOM Maßnahmen DSGVO orientieren müssen. Zur besseren Übersicht sind diese nachfolgend dargestellt:

    Schutzziel Bedeutung & Anforderung
    1. Vertraulichkeit Sicherstellung, dass personenbezogene Daten nur von autorisierten Personen eingesehen, verarbeitet oder weitergegeben werden können. Unbefugte dürfen keinen Zugriff erlangen.
    2. Integrität Gewährleistung, dass personenbezogene Daten korrekt und unverändert bleiben. Unautorisierte oder unbeabsichtigte Modifikationen müssen verhindert oder erkannt werden.
    3. Verfügbarkeit Personenbezogene Daten und die Systeme zu ihrer Verarbeitung müssen bei Bedarf zugänglich sein. Systemausfälle und Datenverluste sind zu minimieren.
    4. Belastbarkeit (Resilienz) Die Systeme müssen auch unter außergewöhnlichen Belastungen (Cyberangriffe, Naturkatastrophen) funktionsfähig bleiben oder rasch wiederhergestellt werden können.

    Ergänzend fordert Art. 32 Abs. 1 lit. d DSGVO ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit aller technischen und organisatorischen Maßnahmen.

    Technische und organisatorische Maßnahmen Beispiele: Der Praxisleitfaden

    Die folgende Übersicht strukturiert konkrete Beispiele für TOMs nach den klassischen Datenschutz-Kontrollkategorien. Anstatt langer Listen finden Sie hier kompakte Gegenüberstellungen der technischen und organisatorischen Aspekte.

    Kontrollkategorie Technische Maßnahmen Organisatorische Maßnahmen
    ZutrittskontrollePhysischer Schutz der Datenverarbeitung vor unbefugtem Zugang. Elektronische Zutrittskontrollsysteme (Badge, Chipkarten), biometrische Zugangssicherung für Serverräume, Videoüberwachung sensibler Bereiche, automatische Türschließer sowie Alarm- und Einbruchmeldesysteme. Besucherrichtlinien mit Anmeldepflicht, dokumentierte Schlüsselverwaltung, regelmäßige Überprüfung von Zutrittsberechtigungen, Umsetzung eines Zonenkonzepts und die Protokollierung von Zutrittsversuchen.
    Zugangskontrolle
    Schutz vor unbefugter Systemnutzung.    		 Einsatz von Multi-Faktor-Authentifizierung (MFA), starke Passwortrichtlinien, automatische Bildschirmsperren, Festplattenverschlüsselung, VPN-Pflicht für Remote-Arbeit und automatische Kontosperrungen. Festgelegte Verfahren zur Benutzerverwaltung (Anlage, Änderung, Löschung), Clean-Desk-Policy, Richtlinien für mobile Geräte (BYOD) und regelmäßige Rezertifizierung der Benutzerkonten.
    Zugriffskontrolle
    Berechtigungsmanagement nach dem Need-to-know-Prinzip.    		 Rollenbasierte Berechtigungskonzepte (RBAC), granulare Zugriffssteuerung auf Dateiebene, Data Loss Prevention (DLP) Systeme und die Protokollierung aller Datenzugriffe (Audit Trails). Anwendung des Prinzips der minimalen Rechtevergabe (Least Privilege), regelmäßige Berechtigungsreviews, dokumentierte Antrags- und Genehmigungsprozesse sowie sofortige Entzüge bei Rollenwechseln.
    Weitergabekontrolle
    Schutz bei der Datenübertragung und -speicherung.    		 TLS/SSL- und Ende-zu-Ende-Verschlüsselung, VPN-Tunnel für Transfers, sichere Protokolle (SFTP), verschlüsselte E-Mail-Anhänge und die Deaktivierung von USB-Ports. Richtlinien für den Datenversand, Verbot privater E-Mail-Accounts für dienstliche Zwecke, Protokollierung von Exporten und die zertifizierte Entsorgung von Datenträgern.
    Eingabekontrolle
    Nachvollziehbarkeit der Datenverarbeitung.    		 Umfassende Audit-Logs, Versionierung von Datensätzen, manipulationssichere WORM-Speicher für Log-Dateien und automatische Zeitstempel bei jeder Änderung. Festgelegte Verantwortlichkeiten für die Dateneingabe, Anwendung des Vier-Augen-Prinzips bei kritischen Änderungen und definierte Aufbewahrungsfristen für Log-Daten.
    Auftragskontrolle
    Absicherung der Auftragsverarbeitung.    		 Technische Durchsetzung von Zugriffsrichtlinien bei Dienstleistern, Monitoring-Tools und die strikte Verschlüsselung von Daten vor der Übermittlung an Verarbeiter. Abschluss von Auftragsverarbeitungsverträgen (AVV) nach Art. 28 DSGVO, Due-Diligence-Prüfungen vorab, regelmäßige Audits und vertraglich geregelte Löschpflichten.
    Verfügbarkeitskontrolle
    Schutz vor Datenverlust.    		 Automatisierte Backups nach der 3-2-1-Regel, USV und Notstromaggregate, redundante Systemarchitekturen (Clustering, RAID), DDoS-Schutz und Brandschutzsysteme. Dokumentierte Backup-Konzepte, regelmäßige Restore-Tests, Business-Continuity-Management (BCM), Disaster-Recovery-Pläne und regelmäßige Notfallübungen.
    Trennungsgebot
    Zweckgebundene Verarbeitung.    		 Logische Mandantentrennung, physische Trennung von Produktiv- und Testsystemen, Sandboxing, Netzwerksegmentierung sowie Pseudonymisierung von Testdaten. Dokumentiertes Konzept zur Datentrennung, klare Festlegung von Verarbeitungszwecken im VVT und gezielte Mitarbeiterschulungen zum Trennungsgebot.

    Tipp: Das Vendor Risk Management von TrustSpace ermöglicht eine systematische Auswahl, Bewertung und laufende Überwachung von Auftragsverarbeitern – inklusive automatisiertem AVV-Management und Audit-Dokumentation.

    TOM Maßnahmen dokumentieren: Anforderungen und Best Practices

    Die Dokumentation der TOMs ist eine Pflicht aus Art. 5 Abs. 2 DSGVO (Rechenschaftspflicht). Sie wird zwingend in diversen Situationen benötigt: Bei Behördenanfragen, als Anlage zu Auftragsverarbeitungsverträgen, für Datenschutz-Folgenabschätzungen, als Nachweis gegenüber Partnern, im Falle einer Datenpanne sowie bei Zertifizierungsverfahren (z.B. ISO 27001).

    Strukturierte inhaltliche Anforderungen

    Eine vollständige Dokumentation sollte tabellarisch oder systematisch folgende Punkte abdecken:

    Erforderliche Metadaten pro Maßnahme: Konkrete Beschreibung der Maßnahme | Zuordnung zum Schutzziel | Zuordnung zur Kontrollkategorie | Verantwortliche Person/Abteilung | Umsetzungsstatus & Implementierungsdatum | Datum der letzten und nächsten Überprüfung | Ergebnis der Wirksamkeitsprüfung.

    Häufige Dokumentationsfehler (und wie man sie vermeidet)

    Zu generische Beschreibungen
    Aussagen wie „Es bestehen Sicherheitsmaßnahmen” reichen nicht. Benennen Sie präzise, welche Software oder welcher Prozess genutzt wird.
    Veraltete Dokumentation
    Maßnahmen, die seit Jahren nicht angefasst wurden, führen fast immer zu Prüfungsbefunden. Ein laufendes Review-Verfahren ist Pflicht.
    Fehlende Wirksamkeitsprüfung
    Maßnahmen nur zu beschreiben genügt nicht; sie müssen aktiv und nachweisbar getestet werden (z.B. durch Penetrationstests oder Restore-Übungen).
    Keine Risikoorientierung
    Die Maßnahmen müssen zum Risiko passen. Ein Newsletter-Versand erfordert andere TOMs als die Verarbeitung hochsensibler Gesundheitsdaten.

    Eine Plattformlösung wie TrustSpace ermöglicht die zentrale, strukturierte Dokumentation aller TOMs mit automatischen Erinnerungen für Reviews, Versionierung und direkter Verknüpfung mit dem Verzeichnis der Verarbeitungstätigkeiten.

    TOM-Checkliste für Unternehmen

    Nutzen Sie die folgende Check-Tabelle zur Evaluierung und Optimierung Ihrer Maßnahmen:

    Status Prüfbereich Konkrete Fragestellung
    ☐ Grundlagen Sind alle Verarbeitungstätigkeiten identifiziert, im VVT erfasst und einer Risikobewertung unterzogen worden?
    ☐ Grundlagen Ist ein Datenschutzbeauftragter benannt (sofern gesetzlich vorgeschrieben)?
    ☐ IT & Technik Ist Multi-Faktor-Authentifizierung (MFA) für relevante Systeme aktiviert und existiert ein getestetes Backup-Konzept?
    ☐ IT & Technik Werden Verschlüsselungen, Patch-Management, Netzwerksegmentierung und Endpoint-Schutz konsequent angewendet?
    ☐ Organisation Finden regelmäßige, dokumentierte Mitarbeiterschulungen zum Datenschutz statt?
    ☐ Organisation Sind AV-Verträge geschlossen, Löschkonzepte definiert und Prozesse für Datenschutzvorfälle etabliert?
    ☐ Evaluation Werden die TOMs mindestens jährlich auf ihre Wirksamkeit überprüft und bei Prozessänderungen sofort angepasst?

    Ob ein Unternehmen überhaupt einen Datenschutzbeauftragten stellen muss, richtet sich nach Mitarbeiterzahl und Art der Verarbeitung – die Kriterien, ab wann die Bestellpflicht greift, fasst der verlinkte Beitrag zusammen.

    Steht die Bestellung an, lohnt vor der Entscheidung ein Vergleich von internem und externem Datenschutzbeauftragten hinsichtlich Kosten, Haftung und Fachwissen.

    TOM-Vorlage: Die Anlage zum Ausfüllen

    Viele Unternehmen benötigen die technischen und organisatorischen Maßnahmen nicht nur als Fließtext, sondern als strukturierte TOM-Anlage – etwa als Anlage zum Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO oder zur Vorlage bei einem Audit. Die folgende Vorlage bildet die klassischen acht Kontrollbereiche sowie die zusätzlichen Anforderungen aus Art. 32 DSGVO ab. Tragen Sie je Bereich Ihre konkret umgesetzten Maßnahmen ein und markieren Sie den Status.

    Kontrollbereich Beispielmaßnahmen (individuell ergänzen) Umgesetzt?
    Zutrittskontrolle Chipkarten- oder Schließsystem, Alarmanlage, Besucherprotokoll, Serverraum-Sicherung ☐ ja   ☐ teilweise   ☐ offen
    Zugangskontrolle Passwortrichtlinie, Multi-Faktor-Authentifizierung, automatische Bildschirmsperre ☐ ja   ☐ teilweise   ☐ offen
    Zugriffskontrolle Berechtigungskonzept (Need-to-know), Rollenmodell, Protokollierung von Zugriffen ☐ ja   ☐ teilweise   ☐ offen
    Weitergabekontrolle Transportverschlüsselung (TLS), verschlüsselte Datenträger, sichere Löschverfahren ☐ ja   ☐ teilweise   ☐ offen
    Eingabekontrolle Protokollierung von Eingabe, Änderung und Löschung; Nachvollziehbarkeit der Verantwortlichen ☐ ja   ☐ teilweise   ☐ offen
    Auftragskontrolle AV-Verträge nach Art. 28, Dienstleisterprüfung, dokumentierte Weisungen ☐ ja   ☐ teilweise   ☐ offen
    Verfügbarkeitskontrolle Backup-Konzept, unterbrechungsfreie Stromversorgung, Notfallplan, Wiederherstellungstests ☐ ja   ☐ teilweise   ☐ offen
    Trennungskontrolle Mandantentrennung, getrennte Test- und Produktivsysteme, Zweckbindung der Verarbeitung ☐ ja   ☐ teilweise   ☐ offen
    Pseudonymisierung & Verschlüsselung
    (Art. 32 Abs. 1 a)    		 Pseudonymisierung personenbezogener Daten, Festplatten- und E-Mail-Verschlüsselung ☐ ja   ☐ teilweise   ☐ offen
    Belastbarkeit & Wiederherstellbarkeit
    (Art. 32 Abs. 1 b/c)    		 Redundante Systeme, definierte Wiederanlaufzeiten (RTO/RPO), regelmäßige Restore-Übungen ☐ ja   ☐ teilweise   ☐ offen
    Regelmäßige Überprüfung
    (Art. 32 Abs. 1 d)    		 Turnusmäßige Wirksamkeitsprüfung der TOMs, interne Audits, Anpassung an neue Risiken ☐ ja   ☐ teilweise   ☐ offen

    Ist ein externer Datenschutzbeauftragter für KMU bestellt, prüft dieser die Vorlage üblicherweise mit und hält sie aktuell. Wie sich die TOMs von der übergeordneten Abgrenzung zwischen Datenschutz und Informationssicherheit ableiten, zeigt der verlinkte Beitrag.

    TOMs im Zusammenspiel mit ISO 27001 und anderen Standards

    Die DSGVO-Maßnahmen agieren nicht im luftleeren Raum. Sie überschneiden sich stark mit etablierten Sicherheitsframeworks:

    ISO 27001
    Der internationale Standard für Informationssicherheits-Managementsysteme (ISMS) definiert in Anhang A Maßnahmen (Controls), die große Überlappungen mit den TOMs aufweisen. Ein ISMS ist die ideale Basis für DSGVO-Compliance.
    BSI IT-Grundschutz
    Das Kompendium des Bundesamts für Sicherheit in der Informationstechnik bietet äußerst detaillierte Maßnahmenkataloge, die als Blaupause für die technische Umsetzung dienen.
    SOC 2 & NIS-2-Richtlinie
    Während SOC 2 ähnliche Trust Service Criteria adressiert, erweitert NIS-2 die Anforderungen an das Risikomanagement für Cybersicherheit kritischer Infrastrukturen und Lieferketten.

    Unternehmen, die ihre TOMs im Rahmen eines integrierten Managementsystems umsetzen, profitieren von Synergien. TrustSpace ermöglicht diesen Ansatz: Die Plattform verknüpft DSGVO-TOMs direkt mit ISO 27001 Controls und NIS-2-Anforderungen – ohne doppelte Dokumentation.

    TOMs unter NIS2: Was Art. 21 zusätzlich verlangt

    Seit der NIS2-Richtlinie sind technische und organisatorische Maßnahmen nicht mehr nur ein Datenschutzthema. Während Art. 32 DSGVO auf den Schutz personenbezogener Daten zielt, verlangt Art. 21 NIS2 Risikomanagementmaßnahmen für die Sicherheit der gesamten Netz- und Informationssysteme – unabhängig davon, ob personenbezogene Daten betroffen sind. Betroffene Unternehmen müssen beide Ebenen abdecken.

    Kriterium TOMs nach DSGVO (Art. 32) TOMs nach NIS2 (Art. 21)
    Schutzobjekt Personenbezogene Daten Netz- und Informationssysteme insgesamt
    Auslöser Jede Verarbeitung personenbezogener Daten Einstufung als wichtige oder besonders wichtige Einrichtung
    Pflichtmaßnahmen (Auszug) Vertraulichkeit, Integrität, Verfügbarkeit, Belastbarkeit, Wiederherstellbarkeit Risikoanalyse, Incident Handling, Business Continuity, Lieferkettensicherheit, Kryptografie, Zugriffskontrolle, MFA, Schulungen

    Die zehn Mindestmaßnahmen aus Art. 21 Abs. 2 NIS2 gehen damit über die klassischen DSGVO-TOMs hinaus – insbesondere um Incident Handling, Lieferkettensicherheit und die Aufrechterhaltung des Betriebs. Welche Unternehmen betroffen sind und wie die Umsetzung Schritt für Schritt gelingt, fasst unsere NIS2-Checkliste für KMU zusammen. Wer seine TOMs sauber nach Art. 32 DSGVO dokumentiert hat, hat für NIS2 bereits einen großen Teil der Grundlage gelegt.

    Häufige Fehler bei der TOM-Umsetzung

    1. One-Size-Fits-All-Ansatz

    Eine Einheitsliste für alle Verarbeitungen ignoriert das gesetzlich geforderte konkrete Risiko. Die Maßnahmen müssen stets verhältnismäßig und individuell angepasst sein.

    2. Reine Techniklastigkeit

    Die beste Firewall nützt nichts, wenn Mitarbeiter auf Phishing hereinfallen. Mitarbeitersensibilisierung und klare Prozesse sind ebenso wichtig wie Hard- und Software.

    3. Fehlende Kontinuität

    Art. 32 DSGVO fordert ein Verfahren zur regelmäßigen Überprüfung. Wer TOMs einmalig definiert und ablegt, verfehlt die rechtlichen Anforderungen.

    4. Blindflug bei Dienstleistern

    Sich nur auf vertragliche Zusagen im AVV zu verlassen, ist riskant. Auch die TOMs der Dienstleister müssen aktiv eingefordert und auditiert werden.

    Bußgelder und Konsequenzen bei unzureichenden TOMs

    Fehlende oder unzureichende Maßnahmen sind kein Kavaliersdelikt. Die Aufsichtsbehörden prüfen bei Datenpannen als Erstes die implementierten TOMs. Folgende Konsequenzen drohen:

    Hohe Bußgelder Nach Art. 83 Abs. 4 DSGVO drohen Sanktionen von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes für Verstöße gegen Art. 32.
    Schadensersatz Betroffene Personen können materiellen und immateriellen Schadensersatz (Art. 82 DSGVO) einklagen.
    Behördliche Anordnungen Behörden können die sofortige Einstellung von Verarbeitungstätigkeiten anordnen, bis die IT-Sicherheit nachgebessert wurde.
    Reputationsschaden Datenlecks zerstören das Vertrauen von Kunden und Geschäftspartnern meist langfristig und ziehen negative Presse nach sich.