EVB-IT: Rahmenvertrag nebst Anhängen

Die folgende Tabelle verdichtet die amtliche Entscheidungshilfe 2026, die aktuellen amtlichen Downloadseiten und die einschlägigen AGB/Muster für die hier relevanten Vertragstypen. Hardwarebezogene Typen wie Kauf oder Instandhaltung bleiben bewusst außen vor.

EVB-IT Cloud ist für den Regelfall eines SaaS-CAFM die naheliegende Erstwahl. Der amtliche Cloudvertrag ordnet ausdrücklich SaaS, PaaS, IaaS, Managed Cloud Services sowie einmalige Initialleistungen, sonstige Leistungen und Leistungen bei Vertragsende ein und lässt unterschiedliche Preismodelle bis hin zu nutzungsabhängiger Vergütung zu. Hinzu kommt ein enges Regelungsgerüst zu Leistungsort, AVV/TOM, Verfügbarkeit, Reporting, Prüfrechten, Unterauftragnehmern und Migration. Besonders praxisrelevant ist, dass der Vertrag anbieterseitige AGB nur nachrangig und nur insoweit zulässt, als sie nicht mit den übrigen Vertragsregeln kollidieren oder diese beschränken. Das ist für SaaS-Beschaffungen ein erheblicher Vorteil gegenüber rein anbieterformulierten Cloud Terms.

EVB-IT Dienstleistung ist nicht der richtige Hauptvertrag für den Betrieb des CAFM-Systems, wohl aber regelmäßig der präziseste Ergänzungsvertrag für Schulungen und begleitende Unterstützungsleistungen. Seine amtliche Logik ist eindeutig: Gegenstand sind Dienstleistungen; werkvertragliche Leistungen sind nicht Vertragsgegenstand. Dafür regelt er Service- und Reaktionszeiten, Schlüsselpersonal, Unterauftragnehmerzustimmung, Vertragsstrafen bei Termin- oder Reaktionszeitüberschreitungen sowie eine klare Exit-Pflicht zur Herausgabe oder Löschung von Arbeitsergebnissen. Für Schulungspakete, Key-User-Befähigung, Multiplikatorenschulungen, Administrationscoaching oder variable Migrationsunterstützung ist das regelmäßig besser als eine Überdehnung des Cloudvertrags. Kritisch ist nur, dass die ordnungsgemäße Datensicherung grundsätzlich dem Auftraggeber obliegt, solange Datensicherung nicht ausdrücklich Teil der Dienstleistung ist.

EVB-IT Service und EVB-IT Pflege S sind Ausnahmeinstrumente für die hier betrachtete Zielarchitektur. Der Servicevertrag ist stark, wenn ein umfassender systembezogener Service geschuldet wird — mit Hotline, Ticketsystem, neu zu installierenden Programmständen, Dokumentationsfortschreibung, Nachfolgerunterstützung und teilweise sogar Quellcode-/Hinterlegungslogik. Genau diese Tiefe macht ihn für reine SaaS-CAFM-Beschaffungen häufig zu schwer. Pflege S ist demgegenüber auf Standardsoftware-Pflege zugeschnitten; die amtlichen Nutzerhinweise und AGB betonen, dass dort bereits Dienst- und Werkleistungen in einem Vertrag verbunden werden. Für reinen Cloudbezug ohne gesonderte Standardsoftwareüberlassung ist das regelmäßig keine gute Passung. EVB-IT System oder EVB-IT Erstellung sollten erst dann in Betracht kommen, wenn Individualsoftware bzw. werkvertragliche Anpassungen den Schwerpunkt bilden; die amtliche Entscheidungshilfe nennt als Faustwert, dass der Individualisierungsanteil etwa mehr als 15–20 % des Auftragswertes ausmacht.

Die sachgerechte Grundentscheidung lautet in den meisten Fällen: EVB-IT Rahmenvereinbarung als Dach + EVB-IT Cloud als Primärmodul + EVB-IT Dienstleistung als Ergänzungsmodul. Der Grund ist nicht nur juristisch, sondern betriebswirtschaftlich: Der Cloudteil erfasst die dauerhaft geschuldete Bereitstellung, Sicherheit, Performance, Datenspeicherung und Exit-Migration; der Dienstleistungsteil erfasst die personengebundenen, im Umfang schwankenden Schulungs- und Unterstützungsleistungen. Damit werden unterschiedliche Leistungslogiken und Preislogiken nicht vermischt. Die Rahmenvereinbarung bringt diese Bausteine unter eine einheitliche Beschaffungsarchitektur, wenn über die Laufzeit mehrere Abrufe, Nutzererweiterungen, Schulungspakete oder Zusatzservices zu erwarten sind.

