--- title: "Tabletop Exercise Ransomware: Anleitung und Szenarien" date: 2026-03-10T09:55:00+01:00 author: FAST LTA canonical_url: "https://www.fast-lta.de//de/blog/tabletop-exercise-ransomware-2" section: "Entries: Articles" --- ### 1. Was ein Table­top Exer­cise ist und was es nicht ist [\#](#1-was-ein-tabletop-exercise-ist-und-was-es-nicht-ist "1. Was ein Tabletop Exercise ist und was es nicht ist") #### Defi­ni­ti­on [\#](#definition "Definition") Ein Table­top Exer­cise (TTX) ist eine dis­kus­si­ons­ba­sier­te Übung, bei der Schlüs­sel­per­so­nen ein Inci­dent-Sze­na­rio durch­spie­len, ohne phy­si­sche Aktio­nen an ech­ten Sys­te­men durch­zu­füh­ren. Im Mit­tel­punkt steht die Ent­schei­dungs­fin­dung: Wer trifft wel­che Ent­schei­dung, nach wel­chem Pro­zess, mit wel­chen Informationen? #### Was ein TTX leis­tet [\#](#was-ein-ttx-leistet "Was ein TTX leistet") - Offen­bart Lücken in Inci­dent-Respon­se-Plä­nen, bevor ein rea­ler Vor­fall das tut - Tes­tet Kom­mu­ni­ka­ti­ons­ket­ten und Eskalationswege - Macht Ver­ant­wort­lich­kei­ten im Kri­sen­fall kon­kret (statt auf dem Papier zu lassen) - Schult Teil­neh­mer in Kri­sen­ent­schei­dun­gen unter Zeitdruck - Erzeugt Audit-Evi­denz für NIS2-Com­pli­ance (§30 BSIG in der Fas­sung des NIS2UmsuCG: Risi­ko­ma­nage­ment umfasst Back­up-Manage­ment und Kri­sen­ma­nage­ment, deren Wirk­sam­keit nach­weis­bar sein muss) #### Was ein TTX nicht leis­tet [\#](#was-ein-ttx-nicht-leistet "Was ein TTX nicht leistet") - Kein tech­ni­scher Reco­very-Test (das ist ein sepa­ra­ter Disaster-Recovery-Test) - Kei­ne Prü­fung von Backup-Integrität - Kein Red-Team-Test der Infrastruktur TTX und tech­ni­sche Reco­very-Tests ergän­zen ein­an­der, sie erset­zen sich nicht. --- ### 2. Vor­be­rei­tung: Wer muss dabei sein, was wird gebraucht [\#](#2-vorbereitung-wer-muss-dabei-sein-was-wird-gebraucht "2. Vorbereitung: Wer muss dabei sein, was wird gebraucht") #### Teil­neh­mer­kreis [\#](#teilnehmerkreis "Teilnehmerkreis") - **IT-Lei­ter / CISO:** tech­ni­sche Ent­schei­dun­gen, Eskalationsverantwortung - **Geschäfts­füh­rer / Vor­stand:** Ent­schei­dungs­ge­walt über Löse­geld­zah­lung, Pressemitteilungen - **Rechts­ab­tei­lung / Daten­schutz­be­auf­trag­ter:** DSGVO-Mel­de­pflich­ten, haf­tungs­recht­li­che Fragen - **PR / Kom­mu­ni­ka­ti­on:** Kun­den- und Pres­se­kom­mu­ni­ka­ti­on im Krisenfall - **Haupt­ver­ant­wort­li­cher für kri­ti­sche Sys­te­me:** ERP, CRM, Pro­duk­ti­on je nach Branche - **Finan­ce / CFO:** Cyber-Ver­si­che­rung, Notfallbudget - **Mode­ra­tor (intern oder extern):** Sze­na­ri­en ein­lei­ten, Tem­po steu­ern, Ergeb­nis­se dokumentieren **Min­dest­grö­ße:** 5 Per­so­nen. Ide­al: 8 bis 12 Per­so­nen. Mehr als 15 macht die Dis­kus­si­on schwer steuerbar. #### Mate­ria­li­en und Vor­be­rei­tung [\#](#materialien-und-vorbereitung "Materialien und Vorbereitung") **Mode­ra­tor:** - Sze­na­ri­en (sie­he Abschnitt 4) aus­dru­cken und bereithalten - Zeit­plan auf­stel­len: Eröff­nung (15 Min) + Sze­na­rio (45 bis 60 Min) + Aus­wer­tung (30 Min) - Pro­to­kol­lant benennen **Teil­neh­mer:** - Aktu­el­len Inci­dent-Respon­se-Plan mit­brin­gen (gedruckt; Sinn der Übung: Gilt er auch, wenn der PC nicht geht?) - Kon­takt­lis­te aller exter­nen Ansprech­part­ner (BSI-Mel­de­platt­form, Cyber-Ver­si­che­rung, IT-Foren­si­ker, Pressesprecher) - Reco­very-Run­books für kri­ti­sche Systeme **Wich­tig:** Der Mode­ra­tor kün­digt das Sze­na­rio NICHT im Vor­aus an. Spon­ta­ne Reak­tio­nen zei­gen rea­lis­ti­sche Lücken. #### Timing und Häu­fig­keit [\#](#timing-und-h%C3%A4ufigkeit "Timing und Häufigkeit") - **Dau­er:** 2 bis 3 Stun­den (ohne Pau­sen) für ein voll­stän­di­ges Sze­na­rio mit Auswertung - **Häu­fig­keit:** Min­des­tens jähr­lich für NIS2-Com­pli­ance; emp­foh­len: halbjährlich - **Zeit­punkt:** Außer­halb der Hoch­last-Peri­oden pla­nen (z. B. nicht im Q4-Abschluss) --- ### 3. Ablauf­struk­tur: So wird das TTX mode­riert [\#](#3-ablaufstruktur-so-wird-das-ttx-moderiert "3. Ablaufstruktur: So wird das TTX moderiert") #### Pha­se 1: Eröff­nung (15 Minu­ten) [\#](#phase-1-er%C3%B6ffnung-15-minuten "Phase 1: Eröffnung (15 Minuten)") - Mode­ra­tor erklärt Zweck und Regeln - Wich­tigs­te Regel: **​„Es gibt kei­ne dum­men Ant­wor­ten.”** Lücken sol­len sicht­bar wer­den, nicht versteckt - Kei­ne Ablen­kung durch Han­dys oder E‑Mails - Pro­to­kol­lant stellt sich vor - Inci­dent-Respon­se-Plan liegt auf dem Tisch #### Pha­se 2: Sze­na­rio-Injek­ti­on (3 bis 5 Minu­ten) [\#](#phase-2-szenario-injektion-3-bis-5-minuten "Phase 2: Szenario-Injektion (3 bis 5 Minuten)") Mode­ra­tor liest Sze­na­rio vor. Teil­neh­mer hören zu, ohne zu han­deln. Dann: ers­te offe­ne Frage. #### Pha­se 3: Dis­kus­si­on (40 bis 50 Minu­ten) [\#](#phase-3-diskussion-40-bis-50-minuten "Phase 3: Diskussion (40 bis 50 Minuten)") Mode­ra­tor stellt vor­be­rei­te­te Fra­gen in Phasen: - Pha­se A: Ers­te Reak­ti­on (0 bis 15 Minu­ten nach Vorfallserkennung) - Pha­se B: Eska­la­ti­on und Ent­schei­dung (15 bis 60 Minuten) - Pha­se C: Wie­der­her­stel­lung und Kom­mu­ni­ka­ti­on (60 Minu­ten bis Ende) Mode­ra­tor unter­bricht wenn nötig: ​„Was pas­siert jetzt, wenn X nicht erreich­bar ist?” oder ​„Wer ent­schei­det das, wenn der CEO im Urlaub ist?” #### Pha­se 4: Aus­wer­tung (30 Minu­ten) [\#](#phase-4-auswertung-30-minuten "Phase 4: Auswertung (30 Minuten)") Alle Teil­neh­mer ant­wor­ten auf drei Fragen: 1. Was hat gut funktioniert? 2. Was hat nicht funk­tio­niert oder war unklar? 3. Wel­che eine Sache soll­ten wir bis zum nächs­ten Quar­tal umge­setzt haben? Pro­to­kol­lant notiert. Ergeb­nis: Maß­nah­men­lis­te mit Ver­ant­wort­li­chen und Fristen. --- ### 4. Die drei Sze­na­ri­en [\#](#4-die-drei-szenarien "4. Die drei Szenarien") #### Sze­na­rio 1: Tar­ge­ted Ran­som­wa­re, der klas­si­sche Unter­neh­mens­an­griff [\#](#szenario-1-targeted-ransomware-der-klassische-unternehmensangriff "Szenario 1: Targeted Ransomware, der klassische Unternehmensangriff") **Schwie­rig­keits­grad:** Mit­tel | **Emp­foh­len für:** Ers­tes TTX **Sze­na­rio-Text:** Es ist Diens­tag, 06:47 Uhr. Der ers­te Mit­ar­bei­ter, der sich ein­loggt, sieht eine Feh­ler­mel­dung auf dem Bild­schirm. Weni­ge Minu­ten spä­ter rufen drei wei­te­re an. Das Help­desk-Sys­tem ist nicht erreich­bar. Der IT-Lei­ter wird infor­miert und stellt fest, dass auf dem Datei­ser­ver statt der übli­chen Ord­ner hun­der­te Datei­en mit der Endung „.encrypt­ed” vor­han­den sind, dazu eine Text­da­tei: ​„Your files have been encrypt­ed. Cont­act \[E‑Mail-Adres­se\] within 72 hours.” Ers­te Über­prü­fung: Acti­ve Direc­to­ry ist noch erreich­bar. E‑Mail-Sys­tem: nicht erreich­bar. ERP-Sys­tem: nicht erreich­bar. Back­up-Repo­si­to­ry: Sta­tus unbe­kannt, der Back­up-Ser­ver ant­wor­tet nicht auf Ping. Zeit­punkt: 07:15 Uhr. Arbeits­schicht beginnt in 45 Minuten. **Pha­se-A-Fra­gen (ers­te Reaktion):** 1. Wer trifft die Ent­schei­dung, ob die Arbeits­schicht wie geplant beginnt oder ob Mit­ar­bei­ter nach Hau­se geschickt werden? 2. Wel­che Sys­te­me müs­sen sofort iso­liert wer­den, und wer hat die Befug­nis dazu? 3. Wie lau­tet die ers­te inter­ne Kom­mu­ni­ka­ti­on? An wen? In wel­cher Form (Mail ist mög­li­cher­wei­se ausgefallen)? 4. Wann wird der Geschäfts­füh­rer infor­miert, und durch wen? **Pha­se-B-Fra­gen (Eska­la­ti­on):** 1. Das Back­up-Repo­si­to­ry ist kom­pro­mit­tiert. Was bedeu­tet das für die Recovery-Zeit-Schätzung? 2. Haben Sie ein Air-Gap-Back­up, auf das der Angrei­fer kei­nen Zugriff hat­te? Wis­sen Sie, wie aktu­ell die­ses ist? 3. Ein exter­nes IT-Foren­sik-Unter­neh­men soll hin­zu­ge­zo­gen wer­den. Wer ent­schei­det das? Haben Sie bereits einen Vertrag? 4. Wann und wie wird der Vor­fall dem BSI gemel­det? (§32 BSIG in der Fas­sung des NIS2UmsuCG: Erst­mel­dung erheb­li­cher Sicher­heits­vor­fäl­le bin­nen 24 Stun­den, aus­führ­li­che Mel­dung bin­nen 72 Stun­den, Abschluss­be­richt nach einem Monat) 5. Wann und wie wer­den betrof­fe­ne Kun­den infor­miert? Wer for­mu­liert die Nachricht? 6. Die Angrei­fer haben eine Löse­geld­for­de­rung gestellt. Wer ent­schei­det, ob gezahlt wird, und nach wel­chen Kriterien? **Pha­se-C-Fra­gen (Wie­der­her­stel­lung):** 1. In wel­cher Rei­hen­fol­ge wer­den Sys­te­me wie­der­her­ge­stellt? Wer hat das entschieden? 2. Das ERP-Sys­tem braucht vor­aus­sicht­lich 36 Stun­den für den Res­to­re. Die Pro­duk­ti­on steht. Wel­che manu­el­len Not­fall­pro­zes­se greifen? 3. Wann ist der Vor­fall ​„been­det”? Wor­an erken­nen Sie das? 4. Was pas­siert mit Daten, die zwi­schen dem letz­ten Back­up und dem Angriff ent­stan­den sind? #### Sze­na­rio 2: Sup­p­ly-Chain-Angriff über einen kom­pro­mit­tier­ten Dienst­leis­ter [\#](#szenario-2-supply-chain-angriff-%C3%BCber-einen-kompromittierten-dienstleister "Szenario 2: Supply-Chain-Angriff über einen kompromittierten Dienstleister") **Schwie­rig­keits­grad:** Hoch | **Emp­foh­len für:** Zwei­tes TTX, NIS2-pflich­ti­ge Unternehmen **Sze­na­rio-Text:** Es ist Don­ners­tag, 14:30 Uhr. Sie erhal­ten einen Anruf von Ihrem Mana­ged-Ser­vice-Pro­vi­der: ​„Wir haben ein Sicher­heits­pro­blem in unse­rer Umge­bung. Wir gehen davon aus, dass Kun­den­sys­te­me betrof­fen sein könn­ten. Wir emp­feh­len, den VPN-Zugang zu unse­rer Umge­bung sofort zu sperren.” Zwei Stun­den spä­ter: Drei Ihrer Ser­ver zei­gen unge­wöhn­li­ches Ver­hal­ten. Auf einem Daten­bank­ser­ver wer­den auto­ma­ti­siert Daten an eine exter­ne Adres­se über­tra­gen. Das Back­up-Sys­tem, das der MSP ver­wal­tet, ist nicht erreichbar. Zeit­punkt: 16:45 Uhr. In 15 Minu­ten beginnt ein Kun­den­ter­min mit einem Ihrer größ­ten Kun­den, bei dem auch Zugriff auf gemein­sam genutz­te Sys­tem­da­ten geplant ist. **Pha­se-A-Fra­gen (ers­te Reaktion):** 1. Wird der Kun­den­ter­min statt­fin­den? Wenn ja: Wie ver­hal­ten Sie sich, ohne die Situa­ti­on preiszugeben? 2. Wel­che Ver­bin­dun­gen zum MSP müs­sen sofort getrennt wer­den? Wer tut das, der MSP oder Ihre IT? 3. Wie beur­tei­len Sie die Ver­läss­lich­keit der Infor­ma­tio­nen, die der MSP Ihnen gibt? Hat er Inter­es­se dar­an, das Aus­maß kleinzureden? 4. Wel­che Sys­te­me betrei­ben Sie kom­plett eigen­stän­dig, ohne MSP-Beteiligung? **Pha­se-B-Fra­gen (Eska­la­ti­on):** 1. Der MSP hat Zugang zu Ihren Back­up-Sys­te­men gehabt. Wie ver­läss­lich sind Ihre Back­ups noch? 2. Haben Sie Audit-Logs, aus denen her­vor­geht, wel­che Aktio­nen der MSP in Ihrer Umge­bung durch­ge­führt hat? 3. Was sind Ihre ver­trag­li­chen Ansprü­che gegen­über dem MSP? Haben Sie Audit-Rechte? 4. Besteht eine DSGVO-Mel­de­pflicht? (Daten­über­tra­gung an exter­ne Adres­se, mög­li­cher­wei­se per­so­nen­be­zo­ge­ne Daten) 5. Infor­mie­ren Sie den Kun­den, der in 15 Minu­ten zum Ter­min erscheint? Was sagen Sie ihm? **Pha­se-C-Fra­gen (Wie­der­her­stel­lung):** 1. Kön­nen Sie die Sys­te­me ohne MSP-Unter­stüt­zung wie­der­her­stel­len? Haben Sie Zugang zu allen not­wen­di­gen Daten und Dokumentationen? 2. Wie tau­schen Sie den MSP mit­tel­fris­tig aus, und wel­che Abhän­gig­kei­ten müs­sen zuerst auf­ge­löst werden? 3. Was ändern Sie in der Lie­fe­ran­ten­be­wer­tung und im Supplier-Monitoring? #### Sze­na­rio 3: Insi­der-Thre­at, Sabo­ta­ge durch einen ehe­ma­li­gen Mit­ar­bei­ter [\#](#szenario-3-insider-threat-sabotage-durch-einen-ehemaligen-mitarbeiter "Szenario 3: Insider-Threat, Sabotage durch einen ehemaligen Mitarbeiter") **Schwie­rig­keits­grad:** Sehr hoch | **Emp­foh­len für:** Fort­ge­schrit­te­ne TTX, KRITIS-Betreiber **Sze­na­rio-Text:** Es ist Mon­tag, 09:00 Uhr. Dem IT-Team fällt auf, dass in der Nacht von Frei­tag auf Sams­tag meh­re­re Back­up-Jobs still abge­bro­chen wur­den, ohne Alar­mie­rung, weil das Moni­to­ring-Sys­tem gleich­zei­tig deak­ti­viert wur­de. Außer­dem feh­len drei Wochen Back­up-Gene­ra­tio­nen: Die Jobs wur­den als ​„erfolg­reich” pro­to­kol­liert, haben aber kei­ne Daten gespeichert. IT-Foren­sik ergibt: Ein Admi­nis­tra­tor­kon­to, das einem Mit­ar­bei­ter gehör­te, der das Unter­neh­men vor sechs Wochen ver­las­sen hat, hat die Mani­pu­la­ti­on durch­ge­führt. Das Kon­to wur­de nach dem Aus­schei­den nicht deaktiviert. Aktu­el­le Back­up-Situa­ti­on: Das letz­te vali­de Back­up ist fünf Wochen alt. Alle neue­ren Back­ups sind leer. **Pha­se-A-Fra­gen (ers­te Reaktion):** 1. Wel­cher Daten­ver­lust ist ein­ge­tre­ten? Wie bewer­ten Sie das Ausmaß? 2. War­um war das Kon­to sechs Wochen nach dem Aus­schei­den noch aktiv? Was sagt Ihr Off­boar­ding-Pro­zess dazu? 3. Wer außer dem ehe­ma­li­gen Mit­ar­bei­ter wuss­te von die­sem Konto? **Pha­se-B-Fra­gen (Eska­la­ti­on):** 1. Haben Sie eine DSGVO-Mel­de­pflicht? (Die Daten­in­te­gri­tät ist mög­li­cher­wei­se betroffen) 2. Liegt ein Straf­tat­be­stand vor? (§202a StGB: Aus­spä­hen von Daten; §303b StGB: Com­pu­ter­sa­bo­ta­ge) Wird Straf­an­zei­ge gestellt, und wann? 3. Wie kom­mu­ni­zie­ren Sie den Vor­fall intern, ohne Panik zu erzeugen? 4. Wel­che ande­ren inak­ti­ven Kon­ten exis­tie­ren mög­li­cher­wei­se in Ihrer Umge­bung? Haben Sie ein Inventar? **Pha­se-C-Fra­gen (Wie­der­her­stel­lung):** 1. Die letz­ten fünf Wochen Daten feh­len. Wel­che Daten kön­nen aus ande­ren Quel­len (Trans­ak­ti­ons­logs, E‑Mail-Anhän­ge, exter­ne Sys­te­me) rekon­stru­iert werden? 2. Haben Sie ein Air-Gap-Back­up, das die Mani­pu­la­ti­on nicht mit­ge­macht hat, weil es phy­sisch iso­liert war? 3. Was ändern Sie im Benut­zer-Off­boar­ding-Pro­zess? In der Backup-Überwachung? --- ### 5. Aus­wer­tungs­rah­men: Was nach dem TTX pas­siert [\#](#5-auswertungsrahmen-was-nach-dem-ttx-passiert "5. Auswertungsrahmen: Was nach dem TTX passiert") #### Sofort­pro­to­koll (noch am sel­ben Tag) [\#](#sofortprotokoll-noch-am-selben-tag "Sofortprotokoll (noch am selben Tag)") Pro­to­kol­lant fasst zusammen: - Wel­che Ent­schei­dun­gen wur­den ver­zö­gert oder gar nicht getroffen? - Wel­che Pro­zes­se funk­tio­nier­ten nicht wie erwartet? - Wel­che Doku­men­te fehl­ten oder waren nicht aktuell? - Wel­che Kon­tak­te waren nicht verfügbar? #### Maß­nah­men­lis­te (inner­halb einer Woche) [\#](#ma%C3%9Fnahmenliste-innerhalb-einer-woche "Maßnahmenliste (innerhalb einer Woche)") Für jeden iden­ti­fi­zier­ten Mangel: - Maß­nah­me (Was wird getan?) - Ver­ant­wort­li­cher (Wer ist zuständig?) - Frist (Bis wann?) - Über­prü­fung (Wie wird Umset­zung bestätigt?) #### Typi­sche Erkennt­nis­se aus Ran­som­wa­re-TTX-Übun­gen [\#](#typische-erkenntnisse-aus-ransomware-ttx-%C3%BCbungen "Typische Erkenntnisse aus Ransomware-TTX-Übungen") - **BSI-Mel­de­pflicht unbe­kannt oder unklar** (sehr häu­fig): Schu­lung + Check­lis­te im IR-Plan - **Ent­schei­dung über Löse­geld­zah­lung ohne kla­ren Pro­zess** (häu­fig): Ent­schei­dungs­baum vor­ab dokumentieren - **DR-Plan off­line nicht ver­füg­bar** (häu­fig): dru­cken und einschließen - **Kein Air-Gap-Back­up** (häu­fig): Air-Gap-Lay­er einführen - **Exter­ne IR-Fir­ma nicht vor­ab beauf­tragt** (gele­gent­lich): Rah­men­ver­trag mit IR-Dienstleister - **Kun­den­kom­mu­ni­ka­ti­on ohne abge­stimm­ten Text** (gele­gent­lich): Kom­mu­ni­ka­ti­ons­vor­la­gen vorbereiten - **Off­boar­ding-Pro­zess lücken­haft** (häu­fig, sie­he Sze­na­rio 3): Off­boar­ding-Check­lis­te mit IT-Schritt --- ### Wei­ter­füh­ren­de Res­sour­cen [\#](#weiterf%C3%BChrende-ressourcen "Weiterführende Ressourcen") → IT-Resi­li­enz: Leit­fa­den für wider­stands­fä­hi­ge IT (/de/­b­log/it-resi­li­enz-leit­fa­den/) → Von Stu­fe 2 auf Stu­fe 4: Der effi­zi­en­tes­te Weg zur Resi­li­enz (/de/­b­log/­von-stu­fe-2-auf-stu­fe-4-resi­li­en­z/) → Audit-Vor­be­rei­tung NIS2: Check­lis­te für IT-Lei­ter (/de/­b­log/au­dit-vor­be­rei­tung-nis2-check­lis­te/) → Inci­dent Respon­se Plan erstel­len: Vor­la­ge und Anlei­tung (/de/­b­log/in­ci­dent-respon­se-plan-vor­la­ge/) → Air Gap als Resi­li­enz-Lay­er: War­um Tier 2 über alles ent­schei­det (/de/­b­log/air-gap-resi­li­enz-lay­er/) ### KRITIS KRITIS bezeichnet Organisationen und Einrichtungen, deren Ausfall oder Beeinträchtigung zu erheblichen Versorgungsengpässen oder Gefährdungen der öffentlichen Sicherheit führen würde — KRITIS-Betreiber unterliegen nach §8a BSI-Gesetz verschärften Anforderungen an IT-Sicherheit und müssen diese alle zwei Jahre gegenüber dem BSI nachweisen. [Mehr erfahren →](https://www.fast-lta.de//de/glossar/kritis) ### KRITIS KRITIS bezeichnet Organisationen und Einrichtungen, deren Ausfall oder Beeinträchtigung zu erheblichen Versorgungsengpässen oder Gefährdungen der öffentlichen Sicherheit führen würde — KRITIS-Betreiber unterliegen nach §8a BSI-Gesetz verschärften Anforderungen an IT-Sicherheit und müssen diese alle zwei Jahre gegenüber dem BSI nachweisen. [Mehr erfahren →](https://www.fast-lta.de//de/glossar/kritis) ### Air Gap Ein Air Gap ist die physische Unterbrechung jeder Netzwerkverbindung zwischen einem Backup-System und der übrigen IT-Infrastruktur, sodass das System im Offline-Zustand keine adressierbare Netzwerkschnittstelle besitzt und damit für Ransomware und Angreifer unerreichbar ist. [Mehr erfahren →](https://www.fast-lta.de//de/glossar/air-gap) ### DSGVO Die DSGVO (Datenschutz-Grundverordnung, EU 2016/679) ist die europäische Regulierung zum Schutz personenbezogener Daten — für IT-Infrastruktur besonders relevant in Art. 5 (Grundsätze), Art. 17 (Recht auf Löschung), Art. 28 (Auftragsverarbeiter) und Art. 32 (Sicherheit der Verarbeitung). [Mehr erfahren →](https://www.fast-lta.de//de/glossar/dsgvo) ### DSGVO Die DSGVO (Datenschutz-Grundverordnung, EU 2016/679) ist die europäische Regulierung zum Schutz personenbezogener Daten — für IT-Infrastruktur besonders relevant in Art. 5 (Grundsätze), Art. 17 (Recht auf Löschung), Art. 28 (Auftragsverarbeiter) und Art. 32 (Sicherheit der Verarbeitung). [Mehr erfahren →](https://www.fast-lta.de//de/glossar/dsgvo) ### DSGVO Die DSGVO (Datenschutz-Grundverordnung, EU 2016/679) ist die europäische Regulierung zum Schutz personenbezogener Daten — für IT-Infrastruktur besonders relevant in Art. 5 (Grundsätze), Art. 17 (Recht auf Löschung), Art. 28 (Auftragsverarbeiter) und Art. 32 (Sicherheit der Verarbeitung). [Mehr erfahren →](https://www.fast-lta.de//de/glossar/dsgvo) ### Disaster Recovery Disaster Recovery bezeichnet die strukturierten Prozesse und technischen Maßnahmen, die sicherstellen, dass IT-Systeme nach einem schwerwiegenden Ausfall — Ransomware-Angriff, Hardwareversagen, Rechenzentrumsausfall — innerhalb definierter Zeitrahmen (RTO) mit maximalem Datenverlust (RPO) wiederhergestellt werden können. [Mehr erfahren →](https://www.fast-lta.de//de/glossar/disaster-recovery)