Third-Party-Risk-Management (TPRM) galt lange als Pflichtfach: Fragebogen verschicken, Zertifikate einsammeln, Auditberichte abheften – fertig. Spätestens mit dem Digital Operational Resilience Act (DORA) ist dieses Verständnis Geschichte. TPRM wird vom statischen Kontrollpunkt zum dynamischen Kern der digitalen Widerstandsfähigkeit. Nicht mehr das „Ob“ einer Maßnahme zählt, sondern das „Hält es im Ernstfall?“. Governance rückt damit näher an den operativen Puls; Lieferantenbeziehungen werden zu gemeinsam verantworteten Resilienz-Systemen – gemessen, getestet, nachweisbar.

Dieser Beitrag zeigt, wie sich TPRM unter DORA grundlegend verschiebt: weg von Dokumentation, hin zu belastbarer Operations-Resilienz. Er ordnet die neuen Erwartungen, skizziert ein modernes Operating Model, gibt konkrete Leitplanken für Verträge, Technik und Monitoring – und benennt Anti-Patterns, die heute noch zu häufig zu sehen sind.

Für viele Unternehmen ist das Wort „Audit“ immer noch ein Synonym für Stress, lange To-do-Listen und schlaflose Nächte. Das gilt umso mehr, wenn es um neue regulatorische Anforderungen wie DORA geht. Schließlich verlangt die EU-Verordnung nicht nur, dass Unternehmen ihre digitale Resilienz aufbauen und pflegen – sie müssen auch jederzeit nachweisen können, dass sie dies tatsächlich tun. Audits sind das zentrale Instrument, mit dem Aufsichtsbehörden überprüfen, ob Prozesse, Systeme und organisatorische Strukturen den Vorgaben entsprechen. Wer hier unvorbereitet auftritt, riskiert nicht nur negative Feststellungen, sondern auch Bußgelder, Reputationsschäden und im schlimmsten Fall Einschränkungen im Geschäftsbetrieb. Dabei kann ein DORA-Audit deutlich entspannter verlaufen, wenn Unternehmen frühzeitig die richtigen Strukturen schaffen und Auditfähigkeit als Dauerzustand begreifen, nicht als kurzfristige Projektaufgabe.

Was DORA wirklich prüft: Mehr als Technik

Der wichtigste Schritt zu einem souveränen Audit ist das Verständnis, was DORA überhaupt nachprüft. Die Verordnung deckt ein breites Spektrum ab: vom IKT-Risikomanagement über Incident Reporting und Resilienztests bis hin zum Management von Drittparteien und dem Informationsaustausch im Sektor. Das bedeutet: Audits verlangen technische und organisatorische, vertragliche und strategische Nachweise. Ein Penetrationstest-Bericht mag zeigen, dass ein System hart ist – wenn der dazugehörige Prozess für Schwachstellenmanagement nicht dokumentiert oder nicht gelebt ist, bleibt eine Lücke. Ebenso sehen Auditoren Inkonsistenzen sofort: Was im Risikoregister steht, muss mit Testberichten, Vorfall-Eskalationswegen und Lieferantenverträgen zusammenpassen.

C5 hat sich leise, aber stetig vom Katalog für Cloud-Kontrollen zur Referenz für gelebte Cloud-Governance entwickelt. 2025 markiert den Punkt, an dem diese Entwicklung sichtbar wird: Nicht mehr die Frage „Welche Kriterien erfüllt der Provider?“ dominiert, sondern „Wie steuern wir als Unternehmen – nachweisbar, zeitkritisch und wiederholbar – unsere Cloud-Realität?“ Wer C5 noch als Attest versteht, verschenkt Wirkung. Wer C5 als Betriebssprache, als Schalterset und als Evidenzfundament begreift, gewinnt Tempo, Resilienz und Vertrauen. Dieser Beitrag zeichnet nach, wie C5 2025 zur Benchmark wird: in Architektur und Betrieb, in Audits und Aufsicht, in Lieferketten und Verträgen, in Daten- und KI-Domänen – und wie sich die Kultur ändert, wenn Prüfung kein Ereignis mehr ist, sondern Nebenprodukt guter Arbeit.

Warum 2025 anders ist

