Secure-by-Demand-Softwarebeschaffung 2026

Es ist Dienstagmorgen Anfang 2026, und Maria, CISO eines schnell wachsenden europäischen Zahlungsdienstleisters, präsentiert vor dem Leitungsorgan. Der letzte Tagesordnungspunkt sollte Routine sein: die Freigabe einer neuen KI-gestützten Plattform zur Betrugserkennung. Der Anbieter hat eine überzeugende Demo, einen befristeten Rabatt, eine einseitige Sicherheitsübersicht und einen Standardvertrag.

Dann beginnen die Fragen.

Der CEO fragt: „Woher wissen wir, dass diese Plattform sicher ist? Unsere Kunden aus dem Finanzdienstleistungssektor verlangen Nachweise der DORA-Compliance, und dieser Lieferant wird Teil unserer kritischen Infrastruktur.“

Die Rechtsabteilung fragt, ob der Auftragsverarbeitungsvertrag fertig ist, wo EU-Kundendaten verarbeitet werden und ob Unterauftragsverarbeiter offengelegt sind. Die Leitung für operationale Resilienz fragt nach Exit-Planung, Backup-Exporten und Kontinuität für kritische Funktionen. Der Produktsicherheitsingenieur verlangt Informationen zur Offenlegung von Schwachstellen, Nachweise zum Patching und eine SBOM oder eine gleichwertige Erklärung zur Komponententransparenz. Die Beschaffung stellt die Frage, die Lieferantenrisiken teuer macht: „Können wir jetzt freigeben und die Unterlagen nach der Unterzeichnung einholen?“

Das ist der Moment, in dem moderne Softwarebeschaffung entweder zu einer wirksamen Kontrolle wird oder zu einem künftigen Vorfallsbericht.

Im Jahr 2026 kann sichere Softwarebeschaffung nicht mehr auf Wohlwollen nach Vertragsschluss beruhen. NIS2-Sicherheit der Lieferkette, DORA-IKT-Drittparteienrisiken, GDPR-Rechenschaftspflicht für Auftragsverarbeiter und Produktsicherheitserwartungen des Cyber Resilience Act haben die Lieferantensicherheit an den Punkt der Beschaffungsentscheidung verlagert. Käufer benötigen Secure-by-Demand-Softwarebeschaffung, bei der der Kunde Sicherheitsnachweise, Vertragsklauseln, Onboarding-Gates und operative Verantwortlichkeiten vor dem Kauf definiert.

Für Clarysec-Kunden ist die Antwort nicht eine weitere Tabelle, die in E-Mails verschwindet. Es ist ein an ISO/IEC 27001:2022 ausgerichtetes Kontrollsystem für die Beschaffung, abgebildet über Clarysec-Richtlinien, die Zenith Blueprint: An Auditor’s 30-Step Roadmap und Zenith Controls, sodass jeder Software- oder SaaS-Kauf einen belastbaren Prüfpfad vom Geschäftsbedarf bis zur Entscheidung über das Lieferantenrisiko hat.

Secure-by-Demand ist die neue Kontrolle für Softwarebeschaffung

Security by Design wird üblicherweise aus Sicht des Anbieters diskutiert. Secure-by-Demand ist die käuferseitige Disziplin: Die Organisation lehnt den Kauf von Software ab, sofern der Anbieter nicht nachweisen kann, dass Sicherheit, Datenschutz, Resilienz, Schwachstellenbehandlung und Auditierbarkeit in das Angebot eingebaut sind.

Dadurch verändert sich das Beschaffungsgespräch. Statt zu fragen: „Haben Sie Sicherheit?“, stellt die Beschaffung präzisere Fragen:

• Welche Daten werden Sie verarbeiten, wo und in welcher rechtlichen Rolle?
• Welche Geschäftsfunktion wird von Ihnen abhängen, und wie kritisch ist sie?
• Welche Nachweise belegen, dass Ihre Kontrollen wirksam betrieben werden und nicht nur dokumentiert sind?
• Zu welchen Fristen für Vorfallmeldungen verpflichten Sie sich?
• Welche Nachweise zur Offenlegung von Schwachstellen, zu Patching, SBOM oder VEX können Sie bereitstellen?
• Welche Unterauftragnehmer oder Unterauftragsverarbeiter werden Zugriff auf unsere Daten oder Services haben?
• Können wir während der Vertragslaufzeit auditieren, prüfen oder Nachweise anfordern?
• Was geschieht bei Vertragsbeendigung, Migration, Datenschutzverletzung, Insolvenz oder Anfrage einer Aufsichtsbehörde?