Zwei Abgrenzungen sind besonders wichtig. Erstens: Betreuung ist nicht automatisch Servicevertrag. Die Cloud-AGB definieren Managed Cloud Services ausdrücklich als Leistungen wie Benutzerverwaltung, Verwaltung verschiedener Cloud-Angebote/Optionen, Kapazitätsmanagement oder Beratung bei Upgrade- und Lizenzfragen. Solche Leistungen können daher im Cloudregime bleiben, sofern sie cloudnah und betreiberseitig sind. Zweitens: Wartung ist nicht automatisch Pflege S. Bei SaaS ist „Wartung“ häufig nichts anderes als die vom Cloudanbieter geschuldete Aktualisierung, Störungsbeseitigung und Betriebsführung; die Pflege-S-Logik passt eher auf separat überlassene Standardsoftware.

Die EVB-IT Rahmenvereinbarung ist für variable Cloud-CAFM-Bedarfe attraktiv, weil sie die Bereiche der EVB-IT-Vertragstypen modular zusammenfasst. Amtlich vorgesehen ist, dass Teil A allgemeine Bestimmungen für alle gewählten Leistungsbereiche enthält, während Teil B die konkret vereinbarten Leistungsbereiche aktiviert. Die einzelnen EVB-IT-AGB werden nicht abstrakt „als Ganzes“ beigezogen, sondern über die Auswahl der Module in die konkrete Rahmenstruktur integriert. Für SaaS-CAFM sollte daher schon in den Vergabeunterlagen transparent der Modulumfang genannt werden: typischerweise Teil B Cloud und Teil B Dienstleistung.

Vergaberechtlich ist vorab zu klären, dass es sich bei einer CAFM-SaaS-Beschaffung regelmäßig nicht um einen Bauauftrag handelt. § 103 GWB trennt Liefer-, Bau- und Dienstleistungsaufträge; § 650a BGB definiert den Bauvertrag über Herstellung, Wiederherstellung, Beseitigung oder Umbau eines Bauwerks oder einer Außenanlage. Eine cloudbasierte CAFM-Software einschließlich Betrieb, Schulung und Support fällt typischerweise nicht darunter. Für den Oberschwellenbereich ist damit die VgV einschlägig; VOB/A ist im Regelfall nicht die richtige Verfahrensordnung. Vertraglich bleibt es allerdings typisch, dass EVB-IT-Muster zusätzlich auf VOL/B verweisen. Praktisch heißt das: verfahrensrechtlich GWB/VgV bzw. UVgO; vertragsrechtlich EVB-IT plus die jeweils einbezogenen zusätzlichen Vertragsbedingungen.

Für die Leistungsbeschreibung ist eine funktionale Ausschreibung besonders geeignet. § 31 VgV erlaubt ausdrücklich Leistungs- oder Funktionsanforderungen. Bei einem CAFM-SaaS sollte die Leistungsbeschreibung deshalb nicht nur Produktnamen oder Bildschirmmasken abfragen, sondern objektive Aufgaben und Ziele beschreiben: Stammdatenverwaltung, Flächenmanagement, Tickets/Helpdesk, Betreiberpflichten, Instandhaltungsprozesse, mobile Workflows, Rollen- und Berechtigungskonzept, Schnittstellen zu ERP/HR/IoT, Mandantenfähigkeit, Datenmigration, Berichtswesen, Protokollierung, Backup, Exit und Performance. Für Sicherheits- und Qualitätsanforderungen wie C5 oder ISO-Nachweise ist § 34 VgV zu beachten: Gütezeichen und vergleichbare Nachweise müssen auftragsbezogen sein und dürfen nicht ohne Öffnungsklausel für gleichwertige Belege gefordert werden.

