NIS2 klingelt.
Haben Sie diese 7 Nachweise für Ihre Excel-/VBA-Makros griffbereit?

Excel-Dateien, Makros und Add-Ins sind in vielen Unternehmen zu Mikro-Anwendungen geworden – mit echtem Geschäftsrisiko. Teilweise steuern sie heute kritische Arbeitsschritte und sind damit NIS2-relevant. NIS2 verlangt keine „Makro-Verbote“, sondern wirksame Steuerung und belastbare Nachweise. Dieser Beitrag fasst zusammen, was Auditoren sehen wollen, welche technische Baseline funktioniert (MOTW, Signaturpflicht, Trusted Locations, Distribution, Restore) und enthält eine Audit-Readyness-Checkliste. Können Sie alle Punkte abhaken?

Warum Excel-/VBA-Makros NIS2-relevant sind

Excel steuert heute Angebotspreise, Reporting, Datenaufbereitung, Betriebsdaten – oft mit personenbezogenen oder vertraulichen Inhalten. NIS2 adressiert Organisationen und erwartet bei kritischen Prozessen Risikosteuerung, wirksame Maßnahmen und Dokumentation. Zusätzlich blockiert Microsoft via Mark of the Web (MOTW) standardmäßig Internet-Quellen. Wer ohne Signatur-Prozess arbeitet, erzeugt Störungen – und Risikogaps. Die Lösung ist eine gehärtete Office-Governance.

Technische Baseline für Office-Makros

• MOTW strikt aktiv: Dateien mit Internet-Herkunft führen keinen Code aus – Absicherung gegen eingeschleusten VBA-Code.
• Nur signierte Makros: V3-Signatur mit Zeitstempel, Herausgeber als Trusted Publisher (Intune/GPO) verteilt; private Schlüssel geschützt (z.B. HSM/Token).
• Trusted Locations restriktiv: nach dem Minimal-Prinzip konfigurieren; Nutzer-eigene Einträge verhindern; Pfade wenn möglich read-only.
• Distribution & Betrieb: Versionierung, Rollback-Plan, Freigaben nur aus kontrollierten Quellen.
• Monitoring: Block-/Signatur-Events und auffällige Zugriffe; Wirksamkeit regelmäßig prüfen und protokollieren.

Die 7 prüffähigen Nachweise

Auditoren suchen keine Absichtserklärungen, sondern belastbare Belege, die sich nachvollziehen und wiederholen lassen. Die folgenden sieben Nachweise machen Ihre Makro-Landschaft prüffähig: Sie zeigen, was im Einsatz ist, welche Regeln gelten, wie Signaturen verwaltet werden, wo Makros laufen dürfen – und dass Änderungen, Wiederanläufe und Sicherheitsvorfälle beherrscht werden.

1) Makro-Inventar inkl. Kritikalität

Das Inventar ist die zentrale Quelle der Wahrheit: eine gepflegte Liste aller produktiven Excel-Dateien und Add-Ins mit fachlichem und technischem Owner, eindeutigem Zweck, Speicherort, Signaturstatus sowie Datenklasse (z. B. intern, vertraulich, personenbezogen). Entscheidend ist die Kritikalität: Legen Sie transparent fest, nach welchen Kriterien (Auswirkung, Häufigkeit, Datenrisiko, Prozessrelevanz) ein Makro als niedrig, mittel oder hoch eingestuft wird – und dokumentieren Sie den Review-Turnus, Abhängigkeiten (z. B. zu Templates, externen Bibliotheken) und die letzte Prüfung. Ein gutes Inventar erlaubt es Auditor:innen, stichprobenfrei vom Eintrag zum Artefakt zu springen und umgekehrt.

2) Richtlinien-Exports (GPO/Intune)

