ISMS-Dokumentation: Welche Dokumente du wirklich brauchst (und welche nicht)

Dokumentation im ISMS: Pflicht, Kür und Ballast

Wer ein ISMS nach ISO 27001 aufbaut, stößt schnell auf eine zentrale Frage: Welche Dokumente muss ich haben, welche sollte ich haben, und welche kann ich mir sparen? Die Antwort darauf ist weniger eindeutig, als viele Berater es darstellen. ISO 27001 nennt bestimmte Dokumente explizit als Pflicht, lässt bei anderen aber Spielraum. Und genau in diesem Spielraum entstehen die typischen Fehler: Zu wenig Dokumentation führt zu Audit-Feststellungen, zu viel Dokumentation führt zu einem Papiertiger, den niemand pflegt.

Dieser Artikel gibt dir eine vollständige Übersicht. Du erfährst, welche Dokumente ISO 27001 zwingend verlangt, welche sinnvoll ergänzen, und wo du bewusst die Bremse ziehen solltest. Am Ende steht ein konkretes Beispiel: die Dokumentenlandschaft eines mittelständischen Unternehmens mit rund 100 Mitarbeitern.

Was ISO 27001 unter dokumentierter Information versteht

Bevor wir in die Liste einsteigen, lohnt sich ein kurzer Blick auf die Terminologie. ISO 27001 spricht durchgängig von „dokumentierter Information" (documented information). Dieser Begriff umfasst zwei Kategorien:

Dokumente sind Vorgabedokumente wie Richtlinien, Verfahren und Pläne. Sie beschreiben, wie etwas gemacht werden soll. Ein Beispiel: die Informationssicherheitsrichtlinie definiert die Grundsätze, nach denen das Unternehmen Informationssicherheit betreibt.

Aufzeichnungen sind Nachweisdokumente. Sie belegen, dass etwas tatsächlich gemacht wurde. Ein Beispiel: das Protokoll des Management-Reviews belegt, dass die Geschäftsführung das ISMS regelmäßig überprüft hat.

Die Unterscheidung ist wichtig, weil Auditoren beide Typen prüfen. Ein Dokument allein reicht nicht. Wenn die Risikobewertungsmethodik beschrieben ist, aber keine Risikobewertung als Aufzeichnung existiert, ist die Anforderung nicht erfüllt.

Pflichtdokumente nach ISO 27001: Die vollständige Liste

Die folgenden Dokumente werden in ISO 27001:2022 explizit gefordert. Ohne sie ist eine Zertifizierung nicht möglich. Die Klausel-Referenzen helfen dir, die Anforderung in der Norm nachzuschlagen.

Kontext und Geltungsbereich (Klausel 4)

Der Scope ist eines der meistgeprüften Dokumente im Audit. Er muss Standorte, Geschäftsbereiche, Prozesse und Technologien benennen, die vom ISMS abgedeckt werden. Vage Formulierungen wie „alle IT-Systeme" reichen nicht aus.

Führung und Verpflichtung (Klausel 5)

Die Informationssicherheitsrichtlinie ist das Dach aller anderen Richtlinien. Sie muss von der Geschäftsführung freigegeben sein und allen Mitarbeitern bekannt gemacht werden. Ein unterschriebenes PDF in einem SharePoint-Ordner, das nie jemand öffnet, erfüllt die Anforderung formal, aber nicht inhaltlich.

Planung (Klausel 6)

Die SoA ist das Herzstück der ISO-27001-Dokumentation. Sie listet alle 93 Controls aus Anhang A auf und dokumentiert für jede einzelne, ob sie angewendet wird, wie sie umgesetzt ist und warum sie ggf. ausgeschlossen wurde. Ein schlecht gepflegtes SoA ist einer der häufigsten Gründe für Hauptabweichungen im Audit.

Unterstützung (Klausel 7)

Die Dokumentenlenkung ist gewissermaßen das Meta-Dokument: Sie beschreibt, wie alle anderen Dokumente verwaltet werden. Ohne funktionierendes Dokumentenlenkungsverfahren ist das gesamte ISMS formal angreifbar.

Betrieb (Klausel 8)

Bewertung der Leistung (Klausel 9)

Verbesserung (Klausel 10)

Wenn du alle Dokumente aus dieser Liste zusammenzählst, kommst du auf rund 20 bis 25 Einzeldokumente und Aufzeichnungen. Das ist die Pflicht. Alles, was darüber hinausgeht, ist Kür.

