NIS2 in Slovenia: Evidence for ZInfV-1 Implementation

A security policy describes an intended way of working. Implementation evidence shows what the organisation actually does, where it does it and how it responds when a measure fails. For a Slovenian organisation working on ZInfV-1, the useful next step is often connecting existing documentation to verifiable operational records.

This article proposes a practical way to organise those records. It does not determine whether an organisation is covered, establish a complete legal checklist or conclude that a set of documents proves compliance. The official act and current URSIV guidance remain the starting points for applicable requirements.

Begin with an accountable scope

Before collecting screenshots, identify which legal entity, services, sites and supporting systems the implementation programme covers. Record who maintains the applicability assessment and which current sources support it. Coverage should follow the statutory criteria and exceptions; it should not be inferred from a supplier's marketing checklist.

URSIV explains the self-identification and registration framework and provides supporting material for covered organisations. Registration is an administrative step, not evidence that every security measure operates as intended. Keep the registration record separate from the implementation register so that the two cannot be mistaken for the same conclusion. URSIV obligations and support.

Give the scope a review date. An acquisition, new service, supplier change or substantial infrastructure change can make an old record incomplete. Assign someone to assess those triggers rather than waiting for a scheduled document refresh to reveal the change.

Connect a risk to a control and its result

A useful evidence chain begins with a concrete risk scenario. For example, an unauthorised former supplier account could retain administrative access to a supported system. The relevant control might combine an account owner, a defined offboarding process and a recurring access review.

The evidence should then show whether those activities occurred: the account population reviewed, the reviewer, the review date, the decisions and any removals. A policy requiring reviews supplies context. A list of accounts without review decisions does not demonstrate that the review happened.

This distinction helps avoid an oversized document library. Keep enough evidence to support the implementation claim and make its limitations visible. A single well-scoped review record can be more useful than numerous screenshots that omit the system name, time and responsible person.

Build a working evidence register

The matrix below is an editorial organising aid. It is not an official exhaustive ZInfV-1 checklist or a substitute for assessing the applicable provisions.

For each entry, add the service, control owner, evidence location, observation period and next review trigger. Reference the authoritative requirement separately. This makes it possible to update the legal mapping without rewriting every operational record.

Distinguish existence, implementation and effectiveness

Consider a fictional organisation with a documented backup policy. The policy exists and assigns responsibility. The backup platform produces completion reports, which support a claim that copying took place. A restoration exercise then establishes whether selected data and services can actually be recovered under the tested conditions.

These records answer different questions. The register should not collapse them into a single green status. Use a short explanation such as “configuration reviewed; restoration not yet exercised” when that is the real state. The limitation then becomes a task with a responsible owner.

URSIV's supporting guidance discusses security documentation, risk management, continuity, incident response and assessment of control effectiveness. Its templates need to reflect the actual organisation. Copying a template without resolving its operational assumptions leaves those assumptions untested. URSIV implementation support.

Make exceptions reviewable

An exception record should identify the affected service, the reason the planned measure is not yet implemented and the resulting exposure. Record the person authorised to decide, any interim restriction, the expiry or review date and the condition for closure.

For example, a legacy integration might prevent an immediate authentication change. The record should name the integration and describe the specific dependency. “Business requirement” alone does not explain why the exception remains necessary or what will allow it to end.

An internal risk decision does not by itself remove a statutory obligation. Keep the technical risk decision and the legal assessment distinct. Escalate uncertainty about the applicable requirement through the organisation's designated compliance or legal process, with the actual facts attached.

Use assessments for the questions they answer

A penetration test can supply evidence about defined attack paths, weaknesses and the results of attempted controls. A retest can establish whether selected findings remain reproducible in the tested release. Neither should be relabelled as a complete assessment of all ZInfV-1 requirements.

URSIV distinguishes conformity assessment and self-assessment processes for different entity categories. The organisation should map its technical reviews to the relevant process instead of assuming that one commercial service fulfils every obligation. URSIV assessment guidance.

For practical follow-up, use pentest reporting guidance when connecting each technical finding to the remediation and retest register. Keep assessment scope, test limitations and outstanding findings visible beside the evidence reference.

Prepare a concise management review

Management needs a view of decisions, not a folder count. Report which services have implementation evidence, which measures failed validation and which corrective actions are late. Show the consequences supported by the affected service, avoiding speculative fines or unsupported claims about business loss.

Choose one incomplete evidence chain and follow it from risk to decision. If an access review discovered unnecessary supplier rights, can the team demonstrate the removal and confirm that required support still works? That small sample often reveals whether the evidence process is connected to actual operations.

Protect the underlying records. Configuration exports and incident documents may contain personal data or operational secrets. Use restricted references in the management register and prepare a redacted copy when information must be shared more broadly.

Frequently asked questions

Does a completed template prove compliance?

No. It documents a position or intended procedure. Implementation and effectiveness require appropriate evidence, and the legal conclusion depends on the applicable requirements and facts.

Is every Slovenian company required to buy an annual pentest?

That conclusion cannot be drawn from NIS2 or a generic checklist. Determine the organisation's status and applicable duties from current official sources before choosing assessment services.

How much evidence should be retained?

Define retention through applicable requirements, investigation needs and the control's review cycle. Preserve enough context to understand the result; do not collect sensitive information without a defined purpose.

For a starting point for technical reviews, see the security checklists. For related assessment guidance, see Active Directory security and security reporting.