ISO/IEC 27001:2022 liefert das Managementsystem-Rückgrat für diesen Wandel. Clause 4 verlangt, dass die Organisation ihren Kontext, interessierte Parteien und den ISMS-Geltungsbereich versteht, einschließlich externer regulatorischer und lieferantenbezogener Anforderungen. Clause 5 macht Lieferantenrisiken zu einer Führungs- und Governance-Verantwortung. Clause 6 verlangt Risikobeurteilung, Risikobehandlung, Auswahl von Kontrollen, eine Erklärung zur Anwendbarkeit und Entscheidungen über Restrisiken. Clause 8 verlangt den kontrollierten Betrieb von Prozessen, einschließlich extern bereitgestellter Prozesse. Clause 9 verlangt Überwachung, Internes Audit und Managementbewertung.

Damit ist Softwarebeschaffung nicht nur ein kommerzieller Workflow. Sie wird zu einem betriebenen und auditierbaren ISMS-Prozess. Regulatoren und Auditoren fragen zunehmend, warum eine Organisation einen Lieferanten akzeptiert hat, bevor sie das Risiko verstanden hatte. Secure-by-Demand-Beschaffung liefert eine klare Antwort: Das Risiko wurde bewertet, behandelt, vertraglich geregelt und zugewiesen, bevor die Abhängigkeit entstand.

Warum NIS2, DORA, GDPR und CRA bei der Lieferantenauswahl zusammenlaufen

Marias Leitungsorgan stellt die richtigen Fragen, weil ein einzelner Softwarelieferant mehrere Verpflichtungen gleichzeitig auslösen kann.

NIS2 gilt nach Sektor, Größe und Kritikalität; Annex I und Annex II bringen viele digitale, finanzielle, infrastrukturelle, Managed-Service- und cloudabhängige Organisationen in den Geltungsbereich. Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, einschließlich Sicherheit der Lieferkette, sicherer Beschaffung, sicherer Entwicklung und Wartung, Schwachstellenbehandlung, Zugriffskontrolle, Asset-Management, Kontinuität, Umgang mit Informationssicherheitsvorfällen und Bewertung der Kontrollwirksamkeit. Article 21(3) verlangt insbesondere die Berücksichtigung von Schwachstellen direkter Lieferanten und der Cybersicherheitspraktiken von Lieferanten. Article 23 schafft abgestufte Erwartungen an die Meldung erheblicher Vorfälle, einschließlich Frühwarnung innerhalb von 24 Stunden und Meldung innerhalb von 72 Stunden.

DORA gilt seit dem 17. Januar 2025 für Finanzunternehmen im Geltungsbereich. Es schafft einheitliche Anforderungen an das Management von IKT-Risiken, die Meldung IKT-bezogener Vorfälle, Tests der digitalen operationalen Resilienz und das IKT-Drittparteienrisikomanagement. DORA ist für die Beschaffung besonders präskriptiv. Finanzunternehmen benötigen Strategien für IKT-Drittparteienrisiken, Register von IKT-Servicevereinbarungen, Due-Diligence-Prüfungen, Konzentrationsrisikoanalysen, schriftliche Verträge mit Sicherheits- und Resilienzbestimmungen, Audit- und Zugriffsrechte, Mitwirkungspflichten, Kündigungsrechte und Exit-Pläne. Articles 28 und 30 sind zentral für IKT-Drittparteienrisiken und vertragliche Kontrollen, während Articles 17 bis 23 Vorfallmanagement und Berichterstattung prägen.

GDPR fügt das Gate der Rechenschaftspflicht für Auftragsverarbeiter hinzu. Articles 5, 28, 32, 33 und 34 verlangen Rechenschaftspflicht, Verträge mit Auftragsverarbeitern, angemessene Sicherheit, Zusammenarbeit bei Meldungen von Datenschutzverletzungen und die Behandlung von Auswirkungen auf betroffene Personen. Ein SaaS-Lieferant, der personenbezogene Daten verarbeitet, ist nicht nur ein Anbieter. Er wird Teil des Compliance-Status des Verantwortlichen. Der DPA, technische und organisatorische Maßnahmen, die Liste der Unterauftragsverarbeiter, geeignete Garantien für Übermittlungen, Aufbewahrungsregeln und Löschpflichten müssen verstanden sein, bevor die Verarbeitung beginnt.

