Guider

När företag börjar bygga produkter med AI, eller integrera språkmodeller i befintliga system, uppstår nya former av av säkerhetsrisker. Traditionella säkerhetsverktyg är byggda för förutsägbara system där samma input alltid ger samma output och logiken går att granska rad för rad. Men så fungerar inte AI-system. De beter sig icke-deterministiskt, det vill säga svaret kan variera även med identisk inmatning, och de tar emot instruktioner i vanlig text snarare än i kod. Det öppnar attackytor som klassiska säkerhetsramverk inte är byggda för.

Den här guiden ger en konkret överblick av de viktigaste riskerna, hur de testas och vad du kan göra för att minska dem.

‍

Varför AI-säkerhet är annorlunda

I ett traditionellt webbaserat system finns det en tydlig logik att testa: kod som gör saker, svar som följer regler, beteende som går att förutsäga. Säkerhetsarbetet handlar om att hitta luckor i den logiken. AI-system fungerar annorlunda på några sätt som faktiskt spelar roll för säkerheten.

Beteendet varierar. Modellen kan ge olika svar på samma fråga, och det gör det svårt att definiera vad som är normalt och ännu svårare att garantera att säkerhetskontroller håller i alla lägen.

Träningsdata är en möjlig attackväg. En angripare som kan påverka vad modellen tränas på kan forma hur den beter sig i grunden. Det kallas data poisoning och är ett av de svårare problemen att upptäcka i efterhand.

Instruktioner kommer som vanlig text. Användare skriver till modellen på naturligt språk, och modellen kan inte på ett tillförlitligt sätt skilja på legitima instruktioner och skadliga. Det skapar en attackyta som lever i själva innehållet, inte i koden.

Det finns också ett ansvarsglapp som är lätt att missa. Leverantörer som OpenAI och Anthropic ansvarar för sin infrastruktur och sin modell, men hur du hanterar inmatningar, vilka verktyg modellen får tillgång till och hur du filtrerar output, det är ditt ansvar. De flesta allvarliga incidenter inträffar i det gapet.

‍

De största riskerna — OWASP Top 10 för LLM

OWASP, organisationen bakom de välkända säkerhetslistorna för webbapplikationer, har publicerat en lista specifikt för AI-system och språkmodeller. Listan uppdaterades 2025 och speglar hur hotbilden har förändrats i takt med att fler företag börjat bygga med AI. Här är de tio riskerna.

‍

Prompt Injection

En angripare smugglar in instruktioner i text som modellen behandlar och kapar på så sätt modellens beteende. Det kan ske direkt via användarens egna inmatningar, eller indirekt via dokument och webbsidor som modellen hämtar och läser. Prompt injection är den mest utbredda attack-klassen mot AI-system och saknar i dag en generell teknisk lösning.

‍

Sensitive Information Disclosure

Modellen läcker känslig information, till exempel interna instruktioner som styr hur den beter sig, konfidentiella dokument i dess kontext eller uppgifter från andra användare. Risken ökar i system som hämtar information från externa källor, eller där flera användare delar samma kontext.

‍

Supply Chain

AI-applikationer beror på en lång kedja av komponenter: modell-API, databaser, plugins, träningsdata. Komprometteras någon del av kedjan kan en angripare påverka modellens beteende utan att röra applikationskoden direkt.

‍

Data and Model Poisoning

Den data som modellen tränas eller finjusteras på manipuleras i syfte att påverka hur den beter sig. Det kan handla om att plantera dolda beteenden som aktiveras av specifika triggers, eller att systematiskt vrida modellens svar i en viss riktning. Svårt att upptäcka, och svårt att åtgärda när det väl har skett.

‍

Improper Output Handling

Modellens svar behandlas som pålitlig data och skickas vidare utan tillräcklig kontroll. Det öppnar för attacker längre ned i kedjan: om modellen genererar JavaScript som renderas direkt i en webbläsare, eller SQL som körs mot en databas utan filtrering, kan en angripare styra vad som faktiskt exekveras.

‍

Excessive Agency

Modellen ges fler behörigheter och verktyg än vad uppgiften kräver. Om en attack lyckas är det modellens faktiska behörigheter som avgör hur stor skadan kan bli. En AI-agent som får skriva filer, skicka e-post och anropa externa tjänster är ett betydligt allvarligare problem än en som bara får läsa.

‍

System Prompt Leakage

Systemprompten, de bakomliggande instruktioner som styr hur modellen beter sig, exponeras för användare eller angripare. Dessa instruktioner innehåller ofta känslig logik: säkerhetsregler, interna riktlinjer, API-nycklar och behörighetsstrukturer. Om de läcker får angripare en detaljerad karta över hur systemet fungerar.

‍

Vector and Embedding Weaknesses

Många AI-system använder RAG, vilket innebär att modellen hämtar relevant information från en extern kunskapsbas innan den svarar. Den kunskapsbasen indexeras som numeriska vektorer (embeddings). Sårbarheter här inkluderar att skadliga vektorer smygs in i databasen och påverkar vilken information som hämtas, eller att konstruerade frågor lurar systemet att returnera data som inte borde vara tillgänglig.

‍

Misinformation

Modellen genererar felaktiga påståenden med hög säkerhet. I affärsapplikationer kan det leda till felaktiga beslut, juridiska problem eller skadat förtroende. Risken är störst i system där modellens svar presenteras som fakta utan källhänvisning och utan ett mänskligt verifieringssteg.

‍

Unbounded Consumption

Applikationen tillåter oreglerad resursanvändning. En angripare kan konstruera frågor som triggar extremt kostsamma beräkningar, driva upp kostnader kraftigt eller orsaka driftsstörningar. I tjänster med rörlig prissättning per API-anrop kan det få direkt ekonomisk effekt.
‍

Läs vår artikel om: Säkerhet i LLM-applikationer – vad företag behöver veta

‍

Sårbarheter i RAG-system och agenter

RAG-system och AI-agenter introducerar ytterligare risker som förtjänar ett eget avsnitt.

RAG, Retrieval-Augmented Generation, är en teknik där modellen hämtar information från en extern kunskapsbas innan den svarar. Det gör systemet mer faktabaserat och aktuellt, men öppnar också för en indirekt variant av prompt injection: en angripare som kan påverka innehållet i de dokument som modellen läser kan styra vad modellen säger, utan att användaren gör något fel. Retrieval-manipulation är en liknande attack där en konstruerad fråga lurar hämtningslogiken att returnera fel information.

AI-agenter är system där modellen inte bara svarar utan också agerar, till exempel söker information, skriver kod, skickar e-post eller anropar externa tjänster. Det förstärker effekten av alla andra risker. Ju fler saker en agent får göra, desto mer kan en angripare åstadkomma om de lyckas kapa dess beteende. Grundregeln är enkel men lätt att strunta i under utveckling: ge agenten bara de behörigheter som faktiskt behövs för uppgiften.

‍

Dataskydd och AI — GDPR och EU AI Act

Att integrera AI i affärssystem väcker juridiska frågor som går bortom ren säkerhetstestning, och det är värt att ha grunderna klara.

