What NIS2 point 6.3 requires for configuration management
NIS2 point 6.3 requires an in-scope digital infrastructure or digital provider entity to set secure configurations for its hardware, software, services and networks, write them down, enforce them and keep watching them. The point sits within the Implementing Regulation (EU) 2024/2690 annex and is tested as a continuing cycle, not a one-time hardening project. Point 6.3.2 separates two situations. Newly installed systems need a secure configuration and the tools to enforce it before they go live. Systems already in operation need the same baseline enforced across their whole working life, including the systems nobody has touched in years. Point 6.3.3 adds review triggers: configurations must be reviewed at planned intervals and after significant incidents or significant changes to operations or risks. Your first decision is which intervals and triggers you will commit to in writing, because an assessor will hold you to the schedule you set.
Configuration drift is usually the hard part. A baseline that is correct on the day it is applied starts to diverge as patches land, administrators make emergency fixes, new services are switched on, and cloud or virtual resources are created outside the normal build process. The assessor's question is rarely whether a baseline exists. It is whether the live estate still matches it, and whether an unexpected change would be noticed. Work through three checks: confirm the inventory of systems covered by each baseline, sample production hosts against it, and test whether a deliberate misconfiguration generates an alert. Confirm with your own environment and your national competent authority how much evidence of this kind they expect in practice.
Changes that alter configuration also fall under the change management requirements of point 6.4, so every deviation from a baseline should pass through a documented change record, with risk-based testing and approval before implementation. Approved exceptions need compensating measures and an end date, otherwise they become undocumented drift. Open-source tooling can produce much of this evidence. Wazuh's Security Configuration Assessment checks endpoints against YAML policies, and Fleet policies answer yes or no questions about device state through osquery. GLPI and Zammad can hold the change and exception records. Whether each tool covers your platforms, operating systems and cloud resources is something to verify in a proof of concept before you commit to it.
Which systems and teams fall under configuration management scope
Point 6.3 applies to every hardware, software, service and network element the entity runs, so the first work is deciding where the boundary sits. The cards below cover the scoping decisions that change effort most, and the ownership split between teams that set configurations and teams that approve changes under point 6.4.
Hardware and network devices
Physical servers, firewalls, switches, routers and load balancers all carry configurations that point 6.3 covers. Start from the asset inventory, then confirm each device has a recorded baseline, including management interfaces, default credentials removed and unused services disabled. Ask whether out-of-band management consoles and spare hardware sitting in storage are included, since these are common gaps.
Endpoints and operating systems
Workstations, laptops and mobile devices are often managed by a different team than servers, which creates gaps in the baseline. Confirm which operating system builds are approved, how the baseline is enforced on enrolled devices, and how unmanaged or bring-your-own devices are handled before they reach corporate systems. Each endpoint class needs a named baseline owner.
Cloud and virtual resources
Virtual machines, containers, managed databases, storage buckets and cloud IAM policies change through automation, so configurations drift quickly. Scope should cover both the infrastructure as code templates and the live resources they produce. Check whether resources created outside the pipeline, such as console changes or test accounts, are detected and brought back under review.
Software and third-party managed components
Applications, middleware, open-source components and services run by managed providers still fall within the entity's obligations when they affect its systems. Decide which configuration settings the entity controls itself and which the provider controls, then record that split in contracts and the baseline. Ask providers for evidence of their own configuration checks rather than assuming it exists.
Entity type and depth of work
The implementing regulation sets requirements for the listed entity types, such as cloud, data center, managed service and online platform providers, and the depth expected follows from the entity's risk profile and services. An entity operating a single data center and one managed service differs from a group running many environments. Confirm with the competent authority or a qualified adviser which entity category applies before setting the scope.
Ownership: configuration versus change approval
Platform and infrastructure teams usually own the secure configurations themselves, while a change board or risk owner approves deviations under point 6.4. Keeping these roles separate prevents the people who make a change from also approving it. Write the split into a RACI table, and confirm that security and the management body see exceptions and their compensating measures.
How secure configurations drift after go-live
A build that passed review on the day it went live can fail point 6.3 within weeks, and the reason is usually ordinary operations rather than neglect. Point 6.3.2 requires secure configurations and the tools that enforce them over the system's whole life, so the drift sources an organization must plan for are the ones it already has: manual hotfixes applied over SSH to fix an outage, cloud console edits made directly in the provider portal to open a port or widen a security group, and vendor defaults on newly installed devices such as routers, hypervisors or appliances that ship with default credentials, open management services or logging turned off. Each of these changes the running state without touching the baseline document, so the documented configuration and the real one start to diverge.
Emergency changes after an incident deserve their own plan, because they are the most likely to be accepted without review and the most likely to stay in place. Point 6.3.3 requires configurations to be reviewed after significant incidents and after significant changes, so the incident record should trigger a configuration review as a standard step, not as an optional lessons-learned item. Unmanaged exceptions are the quiet fourth source: a waiver granted for a legacy application that is never revisited. Point 6.4 expects every configuration change, including an emergency one, to be documented and assessed on a risk basis, so each drift event should either become a logged change with an approver or be reverted. Ask your team to confirm, for each category above, which alert or scan would reveal it, who owns the decision to accept or revert, and how the review date is recorded for every approved exception.
How to implement configuration management step by step
This sequence moves from knowing what you run to proving it stays configured as intended. Each step produces a record that an assessor can test against point 6.3 of the Annex to Implementing Regulation 2024/2690.
Inventory the in-scope assets
Start by listing every hardware device, operating system, application, cloud service and network device that supports the services in scope for NIS2. The operations or IT team owns this list, and it should draw from the asset inventory point 12.4 requires, so the two records agree. Record the owner, location, function and classification of each asset. The step is done when someone can point to an asset without a documented owner and confirm that no in-scope system is missing from the list.
Define secure baselines per asset class
Group the inventory into asset classes such as Windows servers, Linux hosts, network firewalls, container hosts and SaaS tenants. For each class, write a baseline configuration that sets out the security settings you require, drawing on vendor hardening guides or widely used benchmarks such as those published by CIS. Security architecture or platform engineering approves each baseline, and the approval date and version go into the document. The output is a baseline document per asset class that a reviewer can compare against a live system.
Set enforcement for new and existing systems
Build the processes and tools that apply the baseline when a system is installed and keep it in place afterward. For new systems, use hardened images, infrastructure-as-code templates or provisioning checklists, and block deployment until the baseline is met. For systems already running, use a scanner or endpoint tool to check the configuration on a schedule. Confirm with each tool vendor which checks it supports, because capabilities differ between products. The output is a documented enforcement procedure and a tested example of a non-compliant system being detected.
Establish the change and exception workflow
Route every configuration change through the change management procedure required by point 6.4, with a documented request, a risk-based test and an approval before implementation. Where a system cannot meet the baseline, record an approved exception with a named owner, an expiry review and compensating measures. A ticketing or change management tool can hold these records, and the change owner closes each ticket only after the post-change check passes. The output is a change record and an exception register that link each deviation to its approval.
Schedule reviews and trigger-based reviews
Set a planned review interval for each baseline, and record the interval in the baseline document so the requirement in point 6.3.3 is visible. Add trigger-based reviews that run after a significant incident, after a significant change to operations or after a change in risk. The security lead owns the calendar, and each review ends with a decision to keep, update or retire each baseline. The output is a review log with dates, participants and outcomes, which shows the reviews happened on the planned cycle.
Run continuous monitoring and drift detection
Monitor configurations between reviews so that unexpected changes surface quickly. Compare live settings with the approved baseline, and alert on drift or on any change that does not match an approved ticket. Investigate each alert, then either correct the system or raise an exception. Confirm which alerts your tools can send and how they reach the on-call team before you rely on them. The output is a drift report and a set of alert records, and each unexplained deviation must end with a documented correction or an approved exception.
How an assessor tests configuration management
This table sets out each step an assessor takes to test point 6.3, the evidence requested at each step, and the findings that most often stop an entity from passing. Read it as a test plan: the first column names the check, and the other columns show what the entity should have ready and where the test usually fails.
| Assessor step | Evidence requested | Common finding |
|---|---|---|
| Confirm baselines exist and cover in-scope assets | Documented secure baseline configurations for each system class, mapped to the asset inventory of in-scope hardware, software, services and network devices | Baselines exist for servers but not for network devices, cloud services or endpoints added later |
| Sample systems and compare live configuration to baseline | Current configuration exports or scan results for a sample of systems, with the baseline each one is measured against and the date of the comparison | Production hosts drift from the baseline, and no one can show which deviations were approved |
| Test newly installed systems | Build or provisioning records showing that secure configuration is applied before a new system enters production | New systems go live with vendor default settings and are configured manually after deployment |
| Review approved exceptions and compensating measures | Exception register with the business reason, risk owner approval, expiry date and the compensating control in place | Exceptions are granted verbally, never expire, or have no compensating measure recorded |
| Check review records against planned intervals and triggers | Review calendar and completed review records, plus records of reviews after significant incidents or significant changes to operations or risks | Reviews are planned but not performed, or no review followed a recent incident or major change |
| Trace configuration changes through point 6.4 | Change tickets with risk assessment, testing evidence, approval and before and after configuration snapshots | Configuration changes are made directly on systems without a change record |
| Check alerting on unexpected changes | Alert rules or logs showing detection of unauthorized configuration changes and the response taken | Changes are never detected, or alerts are generated but not reviewed |
Which evidence shows secure configurations are enforced
ENISA's June 2025 guidance names four kinds of evidence that show a configuration regime is documented, controlled and watched over time. Each card below covers one artifact, what it proves for point 6.3, how to keep it current between assessments, and who signs it off.
Documented secure baseline configurations
The baseline is the written security standard for each class of hardware, software, service and network, such as a hardened operating system image or a firewall policy. It shows the entity has decided what "secure" means before a system goes live. Keep each baseline versioned with its owner and review date, and check that the live estate still matches the approved text. Sign-off: the system owner proposes, and the security function approves.
Approved exceptions with compensating measures
An exception records a place where a system cannot meet its baseline, for example a legacy application that needs an unsupported protocol. The record should name the deviation, the business reason, the compensating measures such as network isolation or extra monitoring, and an expiry date. Review open exceptions at each baseline review so that expired deviations do not quietly become permanent. Sign-off: the risk owner accepts the residual risk in writing.
Configuration snapshots before and after changes
A snapshot captures the configuration state of a system immediately before and after an approved change, so the team can show what changed and confirm the result matched the plan. Pair each snapshot with the change record it belongs to, which is where point 6.4 requires documented, risk-based testing and assessment. Confirm that snapshots are stored outside the system they describe, so they remain available if that system is compromised. Sign-off: the change approver checks the after state against the plan.
Alerts on unexpected configuration changes
Drift alerts show that the enforced state is being monitored between audits, not only at the time of a project. Wazuh Security Configuration Assessment checks monitored endpoints against YAML policies, mostly based on CIS benchmarks, and recommends remediation. Fleet policies run yes or no osquery checks and show which devices pass or fail each one. Confirm which alerts reach a person, how quickly they are triaged, and how each alert links to a change record or an incident. Sign-off: the operations lead reviews alert trends and closes each finding.
Change records that tie the evidence together
A change record in GLPI or Zammad links the baseline, the exception, the snapshots and the alerts to one approved request. GLPI's Assistance module supports tickets, problems and changes following ITIL practices, which gives auditors a single trail from request to outcome. Check that every configuration change has a record and that no record closes without the post-change snapshot attached. Sign-off: the change manager approves the record before implementation.
Which open-source tools produce configuration evidence
Wazuh's Security Configuration Assessment compares monitored endpoints against a set of configuration policies and reports which checks pass or fail. The policies are written in YAML, are shipped mostly based on CIS benchmarks, and can be extended with custom policies that match the entity's own documented secure baselines. The module checks files, directories, registry keys and running processes, and it recommends remediation for failed checks. The output is a repeatable record of the baseline an endpoint was measured against, which supports the requirement to monitor configurations over time.
- Baseline mapping: Each policy is a set of checks, so the entity can show which documented baseline each policy implements.
- Custom policies: Organization-specific settings can be added where the shipped policies do not match the approved baseline.
- Scan history: Repeated scans show whether an endpoint drifted from its baseline between review cycles.
- Remediation advice: Failed checks come with recommended fixes that feed the change process.
- Licensing: Wazuh is released under GPL-2.0-only, so confirm that this license fits the entity's distribution and internal use model.
Confirm which policy files apply to each operating system in your environment and whether your approved baseline matches the shipped content before you rely on the results.
Fleet expresses configuration checks as policies, where each policy is a yes or no question asked of a device as an osquery query. The policies page shows which devices in each fleet pass or fail each policy. This gives a current view of the configuration state across devices, which is useful for showing that secure configurations are enforced on systems in operation, not only documented. Results change as devices change, so the evidence reflects the state at the time it was captured.
- Yes or no policies: Each policy has a single, testable question, which makes the pass or fail result easy to explain to an assessor.
- Per-device status: The view identifies the specific devices that fail a policy, so remediation can be tracked to individual systems.
- Snapshots: Exporting results at planned review points gives dated evidence for the review requirement.
- Coverage gaps: Devices that are not enrolled or do not report cannot be assessed, so the entity should compare enrollment against its asset inventory.
- Licensing: Fleet is released under MIT. Confirm the agent deployment and data handling model against the entity's own policies.
Confirm that the policies you write match your documented baselines and that enrollment covers every system in scope.
Configuration changes must be documented and, based on risk, tested and assessed before implementation. GLPI's Assistance module supports this with tickets, problems and changes that follow ITIL practices, along with plannings, statistics, recurrent ticket tracking and a Kanban view. Zammad, a web-based helpdesk, consolidates requests arriving by email, chat, telephone and social media into one ticket system. It is better suited to handling incoming requests and their communication than to recording formal change approvals, so the two tools often serve different parts of the record.
- Change records: GLPI change objects can hold the requested change, the risk assessment, approvals and the implementation outcome.
- Exception tracking: Approved deviations from a baseline can be recorded with their compensating measures and review dates.
- Request intake: Zammad keeps the communication trail for requests that lead to configuration work.
- Recurring issues: Recurrent ticket statistics help show repeated drift that points to a baseline problem.
- Licensing: GLPI is GPL-3.0-or-later and Zammad is AGPL-3.0-only. Confirm the license obligations for any modifications and hosting.
Confirm that approval workflows in your chosen tool match the change management procedure your organization has documented.
What meeting configuration management costs in money and effort
Configuration management under point 6.3 of the Annex to Implementing Regulation 2024/2690 has a modest licensing line and a large labor line. The open-source tools that can scan endpoints against policies, track changes and log tickets, such as Wazuh, Fleet, GLPI and Zammad, usually carry no license fee, but the organization still pays for the servers or cloud capacity that run them, for the engineering that installs and integrates them, and for the staff who maintain them. Ask any partner quoting this work to separate hosting, licensing (if any), implementation and run costs so you can see which lines recur.
The largest one-time cost is building secure baseline configurations for each asset class: servers, workstations, network devices, cloud accounts, databases and the key services. Each baseline needs an owner, a documented rationale, a version, and an agreed set of exceptions with compensating measures. The effort rises with the number of distinct asset classes, the diversity of operating systems and vendors, and how much legacy estate must be documented before it can be enforced. Recurring costs follow from the reviews that point 6.3.3 requires at planned intervals and after significant incidents or changes, from keeping snapshots and drift alerts current, and from handling the exceptions that accumulate over time.
External review is optional but worth pricing separately. An independent configuration check or penetration-style test of hardened systems is a scoped engagement, and its cost depends on the number of hosts, environments and depth of testing agreed in writing. Authority and auditor time is driven by how well evidence is organized: a supervisor or assessor who can trace a baseline to its approval, a change record and a drift report spends less time on requests. In any quote, ask for line items for each one-time and recurring component, the assumed number of asset classes, the review cadence, who keeps the evidence current after handover, and the exact deliverables that will be accepted as evidence.
Where configuration management usually falls short
Most organizations have a hardening standard somewhere, yet point 6.3 of the Annex to Implementing Regulation (EU) 2024/2690 asks for more: configurations that are enforced, exceptions that are recorded, and reviews that respond to change. The gaps below are where supervisors most often find the distance between a document and a working control.
Baselines written but never enforced
A hardening guide sitting in a wiki does not configure anything. Point 6.3.2 expects processes and tools that enforce secure configurations on new systems and on systems in operation. Check whether each baseline maps to a scanning policy or a configuration management tool, and whether a sample of production hosts actually matches it. Wazuh Security Configuration Assessment can compare endpoints against YAML policies, which gives you a measurable test rather than a claim.
No exception register
Teams often disable a rule to keep a legacy application running and never record why. ENISA's June 2025 guidance treats approved exceptions with compensating measures as evidence, so every deviation from a baseline needs an owner, a justification, an expiry date and a compensating control. Ask for the register before the assessor does. An exception with no end date is usually a baseline that was quietly abandoned.
Snapshots missing after changes
Point 6.4 requires changes to be documented and tested according to risk, and point 6.3 expects the configuration state to be traceable. If a change ticket closes without a before and after record of the configuration, you cannot prove what changed or roll it back. Check that changes in your ticketing system link to configuration snapshots taken before and after implementation, and sample recent changes to confirm the link exists.
Cloud and endpoint estates left out of scope
Configuration reviews often cover the data center and miss cloud accounts, SaaS administration consoles, container platforms and laptops. Point 6.3 applies to hardware, software, services and networks, so each of those estates needs a named owner and a policy. Compare the scope of your scanning and device policies against your asset inventory. Any system in the inventory with no configuration check is a finding waiting to be written.
Reviews not triggered by incidents
Point 6.3.3 requires configurations to be reviewed after significant incidents and significant changes to operations or risks, not only at planned intervals. Many teams close an incident with a root cause and a patch but never revisit the configurations that allowed it. Add a mandatory configuration review step to the incident closure checklist and record its outcome, including the decision to make no change, so the review is visible in the file.
Alerts with no owner
A policy that fails on a device is only useful if someone is accountable for it. Fleet policies show which devices pass or fail each query, and Wazuh raises findings for misconfigurations, yet failing results often accumulate in a dashboard that nobody triages. For each policy, name the team that receives the failure, the response time they are expected to meet and the ticket type it creates. Sample a few old failures and check whether any were closed with a documented outcome.
Who owns configuration management, who helps, and who audits
The organization owns its configuration management. Point 6.3 of the Annex to Implementing Regulation (EU) 2024/2690 requires the entity to establish, document, implement and monitor configurations, including security configurations, of its hardware, software, services and networks. Those decisions belong to the entity: management and the security function approve the secure baselines, decide which deviations are acceptable, and remain accountable when a system drifts from its approved state. Outsourcing does not transfer that accountability.
- Baseline approval: Named owners sign off on the secure configuration for each system class before it goes live.
- Exception decisions: Approved exceptions, with compensating measures and an expiry date, are recorded by the owner, not by the partner who notices the deviation.
- Review schedule: The entity sets the planned review intervals and triggers for review after significant incidents or significant changes, as point 6.3.3 requires.
- Change accountability: Configuration changes run through the change procedures of point 6.4, so the entity decides which changes are tested and assessed before implementation.
- Asset inputs: The entity keeps the inventory that tells every tool which systems exist and which baseline applies.
Before you engage anyone, confirm internally who signs each baseline and who can accept a deviation.
An implementation partner helps the organization put configuration management into practice. DeployOpen, for example, plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, and it prepares systems and evidence for compliance assessments. A partner can build the tooling and the evidence pipeline, but it does not decide the entity's baselines and it does not judge its own work as an assessor would.
- Tooling setup: Configuring scanners and policy engines, such as Wazuh Security Configuration Assessment with CIS-based or custom YAML policies, on the client's endpoints.
- Baseline drafting: Drafting secure baseline configurations for the client's owners to review, test and approve.
- Monitoring and alerts: Setting up alerts on unexpected configuration changes and dashboards of passing and failing policies, for example with Fleet policies.
- Ticketing and change records: Configuring GLPI or Zammad so that changes, exceptions and remediation tasks have a traceable record.
- Evidence preparation: Collecting snapshots before and after changes and organizing evidence the entity can present. Evidence the partner prepares must still be reviewed and owned by the entity.
Ask any partner to state in writing which decisions stay with your team and which artifacts they will hand over.
The independent party tests and reports. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines under Articles 32 to 34. Where an entity uses an independent audit or certification body for another framework, that body issues its own report or certificate. In either case, the tester is independent of the entity and of the partner that built the controls.
- Sampling: An assessor selects systems, checks their configuration against the documented baseline, and looks for drift.
- Exception review: The assessor checks whether each exception was approved, time-limited and backed by compensating measures.
- Change testing: The assessor traces a sample of changes through the point 6.4 process and compares before and after states.
- Findings: Findings are issued by the assessor, and the entity responds with its own corrective actions.
- Independence limit: An assessor may advise on what evidence exists, but it cannot write the baselines or produce the evidence it will later test.
Confirm with your supervisor or auditor which evidence formats and sampling they expect before the engagement starts.
Questions buyers ask about configuration management under NIS2
Can we do NIS2 configuration management in-house?
Yes, in most organizations the work can be done in-house, but the scope decides how much capacity it needs. Point 6.3 asks you to establish, document, implement and monitor secure configurations for hardware, software, services and networks, and the organization owns that obligation either way. Internal teams usually handle the policy and the baseline decisions. The harder part is the sustained work: building hardened baselines for each system type, enforcing them on new builds, and keeping evidence current across the operating life of each system. Ask yourself whether your team has time for that routine work alongside its current duties, and whether it can document decisions well enough for a supervisor to follow them.
How long does configuration management work take to set up?
Duration depends on the number of system types, how much configuration is already documented, and how many environments are in scope. No fixed timeline applies under NIS2, and the researched facts supplied for this page do not give a duration, so ask any partner to state one in a written scope. The main drivers are the size of the asset inventory, the number of distinct operating systems, cloud accounts and network devices, and whether baselines exist or must be written from scratch. Work is also faster when policy owners are available to approve exceptions. Ask for the deliverables and the dependencies in the scope before comparing timelines.
What does configuration management need from management and engineering?
Management must approve the policy, accept the risk of any exceptions, and fund the work that keeps baselines current. Engineering must build the secure configurations, deploy the enforcement tools, and act on the results. Responsibilities usually split as follows:
- Management: approves the configuration policy, owns the risk acceptance for approved exceptions, and reviews reports on drift.
- Engineering: writes and tests baselines, applies them to new and existing systems, and fixes failed checks.
- Change owners: document configuration changes and follow the testing and assessment steps tied to point 6.4.
Because Article 20 places approval and oversight of the risk-management measures with the management body, the approval record should name who signed off each baseline.
Does NIS2 issue a certificate for configuration management?
No. NIS2 creates no certificate of compliance, so no body issues a NIS2 certificate for configuration management. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines under Articles 32 to 34. Where an organization wants independent assurance, it can ask an external auditor or assessor to test its configuration controls against an agreed framework, and that auditor issues the report, not the implementation partner. DeployOpen prepares systems, controls and evidence for such assessments but does not issue audit reports, attestations or certifications.
How do we size the cost of configuration management from a written scope?
Cost follows from the written scope, and the researched facts for this page do not provide price or effort figures, so compare quotes on the same basis. Ask for a scope that lists the system types, number of hosts, cloud accounts and network devices, the baselines to be written, the enforcement tools to be deployed, the number of environments, and the evidence the supplier will produce. Separate one-time work, such as baseline creation and tool deployment, from recurring work, such as scheduled reviews, drift triage and baseline updates after changes or incidents. Also ask who maintains the tools after handover. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.
How does configuration management relate to change management under point 6.4?
Configuration changes fall under the change management procedures of point 6.4, so every change to a baseline must be documented and, based on risk, tested and assessed before it is implemented. Point 6.3 defines the approved secure state, and point 6.4 governs how the state moves. In practice, a ticket records the change, the risk assessment decides the testing depth, and the configuration snapshot taken before and after the change becomes the evidence. ENISA's June 2025 guidance lists these snapshots and alerts on unexpected changes as examples of evidence. Confirm with your change tool that tickets can link to affected configuration items.
Which open-source tools help produce configuration evidence?
Several self-hosted open-source tools can produce parts of the evidence, and each covers a different piece of the control. Confirm the exact capability in your environment before relying on it.
- Wazuh Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies, mostly based on CIS benchmarks and extendable with custom policies, and recommends remediation.
- Fleet policies ask yes or no questions of devices as osquery queries, and the policies page shows which devices pass or fail each policy.
- GLPI's Assistance module tracks tickets, problems and changes following ITIL practices, which supports the change records behind point 6.4.
These tools run inside your own infrastructure, so the evidence stays under your control. DeployOpen can plan, deploy and integrate them as part of a fixed-scope engagement.
How DeployOpen prepares configuration evidence for NIS2
DeployOpen plans, implements, hardens and documents self-hosted open-source tooling inside your own cloud accounts, data centers or air-gapped networks, and it prepares the secure baselines and configuration evidence that point 6.3 asks for under a fixed scope agreed in writing before work starts. In practice that means DeployOpen works with your team to define which hardware, operating systems, services and network devices are in scope, sets up the monitoring and change-tracking tools those baselines depend on, and writes down how each configuration is established, enforced and reviewed. Your organization keeps ownership of the controls. Your management body approves the configuration policy, names who may approve exceptions, and decides the review intervals, because those choices are governance decisions that an implementation partner should not make on your behalf.
The evidence work follows the examples ENISA lists in its June 2025 guidance: documented baseline configurations, a register of approved exceptions with their compensating measures, configuration snapshots taken before and after changes, and alerts on unexpected changes. DeployOpen can configure the open-source tools that generate much of this material, such as Wazuh Security Configuration Assessment scans, Fleet policies and a GLPI change module, and document how their outputs are retained and who reviews them. Ask any implementation partner to show, in the written scope, which artifacts will be delivered, who will hold the original records, and what remains for your staff to run after handover. Those items determine how much of the evidence can be reproduced later.
DeployOpen does not issue audit reports, attestations or certifications. Competent authorities supervising NIS2 and any independent auditor or certification body you engage will test your configuration controls and reach their own conclusions. Before commissioning this work, confirm with those bodies which evidence formats they accept, and ask the implementation partner to state in writing which parts of the evidence are prepared for review and which parts you must verify yourself.
