Grundschutz++ OSCAL Catalog: What the BSI Actually Requires for Pentests

Grundschutz++ Has Arrived. But What Does It Actually Contain?

On April 1, 2026, the German Federal Office for Information Security (BSI) published the methodology guide for Grundschutz++. Along with it came three machine-readable OSCAL catalog files, freely available on GitHub. The entire catalog is a 4 MB JSON file, licensed under CC-BY-SA 4.0. Anyone can download, parse, and evaluate it.

That is exactly what we did. In this article, we show what the Grundschutz++ application catalog actually contains, how requirements are structured, and what this means for organizations that fall under Germany's NIS-2 implementation law.

Structure of the OSCAL Catalog

The catalog is based on NIST's OSCAL standard (Open Security Controls Assessment Language), a framework for describing security requirements in machine-readable form. The BSI uses OSCAL version 1.1.3 and provides the catalog in both JSON and XML format.

The application catalog contains a total of 998 requirements, distributed across 20 so-called practices. These practices cover the full spectrum of information security: from governance and compliance through risk management and facility management to detection, configuration, and software development.

Each individual requirement comes with structured metadata, including a security level (normal or elevated), an effort level from 0 to 5, and a modal verb that defines the degree of obligation.

MUST, SHOULD, CAN: The Obligation Levels

The three modal verbs in the catalog follow the BSI's established system. MUST means mandatory, no exceptions. SHOULD means strongly recommended, deviations must be justified. CAN means optional, advisable for organizations with elevated protection needs.

The distribution across all 998 requirements is revealing:

• 152 requirements are marked as MUST
• 620 requirements carry SHOULD
• 226 requirements are CAN

Less than one sixth of all requirements are actually mandatory. The vast majority falls into the category of recommendation or optional measure. For organizations looking for a pragmatic starting point, this may be a relief. For the actual security posture, it raises questions.

What the Catalog Says About Penetration Testing

The "Detection" practice (DET) is responsible for technical security testing. It contains five subgroups, including vulnerability management and attack detection. Penetration tests are listed under DET.5.4, titled "Regular Penetration Tests."

The metadata for this requirement speaks clearly:

The modal verb is CAN. The security level is set to elevated, meaning the requirement only applies to organizations with heightened protection needs. The effort level is 5, the highest in the entire catalog. In plain terms: penetration tests are optional, intended only for a subset of organizations, and classified as the most resource-intensive measure available.

The accompanying guidance text is actually quite solid. It describes pentests as simulated cyberattacks and references recognized methodologies such as the BSI Practical Guide for IS Penetration Tests, OWASP, PTES, and NIST SP 800-115. The qualification of the people performing the tests is highlighted as critical.

Vulnerability scans (DET.5.3) are one level higher at SHOULD. Automated attack detection (DET.4.2) as well. The actual test by a human attempting to break into a system remains voluntary.

What This Means for Organizations Under NIS-2

Grundschutz++ is not just any framework. It was defined as the binding state of the art under Germany's NIS-2 implementation law (§ 44 Para. 1 BSIG). All important and particularly important entities must measure themselves against it.

If an organization implements only the MUST requirements, it has formally met the minimum standard. Penetration tests are not part of that minimum. Vulnerability scans as a SHOULD measure would need to be justified if skipped. But an active review of defensive capabilities by qualified testers? Optional.

This is not an oversight by the BSI. The classification as CAN at an elevated security level reflects the reality that penetration tests require effort, expertise, and budget. Not every small organization can or needs to conduct regular pentests. For organizations with critical infrastructure, sensitive data, or a serious threat landscape, however, the optional classification is difficult to justify.

Automated Compliance Does Not Replace Security Testing

The paradigm shift of Grundschutz++ lies in machine readability. OSCAL enables automated checking of requirements against an organization's actual state. Tool vendors will bring OSCAL-capable compliance solutions to market in the coming months. Green dashboards, automated reports, real-time compliance monitoring.

This is progress for documentation and evidence management. But it has limits. No OSCAL check finds a SQL injection in a web application. No JSON catalog discovers that an administrator uses weak passwords. No automated tool detects whether social engineering works on employees.

The danger is that organizations confuse automated compliance with actual security. A green dashboard means that processes are documented and policies are in place. It does not mean an attacker stays out.

Assessment and Recommendation

Grundschutz++ is an important modernization step. The reduction to roughly 1,000 requirements, the machine-readable format, and the open development on GitHub make the standard more accessible and practical than its predecessor.

At the same time, no organization should make the mistake of limiting itself to minimum requirements. Anyone subject to NIS-2 who works with sensitive data or critical systems should not treat penetration tests as CAN. Experience from hundreds of initial assessments shows that organizations that never actively test their systems systematically overestimate their security posture.

The OSCAL catalog is a good tool for compliance. For actual security, you still need people who put systems to the test.