BSI IT-Grundschutz Compendium: Structure, Modules, and How to Use It

What is the BSI IT-Grundschutz Compendium?

The IT-Grundschutz Compendium from the Federal Office for Information Security (BSI) is the central reference work for information security in Germany. It is updated annually and in its current edition comprises over 100 modules that define concrete security requirements for virtually every aspect of information security.

Unlike ISO 27001, which is formulated at an abstract level and gives organizations significant room for interpretation, IT-Grundschutz is concrete. Where ISO 27001 says "appropriate access controls must be implemented," IT-Grundschutz says: "Here is a module for Windows servers, a module for Linux servers, and a module for Active Directory, and in each module you'll find the concrete requirements you need to implement."

This concreteness is simultaneously the greatest strength and the greatest challenge of IT-Grundschutz. The strength: you don't have to figure out yourself which measures are appropriate for a Windows server — the BSI has analyzed it for you. The challenge: the total scope is enormous, and full implementation of all relevant modules requires significant resources.

The methodology: From standard to concept

Before diving into the modules, you need to understand the BSI methodology. IT-Grundschutz is not just a controls catalog — it's a methodological framework for building and operating an ISMS.

BSI Standard 200-1: Information security management systems

BSI Standard 200-1 defines the foundations for an ISMS. It is compatible with ISO 27001 and describes the general requirements for information security management: security policy, organization, roles, resources, awareness, documentation, and review.

If you already operate an ISMS under ISO 27001, you'll find little new in BSI Standard 200-1. The requirements are largely equivalent, just structured differently.

BSI Standard 200-2: IT-Grundschutz methodology

BSI Standard 200-2 is the heart of the methodology. It describes three variants for implementation:

Basic protection. The entry-level variant. You implement the basic requirements of the relevant modules for all target objects (IT systems, applications, rooms, processes). This provides a fundamental level of security and is suitable as an entry point for organizations that don't yet have an ISMS.

Standard protection. The recommended variant for regular operations. You implement both the basic and standard requirements for all target objects. This achieves a security level that corresponds to the state of the art and serves as a basis for certification.

Core protection. A focused variant where you initially secure only the most critical business processes and their IT infrastructure. Core protection makes sense when you want to quickly achieve a high level of security for the "crown jewels" and catch up with the rest later.

BSI Standard 200-3: Risk management

BSI Standard 200-3 describes risk analysis as a complement to the IT-Grundschutz methodology. It comes into play when standard protection is not sufficient — that is, for elevated protection needs. The risk analysis identifies additional threats and vulnerabilities beyond standard scenarios and derives additional measures.

BSI Standard 200-4: Business continuity management

BSI Standard 200-4 supplements the IT-Grundschutz framework with business continuity management. It describes the methodology for BIA (business impact analysis), BCM planning, and emergency management.

The compendium structure: The ten layers

The IT-Grundschutz Compendium organizes its modules in ten layers, ranging from abstract process topics to concrete technical systems.

Process layers (Layers 1 to 4)

ISMS (Layer 1) contains the fundamental module ISMS.1 (Security Management), which defines the foundations for information security management. It is relevant for every organization and is always considered first.

ORP: Organization and Personnel (Layer 2) comprises modules for organizational security aspects: ORP.1 (Organization), ORP.2 (Personnel), ORP.3 (Awareness and Training), ORP.4 (Identity and Access Management), ORP.5 (Compliance Management).

CON: Concepts (Layer 3) contains overarching security concepts: CON.1 (Cryptography Concept), CON.2 (Data Protection), CON.3 (Backup Concept), CON.6 (Deletion and Destruction), CON.7 (Information Security When Traveling), CON.8 (Software Development), CON.9 (Information Exchange), CON.10 (Web Application Development), CON.11 (Classified Information Protection).

OPS: Operations (Layer 4) covers operational IT management: OPS.1 covers in-house operations (proper IT administration, patch and change management, vulnerability management, logging, software testing, archiving). OPS.2 covers operations by third parties (cloud usage, IT outsourcing, remote work). OPS.3 covers operations for third parties (provision of IT services).

System layers (Layers 5 to 10)

APP: Applications (Layer 5) comprises modules for specific application types: office products, web browsers, web servers, DNS servers, database systems, email clients and servers, directory services (Active Directory, LDAP), relational databases, SAP, and more.

