API för compliance: säkerhet, loggning och SSO i praktiken

API och compliance hänger ihop på två sätt. Det första gäller era egna API:er. De flyttar personuppgifter och verksamhetskritisk information mellan system och måste därför uppfylla samma krav på säkerhet, behörighetsstyrning och spårbarhet som resten av er it-miljö, enligt GDPR och i många fall den nya cybersäkerhetslagen. Det andra gäller ert compliancearbete, som blir mer effektivt när systeminventering, incidenter, leverantörer och åtgärder kan hämtas och uppdateras automatiskt i stället för att föras för hand. Den här guiden går igenom båda delarna, med de krav som svenska myndigheter faktiskt ställer och de frågor du bör ställa till en leverantör, inklusive frågor om SSO.

Kort sagt

• Ett API är ett gränssnitt för maskinellt informationsutbyte mellan system. Därmed ska det omfattas av er riskanalys, er registerförteckning och er behörighetsstyrning.
• Svenska myndigheters riktlinjer ger en tydlig miniminivå: HTTPS med minst TLS 1.2, autentisering och auktorisation när åtkomsten är begränsad, samt auditloggar vid säkerhetsrelaterade händelser.
• Cybersäkerhetslagen (NIS2) trädde i kraft den 15 januari 2026 och skärper kraven på säkerhetsåtgärder, även för integrationer och leverantörskedjan.
• SSO med flerfaktorsautentisering är en compliancekontroll i sig: den samlar åtkomsten, gör ansvarsfördelningen tydlig och underlättar spårbarheten.
• API:er i compliancearbetet minskar manuell administration, men bara om datan landar i en struktur som kan visa efterlevnad för en tillsynsmyndighet.

Innehållsförteckning

• Vad ett API är och varför det blir en compliancefråga
• Två perspektiv på API och compliance
• Regelverken som berör era API:er
• Säkerhetskraven i praktiken
• SSO som compliancekontroll
• Så använder du API:er för att automatisera compliancearbetet
• Krav att ställa på en complianceplattform
• Samla API-styrningen och efterlevnaden i Trustview
• Vårt perspektiv: API-frågan är en ansvarsfråga
• Vanliga frågor
• Källor

Vad ett API är och varför det blir en compliancefråga

API står för Application Programming Interface. Skatteverket beskriver ett API som en bro mellan system och ett kontrollerat sätt att överföra information. Sveriges Dataportal förtydligar att ett API inte är databasen eller servern, utan koden som hanterar åtkomstpunkten till den information som externa system behöver använda.

Det är just åtkomstpunkten som gör API:et intressant ur ett complianceperspektiv. Varje API är en dörr in till er information. Om dörren saknar lås, eller om alla som har en nyckel kommer åt alla rum, spelar det mindre roll hur väl ni har skyddat resten av miljön.

För en dataskyddsjurist eller ett dataskyddsombud innebär det konkret att:

• en integration som för över personuppgifter är en del av en behandling och ska kunna spåras i registerförteckningen enligt GDPR
• ett API som exponerar personuppgifter mot en extern part kan kräva ett personuppgiftsbiträdesavtal
• en sårbarhet i ett API kan leda till en personuppgiftsincident med 72-timmarsfristen för anmälan till IMY

För en CISO är API:et en del av attackytan. Ett API som ingen har inventerat blir lätt en svag länk.

Öppna och stängda API:er

Skatteverket skiljer mellan öppna och stängda API:er och påpekar att även ett öppet API kan kräva avtal eller betalning. Tekniskt dominerar REST, som hanterar flera format, oftast JSON eller XML. Den äldre standarden SOAP bygger på XML och har striktare regler. Ur ett complianceperspektiv är skillnaden mellan öppet och stängt viktigast: ju fler som kan anropa API:et, desto viktigare blir autentisering, begränsningar och loggning.

Två perspektiv på API och compliance

När du arbetar med frågan behöver du hålla isär två perspektiv. De kräver olika ägare och olika kontroller.

I många organisationer hamnar det första perspektivet hos it och det andra hos juridik. Problemet uppstår när ingen äger kopplingen mellan dem. Då vet it hur API:et är byggt men inte vilka personuppgifter det hanterar, medan juridik vet vilka behandlingar som finns men inte genom vilka integrationer de sker.

Regelverken som berör era API:er

Inget svenskt eller europeiskt regelverk har ett eget kapitel om API:er. Kraven följer i stället av bredare bestämmelser om säkerhet och ansvar.

GDPR

