Beispiel einer Risikobeurteilung nach ISO 12100
TL;DR
  • Eine Risikobeurteilung nach ISO 12100 ist ein nachvollziehbarer Sicherheitsprozess, kein gut aussehendes Formular oder sauberes PDF.
  • Excel kann als Arbeitsmittel dienen, ersetzt aber keine auditfeste Dokumentation mit Begründungen, Entscheidungen und Freigaben.
  • Die Unterlagen müssen Maschinengrenzen, reale Aufgaben, Gefährdungen, gefährliche Ereignisse, Risikobewertung und Maßnahmen klar abbilden.
  • Die Risikominderung muss der Normlogik folgen: erst konstruktiv, dann technische Schutzmaßnahmen, zuletzt Information und Organisation.
  • Nach jeder Maßnahme sind Sekundär- und Restrisiken neu zu bewerten, weil Abschirmung, Verriegelung oder Elektroänderungen neue Risiken erzeugen können.

Der schlechteste Typ der Risikobeurteilung ist nicht chaotisch. Er sieht professionell aus. Genau deshalb ist ein belastbares Beispiel einer Risikobeurteilung nach ISO 12100 so wichtig: Nicht die Optik zählt, sondern ob der Prozess technisch, logisch und für ein Audit nachvollziehbar geführt wurde. Eine Excel-Tabelle mit Punkten, Normverweisen, Kommentaren und einem sauberen PDF erzeugt schnell das angenehme Gefühl, das Thema sei abgehakt. Ist es oft nicht. ISO 12100 bewertet keine Ästhetik. ISO 12100 bewertet, ob jemand die Sicherheit der Maschine tatsächlich systematisch beurteilt, Risiken mindert und das sauber dokumentiert hat.

Und genau hier beginnt das Problem. Eine Excel-Tabelle kontrolliert keine Logik. Sie zwingt niemanden, von den Grenzen der Maschine zu realen Aufgaben, zu jeder Gefährdungssituation und zu jedem gefährlichen Ereignis zu gehen. Sie erinnert nicht daran, dass nach einer Schutzmaßnahme ein sekundäres Risiko entstehen kann. Und sie hält selten belastbar fest, wer wann welche Entscheidung getroffen hat. Dort trennt sich Verwaltung von Ingenieurarbeit.

Beispiel einer Risikobeurteilung nach ISO 12100: Warum Excel nicht reicht

Kann man eine Risikobeurteilung in Excel aufsetzen? Natürlich. Kann man damit auch den Anschein einer fertigen Unterlage erzeugen? Ebenfalls ja. Aber ISO 12100 verlangt keine Excel-Tabelle. Die Norm verlangt eine Dokumentation der Risikobeurteilung. Das ist nicht dasselbe.

Eine Excel-Tabelle kann ein Arbeitsmittel sein. Ein Notizblock in strukturierter Form. Eine Sammelstelle für Einträge. Mehr erst einmal nicht. Was die Dokumentation der Risikobeurteilung leisten muss, ist deutlich anspruchsvoller. Sie muss nicht nur zeigen, was eingetragen wurde, sondern auch, warum es eingetragen wurde und wie die Entscheidungen zustande kamen.

Eine belastbare Dokumentation der Risikobeurteilung muss mindestens erkennbar machen:

  • welche Grenzen der Maschine festgelegt wurden,
  • welche bestimmungsgemäße Verwendung und welche realen Aufgaben betrachtet wurden,
  • welche Gefährdung, welche Gefährdungssituation und welches gefährliche Ereignis jeweils analysiert wurden,
  • wie das Risiko eingeschätzt wurde,
  • welche Schutzmaßnahme ausgewählt wurde,
  • in welcher Reihenfolge die Risikominderung erfolgte,
  • ob nach der Maßnahme ein sekundäres Risiko entstanden ist,
  • wie das Restrisiko beurteilt wurde,
  • und wer welche Entscheidung getroffen oder freigegeben hat.

Der Knackpunkt ist die Reihenfolge. ISO 12100 ist bei der Risikominderung nicht dekorativ, sondern klar: zuerst konstruktive Lösungen, dann technische Schutzmaßnahmen, erst danach Information für die Nutzung und organisatorische Festlegungen. In der Praxis springt man aber gern direkt von der Gefährdung zur Schutzeinrichtung, zur Betriebsanweisung oder zur Unterweisung. Das geht schnell. Es sieht auf dem Papier ordentlich aus. Es unterbricht aber die Logik der Norm.

