Rollenbasierte Prozesssteuerung: Wie Befugnisse den Ablauf bestimmen

Was rollenbasierte Prozesssteuerung bedeutet

Ein Rollenname muss im Betrieb in konkrete Befugnisse übersetzt werden. Für jede Funktion ist festzulegen, welche Aufgaben und Entscheidungen sie an welchen Gegenständen ausführen darf und welche Verantwortung damit verbunden ist.

Im Unterschied zur allgemeinen Zugriffskontrolle betrachtet sie nicht nur, ob jemand eine Seite öffnen oder einen Datensatz lesen darf. Entscheidend ist die Prozesswirkung: Wer darf eine Aufgabe übernehmen, einen Messwert bestätigen, Material übergeben, Nacharbeit verlangen, einen Zustand sperren oder eine Freigabe erteilen?

Task Orchestration erzeugt und verteilt konkrete Aufgaben anhand des Prozesszustands. Die rollenbasierte Prozesssteuerung bestimmt dabei, welche Personen für die jeweilige Aufgabe und ihre möglichen Ergebnisse tatsächlich in Betracht kommen.

Beispiel: Die Vertretung endet während einer offenen Aufgabe

In einem fiktiven Fall vertritt P7 die Prüfrolle am Standort Nord bis 14:00 Uhr. Um 13:50 Uhr übernimmt P7 eine Aufgabe. Um 14:05 Uhr versucht die Person, das Prüfergebnis freizugeben. Für dieses Beispiel ist festgelegt, dass die Vertretung ab 14:00 Uhr keine neue Freigabe mehr erlaubt.

Die frühere Übernahmeberechtigung genügt somit nicht. Bei der Freigabe muss die dann geltende Befugnis geprüft werden. Die Anwendung soll die Aktion mit einem verständlichen Grund ablehnen und den vorgesehenen Übergabeweg anbieten. Ein noch geöffnetes Fenster darf die abgelaufene Befugnis nicht verlängern.

Die bisherigen Eingaben bleiben P7 und dem damaligen Kontext zugeordnet. Die offene Aufgabe geht nach der festgelegten Übergangsregel an eine weiter berechtigte Person. Diese erhält durch die Übernahme nicht automatisch das Recht, frühere Angaben als eigene Beobachtung auszugeben.

Ob der Entzug im Moment der Aktion tatsächlich greift, muss technisch geprüft werden. Für einen Vergleich von Compliance-Software eignet sich dieser Fall als konkreter Berechtigungsnachweis: Entscheidend ist die Ablehnung der nicht mehr zulässigen Aktion, nicht allein die angezeigte Rollenbezeichnung.

Berechtigungen werden im Moment der Prozesshandlung geprüft

Eine Anmeldung zu Beginn des Arbeitstags beweist nicht, dass jede spätere Handlung zulässig ist. Berechtigungen können sich ändern, eine Vertretung kann auslaufen oder der Prozessgegenstand kann in einen Bereich wechseln, für den die aktive Rolle nicht gilt.

Die Prüfung sollte deshalb an der fachlich wirksamen Aktion erfolgen. Vor Freigabe, Sperrung, Übergabe oder Korrektur wird bewertet, ob Identität, Rolle, Geltungsbereich und gegebenenfalls Funktionstrennung weiterhin passen.

Wird die Handlung abgelehnt, bleibt auch dieser Versuch angemessen nachvollziehbar. Das System sollte der Person verständlich mitteilen, welche Voraussetzung fehlt, ohne dadurch vertrauliche Berechtigungsstrukturen unnötig offenzulegen.

Eine Rolle beschreibt eine betriebliche Funktion

Eine Rolle ist keine bloße Stellenbezeichnung. Sie beschreibt eine Funktion im Prozess, mit der bestimmte Verantwortungen und Befugnisse verbunden sind. Beispiele sind ausführende Person, prüfende Rolle, Freigabeberechtigte, Lagerverantwortliche oder Systemadministration.

Das NIST-Modell für Role-Based Access Control ordnet Nutzer Rollen und Rollen wiederum Berechtigungen zu. Dadurch werden Berechtigungen nicht für jede Person einzeln verwaltet, sondern an Funktionen der Organisation gebunden.^[1]