Empfohlene Dokumente: Was Auditoren erwarten, auch wenn es nicht Pflicht ist

Neben den explizit geforderten Dokumenten gibt es eine Reihe von Dokumenten, die in der Norm nicht wörtlich verlangt werden, die aber von den meisten Auditoren erwartet werden. Der Grund: Die Pflichtdokumente setzen ihre Existenz implizit voraus, oder sie sind die logische Umsetzung eines Controls aus Anhang A.

Richtlinien auf operativer Ebene

Die Informationssicherheitsrichtlinie aus Klausel 5.2 ist das Dachdokument. Für die tatsächliche Steuerung brauchst du themenspezifische Richtlinien:

• Passwortrichtlinie (A.5.17): Komplexität, Länge, Wiederverwendung, MFA
• Zugriffskontrollrichtlinie (A.5.15, A.5.18): Berechtigungskonzept, Least Privilege, Rezertifizierung
• Mobile Device und Remote-Work-Richtlinie (A.6.7, A.8.1): BYOD-Regelungen, VPN-Pflicht, Geräteverschlüsselung
• Backup-Richtlinie (A.8.13): Backup-Strategie, Aufbewahrungsfristen, Restore-Tests
• Richtlinie zur Informationsklassifizierung (A.5.12, A.5.13): Schutzstufen, Kennzeichnung, Handhabung
• Verschlüsselungsrichtlinie (A.8.24): Welche Daten werden wie verschlüsselt, Schlüsselmanagement
• Richtlinie zum Umgang mit Sicherheitsvorfällen (A.5.24 bis A.5.28): Erkennung, Meldung, Eskalation, Nachbearbeitung
• Lieferantenrichtlinie (A.5.19 bis A.5.22): Bewertung, vertragliche Anforderungen, Überwachung

Jede dieser Richtlinien adressiert ein oder mehrere Controls aus Anhang A. Im SoA referenzierst du diese Richtlinien als Umsetzungsnachweis.

Verfahrensdokumente und Prozessbeschreibungen

• Incident-Response-Plan: Detaillierter Ablauf bei Sicherheitsvorfällen mit Rollen, Kommunikationswegen und Eskalationsstufen
• Business-Continuity-Plan: Wie der Geschäftsbetrieb bei einem Ausfall aufrechterhalten wird
• Wiederanlaufplan: Technische Wiederherstellung von Systemen nach einem Vorfall
• Change-Management-Verfahren: Wie Änderungen an Systemen geplant, genehmigt und durchgeführt werden
• Onboarding- und Offboarding-Prozess: Vergabe und Entzug von Berechtigungen bei Eintritt und Austritt

Inventare und Verzeichnisse

• Asset-Inventar: Alle Informationswerte mit Eigentümer, Klassifizierung und Schutzbedarf
• Risikoregister: Zentrale Übersicht aller identifizierten Risiken mit Bewertung und Status der Behandlung
• Maßnahmenregister: Alle laufenden und abgeschlossenen Maßnahmen mit Verantwortlichem, Frist und Status
• Lieferantenverzeichnis: Externe Dienstleister mit sicherheitsrelevanter Einstufung und vertraglichem Status

Weitere empfohlene Aufzeichnungen

• Schulungsplan: Jahresplanung der Awareness- und Fachschulungen
• Audit-Jahresplan: Dreijährige Auditplanung über alle ISMS-Bereiche
• Kennzahlen-Dashboard: Regelmäßig aktualisierte ISMS-KPIs
• Protokolle von Sicherheitsvorfällen: Strukturierte Nachbearbeitung abgeschlossener Vorfälle

Die empfohlenen Dokumente bringen die Gesamtzahl auf etwa 40 bis 50 Einzeldokumente. Das klingt nach viel, ist aber für ein funktionierendes ISMS realistisch. Entscheidend ist nicht die Anzahl, sondern die Qualität und Aktualität.

Was du NICHT brauchst: Over-Engineering erkennen und vermeiden

Jetzt zum vielleicht wichtigsten Teil dieses Artikels. Denn die Versuchung, zu viel zu dokumentieren, ist in der Praxis mindestens so groß wie die Gefahr, zu wenig zu haben. Over-Engineering in der ISMS-Dokumentation hat konkrete Ursachen, und es hat konkrete Kosten.

Typische Formen von Over-Engineering

