Anforderungskatalog ISMS-Software: Was gehört hinein?

Ein Anforderungskatalog für ISMS-Software beschreibt produktneutral, welche Aufgaben das Werkzeug lösen muss, trennt wenige Ausschlusskriterien von gewichteten Bewertungskriterien und legt für jede Anforderung fest, wie sie geprüft wird. Die meisten öffentlichen Auftraggeber müssen Liefer- und Dienstleistungen seit 2026 ab 216.000 Euro netto EU-weit ausschreiben. KaitoSec hat solche Kataloge als Anbieter beantwortet.

Wer ISMS-Software beschafft, ob Kommune, Landesbehörde, kommunaler IT-Dienstleister, Stadtwerk oder Mittelständler mit internem Auswahlprozess, beginnt oft mit einem Produktdatenblatt statt mit dem eigenen Bedarf. Heraus kommen Kataloge, die ein Produkt beschreiben, aber keine Aufgabe.

Dieser Leitfaden richtet sich an Beschaffer. Er zeigt, wie Sie den Katalog gliedern, Ausschluss- von Bewertungskriterien trennen, fachliche und betriebliche Anforderungen formulieren und den passenden EVB-IT-Vertragstyp wählen. Der Musterkatalog ist bewusst produktneutral und funktioniert mit jedem Anbieter, auch mit der Plattform von KaitoSec für ISMS, BCMS, DSMS und AIMS. Wer den fertigen Entwurf an einem Werkzeug durchspielen will, kann das in einer Demo von KaitoSec tun.

Was ist ein Anforderungskatalog für ISMS-Software, und wann brauchen Sie ihn?

Ein Anforderungskatalog (oft Lastenheft genannt) beschreibt aus Sicht des Auftraggebers, welche Aufgaben eine ISMS-Software lösen und unter welchen Bedingungen sie betrieben werden soll. In öffentlichen Vergaben ist er Kern der Leistungsbeschreibung nach § 121 GWB: so eindeutig, dass alle Anbieter ihn gleich verstehen und Angebote vergleichbar werden.

Im Pflichtenheft beschreibt dagegen der Anbieter, wie er die Anforderungen umsetzt. Laut § 121 Abs. 1 GWB enthält die Leistungsbeschreibung „die Funktions- oder Leistungsanforderungen oder eine Beschreibung der zu lösenden Aufgabe“. Ein Katalog, der Aufgaben beschreibt statt Produktmerkmale, erfüllt das am direktesten.

Öffentliche Auftraggeber müssen EU-weit ausschreiben, sobald der geschätzte Auftragswert den Schwellenwert erreicht. § 106 GWB verweist auf das EU-Recht; seit dem 1. Januar 2026 gelten netto 216.000 Euro für Liefer- und Dienstleistungen allgemeiner öffentlicher Auftraggeber, 140.000 Euro für oberste und obere Bundesbehörden und 432.000 Euro für Sektorenauftraggeber. Der Sektorenwert betrifft Stadtwerke mit Sektorentätigkeit. Grundlage ist die Delegierte Verordnung (EU) 2025/2152, für Sektorenauftraggeber die Verordnung 2025/2150.

Bei Software-Abos ohne Gesamtpreis zählt nach § 3 Abs. 11 VgV bei Laufzeiten bis 48 Monate der Gesamtwert der Laufzeit, bei unbestimmter oder längerer Laufzeit der 48-fache Monatswert. Optionen und Verlängerungen rechnen Sie nach § 3 Abs. 1 VgV mit. Ein SaaS-Abo mit überschaubarem Jahrespreis kann so den Schwellenwert erreichen.

Unterhalb der Schwellenwerte richtet sich die Leistungsbeschreibung nach § 23 UVgO, soweit Bund oder Land die UVgO anwenden, sonst nach Landesvergaberecht.

Auch ohne Ausschreibungspflicht lohnt der Katalog, etwa wenn ein Mittelständler sein ISMS mit Software unterstützen will. Er erzwingt die Klärung des eigenen Bedarfs, bevor das erste Angebot vorliegt, und macht Angebote vergleichbar.

Wie gliedern Sie einen Anforderungskatalog für ISMS-Software?