Für die Zuschlagswertung ist das beste Preis-Leistungs-Verhältnis maßgeblich. Preis oder Kosten müssen also in die Wertung einfließen, aber sie müssen nicht das allein prägende Kriterium sein. Gerade bei einem sicherheits- und prozesskritischen CAFM-SaaS ist ein Bewertungsmodell sachgerecht, das Fachfunktionalität, Betriebs-/Servicekonzept, Datenschutz/IT-Sicherheit, Einführung/Schulung, Exit/Portabilität und Preis/TCO gewichtet. Parallel ist das Losgebot im Blick zu behalten: Nach § 97 GWB sind Leistungen grundsätzlich in Teil- oder Fachlose zu zerlegen. Wer Cloud, Schulung und Beratung zusammenfasst, sollte im Vergabevermerk dokumentieren, warum dies aus technischen oder wirtschaftlichen Gründen geboten ist; andernfalls ist ein separates Schulungs-/Beratungslos zu prüfen.

Gerade bei einer Rahmenvereinbarung sind zwei Punkte vergaberechtsfest zu dokumentieren: Bedarfsschätzung und Obergrenze. Nach § 21 VgV ist das in Aussicht genommene Auftragsvolumen so genau wie möglich zu ermitteln und bekannt zu geben; die Laufzeit darf grundsätzlich vier Jahre nicht überschreiten. Darüber hinaus verlangt die unionsrechtliche Rechtsprechung zu Rahmenvereinbarungen, dass Höchstmenge und/oder Höchstwert festgelegt werden; mit Erreichen dieser Grenze verliert die Rahmenvereinbarung ihre Wirkung. Wer diese Grenze nicht sauber definiert, schafft ein erhebliches Nachprüfungsrisiko für Abrufe und Verlängerungen.

Für die Ausschreibungsunterlagen sind folgende Formulierungsansätze tragfähig. Sie ersetzen keine hausinterne Rechtsprüfung, treffen aber die Logik der amtlichen EVB-IT-Struktur. Die zugrunde liegenden Muster ergeben sich aus der offiziellen Rahmenvereinbarungsseite, der Entscheidungshilfe und den vergaberechtlichen Vorgaben zu Rahmenvereinbarungen.

• EVB-IT Cloud für die Bereitstellung und den Betrieb des CAFM-Systems als SaaS einschließlich Datenspeicherung, Datensicherung, Verfügbarkeit, Support, Reporting und Leistungen bei Vertragsende;

• EVB-IT Dienstleistung für Schulungs-, Beratungs- und Unterstützungsleistungen, soweit diese nicht als initiale oder sonstige Leistungen bereits Bestandteil des Cloud-Abrufs sind.

Abrufe erfolgen ausschließlich im Rahmen der in der Auftragsbekanntmachung, den Vergabeunterlagen und der Rahmenvereinbarung ausgewiesenen Höchstmengen und des Höchstwertes. Überschreitungen sind unzulässig. Der Auftraggeber behält sich vor, Abrufe nach Nutzerzahlen, Standorten, Modulen, Schulungspaketen und Servicelevels zu staffeln.

Im Konfliktfall gilt folgende Rangfolge: Leistungsbeschreibung/Lastenheft, ausgefüllter Cloud-Kriterienkatalog, AVV/TOM, Preisblatt, ausgefüllte EVB-IT-Muster, einschlägige EVB-IT-AGB des gewählten Leistungsbereichs, nachrangig ausdrücklich einbezogene anbieterseitige AGB, soweit sie den vorstehenden Regelungen nicht widersprechen und diese nicht beschränken.

Die amtlichen Cloud-AGB und der Kriterienkatalog enthalten bereits die richtigen Regelungskörbe. Für eine CAFM-SaaS-Ausschreibung genügt es aber nicht, diese Unterlagen lediglich beizulegen. Sie müssen mit konkreten Leistungswerten, Formaten, Rollen und Fristen ausgefüllt werden. Die nachfolgenden Musterbausteine orientieren sich an der Systematik der EVB-IT Cloud sowie an den Sicherheits- und Datenschutzleitlinien des Bundesamt für Sicherheit in der Informationstechnik, der amtlichen C5-Systematik und den Hinweisen der Datenschutzaufsicht.

