Luebeck, Anfang Mai 2026 - ein Anruf aus dem Werkstattbuero

Es ist Freitag, der 8. Mai 2026, kurz nach zehn Uhr vormittags. Im zweiten Stock eines unscheinbaren Klinkergebaeudes im Luebecker Gewerbegebiet sitzt Reiner Bredow, Geschaeftsfuehrer der Luebecker Sensortechnik Bredow GmbH, an seinem Schreibtisch und liest zum dritten Mal denselben Absatz einer E-Mail seines IT-Dienstleisters. Es geht um den Cyber Resilience Act, jene Verordnung, von der er vor sechs Monaten zum ersten Mal gehoert hat, im Zuge eines Verbandstreffens des VDMA, und die er seither in eine Schublade gelegt hatte: Das gilt fuer uns eigentlich nicht, wir machen ja Hardware.

Die Luebecker Sensortechnik Bredow GmbH ist ein klassischer Fall des deutschen Mittelstands. 78 Mitarbeitende, davon 14 in der Entwicklung, 23 in der Fertigung, der Rest in Vertrieb, Verwaltung und Service. Das Unternehmen produziert seit 1987 induktive und kapazitive Sensoren fuer die industrielle Automatisierung - kleine, robuste Bauteile, die in Werkzeugmaschinen, Foerderbaendern und Roboterzellen verbaut werden. In den letzten zehn Jahren hat Bredow seine Produkte sukzessive vernetzungsfaehig gemacht: IO-Link-Schnittstellen, Firmware mit OPC-UA-Stack, eine eigene Cloud-Plattform fuer Predictive Maintenance, ein optionales OTA-Update-Modul, das die Sensoren ueber LTE-M aktualisierbar macht.

Diese Vernetzung war Bredows Antwort auf den Preisdruck aus Asien. Sie ist auch der Grund, weshalb seit dem 11. Dezember 2024 ein 138-seitiges EU-Dokument den Tagesablauf der Luebecker Firma neu sortieren wird. Denn die Verordnung (EU) 2024/2847, der Cyber Resilience Act, kennt keine Toleranz dafuer, ob ein Unternehmen sich selbst als Hardware-Hersteller versteht. Wenn ein Produkt mit digitalen Elementen in Verkehr gebracht wird, und ein IO-Link-Sensor mit Firmware ist genau das, faellt es unter die Verordnung.

Der Anruf aus dem Werkstattbuero, der Bredow an diesem Freitag erreicht, hat einen sehr konkreten Anlass. Der IT-Dienstleister, ein lokaler Systemhauspartner, hat die Geschaeftsfuehrung daran erinnert, dass am 11. September 2026 der erste verbindliche Compliance-Stichtag der Verordnung wirksam wird: die Meldepflicht fuer aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfaelle. 24 Stunden Early Warning, 72 Stunden Vollmeldung, 14 Tage Abschlussbericht, an die ENISA, an das nationale CSIRT, ueber eine zentrale Plattform, die zu diesem Zeitpunkt funktionsfaehig sein muss. Heute, am 26. Mai 2026, sind das nur noch 108 Tage.

Was die Verordnung wirklich verlangt - und was sie nicht verlangt

Bevor wir Bredow durch die naechsten Wochen begleiten, lohnt sich ein nuechterner Blick auf den regulatorischen Rahmen. Der Cyber Resilience Act ist keine NIS2 und keine DORA. Er reguliert nicht primaer den Betrieb von IT-Infrastruktur, sondern das Inverkehrbringen von Produkten mit digitalen Elementen, also Software, vernetzte Hardware, Firmware, Cloud-Komponenten, die Bestandteil eines Produkts sind. Damit zielt die Verordnung genau auf jene Schicht des Mittelstands, die sich bisher hinter der Aussage wir machen ja keine Software der Cyber-Compliance entzogen hat: Maschinenbauer, Sensorhersteller, Steuerungstechnik, Medizinprodukte, Sicherheitstechnik, Spielzeuge mit Bluetooth, smarte Haushaltsgeraete.

Die zentralen Pflichten unterscheiden sich nach Zeithorizont. Ab dem 11. September 2026 gilt die Meldepflicht. Ab dem 11. Dezember 2027 gelten die vollen technischen Anforderungen - Security by Design, Schwachstellenmanagement ueber den gesamten Lebenszyklus von mindestens fuenf Jahren, sichere Default-Konfigurationen, Konformitaetsbewertung, CE-Markierung. Wer ab Dezember 2027 ein nicht-konformes Produkt in den EU-Markt bringt, riskiert Bussgelder bis 15 Millionen Euro oder 2,5 Prozent des globalen Jahresumsatzes.

