KfW-2026-0034_Leistungsbeschreibung.pdf

[Seite 1]

Leistungsbeschreibung RKA-Tool

Leistungsbeschreibung zum Vertrag

„Einführung einer cloudbasierten

Reisekostenabrechnungs- und

Kostenerstattungslösung für die KfW und die

KfW IPEX-Bank“

KfW-2026-0034

1

[Seite 2]

Leistungsbeschreibung RKA-Tool

Inhalt

1 Einsatzzweck und Hintergrund der Beschaffung ........................................................ 5 1.1 Anforderungen gemäß Anlage A.1 5 2 Leistungsüberblick ........................................................................................................ 5 3 Anforderungen an die Software ................................................................................... 6 3.1 Funktionale Anforderungen (SaaS) 6 3.1.1 Erfassung und Verwaltung von Reisekosten und Kostenerstattungen .... 6 3.1.2 Genehmigungs- und Freigabeworkflows ................................................. 7 3.1.3 Reporting und Transparenz .................................................................... 8 3.1.4 Belegmanagement und Automatisierung ................................................ 8 3.1.5 Steuer- und lohnsteuerrelevante Anforderungen .................................... 9 3.1.6 Betrugs- und Fehlererkennung ............................................................. 10 3.1.7 Weitere Unterstützungsfunktionen für Benutzer.................................... 10 3.1.8 Löschkonzept ........................................................................................ 10 3.1.9 Nachhaltigkeit ....................................................................................... 10 3.2 Funktionale Anforderungen (App für den Einsatz auf mobilen Endgeräten) 11 3.3 Darstellung / Browserunabhängigkeit / Endgeräte, Usability und Barrierefreiheit 11 3.4 Zugangs- und /oder Nutzungsvoraussetzungen 11 3.5 Benutzer & Rollenverwaltung 12 3.6 Rechte & Rollenkonzept 12 3.7 E-Mail Hosting & Versand 13 3.8 Schnittstellen 14 3.8.1 KfW-Systeme ........................................................................................ 15 3.8.2 Third-Party-Systeme ............................................................................. 15 4 Nutzungsumfang und -voraussetzungen ................................................................... 15 4.1 Nutzungsumfang 15 4.1.1 Grundbedarf .......................................................................................... 15 4.1.2 Nachbeschaffungsoption, Mengenerweiterung/-reduzierung ................ 16 4.2 Umgebungen 16 4.2.1 Trennung und Parität ............................................................................ 17 4.2.2 Release Management ........................................................................... 17 4.2.3 Datenbereitstellung ............................................................................... 17

2

[Seite 3]

Leistungsbeschreibung RKA-Tool

4.2.4 Schnittstellen......................................................................................... 17 4.3 Kopier- und Nutzungssperren in clientseitige Software (App) 17 4.4 Prüfpflichten, Schadsoftware und unerwünschte Funktionalität 18 4.5 Dokumentation 18 4.5.1 Fachliches und Technisches Design (FuTD) für die Software .............. 18 4.5.2 Stufentestkonzepte für Systemtest, Systemintegrationstest, UAT ........ 19 4.5.3 Applikationsspezifisches Berechtigungskonzept ................................... 19 4.5.4 IT-Sicherheitskonzept ........................................................................... 19 5 Projekthafte Einführung zur Bereitstellung des Services und der Software ........... 20 5.1 Zielsetzung und Leistungscharakter 20 5.2 Projektvorgehen und Steuerung 20 5.2.1 Phase 1: Projektinitialisierung ............................................................... 21 5.2.2 Phase 2: Feinkonzeption ...................................................................... 21 5.2.3 Phase 3: Umsetzung, Konfiguration und technische Anbindung .......... 22 5.2.4 Phase 4: System-, Integrations-, Fach- und Sicherheitstests in der Testumgebung .................................................................................................... 23 5.2.5 Phase 5: Bereitstellung der Produktivumgebung und GoLive ............... 24 5.2.6 Phase 6: Schulungen ............................................................................ 24 5.2.7 Phase 7 Stabilisierungsphase ............................................................... 24 5.2.8 Phase 8: Projektabnahme ..................................................................... 25 5.3 Mitwirkung der KfW 25 5.4 Meilensteine 26 M6: Stabilisierungsphase .................................................................................... 26 5.5 Projektteam 26 6 Betrieb und Pflege der Software ................................................................................ 28 6.1 Schulungen für Mitarbeiter des Auftragnehmers 29 6.2 Physische Sicherheit 29 6.2.1 Serverstandorte .................................................................................... 29 6.3 Update & Releasemanagement 30 6.4 Allgemeine Bedingungen für Releases 31 6.5 Schwachstellen, Patchmanagement, Härtung 31 6.6 Business Continuity, Datensicherung und Wiederherstellung 31 6.7 Monitoring und Reporting 33 6.7.1 Monitoring ............................................................................................. 33

3

[Seite 4]

Leistungsbeschreibung RKA-Tool

6.7.2 Reporting .............................................................................................. 34 6.8 Service Desk und Servicezeit 34 6.9 Störungsbearbeitung 35 6.9.1 Störungsmeldung durch die KfW und Bearbeitung durch den Auftragnehmer .................................................................................................... 35 6.9.2 Meldung einer Störung durch den Auftragnehmer und Bearbeitung ..... 35 6.9.3 Klassifizierung von Störungen............................................................... 35 6.9.4 Störungsbeseitigung ............................................................................. 36 6.10 Service-Level-Agreements 36 6.10.1 SLA1: Verfügbarkeit .............................................................................. 36 6.10.2 SLA2: Reaktionszeit und Wiederherstellungszeit.................................. 37 6.10.3 SLA3: Performance ............................................................................... 37 6.10.4 Folgen von Service Level Verstößen .................................................... 37 7 Beratung für die Bereitstellung, Konfiguration und Anpassung .............................. 38 8 Governance Meetings ................................................................................................. 38

4

[Seite 5]

Leistungsbeschreibung RKA-Tool

1 Einsatzzweck und Hintergrund der Beschaffung Der Auftragnehmer hat ein cloudbasiertes Reisekostenabrechnungs- und Kostenerstattungssystem (nachfolgend „Software“ oder „RKA-Tool“) in der Betriebsform SaaS (Software as a Service) bereitzustellen und zu betreiben, mit welchem die KfW den gesamten Prozess der Reisekosten- und Spesenabrechnung (im Folgenden auch „Kostenerstattung“) digital, effizient und revisionssicher abwickeln kann, inkl. der Erfassung, Genehmigung, Prüfung und Freigabe der zu erstattenden Kosten. Mit der Einführung der Software soll das bisher eingesetzte Reisekostenabrechnungstool im SAP HCM Umfeld sowie der manuelle und PDF-formularbasierte Prozess der Kostenerstattungen abgelöst werden. Ziel ist es, die heute stark manuellen, teils papie‑rbasie‑rten Abläufe durch einen medienbruchfreien, weitgehend automatisierten Prozess zu ersetzen, der sowohl die internen Richtlinien der KfW als auch die einschlägigen gesetzlichen und steuerlichen Anforderungen erfüllt. Ein weiteres Ziel ist die Verbesserung der Transparenz über Reisekosten sowie Kostenerstattungen. Die Software muss aussagekräftige Auswertungen und Berichte für verschiedene Zielgruppen (z.B. Fachabteilungen, Personal- und Finanzbereiche, Führungskräfte, Revision, Compliance) bereitstellen und damit die Steuerung und Überwachung der Reisekosten auf Unternehmens-, Standort- und Organisationseinheitsebene unterstützen. Die vom Auftragnehmer geschuldete Software wird von Benutzern (z.B. Sekretariate, Führungskräfte, Prüfer, Auditoren) der KfW und ihren Tochtergesellschaften genutzt werden. Sie muss sowohl stationär (Web Frontend) als auch über mobile Endgeräte (App) eingesetzt werden können, um eine zeitnahe Erfassung von Reisekosten und sonstigen Kostenerstattungen, die Prüfung‑ von Abrechnungen und deren Genehmigung unabhängig vom Arbeitsort zu ermöglichen. 1.1 Anforderungen gemäß Anlage A.1 Die Anlage „A.1 Wertungsmatrix Kriterienkatalog“ ist Bestandteil dieser Leistungsbeschreibung. Der vom Auftragnehmer geschuldete Funktionsumfang der vertragsgegenständlichen Software ergibt sich im Einzelnen aus den Vorgaben dieser Leistungsbeschreibung sowie aus der Anlage A.1. Die vom Auftragnehmer geschuldete fachliche und technische Funktionalität wird, durch die in Anlage A.1 definierten MUSS-Anforderungen sowie durch die definierten KANN- Anforderungen bestimmt, soweit und sofern der Auftragnehmer deren Erfüllung angeboten hat. Die Detailanforderungen an die vom Auftragnehmer geschuldete Software ergeben sich aus Anlage A.1.

2 Leistungsüberblick Der Auftragnehmer schuldet folgende Leistungen: a) Bereitstellung einer cloudbasierten Software as a Service Lösung zur Reisekosten- und Spesenabrechnung inklusive mobiler App/Client Software mit dem Funktionsumfang, wie in den Kapiteln 3, 4 un‑d d‑e‑n Vorgab‑en des Kapitels 8. ‑

5

[Seite 6]

Leistungsbeschreibung RKA-Tool

b) Durchführung eines Projektes zur Einführung der Software, wie in Kapitel 5 beschrieben, dass insbesondere die Integration der Software in die bestehende Systemlandschaft der KfW, die Ausgestaltung des Rollen- und Berechtigungskonzepts, die Konfiguration fachlicher Regeln und Formulare sowie Tests, Schulungen und die Vorbereitung der Abnahme umfasst. Die Meilensteine sind in Kapitel 5.4 dieses Dokuments skizziert. Die zugehörigen Anforderungen sind diesem Dokument und Anlage A.1 zu entnehmen.

c) Sicheren, EU DSGVO konformen und leistungsfähigen Betrieb der Software, wie in Kapitel 6 beschrieben. Hierzu zählen insbesondere die technische Betriebsführung, die Überwach‑ung der S‑ ysteme, die Datensicherung und Wiederherstellung, die Behandlung von Störungen, das Schwachstellen und Patchmanagement sowie die Bereitstellung von Updates und Releases, einschließlich der SLAs in Kapitel 6.10. ‑ d) Je nach Bedarf Erbringung zusätzlicher Leistungen, wie in Kapitel 7 beschrieben.

3 Anforderungen an die Software Der Auftragnehmer stellt der KfW die Software wie nachfolgend, sowie in Anlage A.1 beschrieben zur Verfügung. Darüber hinaus schuldet der Auftragnehmer ergänzend diejenige Funktionalität, die er mit dem Angebot beigefügten Antwortvorlage „Anlage B.1 Wertungsmatrix Kriterienkatalog.xlsx“ als vorhanden gekennzeichnet hat. Die Software muss die in diesem Kapitel beschriebenen Anforderungen an Funktionalität, Berechtigungs- und Rollenkonzept, Reporting, Darstellung, Barrierefreiheit sowie an die App- Unterstützung erfüllen. Zudem muss sichergestellt sein, dass alle gesetzlichen Vorgaben im Zusammenhang mit Reisekosten sowie Spesen- und Kostenerstattungen eingehalten werden.

3.1 Funktionale Anforderungen (SaaS)

3.1.1 Erfassung und Verwaltung von Reisekosten und Kostenerstattungen Die vom Auftragnehmer geschuldete Software muss die vollständige Erfassung, Verwaltung, Genehmigung und Prüfung von Reisekosten sowie sonstigen Kostenerstattungen ermöglichen. Hierzu gehört, dass Benutzer alle relevanten Kostenpositionen einer Geschäftsreise (z.B. Fahrtkosten, Übernachtungen, Verpflegungsmehraufwand, sonstige Auslagen) strukturiert in entsprechenden Eingabeformularen erfassen und bei Bedarf mit Belegen hinterlegen können. Die Formulare müssen (z.B. pro Abrechnungskopf oder Ausgabeart) konfigurierbar und eine Zwangseingabe muss feldbasiert möglich sein. Ebenso müssen einmalige oder wiederkehrende Kostenerstattungen (z.B. Blumen zum Jubiläum, Team Essen, Bewirtungen, Geschenke) ohne Bezug zu einer Reise erfasst und von den Reisekosten separat betrachtet und ausgewertet werden können. ‑ Die vom Auftragnehmer geschuldete Software hat sowohl pauschalierte als auch belegbasierte Abrechnungen zu unterstützen. Dies umfasst insbesondere die korrekte und automatische Berechnung der jeweils gültigen Tages und Übernachtungspauschalen nach den in Deutschland und des Landes einer KfW Auslandsniederlassung geltenden gesetzlichen und steuerlichen Regelungen sowie die ‑einschlägigen Besonderheiten (z.B. Mahlzeitenabzüge, 3 Monatsregel). Es muss möglich sein, die gesetzlichen Pauschalen durch die KfW individuell zu ergänzen bzw. anzupassen. Bei Nutzung eines privaten PKW sind Kilometerpausch‑alen automatisch und anhand der gesetzlichen Vorgaben „kartengestützt“ zu berechnen und in der Abrechnung korrekt auszuweisen.

6

[Seite 7]

Leistungsbeschreibung RKA-Tool

Die Software muss darüber hinaus ermöglichen, private Anteile an Reisen und Ausgaben transparent zu kennzeichnen und separat auswertbar zu machen, sodass sowohl interne Vorgaben als auch steuerliche Anforderungen eingehalten werden können. Die Unterscheidung zwischen lohnsteuerfreien und steuerpflichtigen Leistungen ist systemseitig zu unterstützen; entsprechende Beträge sind getrennt auszuweisen. Schließlich muss es für den Benutzer möglich sein, bei Bedarf abweichende Kontierungsinformationen (z.B. Kostenstellen, Projekte oder weitere Kontierungsobjekte) zu erfassen. Die Software hat diese Informationen so zu verwenden, dass sie im Rahmen der Integration in das Finanz- und Rechnungswesen (SAP ERP) für die korrekte Verbuchung genutzt werden können. Siehe Anlage A.1.

