„Müssen wir bei diesem Projekt eigentlich noch an Sicherheit denken?“

Das neue Büro ist gemietet. Der Grundriss steht, die Türen sind bestellt, das Umzugsunternehmen ist gebucht. In sechs Wochen soll umgezogen werden. Die Projektleitung zeigt gerade den letzten Stand, als jemand eher beiläufig fragt: „Ach so, müssen wir bei dem Umzug eigentlich noch irgendwas mit Informationssicherheit machen?“

Ja. Beispielsweise beim Raum, in dem später die Server und die Netzwerktechnik stehen sollen. Dessen bereits eingebaute Glastür sieht ausgesprochen elegant aus. Gegen neugierige Blicke und unbefugten Zutritt hilft Eleganz allerdings nur begrenzt.

Und damit fängt die Liste erst an. Wer hat eigentlich schon alles Schlüssel für die neuen Räume – und wer soll sie künftig haben? Im Gebäude liegen bereits Datenkabel: einfach einstöpseln oder erst einmal prüfen, wo die herkommen und wo sie enden? Der Vermieter sagt: „WiFi kommt von uns.“ Praktisch – aber wollen und dürfen wir dieses WLAN überhaupt benutzen? Zwei der sechs Büros belegt vorerst noch ein Untermieter, „der aber bestimmt in drei oder vier Monaten auszieht“. Wer ist das eigentlich, welche Bereiche und Zugänge teilen wir mit ihm und können wir ihm vertrauen? Und selbstverständlich muss ein Notausgang von innen jederzeit zu öffnen sein. Die interessante Frage ist nur: Warum lässt er sich auch von außen öffnen?

Genau für solche Fälle gibt es A.5.8 im Anhang A der ISO 27001. Informationssicherheit soll in das Projektmanagement integriert werden. Nicht irgendwann kurz vor dem Ziel. Und nicht nur bei Projekten, die ohnehin das Wort „IT“ im Namen tragen.

Die kurze Antwort: Sicherheit gehört in jedes relevante Projekt

A.5.8 verlangt nicht, dass aus jedem Vorhaben ein Sicherheitsgroßprojekt mit 14 Gremien und einem eigenen Lenkungskreis wird. Die Anforderung ist viel vernünftiger: Bei Projekten muss rechtzeitig geprüft werden, welche Anforderungen und Risiken der Informationssicherheit eine Rolle spielen. Die notwendigen Aufgaben müssen geplant, Verantwortlichkeiten geklärt und Entscheidungen nachvollziehbar getroffen werden.

Wie groß dieser Sicherheitsanteil sein muss, hängt vom Projekt ab. Die Weihnachtsfeier braucht vermutlich keinen Security-Workstream. Der Umzug des gesamten Unternehmens, die Einführung eines neuen CRM-Systems oder die Ausgründung der IT ziemlich sicher schon.

Was ist eigentlich ein Projekt?

Im Alltag wird das Wort erstaunlich großzügig verwendet. Manchmal heißt jede Aufgabe mit mehr als zwei Arbeitsschritten gleich Projekt. An anderer Stelle heißt selbst die Übernahme eines Unternehmens bloß „Da läuft gerade noch so ein Thema.“

Als handfeste Arbeitsregel kann man sagen: Ein Projekt hat ein Ziel, ist zeitlich begrenzt, verursacht einen nennenswerten Koordinations- oder Ressourceneinsatz und besitzt Einmaligkeitscharakter. Es soll also ein bestimmtes, nicht bloß fortlaufendes Ergebnis hergestellt werden.

Das ist keine harte Normdefinition mit einer Mindestzahl von Personentagen. Ein kleines Vorhaben kann ebenfalls ein Projekt sein. Die Regel hilft aber, Projekte von Routineprozessen zu unterscheiden. Die monatliche Lohnabrechnung ist ein wiederkehrender Prozess. Die Einführung einer neuen Abrechnungssoftware ist ein Projekt. Das tägliche Arbeiten im bestehenden Büro ist Betrieb. Der Umzug in ein neues Büro ist ein Projekt.