EU AI Act började gälla i faser från 2024 och de flesta kraven slår igenom under 2026 och 2027, beroende på vilken typ av system det gäller. Lagen klassificerar AI-system efter risk, och kraven skalar med klassificeringen. Högrisk-system, det vill säga system som används vid kreditbeslut, rekrytering eller medicinsk diagnos, har de tyngsta kraven: riskhantering, teknisk dokumentation och löpande övervakning. Alla företag som utvecklar eller använder AI-system inom EU träffas av lagen i någon utsträckning, även om det är högrisk-kategorin som har flest konkreta skyldigheter att förhålla sig till.

GDPR-frågan handlar framför allt om vad som händer när du skickar data till en extern AI-leverantör. Sedan 2023 finns EU-US Data Privacy Framework, ett ramverk som gör det möjligt att överföra personuppgifter till certifierade amerikanska företag, inklusive de stora AI-leverantörerna, utan att behöva teckna separata avtal för varje överföring.  

Det som är värt att kontrollera är att din specifika leverantör faktiskt är certifierad, och att de avtal som finns täcker den data du faktiskt skickar. Rättsläget kring internationella dataöverföringar har förändrats flera gånger de senaste åren och kan förändras igen.

Det praktiska rådet är enkelt: skicka inte mer data än nödvändigt. Personuppgifter och konfidentiell affärsdata bör hållas utanför modellens kontext i den mån det går, och när det inte går bör du veta exakt vilket avtal som reglerar behandlingen.

Hur testar man AI-säkerhet?

Att säkerhetstesta ett AI-system kräver en annan metodik än klassisk pentestning. Klassisk pentestning testar känd logik i känd kod. AI-testning testar hur ett system beter sig när det utsätts för fientliga inmatningar, och det kräver både teknisk bredd och förståelse för hur språkmodeller fungerar.

Prompt injection-testning är grunden. Det handlar om att systematiskt försöka kapa modellens beteende via inmatningar: direkta instruktioner, rollspelsscenarier och instruktioner inbäddade i dokument som modellen läser. Det går inte att automatisera fullt ut, utan det behövs manuell testning av en person som förstår hur modeller beter sig.

Jailbreak-testning undersöker om modellens säkerhetsfiltrar kan kringgås för att få den att generera svar den normalt blockerar. Metoderna förändras snabbt och kräver löpande uppdatering av testfall.

Dataläckagetestning undersöker om en angripare kan manipulera modellen att lämna ut information från sin kontext eller från anslutna datakällor till en obehörig mottagare.

Adversarial testing handlar om konstruerade inmatningar som är utformade för att manipulera modellens klassificering eller svar på ett specifikt sätt, ofta subtilt nog att det inte syns för en vanlig användare.

Cyloqs approach utgår från offensiv säkerhetskompetens tillämpad på AI-specifika attackmetoder. Vi testar era AI-system på samma sätt som en angripare skulle göra det, med OWASP Top 10 för LLM som ett av ramverken.

‍

Praktiska åtgärder för företag

Det finns ett antal åtgärder som minskar riskytan påtagligt och som bör vara på plats i alla system med AI-integration i produktion.

‍

1. Validera inmatningar. Filtrera och kontrollera vad användare skickar in innan det når modellen. Det tar inte bort prompt injection-risken helt, men det minskar attackytan.

‍

2. Kontrollera vad modellen skickar vidare. Behandla aldrig modellens svar som betrodd kod eller data. Sanera och validera output innan den renderas i en webbläsare eller skickas till andra system.

‍

3. Begränsa behörigheter. Ge modellen och eventuella agenter bara de rättigheter som faktiskt behövs för uppgiften. Ju mindre ett angrepp kan åstadkomma, desto bättre.

‍

4. Övervaka prompt-mönster. Logga och analysera inmatningar löpande för att upptäcka avvikande beteenden och pågående försök att manipulera modellen. Det ger er synlighet och underlag om något händer.

‍

5. Tänk igenom vilken data som skickas. Personuppgifter och konfidentiell affärsdata bör hållas utanför modellens kontext i den mån det är möjligt. Skicka bara det som faktiskt behövs för att lösa uppgiften.

‍

6. Testa regelbundet. AI-system förändras snabbt: modellversioner uppdateras, instruktioner justeras, nya funktioner adderas. Testa vid varje större förändring och minst en gång per år för system i produktion.

NIS2 är EU:s direktiv om cybersäkerhet. Det ställer tydligare krav, omfattar fler sektorer och ger tillsynsmyndigheter verkliga muskler att agera, vid bristande efterlevnad. Om ditt företag inte redan vet om ni omfattas av NIS2 är det hög tid att ta reda på det.

Den här guiden går igenom vad NIS2 innebär i praktiken, om er verksamhet berörs av lagen, vad ni konkret måste göra och vad som händer om ni inte gör det.

‍

NIS2 i korthet

NIS2 (Directive on Security of Network and Information Systems, EU 2022/2555) är EU:s uppdaterade regelverk för cybersäkerhet. Det ersätter NIS1 från 2016 och trädde i kraft på EU-nivå i januari 2023. I Sverige implementerades direktivet genom cybersäkerhetslagen (2025:1506), som gäller från den 15 januari 2026. Samtidigt upphävdes den tidigare svenska NIS-lagen.

Jämfört med föregångaren NIS1 är skillnaderna stora. Antalet reglerade sektorer har mer än fördubblats, från sju till arton. Kraven är skarpare och mer konkreta. Böterna är höga. Och ledningen kan inte längre hålla sig på avstånd från frågorna.

I Sverige är tillsynen uppdelad per sektor. Myndigheten för civilt försvar (MCF) samordnar arbetet på nationell nivå, men det är sektorsspecifika myndigheter som granskar att lagen följs i praktiken, bland annat:

‍

• Transportstyrelsen för transport  

• Finansinspektionen för finanssektorn  

• Energimyndigheten för energi  

• Post- och telestyrelsen för elektronisk kommunikation
  
  Läs mer: Vad är NIS2 och vad innebär det för dig?

‍

Omfattas ditt företag av NIS2?

Cybersäkerhetslagen delar in verksamheter i två kategorier: väsentliga och viktiga. Kraven på säkerhetsåtgärder är i princip desamma för båda, men tillsynen skiljer sig åt. Väsentliga verksamheter är föremål för löpande, proaktiv tillsyn. Viktiga verksamheter granskas reaktivt, det vill säga när det finns indikationer på brister.

Väsentliga sektorer inkluderar bland annat energi (el, gas, olja, fjärrvärme, vätgas), transport (flyg, järnväg, väg, sjöfart), bank och finansmarknadsinfrastruktur, hälso- och sjukvård, dricksvatten och avloppsvatten, digital infrastruktur samt offentlig förvaltning.

Viktiga sektorer inkluderar bland annat posttjänster, avfallshantering, kemikalietillverkning, livsmedelsproduktion, tillverkning av medicinteknisk utrustning och motorfordon samt digitala leverantörer.

Den fullständiga förteckningen över sektorer finns i cybersäkerhetslagen och på mcf.se.

Storlekskriterier: Som huvudregel gäller lagen för medelstora och stora organisationer, det vill säga verksamheter med minst 50 anställda eller en omsättning och balansomslutning som överstiger 10 miljoner euro. Mikro- och småföretag är undantagna om de inte tillhör en sektor där de bedöms vara särskilt kritiska. De allra flesta statliga myndigheter, regioner och kommuner omfattas oavsett storlek.