Richtlinien regeln, was am Arbeitsplatz technisch durchgesetzt wird. Exportieren Sie die effektiven Policies aus GPO bzw. Intune und belegen Sie damit, dass sicherheitsrelevante Einstellungen erzwungen werden: Blockierung von Dateien mit Mark-of-the-Web (MOTW), Ausführung nur signierter Makros, Deaktivierung von „Trusted Documents“ und Verbot benutzerdefinierter Trusted Locations. Wichtig ist der Geltungsbereich: Dokumentieren Sie die Scopes (OUs, Gerätegruppen), Rollout-Wellen, Ausnahmen und das Datum der letzten Änderung. So wird sichtbar, dass die Schutzmaßnahmen nicht nur existieren, sondern auch flächendeckend greifen.

3) Signatur- & Publisher-Nachweise

Makros sind nur so vertrauenswürdig wie ihre Signaturen. Legen Sie die verwendeten Zertifikate mit Gültigkeit und Zeitstempel dar, beschreiben Sie den Schutz der privaten Schlüssel (z. B. HSM, TPM, Smartcard) und zeigen Sie, wie „Trusted Publisher“ verteilt werden. Der Nachweis muss die Kette schließen: vom signierten Build-Artefakt über die Prüfsumme bis zur produktiven Version beim Anwender. So kann nachvollzogen werden, dass genau dieser signierte Stand produktiv ist und dass der Signaturprozess gegen Missbrauch abgesichert wurde.

4) Trusted-Locations-Konzept

Wo Makros überhaupt laufen dürfen, entscheidet Ihr Trusted-Locations-Konzept. Beschreiben Sie begründete, möglichst enge Pfade mit klaren Berechtigungen (Least Privilege) und festen Review-Terminen. Netzwerkpfade sollten die Ausnahme bleiben und – wenn unvermeidbar – ausschließlich read-only bereitgestellt werden. Halten Sie außerdem fest, wie Sie Umgehungen verhindern (z. B. keine Nutzer-TLs, keine Schreibrechte für breite Gruppen) und wie neue Pfade beantragt, geprüft und wieder entfernt werden. Dieses Konzept verhindert Wildwuchs und macht Ausnahmen transparent.

5) Release- & Change-Protokolle

Jede Änderung an Makros muss nachvollziehbar sein. Führen Sie für Releases und Changes Tickets oder Pull Requests mit Peer-Review, Testnachweisen (funktional und sicherheitlich) und formaler Freigabe. Versionieren Sie sauber (z.B. semantisch), verknüpfen Sie das Inventar mit der freigegebenen Version und hinterlegen Sie, was getestet wurde und warum. Für Audits genügt oft ein aktueller Auszug der letzten Releases – wenn daraus klar ersichtlich ist, dass Änderungen kontrolliert, geprüft und dokumentiert ablaufen.

6) Restore-Protokoll (Rollback)

Backups sind wertlos, wenn der Wiederanlauf nicht funktioniert. Protokollieren Sie mindestens halbjährlich einen realen Restore-Test: Welche Schritte, welche Rollen, welche Dauer? Welche Version wurde zurückgespielt, wie wurde die Integrität (Signatur, Hash) geprüft und wie schnell war der betroffene Prozess wieder arbeitsfähig? Ergänzen Sie Zielwerte für RTO/RPO und dokumentieren Sie Lessons Learned. Damit belegen Sie, dass Sie nicht nur sichern, sondern den Betrieb nach einem Fehler oder einer kompromittierten Makro-Version reproduzierbar wiederherstellen können.

7) Logs & Incident-Runbook

Definieren Sie, welche Ereignisse relevant sind (z. B. geblockte Makros, Signaturfehler, Policy-Verstöße, Ausführung außerhalb erlaubter Pfade) und wo diese Ereignisse landen (Endpoint-Logs, Ticket-System). Das Incident-Runbook beschreibt den Ablauf von der Meldung bis zur Aufarbeitung: Erkennung, Erstreaktion, Eskalation, Eindämmung, Recovery und Post-Incident-Review – inklusive Rollen (Fachbereich, IT, ISB, Management), Kommunikationsmatrix und internen Zeitvorgaben (z.B. Erstmeldung innerhalb 24 h, Status in 72 h, Abschlussbericht binnen 30 Tagen). So zeigen Sie, dass Vorfälle nicht zufällig, sondern nach einem trainierten Standardprozess bearbeitet werden.

