Self-hosted GRC tools for NIS2: CISO Assistant and eramba

CISO Assistant is an open core project. Files outside the top-level enterprise directory are licensed under the GNU Affero General Public License v3.0 only (AGPL-3.0-only), which is an open-source license that permits use, modification and redistribution, with the obligation to share source code of modified versions when they are offered to users over a network. Files inside the enterprise directory are governed by the proprietary intuitem Commercial Software License and require a contract with intuitem.

• Core under AGPL-3.0-only: The community code outside the enterprise directory can be used, modified and self-hosted under the license terms.
• Enterprise directory under a commercial license: Code inside the enterprise directory is not covered by the AGPL and needs a separate agreement with intuitem.
• No feature list in the README: The README does not say which features sit in the enterprise directory, so you cannot infer edition coverage from it.
• Network use obligations: If you modify the AGPL code and let staff or suppliers access it over a network, the source of your modifications may need to be made available. Confirm how this applies to your setup.
• Contract cost: Any commercial terms for the enterprise directory are a negotiated cost that recurs, so ask intuitem for a written statement of what is included.

Before relying on a specific feature, confirm in writing with intuitem which components it depends on, and have legal counsel read the CISO Assistant license file alongside the README.

eramba Community is free to use, but it is not open source. Since a June 2024 update, the license published by eramba Limited forbids modifying, selling, licensing or otherwise distributing the software. eramba staff have stated that it should not be called open source because redistribution is not allowed. The license defines what you may do with the software, so the terms matter as much as the price.

• Use without payment: Running Community costs no license fee, but the license governs what you can do with it.
• Modification is prohibited: You cannot change the code to fit internal workflows, which limits in-house customization.
• Distribution is prohibited: Providing the software to affiliates, subsidiaries or suppliers as a hosted service may fall outside the license. Ask counsel how the terms treat group entities.
• Edition limits: Community covers 4 of 7 use cases. Awareness Programs, Automated Account Reviews and Online Assessments, plus automation, REST APIs, reporting and notifications, need the paid Enterprise edition.
• Enterprise license terms: Enterprise has its own terms, so confirm what it permits for modification and hosting before you buy.

Ask eramba Limited to confirm in writing whether your intended group hosting, customization and integrations are permitted under Community, and have legal counsel review the June 2024 license announcement against your plans.

Groups with several legal entities need to know who may run the software and for whom. The answer differs between the two tools and depends on how your group is structured, which is why generic license advice rarely settles the question. The points below are the questions to put to each vendor and to counsel before deployment.

• Who operates the instance: Confirm whether a parent company, a shared service center or a managed service provider may host and administer the tool for subsidiaries.
• Who uses the instance: Confirm whether employees and contractors of other group entities may log in, and whether that counts as distribution.
• Integrations and scripts: Ask whether writing scripts that call APIs, or adding connectors, counts as modification under each license.
• Customization costs: Under a restrictive license, custom features may have to come from the vendor or a contracted provider, which adds a recurring cost.
• Exit planning: Confirm how you export risk registers, evidence and control records if you change tools.

The license of the tool you choose becomes part of your NIS2 supplier and governance records, so keep the written answers with your third-party risk documentation.

A license review is a legal task, not a technical one. Your legal counsel should read the full license text for each tool, the vendor's written statements and any commercial agreement, then compare them against the use you intend. Your security team should supply the deployment model so counsel can test specific scenarios rather than general statements.

• Gather the source documents: Collect the license file, the README, the vendor's commercial terms and any statements on edition scope.
• Describe the deployment: Give counsel the number of entities, the hosting location, who administers the system and whether suppliers have access.
• List planned changes: Include customizations, integrations, reporting extensions and any plan to share configuration with other entities.
• Record vendor answers: Keep written confirmations about enterprise features and permitted use, dated and signed by the vendor.
• Review on change: Repeat the review when you upgrade, add entities, change hosting or buy a higher edition.

Before you choose a tool, have counsel confirm in writing that your intended use is permitted under each license and that the features you need are available in the edition you will run.

eramba Community covers 4 of the 7 use cases that eramba lists, and the remaining use cases sit behind the paid Enterprise edition. For a NIS2 program, the core risk and control records can run on Community, but several of the features that reduce manual follow-up do not. Ask eramba which use cases are included in the version you plan to run before you commit the process to it. The following features need Enterprise:

• Awareness Programs: Tracking training completion for the management body and staff is relevant to Article 20 training duties. On Community, you would record completion in another system and link the evidence manually.
• Automated Account Reviews: Periodic access reviews support the access control evidence supervisors ask for. Without automation, a named reviewer must extract and sign off each review by hand.
• Online Assessments: Questionnaires sent to suppliers or control owners are a common way to collect supplier and measure evidence. Without them, assessments usually run through spreadsheets or email.
• Automation, REST APIs, reporting and notifications: These connect eramba to ticketing, logging or asset sources, and they generate scheduled reports and reminders. Without notifications, evidence owners are not alerted when a testing date arrives, so someone must track the calendar outside the tool.

