NIS2 geautomatiseerd discovery-bewijs: wat scans wél bewijzen

.smc-post-content p,
.smc-post-content ul,
.smc-post-content ol,
.smc-post-content li,
.smc-post-content td,
.smc-post-content th {
color: #333333 !important;
font-size: 18px !important;
}
.smc-post-content h2,
.smc-post-content h3 {
color: #1E1E1E !important;
font-weight: bold !important;
text-decoration: none !important;
}
.smc-post-content h2 {
margin-bottom: 40px !important;
}
.smc-post-content h3 {
margin-bottom: 20px !important;
}
.smc-post-content a {
color: #62aab7 !important;
text-decoration: none;
}
.smc-post-content a:hover {
text-decoration: underline;
}
.smc-post-content table {
width: 100%;
border-collapse: collapse;
margin: 25px 0 40px 0;
}
.smc-post-content th,
.smc-post-content td {
border: 1px solid #dddddd;
padding: 12px;
text-align: left;
vertical-align: top;
}
.smc-post-content th {
background-color: #f8f9fa;
color: #1E1E1E !important;
font-weight: bold;
}
.smc-post-content details summary {
color: #62aab7 !important;
}

Estimated reading time: 14 minutes

Key takeaways

• NIS2 automated discovery evidence helps organisations prove what assets exist, where they are, who owns them, and how they are managed.
• A reliable NIS2 asset inventory must go beyond spreadsheets and static CMDB records.
• Automated discovery supports risk management, vulnerability handling, incident response, business continuity, governance, and audit readiness.
• A NIS2 evidence asset register should include technical, ownership, lifecycle, risk, and evidence fields.
• Tools such as Lansweeper can improve visibility, but they must operate within a governed ITAM and compliance framework.
• SMC Consulting can help organisations turn discovery data into a defensible NIS2 asset management capability.

NIS2 automated discovery evidence gives organisations a practical way to prove what technology assets exist, where they are located, who owns them, and how they are managed. Under NIS2, this matters because organisations cannot secure, patch, monitor, isolate, or recover assets they cannot identify.

A reliable NIS2 asset inventory must go beyond spreadsheets and incomplete CMDB records. It needs current, repeatable, and traceable data that supports risk management, incident response, vulnerability handling, governance, and audit readiness.

In simple terms, NIS2 automated discovery evidence is automatically collected, timestamped, and verifiable information about technology assets. It helps prove what assets exist, where they are located, who owns them, and how they are managed for NIS2 compliance.

This article explains how to build a provable IT inventory, what a NIS2 evidence asset register should include, how Lansweeper NIS2 use cases can support visibility, and where SMC Consulting NIS2 ITAM support can help.

Why asset visibility matters under NIS2

A NIS2 asset inventory is the foundation for practical cybersecurity risk management. For organisations defining their NIS2 asset data model, NIS2 CMDB requirements can help translate compliance expectations into structured asset, ownership, service, and evidence fields.

NIS2 expects in-scope organisations to apply appropriate technical, operational, and organisational measures. For example, Article 21 refers to measures such as risk analysis, incident handling, business continuity, supply chain security, vulnerability management, access control, and asset management.

However, each of these measures depends on knowing what assets exist. If a server is unknown, it may not be patched. If a remote laptop is unmanaged, it may not be monitored. If a cloud workload is missing from the inventory, it may not be included in incident response or recovery planning.

A strong NIS2 asset inventory should include:

• Servers, laptops, desktops, and mobile devices.
• Network devices, virtual machines, and cloud resources.
• OT, IoT, and connected devices.
• Operating systems, installed software, and patch status.
• Owners, users, locations, and business service links.
• Unsupported, unmanaged, or end-of-life technology.

Therefore, asset visibility is not only an IT administration task. It supports risk assessment, vulnerability prioritisation, access control, business continuity, incident scoping, and compliance reporting.

In practice, automated discovery evidence helps leaders answer a simple but critical question: “Do we know what we are responsible for protecting?”

Without that answer, NIS2 compliance controls can become assumptions rather than evidence-backed practices.

Why manual asset inventories are not enough

A provable IT inventory cannot rely only on spreadsheets. Manual registers are easy to create, but they are difficult to keep accurate because technology changes every day. Devices are purchased, moved, retired, renamed, rebuilt, or reconfigured. Meanwhile, users connect remotely, software is installed, and cloud resources are created or removed within minutes.

Manual inventories often fail because:

• Records become stale between review cycles.
• Shadow IT and unmanaged devices are missed.
• Remote endpoints are difficult to track.
• Cloud assets sit outside traditional infrastructure records.
• Duplicate names reduce trust in the data.
• Ownership and business criticality fields are incomplete.
• Manual updates create human error.
• Historical changes are hard to prove.

Nevertheless, manual data still has value. It can add business context, record exceptions, and support approvals. For instance, a manual validation step may confirm that a discovered server supports a critical payment service. However, manual records should enrich automated discovery evidence, not replace it.

The key issue is proof. A spreadsheet may claim that a NIS2 asset inventory is complete, but it usually cannot show when the data was collected, how it was validated, or whether hidden assets were missed. Consequently, organisations need automated discovery to collect asset data repeatedly, consistently, and with timestamps.

Capability	Manual inventory	Automated discovery evidence
Currency	Often updated in cycles	Updated on a schedule or trigger
Coverage	Depends on human input	Finds known and unknown assets
Traceability	Often weak	Linked to scans, agents, or connectors
Audit readiness	Requires manual preparation	Produces repeatable reports
Change history	Limited	Easier to retain and review

What is NIS2 automated discovery evidence?

NIS2 automated discovery evidence is automatically collected, timestamped, and verifiable information about technology assets and their status. It supports NIS2-related compliance, governance, cybersecurity risk management, and audit activities.

Importantly, the goal is not simply to collect more data. Instead, the goal is to show that the organisation has a controlled, repeatable process for understanding and managing its technology estate. This aligns well with structured service management thinking, where frameworks such as ITIL emphasise repeatable practices, ownership, and continual improvement.

Examples of automated discovery evidence include:

• Device discovery reports.
• Network scan results.
• Hardware configuration records.
• Software inventory data.
• Operating system and patch information.
• User and ownership relationships.
• Asset change history.
• Unknown or unauthorised device reports.
• Unsupported operating system reports.
• End-of-life hardware and software reports.
• Cloud asset inventory reports.
• Remote endpoint records.
• Remediation and exception records.

Good evidence should be current, repeatable, traceable, verifiable, relevant, and retained. For example, a report showing unsupported operating systems is useful only if it includes a date, source, scope, owner, and follow-up action.

Therefore, discovery evidence should feed more than the asset register. It should also support vulnerability management, incident response, change management, risk registers, business continuity planning, and management reporting. When this evidence is connected to governance processes, it becomes part of a defensible compliance position.

How automated asset discovery supports NIS2

An automated asset discovery NIS2 approach helps organisations move from static documentation to continuous visibility. Instead of waiting for periodic manual reviews, discovery tools can identify connected devices, collect technical attributes, and consolidate asset information into a central inventory.

This supports NIS2 by helping teams:

• Identify known, unknown, managed, and unmanaged assets.
• Detect devices missing from the official inventory.
• Discover assets across local networks, remote endpoints, cloud, OT, and IoT.
• Identify operating systems, installed applications, and patch status.
• Detect unsupported or end-of-life technology.
• Link assets to users, locations, departments, and owners.
• Prioritise vulnerabilities based on asset criticality.
• Scope incidents faster and more accurately.
• Produce repeatable reports for assurance and management.
• Maintain evidence of changes over time.

For example, Lansweeper documentation states that Network Discovery is designed to automatically identify IP-connected devices and create a continuously updated inventory. Additionally, its discovery documentation describes coverage across local networks, remote endpoints, and cloud environments, with duplicate findings reconciled into unified records.

However, automated discovery does not remove the need for governance. It provides factual data, but people and processes must decide ownership, risk classification, remediation priority, exception handling, and evidence retention.

Consequently, automated discovery becomes most valuable when it is integrated with ITSM, cybersecurity, and compliance workflows. Industry platforms such as ServiceNow also show how asset, incident, change, and risk data can be connected across service management processes.

Building a NIS2 evidence asset register

A NIS2 evidence asset register is an asset inventory where each material record contains enough technical, ownership, lifecycle, risk, and evidence information to support compliance, control testing, and cybersecurity decisions.

It should not be a simple list of device names. Instead, it should answer six practical questions:

• What is the asset?
• Where is it located?
• Who owns it?
• Why does it matter?
• How is it managed?
• Where did the data come from?

Recommended fields include:

Field	Purpose	Example evidence source
Asset name	Identifies the asset	Discovery scan
Unique ID	Reduces duplicate records	Endpoint agent
Owner	Assigns accountability	CMDB or HR system
Location	Supports scoping	Network discovery
IP or cloud ID	Confirms technical identity	Cloud connector
Operating system	Supports patching	Discovery tool
Installed software	Supports risk review	Software inventory
Patch status	Shows exposure	Vulnerability tool
Business criticality	Helps prioritise risk	Service owner validation
Lifecycle status	Flags ageing assets	Procurement data
Discovery source	Provides traceability	Scan, agent, connector
Last-seen date	Shows currency	Discovery platform
Validation status	Supports audit review	Named approver

A basic inventory answers, “What assets do we think we have?” By contrast, a NIS2 evidence asset register answers, “What evidence supports this record, when was it last confirmed, and who is accountable?”

Therefore, source traceability is essential. Records should link to network discovery, endpoint agents, cloud connectors, directory services, procurement systems, vulnerability scanners, CMDB records, or validated manual approvals. This traceability turns asset data into a provable IT inventory.

What makes a provable IT inventory?

A provable IT inventory is an asset inventory that can be independently reviewed and supported by repeatable, traceable evidence. It proves not only that assets exist, but also that the organisation has an operating process to keep asset data reliable.

A defensible inventory should be:

• Complete: It covers on-premises, remote, cloud, OT, IoT, and relevant third-party-connected environments.
• Current: Data is refreshed according to a defined schedule or trigger.
• Consistent: Naming, categories, ownership, lifecycle status, and risk fields follow agreed standards.
• Traceable: Records link back to discovery tools, scans, agents, connectors, or validation activities.
• Version-controlled: Historical changes and previous inventory states can be reviewed.
• Owned: Each material asset has a responsible business or technical owner.
• Integrated: Inventory data feeds vulnerability, incident, change, risk, ITSM, and continuity processes.
• Governed: Exceptions are reviewed, assigned, documented, and remediated.

This matters because NIS2 compliance should not become a one-off documentation exercise. Instead, organisations need evidence that controls are operating over time.

For example, a vulnerability team needs to know which assets are affected, who owns them, and whether they support critical services. Similarly, an incident team needs accurate asset data to define scope and impact. Standards such as ISO/IEC 20000 also reinforce the importance of controlled service management practices and reliable management information.

Ultimately, automated asset discovery is a core input. Yet governance, ownership, and integration make the inventory truly defensible.

Using Lansweeper for NIS2 asset visibility

Lansweeper NIS2 use cases typically centre on improving technology visibility and maintaining a consistent asset inventory. Lansweeper can support automated discovery and IT asset management by helping organisations discover, centralise, and enrich asset records. For organisations evaluating discovery coverage, Lansweeper asset discovery and ITAM support can help connect technical scanning capabilities with practical inventory governance.

Lansweeper states that its platform can discover and centralise IT, OT, cloud, and IoT assets while enriching records with hardware, software, user, and lifecycle information. As a result, it can provide useful data for NIS2 asset inventory improvement, especially where organisations have fragmented tooling or stale CMDB records.

Relevant capabilities can include:

• Network scanning and device discovery.
• Endpoint discovery for remote and transient devices.
• Cloud asset inventory.
• Hardware and software inventory.
• Identification of unknown or unmanaged assets.
• Detection of unsupported operating systems and software.
• Asset reports and dashboards.
• Network and dependency mapping.
• Integration with ITSM and security tools.
• Centralised asset records.

These capabilities can help generate audit-ready discovery evidence, highlight exceptions, and provide input for vulnerability, incident, and lifecycle processes.

However, Lansweeper alone does not make an organisation NIS2 compliant. It is an enabling technology within a broader governance and ITAM framework. Organisations still need defined policies, ownership rules, agreed discovery coverage, risk classifications, exception workflows, review processes, evidence retention, and management oversight.

Therefore, Lansweeper should be implemented with clear operating processes. Otherwise, the organisation may collect more data without improving control, accountability, or compliance readiness.

Practical steps to create NIS2 automated discovery evidence

Creating NIS2 automated discovery evidence should be an ongoing operating process, not a one-off project before an audit. A practical roadmap includes the following steps.