Richtlinien für selbstverständliche Dinge. Du brauchst keine eigene „Richtlinie zum verantwortungsvollen Umgang mit dem Firmenlaptop", wenn die Mobile-Device-Richtlinie das abdeckt. Du brauchst kein separates Dokument „Sicherheit am Arbeitsplatz", wenn die physische Sicherheit in der Zutrittskontrollrichtlinie steht. Jedes zusätzliche Dokument erzeugt Pflegeaufwand und erhöht die Wahrscheinlichkeit von Widersprüchen.

Prozessbeschreibungen für triviale Abläufe. Nicht jeder IT-Vorgang braucht ein formales Verfahrensdokument. Wenn dein Team aus drei Administratoren besteht, die täglich miteinander sprechen, ist ein 15-seitiges Change-Management-Verfahren mit fünf Genehmigungsstufen nicht nur überflüssig, sondern kontraproduktiv. Es wird nicht gelebt, und der Auditor wird das merken.

Detailgrade, die keinen Mehrwert bringen. Eine Risikobewertung muss Risiken identifizieren, bewerten und priorisieren. Sie muss nicht für jedes Risiko eine zweiseitige Analyse mit fünf Unterkategorien enthalten, wenn die Bewertungsmethodik das nicht vorsieht. Ein kompaktes Risikoregister mit klaren Bewertungskriterien ist einem aufgeblähten Risikohandbuch in der Praxis überlegen.

Doppeldokumentationen. Wenn das Asset-Inventar den Schutzbedarf enthält und das Risikoregister ebenfalls den Schutzbedarf auflistet, pflegst du dieselbe Information an zwei Stellen. Bei der nächsten Aktualisierung weichen die Werte ab, und der Auditor stellt die berechtigte Frage, welches Dokument führend ist. Jede Information sollte genau eine autoritative Quelle haben.

Vorlagen ohne Kontext. Ein häufiger Fehler bei Beratern und fertigen Vorlagenpaketen: Es werden 80 Dokumente geliefert, die generisch sind und nie auf das Unternehmen angepasst werden. Der Auditor erkennt das sofort, wenn in der Passwortrichtlinie „Unternehmen XY" steht, die Serverrichtlinie Windows-Server beschreibt, obwohl du nur Linux betreibst, oder die Zutrittskontrollrichtlinie ein Rechenzentrum regelt, das du gar nicht hast.

Faustregel für die richtige Dokumentationstiefe

Jedes Dokument muss mindestens eine der folgenden Fragen mit Ja beantworten können:

1. Fordert die Norm dieses Dokument explizit?
2. Braucht ein Mitarbeiter dieses Dokument, um seine Aufgabe korrekt auszuführen?
3. Braucht der Auditor dieses Dokument als Nachweis für die Umsetzung eines Controls?
4. Hilft dieses Dokument bei der Entscheidungsfindung in einer konkreten Situation?

Wenn keines dieser Kriterien zutrifft, brauchst du das Dokument nicht. Streich es, bevor es dich Pflegeaufwand kostet.

Dokumentenstruktur: Ordnung statt Chaos

Eine gute Dokumentenstruktur ist die Voraussetzung dafür, dass dein ISMS-Dokumentensystem funktioniert. Es gibt verschiedene Ansätze, aber ein bewährtes Modell ist die Pyramidenstruktur.

Die Dokumentenpyramide

Ebene 1: Richtlinien (Policies) Das sind die Grundsatzdokumente: die Informationssicherheitsrichtlinie und die themenspezifischen Richtlinien. Sie beschreiben das „Was" und „Warum". Richtlinien werden von der Geschäftsführung oder dem ISB freigegeben und gelten für das gesamte Unternehmen oder klar definierte Bereiche.

Ebene 2: Verfahren und Prozesse (Procedures) Diese Dokumente beschreiben das „Wie". Der Incident-Response-Plan, das Change-Management-Verfahren, der Onboarding-Prozess. Sie richten sich an die Personen, die den Prozess ausführen, und sind detaillierter als Richtlinien.

Ebene 3: Arbeitsanweisungen und Checklisten Noch detailliertere Anleitungen für spezifische Tätigkeiten: Checkliste für Server-Härtung, Anleitung zur Benutzeranlage im Active Directory, Ablauf beim Restore-Test. Nicht jeder Prozess braucht Arbeitsanweisungen. Nur dort, wo Fehler gravierende Folgen haben oder die Tätigkeit selten ausgeführt wird.

