Cybersecurity 28 Oct 2026 · 5 min read

Contracts signed before 1 October: what Sweden's new NIS2 rules ask of your suppliers

On 1 October 2026, new regulations under Sweden's Cybersecurity Act (cybersäkerhetslagen) took effect. Much of the attention has gone to management training and incident reporting. But one paragraph will land on many IT and procurement desks this winter: operators must identify whether agreements signed before 1 October need to be supplemented with cybersecurity requirements – and handle the risk where they cannot be.

For most organisations, that means going back to the cloud, hosting, SaaS and outsourcing contracts already in place. Here is what the rules say, and what we think makes the work worthwhile rather than just more paperwork.

What the new rules require

The regulations in question are MCFFS 2026:11: regulations and general advice from Myndigheten för civilt försvar (MCF) on security measures and management training for essential and important operators. They apply to most covered sectors, including healthcare and public administration. Operators in digital infrastructure and ICT service management largely follow EU-level rules instead, so check which regime applies to you.

Chapter 4 covers acquiring systems and outsourcing information processing. In short, the operator must:

assess and handle the risks before acquiring a system or outsourcing processing
make sure the supplier meets the same requirements the operator itself is subject to, unless the operator covers them fully
evaluate whether the supplier can meet those requirements for the whole contract period
identify and handle the need to supplement agreements made before 1 October 2026, where possible, and manage the risks of agreements whose requirements are insufficient
manage continuity in its digital supply chains, including information about the supplier's own subcontractors
consider choosing products and services certified under European cybersecurity certification schemes

The general advice – not binding, but a clear signal of what supervisors will look for – lists what an outsourcing agreement should cover. That includes a named system owner at the supplier, when and how the supplier reports incidents, threats, vulnerabilities and changes, how risks from subcontractors are handled, joint incident and continuity exercises, how compliance is followed up, a right to terminate early if the supplier falls short, and how your information is returned or destroyed when the agreement ends.

One more line is worth noticing: when assessing supply-chain risk, operators should also consider authorities' recommendations aimed at strengthening EU and Swedish digital sovereignty. Sovereignty has moved from political debate into supervisory guidance.

Why a contract review alone is not enough

Many contract clauses are only as strong as the architecture behind them. Three examples:

Termination rights. A right to leave a supplier early is worth little if you cannot actually move. If your workloads depend on one provider's proprietary services, the clause gives you a negotiating position, not an exit.

Return of information. "The supplier shall return the data" says nothing about format, completeness or time. Does it include logs, backups, configuration and audit trails? Can anything you get back be loaded somewhere else?

Incident reporting. You have 24 hours to make an initial report of a significant incident to the NCSC. If your supplier's contract allows them 72 hours to tell you, the timelines do not fit. Your own monitoring needs to see enough not to depend entirely on the supplier's notice.

A practical way to approach the review

Supervision has so far been mostly desk-based, and no sanction fees had been imposed as of the summer, according to Vinge's review. That is a window to do this properly rather than in a hurry.

List suppliers by what they process. Start with those that handle classified or sensitive information, or run systems you cannot operate without. Include support and remote-access arrangements – they are processing too.
Map the subcontractors. For cloud and SaaS, ask which parties and jurisdictions can actually reach your data, including operations and support staff.
Compare each contract with the general advice. Note the gaps rather than trying to fix everything at once.
Renegotiate where you have leverage. Large providers often offer only standard terms. Where you cannot change the contract, the regulation still asks you to handle the risk.
Compensate technically where the contract falls short. Encryption with keys you control, backups held outside the provider, your own logging, and infrastructure defined as code so an environment can be rebuilt elsewhere.
Test the exit at least once. Restore a backup somewhere else, or rebuild a non-production environment on another platform. A tested exit path is evidence; a clause is a promise.
Record the decisions. Where you accept a risk, write down why and who decided it. That is what management is now expected to approve and follow up.

Avoid the most expensive binder in Sweden

There is a real risk that NIS2 mainly produces documentation. A spreadsheet of contract gaps that nobody acts on does not make anyone more resilient. The value lies in the decisions it forces: which suppliers you truly depend on, what you would do if one disappeared, and whether your architecture lets you act on that.

Done well, the same work also prepares you for the EU's proposed Cloud and AI Development Act, which raises many of the same questions about control, jurisdiction and portability.

Entit helps organisations in healthcare and the public sector connect supplier requirements with the architecture that makes them real. If you are starting your contract review, we are happy to compare notes.

Sources

Discuss this with us