Det förändrade systemlandskapet
Vad ett IT-system måste göra, hantera och skydda ser helt annorlunda ut idag jämfört med för tio år sedan. Det beror inte primärt på ny teknik, utan på att juridiken har förändrat vad system är skyldiga att vara.
Ett e-handelssystem 2015 måste:
- Ta emot beställningar och betalningar
- Visa produkter korrekt
- Skicka orderbekräftelser
Samma system 2026 måste dessutom:
- Inhämta, lagra och kunna radera samtycken, och vid intrång anmäla till IMY inom 72 timmar (GDPR)
- Erbjuda fullständig tillgänglighet för användare med funktionsnedsättning (EAA)
- Uppfylla starka kundautentiseringskrav och bedrägeriövervakning vid betalning (PSD2)
- Säkerställa transparens om automatiserade beslut och personalisering (DSA)
Det här gäller ett typiskt e-handelssystem. För samhällskritisk verksamhet, energi, vård, finansiell infrastruktur, tillkommer dessutom Cybersäkerhetslagen och Cyber Resilience Act med ytterligare krav på incidentrapportering, kontinuitet och komponentkontroll.
Systemet har fler krav på sig, inte för att verksamheten valt det, utan för att lagen kräver det. Och när systemet måste göra mer, måste vi verifiera mer.
Det regulatoriska landskapet fortsätter växa. Cybersäkerhetslagen, AI Act, Cyber Resilience Act (CRA), Data Act, fler regelverk tillkommer kontinuerligt. En stor del av det som tidigare var frivillig god praxis är nu lagstadgat med konkreta sanktioner. Tillgänglighetstestning var ”bra att ha” för att nå fler användare, idag är det lag med sanktionsavgifter vid bristande efterlevnad. Säkerhetstestning gjordes för att skydda verksamheten, idag kräver Cybersäkerhetslagen det med hot om böter och personligt ansvar för ledningen. Personuppgiftshantering som tidigare var en intern policy regleras nu i GDPR med böter upp till 4% av årsomsättningen.
Det innebär att testtäckningen måste följa systemkraven. Juridiken tillför nya systemkrav, och varje nytt systemkrav behöver testas. Det förändrar också hur vi prioriterar och dokumenterar:
Prioriteringarna förändras: En brist som tidigare var en dålig användarupplevelse kan idag vara ett lagbrott med böter på miljontals euro. Juridiken förskjuter vilka brister som är allvarliga.
Dokumentationen får ny roll: Testdokumentation är inte längre bara ett internt arbetsmaterial, det är juridiskt bevis vid myndighetsgranskning. ”Vi testade inte det” är ingen ursäkt när Integritetsskyddsmyndigheten eller Myndigheten för civilt försvar kommer på besök.
Detta kapitel ger dig den grundläggande förståelse du behöver för att navigera i detta förändrade systemlandskap. Vi fördjupar oss inte i specifika testmetoder, det kommer i senare kapitel, istället fokuserar vi på varför juridiken förändrar vad system måste vara och hur det i sin tur påverkar testning.
Grundläggande juridisk förståelse
Hur juridik fungerar (för tekniker)
Om du kommer från en teknisk bakgrund är det lätt att tro att juridik fungerar som kod. Det gör det inte. Här är de viktigaste skillnaderna du måste förstå:
Lagar ändras inte, tolkningen gör det:
Många tekniker tror att det kommer en ”GDPR 2.0” när lagen behöver uppdateras. Men så fungerar inte juridik. GDPR från 2018 är fortfarande exakt samma text idag, men vad den betyder i praktiken har utvecklats kontinuerligt genom hundratals myndighetsbeslut, domstolsutslag och vägledningar.
Detta är juridikens styrka, flexibilitet utan konstanta lagändringar, men det skapar osäkerhet. Du kan inte säga ”vi är compliant” och sedan glömma det. Regelefterlevnad är en kontinuerlig process, inte ett tillstånd.
Vaga formuleringar är avsiktliga:
När GDPR kräver ”lämpliga tekniska åtgärder” eller ”rimlig säkerhet”, är detta inte dåligt skrivet. Det är medvetet vagt för att kunna anpassas till olika situationer. En liten webshop och en bank har olika krav på ”rimlig säkerhet”.
Men om du behöver konkreta testfall är detta frustrerande. ”Lämpliga tekniska åtgärder” måste översättas till ”AES-256 kryptering med nyckelhantering enligt X”. Det är här du behöver samarbeta med juridisk expertis.
Kontext avgör allt:
Samma data kan ha helt olika juridisk status beroende på kontext. Ta ett bilregistreringsnummer som exempel:
- Enbart ett registreringsnummer: Bilen är registrerad på ett företag. Företag är inte fysiska personer och omfattas inte av GDPR. Registreringsnumret är inte en personuppgift.
- Kopplat till en person: Samma bil har en namngiven förare i systemet. Nu kan registreringsnumret kopplas till en specifik person och blir en personuppgift.
- Avslöjar känslig information: Bilen som är kopplad till en person parkeras regelbundet utanför ett sjukhus eller en mottagning. Nu kan uppgiften avslöja information om hälsotillstånd, vilket gör den till en känslig personuppgift med extra skyddskrav.
- Bevisföring: Föraren får en fortkörningsbot. Nu är registreringsnumret kopplat till en lagöverträdelse, ytterligare en kategori med särskilda krav.
Det är ett bra exempel på hur tolkningen förändras, även om lagtexten inte gör det. När jag ställde frågan till en jurist 2018 fick jag ett rakt svar: en företagsbils registreringsnummer är inte en personuppgift. Samma fråga 2026 gav ett annat svar: man bör numera alltid hantera ett registreringsnummer som en personuppgift, just på grund av den här typen av kontextuell koppling. Lagen är densamma, men sex år av myndighetsbeslut och domstolspraxis har gjort tolkningen tydligare och striktare.
Ett och samma datafält, fyra helt olika juridiska nivåer beroende på kontext. Du måste förstå domänen för att veta vad som är juridiskt känsligt. Det behandlas vidare i kapitel 1.8.
Det här är ett utdrag ur min kommande bok om test