CRA-Erwartungen ergänzen die Produktsicherheit. Auch wenn der Käufer nicht der Hersteller ist, sollten Beschaffungsteams Nachweise zu sicherer Entwicklung, Schwachstellenbehandlung, Produktsupport, Sicherheitsupdates, koordinierter Offenlegung von Schwachstellen und Komponententransparenz verlangen, etwa eine SBOM oder eine gleichwertige Erklärung. Diese Anforderungen gehören in RFPs, Sicherheitsanhänge und Abnahme-Gates.

Das gemeinsame Thema ist einfach: Die kaufende Organisation muss wissen, was sie kauft, welches Risiko sie importiert und welche Nachweise sie vorlegen kann, wenn Regulatoren, Kunden oder Auditoren fragen.

Das ISO 27001-Kontrollrückgrat für Lieferantensicherheit

Das wirksamste Secure-by-Demand-Beschaffungsmodell ist nicht nach einzelnen Regelwerken aufgebaut. Es ist kontrollorientiert. Clarysec nutzt ISO/IEC 27001:2022 als ISMS-Rückgrat, unterstützt durch die Leitlinien aus ISO/IEC 27002:2022 und Cross-Compliance-Mapping in Zenith Controls.

In Zenith Controls ist die Lieferantensicherheit um die ISO/IEC 27002:2022-Kontrollen 5.19, 5.20 und 5.21 verankert. Das sind keine isolierten Checklistenpunkte. Sie bilden einen Beschaffungslebenszyklus.

Zenith Controls bildet diese ISO-Kontrollen auf regulatorische und Audit-Erwartungen ab. Es schafft keine separaten proprietären Kontrollen mit dem Namen Zenith Controls. Es hilft Teams zu verstehen, wie ISO/IEC 27002:2022-Kontrollen NIS2, DORA, GDPR, NIST CSF 2.0 und COBIT-orientierte Vertrauensbildung unterstützen.

Auch das unterstützende Kontrollnetzwerk ist entscheidend. Lieferantensicherheit ist mit Asset-Management, Zugriffskontrolle, Cloud-Sicherheit, Schwachstellenmanagement, Protokollierung, Vorfallmanagement, IKT-Bereitschaft für die Aufrechterhaltung des Geschäftsbetriebs, sicherer Entwicklung, Anwendungssicherheit, Konfigurationsmanagement, Backup, Redundanz, rechtlicher Compliance, Datenschutz, Änderungsmanagement und unabhängiger Prüfung verbunden. Die Beschaffung koordiniert den Prozess, aber die Risikoverantwortung muss den Geschäftsverantwortlichen, Informationssicherheit, Recht, Datenschutz, IT, Finanzen und den Serviceverantwortlichen einbeziehen.

Clarysec-Richtlinien-Gates vor der Unterzeichnung

Das Richtlinienmodell von Clarysec verlagert Lieferantensicherheit bewusst nach vorne. Die stärkste Formulierung steht dort, wo sie hingehört: bevor Vereinbarungen unterzeichnet, Cloud-Abonnements aktiviert und Daten geteilt werden.

Die KMU-Version der Clarysec-Richtlinie zur Lieferanten- und Drittparteiensicherheit besagt:

Lieferantenrisiken sind zu bewerten und zu dokumentieren, bevor Vereinbarungen unterzeichnet oder Zugriffe gewährt werden.

Dies stammt aus dem Abschnitt „Ziele“, Richtlinienklausel 3.3. Die Klausel ist kurz, weil die Kontrollabsicht nicht verhandelbar ist: keine Risikobeurteilung, kein Vertrag, kein Zugriff.

Für Unternehmensumgebungen verstärkt Clarysecs Richtlinie zur Lieferanten- und Drittparteiensicherheit das Vorvertrags-Gate:

Alle neuen Lieferanten müssen vor Vertragsabschluss eine dokumentierte Sicherheitsbewertung durchlaufen.