Tillhör ni en sektor som uppfyller storlekskriterierna och är verksamma i Sverige? Då träffas ni troligen av lagen. Nästa steg är att anmäla er verksamhet till Myndigheten för civilt försvar.

Är det oklart om er verksamhet träffas? Rådgör med jurist eller kontakta tillsynsmyndigheten för er sektor.

‍

Läs mer: Cybersäkerhet för kommuner och offentlig sektor

‍

Kärnkraven — tio säkerhetsåtgärder

Artikel 21 i NIS2-direktivet listar tio säkerhetsåtgärder. Alla som omfattas av lagen måste ha dem på plats.

‍

1. Riskanalys och informationssystemssäkerhet

Ni ska löpande identifiera, värdera och hantera risker mot era system. Det handlar om att ha koll på vilka tillgångar ni har, vilka hot som finns och hur ni prioriterar skyddet. Det här arbetet ska vara kontinuerligt, inte något ni gör en gång och sedan lägger i en låda.

‍

2. Incidenthantering

Ni ska kunna upptäcka, hantera och återhämta er från säkerhetsincidenter. Det kräver tydliga roller och att folk vet vad de ska göra när något händer. En plan som aldrig testats ger falsk trygghet. Öva era rutiner.

‍

3. Driftskontinuitet

Säkerhetskopior, återställningsplaner och krishantering ska finnas på plats. Målet är att hålla igång verksamheten även när något går fel. Kartlägg vilka system som är kritiska och vad ni är beroende av.

‍

4. Leveranskedjans säkerhet

Ni ansvarar inte bara för er egen miljö. Leverantörer och underleverantörer som levererar digitala tjänster till er är också er risk. Kartlägg er leveranskedja och ställ säkerhetskrav i avtal.

‍

5. Säkerhet vid förvärv, utveckling och underhåll av system

Säkerhet ska vara med från början, inte något ni lägger till när systemet redan är i drift. Det inkluderar att hålla system patchade, hantera sårbarheter och ha rutiner för att agera på ny sårbarhetsinformation.

‍

6. Utvärdering av säkerhetsåtgärder

Ni ska kunna visa att det ni gör faktiskt fungerar. Det kräver uppföljning och mätning av säkerhetsarbetet. Regelbunden säkerhetstestning, till exempel penetrationstest, är en naturlig del av det.

‍

7. Cyberhygien och utbildning

Alla i organisationen ska ha tillräcklig kunskap för att inte utgöra en sårbarhet. Utbilda personalen och bygg en kultur där säkra beteenden är det normala. Ledningen ska delta aktivt, inte bara nicka igenom besluten.

‍

8. Kryptografi och kryptering

Ni ska ha rutiner för hur kryptografi används i verksamheten. Det gäller skydd av data både när den lagras och när den skickas, samt hur kryptografiska nycklar hanteras.

‍

9. Åtkomstkontroll och personalsäkerhet

Vem som har åtkomst till vad ska styras av roll och faktiskt behov. Det inkluderar rutiner när personal tillkommer eller slutar, löpande kontroll av behörigheter och hantering av IT-tillgångar.

‍

10. Flerfaktorsautentisering och säkrad kommunikation

Starka inloggningsmetoder ska användas för åtkomst till kritiska system, både externt och internt. Intern kommunikation och nödkommunikation ska vara säkrad.

‍

Rapporteringsskyldigheter

NIS2 ställer tydliga krav på hur och när ni ska rapportera incidenter. Rapporteringen sker till tillsynsmyndigheten för er sektor.

Inom 24 timmar från det att ni fått kännedom om en betydande incident ska en tidig varning skickas in. En kort signal om att något allvarligt har inträffat, mer behövs inte i det här läget.

Inom 72 timmar ska en mer fullständig incidentanmälan vara inskickad. Här beskriver ni vad som hänt, era initiala bedömningar och vilka åtgärder ni vidtagit.

Inom en månad ska en slutrapport lämnas med en komplett analys av incidenten, dess konsekvenser och hur ni har hanterat den.

Vad räknas som en "betydande" incident? En incident som orsakar eller riskerar att orsaka allvarliga driftstörningar för er tjänst, eller som påverkar andra organisationer eller samhällsfunktioner. Kontakta tillsynsmyndigheten för er sektor om ni är osäkra.

Tänk på att sen eller utebliven rapportering kan leda till sanktionsavgifter. Ni behöver inte ha drabbats av en allvarlig attack för att få böter, bristande efterlevnad räcker.

‍

Ledningens ansvar

En av de tydligaste nyheterna i NIS2 jämfört med NIS1 är att ledningsansvaret är uttalat. Cybersäkerhet går inte längre att endast delegera till IT-avdelningen.

Styrelsen och ledningen ansvarar för att godkänna och följa upp de säkerhetsåtgärder som lagen kräver. De ska utbilda sig inom cybersäkerhet för att kunna ta det ansvaret på allvar. Vid allvarliga brister kan de hållas personligen ansvariga.

Sanktionsavgifterna är kopplade till global omsättning. För väsentliga verksamheter upp till 10 miljoner euro eller 2 procent av global årsomsättning. För viktiga verksamheter upp till 7 miljoner euro eller 1,4 procent. Det högsta beloppet gäller.

Cybersäkerhet är med andra ord inte längre en IT-fråga med en egen budgetrad. Det är en ledningsfråga med rättsliga och ekonomiska konsekvenser.

‍

Så kommer ni igång — åtgärdsplan

Full efterlevnad tar tid. Strukturer, rutiner och säkerhetskultur byggs inte på en vecka. Men det finns en logisk ordning att jobba sig igenom.

Steg 1: Bekräfta om ni omfattas. Gå igenom listan över sektorer som inkluderas. Kontrollera er storlek mot tröskelvärdena. Kontakta tillsynsmyndigheten för er sektor om ni är osäkra. Anmäl er till Myndigheten för civilt försvar när ni vet att ni träffas av lagen.

Steg 2: Genomför en gap-analys. Mät er nuvarande säkerhetsnivå mot de tio åtgärderna i artikel 21. Identifiera var ni har luckor. Grunden finns ofta på plats, men systematiken och dokumentationen saknas.

Steg 3: Ta fram en åtgärdsplan med ansvariga. Prioritera efter risk och börja med det som ger störst effekt. Bestäm vem som ansvarar för vad och sätt realistiska deadlines. Ledningen ska vara med, det är ett krav enligt lagen.

Steg 4: Implementera och dokumentera. Genomför åtgärderna och dokumentera löpande. Ni ska kunna visa tillsynsmyndigheten att ni arbetar systematiskt. Dokumentation är bevis på att arbetet faktiskt görs.

Steg 5: Följ upp kontinuerligt. NIS2 är ett löpande arbete. Testa era planer, uppdatera riskanalysen och håll utbildningarna aktuella.

‍

Hur Cyloq hjälper

Cyloq arbetar med offensiv cybersäkerhet. Vi testar era system på samma sätt som en angripare skulle göra det, och ger er en konkret bild av var ni faktiskt är sårbara, inte bara vad policydokumenten säger.

