NIS 2 evidence, the way an auditor reads it.

The NIS 2 Directive requires essential and important entities to take appropriate technical, operational and organisational measures. SecHive produces the technical evidence — controlled, replayable, and labeled — that an auditor or competent authority can read without rebuilding context.

Book a compliance demo → How the chain works

FrameworkNIS 2 Directive

JurisdictionEU 2022/2555

ReferenceArticle 21(2)(a–i), Art. 23

ScopeEssential & important entities

SecHive evidencetechnical

Auditor opinionout of scope

§ Articles → Evidence

Where SecHive evidence fits in NIS 2 Directive.

The mapping is intentionally narrow. We list only the articles where SecHive produces a directly defensible artifact, and we name the artifact.

Article / control	What it requires	SecHive artifact
Art. 21(2)(a) — Risk analysis	Policies on risk analysis and information system security.	Per-engagement risk register, hypothesis graph, and validated finding set.
Art. 21(2)(b) — Incident handling	Detect, respond and recover from incidents.	Reproducible exploit chain — feeds detection engineering and tabletop input.
Art. 21(2)(d) — Supply chain	Cybersecurity in supplier and service-provider relationships.	Source-audit run mode against supplier artifacts; PR audit at integration point.
Art. 21(2)(e) — Effectiveness testing	Policies and procedures to assess effectiveness of measures.	Per-control proof packs with replay scripts and reviewer disposition.
Art. 21(2)(f) — Cyber hygiene	Basic cyber-hygiene practices and training.	Public-safe write-ups suitable for internal training without leaking client material.
Art. 21(2)(g) — Cryptography	Use of cryptography and where appropriate, encryption.	Cryptographic-control validation findings: replay, downgrade, key-handling abuse.
Art. 21(2)(i) — Network and system security	Vulnerability handling and disclosure.	SecHive coordinates redaction-safe disclosure and tracks remediation status.
Art. 23 — Reporting	Significant incident reporting to CSIRT / authority.	Incident-shaped report bundle with timestamps, scope, and chain of custody.

§ Buyer view

SecHive provides.

What you can put in front of an auditor or a security review.

For the CISO

Mappable evidence per Article 21(2) sub-clause.
Time-bounded findings with severity and impact.
Retest records that close the loop with the engineering team.

For the legal / compliance team

Redaction manifests for cross-border or supplier engagements.
Operator identity stamped on every disposition.
Cosigned attestation on report bundles.

For engineering

Deterministic replay.sh per finding.
Source references when source mode is enabled.
Negative evidence for refuted candidates.

For the auditor

Run-mode-labeled evidence rows.
sha256 binding to underlying artifacts.
Methodology spine consistent across engagements.

§ Sample evidence

A page from the matrix.

SecHive renders an evidence matrix per engagement. Below is one row, redacted.

EVIDENCE ROW — sample

# evidence-row.yaml — redacted
control:    Art. 21(2)(e)  # effectiveness testing
finding_id: VTX-RPL-0042
mode:       black-box
target:     redacted
target_ref: image@sha256:9c4e…  # pinned
artifact:
  path:    artifacts/replay.sh
  sha256:  7c3a…
  signed:  cosign:sechive-key
disposition:
  reviewer:  redacted-operator
  state:    confirmed
retest:
  status:    fixed @ 2026-04-18
  evidence:  artifacts/retest-receipt.json

What an auditor sees

The control id and the finding id, bound together.
A run-mode label (black-box, source-aware, etc.).
A sha256 of the underlying artifact.
A reviewer disposition with operator identity.
A retest record if the finding has been remediated.

See the full output matrix →