Spätestens wenn die Unterlagen später für CE im Rahmen der 2006/42/EG herangezogen werden, rächt sich diese Verwechslung. Ein ordentliches PDF ersetzt keine nachvollziehbare Logik. Wenn man nach Wochen nicht mehr sauber erklären kann, warum eine Schutzmaßnahme gewählt wurde, warum eine andere verworfen wurde und auf welcher Basis das Restrisiko akzeptiert wurde, dann liegt keine belastbare Dokumentation der Risikobeurteilung vor. Dann liegen Arbeitsdaten vor. Manchmal sauber formatiert. Manchmal auf den ersten Blick überzeugend. Aber eben nur Arbeitsdaten.

Sekundäres Risiko: Hier kippt die Logik

Eine Schutzmaßnahme beendet den Prozess nicht. Sie verändert den Risikozustand. Wer danach nicht erneut hinschaut, dokumentiert nur die halbe Wahrheit. Genau an dieser Stelle fangen viele Risikobeurteilungen an, sich etwas vorzumachen.

Mechanisches Beispiel: bessere Abschirmung, schlechterer Zugang

An einer Station besteht beim Eingreifen in einen Bewegungsbereich ein Risiko durch Kontakt mit gefährlichen Bewegungen. Das Team ergänzt eine bewegliche Schutzeinrichtung mit Verriegelung. Während des Automatikbetriebs sinkt das Risiko deutlich. So weit, so gut.

Dann kommt die Realität. Bei Reinigung und beim Beseitigen von Staus muss die Bedienperson jetzt tiefer in die Maschine greifen, durch eine engere Öffnung arbeiten, in unnatürlicher Haltung hantieren und schlechter sehen, was im Inneren passiert. Das ursprüngliche mechanische Risiko sinkt, aber gleichzeitig entsteht ein sekundäres Risiko durch schlechtere Zugänglichkeit, eingeschränkte Sicht und schlechtere Ergonomie. Wer das nicht erneut bewertet, dokumentiert eine Welt, die sicherer aussieht als die reale Anlage.

Beispiel aus der Steuerung: richtige Sicherheitsfunktion, falscher Effekt im Betrieb

Ein anderer Klassiker: An einer Anlage werden eine Sicherheitsfunktion, eine Verriegelung, ein manueller Reset und eine Wiederanlaufsperre sauber umgesetzt. Technisch kann das völlig korrekt sein. Das Problem entsteht erst im Ablauf. Wenn jede kleine Intervention länger dauert, der Bediener aus dem Arbeitsrhythmus gerissen wird und nach jeder Öffnung mehrere Schritte nötig sind, wächst der Druck, Abkürzungen zu suchen.

Dann taucht das auf, worüber in Besprechungen gern zu leise gesprochen wird: der reflexhafte Reset ohne echte Zonenprüfung, der Griff zur Überbrückung, das improvisierte Beschleunigen des Wiederanlaufs. Die Sicherheitsfunktion ist dann nicht das Problem. Das Problem ist, dass ihre Wirkung auf den realen Arbeitsablauf nicht mitbewertet wurde. Genau das ist ein sekundäres Risiko auf der Ebene Mensch, Verhalten und Organisation.

Elektrisches Beispiel: lokal verbessert, global verschlechtert

Auch im elektrischen Bereich passiert das schneller, als vielen lieb ist. Angenommen, an einem Teil der Maschine wird ein Problem erkannt und jemand ergänzt dort selektiv den Potentialausgleich. Die Absicht ist gut: bessere elektrische Sicherheit, geringeres Risiko eines elektrischen Schlags.

Wenn der Potentialausgleich aber nur für einen Ausschnitt des Systems verändert wird, kann eine neue Situation entstehen. Ein Maschinenteil bekommt ein anderes Bezugspotential als der Rest. Bei einem Fehler oder in einem Übergangszustand steigt das Risiko ungewollter Potentialdifferenzen. Eine Person, die gleichzeitig zwei Teile berührt, gerät damit unter Umständen in ein gefährlicheres Szenario als vor der vermeintlichen Verbesserung. Auch hier gilt: Die Schutzmaßnahme war nicht per se falsch. Falsch war der fragmentierte Blick auf das Gesamtsystem.

Was diese Beispiele verbindet, ist simpel: Jemand hat etwas getan, das vernünftig aussah. Eine Schutzeinrichtung ergänzt. Eine Sicherheitsfunktion verbessert. Eine elektrische Maßnahme umgesetzt. Das Problem war nicht die Existenz der Schutzmaßnahme. Das Problem war, dass niemand geprüft hat, was sie mit dem restlichen System Mensch-Maschine-Energie-Prozess macht.

