Guide
Wie nutzt du einen Nachweis für mehrere Audits?
Ein Beleg kann mehrere Prüfungen unterstützen. Mit einer Abdeckungsmatrix erkennst du, wo Geltungsbereich, Zeitraum oder Prüfkriterium zusätzliche Arbeit verlangen.
Drei Prüfungen fragen nach dem Umgang mit externen Dateifreigaben. Dein Team kopiert dieselbe Richtlinie in drei Ordner. Kurz darauf wird sie geändert. In einem Ordner liegt schon die neue Version, in den anderen noch die alte.
Pflege einen Beleg an einer maßgeblichen Stelle und bewerte seine Eignung für jede Prüfung getrennt. So vermeidest du widersprüchliche Kopien, ohne unterschiedliche Anforderungen gleichzusetzen.
Teil zwei der Serie „Nachweise, die im Alltag tragen“ führt vom vorhandenen Beleg zur Abdeckungsmatrix. Die Aktualität des Belegs prüfst du nach dem Ablauf aus Teil eins. Hier geht es darum, welche zusätzliche Aussage ein anderes Audit benötigt.
Gemeinsames Thema bedeutet nicht gleiche Anforderung
ISO 27001, TISAX, ein internes Kontrollsystem und ein Kundenvertrag können ähnliche Themen berühren. Daraus folgt nicht, dass derselbe Nachweis jeden Prüfpunkt vollständig erfüllt. Anforderungen können andere Rollen, Systeme, Zeiträume oder Arten der Prüfung betreffen.
Beim Vergleich von Standards beschreibt ein Mapping Beziehungen zwischen Anforderungen. Das NIST-Programm OLIR beschreibt solche Beziehungen zwischen Elementen verschiedener Dokumente. NIST weist in den OLIR-FAQ darauf hin, dass daraus abgeleitete Zuordnungen einen Ausgangspunkt für Vergleiche bilden. Die Bewertung im eigenen Kontext bleibt notwendig.
Für eure Arbeit heißt das: Notiere zu jeder Zuordnung, welchen Teil der Anforderung der Beleg unterstützt. „Passt zu Zugriffsschutz“ ist zu unscharf, wenn im nächsten Audit die tatsächliche Beendigung von Zugängen geprüft wird.
In Kopexa verbindet die Maßnahme Nachweise und Controls
Nachweis → Maßnahme → mehrere Controls: In Kopexa hinterlegst du den Nachweis an der Maßnahme. Die Maßnahme wird den passenden Controls zugeordnet. Eine gemeinsam genutzte Maßnahme kann damit Anforderungen aus mehreren Standards unterstützen, ohne dass du ihre Nachweise für jeden Standard erneut pflegen musst.
Im Beispiel setzt die Maßnahme „Externe Freigaben steuern“ den vorgesehenen Freigabeweg um. Richtlinie und Prüfprotokoll liegen an dieser Maßnahme. Über die zugeordneten Controls wird nachvollziehbar, für welche Anforderungen diese Umsetzung relevant ist. Ob die Belege deren jeweiligen Prüfzweck abdecken, bewertet ihr getrennt.
Ein Beleg, drei unterschiedliche Fragen
Fiktiver Fall: Die Richtlinie R-12, Version 2, beschreibt befristete externe Freigaben im Projektportal. Dazu gibt es einen aktuellen Testbericht P-08 und eine dokumentierte Unterweisung der betroffenen Projektleitenden. Diese Belege lassen sich für mehrere Prüffragen nutzen; sie belegen aber unterschiedliche Dinge.
Eine Maßnahme, gemeinsam gepflegte Nachweise und getrennte Prüffragen. Die Control-Bezeichnungen sind Beispiele, keine zitierten Normanforderungen.
| Prüfung und Kriterium im Beispiel | Geltungsbereich und Zeitraum | Geeigneter Beleg | Unterstützte Aussage | Zusätzliche Prüfung |
|---|---|---|---|---|
| Internes ISMS-Audit: Freigabeweg ist geregelt | Aktuell verwendetes Projektportal | R-12, freigegebene Version 2 | Vorgehen und Verantwortung sind festgelegt | Passt der Inhalt zur tatsächlichen Arbeitsweise? |
| Kundenaudit: Freigaben im konkreten Projekt sind befristet | Vereinbartes Projekt und Prüfzeitraum | P-08 mit passender Stichprobe | Geprüfte Freigaben entsprechen dem festgelegten Kriterium | Sind Projekt und geforderter Zeitraum vollständig erfasst? |
| Interne Kontrolle: Betroffene Rollen kennen den neuen Weg | Vorgesehene Projektleitende nach der Änderung | Unterweisungsunterlagen und dokumentierte Teilnahme | Änderung wurde vermittelt | Können die Beteiligten den Weg im Beispielszenario anwenden? |
Diese Matrix ist kein normatives Mapping zwischen Standards. Sie zeigt, wie du aus dem Wort „Zugriffsschutz“ getrennte Prüffragen machst. Übernimm in euer echtes Register die genaue Anforderung einschließlich Quelle und Version.
Prüfe fünf Unterschiede vor der Wiederverwendung
Geltungsbereich: Gehören die betreffende Gesellschaft, der Standort, das System und die Leistung zum Nachweis? Ein konzernweiter Titel genügt nicht, wenn die Stichprobe nur einen Standort erfasst.
Zeitraum: Geht es um den heutigen Zustand oder die Durchführung während einer bestimmten Periode? Ein aktueller Screenshot beantwortet nicht automatisch eine Frage zum vergangenen Quartal.
Prüfkriterium: Belegt die Datei eine Vorgabe, ihre Umsetzung oder das Ergebnis einer Prüfung? Eine Richtlinie kann den Prozess beschreiben; für einen Wirksamkeitstest brauchst du mehr.
Prüfumfang: Welche Fälle wurden betrachtet, welche nicht? Eine Stichprobe bleibt eine Stichprobe. Kennzeichne ihre Grenzen, statt den Nachweis auf ungeprüfte Bereiche auszudehnen.
Freigabe zur Weitergabe: Darf die empfangende Stelle den vollständigen Beleg sehen? Wenn Schwärzungen nötig sind, prüfe, ob die relevante Aussage danach noch beurteilt werden kann. Vereinbare bei Bedarf kontrollierte Einsicht statt einer ungeschützten Kopie.
Baue eine Abdeckungsmatrix statt weiterer Auditordner
Gehe von der Maßnahme aus: Welche Controls unterstützt sie, und welche ihrer Nachweise passen zur jeweiligen Prüffrage? Halte diese Bewertung in der Abdeckungsmatrix fest. Die Referenz zeigt auf die konkrete Belegfassung an der Maßnahme.
Ein kompakter Eintrag enthält:
- Control beziehungsweise Anforderung mit Quelle und Version;
- zugeordnete Maßnahme;
- Geltungsbereich und benötigten Zeitraum;
- Belegreferenz mit Fassung und Herkunft;
- unterstützte Aussage und verbleibende Lücke;
- zuständige prüfende Rolle und Ergebnisdatum;
- gegebenenfalls ergänzende Aufgabe oder Nachweis.
Dadurch kann derselbe Beleg im internen Audit ausreichend sein und im Kundenaudit nur einen Teil abdecken. Das ist kein Widerspruch. Die Prüffragen sind verschieden.
Die technische Struktur dahinter erläutert unser Beitrag zu OSCAL und verknüpften Sicherheitsnachweisen. Für den Einstieg brauchst du jedoch zuerst eine nachvollziehbare fachliche Zuordnung.
Was passiert, wenn sich der gemeinsame Beleg ändert?
Eine zentrale Ablage erleichtert die Pflege, ersetzt aber keine Folgenprüfung. Wird R-12 überarbeitet, gehe von der zugehörigen Maßnahme zu den betroffenen Controls und Prüfungen. Beschreibt die neue Version denselben Prozess? Hat sich die Zielgruppe geändert? Welche laufende Prüfung braucht die neue Fassung?
Halte für abgeschlossene Audits fest, welche Version damals vorlag. Ein Link, der heute auf eine andere Datei zeigt, darf die damalige Prüfgrundlage nicht unbemerkt verändern. Entscheidet anhand eurer Dokumentations- und Aufbewahrungsvorgaben, wie diese Grundlage nachvollziehbar bleibt.
Eine neue Belegfassung erfordert eine Folgenprüfung; sie schreibt die Vergangenheit nicht um.
Auch eine Änderung der Anforderung kann einen Review auslösen, obwohl die Datei selbst unverändert ist. Pflege deshalb die Version auf beiden Seiten: am Beleg und an der Anforderungsquelle.
Der Nutzen zeigt sich an der verbleibenden Arbeit
Wähle zwei echte Prüfanforderungen mit ähnlichem Thema. Prüfe, ob dieselbe Maßnahme beide unterstützt. Betrachte ihre Nachweise und schreibe für jede Anforderung getrennt auf, was sie belegen und was noch fehlt. Die gemeinsame Grundlage spart erneutes Suchen und widersprüchliche Kopien. Offene Arbeit bleibt sichtbar.
Eine Zuordnung in der Software ersetzt weder eure fachliche Entscheidung noch die Beurteilung durch die prüfende Stelle. In einer Kopexa-Demo lässt sich dieser Ablauf anhand eurer beiden Anforderungen besprechen.
Im dritten Teil geht es weiter: Wie kommt die geänderte Richtlinie aus dem Review bei den Menschen an, die danach arbeiten sollen?
Kurz beantwortet
Häufige Fragen
Noch eine Frage offen? Hier findest du die Antworten zum Nachlesen.
Kann ein Nachweis für mehrere Audits verwendet werden?
Ja, wenn er die jeweilige Prüffrage unterstützt. Geltungsbereich, Zeitraum, Kriterium und Prüfumfang müssen je Audit bewertet werden. Dieselbe Datei kann in einer Prüfung ausreichen und in einer anderen nur einen Teil abdecken.
Beweist ein Mapping die Erfüllung einer Anforderung?
Nein. In Kopexa werden Maßnahmen den Controls zugeordnet; die Nachweise liegen an der Maßnahme. Diese Zuordnung allein belegt noch keine vollständige Erfüllung. Ob der Beleg für die konkrete Anforderung ausreicht, muss getrennt bewertet werden.
Was passiert bei einer neuen Belegversion?
Prüfe die davon abhängigen Zuordnungen. Halte für abgeschlossene Prüfungen nachvollziehbar, welche Fassung damals zugrunde lag, statt die historische Prüfgrundlage stillschweigend zu ersetzen.
Quellen
- NIST: National Online Informative References – FAQ — NIST [Abgerufen am ]