Die Meldepflicht im September ist der Probelauf. Sie verlangt drei Schritte. Erstens den Early Warning: Innerhalb von 24 Stunden nach Kenntnisnahme einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Sicherheitsvorfalls muss der Hersteller die ENISA und das zustaendige CSIRT informieren. Kenntnisnahme beginnt nicht erst mit der Bestaetigung, sondern mit dem ersten begruendeten Verdacht. Zweitens, innerhalb von 72 Stunden, eine Vollmeldung mit technischen Details, Bewertung der Auswirkungen und ersten Mitigationsmassnahmen. Drittens, spaetestens 14 Tage nach Verfuegbarkeit einer Korrekturmassnahme, ein Abschlussbericht.

Die Meldungen laufen ueber die Single Reporting Platform (SRP), eine zentrale ENISA-Plattform, die zum 11. September 2026 in Betrieb gehen wird. Eine Testphase ist vorgesehen. Hersteller, die heute nicht wissen, welche ihrer Produkte unter den CRA fallen, werden den 11. September nicht ueberleben, nicht im Sinne einer Marktverbannung, sondern im Sinne einer Behoerden-Aufmerksamkeit, die nicht mehr verschwindet.

Der erste Schritt: Inventur, was Bredow eigentlich verkauft

Reiner Bredow ruft am Montag, dem 11. Mai 2026, eine Krisensitzung ein. Anwesend sind sein technischer Leiter Dr. Henning Voss, die Entwicklungsleiterin Sabine Mertens, der fuer IT zustaendige Kaufmaennische Leiter Markus Petersen und, auf Vorschlag des IT-Dienstleisters, ein externer Berater der pleXtec, den Petersen aus einer frueheren Zusammenarbeit kennt. Auf dem Tisch liegt eine erste Frage, die simpler scheint, als sie ist: Welche Produkte verkaufen wir eigentlich, und welche davon fallen unter den CRA?

Bredow zaehlt aus dem Kopf zwoelf Hauptprodukte auf. Voss korrigiert auf 47, weil jede Variante mit unterschiedlicher Anschlussspannung als eigene Bestellnummer gefuehrt wird. Die ERP-Auswertung am Nachmittag ergibt 213 aktive Artikelnummern. Wenn man Auslaufmodelle einschliesst, die noch im Service unterstuetzt werden: 487. Und die Antwort auf die Frage enthaelt das Produkt Software oder vernetzbare Bestandteile? ist bei zwoelf von 213 Hauptartikeln ein zweifelsfreies Ja, bei 86 ein Vielleicht (etwa weil ein optionales Funkmodul nachruestbar ist), bei 115 ein Nein.

Es ist diese erste Inventur, die in vielen Mittelstandsunternehmen scheitert. Nicht, weil sie schwer ist, sondern weil sie an organisatorischen Bruchlinien entlanglaeuft: zwischen Produktmanagement, Entwicklung und Vertrieb. Bredow lernt an diesem Nachmittag, dass die Entwicklungsabteilung seit 2019 eine andere Liste vernetzungsfaehiger Produkte fuehrt als das Marketing. Und dass es eine dritte Liste gibt, die in der Service-Abteilung als Geraete mit Update-Funktion gefuehrt wird und die wieder anders aussieht.

Der pleXtec-Berater schlaegt vor, eine einheitliche Produkt-Cybersecurity-Klassifikation einzufuehren. Drei Stufen: nicht im CRA-Geltungsbereich, im Geltungsbereich mit Standardkategorie, im Geltungsbereich mit kritischer oder wichtiger Klassifikation. Letztere unterliegen schaerferen Konformitaetsbewertungen mit notifizierten Stellen. Fuer Bredow ergibt sich nach drei Tagen Arbeit folgende Verteilung: 14 Hauptprodukte fallen unter den CRA-Standard, drei davon (die Funkmodule mit Sicherheitsfunktion in der Maschinenueberwachung) potenziell als wichtig gemaess Anhang III. Letzteres muss bis Q3 2026 endgueltig geklaert werden, wahrscheinlich mit einem Rechtsgutachten.

Der zweite Schritt: PSIRT - die Stabsstelle, die es noch nicht gibt