GDPR kräver lämpliga tekniska och organisatoriska åtgärder. IMY beskriver korrekt behörighetsstyrning som en grundläggande säkerhetsåtgärd som bygger på principen “need to know”. Verksamheten behöver dokumentera behovs- och riskanalyser och regelbundet granska behörigheterna, så att ingen har tillgång till mer information än nödvändigt. Det gäller i lika hög grad för tekniska konton och API-nycklar som för personal.

När ett API skickar personuppgifter till en leverantör som behandlar dem för er räkning behöver ni normalt ett biträdesavtal. Läs mer om krav på personuppgiftsbiträdesavtal och om när avtalet ska vara på plats. Vår egen genomgång av när ni måste ha ett biträdesavtal visar hur frågan ser ut i praktiken.

Cybersäkerhetslagen (NIS2)

Cybersäkerhetslagen och cybersäkerhetsförordningen trädde i kraft den 15 januari 2026 och införde NIS2-direktivet i svensk rätt. För verksamheter som omfattas innebär det krav på riskbaserade säkerhetsåtgärder, incidentrapportering och säkerhet i leverantörskedjan. API:er mot leverantörer och partner är en central del av den kedjan, och sanktionsrisken gör att frågan inte längre kan lämnas enbart till utvecklingsteamet.

eIDAS och betrodda tjänster

För tillhandahållare av betrodda tjänster gäller dessutom eIDAS-förordningen. PTS anger att dessa tillhandahållare ska följa säkerhetskraven i både eIDAS och cybersäkerhetslagen, inklusive åtgärder mot rättsliga, affärsmässiga och operativa risker. PTS betonar också vikten av ett långsiktigt och systematiskt säkerhetsarbete med tydlig rollfördelning och utpekade ansvariga.

Säkerhetskraven i praktiken

Det mest konkreta svenska stödet finns i den REST API-profil som publiceras på Sveriges Dataportal. Den är framtagen för offentlig sektor inom ramen för det API Playbook som Digg tagit fram tillsammans med bland andra Bolagsverket, Lantmäteriet och E-hälsomyndigheten, men fungerar väl som referensnivå även för privata verksamheter.

Enligt säkerhetsavsnittet i REST API-profilen gäller följande:

1. Transport: all trafik ska gå över HTTPS med minst TLS 1.2.
2. Certifikat: certifikat ska baseras på SHA-2 med minst 2048 bitars nyckellängd.
3. Ömsesidig autentisering: kan behövas beroende på informationsklassning.
4. Autentisering och auktorisation: ska användas när åtkomsten till informationen är begränsad.
5. Loggning: loggningsnivåer ska definieras, och auditloggar ska skrivas före och efter säkerhetsrelaterade händelser.

MSB:s vägledning om säkerhetsåtgärder i informationssystem lägger till ett viktigt led: redan vid utveckling och utkontraktering ska kraven på behörigheter, autentisering, kryptering, loggning och säkerhetstester identifieras. Säkerheten ska alltså finnas i kravställningen, inte läggas till i efterhand.

För den tekniska granskningen är OWASP API Security Top 10 från 2023 den etablerade referensen. Där toppar bristande auktorisation på objektnivå listan, och bristande inventering av API-versioner finns också med. Båda är lika mycket compliancefrågor som tekniska frågor: utan inventering kan ni inte visa vilka behandlingar som pågår, och utan korrekt auktorisation brister ni i behörighetsstyrningen.

Exempel: så ser en myndighets API-säkerhet ut

Skatteverkets tjänstebeskrivning för ombudshantering via API är ett bra exempel på hur kraven blir konkreta:

• Mjukvaran identifieras med Client ID och Client Secret, eller med Client ID och ett utpekat organisationscertifikat.
• Den externa användaren autentiseras med organisationscertifikat eller e-legitimation.
• Inkommande anrop auditloggas för att förebygga och utreda säkerhetsincidenter, och loggarna sparas i upp till fem år.

Lägg märke till att både systemet och människan bakom anropet identifieras. Det är just den kombinationen som gör det möjligt att i efterhand svara på vem som gjorde vad.

Exempel: när behörighetsstyrningen brister

IMY:s granskning av Stockholms stads Skolplattform visar vad som händer när åtkomsten inte kan begränsas. Bristerna innebar att stora delar av personalen kunde komma åt uppgifter om elever med skyddad identitet och att vårdnadshavare kunde se andra barns uppgifter. Fallet gällde inte bara API:er, men mönstret är detsamma: en åtkomstpunkt som lämnar ut mer än mottagaren behöver.

Loggning som håller vid tillsyn