Våra tjänster täcker flera av kraven i NIS2 direkt. Penetrationstest och sårbarhetsskanning adresserar krav 5 och 6 om sårbarhetshantering och utvärdering av säkerhetsåtgärder. Vår incidenthantering ger er beredskap att möta krav 2. Och beredskapsplanering stärker er driftskontinuitet enligt krav 3.

Vill ni veta var ni faktiskt står? Vi erbjuder en NIS2-gap-analys med en tydlig nulägesbild och en prioriterad åtgärdslista.

Kontakta oss

‍

Guiden ger en faktabaserad överblick av NIS2 och cybersäkerhetslagen. Den ersätter inte juridisk rådgivning. Tolkningsfrågor om er verksamhet träffas av lagen, eller hur specifika krav ska tillämpas i er kontext, bör stämmas av med jurist.

En cyberincident kan inträffa när som helst. Det kan vara ransomware som krypterar era filer mitt i natten, ett dataintrång som pågått i veckor utan att någon märkt något, eller en phishingattack som gav angriparen tillgång till ett administratörskonto. Det som avgör hur illa det går är sällan vilken typ av attack det rör sig om, utan hur snabbt och metodiskt ni reagerar.

Det är det incidenthantering handlar om.

‍

Vad är incidenthantering?

Incidenthantering, eller incident management på engelska, är den strukturerade processen för att identifiera, begränsa, utreda och återhämta sig från en säkerhetsincident. Det inkluderar både det tekniska arbetet, kommunikationen utåt och det juridiska efterspelet.

Många blandar ihop incidenthantering med krishantering. Krishantering är bredare och täcker allt från naturkatastrofer till PR-kriser. Incidenthantering är specifikt inriktad på IT-säkerhetsincidenter och har en väldefinierad process med tydliga roller och faser.

En vanlig missuppfattning är att det räcker med att ha en incidenthanteringsplan på papper. En plan som aldrig testats är i praktiken värdelös under en pågående attack. Stress, tidspress och oklara roller gör att otestad dokumentation sällan följs. Planen måste övas, och rollerna måste sitta.

‍

De sex faserna i incidenthantering

Etablerade ramverk för incidenthantering delar in processen i sex faser. De ser ut som en linjär sekvens, men i praktiken överlappar flera av dem med varandra, särskilt under en aktiv incident.

‍

Fas 1: Förberedelse

Allt börjar innan incidenten inträffar. Förberedelsefasen handlar om att bygga kapaciteten att faktiskt kunna hantera en incident. Det inkluderar att definiera roller och ansvar, ta fram en incidenthanteringsplan, etablera kommunikationskanaler och sätta upp de tekniska verktyg som behövs för loggning och detektion. Organisationer som investerar ordentligt i förberedelse hanterar incidenter snabbare, begränsar skadan mer effektivt och återhämtar sig med färre komplikationer.

‍

Fas 2: Identifiering

Något verkar konstigt. Kanske är ett system ovanligt långsamt, en användare har loggat in från ett oväntat land, eller ett larm har triggats i ert SIEM. Identifieringsfasen handlar om att avgöra om det faktiskt rör sig om en incident, och i så fall vad som hänt, vilka system som berörs och hur allvarligt det är. Felaktig eller försenad identifiering är ett av de vanligaste misstagen under incidenter, och varje timme av fördröjning ger angriparen mer spelrum.

‍

Fas 3: Inneslutning

Målet är att stoppa spridningen. Det kan innebära att isolera drabbade system från nätverket, blockera specifika IP-adresser, stänga av användarkonton eller segmentera delar av infrastrukturen. Det är viktigt att skilja på kortsiktig inneslutning, att snabbt begränsa skadan, och långsiktig inneslutning, som innebär mer hållbara åtgärder medan utredningen pågår. Att stänga av system för tidigt, utan att ha säkrat bevis, är ett vanligt misstag som kan försvåra den forensiska utredningen.

‍

Fas 4: Utrotning

När spridningen är stoppad börjar arbetet med att faktiskt rensa bort hotet. Det kan innebära att ta bort skadlig kod, stänga bakdörrar, återkalla komprometterade behörigheter och patcha de sårbarheter som angriparen utnyttjat. Utrotningsfasen kräver ofta djup teknisk kompetens och forensisk analys för att säkerställa att angriparen inte fortfarande befinner sig i miljön, dold i ett system ni inte tittat på.

‍

Fas 5: Återställning

Systemen är rensade. Nu handlar det om att gradvis ta dem tillbaka i drift och verifiera att de fungerar korrekt, utan kvarvarande hot. Återställning sker oftast i etapper, de mest kritiska systemen prioriteras och varje system övervakas noga innan nästa tas upp. Det är inte ovanligt att återställningsfasen tar veckor eller månader, särskilt efter ransomware-attacker där backupstrategin inte varit tillräckligt robust.

‍

Fas 6: Lärdomar

Incidenten är hanterad, men arbetet är inte klart. Två till fyra veckor efter att incidenten avslutats genomförs en strukturerad genomgång, ett "lessons learned"-möte, där hela händelseförloppet gås igenom. Vad fungerade? Vad fungerade inte? Vad borde vi ha märkt tidigare? Resultatet används för att uppdatera incidenthanteringsplanen, förbättra detektionsförmågan och se till att samma incident inte kan inträffa igen.

‍

Roller och ansvar under en incident

En incident är fel tidpunkt att diskutera vem som gör vad. De rollerna måste vara definierade och inövade i förväg.

Incidentledare är den person som leder insatsen och tar beslut under trycket. Det är inte nödvändigtvis den mest tekniskt kompetenta personen, utan den som kan hålla ihop helheten, kommunicera uppåt till ledningen och se till att arbetet rör sig framåt även när läget är oklart.

Teknisk lead ansvarar för den forensiska utredningen och de tekniska åtgärderna, att isolera system, analysera loggar och rensa bort hotet. I en komplex incident kan det krävas flera specialister med ansvar för olika delar av infrastrukturen.

Kommunikationsansvarig hanterar all kommunikation utåt, till kunder, leverantörer och om det behövs media, samt internt till medarbetare. Det är en roll som kräver god omdömesförmåga och som ofta underskattas under akuta incidenter.

Juridik och compliance behöver vara involverade tidigt, särskilt om persondata kan ha stulits. Tidsfristerna för rapportering är korta och det juridiska efterspelet kan bli kostsamt om det hanteras fel från start.

Ledningen behöver löpande uppdateringar och är ytterst ansvarig för affärskritiska beslut, till exempel om verksamheten ska stängas ner temporärt eller om det ska kommuniceras proaktivt till kunder.

‍

Kommunikation under en incident

Kommunikation under en aktiv incident är svårt. Det finns ett naturligt drag mot att säga så lite som möjligt för att undvika oro, men underinformation skapar ofta mer skada än transparens.

Internt ska medarbetare veta vad som händer, vad de förväntas göra och vad de inte ska göra. En vanlig instruktion är att inte prata om incidenten externt tills kommunikationsansvarig godkänt det, för att undvika att felaktig information sprids.

Externt behöver ni avgöra om kunder eller leverantörer berörs och när de ska informeras. En sen kommunikation som upplevs som förtäckt är ofta mer skadlig för förtroendet än en tidig kommunikation som erkänner vad som hänt.