Genau deshalb reicht eine Tabelle mit den Spalten Gefährdung, Schutzmaßnahme und Ergebnis nach Risikominderung nicht aus. Sie zeigt oft nur den Endzustand. Sie fragt nicht konsequent: Was hat sich außerdem verändert? Wo entsteht ein neues sekundäres Risiko? Muss erneut bewertet werden? Wenn das fehlt, wird aus Risikobeurteilung schnell Schönfärberei mit Tabellenoptik.

Ohne Audit Trail bleibt nur die letzte Version

Der Audit Trail, also die Entscheidungsspur, ist kein Zusatz für Perfektionisten. Er ist der Beleg, dass im Projekt tatsächlich nachgedacht wurde. In der Praxis fehlt selten das Ergebnis. Eine Tabelle gibt es fast immer. Punkte gibt es auch. Schutzmaßnahmen ebenfalls. Das eigentliche Loch entsteht später: Wer hat die Einstufung geändert? Wann? Warum? Auf welcher Basis wurde ein Restrisiko akzeptiert? Warum wurde hier eine Sicherheitsfunktion verlangt und dort nur Information für die Nutzung?

Wenn die Risikoeinstufung plötzlich niedriger ist

Ein typischer Fall: In der letzten Version steht bei einer Gefährdungssituation nicht mehr mittleres, sondern niedriges Risiko. Akzeptiert. Fertig. Nur weiß vier Wochen später niemand mehr, ob das an einer echten Schutzmaßnahme lag, an einer geänderten Annahme, an einer besseren Szenarienbeschreibung oder schlicht daran, dass jemand den Vorgang abschließen wollte. Ohne Audit Trail sieht die Datei ordentlich aus. Technisch bleibt sie schwach.

Wenn akzeptabel im Feld steht, aber nicht im Kopf

Noch häufiger: Es steht einfach akzeptabel da. Nur worauf stützt sich das? Auf seltene Exposition? Auf geringe Schadensschwere? Auf kontrollierte Bedingungen? Auf geschulte Personen? Oder nur auf einen niedrigen Zahlenwert, den niemand mehr hinterfragt hat? Ohne Audit Trail gibt es keinen sauberen Unterschied zwischen begründeter Ingenieurentscheidung und später Kosmetik.

Wenn PL d nur aus Gewohnheit eingetragen wurde

Das ist einer der gefährlichsten Fälle. Im Dokument steht eine Sicherheitsfunktion nach ISO 13849, dazu PL d. Auf den ersten Blick wirkt das professionell. Nur kann später oft niemand mehr erklären, welche Sicherheitsfunktion genau gemeint war, was sie überwacht, was sie sicher abschaltet und warum gerade PL d gefordert wurde. War das Ergebnis einer nachvollziehbaren Ableitung aus der Risikobeurteilung? Oder nur Branchenroutine? Ohne Audit Trail bleibt das offen. Und offen ist in diesem Zusammenhang schlicht zu wenig.

Excel kann Werte überschreiben, Zellen färben und Kommentare aufnehmen. Was Excel schlecht kann, ist die Entwicklung einer Entscheidung belastbar festhalten. Genau deshalb bleibt bei vielen Tabellen am Ende nur die letzte Version sichtbar. Aber eine gute Dokumentation der Risikobeurteilung muss mehr können als eine letzte Version zeigen. Sie muss den Weg dorthin erhalten.

Beispiel einer Risikobeurteilung nach ISO 12100: Eine Verpackungsstation in der Praxis

Damit das Ganze nicht in Theorie stecken bleibt, nehmen wir eine automatisierte Verpackungsstation. Keine abstrakte Maschine, sondern eine reale Anlage mit gefährlichen Bewegungen, Bedienereingriffen, Beseitigung von Staus, Instandhaltungsaufgaben, Zugang zu elektrischer und pneumatischer Energie sowie Sicherheitsfunktionen, die von der Steuerungslogik abhängen.

In einer belastbaren Analyse reicht dafür kein pauschaler Eintrag wie mechanische Gefährdung im Arbeitsbereich. In dem hier beschriebenen Beispiel wurden 16 getrennte Gefährdungssituationen bewertet: 13 aufgabenbezogene Szenarien und 3 gefährliche Ereignisse nach der Logik von ISO 12100.

Was tatsächlich bewertet wurde

  • kleine Eingriffe während des Automatikbetriebs,
  • das Beseitigen von Staus,
  • das Einstellen von Schutzeinrichtungen,
  • Funktionstests,
  • das Trennen elektrischer und pneumatischer Energie,
  • der Wechsel von Verschleißteilen,
  • die Fehlerdiagnose an elektrischer Ausrüstung,
  • unbeabsichtigter Anlauf,
  • Auswurf von Teilen,
  • Freisetzung pneumatischer Energie.