Für reale Betriebsprozesse reicht ein Rollenname dennoch nicht. Die Rolle muss fachlich bestimmt sein: Für welche Tätigkeit gilt sie? Auf welche Objekte, Standorte oder Produktgruppen bezieht sie sich? Welche Qualifikation wird vorausgesetzt? Und darf sie nur ausführen oder auch das eigene Ergebnis prüfen?

Berechtigungen beziehen sich auf konkrete Handlungen

Eine Rolle sollte nicht pauschal „Vollzugriff“ erhalten, wenn sie tatsächlich nur wenige Prozesshandlungen benötigt. Berechtigungen lassen sich präziser als Verbindung aus Handlung und Gegenstand beschreiben: eine Aufgabe starten, einen Messwert erfassen, einen Bestand bewegen, einen Prüfstatus setzen oder eine bestimmte Charge freigeben.

Das XACML-Profil für Core und Hierarchical RBAC beschreibt Rollen als organisatorische Funktionen mit zugeordneten Verantwortungen und Berechtigungen. Es behandelt zudem Rollenhierarchien und Berechtigungen, für die mehrere Rollen gleichzeitig erforderlich sein können.^[2]

Die technische Prüfung sollte deshalb nicht nur fragen: „Hat die Person die Rolle Qualitätssicherung?“ Sie muss auch die beabsichtigte Handlung, das betroffene Objekt und gegebenenfalls zusätzliche Bedingungen berücksichtigen. Eine Berechtigung zur Dokumentenprüfung ist nicht automatisch eine Freigabeberechtigung für eine Produktionscharge.

Lesen, bearbeiten und fachlich entscheiden sind verschiedene Rechte

Viele Systeme beschränken Berechtigungen auf Lesen, Schreiben und Löschen. Für kontrollierte Prozesse ist diese Einteilung zu grob. Das Eintragen eines Ergebnisses, die Bestätigung seiner Prüfung und die Freigabe eines Folgezustands besitzen unterschiedliche fachliche Bedeutungen.

Eine Person kann einen Messwert erfassen dürfen, ohne ihn abschließend zu prüfen. Eine andere Rolle kann die Plausibilität bestätigen, aber keine Charge freigeben. Erst eine ausdrücklich dazu befugte Funktion darf den Status setzen, der Verwendung, Weiterverarbeitung oder Abgabe ermöglicht.

Ein Approval Workflow führt solche Prüfung, Rückgabe und Freigabe als eigenen Entscheidungsablauf. Die rollenbasierte Steuerung liefert dafür die zulässigen Beteiligten und verhindert, dass eine technisch mögliche Bedienhandlung automatisch als fachlich wirksame Entscheidung gilt.

Eine Rolle gilt nicht zwingend in jedem Kontext

Dieselbe Person kann mehrere Rollen besitzen. Welche davon sie in einer konkreten Situation ausüben darf, hängt häufig vom betrieblichen Kontext ab. Standort, Bereich, Produktgruppe, Prozessphase, Schicht oder organisatorische Zuordnung können den zulässigen Umfang begrenzen.

Eine Lagerrolle am Standort A muss nicht zu Materialbewegungen am Standort B berechtigen. Eine Person kann für eine Produktgruppe freigabeberechtigt sein, ohne dieselbe Verantwortung für andere Produkte zu tragen. Auch die Rolle eines Vertreters kann nur für einen bestimmten Zeitraum aktiviert werden.

Die Prüfung verbindet deshalb Identität, Rolle und Geltungsbereich. Sie darf nicht allein auf einen globalen Rollennamen vertrauen. Sonst wachsen Rollen mit der Zeit zu weit und verleihen Befugnisse, die für die konkrete Aufgabe nie vorgesehen waren.

Rollen und situative Attribute können zusammenwirken

Ein rein rollenbasiertes Modell stößt an Grenzen, wenn jede betriebliche Besonderheit eine eigene Rolle erzeugt. Aus „Prüfer“ würden dann zahlreiche Varianten für Standort, Produktgruppe, Schicht und Prozessphase. Eine solche Rollenexplosion wird schwer verständlich und fehleranfällig.

