Why the ISMS Question Isn’t Optional with openDesk
Any government agency that introduces openDesk solves a sovereignty problem — but at the same time creates a new obligation: every new application, every new system, must fit into the existing information security management system (ISMS). BSI IT-Grundschutz remains the authoritative methodology for federal agencies and critical infrastructure (KRITIS) operators, and with the transposition of NIS-2 into national law, along with the Grundschutz++ changes in effect since January 2026, the pressure for clean, audit-ready documentation has, if anything, increased rather than decreased.
The good news up front: IT-Grundschutz is deliberately designed to be tool- and vendor-neutral. Open-source solutions meet the requirements just as well as proprietary products in principle — what matters is not who wrote the software, but whether the protection goals of confidentiality, integrity, and availability can be demonstrably achieved. For managing the ISMS itself, the open-source tool Verinice has also become established, directly mapping the Grundschutz methodology — structural analysis, protection needs assessment, module modeling, and risk analysis according to BSI Standards 200-1 through 200-3 included.
Cleanly Delimiting the Information Domain
The first step isn’t technical but conceptual: where exactly does the existing information domain end, and where does openDesk begin? For most agencies, it makes sense to model openDesk together with Nubus as its own, clearly delimited scope within the larger information domain — with defined interfaces to the existing network, identity management, and any specialized applications. This is especially worthwhile when openDesk is initially introduced only for part of the agency or in a pilot phase, because a narrowly delimited domain can be modeled with manageable effort and expanded later, rather than restructuring the entire agency IT all at once.
Important for the operating model: if openDesk is self-hosted — for example in an agency’s own data center, or via a Docker/Portainer-Kubernetes setup as described in the article on SSO integration — full responsibility for the Grundschutz modules lies with the agency itself. If openDesk is instead obtained as a managed service, part of the responsibility shifts to the provider, but must still be documented in the agency’s own ISMS as an outsourcing relationship with corresponding contractual proof obligations.
Mapping the openDesk/Nubus Components to Grundschutz Modules
IT-Grundschutz organizes its modules into thematic layers. For openDesk and Nubus, the most relevant ones can be mapped directly to the familiar components:
- ORP.4 Identity Management is the obvious module for Nubus: the directory service, Keycloak as identity provider, and the connection to an existing Active Directory or LDAP all belong precisely in this module. Anyone implementing the staged AD/LDAP migration described in the previous article is, at the same time, documenting a substantial part of this module.
- APP modules for the specialized applications cover Nextcloud, Collabora Online, OpenProject, Element, and the other openDesk modules. Since each of these nine projects has its own release cycle and its own security advisories, a separate, lean module entry per core application is recommended instead of one blanket “openDesk” object — this is the only way to keep track of which module already fulfills which protective measures.
- OPS Operations, particularly patch and vulnerability management, is no side issue for openDesk but the real day-to-day effort: nine independent open-source projects mean nine update paths and potentially nine simultaneous security advisories. A documented, well-rehearsed process for prompt patching is therefore one of the points auditors tend to scrutinize especially closely.
- SYS and NET for the underlying infrastructure cover the Kubernetes cluster on which Nubus runs, including ingress, certificate management, and network segmentation. Anyone running openDesk containerized via Docker and Portainer also documents, at this point, the hardening of the underlying Kubernetes-in-Docker setup.
- DER Detection and Response covers monitoring, logging, and incident handling. Via its provisioning and Guardian components, Nubus delivers structured events that can feed into a central logging and monitoring concept — a prerequisite for a security incident in any of the nine applications even being noticed promptly.
Making It Audit-Ready: What Matters in Practice
An auditor doesn’t check whether the technology could theoretically be secure, but whether the implementation is demonstrably documented. For openDesk/Nubus, this means concretely:
Complete evidence instead of claims. For every modeled module, the ISMS tool needs a documented implementation status — implemented, partially implemented, or not implementable with justification. A blanket reference to “open source is secure” doesn’t replace a single piece of evidence.
Patch history as a continuous log. Since openDesk publishes patch releases at short intervals, an automated log of which module was brought to which state and when is worthwhile. In an actual audit, this is the fastest way to prove that vulnerabilities were closed promptly.
Reference the role and permission concept directly from Nubus. Since Guardian controls role-based access control across all modules, the permission concept stored there can be adopted almost unchanged as evidence for the access control modules — saving duplicate documentation work.
Draw a clear line between your own and external areas of responsibility. Especially with self-managed Docker/Portainer operation, it’s important to clearly state in the security concept what your own IT is responsible for and what is inherited from the upstream projects — such as security patches provided by the individual module communities.
Practical Approach in Four Steps
- Structural analysis. Set up openDesk/Nubus as its own scope in the ISMS tool, capturing all components — identity management, specialized applications, infrastructure — as target objects.
- Protection needs assessment. Determine the protection needs for each component with respect to confidentiality, integrity, and availability; Nubus, as the identity layer, generally receives a higher protection requirement than an individual specialized application, because a failure or compromise immediately affects all connected modules.
- Modeling with the appropriate modules. Assign the modules mentioned above (ORP.4, the relevant APP modules, OPS, SYS/NET, DER) and carry out the target-vs-actual comparison using the IT-Grundschutz check.
- Plan for regular recertification. A security concept created once is not a free pass — for basic or standard protection under BSI-Grundschutz, a certificate is valid for three years, with annual surveillance audits in between. Precisely because openDesk continues to evolve on a monthly cadence, ISMS documentation should be updated continuously alongside the modules’ release cycles, not just ahead of recertification.
Conclusion
openDesk and Nubus are no obstacle to BSI-Grundschutz compliance — quite the opposite: the clear division into identity management, specialized applications, and infrastructure maps cleanly onto established Grundschutz modules, and with Verinice there’s even an open-source tool available for this that fits openDesk’s sovereignty philosophy. The real effort lies not in the modeling itself but in ongoing maintenance: nine independent projects with their own release cycles demand patch and evidence management run with the same discipline as the software development itself.