Myndighetsrapportering är inte valfri. Vid persondataintrång är ni skyldiga att anmäla till IMY inom 72 timmar enligt GDPR. Vid incidenter i verksamheter som omfattas av NIS2 gäller en preliminär rapportering till relevant tillsynsmyndighet inom 24 timmar och en mer fullständig rapport inom 72 timmar. CERT-SE är nationellt kontaktorgan och kan ge operativt stöd vid allvarliga incidenter.

‍

Vanliga misstag under incidenter

Många av de misstag som görs under incidenter är förutsägbara. Det betyder att de går att förebygga.

‍

• Att stänga av system för tidigt. Det kan verka logiskt att omedelbart stänga av ett komprometterat system, men det kan förstöra viktiga bevis och försvåra den forensiska utredningen. Isolering är i de flesta fall bättre än att stänga av.

‍

• Att kommunicera för sent. Att vänta med att informera kunder eller myndigheter för att ha "hela bilden" leder ofta till att tidsfrister missas och att förtroendet skadas mer än nödvändigt.

‍

• Att sakna en testad backupstrategi. Det är inte ovanligt att organisationer som drabbas av ransomware upptäcker att deras backuper antingen är krypterade tillsammans med resten eller aldrig testats för återställning.

‍

• Att inte dokumentera i realtid. Under en aktiv incident är det lätt att fokusera på det tekniska och glömma att föra logg. Det försvårar både “lessons learned” och eventuell rättsprocess.

‍

• Att underskatta lateral rörelse. En angripare som tagit sig in i ett system har ofta rört sig vidare i nätverket. Att enbart fokusera på det första komprometterade systemet kan leda till att hotet kvarstår i miljön.

‍

• Att lösa incidenten utan att förstå grundorsaken. Att städa och återställa utan att ha identifierat hur angriparen tog sig in innebär att dörren fortfarande står öppen.

‍

När ska man kalla in extern hjälp?

Inte alla incidenter kräver extern support, men i en del lägen är det avgörande att få in rätt kompetens snabbt.

Kalla in extern hjälp om attacken fortfarande pågår och ni inte har kapacitet att stoppa den, om den interna kompetensen inte räcker till för forensisk utredning, om compliance-krav gör att utredningen behöver dokumenteras av oberoende part, eller om incidentens omfattning är oklar.

Cyloq kan kopplas in akut, även om ni inte är kund sedan tidigare. Det första samtalet är kostnadsfritt och parallellt med att insatsen påbörjas definieras scope och avtal, för att inte försena responsen. Ju tidigare ni ringer, desto fler alternativ har ni.

Läs vår artikel: Vad gör du när ditt företag utsatts för intrång?

Penetrationstest i korthet

Ett penetrationstest, eller pentest, är en kontrollerad och auktoriserad attack mot era IT-system. En certifierad säkerhetsspecialist försöker ta sig in i era system på samma sätt som en verklig angripare skulle göra, med målet att hitta svagheter innan någon annan gör det.

Företag genomför pentester för att förstå hur väl deras säkerhet faktiskt håller. Inte bara på papper, utan i praktiken. Det ger en konkret bild av vilka risker som finns och vad som behöver åtgärdas, formulerat på ett sätt som går att agera på. Vi har koll på det här, Cyloq har genomfört 500+ granskningar och identifierat 670+ kritiska sårbarheter hos svenska företag och organisationer.

‍

Vilka typer av penetrationstester finns?

Vilket test som passar beror på vad ni vill skydda. De vanligaste testerna ser ut så här:

‍

Webbapplikationstest

Ett webbapplikationstest granskar säkerheten i webbaserade tjänster, inloggningsfunktioner, formulär och dataflöden. Det passar er som har en kundinriktad webbtjänst eller en intern webbapplikation som hanterar känslig information.

‍

API-test

Ett API-test fokuserar specifikt på hur era API:er hanterar autentisering, behörighetskontroll och dataexponering. Det är särskilt viktigt för organisationer som integrerar tjänster med externa parter eller exponerar API:er mot kunder och partners.

‍

Test av extern infrastruktur

Ett test av extern infrastruktur granskar allt som är synligt mot internet, brandväggar, servrar, DNS och publika tjänster. Det är ett bra första test för organisationer som vill förstå vad en angripare egentligen ser och kan utnyttja utifrån, utan att ens ha någon förkunskap om er miljö.

‍

Internt nätverkstest

Ett internt nätverkstest simulerar ett scenario där en angripare redan tagit sig in, till exempel via ett lyckat nätfiskeförsök eller ett komprometterat konto. Det är rätt val när ni vill förstå hur långt en intern angripare faktiskt kan röra sig i miljön och vad som är åtkomligt om perimeterskyddet brister.

‍

Molntest

Ett molntest granskar konfigurationer i Azure, AWS eller Google Cloud. Det passar särskilt er som migrerat till molnet nyligen eller som byggt ut era molntjänster. Felkonfigurationer är en av de vanligaste orsakerna till dataintrång i molnmiljöer och något traditionella nätverkstester sällan täcker.

‍

Active Directory-test

Ett Active Directory-test granskar hur väl er AD-miljö är skyddad mot attacker som privilege escalation, lateral movement och Kerberoasting. Det är relevant för i princip alla organisationer som kör Windows-baserade miljöer, och extra viktigt om ni hanterar känsliga system eller har många användare med olika behörighetsnivåer.

‍

Mobilappstest

Ett mobilappstest granskar säkerheten i iOS- och Android-applikationer, hur data lagras lokalt, hur kommunikationen med back-end sker och om det går att manipulera appens beteende på sätt som inte var tänkt. Det passar alla som har en app i produktion som hanterar användardata eller är kopplad till känsliga back-endsystem.

Boka ett möte med oss så ser vi vilket test som passar er bäst.

‍

När bör ett företag göra ett pentest?

Det finns ett antal situationer där ett pentest är särskilt motiverat:

‍

• Inför en produktlansering. Ett av de bästa tillfällena att testa, när ni fortfarande kan åtgärda fynd innan de når era användare.
  ‍
• Efter en större systemförändring. En migrering till molnet eller en ny integration introducerar nästan alltid nya risker.
  ‍
• Vid efterlevnadskrav. NIS2, ISO 27001 och PCI-DSS ställer krav på att säkerheten faktiskt testas och dokumenteras, och ett pentest är ett av de mest konkreta sätten att möta dem.
  ‍
• Efter en säkerhetsincident. För att förstå hur angriparen tog sig in och säkerställa att vägen är stängd.

För system som hanterar känslig data rekommenderas pentest som rutin, minst en gång per år. Hotbilden förändras kontinuerligt, och ett test som genomfördes för 18 månader sedan säger ingenting om hur ni står er idag.

‍

White box, grey box och black box — vad är skillnaden?

De tre varianterna skiljer sig åt i hur mycket information testaren får om systemet innan testet börjar, och valet påverkar både djup och kostnad.

Black box innebär att testaren startar helt utan förkunskaper, precis som en extern angripare. Det ger en realistisk bild av hur svårt det faktiskt är att ta sig in utifrån, men kan missa djupare sårbarheter som kräver mer tid och insyn att hitta.

White box ger testaren full tillgång till källkod, systemdokumentation och arkitektur. Det möjliggör en grundlig granskning och passar bra när ni vill maximera täckningen, till exempel inför en produktlansering eller ett större systemskifte.

