Grundschutz++ signals a broader shift in modern ISMS design

At a glance

What this is: This is an analysis of BSI’s Grundschutz++ direction and its move toward a more digital, target-object based ISMS model.

Why it matters: It matters because IAM, NHI, and broader security governance teams will need to understand how control mapping, lifecycle management, and audit evidence change when the framework becomes more granular and machine-readable.

By the numbers:

• BSI's Grundschutz++ reduces requirements by around 85% through consolidation and clear must, should, can tiers.
• The new structure maps roughly 450 technical, 380 organisational, and 100 ISMS requirements.

👉 Read Nexis's analysis of BSI Grundschutz++ and ISMS modernisation

Context

Grundschutz++ is BSI's effort to modernise ISMS governance by moving away from the older IT-centric framing and toward a broader security model that can describe information, systems, networks, applications, locations, procurement, and users more directly. For security teams, the important question is not whether the terminology changes, but how a more granular control model affects governance, evidence, and accountability.

The shift also matters for identity programmes because lifecycle and access controls are easier to govern when framework requirements are attached to specific target objects rather than abstract modules. That creates an opportunity for stronger alignment between IAM, PAM, NHI, and audit processes, but it also raises the bar for consistent classification and control ownership.

Key questions

Q: How should organisations adapt their ISMS when requirements are mapped to target objects instead of modules?

A: Organisations should rebuild control ownership around concrete objects such as systems, applications, users, and procurement processes. That makes evidence collection, accountability, and audit tracing more precise. The key is to preserve interpretation quality while removing module-level ambiguity, so each requirement has a named owner and a measurable control path.

Q: Why does machine-readable security guidance matter for governance teams?

A: Machine-readable guidance matters because it can be imported into governance tooling, version control, and evidence workflows without manual re-entry. That improves consistency and change tracking, but only if the organisation maintains clean taxonomy and ownership. Without that discipline, automation simply accelerates confusion rather than reducing it.

Q: What breaks when control frameworks are reduced too aggressively?

A: What breaks is often not the number of controls, but the clarity of scoping and ownership behind them. If reduction is treated as simplification without redesigning governance paths, teams can lose traceability, misclassify assets, and weaken assurance. The practical test is whether every remaining control still has a clear purpose and evidence trail.

Q: How do IAM and NHI programmes fit into a modern ISMS model?

A: IAM and NHI programmes fit best when identities are treated as explicit control subjects with their own lifecycle, ownership, and evidence requirements. Service accounts, API keys, certificates, and privileged users should not disappear into general IT buckets. A modern ISMS should make those identity objects visible enough to govern and audit directly.

Technical breakdown

Target objects replace modules in the new ISMS model

Grundschutz++ moves from a module-based structure to target objects, meaning requirements attach directly to the thing being protected rather than to a generic building block. That is a material change in governance design because it narrows ambiguity. Instead of forcing a control into a prebuilt module, teams can map obligations to information, applications, systems, or even purchasing processes. The model also supports a more explicit separation between technical, organisational, and ISMS-level requirements, which should improve traceability for audits and internal ownership.

Practical implication: reorganise your control library so owners can map requirements to specific assets, processes, and identities without relying on module proxies.

Machine-readable requirements change how controls are consumed

A GitHub repository with machine-readable requirements suggests that Grundschutz++ is intended to be operationalised in digital workflows, not just read as a static standard. If requirements are published in structured formats such as JSON, they can be imported into governance tooling, evidence trackers, or assurance workflows more easily. That does not remove the need for interpretation, but it does reduce manual re-entry and makes version control, diffs, and traceability more feasible across security and compliance teams.

Practical implication: prepare your governance tooling for structured requirement ingestion, version tracking, and evidence mapping.

Control reduction changes the economics of assurance

An 85% reduction in requirements is not just simplification, it changes the economics of implementation. Fewer requirements can improve adoption, but only if the reduction reflects real consolidation rather than hidden ambiguity. When must, should, and can categories are clearer, teams can focus effort on the controls that carry the most assurance value. The risk is that organisations treat fewer requirements as less governance, when in practice the change demands tighter interpretation and better scoping discipline.

