CRA för SaaS: omfattning, ansvar och bevis

Det går inte att säkert svara på ”omfattas SaaS av CRA?” enbart utifrån abonnemangsmodellen. CRA reglerar produkter med digitala element, medan molntjänster – inklusive SaaS – också behandlas i NIS2-regelverket. Den avgörande frågan är vad produkten är, vilken programvara som tillhandahålls på marknaden och om en fjärrtjänst är en integrerad del av en produktfunktion.

Börja med arkitekturen och leveransmodellen, inte marknadsföringsetiketten.

Två frågor som ofta blandas ihop

Är molntjänsten i sig en produkt med digitala element enligt CRA?

Utgå inte från det bara för att användarna kommer åt programvaran via en webbläsare.

Är fjärrtjänsten en del av en annan produkt med digitala element?

Det kan den vara. CRA definierar en ”lösning för fjärrbehandling av data” som databehandling på distans där programvaran har utformats och utvecklats av tillverkaren eller under tillverkarens ansvar, och vars avsaknad skulle hindra produkten med digitala element från att utföra en av sina funktioner.

CRA:s skäl ger ett exempel där en mobilapplikation behöver åtkomst till ett API eller en databas som tillhandahålls genom en tjänst utvecklad av tillverkaren. I den situationen kan tjänsten omfattas av produktens tillämpningsområde som en lösning för fjärrbehandling av data.

Kartlägg arkitekturen innan tillämpningsområdet avgörs

Beskriv följande delar separat för ett SaaS-erbjudande:

programvara som levereras till kunden – agent, dator- eller mobilapplikation, apparat, insticksprogram, bibliotek;
webbgränssnitt – vad användaren kommer åt i webbläsaren;
backend/API – funktioner som utförs på distans;
databaser och behandling – vilka fjärrdelar som krävs för produktfunktioner;
tredjepartsintegrationer – vad som ligger under tillverkarens ansvar och vad som inte gör det;
marknadsmodell – vem som tillhandahåller lösningen och under vilket varumärke;
uppdateringar – vilka delar som ändras av tillverkaren och hur de påverkar säkerheten;
stöd – hur länge varje relevant komponent underhålls.

Kartläggningen stödjer både bedömningen av tillämpningsområdet och den senare tekniska dokumentationen.

Tre exempelsituationer

A. Molntjänst som endast används i webbläsaren

Användaren loggar in i en tjänst via webbläsaren utan att en separat programvaru- eller hårdvaruprodukt levereras. Dra inte slutsatsen ”CRA gäller” enbart från ”SaaS”. Kontrollera CRA:s definitioner och kommissionens aktuella vägledning och bedöm separat NIS2-skyldigheter där de är relevanta för organisationen.

B. Programvaruprodukt med backend som drivs av tillverkaren

Kunden får en applikation eller komponent vars viktiga funktion inte kan fungera utan en backend som tillverkaren har utformat. Fjärrbehandlingen kan vara en del av produkten enligt CRA.

C. En produkt använder en fristående molntjänst

När tjänsten är utformad och utvecklad utanför tillverkarens ansvar kan sambandet skilja sig från en egen backend. ”Data finns i molnet” besvarar inte i sig frågan om CRA.

Detta är vägledande exempel, inte rättsliga avgöranden för en bestämd arkitektur.

Varför detta är en aktuell verksamhetsfråga

Artikel 14 gäller sedan den 11 september 2026 och omfattar även produkter inom tillämpningsområdet som släppts ut på marknaden före den 11 december 2027.

Om erbjudandet består av en applikation, komponent och backend behöver teamet veta följande för den berörda produkten och utgåvan:

var sårbarhetsrapporter tas emot;
vem som gör triage;
hur produktpåverkan bedöms;
hur rättningar ges ut;
hur användarna informeras;
när bedömningen av CRA-rapporteringsplikt startar.

Utan en tydlig produktgräns är det svårt att definiera T0, ansvarsfördelningen eller en anmälans omfattning.