Genau dieses Auflösen in konkrete Aufgaben macht den Unterschied. Eine Maschine lässt sich nicht ehrlich allgemein bewerten. Bewertet wird immer die Beziehung zwischen Mensch und Maschine bei einer konkreten Tätigkeit, in einer konkreten Zone, unter konkreten Zugangsbedingungen.

Was das Beispiel gezeigt hat

  1. Das Hauptproblem lag nicht im bloßen Vorhandensein gefährlicher Bewegung. Kritisch wurde es in dem Moment, in dem Menschen für Eingriffe, Diagnose oder Beseitigung von Staus Zugang brauchten. Das ist ein typischer Befund, der in groben Tabellen gern untergeht.
  2. Nicht jede Gefährdungssituation musste gleich behandelt werden. Einige Szenarien konnten als niedriges Risiko akzeptiert werden, aber nur unter klar dokumentierten Randbedingungen: geringe Expositionshäufigkeit, begrenzte Aufgabe, überschaubare Schadensschwere, kontrollierte Ausführung und eindeutige Rolle der nutzenden Person.
  3. Mehrere Szenarien waren ohne echte Risikominderung nicht glaubwürdig abschließbar. Dazu gehörten kleine Eingriffe im geschützten Bereich, Beseitigung von Staus, unbeabsichtigter Wiederanlauf, elektrischer Zugang bei Energietrennung und Fehlerdiagnose. Hier reichte eben nicht Schutzeinrichtung plus Hinweis in der Anleitung. Hier musste beschrieben werden, welche Sicherheitsfunktion das Risiko tatsächlich reduziert, wann sie den gefährlichen Zustand verhindert, wie die Verriegelung wirkt, wann ein manueller Reset nötig ist und wie die Wiederanlaufsperre umgesetzt ist.
  4. Das Restrisiko war nur dort belastbar, wo die Begründung sichtbar blieb. Ein eingetragenes akzeptables Restrisiko ohne nachvollziehbare Herleitung ist nichts weiter als eine Behauptung in Tabellenform.
  5. Mehrere Schutzmaßnahmen erzeugten neue Prüfpflichten. Nach dem Einbau von Schutzeinrichtungen und nach Änderungen der Steuerungslogik musste jeweils geprüft werden, ob ein sekundäres Risiko entstand. Genau dieser Zwischenschritt fehlte in vereinfachten Vorlagen regelmäßig.
  6. Der Audit Trail zeigte, wer was entschieden hat. Erst dadurch wurde sichtbar, warum bestimmte Szenarien akzeptiert wurden, warum andere in die Risikominderung gingen und weshalb bei einzelnen Sicherheitsfunktionen eine höhere Zuverlässigkeit gefordert wurde.

Das ist der eigentliche Wert eines guten Beispiels. Nicht die Anzahl der Zeilen beeindruckt. Entscheidend ist, dass der Prozess lesbar wird: Ausgangsannahmen, Aufgaben, Gefährdung, Gefährdungssituation, gefährliches Ereignis, Auswahl der Schutzmaßnahme, Prüfung auf sekundäres Risiko, Neubewertung und Begründung des Restrisikos.

Woran Sie eine belastbare Dokumentation der Risikobeurteilung erkennen

Eine gute Dokumentation der Risikobeurteilung ist keine Ansammlung von Feldern, die am Ende grün aussehen. Sie ist ein technischer Nachweis. Sie muss Monate später noch rekonstruierbar, prüfbar und verteidigbar sein.

  • Die Grenzen der Maschine und die realen Aufgaben sind am Anfang sauber festgelegt.
  • Gefährdungen werden nicht pauschal, sondern über konkrete Gefährdungssituationen und gefährliche Ereignisse bewertet.
  • Die Reihenfolge der Risikominderung nach ISO 12100 ist erkennbar und nicht übersprungen.
  • Jede Schutzmaßnahme wird auf sekundäres Risiko geprüft.
  • Das Restrisiko wird begründet und nicht nur markiert.
  • Sicherheitsfunktion, Verriegelung, manueller Reset und Wiederanlaufsperre sind dort beschrieben, wo sie für die Risikominderung tatsächlich relevant sind.
  • Der Audit Trail macht Änderungen, Entscheidungen und Freigaben nachvollziehbar.

