ISMS Software Requirements Catalogue: What Goes In?

A requirements catalogue for ISMS software describes, in product-neutral terms, which tasks the tool has to handle, separates a small number of exclusion criteria from weighted award criteria, and specifies how each requirement will be tested. Since 2026, most German public contracting authorities have to tender supplies and services EU-wide from EUR 216,000 net. KaitoSec has responded to catalogues like these as a bidder.

Buyers of ISMS software, whether municipalities, state authorities, municipal IT service providers, public utilities or mid-sized companies with an internal selection process, often start with a product data sheet instead of their own needs. The result is a catalogue that describes a product, not a task.

This guide is written for buyers. It shows how to structure the catalogue, separate exclusion criteria from award criteria, phrase functional and operational requirements and pick the right EVB-IT contract type. The template catalogue is deliberately product-neutral and works with any vendor, including the KaitoSec platform for ISMS, BCMS, DSMS and AIMS. You can test your finished draft against a tool in a KaitoSec demo.

What is a requirements catalogue for ISMS software, and when do you need one?

A requirements catalogue (in German often called a Lastenheft) describes, from the buyer's perspective which tasks ISMS software must handle and under which conditions it will run. In public procurement it is the core of the specification under § 121 of the Act against Restraints of Competition (GWB): clear enough that all bidders read it the same way and offers become comparable.

In the Pflichtenheft, by contrast, the vendor describes how it will implement the requirements. According to § 121(1) GWB, the specification contains "the functional or performance requirements or a description of the task to be solved" (translated). A catalogue describing tasks rather than product features meets this most directly.

Public contracting authorities must tender EU-wide once the estimated contract value reaches the threshold. § 106 GWB refers to EU law; since 1 January 2026 the net thresholds are EUR 216,000 for supplies and services of general public contracting authorities, EUR 140,000 for supreme and higher federal authorities and EUR 432,000 for sector contracting entities. The sector threshold applies to public utilities engaged in sector activities. The legal basis is Delegated Regulation (EU) 2025/2152, and Regulation 2025/2150 for sector contracting entities.

For software subscriptions without a total price, § 3(11) of the Public Procurement Regulation (VgV) counts the total value over the term for terms of up to 48 months, and 48 times the monthly value for indefinite or longer terms. Under § 3(1) VgV, options and renewals are included. A SaaS subscription with a modest annual price can therefore reach the threshold.

Below the thresholds, the specification follows § 23 of the Sub-threshold Procurement Rules (UVgO) where the federal government or the federal state applies the UVgO, and state procurement law otherwise.

The catalogue pays off even without a tendering obligation, say when a mid-sized company wants to support its ISMS with software. It forces you to clarify your needs before the first offer arrives and makes offers comparable.

How do you structure a requirements catalogue for ISMS software?

We recommend seven parts: initial situation and quantity structure, foundations of the overall solution, functional requirements, data migration and interfaces, operations and security, vendor and contract, evaluation procedure. Each requirement also gets a unique number, a type (exclusion, scored or information) and a test method.

The order is a template. What counts legally is that the characteristics of the contract are described "in the form of performance or functional requirements or a description of the task to be solved", "as precisely as possible", so that they "allow sufficiently comparable offers to be expected" (§ 31(2) no. 1 VgV; cf. § 121(1) GWB).

Number, type and test method are practical. Bidders answer line by line, evaluators can map every answer unambiguously, and bidder questions can refer to a number. For the type, the federal UfAB offers two categories:

• A criterion (exclusion, referred to below as "mandatory"): "Failure to meet a requirement marked as an exclusion criterion necessarily leads to the exclusion of the offer / request to participate."
• B criterion (scored): It is assessed according to "defined assessment standards and points systems (weighting points and assessment points)".

We add a third type, information: a statement without scoring, such as system requirements or the licensing model.

The quantity structure goes at the beginning. State editing and read-only users, tenants or organisational units, information domains, the estimated number of target objects and the planned standards. Without these figures, prices are not comparable.