Vad ett beslut om SaaS-tillämpningsområde ska innehålla

diagram över produktens gränser;
delar som levereras lokalt;
delar som körs på distans;
varje dels funktion;
om borttagning av fjärrdelen hindrar en produktfunktion;
ansvar för utveckling av fjärrdelen;
distributions- och varumärkesmodell;
organisationens roll;
rättslig grund och vägledning som använts för bedömningen;
personen som godkänner resultatet;
nästa granskningsdatum.

Hur Pulsar kan hjälpa

Pulsar kan bevara beslutet om tillämpningsområde och stödmaterialet och koppla resultatet till risker, dokument, åtgärder, leverantörer och underlag. När arkitekturen ändras i en senare utgåva kan beslutet återgå till granskning i stället för att bli kvar som en inaktuell PDF.

Pulsar ska inte självständigt ge ett juridiskt slutgiltigt svar ”CRA gäller / gäller inte” utan en granskningsbar grund och mänskligt godkännande.

Se Pulsar GRC i ett bedömningsflöde

Ett abonnemang är en affärsmodell, inte en produktgräns

Anta att ett företag säljer en webbtjänst och beskriver hela erbjudandet som SaaS. En del kunder använder bara webbläsaren, medan andra installerar en lokal agent som skickar data till samma backend. De två användningssätten kan behöva skilda produktbedömningar. Lista först vilka delar som faktiskt distribueras, vad kunden installerar och vilka fjärrfunktioner som behövs. Gör inte en gemensam slutsats enbart därför att betalningen sker genom samma abonnemang.

För den fristående webbtjänsten ska bedömaren kontrollera CRA:s definitioner och aktuella vägledning innan tillämplighet avgörs. För agenten behöver bedömningen omfatta dess funktioner och beroenden. Standalone SaaS är inte automatiskt en CRA-produkt. Samtidigt räcker uttrycket ”bara en tjänst” inte för att undanta programvara som faktiskt levereras eller fjärrbehandling som hör till en produkt med digitala element.

Beskriv ett funktionellt beroende utan att överdriva det

En produkt kan använda externa tjänster för flera ändamål. Skriv vad varje del gör och om produktens funktion kan genomföras utan den. Skilj en tillvalsfunktion från en del som behövs för en av produktens funktioner. Bevara också vem som utvecklar fjärrprogramvaran eller under vems ansvar utvecklingen sker. Dessa fakta hjälper en rättslig bedömare att använda CRA:s definitioner korrekt.

Testa beroendet i en lämplig miljö eller dokumenterad analys. Om ett API försvinner, vilka funktioner fortsätter fungera och vilka faller bort? Ange produktversion och förutsättningar. Testresultatet är ett faktaunderlag, inte ett automatiskt juridiskt svar. Om dokument och faktiskt beteende skiljer sig behöver teamet rätta underlaget eller utreda orsaken innan bedömningen godkänns.

Kundinstallerade delar behöver en egen versionsbild

En backend kan uppdateras centralt medan kundens agent eller mobilapp ligger kvar i en äldre version. Dokumentera vilka kombinationer som stöds och vilka som används enligt de källor organisationen faktiskt har. Ett aktuellt backend-bygge visar inte att alla kundinstallerade delar är uppdaterade. När ett sårbarhetsfynd gäller agenten behöver teamet kunna identifiera de relevanta utgåvorna och hur användare får information.

Om installerade versioner är okända ska den begränsningen framgå. Bedöm vilka register eller kommunikationskanaler som kan minska osäkerheten. En plan för distribution och stöd behöver bygga på det verkliga erbjudandet. Den bör inte anta att alla kunder får en ändring samtidigt bara därför att någon del av tjänsten uppdateras automatiskt.

Arkitekturskissen ska visa ansvar och dataflöde

Rita klient, agent, backend, databaser och relevanta integrationer med korta beskrivningar av deras funktion. Ange vilka delar organisationen utvecklar och vilka som tillhandahålls av en annan part. En logotyp för en molnleverantör visar inte vilken roll tjänsten spelar i produktens funktion. Beskriv därför sambandet och bevara referensen till de tekniska källorna.