Wir empfehlen eine Gliederung in sieben Teile: Ausgangslage und Mengengerüst, Grundlagen der Gesamtlösung, fachliche Anforderungen, Datenübernahme und Schnittstellen, Betrieb und Sicherheit, Anbieter und Vertrag, Bewertungsverfahren. Jede Anforderung erhält außerdem eine eindeutige Nummer, einen Typ (Ausschluss, Bewertung oder Information) und eine Prüfmethode.

Die Reihenfolge ist ein Muster. Rechtlich zählt: Die Merkmale des Auftragsgegenstands sind „in Form von Leistungs- oder Funktionsanforderungen oder einer Beschreibung der zu lösenden Aufgabe“ zu beschreiben, „so genau wie möglich“, damit sie „hinreichend vergleichbare Angebote erwarten lassen“ (§ 31 Abs. 2 Nr. 1 VgV; vgl. § 121 Abs. 1 GWB).

Nummer, Typ und Prüfmethode haben einen praktischen Grund. Bieter antworten zeilenweise, Bewertende ordnen jede Antwort eindeutig zu, und Bieterfragen lassen sich auf eine Nummer beziehen. Für den Typ bietet die UfAB des Bundes zwei Kategorien:

• A-Kriterium (Ausschluss, im Folgenden „Muss“): „Die Nichterfüllung einer als Ausschlusskriterium gekennzeichneten Anforderung führt zwingend zum Ausschluss des Angebotes / Teilnahmeantrages.“
• B-Kriterium (Bewertung): Es wird nach „definierten Bewertungsmaßstäben und Punktesystemen (Gewichtungspunkte und Bewertungspunkte)“ bewertet.

Als dritten Typ ergänzen wir die Information: eine Angabe ohne Bewertung, etwa Systemvoraussetzungen oder Lizenzmodell.

Das Mengengerüst gehört an den Anfang. Nennen Sie schreibende und lesende Nutzer, Mandanten oder Organisationseinheiten, Informationsverbünde, die geschätzte Zahl der Zielobjekte und die geplanten Normen. Ohne diese Angaben sind Preise nicht vergleichbar.

Kapitel	Inhalt (Beispiele)	Typischer Kriterientyp	Prüfmethode
1 Ausgangslage	Organisation, Ziele, Mengengerüst, vorhandene Werkzeuge, gewünschtes Betriebsmodell	Information	–
2 Grundlagen der Gesamtlösung	benötigte Managementsysteme (ISMS, ggf. BCMS/DSMS), Mehrbenutzerbetrieb, deutschsprachige Oberfläche, Webzugriff, Barrierefreiheit der Oberfläche	überwiegend Muss	Eigenerklärung, Präsentation
3 Fachliche Anforderungen	Vorgehen nach ISO 27001 und/oder IT-Grundschutz, Risiko, Maßnahmen, Audit, Dokumente, Vorfälle, Berichte	Muss (Kernmethodik), Bewertung (Komfort, Tiefe)	Use-Case-Aufgabe, Teststellung
4 Datenübernahme und Schnittstellen	Import aus CMDB, Excel/CSV, Altwerkzeug; Export aller Daten in offenem Format	Muss (Export), Bewertung (Importtiefe)	Teststellung mit Datenauszug
5 Betrieb und Sicherheit	SaaS oder On-Premise, Datenstandort, Mandanten, SSO, Rollen, Protokollierung, Backup, bei SaaS Auftragsverarbeitungsvertrag (Art. 28 DSGVO)	bedingte Muss-Kriterien je Betriebsmodell	Nachweis, Konzept, Vertragsanlage
6 Anbieter und Vertrag	Zertifikate und Testate, deren Geltungsbereich den angebotenen Betrieb ausdrücklich nennt; SBOM; Support und Service-Level (Verfügbarkeit, Reaktionszeiten); Vertragstyp (EVB-IT); Exit	Eignung bzw. Muss, Bewertung	Nachweis, Vertragsanlage
7 Bewertungsverfahren	Gewichtung, Punkteskala, Präsentation oder Teststellung, Bewertungsgremium	Verfahrensregel	–

Zur Barrierefreiheit in Kapitel 2: Bei Leistungen zur Nutzung durch natürliche Personen sind „außer in ordnungsgemäß begründeten Fällen die Zugänglichkeitskriterien für Menschen mit Behinderungen […]“ zu berücksichtigen (§ 121 Abs. 2 GWB; unterhalb der Schwellenwerte gleichlautend § 23 Abs. 4 UVgO). Öffentliche Stellen des Bundes haben die barrierefreie Gestaltung „bei der Planung, Entwicklung, Ausschreibung und Beschaffung zu berücksichtigen“, grafische Programmoberflächen eingeschlossen (§ 12a BGG); Maßstab ist die BITV 2.0.

