NIS2

NIS2 and your Linux servers

Denmark’s NIS2 Act has applied since 1 July 2025. If your organisation is covered, or supplies one that is, you will be asked what you do about the security measures in the directive. This page shows which of them my work gives you evidence for, and what I document as a supplier.

How the work maps to Article 21(2)

Article 21(2) of the NIS2 Directive lists the measures covered entities must take. Every deliverable below is written so you can hand it to an auditor, a customer’s security questionnaire or your supervisory authority.

MeasureWhat you get from me

(a) Risk analysis and information system security policiesAn attack surface review and a written threat model that names what is covered and what is not.
Linux hardening →

(b) Incident handlingDetection alerts in the monitoring you already run, each with a runbook saying what to check and collect first.
Kernel security →

(c) Business continuity, backups and disaster recoveryServers that can be rebuilt from code, and an upgrade and rollback procedure rehearsed with your team.
Infrastructure →

(d) Supply chain securitySigned build artefacts and an SBOM in your pipeline, and a supplier statement for my own access (below).
Infrastructure →

(e) Security in acquisition, development and maintenance, including vulnerability handlingCVE mitigation, packages pinned to versions you chose, and kernel-level controls that reduce the attack surface.
Kernel security →

(f) Assessing whether the measures workMeasurements before and after every change, and a follow-up check after every review.
Performance →

(g) Basic cyber hygieneA hardening baseline applied as reviewable code to every server, not just the ones someone remembered.
Linux hardening →

(i) Access control and asset managementA server inventory kept as code, least-privilege access, and nothing sensitive exposed to the internet.
Linux hardening →

(j) Multi-factor authenticationZero Trust access with MFA in front of every admin surface.
Linux hardening →

Not covered: (h) cryptography policies, and the training and HR parts of (g) and (i). Those are organisational measures, and I do not deliver them.

Reporting deadlines

Early warning: within 24 hours of becoming aware of a significant incident
Incident notification: within 72 hours
Final report: within one month

Deadlines that short depend on noticing early and knowing what to collect. That is what detection with a runbook per alert is for.

DORA and the Cyber Resilience Act

DORA has applied to financial entities since 17 January 2025, with its own ICT risk and third-party requirements.
The Cyber Resilience Act requires manufacturers of products with digital elements, including Linux-based devices, to report actively exploited vulnerabilities from 11 September 2026. The rest applies from 11 December 2027.

Helius as your supplier

Covered entities must assess the security of their direct suppliers. This is what I can state and sign.

All work is done by me personally. There are no subcontractors.
Access is a named personal account with the least privilege the work needs, never a shared root login. It is revoked when the engagement ends.
Multi-factor authentication on all access to client systems, and full-disk encryption on my work machines.
No client data is stored on my machines, and production data is not copied. Test data is generated or anonymised.
I sign your data processing agreement (GDPR Article 28) and NDA, or provide my own.
Helius ApS, CVR 46850297, VAT DK46850297, Denmark.

This page is not legal advice, and no single supplier makes you compliant. It shows which measures my work gives you evidence for.

Tell me what is broken

A short description is enough. Within one business day I will tell you what I think the problem is, roughly how long it takes, and whether you need me at all. Sometimes the honest answer is no.

[email protected]

I reply within 1 business day · No contact forms, no tracking pixels, no CRM sequence.

On GitHub