NIS2 in Sweden: The Practical Engineer's Checklist

Updated 27 September 2026: the Swedish act's real dates, the eight supervisory authorities, the MCFFS regulations, the three incident reports, and the Azure and Microsoft 365 controls behind the ten measure areas.

This is engineering guidance built from the statutory text and the authorities' own material, not legal advice, and Technspire does not certify compliance. Classification decisions belong with counsel and with the authority that supervises your sector.

Scope. Are You In?

The act covers eighteen sectors, several of them subdivided. Alongside the expected ones (energy, transport, banking, health, water, digital infrastructure, public administration) sit categories that catch companies which never considered themselves critical infrastructure: ICT service management between businesses, research, waste, chemicals, food, and the manufacture of medical devices, electronics, machinery and vehicles.

Size is the second filter. Medium and large enterprises are in scope, measured with the EU definition in Recommendation 2003/361/EC, so affiliated and partner enterprises count toward headcount and turnover. A 40-person Swedish subsidiary of a large group is often in scope on group figures alone, which is where most self-assessments go wrong.

The väsentlig and viktig split follows from sector and size. Broadly, large enterprises in the NIS2 Annex I sectors are essential, as are state authorities, qualified trust service providers, top-level domain registries, and municipalities and regions above the medium threshold. Medium enterprises in Annex I, and medium and large enterprises in Annex II sectors, are important. Swedish preparedness authorities (beredskapsmyndigheter) are covered irrespective of size unless exempted.

The classification is not cosmetic. Supervision of essential entities is planned, including audits and security scanning. For important entities the act permits supervisory measures only where the authority has reason to believe the entity is not complying. Ceilings differ, and so does exposure for the people running the company.

Registration, and Who Actually Supervises You

Chapter 2, Section 2 requires an entity to register så snart det kan ske, as soon as it can be done, with the authority the government designates. Section 5 of the ordinance routes that to the single point of contact, and Sections 23 and 31 name Försvarets radioanstalt (FRA) as both that contact point and the Swedish CSIRT. The registration service opened on 2 February 2026. On 1 July 2026 the cyber tasks of Myndigheten för civilt försvar (MSB, renamed on 1 January 2026) moved to Nationellt cybersäkerhetscenter at FRA, and registrations now go there.

The form asks for legal name and organisation number, address, contact details, sector and subsector, and your internet identifiers: IP ranges and domain names. That last field is the one engineering teams underestimate. Generate it from a source of truth, and keep it current, because changes to registered particulars must be reported within 14 days.

Registration is central. Supervision is not: Section 7 splits it across eight authorities.

For a Swedish software or hosting business the answer is usually PTS, and that brings a second rulebook. Commission Implementing Regulation (EU) 2024/2690, adopted on 17 October 2024, sets detailed technical and methodological requirements for cloud, data centre, CDN, DNS and TLD providers, managed service and managed security service providers, online marketplaces and search engines, social networking platforms and trust service providers. PTS has said it will not issue separate Swedish security and incident-reporting regulations for those entities, because the EU text already governs them. If you are a Swedish MSP or SaaS provider, that Annex, not a Swedish föreskrift, is your control specification.

Everyone else works from the Swedish regulations, which arrive on a staggered schedule.

The Ten Risk-Management Measures

Chapter 2, Section 3 requires appropriate and proportionate technical, operational and organisational measures across ten areas. The Swedish regulation frames this as systematic, risk-based work, and adds a physical dimension the directive leaves implicit: facilities where systems process information must be protected against unauthorised access, equipment threats and environmental hazards.

1. Risk analysis and information security policy. Management-approved, reviewed annually, with the risk register versioned rather than overwritten.
2. Incident handling. Runbook, on-call rota, classification rubric, and a workflow that produces the statutory reports as a by-product.
3. Continuity and crisis management. Backups, restore testing with measured durations, recovery objectives, named decision-makers.
4. Supply chain security. Supplier register, criticality tiering, risk assessment, contractual obligations.
5. Acquisition, development and maintenance. Secure SDLC, vulnerability handling with severity-based windows, dependency and secret scanning.
6. Assessing effectiveness. Measurement of whether controls work, not evidence that they exist.
7. Cyber hygiene and training. Patching discipline, phishing resistance, role-based content.
8. Cryptography. At rest and in transit, plus key ownership and rotation.
9. Personnel security, access control, asset management. Joiner, mover and leaver handling, least privilege, a generated inventory.
10. Authentication and secured communications. Multi-factor authentication, ideally phishing-resistant, and a channel that survives losing your primary tenant.

Mapping the Measures to Azure and Microsoft 365

Most Swedish entities in scope already run Microsoft 365 and some Azure, so the mapping below is what a team can implement without buying a platform. Microsoft's own NIS2 material points at Sentinel, Defender for Cloud and Purview Compliance Manager, which lists a premium assessment template for NIS2 Directive (EU) 2022/2555. That template records improvement actions and holds evidence. It is not a compliance verdict.

Incident Reporting. The Clock Is Tight

Reporting runs in three stages through Cyberportalen. The first submission returns an incident ID that every later stage references, so capture it automatically.

If the incident is still running at the one-month mark, the directive expects a progress report then, and the final report within a month of the handling finishing. Authorities can ask for status updates in between. A separate obligation is easy to miss: entities must inform the recipients of their services about significant incidents affecting service delivery. For a B2B platform that means a customer-communications path with a pre-agreed template and a named approver, because drafting cannot start once the 24-hour window is open.

