Cybersäkerhetslagen: This is about management decisions, not firewalls

Cybersäkerhetslagen (CSL) is already in force in Sweden. Unfortunately, CSL is often discussed in terms of technical controls: firewalls, MFA, logging. But those discussions are a distraction. At its core, CSL is a governance and management accountability law. In CSL’s own words:

“The persons who are part of the management of an entity shall undergo training on security measures.”

– Cybersäkerhetslagen (2025:1506), 2 kap 4 §

Despite the prefix “cyber” CSL applies to many industries, including those whose primary output is not IT, such as energy, finances, health, public sector, to name a few. And while rules under CSL are pouring in, one thing is certain: Failure to comply with it may lead to personal consequences, such as being forbidden to hold a management position.

So if you are part of the management team or aspiring to become, this post will walk you through what CSL actually means in practice and how not to anger regulators.

“I want my organization to comply with yet another regulation” said no manager, but CSL is really important.

Society increasingly relies on IT systems for basic needs, such as buying food and accessing healthcare services. Sadly, these systems are increasingly exposed to cyber attacks, whether to exfiltrate data and illegally profit from it, or as part of a hybrid war strategy.

There are tons of reasons why security is hard from an engineering perspective. Nevertheless, each of these challenges have a solution. Unfortunately, implementing these solutions costs money, both in terms of cash and in terms of productivity. In a competitive market, all actors tend to optimize their costs, which leads to security being chronically deprioritized and underfunded. For example, the Swedish Civil Contingencies Agency (MSB) decided back in 2020 that all government entities should use Multifactor Authentication (MFA). However, this decision seems to have not been fully implemented as of beginning 2022.

Even a security-obsessed company will have a finite security budget. And security is expensive! Cyberattackers only need to find one sufficiently large security gap, whereas your organization needs to mitigate “all” security risks. Unfortunately, without a coordinated, industry-wide effort, no single organization will have the security intelligence required to take those security measures that bring the best “bang for the buck”. For example, the organization might need to decide whether it wants to invest in an anti-phishing solution or a full-day org-wide security awareness training. Perhaps it should invest in a cheaper anti-phishing solution combined with a half-day security awareness training. Without having a fuller picture of the current threat landscape, the organization can at best roll a die.

So, how can we ensure that all organizations:

• Invest enough in security; and
• Have access to sufficient security intelligence.

In other words, cybersecurity fails less because engineers don’t know what to do, and more because management hasn’t funded and prioritized it. That is the trend which Cybersäkerhetslagen aims to break.

Before diving into Cybersäkerhetslagen – often shorthanded to CSL – let’s put it into a broader context. CSL is an implementation of the EU NIS2 Directive, whose aim is to increase the overall level of cybersecurity across the European Union. Indeed, CSL is an integral part of Europe’s digital strategy, making sure that we can continue digitizing aspects of our society without shaking the foundations of our democracy.

NIS2 comes with a sector-specific EU regulation for the financial sector, called DORA. While we won’t go into details regarding DORA, the one take-away is that cybersecurity in the financial sector is separated already at the EU level, which will reflect at the Swedish level in the choice of supervisory agencies.

GDPR is an EU regulation which overlaps with NIS2 when it comes to personal data. Some GDPR provisions, in particular enforcement, EU-level enforcement coordination, security and incident reporting have analogies in NIS2 and CSL. However, there are some important differences:

• GDPR is a regulation and applies directly in all EU countries. In contrast, NIS2 needs to be implemented in national law, such as CSL in Sweden.
• GDPR is (as the “G” standing for “General” suggests) cross-sector and deals only with personal data, i.e., information which may cause harm to the privacy of a person.
• GDPR focuses on privacy, although Art. 32 “Security of Processing” does require a risk-based approach to security, which is very similar to NIS2/CSL.
• Maximum GDPR fines (€20 million or 4% of global annual turnover) are higher than the maximum fines under NIS2/CSL (€10,000,000 or 2% of the global annual revenue).

CSL is only concerned with what one would call civil defence. National defence, as regulated by Säkerhetsskyddslag, is explicitly carved out. Notice also, that requirements under Säkerhetsskyddslag are generally stricter than CSL.

CSL is operationalized by Cybersäkerhetsförordingen, which makes minor specifications, gives enforcement power to various Swedish authorities (see “Enforcement” below) and gives rule-making power to the MCF (Swedish Civil Defence and Resilience Agency – Myndigheten för civilt försvar) and PTS (Swedish Post and Telecom Authority – Post- och telestyrelsen).