SYS: IT Systems (Layer 6) covers specific operating systems and system types: Windows Server, Windows Client, Linux Server, macOS, mobile devices (iOS, Android), virtualization, containers, printers, and multifunction devices.

NET: Networks and Communication (Layer 7) comprises network components and concepts: network architecture and design, firewalls, VPNs, WLAN, routers and switches, network management, Voice over IP.

INF: Infrastructure (Layer 8) covers physical security: general building, data center, office space, server room, home office, media archive, cabling.

DER: Detection and Response (Layer 9) comprises modules for detecting and handling security incidents: detection of security-relevant events, security incident management, forensics, remediation of widespread security incidents.

IND: Industrial IT (Layer 10) covers the security of industrial control systems: process control and automation technology, programmable logic controllers (PLCs), sensors and actuators, machine safety.

Structure of a module

Each module follows a uniform structure that makes working with the compendium easier.

Introduction and objectives. Describes what the module addresses and why it is relevant.

Threat landscape. Lists the typical threats and vulnerabilities that affect the subject of the module. This gives you an overview of which risks the module addresses.

Requirements. The core of the module. The requirements are divided into three categories:

• Basic requirements (MUST): These requirements must be implemented to ensure a minimum level of security. They are required for basic protection.
• Standard requirements (SHOULD): These requirements correspond to the state of the art and should be implemented for standard protection. Deviations must be justified.
• Requirements for elevated protection needs (SHOULD): Additional requirements for target objects with particularly high security requirements.

Further information. References to relevant BSI documents, technical guidelines, and other sources.

Example: Module SYS.1.1 General Server

To make the structure tangible, here's a simplified example. Module SYS.1.1 describes the fundamental security requirements for servers, regardless of the operating system.

Basic requirements (excerpt):

• Appropriate placement (physically protected location)
• User authentication
• Restrictive privilege assignment
• Activation of role-based protection
• Protection of interfaces
• Deactivation of unnecessary services
• Security-relevant updates and patches

Standard requirements (excerpt):

• Definition of a security policy for servers
• Planning of server deployment
• Operational documentation
• Setting up a reference installation
• Logging
• System monitoring
• Regular data backup

Requirements for elevated protection needs (excerpt):

• Hard disk encryption
• Redundancy
• High availability

The more specific modules (SYS.1.2 for Windows Server, SYS.1.3 for Linux) supplement these general requirements with operating system-specific points.

IT-Grundschutz and ISO 27001: Not an either/or

One of the most common questions is: Should I use ISO 27001 or IT-Grundschutz? The answer: it's not an either/or. Both approaches can be combined, and there are various ways to do so.

Option 1: ISO 27001 certification based on IT-Grundschutz (BSI certification)

You can obtain an ISO 27001 certification based on IT-Grundschutz. This certification is issued by the BSI and confirms that you operate an ISMS under ISO 27001 and use the IT-Grundschutz methodology for controls selection.

The advantage: you get an internationally recognized ISO 27001 certification while using the concrete controls catalog of IT-Grundschutz. The disadvantage: the effort is significant because you must fully implement both the ISO 27001 requirements and the IT-Grundschutz methodology. This option is typically relevant for government agencies and large organizations.

Option 2: Standard ISO 27001 certification with IT-Grundschutz as a controls catalog

You build your ISMS under ISO 27001 and use the IT-Grundschutz modules as guidance for selecting and implementing controls. You are not bound by the full IT-Grundschutz methodology but benefit from the concrete recommendations in the modules.

This is the most pragmatic approach for mid-market companies. You use the IT-Grundschutz modules as a checklist to ensure you haven't overlooked anything essential when implementing Annex A controls, without having to perform the formal IT-Grundschutz modeling.

Option 3: Pure IT-Grundschutz without certification

You use IT-Grundschutz as an internal methodology to systematically raise your security level, but don't pursue certification. This makes sense when senior management or customers don't require a certificate but you want a structured approach for improving your information security.

Using IT-Grundschutz pragmatically: A guide

The sheer size of the compendium can be intimidating. Over 100 modules, hundreds of requirements, and the feeling that it will take you years to implement everything. Here's the pragmatic path.

Step 1: Conduct a structural analysis

Document your IT landscape: What business processes exist? What applications support these processes? On which IT systems do the applications run? How are the systems networked? In which facilities are they located?

The result is a structural plan that divides your IT landscape into target objects: applications, IT systems, network components, rooms, and buildings.