Chapter	Content (examples)	Typical criterion type	Test method
1 Initial situation	Organisation, objectives, quantity structure, existing tools, preferred operating model	Information	–
2 Foundations of the overall solution	Required management systems (ISMS, possibly BCMS/DSMS), multi-user operation, German-language interface, web access, accessibility of the interface	Mostly mandatory	Self-declaration, presentation
3 Functional requirements	Approach according to ISO 27001 and/or IT-Grundschutz, risk, controls, audit, documents, incidents, reports	Mandatory (core methodology), scored (convenience, depth)	Use-case task, test installation
4 Data migration and interfaces	Import from CMDB, Excel/CSV, legacy tool; export of all data in an open format	Mandatory (export), scored (import depth)	Test installation with data extract
5 Operations and security	SaaS or on-premise, data location, tenants, SSO, roles, logging, backup, for SaaS a data processing agreement (Art. 28 GDPR)	Conditional mandatory criteria per operating model	Evidence, concept, contract annex
6 Vendor and contract	Certificates and attestations whose scope explicitly names the operation offered; SBOM; support and service levels (availability, response times); contract type (EVB-IT); exit	Suitability or mandatory, scored	Evidence, contract annex
7 Evaluation procedure	Weighting, points scale, presentation or test installation, evaluation panel	Procedural rule	–

On accessibility in chapter 2: for services intended for use by natural persons, "the accessibility criteria for persons with disabilities […]" must be taken into account "except in duly justified cases" (§ 121(2) GWB; below the thresholds, identically § 23(4) UVgO). Federal public bodies must take accessible design into account "in planning, development, tendering and procurement", graphical user interfaces included (§ 12a BGG); the benchmark is the BITV 2.0.

Mandatory criterion or points: how do you weight the requirements?

Mandatory criteria should only cover what the software would be unusable without; everything else belongs in weighted award criteria. Declare almost everything mandatory and you end up deciding on price alone. In public procurement, award criteria and their weighting must be stated in the contract notice or the procurement documents (§ 127(5) GWB).

As a rule of thumb, the mandatory set holds the methodological core of your ISMS and genuine legal or organisational obligations, such as a non-negotiable data location. Quality, depth, usability and convenience are scored with points. Methodological help comes from the UfAB, which the BMDS describes as "a practical guide for carrying out IT procurements". The current version, UfAB 2018, distinguishes A and B criteria and describes evaluation methods such as the simple and the extended benchmark method.

What separates suitability criteria from award criteria?

Suitability criteria concern the company, award criteria concern the offer. The two belong in separate parts of the catalogue.

Suitability criteria may relate exclusively to the qualification and authorisation to pursue the professional activity and to economic, financial, technical and professional capacity (§ 122(2) GWB). They must be linked to the subject matter of the contract and proportionate to it and to the contract value (para. 4). As proof of technical and professional capacity, the contracting authority can require, among other things, a list of the main services delivered in at most the last three years (§ 46(3) no. 1 VgV). When selecting suitability criteria and evidence, the particular circumstances of young companies and SMEs must be given appropriate consideration (§ 42(2) VgV).

The contract is awarded to the most economically advantageous offer, meaning the one with the best price-quality ratio (§ 127(1) GWB). Besides price or cost, factors such as quality, the qualifications of the staff assigned, customer service and technical assistance, and aspects of digital sovereignty may be taken into account (§ 58(2) VgV). The weighting may also be stated as a range (para. 3).

How do you set the points scale and the type of procedure?

Define what each score means for every scored requirement. An example scale: 0 = not available, 1 = only via a workaround or export, 2 = out of the box, 3 = out of the box plus reporting.

If you expect many vendors, a two-stage approach fits. In the competitive procedure with negotiation, suitability is checked first; only invited candidates submit offers (§ 17(1) and (4) VgV). The time limit for requests to participate is at least 30 days (para. 2).

Its admissibility is governed by § 14(3) VgV, for example when solutions need to be adapted. In the open procedure, the contracting authority examines the offers before suitability, but may deviate from this where increased effort or other procedural reasons stand in the way; no justification is required (§ 42(4) VgV).

The procurement office chooses the procedure. Your catalogue has to fit it.

Which functional requirements belong in the catalogue?

Functionally, the catalogue must reflect your methodology: for ISO 27001 the scope, risk assessment, Statement of Applicability, controls, internal audits and management review; for BSI IT-Grundschutz the steps structure analysis, protection requirements assessment, modelling, IT-Grundschutz check and risk analysis. On top come tasks, documents, incidents and reports.

What does the software need to cover for ISO 27001?

Derive the criteria from the requirements of ISO 27001. The software documents the scope, assesses risks and records their treatment.

For the Statement of Applicability (SoA), every control needs a justification for inclusion or exclusion. Controls carry owners and deadlines, and evidence is attached to the relevant control. Internal audit and management review belong in there as well.