Wer es normativer mag: Die DIN 69901-5 sammelt Begriffe des Projektmanagements. Die aktuelle DIN ISO 21502 gibt Leitlinien für Projektmanagement und gilt unabhängig von Zweck, Größe, Kosten, Dauer oder Vorgehensmodell eines Projekts. Für A.5.8 ist aber weniger wichtig, welches Lehrbuchetikett ein Vorhaben trägt. Entscheidend ist, ob ein zeitlich begrenztes Vorhaben Sicherheitsanforderungen oder Sicherheitsrisiken verändert.

Übrigens: Das ISO 27001 Projekt selbst ist zunächst ein Projekt. Das dabei entstehende ISMS soll danach aber in den laufenden Betrieb übergehen. Auch diese Unterscheidung wird gern übersehen.

A.5.8 meint nicht nur IT- und Kundenprojekte

Bei „Informationssicherheit im Projektmanagement“ denken viele zuerst an Softwareentwicklung, Cloud-Migration oder ein neues Rechenzentrum. Das ist richtig, aber viel zu eng. Sicherheitsrelevante Projekte können auch sein:

• ein Büroumzug oder die Eröffnung eines neuen Standorts,
• eine Umstrukturierung mit neuen Zuständigkeiten,
• der Kauf oder Verkauf eines Unternehmens,
• eine Verschmelzung oder ein Carve-out,
• die Ausgründung der IT als eigenes Unternehmen,
• die Einführung eines ERP-, CRM- oder HR-Systems,
• der Wechsel eines Cloud- oder Outsourcing-Dienstleisters,
• die Entwicklung eines neuen Produkts oder einer neuen Dienstleistung,
• die Schließung eines Standorts oder die Aufgabe eines Geschäftsbereichs.

All diese Vorhaben verändern etwas: Prozesse, Systeme, Datenflüsse, Räume, Verträge, Rollen, Lieferanten oder Zugriffsrechte. Und damit verändern sie regelmäßig auch Sicherheitsanforderungen und Risiken.

Warum der Büroumzug ein Sicherheitsprojekt ist, ohne so zu heißen

Der Umzug wird nicht zum Sicherheitsprojekt, nur weil Informationssicherheit berücksichtigt werden muss. Er bleibt ein Umzugsprojekt. Sicherheit ist eine notwendige Perspektive darin.

Schon die Wahl und Gestaltung der Räume betrifft den physischen Schutz. Wo liegen sensible Bereiche? Können Besucher versehentlich bis zur Technik laufen? Wer bekommt welche Schlüssel oder Zutrittsrechte? Was ist mit Sichtschutz, Alarmierung, Brandschutz und der Entsorgung vertraulicher Unterlagen?

Dann kommen die Assets des Unternehmens ins Spiel. Geräte, Papierakten und Datenträger müssen vollständig, sicher und möglichst unbeschädigt am neuen Standort ankommen. Lieferanten erhalten während des Umzugs ungewöhnlich viel Zugang. Deshalb sollte man auch ihre Sicherheitsrisiken und Verantwortlichkeiten klären.

Schließlich soll das Unternehmen weiterarbeiten können. Ein falsch terminierter Leitungsanschluss macht aus einem schönen neuen Büro sehr schnell einen großen Pausenraum. Die Frage, welche Ausfälle noch tolerierbar sind und welche Vorsorge nötig ist, gehört damit auch zum Business Continuity Management.

Das alles fällt nicht plötzlich vom Himmel. Es war von Anfang an im Vorhaben enthalten. Man hat nur zu spät danach gefragt.

Sicherheit gehört an den Projektanfang