Dies stammt aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.1.1. Dieselbe Richtlinie benennt außerdem „Rechte zur Auditierung, Prüfung und Anforderung von Sicherheitsnachweisen“ im Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.4.

Für Cloud- und SaaS-Beschaffung ergänzt die KMU-Richtlinie zur Nutzung von Cloud-Diensten ein praktisches Genehmigungs-Gate:

Jede Nutzung von Cloud-Services muss vor Implementierung oder Abonnement durch den Geschäftsführer (GM) geprüft und genehmigt werden.

Dies stammt aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.1. In einer kleinen Organisation kann diese Genehmigung dem Äquivalent eines Cloud-Governance-Gremiums entsprechen. In einem Unternehmen wird daraus ein Workflow über Beschaffung, Sicherheit, Datenschutz und Architektur hinweg. Die Enterprise-Richtlinie zur Nutzung von Cloud-Diensten unterstützt zudem vertragliche Cloud-Anforderungen, einschließlich durchsetzbarer Bestimmungen in CSP-Verträgen.

Für Softwarebeschaffung ist die Enterprise-Richtlinie zu Anforderungen an die Anwendungssicherheit eindeutig:

Softwarebeschaffungen oder Outsourcing-Vereinbarungen müssen Sicherheitsanforderungen in RFPs, Verträgen und SLAs enthalten, einschließlich Bestimmungen zu Fristen für die Behebung von Schwachstellen und Auditrechten gegenüber Drittparteien.

Dies stammt aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.4. Beachten Sie die Reihenfolge: RFPs, Verträge und SLAs. Sicherheit erscheint bereits in der Marktbearbeitungsphase, nicht als Anhang nach Zuschlag.

Für GDPR-getriebene Beschaffung verlangt Clarysecs KMU-Richtlinie zur rechtlichen und regulatorischen Einhaltung:

Klauseln für einen Auftragsverarbeitungsvertrag (DPA) oder gleichwertige vertragliche Bedingungen müssen vereinbart werden, bevor personenbezogene oder sensitive Daten geteilt werden.

Dies stammt aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.3.2. Dies verhindert einen der häufigsten Fehler beim SaaS-Onboarding: personenbezogene Daten in ein Tool hochzuladen, bevor Auftragsverarbeiterbedingungen, Pflichten bei Datenschutzverletzungen und Bedingungen für Unterauftragsverarbeiter vereinbart sind.

Für Anwendungssicherheit bei Anbietern verlangt die KMU-Richtlinie zu Anforderungen an die Anwendungssicherheit, dass die Beschaffung:

Verpflichtungen zur Offenlegung von Schwachstellen, zu Reaktionszeiten und zum Patching festlegt.

Dies stammt aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.2. Dort heißt es außerdem:

Der GM muss Dokumentation oder Zertifizierungen (z. B. SOC 2, ISO 27001, Sicherheitsprüfberichte) als Nachweis der Einhaltung durch den Anbieter anfordern, sofern anwendbar.

Dies stammt aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.3.2. Das Schlüsselwort ist Nachweis. Secure-by-Demand-Beschaffung basiert nicht auf Vertrauensaussagen. Sie basiert auf prüffähigen Artefakten.

Das Beschaffungs-Gate der Zenith Blueprint

Die Zenith Blueprint behandelt Lieferantensicherheit als betriebene Kontrolle, nicht als Beschaffungsslogan. In der Phase „Controls in Action“ deckt Step 23 organisatorische Kontrollen 5.19 bis 5.37 ab, einschließlich Informationssicherheit in Lieferantenbeziehungen.

Die Blueprint erklärt:

Es beginnt mit der Lieferantenklassifizierung. Nicht alle Lieferanten tragen dasselbe Risiko. Ein Reinigungsdienst kann physischen Zutritt zu Büros haben, aber keinen Zugriff auf Netzwerke. Ein Penetrationstest-Unternehmen oder Hosting-Anbieter dagegen kann tiefgehenden technischen Zugriff auf das Herz Ihrer Infrastruktur haben. Die Klassifizierung sollte berücksichtigen, ob der Lieferant Ihre Informationen direkt handhabt oder verarbeitet, ob er Infrastruktur oder Plattformen bereitstellt, auf denen Sie arbeiten, ob er Systeme in Ihrem Auftrag verwaltet oder wartet und ob seine Kompromittierung Ihre Ziele in Bezug auf Vertraulichkeit, Integrität oder Verfügbarkeit beeinträchtigen könnte.