Die EVB-IT Cloud definiert Verfügbarkeit über Betriebszeit, Ausfallzeit und Verfügbarkeitsklassen, lässt aber zugleich eine weitergehende Konkretisierung über den Kriterienkatalog zu. Für ein CAFM reicht es meist nicht, nur einen Prozentwert zu fordern. Sinnvoll ist vielmehr eine kombinierte SLA-Logik aus Verfügbarkeitsklasse, Kernbetriebszeit, Reaktions- und Wiederherstellungszeiten, Use-Case-bezogenen Antwortzeiten und gleichzeitiger Nutzerzahl. Der Kriterienkatalog erlaubt ausdrücklich auch, Antwortzeitverhalten, Datendurchsatz, Paketverlustraten oder die Anzahl gleichzeitig nutzender Personen in die Nichtverfügbarkeitsdefinition einzubeziehen.

Der Auftragnehmer schuldet für die Produktivumgebung des CAFM-Systems in der Kernbetriebszeit Montag bis Freitag von 06:00 Uhr bis 20:00 Uhr eine Verfügbarkeit von mindestens 99,9 % je Kalendermonat. Zusätzlich gilt die Leistung als nicht verfügbar, wenn im Durchschnitt von fünf Minuten innerhalb der Kernbetriebszeit die Antwortzeit für die Use Cases „Ticket anlegen“, „Flächenobjekt öffnen“ oder „mobilen Arbeitsauftrag synchronisieren“ mehr als 3 Sekunden beträgt oder weniger als 300 gleichzeitige Nutzer die Leistung vollumfänglich nutzen können. Für Störungsklasse 1/2/3 gelten Reaktionszeiten von 30 Minuten / 4 Stunden / 1 Arbeitstag und Wiederherstellungszeiten von 4 Stunden / 1 Arbeitstag / 3 Arbeitstagen. Unterschreitungen lösen Gutschriften nach Preisblatt aus.

Für laufende Supportqualität sollte zusätzlich das monatliche Reporting aus der Cloud-AGB-Systematik konkretisiert werden: dokumentierte Ausfallzeiten, Überschreitungen von Reaktions-/Wiederherstellungszeiten, offene Tickets, sicherheitsrelevante Störungen, Gutschriften und Trendanalysen. Gerade für CAFM ist außerdem ein Dashboard- oder API-Zugang zum Monitoring sinnvoll, weil Betreiber- und Instandhaltungsprozesse häufig auf tagesaktuellen Leistungsdaten aufsetzen.

Die Cloud-AGB sehen als Ausgangspunkt vor, dass Daten des Auftraggebers ausschließlich in der EU, im EWR und — bei Angemessenheitsbeschluss — in der Schweiz verarbeitet werden; für personenbezogene Daten ist vorab eine AVV mit TOM abzuschließen, und die Vorgaben von Art. 28 und 32 DSGVO sind vollständig einzuhalten. Der Kriterienkatalog erlaubt zusätzlich strengere Vorgaben, etwa dass Metadaten nur in EU/EWR verarbeitet werden. Für öffentliche Stellen ist das besonders wichtig, weil die Datenschutzaufsicht cloudbasierte Dienste kritisch danach bewertet, ob der Anbieter tatsächlich weisungsgebunden bleibt und ob Verarbeitungen zu eigenen Zwecken ausgeschlossen sind; außerdem können öffentliche Stellen sich für solche Eigennutzungen typischerweise nicht auf ein „berechtigtes Interesse“ des Anbieters stützen. Nach Schrems II helfen Standardvertragsklauseln allein nicht automatisch; Drittlandübermittlungen verlangen vielmehr eine eigenständige Risikoprüfung und gegebenenfalls zusätzliche Schutzmaßnahmen.

Der Auftragnehmer verarbeitet sämtliche Inhaltsdaten, Protokolldaten, Datensicherungen, Support-Arbeitskopien und Administrationsdaten ausschließlich in Deutschland; soweit diese Standortvorgabe mangels sachlicher Rechtfertigung vergaberechtlich nicht aufrechterhalten werden kann, hilfsweise ausschließlich in der EU/im EWR. Jede Verarbeitung in einem Drittland sowie jeder Fernzugriff aus einem Drittland bedarf der vorherigen schriftlichen Zustimmung des Auftraggebers und eines nachgewiesenen, für den Einzelfall tragfähigen Übermittlungsmechanismus nach Kapitel V DSGVO. Eine Verarbeitung zu eigenen Zwecken des Auftragnehmers oder eines Unterauftragnehmers ist ausgeschlossen. Der Auftragnehmer unterstützt den Auftraggeber bei Betroffenenrechten, Datenschutz-Folgenabschätzungen, Prüfungen durch Aufsichtsbehörden und Sicherheitsvorfällen unverzüglich.

