SaaS-sikkerhedsspørgsmål for små teams før køb

Små danske teams køber ofte SaaS, fordi det løser et problem hurtigt: CRM, support, HR, projektstyring, analyse eller automatisering. Risikoen opstår, når værktøjet får adgang til kundedata, medarbejderoplysninger, MitID Erhverv-relaterede processer, økonomidata eller interne dokumenter, men sikkerhedstjekket kun består af “har I ISO 27001?” og et ja fra sælgeren.

Denne guide er lavet til teams uden en stor procurement- eller security-afdeling. Den hjælper jer med at stille bedre spørgsmål, forstå svarene og afgøre, hvornår I skal acceptere risiko, bede om dokumentation eller vælge en anden leverandør.

TL;DR

• Start med datatypen: personoplysninger, fortrolige kundedata og adgang til interne systemer kræver mere due diligence end et simpelt designværktøj.
• Bed altid om en databehandleraftale, hvis leverandøren behandler personoplysninger på jeres vegne. GDPR artikel 28 beskriver kravene til databehandlere og aftalens indhold.
• Gode svar er konkrete: hvor data lagres, hvem der har adgang, hvordan underleverandører styres, hvor længe logs opbevares, og hvad der sker ved brud.
• Bekymrende svar er vage: “enterprise-grade security”, “vi følger best practice” eller “vores cloud provider tager sig af det”.
• Brug spørgsmålene som en samtale, ikke som en eksamen. Målet er at finde de risici, der betyder noget for jeres team.

Scenariet: et lille team skal købe et nyt værktøj

Forestil jer et dansk B2B-team på 12 personer. I overvejer et SaaS-værktøj til kundesupport og automatiserede svar. Værktøjet skal integreres med e-mail, CRM og måske interne vidensartikler. Det kan derfor komme til at behandle kundernes navne, e-mailadresser, supporthistorik, kontraktspørgsmål og nogle gange følsomme oplysninger, som kunderne selv skriver i en besked.

I har ikke en CISO. I har en founder, en operationsansvarlig og en udvikler, der kan læse en sikkerhedsside, men ikke bruge tre uger på vendor risk management. I skal træffe en ansvarlig beslutning uden at gøre processen tungere end nødvendigt.

Det rigtige spørgsmål er ikke “er værktøjet sikkert?” Det er: “er sikkerhed, dokumentation og juridisk opsætning tilstrækkelig til den data og adgang, vi giver det?”

Før I kontakter leverandøren: klassificér jeres brug

Lav en kort intern vurdering først:

• Hvilke data skal uploades eller synkroniseres?
• Indeholder data personoplysninger efter GDPR?
• Er leverandøren databehandler, selvstændig dataansvarlig eller begge dele i forskellige funktioner?
• Skal værktøjet have adgang til e-mail, CRM, betalingssystemer, kode, filer eller identity provider?
• Hvem i teamet skal have administratoradgang?
• Hvad er konsekvensen, hvis værktøjet er nede, lækker data eller ændrer data ved en fejl?

For et lavrisikoværktøj kan en sikkerhedsside og standardvilkår være nok. For et værktøj med kundedata, HR-data eller integrationer skal I se mere dokumentation.

Spørgsmål til leverandøren: data og GDPR

Spørg: Hvilke typer data behandler I for os, hvor lagres data, og hvem er juridisk rollefordeling?

Et godt svar: Leverandøren beskriver klart, hvilke datafelter der behandles, om data ligger i EU/EØS eller tredjelande, og om de fungerer som databehandler. De kan fremsende en databehandleraftale, liste over underdatabehandlere og information om internationale overførsler.

Et bekymrende svar: “Alt ligger sikkert i skyen”, “vi er GDPR-compliant” uden databehandleraftale, eller “vores jurist kan se på det efter kontraktunderskrift”. Hvis de ikke kan forklare deres rolle, bliver jeres egen dokumentation over for Datatilsynet svagere.

GDPR artikel 28 er central her: en databehandler må kun behandle data efter dokumenterede instrukser, skal hjælpe med sikkerhed og brud, og skal have styr på underdatabehandlere. Det er ikke pynt i kontrakten; det er grundlaget for lovlig brug.

Spørgsmål til adgang og login

Spørg: Understøtter I SSO, MFA, rollebaseret adgang og audit logs for administratorhandlinger?

Et godt svar: Leverandøren tilbyder MFA som minimum, gerne SSO/SAML eller OIDC på relevante planer, klare roller, begrænsede administratorrettigheder og logs over login, eksport, integrationer og ændringer i adgang. Hvis jeres virksomhed bruger MitID Erhverv i beslægtede arbejdsgange, bør leverandøren kunne forklare, hvordan deres login og rettighedsmodel passer ind i jeres samlede adgangsstyring, selv om SaaS-værktøjet ikke nødvendigvis bruger MitID direkte.

Et bekymrende svar: Alle brugere er næsten administratorer, MFA er ikke tilgængelig, eller logs findes kun på den dyreste enterprise-plan. For små teams er konto-overtagelse ofte en mere realistisk risiko end avancerede angreb.

Spørgsmål til leverandørkæde og underleverandører

Spørg: Hvilke underleverandører bruger I, hvordan vurderer I dem, og hvordan informerer I os om ændringer?

Et godt svar: Leverandøren har en offentlig eller kontraktuel liste over underdatabehandlere, en proces for ændringer, sikkerhedsvurdering af kritiske leverandører og mulighed for at gøre indsigelse ved væsentlige ændringer. CISA anbefaler at se på ICT supply chain security som en løbende disciplin, ikke kun som et engangstjek.