Step 2: Determine protection needs

Assess the protection needs for each business process and each target object across the three fundamental values: confidentiality, integrity, and availability. The BSI defines three protection need categories: normal, high, and very high.

Protection needs are inherited: if a business process has high protection needs, the supporting applications and IT systems inherit those protection needs. This simplifies the assessment but requires clean documentation of the dependencies.

Step 3: Modeling

Assign the appropriate modules from the compendium to each target object. A Windows server gets module SYS.1.1 (General Server) and SYS.1.2 (Windows Server). The associated server room gets INF.2 (Data Center and Server Room). The web application running on it gets APP.3.1 (Web Applications and Web Services).

Step 4: IT-Grundschutz check

For each assigned module, check which requirements are already implemented and where gaps exist. This is the actual legwork and requires technical know-how as well as access to the systems and their documentation.

Step 5: Risk analysis for elevated protection needs

For target objects with high or very high protection needs, the standard requirements may not be sufficient. Here you conduct a supplementary risk analysis per BSI Standard 200-3 and derive additional measures.

Step 6: Implementation and consolidation

Implement the identified measures, prioritized by protection needs and risk. Start with the basic requirements for all target objects (this gives you a solid foundation), then work through the standard requirements.

IT-Grundschutz and NIS2

For organizations within the scope of NIS2, IT-Grundschutz is a recognized method for demonstrating security requirements. The NIS2 transposition law provides that operators of critical infrastructure and particularly important entities may apply sector-specific security standards (B3S) recognized by the BSI. IT-Grundschutz qualifies as such a standard.

Specifically, this means: if you implement IT-Grundschutz at the standard protection level, you meet the technical and organizational measures that NIS2 requires in Article 21. The mapping is not one-to-one, but the coverage is high.

The NIS2-specific requirements that go beyond IT-Grundschutz (in particular reporting obligations, personal liability of senior management, and certain governance requirements) must be addressed separately.

Strengths and limitations of IT-Grundschutz

Strengths

Concreteness. IT-Grundschutz tells you what to do, not just that you should do something. This is particularly valuable for organizations without deep security expertise that need concrete guidance.

German-language and current. The compendium is updated annually and reflects the current state of the art. New technologies (containers, cloud, mobile) are covered promptly through new modules.

Freely available. The entire compendium is freely accessible on the BSI website. There are no license fees.

Recognized. IT-Grundschutz is the de facto standard for public administration in Germany and is accepted by many supervisory authorities and industry associations as evidence of compliance.

Limitations

Scope. Full implementation of all relevant modules requires significant resources. For small organizations with limited budget and personnel, the effort can be disproportionate.

Germany focus. IT-Grundschutz is a German standard. For organizations with an international orientation, ISO 27001 is the more broadly recognized basis.

Formal modeling. The full IT-Grundschutz methodology (structural analysis, protection needs assessment, modeling, IT-Grundschutz check) is resource-intensive and requires methodical execution. It is required for formal BSI certification but not for pragmatic use as a controls catalog.

Technology-heavy. IT-Grundschutz has a strong technology focus. The organizational and cultural aspects of information security are addressed in the process layers but receive less attention compared to the technical modules.

The pragmatic middle ground

For mid-market companies, I recommend the pragmatic middle ground: use ISO 27001 as the structural framework for your ISMS and IT-Grundschutz as the concrete controls catalog. You benefit from the international recognition and flexible structure of ISO 27001 while also leveraging the concrete, detailed recommendations of IT-Grundschutz.

In practice, this looks like this: you build your ISMS under ISO 27001, with risk assessment, Statement of Applicability, and Annex A controls. In ISMS Lite, BSI IT-Grundschutz modules can be directly mapped to assets and the implementation status documented per requirement. When you then want to implement a specific measure (for example, "How do I secure my Windows server?"), you look up the corresponding IT-Grundschutz module and use its requirements as a checklist. This gets you to concrete results faster without having to go through the entire formal IT-Grundschutz process.

Further reading

• Building an ISMS: The complete guide for companies with 50 to 500 employees
• NIS2 vs. ISO 27001: Commonalities, differences, and synergies
• ISMS frameworks compared: ISO 27001, BSI IT-Grundschutz, NIST, and more
• Protection needs assessment: Evaluating confidentiality, integrity, and availability
• Creating a security concept: From risk analysis to controls planning