Ebene 4: Aufzeichnungen und Nachweise (Records) Alle Ergebnisse und Belege: Risikobewertungen, Audit-Berichte, Schulungsnachweise, Vorfallsprotokolle, Management-Review-Protokolle. Diese Dokumente werden nicht geplant erstellt, sondern entstehen als Ergebnis eines Prozesses.

Ordnerstruktur

Eine bewährte Ordnerstruktur für die ISMS-Dokumentation orientiert sich an den Klauseln der Norm:

ISMS/
├── 01_Kontext_und_Scope/
│   ├── ISMS-Scope.pdf
│   ├── Kontext_der_Organisation.pdf
│   └── Interessierte_Parteien.pdf
├── 02_Richtlinien/
│   ├── Informationssicherheitsrichtlinie.pdf
│   ├── Passwortrichtlinie.pdf
│   ├── Zugriffskontrollrichtlinie.pdf
│   └── ...
├── 03_Risikomanagement/
│   ├── Risikobewertungsmethodik.pdf
│   ├── Risikoregister.xlsx
│   ├── Risikobehandlungsplan.pdf
│   └── SoA.xlsx
├── 04_Verfahren/
│   ├── Incident-Response-Plan.pdf
│   ├── Change-Management-Verfahren.pdf
│   └── ...
├── 05_Inventare/
│   ├── Asset-Inventar.xlsx
│   ├── Lieferantenverzeichnis.xlsx
│   └── ...
├── 06_Schulung/
│   ├── Schulungsplan.pdf
│   ├── Schulungsnachweise/
│   └── ...
├── 07_Audit/
│   ├── Auditprogramm.pdf
│   ├── Auditberichte/
│   └── ...
├── 08_Management_Review/
│   ├── Review_2025-Q4.pdf
│   └── ...
└── 09_Verbesserung/
    ├── Massnahmenregister.xlsx
    └── Korrekturmassnahmen/

Diese Struktur ist ein Vorschlag. Wichtiger als die exakte Gliederung ist die Konsistenz: Wenn du dich für eine Struktur entschieden hast, halte sie durch.

Namenskonvention: Kein Dokument ohne Regeln

Ohne einheitliche Namenskonvention endet jedes Dokumentenmanagementsystem im Chaos. Spätestens beim zweiten Auditor, der fragt „Wo ist die aktuelle Version der Passwortrichtlinie?", wirst du eine bereuen, wenn du keine hast.

Empfohlenes Namensformat

[Typ]-[Thema]-[Version].[Format]

Beispiele:
POL-Informationssicherheit-v2.1.pdf
POL-Passwort-v1.3.pdf
PRO-Incident-Response-v1.0.pdf
REC-Management-Review-2025-Q4.pdf
REG-Risikoregister-v3.2.xlsx
CHK-Server-Haertung-v1.1.pdf

Typkürzel

Versionierung

Nutze Semantic Versioning in vereinfachter Form:

• Hauptversion (v1.0, v2.0): Grundlegende Überarbeitung, neue Freigabe erforderlich
• Nebenversion (v1.1, v1.2): Kleinere Anpassungen, Review durch ISB
• Entwurf: Kennzeichne Entwürfe mit „DRAFT" im Dateinamen oder als Wasserzeichen

Jedes Dokument muss eine Versionshistorie enthalten. Diese muss mindestens Versionsnummer, Datum, Änderungsbeschreibung und Freigabe durch wen enthalten. Ein kurzer Dreizeiler in einer Tabelle reicht aus.

Dokumentenlenkung: Der Prozess hinter den Dokumenten

Die Dokumentenlenkung beschreibt den gesamten Lebenszyklus eines ISMS-Dokuments: von der Erstellung über Prüfung und Freigabe bis zur Archivierung und Löschung. Ohne funktionierendes Dokumentenlenkungsverfahren ist die gesamte Dokumentation angreifbar.

Lebenszyklus eines ISMS-Dokuments

1. Erstellung: Ein neues Dokument wird erstellt, typischerweise durch den ISB oder den Prozessverantwortlichen. Der Ersteller ist verantwortlich für den Inhalt und die Einhaltung der Namenskonvention und Vorlage.

