Three levels: method, evidence, management system

The German compliance landscape for IT security rests on three pillars that answer different questions. BSI IT-Grundschutz is a methodology for an information security management system (ISMS) and provides concrete building blocks with requirements. ISO/IEC 27001 is the international standard for the ISMS itself and is therefore certifiable. BSI C5 is a criteria catalogue specifically for cloud services that serves as auditable evidence (attestation).

For APIs, this classification matters because none of these frameworks contains its own "API security" clause. API security follows from generic requirements for authentication, authorization, logging, protection against automated abuse, and data protection, which are laid down in building blocks and controls. An auditor does not ask for a score, but whether these requirements have been implemented and evidenced for the specific interfaces.

The three frameworks relate to one another: according to the BSI, IT-Grundschutz is explicitly compatible with ISO/IEC 27001, and an organization can be certified to ISO 27001 on the basis of IT-Grundschutz. The foundation is formed by the BSI standards 200-1 (general ISMS requirements), 200-2 (building the ISMS), and 200-3 (risk analysis).

FeatureBSI IT-GrundschutzBSI C5ISO/IEC 27001
PublisherBSIBSIISO/IEC
What it isISMS methodology with building blocksCriteria catalogue for cloud servicesCertifiable ISMS standard
Result/evidenceISO 27001 certificate on the basis of IT-GrundschutzAttestation by auditors (ISAE 3000)Certificate from an accredited body
API-relevant partBuilding block APP.3.1 Web Applications and Web ServicesCloud controls, audited annuallyAnnex A / ISO 27002:2022, technological controls
Geographic focusGermany/DACHGermany, used across EuropeInternational
Current editionCompendium Edition 2022C5:2020 and C5:20262022 edition

BSI IT-Grundschutz, BSI C5, and ISO/IEC 27001 compared

BSI IT-Grundschutz: the APP.3.1 building block for web applications and web services

The IT-Grundschutz Compendium organizes security into building blocks. For APIs, the building block APP.3.1 Web Applications and Web Services is central. It explicitly covers web services as well, i.e. applications that provide data to other applications over HTTP(S) and are typically invoked not directly by humans but by programs. The building block explicitly names REST-based web services as an area of application.

The threat landscape described in the building block reads like an early precursor of the OWASP API Top 10. Among others, it names insufficient logging of security-relevant events, disclosure of security-relevant information (e.g. framework versions in responses), abuse through automated use (brute force against logins, enumeration of valid usernames, application-level denial of service through resource-intensive calls), and insufficient authentication.

The requirements are concrete and API-relevant:

  • APP.3.1.A1 Authentication: access to protected resources only after authentication, with defined thresholds for failed login attempts.
  • APP.3.1.A7 Protection against unauthorized automated use: measures against automated abuse, with an exception for functions explicitly intended for automation.
  • APP.3.1.A14 Protection of confidential data: server-side protection of credentials using salted hashing procedures.
  • APP.3.1.A9 Procurement: secure input validation and output encoding, secure session management, sufficient logging, and appropriate access management.

According to the building block, the information security officer (CISO) is responsible for fulfillment. The building block covers operations; development belongs in CON.10, web servers in APP.3.2.

BSI TR-03161: security requirements for applications in healthcare

The technical guideline BSI TR-03161 addresses manufacturers of healthcare applications and is the basis for the assessment of digital health applications. According to the BSI, it can also serve as a guideline for any application that processes or stores sensitive data.

The guideline is divided into three parts that together cover the typical structure of an API-based application:

  • Part 1: Mobile applications (the client).
  • Part 2: Web applications.
  • Part 3: Background systems, i.e. the backend services and thus the APIs through which mobile apps and web front ends obtain their data.

The requirements are formulated along the protection goals of confidentiality, integrity, and availability, and cover topics such as secure communication, authentication, data storage, and interface security. For providers in the healthcare sector, TR-03161 is thus the most concrete German benchmark for what security an API between app and backend must deliver.

BSI C5 as evidence and ISO/IEC 27001 as a management system

The Cloud Computing Compliance Criteria Catalogue (C5) was first published by the BSI in 2016 and sets a minimum level of security for cloud services. Anyone offering or procuring an API as a cloud service encounters C5 as an instrument of evidence. The mechanism: the provider has fulfillment of the C5 criteria attested by independent auditors according to recognized international auditing standards (type ISAE 3000). The result is a detailed audit report with a system description that is renewed annually. The BSI itself does not review the reports; the customer evaluates them as part of its own risk analysis. C5 thus makes the division of security-critical tasks between provider and customer transparent. The versions currently relevant are C5:2020 and the revised C5:2026.

ISO/IEC 27001, in its 2022 edition, specifies the requirements for establishing, operating, and continually improving an ISMS, and is certifiable through accredited bodies. The associated controls from Annex A are described in ISO/IEC 27002:2022 and organized into four themes: organizational, people, physical, and technological controls. The technological controls are especially API-relevant, for example on secure authentication, access control, secure development, logging, and network security. ISO 27001 does not require API-specific evidence, but rather that the applicable controls be selected on a risk basis, implemented, and their effectiveness reviewed regularly.

Relationship to DORA, NIS2, and GDPR

The German frameworks do not stand alongside the European regulations, they provide the implementation and evidence path for them. GDPR Art. 32, NIS2, and DORA each require measures appropriate to the risk and in line with the state of the art, without prescribing a concrete control list. It is precisely this concretization that IT-Grundschutz, ISO 27001, and C5 deliver.

  • An ISO 27001 certificate or a demonstrated IT-Grundschutz ISMS is recognized evidence that the organizational and technical measures required under GDPR Art. 32 and NIS2 are operated systematically.
  • A C5 audit report serves as evidence in the selection and management of cloud service providers, and thereby supports the third-party and ICT supply-chain oversight required under DORA and NIS2.
  • The building blocks and controls (such as APP.3.1 or the technological ISO controls) provide the auditable individual measures that an audit wants to see applied to specific endpoints.

For all these frameworks, the same principle that applies to DORA, NIS2, and GDPR remains decisive: what counts is not a certificate or a score, but the demonstrable link between the required measure, the tested endpoint, and the documented result. A finding per API with a traceable record that captures the test, the result, and how it was handled is exactly the evidence that an ISMS audit or a C5 attestation demands.

Sources

Keep reading
ComplianceDORA, NIS2 & GDPR for APIs ImplementationImplementing API Security SovereigntySovereignty in a Security Context