ISO 27001: Was sind Interessierte Parteien?

Bei der Ableitung des Kontexts der Organisation schauen Sie von weit oben auf Ihr Unternehmen und fragt: Aus welchen Richtungen wirkt in Sachen Informationssicherheit etwas auf Ihr Unternehmen ein?

Im nächsten Schritt wird es eine Stufe konkreter. Jetzt geht es nicht mehr nur um Richtungen, sondern um die handelnden Akteure, an denen sich diese Erwartungen festmachen. Genau das meint ISO 27001 mit den „interessierten Parteien“. Abschnitt 4.2 verlangt, dass die Organisation die für das ISMS relevanten interessierten Parteien und deren relevante Anforderungen bestimmt und die Informationen darüber überwacht und überprüft.

Praktisch übersetzt heißt das: Sie fragen nicht mehr nur „Woher kommt der Druck?“, sondern „Wer genau will hier eigentlich etwas von uns?“

Mitarbeiter, Kunden, Eigentümer, Aufsichtsbehörden, Lieferanten, Partner oder Zertifizierer sind typische Kandidaten.

Die kurze Antwort

Interessierte Parteien sind die Personen oder Organisationen, deren Anforderungen für Ihr ISMS relevant sind. Es geht also nicht darum, eine endlose Stakeholder-Sammlung zu bauen, sondern die relevanten Akteure herauszufiltern und zu verstehen, welche Anforderungen sie mit Blick auf Informationssicherheit an Ihr Unternehmen herantragen. Nicht jeder Akteur und nicht jede Anforderung muss in das Managementsystem hineinreichen, sondern nur die relevanten. Seit 2022 fordert die ISO 27001 auch, dass genau die relevanten der gefunden Akteure und Anforderungen als solche kenntlich sein sollen.

Die Kundengruppe, die lautstark über zu schwache Sicherheit bei Ihnen lamentiert - aber in Summe nur 20 EUR pro Jahr bei Ihnen ausgibt, ist das dann vermutlich nicht.

Der Unterschied zum Kontext ist damit sauber: Der Kontext beschreibt die Kräfte und Rahmenbedingungen. Die interessierten Parteien machen diese Kräfte konkret. Aus „gesetzlicher Druck“ werden etwa Gesetzgeber, Aufsichtsbehörden oder Gerichte. Aus „Marktdruck“ werden Kunden, Ausschreibungsstellen oder große Partner. Aus „interne Kultur“ werden Mitarbeiter, Führungskräfte oder Gesellschafter.

Abschnitt 4.2 baut genau auf 4.1 auf.

Wer kann eine interessierte Partei sein?

Die einfache Antwort lautet: jede Person oder Organisation, die Ihr Unternehmen mit Blick auf das ISMS beeinflusst, von dessen Entscheidungen betroffen ist oder Anforderungen mitbringt, die für Informationssicherheit relevant werden. Typische Beispiele sind etwa Kunden, Eigentümer, Personen in der Organisation, Lieferanten, Banken, Gesetzgeber, Gewerkschaften, Partner und die Gesellschaft allgemein.

Für die Praxis in ISO 27001 sind meist diese Gruppen besonders spannend: Mitarbeiter, Kunden, Aufsichts- und Gesetzgebungsseite, Lieferanten und Dienstleister, Gesellschafter oder Geschäftsführung, teilweise auch Versicherer, Zertifizierer oder Banken. Und in manchen Fällen auch Cyberkriminelle (diese haben auch Erwartungen an Ihre Sicherheitsleistung - nur eben in die andere Richtung).

Nicht weil jede dieser Gruppen immer gleich wichtig wäre, sondern weil von dort häufig Anforderungen an Vertraulichkeit, Integrität, Verfügbarkeit, Nachweisbarkeit oder Vertragstreue kommen.

Was wollen diese Parteien typischerweise?

Mitarbeiter erwarten oft, dass mit ihren Personaldaten, Bewerbungsunterlagen, Gehaltsinformationen oder Gesundheitsbezügen sauber umgegangen wird. Datenschutzrecht ist dafür ein sehr handfester Treiber: Die DSGVO schützt personenbezogene Daten und verpflichtet Unternehmen zu geeigneten Schutzmaßnahmen.