Muss-Kriterium oder Punkte: Wie gewichten Sie die Anforderungen?

Muss-Kriterien sollten nur das enthalten, ohne das die Software für Sie unbrauchbar wäre; alles andere gehört in gewichtete Bewertungskriterien. Wer fast alles zum Muss erklärt, entscheidet am Ende nur über den Preis. In öffentlichen Vergaben müssen Zuschlagskriterien und Gewichtung in der Bekanntmachung oder den Vergabeunterlagen stehen (§ 127 Abs. 5 GWB).

Als Faustregel gehören ins Muss der methodische Kern Ihres ISMS und echte rechtliche oder organisatorische Pflichten, etwa ein Datenstandort, der für Sie zwingend ist. Qualität, Tiefe, Bedienbarkeit und Komfort bewerten Sie mit Punkten. Methodische Hilfe bietet die UfAB, laut BMDS „ein Praxisleitfaden für die Durchführung von IT-Beschaffungen“. Die aktuelle Fassung UfAB 2018 unterscheidet A- und B-Kriterien und beschreibt Bewertungsmethoden wie die einfache und die erweiterte Richtwertmethode.

Was unterscheidet Eignungs- von Zuschlagskriterien?

Eignungskriterien betreffen das Unternehmen, Zuschlagskriterien das Angebot. Beides gehört in getrennte Teile des Katalogs.

Eignungskriterien dürfen ausschließlich die Befähigung und Erlaubnis zur Berufsausübung sowie die wirtschaftliche, finanzielle, technische und berufliche Leistungsfähigkeit betreffen (§ 122 Abs. 2 GWB). Sie müssen mit dem Auftragsgegenstand in Verbindung und zu ihm sowie zum Auftragswert in einem angemessenen Verhältnis stehen (Abs. 4). Als Beleg der technischen und beruflichen Leistungsfähigkeit kann der Auftraggeber unter anderem eine Liste der wesentlichen Leistungen aus den letzten höchstens drei Jahren verlangen (§ 46 Abs. 3 Nr. 1 VgV). Bei der Auswahl der Eignungskriterien und Eignungsnachweise sind die besonderen Umstände von jungen sowie kleinen und mittleren Unternehmen angemessen zu berücksichtigen (§ 42 Abs. 2 VgV).

Den Zuschlag erhält das wirtschaftlichste Angebot, also das mit dem besten Preis-Leistungs-Verhältnis (§ 127 Abs. 1 GWB). Neben dem Preis oder den Kosten können unter anderem Qualität, die Qualifikation des eingesetzten Personals, Kundendienst und technische Hilfe sowie Aspekte der digitalen Souveränität berücksichtigt werden (§ 58 Abs. 2 VgV). Die Gewichtung darf auch als Spanne angegeben werden (Abs. 3).

Wie legen Sie Punkteskala und Verfahrensart fest?

Beschreiben Sie für jede Bewertungsanforderung, was eine Punktzahl bedeutet. Eine Beispielskala: 0 = nicht vorhanden, 1 = nur über Umweg oder Export, 2 = im Standard, 3 = im Standard plus Auswertung.

Erwarten Sie viele Anbieter, passt ein zweistufiges Vorgehen. Im Verhandlungsverfahren mit Teilnahmewettbewerb wird zuerst die Eignung geprüft; Angebote geben nur aufgeforderte Bewerber ab (§ 17 Abs. 1 und 4 VgV). Die Teilnahmefrist beträgt mindestens 30 Tage (Abs. 2).

Wann diese Verfahrensart zulässig ist, regelt § 14 Abs. 3 VgV, etwa wenn Lösungen angepasst werden müssen. Im offenen Verfahren prüft der Auftraggeber die Angebote vor der Eignung, kann davon abweichen, soweit erhöhter Aufwand oder sonstige verfahrensbezogene Gründe entgegenstehen; eine Begründung ist dafür nicht erforderlich (§ 42 Abs. 4 VgV).

Welche Verfahrensart es wird, entscheidet die Vergabestelle. Ihr Katalog muss dazu passen.

Welche fachlichen Anforderungen gehören in den Katalog?