Damit eine 24-Stunden-Meldepflicht ueberhaupt funktioniert, braucht es eine organisatorische Struktur, die Schwachstellenmeldungen empfaengt, bewertet, triagiert, eskaliert. Im Konzernumfeld nennt man das Product Security Incident Response Team, kurz PSIRT. Im Mittelstand ist das ein neuer Begriff. Bredow hat keine PSIRT-Funktion. Die meisten seiner Wettbewerber auch nicht.

Was Bredow stattdessen hat: einen Service-Postkasten, an den Kunden gelegentlich Bug-Reports schicken. Eine Entwicklungsabteilung, die Bug-Reports nach Severity sortiert, aber Cybersecurity-Schwachstellen nicht systematisch von funktionalen Fehlern trennt. Einen Geschaeftsfuehrer, der vom Service-Team in der Regel nachtraeglich erfaehrt, wenn etwas Groesseres im Feld passiert ist.

Die pleXtec-Beraterin entwirft ein zweistufiges PSIRT-Modell, das zur Groesse der Bredow GmbH passt. Stufe eins: ein dreikoepfiges PSIRT-Kernteam, bestehend aus Dr. Voss (technische Leitung), Sabine Mertens (Entwicklung) und Markus Petersen (Compliance und externe Kommunikation). Diese drei sind fuer die ersten 24 Stunden jeder Meldung zustaendig. Stufe zwei: ein erweiterter Eskalationskreis, der bei kritischer Bewertung hinzugezogen wird: Geschaeftsfuehrung, Rechtsabteilung (extern), Vertriebsleitung. Eine 24/7-Erreichbarkeit fuer externe Schwachstellenmeldungen wird ueber eine dedizierte E-Mail-Adresse (security@bredow.de) und eine Telefonnummer am Service-Notdienst implementiert.

Es klingt nach wenig, ist aber fuer einen 78-Personen-Betrieb erheblich. Die Frage, die im Hintergrund mitschwingt: Was kostet das, und wer traegt die Last? Bredows Antwort, die er an diesem Punkt klar formuliert: Wenn wir nicht in zwei Jahren als unverkaeuflich gelten wollen, ist das keine optionale Investition. Die Stundenzahl, die das Team in der Aufbauphase aufwendet, wird auf 0,5 FTE ueber sechs Monate geschaetzt. Im Steady-State danach: 0,2 FTE.

Der dritte Schritt: SBOM, VEX und die Frage, was eigentlich drin ist

Eine Meldepflicht fuer Schwachstellen funktioniert nur, wenn der Hersteller weiss, welche Software in seinen Produkten steckt. Klingt banal. Ist es nicht. Die Bredow-Sensoren laufen mit Firmware, die auf einem ARM-Cortex-M4 laeuft. Die Firmware enthaelt eine FreeRTOS-Variante, eine TLS-Bibliothek (mbedTLS), einen OPC-UA-Stack vom Lizenzpartner Beckhoff, einen IO-Link-Stack vom Hersteller TMG, und etwa 14.000 Zeilen eigener C-Code, der ueber die Jahre von vier verschiedenen Entwicklern geschrieben wurde, von denen heute noch zwei im Unternehmen sind.

Eine maschinenlesbare Stueckliste, die Software Bill of Materials, SBOM, existiert nicht. Bredow weiss nicht, in welcher Version mbedTLS in welchem Firmware-Release verbaut ist. Wenn morgen eine kritische Schwachstelle in mbedTLS bekannt wird, kann das Unternehmen heute nicht in unter einer Woche beantworten, welche seiner Produkte betroffen sind, in welchen Kundenanlagen sie installiert sind und wie sie aktualisierbar sind.

Die pleXtec-Beraterin sieht darin die groesste operative Luecke. Sie schlaegt eine dreistufige Roadmap vor. Erstens: fuer alle Firmware-Releases ab dem 1. Juli 2026 wird im CI/CD-Prozess automatisch eine SBOM im CycloneDX-Format erzeugt. Tooling: das Open-Source-Werkzeug syft in Kombination mit einem fuer Bredow individualisierten Parser fuer die proprietaeren Stacks. Zweitens: fuer die bestehenden 14 CRA-relevanten Produktfamilien wird rueckwirkend eine SBOM pro aktiver Firmware-Version erstellt. Drittens: ergaenzend zur SBOM wird ein VEX-Dokument (Vulnerability Exploitability eXchange) eingefuehrt, das pro Schwachstelle dokumentiert, ob das Produkt betroffen, nicht betroffen oder mitigiert ist.