Eine Deutschland-only-Klausel ist fachlich oft gewünscht, vergaberechtlich aber nur dann robust, wenn sie aus Schutzbedarf, Geheimschutz, besonderen sektorspezifischen Anforderungen oder klar dokumentierter Risikolage begründet wird. Wo diese Begründung nicht tragfähig ist, ist EU/EWR-only häufig die belastbarere Alternative. In beiden Varianten sollten Drittland-Fernzugriffe ausdrücklich mitgeregelt werden; sonst bleibt der physische Speicherort in der EU leer, wenn Administration oder Support faktisch global erfolgen. Diese Empfehlung ist eine vergaberechtliche und datenschutzrechtliche Schlussfolgerung aus den EVB-IT-Cloud-Regeln, der DSGVO-Systematik und der Aufsichtspraxis.

Der Cloud-Kriterienkatalog erlaubt eine sehr konkrete Ausgestaltung von Backups, Exporten, Aufbewahrungsfristen und Wiederherstellung. Für ein CAFM sollte der Auftraggeber nicht bei „regelmäßigem Backup“ stehen bleiben, sondern RPO/RTO, Backup-Frequenz, Aufbewahrungsfristen, Speicherorte, Verschlüsselung, Restore-Tests und Exportformate konkret definieren. Die Cloud-AGB verlangen bereits ein Notfall-Management im Rahmen des ISMS; der Auftraggeber sollte daher nicht nur den Notfallplan benennen, sondern auch dessen Test- und Nachweisregime verlangen. Das korrespondiert mit den BSI-Mindeststandards für externe Cloud-Dienste und dem C5-Katalog.

Der Auftragnehmer erstellt tägliche Vollsicherungen und transaktionsorientierte Sicherungen im 15-Minuten-Takt. Der Recovery Point Objective beträgt maximal 15 Minuten, der Recovery Time Objective für Störungsklasse 1 maximal 4 Stunden. Primäre und sekundäre Datensicherungen sind räumlich getrennt innerhalb des vereinbarten Datenraums zu speichern. Der Auftragnehmer weist dem Auftraggeber einmal jährlich die erfolgreiche Durchführung eines vollständigen Restore-Tests nach und übermittelt ein Notfallwiederherstellungsprotokoll. Backups, Logs und Wiederherstellungsdaten sind verschlüsselt zu speichern.

Ergänzend sollte geregelt werden, dass Backups nicht die Exit-Pflichten ersetzen. Ein Backup ist keine Portabilitätsstrategie. Für CAFM-Migrationen müssen daher zusätzlich nutzbare Datenexporte vorgesehen werden, idealerweise in offenen, dokumentierten Formaten.

Die Cloud-AGB sind hier ungewöhnlich stark. Sie verpflichten den Auftragnehmer, Daten verfügbar zu machen, Migrationsunterstützung zu leisten, mit einem Nachfolger zu kooperieren, auf Anforderung die Leistung bis zu sechs Monate über das Vertragsende hinaus fortzusetzen und eine Exportschnittstelle mindestens drei Monate nach Vertragsende vorzuhalten, soweit bis dahin keine Löschung erfolgt ist. Genau dieser Mechanismus sollte bei einem CAFM vollständig aktiviert und konkretisiert werden, weil Portabilität und Vendor-Lock-in in der Praxis oft die teuersten Risiken sind.