Grey box är en kombination av de två. Testaren får begränsad information, som en inloggning eller en systemöversikt, vilket simulerar en angripare med viss insyn i miljön. Det är ofta det mest kostnadseffektiva alternativet för etablerade system och ger god täckning utan att kräva lika mycket tid som ett fullständigt white box-test.

‍

Hur går ett penetrationstest till?

Processen följer ett strukturerat mönster oavsett vilket test det rör sig om:

Det börjar med ett inledande möte där ni och testteamet definierar vad som ska testas, vilka system som ingår och vad som är utanför ramarna. Här bestämmer ni tillsammans tidsplan, testmetod och spelregler för engagemanget.

Därefter kartlägger testaren miljön, samlar information om exponerade tjänster, domäner och potentiella ingångspunkter, utan att ännu försöka ta sig in.

Därefter följer en sårbarhetsanalys. Här identifieras och utvärderas de ingångspunkter som hittats. Felaktiga inställningar, gammal mjukvara och logikbrister kartläggs och prioriteras inför nästa steg.

Exploateringen är det som skiljer ett pentest från en sårbarhetsskanning. Testaren försöker aktivt utnyttja de sårbarheter som identifierats för att verifiera om de faktiskt går att nyttja i praktiken och hur långt ett angrepp kan gå.

Allt dokumenteras sedan i en rapport med tekniska beskrivningar, allvarlighetsgraderingar och konkreta åtgärdsförslag. Rapporten är inte rådata, utan ett underlag ni faktiskt kan jobba med.

Avslutningsvis hålls en avstämning där ni går igenom fynden tillsammans med teamet. Ni kan diskutera prioriteringar och få era frågor besvarade.

Ett typiskt test tar 1 till 4 veckor beroende på omfattning och testtyp.

‍

Vad får man i en pentestrapport?

En välskriven pentestrapport är ett arbetsdokument, skriven för beslutsfattare som vill förstå riskbilden utan att behöva sätta sig in i de tekniska detaljerna. Den exekutiva sammanfattningen ger därför en icke-teknisk översikt av de viktigaste upptäckterna.

Varje sårbarhet klassificeras med en allvarlighetsgrad, vanligtvis enligt CVSS-skalan, från observationer till kritiska sårbarheter. Till varje fynd hör en teknisk beskrivning av hur sårbarheten fungerar, var den finns och vad den kan användas till. Dessutom finns reproduktionssteg antecknade som gör det möjligt för ert team att verifiera och förstå fynden mer i detalj.

Rapporten avslutas med konkreta åtgärdsförslag och en prioriteringsordning för vad som bör hanteras först. Det ska gå att fördela arbetet internt direkt efter genomgången.

Hotbilden förändras. Hänger din säkerhet med?

Cyberhoten utvecklas snabbare än någonsin. AI-drivna attacker, zero-days som utnyttjas inom timmar, och intrång via leverantörskedjan är inte längre något som “kan hända” – det händer hela tiden.

Enligt IBM Cost of a Data Breach Report 2025 låg mediankostnaden för ett dataintrång på $4.44 miljoner USD. En stor andel av dessa incidenter började med sårbarheter som hade kunnat förebyggas om rätt skyddsåtgärder funnits på plats. Bland de vanligaste vägarna in fanns phishing, attacker via leverantörer och tredjepart, och komprometterade inloggningsuppgifter. Samtidigt gör automatisering och AI att angrepp inte bara sker snabbare, utan också i betydligt större skala. Det leder till fler infektioner, helt enkelt för att fler träffas snabbare.

Vi på Cyloq granskar hundratals miljöer varje år. I den här guiden sammanfattar vi de sju vanligaste säkerhetsmissarna vi ser i verkligheten – både i kod och konfiguration, men också i arbetssätt, beslut och säkerhetskultur.

Etablerade ramverk som OWASP-listor är viktiga riktmärken, särskilt inom webbapplikationssäkerhet, men de täcker bara en del av bilden. I denna guide kombinerar vi dessa ramverk med observationer från verkliga attacker, tester och uppdrag. Vi lyfter både tekniska och organisatoriska brister som återkommer gång på gång – och ger dig åtgärdsförslag och tips för att och förebygga dem.

‍

1. Felkonfigurerade system och tjänster

Felkonfigurationer är ett av de mest underskattade hoten mot IT-säkerheten. De förekommer i allt från applikationer och molntjänster till nätverksinfrastruktur och autentiseringslösningar.

I OWASP Top 10 2025 för webbapplikationer listas detta som A02: Security Misconfiguration, men problemet är inte bara begränsat till webben. Felaktiga inställningar, kvarlämnade funktioner och öppna åtkomstpunkter dyker upp i alla typer av system och miljöer.

Det räcker med en felaktig inställning i ett system, en onödigt öppen port eller en kvarlämnad debug-funktion för att öppna dörren för ett intrång.

‍

Exempel på vad vi ofta ser:

• En öppen S3-bucket med känslig data, utan autentisering.

• Testinstanser som ligger publikt tillgängliga, med svaga lösenord.

• Adminpaneler som inte är skyddade bakom VPN eller IP-whitelist.

• Felaktiga rättigheter i molntjänster – där "alla" har läsrättigheter till allt.

Den gemensamma nämnaren är små misstag som ofta uppstått som en effekt av stress, otydliga ansvarsområden eller komplexa miljöer där ingen har full överblick. Många system byggs dessutom upp över tid, av olika personer, med olika nivåer av dokumentation, vilket gör det svårt att ha en samlad överblick. Detta är små misstag som kan leda till fullständig kompromettering av ett system.

‍

Vad du kan göra:

‍

• Gör kontinuerliga sårbarhetsskanningar
  Använd verktyg för automatiserad sårbarhetsskanning – både på kodnivå och i den exponerade infrastrukturen. Gör det inte bara vid release, utan löpande. Och glöm inte att även skanna test- och stagingmiljöer.

‍

• Definiera standardkonfigurationer
  Definiera hur ett säkert system ska vara konfigurerat i din organisation. Det gör det lättare att upptäcka avvikelser – och att följa upp att säkerhetskonfigurationer faktiskt efterlevs i praktiken.

‍

• Ha tydliga rutiner för deployment och change management
  All förändring i system ska följas upp med test. Automatiserade CI/CD-pipelines med inbyggda säkerhetskontroller minskar risken för att oavsiktliga felkonfigurationer når produktion.

‍

• Repetera, granska, dokumentera
  Säker konfiguration är inte en engångsinsats. Det kräver löpande arbete, ansvarsfördelning och uppdaterade rutiner. Dokumentera inte bara vad ni gör – dokumentera också varför.

‍

2. Bristande segmentering

Nätverkssegmentering är det en av de mest grundläggande försvarsmekanismerna i moderna IT-miljöer.

Att ha en platt nätverksstruktur är som att alla dörrar till en byggnad är olåsta. Om en angripare tar sig in genom en enda sårbar punkt, till exempel en användares enhet eller en mindre skyddad server, kan de ofta röra sig fritt genom resten av infrastrukturen. Det kallas lateral rörelse, och är en vanlig metod i riktade attacker.

En angripare kan exempelvis ha fått initial access via ett gammalt externt webbgränssnitt, och inom loppet av timmar haft full access till interna HR-system, finansiell data och kundinformation. Bara för att nätverket saknade tillräcklig segmentering.