När arkitekturen förändras ska produktgränsen och tidigare bedömningar granskas. Ett nytt insticksprogram eller en lokal komponent kan skapa frågor som inte fanns i den ursprungliga webbtjänsten. Dokumentera vilka beslut som påverkas och vem som godkänner ändringen. En ny ruta i arkitekturen behöver en följdbedömning, inte bara ett uppdaterat bilddatum.

Håll CRA och organisationsregler urskiljbara

En leverantör kan behöva bedöma nationella NIS2-regler och dataskydd även när en viss tjänst inte bedöms vara en CRA-produkt. Gör dessa bedömningar separat och länka dem där de använder samma fakta. Ett negativt CRA-beslut ska inte användas som ett allmänt besked att organisationen saknar säkerhets- eller rapporteringsskyldigheter. Kriterier, omfattning och ansvar kan skilja sig mellan reglerna.

Ange också vilken jurisdiktion som bedömts. Den svenska språkversionen gör inte den polska KSC-lagen till en svensk regel och avgör inte nationell NIS2-tillämplighet. Företag som verkar i flera länder behöver ansvarig granskning av sina faktiska roller och verksamheter. Pulsar kan bevara besluten och källorna, men den rättsliga analysen kräver kompetenta personer.

Leverantörsavtal hjälper men avgör inte allt

Ett avtal med en backend- eller komponentleverantör kan ange teknisk support och informationsutbyte. Kontrollera vad som faktiskt omfattas och vilka begränsningar som finns. Ett generellt säkerhetsdokument från leverantören ersätter inte bedömningen av den egna produktens användning av tjänsten. Bevara underlag för de fakta som används i beslutet och skapa öppna frågor när något behöver bekräftas.

Identifiera även en praktisk kontaktväg när information om en sårbarhet behövs snabbt. Ett kommersiellt kontaktformulär kan vara för långsamt för en tidskritisk teknisk fråga. Detta är ett operativt planeringsförslag, inte ett universellt avtalskrav. Organisationens process ska bygga på tjänstens betydelse för produkten och de tillämpliga skyldigheterna.

Ett mottagningstest för erbjudandets produktkarta

Be en kollega som inte byggt arkitekturen att ange vilka delar kunden får, vilken version som avses och vilka fjärrfunktioner som ingår. Personen ska kunna hitta källor, ansvariga och den rättsliga bedömningens omfattning. Om svaret bara är ”SaaS” har produktkartan inte blivit tillräckligt tydlig. Förtydliga det som saknas i stället för att lägga till fler generella beskrivningar.

Lägg sedan till ett hypotetiskt nytt klientprogram i en testkopia. Granskaren ska kunna se att erbjudandet förändrats och att tillämplighetsbedömningen kan behöva göras om. Testa även att en fristående integration inte automatiskt kopieras in i produktens rättsliga omfattning utan en bedömning. Syftet är att pröva beslutets användbarhet, inte att ersätta en kvalificerad rättslig analys.

Rapportering och stöd följer den avgränsade produkten

När en produkt eller dess fjärrbehandling bedömts inom CRA behöver organisationen kunna koppla relevanta händelser till den avgränsningen. Ett ärende som bara nämner företagets molntjänst ger inte alltid tillräcklig information om berörd produkt och utgåva. Bevara teknisk triage och vilka kombinationer av klient och backend som undersökts. Rapportering kräver en separat prövning av tillämpliga kriterier.

Stödperiod och uppdateringsplan behöver också spegla skillnaden mellan centralt förvaltad kod och kundinstallerade delar. Dokumentera vilken information kunden får och hur olika utgåvor hålls aktuella. Pulsar kan koppla produktbeslut, risker, uppgifter och underlag. Det lovar inte automatisk hämtning av molnbevis och avgör inte CRA-tillämplighet på egen hand. Ett tydligt faktaunderlag gör det ansvariga beslutet möjligt att förstå och ompröva.

