Which open-source tools for NIS2 measures and evidence fit your program
No open-source tool makes an organization compliant with NIS2, and NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, audits, scans and information requests, so the tools described here produce evidence that the organization must own, keep and be able to explain. An independent process, such as a supervisor's review or an external assessor's check, is what tests whether that evidence holds up. Treat each tool as a source of records for a specific Article 21 measure, not as a finished measure.
Which tools fit depends on the entity's size, sector and existing stack. A small essential entity running most workloads in one cloud may need little more than logging, authentication and backup components, while a larger group with a mature security operations center may only need a GRC platform to hold the evidence together. Recital 52 of NIS2 supports this direction: it says open-source cybersecurity tools and applications can diversify suppliers and support transparent, community-driven vulnerability discovery, and that Member States should be able to promote open-source software, in particular for SMEs facing implementation costs. That is a policy basis for considering open source, not a claim that open source is cheaper, easier to audit or sufficient on its own.
Before choosing, confirm three things with the vendor or project and within your own environment: the license, which determines your obligations if you modify or distribute the software, and any edition limits; whether the free edition includes the content you need, such as vulnerability tests or framework mappings; and who in your organization will own the configuration, retention and review of each tool's output. A tool that cannot show who changed a rule or when a backup was verified will not satisfy a supervisor's request for evidence, however capable its detection or scanning features are.
Which tool covers which NIS2 measure and what it produces
Each open-source tool below supports a specific group of NIS2 measures and produces a specific kind of record a supervisor can ask to see. Read each card for the license, the evidence it generates and the limit to confirm before you rely on it for an audit or inspection.
Wazuh for logging and detection
Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you write. Matching events are written to alerts.log and alerts.json, mapped to MITRE ATT&CK, and forwarded to the Wazuh indexer for review in the dashboard. The evidence is the alert record itself, so confirm which log sources your systems send, how long alerts are retained, and who reviews them. Wazuh is licensed GPL-2.0-only.
Keycloak for multi-factor authentication
Keycloak supports two-factor authentication with passkeys, recovery codes, and TOTP or HOTP codes from apps such as Google Authenticator or FreeOTP. One-time password policies and W3C WebAuthn settings are configurable in the administration console. The evidence is the realm configuration and authentication flow settings, which show which accounts must use a second factor. Confirm how privileged and remote accesses are enforced, since the policy must be applied to every relevant login path. Keycloak is licensed Apache-2.0.
Greenbone Community Edition for vulnerability handling
The OpenVAS Scanner executes vulnerability tests from the Greenbone Community Feed against target systems, with scans controlled by gvmd. Scan reports and their dates show that your systems are tested on a recorded schedule and that findings are tracked. Confirm before relying on it: the free Greenbone Community Feed excludes vulnerability tests for enterprise products, which are only in the paid Greenbone Enterprise Feed, so you must check whether your enterprise software is covered or needs another source. Greenbone Community Edition is licensed AGPL-3.0-or-later.
Bareos for backups
The Bareos Director schedules and supervises backup, restore, verify and archive jobs. It keeps a SQL catalog of backed-up files and can restore files from the current backup or from one before a given date and time. The evidence is the job logs, the catalog and the results of restore and verify jobs, which show that backups run and can be recovered. Confirm that your restore tests are scheduled and documented, because a catalog entry alone does not prove a restore works. Bareos is licensed AGPL-3.0-only.
OpenBao for secrets and cryptography
The OpenBao transit secrets engine encrypts and decrypts application data without storing that data, signs and verifies data, and supports versioned encryption keys with key rotation. Its audit and key-version records show how cryptographic keys are managed over time. Confirm the access policies on each key, how rotation is scheduled, and whether your cryptography policy covers the systems outside the engine. OpenBao is licensed MPL-2.0.
DFIR-IRIS for incident handling
DFIR-IRIS keeps each case as one record of assets, indicators of compromise, tasks and evidence, with a full audit trail. It triages alerts from SIEM, EDR and REST sources into cases and builds a consolidated investigation timeline. Evidence is logged with SHA-256 verification and chain of custody, and reports are generated from case data. Confirm that the reporting clock in your incident process is tracked outside the tool or in it, since the tool records the case but does not decide when a notification is due. DFIR-IRIS is licensed LGPL-3.0-or-later.
CISO Assistant for GRC
CISO Assistant ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2 and DORA, and runs audits and compliance assessments against them with automatic mapping between frameworks. It is the place where measures, risks, suppliers and evidence can be tracked against the NIS2 framework. Confirm the mapping it applies against the authoritative text and ENISA guidance, because an automatic mapping is a starting point for your own review. CISO Assistant is licensed AGPL-3.0-only.
Where license and edition limits change the evidence
Before relying on an open-source tool for a NIS2 measure, confirm which edition and which content feed you are actually running, because the evidence can shrink without any visible error. Greenbone Community Edition (OpenVAS) runs its scan engine under AGPL-3.0-or-later, but the free Greenbone Community Feed excludes vulnerability tests for enterprise products, which appear only in the paid Greenbone Enterprise Feed. A scan that reports no findings for a commercial product may simply mean no test existed for it. For each enterprise platform in scope of the Article 21 vulnerability handling measure, ask the scanning team to document which tests ran, compare that list against the asset inventory, and record the gap as a risk with a compensating method such as vendor advisories or authenticated patch checks. Whether a paid feed is needed is a decision for the organization, and the cost should come from the vendor's written quote.
Copyleft licenses shape how you may use these tools internally. AGPL-3.0 and GPL-2.0 obligations are triggered mainly by distributing modified software or, for AGPL, by offering a modified version to users over a network. Running Wazuh, Bareos, DFIR-IRIS or CISO Assistant unmodified inside your own infrastructure for your own staff usually raises different questions than shipping a modified build to customers or to a managed service client. Once you customize code, embed components into a product, or host the tool for third parties, the obligations change. Ask counsel to confirm, for each component and version you deploy, whether internal use, modification, hosting for a supplier or a group entity, and any distribution to customers trigger source disclosure or license notices. Record the answers in the supplier and open-source component register that supports the NIS2 supply chain requirements.
Several tools hold features back for paid editions, and those boundaries move over time. CISO Assistant is published under AGPL-3.0-only with a community edition, and eramba Community is governed by a license that is free but not open source, so each has different limits on features, support and redistribution. Do not assume a NIS2 framework listed in a community release carries every workflow, integration or report you will need for a supervisor request. Before you commit the evidence process to a tool, write down the edition features you depend on, obtain each vendor's current edition comparison and license text, and ask for written confirmation of what is included. Treat that confirmation as part of the evidence file, because a supervisor will ask why a control record came from a feature that was not available to you.
What supervisors and auditors will ask each tool to show
Supervisors asking about logging and monitoring usually want to see that security-relevant events are collected, reviewed and acted on, not only stored. ENISA's evidence examples for logging point to records of what was configured, what was collected, and who looked at the results. Wazuh writes matching events to alerts.log and alerts.json, and its dashboard shows the same alerts for review. The files show the rule that fired and the source event, but they do not show that someone triaged them, so the review process needs its own record.
- Alert files:
alerts.jsonholds structured alerts with rule identifiers, so you can show what detections were active over a period. - Ruleset version: Export the rule and decoder configuration in use, since a supervisor may ask which rules covered which systems.
- Collection scope: Keep the agent inventory that shows which hosts send logs and which do not.
- Review records: Link alerts to tickets or cases that show who reviewed them and what was decided.
- Gaps: Record hosts or log sources that were silent or excluded, with the reason and the planned fix.
Before a review, confirm that the alert retention period in your environment covers the time window the supervisor is likely to ask about.
For access controls, supervisors look for evidence that multi-factor authentication applies to the accounts that need it, that privileged access is limited and reviewed, and that exceptions are documented. ENISA's examples for privileged access focus on who holds elevated rights and how that is recorded. Keycloak can enforce two-factor authentication with passkeys, recovery codes and TOTP or HOTP codes, and its one-time password and WebAuthn settings are visible in the realm configuration. Those settings prove what the system was told to require, while login records prove what happened.
- Realm configuration: Export the authentication flow and required-action settings to show which factors are mandatory.
- Role assignments: Keep a dated list of users holding administrative roles and the approval for each.
- Authentication events: Pull login and failed login events for privileged accounts over the review period.
- Recovery code handling: Document how recovery codes are issued, stored and reset, since they can bypass a second factor.
- Exceptions: List accounts that cannot use a given factor, with the compensating control and an expiry date.
Confirm with your identity team which applications sit behind Keycloak and which bypass it, because a supervisor will ask about both.
Supervisors asking about vulnerability handling want to see that scanning happens on a defined schedule, that findings are ranked and tracked to closure, and that the scan coverage is known. Greenbone Community Edition runs tests from the Greenbone Community Feed through the OpenVAS scanner, with gvmd controlling scans. The Community Feed excludes vulnerability tests for enterprise products, which only appear in the paid Greenbone Enterprise Feed. A supervisor may therefore ask whether your coverage gaps have been identified and accepted.
- Scan reports: Export completed scan reports with dates, target lists and feed versions used.
- Target inventory: Show which assets were in scope for each scan, so gaps are visible.
- Feed coverage statement: Document which product families the Community Feed does not test and how you cover them.
- Remediation tickets: Link each high-severity finding to a fix, a risk acceptance or a dated exception.
- Re-scan results: Show that remediated findings no longer appear after the fix.
Ask the vendor or your own team to confirm the current feed terms before relying on Community coverage for enterprise software in your estate.
ENISA's examples for backups focus on whether backups are taken, protected and tested by restoring them. A backup job log alone shows that a job ran, not that data can be recovered. Bareos keeps a SQL catalog of backed-up files and runs backup, restore and verify jobs under a Director. A supervisor is most likely to ask for a restore record, meaning evidence that a selected file or set was brought back from a given point in time and checked.
- Restore job logs: Keep Director job logs for restore runs, with start and end times and the job outcome.
- Catalog entries: Show the catalog records that identify which files and versions were restored.
- Verify job results: Retain verify job outputs that compare stored data with the source.
- Restore test scope: Record which systems were restored, to which target, and who approved the test.
- Failure handling: Document failed restores, the root cause and the retest date.
Confirm your recovery time and recovery point targets with the business owners, since a supervisor will compare test results with those targets.
Supervisors checking cryptography and secrets usually ask who controls keys, how they are rotated, and whether a past version can be proven. ENISA's configuration examples expect that key handling is defined and that changes are traceable. OpenBao's transit secrets engine encrypts and decrypts application data without storing it in the engine, signs and verifies data, and supports versioned keys with rotation. The key version history is the record that shows which key version protected which data and when it changed.
- Key version history: Export the version list for each transit key, with creation and rotation dates.
- Rotation policy: Keep the approved rotation interval and the record of each rotation.
- Access policies: Document which identities may encrypt, decrypt or manage each key.
- Audit device logs: Retain logs that show key use and administrative changes.
- Key ceremony records: For root material and unseal handling, record who was present and where the material is held.
Verify with your security team how the cryptography policy names approved algorithms and key lengths, because the key records are only useful if they match that policy.
For incident handling, a supervisor wants to see a complete and orderly account of what happened, what was decided and when each reporting step occurred. DFIR-IRIS keeps each case as one record of assets, indicators of compromise, tasks and evidence, with a full audit trail. It triages alerts from SIEM, EDR and REST sources into cases and builds a timeline. Evidence entries record SHA-256 hashes and chain of custody, which supports the claim that evidence was not altered after collection.
- Case audit trail: Export the change history for each case, showing who edited what and when.
- Consolidated timeline: Keep the investigation timeline as the primary narrative for the reporting clock.
- Evidence hashes: Retain the SHA-256 values and custody entries for every logged item.
- Task records: Link response tasks to owners and completion dates.
- Generated reports: Keep the report version sent to the authority, alongside the case data it came from.
Check with your legal and incident response leads how each case maps to the early warning, notification and final report deadlines, since the tool records the work but the reporting decision belongs to your organization.
How a tool stack is typically rolled out
The rollout moves from deciding which NIS2 measures and assets the stack covers, to a running platform in the client's own infrastructure, to a documented test cycle that produces the first evidence an assessor or supervisor can read. Each phase closes with a named output that the next phase depends on.
Scope the measures and assets
The organization, with its implementation partner, lists the in-scope systems, the Article 21(2) measures each tool would support, and the owner of each measure. The output is a scope register that maps each tool to a measure, a set of assets and a named control owner. The step is done when management or the accountable security lead has approved the register and no in-scope system is left without an owner.
Deploy in the client's infrastructure
The partner installs the selected platforms in the client's own cloud accounts, data centers or air-gapped network, following the client's network segmentation and change process. Hardening, access controls for the administrators and backup configuration are set at this stage. The output is a documented deployment record with versions, hosts, administrator accounts and network paths. It is complete when the platforms run in the agreed environment and the record matches what was built.
Configure rules and policies
The team sets the detection rules, scan schedules, authentication policies, backup jobs and key management settings that match the scope register and the organization's own policies. Default rulesets are reviewed and custom rules are added where the organization's systems need them. The output is a configuration baseline stored under change control. The step closes when a reviewer can trace each configured setting to a measure and a policy.
Connect data sources
Log sources, identity providers, scanning targets, backup clients and case intake channels are connected to the platforms one at a time. Each connection is tested to confirm that events, scan results and backup catalogs arrive and that timestamps are consistent. The output is a data source inventory listing each feed, its owner and its expected content. The step is done when every in-scope source appears in the inventory and sends data that the platforms can read.
Run a test cycle for first evidence
The team runs a controlled cycle that exercises the stack: a scheduled scan, a test authentication event, a restore from backup, a simulated alert triaged into a case and a review of the resulting audit trail. Results are captured as they are produced, not reconstructed later. The output is the first set of evidence records, with dates, operators and results. The cycle is complete when each measure in scope has at least one record that shows the control working, and any gaps are logged as findings.
Document ownership and review cadence
The organization records who owns each tool, each measure and each evidence stream, and sets how often configurations, scan results and test records are reviewed and by whom. Findings from the test cycle are assigned to owners with a tracked remediation path. The output is an ownership matrix and a review calendar that the organization maintains. The step is done when management has accepted the matrix and the calendar is in use for the next review.
What must be in place before the tools produce usable evidence
A logging server, a scanner or a backup director only produces evidence a supervisor can use when someone owns the measure, knows what the assets are, and can show the records were kept under a set rhythm. The six items below are the governance groundwork that connects the tools to the Article 21 measures.
Named owners for each measure
Every Article 21 measure needs one accountable person who decides how the tool is configured, who reviews its output and who signs off exceptions. Ask for a written owner table that lists the tool, the measure it supports and the deputy who covers absence. Check that owners can explain the configuration without reading the vendor manual, because a supervisor will ask them directly. A tool with no named owner typically produces alerts or scan reports that nobody can show were acted on.
Documented asset inventory
Scanners, log collectors, backup jobs and MFA policies only cover what they know about. Maintain an inventory of systems, applications, network segments and cloud accounts with an owner, a classification and an environment label for each entry. Check the inventory against the scan target list and the backup catalog every review cycle, and record the differences. Gaps found this way are often the first finding an assessor raises.
Log source list
Detection is only as complete as the list of sources sending events to it. Write down each source, the events it must produce, the agent or forwarder used, and the person responsible for its health. Confirm each source actually reports by sampling recent events, and record sources that went silent. Keep the list with the detection rules so a reviewer can see what is monitored and what is not.
Retention rules
Set how long logs, alerts, scan results, backup sets, case records and access reviews are kept, and what triggers deletion or archive. Retention periods must be set by the organization against its legal, contractual and incident needs, and the chosen values should be confirmed with counsel. Check that the tools enforce these settings, for example in index lifecycle or backup pruning, instead of relying on manual clean-up. Otherwise evidence disappears on a schedule nobody approved.
Change records
Configuration changes to MFA policies, scan schedules, detection rules, backup jobs and key settings need a ticket, an approver and a date. Store these records in the same system as the change or link them from it, so each change can be traced to a decision. Test a sample by picking a recent change in a tool and asking for the approval it came from. Changes without records are hard to defend when a supervisor asks why a control behaved differently.
Documented review cadence
Each tool output needs a fixed review rhythm, such as daily alert triage, periodic scan result review, backup restore tests and access recertification, with the reviewer and the record of each review named. Write the cadence into the policy set and confirm that the reviews happened by checking the dated sign-offs. A cadence that exists only on paper is treated by assessors as no cadence at all, so sample the last few cycles before any inspection.
Who owns the controls, who deploys the tools and who issues assurance
This table separates three roles: the organization that owns its NIS2 measures and risk decisions, the implementation partner that deploys and documents the tools, and the national competent authority or independent assessor that inspects and judges. Read each row as a question of who decides, who builds and who signs off. DeployOpen prepares systems and evidence, but it does not issue reports, attestations or certificates.
| Area | The organization | Implementation partner such as DeployOpen | National authority or independent assessor |
|---|---|---|---|
| Risk decisions | Owns the risk assessment, proportionality choices, treatment plans and acceptance of residual risk | Gathers asset and configuration data and drafts options for management to decide | Reviews whether the decisions were documented and reasonable |
| Measures and policies | Approves the Article 21 measures and the topic-specific policies | Configures tools such as Wazuh, Keycloak, Bareos and OpenBao to support the measures | Checks that measures are in place and operating in practice |
| Deployment | Provides cloud accounts, data center or air-gapped environments and accepts changes | Plans, installs, integrates, hardens, backs up and upgrades the platforms inside the client's infrastructure | Does not deploy; may run security scans or request information |
| Evidence | Owns and retains evidence, and decides what is accepted as sufficient | Documents configurations, runbooks and test records, and prepares exports for review | Requests and evaluates evidence during inspection or audit |
| Testing | Commissions tests, acts on findings and tracks corrective action | Runs or coordinates security testing within a written scope | May review test results as part of independent assurance |
| Incident reporting | Decides and submits reports to the competent authority and CSIRT under Article 23 | Helps prepare the response process, case records and report drafts in DFIR-IRIS or similar tools | Receives reports and may follow up on significant incidents |
| Assurance and certification | Commissions independent review where needed and presents results to management | Does not issue reports, attestations or certificates | Issues findings, orders or fines; independent auditors issue audit reports where engaged |
| Contract basis | Signs a fixed-scope agreement with defined deliverables | Delivers against the written scope, with ongoing support available as a retainer | Acts under national law; NIS2 creates no certificate of compliance |
Questions to ask before choosing an implementation partner
Open-source tools for NIS2 measures produce evidence only when they are deployed, configured and documented correctly inside your environment. The questions below help you test whether a prospective partner can do that work, explain its limits and put the scope in writing before any system changes.
Hands-on experience with the named tools
Ask which of the tools in your shortlist, such as Wazuh, Keycloak, Greenbone, Bareos, OpenBao, DFIR-IRIS or CISO Assistant, the partner has deployed, upgraded and restored in production-like environments. Ask for a walkthrough of how they would size a Wazuh deployment and where log retention is configured. Vague answers about open-source tooling in general are a warning sign.
License and edition review
Ask the partner to show, in writing, how it checks the license of each component and the edition limits that apply. For example, the free Greenbone Community Feed excludes vulnerability tests for enterprise products, and CISO Assistant and eramba differ in what their free editions include. A good partner will list these gaps before design begins, not after the first audit request.
Written fixed scope
Ask for a scope document that names the systems in and out of scope, the tools to be deployed, the measures each tool supports, the deliverables and the acceptance criteria. Confirm how changes are priced and approved. Most engagements are fixed-scope, so the document should exist before work starts, and it should say what the organization must provide, such as access, staff time and approvals.
Evidence handover format
Ask exactly what the partner hands over at the end: configuration exports, rule sets, backup restore test records, access review outputs, case records and the procedures that generated them. Confirm the format, the storage location and who owns the files afterward. Evidence that only the partner can reproduce is of little use when a supervisor asks for it.
Independent testing of controls
Ask whether the partner tests the controls it configured, and whether that testing is performed by a separate team or by the same people who built them. Ask what the test covers, such as restore tests for backups, MFA enforcement checks in Keycloak and vulnerability scan coverage. Confirm that independent review and audit remain the role of your external auditor or competent authority.
What the partner does not do
Ask the partner to state, in writing, what it will not provide. A preparer of systems and evidence does not issue audit reports, attestations or certificates, and it does not make the management body's decisions on risk acceptance or accountability. Confirm that your organization keeps ownership of its controls, policies and reporting obligations to the national authority.
Questions buyers ask about open-source NIS2 tooling
Are open-source tools enough to meet NIS2?
No single tool, open source or not, makes an entity compliant. NIS2 requires the organization to run risk management under Article 21, with documented policies, management approval and evidence that the measures work in practice. Open-source tools cover several technical measures well, including log analysis and detection, multi-factor authentication, vulnerability scanning, backups, secrets management and case handling. They produce records that a supervisor can inspect. What they do not do is decide scope, approve policies, accept residual risk or prove that controls operate. Those remain management and process tasks, and the tools should be mapped to the measures they support before anyone assumes gaps are closed.
Does a self-hosted open-source stack reduce NIS2 costs?
It can reduce license spending, but total cost depends on other drivers. Software licenses are often the smallest line item. The larger costs are internal engineering time to install, configure, harden and upgrade each platform, storage and compute inside your own environment, monitoring staff who review alerts, and the time spent producing evidence. Costs rise with the number of log sources, users, assets and the number of Member States or entities covered. Costs fall when tools share one identity provider, one logging pipeline and one GRC record. Ask any partner to separate one-time setup from recurring operation, and to state which licenses, feeds or paid editions are assumed in the quote.
What do our internal staff need to run these tools?
Your staff must own the decisions and be able to operate the platforms after handover. Management needs to approve the risk treatment and policies. Security staff need to define detection rules, triage alerts, approve access changes and review evidence. Platform engineers need to run upgrades, backups, certificate rotation and capacity planning. Someone must also hold the audit trail for incidents and supplier reviews. An implementation partner can install, document and train, but it cannot replace these roles. Before signing, confirm named internal owners for each tool, the on-call arrangements and the skills your team will need for upgrades.
Do open-source NIS2 tools certify compliance?
No. NIS2 creates no certificate of compliance. National competent authorities oversee entities through inspections, security audits, scans, information requests and fines. A tool, a dashboard or a framework mapping does not issue a report or certificate. Only independent auditors or certification bodies issue attestations, and where a national authority requires evidence, it reviews what your organization can show. Treat tools as sources of evidence, such as alert records, scan results, MFA settings and backup catalogs. Pair them with approved policies and documented decisions, and check what your competent authority expects in your Member State.
What licenses should we check before internal use?
Check the license of each tool against how you will use it, not just whether the source is public. Wazuh is GPL-2.0-only, Keycloak is Apache-2.0, Greenbone Community Edition is AGPL-3.0-or-later, Bareos is AGPL-3.0-only, OpenBao is MPL-2.0, DFIR-IRIS is LGPL-3.0-or-later and CISO Assistant is AGPL-3.0-only. Internal use generally does not trigger the same obligations as distributing modified software, but AGPL terms can apply when you offer modified versions over a network. Have legal counsel review your deployment model, especially if you ship modified code to customers or subsidiaries. Confirm the current license text in each project's repository before you build on it.
Which edition limits should we check first?
Edition limits decide whether a tool produces the evidence you need. The main example is Greenbone Community Edition, where the free Community Feed excludes vulnerability tests for enterprise products that are only in the paid Greenbone Enterprise Feed. If your estate runs those products, your scans may have blind spots. For other tools, check which features are held back for paid editions, such as SSO integrations, support, extra user management or reporting. For CISO Assistant and eramba, confirm which framework content, audit features and workflow features each edition includes. Write the edition, feed and version you tested into your evidence record.
How do we confirm a tool's current feature set?
Test the feature against your own environment and use the vendor's current documentation as the reference. Read each project's latest documentation and release notes, check the license file in the repository, and confirm feed or update channels. For example, the Wazuh ruleset documentation describes its built-in rules and decoders, and the Keycloak administration guide describes its MFA options. Then run a small proof of concept with your log sources, identity setup or scan targets, and record the output. Feature sets change between releases, so repeat the check before each assessment and keep the version number with the evidence.
What should we ask an implementation partner in a quote?
Ask for a written scope that lists each tool, version, edition, feed and license, along with the NIS2 measures each one supports. Ask which deliverables you receive, such as configuration baselines, runbooks, evidence procedures and training records, and which items remain your responsibility. Ask how one-time setup is priced separately from recurring support, upgrades and testing. Confirm who owns the systems and data after handover, what happens if scope changes, and how acceptance is tested. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms in your own infrastructure, and most engagements are fixed-scope, but it does not issue audit reports or certificates. Ask your independent assessor to confirm the evidence is acceptable.
Primary sources to read before deciding
Before you choose any tool, read the primary text that sets the obligations. Start with Directive (EU) 2022/2555 on EUR-Lex, because Article 21 defines the measures you must evidence, and your national transposition law determines how your supervisor applies them. Then read ENISA's NIS2 technical implementation guidance. It is non-binding, but it gives the evidence examples supervisors commonly reference, so compare each tool's output against those examples rather than against the marketing claims on a vendor page.
Next, read the documentation for the components you plan to rely on, focusing on what each one can and cannot prove. The Wazuh ruleset documentation tells you which events generate alerts and how custom rules are written, which matters for the detection evidence you will show. The Keycloak Server Administration Guide shows the one-time password and WebAuthn settings you need to document for MFA. The Greenbone background documentation explains the Community Feed boundary: confirm with Greenbone which vulnerability tests your products need, because enterprise product tests sit only in the paid feed. The Bareos documentation covers restore and verify jobs, which is where backup evidence comes from, and the OpenBao transit secrets engine documentation covers key versioning and rotation for the cryptography policy.
For incident handling, read the DFIR-IRIS documentation to confirm how case records, audit trails and SHA-256 evidence logging work in your deployment, since these determine what you can show a supervisor after an incident. Finally, read the CISO Assistant README and check its license against your own use, because the AGPL terms and the features reserved for paid editions affect how you run the GRC record. Write down which sources you relied on for each control. That list becomes the starting point for your evidence index and for any scoping conversation with an implementation partner or auditor.
How DeployOpen scopes, deploys and prepares NIS2 evidence
DeployOpen plans, implements, hardens and documents self-hosted open-source tools inside your own infrastructure, so the logging, authentication, vulnerability, backup, secrets and case-handling records that support NIS2 measures are produced by systems you control. We prepare the systems and evidence; your organization owns its controls, and only an independent auditor or competent authority can judge compliance.
How we scope
- Agree in writing which NIS2 measures, tools and systems fall inside the engagement before any work starts.
- Confirm which cloud accounts, data centers or air-gapped networks will host each tool and who holds administrative access.
- Record the license and edition of every tool, including feature limits such as paid vulnerability feeds, before scope is fixed.
How we build
- Deploy and configure each tool in your environment, with logging, alerting and access settings mapped to the measures in scope.
- Harden the installations and test that logs, alerts, backups and key operations actually produce the records you expect.
- Integrate tools with your identity provider, ticketing and reporting paths so evidence is captured as work happens.
How we hand over
- Document configurations, runbooks and an evidence map showing which record supports which measure and where it is stored.
- Walk your staff through routine checks, retention settings and how to export evidence for an auditor or supervisor.
- Deliver the written scope outcomes so your compliance lead can review what was built against the agreed deliverables.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after the fixed-scope work is complete.
- Keep configurations current as tool versions change, and review evidence outputs when your NIS2 program or scope changes.
- Confirm with your own assessor or national authority which evidence they accept, since DeployOpen does not issue audit reports or certificates.