3.1.2 Genehmigungs- und Freigabeworkflows Die vom Auftragnehmer geschuldete Software muss über einen konfigurierbaren, intuitiv bedienbaren sowie automatisierten Workflow zur Genehmigung und Freigabe von Reisekostenabrechnungen sowie für sonstige Kostenerstattungen verfügen. Der Workflow ist so auszugestalten, dass die heute bestehenden manuellen Prozessschritte automatisiert, Durchlaufzeiten verkürzt und Bearbeitungsfehler minimiert werden. Der Workflow muss mindestens folgende Anforderungen erfüllen: Abbildung mehrstufiger Genehmigung- und Prüfschritte entsprechend den internen Richtlinien der KfW, Zuordnung der jeweils verantwortlichen Rollen (z.B. Benutzer, Vorgesetzte, prüfende Stellen, Freigabe/Payroll), Konfigurierbare Vertretungs- und Eskalationsregelungen (z.B. bei Fristüberschreitungen oder Abwesenheiten), Transparente Nachvollziehbarkeit des Bearbeitungsstatus und der getroffenen Entscheidungen, z.B. anhand eines Prüfpfades Detaillierte Anforderungen an den Genehmigungsworkflow ergeben sich aus Anlage A.1. Je nach Prozessvorgabe der KfW muss es möglich sein, unterschiedliche Genehmigungswege abzubilden (z.B. Genehmigung durch direkte Führungskraft, zusätzliche Freigabe durch Fach- oder Budgetverantwortliche). Für Kostenerstattungen ohne Reisebezug muss ein separater, angepasster Workflow konfiguriert werden. Die Details der einzelnen Workflows sind der Anlage A.1 zu entnehmen. Die Software hat Vertretungs- und Assistenzregelungen zu unterstützen. Dies umfasst bspw. die Ablösung abwesender Genehmiger, die Zuweisung von Abrechnungen an Sekretariate oder Assistenzrollen sowie die Möglichkeit, Genehmigungsrechte zeitweise zu delegieren. Die hierfür erforderlichen Personen- und Organisationsdaten (z.B. Benutzer, Organisationseinheiten, Vorgesetzten- und Vertretungsbeziehungen) werden aus dem führenden HR-System (z.B. aktuell SAP HCM) übernommen oder im Profil manuell gepflegt. Die fachlichen und technischen Anforderungen an die Schnittstellen werden in der SST-Definition der Anlage A.1 konkretisiert. Zur Sicherstellung eines reibungslosen Ablaufs muss die Software automatische Benachrichtigungen an die Benutzer vorsehen, etwa bei Statusänderung einer Abrechnung, bei anstehenden oder überfälligen Genehmigungen sowie bei Rückfragen oder Rückweisungen von Abrechnungen. Diese Benachrichtigungen sollen insbesondere per E Mail oder als Push-Nachricht aus der entsprechenden App erfolgen und die Benutzer gezielt über erforderliche Aktivitäten informieren. ‑ 7

[Seite 8]

Leistungsbeschreibung RKA-Tool

3.1.3 Reporting und Transparenz Die vom Auftragnehmer geschuldete Software muss umfassende Reporting- und Analysemöglichkeiten zur Verfügung stellen, die es den berechtigten Benutzern ermöglichen, Reisekosten und Spesen nach unterschiedlichen Kriterien auszuwerten. Hierzu gehört eine Übersicht über alle eingereichten Abrechnungen einschließlich der jeweiligen Statusinformation (z.B. Entwurf, eingereicht, in Prüfung, genehmigt, ausgezahlt). Führungskräfte müssen in der Lage sein, die Abrechnungen ihrer direkt zugeordneten Mitarbeitenden einzusehen und Auswertungen über die in einem bestimmten Zeitraum angefallenen Reisekosten und Spesen zu erstellen. Dies umfasst insbesondere Berichte auf Benutzer , Kostenstellen- oder Organisationseinheitsebene sowie die Darstellung von Trends (z.B. Entwicklung der Reisekosten im Zeitverlauf). ‑ Die vom Auftragnehmer geschuldete Software hat Standardberichte bereitzustellen, die typische Auswertungsbedarfe abdecken, z.B. Kostenartenberichte (Fahrtkosten, Unterkunft, Verpflegung, Geschenke, Bewirtungen, sonstige Auslagen), Summen und Trendberichte oder Auswertungen zur Unterstützung von Compliance- und Steuerprüfungen. Darüber hinaus sollen berechtigte Benutzer eigene Berichte konfigurieren und ‑speichern können (Self Service-Reporting), ohne dass hierfür Eingriffe durch den Auftragnehmer erforderlich sind. ‑ Alle Berichte müssen rollenbasiert zugreifbar sein und in gängigen Formaten (mindestens Excel, PDF und CSV) exportiert werden können. Ferner muss die vom Auftragnehmer geschuldete Software die Möglichkeit bieten, Berichte automatisiert bereitzustellen, beispielsweise durch regelmäßigen Versand per E Mail oder durch ein sog. „Bursting“, bei dem Berichte entsprechend vordefinierter Empfängerkreise und zu festgelegten Zeitpunkten verteilt werden. ‑ Die vom Auftragnehmer geschuldete Lösung muss es den Benutzern ermöglichen einen Reisekostennachweis aus einer Abrechnung zu erstellen, damit die abzurechnenden Kosten vollständig und nachvollziehbar dokumentiert sind und die korrekte Prüfung sowie sachgerechte Erstattung sichergestellt werden kann. Darüber hinaus muss die vom Auftragnehmer geschuldete Software eine revisionssichere und GoBD-konforme Dokumentation der Reisekosten- und Spesenprozesse ermöglichen. Änderungen an Abrechnungen und Stammdaten müssen nachvollziehbar und auditierbar sein, sodass sowohl interne als auch externe Prüfungen (Revision, Steuerprüfung, Betriebsprüfungen) effizient unterstützt werden.

3.1.4 Belegmanagement und Automatisierung Die vom Auftragnehmer geschuldete Software muss eine durchgängige digitale Erfassung und Verwaltung von Belegen ermöglichen. Benutzer sollen Belege sowohl im Web Frontend als auch über die mobile App hochladen bzw. erfassen können. Darüber hinaus ist es erforderlich, dass Belege per E Mail an die Software übermittelt und dort automatis‑ch dem richtigen Benutzer und – soweit möglich – der entsprechenden Abrechnung zugeordnet werden können. ‑ Zur Reduzierung des manuellen Aufwands muss die Software, Funktionen zur automatisierten Belegerkennung (z.B. mittels OCR und ggf. KI gestützter Verfahren) bereitstellen. Diese haben insbesondere Beträge, Ausgabeorte, Steuersätze, Datum, Währung und relevante Stammdaten (z.B. Firmenanschrift auf ‑Hotelrechnungen) aus Belegen in mehreren Sprachen (s. Anlage A.1) auszulesen und für die weitere Verarbeitung aufzubereiten. Zudem sollen die Belege automatisch der korrekten Spesenart zugeordnet werden. Die Benutzer müssen die Möglichkeit haben, die erkannten Informationen zu

8

[Seite 9]

Leistungsbeschreibung RKA-Tool

überprüfen und bei Bedarf zu korrigieren; eine manuelle Kontrolle der OCR Ergebnisse ist daher zwingend vorzusehen. ‑ Es muss außerdem möglich sein, für Auslandsbelege, Beträge in Fremdwährung zu erfassen. Dabei soll eine automatische Umrechnung in die Heimatwährung des Benutzers erfolgen, basierend auf dem tagesaktuellen Umrechnungskurs. Für Bewirtungsbelege oder andere Veranstaltungen soll es für die Benutzer die Möglichkeit geben, Teilnehmer inkl. Firmenzugehörigkeit, manuell oder per Upload hinzuzufügen. Die vom Auftragnehmer geschuldete Software muss die in Deutschland und anderen Ländern üblichen E Rechnungsformate (z.B. XML Formate, ZUGFeRD) empfangen, verarbeiten und in ein für die Benutzer lesbares Format (z.B. PDF) überführen können. Darüber hinaus soll ‑die Software in der Lage sein,‑ aus angebundenen Drittsystemen (z.B. Kreditkartenanbieter, Reisebuchungssystem, Reisedienstleister wie HRS Pay oder Deutsche Bahn) eingehende Daten und Belege zu importieren und die darin enthaltenen Transaktionen oder Belege automatisch den passenden Benutzern und Abrechnungen inklusive der korrekten Spesenarten zuzuordnen. Für den Fall, dass Originalbelege verloren gehen, hat der Auftragnehmer eine durch die Software unterstützte Eigenbelegerstellung vorzusehen, die den deutschen steuerlichen Anforderungen bzw. des den steuerlichen Anforderungen des Landes der KfW Niederlassung genügt und entsprechend als Eigenbeleg gekennzeichnet wird.

3.1.5 Steuer- und lohnsteuerrelevante Anforderungen Die vom Auftragnehmer geschuldete Software muss sämtliche steuer- und lohnsteuerrelevanten Aspekte einer Reisekosten- und Spesenabrechnung fachlich korrekt abbilden. Hierzu gehört insbesondere die automatische Berechnung und Aufsplittung von Ausgaben, die unterschiedlichen Steuersätzen unterliegen, sowie der korrekte Ausweis dieser Steuersätze für die Weiterverarbeitung im Finanzsystem, inkl. der hinterlegten Steuerkennzeichen. Die jeweils geltenden gesetzlichen Tages- und Übernachtungspauschalen sowie Kilometerpauschalen des jeweiligen KfW Standortes sind durch die Software zu hinterlegen und regelmäßig zu aktualisieren. Änderungen der gesetzlichen Vorgaben hat der Auftragnehmer zeitgerecht – und im besten Fall automatisch – umzusetzen, sodass Abrechnungen stets auf Basis der aktuellen Werte erfolgen. Ergänzend muss es möglich sein, firmenspezifische Regelungen abzubilden, etwa abweichende Pauschalen oder interne Reisekostenrichtlinien. Bei der Angabe und Berechnungen von Tagespauschalen muss es möglich sein, als Ausgangspunkt zwischen dem Wohnsitz und dem Firmenstandort zu unterscheiden, eine entsprechende Erfassung ist daher erforderlich. Lohnsteuerpflichtige Sachzuwendungen wie Geschenke, Bewirtungen oder bestimmte Veranstaltungen sind als solche erfassbar und eindeutig zu kennzeichnen. Die vom Auftragnehmer geschuldete Software muss die Möglichkeit bieten, die steuerliche Abzugsfähigkeit (z.B. beschränkt abzugsfähige Aufwendungen) systemseitig abzubilden und in den Berichten sowie in den für die Lohnabrechnung erforderlichen Daten entsprechend auszuweisen. Die für die Lohnabrechnung notwendigen Informationen (z.B. Sachbezugswerte, Lohnarten, steuerliche Kennzeichen, geldwerte Vorteile) sind in geeigneter Form zur Übergabe an die angebundene Payroll Lösung aufzubereiten. Darüber hinaus soll die Software – sofern im Angebot angegeben – Optionen zur Unterstützung von Vorsteuerrückerstattungsverfahren (z.B. in Deutschland, ‑EU, Schweiz) bereitstellen.

9

[Seite 10]

Leistungsbeschreibung RKA-Tool

3.1.6 Betrugs- und Fehlererkennung Die Software muss Funktionen zur automatisierten Erkennung potenzieller Fehler und Auffälligkeiten bereitstellen, um Missbrauch und Betrug zu vermeiden und Prüfaufwände zu fokussieren sowie zu reduzieren. Hierzu zählen Prüfregeln (s. Anlage A.1) die bereits während der Erfassung, Genehmigung und Prüfung von Abrechnungen aktiv sind und Benutzer durch Hinweise, Warnungen oder harte Sperren auf Unstimmigkeiten aufmerksam machen. Beispiele hierfür sind die Identifikation mehrfach eingereichter oder KI-generierter (nicht richtlinienkonformer) Belege, das Erkennen doppelter oder auffälliger Ausgaben für denselben Tag, ungewöhnliche Betragskonstellationen oder Konflikte mit innerbetrieblichen Richtlinien (z.B. Überschreitung von Höchstbeträgen). Darüber hinaus muss die Software eine automatisierte, risikoorientierte Auswahl von Abrechnungen für Stichprobenprüfungen unterstützen. Die zugrunde liegenden Kriterien (z.B. bestimmte Ausgabe- oder Belegarten, Betragsgrenzen, Länder, Ausgabekategorien) müssen durch die KfW konfigurierbar und jederzeit anpassbar sein, sodass Prüfkapazitäten gezielt eingesetzt werden können.

3.1.7 Weitere Unterstützungsfunktionen für Benutzer Die vom Auftragnehmer geschuldete Software muss den Benutzer bei der Erledigung wiederkehrender Aufgaben und der Einhaltung der Prozessvorgaben sowie Unternehmensrichtlinien bestmöglich unterstützen. Hierzu gehört unter anderem die Möglichkeit, bestehende Abrechnungen zu kopieren und für neue, ähnlich gelagerte Abrechnungen wiederzuverwenden, um den Erfassungsaufwand zu reduzieren. Es muss möglich sein, bereits ausgezahlte Abrechnungen unter Beachtung der Anforderungen an Revisionssicherheit und GoBD erneut zu öffnen und zu korrigieren, wenn bspw. weitere Belege nachzureichen oder Kontierungsobjekte anzupassen sind. Die dabei entstehenden Änderungen sind lückenlos zu protokollieren und das Delta an nachgelagerte Systeme zu übermitteln. Die Software muss darüber hinaus geeignete Such-, Sortier- und Filterfunktionen bereitzustellen, sodass Benutzer, Genehmiger und Prüfer Abrechnungen und Belege nach unterschiedlichen Kriterien (z.B. Zeitraum, Benutzer, Kostenart, Status) zielgerichtet finden und auswerten können.