2. Review: Das Dokument wird von einer fachlich zuständigen Person geprüft. Bei Richtlinien ist das oft der ISB, bei technischen Dokumenten der IT-Leiter. Der Reviewer prüft inhaltliche Korrektheit, Konsistenz mit anderen Dokumenten und Praxistauglichkeit.

3. Freigabe: Die formale Genehmigung. Richtlinien werden durch die Geschäftsführung freigegeben, operative Dokumente durch den ISB oder den jeweiligen Verantwortlichen. Die Freigabe muss nachweisbar sein, sei es durch Unterschrift, digitale Signatur oder einen dokumentierten Workflow.

4. Veröffentlichung und Kommunikation: Das Dokument wird am definierten Ablageort gespeichert und den betroffenen Personen bekanntgemacht. Bei Richtlinien, die alle Mitarbeiter betreffen, ist eine aktive Kommunikation erforderlich, nicht nur ein Upload auf den Fileserver.

5. Regelmäßige Überprüfung: Jedes Dokument hat einen Prüfzyklus. Richtlinien typischerweise jährlich, operative Dokumente alle ein bis zwei Jahre. Die Überprüfung stellt sicher, dass das Dokument noch aktuell ist und mit der gelebten Praxis übereinstimmt.

6. Aktualisierung: Bei Änderungen wird eine neue Version erstellt, die den Review- und Freigabeprozess erneut durchläuft. Die Vorgängerversion wird als „abgelöst" markiert und archiviert.

7. Archivierung und Löschung: Abgelöste Versionen werden für einen definierten Zeitraum archiviert (typischerweise mindestens über den Zertifizierungszyklus von drei Jahren), dann gelöscht. Es darf zu keinem Zeitpunkt unklar sein, welches die aktuelle Version ist.

Zugriff und Verteilung

Nicht jedes Dokument muss für jeden zugänglich sein. Ein sinnvolles Zugriffsmodell:

• Richtlinien: Alle Mitarbeiter (Leserecht)
• Verfahren: Beteiligte Abteilungen (Leserecht), Prozessverantwortliche (Schreibrecht)
• Arbeitsanweisungen: Betroffene Teams (Leserecht)
• Risikoregister, SoA: ISB, Geschäftsführung, Risikoeigner (Leserecht), ISB (Schreibrecht)
• Audit-Berichte: ISB, Geschäftsführung, Auditierter Bereich

Praxisbeispiel: Dokumentenlandschaft eines 100-Mitarbeiter-Unternehmens

Genug Theorie. Wie sieht die Dokumentenlandschaft eines mittelständischen IT-Dienstleisters mit 100 Mitarbeitern, drei Standorten und ISO-27001-Zertifizierung konkret aus? Dieses Beispiel zeigt eine realistische, auditfähige Dokumentation ohne Over-Engineering.

Richtlinien (11 Dokumente)

Elf Richtlinien, jede zwischen drei und acht Seiten. Kompakt, fokussiert und tatsächlich lesbar. Kein Dokument, das 30 Seiten lang ist und niemand bis zum Ende liest.

Verfahren und Pläne (8 Dokumente)

Inventare und Register (5 Dokumente)

Vorlagen (6 Dokumente)

Regelmäßig erzeugte Aufzeichnungen

Diese Dokumente entstehen im laufenden Betrieb:

• Quartalsweise: Aktualisiertes Risikoregister, Maßnahmenfortschritt, ISMS-Kennzahlen
• Halbjährlich: Interne Audit-Berichte (2 bis 3 pro Jahr, rotierend)
• Jährlich: Management-Review-Protokoll, aktualisierter Schulungsplan, Ergebnisse der Awareness-Schulung
• Anlassbezogen: Vorfallsberichte, Korrekturmaßnahmen, Änderungsanträge

Gesamtzählung

Das ergibt rund 30 aktiv gepflegte Dokumente plus Vorlagen und laufende Aufzeichnungen. Für ein 100-Mitarbeiter-Unternehmen ist das ein realistischer und handhabbarer Umfang. Jedes einzelne Dokument hat einen klaren Zweck und einen definierten Pflegezyklus.

Häufige Fragen zur ISMS-Dokumentation

Muss ich alles in einem bestimmten Format erstellen? Nein. ISO 27001 schreibt kein Format vor. Du kannst Word, PDF, Wiki-Systeme, spezialisierte ISMS-Tools oder eine Kombination verwenden. Wichtig ist, dass die Dokumente auffindbar, aktuell und geschützt vor unbefugter Änderung sind.

