Säkerhetsgranskning – så fungerar en teknisk genomlysning

"Kan ni bara köra en säkerhetsgranskning på vår plattform?" är en av de vanligaste förfrågningarna vi får, och den döljer nästan alltid ett missförstånd om vad en säkerhetsgranskning faktiskt är. Det är inte en pentest, det är inte en ISO-revision, och det är definitivt inte en automatisk scanning som spottar ut en PDF. En teknisk säkerhetsgranskning är en bredare genomlysning av arkitektur, konfiguration, processer och kod – gjord för att ge en verklig bild av var riskerna ligger innan ni bygger en åtgärdsplan eller ett budgetunderlag.

Jag har genomfört den här typen av genomlysningar för allt från tioanställda SaaS-startups till bolag med flera hundra medarbetare och komplex molninfrastruktur, som en del av vårt cybersäkerhetsarbete. Den här artikeln går igenom hur en granskning faktiskt går till – från scope till slutrapport – så att ni vet vad ni beställer och vad ni bör kräva av leverantören.

Vad en säkerhetsgranskning är – och vad den inte är

En penetrationstest svarar på frågan "kan någon bryta sig in via den här specifika vägen?" och är avgränsat till att bevisa exploaterbara sårbarheter. En säkerhetsgranskning svarar på en bredare fråga: "var ligger våra risker sammantaget, och i vilken ordning ska vi åtgärda dem?" Den kombinerar teknisk analys med intervjuer, konfigurationsgranskning och processgenomgång, och resulterar i en prioriterad bild snarare än en lista över bevisade exploits. En ISO 27001- eller SOC 2-revision är i sin tur en formell kontroll mot ett specifikt ramverks krav – en säkerhetsgranskning kan förbereda er för en sådan revision, men är inte samma sak.

Vår rekommendation för de flesta bolag: gör en säkerhetsgranskning först för att förstå helheten, komplettera sedan med riktade penetrationstester mot de system där riskerna visade sig vara högst. Att beställa en pentest innan ni vet var de verkliga riskerna finns leder ofta till att testet fokuseras fel.

Scope och förberedelser – vad vi behöver från er

En bra granskning börjar med ett tydligt scope, inte med att konsulten "kollar lite på allt". Vi går igenom vilka system, miljöer och dataflöden som ska ingå, vilka som är undantagna och varför, samt vilken tidsperiod och vilka intressenter som behöver vara tillgängliga för intervjuer. Förberedelsen från kundens sida tar normalt en till två veckor och innebär att samla tillgångsregister, arkitekturdiagram (även om de är föråldrade – det säger också något), åtkomstlistor för kritiska system, och kontaktpersoner för infrastruktur, applikation och processer.

Ett vanligt misstag är att vänta med att bjuda in rätt personer till scope-mötet. Ju tidigare säkerhetsansvarig, en backend-utvecklare och någon från drift sitter med, desto mindre tid går åt till att jaga information mitt i granskningen. Vi rekommenderar också att sätta ett tydligt mål för granskningen redan i scope-fasen – "förbereda oss för NIS2", "due diligence inför en investeringsrunda" och "verifiera efter en incident" kräver olika viktning av vad vi gräver djupast i.

Tidsåtgången varierar mer än de flesta förväntar sig. En avgränsad granskning av en enskild SaaS-applikation med en molnmiljö tar normalt en till två veckor kalendertid, medan en granskning av ett bolag med flera produkter, blandad on-prem- och molninfrastruktur och ett tiotal integrationer lätt landar på fyra till sex veckor. Prissättningen följer samma logik – räkna med att den faktiska arbetstiden, snarare än kalendertiden, är det som avgör kostnaden, eftersom mycket av tiden går åt till intervjuer och manuell analys snarare än att bara köra verktyg.

De sex områdena vi går igenom

En teknisk genomlysning täcker normalt sex huvudområden, viktade efter er verksamhet:

• Identitet och åtkomst: hur konton skapas, vem har admin-rättigheter, om MFA är obligatoriskt, och hur offboarding faktiskt sköts i praktiken (inte bara på papper).
• Nätverk och infrastruktur: segmentering, exponerade portar och tjänster, brandväggsregler, och hur produktions- och testmiljöer är isolerade från varandra.
• Applikationssäkerhet: autentisering, sessionshantering, inputvalidering och beroendehantering i koden – ofta med stöd av statisk analys.
• Datahantering: kryptering i vila och under överföring, backup-rutiner och hur ofta återställning faktiskt testas, samt klassificering av känslig data.
• Molnkonfiguration: IAM-policyer, publika buckets och storage-resurser, loggning och larmning i molnmiljön.
• Processer och organisation: incidenthantering, patchhantering, leverantörskedjans säkerhet och hur säkerhetsansvar faktiskt är fördelat.

Verktyg och metod 2026

Metoden är en kombination av automatiserad scanning och manuell analys – automatiken hittar breda mönster snabbt, men det manuella arbetet hittar de risker som bara framgår av sammanhang. På infrastruktursidan använder vi verktyg som Nessus eller Tenable för sårbarhetsscanning, Prowler och ScoutSuite för molnkonfigurationsgranskning (AWS, Azure, GCP), och Nuclei för snabb, mallbaserad kontroll av kända exponeringar. På applikationssidan kompletterar vi med statisk kodanalys (Semgrep, CodeQL) och en manuell genomgång av autentiseringsflöden, som verktyg sällan fångar korrekt på egen hand.

Det manuella momentet är där mest värde skapas. Ett automatiserat verktyg kan flagga att en S3-bucket är publik, men det är den manuella genomgången som avgör om det faktiskt spelar roll – innehåller den känslig data, eller är det avsiktligt publikt marknadsföringsmaterial? Utan den bedömningen får ni en rapport full av brus som ingen orkar prioritera.

Hur fynd klassificeras

Varje observation vi gör dokumenteras med allvarlighetsgrad, sannolikhet för utnyttjande, affärspåverkan och en konkret åtgärdsrekommendation – inte bara "detta bör åtgärdas". Vi använder en CVSS-liknande skala kompletterad med en affärsriskbedömning, eftersom en teknisk hög-severity-brist i ett system utan känslig data ofta ska prioriteras lägre än en medelhög brist i betalningsflödet.

Den strukturen gör att ledningen kan läsa rapporten utan att förstå tekniska detaljer, samtidigt som utvecklingsteamet får exakt den information de behöver för att åtgärda.

Rapporten och åtgärdsplanen

En bra slutrapport har tre lager: en ledningssammanfattning på en till två sidor med de viktigaste riskerna och en övergripande riskbild, en prioriterad åtgärdslista med ägare och rekommenderad tidslinje per fynd, och en teknisk bilaga med full detaljering för de team som ska genomföra fixarna. Om rapporten inte går att omsätta i en konkret åtgärdsplan med ansvarig person och datum har den inte gjort sitt jobb – den är bara en dyr lista med observationer.

Vi lägger alltid in en uppföljningspunkt 60–90 dagar efter leverans, för att verifiera att de mest kritiska punkterna faktiskt är åtgärdade och inte bara markerade som klara i ett projektverktyg.

Hur ofta och när i livscykeln

Vår generella rekommendation är en fullständig granskning årligen, med riktade uppföljningar efter större förändringar – en ny molnmigrering, en sammanslagning, en större produktlansering eller inför en investeringsrunda där due diligence kräver dokumenterad säkerhetsmognad. För bolag som omfattas av NIS2 eller andra regelkrav är en granskning ofta det snabbaste sättet att gå från policy till en dokumenterad, verifierad bild av verkligheten.

Av de granskningar vi genomfört under 2026 hade drygt sex av tio bolag minst en kritisk brist de själva inte kände till innan vi började – oftast i molnkonfiguration eller i hur äldre integrationer autentiserar mot varandra. Det är precis den typen av blinda fläckar en extern genomlysning är till för att hitta, och det är också varför en genuint stark säkerhetsställning kräver mer än teknik – den kräver en säkerhetskultur som gör att teamen faktiskt agerar på det granskningen hittar.

Vill ni ha en objektiv bild av var era risker faktiskt ligger? Vi genomför tekniska säkerhetsgranskningar anpassade efter er miljö och er situation – läs mer om våra tjänster eller boka ett samtal.