1. Define the scope. Identify business units, networks, data centres, cloud providers, remote endpoints, OT environments, IoT estates, third parties, and critical services.
2. Set ownership rules. Define who owns the inventory, who approves records, and who resolves unknown assets or discovery exceptions.
3. Deploy discovery tooling. Configure network scans, endpoint agents, cloud connectors, directory integrations, and other relevant discovery methods.
4. Run baseline scans. Establish an initial view of the estate. Then identify unknown assets, duplicates, unmanaged devices, incomplete records, and unsupported technology.
5. Cleanse and normalise data. Standardise names, asset types, departments, owners, locations, lifecycle states, and risk classifications.
6. Assign business criticality. Identify assets supporting important services, sensitive data, operational processes, customer systems, or regulatory obligations.
7. Create the NIS2 evidence asset register. Ensure each material asset has a discovery source, timestamp, owner, status, and key technical attributes.
8. Schedule recurring discovery. Use more frequent updates for dynamic cloud, remote, and high-risk environments.
9. Create exception reports. Track unknown assets, stale records, missing owners, unsupported technology, and unmanaged devices.
10. Link inventory to security and ITSM. Connect asset data to vulnerability management, incident response, access reviews, change management, procurement, business continuity, and risk registers.
11. Retain evidence. Store dated reports, exports, scans, approvals, remediation evidence, and management reports in a controlled repository.
12. Review and improve. Track discovery coverage, stale assets, ownership completeness, unknown assets, unsupported technology, exception closure time, and assets linked to vulnerabilities.

Common gaps that weaken NIS2 readiness

Many organisations have some form of NIS2 asset inventory, but they cannot prove it is complete, current, and governed. Often, the problem is not the absence of data. Instead, the problem is weak traceability, poor ownership, and limited integration with risk processes.

Common gaps include:

• Discovery coverage excludes cloud resources.
• Remote endpoints are not consistently scanned.
• Network scans miss subnets, offices, data centres, or OT environments.
• Shadow IT detection is informal.
• Assets have no accountable owner.
• Business criticality is missing.
• CMDB records are stale, duplicate, or conflicting.
• Discovery reports are not retained.
• Inventory data is not linked to vulnerability management.
• Incident response teams cannot trust asset relationships.
• Unknown devices are found but not investigated.
• Unsupported technology has no remediation plan.
• Manual updates override automated data without review.
• Cloud resources change faster than inventory processes.

These gaps weaken confidence in the NIS2 asset inventory. Moreover, they reduce incident response speed, make vulnerability prioritisation harder, and can leave unmanaged assets exposed.

A large volume of asset data does not automatically create a provable IT inventory. The data must be traceable, governed, and connected to risk, security, and ITSM workflows. Therefore, remediation should focus on expanding discovery coverage, assigning ownership, retaining evidence, improving data quality, and creating exception workflows.

How SMC Consulting can help

SMC Consulting NIS2 ITAM support helps organisations turn discovery data into a governed compliance capability. For organisations looking to operationalise NIS2 inside service management, NIS2 ITSM compliance support can help align asset evidence, workflows, controls, reporting, and accountability.

This support is not limited to deploying a discovery tool. Instead, it includes designing the policies, workflows, roles, data standards, controls, reporting, and governance needed to make the inventory useful and defensible.

SMC Consulting can support:

• NIS2 readiness assessments.
• ITAM maturity reviews.
• Asset discovery strategy and coverage planning.
• Lansweeper implementation or optimisation for Lansweeper NIS2 use cases.
• NIS2 evidence asset register design.
• Ownership and criticality models.
• Evidence framework creation.
• CMDB and ITSM integration.
• Vulnerability and incident management integration.
• Reporting and dashboard design.
• Exception and remediation workflows.
• Ongoing governance and management reporting.

For example, SMC Consulting can help define which environments must be scanned, how often discovery should run, which evidence should be retained, and how unknown or unsupported assets should be escalated.

Additionally, SMC can help organisations connect discovery evidence to broader ITSM practices. Platforms such as Atlassian ITSM highlight the value of connecting service, asset, incident, and change workflows in one operating model. However, the real value comes from process design, ownership, and continual improvement.

If your organisation needs to improve its NIS2 asset inventory or create defensible automated discovery evidence, SMC Consulting can help assess your current position and design a practical ITAM roadmap.

Conclusion

NIS2 compliance depends on knowing what assets exist, where they are, who owns them, how important they are, and whether they are managed effectively. NIS2 automated discovery evidence helps replace assumptions and static spreadsheets with current, repeatable, and traceable information.

A well-designed NIS2 asset inventory supports risk assessment, vulnerability prioritisation, incident scoping, business continuity, governance reporting, and audit readiness. Tools such as Lansweeper can help discover and centralise asset data, but they must operate within a broader ITAM and governance framework.

Start by assessing discovery coverage, ownership completeness, evidence quality, register traceability, and integration with security processes. If your organisation is preparing for NIS2 and needs a reliable way to build a NIS2 asset inventory, create NIS2 automated discovery evidence, or implement a provable IT inventory, contact SMC Consulting to book a NIS2 asset visibility assessment.

About the author

Frequently asked questions