Sabine Mertens ist die Erste, die den praktischen Wert versteht. Wenn wir am 11. September einen ENISA-Bericht abgeben muessen, dann ist die Frage nicht: Hat unser Produkt eine Schwachstelle? Die Frage ist: Welche unserer Produkte hat welche Schwachstelle, und was bedeutet das? Genau das beantwortet die Kombination aus SBOM und VEX in unter einer Stunde, wenn sie existiert. Heute existiert sie nicht.

Der vierte Schritt: Coordinated Vulnerability Disclosure

Die Meldepflicht greift nicht nur, wenn Bredow selbst eine Schwachstelle entdeckt. Sie greift auch, und vor allem, wenn ein Externer eine meldet. Hier muss der Hersteller einen klar dokumentierten Coordinated Vulnerability Disclosure-Prozess (CVD) etablieren: Wie koennen Sicherheitsforscher, Kunden oder andere Dritte Schwachstellen melden? Wie schnell antwortet das Unternehmen? Wann wird der Melder informiert? Wann wird die Schwachstelle oeffentlich gemacht?

Die ISO/IEC 29147 und der etablierte Standard von disclose.io geben dafuer einen Rahmen vor. Bredow entscheidet sich fuer eine angepasste Variante. Auf der Unternehmens-Website wird eine /.well-known/security.txt-Datei eingefuehrt, die folgende Felder enthaelt: Contact (mailto:security@bredow.de und eine Telefonnummer), Encryption (PGP-Schluessel-URL), Acknowledgments (eine Hall of Fame fuer Melder), Policy (die vollstaendige CVD-Policy), Preferred-Languages (de, en) und Canonical (die definitive URL der Datei).

Die CVD-Policy beschreibt die Spielregeln: Bredow bestaetigt jede eingehende Meldung innerhalb von 5 Werktagen, gibt nach 30 Tagen eine erste Bewertung, koordiniert die Veroeffentlichung mit dem Melder, gewaehrt keine Bug-Bounties, aber listet (auf Wunsch) den Melder in einer oeffentlichen Anerkennung. Vor allem: Bredow verzichtet auf rechtliche Schritte gegen Forscher, die sich an die Policy halten, eine Klausel, die nicht trivial ist und durch den externen Rechtsbeistand abgestimmt wird.

Der fuenfte Schritt: die Probe - ein fiktives Szenario

Anfang August 2026, sechs Wochen vor dem Stichtag, simuliert das PSIRT-Team unter Leitung der pleXtec-Beraterin einen Ernstfall. Das Szenario: Ein deutscher Sicherheitsforscher entdeckt in einem Bredow-Sensor des Typs BSI-3200 eine Pufferueberlauf-Schwachstelle in der OPC-UA-Implementierung. Er meldet sie am Freitag, 7. August, um 14:32 Uhr via security@bredow.de mit PGP-verschluesselter E-Mail. Der Forscher hat einen PoC, der eine Sensor-Reboot-Schleife ausloest. CVSS-Schaetzung des Forschers: 7.5.

Die Stoppuhr laeuft. PSIRT-Team-Mitglied Petersen sieht die E-Mail um 14:48 und bestaetigt um 14:53 den Empfang. Voss uebernimmt die technische Bewertung. Um 16:20 ist klar: Die Schwachstelle ist reproduzierbar, sie betrifft Firmware-Versionen 3.2.0 bis 3.4.2 des BSI-3200 sowie potenziell die Schwesterprodukte BSI-3210 und BSI-3300. Insgesamt rund 4.700 ausgelieferte Geraete sind im Feld.

Die naechste Frage: Ist die Schwachstelle aktiv ausgenutzt? Ohne Anzeichen dafuer entfaellt die 24-Stunden-Frist, stattdessen greift die normale Veroeffentlichungs- und Patch-Frist. Voss prueft Telemetrie-Daten aus der Cloud-Plattform und findet keine Hinweise. Das PSIRT entscheidet: kein ENISA-Early-Warning, aber ein internes Ticket mit Patch-Frist von 30 Tagen. Sabine Mertens beginnt am Montag, die Firmware-Korrektur einzubauen. Das CVE-Reservierungsverfahren wird ueber die CNA-Funktion eines deutschen Cybersecurity-Dienstleisters angestossen.

