En integration med Microsoft 365 kopplar era verksamhetssystem till Outlook, Teams, SharePoint och OneDrive så att information flödar utan manuellt arbete. Tekniken går oftast snabbt att sätta upp. Svårare är att styra vilka data integrationen kommer åt och vem som ansvarar för dem. Den behöver också klara kraven i GDPR och NIS2. Den här guiden går igenom de vanligaste integrationsmetoderna och hur ni begränsar behörigheter. Den visar också vilka juridiska frågor som måste vara besvarade innan en koppling går i drift, och hur ni dokumenterar arbetet så att det håller vid en granskning.
Kort sagt
- Det finns fem huvudvägar att integrera med Microsoft 365: inbyggda appar, Power Automate, connectors och webhooks, appar från tredje part och egenbyggda lösningar via Microsoft Graph.
- Varje integration gör er attackyta större. Principen om minsta privilegium och ett styrt godkännande av appbehörigheter är grundkrav, inte bara rekommendationer.
- Behandlar integrationen personuppgifter behöver ni ha klarlagt rollerna (personuppgiftsansvarig eller personuppgiftsbiträde), ha biträdesavtal på plats, ha ett giltigt överföringsverktyg vid tredjelandsöverföring och ofta också en DPIA.
- Under NIS2 räknas integrationer mot tredjepartsleverantörer in i leveranskedjan, och det är ledningen som bär ansvaret.
- Dokumentera varje integration i registerförteckningen, riskanalysen och leverantörsbedömningen, och följ upp den löpande.
Innehållsförteckning
- Vad en integration med Microsoft 365 är
- Välj integrationsmetod efter risk, inte bara bekvämlighet
- Behörigheter: minsta privilegium i praktiken
- Juridiken bakom integrationen
- NIS2: integrationen är en del av leveranskedjan
- Steg för steg: från behov till godkänd integration
- Exempel: ärendehantering kopplad till Outlook och SharePoint
- Vår syn: integrationen är en efterlevnadsfråga
- Samla integrationerna i en plattform
- Vanliga frågor
- Källor
Vad en integration med Microsoft 365 är
Med integration menas att en extern funktion eller ett externt system kopplas till Microsoft 365, så att data eller funktioner kan användas på båda sidor. Det kan vara ett CRM-system som hämtar kalenderdata från Outlook, ett ärendehanteringssystem som sparar dokument i SharePoint eller en bot som postar aviseringar i en Teams-kanal.
Microsoft Graph beskrivs av Microsoft som den teknikplattform organisationer använder för att koppla sina affärssystem till data och tjänster i Microsoft 365. De flesta integrationer går i slutändan via Graph, även när användaren aldrig ser det, eftersom ett färdigt gränssnitt eller ett lågkodsverktyg ligger ovanpå.
I praktiken finns fem vanliga sätt att bygga en integration:
- Inbyggda Microsoft 365-appar, till exempel Planner, Forms eller Lists i Teams.
- Power Automate-flöden, alltså automatiseringar utan kod som flyttar data mellan tjänster.
- Connectors och webhooks, som skickar händelser från ett externt system in i en kanal eller ett flöde.
- Tredjepartsappar som installeras via Microsofts appbutik.
- Egenbyggda lösningar via Microsoft Graph API, där ert eget system anropar Microsoft 365 direkt.
När team väljer samarbetsverktyg handlar det ofta om vilka integrationer som redan finns. En jämförelse mellan Slack och Teams visar hur mycket integrationsutbudet väger in när organisationer bestämmer sig för en plattform. För juridiska verksamheter, som kopplar ärende- och dokumenthantering till sin e-post och sina filytor, blir valet särskilt viktigt.
Välj integrationsmetod efter risk, inte bara bekvämlighet
Alla fem metoderna kan ge samma synliga resultat för användaren. Skillnaden ligger i hur mycket kontroll ni har och hur mycket förvaltning lösningen kräver. Tabellen sammanfattar de avvägningar som brukar avgöra valet.
| Metod | Typiskt användningsområde | Förvaltningsinsats | Compliance-frågor att besvara |
|---|---|---|---|
| Inbyggda appar | Uppgifter, formulär, listor i Teams | Låg | Var lagras data, vem har åtkomst? |
| Power Automate | Automatiska flöden mellan tjänster | Låg till medel | Vem äger flödet, vilka konton körs det med? |
| Connectors och webhooks | Aviseringar från externa system | Låg till medel | Vilken information skickas ut, till vilken mottagare? |
| Tredjepartsappar | Specialfunktioner från externa leverantörer | Medel | Leverantörsbedömning, biträdesavtal, tredjeland |
| Egenbyggt via Graph API | Koppling mellan affärssystem och Microsoft 365 | Hög | Behörighetsmodell, loggning, säkerhetstester |
Egenbyggda lösningar via Graph API ger mest flexibilitet, men också störst ansvar. Microsoft rekommenderar i sina riktlinjer för Microsoft Graph bland annat att varje anrop ska ha ett unikt GUID i fältet client-request-id som loggas, så att felsökning och supportärenden kan spåras. Samma vägledning pekar på Graph Explorer som det enklaste sättet att utforska vilka data som finns tillgängliga, innan någon kod skrivs.
För flöden med många anrop går det att samla förfrågningar i batchar via egna connectors i Power Automate. Det ger bättre prestanda, men ökar samtidigt antalet ställen där behörigheter och data hanteras. Varje sådan connector behöver alltså en ägare och en dokumenterad syftesbeskrivning.
En tumregel för val av metod
Välj den enklaste metoden som löser behovet. En inbyggd app eller ett Power Automate-flöde med begränsade behörigheter är lättare att granska än en egenutvecklad tjänst med bred åtkomst till hela organisationens e-post. Egenutveckling är rätt när behovet kräver det, inte för att det är tekniskt möjligt.
Behörigheter: minsta privilegium i praktiken
En integration med Microsoft 365 är lika säker som de behörigheter den har fått. Microsoft anger att principen om minsta privilegium alltid ska tillämpas när affärssystem kopplas via Graph. Det innebär att integrationen bara ska ha åtkomst till de data den behöver för sitt syfte, och inget mer.
Två behörighetstyper är centrala:
- Delegerade behörigheter används när en inloggad användare finns. Integrationen agerar då för användarens räkning och når bara det användaren själv har rätt att se.
- Applikationsbehörigheter används när ingen användare är inloggad, till exempel i bakgrundsjobb. Integrationen kan då få åtkomst till data i hela organisationen.
Risken uppstår när applikationsbehörigheter används i interaktiva scenarier där en användare faktiskt finns. Det kringgår de policyer administratören har konfigurerat och ökar risken. En integration som bara behöver läsa en användares kalender ska alltså inte ha läsrätt till alla postlådor.
Konkreta kontroller som bör finnas på plats:
- Användare ska inte själva kunna godkänna appar som begär åtkomst till organisationens data. Begäran ska gå via en styrd godkännandeprocess.
- Varje registrerad app ska ha en namngiven ägare i verksamheten, inte bara i IT.
- Behörigheter ska ses över regelbundet, till exempel kvartalsvis, och tas bort när integrationen inte längre används.
- Hemligheter och certifikat för appregistreringar ska ha utgångsdatum och förnyas enligt en rutin.
- Anrop och ändringar ska loggas så att det går att visa i efterhand vad integrationen har gjort.
Juridiken bakom integrationen
Tekniken avgör vad integrationen kan göra. Juridiken avgör vad den får göra. För dataskyddsombud och jurister är det här som det mesta av arbetet ligger.
Personuppgiftsansvarig eller personuppgiftsbiträde
När Microsoft 365 kopplas till en tredjepartstjänst uppstår ofta en kedja av aktörer: er organisation, Microsoft och leverantören av den externa tjänsten, ibland med egna underbiträden. IMY:s undersökning av hur sju myndigheter använder molntjänster lyfter fram att osäkerhet kring rollfördelningen mellan personuppgiftsansvarig och personuppgiftsbiträde är en riskfaktor. Samma undersökning visar att myndigheterna upplever en obalans i förhandlingsstyrka mot stora molnleverantörer, vilket gör det svårt att påverka avtalsvillkoren.
För varje integration behöver ni därför kunna svara på:
- Vem bestämmer ändamål och medel för behandlingen?
- Finns ett biträdesavtal med leverantören av den externa tjänsten, och täcker det just den här behandlingen?
- Vilka underbiträden används, och hur informeras ni om ändringar?
Kraven på inbyggt dataskydd gäller också här. Kraven på inbyggt dataskydd enligt artikel 25 innebär att dataminimering och begränsad åtkomst ska ingå redan i designen av integrationen, inte läggas till i efterhand. Vår guide om personuppgifter i Microsoft 365 går djupare in på vad svenska organisationer behöver göra i själva plattformen.
Tredjelandsöverföring och telemetri
Med överföring till tredjeland menas att personuppgifter skickas eller görs tillgängliga för en mottagare utanför EU/EES. Det kräver ett överföringsverktyg enligt kapitel V i GDPR, till exempel standardavtalsklausuler eller ett beslut om adekvat skyddsnivå.
I praktiken missas ofta två saker. Den första är att tredjepartsappen kan lagra eller behandla data i ett annat land än Microsoft 365. Den andra är att diagnostik- och telemetridata också kan innehålla personuppgifter och därför behöver omfattas av analysen. IMY påpekar dessutom att leverantören kontrollerar utrustningen som lagrar informationen, och att leverantörens personal och underleverantörer därför kan få tillgång till den. Läs mer i vår genomgång av tredjelandsöverföringar enligt GDPR.
Konsekvensbedömning när risken är hög
En integration som behandlar känsliga personuppgifter, övervakar anställda eller kopplar ihop stora datamängder från flera system kan kräva en konsekvensbedömning (DPIA) innan den tas i drift. Granskningen ska inte göras en gång vid upphandling och sedan glömmas bort, utan löpande, särskilt när leverantören ändrar sina villkor eller funktioner. Använd vår guide om när DPIA krävs för att avgöra frågan, och DPIA-processen steg för steg när ni ska genomföra den.
Granskningar av Microsofts molntjänster i svensk offentlig sektor är inget nytt. När IMY (dåvarande Datainspektionen) granskade Ale kommuns användning av Office 365 i skolverksamheten uppfyllde kommunen kraven i personuppgiftslagen, med ett undantag. Granskningen visar att tillsynsmyndigheten bedömer hur verksamheten använder tjänsten, inte bara tjänsten i sig.
NIS2: integrationen är en del av leveranskedjan
För verksamheter som omfattas av NIS2 är en integration med en extern leverantör mer än en IT-fråga. Direktivet ställer betydligt skärpta krav på säkerheten i leveranskedjan, och integrationer med tredjepartsleverantörer via Microsoft 365 räknas in i den. Enligt MSB:s vägledning bär ledningen ett tydligt ansvar för att kontrollera säkerheten i hela den digitala leveranskedjan, inte bara i den egna IT-miljön.
En tredjepartsapp med bred åtkomst till e-post och dokument kan bli den svaga länken. Om leverantören drabbas av ett intrång kan angriparen nå era data via den behörighet ni själva har gett. Därför bör varje integrationsleverantör bedömas på samma sätt som andra kritiska leverantörer:
- Vilka säkerhetsåtgärder och certifieringar kan leverantören visa?
- Hur och hur snabbt rapporterar leverantören incidenter till er?
- Vilka data når integrationen, och vad blir konsekvensen om den komprometteras?
- Finns det en plan för att stänga av integrationen snabbt?
Vi beskriver kraven närmare i NIS2-krav på leverantörskedjan och i artikeln om varför det inte räcker att säkra den egna IT-miljön.
Steg för steg: från behov till godkänd integration
En strukturerad process gör att samma frågor ställs varje gång, oavsett om det är IT, HR eller juristavdelningen som vill koppla in ett nytt verktyg.
- Beskriv behovet och ändamålet. Vad ska integrationen göra, för vem och med vilka data?
- Välj metod. Börja med den enklaste metoden som löser behovet och motivera ett eventuellt val av egenutveckling.
- Kartlägg dataflödet. Vilka personuppgifter flyttas, var lagras de och passerar de gränsen till ett tredjeland?
- Fastställ roller och avtal. Klargör ansvarsfördelningen och säkerställ att biträdesavtal och överföringsverktyg finns.
- Gör en riskbedömning. Bedöm risker för informationssäkerhet och för de registrerades rättigheter, och gör en DPIA om kriterierna är uppfyllda.
- Bedöm leverantören. Gå igenom säkerhet, incidenthantering och underleverantörer, särskilt om ni omfattas av NIS2.
- Begränsa behörigheterna. Ge minsta möjliga åtkomst och låt en administratör godkänna den.
- Dokumentera. Uppdatera registerförteckningen, riskregistret och leverantörsförteckningen.
- Tilldela ansvar och följ upp. Utse en ägare, sätt datum för översyn och följ upp åtgärder tills de är stängda.
Punkt 9 är den som oftast brister. Det finns en ägare när integrationen godkänns, men ingen som tittar på den när leverantören ändrar villkor ett år senare. Vår guide om åtgärdsuppföljning inom compliance visar hur ni håller ordning på det.
Exempel: ärendehantering kopplad till Outlook och SharePoint
Scenario. En advokatbyrå vill koppla sitt ärendehanteringssystem till Microsoft 365, så att e-post i Outlook automatiskt sparas i rätt ärende och dokument hamnar i en SharePoint-plats per klient.
Så här ser bedömningen ut i praktiken:
- Metod: Leverantören erbjuder en färdig app som använder Graph API. Det kräver ingen egenutveckling, men appen begär läsrätt till alla postlådor.
- Behörighet: Byrån kräver att åtkomsten begränsas till de postlådor som hör till jurister och assistenter, och att godkännandet görs av en administratör.
- Roller: Leverantören är personuppgiftsbiträde. Biträdesavtalet kompletteras så att det omfattar den nya behandlingen och leverantörens underbiträden.
- Tredjeland: Leverantören använder en driftleverantör utanför EU/EES för support. Standardavtalsklausuler och en överföringsanalys tas fram.
- DPIA: Eftersom klientkorrespondens kan innehålla känsliga uppgifter och uppgifter om lagöverträdelser genomförs en DPIA.
- Uppföljning: IT-chefen blir ägare och behörigheterna ses över varje kvartal.
Resultatet är en integration som sparar tid för juristerna och som byrån kan försvara vid en granskning.
Vår syn: integrationen är en efterlevnadsfråga
Vi möter ofta organisationer där integrationer med Microsoft 365 har vuxit fram en i taget. Någon på marknadsavdelningen kopplade in ett verktyg, IT byggde ett flöde i Power Automate, och HR fick en ny app i Teams. Var för sig är de små. Tillsammans blir de ett nätverk av dataflöden som ingen har full överblick över.
Vår erfarenhet som jurister är att problemet sällan är tekniken. Problemet är att den juridiska bedömningen, riskanalysen och leverantörsgranskningen görs i olika dokument av olika personer, om de alls görs. När IMY eller en kund frågar hur en viss integration hanterar personuppgifter tar det veckor att få ihop svaret.
Vi menar att varje integration ska behandlas som en behandling i registerförteckningen, som en risk i riskregistret och som en leverantör i leverantörsbedömningen, med samma ägare och samma uppföljning. Det låter administrativt, men med strukturerade arbetsflöden blir det mindre arbete, inte mer. Det är dessutom det enda sättet att visa att ledningen har kontroll, vilket NIS2 uttryckligen kräver.
— Jesper
Samla integrationerna i en plattform
Trustview är en svenskutvecklad plattform för compliance, dataskydd och informationssäkerhet, byggd av jurister. I plattformen kan du automatisera registerförteckningen enligt GDPR, göra DPIA och TIA, logga risker och incidenter, bedöma leverantörer och delegera ansvar. Du följer också upp åtgärder och får realtidsöversikt över compliance-status för GDPR, NIS2, ISO 27000 och AI-förordningen. Färdiga mallar och guider hjälper dig att komma igång, och vid behov finns lokal juridisk rådgivning som tillägg. Prenumerationen kostar från 2 500 kr per månad.
Vanliga frågor
Vilka program ingår i Microsoft 365?
Vilka program som ingår beror på abonnemanget, men företagsplanerna bygger i regel på Outlook, Teams, Word, Excel, PowerPoint, SharePoint och OneDrive. Kontrollera alltid den aktuella planen i Microsofts administrationscenter, eftersom innehållet ändras över tid. Ur ett integrationsperspektiv är det framför allt Outlook, Teams och SharePoint som externa system kopplas mot.
Behöver vi göra en DPIA för varje integration?
Nej, en DPIA krävs när behandlingen sannolikt leder till hög risk för de registrerades rättigheter, till exempel vid känsliga uppgifter, systematisk övervakning eller sammankoppling av stora datamängder. Däremot bör varje integration få en grundläggande riskbedömning och dokumenteras. Använd våra riskkriterier för DPIA för att avgöra var gränsen går.
Hur avslutar man Microsoft 365?
Prenumerationer kan avslutas via administrationscentret för Microsoft 365, och därefter tas data bort enligt Microsofts kvarhållningsregler. Har ni köpt via en partner behöver ni vända er till partnern. Kostnadsfria utvärderingsversioner övergår automatiskt till betald prenumeration efter 30 dagar om de inte avslutas i tid. Kontrollera innan dess att integrationer som är beroende av tjänsten stängs av och att data exporteras.
Vem i organisationen ska äga en integration?
Ägaren bör sitta i den verksamhet som använder integrationen, med stöd från IT för det tekniska och från dataskyddsombudet för det juridiska. Det viktiga är att det finns en namngiven person som ansvarar för behörigheter, avtal och översyn. Utan ägare blir integrationen kvar långt efter att behovet har försvunnit.
Källor
- Microsoft Learn: Common integration patterns with Microsoft Graph
- Microsoft Learn: Best practices for working with Microsoft Graph
- Microsoft 365 Developer Blog: Batch requests with Power Automate custom connectors
- Wintive: Microsoft Teams Integration, 2026 Admin Guide
- IMY: Användning av molntjänster inom offentlig sektor
- IMY: Överföring till tredjeland
- IMY: Säker användning av molntjänster
- IMY: Granskning av molntjänsten Office 365
- MSB: Vägledning om säkerhet i leveranskedjan
- Microsoft Support: Avsluta en Microsoft 365-prenumeration