Therefore, when someone refers to CSL, they are more likely referring to the body of rules issued by MCF and PTS (which are referred to as MCFFS and PTSFS, respectively), then the law itself. It is really the MCFFS and PTSFS-es which contain (or will contain) the detailed requirements that an organization will need to fulfill.

Cybersäkerhetsförordingen also designates MCF as the single contact point, the “router” if you will, for some of the CSL requirements, which we will discuss below.

Cybersäkerhetslagen applies to all entities of a certain size in sectors defined as essential and important according to the EU NIS2 Directive, as well as the state, regions and municipalities. Check out the image below to get an overview.

For sectors falling under the supervision of PTS, you may use their tool “Omfattas vi av CSL?” to make an exact determination.

On a high level, CSL requires you – an essential or important entity – to do 3 things:

• Identify (register) yourself
• Report incidents
• Take security measures

Let’s dive into each one of these. But first, who actually makes the rules?

For all entities, MCF acts as the single point of contact, which means that they provide the portal to handle registration and report incidents, which MCF will then make available to the relevant supervisory authorities.

However, Sweden seems to divide sectors into those which primarily sell digital services and those who use (but don’t sell) digital services. For example, an Internet service provider sells Internet, which is a digital service. In contrast, an energy company does not sell digital services – they sell electricity – although they are heavily relying on digital services both internally and towards their customers.

For lack of a better name, let’s call the former “ICT-selling sectors”. For such sectors, PTS makes rules on identification, incident reporting and security measures. These are:

• Digital infrastructure;
• ICT service management (business-to-business);
• Space;
• Postal and courier services;
• Digital providers.

For all other (“non-ICT-selling”) sectors under CSL, MCF makes the rules.

As an essential or important entity, you need to proactively identify yourself. Failure to do so can lead to way worse consequences than having a firewall with “allow all”.

Let us discuss what information you need to provide according to MCFFS 2026:1 and why:

1. Company name, address, email address, orgnr, phone number: This is standard information to identify a company and enables the regulators to reach you.
2. IP addresses and domain names: This is likely going to be used to proactively monitor breaches via an automated vulnerability scanning service, such as MCF’s ANTS.
3. Which essential and important sectors you operate in: This allows MCF to “route” the information to the correct supervisory authority.

Under CSL, your entity needs to report certain incidents and “near-misses” to MCF. The reporting needs to happen on a very strict timeline, so you already now should define or revise your processes accordingly:

• Initial report after 24 hours from the start of the incident;
• Interim report after 72 hours;
• Final report after 1 month;
• Potential follow-up reports if the incident is longer than 1 month.

What events are incidents under CSL? Here we need to go for the ICT-selling / non-ICT-selling split again.

For ICT-selling sectors, as of 2026-02-02, PTS has not drafted its own rules. Instead, it mandates the rules under Commission Implementation Regulation (EU) 2024/2690. For example a cloud computing provider will have to report an incident if:

• (a) a cloud computing service provided is completely unavailable for more than 30 minutes;
• (b) the availability of a cloud computing service of a provider is limited for more than 5 % of the cloud computing service’s users in the Union, or for more than 1 million of the cloud computing service’s users in the Union, whichever number is smaller, for a duration of more than one hour;
• (c) the integrity, confidentiality or authenticity of stored, transmitted or processed data related to the provision of a cloud computing service is compromised as a result of a suspectedly malicious action,
• (d) the integrity, confidentiality or authenticity of stored, transmitted or processed data related to the provision of a cloud computing service is compromised with an impact on more than 5 % of that cloud computing service’s users in the Union, or on more than 1 million of that cloud computing service’s users in the Union, whichever number is smaller.

For non-ICT-selling sectors, as of 2026-02-02, MCF plans to issue rules by April 2026. However, we may get a projection of how these rules will look like, by looking at examples on when incidents had to be reported under NIS1:

• In healthcare, if ambulance service was somehow affected. (MSBFS 2018:9 7 kap. 1 § 2).
• If a patient journal system is down for more than 2 hours. (MSBFS 2018:9 7 kap. 1 § 3).
• In the energy sector, if at least 2000 customers or 50% of your customers were affected for at least 2 hours. (MSBFS 2018:9 3 kap. 1 § 1).
• In the transportation sector, if at least 1000 users or a geographical region of at least 10000 km2 were affected for at least 1 hour. (MSBFS 2018:9 4 kap. 1 § 1).

As of 2026-02-02, the tool to register yourself still needs to be launched. (MCF points to their NIS1-era IRON tool for incident reporting, but which didn’t work when we tested.)

Under CSL, essential and important entities have to implement certain security measures. And, as you might have gotten used to, we need to go for the ICT-selling / non-ICT-selling split again.

