The BSI IT-Grundschutz is Germany's comprehensive cybersecurity methodology, developed and maintained by the Federal Office for Information Security (BSI). The IT-Grundschutz Compendium provides a catalog of standard security safeguards organized into building blocks (Bausteine) covering processes, systems, and infrastructure. It enables organizations to achieve a security level appropriate for normal protection requirements and provides a clear path to ISO 27001 certification. Widely adopted in the DACH region, IT-Grundschutz is mandatory for German federal agencies and recognized as a rigorous, practical approach to information security.
10
Layers
~100
Modules
3
Approaches
Since 1994
Established
The Ten Layers
IT-Grundschutz organizes its building blocks (Bausteine) into ten layers. The first five cover process-level security topics, while the remaining five address specific systems, networks, and infrastructure.
Process Layers
🛡
ISMS — Information Security Management
Foundation for systematic information security management. Defines the security process, security organization, and management responsibilities.
Organizational and personnel-related security measures. Covers security awareness, training, outsourcing, and organizational structures.
Organisation, Personnel, Awareness, Outsourcing
📄
CON — Concepts & Procedures
Cross-cutting security concepts. Covers cryptography, data protection, privacy, data backup, deletion, software development, and cloud usage.
Crypto, Data Protection, Backup, Cloud
🔧
OPS — Operations
Operational security measures. Covers proper IT operations, patch management, malware protection, logging, monitoring, and outsourced operations.
IT Ops, Patching, Malware, Monitoring
🚨
DER — Detection & Response
Incident detection, response, and forensics. Covers security event detection, incident management, cleanup, IT forensics, and auditing.
SIEM, Incident Response, Forensics, Audit
System & Infrastructure Layers
💻
APP — Applications
Security requirements for specific application types including office products, web servers, email, DNS, directory services, databases, and containers.
Web, Email, DNS, Databases, Containers
🖥
SYS — IT Systems
Security requirements for IT systems including servers, clients, mobile devices, virtualization, and IoT devices.
Servers, Clients, Mobile, Virtualization
⚙
IND — Industrial IT
Security for industrial control systems including ICS components, PLCs, sensors, actuators, and process control systems.
ICS, SCADA, PLC, OT Security
🌐
NET — Networks
Network security requirements including architecture, firewalls, VPN, WLAN, network management, and VoIP.
Firewall, VPN, WLAN, Segmentation
🏢
INF — Infrastructure
Physical and environmental security for buildings, server rooms, data centres, offices, and mobile workstations.
Data Centre, Server Room, Physical Security
Why Should a Security Engineer Care?
The Gold Standard in DACH
IT-Grundschutz is the most widely recognized cybersecurity methodology in Germany, Austria, and Switzerland. If you operate in the DACH region, you'll encounter it in customer requirements, audits, and regulations.
BSI Certification = ISO 27001
BSI offers ISO 27001 certification based on IT-Grundschutz. This means you get ISO 27001 plus the detailed, prescriptive controls that IT-Grundschutz provides — more rigorous than standard ISO 27001.
Concrete, Not Abstract
Unlike high-level frameworks, IT-Grundschutz provides specific, actionable security measures for each module. It tells you exactly what to do, not just what to achieve.
Maps to EU Regulations
IT-Grundschutz provides strong coverage of NIS2 Art. 21 measures and DORA requirements. If you implement IT-Grundschutz, you have a solid compliance foundation for EU regulations.
BSI IT-Grundschutz vs. Frameworks You Already Know
Aspect
BSI IT-Grundschutz
ISO 27001
NIST CSF
NIS2
Type
National methodology + compendium
International standard
Voluntary framework
EU Directive
Origin
Germany (BSI)
International (ISO/IEC)
United States (NIST)
European Union
Approach
Prescriptive (specific measures)
Risk-based (Annex A controls)
Outcome-based (functions/categories)
Directive with implementing acts
Certification
Yes (ISO 27001 auf Basis von IT-Grundschutz)
Yes (ISO 27001)
No
National supervision
Modules / Controls
~100 modules, ~800+ requirements
93 Annex A controls
106 subcategories
10 mandatory measures
Protection Level
Standard protection + additional for high
Risk-based
Risk-based tiers
Proportionate to risk
Mandatory For
German federal agencies
Voluntary
US federal (reference)
EU essential/important entities
The Ten Layers — Deep Dive
Select a layer from the sidebar or filter below to focus on a specific domain.
ISMS — Information Security Management System
The ISMS layer is the foundation of IT-Grundschutz. It defines the systematic approach to managing information security, establishing the security process, defining roles and responsibilities, and ensuring continuous improvement. Every organization implementing IT-Grundschutz starts here.
Key ISMS Modules
Click any row for detailed context, obligations, and external references.
Module ID
Module Name
Description
Level
ISMS.1
Security Management
Establishes the security process, security policy, and security organization
Basis + Standard
DER.3.1
Auditing & Revision
Internal audits and compliance checks of the ISMS
Basis + Standard
DER.2.1
Security Incident Management
Processes for handling security incidents
Basis + Standard
Security Engineer Takeaway: ISMS.1 is non-negotiable — it is the single most critical module in IT-Grundschutz. Without a functioning security management process, all other modules are isolated measures without governance. Start here: define your security policy, appoint an Information Security Officer (ISB), establish a security organization, and create the security concept. This module maps directly to ISO 27001 Clauses 4–10.
ORP — Organisation & Personnel
The ORP layer addresses the organizational framework and human factor in information security. It covers how security is embedded into the organization's structure, HR processes, awareness programmes, and identity management.
Key ORP Modules
Click any row for detailed context, obligations, and external references.
Module ID
Module Name
Description
Level
ORP.1
Organisation
Organizational framework for security including roles, responsibilities, and processes
Security awareness programmes and targeted training
Basis + Standard
ORP.4
Identity & Access Management
Access control and identity management across the organization
Basis + Standard
Security Engineer Takeaway: ORP.4 (Identity & Access Management) is where most organizations have the biggest gaps. Ensure you have: (1) a documented authorization concept, (2) regular access reviews, (3) immediate deprovisioning on departure, (4) privileged access management (PAM). ORP.3 is equally critical — security awareness is not a checkbox exercise but a continuous programme tailored to your organization's risk profile.
CON — Concepts & Procedures
The CON layer provides cross-cutting security concepts that apply across the organization. These are the foundational policies and procedures that inform how specific technical measures are implemented.
Key CON Modules
Click any row for detailed context, obligations, and external references.
Module ID
Module Name
Description
Level
CON.1
Crypto Concept
Cryptographic concept including key management, algorithm selection, and policies
Basis + Standard
CON.3
Data Backup Concept
Backup strategy, procedures, testing, and restoration
Basis + Standard
CON.6
Deletion & Destruction
Secure data disposal and media sanitization
Basis + Standard
CON.8
Software Development
Secure development lifecycle and coding practices
Basis + Standard
CON.10
Cloud Services
Developing and using cloud services securely
Basis + Standard
Security Engineer Takeaway: CON.3 (Data Backup) is frequently underestimated until a ransomware incident proves its importance. Ensure your backup concept includes: (1) 3-2-1 rule (3 copies, 2 media types, 1 offsite), (2) regular restore testing, (3) immutable backups, (4) documented RTO/RPO targets. CON.10 (Cloud Services) is increasingly critical as organizations move to cloud — map your cloud usage to this module's requirements.
OPS — Operations
The OPS layer covers day-to-day operational security measures. These are the hands-on, operational practices that keep your IT environment secure including patching, monitoring, malware protection, and managing outsourced services.
Key OPS Modules
Module ID
Module Name
Description
Level
OPS.1.1.1
Proper IT Operations
Secure day-to-day IT operations management
Basis + Standard
OPS.1.1.2
Orderly IT Administration
IT administration practices and procedures
Basis + Standard
OPS.1.1.3
Patch & Change Management
Structured patch and change management processes
Basis + Standard
OPS.1.1.4
Malware Protection
Malware prevention, detection, and response
Basis + Standard
OPS.1.1.5
Logging
Security event logging and log management
Basis + Standard
OPS.1.1.6
Monitoring
System and network monitoring
Standard
Security Engineer Takeaway: OPS.1.1.3 (Patch & Change Management) and OPS.1.1.4 (Malware Protection) are your operational backbone. Unpatched systems and inadequate malware protection are the top two attack vectors in BSI's annual threat reports. Combine these with OPS.1.1.5/6 (Logging & Monitoring) to create a detection-in-depth approach. Aim for: patch SLAs of 7 days for critical vulnerabilities, EDR on all endpoints, and centralized log management with at least 90 days retention.
DER — Detection & Response
The DER layer focuses on detecting security events, managing incidents, performing forensics, and conducting audits. This layer is critical for organizations subject to NIS2 or KRITIS requirements, which mandate incident detection and reporting capabilities.
Key DER Modules
Module ID
Module Name
Description
Level
DER.1
Detection of Security Events
Security event detection, SIEM, and alerting
Basis + Standard
DER.2.1
Security Incident Management
Incident response process and coordination
Basis + Standard
DER.2.2
Cleanup after Security Incidents
Post-incident remediation and recovery
Standard
DER.2.3
Cleanup Verification
Verification that remediation was successful
Standard
DER.3.1
Auditing & Revision
Internal audits and compliance checks
Basis + Standard
Security Engineer Takeaway: DER.1 and DER.2.1 together form your SOC foundation. BSI expects you to have: (1) centralized logging feeding a SIEM or equivalent, (2) defined detection rules for common attack patterns, (3) documented incident response procedures with clear escalation paths, (4) regular IR exercises. If you are a KRITIS operator, these modules directly support your BSI reporting obligations.
APP — Applications
The APP layer provides security requirements for specific types of applications. Each module addresses the particular threats and measures relevant to that application category, from office software to containerized workloads.
Key APP Modules
Module ID
Module Name
Description
Level
APP.1.1
Office Products
Security for office suite applications
Basis + Standard
APP.1.2
Web Browser
Browser security hardening and management
Basis + Standard
APP.3.1
Web Applications & Web Services
Web application security (OWASP Top 10)
Basis + Standard
APP.3.2
Web Server
Web server hardening and configuration
Basis + Standard
APP.5.3
Email Server & Client
Email security, anti-spam, anti-phishing
Basis + Standard
APP.6
General Software
Software asset management and lifecycle
Basis + Standard
Security Engineer Takeaway: APP modules are selected during the modeling phase (Modellierung) based on which applications you actually use. Focus on APP.1.2 (Web Browser) and APP.5.3 (Email) first — these are the primary entry points for phishing and drive-by attacks. For web applications, APP.3.1 aligns well with OWASP standards.
SYS — IT Systems
The SYS layer covers security requirements for IT systems including servers, clients, mobile devices, and virtualization platforms. These modules provide system-level hardening and configuration baselines.
Key SYS Modules
Module ID
Module Name
Description
Level
SYS.1.1
General Server
Server baseline security and hardening
Basis + Standard
SYS.2.1
General Client
Client/desktop baseline security
Basis + Standard
SYS.3.2A
Mobile Device Management
MDM and mobile security management
Basis + Standard
SYS.1.5
Virtualization
Virtualization platform security
Basis + Standard
SYS.4.4
General IoT Devices
IoT device security
Basis + Standard
Security Engineer Takeaway: SYS.1.1 (General Server) and SYS.2.1 (General Client) are applied to every server and client in your environment during modeling. These provide your hardening baselines. Layer OS-specific modules (Windows Server, Linux Server) on top. Virtualization (SYS.1.5) is increasingly critical as hypervisor escapes become a realistic threat vector.
IND — Industrial IT
The IND layer addresses security for industrial control systems (ICS/OT). These modules are essential for manufacturing, energy, and critical infrastructure organizations operating operational technology environments.
Key IND Modules
Module ID
Module Name
Description
Level
IND.1
ICS Overview
General requirements for industrial control systems
Basis + Standard
IND.2.1
General ICS Components
Security for common ICS components
Basis + Standard
IND.2.2
Programmable Logic Controllers
PLC security and hardening
Basis + Standard
IND.2.3
Sensors & Actuators
Field device security
Basis
IND.2.7
Safety Instrumented Systems
Safety systems security
Basis + Standard
Security Engineer Takeaway: If you operate OT environments, IND modules are mandatory for your IT-Grundschutz modeling. Key priority: network segmentation between IT and OT (see also NET.1.1). IND modules complement IEC 62443 — if you already follow 62443, IT-Grundschutz IND modules map well and can demonstrate compliance in both frameworks.
NET — Networks
The NET layer defines security requirements for network infrastructure. Network architecture and segmentation form the backbone of defense-in-depth, making these modules critical for every organization.
Key NET Modules
Module ID
Module Name
Description
Level
NET.1.1
Network Architecture & Design
Network segmentation, zones, and architecture
Basis + Standard
NET.3.1
Router & Switches
Network device security and hardening
Basis + Standard
NET.3.2
Firewall
Firewall architecture, rulesets, and policies
Basis + Standard
NET.3.3
VPN
Virtual private network security
Basis + Standard
NET.2.1
WLAN
Wireless network security
Basis + Standard
NET.4.1
VoIP
Voice over IP security
Basis + Standard
Security Engineer Takeaway: NET.1.1 (Network Architecture) is foundational — proper network segmentation is the single most effective measure against lateral movement. BSI recommends a zone-based architecture with DMZ, management, and internal zones separated by firewalls (NET.3.2). Ensure your firewall rules follow a default-deny approach and are reviewed at least annually.
INF — Infrastructure
The INF layer addresses physical and environmental security. Often overlooked in cybersecurity discussions, physical security remains a fundamental requirement — you cannot secure data on servers that are physically accessible to unauthorized persons.
Key INF Modules
Module ID
Module Name
Description
Level
INF.1
General Buildings
Physical security fundamentals for all buildings
Basis + Standard
INF.2
Server Room & Data Centre
Data centre physical security, environmental controls
Basis + Standard
INF.5
Technical Room
Security for technical and utility rooms
Basis + Standard
INF.7
General Office
Office workspace security
Basis + Standard
INF.8
Mobile Workstation
Mobile and flexible work environment security
Basis + Standard
INF.9
Home Office
Home office / telecommuting security
Basis + Standard
Security Engineer Takeaway: INF.2 (Server Room & Data Centre) is critical for anyone operating their own infrastructure. Key requirements: access control (electronic, logged), environmental monitoring (temperature, humidity, water), fire suppression, redundant power (UPS + generator), and documented emergency procedures. INF.9 (Home Office) has gained importance post-pandemic — ensure your telecommuting concept covers secure connectivity, device security, and physical document handling.
Module Explorer
Key modules from each IT-Grundschutz layer. Click to expand details, requirements, and practical security notes.
ISMS — Information Security Management
ISMS.1Security ManagementCritical▶
Foundation of the ISMS. Defines the security process, security policy, security organization, and integration into organizational processes.
Key Requirements
Define and publish an information security policy approved by management
Appoint an Information Security Officer (ISB) with adequate authority and resources
Establish a security organization with defined roles and responsibilities
Create and maintain a security concept (Sicherheitskonzept)
Integrate the security process into all organizational processes
Regular management reviews and continuous improvement
Security Engineer Takeaway: This is the single most important module. Without ISMS.1, nothing else has a governance foundation. Ensure the ISB has direct reporting to management, a documented security concept, and regular management reviews. This module maps directly to ISO 27001 Clauses 4-10 and is the foundation for BSI certification.
ORP — Organisation & Personnel
ORP.1OrganisationCritical▶
Organizational framework for information security including roles, responsibilities, and security processes integrated into the organization's structure.
Key Requirements
Define clear security responsibilities for all roles
Establish security processes aligned with business processes
Ensure adequate resource allocation for security activities
Document and maintain organizational security procedures
Regular review and update of organizational measures
Security Engineer Takeaway: Clear roles and responsibilities prevent security gaps. Ensure every asset and process has a designated owner accountable for security. Build a RACI matrix for key security processes.
ORP.2PersonnelImportant▶
HR security measures including background checks, security agreements, training requirements, and offboarding procedures.
Key Requirements
Background checks proportionate to the sensitivity of the role
Non-disclosure agreements and security obligations for all employees
Security briefing during onboarding
Defined offboarding process with access revocation
Regular review of access rights when roles change
Security Engineer Takeaway: The biggest HR security risk is the gap between someone leaving and their access being revoked. Automate deprovisioning tied to HR events. Ensure security agreements cover third-party contractors as well as employees.
ORP.3Awareness & TrainingImportant▶
Security awareness programmes and targeted training to build a security-conscious culture across the organization.
Key Requirements
Develop and maintain a security awareness programme
Regular awareness campaigns covering current threats
Role-specific training for security-relevant positions
Phishing simulations and social engineering tests
Track and measure training effectiveness
Security Engineer Takeaway: Generic annual training is not enough. Build a continuous programme: monthly phishing simulations, quarterly awareness topics aligned with current threats, annual deep-dive training for high-risk roles (admins, developers, finance). Measure click rates, reporting rates, and repeat offenders.
ORP.4Identity & Access ManagementCritical▶
Access control and identity management across the organization, covering authentication, authorization, and privileged access.
Key Requirements
Document an authorization concept based on least privilege
Implement role-based access control (RBAC)
Privileged access management (PAM) for administrative accounts
Multi-factor authentication for sensitive systems
Regular access reviews and recertification
Immediate access revocation on role change or departure
Security Engineer Takeaway: IAM is consistently the highest-impact module after ISMS.1. Prioritize: (1) MFA for all admin and remote access, (2) PAM for privileged accounts, (3) quarterly access reviews, (4) automated provisioning/deprovisioning. This maps directly to NIS2 Art. 21(2)(i) and (j).
CON — Concepts & Procedures
CON.1Crypto ConceptImportant▶
Cryptographic concept including key management, algorithm selection, and organizational crypto policies.
Key Requirements
Document a cryptographic concept covering all use cases
Select appropriate algorithms based on BSI technical guidelines (TR-02102)
Encrypt data at rest and in transit where appropriate
Plan for cryptographic algorithm migration (post-quantum)
Security Engineer Takeaway: Follow BSI TR-02102 for recommended algorithms and key lengths. TLS 1.2+ is mandatory for all network communications. Start your post-quantum cryptography migration planning now — BSI recommends hybrid approaches for long-lived data.
CON.3Data Backup ConceptCritical▶
Backup strategy, procedures, testing, and restoration capabilities.
Key Requirements
Document a backup concept with defined RTO/RPO per system
Implement the 3-2-1 backup principle
Regular backup testing including full restore tests
Immutable or offline backup copies for ransomware resilience
Encryption of backup media
Monitoring of backup success/failure
Security Engineer Takeaway: Your backup concept is your last line of defense against ransomware. Key question: can you restore your critical systems from backup within your defined RTO? If you haven't tested it, you don't know. Test full restores quarterly, maintain at least one immutable/offline backup copy, and ensure backups are not accessible from the production network.
CON.6Deletion & Destruction of DataImportant▶
Secure data disposal and media sanitization to prevent data leakage from decommissioned systems and storage media.
Key Requirements
Define data retention and deletion policies
Implement secure deletion procedures per DIN 66399
Physical destruction of storage media when appropriate
Document and verify deletion activities
Cover cloud data deletion and provider responsibilities
Security Engineer Takeaway: Often overlooked until a data breach from a discarded hard drive makes the news. Align with DIN 66399 destruction classes. For cloud environments, understand your provider's data deletion guarantees and document them.
CON.8Software DevelopmentImportant▶
Secure software development lifecycle covering design, implementation, testing, and deployment.
Key Requirements
Integrate security into all phases of the development lifecycle
Threat modeling during design phase
Secure coding guidelines and code reviews
SAST/DAST in CI/CD pipelines
Security testing before production deployment
Dependency and supply chain management for software components
Security Engineer Takeaway: If you develop software, this module is essential. Implement shift-left security: threat modeling in design, SAST in CI pipelines, DAST in staging, dependency scanning (SCA), and security-focused code reviews. Maintain an SBOM for your applications.
CON.10Developing and Using Cloud ServicesImportant▶
Cloud security concept covering secure use of cloud services and shared responsibility models.
Key Requirements
Document a cloud security concept per provider/service
Understand and implement the shared responsibility model
Cloud provider evaluation using BSI C5 criteria
Data residency and sovereignty requirements
Cloud access security and identity federation
Exit strategy and data portability
Security Engineer Takeaway: Use BSI C5 (Cloud Computing Compliance Criteria Catalogue) to evaluate cloud providers. Ensure you understand the shared responsibility model for each service (IaaS vs PaaS vs SaaS have very different security scopes). Document data residency requirements — German authorities often require data processing within the EU/EEA.
OPS — Operations
OPS.1.1.1Proper IT OperationsCritical▶
Secure day-to-day IT operations management covering documentation, process management, and operational security procedures.
Key Requirements
Document all IT operational processes and procedures
Maintain up-to-date system and network documentation
Define and follow standard operating procedures
Capacity and performance management
Regular review and update of operational documentation
Security Engineer Takeaway: Proper operations documentation is the foundation for everything else. If you don't know what you're running, you can't secure it. Maintain a current network plan, system inventory, and process documentation.
OPS.1.1.2Orderly IT AdministrationCritical▶
IT administration practices and procedures for secure system management.
Key Requirements
Separate administrative and regular user accounts
Dedicated administration networks or jump servers
Four-eyes principle for critical administrative changes
Logging of all administrative activities
Regular administrative account reviews
Security Engineer Takeaway: Never use admin accounts for daily work. Implement a tiered administration model: Tier 0 for identity infrastructure, Tier 1 for servers, Tier 2 for workstations. Use dedicated admin workstations (PAWs) for high-privilege activities.
OPS.1.1.3Patch & Change ManagementCritical▶
Structured patch and change management processes to maintain system security and stability.
Key Requirements
Document a patch management policy with SLAs per severity
Regular vulnerability scanning to identify missing patches
Test patches before production deployment
Formal change management process (request, approve, implement, verify)
Emergency patching procedures for critical vulnerabilities
Track patch compliance across all systems
Security Engineer Takeaway: Unpatched systems are the #1 attack vector in BSI's threat reports. Define clear SLAs: critical patches within 7 days, high within 14 days. Automate patch deployment where possible, but always test critical patches first. Track compliance: aim for 95%+ patch compliance within SLA.
OPS.1.1.4Malware ProtectionCritical▶
Malware prevention, detection, and response measures across all systems.
Key Requirements
Deploy anti-malware on all systems (servers and clients)
Centralized management and monitoring of malware protection
Regular signature and engine updates
Email gateway anti-malware scanning
Web proxy content filtering
EDR/XDR for advanced threat detection
Procedures for malware incident handling
Security Engineer Takeaway: Move beyond traditional antivirus to EDR/XDR. Ensure coverage on all endpoints including servers. Key metrics: EDR coverage percentage, detection-to-response time, false positive rate. Combine with application whitelisting for high-value systems.
OPS.1.1.5LoggingImportant▶
Security event logging and log management for all relevant systems.
Key Requirements
Define a logging policy (what, where, how long)
Centralized log collection and management
Log retention aligned with legal and regulatory requirements
Protection of log integrity (tamper-proof storage)
Regular log review and analysis
Time synchronization across all systems (NTP)
Security Engineer Takeaway: Logging without analysis is wasted storage. Feed logs into a SIEM and create meaningful detection rules. Minimum retention: 90 days online, 1 year archived. Ensure all authentication events, privileged actions, and security-relevant changes are logged.
OPS.1.1.6MonitoringImportant▶
System and network monitoring for availability, performance, and security.
Key Requirements
Monitor availability and performance of critical systems
Network traffic monitoring and anomaly detection
Alerting and escalation procedures
Monitoring dashboards for operational awareness
Integration with incident management processes
Security Engineer Takeaway: Combine IT monitoring (availability) with security monitoring (SIEM). Use network flow analysis to detect lateral movement and data exfiltration. Establish baseline behavior and alert on anomalies.
OPS.1.2.5Remote MaintenanceImportant▶
Secure remote administration and maintenance procedures.
Key Requirements
Document approved remote maintenance methods and tools
Strong authentication (MFA) for all remote access
Encrypted connections for all remote maintenance
Logging and monitoring of all remote sessions
Approval workflow for third-party remote access
Security Engineer Takeaway: Remote maintenance is a high-risk attack vector. Use only approved tools, enforce MFA, record sessions for privileged access, and limit vendor access to specific time windows with approval. Never use shared credentials for remote access.
OPS.2.1Outsourcing for CustomersImportant▶
Managing outsourced services from a customer's perspective.
Key Requirements
Security requirements in outsourcing contracts
Regular assessment of outsourcing provider security
Incident notification obligations for providers
Audit rights and compliance verification
Exit strategy and transition planning
OPS.2.2Cloud UsageImportant▶
Secure use of cloud services as a consumer.
Key Requirements
Cloud security strategy and concept
Provider evaluation using BSI C5 criteria
Shared responsibility model documentation per service
Data classification and handling in cloud environments
Cloud security configuration baselines
Security Engineer Takeaway: Use BSI C5 attestation reports to evaluate cloud providers. For each service, document who is responsible for what in the shared responsibility model. Implement cloud security posture management (CSPM) to continuously verify configurations.
DER — Detection & Response
DER.1Detection of Security EventsCritical▶
Security event detection and SIEM capabilities for identifying threats and incidents.
Key Requirements
Deploy a SIEM or equivalent detection capability
Define detection rules for relevant threat scenarios
Correlate events across multiple sources
Establish alerting thresholds and triage procedures
Regular tuning of detection rules
Threat intelligence integration
Security Engineer Takeaway: Detection without response is useless, and response without detection is blind. Start with high-value detection use cases: failed auth brute force, lateral movement, privilege escalation, data exfiltration indicators. Feed threat intel into your SIEM to detect known IOCs.
DER.2.1Security Incident ManagementCritical▶
Incident response process covering detection, classification, containment, eradication, and recovery.
Key Requirements
Document an incident response policy and procedure
Define incident classification and severity levels
Establish escalation paths and communication plans
Define roles (IR team, management, legal, communications)
Regular IR exercises and tabletop tests
Post-incident review and lessons learned
Integrate with regulatory reporting requirements (NIS2, KRITIS)
Security Engineer Takeaway: Have playbooks for your top 5 incident scenarios: ransomware, data breach, insider threat, DDoS, supply chain compromise. Test them at least annually. Ensure you know your reporting obligations under NIS2/KRITIS before an incident happens — the clock starts when you become aware.
DER.2.2Cleanup after Security IncidentsImportant▶
Post-incident remediation and recovery procedures.
Key Requirements
Structured cleanup process after security incidents
Ensure complete eradication of attacker access
System rebuild or verified remediation
Password resets for compromised or potentially compromised accounts
Communication to affected parties
DER.2.3Cleanup VerificationImportant▶
Verification that incident remediation was successful and no remnants of the attack persist.
Key Requirements
Verify that all attacker artifacts have been removed
Confirm no persistence mechanisms remain
Validate that vulnerabilities exploited have been patched
Enhanced monitoring for reinfection indicators
DER.3.1Auditing & RevisionImportant▶
Internal audits and compliance checks against IT-Grundschutz requirements.
Key Requirements
Define an audit programme with scope and frequency
Conduct IS revision against IT-Grundschutz requirements
Document findings and track remediation
Management review of audit results
Independent audit capability
Security Engineer Takeaway: IT-Grundschutz compliance checks (Soll-Ist-Vergleich) are the core audit mechanism. For each module applied during modeling, verify that Base and Standard requirements are met. Document gaps and create a remediation plan with timelines.
APP — Applications
APP.1.1Office ProductsStandard▶
Security for office suite applications including macro security and document handling.
Key Requirements
Restrict macro execution (disable by default, whitelist trusted sources)
Disable or restrict ActiveX and embedded objects
Regular updates and patching of office applications
User guidance on handling documents from untrusted sources
APP.1.2Web BrowserImportant▶
Browser security hardening and management.
Key Requirements
Use current, supported browser versions
Centralized browser configuration management
Restrict extension/plugin installation
Enable safe browsing and phishing protection
Certificate validation and HSTS enforcement
Security Engineer Takeaway: The web browser is the primary attack surface for phishing and drive-by downloads. Manage browser configurations centrally via GPO or MDM, restrict extensions to approved ones, and enforce TLS/certificate checks.
APP.3.1Web Applications and Web ServicesImportant▶
Web application security including OWASP Top 10 protection and API security.
Dedicated admin access and restricted local accounts
Regular patching and vulnerability management
System integrity monitoring
Security Engineer Takeaway: SYS.1.1 is applied to every server during IT-Grundschutz modeling. It provides the baseline that OS-specific modules (Windows Server, Linux Server) build upon. Automate hardening using configuration management tools (Ansible, Puppet, Chef).
SYS.2.1General ClientCritical▶
Client/desktop baseline security applicable to all workstation types.
Key Requirements
Standardized client build with security baseline
Full disk encryption
Endpoint protection (EDR/antivirus)
Application whitelisting or control
Local firewall enabled
Automatic screen lock
User accounts without local admin rights
Security Engineer Takeaway: Golden rule: no local admin for regular users. Combine with full disk encryption, EDR, and automatic updates. Create a standardized client build and deploy via imaging/provisioning.
SYS.3.2AMobile Device ManagementImportant▶
MDM and mobile security management for smartphones and tablets.
Key Requirements
Deploy an MDM solution for all managed mobile devices
Enforce device encryption and passcode policies
Remote wipe capability
App management and restriction
Separation of business and personal data (containerization)
OS update enforcement
SYS.1.5VirtualizationImportant▶
Virtualization platform security including hypervisor hardening and VM isolation.
Key Requirements
Hypervisor hardening and minimal installation
VM isolation and resource separation
Dedicated management network for hypervisor administration
Secure VM provisioning and decommissioning
Regular patching of hypervisor platform
NET — Networks
NET.1.1Network Architecture and DesignCritical▶
Network segmentation, zones, and architecture design for defense-in-depth.
Regular review and update of network documentation
Security Engineer Takeaway: Network segmentation is the most effective measure against lateral movement. BSI recommends a minimum of: internet-facing DMZ, internal network zones by sensitivity, a dedicated management network, and guest/visitor isolation. Review your network plan annually and after significant changes.
NET.3.1Router and SwitchesImportant▶
Network device security and hardening for routers and switches.
Firewall architecture, rulesets, and management policies.
Key Requirements
Default-deny policy (block everything not explicitly allowed)
Documented firewall ruleset with business justification for each rule
Regular ruleset review and cleanup
Logging of all denied and critical allowed traffic
High-availability configuration for critical firewalls
Change management for firewall rule modifications
Security Engineer Takeaway: Every firewall rule should have: (1) a documented business reason, (2) an owner, (3) a review date. Audit your rulesets annually — remove rules for decommissioned systems and overly broad "any/any" rules. Use NGFW capabilities (application awareness, IPS) where available.
INF — Infrastructure
INF.1General BuildingsStandard▶
Physical security fundamentals for all buildings housing IT systems.
Key Requirements
Physical access control system (electronic preferred)
Visitor management and escort procedures
Physical security zones based on sensitivity
Perimeter security and intrusion detection
Key and access media management
INF.2Server Room and Data CentreCritical▶
Data centre physical security, environmental controls, and infrastructure resilience.
Key Requirements
Access control with logging (electronic, biometric for high security)
Environmental monitoring (temperature, humidity, water detection)
Fire detection and suppression systems
Redundant power supply (UPS + generator)
Redundant cooling systems
Cable management and physical separation
Emergency procedures documented and tested
Security Engineer Takeaway: Data centre physical security is foundational. If you operate your own server rooms, ensure environmental monitoring with 24/7 alerting, fire suppression appropriate for IT equipment (gas-based, not water), and UPS with at least 15 minutes autonomy plus generator backup. If you use colocation or cloud, verify these controls through provider audits.
BSI Security Approaches
BSI IT-Grundschutz defines three approaches (Vorgehensweisen) for implementing information security, depending on the organization's needs, size, and risk exposure.
The Three Approaches
Basic Protection (Basis-Absicherung)
BSI-Standard 200-2 • Entry Level
Entry-level approach for organizations starting their security journey
Covers the most essential security measures (Basis-Anforderungen only)
Good for small organizations or as a first step
Focuses on implementing base requirements from IT-Grundschutz
Not certifiable, but provides a solid foundation
Typical timeline: 3–6 months
Standard Protection (Standard-Absicherung)
BSI-Standard 200-2 • Recommended Target
The recommended approach for most organizations
Implements all standard requirements from IT-Grundschutz Compendium
Achieves protection for "normal" protection requirements (Normalschutzbedarf)
Basis for ISO 27001 certification based on IT-Grundschutz
Comprehensive coverage of all relevant modules
Typical timeline: 12–24 months
Core Protection (Kern-Absicherung)
BSI-Standard 200-2 • Focused Approach
Focused approach for protecting the most critical business processes and assets first
Ideal for organizations with limited resources
Protects "crown jewels" — the most valuable assets
Can be combined with Standard Protection over time
Not certifiable on its own, but a strategic starting point
Typical timeline: 6–12 months
Approach Comparison
Aspect
Basic Protection
Standard Protection
Core Protection
Goal
Essential security measures
Comprehensive security
Protect critical assets
Scope
Entire organization (basic)
Entire organization (full)
Critical processes only
Effort
Low–Medium
High
Medium (focused)
Requirements
Basis-Anforderungen only
Basis + Standard
Basis + Standard (critical scope)
Certification
Not certifiable
ISO 27001 auf Basis IT-Grundschutz
Not certifiable
Recommended For
SMEs, first-time implementers
All organizations (target state)
Large orgs, phased approach
Timeline
3–6 months typical
12–24 months typical
6–12 months typical
Requirement Levels
Each IT-Grundschutz module contains requirements at three levels:
Basis (Base Requirements)
Must-have • Always implement
Minimum security measures that should always be implemented
Required for all three approaches
Non-implementation must be justified and carries inherent risk
These are the "non-negotiables" of information security
Standard (Standard Requirements)
Should-have • Normal protection
Recommended for normal protection requirements (Normalschutzbedarf)
Combined with Base, achieves Standard Protection level
Required for ISO 27001 certification based on IT-Grundschutz
Should be implemented unless risk-based justification for deviation exists
Erhöht (Elevated Requirements)
For high protection needs • Additional risk analysis
Applied when information to be protected exceeds normal protection requirements
Highly confidential data, critical business processes, or high-impact systems
Selected based on additional risk analysis (BSI-Standard 200-3)
Often required for KRITIS operators and financial institutions
The IT-Grundschutz Process
1. Initiation & Scoping
ISMS.1 • Management
Define scope and approach (Basic/Standard/Core)
Appoint Information Security Officer (ISB)
Establish security organization
Approve security policy
2. Structural Analysis
BSI-Standard 200-2
Document business processes and IT dependencies
Create network plan and system inventory
Identify all IT systems, applications, and infrastructure
Group similar assets for efficient modeling
3. Protection Needs Assessment
BSI-Standard 200-2
Assess protection needs for confidentiality, integrity, availability
Classify as normal, high, or very high
Consider dependencies and maximum principle
Identify assets requiring elevated protection
4. Modeling (Modellierung)
IT-Grundschutz Compendium
Map IT-Grundschutz modules to each asset
Apply process modules (ISMS, ORP, CON, OPS, DER) organization-wide
Apply system/infrastructure modules (APP, SYS, NET, INF) to specific assets
Document the modeling result
5. Compliance Check (Soll-Ist-Vergleich)
BSI-Standard 200-2
For each mapped module, check implementation status of all requirements
Status: implemented, partially implemented, not implemented, not applicable
Document gaps and justifications
Create remediation plan
6. Risk Analysis & Certification
BSI-Standard 200-3
Additional risk analysis for elevated protection needs
Important milestones in the evolution of BSI IT-Grundschutz.
1994
First IT-Grundschutz Manual
BSI publishes the first IT-Grundschutz Manual (IT-Grundschutzhandbuch), establishing a systematic approach to information security for German federal agencies.
2005
ISO 27001 Alignment
IT-Grundschutz methodology aligned with ISO/IEC 27001, enabling "ISO 27001 certification based on IT-Grundschutz" as a recognized certification path.
2006
First BSI Certification
First ISO 27001 certification based on IT-Grundschutz issued by BSI-certified auditors, establishing the certification scheme.
2017
Major Modernization
BSI publishes BSI-Standards 200-1, 200-2, and 200-3, replacing the older BSI 100-x series. Introduction of the three new approaches (Basic, Standard, Core Protection). IT-Grundschutz Compendium replaces the old IT-Grundschutz Catalogs.
February 2018
First IT-Grundschutz Compendium
First edition of the IT-Grundschutz Compendium published with the new module structure organized into 10 layers.
2019
Compendium Annual Update
IT-Grundschutz Compendium annual update with additional modules and refinements to existing ones.
2020
Compendium Annual Update
Annual update reflecting new threat landscape and remote work requirements.
2021
BSI-Standard 200-4 Published
BSI-Standard 200-4 (Business Continuity Management) published, completing the BSI 200-x series and integrating BCM with IT-Grundschutz.
2022
Cloud & Container Modules
IT-Grundschutz Compendium annual update with expanded cloud computing and container technology modules.
2023
Compendium Edition 2023
IT-Grundschutz Compendium Edition 2023 with expanded modules for modern IT environments, including enhanced ICS/OT security modules.
February 2024
Compendium Edition 2024
IT-Grundschutz Compendium Edition 2024 released with updates reflecting NIS2 requirements and current threat landscape.
February 2025
Compendium Edition 2025
IT-Grundschutz Compendium Edition 2025 released with further alignment to NIS2 implementation and updated modules.
Ongoing
Annual Updates Continue
BSI continues to publish annual updates to the IT-Grundschutz Compendium, adding new modules and updating existing ones to address evolving threats and technologies.
Compliance Checklist
Track your IT-Grundschutz implementation progress. Checkmarks are saved locally in your browser.
Additional risk analysis performed for elevated protection needs
Audit & Certification
Internal audit completed against IT-Grundschutz requirements
Findings remediated or accepted with justification
Documentation package prepared for certification (if applicable)
External audit by BSI-certified auditor scheduled (if applicable)
ISO 27001 auf Basis von IT-Grundschutz certification achieved (if applicable)
Who Uses BSI IT-Grundschutz
BSI IT-Grundschutz is particularly relevant in the DACH region and for organizations with German federal connections, but its practical approach appeals to organizations globally.
Mandatory Use
Context
Requirement
Notes
German Federal Agencies
Mandatory per UP Bund (Implementation Plan for Federal Administration)
Must implement IT-Grundschutz Standard Protection
German Federal Contractors
Often required in contracts with federal agencies
BSI certification may be required
KRITIS Operators (Germany)
BSI-KritisV references IT-Grundschutz as implementation standard
Critical infrastructure operators in Germany
NIS2 Implementation (Germany)
BSI is the competent authority; IT-Grundschutz is the recognized implementation approach
NIS2UmsuCG (German NIS2 transposition)
Common Voluntary Adoption
Sector
Why They Use IT-Grundschutz
Notes
German Financial Services
BaFin references BSI standards; DORA implementation
Note on KRITIS: German critical infrastructure operators (KRITIS) are required to demonstrate appropriate security to BSI every two years. IT-Grundschutz or ISO 27001 certification is accepted as evidence. With the NIS2 transposition (NIS2UmsuCG), the number of organizations in scope is expected to increase significantly.
BSI Standards & Publications
BSI publishes a comprehensive set of standards (BSI-Standards) that define the methodology, and the IT-Grundschutz Compendium that contains the actual security modules and requirements.
BSI Standards
BSI-Standard 200-1: ISMS
Information Security Management Systems
Defines the general requirements for an ISMS
Compatible with ISO 27001
Establishes the framework for systematic security management
Covers security process, organization, and management commitment
BSI-Standard 200-2: IT-Grundschutz Methodology
How to Implement IT-Grundschutz
Describes the three approaches (Basic, Standard, Core)
Structural analysis and protection needs assessment
Modeling methodology (Modellierung)
Compliance check process (Soll-Ist-Vergleich)
Implementation and continuous improvement
BSI-Standard 200-3: Risk Analysis
Methodology for Risk Analysis
Methodology for risk analysis based on IT-Grundschutz
Used for assets with elevated protection needs
Covers threat identification, vulnerability assessment, and risk evaluation
Integrates with the IT-Grundschutz compliance check
BSI-Standard 200-4: Business Continuity Management
BCM Integrated with IT-Grundschutz
Business continuity management methodology
Business impact analysis (BIA)
BCM strategy and planning
Integrated with IT-Grundschutz for holistic resilience
Complements ISO 22301
IT-Grundschutz Compendium
Annual Publication
IT-Grundschutz-Kompendium
Published annually (typically February)
Contains all building blocks (modules) organized into 10 layers
Each module contains: description, threat landscape, base/standard/elevated requirements
Cross-reference tables to ISO 27001 Annex A controls
Available in German (primary) with partial English translations
Additional BSI Publications
Technical Guidelines & Criteria
BSI TR-02102: Cryptographic Mechanisms (recommended algorithms and key lengths)
BSI situation reports and threat landscape analyses
Certification & Compliance Context
BSI IT-Grundschutz is a methodology, not a regulation. However, it has significant regulatory leverage through certification, KRITIS requirements, and its role as the recognized implementation standard for NIS2 in Germany.
ISO 27001 auf Basis von IT-Grundschutz
BSI Certification Scheme
BSI-certified auditors conduct the audit
Certificate valid for 3 years with annual surveillance audits
More detailed than standard ISO 27001 — auditors check specific IT-Grundschutz requirements
Recognized internationally as ISO 27001 certification
Provides higher assurance due to prescriptive control verification
BSI as NIS2 Authority
German NIS2 Implementation
BSI is Germany's competent authority for NIS2 implementation
IT-Grundschutz provides the implementation pathway for NIS2 Art. 21 measures in Germany
Organizations implementing IT-Grundschutz have strong coverage of NIS2 requirements
KRITIS Requirements
Critical Infrastructure Protection
German critical infrastructure operators (KRITIS) must demonstrate security to BSI every 2 years
IT-Grundschutz or ISO 27001 are accepted as evidence
BSI can issue binding instructions to KRITIS operators
Sector-specific security standards (B3S) align with IT-Grundschutz
Non-compliance can result in orders and fines
Regulatory Leverage
Cross-Regulatory Recognition
BaFin (financial supervisor) references BSI standards in its regulatory expectations
Healthcare regulators reference BSI for sector-specific security
Implementing IT-Grundschutz provides evidence of compliance with multiple regulatory requirements simultaneously
DORA-regulated entities can leverage IT-Grundschutz for ICT risk management framework
German public procurement increasingly requires BSI certification
Security Engineer Takeaway: IT-Grundschutz is increasingly becoming a "master key" for regulatory compliance in Germany. Implementing Standard Protection and achieving ISO 27001 based on IT-Grundschutz provides evidence of compliance for NIS2, KRITIS, and sector-specific regulations simultaneously. The investment in IT-Grundschutz pays dividends across multiple compliance obligations. If you are subject to multiple German/EU regulations, IT-Grundschutz is often the most efficient compliance approach.
External Resources & References
Curated links to official documents, technical guidance, and tools. All links open in a new tab.
BSI's Alliance for Cyber Security. A platform for information exchange between businesses, public institutions, and BSI on cybersecurity topics.
AllianceInfo Exchange
Tip: The IT-Grundschutz Compendium is primarily published in German. While BSI provides some English translations, the authoritative versions of modules and requirements are in German. If you work in the DACH region, reading the German originals is recommended for precise interpretation. The BSI Standards 200-1 through 200-4 are available in English.
Search Results
🔍
Start typing in the search bar to find modules, requirements, and keywords.