Stattdessen kann die Rolle die grundsätzliche Funktion beschreiben, während Attribute ihren aktuellen Geltungsbereich eingrenzen. Die Person besitzt beispielsweise die Rolle „Prüfung“; zusätzlich wird bewertet, ob sie für den betroffenen Standort qualifiziert, der Produktgruppe zugeordnet und nicht selbst an der Ausführung beteiligt ist.

Die Entscheidung bleibt dadurch nachvollziehbar: Rolle, Handlung, Objekt und angewandte Bedingungen werden gemeinsam betrachtet. Das System sollte jedoch vermeiden, fachliche Berechtigungen in undurchsichtigen Einzelregeln zu verstecken. Nutzer und Verantwortliche müssen verstehen können, warum eine Handlung erlaubt oder abgelehnt wurde.

Eine zugewiesene Rolle ersetzt keinen Qualifikationsnachweis

Eine organisatorische Rolle und die fachliche Eignung einer Person sind miteinander verbunden, aber nicht identisch. Für bestimmte Aufgaben können Schulung, Einweisung, Erfahrung, Zertifikat oder eine formale Benennung erforderlich sein.

Die Prozesssteuerung sollte prüfen können, ob die vorausgesetzte Qualifikation zum Zeitpunkt der Ausführung gültig ist. Läuft eine Schulung ab oder wird eine Berechtigung widerrufen, dürfen neue Aufgaben nicht weiterhin allein aufgrund einer alten Rollenzuweisung entstehen.

Digitale Arbeitsanweisungen stellen die zur Aufgabe passende freigegebene Ausführung bereit. Sie machen eine unqualifizierte Person jedoch nicht automatisch geeignet. Aufgabenführung und Berechtigungsprüfung erfüllen unterschiedliche Funktionen.

Funktionstrennung begrenzt unvereinbare Rollen

Rollenbasierte Steuerung soll nicht nur Befugnisse erteilen, sondern auch unzulässige Kombinationen verhindern. Wer einen kritischen Vorgang selbst ausgeführt hat, darf ihn je nach Prozess möglicherweise nicht unabhängig prüfen oder freigeben.

Im NIST-RBAC-Modell beschränkt statische Funktionstrennung die Zuweisung unvereinbarer Rollen. Dynamische Funktionstrennung begrenzt dagegen, welche Rollen eine Person innerhalb derselben Sitzung gleichzeitig aktivieren darf. Daraus folgt noch keine Prüfung aller früheren Handlungen an einer Charge.^[1]

Eine Regel wie „Wer ausgeführt hat, darf denselben Vorgang nicht unabhängig prüfen“ benötigt zusätzlich den Verlauf der konkreten Prozessinstanz. Diese verlaufsbezogene Funktionstrennung muss auch dann greifen, wenn Ausführung und Prüfung in unterschiedlichen Sitzungen stattfinden.

Die verlaufsbezogene Prüfung benötigt den realen Verlauf. Erst wenn bekannt ist, wer an der konkreten Charge, Aufgabe oder Dokumentversion beteiligt war, lässt sich beurteilen, ob eine spätere Prüfung unabhängig erfolgen kann. Eine bloße Rollenliste ohne Prozesskontext genügt dafür nicht.

MHRA Abschnitt 6.16 adressiert auch Interessenkonflikte bei der Systemadministration: Der Kreis der Personen mit Administratorzugang soll auf das für die Organisation mögliche Minimum begrenzt sein. Rechte etwa zur Datenlöschung, Datenbankänderung oder Systemkonfiguration sollen nicht bei Personen liegen, die unmittelbar an Erzeugung, Prüfung oder Freigabe der Daten beteiligt sind. Generische Administratorkonten sind nicht für die Routinenutzung vorgesehen; Administratoren benötigen individuell zuordenbare Zugangsdaten.^[7] Technische Administration ist damit von der Befugnis zu fachlichen Entscheidungen über diese Daten zu unterscheiden.

Aufgabenzuweisung und Ausführungsberechtigung müssen zusammenpassen

Eine Aufgabe kann zunächst einer Gruppe potentiell zuständiger Personen angeboten werden. Erst bei Übernahme wird sie einer tatsächlichen Bearbeitung zugeordnet. WS-HumanTask unterscheidet hierzu unter anderem potentielle und tatsächliche Eigentümer sowie weitere menschliche Rollen im Aufgabenlebenszyklus.^[3]