Practical implication: review whether your current assurance model relies on control volume rather than control precision.

NHI Mgmt Group analysis

Grundschutz++ is a governance redesign, not a cosmetic simplification. The move from modules to target objects changes how control ownership, audit evidence, and implementation scope are expressed. That matters because identity and access controls can no longer hide inside broad categories when the framework expects direct mapping to concrete assets and users. Practitioners should read this as a demand for sharper governance boundaries, not just a cleaner document structure.

Machine-readable standards push ISMS teams toward executable compliance thinking. A repository format such as JSON shifts the work from interpretation alone to structured consumption, which is where modern governance tooling already lives. That will help teams automate part of the mapping and review cycle, but only if the underlying control taxonomy is kept consistent. The implication is that assurance becomes more data-like, and teams need better metadata discipline.

Reduced requirement volume only works if the scoping model is stronger than before. An 85% cut in listed requirements can improve usability, but it also increases the importance of deciding what actually belongs to each target object. If scoping is weak, simplification becomes ambiguity with a better interface. Security leaders should expect more responsibility on governance design, because the framework itself is less of a crutch.

Identity governance will benefit most where organisations treat people, machines, and services as separate control subjects. A target-object model is naturally better suited to lifecycle and access control decisions when the governed entity is explicit. That creates a clearer bridge between ISMS, IAM, and NHI governance, especially where service accounts or technical users were previously buried in generic infrastructure controls. The practitioner conclusion is to align identity ownership with the new object model before the audit cycle forces the issue.

From our research:

• 89% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means many identity programmes still operate with incomplete non-human inventory.
• For the governance side of this problem, see the NHI Lifecycle Management Guide for how visibility, rotation, and offboarding change assurance outcomes.

What this signals

Target-object governance will pressure teams to get inventory right before they get automation right. If requirements are attached to concrete objects, incomplete service-account and workload inventories become governance defects, not just operational gaps. With only 5.7% of organisations having full visibility into their service accounts, identity teams should expect framework modernisation to expose baseline weaknesses faster than current control reviews do.

Machine-readable standards will reward organisations that can connect policy, evidence, and identity state. The practical advantage is not the repository format itself, but the ability to keep control logic, asset scope, and audit artifacts in sync as change happens. Teams that still separate IAM evidence from broader ISMS records will feel the friction first, especially where NHI ownership is shared across security and platform teams.

For practitioners

• Rebuild your control mapping around target objects Translate current module-based governance into asset, application, network, user, and procurement ownership so each requirement has a clear control owner and evidence path.
• Prepare for structured requirement ingestion Treat the GitHub repository as a signal to align governance tooling with machine-readable inputs, versioning, and traceable change management.
• Review where IAM and NHI controls sit inside ISMS scope Make sure service accounts, API keys, certificates, and privileged users are mapped to explicit governance objects rather than folded into generic infrastructure buckets.
• Test whether your assurance model depends on control count Validate that simplification does not hide missing evidence, unclear ownership, or weak scoping assumptions in the current framework.

Key takeaways

• Grundschutz++ changes the governance model by attaching requirements to target objects, which makes scoping and ownership more explicit.
• The reduction in requirement volume can improve usability, but only if organisations replace module thinking with stronger control traceability.
• IAM and NHI teams should treat the new structure as a prompt to tighten identity inventory, lifecycle ownership, and audit evidence mapping.

Key terms

• Target Object: A target object is the specific thing a security requirement applies to, such as an application, user, system, or location. In a modern ISMS, this reduces abstraction and makes ownership clearer because controls are tied directly to the protected asset rather than to a generic framework module.
• Machine-readable Requirements: Machine-readable requirements are security obligations published in structured form so tools can process them automatically. They support change tracking, evidence mapping, and workflow integration, but they still need human governance to preserve meaning, scope, and accountability.
• Control Traceability: Control traceability is the ability to follow a requirement from its policy definition through implementation and evidence. It helps auditors and security leaders confirm that a control exists, who owns it, and how it is validated over time.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Nexis: GRC Grundschutz++ The Next Step by the BSI Towards a Modern ISMS. Read the original.