IT-Sicherheit im Pflichtenheft: Was KMU beim Festpreis-Projekt oft vergessen

Ein Festpreisangebot bildet genau das ab, was im Pflichtenheft steht - nicht mehr und nicht weniger. Steht dort nichts zu Passwortregeln, Zugriffsrechten oder Verschlüsselung, wird dein Entwicklungspartner auch nichts davon einplanen, kalkulieren oder umsetzen. Das Ergebnis merkst du meist erst kurz vor dem Livegang, wenn ein Pentest, ein Kunde oder du selbst nach Sicherheitsfunktionen fragst, die schlicht nicht Teil der Beauftragung waren - und dann als teure Nachforderung nachverhandelt werden müssen. IT-Sicherheit ist damit kein technisches Detail, das sich "der Entwickler schon überlegt", sondern eine Reihe konkreter Anforderungen, die du selbst ins Pflichtenheft schreiben oder zumindest aktiv einfordern musst.

Authentifizierung und Zugriffsrechte konkret spezifizieren

"Login mit Benutzername und Passwort" ist keine Anforderung, sondern eine Lücke. Ohne weitere Angaben bekommst du im Zweifel die günstigste Umsetzung: ein Passwortfeld ohne Mindestanforderungen, keine Zwei-Faktor-Authentifizierung, eine einzige Nutzerrolle mit Zugriff auf alles. Für die meisten Geschäftsanwendungen reicht das nicht. Definiere stattdessen konkret:

Mindestanforderungen an Passwörter (Länge, Komplexität, sichere Speicherung als Hash statt Klartext)
Ob und für welche Rollen eine Zwei-Faktor-Authentifizierung (2FA) verpflichtend ist
Welche Rollen es gibt und was jede Rolle sehen und tun darf (rollenbasierte Zugriffskontrolle, kurz RBAC)
Wie ein Nutzerkonto gesperrt oder ein Zugriff sofort entzogen werden kann, etwa wenn ein Mitarbeiter das Unternehmen verlässt

Je konkreter diese Punkte im Pflichtenheft stehen, desto genauer kann dein Entwicklungspartner sie im Festpreis kalkulieren - und desto schwerer wird es später, sie als "nicht vereinbart" abzulehnen.

Schutz vor gängigen Angriffsmustern einfordern

Du musst kein Sicherheitsexperte werden, um sinnvolle Anforderungen zu stellen. Es reicht, im Pflichtenheft zu verlangen, dass die Anwendung nach anerkannten Standards gegen die gängigsten Schwachstellen abgesichert ist - etwa orientiert an den OWASP Top 10, der bekanntesten Liste kritischer Web-Sicherheitsrisiken. Konkret gehört dazu unter anderem:

Validierung aller Nutzereingaben, damit niemand über ein Formularfeld Schadcode oder manipulierte Datenbankabfragen einschleusen kann
Schutz vor unbefugtem Zugriff auf fremde Datensätze allein durch das Erraten oder Verändern einer ID in der URL
Sichere Verwaltung von Sitzungen (Sessions), damit ein gestohlenes Zugriffstoken nicht dauerhaft gültig bleibt

Frage im Angebot aktiv nach, ob und wie sich der Anbieter an solchen Standards orientiert. Ein seriöser Entwicklungspartner kann diese Frage im Erstgespräch beantworten - schweigt er dazu oder wirkt überrascht, ist das ein Warnsignal, das du ernst nehmen solltest, lange bevor der Vertrag unterschrieben ist.

Verschlüsselung bei Übertragung und Speicherung

Zwei Punkte gehören standardmäßig in jedes Pflichtenheft, werden aber trotzdem regelmäßig vergessen, weil sie "selbstverständlich" erscheinen: Verschlüsselung der Datenübertragung per HTTPS/TLS und Verschlüsselung sensibler Daten in der Datenbank, etwa Passwörter, Zahlungsdaten oder andere besonders schützenswerte Informationen. "Selbstverständlich" heißt aber nicht "automatisch enthalten" - ohne explizite Anforderung ist auch das eine Leistung, die im Zweifel erst nachträglich und gegen Aufpreis ergänzt wird. Kläre außerdem, wie Backups verschlüsselt und aufbewahrt werden, da Backups in der Praxis oft schwächer abgesichert sind als das produktive System.

Wartung, Patch-Management und Verantwortlichkeit nach dem Launch

Sicherheit ist kein einmaliger Zustand, den man beim Launch abhakt. Software basiert auf Bibliotheken und Frameworks, in denen laufend neue Schwachstellen bekannt werden - eine Anwendung, die beim Livegang sicher war, kann das ein Jahr später ohne Pflege nicht mehr sein. Kläre deshalb vertraglich, wer nach dem Launch für das Einspielen sicherheitsrelevanter Updates zuständig ist, wie oft das passiert und ob es Teil eines Wartungsvertrags oder eine separate Leistung ist. Ohne klare Zuständigkeit bleibt diese Aufgabe in der Praxis oft liegen, bis es zu spät ist.