Weske beschreibt für Human-Interaction-Workflows die Architekturgrundlage dieser Auswahl: Die Workflow Engine kann organisatorische Informationen, Fähigkeiten und Kompetenzen nutzen, um Arbeit verfügbaren und geeigneten Personen anzubieten.^[8] Das unterstützt die Auswahl passender Beteiligter. Ob P7 später noch freigeben darf, ergibt sich jedoch nicht aus dem früheren Aufgabenangebot; dafür ist die hier beschriebene prozessbezogene Aktionsprüfung erforderlich.

Die Übernahme darf nur gelingen, wenn die Person im aktuellen Kontext berechtigt ist. Ändert sich ihre Rolle während einer bereits laufenden Aufgabe, benötigt der Prozess eine klare Regel: Darf sie abschließen, wird die Aufgabe angehalten oder muss sie kontrolliert neu zugewiesen werden?

Auch Delegation ist keine formlose Weitergabe. Die delegierende Person muss dazu befugt sein, die empfangende Person benötigt die erforderliche Rolle und der Wechsel bleibt mit Zeitpunkt und Grund sichtbar. Verantwortung darf nicht durch eine versteckte Umleitung verschwimmen.

Das Ende der Vertretung und offene Aufgaben gemeinsam regeln

Eine Vertretung braucht einen festgelegten Umfang: Zeitraum, Aufgabenarten, Standorte und gegebenenfalls ausgeschlossene Freigaben. Sie übernimmt nicht zwangsläufig sämtliche Befugnisse der vertretenen Person.

Für das Ende ist zu bestimmen, welche weiteren Aktionen untersagt sind und wie offene Aufgaben übergeben werden. Ein automatischer Entzug ist eine mögliche Umsetzung, deren rechtzeitige Wirkung einschließlich bestehender Sitzungen geprüft werden muss.

Rollenänderungen benötigen einen kontrollierten Lebenszyklus

Neue Rollen und Berechtigungen sollten nicht unmittelbar durch dieselbe Person wirksam werden, die sie beantragt. Je nach Risiko können Antrag, Prüfung, Genehmigung, Aktivierung und regelmäßige Überprüfung getrennte Schritte bilden.

Bei Eintritt, Funktionswechsel und Ausscheiden müssen Zuweisungen zeitnah angepasst werden. Besonders kritisch sind angesammelte Altberechtigungen: Eine Person wechselt die Funktion, behält aber Rechte aus ihrer früheren Tätigkeit und kann dadurch unbeabsichtigt unvereinbare Rollen kombinieren.

Die Workflow Engine kann Aufgaben und Zustände eines solchen Änderungsprozesses kontrollieren. Die fachliche Entscheidung, welche Rolle erforderlich und mit welcher anderen Funktion vereinbar ist, bleibt jedoch eine organisatorische Verantwortung.

MHRA Abschnitt 6.16 konkretisiert dies für Systeme mit GxP-Daten: Unterstützt das System individuelle Benutzerzugänge, sind diese zu nutzen. Neben den aktuellen Zugriffsstufen müssen auch historische Zugriffsrechte nachweisbar sein; führt das System diese Historie nicht, ist sie außerhalb des Systems aufzuzeichnen.^[7] Für P7 muss sich damit später feststellen lassen, welche Zugriffsrechte um 13:50 Uhr galten und welche um 14:05 Uhr nicht mehr bestanden. Eine Liste der heutigen Rollenzuweisungen würde dafür nicht genügen.

Notfallberechtigungen müssen Ausnahmehandlungen bleiben

In außergewöhnlichen Situationen kann eine normalerweise nicht verfügbare Handlung dringend erforderlich sein. Ein bloßes dauerhaftes Administratorkonto wäre dafür zu weitreichend. Besser ist eine eng begrenzte Notfallberechtigung, die nur für einen bestimmten Zweck und Zeitraum aktiviert wird.