Der Auftragnehmer stellt dem Auftraggeber spätestens 90 Kalendertage vor dem geplanten Vertragsende einen vollständigen Testexport der Stamm-, Bewegungs-, Rollen-, Konfigurations- und Dokumentendaten in den Formaten CSV, JSON und SQL-Dump sowie Dokumente in PDF/A oder Originalformat zur Verfügung. Die Exportformate, Datenmodelle und Feldbeschreibungen sind dokumentiert. Auf Verlangen des Auftraggebers unterstützt der Auftragnehmer die Migration zu einem Nachfolger oder in den Eigenbetrieb nach Aufwand auf Basis der vereinbarten Sätze. Verzögert sich die Migration, wird die Leistung auf Anforderung einmalig bis zu sechs Monate zu den bisherigen Konditionen weiter erbracht. Spätestens 30 Tage nach bestätigter Migration und Ablauf der Aufbewahrungsfristen löscht der Auftragnehmer sämtliche Daten sicher und weist dies schriftlich nach.

Bei einem CAFM ist zusätzlich ratsam, ausdrücklich Konfigurationsartefakte einzubeziehen: Formulare, Workflows, Regelwerke, Eskalationen, Pflegeschemata, Objektstrukturen, Assets, Benutzerrollen, Dashboarddefinitionen und Schnittstellenparameter. Wenn diese Artefakte nicht mitgenommen werden, ist die „Datenportabilität“ häufig nur scheinbar erreicht. Diese Empfehlung folgt als praktische Konkretisierung aus der EVB-IT-Migrationslogik.

Ein häufiger SaaS-Fallstrick ist die Annahme, dass alle Anbieterupdates stets unkritisch seien. Die Cloud-AGB lassen Änderungen zur Funktionsverbesserung oder Anpassung an den Stand der Technik zwar zu, verbieten aber Verschlechterungen der ursprünglich vereinbarten Funktionalitäten; unzulässig sind insbesondere Änderungen, die im Vergabeverfahren zu einer schlechteren Bewertung geführt hätten. Der Kriterienkatalog erlaubt zudem, die Pflicht zur Installation von Updates, Upgrades, Releases, Firmwareständen und Rechtsänderungsanpassungen sehr konkret zu regeln. Sicherheitsrelevante Updates können sogar anhand von CVSS-Schweregraden mit Zeitvorgaben belegt werden. Für ein CAFM ist deshalb ein abgestuftes Release-Regime sinnvoll: Security-Patches schnell und verpflichtend, Funktionsreleases mit Vorabinformation, Teststellung und geordnetem Rollback-/Abstimmungsprozess.

Sicherheitsrelevante Patches sind entsprechend dem Schweregrad der adressierten Schwachstelle unverzüglich einzuspielen; kritische Schwachstellen spätestens innerhalb von 3 Stunden, hohe innerhalb von 3 Tagen. Funktionsrelevante Updates, Upgrades und Releases sind dem Auftraggeber mindestens 30 Kalendertage vor Produktivsetzung anzukündigen. Der Auftragnehmer stellt dem Auftraggeber eine Testumgebung oder sonstige Nachvollzugsmöglichkeit zur Verfügung. Änderungen, die die im Vergabeverfahren bewerteten Funktionalitäten, Schnittstellen oder Nutzungsbedingungen verschlechtern, sind unzulässig, sofern der Auftraggeber nicht ausdrücklich zustimmt.

Für Schulungen reicht ein pauschaler Satz wie „Einweisung der Nutzer“ fast nie aus. Empfehlenswert ist, Zielgruppen, Formate, Unterlagen, Wiederholbarkeit und Rechte an den Trainingsmaterialien zu definieren. EVB-IT Dienstleistung ist dafür regelmäßig das bessere Modul; cloudnahe Einführungsleistungen können alternativ als initiale oder sonstige Leistungen im Cloudvertrag verbleiben. Für Support-Level liefern Cloud, Service und Pflege S hilfreiche Muster: deutsche Hotline, qualifiziertes Personal, Ticketsystem, ständige Erreichbarkeit innerhalb der Servicezeit, keine Mehrwertnummern, nachvollziehbarer Bearbeitungsfortschritt.

Der Auftragnehmer erbringt ein Schulungskonzept für die Zielgruppen Administratoren, Key User, Sachbearbeitung und Mobile-Nutzer. Geschuldet sind mindestens: zwei Administratorenschulungen à zwei Tage, vier Key-User-Schulungen à ein Tag, acht Endanwenderschulungen à ein halber Tag sowie ein Train-the-Trainer-Modul. Sämtliche Unterlagen sind in deutscher Sprache in bearbeitbarer elektronischer Form zu überlassen; der Auftraggeber erhält ein zeitlich und räumlich unbeschränktes Nutzungsrecht für interne Schulungszwecke.