Fachlich muss der Katalog die Methodik abbilden, nach der Sie arbeiten: für ISO 27001 Geltungsbereich, Risikobeurteilung, Erklärung zur Anwendbarkeit, Maßnahmen, interne Audits und Managementbewertung; für BSI IT-Grundschutz die Schritte Strukturanalyse, Schutzbedarfsfeststellung, Modellierung, IT-Grundschutz-Check und Risikoanalyse. Dazu kommen Aufgaben, Dokumente, Vorfälle und Berichte.

Was muss die Software für ISO 27001 abdecken?

Leiten Sie die Kriterien aus den Anforderungen der ISO 27001 ab. Die Software dokumentiert den Geltungsbereich, beurteilt Risiken und hält deren Behandlung fest.

Für die Erklärung zur Anwendbarkeit (SoA) braucht jedes Control eine Begründung für Auswahl oder Ausschluss. Maßnahmen tragen Verantwortliche und Fristen, Nachweise hängen am jeweiligen Control. Internes Audit und Managementbewertung gehören ebenfalls hinein.

Was gehört für BSI IT-Grundschutz in den Katalog?

Maßstab ist der BSI-Standard 200-2. Er unterscheidet Basis-, Kern- und Standard-Absicherung. Die Standard-Absicherung führt über Strukturanalyse, Schutzbedarfsfeststellung, Modellierung, IT-Grundschutz-Check und Risikoanalyse zur Umsetzungsplanung. Für die Arbeit damit „sollten geeignete Hilfsmittel genutzt werden“, schreibt das BSI: eine Empfehlung, keine Pflicht.

„Dies können zum einen geeignete IT-Grundschutz-Tools sein, also Anwendungen, die die gesamte Vorgehensweise nach IT-Grundschutz unterstützen, beginnend bei der Stammdatenerfassung, über die Schutzbedarfsfeststellung, die Risikoanalyse sowie den Soll-Ist-Vergleich (IT-Grundschutz-Check) bis hin zur Erfüllung der Anforderungen.“

— BSI-Standard 200-2, Kapitel 8.4.3

Wer eine IT-Grundschutz-Software beschafft, kann die Anforderung so fassen: „Die Software unterstützt die Vorgehensweise nach BSI-Standard 200-2 und ordnet die Bausteine des jeweils gültigen BSI-Anforderungskatalogs den Zielobjekten zu.“ Einen Startpunkt für Muss- und Bewertungskriterien bieten die Leistungsmerkmale für Software-Tools des BSI, etwa Risikoanalyse, Berichterstellung, Revisionsunterstützung, Mandantenfähigkeit und Historienführung auf Feldebene. Die Liste entstand im Hinblick auf das Support-Ende des GSTOOL Ende 2016 und nennt noch den „Basissicherheitscheck“. Modernisieren Sie sie, statt sie abzuschreiben.

Planen Sie außerdem Grundschutz++ ein. Laut BSI ist eine Zertifizierung danach ab dem 1. Januar 2027 möglich, die Zertifizierbarkeit nach bisherigem IT-Grundschutz endet am 30. November 2031. Eine neutrale Bewertungsfrage lautet: „Beschreiben Sie, wie und zu welchen Konditionen neue BSI-Anforderungskataloge, einschließlich Grundschutz++, in die Software übernommen werden und was mit bestehenden Daten geschieht.“

Welche Querschnittsfunktionen braucht jedes ISMS-Tool?

Unabhängig von der Norm braucht jedes ISMS-Tool:

• eine Risikomethode mit nachvollziehbarer Bewertung, Restrisiko und Risikoeigner
• Aufgaben mit Status, Wiedervorlage und Eskalation
• Audits mit Feststellungen
• Dokumentenlenkung mit Versionen und Freigaben
• die Auswertung von Sicherheitsvorfällen
• Berichte für die Leitung

Arbeiten Sie mit mehreren Normen parallel, lautet die Anforderung: „Eine Maßnahme kann mehreren Normanforderungen zugeordnet werden.“ Das ist das Prinzip einer Kontrollbibliothek für mehrere Normen.

Beschaffen Sie ein BCMS nach BSI-Standard 200-4 oder ein DSMS mit, gehört ein gemeinsamer Datenbestand für Assets, Prozesse und Personen über die Managementsysteme hinweg in den Katalog. Brauchen Sie das nicht, lassen Sie es weg. Nach § 31 Abs. 1 VgV muss die Leistungsbeschreibung allen Unternehmen den gleichen Zugang zum Vergabeverfahren gewähren.