Kunden erwarten meist etwas sehr Bodenständiges: dass ihre Daten vertraulich bleiben, Systeme verfügbar sind, Projektinformationen nicht verloren gehen und Sicherheitszusagen eingehalten werden. In der Praxis materialisiert sich das oft über Verträge, NDAs, AV-Verträge, Sicherheitsanhänge, Auditrechte oder Fragebögen.

Gesetzgeber und Aufsichtsbehörden bringen andere Erwartungen mit: Compliance, Meldefähigkeit, dokumentierte Schutzmaßnahmen und im Zweifel belastbare Nachweise. Je nach Unternehmen können Datenschutzrecht, branchenspezifische Vorgaben oder Cybersicherheitsregime eine Rolle spielen. Auf EU-Ebene setzt NIS2 einen gemeinsamen Rahmen für Cyber-Risikomanagement und Meldepflichten in relevanten Sektoren; in Deutschland weist das BSI darauf hin, dass mit dem neuen BSIG und dem NIS-2-Umsetzungsgesetz deutlich mehr Unternehmen gesetzliche Anforderungen treffen können.

Eigentümer, Geschäftsführung oder Gesellschafter erwarten typischerweise, dass Informationssicherheit nicht nur korrekt aussieht, sondern das Unternehmen stabil hält: keine peinlichen Vorfälle, keine unnötigen Ausfälle, keine vermeidbaren Haftungs- oder Reputationsschäden.

Auch Lieferanten und Partner können relevante Anforderungen einbringen, etwa über sichere Schnittstellen, klare Verantwortlichkeiten, die Nutzung von erbrachten Dienstleistungen gem Vertrag, die Einhaltung von Löschzusagen oder abgestimmte Reaktionswege.

Der häufigste Denkfehler

Der häufigste Denkfehler lautet: „Interessierte Parteien sind einfach eine hübsche Stakeholderliste.“

Abschnitt 4.2 verlangt nicht nur Namen, sondern auch die relevanten Anforderungen dieser Parteien und die laufende Überwachung und Überprüfung dieser Informationen. Eine bloße Tabelle mit „Kunden, Mitarbeiter, Behörden“ ist deshalb noch kein belastbares Ergebnis. Entscheidend ist, ob Sie daraus tatsächlich ableiten, was Ihr ISMS berücksichtigen muss.

Wie findet man die interessierten Parteien praktisch?

Am einfachsten gelingt das, wenn Sie vom eben beschriebenen Kontext ausgehen und jede Einflussrichtung einmal in konkrete Akteure übersetzen. Aus „gesetzlich“ werden etwa Datenschutzaufsicht, Gesetzgeber oder branchenspezifische Aufsicht. Aus „Markt“ werden Kunden, potenzielle Neukunden oder Ausschreibungsstellen. Aus „intern“ werden Mitarbeiter, Führungskräfte oder Gesellschafter. Aus „Lieferkette“ werden Cloud-Anbieter, MSPs oder andere kritische Partner.

Ein guter Praxistest lautet: Wenn diese Partei morgen unzufrieden wäre oder strengere Anforderungen stellt, würde das unser ISMS oder unsere Informationssicherheit spürbar betreffen? Wenn die Antwort ja ist, lohnt sich ein genauerer Blick.

Was hält man dann fest?

Es reicht meist völlig, je interessierter Partei drei Dinge sauber festzuhalten: Wer ist es? Was erwartet sie? Und warum ist das für das ISMS relevant? Daraus lässt sich oft schon direkt ableiten, ob Anforderungen in Richtlinien, Verträgen, technischen Maßnahmen, Schulungen oder Prozessen landen müssen.

Beispiele wären etwa:

• Mitarbeiter: Vertraulichkeit ihrer Personaldaten, verlässliche Zugriffssteuerung, sichere Arbeitsmittel.
• Kunden: Vertraulichkeit von Projekt- und Kundendaten, Verfügbarkeit vereinbarter Systeme, Einhaltung vertraglicher Sicherheitszusagen.
• Aufsichtsseite: Einhaltung rechtlicher Anforderungen, Meldewege, dokumentierte Nachweise.
• Gesellschafter oder Geschäftsführung: stabiles und wirtschaftlich vertretbares Sicherheitsniveau, Schutz vor Reputations- und Haftungsschäden. Diese Art von Zuordnung macht Clause 4.2 prüfbar und nützlich.
• usw.

