NIS2 and supplier agreements – which cybersecurity requirements should be agreed upon?

By Mallbutiken · Facts checked September 30, 2026 · Approx. 9 minutes reading time

For organizations covered by the Swedish Cybersecurity Act, supply chain security is an explicit area within the requirements for security measures. Supplier agreements therefore become an important tool for making security requirements, incident information, subcontractors, continuity, and follow-up concrete. However, the agreement does not replace the organization's own risk analysis or other NIS2 efforts.

What does the Cybersecurity Act say about the supply chain?

The Swedish Cybersecurity Act (2025:1506) entered into force on January 15, 2026, and implements parts of the NIS2 Directive. For operators covered by the Act, security measures must be appropriate and proportionate, based on an all-risk perspective, and provide a level of security commensurate with the risk.

Chapter 2, Section 3 lists the areas that security measures must at least address. This explicitly includes supply chain security, along with, among other things, incident handling, continuity and crisis management, secure acquisition and maintenance, monitoring of security measures, cyber hygiene, cryptography, access control, and authentication.

This does not mean that every supplier must receive the same annex or the same technical requirements. The requirements must be risk-based. A supplier with an administrative low-risk function should normally be assessed differently than one that operates a business-critical system, handles privileged access, or is essential for a critical service.

Start with supplier criticality

Before drafting contractual requirements, the organization should understand the dependency. A simple way is to classify the supplier based on the consequences if the service is lost, compromised, or starts delivering incorrect results.

Document the assessment. This makes it easier to justify why a critical supplier has more extensive requirements and more frequent follow-ups than a supplier with limited impact. To determine how quickly critical operations must be restored, you can use a BIA (Business Impact Analysis).

10 cybersecurity areas to regulate in supplier agreements

1. Defined security level. Describe which governing requirements, policies, or control areas the supplier must fulfill and for which part of the service.
2. Identity and access. Regulate principles for authorization, privileged accounts, MFA, access reviews, and account termination where relevant.
3. Vulnerabilities and patching. Specify how vulnerabilities are discovered, prioritized, addressed, and communicated.
4. Logging and traceability. Determine which logs are needed, how long they are stored, and how the customer can receive relevant documentation during an incident.
5. Incident information. Specify when and how the supplier must notify the customer, what information must be provided, and how updates are handled.
6. Continuity and restoration. Regulate backups, restoration, backup routines, testing, and relevant RTO/RPO values.
7. Subcontractors. Determine which critical subcontractors are permitted, how changes are notified, and which requirements must be passed on down the chain.
8. Verification. Specify which documentation, audits, test results, or other evidence the customer can use for follow-up.
9. Changes. Regulate major technical or organizational changes that could affect the risk profile.
10. Exit. Determine how access is terminated, data is returned or deleted, and how migration is carried out without unnecessary security or continuity gaps.

Incidents: the agreement must support the customer's own handling

When a supplier detects an incident, the customer must receive information quickly enough to assess their own impact and any potential reporting obligations. Therefore, avoid vague wording that only states that the supplier informs "as needed."

Instead, determine which events must be reported contractually, contact routes, initial information levels, and how supplementary information is provided. For example, request information about affected systems, timelines, preliminary impact, implemented mitigation measures, and known dependencies.

Subcontractors: map critical dependencies

A service can in practice consist of several layers: SaaS provider, cloud infrastructure, identity provider, support partner, and other components. Focus on the subcontractors that actually affect the service's security or continuity.

The agreement can, for example, regulate requirements for advance notice when changing critical subcontractors, which security requirements must be passed on, how incident information flows through the chain, and what measures the customer is entitled to if the risk profile changes significantly.

If personal data is processed, the GDPR's rules on sub-processors apply when the relationship is a data processing agreement. Read the guide on DPA and sub-processors.

How to follow up on a supplier's security requirements?

A contractual requirement that is never followed up has limited value. Choose a control method based on risk. For a critical supplier, it may be relevant to have recurring security meetings, audit reports, certification documentation, vulnerability information, continuity tests, or specific evidence of measures.

This does not mean that the customer should always be granted unlimited physical audits. The agreement can create a tiered approach: standardized documentation first, supplementary questions in case of deviations, and more intrusive verification when the risk or an incident justifies it.

Certification is a basis – not the entire assessment

A certification or external report can provide valuable information, but check the scope. Which systems, locations, and services are covered? Is the report current? Are there exceptions or remarks? Does it match what you are actually purchasing?

Continuity: the contractual requirement must match business needs

If the supplier supports a critical activity, their restoration capability should be compared with the business's own goals. A continuity plan can describe backup routines when the supplier cannot deliver; the supplier agreement should, in turn, specify the requirements the supplier must actually fulfill.

SaaS supplier? Coordinate the security annex with the main agreement

For cloud services, security requirements must work together with the SLA, support, data, subcontractors, liabilities, and exit. Conflicting annexes create new risks. Read what a SaaS agreement should contain and feel free to specify which document takes precedence if the contractual documents state different things.

Pre-agreement checklist with a critical supplier

• Has the supplier been classified based on criticality and dependency?
• Are the most important systems, data flows, and accesses identified?
• Are the security requirements proportionate and verifiable?
• Is there a clear incident contact and requirements for prompt initial information?
• Are subcontractors and changes in the chain regulated?
• Are there requirements for vulnerability and patch management?
• Are backup, restoration, and continuity testable?
• Is there a reasonable way to follow up on compliance?
• Is exit, data return, and access termination planned?
• Is the agreement coordinated with GDPR/DPA, SLA, and other relevant annexes?

Need to structure your NIS2 work?

Mallbutiken's NIS2 package contains 15 integrated document templates for risk management, incidents, continuity, supplier security, and security annexes to supplier agreements, among others. Delivered in Word and PDF. Store price: 199 SEK.

See the NIS2 template package

Frequently asked questions

Are all suppliers covered by NIS2?

No. The direct scope of the Cybersecurity Act depends on, among other things, the type of operation and other criteria. However, a supplier that is not directly covered may still face contractual requirements from a customer that needs to manage their supply chain risk.

Is it enough to require ISO 27001?

No, not as a general solution. A certification can be relevant evidence, but the customer still needs to assess the specific service, the scope, the dependencies, and what security requirements are needed.

Must all suppliers receive the same security annex?

No. The law is based on appropriate and proportionate measures in relation to the risk. A risk-based supplier program should therefore distinguish between different levels of criticality.