Was gilt für Datenübernahme, Betrieb und die Sicherheit des Anbieters?

Fordern Sie einen Import aus den Quellen, die Sie heute nutzen (CMDB, Excel/CSV, Export des Altwerkzeugs), und einen vollständigen Export in offenem Format. Legen Sie das Betriebsmodell fest oder formulieren Sie Muss-Kriterien je Modell. Vom Anbieter verlangen Sie Nachweise, deren Geltungsbereich den angebotenen Betrieb ausdrücklich nennt.

Wie fordern Sie Datenimport und -export richtig?

Benennen Sie die Quellen konkret: Zielobjekte aus der CMDB, Personen und Rollen, Excel- oder CSV-Dateien mit Feldzuordnung sowie Bestandsdaten aus dem Altwerkzeug mit Modellierung und Umsetzungsstatus. Ebenso wichtig ist der Rückweg: der Export aller Daten in maschinenlesbarem Format.

Prüfen Sie beides per Teststellung mit eigenem Datenauszug, nicht per Eigenerklärung.

Den Umstieg aus einem Altwerkzeug behandeln die Beiträge zur Ablösung einer IT-Grundschutz-Software und zur GSTOOL-Nachfolge.

SaaS oder On-Premise: Wie legen Sie das Betriebsmodell fest?

Entscheiden Sie das Betriebsmodell vorab. Wollen Sie beide zulassen, formulieren Sie bedingte Muss-Kriterien: „Muss, sofern On-Premise angeboten“ (etwa Betrieb auf eigener Virtualisierung, eigene Zertifikate) und „Muss, sofern Cloud angeboten“ (etwa Datenstandort EU oder Deutschland). In Vergaben, die wir als Anbieter beantwortet haben, hielt genau dieser Mechanismus beide Modelle vergleichbar, ohne eines auszuschließen.

Verarbeitet der Anbieter bei SaaS personenbezogene Daten in Ihrem Auftrag, etwa Namen und Vorfallmeldungen, ist ein Vertrag nach Art. 28 Abs. 3 DSGVO nötig. Fordern Sie den AV-Vertrag als Muss. Die EVB-IT Cloud-AGB sehen den Abschluss einer solchen Vereinbarung in Ziffer 6.1.3 selbst vor.

Modellunabhängig gehören hinein: getrennte Mandanten für mehrere Organisationen oder Informationsverbünde, Single Sign-on über Ihr Identitätsmanagement (etwa SAML 2.0 oder OpenID Connect „oder gleichwertig“), ein Rollenkonzept, Protokollierung sowie Backup und Wiederherstellung.

Welche Nachweise verlangen Sie vom Anbieter?

Verlangen Sie Zertifikate oder Testate samt Geltungsbereich, und zwar so, dass dieser Hosting, Betrieb, Wartung und Support der angebotenen Anwendung ausdrücklich nennt.

Für Cloud-Dienste beschreibt der Kriterienkatalog C5 des BSI „Mindestanforderungen an sicheres Cloud Computing“. Die EVB-IT Cloud-AGB verpflichten den Auftragnehmer auf die bei Vertragsschluss aktuellen C5-Basiskriterien (Ziffer 1.2), nachweisbar etwa per C5-Bericht Typ 2 (Ziffer 6.4.1).

Eine SBOM erhalten Sie nur, wenn Sie sie ausdrücklich vereinbaren. Die EVB-IT Überlassung-AGB (Typ A) regeln in Ziffer 4.4: „Soweit die Lieferung einer Software Bill of Materials (SBOM) vereinbart ist, muss diese für jede Standardsoftware und jede Softwarekomponente gemäß BSI TR-03183-2 bereitgestellt werden.“ Die TR-03183-2 liegt in Version 2.1.0 vor. Der Cyber Resilience Act gilt ab dem 11.12.2027 vollständig. Er verlangt von Herstellern eine SBOM, aber keine Veröffentlichung.

Für NIS2-Einrichtungen umfassen die Risikomanagementmaßnahmen nach § 30 Abs. 2 Nr. 4 BSIG die „Sicherheit der Lieferkette“, einschließlich der Beziehungen zu unmittelbaren Anbietern. Die EVB-IT bieten dafür eine Anlage NIS2 als Übergangslösung.