‍

Vad du kan göra:

‍

• Separera känsliga miljöer från användarnätverk

• Begränsa kommunikationen mellan segment med hjälp av brandväggar och policies

• Tillåt endast “need-to-know”-access mellan system

• Kombinera med Zero Trust-principer för autentisering och åtkomst

‍

Segmentering löser inte allt. Men den kan vara skillnaden mellan en lokal incident och ett fullskaligt intrång. Genom att begränsa åtkomst väger segmenteringen upp för andra svagheter, och köper dig tid att agera.

‍

3. Incidentrespons som bara finns på papper

De flesta organisationer har någon form av incidentplan. Den ligger i en mapp på intranätet, uppdaterades för ett par år sedan, och innehåller roller och processer som inte längre är relevanta. Och, den är aldrig testad i praktiken. Det är inte förrän en riktig incident inträffar som bristerna i planen märks, som exempelvis att:

‍

• Roller är otydliga eller obemannade.

• Loggningen fångar inte det som faktiskt pågår.

• Kommunikationsvägar är oklara.

• Beslut tas för sent – eller inte alls.

‍

Effekten det får är att attacken inte stoppas i tid och konsekvenserna blir enorma. Ta till exempel en organisation som utsätts för ransomware en fredag eftermiddag. IT-avdelningen försöker hantera situationen själva men har begränsad insyn i hur allvarligt det är. Säkerhetschefen kopplas in först på måndag morgon. Då har attacken redan spridit sig, backuperna är krypterade och flera affärskritiska system ligger nere.

‍

För att se till att ni har en gedigen incidentrespons bör ni:

‍

• Simulera på riktigt – gör tabletop-eller red teaming-övningar där olika incidenter spelas upp och teamet får fatta beslut i realtid.

• Testa tekniken – loggar ni det ni behöver? Går det larm vid rätt tillfällen? Testa och justera.

• Definiera roller – vem ansvarar för beslut, kommunikation, återställning? Det ska vara tydligt – även under stress.

• Utbilda organisationen – alla behöver inte kunna allt, men alla måste veta vad de ska göra.

‍

4. Övertro på intern kompetens

En annan vanlig miss många organisationer gör är att förlita sig på sitt interna säkerhetsteam. För även de mest kompetenta teamen riskerar att bli hemmablinda. När man granskar samma kodbas, samma konfigurationer och samma miljöer dag ut och dag in, är det lätt att förbise det som inte sticker ut, trots att det är just där hoten ofta gömmer sig.

Dessutom tenderar många organisationer att överskatta sin egen säkerhetsnivå. En intern kodgranskning, ett automatiserat verktyg eller en revision enligt mall skapar en känsla av trygghet, men den är inte alltid förankrad i verkligheten. Vi hör ofta: “Vi gjorde en egen granskning nyligen – det såg bra ut.” Ändå har vi vid första externa testet hittat allvarliga sårbarheter, som RCE (Remote Code Execution) eller exponerad känslig data.

Vi rekommenderar att man kompletterar sitt interna team med en utomstående cybersäkerhetsexpert, som inte är en del av organisationens processer, och ser på miljön med nya ögon. Det är ofta då man hittar de verkliga riskerna. Och för att säkra perspektivet över tid bör man även rotera mellan olika testare, eftersom även de kan bli hemmablinda.

‍

Tänk på:  

‍

• Kombinera intern granskning med extern validering – Låt det interna säkerhetsarbetet utmanas och kompletteras. Det ger en mer nyanserad bild av nuläget.

• Genomför externa penetrationstester regelbundet – Låt oberoende experter försöka ta sig in i era system. Ett pentest avslöjar ofta sådant som interna team missar.

• Välj rätt partner – Alla granskningspartner är inte lika vassa. Se till att ni anlitar experter som förstår er verksamhets behov och risker, och är experter på det de gör.

‍

En extern säkerhetsgranskning ger er även ett kvitto på att er säkerhet är testad i praktiken, vilket hjälper till att stärka förtroendet hos både kunder, investerare och styrelse.

‍

5. Svaga autentiserings- och åtkomstkontroller

Autentisering är det första hindret en angripare måste ta sig förbi. Men om det hindret är lågt, eller saknas, spelar det ingen roll hur stark resten av infrastrukturen är. Vi ser fortfarande konton som delas mellan flera användare, lösenord som skickas i klartext, eller flerfaktorsautentisering (MFA) som bara krävs i vissa system. Ibland används till och med standardlösenord på exponerade tjänster. Allt det här öppnar upp för intrång.

Men det handlar inte bara om vem som får logga in, utan också vad den personen kan göra efteråt. Det är två olika saker, och båda är vanliga problem. Dessa listas i OWASP Top 10. Brister i själva autentiseringen klassas under OWASP A07: Authentication Failures. Brister i behörighetshanteringen, alltså åtkomstkontroller, hamnar istället under A01: Broken Access Control, som är bland de allvarligaste och mest förekommande sårbarheterna vi hittar i våra tester.

‍

Exempel på vad vi ofta ser:

‍

• MFA som är konfigurerat men inte krävs för vissa användare eller endpoints. (A07)

• Applikationer som saknar spärrar mot upprepade inloggningsförsök (t.ex. kontolåsning eller rate limiting), vilket gör automatiserade attacker som credential stuffing och hybrid password spray attacks möjliga. (A07)

• Felaktigt hanterade sessionstokens som inte förnyas korrekt eller loggas i klartext. (A07)

• Användare som kan ändra API-anrop eller URL-parametrar för att komma åt andra användares data – trots att de inte har rätt behörighet. (A01)

• Roller och åtkomster som inte är korrekt avgränsade, vilket gör att en vanlig användare kan få adminbehörighet i vissa delar av systemet. (A01)

‍

Den gemensamma nämnaren är små misstag, ofta orsakade av komplexitet, bristande överblick eller otydliga ansvarsområden. Dessa brister skapar en attackyta som ofta kan utnyttjas länge innan någon ens märker att något är fel och kan leda till fullständig kompromettering.

‍

Vad du kan göra:

‍

• Implementera en central och standardiserad autentiseringslösning – använd etablerade protokoll som SAML eller OIDC istället för hemmasnickrade lösningar.

• Granska behörigheter – manuellt - automatiserade verktyg kan sällan avgöra vad som borde vara tillåtet. Gör manuella granskningar av rollstrukturer, API-anrop och åtkomstlogik.

• Ställ krav på MFA överallt – även internt – och verifiera att det verkligen är aktiverat för alla konton och applikationer.

• Använd least privilege som grundprincip - tilldela aldrig mer rättigheter än vad som krävs, och se till att det gäller både användare och systemintegrationer.

• Inför spärrar för brute-force-attacker – t.ex. kontolåsning eller CAPTCHA vid upprepade försök.

• Se till att sessionshanteringen är korrekt konfigurerad – tokens ska vara säkra, tidsbegränsade och inte exponerade.

• Övervaka autentiseringsflöden – identifiera misstänkta inloggningar eller ovanliga beteenden i realtid.

‍

6. Leverantörskedjan