Für Kontrolle 5.20 ist die Blueprint direkt:

Zentrale Bereiche, die typischerweise in Lieferantenvereinbarungen geregelt werden, umfassen Vertraulichkeitspflichten; Verantwortlichkeiten für Zugriffskontrolle; technische und organisatorische Maßnahmen für Datenschutz, Verschlüsselung, sichere Übertragung, Backup und Verfügbarkeitszusagen; Fristen und Protokolle für Vorfallmeldungen; Auditrechte, einschließlich Häufigkeit, Umfang und Zugriff auf relevante Nachweise; Unterauftragnehmerkontrollen; sowie Bestimmungen zum Vertragsende wie Datenrückgabe oder Vernichtung, Asset-Wiederherstellung und Kontodeaktivierung.

Sie kommt zu dem Schluss, dass Kontrolle 5.20 „Ihre letzte Hebellinie“ ist und „an das Beschaffungs-Gate gehört“. Sobald der Vertrag unterzeichnet ist, sinkt die Verhandlungsmacht. Vor der Unterzeichnung können Nachweise und Verpflichtungen zu Kaufbedingungen gemacht werden.

Für ausgelagerte Entwicklung ergänzt die Phase „Controls in Action“, Step 21, Kontrolle 8.30, eine weitere Beschaffungsanforderung. Die Blueprint stellt fest:

Im Kern dieser Kontrolle steht der Grundsatz, dass Sicherheit eine vertragliche Anforderung sein muss, keine mündliche Erwartung.

Ausgelagerte Teams sollten dieselben Standards für sichere Entwicklung erfüllen wie interne Teams, einschließlich statischer Analyse, Peer-Review, Verschlüsselung, MFA für Repositories und Transparenz zu Code, Architekturentscheidungen, Schwachstellen, Änderungsanträgen, CI/CD-Protokollen und Scan-Ergebnissen.

Ein Secure-by-Demand-RFP-Gate an einem Nachmittag aufbauen

Angenommen, Ihre Organisation möchte eine Plattform für Kundenanalysen beschaffen. Sie wird Kundenkennungen, Verhaltensereignisse, Support-Metadaten und Transaktionsreferenzen aufnehmen. Der Geschäftsverantwortliche wünscht eine schnelle Freigabe. Das Sicherheitsteam hat eine Woche.

Beginnen Sie mit einem Datensatz für das Beschaffungs-Gate und nutzen Sie die Richtlinie zur Lieferanten- und Drittparteiensicherheit, die Richtlinie zu Anforderungen an die Anwendungssicherheit, die Richtlinie zur Nutzung von Cloud-Diensten, die Richtlinie zur rechtlichen und regulatorischen Einhaltung und Step 23 der Zenith Blueprint als Quelldokumente.

Fügen Sie dem RFP einen Secure-by-Demand-Fragebogen bei. Vermeiden Sie generische Fragen wie „Verschlüsseln Sie Daten?“ Stellen Sie nachweisorientierte Fragen:

1. Stellen Sie Ihren aktuellen unabhängigen Vertrauensbericht, Ihr Zertifikat oder gleichwertige Kontrollnachweise bereit.
2. Benennen Sie Hosting-Standorte, Datenresidenzoptionen, Backup-Standorte und Standorte für Supportzugriffe.
3. Stellen Sie den DPA, die Liste der Unterauftragsverarbeiter und den Benachrichtigungsprozess für Änderungen bei Unterauftragsverarbeitern bereit.
4. Bestätigen Sie Fristen für Vorfallmeldungen, einschließlich Unterstützung für 24-Stunden-Frühwarnungen, wenn NIS2-Workflows ausgelöst werden können, und Unterstützung gestufter Berichterstattung für DORA-regulierte Kunden.
5. Stellen Sie die Richtlinie zur Offenlegung von Schwachstellen, Patch-SLAs nach Schweregrad und Nachweise aktueller Governance zur Behebung von Schwachstellen bereit.
6. Stellen Sie Produktsicherheitsnachweise bereit, etwa eine Beschreibung des Lebenszyklus sicherer Entwicklung, eine Zusammenfassung von Penetrationstests, SBOM oder eine Erklärung zur Komponententransparenz sowie den Zeitraum für Sicherheitsupdate-Support.
7. Bestätigen Sie MFA, das Prinzip der minimalen Berechtigung, Protokollierung, Überwachung administrativer Zugriffe sowie Auditrechte oder Rechte zur Nachweisanforderung durch den Kunden.
8. Beschreiben Sie Export, Löschung, Rückgabe, Unterstützung bei Vertragsbeendigung und Übergangshilfe.
9. Listen Sie wesentliche Unterauftragnehmer und IKT-Abhängigkeiten auf, die den Service unterstützen.
10. Bestätigen Sie, ob Kundendaten für Training, Analysen, Produktverbesserung oder KI-Modellentwicklung genutzt werden, und benennen Sie die Rechtsgrundlage oder das Modell dokumentierter Weisungen des Auftragsverarbeiters.

