SaaS-säkerhetsfrågor för små team före köp

Små svenska team köper ofta SaaS för att lösa ett problem snabbt: kundsupport, CRM, HR, projektledning, analys, ekonomi eller automatisering. Problemet uppstår när verktyget får tillgång till kunddata, medarbetaruppgifter, e-post, filer eller interna system, samtidigt som säkerhetsgranskningen består av en säljpresentation och frågan “är ni GDPR-säkra?”.

Den här guiden är skriven för team utan stor inköpsavdelning eller egen säkerhetschef. Målet är inte ett tungt enterprise-flöde, utan att hjälpa er ställa rätt frågor, tolka svaren och fatta ett bättre köpbeslut innan verktyget kopplas in.

TL;DR

• Börja med vilken data verktyget ska hantera. Personuppgifter, kundärenden, HR-data och integrationer kräver mer granskning än ett fristående låg-riskverktyg.
• Om leverantören behandlar personuppgifter för er räkning behöver ni normalt ett personuppgiftsbiträdesavtal. GDPR artikel 28 anger centrala krav för personuppgiftsbiträden.
• Bra leverantörssvar är konkreta: datalagring, underbiträden, åtkomst, loggar, radering, incidenthantering och backup.
• Varningsflaggor är vaga formuleringar som “enterprise-grade security”, “vi följer best practice” eller “vår molnleverantör sköter säkerheten”.
• Anpassa frågorna efter risk. Små team behöver inte överarbeta varje köp, men de ska veta vilken risk de accepterar.

Scenariot: ett litet team ska välja ett nytt verktyg

Tänk er ett svenskt B2B-bolag med 15 personer. Ni vill köpa ett SaaS-verktyg för support och kunskapshantering. Verktyget ska integreras med e-post, CRM och interna hjälpartiklar. Det kommer därför sannolikt att hantera namn, e-postadresser, supporthistorik, avtalsfrågor och ibland information som kunder själva råkar skriva in i fritext.

Ni har ingen CISO. En grundare äger budgeten, en operationsperson leder införandet och en utvecklare kan granska tekniska svar, men ingen kan lägga en månad på leverantörsrisk. Samtidigt måste ni kunna visa att ni har tänkt igenom dataskydd och säkerhet, särskilt om ni behandlar personuppgifter.

Den avgörande frågan är inte “är leverantören säker?”. Den är för bred. Frågan är: “är säkerhet, dokumentation och juridiskt upplägg tillräckligt för den data och åtkomst vi ger dem?”

Innan ni kontaktar leverantören: kartlägg er användning

Gör en kort intern riskbild innan ni skickar frågor:

• Vilken data kommer att importeras, synkas eller skapas i verktyget?
• Innehåller datan personuppgifter enligt GDPR?
• Är leverantören personuppgiftsbiträde, självständigt personuppgiftsansvarig eller båda i olika delar av tjänsten?
• Ska verktyget integreras med e-post, CRM, dokumentlagring, kod, betalning eller identitetsleverantör?
• Vilka personer ska ha administratörsrättigheter?
• Vad händer om verktyget ligger nere, läcker data eller ändrar data felaktigt?

För ett verktyg utan känslig data kan standardvillkor, MFA och en säkerhetssida räcka. För ett verktyg med kunddata, HR-data eller breda integrationer behövs mer dokumentation.

Frågor om data och GDPR

Fråga: Vilka typer av data behandlar ni för oss, var lagras datan och vilken juridisk roll har ni?

Ett bra svar: Leverantören beskriver vilka datatyper som behandlas, om data lagras inom EU/EES eller i tredjeland, och om de agerar som personuppgiftsbiträde. De kan tillhandahålla ett personuppgiftsbiträdesavtal, en lista över underbiträden och information om eventuella internationella överföringar.

Ett oroande svar: “Allt ligger säkert i molnet”, “vi är GDPR-compliant” utan avtal, eller “juridiken löser vi efter signering”. Om leverantören inte kan förklara sin roll blir er egen dokumentation svagare vid frågor från IMY eller kunder.

GDPR artikel 28 är central. Den säger bland annat att ett personuppgiftsbiträde ska behandla personuppgifter enligt dokumenterade instruktioner, hjälpa till med säkerhet och incidenter, och ha kontroll över underbiträden. Det är inte en formalitet; det är en del av grunden för att använda tjänsten lagligt.

Frågor om inloggning och åtkomst

Fråga: Stödjer ni SSO, MFA, rollbaserad åtkomst och audit logs för administratörsåtgärder?

Ett bra svar: Leverantören erbjuder MFA som standard, gärna SSO via SAML eller OIDC på relevanta planer, tydliga roller, begränsade administratörsrättigheter och loggar över inloggning, export, integrationer och behörighetsändringar. Om ert bolag använder BankID i andra affärsprocesser bör leverantören kunna förklara hur deras egen identitets- och åtkomstmodell passar in i er helhet, även om verktyget inte använder BankID direkt.

Ett oroande svar: Nästan alla användare är administratörer, MFA saknas, eller loggar finns bara i en dyr enterprise-plan. För små team är kapade konton ofta en mer sannolik risk än avancerade attacker.

Frågor om leverantörskedja och underbiträden

Fråga: Vilka underleverantörer och underbiträden använder ni, hur granskar ni dem och hur meddelas vi vid ändringar?

Ett bra svar: Leverantören har en offentlig eller avtalsmässig lista över underbiträden, en process för förändringar, säkerhetsgranskning av kritiska leverantörer och möjlighet att invända vid väsentliga ändringar. CISA lyfter ICT supply chain security som en löpande disciplin, inte ett engångsformulär.