Der Auftragnehmer betreibt einen deutschsprachigen 1st-/2nd-Level-Support innerhalb der Servicezeiten Montag bis Freitag von 06:00 Uhr bis 20:00 Uhr. Störungsmeldungen können telefonisch, per E-Mail und über ein webbasiertes Ticketsystem abgegeben werden. Das Ticketsystem muss den Eingang unter Wiedergabe des gemeldeten Inhalts bestätigen und eine jederzeitige Statusverfolgung ermöglichen. Mehrwertdienste-, Mobilfunk- oder Auslandsrufnummern sind ausgeschlossen. Für Störungsklasse 1 ist eine Eskalation an den 3rd Level binnen 30 Minuten vorzusehen.

Gerade bei Cloud-SaaS ist die Unterauftragnehmerkette der neuralgische Punkt. Die Cloud-AGB sehen bereits die Benennung von Unterauftragnehmern und deren Leistungsbereich vor; alternativ kann ausdrücklich ein Zustimmungserfordernis des Auftraggebers vereinbart werden. Außerdem sind Prüfrechte, C5-Berichte vom Typ 2, Auditnachweise, Penetrationstests und Schwachstellenanalysen vorgesehen. Für anspruchsvolle CAFM-Beschaffungen sollte deshalb die gesamte Lieferkette transparent gemacht und ein Wechselprozess geregelt werden, der vergaberechtlich nicht zu einer stillen Verschiebung des Bewertungsbildes führt.

Sämtliche Unterauftragnehmer und Unterauftragnehmerketten sind mit Name, Sitz, Leistungsbeschreibung, Datenstandort und Zugriffsebene bereits mit Angebotsabgabe offenzulegen. Der Wechsel eines für Hosting, Betrieb, Datenspeicherung, Supportzugriff oder Sicherheit relevanten Unterauftragnehmers bedarf einer Vorabinformation von mindestens 30 Kalendertagen; für besonders kritische Unterauftragnehmer ist die ausdrückliche Zustimmung des Auftraggebers erforderlich. Der Auftragnehmer legt jährlich einen aktuellen C5-Bericht Typ 2 sowie auf Verlangen Nachweise über Penetrationstests, Schwachstellenanalysen und Sicherheitsvorfälle vor. Der Auftraggeber, von ihm beauftragte Prüfer sowie, soweit einschlägig, zuständige Aufsichtsorgane erhalten die erforderlichen Prüf- und Einsichtsrechte.

Die folgende Checkliste übersetzt die vorstehenden Ergebnisse in einen vergabereifen Ablauf. Sie beruht auf der EVB-IT-Rahmenlogik, den Cloud-/Dienstleistungs-/Service-AGB sowie auf den vergaberechtlichen Leitplanken zu Leistungsbeschreibung, Losbildung, Zuschlagskriterien und Rahmenvereinbarungen.

Für die Angebotswertung empfiehlt sich bei einem SaaS-CAFM ein Beispielmodell wie das folgende. Es ist bewusst stärker auf Risiko-, Betriebs- und Sicherheitsqualität ausgerichtet als auf den reinen Lizenzpreis. Das ist mit GWB/VgV vereinbar, solange die Kriterien auftragsbezogen, transparent und prüfbar sind und Preis/Kosten Teil der Wertung bleiben.

fehlende Bereitschaft zur AVV, fehlende Offenlegung wesentlicher Unterauftragnehmer, keine C5-/gleichwertigen Sicherheitsnachweise, kein belastbarer Datenexport, unzulässige Verarbeitung zu eigenen Zwecken des Anbieters, keine prüfbaren SLA-Messpunkte oder keine Zustimmung zur vorgegebenen Vertragsrangfolge. Diese KO-Logik ist besonders wirksam, weil sie grundlegende Rechts- und Betriebsrisiken aus der eigentlichen Qualitätswertung heraushält.

Die Verhandlungs- und Fallstrickliste ist in diesem Thema auffällig konsistent. Der erste und häufigste Fehler ist die falsche Typenwahl: Wer reines SaaS als EVB-IT System oder Service ausschreibt, importiert unnötig Werk- oder Systemlogik, die später bei Abnahme, Haftung, Änderungsverfahren und Nachfolgebetrieb zu Konflikten führt. Umgekehrt verliert der Auftraggeber Steuerung, wenn er variable Schulungs- und Unterstützungsleistungen im Cloudvertrag nur als unspezifizierten Annex „mitschwimmen“ lässt.