I ett tillsynsbeslut mot Migrationsverket framhöll IMY att det ska gå att verifiera vilka uppgifter som registrerats, när, av vem och i vilket syfte. När ni bestämmer hur länge loggarna ska sparas ska både it-säkerhets- och integritetsperspektivet vägas in. Loggar innehåller ofta själva personuppgifter, så en lagringstid som är för lång blir en egen risk. Vår guide om åtkomstloggning enligt GDPR går igenom hur ni kommer igång, och artikeln om hur länge personuppgifter får sparas hjälper er att motivera lagringstiden.

SSO som compliancekontroll

Single sign-on (SSO) brukar ses som en bekvämlighetsfunktion. För dig som ansvarar för efterlevnad är det snarare en kontroll. När inloggningen går via organisationens centrala identitetstjänst får ni:

• En plats för åtkomstbeslut. När en medarbetare slutar och kontot stängs i identitetstjänsten försvinner åtkomsten till alla anslutna system, även complianceplattformen där riskbedömningar och incidentrapporter finns.
• Starkare autentisering. MSB rekommenderar flerfaktorsautentisering för alla publikt exponerade tjänster, för information med högt värde och för systemadministrativa konton. Med SSO kan ni kräva MFA på ett ställe i stället för system för system.
• Tydligare ansvarsfördelning. Roller och grupper från identitetstjänsten kan styra vem som får se, redigera eller godkänna en konsekvensbedömning eller en leverantörsbedömning.
• Spårbarhet. Inloggningar och åtgärder kopplas till en verifierad identitet, vilket är förutsättningen för en logg som håller vid tillsyn.

I offentlig sektor driver Digg arbetet med samordnad identitet och behörighet inom Ena, Sveriges digitala infrastruktur. Digg pekar på att gemensamma regler och tekniska lösningar minskar behovet av manuella kontroller och speciallösningar. Samma logik gäller i en enskild organisation: ju färre separata inloggningar, desto färre konton att granska.

SSO ersätter dock inte behörighetsstyrningen. En person som kan logga in ska fortfarande bara se det hon behöver. Kontrollera därför att rollerna i varje system speglar principen om need to know och att behörigheterna granskas regelbundet.

Så använder du API:er för att automatisera compliancearbetet

Det andra perspektivet handlar om att låta data flöda in i compliancearbetet i stället för att samla in den via mejl och kalkylark. Arbeta stegvis:

1. Inventera era integrationer. Lista alla API:er, både de ni exponerar och de ni anropar hos leverantörer. Notera ägare, vilka uppgifter som flödar och informationsklassning.
2. Koppla varje integration till en behandling. Varje API som hanterar personuppgifter ska kunna knytas till en post i behandlingsregistret, med ändamål, rättslig grund och mottagare.
3. Prioritera efter risk. Börja med integrationer som rör känsliga personuppgifter, externa mottagare eller samhällsviktiga tjänster. Riskbaserad prioritering gör att resurserna hamnar där risken är störst.
4. Bedöm leverantörerna bakom API:erna. Under cybersäkerhetslagen är leverantörskedjan en del av ert ansvar. Dokumentera säkerhetsnivå, biträdesavtal och eventuella tredjelandsöverföringar.
5. Automatisera insamlingen där det går. Data om system, användare och incidenter som redan finns i andra verktyg bör hämtas automatiskt, så att registren hålls aktuella utan dubbelarbete.
6. Sätt upp uppföljning. Varje brist ska bli en åtgärd med ansvarig och deadline, och status ska kunna rapporteras till ledningen.

Ett scenario

Ett medelstort bolag med ett trettiotal SaaS-tjänster upptäcker vid en intern revision att två integrationer mot ett marknadsföringsverktyg skickar fler kundfält än ändamålet kräver. Ingen hade kopplat integrationerna till registerförteckningen. Åtgärden blir tredelad: it begränsar fälten i API-anropet, juridik uppdaterar behandlingen och biträdesavtalet, och dataskyddsombudet lägger in en återkommande kontroll. Utan en gemensam struktur hade de tre stegen hamnat i tre olika system.

Krav att ställa på en complianceplattform

Om ni ska välja verktyg för att hålla ihop arbetet, ställ frågor som rör både integration och åtkomst. Ett ärendehanteringsverktyg eller ett kalkylark kan fungera i början, men brister ofta i juridisk struktur. Vi har jämfört angreppssätten i artikeln om Jira för efterlevnad.

Frågan om datalagring och jurisdiktion väger tyngre ju känsligare information ni samlar. Vi har skrivit mer om varför det spelar roll i En svensk tjänst och varför det är viktigt.

Samla API-styrningen och efterlevnaden i Trustview