Welcher EVB-IT-Vertrag passt zu Kauf, Miete oder Cloud?

Für dauerhaft gekaufte Standardsoftware ist EVB-IT Überlassung Typ A vorgesehen, wahlweise mit Pflege; separat beschaffte Pflege läuft über EVB-IT Pflege S. Zeitweise Überlassung deckt Typ B ab, Software als Service der EVB-IT Cloudvertrag. Vertragstyp, Betriebsmodell und Leistungsbeschreibung müssen zusammenpassen, sonst klären Bieterfragen, was der Katalog offenließ.

Die Übersicht der aktuellen EVB-IT des BMDS beschreibt Typ A als „Dauerhafte Überlassung von Standardsoftware ggf. inkl. Pflege“, Typ B als „Zeitweise Überlassung von Standardsoftware“, Pflege S als „Pflege von Standardsoftware“ und den Cloudvertrag als Grundlage für die „Erbringung von Cloudleistungen wie SaaS, IaaS, PaaS“. Beschaffen Sie Einführung und Schulung getrennt, kommt EVB-IT Dienstleistung hinzu. Auf derselben Seite liegt eine offizielle Entscheidungshilfe für die Auswahl.

Beschaffungsmodell	Passender EVB-IT-Typ	Worauf achten
Kauflizenz, On-Premise	Überlassung Typ A (wahlweise mit Pflege) oder Pflege S separat	Datensicherung liegt beim Auftraggeber (Typ-A-AGB, Ziff. 2.5)
Mietlizenz, On-Premise	Überlassung Typ B	Laufzeit und Kündigung
SaaS	Cloud	C5-Basiskriterien (Ziff. 1.2), Datenexport und Exit, AV-Vertrag nach Art. 28 DSGVO als Anlage

Wie regeln Sie den Exit im Cloudvertrag?

Die EVB-IT Cloud-AGB in der Version 1.0.2 vom 01.03.2026 sehen vor, dass der Auftragnehmer die Daten ohne gesonderte Vergütung verfügbar macht (Ziff. 13.1). Die Exportschnittstelle steht bis zu drei Monate nach Vertragsende bereit, soweit die Daten nicht gelöscht sind (Ziff. 13.3.3). Bei verzögerter Migration ist eine einmalige Weiterleistung von maximal sechs Monaten vorgesehen (Ziff. 13.2.2).

Migrationsunterstützung gibt es dagegen nur, „soweit vereinbart“ (Ziff. 13.2). Brauchen Sie sie, gehört sie ausdrücklich in den Katalog.

Ein typischer Bruch: Die Leistungsbeschreibung verlangt einen Software-Service, beigefügt ist aber ein Überlassungsvertrag. Dessen Pflichten, etwa Lieferung per Download oder Datensicherung beim Auftraggeber, passen nicht zu einem Dienst, den der Anbieter betreibt. Gleichen Sie beides vor der Veröffentlichung ab.

Welche Fehler machen einen Anforderungskatalog unbrauchbar?

Typische Fehler sind ein aus einem Produktdatenblatt abgeschriebener Katalog, zu viele Muss-Kriterien, Anforderungen ohne Prüfmethode, der Verzicht auf einen Praxistest und eine Kostenbetrachtung, die nur den Lizenzpreis sieht. Jeder dieser Fehler führt zu Angeboten, die sich auf dem Papier gleichen und im Betrieb unterscheiden.