Protokollierung und Erkennung von Sicherheitsvorfällen

Damit du einen Sicherheitsvorfall überhaupt bemerkst, braucht die Anwendung eine Protokollierung sicherheitsrelevanter Ereignisse: fehlgeschlagene Login-Versuche, Änderungen an Zugriffsrechten, ungewöhnliche Zugriffsmuster. Ohne ein solches Logging fällt ein unbefugter Zugriff oft erst auf, wenn der Schaden bereits entstanden ist - oder gar nicht. Kläre im Pflichtenheft, welche Ereignisse protokolliert werden, wie lange die Protokolle aufbewahrt werden und ob eine einfache Benachrichtigung bei verdächtigen Mustern (etwa vielen fehlgeschlagenen Logins in kurzer Zeit) vorgesehen ist.

Reaktionszeit im Ernstfall vertraglich festlegen

Wenn trotz aller Vorkehrungen ein Sicherheitsvorfall auftritt, zählt jede Stunde. Kläre deshalb vor Projektstart, nicht erst im Ernstfall: Wie schnell wirst du informiert, wenn dein Entwicklungspartner einen Vorfall bemerkt? Wer behebt eine kritische Schwachstelle, und in welcher Frist? Ist das im Festpreis oder im Wartungsvertrag enthalten, oder wird es separat abgerechnet? Diese Fragen berühren auch deine Meldepflichten nach der DSGVO, sobald personenbezogene Daten betroffen sind - Details dazu, etwa zur 72-Stunden-Frist bei Datenpannen, findest du in unserer DSGVO-Checkliste für Softwareprojekte. Eine feste, schriftlich vereinbarte Reaktionszeit verhindert, dass im Ernstfall erst über Zuständigkeiten diskutiert wird, statt das Problem zu lösen.

Fazit

IT-Sicherheit lässt sich nicht nachträglich in ein fertiges System einbauen, ohne dass es teuer wird - und bei einem Festpreisvertrag wird sie erst recht nicht automatisch mitgeliefert, wenn sie im Pflichtenheft fehlt. Authentifizierung, Schutz vor gängigen Angriffsmustern, Verschlüsselung, Patch-Management, Protokollierung und eine klare Reaktionszeit im Ernstfall gehören als konkrete, prüfbare Anforderungen in jedes Pflichtenheft. Je präziser diese Punkte formuliert sind, desto verlässlicher lässt sich das Angebot dagegen kalkulieren - und desto weniger Raum bleibt für Nachforderungen, die eigentlich von Anfang an dazugehört hätten.

Häufig gestellte Fragen

Warum reicht "sicheres Login" nicht als Anforderung im Pflichtenheft?

Weil es zu vage ist, um kalkuliert zu werden. Ohne konkrete Angaben zu Passwortregeln, Zwei-Faktor-Authentifizierung und Zugriffsrollen bekommst du im Zweifel die günstigste Umsetzung ohne diese Funktionen - und musst sie später als teure Nachforderung nachbestellen.

Muss ich als Auftraggeber die OWASP Top 10 im Detail kennen?

Nein. Es reicht, im Pflichtenheft zu verlangen, dass sich die Entwicklung an anerkannten Sicherheitsstandards wie den OWASP Top 10 orientiert, und im Angebotsgespräch aktiv nachzufragen, wie der Anbieter das konkret umsetzt.

Wer ist nach dem Launch für Sicherheitsupdates zuständig?

Das muss vertraglich geklärt werden, zum Beispiel im Rahmen eines Wartungsvertrags. Ohne klare Zuständigkeit bleibt das Einspielen sicherheitsrelevanter Updates in der Praxis oft liegen, bis eine bekannte Schwachstelle ausgenutzt wird.

Was hat IT-Sicherheit mit Festpreis-Nachforderungen zu tun?

Ein Festpreisangebot deckt genau das ab, was im Pflichtenheft steht. Sicherheitsfunktionen, die dort fehlen, sind nicht im Preis enthalten und werden später als separate, oft teure Nachforderung abgerechnet.

Ist IT-Sicherheit im Pflichtenheft dasselbe wie DSGVO-Konformität?

Nein, beides überschneidet sich, ist aber nicht identisch. DSGVO-Anforderungen betreffen den rechtlichen Umgang mit personenbezogenen Daten, etwa Auftragsverarbeitung und Meldepflichten. IT-Sicherheit im hier beschriebenen Sinn betrifft die technische Absicherung der Anwendung selbst, unabhängig davon, ob personenbezogene Daten verarbeitet werden.