3.1.8 Löschkonzept Der Auftragnehmer hält für die vertragsgegenständliche Software ein EU-DSGVO-konformes Löschkonzept vor und stellt dieses der KfW als Bestandteil der vertraglich geschuldeten Leistungen zur Verfügung. Er wendet das Löschkonzept im Rahmen des Betriebs der SaaS-Lösung eigenverantwortlich an und ist für die fristgerechte Löschung bzw. Anonymisierung der Daten verantwortlich.

3.1.9 Nachhaltigkeit Die vom Auftragnehmer geschuldete Software unterstützt die Berechnung und Auswertung der mit Dienstreisen verbundenen CO -Emissionen auf Basis etablierter Emissionsfaktoren, vorzugsweise nach DEFRA/TIM. Es ermöglicht zudem die Zuordnung von Emissionen zu Kostenstellen/Projekten und stellt tran₂sparente Reporting-Funktionen zur Verfügung, die ESG-relevante Kennzahlen (z. B. CO -Emissionen, Nutzung nachhaltiger Verkehrsmittel, Einhaltung von ESG-Reisevorgaben) auswertbar machen und deren Berechnungslogik dokumentieren. ₂

10

[Seite 11]

Leistungsbeschreibung RKA-Tool

3.2 Funktionale Anforderungen (App für den Einsatz auf mobilen Endgeräten) Für den Einsatz auf mobilen Endgeräten (z.B. Smartphones, Tablets) muss der Auftragnehmer eine App bzw. mobile Client Software bereitstellen, die die wesentlichen Funktionen der Reisekosten- und Spesenabrechnung unterstützt. Die App muss den Benutzer ermöglichen, Reisen und Auslage‑n unmittelbar unterwegs zu erfassen, Belege per Foto aufzunehmen und hochzuladen sowie den Status der Abrechnungen einzusehen. Führungskräfte und andere Genehmigungsberechtigte müssen über die App Abrechnungen prüfen, Rückfragen stellen und Genehmigungen erteilen können, ohne auf einen stationären Arbeitsplatz angewiesen zu sein. Die App hat hierfür intuitive Oberflächen bereitzustellen, die auch auf kleineren Displays eine komfortable Bedienung erlauben. Die App muss mindestens die aktuellste Version des mobilen Betriebssystem iOS unterstützen. Zudem darf es nur möglich sein, die App im KfW-eigenen App-Store zum Download zur Verfügung zu stellen.

3.3 Darstellung / Browserunabhängigkeit / Endgeräte, Usability und Barrierefreiheit Die vom Auftragnehmer geschuldete Software ist so auszugestalten, dass sie auf unterschiedlichen Endgeräten (PC, Notebook, Tablet, Smartphone) im Browser vollständig und lesbar dargestellt wird und Benutzer mit jedem dieser Geräte uneingeschränkt arbeiten können. Die Darstellung hat sich automatisch an die jeweilige Displaygröße anzupassen (responsive Design); Grafiken und Oberflächen sind hinsichtlich Ladezeiten und Auflösung zu optimieren. Der Auftragnehmer muss die Software so ausgestalten, dass sie mindestens von den folgenden Browsern unterstützt, wird:

 Safari mobile  Microsoft Edge Die Software muss über das jeweils aktuellste Release der oben genannten Browser sowie dessen Vorgänger (n-1) zugreifbar sein. Die Bedienoberflächen sind vom Auftragnehmer benutzerfreundlich und intuitiv zu gestalten, um die Akzeptanz der Lösung zu erhöhen und Schulungsaufwände zu begrenzen. Die Software muss mehrsprachig zur Verfügung stehen, mindestens in deutscher und englischer Sprache. Benutzer müssen zur besseren Benutzerführung Hinweise, wie bspw. Mouse Over mit Informationen zur Feldeingaben, bei der Erfassung und Bearbeitung der Abrechnung bereitgestellt werden. Fehleingaben müssen durch entsprechende Beschreibungen und Icons gekennzeichnet werden, z.B., Sternchen für Pflichtfelder, Dreieck für Warnungen und Ausrufezeichen für Stoppkriterien, die den Prozess blockieren. Die Frontend Funktionalitäten der Software (Web Frontend und App) müssen die jeweils gültigen gesetzlichen Anforderungen an die Barrierefreiheit erfüllen (derzeit § 12a BGG i.V.m. BITV 2.0). Die‑ Umsetzung der Barrierefreiheit ist v‑om Auftragnehmer zu dokumentieren und der KfW auf Anforderung nachzuweisen. Eine lokale Installation von der Software für die generelle Nutzung der vom Auftragnehmer geschuldeten SaaS-Software auf den PCs oder Notebooks, also abgesehen von der App gem. Ziff. 3.2, darf für die Nutzung des RKA-Tools nicht erforderlich sein. 3.4 Zugangs- und /oder Nutzungsvoraussetzungen Die vom Auftragnehmer geschuldete Software muss über eine durch die KfW konfigurierbare, automatisierte Benutzer- und Rollenverwaltung verfügen, die an den zentralen Identity Provider der KfW (derzeit Microsoft Entra ID) angebunden werden kann.

11

[Seite 12]

Leistungsbeschreibung RKA-Tool

Die Neuanlage, Anmeldung und Berechtigungsprüfung der Benutzer hat über ein Single Sign On (SSO) Verfahren mit einer Just-In-Time-Provisioning-Funktionalität zu erfolgen. Dazu muss der Auftragnehmer eine geeignete SSO Integration inkl. der Übertr‑agung‑ un‑d Auswertung der Credentials (z.B. auf Basis OAuth 2.0) zur Verfügung stellen und ihre dauerhafte Funktionsfähigkeit gewährleisten. ‑ Benutzerstammdaten, insbesondere Personaldaten aus dem Personaldaten-System, sind automatisiert in die Software zu übernehmen und aktuell zu halten. Veränderungsereignisse (z.B. Eintritt, Austritt, Namens- und Rollenwechsel, Änderung der Organisationseinheit und Kostenstellen) müssen unverzüglich berücksichtigt werden, sodass verwaiste oder unberechtigte Zugriffe vermieden werden. Der Auftragnehmer hat zu gewährleisten, dass die Software über SCIM 2.0 oder ein gleichwertiges Protokoll, eine automatisierte Bereitstellung und Aufhebung der Bereitstellung von Benutzern unterstützt. Nicht mehr benötigte Benutzer werden unverzüglich deaktiviert oder im Sinne der EU-DSGVO gelöscht.

Der Auftragnehmer gewährleistet, dass die im Rahmen des Einführungsprojektes aktuellen KfW-Richtlinien zur Passwortvergabe eingehalten werden. Der Auftragnehmer muss gewährleisten, dass Passwörter verschlüsselt gespeichert werden. 3.5 Benutzer & Rollenverwaltung Hinsichtlich der Benutzer- und Rollenverwaltung bestehen die folgenden Pflichten des Auftragnehmers bzw. Anforderungen an die von ihm geschuldete Software: Die Software muss die Abhängigkeiten zwischen den Rollen (Funktionstrennung bzw. Separation of Duties) berücksichtigen, um diese klar voneinander abzugrenzen. Des Weiteren stellt der Auftragnehmer sicher, dass auch die Standardbenutzer/ benutzergruppen, die nicht zur Leistungserbringung notwendig sind, gelöscht oder deaktiviert werden. Die Software ist so auszugestalten, dass jeder Benutzer nur diejenigen Rechte hat, die er zur Erledigung seiner Aufgaben benötigt. Insbesondere, dass eine Person nicht gleichzeitig eine Abrechnung erstellen und endgültig freigeben kann (Vieraugenprinzip). Die Rechtevergabe ist so auszugestalten, dass jeder Benutzer nur diejenigen Funktionen und Daten einsehen und bearbeiten kann, die er zur Erfüllung seiner Aufgaben benötigt (Need to know Prinzip).

Der Auftragnehmer ist verpflichtet administrative und privilegierte Zugriffe lokal zu ‑ ‑ ‑ protokollieren und bei Bedarf auszuwerten, um den Anforderungen an Informationssicherheit und Compliance zu genügen. Der Auftragnehmer hat mit Abschluss seiner ISO 27001 Zertifizierung, sicherzustellen, dass die administrativen Berechtigungen halbjährlich einer dokumentierten Prüfung unterzogen werden. Der Auftragnehmer hat eine Informationspflicht über die in seinem IT-System zugewiesenen Rechte. 3.6 Rechte & Rollenkonzept Die vom Auftragnehmer geschuldete Software muss über ein rollenbasiertes Berechtigungsmodell verfügen (s. Anlage A.1) mit dem der Zugriff auf Funktionen und Daten granular gesteuert werden kann. Folgende Rollen sind vom Auftragnehmer mindestens vorzusehen:

 Power User: IT-& Fachbereich-seitige Konfiguration der Software

12

[Seite 13]

Leistungsbeschreibung RKA-Tool

 KfW & IPEX Mitarbeitende: Benutzer mit Erfassungsrechten  Genehmiger  Prüfer/Revision  Steuerfachbereich  Sekretariate  Monitoring und Reporting Des Weiteren müssen nachfolgende Mindestanforderungen bezüglich der Konfiguration der Berechtigungsvergabe System-seitig gegeben sein:

 Das Anlegen neuer Rollen muss durch die KfW eigenständig möglich sein  Die Rechte der Rollen müssen durch die KfW den aktuellen Gegebenheiten angepasst werden können  Einem Benutzer müssen mehrere Rollen zugeordnet werden können Weiterhin ist vorzusehen, dass Berechtigungen organisations- oder funktionsbezogen vergeben werden können (z.B. differenzierte Rechte für verschiedene Geschäftseinheiten).

3.7 E-Mail Hosting & Versand Der Auftragnehmer schuldet ein Reisekostenabrechnungs- und Kostenerstattungssystem, das den Versand anlassbezogener, automatisierter E-Mail-Nachrichten an bestimmte Benutzer unterstützt. Der Auftragnehmer muss gewährleisten, dass die Software die nachfolgenden Anforderungen erfüllt:

 Der Auftragnehmer stellt der KfW für ausgehenden E-Mails einen Mail-Server zur Verfügung, welcher sich im Europäischen Wirtschaftsraum (exklusive Vereinigtes Königreich) befindet.  Für den Mail-Server ist eine IP-Adresse zu vergeben, kein Bereich an IP-Adressen.  Der Mail-Server verfügt über eine positive Cisco Reputation (bei der KfW kommen aktuelle Cisco-Komponenten zum Einsatz) und darf keine Sicherheitsmängelaufweisen. (z.B. kein Internet Blacklist Eintrag).  Die Software muss technisch in der Lage sein, nicht zugestellte oder rückläufige E- Mails die z.B. abgelehnt wurden (z.B. temporär) oder auch beantwortete no-reply Mails, erneut zu versenden oder anderweitig zu verarbeiten (z.B. Queuing, Autoresponder).  Der Auftragnehmer gewährleistet, dass DMARC durch die Software aktiv genutzt wird.  Die Software verwendet zur E-Mailauthentifizierung mindestens SPF und DKIM.  Der Auftragnehmer gewährleistet, dass der Mail-Server über Sicherheitsmodule wie z.B. Anti-Virus, Anti-Spam und einen Content Filter-System verfügen. Alle zu versendenden E-Mails müssen auf maliziöse Inhalte, Spam, Würmer und Trojaner überprüft werden. Für die Überprüfung ist mindestens ein geeigneter Viren-Scanner heranzuziehen.  Der Auftragnehmer trägt Sorge dafür, dass die versendeten E-Mails beim Empfänger nicht als Spam eingestuft werden.  Der E-Mail Server darf keine (dauerhafte) Weiterleitungs-Regel besitzen.  Der E-Mail-Versand folgt den weltweiten Standards, sogenannten RFCs (Request for Comments), in welchen Protokolle und Formatvorgaben exakt definiert sind.  Der Kommunikationsaufbau vom Server des Auftragnehmers zum Auftraggeber erfolgt mindestens mittels STARTTLS.

13

[Seite 14]

Leistungsbeschreibung RKA-Tool

 Der E-Mail-Versand muss durch die Software hinsichtlich Mailvolumen pro Stunde einstellbar sein. Die Einstellung muss durch den Auftragsnehmer oder die KfW änderbar sein.  Die Software muss verschiedene E-Mail-Vorlagen verwalten und bereitstellen können. Dabei müssen die Vorlagen durch die KfW frei konfigurierbar erzeugt werden können  Der E-Mailversand muss durch die KfW konfiguriert und eingerichtet werden können. Es muss sowohl ein automatisierter als auch ein manueller Versand konfigurierbar sein.  Die Software berücksichtigt für den E-Mail-Versand alle gesetzlichen Vorgaben sowie regulatorische Vorgaben der KfW Bankengruppe (z.B. Datenschutz).  Der E-Mail-Versand erfolgt über die von der KfW vorgegebene Subdomain-Adressen (@.kfw.com). Damit wird sichergestellt, dass E-Mails auch an nicht-KfW Empfänger gesendet werden können. Eine Konkretisierung erfolgt sofern notwendig im Einführungsprojekt.  Es dürfen für den Versand keine manipulierten E-Mail-Adressen verwendet werden.  Nicht mehr gültige E-Mail Adressen müssen identifiziert und vom weiteren Versand ausgeschlossen werden. Bei einem Massenversand von E-Mails müssen diese zeitversetzt in mehreren Tranchen von maximal 500 Nachrichten pro Stunde über einen längeren Zeitraum versendet werden. Die zeitlichen Versandkorridore sind mit der KfW abzustimmen.