Bewerten Sie den Anbieter anschließend vor der Verhandlung.

Aktualisieren Sie abschließend das Risikoregister und die Erklärung zur Anwendbarkeit. Der Datensatz zur Risikobehandlung sollte zeigen, warum die ISO/IEC 27002:2022-Kontrollen 5.19, 5.20 und 5.21 anwendbar sind, welche vertraglichen und technischen Anforderungen ausgewählt wurden, wer das Restrisiko verantwortet und welcher Überwachungsturnus gilt. Wenn der Fachbereich trotz Lücken fortfahren möchte, nutzen Sie einen formalen Risikoakzeptanz-Datensatz mit Ablaufdatum, kompensierenden Kontrollen und Genehmigung durch die Geschäftsleitung.

Vertragsklauseln, die Regulierung in durchsetzbare Verpflichtungen überführen

Sicherheitserwartungen müssen zu vertraglichen Zusagen werden. Ein Zertifikat kann nützlich sein, beantwortet aber selten jede Frage zu Ihrem konkreten Service, Datenstandort, Unterauftragnehmern, Supportmodell, Vorfallzusagen oder Exit-Rechten.

Diese Tabelle ist die praktische Brücke zwischen rechtlichen Verpflichtungen und Beschaffungsarbeit. Sie hilft außerdem Recht, Sicherheit und Beschaffung, aus derselben Kontrollbasis heraus zu verhandeln.

Cross-Compliance-Mapping: eine Lieferantenakte, viele Verpflichtungen

Der Vorteil von ISO/IEC 27001:2022 als Rückgrat besteht darin, dass eine Lieferantensicherheitsakte mehrere regulatorische Gespräche unterstützen kann.

NIST CSF 2.0 ist als Kommunikationsebene nützlich. Seine GOVERN-Funktion betont Bewusstsein für rechtliche, regulatorische, vertragliche, datenschutzbezogene und abhängigkeitsspezifische Anforderungen. Seine GV.SC-Ergebnisse zur Lieferkette verlangen Prozesse für das Risikomanagement in der Lieferkette, Lieferantenrollen, Priorisierung von Lieferanten nach Kritikalität, vertragliche Anforderungen, Due Diligence, Überwachung, Vorfallplanung und Planung der Vertragsbeendigung.

Das lässt sich sauber auf Step 23 der Zenith Blueprint und die ISO/IEC 27002:2022-Kontrollen 5.19 bis 5.21 abbilden, wie sie in Zenith Controls gemappt sind. Es gibt Leitungsorganen außerdem eine Sprache, die sie verstehen: Ist-Zustand, Zielzustand, Lücke, Risiko, Maßnahme, Verantwortlicher und Datum.

Was Auditoren fragen werden

Ein starker Secure-by-Demand-Beschaffungsprozess sollte unterschiedlichen Audit-Blickwinkeln standhalten.

Ein ISO/IEC 27001:2022-Auditor beginnt mit ISMS-Kontext und Geltungsbereich. Er wird fragen, ob Lieferantenschnittstellen und Abhängigkeiten einbezogen sind, ob Anforderungen interessierter Parteien NIS2, DORA, GDPR und Kundenverträge umfassen und ob Lieferantenrisiken konsistent nach der Risikomethodik bewertet werden. Er wird dem Prüfpfad in Risikobehandlung, Erklärung zur Anwendbarkeit, Lieferantenkontrollen, operative Nachweise, Internes Audit und Managementbewertung folgen.