Du kan ha full kontroll över dina egna system, men det räcker inte om dina leverantörer inte håller samma nivå. I dagens IT-landskap är de flesta miljöer uppbyggda av komponenter från andra: tredjepartsbibliotek, API:er, plugins, molntjänster, SaaS-lösningar. Varje sådan integration är en potentiell väg in. Och dessa attacker har ökat markant på sistone. Enligt 2025 Data Breach Investigations Report (DBIR) har andelen intrång där en tredje part var inblandad dubblats jämfört med förgående år; från 15 % 2024, till 30 % 2025.

När angripare inte kommer in genom huvudingången, letar de efter sidoingångar, och leverantörskedjan är ofta just det. Tredjepartsintegrationer, plugins och externa tjänster får sällan samma säkerhetsgranskning som de interna systemen, trots att de kan ha direkt access till affärskritiska data eller funktioner.

‍

Vanliga missar vi ser är:

‍

• Applikationer som använder externa komponenter utan att kontrollera uppdateringar eller ägarskiften.

• Otydliga säkerhetskrav i avtal - otillräckliga SLAs för patchning/incident reporting och inga krav på oberoende audit eller regelbundna pentest.

• Brist på rutiner för säkerhetskrav i inköpsprocessen – säkerheten antas istället för att verifieras.

‍

OWASP listar denna typ av sårbarhet under A03: Software Supply Chain Failures, som täcker just fall där tillit till kod, komponenter eller processer inte följs upp tillräckligt.

‍

Vad du kan göra:

‍

• Ställ krav på leverantörer och tredjepartstjänster – definiera tydliga minimikrav på säkerhetsnivå, uppdateringspolicy, incidentrapportering och rollbaserad åtkomst.

• Granska mjukvaruberoenden regelbundet – håll koll på vilka komponenter ni använder, och hur de förändras över tid.

• Ha separata miljöer och åtkomstkontroller för olika leverantörer – isolera integrationer så att de inte kan påverka kärnsystem vid kompromettering.

• Följ upp med återkommande granskningar och säkerhetsdialoger – det räcker inte att ställa krav vid onboarding, uppföljning krävs.

• Implementera Software Composition Analysis (SCA) – automatiserade verktyg som varnar för sårbara beroenden och licensrisker i kodbasen.

‍

7. Bristande säkerhetskultur

IT-säkerhet handlar som sagt inte bara om teknik, det handlar också om människor. Och just därför är den mänskliga faktorn en av de mest sårbara punkterna i de flesta organisationer. Det bekräftas även i Verizon DBIR 2025, där 60 % av alla intrång involverade mänskliga misstag på något sätt.

En felaktigt klickad länk, en glömd skärm med öppen information, eller en slarvigt hanterad USB-sticka kan räcka för att inleda en kedjereaktion. Även de mest robusta tekniska lösningarna kan kringgås om användarna inte förstår riskerna eller saknar rätt rutiner.

Men säkerhetskultur uppstår inte av sig själv. Den behöver jobbas på, aktivt och över tid. Det räcker inte med en obligatorisk e-learning en gång om året.

‍

Vad du kan göra:

‍

• Konfigurera ditt spamfilter – Detta för att minimera risken att phishing-mejlet ens når dina anställda.

• Utbilda kontinuerligt, inte punktvis – Skapa ett utbildningsprogram med återkommande insatser, inte bara för IT, utan för hela organisationen. Anpassa innehållet efter roller och risker.

• Simulera verkliga scenarier – Genomför phishing-simuleringar, incidentövningar och rollspel så att alla får öva i realistiska situationer.

• Sätt säkerhet på agendan – Lyft säkerhet i interna nyhetsbrev, avdelningsmöten och onboarding – inte bara i policies.

• Bygg en kultur där man vågar rapportera – Skapa ett klimat där misstänkta händelser rapporteras snabbt, utan skuld eller skam.

• Följ upp och förbättra – Mät säkerhetsbeteenden, samla in feedback och iterera på insatserna. En stark säkerhetskultur är inget man blir klar med.

‍

Vad är OWASP Top 10?

OWASP (Open Worldwide Application Security Project) är en global ideell organisation som arbetar för att förbättra mjukvarusäkerhet. En av deras mest kända resurser är OWASP Top 10, som listar de vanligaste och mest kritiska säkerhetsbristerna i webbapplikationer.

Listan används som branschstandard och är ett viktigt verktyg för utvecklare, säkerhetsarkitekter och beslutsfattare som vill förstå vanliga attackytor i webbaserade system.

OWASP tillhandahåller flera olika Top 10-listor (för API:er, moln, mobil, etc.), och många av de brister vi på Cyloq identifierar i våra tester ligger utanför dessa ramar – till exempel relaterade till konfiguration, åtkomstkontroller, leverantörskedjor eller mänskliga faktorer.

‍

Om Cyloq

Vi har arbetat med allt från techbolag och myndigheter till internationella koncerner och kritisk infrastruktur. Med över 15 års erfarenhet i ryggen har vi byggt upp ett sjätte sinne för hur angrepp sker, hur svagheter smyger sig in och var de verkliga riskerna gömmer sig. Och med erfarenhet från både offensiv och defensiv säkerhet vet vi hur angripare tänker, hur försvar faller, och hur de kan förstärkas.

Vi är en partner du kan lita på, med erfarenheten att förstå din verklighet och anpassa vårt arbete efter de specifika krav din bransch ställer.

‍

Redo att se om dina system är så säkra som du tror?

Nu vet du vilka misstag som kan fälla även de mest erfarna säkerhetsteamen. Kunskap räcker långt, men du behöver också testa dina system på riktigt.

Ett penetrationstest är det mest konkreta du kan göra för att hitta brister innan någon annan gör det. Det är en mindre insats som visar exakt var det brister och var ni bör förstärka.

För organisationer med komplexa system, många integrationer och höga säkerhetskrav är en extern granskning det bästa ni kan göra för att garantera att ett system eller applikation faktiskt håller tätt.

Cyloq genomför avancerade, manuella tester med angriparperspektiv. Vi kartlägger attackytan, identifierar sårbarheter och visar exakt hur långt en angripare skulle kunna ta sig, och vad du kan göra för att stoppa det.

Vårt fokus är inte att bekräfta att allt ser bra ut. Vårt fokus är att hitta det som kan sänka dig, innan någon annan gör det. Och om inte vi hittar några luckor, kan du vara säker på att ingen annan gör det heller.

‍

“Vi vill ju att de ska hitta saker, men man har ju också gott självförtroende. Vi tänkte att de inte skulle lyckas med detta på så kort tid.” - Tim, VX Fiber

‍

“Vi blev positivt överraskade. De hittade en hel del som inte hade kommit fram i tidigare penetrationstest eller vårt bug bounty program. Så vi var väldigt nöjda med resultatet penetrationstestet gav!” - Marcus, Stravito

‍

Förebygg bristerna. Testa på riktigt.

‍

Så här går ett penetrationstest med Cyloq till:

• Uppstartsmöte: Vi sätter scopet och målen tillsammans.

• Attackfas: Vi angriper din miljö, granskar varje yta, varje länk och varje väg in.

• Löpande rapportering: Kritiska brister rapporteras direkt.

• Leverans: Du får en konkret rapport med tydliga rekommendationer.

‍

När du är redo att gå från insikt till handling, finns vi här!