For ICT-selling sectors, PTS has not produced its own rules and points instead to:

• EU NIS2 requirements, which can be summarized as:
  • Perform risk management (à la ISO 27001)
  • Fulfill 10 minimum requirements, such as incident handling, business continuity and multi-factor authentication
• Commission Implementing Regulation (EU) 2024/2690, which further specifies the NIS2 requirements into 13 top-level requirements, split into sub-requirements and sub-sub-requirements … a total of 206 requirements to fulfill.
• ENISA’s NIS2 Technical Implementation Guidance, which not only provides guidance, but also a really good mapping to ISO 27001:2022.

For the non-ICT-selling sectors, as of 2026-02-17, MCF plans to lay down rules by April 2026.

CSL puts a lot of emphasis on management responsibility. The management team needs to have training on cyber security, and is ultimately responsible for making sure that the entity takes cybersecurity seriously. Sure, the management team will not configure firewall rules, but they need to approve an information security policy. Of course, just having a paper won’t help. The management team also needs to make sure it has access to the required experts and to budget accordingly.

In short, CSL is like the Sarbanes–Oxley Act which emerged after the bankruptcy of Enron in 2002. Just as the board of directors and the management team needs to be literate in accounting, they now also need to be literate in cybersecurity.

While MCF acts like the CSL “router”, your regulators will actually be:

If you are already working in a regulated sector – say energy – you might already be familiar with your regulator – say Energimarknadsinspektionen. This sends a very clear message: CSL is not to be seen as a horizontal regulation, like GDPR. Instead, cybersecurity is another aspect of ensuring that certain sectors critical to society function as expected.

These regulators will already know you, since they have access to the registry of companies in their sectors via MCF. Similarly, they will know when an incident takes place via the reports you send to MCF and they receive.

So what will enforcement look like?

Essential entities will be audited on a periodic basis and will have to cover the costs of the audit. For important entities, the regulators will only act when they have a good reason to believe that is needed. Regulators will act according to an escalation ladder, that is “very Swedish”. In fact, if someone started reading this blog post from this sentence, they couldn’t determine if I’m writing about environment protection, work environment law or taxation laws. That ladder looks as follows:

1. Dialog phase: First, regulators will ask for information and clarifications, assuming that most Swedish companies are cooperative and take regulations seriously. Failing to respond on time or clearly will put regulators on their toes and can have serious consequences for you.
2. Injunctions (förelägganden): If that doesn’t work, regulators will take injunctions, which means they will formally require you to do something, such as correct your governance or take certain security measures. Injunctions may be accompanied by conditional fines (vite) along the lines of “if you don’t take security measures X by YYYY-MM-DD, then you must pay Z million SEK”.
3. Personal consequences (näringsförbud): If the company still does not comply, the regulator will turn against members of the management team, personally forbidding them from holding management roles. As with the rest of CSL, this clearly signals that cybersecurity is now treated as a board and management duty, not an IT issue.

Now that you are equipped with general knowledge about CSL, you might ask: Where do I even start?

We assume that your organization already assigned a person overall responsibility for CSL compliance, e.g., the CISO.

As a member of the management team, you are likely purchasing a lot of digital services, such as cloud infrastructure and managed services. Under CSL, you are responsible for the security posture of the services you depend on.

Therefore, we recommend you review your mission-critical suppliers through a CSL lens. Ask them how they perform risk management in line with NIS2/CSL and what security measures they implemented. If a supplier cannot clearly explain how they align with CSL or cannot present convincing evidence, that is already useful information.

In case you are in the process of buying new services, it’s a good idea to qualify suppliers based on their alignment with CSL. For example, if you are looking for an application platform, aim for one which is purpose-built for software critical to society, such as Welkin.

Welkin by Elastisys is a cloud-native application platform for software critical to society, built for security, compliance, and digital sovereignty in regulated and critical sectors. Developed in Sweden and fully under EU jurisdiction, Welkin runs consistently across any infrastructure and provides built-in regulatory controls. This enables teams to deploy and operate applications and AI workloads without cloud lock-in or platform complexity.

LEARN MORE

• Cybersäkerhetslag (2025:1506)
• Cybersäkerhetsförordning (2025:1507)
• MCFFS 2026:1 föreskrifter om anmälan och identifiering av väsentliga och viktiga verksamhetsutövare
• Tidsplan för införandet av cybersäkerhetslagen i Sverige, last accessed 2026-02-17
• Omfattas vi av CSL?, last accessed 2026-02-17
• Commission Implementing Regulation (EU) 2024/2690
• ENISA’s NIS2 Technical Implementation Guidance