3.8 Schnittstellen Die Systemlandschaft setzt sich aus der vom Auftragnehmer geschuldeten Software, den angebundenen KfW-Systemen und verschiedenen Third-Party-Systemen zusammen. Nachfolgend werden die vom Auftragnehmer bereitzustellenden Schnittstellen und die zukünftig geplante Anwendungslandschaft näher beschrieben.

Abbildung 1: Zukünftige Anwendungslandschaft

14

[Seite 15]

Leistungsbeschreibung RKA-Tool

3.8.1 KfW-Systeme Für eine leistungsfähige Reisekosten- und Kostenerstattungssoftware ist eine weitreichende Integration von SAP-Systemen erforderlich, da zwischen den Systemen bestimmte Stamm- und Bewegungsdaten ausgetauscht werden müssen. Die Software muss für den Datentransfer SAP PI und SAP CI unterstützen. Aus KfW Sicht lässt sich zum aktuellen Zeitpunkt noch nicht abschätzen welche Middleware zum Einsatz kommen soll. Daher entscheidet die KfW während des Einführungsprojektes, welche Middleware vom Auftragnehmer zu verwenden ist. Nach dem Datentransfer muss eine automatisierte Datenintegritätsprüfung möglich sein (z.B. über HMAC_SHA / SHA256 oder höher).

3.8.2 Third-Party-Systeme Der Auftragnehmer schuldet die Einrichtung der Schnittstellen zwischen der Software und den folgenden, von der KfW bereits eingesetzten, Third-Party-Systemen:

 HRS Pay  SEB Kort Bank AB (ehemals AirPlus) Ziel der Anbindungen ist die automatisierte Übernahme und Verarbeitung von Transaktions- und Rechnungsdaten aus den genannten Third-Party-Systemen in der Software, sodass diese Daten für die ordnungsgemäße und effiziente Durchführung der Reisekostenabrechnung zur Verfügung stehen. Der Auftragnehmer gewährleistet, dass die erforderlichen Schnittstellen den sicheren und zuverlässigen Datenaustausch zwischen der Software und den jeweiligen Third-Party- Systemen ermöglichen. Die Datenübertragung ist mindestens nach TLS 1.2 verschlüsselt durchzuführen. Für den Verbindungsaubau müssen sichere Authentifizierungsverfahren verwendet werden. Die technische Umsetzung der Anbindungen kann – abhängig von den technischen Möglichkeiten und Anforderungen des jeweiligen Third-Party-Systems – über geeignete API- Technologien oder mittels SFTP-basiertem Datentransfer erfolgen. Der Auftragnehmer hat hierbei sicherzustellen, dass die jeweils eingesetzte Integrationslösung den fachlichen Anforderungen sowie den geltenden Anforderungen an Datenschutz, Informationssicherheit, Verfügbarkeit und Datenintegrität entspricht. Eine detaillierte Beschreibung der Schnittstellen ist der Anlage A.1 zu entnehmen. 4 Nutzungsumfang und -voraussetzungen 4.1 Nutzungsumfang

4.1.1 Grundbedarf Der Auftragnehmer stellt der KfW die Software in folgendem Umfang zur Verfügung. Dieser Umfang umfasst:

 die Bereitstellung der Anwendung als SaaS-Lösung für alle Mitarbeiter (ca. 10.000 Benutzer) der KfW und IPEX  die Überlassung der mobilen App zur Erfassung und Bearbeitung von Reisekosten und sonstigen Kostenerstattungen auf mobilen Endgeräten ebenfalls für alle o.g. Mitarbeiter

15

[Seite 16]

Leistungsbeschreibung RKA-Tool

 25.000 Transaktionen pro Jahr

4.1.2 Nachbeschaffungsoption, Mengenerweiterung/-reduzierung Der Auftragnehmer räumt der KfW die Möglichkeit ein, den Nutzungsumfang während der Vertragslaufzeit zu erweitern oder reduzieren, etwa durch:

 Hinzunahme oder entfernen weiterer Benutzergruppen oder Organisationseinheiten (z.B. KfW Capital, Auslandsbüros)  Erhöhung oder Reduzierung der Benutzerzahlen,  Erhöhung oder Reduzierung der Transaktionszahlen,  Erweiterung oder Reduzierung des funktionalen Umfangs im Rahmen der vom Auftragnehmer angebotenen Module. Die KfW ist berechtigt, ergänzende Lizenzen bzw. Nutzungskontingente zu den im Preisblatt vereinbarten Konditionen nachzubestellen bzw. abzubestellen. Der Auftragnehmer hat diese Kontingente unverzüglich, spätestens jedoch innerhalb von 4 Wochen nach Anforderung bereitzustellen. 4.2 Umgebungen Der Auftragnehmer hat der KfW folgende Umgebungen und die dafür erforderlichen Zugangsberechtigungen zur Verfügung zu stellen

Der Auftragnehmer hat der KfW erforderliche Zugangsdaten in ausreichender Menge zur Verfügung zu stellen, wie sie für die Ausführung von Aufgaben in den verschiedenen Umgebungen für die in der Übersicht definierten Zwecke erforderlich sind. Grundsätzlich werden die KfW-Nutzer die KfW-TEST Umgebung jedoch in deutlich geringerer Zahl nutzen. Die Kosten für die Bereitstellung der KfW-TEST Umgebung und der erforderlichen Zugangsdaten sind in der monatlichen Pauschale gemäß Pos. 2.1 des Preisblattes enthalten. Während des Einführungsprojekt muss eine weitere Umgebung (DEV) zur Verfügung gestellt werden, die darauf entfallenden Kosten sind in den Preis des Implementierungsprojektes zu inkludieren. Nach Abschluss des Implementierungsprojektes und während der gesamten Vertragslaufzeit der Software muss die Umgebung auf Anforderung der KfW mit einem Vorlauf von 3 Wochen auf- und abgebaut werden können. Die für die Dauer der Nutzung anfallenden monatlichen Kosten müssen in Pos. 3.3 des Preisblattes aufgeführt werden.

16

[Seite 17]

Leistungsbeschreibung RKA-Tool

Der Auftragnehmer hat der KfW erforderlichen Zugangsdaten in ausreichender Menge zur Verfügung zu stellen, wie sie für die Ausführung der Aufgaben für die in der Übersicht definierten Zwecke erforderlich sind.

Die folgenden Anforderungen gelten für die Bereitstellung und den Betrieb dieser Umgebungen:

4.2.1 Trennung und Parität

 Alle Umgebungen müssen in Bezug auf Daten und Zugriffsrechte vollständig voneinander getrennt betrieben werden. Die Umgebung (PROD) mit Produktionsdaten muss von den Umgebungen ohne Produktionsdaten (DEV, TEST) isoliert werden, ein unbeabsichtigter Datenfluss zwischen den beiden Klassen muss technisch ausgeschlossen werden.

4.2.2 Release Management

 Änderungen für die Erstfreigabe der Software in die Produktion oder von der KfW geforderte Änderungen an Konfiguration, Customizing, Software und Schnittstellen müssen dem kontrollierten Pfad DEV → TEST → PROD folgen.  Die Software-Updates, Patches und Neuveröffentlichungen des Auftragnehmers folgen dem vom Auftragnehmer festgelegten Release-Management-Pfad mit der Ausnahme, dass funktionale Änderungen oder Änderungen der API gemäß Kapitel 6.3 mitgeteilt werden müssen.

4.2.3 Datenbereitstellung

 Der Auftragnehmer gewährleistet, dass personenbezogene und sensible Geschäftsdaten gemäß der DSGVO anonymisiert oder pseudonymisiert werden, wenn Produktionsdaten in DEV und TEST bereitgestellt werden.

4.2.4 Schnittstellen Die Software tauscht Daten mit internen Anwendungen der KfW und Third-Party-Systemen aus. Der Auftragnehmer muss in jeder Umgebung die dokumentierten Schnittstellen bereitstellen und gewährleisten, dass jede Umgebung mit den entsprechenden Anwendungen verbunden ist. Grundbedarf und Nachbeschaffungsoptionen

4.3 Kopier- und Nutzungssperren in clientseitige Software (App) Sofern für die Nutzung der SaaS-Lösung clientseitige Software (z.B. eine App für mobile Endgeräte) erforderlich ist, sind Kopier- und Nutzungssperren nur zulässig, wenn diese im Angebot des Auftragnehmers konkret beschrieben und im Vertrag ausdrücklich vereinbart wurden. Insbesondere sind technische Beschränkungen oder Sperren unzulässig, die:

 die vertragsgemäße Nutzung der App durch die KfW behindern oder  die Nutzung ohne vorherige transparente Information und ausdrückliche Zustimmung der KfW einschränken. Versteckte oder nicht dokumentierte Kopier- und Nutzungssperren sind ausgeschlossen.

17

[Seite 18]

Leistungsbeschreibung RKA-Tool

4.4 Prüfpflichten, Schadsoftware und unerwünschte Funktionalität Der Auftragnehmer verpflichtet sich, dass die zur Leistungserbringung eingesetzte Software sowie die zugrunde liegende IT-Infrastruktur regelmäßig und nach dem Stand der Technik auf Schadsoftware und sonstige schädliche Programmcodes geprüft werden. Hierzu sind aktuelle Schutzmechanismen (z.B. Virenschutz, Malware-Scanner) einzusetzen. Der Auftragnehmer gewährleistet, dass die bereitgestellte Software und die eingesetzten IT- Systeme keine Funktionen enthalten, die:

 die Vertraulichkeit, Integrität oder Verfügbarkeit der KfW-Systeme oder -Daten beeinträchtigen,  ungewollt Daten über die Nutzung der Software, die KfW-Infrastruktur oder das Benutzerverhalten an Dritte übermitteln,  ohne Wissen der KfW Daten manipulieren oder unzulässige Funktionserweiterungen deaktivieren.

4.5 Dokumentation Der Auftragnehmer hat der KfW alle für den Zugang zur Software erforderlichen Informationen, technischen Spezifikationen und Unterlagen in ausreichendem Umfang zur Verfügung zu stellen. Die Lieferung der Unterlagen ist Bestandteil der Hauptpflicht. Hierzu gehören insbesondere Beschreibungen die nachfolgend aufgeführten Dokumentationen. Der Auftragnehmer stellt der KfW eine vollständige und aktuelle Dokumentation der Software in deutscher Sprache zur Verfügung. Die Dokumentation ist der KfW in elektronischer Form zur Verfügung zu stellen. Textdokumente sind in einem gängigen Office-Format (z.B. M365) sowie als PDF bereitzustellen. Eine Benutzerdokumentation kann abweichend auch als Online- Dokumentation (z.B. Wiki, Online-Hilfe) geführt werden, sofern ein Export bzw. eine Sicherung möglich ist. Die KfW ist berechtigt, die Dokumentation für interne Zwecke zu vervielfältigen, zu verteilen und – soweit erforderlich – anzupassen (z.B. Ergänzung um interne Prozessbeschreibungen). Der Auftragnehmer hat sicherzustellen, dass die Wirksamkeit, der im technischen Design der Software beschriebenen Sicherheitsmaßnahmen über die Anwendung aktuell dokumentierter Testszenarien und Testfälle nachgewiesen wird. Der Auftragnehmer hat sicherzustellen, dass die aktuell produktive Version der Software gemäß der Testvorgaben getestet wurde. Der Auftragnehmer ist dafür verantwortlich, diese Dokumentation regelmäßig, mindestens nach jedem Upgrade der Lösung, zu aktualisieren und der KfW zur Verfügung zu stellen.

4.5.1 Fachliches und Technisches Design (FuTD) für die Software Der Auftragnehmer hat bei der Erstellung eines Fachlichen und Technischen Designs auf Basis einer von der KfW bereitgestellten Vorlage mitzuwirken, dass insbesondere den Umfang und die technische Umsetzung der geforderten Sicherheitsmaßnahmen beschreibt. Der Auftragnehmer hat im FuTD insbesondere die von ihm angebotene Umsetzung aller fachlichen Anforderungen der KfW in der Software zu beschreiben. Dies schließt die Dokumentation der erforderlichen KfW-individuellen Anpassungen in der Software (Parametrisierung, Konfiguration oder Individualentwicklung) ein.

18

[Seite 19]

Leistungsbeschreibung RKA-Tool

Im Hinblick auf die im FuTD dargestellten Prozesse berät der Auftragnehmer zur Prozessoptimierung in Verbindung mit dem Produkteinsatz. Der Auftragnehmer bestätigt durch Review und Freigabe des FuTDs die Vollständigkeit und Korrektheit der für seine weitere Arbeit relevanten Angaben. Das FuTD beinhaltet Schnittstellenspezifikationen. Der Auftragnehmer hat diesbezüglich folgendes zum FuTD zuzuliefern:

 Beschreibung der verwendeten Formate und deren Inhalt  Technische Beschreibung der Schnittstelle (z. B. Protokolle, Verschlüsselungsverfahren, Zertifikate, verwendete technische Benutzerkonten)  Typ der Schnittstelle (z. B. Online-Schnittstelle als API oder Dateischnittstelle)  Einbindung der Schnittstelle in die Prozesse der KfW (z. B. Intervalle, Zeitpunkte)  Schnittellen mit KfW Systemen  Schnittstellen mit Third Party Systemen

Die Dokumentation muss einen Detaillierungsgrad aufweisen, welcher die notwendigen Implementierungen auf KfW-Seite ermöglicht. Die KfW nimmt das FuTD unter dem Fokus der Weiterverwendbarkeit und Einhaltung der Dokumentationsvorschriften ab.

4.5.2 Stufentestkonzepte für Systemtest, Systemintegrationstest, UAT Der Auftragnehmer schuldet die Mitwirkung bei der Erstellung von Stufentestkonzepten. Hierzu gehören auch die jeweiligen Testfallkataloge. Für den Teil der Software, der das Reisekostenabrechnungstool betrifft, berät der Auftragnehmer die KfW bei der Bedarfs- und Impactanalyse, bei der Aufwandsschätzung und bei der Detailplanung erforderlichen Testaktivitäten mit seiner Expertise aus anderen vergleichbaren Implementierungsprojekten mit. Der Auftragnehmer berät zudem zu den Möglichkeiten der Testautomatisierung.