Ett oroande svar: Leverantören säger att “AWS/Google/Microsoft tar hand om säkerheten” men kan inte beskriva egna analysverktyg, supportsystem, e-postleverantörer eller AI-funktioner. Molnleverantören skyddar infrastrukturen; SaaS-leverantören ansvarar fortfarande för applikationen, konfigurationen, åtkomsten och sina egna underleverantörer.

Frågor om säkerhetskontroller och dokumentation

Fråga: Vilka kontroller använder ni för kryptering, sårbarhetshantering, backup, loggning och incidenthantering?

Ett bra svar: Leverantören svarar konkret: kryptering i transit och vila, patchprocess, sårbarhetsskanning, kundseparering, testade backuper, loggövervakning, incidentplan och realistiska kontaktvägar. De kan dela en SOC 2-rapport, ISO-certifikat, sammanfattning av penetrationstest eller en mappning mot ett ramverk som CSA Cloud Controls Matrix.

Ett oroande svar: Det finns ingen dokumentation, de vägrar dela ens en sammanfattning under NDA, eller de nöjer sig med “bank-grade encryption”. Kryptering säger lite om behörigheter, felkonfigurationer, drift, loggning och respons vid incidenter.

Snabb bedömningstabell

Svensk juridisk nyans

För svenska bolag är GDPR både ett EU-regelverk och en praktisk fråga om ansvar, dokumentation och tillsyn. IMY förväntar sig att personuppgiftsansvariga kan visa hur de har bedömt risker och valt personuppgiftsbiträden. Ett personuppgiftsbiträdesavtal bör beskriva ändamål, varaktighet, typer av personuppgifter, kategorier av registrerade, säkerhetsåtgärder, underbiträden, stöd vid registrerades rättigheter och vad som händer med datan när avtalet avslutas.

Om SaaS-verktyget används nära processer där stark identitet är viktig, exempelvis där kunder eller medarbetare identifieras med BankID i andra delar av flödet, bör inte SaaS-verktygets åtkomststyrning bli den svaga länken. Varje verktyg måste inte ha BankID-inloggning, men ni behöver förstå hur användare läggs till, tas bort, får roller och övervakas.

Avvägningar: rimlig säkerhet utan tung byråkrati

Små team ska inte kopiera stora koncerners inköpsprocesser rakt av. För många frågor kan bromsa ett bra verktyg och skapa en falsk känsla av kontroll. Använd en riskbaserad nivå:

• Låg risk: säkerhetssida, standardvillkor, MFA, dataexport och tydlig support kan räcka.
• Medelrisk: kräv personuppgiftsbiträdesavtal, underbiträdeslista, MFA eller SSO, raderingsprocess och incidentkontakt.
• Hög risk: gör juridisk granskning, tekniskt review, begränsad pilot, dokumenterad riskacceptans och exit-plan.

Det finns även en kommersiell avvägning. Vissa leverantörer lägger SSO, audit logs eller avancerade roller på dyra planer. Då behöver ni avgöra om återstående kontroller är tillräckliga, om kostnaden är motiverad, eller om ett annat verktyg passar er risknivå bättre.

Metod och evidens

Guiden bygger på fyra typer av källor. GDPR artikel 28 används för kraven på personuppgiftsbiträden och avtal. CISA:s material om ICT supply chain security ligger bakom fokus på leverantörskedja och löpande riskhantering. CSA Cloud Controls Matrix används som referenspunkt för kontroller inom åtkomst, loggning, kryptering, förändringshantering och incidentrespons. ENISA:s cloud security guide for SMEs stödjer den praktiska, riskbaserade nivån för mindre organisationer.

Det här är inte juridisk rådgivning och ersätter inte en konkret bedömning av avtal, dataskydd eller säkerhetsarkitektur. Det är en inköpsram som hjälper små team att ställa bättre frågor innan ett SaaS-verktyg får tillgång till data och system.

FAQ

Måste vi alltid kräva ISO 27001 eller SOC 2? Nej. Certifieringar och rapporter är användbara signaler, men de är inte alltid nödvändiga för låg-riskverktyg. Vid högre risk bör ni be om relevant dokumentation och kontrollera vad den faktiskt omfattar.

Räcker ett personuppgiftsbiträdesavtal för GDPR? Nej. Avtalet är viktigt när leverantören är biträde, men ni behöver också bedöma ändamål, dataminimering, säkerhet, underbiträden, radering och överföringar.

Vad gör vi om leverantören är amerikansk? Det är inte automatiskt fel, men ni behöver förstå lagring, överföringsgrund, underleverantörer och eventuella kompletterande skyddsåtgärder. Ta juridisk hjälp vid hög risk.

Hur många frågor ska vi skicka? Skicka hellre 10-15 relevanta frågor än ett långt standardformulär. Välj frågor efter datatyp, integrationer och affärskritikalitet.

Vilken varningsflagga är viktigast? Att leverantören inte kan förklara vilken data de behandlar, vilka underbiträden de använder eller hur ni blir informerade vid en säkerhetsincident.

Förslag på interna länkar

• Guide: Så granskar små team SaaS-leverantörer utan en säkerhetsavdelning
• Mall: Personuppgiftsbiträdesavtal och underbiträden — vad ska kontrolleras?
• Checklista: MFA, SSO och behörigheter för små företag
• Guide: Molnsäkerhet för mindre bolag före migration