Mit ein wenig Fleiß lassen sich diese Anforderungen noch ausarbeiten in die drei Aspekte Vertraulichkeit, Integrität und Verfügbarkeit - dann sind später die Schutzbedarfe der kritischen Informationen einfach klassifiziert (hier mehr dazu).

Was kommt danach?

Wenn Kontext der Organisation die Landkarte ist und interessierte Parteien die handelnden Akteure darauf sind, dann ist der nächste Schritt fast automatisch der Anwendungsbereich. Denn spätestens jetzt wird klarer, welche Teile des Unternehmens, welche Prozesse, welche Informationen und welche Systeme im ISMS liegen müssen, um die relevanten Anforderungen abzudecken. Abschnitt 4 der ISO 27001 baut genau in dieser Reihenfolge auf: Kontext, interessierte Parteien, Scope.

Was will der Auditor sehen?

Ein Auditor will hier normalerweise keine philosophische Stakeholderanalyse. Er will sehen, dass Sie die relevanten interessierten Parteien identifiziert haben, deren relevante Anforderungen kennen und diese Informationen nicht vergessen, sondern regelmäßig überprüfen - spätestens im Management Review.

Hilfreiche Nachweise sind deshalb zum Beispiel eine kurze Liste relevanter interessierter Parteien, die zugehörigen Anforderungen, der Bezug zum ISMS und ein nachvollziehbarer Mechanismus, wie Änderungen erkannt werden. Mehr braucht es oft gar nicht. Weniger aber meistens auch nicht.

Nicht jeder, der sich interessiert, ist gleich wichtig

Die Liste darf breit beginnen. Danach muss sie aber brauchbar werden. Für jede mögliche interessierte Partei helfen vier Fragen:

• Welche Beziehung besteht zum ISMS oder zu seinem Geltungsbereich?
• Welche Anforderungen dieser Partei sind für die Informationssicherheit wirklich relevant?
• Sind diese Anforderungen verbindlich, vertraglich zugesagt oder geschäftlich sinnvoll?
• Wo werden sie im ISMS umgesetzt und wer behält Änderungen im Blick?

Ein Nachbar, der sich über Lieferverkehr beschwert, kann für den Standort relevant sein. Er hat deshalb aber noch keine eigenen Anforderungen an die Verschlüsselung Ihrer Backups. Ein Großkunde kann dagegen konkrete Meldezeiten, Nachweise oder Sicherheitsstandards verlangen. Eine Aufsichtsbehörde bringt gesetzliche Anforderungen mit. Mitarbeiter erwarten wiederum klare Regeln, funktionierende Arbeitsmittel und einen vernünftigen Umgang mit ihren Daten.

Aus der Liste muss etwas folgen

Eine Tabelle mit den Spalten Partei und Erwartung ist nur der Anfang. Wenn dort beim Kunden „Informationssicherheit“ steht, weiß noch niemand, was zu tun ist. Besser ist eine nachvollziehbare Kette: Der Kunde verlangt eine Meldung erheblicher Sicherheitsvorfälle innerhalb einer bestimmten Frist. Diese Anforderung landet im Incident-Prozess, bekommt einen Verantwortlichen und wird bei Vertragsänderungen überprüft.

Das verbindet die interessierten Parteien mit dem Kontext der Organisation, dem Scope, den rechtlichen und vertraglichen Anforderungen, dem Risikomanagement und den Gründen, aus denen Kunden eine ISO 27001 fordern.

Was will der Auditor sehen?

Der Auditor möchte erkennen, dass die Organisation ihre relevanten Parteien nicht geraten, sondern systematisch bestimmt hat. Er kann eine Partei herausgreifen und fragen: Welche relevante Anforderung kommt von ihr? Wo ist diese umgesetzt? Wer beobachtet Änderungen? Wann wurde zuletzt geprüft, ob die Liste noch passt?

Ein alle zwölf Monate unverändert weiterkopiertes Tabellenblatt beweist wenig. Gute Nachweise sind neue Verträge, Kundenanforderungen, Behördenkontakte, Änderungen des Geschäftsmodells oder Entscheidungen, mit denen das Unternehmen auf veränderte Erwartungen reagiert hat.

Interesse geweckt?

Sie möchten das Thema in Ihrem Unternehmen sauber und pragmatisch angehen? Sprechen Sie mit uns.