4.5.3 Applikationsspezifisches Berechtigungskonzept Der Auftragnehmer schuldet die Lieferung der für die Erstellung des Berechtigungskonzeptes notwendigen Informationen. Der Auftragnehmer hat zu beraten, wie die Berechtigungskonzepte nach Kapitel 3.5 am besten funktional und technisch in der Software umgesetzt werden können

4.5.4 IT-Sicherheitskonzept Der Auftragnehmer schuldet die Mitwirkung bei der Erstellung eines IT-Sicherheitskonzeptes. Dies beinhaltet insbesondere Unterstützung in Bezug auf folgende Punkte:

• Funktionsbeschreibung
• Technische Beschreibung (z.B. Architektur, Komponenten, Schnittstellen, Firewall- Regeln)
• Physische und Umgebungssicherheit (z.B. Zutrittskontrolle) Zugriffs- und Zugangskontrolle (z.B. Benutzerzuweisungsprozess, Passwortverwaltung)
• Protokollierung
• Datensicherung und -wiederherstellung

19

[Seite 20]

Leistungsbeschreibung RKA-Tool

• Spezielle Sicherheitsmaßnahmen (z.B. Schutz vor Malware, Patch- und Release- Management)

5 Projekthafte Einführung zur Bereitstellung des Services und der Software 5.1 Zielsetzung und Leistungscharakter Der Auftragnehmer schuldet die erfolgreiche Einführung der Software als Erfolg im Sinne einer werkvertraglichen Leistung. Die erfolgreiche Einführung umfasst:

 die Herstellung der vollständigen Betriebsbereitschaft der Software in der Produktivumgebung, einschließlich sämtlicher in dieser Leistungsbeschreibung (inkl. Anlagen) beschriebenen Funktionalitäten, Datenanbindungen, Schnittstellen sowie deren Integration in bestehende Prozesse und IT-Landschaften der KfW  die Anbindung an das zentrale Berechtigungsmanagement der Mandanten (KfW und IPEX),  der Nachweis der Funktionsfähigkeit, Integration, fachlichen Eignung und Sicherheit der Software durch die erfolgreichen Tests gemäß Phase 4 in der Testumgebung,  die Durchführung der vereinbarten Schulungen inklusive der Bereitstellung der Schulungsunterlagen,  die Übergabe der herstellerspezifischen Dokumentation sowie  die Zulieferung der nötigen Informationen für die Erstellung der KfW-spezifischen Dokumentation.

Der Auftragnehmer hat das Einführungsprojekt eigenverantwortlich und in enger Zusammenarbeit mit der KfW zu planen, zu steuern und durchzuführen. Die Verantwortung für die termin- und qualitätsgerechte Herbeiführung des geschuldeten Erfolgs liegt beim Auftragnehmer. Die Mitwirkung der KfW ist in Kapitel 5.3 beschrieben. Die Anforderungen an das einzusetzende Projektteam ergeben sich aus Kapitel 5.5 dieser Leistungsbeschreibung. Das Einführungsprojekt ist vom Auftragnehmer unmittelbar nach Zuschlagserteilung (voraussichtlich 04/2027) zur Abnahmereife zu führen. Der Zeitraum vom Kick-off bis zur Abnahme darf zwölf Monate nicht überschreiten. Eine Migration von Daten aus Bestandssystemen ist keine geforderte Leistung.

5.2 Projektvorgehen und Steuerung Das Einführungsprojekt gliedert sich in die folgenden Phasen, wobei eine zeitliche Überlappung zulässig ist, soweit die Erreichung der Meilensteine hierdurch nicht gefährdet, wird:  Phase 1: Projektinitialisierung  Phase 2: Feinkonzeption  Phase 3: Umsetzung, Konfiguration und technische Anbindung  Phase 4: System-, Integrations-, Fach- und Sicherheitstests in der Testumgebung  Phase 5: Bereitstellung der Produktivumgebung und GoLive  Phase 6: Schulungen  Phase 7: Stabilisierungsphase  Phase 8: Abnahme Die initiale Erstellung der Dokumentation gemäß Kapitel 4.5 ist keine eigenständigen Projektphase, sondern sämtlichen Phasen begleitende Daueraufgaben des Auftragnehmers.

20

[Seite 21]

Leistungsbeschreibung RKA-Tool

Für die Nutzung der DEV- und Testumgebung sowie für die dort eingerichteten Benutzer und durchgeführten Transaktionen dürfen keine nutzer- oder transaktionsbezogenen Entgelte anfallen. Der Auftragnehmer hat spätestens zum Kick-off einen Projektplan vorzulegen, der die Arbeitspakete, Verantwortlichkeiten, Meilensteine sowie die von der KfW zu erbringende Mitwirkung mit konkreten Terminen ausweist. Der Projektplan bedarf der Freigabe durch die KfW, Änderungen sind anzuzeigen und zu begründen. Während der Projektlaufzeit findet ein regelmäßiger, wöchentlicher Statustermin statt, dessen Ergebnisse der Auftragnehmer in einem Protokoll festhält. Erkennbare Gefährdungen des Zeitplans oder der Leistungsqualität hat der Auftragnehmer der KfW unverzüglich und unaufgefordert mitzuteilen und geeignete Gegenmaßnahmen vorzuschlagen.

5.2.1 Phase 1: Projektinitialisierung Der Auftragnehmer hat innerhalb von 4 Wochen nach Zuschlagserteilung einen Kick-off- Termin durchzuführen, der nach Wahl der KfW in Präsenz am Standort Frankfurt am Main der KfW oder im Rahmen einer von der KfW initiierten Videokonferenz (derzeit WebEx) stattfindet. Der Auftragnehmer bereitet den Termin inhaltlich vor, moderiert ihn und dokumentiert die Ergebnisse in einem mit der KfW abzustimmenden Protokoll. Gegenstand des Kick-off-Termins sind insbesondere  Vorstellung des Projektteams und der Ansprechpartner beider Seiten  Abstimmung des Projektplans einschließlich der Meilensteine und Mitwirkung  Festlegung der Kommunikations- und Eskalationswege,  Abstimmung der technischen Rahmenbedingungen sowie  Abstimmung des Schulungskonzepts und der Anforderungen an die Dokumentation gemäß Kapitel 4.5.

5.2.2 Phase 2: Feinkonzeption Im Rahmen des Einführungsprojekts erstellt der Auftragnehmer auf Grundlage der Leistungsbeschreibung und der Anforderungen des Auftraggebers ein Feinkonzept als verbindliche Grundlage für die Konfiguration, Integration, Erprobung und Inbetriebnahme der Software.

Das Feinkonzept konkretisiert insbesondere:

 die fachlichen Prozesse zur Erfassung, Prüfung, Genehmigung und Abrechnung von Reisekosten,  Rollen, Berechtigungen und Genehmigungsworkflows,  die erforderliche Systemkonfiguration und Abbildung der fachlichen Anforderungen,  Schnittstellen zu vor- und nachgelagerten Systemen,  relevante Auswertungen und Reports,  das Vorgehen für Schnittstellentests in der DEV-Umgebung, Systemtests, Systemintegrationstests, User Acceptance Tests, Penetrationstests, Produktionsfreigabe und Abnahme  offene Punkte und erforderliche Entscheidungen

21

[Seite 22]

Leistungsbeschreibung RKA-Tool

Die Erstellung erfolgt in enger Abstimmung mit dem Auftraggeber. Hierzu führt der Auftragnehmer erforderliche Workshops und Abstimmungstermine durch und dokumentiert die Ergebnisse.

Das abgestimmte und vom Auftraggeber freigegebene Feinkonzept bildet die Grundlage für die anschließende Umsetzung. Offene Punkte, die die Umsetzung, den Zeitplan oder die Erreichung der vorgesehenen Test- und Freigabekriterien beeinträchtigen können, sind vor Freigabe des Feinkonzepts zu entscheiden oder mit Verantwortlichkeit und verbindlichem Entscheidungstermin im Feinkonzept festzuhalten.

5.2.3 Phase 3: Umsetzung, Konfiguration und technische Anbindung Der Auftragnehmer hat die Software entsprechend dem von der KfW freigegebenen Feinkonzept sowie den im Projektverlauf abgestimmten Vorgaben in der DEV-Umgebung umzusetzen, zu konfigurieren und technisch anzubinden. Dies umfasst insbesondere:  die Einrichtung der Mandanten,  die Bereitstellung Konfigurationen für KfW und IPEX,  die Umsetzung des Rollen- und Berechtigungskonzepts,  die Konfiguration der vereinbarten Sicherheits- und Datenschutzeinstellungen,  die Einrichtung und Konfiguration der fachlichen Prozesse, Workflows, Vorlagen, Formularfelder, Prüflogiken, Reports und Auswertungen,  die Umsetzung vereinbarter KfW-spezifischer Anpassungen durch Konfigurationen  die technische Einrichtung und Konfiguration der Schnittstellen zu vor- und nachgelagerten Systemen sowie zu externen Providern,  die Einrichtung der Anbindung an das zentrale Berechtigungsmanagement der Mandanten KfW und IPEX sowie  die Erstellung und Fortschreibung der für die Umsetzung erforderlichen technischen und fachlichen Dokumentation. Der Auftragnehmer hat die technische Anbindung der Schnittstellen in Abstimmung mit den durch die KfW benannten Ansprechpartnern in der DEV-Umgebung umzusetzen. Nach Einrichtung der jeweiligen Schnittstellen führt die KfW in der DEV-Umgebung Schnittstellentests durch. Der Auftragnehmer unterstützt die KfW hierbei in erforderlichem Umfang und stellt die hierfür erforderlichen fachlichen und technischen Ansprechpartner zur Verfügung. Festgestellte Mängel und Abweichungen hat der Auftragnehmer unverzüglich zu analysieren und zu beheben. Nach Mängelbehebung stellt der Auftragnehmer die betroffenen Schnittstellen erneut für erforderliche Nachtests in der DEV-Umgebung bereit. Nach erfolgreichem Abschluss der erforderlichen Systemtest in der DEV-Umgebung stellt der Auftragnehmer die Software einschließlich der Schnittstellen in der Testumgebung zur Durchführung der Tests gemäß Phase 4 bereit.

22

[Seite 23]

Leistungsbeschreibung RKA-Tool

5.2.4 Phase 4: System-, Integrations-, Fach- und Sicherheitstests in der Testumgebung Die KfW führt in der Testumgebung die folgenden Teststufen durch:  Systemtest (ST): Technische Prüfung der vollständigen Software einschließlich der vereinbarten Funktionen, Konfigurationen, Anpassungen, Rollen, Berechtigungen, Workflows, Auswertungen und Reports.  Systemintegrationstest (SIT): Technische Prüfung der vollständigen Software einschließlich aller vereinbarten Schnittstellen zu vor- und nachgelagerten Systemen sowie externen Providern.  User Acceptance Test (UAT): Fachliche Prüfung der Software durch die KfW anhand repräsentativer End-to-End-Prozesse. Der UAT umfasst insbesondere die Prüfung der fachlichen Prozesse zur Erfassung, Prüfung, Genehmigung und Abrechnung von Reisekosten sowie der hierfür eingerichteten Rollen, Berechtigungen, Workflows, Auswertungen und Reports.  Penetrationstest: Sicherheitsprüfung der Software und der vereinbarten Schnittstellen. Die KfW ist berechtigt, den Penetrationstest selbst durchzuführen oder durch einen von ihr beauftragten Dritten durchführen zu lassen. Der Auftragnehmer hat die Durchführung des Penetrationstests in erforderlichem Umfang zu unterstützen und die hierfür notwendigen Informationen, Zugänge und Ansprechpartner rechtzeitig bereitzustellen. Die einzelnen Teststufen können nach Abstimmung mit der KfW zeitlich überlappend durchgeführt werden, soweit hierdurch die ordnungsgemäße Testdurchführung und die Erreichung der vorgesehenen Freigabekriterien nicht gefährdet werden. Der Auftragnehmer hat die KfW bei der Testdurchführung in erforderlichem Umfang zu unterstützen. Er stellt während der Testphase ausreichend qualifizierte fachliche und technische Ansprechpartner einschließlich eines IT-Experten und eines Stellvertreters mit der erforderlichen Entscheidungs- und Handlungskompetenz zur Verfügung. Die KfW dokumentiert die Testdurchführung und die Testergebnisse. Festgestellte Mängel und Abweichungen werden dem Auftragnehmer mitgeteilt. Der Auftragnehmer hat diese unverzüglich zu analysieren, geeignete Maßnahmen zur Behebung vorzuschlagen und die Mängel innerhalb der abgestimmten Fristen zu beheben. Nach Mängelbehebung stellt der Auftragnehmer die betroffenen Funktionen, Konfigurationen oder Schnittstellen für erforderliche Nachtests erneut in der Testumgebung bereit. Der Auftragnehmer und die KfW stimmen sich bei Bedarf über die Priorisierung der festgestellten Mängel und Abweichungen ab. Nach Abschluss aller Tests kann die Produktionsfreigabe durch die KfW erfolgen. Die Voraussetzung dafür besteht in einem User Acceptance Test, dessen Ergebnis keine betriebsverhindernden Mängel beinhalten darf. Zusätzlich dürfen nur betriebsbehindernde Mängel offen sein, für die ein akzeptabler Workaround vorhanden ist (wird bilateral mit dem Auftragnehmer vereinbart) und die in ihrer Gesamtheit nicht als betriebsverhindernder Mangel einzuschätzen sind. Der Penetrationstest gilt als erfolgreich abgeschlossen, wenn keine kritischen oder hohen Sicherheitsmängel offen sind. Sicherheitsmängel geringerer Kritikalität sind zu dokumentieren, risikoorientiert zu bewerten und innerhalb verbindlich vereinbarter Fristen zu beheben. Eine Produktionsfreigabe trotz noch offener Sicherheitsmängel geringerer Kritikalität setzt die Zustimmung der KfW voraus.

