En säkerhetschecklista för svenska företag före lansering
Applikationen är färdig. Inloggningen fungerar, betalningen går igenom och informationen sparas i databasen. Teamet har testat de viktigaste funktionerna och kunden väntar på lanseringen.
Men ingen har försökt logga in som någon annan. Ingen har kontrollerat vad som händer när en vanlig användare ändrar ett id-nummer i webbadressen. Ingen vet exakt vilka externa kodbibliotek systemet är beroende av. Säkerhetsloggarna finns kanske – men ingen får ett larm när något onormalt händer.
Programvaran fungerar. Frågan är om företaget kan lita på den.
Den största programvarurisken är ofta osynlig fram till den dag då den blir dyr. Ett säkerhetsproblem kan ligga oupptäckt i månader och först märkas när kunduppgifter läcker, verksamheten stannar eller en leverantör meddelar att ett system måste tas offline.
Under 2025 anmäldes 12 276 personuppgiftsincidenter till Integritetsskyddsmyndigheten, IMY. Det var den högsta nivån hittills. En stor del av ökningen berodde på omfattande incidenter hos personuppgiftsbiträden vars system användes av många olika organisationer.
Samtidigt visar den svenska årsrapporten om cyberincidenter 2025 att nästan hälften av de rapporterade incidenterna var kopplade till leveranskedjor. Misstag och systemfel hörde fortfarande till de vanligaste kända orsakerna. Det är en viktig påminnelse: hotet är inte bara en angripare utanför företaget. Risken kan finnas i en uppdatering, en molntjänst, ett kodbibliotek eller en felaktig inställning.
Säkerhet är inte ett test i slutet av projektet
Många företag behandlar säkerhet som ett sista kontrollsteg före lansering. Utvecklarna bygger funktionerna, verksamheten godkänner designen och därefter får någon ”säkerhetstesta” systemet.
Då är flera av de dyraste besluten redan fattade.
Om applikationen har en osäker behörighetsmodell, samlar in onödiga personuppgifter eller är beroende av ett gammalt tekniskt ramverk räcker det sällan med några mindre korrigeringar. Säkerhet behöver därför byggas in från början och följas upp under hela systemets livslängd.
OWASP:s aktuella Top 10 för 2025 placerar bristande åtkomstkontroll och felaktiga säkerhetskonfigurationer bland de mest kritiska riskerna för webbapplikationer. OWASP:s Application Security Verification Standard, ASVS, kan dessutom användas som en konkret kravlista vid utveckling, testning och upphandling.
Följande checklista hjälper svenska företag att bedöma om en applikation är redo att möta verkligheten – inte bara om den fungerar under en demonstration.
1. Vet ni vilken information systemet skyddar?
Börja med att kartlägga vad applikationen faktiskt hanterar.
Innehåller den kundregister, avtal, betalningsuppgifter, hälsodata, användarbeteenden eller interna affärshemligheter? Var lagras informationen? Vilka andra system skickas den till? Hur länge sparas den?
Samla inte in information ”för säkerhets skull”. Ju mer data företaget lagrar, desto större blir konsekvensen av ett intrång.
IMY betonar att inbyggt dataskydd och dataskydd som standard gäller företag i alla storlekar. Systemets standardinställningar ska vara dataskyddsvänliga och personuppgiftsbehandlingen behöver planeras redan när lösningen utformas.
2. Har varje användare rätt behörighet – och inget mer?
En användare ska bara kunna se och göra det som rollen kräver.
Testa inte enbart om administratören kan öppna administrationspanelen. Testa om en vanlig användare kan komma åt den genom att ändra en länk, manipulera ett API-anrop eller återanvända en gammal sessionsnyckel.
Kontrollera även vad som händer när en medarbetare byter roll eller slutar. Behörigheter som ligger kvar efter avslutad anställning är en onödig risk.
Använd multifaktorautentisering för administratörer och andra känsliga konton. Undvik gemensamma konton och se till att systemet aldrig levereras med ett känt standardlösenord.
3. Är systemets standardinställningar säkra?
En säker applikation ska inte kräva att kunden först hittar och ändrar tio avancerade inställningar.
Testmiljöer, administrativa gränssnitt, felsökningsfunktioner och databaser ska inte exponeras mot internet utan ett tydligt behov. Standardkonton ska tas bort. Felmeddelanden ska hjälpa användaren utan att avslöja databasstruktur, serverversioner eller interna sökvägar.
Principen bör vara enkel: systemet ska vara säkert direkt efter installationen, inte först efter att någon har läst en lång manual.
4. Vet ni vilken extern kod applikationen innehåller?
Modern programvara byggs nästan aldrig helt från grunden. Den använder paket från exempelvis npm, pip eller Maven, externa API:er, molntjänster och färdiga komponenter.
Det sparar tid men skapar beroenden.
ENISA varnar för att paketförvaltare och tredjepartskomponenter kan introducera risker i hela programvarans leveranskedja. Företaget bör därför ha en aktuell komponentförteckning, låsta versionsnummer, automatisk sårbarhetsskanning och en rutin för att snabbt uppdatera kritiska beroenden.
Frågan är inte bara: ”Har vi sårbara paket?”
Den viktigare frågan är: ”Hur snabbt märker vi det – och vem ansvarar för att åtgärda dem?”
5. Har systemet testats på andra sätt än genom vanliga användarflöden?
Ett funktionstest visar att systemet gör det utvecklaren har tänkt. Ett säkerhetstest undersöker vad som händer när någon använder systemet på ett sätt som utvecklaren inte har tänkt.
Kombinera därför kodgranskning, automatiserad säkerhetsskanning och tester av den körande applikationen. För system som hanterar känsliga uppgifter eller affärskritiska processer bör en oberoende penetrationstestare granska lösningen före lansering.
Upptäckta problem ska prioriteras utifrån faktisk risk, inte enbart antalet tekniska varningar.
6. Skyddas hemligheter och personuppgifter korrekt?
API-nycklar, databaslösenord och certifikat ska inte ligga direkt i källkoden, chattloggar eller delade dokument.
Känslig information behöver skyddas både under överföring och när den lagras. Säkerhetskopior ska omfattas av samma skydd som produktionsdatabasen. Det hjälper inte att kryptera huvudsystemet om en okrypterad kopia ligger i ett gammalt lagringskonto.
Företaget behöver också veta vem som kan komma åt produktionsdata och hur åtkomsten följs upp.
7. Kan ni upptäcka ett intrång?
En applikation utan användbara loggar kan vara angripen utan att någon märker det.
Logga exempelvis misslyckade inloggningar, ändringar av behörigheter, administrativa åtgärder, stora datauttag och försök att kringgå åtkomstkontroller. Loggarna ska skyddas mot manipulation och inte själva innehålla fler personuppgifter än nödvändigt.
Bestäm vilka händelser som ska skapa ett larm och vem som faktiskt tar emot det. OWASP framhåller att applikationsloggning ofta saknas eller är dåligt konfigurerad, trots att den kan ge insyn som vanliga serverloggar inte erbjuder.
8. Har ni testat återställning – inte bara säkerhetskopiering?
Många företag kan svara ja på frågan om de har backup. Färre kan svara på hur lång tid en fullständig återställning tar.
Testa återställningen före lansering. Dokumentera vilka system som måste startas först, vem som fattar beslut och hur verksamheten arbetar manuellt om applikationen ligger nere.
Säkerhetskopior bör vara separerade från produktionsmiljön. Annars riskerar även kopiorna att krypteras eller förstöras vid ett intrång.
9. Finns en plan för incidenter och rapportering?
Bestäm i förväg vem som leder arbetet om något händer. Ta fram kontaktvägar till utvecklare, driftleverantör, ledning, juridiskt stöd och kommunikation.
Vid en personuppgiftsincident måste företaget snabbt bedöma riskerna för de berörda. Vissa incidenter ska anmälas till IMY, och organisationen ska dokumentera samtliga personuppgiftsincidenter.
Sveriges nya cybersäkerhetslag trädde i kraft den 15 januari 2026. Den ställer skärpta krav på vissa offentliga och privata verksamhetsutövare inom utpekade sektorer, bland annat kring riskhantering och rapportering av betydande incidenter. Även företag som inte omfattas direkt kan möta högre krav genom kunder, upphandlingar och leverantörsavtal.
För programvara som omfattas av EU:s Cyber Resilience Act börjar rapporteringskraven för aktivt utnyttjade sårbarheter och allvarliga säkerhetsincidenter gälla den 11 september 2026.
10. Vem äger säkerheten efter lanseringen?
Lanseringen är inte slutet på säkerhetsarbetet. Den är början på den period då riktiga användare, riktiga data och riktiga angripare möter systemet.
Utse därför en ansvarig person eller funktion för uppdateringar, sårbarheter, loggar och incidenter. Bestäm hur länge applikationen ska få säkerhetsuppdateringar och vad som händer när en leverantör slutar stödja en komponent.
Ett system utan en ägare blir med tiden ett system som ingen vågar ändra men som verksamheten inte kan vara utan.
Slutsats: lansera inte bara en fungerande applikation
Säker programvara betyder inte att varje tänkbar risk är eliminerad. Det betyder att företaget förstår riskerna, har valt rimliga skydd och kan upptäcka, hantera och återhämta sig från problem.
Innan lanseringen bör ledningen därför kunna svara på fyra frågor:
Vilken information kan skadas?
Hur kan någon få obehörig åtkomst?
Hur upptäcker vi att något har hänt?
Hur fortsätter verksamheten om systemet slutar fungera?
En applikation är inte redo bara för att den fungerar.
Den är redo när företaget också vet varför den går att lita på.