Informationssicherheit wird teuer, wenn sie erst auftaucht, nachdem die wichtigen Entscheidungen gefallen sind. Eine andere Tür im Grundriss zu planen, ist einfach. Eine bereits eingebaute Tür wieder herauszureißen, ist ebenfalls einfach – nur teurer, langsamer und ausgesprochen ärgerlich.

Dasselbe gilt bei Software, Verträgen und Organisationsänderungen. Sicherheitsanforderungen lassen sich in einer Ausschreibung berücksichtigen. Nach Vertragsabschluss kann derselbe Wunsch eine kostenpflichtige Sonderleistung sein. Rollen lassen sich während einer Umstrukturierung sauber zuschneiden. Drei Monate später muss man womöglich Berechtigungen, Arbeitsabläufe und Zuständigkeiten erneut umbauen.

Deshalb braucht jedes relevante Projekt früh einen Sicherheitscheck. Früh heißt: bevor Architektur, Anbieter, Vertrag, Grundriss oder Zielorganisation praktisch feststehen.

Ein pragmatischer Sicherheitscheck für Projekte

1. Betrifft das Projekt schützenswerte Informationen, Prozesse oder Systeme?

Die erste Frage ist ein Filter. Werden Daten verarbeitet oder übertragen? Werden Prozesse, Anwendungen, Standorte, Rollen, Lieferanten oder technische Infrastrukturen verändert? Können Vertraulichkeit, Integrität oder Verfügbarkeit betroffen sein?

Wenn die Antwort überall ehrlich „Nein“ lautet, darf der Sicherheitsanteil sehr klein bleiben. Wenn ein „Ja“ auftaucht, geht die Prüfung weiter.

2. Welche Anforderungen gelten?

Es gibt interne Vorgaben, Kundenanforderungen, Verträge, Gesetze und regulatorische Anforderungen. Diese sollten nicht erst bei der Abnahme entdeckt werden. Eine Übersicht über rechtliche und vertragliche Sicherheitsanforderungen hilft dabei.

Auch Klassifizierung und Schutzbedarf sind nützlich: Ein Projekt, das öffentliche Marketingtexte bewegt, braucht andere Maßnahmen als eines, das Gesundheitsdaten, Konstruktionsunterlagen oder Zugangsdaten verarbeitet.

3. Welche Sicherheitsrisiken entstehen oder verändern sich?

Hier ist keine hundertseitige Sonderanalyse für jedes kleine Vorhaben nötig. Aber die relevanten Risiken müssen erkannt und behandelt werden. Eine bestehende Methode für das ISO 27001 Risikomanagement kann dafür genutzt werden. Wichtig ist, dass Projektrisiken nicht nur Budget und Termin meinen. Auch ein pünktlich und im Budget fertiggestelltes Projekt kann sicherheitstechnisch ein prachtvoller Unfall sein.

4. Wer entscheidet und wer setzt um?

Informationssicherheit darf im Projektplan nicht als Aufgabe „Security klären“ ohne Namen und Termin stehen. Wer formuliert Anforderungen? Wer bewertet Risiken? Wer genehmigt Ausnahmen? Wer prüft vor dem Go-live? Wer übernimmt offene Punkte in den Betrieb?

Saubere Rollen, Verantwortlichkeiten und Befugnisse verhindern, dass am Ende alle beteiligt waren, aber niemand zuständig.

5. Welche Sicherheitsaufgaben gehören in den Projektplan?

Was erledigt werden muss, bekommt eine verantwortliche Person, einen Termin und bei Bedarf eine Abhängigkeit. Das können Anforderungen in der Ausschreibung, eine Datenschutz- oder Sicherheitsprüfung, ein Berechtigungskonzept, Tests, Freigaben, Schulungen oder eine Notfallvorsorge sein.

Bei größeren Vorhaben helfen Entscheidungspunkte: Kein Anbieterentscheid ohne geprüfte Anforderungen. Kein Go-live ohne geklärte kritische Risiken. Keine Projektabnahme ohne Übergabe an den Betrieb.