Ett kommersiellt paket kan innehålla flera bedömningar

Säljteamet kan vilja presentera webbportal, agent och integration som ett enda erbjudande. Den tekniska produktkartan behöver fortfarande skilja delarna åt. Ange vilken rättslig bedömning som hör till varje avgränsning och vilka fakta som är gemensamma. Detta gör att ett kundsvar kan vara kort utan att bli oklart. Det hindrar också en bedömning av webbtjänsten från att kopieras till en ny distribuerad komponent.

Kontrollera avtals- och produkttexter när en del byts ut. Om kunden nu får ett nytt klientprogram ska det framgå i den interna överlämningen till produkt- och säkerhetsansvariga. En ändring av licens eller pris kan sammanfalla med en teknisk förändring som behöver nytt beslut. Bevara båda spåren så att granskaren kan förstå vad som faktiskt förändrades.

Som slutkontroll kan en person utanför säljprojektet läsa paketbeskrivningen och jämföra den med produktakten. Otydliga gränser ska då bli en konkret redigerings- eller bedömningsuppgift före nästa kundsvar.

Relaterad vägledning

Repetera ett krav och ett granskat resultat

Använd en fiktiv produkt som består av en skrivbordsklient och en tillverkarstyrd backend. Detta är ett exempel på syntetisk arkitektur, inte en förklaring om att varje SaaS-tjänst faller under CRA. Anteckna först produktfunktionen, backendens roll och frågan som behöver kvalificerad omfattningsgranskning. Behåll rättskällan och granskningsbeslutet tillsammans med protokollet.

När exemplets tillämplighetsantaganden är explicita, välj ett relevant krav och en åtgärd. Tilldela en ägare och ett datum och definiera sedan vilka bevis som skulle visa åtgärdens resultat. Till exempel kan åtgärden granska en produktåtkomstregel och bifoga den fiktiva testbeskrivningen och resultatet. En behörig person granskar bevisningen mot det angivna kriteriet. En fil som bifogas åtgärden slutför inte den granskningen av sig själv.

I Pulsar, läs tillbaka kravet, länkad åtgärd, källversion och bevis efter att du har sparat. Be en kollega identifiera nästa ansvar utan en förklaring från författaren. Den konkreta provproduktionen är ett inspekterbart fragment av produktarbetet. Det är inte en automatisk CRA-klassificering, bedömning av överensstämmelse, CE-deklaration eller inlämnande till en myndighet.

Pulsar erbjuder en 14-dagars provperiod som kräver en betalningsmetod. Granska den valda planen, priset efter provperioden och avbokningsvillkoren innan du bekräftar. Använd syntetiska poster för denna övning; ett riktigt produktbeslut kräver din egen arkitektur och kvalificerad granskning.

Källor

Förordning (EU) 2024/2847 — Cyber Resilience Act
Europeiska kommissionen — Cyber Resilience Act och tillämpningsdatum Källor kontrollerade: 2 oktober 2026. De praktiska testerna och exemplen ovan är redaktionella förslag, inte nya rättsliga krav.
Pulsar GRC — åtkomst, dataisolering och export (polska) Källor kontrollerade: 2026-10-10.
CRA — Regulation (EU) 2024/2847 — Produktens omfattning och tillämpliga skyldigheter.
European Commission — CRA guidance, 27 July 2026 — Officiell vägledning om omfattning och genomförande.
European Commission — CRA legislative summary — Omfattning, sårbarhetshantering och ansökningsdatum.
Pulsar GRC — features — Registrerade krav, handlingar och bevis.
Pulsar GRC — pricing — Villkor för testperioden.
Publicerad produktomfattning och testvillkor — Publicerad produktomfattning och testvillkor. Granska villkoren och påbörja den 14-dagars provperioden

Sårbarheter i IoT-komponenter: leverantörer, beslut och korrigeringar

Polska KSC/NIS2 för IT-leverantörer: bedömning och ett åtgärdsregister

API och MCP i GRC: definiera åtkomst innan system ansluts