On 1 October, the regulations on security measures and management training take effect. Anyone who reads them as a checklist will plan badly. The key lies in how the requirements are worded.
When a new regulation arrives, it is natural to look for the requirements and start ticking boxes. With MCFFS 2026:11, which sets out the security measures required under the Swedish Cybersecurity Act, it does not quite work that way. The regulation uses different formulations that mean different things, and the difference determines how much work lies ahead and what a supervisory authority will ask about.
The wording that demands the most thought is neither shall (ska) nor should (bör). It is where the entity has to identify and manage the need for something (identifiera och hantera behovet av).
Check first whether the whole regulation applies to you. Entities working exclusively in digital infrastructure, digital providers, ICT service management between businesses, postal and courier services or space are covered only by the management training requirement.
Shall means shall
Where the regulation says an entity shall do something, there is no room for judgement. The requirement applies.
This covers appointing a coordinator and keeping an action plan. Every system has to have a system owner, and all information processing an information owner. Management has to be informed of the current state at least once a year. On the technical side it covers multi-factor authentication, for system administration access and for staff and supplier access over external networks, along with segmentation, intrusion detection in the IT segment of the production environment, and prompt handling of security updates.
This is the floor. It is also the easiest part to understand, even if not always easy to implement.
Should is advice, but not empty advice
The regulation also contains general advice, written with the word should. It is not binding. Its purpose is to clarify how the requirements can be met.
In practice it still matters. This is where you find the reference to ISO/IEC 27001 and 27002, the advice to begin security updates within 72 hours, and to exercise crisis management annually. The general advice describes what the authority considers a reasonable level.
You are free to do it differently. But then you need to explain why, and show that it achieves the same purpose.
Identify and manage the need is the core
This wording recurs throughout the regulation, particularly in the chapters on technical and physical measures. It applies to backups, redundant functions, real-time monitoring, encryption, crisis organisation and software allowlisting.
It means two things.
First, you have to assess whether the need exists. That assessment must be based on your own situation, supported by information classification and risk analysis and monitoring of the threat landscape.
Then you have to act on what you concluded. If the need exists, the measure has to be implemented. If not, the conclusion and the reasons must be documented.
This is where many will go wrong. It is easy to read the wording as a softer version of should, as optional. It is not. The measure may not always be needed, but the assessment is. An organisation that has never taken a position has a deficiency, even if the answer would have been no.
Backups are a good example. The regulation does not explicitly require you to take backups. It requires that information can be restored within defined timeframes, and that you identify and manage the need for them. Almost nobody will conclude it is absent. But the decision has to be yours, deliberate and traceable.
A fourth nuance that is easy to miss
A number of requirements are worded as shall, unless it is obviously unnecessary. This covers connection to CERT-SE’s service for automated vulnerability notifications (ANTS), DNSSEC for your own domains, parts of the security logging in the production environment, and surveillance of premises.
This is not a needs assessment. The starting point is that the requirement applies. The exemption requires it to be obvious that the measure is unnecessary, and the burden of proof falls on you. The threshold is high.
What a good needs assessment contains
The regulation says decisions, analyses and assessments should be documented and retained for supervisory purposes. A needs assessment that holds up need not be long, but it must answer a few basic questions.
- Which requirement and which part of the environment the assessment covers
- What it is based on, for example a risk analysis or information classification
- What you concluded, and why
- Who made the decision, and when
- When the assessment is to be reviewed again
That last point is easy to forget. An assessment that was right a year ago can be wrong today. The threat landscape changes, the systems change, the business changes. The regulation explicitly requires you to identify and manage the need to update your risk analyses when threats change and new vulnerabilities appear. More on that in Proportionality has an expiry date.
Common pitfalls
The most common is treating needs-assessed requirements as optional and leaving them last. The second is making the assessment in your head and never writing it down.
Other pitfalls are letting someone without the mandate to accept the risk make the assessment, never revisiting it, and overlooking the difference between IT and OT. Several requirements that are absolute for IT segments are needs-assessed for OT segments. That gives industrial operations reasonable room, but does not exempt them from the assessment.
Why the design is sensible
It is easy to be irritated by a regulation that gives no straight answers. But the design is deliberate.
A detailed list of absolute requirements would have suited some organisations and been unreasonable for others. By requiring assessments instead of measures, it gives each organisation room to be proportionate. At the same time, supervision gets something concrete to examine: how you reasoned.
It shifts the centre of gravity from technology to governance. The question is not only what you have implemented, but whether you know why, and whether the right person decided it. That is exactly how cybersecurity should be handled.
How to get started
Start by sorting the requirements by how they are worded. You will quickly see what is absolute, what requires an assessment and what is advice.
Then secure the foundations. Without criteria for risk acceptance, a completed information classification and appointed owners, credible needs assessments are impossible. Produce a simple template and decide who is allowed to make which decisions. Have management approve the framework.
Do not wait for the guidance. The requirements apply from 1 October, while the NCSC’s regulatory guidance is not due until the end of the year. A documented interpretation today beats no interpretation at all.
Three things to take away
Sort the requirements by wording before you plan. Absolute requirements, needs-assessed requirements and general advice call for different work and different amounts of time.
The needs assessment is a requirement in its own right. The conclusion may be that nothing needs doing, but it has to exist and be possible to show.
An assessment has a shelf life. Decide when it will be reviewed at the moment you make the decision, not when the supervisory authority asks.
Sources
- MCFFS 2026:11, regulations and general advice on security measures and management training for essential and important entities, decided 15 June 2026; responsibility passed to the NCSC at FRA on 1 July 2026
- The Swedish Cybersecurity Act (SFS 2025:1506)
- The Swedish Cybersecurity Ordinance (SFS 2025:1507)
- Government Bill 2025/26:28, Strong protection for network and information systems. A new cybersecurity act
- SS-ISO/IEC 27001:2022 and SS-EN ISO/IEC 27002:2022
Want to know where you stand on MCFFS 2026:11? VER&IT helps organisations with gap analysis, needs assessments and management training under the Swedish Cybersecurity Act. Book a free consultation.
More insights
Related articles
Six frameworks. One governance structure. No excuses.
NIS2, GDPR, DORA, CRA, AI Act and the Cybersecurity Act impose overlapping requirements. Five signs your governance falls short.
Alone with the responsibility. The security coordinator who never got a mandate.
One person. No mandate. No resources. That's the reality for information security coordinators in Swedish municipalities.
The Cybersecurity Act and leadership accountability. Are the rules really the same for everyone?
The Swedish Cybersecurity Act imposes the same requirements on public and private sectors, but the consequences for non-compliance differ significantly. We examine what this means for leadership accountability.