Wie detailliert müssen Richtlinien sein? Detailliert genug, dass ein Mitarbeiter weiß, was er tun und lassen soll. Nicht so detailliert, dass technische Änderungen (etwa ein Systemwechsel) sofort eine Richtlinien-Aktualisierung erfordern. Trenne Grundsätze (Richtlinie, änderungsarm) von technischen Details (Arbeitsanweisung, änderungsfreudig).

Kann ich mehrere Themen in einem Dokument zusammenfassen? Grundsätzlich ja, solange die Zuständigkeiten und Prüfzyklen kompatibel sind. Eine kombinierte „Zugriffskontroll- und Passwortrichtlinie" ist sinnvoll, weil beide Themen eng zusammenhängen und denselben Freigeber haben. Eine kombinierte „Backup- und Schulungsrichtlinie" wäre dagegen unsinnig.

Brauche ich ein eigenes Dokumentenmanagement-System? Nicht unbedingt. Ein gut strukturierter Fileserver oder SharePoint mit definierten Berechtigungen kann ausreichen. Wichtig ist, dass die Dokumentenlenkung tatsächlich funktioniert: Versionierung, Freigabe, Zugriffsschutz, Archivierung. Wenn du mehr als 30 Dokumente pflegst und mehrere Personen beteiligt sind, lohnt sich ein spezialisiertes System wie ISMS Lite, weil es Erinnerungen an Prüfzyklen, Freigabeworkflows und Audit-Trails automatisiert. 500 Euro pro Jahr erhältst du alle Module ohne Benutzerlimits, alternativ als Einmalkauf für 2.500 Euro.

Was passiert, wenn ein Dokument veraltet ist? Eine veraltete Richtlinie ist im Audit schlimmer als eine fehlende. Wenn der Auditor sieht, dass die Passwortrichtlinie seit drei Jahren nicht überprüft wurde und noch Anforderungen aus einer abgelösten Systemlandschaft enthält, ist das eine klare Abweichung. Lieber weniger Dokumente, die aktuell sind, als viele veraltete.

Die richtige Balance finden

ISMS-Dokumentation ist kein Selbstzweck. Sie dient zwei Zielen: Sie gibt den Mitarbeitern Orientierung, und sie weist gegenüber Auditoren nach, dass das ISMS funktioniert. Alles, was nicht auf eines dieser Ziele einzahlt, ist Ballast.

Die Pflichtdokumente nach ISO 27001 bilden das Fundament. Die empfohlenen Dokumente ergänzen es um praxisrelevante Richtlinien und Nachweise. Und dann kommt der Punkt, an dem du bewusst entscheidest: Das reicht. Nicht jeder Aspekt braucht ein eigenes Dokument, nicht jedes Dokument braucht zehn Seiten, und nicht jeder Prozess muss in einer formalen Verfahrensbeschreibung enden.

Starte mit den Pflichtdokumenten. Ergänze die Richtlinien, die für dein Unternehmen relevant sind. Baue die Aufzeichnungen im laufenden Betrieb auf. Und überprüfe bei jedem neuen Dokument kritisch: Braucht das wirklich jemand, oder schreibe ich es nur, weil es auf einer Liste steht?

Ein ISMS mit 35 gut gepflegten Dokumenten ist einem ISMS mit 80 verstaubten Dokumenten in jeder Hinsicht überlegen. Dein Auditor wird das genauso sehen.

Weiterführende Artikel

• ISMS aufbauen: Der komplette Leitfaden für Unternehmen mit 50 bis 500 Mitarbeitern
• Statement of Applicability (SoA) erstellen: Controls auswählen und begründen
• Informationssicherheitsrichtlinie schreiben: Aufbau, Inhalt und Beispiel
• Richtlinien-Lifecycle: Von der Erstellung bis zur Außerkraftsetzung
• Internes ISMS-Audit durchführen: Planung, Checkliste und Bericht

Die beste Dokumentation ist die, die tatsächlich gelebt wird. Pflege lieber 30 Dokumente konsequent, als 60 Dokumente auf Vorrat zu erstellen und nie wieder anzufassen. Der Prüfzyklus ist dein bester Freund: Er zwingt dich regelmäßig, jedes Dokument auf Aktualität und Relevanz zu prüfen. Was dabei durchfällt, darf aussortiert werden. Das ist kein Versagen, das ist fortlaufende Verbesserung.