AI, cybersecurity, and IT agreements – a guide for companies

By Mallbutiken · Facts verified September 30, 2026 · Approx. 12 minutes reading time

AI, data protection, SaaS agreements, NIS2, and continuity are not isolated islands of documentation. They meet in the same practical issues: which systems may be used, what data may be processed, what requirements should be imposed on the supplier, who is responsible for the risks, and how does the business continue if the service disappears?

Which document solves which issue?

AI policy and AI governance: manage usage and system risk separately

An AI policy primarily answers user questions: which tools are approved, what information may be entered, when is human oversight required, how is external publishing handled, and what does the employee do in the event of an incident?

AI governance is broader. There, the organization needs to be able to inventory AI systems, identify its role under the AI Act, assess use cases, assign responsibilities, and follow up on suppliers and changes over time.

The EU AI Act is risk- and role-based. Therefore, it is misleading to think that a single document "makes the company AI Act-compliant." The documentation needs to reflect which systems the organization actually develops, provides, or uses.

AI and personal data meet quickly

If an AI tool processes personal data, AI governance needs to be linked to GDPR processes. Check, among other things, the purpose, legal basis, roles for personal data, data minimization, third-country issues, and whether a Data Protection Impact Assessment (DPIA) under GDPR might be needed.

GDPR and DPA: start with the actual role

It is easy to treat a DPA (Data Processing Agreement) as an appendix that should always be sent to an IT supplier. The correct first step is instead to assess who determines the purpose and means of the personal data processing.

When the supplier processes personal data on the customer's behalf, Article 28 of the GDPR and binding regulations for the processor's treatment are triggered. The agreement needs to manage, among other things, instructions, security, sub-processors, support for the controller, deletion/return, and the possibility of auditing.

SaaS agreements: tie together service, data, security, and exit

A SaaS agreement should not stop at price and license. For a business-critical service, the main agreement needs to work together with the service specification, SLA, personal data, security requirements, subcontractors, liability, and exit.

Ask, for example:

• What exactly is included in the subscription?
• How is availability measured?
• Which incident levels and response times apply?
• Where is the data stored and which subcontractors are used?
• Which security controls can be verified?
• How can the customer export data and leave the service?

If the service processes personal data, the SaaS agreement is linked to the DPA. If the customer is covered by cybersecurity legislation, the security and supply chain requirements may need to be tightened further.

NIS2 and cybersecurity law: the supplier is part of the risk profile

The Swedish Cybersecurity Act (2025:1506) entered into force on January 15, 2026. For businesses covered by the act, security measures must address, among other things, risk analysis, incident management, operational continuity and crisis management, supply chain security, security in acquisition/development/maintenance, follow-up, cyber hygiene, cryptography, and access control.

This makes supplier management more than just a procurement issue. The organization needs to know which suppliers are critical, what dependencies they have, how incidents are communicated, and how security requirements are followed up.

Not all suppliers require the same demands

The work must be risk-based and proportionate. A marketing tool without sensitive data and an operating system that the entire core business depends on should not automatically be treated identically.

Therefore, build a simple supplier classification based on access, data sensitivity, operational dependency, concentration risk, and restoration. Let the classification guide due diligence, contractual requirements, and follow-up.

BIA and continuity plan: from requirements to actual resilience

Cyber and supplier requirements only help partially if the organization does not know which activities are most critical. A BIA (Business Impact Analysis) maps business-critical activities, consequences over time, and the resources that the activities require.

Thereafter, continuity plans are built to be able to continue or restore these activities when normal resources do not work.

The Swedish Civil Contingencies Agency's (MSB) methodology guidance describes impact analysis, risk assessment, measures, and continuity planning as parts of a cohesive continuity effort.

A practical workflow for companies

1. Inventory. List critical processes, IT services, AI systems, data flows, and suppliers.
2. Classify. Which information and activities are most worthy of protection or time-critical?
3. Assess roles and legal requirements. GDPR role, AI Act role, NIS2 applicability, and any sector requirements.
4. Prioritize gaps. Start where actual risk and business impact are greatest.
5. Manage internally. Policies, roles, approvals, and training.
6. Regulate externally. SaaS, DPA, security, and other supplier terms.
7. Plan for disruptions. BIA, contingency routines, and continuity plan.
8. Test and follow up. Documentation should lead to measurable control and improvement.

Example: the company introduces an AI-based HR system

One and the same purchase can require several perspectives. AI governance assesses the system's AI usage and risk. The AI policy specifies which functions employees may use. The GDPR assessment maps personal data and roles. The SaaS agreement regulates service, SLA, and exit. The DPA regulates processor treatment. The security assessment reviews access and the supply chain. The BIA determines how critical the system is to the business, and the continuity plan describes the contingency routine if the system goes down.

The point is not to create a maximum volume of documentation. The point is that the same actual system should be consistently managed in all relevant governance and contractual layers.

Management checklist

• Do we know which AI systems and critical IT services are actually being used?
• Is there an owner for every critical system and supplier?
• Have personal data roles and data flows been documented?
• Have we checked which systems may contain confidential information?
• Are there measurable SLA and security requirements where the business depends on the supplier?
• Are critical subcontractors and third-country flows known?
• Has the business identified its most time-critical activities?
• Are there realistic contingency routines and recovery targets?
• Are continuity and security tested in practice?
• Is there a routine for changes: new AI functions, suppliers, integrations, and contract terms?
• Does management receive recurring data on risks, incidents, and open actions?

Need to structure AI governance?

Mallbutiken's AI Governance package contains six Word/PDF templates and an AI register in Excel for, among other things, system inventory, risk assessment, supplier control, and management. Price in the shop: 199 SEK.

See the AI Governance packageSee AI templates

Deepen your knowledge by area