Ein DORA-Prüfer wird sich auf IKT-gestützte Geschäftsfunktionen, kritische oder wichtige Funktionen, Aufzeichnungen zu Drittparteienabhängigkeiten, Vertragsklauseln, Audit- und Zugriffsrechte, Zusammenarbeit bei Vorfällen, Resilienztests, Exit-Strategien und Konzentrationsrisiko konzentrieren. Wenn ein SaaS eine kritische oder wichtige Funktion unterstützt, reicht ein schlanker Anbieterfragebogen nicht aus.

Eine NIS2-Behörde wird fragen, wie die Organisation Cybersicherheitspraktiken von Lieferanten, Schwachstellen direkter Lieferanten, Unterstützung bei Vorfallmeldungen, Kontinuitätsabhängigkeiten und Entscheidungen zur sicheren Beschaffung bewertet hat. Sie wird prüfen, ob die Lieferantensicherheit die eigenen Verpflichtungen der Organisation nach Article 21 und Article 23 unterstützt.

Ein GDPR-Prüfer wird fragen, ob die Rollen von Verantwortlichem und Auftragsverarbeiter vor Beginn der Verarbeitung verstanden wurden, ob ein DPA oder gleichwertige Bedingungen vor Datenweitergabe vereinbart wurden, ob Unterauftragsverarbeiter offengelegt wurden, ob Sicherheitsmaßnahmen angemessen waren, ob die Zusammenarbeit bei Datenschutzverletzungen vertraglich geregelt ist und ob Datenrückgabe oder Löschung durchsetzbar sind.

Ein COBIT 2019- oder ISACA-orientierter Auditor wird sich auf Governance und Rechenschaftspflicht konzentrieren: wer den Lieferanten genehmigt hat, welches Risiko akzeptiert wurde, ob Richtlinienanforderungen eingehalten wurden, ob Ausnahmen nachverfolgt werden und ob Nutzen, Risiko und Ressourcen ausgewogen wurden.

Ihr Nachweispaket sollte Lieferantenklassifizierung, Genehmigung durch den Geschäftsverantwortlichen, Risikobeurteilung, Sicherheitsanforderungen im RFP, Anbieterantworten, DPA, Sicherheitsanhang, SLA, Auditrechte, Register der Unterauftragsverarbeiter, Schwachstellenzusagen, Vorfallklauseln, Nachweise zu Cloud-Standorten, Nachweise zu Protokollierung und Verschlüsselung, Exit-Bedingungen, Aufzeichnungen zur Neubewertung, Ausnahmen und Mapping der Erklärung zur Anwendbarkeit enthalten.

Häufige Fehlermuster beim Softwarekauf

Der erste Fehler besteht darin, Beschaffung als kommerziellen Workflow und Sicherheit als technischen Workflow zu behandeln. Wenn die Sicherheit den Vertrag erhält, hat sich der Fachbereich psychologisch bereits festgelegt, das Implementierungsdatum ist angekündigt und die Verhandlungsmacht ist schwach.

Der zweite Fehler ist Nachweisersatz. Ein Anbieter legt ein Zertifikat vor, und der Käufer nimmt an, dass es jede Frage beantwortet. Eine Zertifizierung kann helfen, deckt aber möglicherweise nicht das konkrete Produkt, die Hosting-Region, das Supportmodell, die Unterauftragnehmerkette, Vorfallpflichten, KI-Datennutzung oder Exit-Anforderungen ab.

Der dritte Fehler ist fehlendes nachgelagertes Risiko. Ein SaaS-Anbieter kann von Cloud-Hosting, Analysewerkzeugen, Supportplattformen, Offshore-Entwicklungsteams, KI-Modellanbietern und Zahlungsabwicklern abhängen. ISO/IEC 27002:2022-Kontrolle 5.21 verlangt Aufmerksamkeit für die IKT-Lieferkette hinter dem direkten Lieferanten. Unter DORA hängt dies mit Unterbeauftragung und Konzentrationsrisiko zusammen. Unter GDPR hängt es mit Unterauftragsverarbeitern zusammen. Unter NIS2 hängt es mit Schwachstellen direkter Lieferanten und Cybersicherheitspraktiken von Lieferanten zusammen.