Architekturprinzipien, die Audits bestehen

Verantwortlichkeit klar benennen. Jede produktive Datei und jedes Add-In hat zwei verantwortliche Rollen: einen fachlichen Owner (Prozess, Inhalt, Nutzen) und einen technischen Owner (Code, Verteilung, Betrieb). Beide Namen stehen im Inventar, mit Vertretung, Erreichbarkeit und Entscheidungsbefugnissen. So ist im Audit auf einen Blick nachvollziehbar, wer Änderungen beauftragt, wer sie bewertet und wer im Störfall entscheidet. Ein einfaches RACI-Schema (Responsible, Accountable, Consulted, Informed) direkt am Eintrag verhindert Grauzonen.

Trennung von Entwicklung und Betrieb strikt durchziehen. Produktive Dateien werden nie direkt editiert. Änderungen entstehen in einer Entwicklungsumgebung, werden versioniert, getestet (funktional und sicherheitlich) und anschließend als signiertes Release ausgerollt. Der Weg in die Produktion ist ein kurzer, dokumentierter Prozess: Ticket/PR → Review → Testprotokoll → Signatur mit Zeitstempel → Rollout über definierte Kanäle (z. B. Intune, Softwareverteilung). Dieses Muster verhindert „heimliche“ Hotfixes, ermöglicht Reproduzierbarkeit und liefert automatisch prüffähige Nachweise (Release-Notizen, Prüfsummen, Signaturdetails).

Minimalprinzip konsequent anwenden. Trusted Locations (TLs) sind so knapp wie möglich definiert und rollenbasiert berechtigt. Nutzer dürfen weder eigene TLs anlegen noch breit beschreibbare Netzpfade verwenden. Jede Ausnahme ist befristet, begründet und im Inventar mit Review-Datum vermerkt. Gleiches gilt für Berechtigungen: Schreibrechte nur für Build-/Release-Konten, Leserechte für die Anwendergruppen, keine globalen „Everyone“-Zugriffe. Das Ergebnis ist eine Umgebung, in der Makros nur dort laufen, wo sie sollen – nachvollziehbar und kontrolliert.

Power-User gezielt befähigen. Kurze, wiederkehrende 30- bis 45-Minuten-Sessions vermitteln genau das Nötige: Wie erkenne ich Signaturen? Was bedeuten Policy-Meldungen („aus Sicherheitsgründen blockiert“)? Wie melde ich einen Bedarf (neue TL, neue Version) richtig an? Mit Cheatsheets und kleinen Demos sinkt die Störquote und es entstehen weniger „Workarounds“, die später im Audit auffallen.

Audit-Readyness-Checkliste

Governance & Verantwortlichkeiten

• Makro-Register (Owner, Zweck, Speicherort, Datenklasse, Kritikalität, letzter Review)
• Release-Policy (Dev→Staging→Prod) schriftlich

Policies & Härtung

• MOTW aktiv; nur signierte Makros (GPO/Intune)
• Trusted Documents aus oder stark eingeschränkt

Signaturen & Publisher

• V3-Signatur mit Zeitstempel; Zertifikate dokumentiert
• Trusted Publisher verteilt; Keys geschützt (HSM/Token)

Trusted Locations

• Schriftliches TL-Konzept: Pfad, Rechte, Review
• Nutzer-TLs unterbunden; Netzwerk-TLs selten & read-only

Betrieb & Wiederanlauf

• Versionierung, Rollback, Freigabe aus kontrollierten Quellen
• Dokumentierter Restore-Test

Monitoring & Meldung

