Softwareanbieter prüfen. Sicherheit, Integration und Eigentum

Kurzantwort

Kaufen Sie kein Sicherheitsversprechen, sondern überprüfbare Verantwortlichkeiten. Vor Vertragsabschluss muss für jedes wichtige Konto, jeden Datenfluss, jede Integration, jede Betriebsentscheidung und jede Übergabe ein Eigentümer benannt sein. Fordern Sie eine aktuelle Datenkarte, ein Zugriffsmodell, einen Incident-Ablauf, Wiederherstellungsnachweise, einen API-Katalog und einen Übergabeplan. Dieser Leitfaden ist keine Rechtsberatung und keine Aussage, dass eine einzelne Kontrolle Rechtskonformität schafft.

Datenkarte und Fragen zu Rollen

Erstellen Sie für jeden Datenfluss eine Zeile mit Quelle, Zweck, Datentyp, Empfänger, Speicherort, Zugriffsrollen, Aufbewahrung und Weg für Export oder Löschung. Trennen Sie Kundendaten von Logs, Analytik, Sicherungen und Testdaten. Fragen Sie, wer eine Zweckänderung freigibt und wer Anfragen betroffener Personen bearbeitet.

Die DSGVO unterscheidet Verantwortliche und Auftragsverarbeiter. Artikel 28 nennt für eine Verarbeitung im Auftrag unter anderem Gegenstand, Dauer, Art, Zweck, Datenarten, betroffene Personen sowie Rechte und Pflichten als Vertragsinhalt. Prüfen Sie Ihre konkrete Rollenverteilung mit Rechtsberatung und Datenschutzverantwortlichen. Fragen Sie, wer Zweck und Mittel festlegt, welche Unterauftragsverarbeiter eingesetzt werden und wie Änderungen mitgeteilt werden. Die Datenschutzinformation von Rise.sk ist kein Ersatz für diese Prüfung.

Zugriffe, Protokolle und sichere Entwicklung

Fordern Sie ein Register aller Umgebungen und Konten an. Dazu gehören Cloud-Administratoren, Produktionsdatenbanken, Repositories, CI, Domains, E-Mail, Analytik, Werbekonten und Supportwerkzeuge. Prüfen Sie persönliche statt geteilter Konten, Mehrfaktor-Authentisierung für sensible Rollen und einen dokumentierten Entzug von Berechtigungen bei Wechsel oder Austritt.

Eine Auditspur muss erklären können, wer eine sensible Aktion ausgeführt hat, wann sie geschah, welches Konto beteiligt war und welches Ergebnis entstand. Fragen Sie nach Administrator-Anmeldungen, Rechteänderungen, Exporten, Konfigurationsänderungen und Eingriffen in Produktion. OWASP ASVS kann als Grundlage für die Beschaffung und Prüfung technischer Anwendungskontrollen dienen. Er ist kein Produktsiegel. Öffentliche Grundsätze finden Sie unter Sicherheit bei Rise.sk.

Fragen Sie auch, wie der Anbieter Quellcode schützt, Änderungen prüft und verwundbare Abhängigkeiten behandelt. Bitten Sie um den Ablauf für Code Review, Secret Scanning, Bibliotheksupdates, Risikobewertung und dringende Korrekturen außerhalb des normalen Releases. NIST SP 800-218 beschreibt Praktiken für sichere Entwicklung. CISA Secure by Design fordert, dass die Sicherheitslast nicht allein beim Kunden liegt.

Sicherungen, Vorfälle und APIs

Eine Sicherung braucht mehr als ein Ja. Fragen Sie nach Speicherort, Schutz, Aufbewahrung, Wiederherstellungsberechtigung und letztem erfolgreichen Test. Vereinbaren Sie Ziele für Daten- und Servicewiederherstellung, Incident-Kontakt, erste Statusmeldung und Beweissicherung. ENISA Threat Landscape 2024 liefert Kontext für Bedrohungen und Resilienz. Ein Plan ohne Übung bleibt eine Annahme.

Jede API begründet eine Betriebs- und Eigentumspflicht. Dokumentieren Sie Eigentümer, Zweck, Vertragsbasis, Authentisierung, Limits, Version, Kosten, personenbezogene Daten und Fehlerverfahren. Klären Sie abgelaufene Tokens, langsame Antworten, doppelte Nachrichten, inkompatible Änderungen und Ausfälle Dritter. Für kritische Abläufe braucht es einen manuellen Fortsetzungsweg. Vergleichen Sie Lieferung und Abnahme mit dem Rise.sk Prozess.

Eigentum, Lizenzen, Support und Übergabe

Vertrag und Anlagen sollen Quellcode, Repository, Domains, Cloud-Konten, Datenbanken, DNS, E-Mail, Analytik, Werbekonten, Design-Dateien, Dokumentation, Passwörter und Wiederherstellungscodes getrennt nennen. Erfassen Sie je Objekt Berechtigung, Administrator, Abrechnung, Speicherort und Übergabeschritt. Ein Kundenwert darf nicht an einer privaten E-Mail eines Lieferanten hängen.

Prüfen Sie Lizenzen für Eigenentwicklung, Open Source, Vorlagen, Schriften, Bilder, APIs und bezahlte Dienste. Fragen Sie nach Limits, Verlängerungen, Mindestlaufzeit, Export und Folgen einer Nichtzahlung. Ein SLA soll Supportzeiten, Priorität, Reaktionsziel, Wiederherstellungsziel, Wartungsfenster und Ausnahmen unterscheiden. Ein Ziel ist ohne Messung und Umfang keine Garantie.

Der Exit-Plan gehört vor Projektbeginn auf den Tisch. Er braucht Datenexport in beschriebenem Format, Repository-Historie, Konto- und Integrationsinventar, Infrastrukturdokumentation, Deployment-Anleitung, sichere Übergabe von Geheimnissen und Übergangsunterstützung. Testen Sie einen kleinen Export und den Login des Kunden in ein eigenes Konto. Der Nachweispaket kann Datenkarte, Zugriffsregister, Wiederherstellungstest, Abhängigkeitsliste, Sicherheitsbefunde, Unterauftragsverarbeiter, API-Katalog, SLA und Abnahmekriterien enthalten.

Die Vertragsanlage sollte Umfang, Eigentum, Datenrollen, Sicherheitsmaßnahmen, Incident-Mitteilung, Sicherungen, Integrationen, Lizenzen, Support, Export und Übergabe enthalten. Fügen Sie Akzeptanzkriterien hinzu, etwa einen erfolgreichen Export, einen Wiederherstellungstest, Zugang des Kunden zu seinen Konten und die Übergabe der Betriebsdokumentation. Lassen Sie die Formulierung für Ihren Fall prüfen.

Ein gutes internes Gespräch trennt Risiko von Vermutung. Wenn ein Lieferant eine Kontrolle beschreibt, notieren Sie den Nachweis, das Datum, den Prüfer, die Einschränkung und die offene Folgearbeit. Business, IT, Finanzen, Marketing und Datenschutz brauchen pro offenem Punkt eine Entscheidung, einen Eigentümer und ein Datum. Rise.sk Services unterstützen technische Bewertung. Weitere Leitfäden stehen im Blog. Lesen Sie vor einer Beauftragung auch die Geschäftsbedingungen.

Quellen

• DSGVO bei EUR-Lex
• OWASP ASVS
• NIST SP 800-218 SSDF
• CISA Secure by Design
• ENISA Threat Landscape 2024