Die Aktivierung kann eine Begründung, eine zusätzliche Bestätigung und eine unmittelbare Benachrichtigung verantwortlicher Stellen verlangen. Jede unter dieser Berechtigung ausgeführte Prozesshandlung wird besonders kenntlich gemacht und anschließend überprüft.

Ein Notfallzugriff setzt fachliche Voraussetzungen nicht außer Kraft. Er darf fehlende Qualifikation oder unvereinbare Verantwortungen nicht beliebig überwinden. Für das Ende der Situation muss festgelegt sein, wie die zusätzliche Befugnis entzogen und der Entzug wirksam geprüft wird. Offene Aufgaben sind anschließend anhand der regulären Rollen neu zu bewerten.

Regulierte Systeme verlangen kontrollierte Befugnisse

21 CFR Part 11 verlangt für geschlossene Systeme in seinem Anwendungsbereich unter anderem die Begrenzung des Systemzugangs auf autorisierte Personen sowie Prüfungen, die sicherstellen, dass nur berechtigte Personen das System nutzen, Aufzeichnungen elektronisch signieren, auf Ein- oder Ausgabegeräte zugreifen oder bestimmte Operationen ausführen können.^[4]

EU-GMP Annex 11 verlangt im GMP-Umfeld ebenfalls, den Zugang zu computergestützten Systemen auf autorisierte Personen zu beschränken und Erteilung, Änderung sowie Entzug von Zugangsberechtigungen aufzuzeichnen.^[5]

Diese Anforderungen schreiben nicht pauschal ein bestimmtes Rollenmodell für jeden Betrieb vor. Die konkrete Ausgestaltung richtet sich nach System, Prozess, Risiko und anwendbarem Rechtsrahmen. Rollenbasierte Prozesssteuerung kann die Umsetzung unterstützen, ersetzt aber weder die fachliche Rollenfestlegung noch die Validierung des Systems.

Was rollenbasierte Prozesssteuerung nicht allein leistet

• Eine Rolle beweist keine Qualifikation. Fachliche Eignung und Gültigkeit müssen gesondert bestimmt werden.
• Eine Berechtigung beweist keine ausgeführte Handlung. Organisatorische Verantwortung kann bereits durch eine Funktion oder Aufgabenzuweisung bestehen. Wer tatsächlich gehandelt hat und welche Wirkung daraus entstand, muss der konkrete Vorgang erkennen lassen.
• RBAC ersetzt nicht jeden Kontext. Standort, Objekt, Zeit und weitere Attribute können zusätzlich erforderlich sein.
• Eine Rollenzuweisung darf nicht unbegrenzt fortbestehen. Änderungen, Vertretungen und Entzug benötigen einen kontrollierten Lebenszyklus.

Aufsichtsbefund

Befund: Die FDA beanstandete gemeinsame Zugangsdaten für ein HPLC-System sowie Administratorrechte, mit denen Analysten Daten ändern und löschen konnten. Darüber hinaus fanden die Inspektoren gelöschte GC-Analysesequenzen im Papierkorb.^[6]

Einordnung: Eine Rollenbeschreibung muss sich in den tatsächlichen Systemrechten wiederfinden. Persönliche Zugänge machen Handlungen zuordenbar; getrennte Berechtigungen begrenzen, was ausführende Personen im System verändern oder löschen können.

Prüffrage: Haben Personen, die messen, zugleich Rechte zum Löschen?

Schreiben vom 14.04.2026 · Quelle geprüft am 18.09.2026.

Dargestellt ist der ausgewählte Behördenbefund zum Zeitpunkt des Schreibens. Unternehmensantworten und spätere Entwicklungen werden hier nicht bewertet; die Darstellung beschreibt keinen aktuellen Compliance-Status.

Die Übernahme um 13:50 Uhr erlaubt nicht jede spätere Aktion

Die Vertretung im Beispiel endet, während die Aufgabe noch offen ist. Ein tragfähiger Ablauf prüft daher die neue Freigabehandlung und führt bei fehlender Befugnis in einen geregelten Übergang.

Rollenbasierte Prozesssteuerung verbindet Funktion, Geltungsbereich und Aktionszeitpunkt. Ihre Qualität zeigt sich auch an einer begründeten Ablehnung, bei der bisherige Arbeit erhalten bleibt und die nächste Zuständigkeit klar wird.