• Block-/Signatur-Events & TL-Zugriffe ins SIEM
• Runbook mit 24/72/30-Zeitstrahl

Lieferkette & Schulung

• Freigabe für Dritt-Vorlagen/Add-Ins inkl. Signaturprüfung
• Power-User-Awareness

Audit-Mapping: NIS2-Anforderung ↔ Nachweis

Die folgende Übersicht zeigt, welche Nachweise Auditor:innen typischerweise für Excel- und VBA-Umgebungen im Rahmen einer NIS2- oder ISMS-Prüfung verlangen – und womit Sie diese belegen können.

Hinweis: Die oben beschriebenen Prüf- und Nachweisfelder sind typische Schwerpunkte in NIS2- bzw. Sicherheits-Audits rund um Excel/VBA und orientieren sich u.a. an gängigen ISMS-Anforderungen (z.B. ISO/IEC 27001) sowie Empfehlungen von Behörden. Sie stellen keine abschließende Liste dar: Umfang und Tiefe der Prüfung hängen stets vom Einzelfall ab (Branche, Schutzbedarf, Scope, Prüfkatalog, Ausnahmen). Dieser Artikel bietet eine Orientierung, ersetzt aber keine fundierte Beratung oder Einzelfall-Bewertung durch Fachpersonal. Sprechen Sie uns bei Beratungs-Bedarf gerne an.

FAQ

„Verbietet NIS2 Makros?“

Nein. Es geht um wirksame Maßnahmen und deren Nachweis – nicht um Verbote.

„Reicht eine Trusted Location?“

Nein. TLs sind nur sicher, wenn selten & restriktiv – und sie ersetzen keine Signaturpflicht.

„Sind wir NIS2-pflichtig?“

Auch ohne direkte Pflichten verlangen Auftraggeber zunehmend Nachweise. Die Baseline senkt zudem Malware-Risiken und Support-Aufwand.

Weiterführende Informationen

• VBA- & Makro-Sicherheit im Unternehmen
• Wenn Excel zu eng wird: Excel-Tool → Web-App
• Managed VBA-Security Service
• NIS2 & Office-Makro-Inventar
• NIS2-Nachweise für Office-Makros & VBA
• NIS2 & Office-Makro-Hardening

Fazit & Managed Service

Wer NIS2-konform prüfen oder sich auf ein Sicherheits-Audit vorbereiten will, merkt schnell: Es geht nicht um Technik allein, sondern um dauerhaft saubere Nachweise – Inventar, Policies, Signaturen, Prozesse, Wiederanlauf. Genau diese Kombination aus Struktur, Aktualität und Dokumentation entscheidet, ob eine Makro-Umgebung als prüffähig gilt.

Viele Unternehmen scheitern hier nicht am Wissen, sondern an knappen Ressourcen: fehlende Zeit für Inventarpflege, unklare Zuständigkeiten oder keine geeigneten Tools für Signatur- und Rollout-Automatisierung. Damit Sie trotzdem sicher und auditfest bleiben, übernehmen wir diese Aufgaben im Rahmen unseres Managed VBA-Security Service – inklusive Inventar-Management, Policy-Rollout (MOTW/„nur signierte Makros“), Signaturverwaltung mit Zeitstempeln und Trusted Publishern, restriktiver TL-Pflege, Versionierung, Restore-Dokumentation, Monitoring-Anbindung und einem vollständigen Audit-Dossier.

So bleibt Ihr Team produktiv – und Ihre Makros bleiben kontrolliert, nachvollziehbar und revisionssicher.

PDF-Karussell zum Thema NIS2 & Excel/VBA

Alle Folien kompakt als PDF – 12 Seiten.

 PDF herunterladen (ca. 150 KB)

Rechtlicher Hinweis: Dieser Beitrag ist ein allgemeiner Fachtext und ersetzt keine Rechtsberatung.

Dieser Beitrag wurde veröffentlich am 11.11.2025.