Confirm current feature availability in writing with eramba before you plan around any of these items.

CISO Assistant is open core. Files outside its top-level enterprise directory are licensed under AGPL-3.0, while files inside that directory fall under the proprietary intuitem Commercial Software License and require a contract with intuitem. The public README does not list which features sit in the enterprise directory, so you cannot determine the edition boundary from the repository alone. Treat any feature you need for NIS2 as unconfirmed until intuitem confirms it in writing.

• Ask for a feature map: Request a list of capabilities that sit in the enterprise directory, mapped to the features you plan to use, such as audits, third-party risk or reporting.
• Check the license terms: Read the license file in the repository to understand what a contract with intuitem would govern, including use, modification and redistribution.
• Confirm support and updates: Ask whether security fixes and framework content updates reach the community build in the same way as the commercial build.
• Clarify costs: Ask what is one-time, what recurs, and what the quote covers, including any modules required for NIS2 use.

In short, ask intuitem which capabilities sit in the commercial enterprise directory before relying on any of them.

A trial shows whether a tool produces the records a NIS2 assessment needs, which matters more than a feature list. Run the same test scenario in each tool, using a small set of real but non-sensitive records, and note which steps need manual work. Keep the trial environment on your own infrastructure so that the evidence you create can move into production without re-entry.

• NIS2 framework content: Load the NIS2 framework in each tool and confirm that Article 21 measures and the implementing regulation requirements appear with the expected structure and mapping.
• Risk register workflow: Create a risk, link it to a treatment and an owner, set a review date, and check whether reminders arrive without manual action.
• Supplier registry: Record a direct supplier with contact points and the ICT products or services it provides, as the implementing regulation requires, and confirm that the record can be exported.
• Evidence and testing schedule: Attach evidence to a control, assign an evidence owner, and check whether audit records for the next period are generated.
• Reporting and exports: Produce a report a supervisor could read, and confirm you can export it without vendor-specific tooling.

Record the result of each step, and ask the vendor to resolve any gap you find before you buy.

Your organization remains the owner of the NIS2 program. Management bears the Article 20 duties, approves the Article 21 measures and decides which risks are accepted. A GRC tool records those decisions but cannot make them on your behalf, so every risk entry, control statement and policy link in CISO Assistant or eramba needs a named person in your organization who answers for its accuracy.

• Management decisions: Approve the risk treatment plan, residual risk acceptance and the scope of the tool itself.
• Control owners: Name a person for each applied control who states how it operates and when it was last tested.
• Evidence owners: Assign who uploads or links each evidence item and who confirms it is current.
• Supplier registry content: Keep the supplier list in the tool accurate, since the implementing regulation expects contact points and the products or services each supplier provides.
• Policy approval: Hold the approval record for each policy outside the tool if your governance requires it.

Check that each control and evidence item in the tool shows a named owner and a review date that a person in your organization can defend.

An implementation partner such as DeployOpen can plan, install, configure, harden, back up, upgrade and document a self-hosted GRC platform inside your own infrastructure. The partner prepares the system and the records it holds. It does not decide whether your controls work, and it does not issue audit reports, attestations or certificates.

• Installation and configuration: Deploy the tool in your cloud account, data center or air-gapped network, and load the frameworks and assessment structures you choose.
• Hardening and access: Configure authentication, role separation and logging for the tool itself, since the GRC record is sensitive.
• Backup and recovery: Set up backups of the database and attachments and test restoration on a schedule agreed in the written scope.
• Upgrades and documentation: Track releases, apply upgrades and document the configuration so that a new administrator can follow it.
• Evidence preparation: Structure evidence items and audit records so your assessor can trace each control to its evidence.

Ask for a written scope that names each of these tasks and states which ones are one-time and which recur under a retainer.

NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. Where you commission an independent assessment, the auditor or assessor issues the findings and the report. Neither the tool nor the partner that configured it can stand in for that judgment.

• Competent authority: Can request documented policies, audit results and underlying evidence, and may test the controls directly.
• Independent assessor: Tests whether the controls operate as described and reports the result under its own name and method.
• Sampling and testing: Assessors select samples from the tool's records and compare them with the systems that produced the evidence.
• Limits of the tool: A record of a completed assessment is not proof that the control worked during the period in question.
• Assessor independence: Keep the assessor separate from the team that configured the tool, to avoid a conflict in the judgment.

Confirm with your assessor which records and access they need to see before the review starts, and how they will verify the tool's contents.