23

[Seite 24]

Leistungsbeschreibung RKA-Tool

Die Erteilung der Produktionsfreigabe durch die KfW setzt den erfolgreichen Abschluss des Systemtests, des Systemintegrationstests, des User Acceptance Tests und des Penetrationstests voraus. Die förmliche Abnahme gemäß Phase 7 bleibt hiervon unberührt.

5.2.5 Phase 5: Bereitstellung der Produktivumgebung und GoLive Nach erfolgreichem Abschluss der Tests gemäß Phase 4 und Erteilung der Produktionsfreigabe hat der Auftragnehmer der KfW die Betriebsbereitschaft der Software in der Produktivumgebung in Textform anzuzeigen (Bereitstellungsanzeige). Nach Durchführung der vereinbarten Schulungen und Abschluss der Stabilisierungsphase hat der Auftragnehmer die Abnahmereife zu erklären. Die Bereitstellung umfasst die produktive Freischaltung für den vereinbarten Benutzerkreis einschließlich der aktivierten Anbindung an das zentrale Berechtigungsmanagement der Mandanten KfW und IPEX.

5.2.6 Phase 6: Schulungen Der Auftragnehmer hat nach der Bereitstellung die folgenden Schulungen durchzuführen:  Der Auftragnehmer führt die Schulungen für die fachlichen PowerUser durch, erstellt die Schulungsunterlagen, passt diese an die KfW-spezifische Parametrisierung und die eingerichteten Prozesse an und richtet sie auf den Teilnehmerkreis aus.  Der Auftragnehmer führt Schulungstermine für die Benutzer durch, erstellt die Schulungsunterlagen, passt diese an die KfW-spezifische Parametrisierung und die eingerichteten Prozesse an und richtet sie auf den jeweiligen Teilnehmerkreis aus.

Die Schulungen können nach Abstimmung mit der KfW als Videokonferenz (derzeit WebEx) durchgeführt werden und sind nach vorheriger Absprache mit der KfW in deutscher und englischer Sprache durchzuführen. Ein Schulungskonzept mit Inhalten, Formaten und Terminvorschlägen ist spätestens vier Wochen vor dem geplanten Schulungsbeginn mit der KfW abzustimmen. Der Auftragnehmer hat die Schulungsunterlagen mindestens sieben Kalendertage vor Durchführung der jeweiligen Schulung bereitzustellen. Die Schulungsunterlagen bedürfen der Freigabe durch die KfW, sind digital zu übergeben und dürfen von der KfW zur internen Weiterverarbeitung und -nutzung vervielfältigt und geändert werden.

5.2.7 Phase 7 Stabilisierungsphase Für einen Zeitraum von 4 Wochen ab GoLive stellt der Auftragnehmer einen benannten, mit dem Einführungsprojekt vertrauten Ansprechpartner zur Verfügung, der eingehende Störungsmeldungen und Benutzerfragen entgegennimmt und deren Bearbeitung nachverfolgt. Während der Stabilisierungsphase schuldet der Auftragnehmer:

 die Bereitstellung einer ausreichenden Zahl von Fachleuten für die erforderlichen Überprüfungs- und Überwachungstätigkeiten und die Behebung von Fehlern  die Bereitstellung eines speziellen Ansprechpartners, einschließlich eines Stellvertreters (IT-Consultant), der über die für diese Rolle erforderliche Erfahrung und Entscheidungskompetenz verfügt. Die Stabilisierungsphase ist Teil des Einführungsprojekts und dient der Begleitung des produktiven Einsatzes der Software bis zur Abnahme.

24

[Seite 25]

Leistungsbeschreibung RKA-Tool

5.2.8 Phase 8: Projektabnahme Die KfW führt nach Zugang der Erklärung der Abnahmereife innerhalb von 20 Arbeitstagen eine Abnahmeprüfung durch, in deren Rahmen sie die Erfüllung der vertraglichen Anforderungen feststellt. Der Auftragnehmer unterstützt die Abnahmeprüfung und stellt während des Prüfzeitraums die kurzfristige Verfügbarkeit fachlich geeigneter Ansprechpartner sicher. Festgestellte Mängel werden dem Auftragnehmer unverzüglich mitgeteilt und sind von diesem unverzüglich zu beheben, nach Mängelbehebung wird die Abnahmeprüfung im erforderlichen Umfang wiederholt. Die Abnahme durch die KfW erfolgt gemäß Ziffer 7 der Allgemeinen Vertragsbedingungen, sowie gesetzlicher Regelungen. Unwesentliche Mängel und noch ausstehende Teile der Anwenderdokumentation stehen der Abnahme nicht entgegen. Sie sind in einem Abnahmeprotokoll festzuhalten und unverzüglich, jedenfalls aber innerhalb der dort vereinbarten Fristen zu beheben bzw. nachzuliefern. Mit der Abnahme beginnt der Regelbetrieb, ab diesem Zeitpunkt gelten die Regelungen zum Betrieb, zum Support und zu den Servicelevels gemäß Kapitel 6.

5.3 Mitwirkung der KfW Die KfW wirkt im Rahmen des Einführungsprojekts wie folgt mit:  Bereitstellung der für die Anbindung an das zentrale Berechtigungsmanagement erforderlichen Informationen innerhalb angemessener Frist nach Anforderung durch den Auftragnehmer,  Bei der Definition und Umsetzung des Rollen- und Berechtigungskonzepts  Durchführung der in ihrem Verantwortungsbereich liegenden Freischaltungen, Konfigurationen oder Installationen innerhalb angemessener Frist nach Anforderung durch den Auftragnehmer sowie  die Prüfung der geschuldeten Dokumente innerhalb angemessener Fristen.  Durchführung der Schnittstellentests in der DEV-Umgebung sowie der Systemtests, Systemintegrationstests und User Acceptance Tests in der Testumgebung innerhalb der im Projektplanvorgesehenen Fristen,  Erteilung oder Verweigerung der Produktionsfreigabe nach Abschluss der Tests gemäß Phase 4 innerhalb angemessener Frist,  Koordination und Durchführung des Penetrationstests innerhalb der im Projektplan vorgesehenen Fristen, sofern die KfW den Penetrationstest selbst oder durch einen von ihr beauftragten Dritten durchführen lässt.

Der Auftragnehmer hat seine Leistungserbringung so zu organisieren, dass die Mitwirkung der KfW auf das erforderliche Maß beschränkt bleibt. Kann der Auftragnehmer eine Leistung wegen einer ausstehenden Mitwirkung nicht erbringen, hat er dies der KfW unverzüglich in Textform anzuzeigen, unterbleibt die Anzeige, kann sich der Auftragnehmer auf die fehlende Mitwirkung nicht berufen.

25

[Seite 26]

Leistungsbeschreibung RKA-Tool

5.4 Meilensteine Der Auftragnehmer muss die Software gemäß dem folgenden Meilensteinplan bereitstellen. Spezifische Termine werden im Projektplan festgelegt, der beim Kick-off vereinbart wird.

5.5 Projektteam Sofern im Einzelfall nicht abweichend bestimmt, hat der Auftragnehmer dabei Personal einzusetzen, das mindestens folgende persönliche Kompetenzen aufweist:

26

[Seite 27]

Leistungsbeschreibung RKA-Tool

• fließende Deutschkenntnisse in Wort und Schrift (mindestens Level B2 des europäischen Referenzrahmens), • sehr gute verbale und schriftliche Kommunikationsfähigkeit, verbunden mit der Fähigkeit, komplexe Zusammenhänge verständlich und adressatengerecht darzustellen, • ausgeprägte Kundenorientierung und konzeptionelles Denken, • Fähigkeit zur Anpassung an spezifische Unternehmensbedingungen, • eigenverantwortliche und selbständige Arbeitsweise, • Fähigkeit, tragfähige Kompromisse zu erarbeiten, • ausgeprägte Teamfähigkeit, • professionelles Auftreten.

27

[Seite 28]

Leistungsbeschreibung RKA-Tool

 Umfangreiche Kenntnisse über die Digitalstrategien, Technologie Trends und State of the Art-/Best Practice- Lösungen  Umfangreiche Kenntnisse in der Identifikation von Anwenderproblemen, Durchführung von anwenderbasierten Analysen und Ableitung von Anforderungen für unterschiedliche Anwendergruppen (z. B. Bedarfsträger, Genehmiger, Einkäufer etc.)  Fähigkeit, sich in die Anforderungen unterschiedlicher Zielgruppen und Stakeholder hineinversetzen zu können  langjährige Erfahrung im Umgang der eingesetzten Software und deren Ecosystem  Fundierte Kenntnisse in der Planung, Steuerung und Kontrolle von Projekten, vor allem im Hinblick auf das Zeit-, Kosten-, Personal- und Qualitätsmanagement  Umfangreiche Erfahrung in Projektcontrolling insbesondere für die Überwachungen von Qualität und Aufwände. Gute Kenntnisse in Wirtschaftlichkeitsanalysen.  gute Kenntnisse in projektmanagementbezogener Dokumentation wie z. B. Risikoanalysen.

6 Betrieb und Pflege der Software Die Regelungen dieses Kapitels konkretisieren den Betrieb und die Pflege der SaaS- Leistung gemäß BVB-Cloud sowie BVB ISMS Cloud. Der Auftragnehmer schuldet währen des Betriebs die Unterstützung bei Prüfungen durch interne Revision, Compliance oder externe Prüfinstanzen (z.B. Bereitstellung von Auswertungen, Nachweis von Audit-Trails). Des Weiteren schuldet der Auftragnehmer die

28

[Seite 29]

Leistungsbeschreibung RKA-Tool

Unterstützung bei der Aktualisierung von Dokumentationen (z.B. Verfahrensdokumentation, technische Konzepte, Berechtigungskonzepte).

6.1 Schulungen für Mitarbeiter des Auftragnehmers Der Auftragnehmer erfüllt seine Schulungspflichten gemäß BVB ISMS Cloud. Ergänzend umfassen diese Schulungen insbesondere:

 sicheren Entwicklungspraktiken,  aktuellen Bedrohungsszenarien,  Datenschutz (insb. DSGVO, Schrems-II-Kontext),  Anforderungen der KfW an Informationssicherheit.  Open Web Application Security Project (OWASP) Top 10 6.2 Physische Sicherheit Der Auftragnehmer muss die physische Sicherheit und den Perimeterschutz der zur Leistungserbringung eingesetzten IT-Systeme mindestens durch folgende Maßnahmen sicherstellen:

 angemessene Maßnahmen zum Schutz der Räumlichkeiten, in denen Systeme betrieben werden, die zur Leistungserbringung für die KfW genutzt werden bzw. von denen aus Zugriff auf solche Systeme möglich ist (z.B. Zutrittskontrolle, Videoüberwachung, Sicherheitsdienst),  unverzügliche Erkennung und Behandlung von Perimeter Verletzungen,  Schutz von Betriebsräumen mindestens durch einen Sicherheitsdienst sowie ein Zwei-Faktor-Authentifizierungsverfahren für Zutritte und Protokollierung dieser Zutritte. Die von der KfW genutzten Software-Instanzen müssen als eigener Mandant technisch und organisatorisch von den Software-Instanzen anderer Kunden des Auftragnehmers abgegrenzt sein. Der Auftragnehmer hat die Software unter einer KfW-spezifischen Sub- Domain zur Verfügung zu stellen. Eine Konkretisierung erfolgt, sofern notwendig, im Einführungsprojekt. Für Testzwecke stellt der Auftragnehmer einen KfW-spezifischen Mandanten zur Verfügung, der logisch von Testumgebungen anderer Kunden getrennt ist. Die Leistungserbringung für den Produktivbetrieb hat in der Produktionsumgebung zu erfolgen.

6.2.1 Serverstandorte Der Auftragnehmer ist verpflichtet, sämtliche Vertragsleistungen ausschließlich unter Einsatz von Servern zu erbringen, die ihren Standort im Gebiet der Bundesrepublik Deutschland, in einem Mitgliedsstaat der Europäischen Union oder in einem anderen Vertragsstaat des Abkommens über den Europäischen Wirtschaftsraum haben oder in Staaten, für die ein gültiger Angemessenheitsbeschluss der Europäischen Kommission vorliegt. Jede Verlagerung der Verarbeitung in ein Drittland bedarf der vorherigen schriftlichen Zustimmung der KfW. Die Parteien sind sich darüber einig, dass die mit dem Schrems-II-Urteil des EuGH (C-311/18) verbundenen Vorgaben der EU-Organe, Gerichte und Aufsichtsbehörden zur Drittlandübermittlung personenbezogener Daten umzusetzen sind. Soweit hierfür zusätzliche Maßnahmen erforderlich sind (einschließlich nachträglicher Vertragsänderungen), werden diese von den Parteien einvernehmlich abgestimmt und umgesetzt.

29

[Seite 30]

Leistungsbeschreibung RKA-Tool