6. Wie erfolgt die Übergabe in den Betrieb?

Projekte enden. Die von ihnen geschaffenen Systeme, Räume, Verträge und Prozesse bleiben. Deshalb muss geklärt sein, wer sie betreibt, überwacht und weiterentwickelt. Dokumentation, Verantwortlichkeiten, offene Risiken, Wartung, Berechtigungen und Notfallverfahren gehören dorthin, wo sie nach Projektende tatsächlich gelebt werden.

Nicht jedes Projekt braucht ein Sicherheitsgroßprogramm

Pragmatismus heißt hier nicht, Sicherheit wegzulassen. Pragmatismus heißt, den Aufwand am Risiko und an der Bedeutung des Vorhabens auszurichten.

Für ein kleines internes Vorhaben können drei dokumentierte Fragen und eine nachvollziehbare Entscheidung genügen. Bei einem Unternehmenskauf, einer Cloud-Migration oder der Ausgründung einer IT-Abteilung wird ein eigener Sicherheitsstrang im Projekt sinnvoll sein. Dazwischen liegt viel Raum.

Eine einfache Projektklassifizierung kann helfen: gering, mittel, hoch sicherheitsrelevant. Daran lassen sich Prüfungen, Freigaben und Nachweise knüpfen. So wird nicht jedes Vorhaben mit demselben Apparat überzogen – und kein kritisches Projekt rutscht durch, weil im Projekthandbuch niemand nach Sicherheit gefragt hat.

Typische Fehler bei A.5.8

• Sicherheit kommt erst zur Abnahme. Dann sind die teuren Entscheidungen längst getroffen.
• Nur IT-Projekte werden geprüft. Umzüge, Zukäufe und Umstrukturierungen bleiben unsichtbar.
• Es gibt eine Checkliste, aber keine Zuständigkeit. Alle setzen Häkchen, niemand löst das Problem.
• Risiken werden nur als Termin- und Budgetrisiken verstanden. Das Projekt kann wirtschaftlich grün und sicherheitstechnisch tiefrot sein.
• Das Projekt endet ohne saubere Übergabe. Offene Sicherheitsaufgaben verschwinden zusammen mit dem Projektteam.

Was will der Auditor sehen?

Ein Auditor wird nicht zwingend ein bestimmtes Projektmanagement-Tool verlangen. Er wird aber verstehen wollen, wie Informationssicherheit tatsächlich in Projekte gelangt.

Gibt es einen frühen Sicherheitscheck? Werden Anforderungen und Risiken aufgenommen? Sind Verantwortlichkeiten und notwendige Freigaben geregelt? Danach wird er vermutlich ein oder mehrere echte Projekte auswählen und prüfen, ob das Verfahren dort gelebt wurde.

Beim Büroumzug könnten Nachweise beispielsweise Sicherheitsanforderungen an Räume und Zutritt, eine Risikobetrachtung, Entscheidungen zu Lieferanten, Aufgaben im Projektplan und die Übergabe an den Betrieb sein. Bei einer neuen Anwendung wären es möglicherweise Anforderungen, Architekturentscheidungen, Berechtigungen, Tests und die Freigabe.

Entscheidend ist die Wirksamkeit. Eine wunderschöne Projektvorlage hilft wenig, wenn die Geschäftsleitung den Unternehmenskauf darin als „strategische Initiative, kein Projekt“ bezeichnet und dadurch sämtliche Sicherheitsfragen elegant umschifft.

Interesse geweckt?

Prüfen Sie nicht erst, ob Informationssicherheit im Projekt vorkam, wenn das Ergebnis schon vor Ihnen steht. Bauen Sie einen kleinen, frühen Sicherheitsfilter in Ihr Projektvorgehen ein. Dann landet die Frage „Müssen wir da eigentlich noch an Sicherheit denken?“ dort, wo sie hingehört: vor der Bestellung der Glastür.

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