Der zweite große Fehler ist die unkontrollierte Einbeziehung von Anbieter-AGB. Die amtlichen Cloudmuster lassen dies nur nachrangig und nicht beschränkend zu; genau daran sollte festgehalten werden. Kritisch sind insbesondere Klauseln zu einseitigen Funktionsänderungen, globalen Datenräumen, nicht genehmigungspflichtigen Subprocessor-Wechseln, weitreichenden Haftungsausschlüssen, Preisgleitklauseln ohne Obergrenze und automatischen Vertragsverlängerungen. Diese Punkte sollten schon im Vergabeverfahren abgefragt und nicht in die Zuschlagsphase verschoben werden.

Der dritte Fehler betrifft die Rahmenvereinbarung selbst. Wer variable Abrufe will, muss den Bedarf belastbar schätzen und die Obergrenze sauber festlegen. Die Kombination aus § 21 VgV und der EuGH-Rechtsprechung zu Höchstmenge/Höchstwert ist hier streng. Ebenso sollte jede nachträgliche qualitative Verschiebung — etwa ein anderer Cloudregionenmix, ein Austausch zentraler Unterauftragnehmer oder eine massive Ausweitung des Leistungsmodells — daraufhin geprüft werden, ob sie eine wesentliche Vertragsänderung darstellen könnte. Die 10-%-Grenze des § 132 GWB ist dabei kein Freibrief für qualitative Änderungen, sondern nur ein enges wertbezogenes Korrektiv.

ehlende Regelung der Datensicherungsverantwortung. Die Dienstleistungs-AGB legen diese ohne Sonderregel grundsätzlich beim Auftraggeber. Wenn der Dienstleister im Rahmen von Migration, Schulung auf Echtdaten, Konfigurationsunterstützung oder Administrationshilfe auf produktive Daten zugreift, muss die Datensicherungsfrage deshalb vertraglich ausdrücklich zugewiesen werden. Andernfalls entstehen im Schadensfall erhebliche Beweis- und Haftungsprobleme.

Schließlich ist auf die einschlägigen Leitlinien und Rechtsprechungsanker abzustellen. Für die Vertragsgestaltung besonders belastbar sind: die amtliche EVB-IT-Entscheidungshilfe 2026; der amtliche Rahmenvereinbarungsansatz; der Beschluss des IT-Planungsrat zur EVB-IT Cloud; der C5-Katalog und der Mindeststandard externer Cloud-Dienste des Bundesamt für Sicherheit in der Informationstechnik; die Hinweise der Die Beauftragte für den Datenschutz und die Informationsfreiheit[44] und der Datenschutzkonferenz zur Auftragsverarbeitung, zu Drittlandtransfers und zu cloudtypischen Eigennutzungen der Anbieter; sowie unionsrechtlich insbesondere Schrems II und die Rechtsprechung zu Höchstwert/Höchstmenge bei Rahmenvereinbarungen. Diese Quellen bilden zusammen einen belastbaren Primärrahmen für eine öffentliche SaaS-CAFM-Beschaffung in Deutschland.

Wenn keine außergewöhnlich hohe Individualisierung vorliegt, sollte die Vergabestelle die Ausschreibung auf EVB-IT Rahmenvereinbarung + EVB-IT Cloud + EVB-IT Dienstleistung zuschneiden, dabei Cloud-nahe Betreuung möglichst als Managed Cloud Service im Cloudmodul halten und Schulung/variable Unterstützungsleistungen als separat bepreiste Dienstleistungsabrufe ausgestalten. EVB-IT Service bleibt die Reserve für systembezogene Service-Sonderfälle; EVB-IT Pflege S für separat gepflegte Standardsoftware; EVB-IT System/Erstellung für echte Werk- und Entwicklungsprojekte. Diese Architektur minimiert Typenfehler, hält die Vergabe transparent, stärkt Datenschutz und Exit-Fähigkeit und bleibt zugleich mit der amtlichen EVB-IT-Systematik am konsistentesten.