1. Aus dem Produktdatenblatt abgeschrieben. § 31 Abs. 6 VgV untersagt Verweise auf Marken, Typen oder bestimmte Verfahren, wenn dadurch bestimmte Unternehmen oder Produkte begünstigt oder ausgeschlossen werden, es sei denn, der Auftragsgegenstand rechtfertigt den Verweis. Lässt sich der Gegenstand sonst nicht hinreichend genau beschreiben, ist ein Verweis ausnahmsweise mit dem Zusatz „oder gleichwertig“ zulässig. Unterhalb der EU-Schwellen erlaubt § 23 Abs. 5 UVgO Markennamen ausnahmsweise mit „oder gleichwertig“, ohne diesen Zusatz nur aus sachlichem Grund, der zu dokumentieren ist. Erkennungszeichen: Menüpunkte, Modulnamen und herstellerspezifische Begriffe im Katalog.
2. Nur Muss-Kriterien. Erfüllen alle Angebote dieselben Ausschlusskriterien, entscheidet faktisch der Preis. Qualität, die über das Minimum hinausgeht, bekommt keine Punkte.
3. Nicht prüfbar. Nach § 127 Abs. 4 GWB sind Zuschlagskriterien so festzulegen, dass „eine wirksame Überprüfung möglich ist, ob und inwieweit die Angebote die Zuschlagskriterien erfüllen“. Ein Kriterium wie „benutzerfreundlich“ ohne Prüfaufgabe lässt sich nicht bewerten.
4. Kein Praxistest. Eigenerklärungen bestätigen, dass eine Funktion existiert. Wie gut sie mit Ihren Daten und Abläufen arbeitet, zeigen sie nicht.
5. Folgekosten vergessen. § 59 VgV erlaubt, das Kriterium „Kosten“ auf Lebenszykluskosten zu stützen: Anschaffung, Nutzung, Wartung und Kosten am Ende der Nutzungsdauer. Die Berechnungsmethode ist in den Unterlagen anzugeben. Bei ISMS-Software gehören Einführung, Schulung, zusätzliche Nutzer, weitere Normen, Pflege und der Exit dazu, ausführlich unter Kosten einer ISMS-Software.
6. Markterkundung als Ausschreibung getarnt. § 28 VgV erlaubt eine Markterkundung vor dem Verfahren, ein Vergabeverfahren „lediglich zur Markterkundung und zum Zwecke der Kosten- oder Preisermittlung“ ist dagegen unzulässig. Wer Anbieter schon bei der Vorbereitung einbindet, muss nach § 7 VgV angemessene Maßnahmen ergreifen, damit der Wettbewerb nicht verzerrt wird.

Wie prüfen Sie die Angebote in der Praxis?

Lassen Sie die Kernanforderungen in einer Präsentation mit vorab definierten Use-Case-Aufgaben und in einer Teststellung mit einem anonymisierten Auszug Ihrer eigenen Daten zeigen. Bewerten Sie mit einer festen Skala und mindestens zwei Personen. So wird aus „erfüllt“ eine überprüfbare und vergleichbare Aussage.

Beschreiben Sie die Aufgaben schon in den Vergabeunterlagen, damit alle Bieter unter gleichen Bedingungen antreten. Drei Beispiele, das erste mit fiktiven Werten:

• „Legen Sie einen Informationsverbund mit 20 Zielobjekten aus der beigefügten CSV-Datei an und modellieren Sie ihn.“
• „Führen Sie für ein Zielobjekt den IT-Grundschutz-Check durch und leiten Sie eine Maßnahme mit Frist ab.“
• „Exportieren Sie alle Daten des Mandanten.“

Geben Sie den Zugang zur Teststellung den späteren Anwendern, nicht nur der Projektleitung. Jede Aufgabe bekommt einen eigenen Bewertungsbogen, auf dem Punktwert und Begründung schriftlich festgehalten werden. So bleibt die Wertung auch Wochen später nachvollziehbar.

An der Zuschlagsentscheidung „sollen in der Regel mindestens zwei Vertreter des öffentlichen Auftraggebers mitwirken“, so § 58 Abs. 5 VgV. Wie sich verschiedene Werkzeuge im direkten Test unterscheiden können, zeigt der Vergleich der IT-Grundschutz-Tools.

Sie möchten Ihren Katalog-Entwurf an einem Werkzeug durchspielen? Bringen Sie Ihre Muss-Kriterien und Use-Case-Aufgaben in eine Demo von KaitoSec mit.

Häufige Fragen

Was ist der Unterschied zwischen Lastenheft und Anforderungskatalog?

Meist keiner: Beide beschreiben aus Sicht des Auftraggebers, was die Software leisten soll. Das Pflichtenheft verfasst dagegen der Auftragnehmer, in der Regel nach dem Zuschlag, und legt darin fest, wie er die Anforderungen umsetzt. Im Vergaberecht ist der Anforderungskatalog Teil der Leistungsbeschreibung nach § 121 GWB.

Ab welchem Auftragswert muss ISMS-Software EU-weit ausgeschrieben werden?