What belongs in the catalogue for BSI IT-Grundschutz?

The benchmark is BSI Standard 200-2. It distinguishes basic, core and standard protection. Standard protection runs through structure analysis, protection requirements assessment, modelling, the IT-Grundschutz check and risk analysis to implementation planning. For this work, "suitable tools should be used", the BSI writes: a recommendation, not an obligation.

"On the one hand, these can be suitable IT-Grundschutz tools, i.e. applications that support the entire IT-Grundschutz approach, starting with master data collection, through the protection requirements assessment, the risk analysis and the target/actual comparison (IT-Grundschutz check), up to the fulfilment of the requirements."

— BSI Standard 200-2, chapter 8.4.3 (translated)

When buying IT-Grundschutz software, you can phrase the requirement as: "The software supports the approach according to BSI Standard 200-2 and assigns the modules of the currently valid BSI requirements catalogue to the target objects." A starting point for mandatory and scored criteria is the BSI's list of performance characteristics for software tools, such as risk analysis, reporting, audit support, multi-tenancy and field-level history. The list was written with the GSTOOL end of support in late 2016 in mind and still mentions the "basic security check". Modernise it rather than copying it.

Also plan for Grundschutz++. According to the BSI, certification against it will be possible from 1 January 2027, and certification against the previous IT-Grundschutz ends on 30 November 2031. A neutral scoring question would be: "Describe how and on what terms new BSI requirements catalogues, including Grundschutz++, are incorporated into the software, and what happens to existing data."

Which cross-cutting functions does every ISMS tool need?

Regardless of the standard, every ISMS tool needs:

• a risk method with traceable assessment, residual risk and risk owner
• tasks with status, follow-up dates and escalation
• audits with findings
• document control with versions and approvals
• analysis of security incidents
• reports for management

Working with several standards in parallel, the requirement reads: "A control can be mapped to several standard requirements." That is the principle of a control library for multiple standards (German).

If you also procure a BCMS according to BSI Standard 200-4 or a DSMS, a shared data set for assets, processes and people across the management systems belongs in the catalogue. If you don't need that, leave it out. Under § 31(1) VgV, the specification must give all companies equal access to the procurement procedure.

What applies to data migration, operations and vendor security?

Require an import from the sources you use today (CMDB, Excel/CSV, export from the legacy tool) and a complete export in an open format. Fix the operating model or set mandatory criteria per model. From the vendor, require evidence whose scope explicitly names the operation offered.

How do you specify data import and export correctly?

Name the sources concretely: target objects from the CMDB, people and roles, Excel or CSV files with field mapping, and existing data from the legacy tool including modelling and implementation status. Equally important is the way back: export of all data in a machine-readable format.

Test both in a test installation with your own data extract, not via self-declaration.

Moving away from a legacy tool is covered in the articles on replacing IT-Grundschutz software (German) and on the GSTOOL successor (German).

SaaS or on-premise: how do you decide on the operating model?

Decide the operating model upfront. If you want to allow both, phrase conditional mandatory criteria: "mandatory if offered on-premise" (for example operation on your own virtualisation, your own certificates) and "mandatory if offered as cloud" (for example data location in the EU or Germany). In tenders we responded to as a bidder, exactly this mechanism kept both models comparable without excluding either.

If a SaaS vendor processes personal data on your behalf, such as names and incident reports, a contract under Art. 28(3) GDPR is required. Make the data processing agreement mandatory. The EVB-IT Cloud terms (Cloud-AGB) themselves provide for concluding such an agreement in clause 6.1.3.

Regardless of the model, include: separate tenants for multiple organisations or information domains, single sign-on via your identity management (for example SAML 2.0 or OpenID Connect "or equivalent"), a role concept, logging, and backup and restore.

What evidence should you require from the vendor?

Require certificates or attestations whose scope explicitly names hosting, operation, maintenance and support of the application offered.

For cloud services, the BSI's C5 criteria catalogue sets out "minimum requirements for secure cloud computing". The EVB-IT Cloud-AGB bind the contractor to the C5 basic criteria current at the time the contract is concluded (clause 1.2), verifiable for instance through a C5 Type 2 report (clause 6.4.1).

You only get an SBOM if you explicitly agree on it. The EVB-IT Überlassung-AGB (Type A) state in clause 4.4: "Where delivery of a Software Bill of Materials (SBOM) has been agreed, it must be provided for each item of standard software and each software component in accordance with BSI TR-03183-2." TR-03183-2 is available in version 2.1.0. The Cyber Resilience Act applies in full from 11 December 2027. It requires manufacturers to have an SBOM, but not to publish it.