Der Probelauf zeigt: Das PSIRT funktioniert. Aber er zeigt auch Luecken. Die Telemetrie-Auswertung dauerte 90 Minuten - im Ernstfall mit echter Ausnutzung waere das zu lang. Bredow investiert in ein verbessertes Monitoring-Dashboard. Der PGP-Empfang ueber security@bredow.de funktionierte, aber zwei externe Mitarbeiter hatten keinen Zugriff auf den Schluessel - das wird strukturell repariert. Und eine dritte Erkenntnis: Die Vertriebsleitung war nicht im Bilde, dass eine Probe lief. Im echten Krisenfall mit Kundeninformation muss die Linie sauberer abgestimmt sein.

Was die Geschichte ueber den Mittelstand verraet

Die Bredow-Geschichte ist fiktiv im Detail, aber im Wesentlichen wahr. Sie wiederholt sich in Variation in hunderten von mittelstaendischen Industriebetrieben, die in den naechsten 108 Tagen eine Compliance-Huerde nehmen muessen, von der sie vor zwoelf Monaten nicht wussten, dass sie fuer sie gilt. Drei strukturelle Erkenntnisse lassen sich aus dem Verlauf ableiten.

Erstens: Der CRA ist kein IT-Thema, sondern ein Produkt-Thema. Wer die Verordnung an die IT-Abteilung delegiert, hat den Rahmen missverstanden. Die zentrale Frage ist: Welche Produkte fallen unter die Verordnung? Welche Software steckt drin? Wie altert sie ueber fuenf Jahre? Diese Fragen beantwortet die IT nicht, sie beantwortet die Produktentwicklung, der Einkauf, das Produktmanagement. CRA ist eine organisatorische Herausforderung an der Schnittstelle zwischen Entwicklung, Service und Compliance.

Zweitens: Transparenz ist die unbequeme Vorbedingung. Wer keine SBOM hat, kann keine CRA-Compliance darstellen. Wer keine VEX-Antworten geben kann, hat in einer aktiven Schwachstellenwelle 24 Stunden Reaktionszeit und keine Datenbasis. Die Investition in Transparenz, in eine maschinenlesbare Erfassung dessen, was im Produkt steckt, ist die Investition, die im September 2026 ueber Handlungsfaehigkeit entscheidet.

Drittens: Geschwindigkeit haengt an Strukturen, nicht an Heroismus. Ein 24-Stunden-SLA fuer Schwachstellenmeldungen ist nur dann einhaltbar, wenn die Eskalationswege, die Kontaktdaten, die Telemetrie-Auswertung, die SBOM-Lookups und der Meldeweg an ENISA vor dem Ereignis existieren. Wer am 11. September 2026 in der Krise improvisiert, wird die Frist nicht halten. Wer im Mai 2026 die Strukturen aufbaut, wird sie halten.

Breitere Einordnung: Was kommt nach der Meldepflicht

Der 11. September 2026 ist nicht das Ende, sondern der Anfang. Ab Dezember 2027 greifen die vollen technischen Anforderungen des CRA: Security by Design ueber den gesamten Lebenszyklus, sichere Default-Konfigurationen, Schwachstellenmanagement fuer mindestens fuenf Jahre nach Verkauf eines Produkts, dokumentierte Risikobewertungen, CE-Markierung mit Konformitaetsbewertung. Wer am 11. Dezember 2027 nicht konform ist, darf das Produkt in der EU nicht mehr in Verkehr bringen.

Die Verzahnung mit anderen Regulierungswellen macht das Bild komplexer. NIS2 reguliert die Betreiber kritischer Infrastruktur und verlangt von ihnen, Lieferanten zu pruefen. Wer als CRA-konformer Hersteller liefert, hat einen Marktvorteil. DORA betrifft den Finanzsektor und seine ICT-Lieferanten, mit teilweise denselben Schwachstellenmelde-Anforderungen. Der EU AI Act, dessen Hochrisiko-Pflichten zuletzt durch den AI-Omnibus-Deal vom 13. Mai 2026 nach hinten verschoben wurden (siehe unser Wissen-Artikel zur Omnibus-Verschiebung), kommt fuer KI-Komponenten in Produkten hinzu. Wer alle vier Verordnungen parallel managen will, braucht eine integrierte Compliance-Architektur, nicht vier parallele Silos.