Cloud-Nutzung ist erwachsen geworden. Unternehmen betreiben Portfolios, nicht Einzelprojekte. Kritische Geschäftsprozesse sind in Plattformen, Automatisierung und Datenströmen verankert. Regulatorik hat den Takt erhöht: Resilienz wird in Zeiten gemessen, nicht in Reifegradfarben. Meldepflichten verlangen Belege in Stunden, nicht in Wochen. Kunden verlangen Nachweise, die die Wirklichkeit abbilden – nicht Präsentationen. In diesem Umfeld reicht es nicht, einen C5-Bericht abzuheften. Er muss anschließen: an Pipelines, an Plattformen, an Notfallpläne, an Verträge, an Kennzahlensysteme. 2025 ist das Jahr, in dem C5 dort ankommt – und dadurch vom Prüfkatalog zur Benchmark wird.

Das IT-Grundschutz-Kompendium des Bundesamts für Sicherheit in der Informationstechnik (BSI) ist so etwas wie die „Enzyklopädie“ der deutschen Informationssicherheit – und trotzdem kennen viele Unternehmen es nur vom Hörensagen oder sehen es als schwerfälligen Behördenwälzer, den man allenfalls für Audits hervorholt. In Wahrheit ist dieses Werk eine der wertvollsten und praxisnahsten Ressourcen, die es im Bereich Cyber- und Informationssicherheit gibt. Wer es versteht und richtig einsetzt, hat nicht nur ein umfassendes Nachschlagewerk, sondern auch einen methodischen Baukasten, mit dem sich fast jede Sicherheitsanforderung strukturiert und nachvollziehbar umsetzen lässt. Gerade in Zeiten von NIS2, DORA, KRITIS-Regelungen oder branchenspezifischen Sicherheitskatalogen liefert der IT-Grundschutz einen roten Faden: Was muss ich organisieren? Welche Maßnahmen sind Stand der Technik? Wie belege ich wirksam, dass wir es tun?

Bausteinlogik statt Bleiwüste: Wie das Kompendium aufgebaut ist

Das Besondere am IT-Grundschutz-Kompendium ist seine Bausteinlogik. Es ist nicht als reines Lehrbuch geschrieben, sondern als Sammlung modularer Sicherheitsbausteine, die je nach Bedarf zusammengesetzt werden können. Jeder Baustein steht für einen klar umrissenen Bereich – das kann ein technisches Thema sein wie „Server“, „Datenbanken“, „Netzkomponenten“ oder „Virtualisierung“, ein organisatorischer Prozess wie „Patch- und Änderungsmanagement“, „Lieferantenmanagement“ und „Incident-Management“, eine physische Komponente wie „Serverraum“ oder „Rechenzentrum“ oder Querschnittthemen wie „Cloud-Nutzung“, „Mobile Arbeit“ und „Kryptokonzept“.

Resilienz ist kein Zufallsprodukt. Sie entsteht nicht allein durch technische Schutzmaßnahmen oder durch das Verfassen von Notfallplänen. Wirkliche Widerstandsfähigkeit zeigt sich erst im Ernstfall – und dafür müssen Unternehmen vorbereitet sein. DORA macht deshalb unmissverständlich klar: Digitale Resilienz ist nicht nur zu planen, sondern regelmäßig und systematisch zu testen. Der Grundgedanke ist einfach: Ein Unternehmen kann nur dann sicherstellen, dass es auf IKT-Störungen, Cyberangriffe oder sonstige digitale Notlagen wirksam reagiert, wenn es diese Szenarien vorher geübt hat. Dabei geht es nicht um symbolische Trockenübungen, sondern um realistische, teilweise sehr anspruchsvolle Tests, die technische Systeme, organisatorische Abläufe und menschliches Handeln gleichermaßen prüfen.

Kritische Funktionen kennen: Ohne Zielbild keine sinnvollen Übungen

Die Grundlage solcher Resilienztests ist eine klare Definition der kritischen Funktionen und Prozesse. Nur wenn bekannt ist, welche Systeme, Daten, Anwendungen und Kommunikationswege für den Geschäftsbetrieb unverzichtbar sind, lassen sich sinnvolle Übungsszenarien entwickeln. DORA verlangt, dass Unternehmen ihre kritischen Assets genau kennen und für diese gezielt Testpläne entwickeln. Das muss nicht immer die gesamte Organisation betreffen – oft sind fokussierte Tests auf einzelne, hochkritische Prozesse effektiver. Entscheidend ist, dass die Auswahl der Tests risikobasiert erfolgt: Je kritischer eine Funktion, desto intensiver und häufiger wird getestet. Dazu gehört auch eine Business-Impact-Analyse (BIA) mit RTO/RPO-Zielen sowie Schutzbedarfen entlang von Vertraulichkeit, Integrität und Verfügbarkeit – ergänzt um Resilienz, Nachvollziehbarkeit und Portabilität.