Et bekymrende svar: Leverandøren siger, at “det håndterer AWS/Google/Microsoft”, men kan ikke nævne egne analyseværktøjer, supportplatforme, e-mailleverandører eller AI-funktioner. Cloududbyderen sikrer infrastrukturen; SaaS-leverandøren er stadig ansvarlig for sin applikation, konfiguration og egne underleverandører.

Spørgsmål til sikkerhedskontroller og dokumentation

Spørg: Hvilke kontroller bruger I for kryptering, sårbarhedshåndtering, backup, logging og incident response?

Et godt svar: Leverandøren svarer med konkrete kontroller: kryptering i transit og hvile, patchingproces, sårbarhedsscanning, adskillelse mellem kunder, backup-test, logmonitorering, incident response-plan og realistiske notifikationsfrister. De kan dele en SOC 2-rapport, ISO-certifikat, pen test-summary eller mapping til kendte rammeværk som CSA Cloud Controls Matrix.

Et bekymrende svar: De har ingen dokumentation, vil ikke dele et resumé under NDA, eller henviser kun til “bank-grade encryption”. Kryptering alene siger ikke meget om adgangsstyring, fejlkonfiguration, logging eller drift.

Hurtig vurderingstabel

Dansk juridisk nuance

For danske virksomheder er GDPR ikke bare et EU-tema; det er også praktisk tilsyn og dokumentation over for Datatilsynet. Hvis en SaaS-leverandør behandler personoplysninger for jer, skal I kunne vise, hvorfor valget er forsvarligt, og hvilke instrukser leverandøren arbejder efter. En databehandleraftale bør dække formål, varighed, datatyper, sikkerhedsforanstaltninger, underdatabehandlere, hjælp ved registreredes rettigheder og sletning eller tilbagelevering ved ophør.

Hvis værktøjet bruges i processer med stærk identitet, fx hvor medarbejdere arbejder med MitID Erhverv eller autoriserede virksomhedsroller, bør adgangsstyringen i SaaS-værktøjet ikke blive det svage led. Alle værktøjer behøver ikke integrere med MitID, men I bør vide, hvordan brugere oprettes, fjernes og overvåges.

Trade-offs: sikkerhed uden at kvæle købet

Små teams skal ikke kopiere enterprise-procurement blindt. For mange spørgsmål kan forsinke et godt værktøj og skabe falsk tryghed. Brug risikobaseret indkøb:

• Lav risiko: standardvilkår, MFA, dataeksport og en kort sikkerhedsside kan være nok.
• Mellem risiko: kræv DPA, underdatabehandlerliste, SSO/MFA, sletningsproces og incident-kontakt.
• Høj risiko: kræv mere dokumentation, juridisk gennemgang, teknisk review, begrænset pilot og exit-plan.

Der er også en kommerciel afvejning. Nogle sikkerhedsfunktioner ligger på dyre planer. Hvis SSO kun findes på enterprise-planen, skal I beslutte, om MFA og stærke roller er tilstrækkeligt, eller om værktøjet ikke passer til jeres risikoniveau.

Metode og evidens

Denne guide bygger på fire typer kilder: juridiske minimumskrav, cloud-sikkerhedskontroller, leverandørkæderisiko og praktisk SME-sikkerhed. GDPR artikel 28 bruges til databehandlerkrav. CISA’s materiale om ICT supply chain security understøtter fokus på underleverandører og løbende leverandørstyring. CSA Cloud Controls Matrix bruges som reference for kontroller som adgang, logging, kryptering, change management og incident response. ENISA’s cloud security guide for SMEs understøtter den risikobaserede tilgang for mindre organisationer.

Guiden giver ikke juridisk rådgivning og erstatter ikke en konkret vurdering af kontrakter eller databeskyttelse. Den er en praktisk indkøbsramme, så små teams kan stille bedre spørgsmål, før data flyttes ind i et nyt værktøj.

FAQ

Skal vi altid kræve ISO 27001 eller SOC 2? Nej. Det er gode signaler, men ikke altid nødvendige for lavrisikoværktøjer. For højere risiko bør I bede om relevant dokumentation, men også læse hvad den faktisk dækker.

Er en databehandleraftale nok til at være GDPR-compliant? Nej. Aftalen er nødvendig, når leverandøren er databehandler, men I skal også vurdere sikkerhed, formål, dataminimering, underleverandører og sletning.

Hvad hvis leverandøren er amerikansk? Det er ikke automatisk udelukket, men I skal forstå datalagring, overførselsgrundlag, underleverandører og eventuelle supplerende foranstaltninger. Få juridisk hjælp ved høj risiko.

Hvor mange spørgsmål skal vi sende? Send færre, bedre spørgsmål. Vælg de 10-15 vigtigste ud fra datatypen og integrationerne. Et kort, præcist spørgeskema giver ofte bedre svar end et langt enterprise-dokument.

Hvad er det største røde flag? Når leverandøren ikke kan forklare, hvilke data de behandler, hvem deres underleverandører er, eller hvordan de informerer jer ved sikkerhedshændelser.

Forslag til interne links

• Guide: Sådan vurderer du SaaS-leverandører uden et stort security-team
• Skabelon: Databehandleraftale og underdatabehandlere — hvad små virksomheder bør tjekke
• Tjekliste: MFA, SSO og adgangsstyring for små teams
• Guide: Cloud-sikkerhed for SMV’er før migration