Die Bredow GmbH hat in den letzten drei Wochen begonnen, diese Architektur aufzubauen. Sie hat einen externen Compliance-Partner an Bord. Sie hat ein PSIRT-Team formiert. Sie hat die SBOM-Pipeline beauftragt. Sie hat den 11. September 2026 im Kalender markiert wie frueher den Start einer Branchenmesse. Reiner Bredow weiss, dass er nicht alle Luecken bis zum Stichtag schliessen wird, aber er weiss, dass er an einem Punkt ist, an dem ein ENISA-Bericht im Ernstfall nicht zur Existenzkrise wird.

Handlungsempfehlungen fuer andere Mittelstaendler

Wer 108 Tage vor dem ersten CRA-Stichtag noch nicht angefangen hat, kann sich an folgender Reihenfolge orientieren:

Phase 1, Mai/Juni 2026 - Produkt-Inventur: Welche unserer Produkte fallen unter den CRA? Welche enthalten welche Software-Komponenten? Wer ist im Unternehmen formal verantwortlich fuer Cybersecurity-Compliance auf Produktebene? Wer ist Stellvertreter? Klare Benennung in einer Geschaeftsfuehrer-Anweisung.

Phase 2, Juni/Juli 2026 - PSIRT-Aufbau: Drei- bis fuenfkoepfiges Kernteam, klare Rollen, dokumentierte Eskalationswege. Externe E-Mail-Adresse security@firma.de. PGP-Schluesselmanagement. CVD-Policy auf der Website. /.well-known/security.txt einrichten.

Phase 3, Juli/August 2026 - SBOM- und VEX-Pipeline: CI/CD-Integration mit Open-Source-Tools (syft, cyclonedx-cli). Rueckwirkend fuer alle aktiven Firmware-/Software-Versionen eine SBOM erstellen. VEX-Vorlagen vorbereiten.

Phase 4, August 2026 - Trockenuebung: Ein realistisches Szenario durchspielen, vom Eingang einer externen Meldung bis zur ENISA-Vollmeldung nach 72 Stunden. Messen, was funktioniert, was Zeit kostet, wo Luecken sind. Nachbessern.

Phase 5, September 2026 - Go-live: Die SRP-Testphase nutzen, um die Anbindung an die ENISA-Plattform zu testen. Erste Probe-Meldungen ohne realen Vorfall einreichen. Verbindung zum nationalen CSIRT herstellen.

Fuer Unternehmen, die diesen Weg nicht alleine gehen wollen, bieten die Beratungsleistungen der pleXtec einen erfahrenen Partner. Wir begleiten Mittelstaendler beim Aufbau von PSIRT-Strukturen, bei der SBOM-Einfuehrung, bei der CRA- und NIS2-Mappings auf bestehende Prozesse. Unsere Compliance-Software-Beratung zeigt, welche Werkzeuge das interne Team entlasten, und welche nur Komplexitaet ohne Nutzen erzeugen. Auch in der sicheren Softwareentwicklung mit Fokus auf SBOM-faehige CI/CD-Pipelines unterstuetzen wir Hersteller technisch wie methodisch.

Ausblick: Der 11. September 2026 als Lackmustest

In 108 Tagen wird sich zeigen, wie ernst der deutsche Mittelstand seine Rolle als Lieferant in der digitalen Wertschoepfungskette nimmt. ENISA wird in den ersten Wochen Meldungen erhalten, einige werden ueberzeugend strukturiert sein, andere werden hektisch zusammengetragen wirken. Die Differenz ist nicht zufaellig. Sie ist die Differenz zwischen Unternehmen, die im Mai 2026 begonnen haben, die Strukturen aufzubauen, und solchen, die im August in Hektik geraten.

Reiner Bredow wird am 11. September wahrscheinlich keine Meldung abgeben muessen. Aber er wird an diesem Tag das gute Gewusst-Gefuehl haben, im Ernstfall handlungsfaehig zu sein. Und das ist, mehr als jede Konformitaetsbescheinigung, die eigentliche Wirkung der Verordnung: Sie zwingt zur Strukturierung dessen, was im Mittelstand zu lange als selbstverstaendlich vorausgesetzt wurde. Dass jemand die Verantwortung hat. Dass jemand reagiert. Dass jemand die Uebersicht behaelt.

Sprechen Sie mit uns ueber das Kontaktformular, wenn Sie Ihre CRA-Strukturen jetzt aufbauen wollen. Die 108 Tage werden nicht zurueckkommen.