Trustview är en svenskutvecklad plattform för compliance, dataskydd och informationssäkerhet, byggd av jurister. I plattformen samlar du registerförteckningar enligt GDPR, konsekvensbedömningar (DPIA och TIA), risk- och incidentloggning, leverantörsbedömningar, ansvarsfördelning och uppföljning av åtgärder, med realtidsöversikt och automatiserade rapporter. Den stödjer GDPR, NIS2, ISO 27000 och AI-förordningen och innehåller färdiga mallar, guider, utbildningsfunktioner och integrationer.

Trustview kostar från 2 500 kr per månad. Behöver ni hjälp att bedöma en specifik integration eller ett leverantörsavtal kan du komplettera med juridisk rådgivning. Berätta gärna hur er identitetsmiljö och era befintliga system ser ut, så visar vi hur integrationerna fungerar i just er miljö.

Vårt perspektiv: API-frågan är en ansvarsfråga

I vårt arbete med jurister, dataskyddsombud och säkerhetsansvariga ser vi sällan att tekniken är det största problemet. TLS, certifikat och tokenbaserad autentisering är välkända och oftast på plats. Det som saknas är kopplingen mellan integrationen och det juridiska sammanhanget: vilken behandling API:et är en del av, vem som äger den, vilket avtal som reglerar mottagaren och vem som följer upp när något ändras.

Därför tycker vi att API-styrning ska behandlas som en del av compliance-programmet och inte som ett separat it-projekt. Varje integration ska ha en ägare, en riskbedömning och en plats i registret. Det är också därför vi har byggt Trustview kring tydliga ramverk och ansvarsfördelning snarare än kring fristående checklistor. Målet är inte att dokumentera mer, utan att kunna visa att ni följer reglerna när någon frågar, oavsett om det är styrelsen, en kund eller en tillsynsmyndighet.

Vårt råd till dig som börjar är enkelt: inventera först, automatisera sedan. Ett automatiskt flöde in i ett register som ingen förstår gör ingen nytta. Ett tydligt register som fylls på automatiskt sparar däremot både tid och risk.

— Jesper

Vanliga frågor

Vad står API för?

API står för Application Programming Interface, ett gränssnitt som låter system utbyta information maskinellt. I praktiken är det den åtkomstpunkt genom vilken ett system hämtar eller skickar data till ett annat. Ur ett complianceperspektiv ska varje API därför behandlas som en dörr till er information.

Vad betyder compliance på svenska?

Compliance översätts oftast till efterlevnad eller regelefterlevnad. Begreppet omfattar både externa krav, som GDPR och cybersäkerhetslagen, och interna regler som policyer och riktlinjer. Läs mer i vår artikel om vad regelefterlevnad innebär för svenska företag.

Måste ett API loggas enligt GDPR?

GDPR anger inga exakta loggningskrav, men kräver lämpliga säkerhetsåtgärder och att ni kan visa efterlevnad. IMY har i tillsyn betonat att det ska gå att verifiera vem som registrerat vilka uppgifter, när och i vilket syfte. För API:er som hanterar personuppgifter är auditloggning därför i praktiken en förutsättning.

Räcker SSO för att uppfylla kraven på åtkomstkontroll?

Nej. SSO samlar inloggningen och gör det lättare att kräva MFA och stänga konton, men styr inte vad en inloggad användare får se. Behörigheterna i varje system måste fortfarande följa need to know-principen och granskas regelbundet. Se SSO som grunden och rollstyrningen som nästa lager.

Källor

Skatteverket: Vad är ett API
Skatteverket: Tjänstebeskrivning Ombudshantering via API
Sveriges Dataportal: En introduktion till REST
Sveriges Dataportal: API Playbook
Sveriges Dataportal: REST API-profil, säkerhet
IMY: Behörighetsstyrning
IMY: Allvarliga brister i Skolplattformen i Stockholm
IMY: Tillsynsbeslut Migrationsverket
Regeringen: Nu skärps kraven på svensk cybersäkerhet
PTS: Säkerhetskrav och tillsyn av betrodda tjänster
MSB: Vägledning, säkerhetsåtgärder i informationssystem
MSB: Cybersäkerhet i Sverige, rekommenderade säkerhetsåtgärder
OWASP API Security Top 10 2023
Digg: Gemensamma regler och krav i samordnad identitet och behörighet

Rekommendationer

• Exempel på dataskyddsverktyg för GDPR-efterlevnad
• Arbetsflöde complianceorganisation: din praktiska guide
• SOC 2 vs ISO 27001: guide för säkerhetsansvariga
• DPO och driftansvariga: få åtkomstloggning enligt GDPR på 90 dagar