Resilienz ist im Alltag oft sichtbar, lange bevor sie dokumentiert ist. Teams reagieren auf Störungen, stabilisieren Systeme, klären Ursachen, steuern Dienstleister, passen Abläufe an. Operativ passiert viel. Und trotzdem kommt in Revisionen oder Prüfungen sehr häufig dieselbe Rückfrage: „Können Sie mir das bitte nachvollziehbar zeigen?“ Nicht, weil niemand glaubt, dass gearbeitet wurde. Sondern weil die Spur fehlt, die Entscheidung, Umsetzung und Ergebnis als Paket zusammenhält.

Genau hier liegt der Kern von Resilienz-Evidenz. Belege sind selten „nicht vorhanden“. Sie sind nur verteilt: Tickets, Chatverläufe, E-Mails, Logs, Monitoring-Dashboards, Meeting-Notizen, Provider-Statusmeldungen, Change-Freigaben, Testprotokolle, Maßnahmenlisten. Im Alltag reicht das oft, weil die Beteiligten den Kontext kennen. Revision darf Kontext nicht erraten. Revision muss aus Dokumenten und Artefakten nachvollziehen können, was passiert ist, warum es passiert ist, wer entschieden hat und was daraus folgte. Und sie muss das ohne Expedition durch fünf Systeme können.

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“.

GRC-Automation klingt nach einer naheliegenden Lösung: Anforderungen wachsen, Nachweise steigen, Audits werden häufiger – also automatisieren wir eben. Workflows, Tickets, Freigaben, automatische Erinnerungen, Dashboards. Viele Organisationen starten genau so. Und viele stellen nach ein paar Monaten fest, dass zwar „mehr System“ da ist, aber nicht unbedingt mehr Steuerung. Manchmal sogar weniger. Das liegt nicht daran, dass Automation grundsätzlich schlecht wäre. Es liegt daran, dass Workflows nur dann helfen, wenn sie eine saubere Betriebslogik unterstützen. Wenn sie dagegen unklare Prozesse, diffuse Verantwortlichkeiten oder schlechte Evidenzlogik einfach nur digitalisieren, entsteht Tool-Chaos: mehr Klicks, mehr Status, mehr Listen – und trotzdem Unsicherheit, wenn es wirklich zählt.

Der Unterschied zwischen „hilfreicher Automation“ und „Tool-Chaos“ ist selten eine Toolfrage. Er ist eine Designfrage. Automatisierung ist wie Beton: Sie macht das, was schon da ist, stabiler – in gut wie in schlecht. Wenn Ihr GRC-Betrieb klare Decision Points hat, klare Owners, klare Nachweisartefakte und einen sinnvollen Takt, dann kann Automation diese Logik verstärken. Wenn Ihr Betrieb aber auf Zuruf funktioniert, wenn Entscheidungen informell getroffen werden oder wenn Evidenz nachträglich zusammengesucht wird, dann verstärkt Automation genau diese Schwächen. Dann wird aus „Wir automatisieren“ schnell „Wir pflegen ein System, das niemandem hilft“.