For NIS2 entities, the risk management measures under § 30(2) no. 4 of the BSI Act (BSIG) include "supply chain security", including relationships with direct suppliers. The EVB-IT offer an NIS2 annex for this as an interim solution.

Which EVB-IT contract fits purchase, rental or cloud?

For permanently purchased standard software, EVB-IT Überlassung Type A is intended, optionally with maintenance; separately procured maintenance runs via EVB-IT Pflege S. Temporary provision is covered by Type B, software as a service by the EVB-IT Cloud contract. Contract type, operating model and specification have to match, otherwise bidder questions settle what the catalogue left open.

The BMDS overview of current EVB-IT describes Type A as "permanent provision of standard software, including maintenance where applicable", Type B as "temporary provision of standard software", Pflege S as "maintenance of standard software" and the Cloud contract as the basis for "the provision of cloud services such as SaaS, IaaS, PaaS". Implementation and training procured separately add EVB-IT Dienstleistung. The same page has an official decision aid for choosing.

Procurement model	Matching EVB-IT type	What to watch
Perpetual licence, on-premise	Überlassung Type A (optionally with maintenance) or Pflege S separately	Data backup lies with the contracting authority (Type A terms, clause 2.5)
Rental licence, on-premise	Überlassung Type B	Term and termination
SaaS	Cloud	C5 basic criteria (clause 1.2), data export and exit, data processing agreement under Art. 28 GDPR as an annex

How do you handle the exit in the Cloud contract?

The EVB-IT Cloud-AGB, version 1.0.2 of 1 March 2026, provide that the contractor makes the data available without separate remuneration (clause 13.1). The export interface remains available for up to three months after the end of the contract, provided the data has not been deleted (clause 13.3.3). If migration is delayed, a one-time continuation of service for a maximum of six months is provided for (clause 13.2.2).

Migration support, on the other hand, is only provided "where agreed" (clause 13.2). If you need it, state it explicitly in the catalogue.

A typical mismatch: the specification asks for a software service, but a provision contract is attached. Its obligations, such as delivery by download or data backup by the contracting authority, don't fit a service the vendor operates. Align the two before publication.

Which mistakes make a requirements catalogue unusable?

Typical mistakes are a catalogue copied from a product data sheet, too many mandatory criteria, requirements without a test method, skipping a hands-on test, and a cost view that only looks at the licence price. Each leads to offers that look alike on paper and differ in operation.

1. Copied from the product data sheet. § 31(6) VgV prohibits references to brands, types or particular processes if this favours or excludes certain companies or products, unless justified by the subject matter of the contract. If the subject matter cannot otherwise be described precisely enough, a reference is exceptionally permitted with the addition "or equivalent". Below the EU thresholds, § 23(5) UVgO exceptionally allows brand names with "or equivalent", and without this addition only for an objective reason that must be documented. Warning signs: menu items, module names and vendor-specific terms in the catalogue.
2. Only mandatory criteria. If all offers meet the same exclusion criteria, price effectively decides. Quality beyond the minimum earns no points.
3. Not testable. Under § 127(4) GWB, award criteria must be set so that "effective verification is possible of whether and to what extent the offers meet the award criteria". A criterion like "user-friendly" without a test task cannot be scored.
4. No hands-on test. Self-declarations confirm that a function exists. They don't show how well it works with your data and processes.
5. Follow-up costs forgotten. § 59 VgV allows the "cost" criterion to be based on life-cycle costs: acquisition, use, maintenance and end-of-life costs. The calculation method must be stated in the documents. For ISMS software this includes implementation, training, additional users, further standards, maintenance and the exit, covered in detail under costs of ISMS software.
6. Market research disguised as a tender. § 28 VgV permits market research before the procedure, but a procurement procedure "solely for market research and for the purpose of cost or price estimation" is not permitted. Involving vendors in preparation, § 7 VgV requires appropriate measures to ensure competition is not distorted.

How do you test the offers in practice?

Have the core requirements demonstrated in a presentation with predefined use-case tasks and in a test installation with an anonymised extract of your own data. Score with a fixed scale and at least two people. That turns "met" into a verifiable and comparable statement.

Describe the tasks in the procurement documents so all bidders compete on equal terms. Three examples, the first with fictitious values:

• "Create an information domain with 20 target objects from the attached CSV file and model it."
• "Carry out the IT-Grundschutz check for one target object and derive a control with a deadline."
• "Export all data of the tenant."

Give the future users access to the test installation, not just the project lead. Each task gets its own scoring sheet on which the score and the rationale are recorded in writing. That keeps the evaluation traceable weeks later.

According to § 58(5) VgV, "as a rule, at least two representatives of the contracting authority should be involved" in the award decision. How tools can differ in a direct test is shown in the comparison of IT-Grundschutz tools.

Want to run your draft catalogue against a tool? Bring your mandatory criteria and use-case tasks to a KaitoSec demo.

Frequently asked questions

What is the difference between a Lastenheft and a requirements catalogue?

Usually none: both describe from the buyer's perspective what the software should do. The Pflichtenheft, by contrast, is written by the contractor, usually after the award, and sets out how it will implement the requirements. In procurement law, the requirements catalogue is part of the specification under § 121 GWB.

Above what contract value does ISMS software have to be tendered EU-wide?

Since 1 January 2026, the threshold for supplies and services of most public contracting authorities is EUR 216,000 net, EUR 140,000 for supreme and higher federal authorities and EUR 432,000 for sector contracting entities. For subscriptions without a total price, the value over the term or 48 times the monthly value counts (§ 3(11) VgV).

Can I name a specific vendor in the catalogue?

As a rule, no. § 31(6) VgV prohibits references to specific products, brands or processes if this favours or excludes companies, unless the subject matter of the contract justifies it. References that are exceptionally permitted must carry the addition "or equivalent". Below the thresholds, § 23(5) UVgO contains a similar rule.

How many mandatory criteria make sense?

There is no standard or reliable figure for this. Only something whose absence would make the software unusable for your organisation qualifies as a mandatory criterion. Everything else belongs in weighted award criteria with a described points scale. § 127(4) GWB requires that it can be effectively verified whether and to what extent offers meet the award criteria.

Do I need C5 attestation for cloud software?

When procuring under EVB-IT Cloud, the Cloud-AGB oblige the contractor to comply with the BSI's C5 basic criteria current at the time the contract is concluded. On request, the contractor must provide security evidence, for example a current C5 Type 2 report. Whether you also require an attestation as a suitability or exclusion criterion is up to your catalogue.

Does Grundschutz++ already belong in the requirements catalogue?

Yes, as a scored requirement on catalogue maintenance. The BSI has announced publication of the Grundschutz++ methodology for 27 October 2026. Certifications will be possible from 1 January 2027, and certification against the previous IT-Grundschutz ends on 30 November 2031. Ask in the catalogue how new BSI catalogues are incorporated into the software.

Sources

1. §§ 106, 121, 122, 127 GWB, Act against Restraints of Competition, gesetze-im-internet.de.
2. §§ 3, 7, 14, 17, 28, 31, 42, 46, 58, 59 VgV, Public Procurement Regulation, last amended 2 September 2026, gesetze-im-internet.de.
3. Sub-threshold Procurement Rules (UVgO), BAnz AT 07.02.2017 B1, text version, Bremen Senator for Economic Affairs.
4. Decree "EU-Schwellenwerte ab 2026", BII1-70409/3#1, Federal Ministry for Housing, Urban Development and Building, 16 December 2025.
5. Delegated Regulation (EU) 2025/2152, Official Journal of the EU, 2025.
6. UfAB: Unterlage für Ausschreibung und Bewertung von IT-Leistungen, Federal Ministry for Digital and State Modernisation (BMDS), 2018 version.
7. Current EVB-IT, BMDS.
8. EVB-IT Cloud-AGB, version 1.0.2, BMDS, 1 March 2026.
9. EVB-IT Überlassung-AGB (Type A), version 3.0.0, BMDS, 1 March 2026.
10. BSI Standard 200-2: IT-Grundschutz Methodology, Federal Office for Information Security (BSI).
11. Leistungsmerkmale für Software-Tools, BSI.
12. Grundschutz++, BSI.
13. C5 criteria catalogue, BSI.
14. Technical Guideline TR-03183, BSI.
15. Cyber Resilience Act, BSI.
16. § 30 BSIG, BSI Act, gesetze-im-internet.de.
17. § 12a BGG and § 1 BITV 2.0, gesetze-im-internet.de.
18. Regulation (EU) 2016/679 (GDPR), Art. 28.