What counts as significant is where engineers get stuck. The Swedish act keys off serious operational disruption or economic damage to the service, plus material or non-material damage to others. For the entity types covered by Implementing Regulation 2024/2690 the thresholds are numeric: financial loss above EUR 500,000 or 5% of total annual turnover in the preceding financial year, whichever is lower; exfiltration of trade secrets; a successful unauthorised access suspected to be malicious and capable of causing severe disruption. Put those in the rubric rather than leaving severity to whoever is on call at 03:00.

The 24-hour clock starts on detection, not on understanding. Treat the early warning as a first-hour task with a named owner, a fallback, and a template holding the two facts it must state. Then rehearse the submission: a team that has never opened Cyberportalen under pressure will lose hours to account problems.

Supply Chain. The Hardest Part

The Swedish regulation on security measures expects entities to require cybersecurity commitments from suppliers, which turns a procurement conversation into an engineering one. A register of names and renewal dates is not enough. Supervision will probe whether you know which suppliers can affect the availability or integrity of your service, and what you agreed with them. Clauses worth having in every critical-supplier contract:

• Notification inside your window. A fixed number of hours, short enough that a supplier incident still leaves you time to file your own early warning.
• Content of that notification. The supplier's classification, affected components, and indicators of compromise where they have them.
• A named security contact and escalation path that does not depend on a single mailbox.
• Subcontractor disclosure, with notice before a material change in the chain.
• Attestation and audit rights. An ISO/IEC 27001 certificate with its scope statement, a SOC 2 Type II report, or the supplier's own registration status where the act applies to them.
• Vulnerability handling with remediation windows by severity, not best-effort language.
• Data location and personnel access geography, stated rather than inferred from a region name.
• A cooperation duty during supervision, so the supplier produces evidence when your authority asks.
• Exit obligations: data return, deletion confirmation, a transition period.

Keep the register queryable. A spreadsheet nobody can join against the asset inventory will be roughly accurate when an authority asks, and you will not know which parts are wrong.

Board-Level Accountability

Chapter 2, Section 4 requires the people in an entity's management to undergo training on security measures. Swedish guidance describes the expected content as basic cybersecurity knowledge: management's own role, terminology, the applicable rules, risk management and oversight, and the organisation's internal procedures. The same guidance sets out what management should do in practice, and it reads like a governance checklist: decide objectives and resources, assign ownership for systems and information, ensure a coordinating function such as a CISO exists, and conduct an annual review covering serious risks, action-plan status, significant incidents and supply-chain exposure.

Deficient governance carries its own consequences. Beyond orders and sanction fees, a court can bar a person from a management position at an essential entity for one to three years, after an unheeded order and a serious violation committed intentionally or by gross negligence. That does not apply in public administration. The engineering deliverable is a short, dated review pack management genuinely reads, plus minutes recording that the review and the training happened.

Evidence That Survives an Audit

Essential entities face planned audits and security scanning, and the act obliges anyone under supervision to hand over the documents an authority needs on request. Supervisors may also enter premises used in the regulated activity, excluding residences. What holds up is dated evidence a system produced, regenerable for a different period.

• Policy documents with an approval record: who approved them, and when.
• Versioned risk register entries, so a supervisor sees how an assessment changed.
• Restore test records with timestamps and measured durations.
• Incident records with the Cyberportalen ID and the submission time of each stage.
• Access review and leaver-deprovisioning exports from the identity platform.
• Supplier register exports showing review dates and criticality tiers.
• Minutes covering the annual review and the training.
• Compliance and secure-score snapshots showing trend rather than one good day.

Screenshots prove nothing about the period a supervisor asks about. Prefer exports from systems that retain history.

Practical Engineering Checklist

• Scope decision written down, with the group figures and the Annex applied.
• Registration submitted; identifiers generated from a source of truth; an owner for the 14-day rule.
• Phishing-resistant MFA for privileged roles; two break-glass accounts excluded and tested.
• A SIEM with round-the-clock response, internal or contracted.
• Early warning as a first-hour runbook task, with a rehearsed submission.
• Classification rubric encoding the significance thresholds for your entity type.
• Customer-notification template and named approver.
• Patch windows by severity; dependency, secret and IaC scanning gating CI builds.
• Minimum TLS version enforced on every public endpoint; keys owned and rotated.
• Immutable backup vaults with quarterly restore rehearsals and recorded durations.
• Supplier register queryable and tiered, with the clause set on new agreements.
• Annual tabletop that includes a simulated early warning against the clock.
• Management training minuted; annual review pack delivered.

A Sequence That Works

Order matters more than effort. Teams that start with the control catalogue spend a quarter producing documents nobody asked for.

Where Year One Stalls

Three things reliably slip. Restore testing gets deferred, so recovery objectives stay theoretical. The supplier register drifts, because nobody owns it between procurement cycles. And the early warning stays a paragraph in a document rather than a rehearsed action, which is the gap that turns a contained technical incident into a supervisory problem.

A bigger policy set fixes none of that. Three routines do: a measured restore, a reviewed supplier register, and a timed submission drill. If you want a second pair of eyes on the engineering side, that is the work our Azure platform and security engagements cover. The legal classification stays with your counsel.