Die unbequeme Wahrheit ist einfach: Eine schicke Tabelle kann eine schwache Risikobeurteilung sehr gut verkleiden. Eine belastbare Risikobeurteilung kann auch nüchtern aussehen. Entscheidend ist nicht das Werkzeug, sondern ob das Werkzeug die Logik trägt. Excel kann als Arbeitsmittel dienen. Eine Safety Software kann den Prozess besser führen. Aber beides nimmt niemandem das Denken ab.

Wenn Gefährdung, Gefährdungssituation, Schutzmaßnahme, sekundäres Risiko, Restrisiko und Audit Trail sauber zusammenpassen, dann haben Sie mehr als eine Liste. Dann haben Sie eine Dokumentation der Risikobeurteilung, die sich technisch, logisch und im Audit verteidigen lässt. Und genau das ist der Maßstab. Nicht die Tabellenoptik.

Häufig gestellte Fragen

Was sollte eine Risikobeurteilung nach ISO 12100 enthalten?

Ein gutes Beispiel für die Risikobeurteilung nach ISO 12100 zeigt nicht nur eine Tabelle der Gefährdungen, sondern den gesamten Entscheidungsablauf gemäß ISO 12100.

  • Grenzen der Maschine und Phasen des Lebenszyklus
  • Aufgaben des Bedieners, des Einrichters sowie bei Instandhaltung und Reinigung
  • Gefährdungen, gefährliche Situationen und gefährliche Ereignisse
  • Risikoeinschätzung, Risikominderung und Restrisiko
  • die angewandten Schutzmaßnahmen sowie die Begründung der Entscheidung
Reicht eine Excel-Tabelle als Dokumentation der Risikobeurteilung aus?

Excel allein kann ein Arbeitswerkzeug sein, ist aber nicht automatisch eine Dokumentation der Risikobeurteilung. Die Anforderung der ISO 12100 bezieht sich auf einen dokumentierten Prozess, der sich rekonstruieren, nachverfolgen und verifizieren lässt.

Wenn das Tabellenblatt nicht die Annahmen, die analysierten Aufgaben, die Reihenfolge bei der Auswahl von Schutzmaßnahmen, das sekundäre Risiko und die Personen zeigt, die die Entscheidungen freigeben, bleibt es nur eine Sammlung von Arbeitsdaten.

Welche Reihenfolge der Risikominderungsmaßnahmen fordert ISO 12100?

ISO 12100 verlangt, die Reihenfolge der Risikominderung einzuhalten. Zuerst wird die inhärent sichere Konstruktion angewendet, dann technische Schutzmaßnahmen und erst ganz am Ende Benutzerinformation.

  • 1. Inhärent sichere Konstruktion
  • 2. Technische Schutzmaßnahmen und ergänzende Schutzmaßnahmen
  • 3. Benutzerinformation, einschließlich Warnhinweisen und Verfahren

Der direkte Sprung von einer Gefährdung unmittelbar zur Benutzerinformation oder allein zu einer Schutzeinrichtung, ohne die vorhergehenden Schritte zu prüfen, schwächt die Logik der Risikobeurteilung.

Was ist das Sekundärrisiko nach Anwendung einer Schutzmaßnahme?

Ein sekundäres Risiko ist ein neues oder verändertes Risiko, das nach Anwendung einer Schutzmaßnahme entsteht. Eine Abdeckung, eine Verriegelung, ein manueller Reset oder eine Änderung der Steuerlogik können eine Gefährdung verringern und gleichzeitig den Zugang, die Sicht, die Ergonomie oder das Verhalten des Bedieners verschlechtern.

Deshalb muss nach jeder Risikominderung die Aufgabe unter realen Arbeitsbedingungen erneut bewertet werden und nicht nur die Schutzmaßnahme in die Tabelle eingetragen werden.

Kann man in der Risikobeurteilung PL d ohne Begründung angeben?

PL d sollte nicht „aus Gewohnheit“ eingetragen werden. Wenn die Risikobeurteilung den Bedarf an einer Sicherheitsfunktion des Steuerungssystems aufzeigt, ist der erforderliche Performance Level auf Grundlage der Funktion, des Verwendungsszenarios und der Fehlerfolgen zu begründen und gemäß PN-EN ISO 13849-1 festzulegen.

In der Dokumentation sollte nachvollziehbar dargestellt werden, wer die Entscheidung getroffen hat, auf welchen Annahmen sie beruhte und welches Risiko die betreffende Sicherheitsfunktion reduzieren sollte.

Bereit für den Wechsel?

Erstellen Sie ein Konto und generieren Sie konforme Dokumentation in 15 Minuten.

Kostenlosen Test starten Keine Kreditkarte erforderlich • 14 Tage kostenlos