Der vierte Fehler ist schwache Vorfallsprache. Ein Vertrag, der sagt „der Lieferant wird den Kunden unverzüglich informieren“, unterstützt möglicherweise keine NIS2-Frühwarnung, keine gestufte DORA-Berichterstattung, keine Kundenkommunikation und keine interne Eskalation. Vorfallklauseln benötigen Zeitrahmen, Auslöser, Kontakte, Mitwirkungspflichten und Nachweispflichten.

Der fünfte Fehler sind unklare Exit-Rechte. Wenn ein Anbieter unsicher, nicht konform, übernommen, insolvent oder strategisch ungeeignet wird, benötigt der Käufer Export, Löschung, Übergangsunterstützung, Kontodeaktivierung und Vernichtungsnachweise. Exit ist kein rechtlicher Nachgedanke. Er ist eine Resilienzkontrolle.

Vom Beschaffungs-Gate zur laufenden Lieferantensicherheit

Secure-by-Demand-Beschaffung endet nicht mit der Unterzeichnung. Ein reifer Lieferantenlebenszyklus nach Clarysec-Art hat fünf Stufen.

Für Hochrisikolieferanten sollte die Überwachung die Aktualisierung von Nachweisen, Sicherheits-Review-Meetings, Teilnahme an Vorfall-Tabletop-Übungen, Berechtigungsüberprüfung, Schwachstellen- und Patch-Berichterstattung, Prüfung von Serviceänderungen und Updates zu Unterauftragsverarbeitern umfassen. Für Lieferanten mit geringerem Risiko kann eine jährliche Überprüfung ausreichen. Skalierbarkeit nach ISO 27001, Verhältnismäßigkeit nach NIS2 und Verhältnismäßigkeit nach DORA unterstützen alle die Anpassung, aber die Anpassung muss begründet und dokumentiert werden.

Der nächste Schritt mit Clarysec

Der nächste riskante SaaS-Kauf wartet nicht auf ein perfektes Governance-Redesign. Beginnen Sie mit der nächsten Beschaffungsanfrage.

Nutzen Sie die Zenith Blueprint: An Auditor’s 30-Step Roadmap, um Step 23 zu Lieferantenbeziehungskontrollen und Step 21 zu Kontrollen für ausgelagerte Entwicklung umzusetzen. Nutzen Sie Zenith Controls, um die ISO/IEC 27002:2022-Kontrollen 5.19, 5.20 und 5.21 auf NIS2, DORA, GDPR, NIST CSF 2.0 und COBIT-orientierte Audit-Erwartungen abzubilden. Nutzen Sie die Clarysec-Richtlinienbibliothek, einschließlich der Richtlinie zur Lieferanten- und Drittparteiensicherheit, der Richtlinie zu Anforderungen an die Anwendungssicherheit, der Richtlinie zur Nutzung von Cloud-Diensten und der Richtlinie zur rechtlichen und regulatorischen Einhaltung, um das Gate durchsetzbar zu machen.

Bevor der nächste Vertrag unterzeichnet wird, verlangen Sie Lieferantenklassifizierung, Sicherheitsnachweise, DPA-Bereitschaft, Vorfallzusagen, Schwachstellenbehandlung, Transparenz zu Unterauftragnehmern, Auditrechte und Exit-Bedingungen.

Das ist Secure-by-Demand-Beschaffung. So wandeln CISOs regulatorischen Druck in Beschaffungsmacht um. So machen Compliance-Manager aus überlappenden Verpflichtungen eine einzige Nachweisakte. So sehen Auditoren, dass Lieferantenrisiken berücksichtigt wurden, bevor eine Abhängigkeit entstand. Und so kaufen Geschäftsverantwortliche Software schneller ein, ohne ungesteuerte Risiken zu übernehmen.

Bereit, Ihren nächsten Softwarekauf in eine auditbereite Kontrolle zu verwandeln? Erkunden Sie Clarysecs integrierte Richtliniensuite, laden Sie die Zenith Blueprint herunter, prüfen Sie Zenith Controls oder vereinbaren Sie eine Demo, um ein Secure-by-Demand-Beschaffungsprogramm aufzubauen, das NIS2, DORA, GDPR, CRA-Erwartungen und einer echten Prüfung durch Auditoren standhält.