6.3 Update & Releasemanagement Der Auftragnehmer gewährleistet, dass die zur Leistungserbringung eingesetzte Software fortlaufend im Rahmen seiner Update- und Release-Planung weiterentwickelt sowie gewartet wird. Das gilt entsprechend für die vom Auftragnehmer geschuldete App für den Einsatz auf mobilen Endgeräten („App“). Der Auftragnehmer stellt der KfW Software und App in der jeweils aktuellen gewarteten Version inkl. Customizing-Einstellungen für die KfW zur Verfügung, so dass der KfW jederzeit, automatisch (in Bezug auf die SaaS-Software) und ohne zusätzliche Lizenzkosten alle Aktualisierungen und Fehlerbehebungen, Sicherheitsupdates und Funktionserweiterungen zur Verfügung stehen. Der Auftragnehmer hat die geschuldete Software so zu pflegen, dass Änderungen an der verwendeten Standardsoftware abwärtskompatibel sind. Bestehende Einstellungen, Datenbestände und Konfiguration (unabhängig davon, ob es sich um allgemein gültige oder KfW-spezifische Daten oder Konfiguration handelt) müssen nach einem Releasewechsel weiterhin gültig sein und ordnungsgemäß funktionieren (Release-Festigkeit). Insbesondere bei Schnittstellenänderungen muss Abwärtskompatibilität sichergestellt sein. Der Auftragnehmer ist nicht berechtigt, Wartungsleistungen auf den von der KfW zur Verfügung gestellten mobilen Endgeräten mit Hilfe von automatisierten Verfahren (z.B. automatisierte Fehlermeldung, Monitoring, Fernzugriff) zu erbringen Der Auftragnehmer ist verpflichtet vor jeder Auslieferung eines neuen Versionsstandes der Software funktionale Tests der neuen Features, Regressionstests sowie nicht funktionale Tests durchzuführen und zu dokumentieren. Voraussetzung für die automatische Aktualisierung der Produktivumgebung ist eine erfolgreiche Abnahme der Testumgebung durch die KfW. Der Auftragnehmer ist verpflichtet die KfW, im Rahmen der Update- und Release Planung regelmäßig, spätestens zwei Wochen vor Implementierung auf dem Testsystem über Inhalt und Zeitpunkt anstehender Releases, zu informieren. Die Information kann auch online (7/24/365) bereitgestellt werden, worüber die KfW dann per E-Mail zu informieren ist. Änderungen mit hohem Risiko oder die maßgeblichen Änderungen an Oberfläche, Handhabung oder Funktion beinhalten, hat der Auftragnehmer gesondert zu kennzeichnen und vorab zu kommunizieren. Die Benachrichtigung muss via E-Mail an die von der KfW benannten Ansprechpartner erfolgen. Dabei hat er eine Vorlaufszeit von 2 Wochen für die Testumgebung zzgl. einer Vorlaufszeit von 6 - 8 Wochen für die Produktivumgebung zu berücksichtigen. Über ungeplante Wartungsarbeiten hat der Auftragnehmer die von der KfW benannten Ansprechpartner rechtzeitig, zu informieren (mindestens 1 Woche vorher). Mit Bereitstellung neuer Versionsstände schuldet der Auftragnehmer die Aktualisierung der vertraglich vereinbarten Dokumentation zur Software. Der Auftragnehmer verpflichtet sich, Aktualisierungen der (clientseitigen) Zugangssoftware bzw. App in Form von Workarounds (Umgehungslösungen), Patches/Updates, Upgrades sowie neuen Releases/Versionen bereitzustellen. Für die Begriffe Umgehungslösung, Patch, Update, Upgrade sowie Release/Version gelten die Begriffsbestimmungen der Besonderen Vertragsbedingungen für Cloud (BVB-Cloud). Die Regelungen dieses Vertrages, insbesondere zu Nutzungsumfang, Zugangs- und/oder Nutzungsvoraussetzungen und Dokumentation, gelten auch für neue Versionsstände der Software.

30

[Seite 31]

Leistungsbeschreibung RKA-Tool

6.4 Allgemeine Bedingungen für Releases Sofern der Auftragnehmer nicht der Hersteller der Software ist, wird der Auftragnehmer die KfW über Ankündigungen des (Dritt-) Herstellers informieren, falls diese Auswirkung auf die bei der KfW eingesetzte Software haben kann (z.B. die Unterstützung für die aktuelle Version wird eingestellt). Sofern der Auftragnehmer nicht der Hersteller der Software ist, trägt er dafür Sorge, dass nur solche Software eingesetzt wird, die sich in Herstellerpflege (Wartung durch den Hersteller) befindet. Um dies sicherstellen, ist der Auftragnehmer dazu verpflichtet, geeignete Wartungsverträge mit Herstellern der zur Leistungserbringung eingesetzten Software abschließen. 6.5 Schwachstellen, Patchmanagement, Härtung Hinsichtlich Schwachstellen, Patchmanagement und Härtung bestehen die folgenden Pflichten des Auftragnehmers bzw. Anforderungen an die Software

6.6 Business Continuity, Datensicherung und Wiederherstellung Der Auftragnehmer stellt sicher, dass die zur Leistungserbringung eingesetzte IT- Infrastruktur über geeignete Backup- und Recovery-Mechanismen für die eingesetzte

31

[Seite 32]

Leistungsbeschreibung RKA-Tool

Software einschließlich Customizing sowie sämtliche für die KfW erfassten und verarbeiteten Daten, Protokolle, Reportings und die Benutzerverwaltung verfügt. Er führt mindestens im Zweiwochenintervall betriebsinterne Backups dieser Inhalte durch. Unbeschadet sonstiger Verpflichtungen erstellt der Auftragnehmer täglich Sicherungskopien aller von ihm für die KfW verarbeiteten und verwalteten Daten und hält diese vor. Diese Sicherungskopien sind der KfW auf deren Anforderung in einem noch zwischen der KfW und dem Auftragnehmer festzulegenden Verfahren in einem für die KfW lesbaren und in ein alternatives IT-System importierbares Format, mindestens jedoch im CSV-Format, zur Verfügung zu stellen. Hinsichtlich der Datensicherung und Wiederherstellung bestehen die folgenden Pflichten des Auftragnehmers bzw. Anforderungen an die Software.

32

[Seite 33]

Leistungsbeschreibung RKA-Tool

Hinweis: Im Rahmen des Einführungsprojektes schuldet der Auftragnehmer die Erstellung eines Datensicherungskonzept sowie die Beschreibung von Wiederherstellungsprozeduren.

6.7 Monitoring und Reporting

6.7.1 Monitoring Für das Monitoring der Software und deren Verfügbarkeit, sowie der zur Leistungserbringung eingesetzten Infrastruktur setzt der Auftragnehmer ein marktübliches Standard-Tool ein, das die Infrastruktur und die Software rund um die Uhr automatisiert überwacht, alle sicherheitsrelevanten Ereignisse lückenlos lokal aufzeichnet und auswertet. Der Auftragnehmer wird auf Anforderung der KfW die Monitoring Daten zur Verfügung stellen. Die vertraglich vereinbarten Meldepflichten des Auftragnehmers bleiben hiervon unberührt. Der Auftragnehmer hat nach Vertragsabschluss, spätestens 4 Wochen vor der geplanten Inbetriebnahme der Software (GoLive) für die KfW ein Format für das in der BVB-Cloud definierte Reporting vorzuschlagen und dieses anschließend mit der KfW abzustimmen. Sollte über das Format kein Einvernehmen erzielt werden können, ist die KfW berechtigt, diesbezüglich Vorgaben zu machen. Die KfW kann auch besondere Auswertungen in Bezug auf die Leistungserbringung beim Auftragnehmer anfordern und hierbei Form und zeitliche Vorgaben der Auswertung spezifizieren. Die schriftliche Darstellung der Auswertungen ist maßgeblich, mündliche Erklärungen des Auftragnehmers, die den Ausführungen des Berichts entgegenstehen, sind nicht verbindlich. Der Auftragnehmer hat die Qualität seiner Leistungen, insbesondere die Einhaltung vereinbarter Service Levels, fortlaufend und kontinuierlich zu messen sowie zu dokumentieren. Er gewährleistet, dass solche Messungen gemäß den jeweiligen Vorgaben der KfW, im Übrigen in marktüblicher Form, zuverlässig, richtig und vollständig erfolgen. Der Auftragnehmer gewährt der KfW Zugang zu den Messdaten und Messergebnissen. Der Auftragnehmer verpflichtet sich dazu, sicherheitsrelevante Ereignisse in seinen IT- Systemen lückenlos lokal aufzuzeichnen und auszuwerten. Ferner verpflichtet sich der Auftragnehmer dazu, die Aufzeichnungen und Auswertungen für das Sicherheitsinformationsmanagement zu dokumentieren.

33

[Seite 34]

Leistungsbeschreibung RKA-Tool

6.7.2 Reporting Der Auftragnehmer erstellt die gemäß den Besonderen Vertragsbedingungen für Cloud (BVB-Cloud) vorgesehene monatliche Reportingübersicht in Form eines SLA-Reports und stellt diesen der KfW zur Verfügung, damit die KfW die SLA-Einhaltung beobachten kann. Der SLA-Report muss der KfW zum 15. des Folgemonats in Textform (typischerweise per E- Mail im Format Excel ab Version 2010 oder im Format pdf) der KfW übermittelt werden. Zudem ist anlassbezogen nach Aufforderung der KfW der Bericht aus dem Monitoring-Tool durch den Auftragnehmer zur Verfügung zu stellen. Zusätzlich zu den in Ziffer 8 der Besonderen Vertragsbedingungen für Cloud genannten Inhalten umfasst der SLA-Report mindestens folgende Basis-Informationen, jeweils bezogen auf den jeweiligen Reportingzeitraum:  Performance der Software je Quartal. Neben dem bereitzustellenden SLA-Report liefert der Auftragnehmer zusätzlich einen Security Report. Inhalt und Nachweispflichten richten sich im Hinblick auf Zertifizierungen, Prüfberichte und regelmäßige Sicherheitsüberprüfungen nach den Besonderen Vertragsbedingungen für Informationssicherheit bezüglich Cloud Services (BVB ISMS Cloud). Ergänzend umfasst der Security Report insbesondere:  Liste autorisierter Software,  Einsatz Vulnerability Tools,  Einsatz Tool zur Überwachung privilegierter Berechtigungen. Der erste Security Report ist zwei Wochen nach dem Kick-Off-Workshop einzureichen. Anschließend ist dieser mindestens halbjährlich bereitzustellen. Der Auftragnehmer lässt mindestens jährlich Penetrationstests durch qualifiziertes internes Personal oder externe Dienstleister durchführen. Die Penetrationstests erfolgen nach einer dokumentierten Testmethodik und umfassen die für die Bereitstellung der Software relevanten Systemkomponenten im Verantwortungsbereich des Auftragnehmers, die im Rahmen einer Risiko-Analyse (Ergebnisbericht vom Pentest) als solche identifiziert wurden. Der Auftragnehmer stellt der KfW spätestens 14 Kalendertage nach Bereitstellung der Testumgebung einen aktuellen Bericht über die Ergebnisse eines Penetrationstest bereit, der zu diesem Zeitpunkt nicht älter als 12 Monate ist. Während der Vertragslaufzeit werden der KfW die jeweils aktuellen Berichte der jährlichen Penetrationstests im Rahmen des Reportings gemäß Ziffer 8 der Besonderen Vertragsbedingungen für Cloud bereitgestellt. Die KfW hat an den Reports Rechte gemäß Ziffer 10.1 der BVB-Cloud, wobei die Nutzungsrechte zeitlich nicht beschränkt sind. Für den Fall, dass der Auftragnehmer seinen Reportingpflichten auch nach Ablauf einer angemessenen, von der KfW gesetzten Frist nicht nachkommt, hat die KfW Anspruch auf eine Gutschrift in Höhe von 5.000 Euro.

6.8 Service Desk und Servicezeit Der Auftragnehmer betreibt ein strukturiertes Support-Modell mit klar definiertem 2nd- und 3rd-Level-Support. Ein End-User-Support kann ebenfalls angeboten werden. Der Service Desk, muss mindestens deutsch- und englischsprachig (optional zusätzliche Sprachen) erreichbar sein. Der Service Desk:

 nimmt Störungsmeldungen und Anfragen der KfW per E-Mail und Telefon entgegen,

34

[Seite 35]

Leistungsbeschreibung RKA-Tool

 erfasst jede Meldung in einem Ticketsystem,  initiiert die Bearbeitung und informiert die KfW über den Bearbeitungsstand. Kann ein Vorgang nicht durchgängig von einer Person bearbeitet werden, hat der Auftragnehmer zu gewährleisten, dass der Bearbeitungsfortschritt im Ticketsystem so dokumentiert ist, dass ein Wechsel ohne wesentliche Verzögerung möglich ist. Die Servicezeit umfasst Arbeitstage von Montag bis Freitag 08:00–17:00 Uhr. Innerhalb dieses Zeitraums hat der Auftragnehmer eine durchgehende Erreichbarkeit des Service Desk zu gewährleisten. Die Personal- und Systemausstattung des Service Desk hat der Auftragnehmer am erwarteten Volumen an Störungsmeldungen und Anfragen zu orientieren.

6.9 Störungsbearbeitung

6.9.1 Störungsmeldung durch die KfW und Bearbeitung durch den Auftragnehmer Der Auftragnehmer hat zu gewährleisten, dass eine Störungsmeldung der KfW über seinen Service Desk oder ein webbasiertes Portal erfolgen kann. Die Störungsmeldung der KfW enthält in der Regel die nachfolgenden Informationen:

 Störungsmelder inklusive Kontakt für Rückfragen (Telefon / E-Mail)  Fehlerbeschreibung  KfW-Incident-Nummer der Störung bei der Rückmeldung (falls bereits vorhanden) Der Auftragnehmer hat die Bearbeitung der Störung systematisch in einem Ticketsystem zu erfassen und eingeleitete Maßnahmen zu dokumentieren. Der Auftragnehmer bestätigt der KfW unverzüglich, spätestens innerhalb von 4 Stunden nach Zugang der Störungsmeldung deren Eingang durch Mitteilung einer eindeutigen Ticketnummer.

6.9.2 Meldung einer Störung durch den Auftragnehmer und Bearbeitung Über nicht von der KfW gemeldete Störungen der Software, die die Verfügbarkeit der Software für die KfW einschränken, informiert der Auftragnehmer die KfW unverzüglich ab Bekanntwerden der Störung in Textform (E-Mail). Die Störungsmeldung des Auftragnehmers an die KfW enthält hat mindestens nachfolgende Informationen zu enthalten:

 die aussagekräftige Beschreibung der Störung,  die eingeleiteten Maßnahmen und  die voraussichtliche Ausfallzeit. Die KfW wird die relevanten Kontaktinformationen für derartige Störungsmeldungen unmittelbar nach Vertragsschluss bekannt geben.

