NIS2 evidence

Turn network activity into evidence your NIS2 programme can use.

obserae helps security teams document assets and intended connectivity, detect exceptions, investigate incidents and retain verifiable records — while keeping network data on infrastructure they control.

Supports a control programme · Does not certify or deliver compliance

Where network evidence contributes

NIS2 is a governance and risk-management obligation. Network monitoring is useful when its output can be connected to controls, decisions and retained evidence.

Risk management

Document assets and expected communications

A named cartography and explicit Flow Matrix turn part of the network architecture into a reviewable operating model.

Incident handling

Detect and investigate exceptions

Alerts retain the query, matching rows, timestamps and asset context needed to qualify an event and support a response workflow.

Assurance

Retain evidence that can be checked

Reports, configuration exports and a tamper-evident audit trail support control reviews without claiming compliance on your behalf.

Supply chain

Verify the software you deploy

Signed releases, an SBOM and build provenance give security teams concrete artefacts for supplier and release assurance.

What NIS2 asks — and what an NDR can support

NIS2 does not prescribe a particular product or make an NDR mandatory. It requires covered entities to manage cybersecurity risk through appropriate and proportionate technical, operational and organisational measures. The European Commission identifies areas including risk analysis, incident handling, business continuity, supply-chain security, vulnerability management, effectiveness assessment, cryptography, access control and asset management. See the Commission’s NIS2 overview and official FAQ.

An NDR contributes where network visibility, detection and retained evidence support those measures. It does not replace governance, a risk assessment, incident reporting, business-continuity planning or legal advice. The useful question is therefore not “does this make us compliant?” but “which control does this evidence support, who reviews it, and what decision follows?”

A practical evidence mapping

Programme concernWhat obserae can contributeBoundary to keep explicit
Risk analysis and system securityNamed assets, observed relationships and an explicit model of intended connectivityIt does not maintain the organisation’s risk register or decide risk acceptance
Incident handlingTimestamped alerts, matching flow evidence, saved investigation queries and integrations with response toolsIt does not make regulatory notifications or replace the incident-response process
Business continuityPassive deployment, health monitoring, scheduled backups and point-in-time recoveryIt does not replace a business-impact analysis or continuity plan
Control effectivenessScheduled reports, unmatched-session analysis, detection history and configuration exportsEvidence informs an assessment; it is not a certification of effectiveness
Access control and asset managementCartography, named users, roles, SSO/LDAP, local-user 2FA and per-user tokensIdentity features support product access, not every access-control obligation in scope
Supply-chain assuranceSigned releases, checksums, SBOM, SLSA provenance and a documented vulnerability processThese artefacts inform supplier risk; they do not assess the entire supply chain

ENISA’s NIS2 technical implementation guidance uses practical guidance, examples of evidence and mappings between requirements and controls. That is the right model for using obserae: connect each retained artefact to a control owner and review process instead of treating a dashboard as proof by itself.

Evidence remains under organisational control

Network-flow records can reveal sensitive relationships even without packet content. obserae keeps those records, reconstructed sessions, asset names and alerts on infrastructure the organisation operates. There is no vendor telemetry, activation service or cloud analysis path.

This simplifies one part of the governance discussion: the organisation chooses storage location, retention, access, backup destinations and optional outbound integrations. It also keeps the responsibility visible. Self-hosting is not an exemption from capacity planning, patching, access reviews or tested recovery.

The security page describes the data paths, passive architecture, release verification, identity controls, tamper-evident audit trail and recovery model in reviewable terms.

From detection to usable incident evidence

A useful alert must carry enough context for another person or system to understand what happened. obserae stores the query that fired, its evaluation time, the matching rows and the asset and threat-intelligence context resolved at that moment. This allows an analyst to review the original evidence rather than reconstructing it from a current dashboard after the environment has changed.

Outputs and a documented API can route that evidence to ticketing, SIEM, SOAR or on-call tools. The authorised response remains outside obserae: it is an out-of-band observer and does not block network traffic. That separation avoids putting the monitoring service in the production path and leaves containment with the systems designed and approved to perform it.

Build the evaluation around a control scenario

For a decision-ready assessment, choose a scenario that already has an owner and an expected response. For example: a workstation communicates directly with a protected database, an unknown asset appears on a managed network, or an internal system reaches known malicious infrastructure.

Then verify four things:

  1. Coverage: did the selected exporters expose the relevant conversation?
  2. Context: could the team identify the assets and intended policy without translating addresses by hand?
  3. Workflow: did the alert preserve enough evidence to qualify, route and review the event?
  4. Assurance: could another reviewer verify configuration changes, access, software origin and recovery?

The result is not a compliance certificate. It is a documented view of what the product can observe, which controls that observation supports, where the boundaries remain and what operating effort the organisation must own.

Start from the control, then test the evidence.

Bring the network and security owners together around one segment, one incident scenario and the evidence your governance process expects.