Seit 1. Januar 2026 gelten für Liefer- und Dienstleistungen der meisten öffentlichen Auftraggeber 216.000 Euro netto, für oberste und obere Bundesbehörden 140.000 Euro und für Sektorenauftraggeber 432.000 Euro. Bei Abonnements ohne Gesamtpreis zählt der Wert der Laufzeit oder der 48-fache Monatswert (§ 3 Abs. 11 VgV).

Darf ich im Katalog einen bestimmten Hersteller nennen?

Grundsätzlich nein. § 31 Abs. 6 VgV untersagt Verweise auf bestimmte Produkte, Marken oder Verfahren, wenn dadurch Unternehmen begünstigt oder ausgeschlossen werden, sofern der Auftragsgegenstand sie nicht rechtfertigt. Ausnahmsweise zulässige Verweise sind mit dem Zusatz „oder gleichwertig“ zu versehen. Unterhalb der Schwellenwerte regelt § 23 Abs. 5 UVgO Ähnliches.

Wie viele Muss-Kriterien sind sinnvoll?

Eine Norm oder belastbare Zahl dazu gibt es nicht. Als Muss-Kriterium taugt nur, was die Software ohne diese Eigenschaft für Ihre Organisation unbrauchbar macht. Alles Weitere gehört in gewichtete Bewertungskriterien mit beschriebener Punkteskala. § 127 Abs. 4 GWB verlangt, dass sich wirksam überprüfen lässt, ob und inwieweit Angebote die Zuschlagskriterien erfüllen.

Brauche ich für Cloud-Software einen C5-Nachweis?

Bei einer Beschaffung nach EVB-IT Cloud schuldet der Auftragnehmer laut Cloud-AGB die Einhaltung der bei Vertragsschluss aktuellen C5-Basiskriterien des BSI. Auf Anforderung muss der Auftragnehmer Sicherheitsnachweise vorlegen, etwa durch einen aktuellen C5-Bericht vom Typ 2. Ob Sie ein Testat zusätzlich als Eignungs- oder Ausschlusskriterium verlangen, entscheiden Sie selbst im Katalog.

Gehört Grundschutz++ schon in den Anforderungskatalog?

Ja, als Bewertungsanforderung zur Katalogpflege. Das BSI hat die Veröffentlichung der Grundschutz++-Methodik für den 27. Oktober 2026 angekündigt. Zertifizierungen sind ab 1. Januar 2027 möglich, die Zertifizierbarkeit nach bisherigem IT-Grundschutz endet am 30. November 2031. Fragen Sie im Katalog, wie neue BSI-Kataloge in die Software übernommen werden.

Quellen

1. §§ 106, 121, 122, 127 GWB, Gesetz gegen Wettbewerbsbeschränkungen, gesetze-im-internet.de.
2. §§ 3, 7, 14, 17, 28, 31, 42, 46, 58, 59 VgV, Vergabeverordnung, zuletzt geändert durch Art. 1 V v. 2.9.2026, gesetze-im-internet.de.
3. Unterschwellenvergabeordnung (UVgO), BAnz AT 07.02.2017 B1, Textfassung des Senators für Wirtschaft Bremen.
4. Erlass „EU-Schwellenwerte ab 2026“, BII1-70409/3#1, Bundesministerium für Wohnen, Stadtentwicklung und Bauwesen, 16.12.2025.
5. Delegierte Verordnung (EU) 2025/2152, Amtsblatt der EU, 2025.
6. UfAB: Unterlage für Ausschreibung und Bewertung von IT-Leistungen, Bundesministerium für Digitales und Staatsmodernisierung (BMDS), Fassung 2018.
7. Aktuelle EVB-IT, BMDS.
8. EVB-IT Cloud-AGB, Version 1.0.2, BMDS, 01.03.2026.
9. EVB-IT Überlassung-AGB (Typ A), Version 3.0.0, BMDS, 01.03.2026.
10. BSI-Standard 200-2: IT-Grundschutz-Methodik, Bundesamt für Sicherheit in der Informationstechnik (BSI).
11. Leistungsmerkmale für Software-Tools, BSI.
12. Grundschutz++, BSI.
13. Kriterienkatalog C5, BSI.
14. Technische Richtlinie TR-03183, BSI.
15. Cyber Resilience Act, BSI.
16. § 30 BSIG, BSI-Gesetz, gesetze-im-internet.de.
17. § 12a BGG und § 1 BITV 2.0, gesetze-im-internet.de.
18. Verordnung (EU) 2016/679 (DSGVO), Art. 28.