6.9.3 Klassifizierung von Störungen Es werden die folgenden Störungsklassen unterschieden:

 Eine betriebsverhindernde Störung liegt vor, wenn die Nutzung der Software unmöglich oder die Nutzbarkeit schwerwiegend eingeschränkt ist. Dies gilt auch, wenn die betriebsbehindernden Störungen insgesamt zu einer betriebsverhindernden Störung in der Nutzbarkeit der Software führen.

35

[Seite 36]

Leistungsbeschreibung RKA-Tool

 Eine betriebsbehindernde Störung liegt vor, wenn die Nutzbarkeit der Software erheblich eingeschränkt ist. Dies gilt auch, wenn die leichten Störungen insgesamt zu einer nicht unerheblichen Einschränkung in der Nutzbarkeit der Software führen.  Eine leichte Störung liegt vor, wenn die Nutzung der Software ohne oder mit unwesentlichen Einschränkungen möglich ist. Gelangt der Auftragnehmer während der Störungsbearbeitung zu der Auffassung, dass die Störung einer zur Meldung von der KfW abweichenden Störungsklasse unterliegt, muss er dies der KfW unter Angabe der Gründe unverzüglich mitteilen. Die KfW wird den Sachverhalt erneut prüfen. Die KfW kann der Änderung der Störungsklasse zustimmen oder diese mit Begründung ablehnen.

6.9.4 Störungsbeseitigung Der Auftragnehmer hat Störungen der Software unter Einhaltung der vereinbarten Reaktions- und Wiederherstellungszeit gemäß Kapitel 6.10.2 zu beseitigen. Für die Begriffe Reaktionszeit und Wiederherstellungszeit gelten die Begriffsbestimmungen der Besonderen Vertragsbedingungen für Cloud (BVB-Cloud). Unabhängig von der Wiederherstellungszeit verpflichtet sich der Auftragnehmer die Störungen unverzüglich zu beseitigen. Sollte eine Störung innerhalb der Wiederherstellungszeit aus nachvollziehbaren Gründen nicht behoben werden können, kann zwischen dem Auftragnehmer und dem Auftraggeber eine davon abweichende Wiederherstellungszeit einvernehmlich vereinbart werden

6.10 Service-Level-Agreements Der Betrieb der Software wird nach den definierten Service Level Agreements gewährleistet. Hierzu gehören insbesondere:

 eine Einstufung der Störungen nach Schweregrad  definierte Reaktions- und Wiederherstellungszeiten je Schweregrad,  regelmäßige Berichterstattung über eingetretene Störungen, Ursachen und ergriffene Maßnahmen.

6.10.1 SLA1: Verfügbarkeit Der Auftragnehmer gewährleistet die Verfügbarkeit der Software auf seiner Infrastruktur bis zum Übergabepunkt in das Internet mit den vereinbarten Funktionen im Zeitraum von Montag bis Freitag von 00:00 – 24:00 Uhr, je Standort. Der Zielwert für die Verfügbarkeit beträgt >= 90 % innerhalb des Reportingzeitraum. Die Definition und Berechnung der Verfügbarkeit sowie die Behandlung geplanter Wartungsfenster richten sich ergänzend nach Ziffer 7 der Besonderen Vertragsbedingungen für Cloud (BVB-Cloud). Geplante Wartungsfenster müssen mit einem Vorlauf von mindestens fünf Arbeitstagen vom Auftragnehmer beim Auftraggeber angekündigt werden. Sie dürfen nur an Samstagen, Sonntagen, bundeseinheitlichen Feiertagen und ansonsten Montag – Freitag im Zeitraum von 20.00 Uhr bis 06.00 Uhr liegen. Sofern ungeplante Wartungsarbeiten zur Aufrechterhaltung des Betriebes dringend erforderlich werden, sind diese der KfW unverzüglich vorher per E-Mail anzukündigen. Ungeplante oder gemeldete, jedoch nicht dringend erforderliche Wartungsarbeiten innerhalb der oben genannten Verfügbarkeitszeiten werden als Nichtverfügbarkeit gewertet.

36

[Seite 37]

Leistungsbeschreibung RKA-Tool

6.10.2 SLA2: Reaktionszeit und Wiederherstellungszeit Der Auftragnehmer verpflichtet sich, Störungen nach klar definierten Prozessen und abhängig von der Störungsklassifizierung sind die folgenden Anforderungen an Wiederherstellungszeit und Reaktionszeit definiert und durch den Auftragnehmer einzuhalten:

6.10.3 SLA3: Performance Der Auftragnehmer gewährleistet, dass die Software bei 98% aller Serverinteraktionen eine maximale Antwortzeit von 2,0 Sekunden nicht überschreitet. Die Antwortzeit beschreibt dabei die Zeitspanne zwischen dem Auslösen einer Interaktion (z.B. ein Mausklick oder Tastaturbefehl) und der Antwort des Systems darauf (aus Sicht des Benutzers). Dieselben Anforderungen an die Antwortzeit gilt auch für die Interaktion zwischen den mobilen Endgeräten, auf welchen die App installiert ist, und der Software. In jedem Fall eines Performanceproblems besteht für den Auftragnehmer die Pflicht zur unmittelbaren und umfassenden Ursachenanalyse und zur Wiederherstellung der geschuldeten Performance. Der Anbieter muss hierzu geeignete Tools sowie Experten für die Analyse bereithalten und zur Verfügung stellen.

6.10.4 Folgen von Service Level Verstößen Bei Nichteinhaltung des für den SL1: Verfügbarkeit definierten Zielwerts wird pro angefangenen Prozentpunkt der Unterschreitung die für den Reportingzeitraum vereinbarte Pauschalvergütung um pauschal 1% gemindert. Ab einer Verfügbarkeit von 75% und weniger beträgt die pauschalisierte Minderung 100%. Für die Nichteinhaltung der für den SL2: Reaktions- oder Wiederherstellungszeit vereinbarten Zielwerte zahlt der Auftragnehmer

 im Fall der betriebsverhindernden Störung bei nicht erfolgter Wiederherstellung innerhalb des nächsten Tages je angefangenem zusätzlichen Tag eine Vertragsstrafe in Höhe von 1.000 EUR  im Fall der betriebsbehindernden Störung bei Überschreitung des Zielwerts je angefangenem Tag eine Vertragsstrafe in Höhe von 500 EUR

Für die Nichteinhaltung der für den SL3: Perfomance vereinbarten Zielwerte zahlt der Auftragnehmer:

 Bei Messfenster-Breaches (z. B. p95/p99 über dem Ziel) gibt es Gutschriften auf die jeweilige Gebühr in Höhe von 10%.

37

[Seite 38]

Leistungsbeschreibung RKA-Tool

7 Beratung für die Bereitstellung, Konfiguration und Anpassung Der Auftragnehmer hat auf gesonderte Anfrage und Beauftragung durch die KfW Beratungs- und Anpassungsleistungen für die Software zu erbringen (On-Demand- Leistungsgegenstand). Dazu können insbesondere folgende Leistungen gehören:

 Konzeption und Umsetzung von KfW-spezifischen Anpassungen der Software durch Konfigurations- und/oder Anpassungsprogrammierung  Beratung zur Prozessoptimierung im Zusammenhang mit der Produktbereitstellung  Konfigurationsberatung

Der Auftragnehmer muss für seine Leistungserbringung Personen mit den für die rechtzeitige, effiziente und kompetente Ausführung der Aufgabe erforderlichen Qualifikationen und Fähigkeiten einsetzen. Die im Kapitel 5.5 aufgeführten Rollen werden von der KfW zum Zweck der Vergütung definiert und entsprechen nicht unbedingt den Rollenbezeichnungen des Auftragnehmers. Der Auftragnehmer darf nur Personen zur Leistungserbringung einsetzen, die mindestens die im Kapitel 5.5 für jede Rolle aufgeführten Qualifikationen besitzen. Der Auftragnehmer muss angemessene Vorkehrungen treffen, um eine ordnungsgemäße Leistungserbringung bei kurzfristigen Änderungen und bei einer Erhöhung des für die Leistungserbringung erforderlichen Personaleinsatzes zu gewährleisten.

8 Governance Meetings Der Auftragnehmer führt halbjährlich ein Steuerungsmeeting mit der KfW durch, um alle aktuellen Themen zu besprechen und über aktuelle Entwicklungen zu informieren. Dabei werden neben allgemeinen Themen der Leistungserbringung insbesondere auch die aktuellen Berichte thematisiert. Weiterhin wird der Auftragnehmer in diesen Gesprächen über Produktentwicklungen und Roadmaps der eingesetzten und neuer Produkte informieren. Das Steuerungsmeeting findet frühestens 5 Werktage nach Zugang der Berichte statt und spätestens einen Monat nach Zugang. Das Steuerungsmeeting wird vom Auftragnehmer organisiert und schriftlich protokolliert (s. Protokollvorlage im Anhang). Das Protokoll soll spätestens 1 Woche nach der Besprechung abgestimmt sein. Die Besprechungen finden auf Verlangen der KfW bis zu 1 x jährlich in Präsenz in den Räumen der KfW statt, ansonsten remote. Neben diesen regelmäßigen Steuerungsmeetings können bei Bedarf anlassbezogene Governance-Termine durchgeführt werden. Anlass, Inhalte und vorzulegende Unterlagen richten sich nach den vertraglichen Vereinbarungen sowie Anlage A.1.

Protokoll DL JFX.docx

38

[Seite 39]

DL JFX am DD.MM.YYYY Frankfurt am Main Protokollant:

Agenda (mit * versehene Punkte sind zwingend zu dokumentieren – sofern keine neuen Informationen vorliegen, ist eine Leermeldung ebenfalls schriftlich festzuhalten)

1. SLAs/Leistungsstörungen*
2. Risikorelevante Ereignisse (Datenschutz, IS, OpRisk)*
3. Subdienstleister (* für kwF Verträge und Auslagerungen)
4. Prüfungen/Audits beim Dienstleister*
5. Kontrollhandlungen durch die KfW/Vor Ort Kontrollen*
6. Notfallplanung (* für kwF Verträge und kritische DL gemäß BIA)
7. Berechtigungsmanagement
8. Änderungen von Anforderungen der KfW an den DL
9. Wartungen/Patches
10. Personelle Themen
11. Allgemeines und fachliche Fragen

VERTRAULICH

Seite 1 von 7

[Seite 40]

Protokoll

1 I = Information, A = Auftrag, E = Entscheidung, P = Problem Seite 2 von 7

[Seite 41]

Protokoll

 Gab es im Betrachtungszeitraum Sicherheits- und/oder I MM Datenschutzvorfälle beim Dienstleister? Wenn ja, welche Maßnahmen wurden ergriffen; welche Learnings abgeleitet? Sofern in den letzten 12 Monaten keine Schadensvorfälle vorlagen, ist dies ebenfalls als P Alle Negativmeldung nachvollziehbar zu dokumentieren („Der Dienstleister bestätigt, dass…“)

 Liegen Berichte über Vorfälle und/oder zur IKT- Sicherheit vor? Stehen die gemeldeten Vorfälle in Zusammenhang mit finanziellen Schäden für die KfW? A 31.03.2022 XY  Liegen neue Audits, Berichte, Zertifizierungen, Jahresabschlüsse vor?

 Liegen Berichte über Maßnahmen und Tests zur operationalen Resilienz (bspw. Penetrationsstest oder TLPT Tests) vor? Ergeben sich daraus Maßnahmen oder Handlungsbedarfe für die KfW?

 Sind Schwachstellen in der Applikation bekannt (z.B. log4j)?

 Sofern relevant: Nachhalten der Abarbeitung der Feststellungen/Besprechung Meilensteine

1 I = Information, A = Auftrag, E = Entscheidung, P = Problem Seite 3 von 7

[Seite 42]

Protokoll

1 I = Information, A = Auftrag, E = Entscheidung, P = Problem Seite 4 von 7

[Seite 43]

Protokoll

 Sind im Betrachtungszeitraum beim Dienstleister Prüfungen durch Dritte (Jahresabschlussprüfer, Aufsichtsbehörden) oder durch die Interne Revision des DL erfolgt? Sofern der Dienstleister keine Berichte vorliegen hat oder die Berichte nicht zur Verfügung stellt, ist dies hier ebenfalls als Negativmeldung zu dokumentieren. („… der Dienstleister bestätigt, dass keine aktuellen Berichte und Feststellungen vorliegen, die die KfW betreffen könnten…“)

 Welche Ergebnisse/Feststellungen haben sich daraus ergeben?

 Ergaben sich daraus risikorelevante Erkenntnisse, die Auswirkungen auf vertragliche Vereinbarungen und die Leistungserbringung zwischen dem DL und der KfW haben?

 Sofern Feststellungen oder Schwachstellen bekannt geworden sind: Welche Maßnahmen werden umgesetzt, um die Feststellungen bzw. Schwachstellen abzustellen? Bis wann werden die Maßnahmen umgesetzt?

 Gab es im Berichtszeitraum Änderungen/Anpassungen an der Notfallplanung beim DL?

 Wurden Notfalltests durchgeführt?

 Ergebnis der Notfalltests und ggf. geplante Maßnahmen zur Behebung von erkannten Problemen im Rahmen der Tests

1 I = Information, A = Auftrag, E = Entscheidung, P = Problem Seite 5 von 7

[Seite 44]

Protokoll

1 I = Information, A = Auftrag, E = Entscheidung, P = Problem Seite 6 von 7

[Seite 45]

Protokoll

 Meilensteine von Projekten/Changes

 Kosten und Budgets

 Weitere fachliche Themen

1 I = Information, A = Auftrag, E = Entscheidung, P = Problem Seite 7 von 7