Vad är en säkerhetsgranskning av ett företag?

Vad är en säkerhetsgranskning av ett företag? Här behöver du skilja den organisatoriska delen, som bedömer ansvar, behörigheter, säkerhetskopior och incidenthantering, från den tekniska delen, som kontrollerar systeminställningar, sårbarheter och kod. Priset beror på hur många och omfattande system som ska granskas och hur ingående arbetet är: vår automatiserade säkerhetskontroll kostar 89–890 € beroende på omfattningen, medan en manuell expertgranskning finns från 3 500 €. Ta först reda på vilken del du behöver och vilka belägg du förväntar dig, eftersom en webbplatskontroll, en bedömning av företagets säkerhetsstyrning och en certifiering är olika uppdrag med olika resultat.

Föreställ dig att en kund skickar ett krav på en säkerhetsgranskning innan avtalet ska undertecknas, men att bilagan innehåller frågor om både medarbetarnas behörigheter och teknisk kontroll av systemet. Det räcker inte att vidarebefordra kravet till utvecklaren: du behöver komma överens med kunden om huruvida kunden förväntar sig en rapport om webbplatsen, dokumenterade företagsprocesser eller ett certifikat från ett oberoende organ, och vilka system eller verksamhetsdelar intyget ska omfatta. Vi rekommenderar att du sparar kravets exakta formulering och klargör syftet innan du väljer utförare och godtar en prisberäkning.

Vad är en säkerhetsgranskning? Två uppdrag med samma namn

De båda delarna besvarar olika frågor. Den organisatoriska delen undersöker hur företaget fattar och genomför säkerhetsbeslut, medan den tekniska delen undersöker hur ett visst system fungerar och om dess skydd går att kringgå. Därför ser samma ämne helt olika ut i de båda delarna: vid en granskning av behörighetsrutiner ber granskaren att få se vem som godkänner en medarbetares behörigheter och hur de återkallas, medan granskaren vid ett applikationstest försöker utföra otillåtna åtgärder med ett vanligt konto. Resultaten bör läsas tillsammans, men det ena ersätter inte det andra: en välordnad behörighetspolicy bevisar inte att applikationen följer den, och en säker applikation bevisar inte att någon har stängt kontot för en medarbetare som slutat.

Därför säger enbart ordet ”granskning” i beställningen ganska lite. Vi rekommenderar att du kompletterar det med två saker: de kriterier som arbetet ska bedömas mot och de belägg du förväntar dig i rapporten. För en sårbarhetsbedömning handlar det om prioriterade fynd, för ett penetrationstest om en konkret skyddsmekanism eller begränsning som man ska försöka kringgå, och för en organisatorisk efterlevnadsgranskning om en uppsättning krav som dokument och dagliga rutiner ska jämföras med.

Om du bara väljer en inledande bristbedömning ska resultatet också benämnas så, snarare än certifiering, och redan i uppdragsbeskrivningen bör du komma överens om vem som ska läsa dokumentet och vilket beslut som ska fattas. Vid certifiering är det viktigt att veta vem som utfärdar intyget: ISO certifierar inte själv företag, och beskriver certifiering som ett skriftligt intyg från ett oberoende organ om att vissa krav är uppfyllda. I samma förklaring anger ISO att ackreditering styrker certifieringsorganets kompetens men inte är obligatorisk; påståendet att bara ackrediterade organ får certifiera vore därför felaktigt. Om din kund kräver ackrediterad certifiering ska du klargöra det villkoret före avtalet och kontrollera det valda organets ackreditering, så att du inte står med ett intyg som kunden inte har gått med på att godta.

Vi erbjuder teknisk kontroll av webbsystem och kan inom den organisatoriska delen hjälpa till att ta fram säkerhetspolicyer, men vi certifierar inte företag och driver inte ditt ledningssystem för informationssäkerhet (LIS), och den gränsen bör också skrivas in i beställningen. Om uppdraget omfattar både webbplatskontroll och bedömning av företagets styrning behöver du komma överens om vem som tar fram tekniska belägg, vem som jämför dem med de valda kraven och vem som ansvarar för slutbedömningen, eftersom du annars kan förvänta dig en bedömning av ledningsprocessen från oss och ett test som du inte beställt från den organisatoriska granskaren. Den organisatoriska delen utförs vanligen av en konsult inom informationssäkerhetsledning eller en ISO/IEC 27001-revisor, medan certifikatet utfärdas av ett certifieringsorgan.

Den organisatoriska delen: jämför dokumenten med arbetet

Det är lätt att skriva fina dokument, så i den organisatoriska delen bör du kontrollera att det finns ansvariga, nödvändiga resurser och belägg för att säkerhetspolicyn följs, och att åtgärder har planerats för problemen i riskbedömningen; ENISA:s vägledning för små och medelstora företag omfattar ledningens ansvar, medarbetarnas delaktighet och utbildning, säkerhetspolicyer, leverantörshantering, åtkomstskydd och en incidenthanteringsplan. Komplettera samtalen med ledning och medarbetare med granskning av dokument och konkreta exempel från arbetet, så att bedömningen kan skilja de avsedda rutinerna från hur de faktiskt följs och ange vilka belägg granskaren inte fick tillgång till och som fortfarande behöver tas fram.

När det gäller behörigheter tittar en bra granskare både på hur konton tilldelas och hur de stängs, om flerfaktorsautentisering används och vilka behörigheter leverantörer har, så exemplen bör omfatta en medarbetare som slutar eller ett leverantörsbyte: det är just då konton ofta glöms bort. Detsamma gäller säkerhetskopior, eftersom svaret ”vi tar kopior” säger ganska lite. En kopia som ingen någonsin har provat att återställa kan visa sig vara ofullständig vid en incident, och då upptäcks det först när webbplatsen redan ligger nere. Det behövs ansvariga för inventeringen av system och enheter, rutiner för granskning av händelseloggar och en namngiven person i incidenthanteringsplanen som fattar beslut och kommunicerar med de berörda, annars förblir planen ett dokument som ingen följer när incidenten inträffar.

Som kriterier kan du använda ISO/IEC 27001:2022, som anger krav på ett ledningssystem för informationssäkerhet (LIS); ordet ”system” avser här ledningen av arbetet, inte bara applikationen som granskas; BSI:s förklaring av standarden anger 93 informationssäkerhetsåtgärder och fyra områden: organisatoriska, personrelaterade, fysiska och tekniska. Kom överens om vilka krav granskningen ska bedöma och med vilka belägg, eftersom en hänvisning till standarden i prisberäkningen inte säger om du beställer en bedömning av ledningssystemet eller bara en teknisk kontroll vars resultat senare ska användas i en bredare granskning; skriv ned det valet innan arbetet börjar.

En annan grund är CIS Controls v8.1 med 18 grupper av säkerhetsåtgärder, som omfattar områden från inventering av företagets tillgångar till penetrationstester och sammanlagt innehåller 153 skyddsåtgärder. CIS beskriver CIS Implementation Group 1 (IG1) som grundläggande cyberhygien med 56 skyddsåtgärder, så ange även den valda gruppen i beställningen och inte bara ramverkets namn. Begär att rapporten kopplar varje bedömt krav till de mottagna beläggen och den konstaterade bristen, så att samma villkor kan kontrolleras efter åtgärderna i stället för att två allmänna bedömningar jämförs.

När lagen kräver en säkerhetsgranskning

Cybersäkerhetslagen (2025:1506), som gäller sedan den 15 januari 2026, innebär inte en allmän skyldighet för varje väsentlig eller viktig verksamhetsutövare att regelbundet beställa en extern granskning. Verksamhetsutövaren ska vidta lämpliga och proportionella tekniska, driftsrelaterade och organisatoriska säkerhetsåtgärder och ha strategier och förfaranden för att bedöma deras effektivitet. Den egna bedömningen är inte en säkerhetsrevision inom tillsynen. Tillsynsmyndigheten får själv eller genom ett oberoende organ utföra regelbundna säkerhetsrevisioner av väsentliga verksamhetsutövare enligt 3 kap. 5 § och, om det finns särskilda skäl, riktade säkerhetsrevisioner av den som står under tillsyn enligt 3 kap. 6 §. För viktiga verksamhetsutövare krävs dessutom anledning att anta att reglerna inte följs för att myndigheten ska få begära uppgifter, få tillträde till lokaler, göra riktade revisioner eller säkerhetsskanningar. Skanningar ska ske i samarbete med verksamhetsutövaren och får utföras av en extern part på myndighetens uppdrag. Varken lagen eller MCFFS 2026:12 anger ett visst antal år mellan regelbundna revisioner; myndigheten bestämmer intervallet med hänsyn till proportionalitet. Enligt MCFFS 2026:12, som gäller sedan den 1 oktober 2026, ska myndigheten säkerställa att ett anlitat organ arbetar opartiskt, självständigt och objektivt. De icke-bindande allmänna råden avråder från organ med affärsrelationer, rådgivningsuppdrag eller andra beroendeförhållanden till verksamhetsutövaren. Rapporten går till myndigheten. Lagen kräver inte att verksamhetsutövaren betalar revisorn; enligt förarbetena bör en riktad revision genom ett oberoende organ ske på myndighetens bekostnad. Revisionen får inte orsaka större kostnad eller olägenhet än nödvändigt. Verksamhetsutövaren ska medverka och kan föreläggas att göra det vid vite. Vid överträdelser ska myndigheten ingripa och kan förelägga verksamhetsutövaren att uppfylla sina skyldigheter; verksamhetsutövaren ansvarar för att åtgärda överträdelserna. Tillsynen är sektorsindelad enligt cybersäkerhetsförordningen (2025:1507). Exempelvis ansvarar Post- och telestyrelsen för digital infrastruktur, digitala leverantörer, förvaltning av IKT-tjänster mellan företag, post- och budtjänster samt rymden. Försvarets radioanstalt (FRA) är gemensam kontaktpunkt och CSIRT-enhet och tar emot anmälningar och incidentrapporter, men beslutar inte om säkerhetsrevisionen. Skyldigheterna i 2 kap. 3–10 §§ gäller inte den del av en verksamhet som är säkerhetskänslig enligt säkerhetsskyddslagen (2018:585) och inte heller verksamhetsutövare som omfattas av DORA. Verksamhetsutövare som undantas enligt artikel 2.4 i DORA står helt utanför cybersäkerhetslagen. Be därför den som erbjuder en ”obligatorisk granskning” att ange bestämmelsen och din status: Din egen effektivitetsbedömning är ett annat uppdrag än en säkerhetsrevision som sektorns tillsynsmyndighet beslutar om.

Myndigheten för civilt försvars föreskrifter och allmänna råd om säkerhetsåtgärder och ledningens utbildning (MCFFS 2026:11) gäller sedan den 1 oktober 2026 för väsentliga och viktiga verksamhetsutövare, med en viktig avgränsning. Om verksamheten som omfattas av lagen enbart finns inom digital infrastruktur, digitala leverantörer, förvaltning av IKT-tjänster mellan företag, post- och budtjänster eller rymden gäller bara kraven på ledningens utbildning, inte kraven på uppföljning och tester nedan. För DNS-leverantörer, registreringsenheter för toppdomäner och leverantörer av molntjänster, datacentraltjänster, nätverk för innehållsleverans, utlokaliserade driftstjänster, utlokaliserade säkerhetstjänster, marknadsplatser online, sökmotorer, plattformar för sociala nätverk och betrodda tjänster gäller kommissionens genomförandeförordning (EU) 2024/2690 direkt. Enligt punkt 6.5 i bilagan ska de utifrån sin egen riskbedömning fastställa behov, omfattning, frekvens och typ av säkerhetstestning. För verksamhetsutövare som omfattas av hela MCFFS 2026:11 kräver 3 kap. 19 § att säkerhetsåtgärdernas lämplighet och proportionalitet följs upp och utvärderas och att förbättringsbehov identifieras. För sektorskritiska system, alltså system som behövs för intern verksamhet eller externa tjänster i den verksamhet som omfattas av lagen, ska detta ske vid behov och minst en gång per år. Uppföljningen stannar hos verksamhetsutövaren; det finns inget krav på att lämna in en återkommande självutvärderingsrapport till en myndighet vid ett visst kalenderdatum. Enligt de icke-bindande allmänna råden kan uppföljningen göras genom granskning, mätning eller tester i form av egenkontroll, intern revision eller extern revision; extern revision är alltså valfri. Innan beslut fattas om att för första gången driftsätta ett system i den digitala miljön ska säkerhetstester och granskningar ha genomförts enligt 4 kap. 6 §. Det är inte ett särskilt krav på penetrationstest, och något fast intervall för återkommande penetrationstester anges inte heller i dessa regler eller i genomförandeförordningen. Enligt 4 kap. 27 § ska tester och granskningar av system i it-segment kontrollera att systemen har den senaste godkända versionen, att publicerade sårbarheter har hanterats och att valda konfigurationer har införts. Något fast testintervall anges inte; för system i ot-segment ska verksamhetsutövaren identifiera och hantera behovet av tester och granskningar. De allmänna råden rekommenderar etablerade metoder för automatiserade och manuella tester samt rapportering av tidigare opublicerade sårbarheter till den nationella CSIRT-enheten. Högre krav i andra författningar gäller framför dessa föreskrifter, och FRA kan medge undantag i enskilda fall om det finns särskilda skäl. Separat ska verksamhetsutövare som omfattas av lagen anmäla sig till FRA så snart det kan ske och anmäla ändrade uppgifter snarast, senast inom 14 dagar efter ändringen. Den anmälan är inte en självutvärdering av säkerheten. Verksamhetsutövare som omfattas av DORA är undantagna från säkerhetsskyldigheterna i 2 kap. 3–10 §§ i cybersäkerhetslagen. När du får ett erbjudande om en ”obligatorisk granskning” bör du därför begära att få den konkreta skyldigheten och din status angivna, så att den egna uppföljningen, inklusive den minst årliga uppföljningen för sektorskritiska system, inte behandlas som samma uppdrag som en säkerhetsrevision som sektorns tillsynsmyndighet beslutar om enligt 3 kap. 5 eller 6 § i cybersäkerhetslagen.

Den tekniska delen: från publika adresser till kod

Ange i den tekniska uppdragsbeskrivningen vilka publika adresser, DNS-poster, öppna tjänster och TLS-inställningar samt vilken server- eller molnkonfiguration, vilka webbapplikationer och vilken källkod du tillåter att utföraren granskar, och ange för varje del om utföraren får åtkomst till inställningarna eller bara ska bedöma det som syns utifrån, eftersom det är olika uppgifter. I NIST:s indelning av metoder för säkerhetstestning skiljs granskning av dokument, loggar och konfiguration från identifiering och analys av mål samt bekräftelse av sårbarheter; den indelningen kan du använda för att tydligare beskriva de valda metoderna och det förväntade resultatet i prisberäkningen.

För webbapplikationer ger OWASP Top 10:2025 ett gemensamt språk: tio riskkategorier, där de två första är brister i åtkomstkontrollen och osäker konfiguration. Listan i sig kontrollerar ingenting, så en bra granskare omvandlar varje kategori till en fråga om din applikation: för åtkomstkontroll innebär det att försöka utföra en rolls åtgärder med en annan rolls konto, och för kategorin osäker design att välja en affärsprocess vars regler skulle kunna kringgås. Komplettera hänvisningen till OWASP med kontrollens omfattning, så att båda parter vet vilka funktioner och användarroller som faktiskt ingår i arbetet.

För e-post bör du planera en bedömning av SPF-, DKIM- och DMARC-inställningarna och koppla uppdraget till de system som företaget skickar meddelanden från: Googles krav på avsändare innebär sedan den 1 februari 2024 att alla som skickar till Gmail-konton ska konfigurera SPF eller DKIM, medan de som skickar fler än 5 000 meddelanden per dag ska konfigurera både SPF, DKIM och DMARC. DMARC-policyn får vara ”none”, men vid direktutskick ska domänen i From-fältet överensstämma med SPF- eller DKIM-domänen; begär därför att uppdraget bedömer både inställningarna och de sändningsvägar du använder, i stället för att bara bocka av att domänposterna finns.

Det vanligaste fyndet i våra granskningar är uppdateringar av PHP, innehållshanteringssystemets kärna och ramverk som inte har installerats. Därför rekommenderar vi att den tekniska uppdragsbeskrivningen omfattar en genomgång av använda versioner, tillägg och beroenden, och att fyndbeskrivningen anger den konkreta komponenten och nödvändiga åtgärden, så att utvecklaren får en genomförbar uppgift snarare än en allmän anmärkning om en föråldrad webbplats. Om din viktigaste fråga gäller vad användarna får göra i systemet räcker inte en versionsgenomgång: då behövs även test av åtkomstkontroll och test av affärslogik. Vi har stött på kritiska fel som gjorde att vilken användare som helst kunde få administratörsbehörighet, och åtgärderna slutade med att systemets kärna skrevs om helt; en versionsgenomgång hade inte hittat ett sådant fel.

Frågan om vad en användare får göra är en annan än frågan om installerade versioner, och var och en behöver egna belägg i rapporten. NIST definierar sårbarhetsskanning som en metod för att identifiera värddatorer, deras egenskaper och tillhörande sårbarheter, medan skanning i vår automatiserade säkerhetskontroll är ett av stegen i det tekniska arbetet. Penetrationstest enligt NIST:s beskrivning kännetecknas av att verkliga angrepp efterliknas för att hitta möjligheter att kringgå skyddet, ofta även genom kombinationer av sårbarheter som ger utökad åtkomst. Valet av själva testet behandlar vi närmare i artikeln om penetrationstest; i beställningen av granskningen är det här viktigt att ange vilka brister utföraren bara ska leta efter och vilka utföraren inom överenskomna gränser ska försöka bevisa att det går att utnyttja i praktiken, samt vilka åtgärder som medvetet lämnas utanför arbetet.

Hur granskningen går till från uppdrag till omtestning

Börja med en skriftlig beskrivning av revisionsomfattningen som anger vilka system, applikationer, adresser och användarroller som ska granskas och tydligt beskriver vad som inte ska kontrolleras i uppdraget, och lägg till syftet och arbetets gränser: vilka åtgärder du tillåter, i vilken miljö de ska utföras, vem som får stoppa kontrollen och vem som ska kontaktas om något oförutsett inträffar; för ett beställningssystem behöver du exempelvis särskilt komma överens om hur åtgärder som annars skulle skapa en riktig beställning ska testas. Även den som ansvarar för ditt systemunderhåll behöver läsa överenskommelsen, så att tillåtna åtgärder, behörigheter och kontaktpersoner är avstämda innan det tekniska arbetet börjar.

Förbered före arbetsstart dokument och personer att intervjua i den utsträckning uppdraget kräver: för den organisatoriska delen policyer, exempel på behörighetstilldelning, dokumentation av återställning från säkerhetskopior och incidenthanteringsplanen, och för den tekniska delen en systembeskrivning och överenskomna behörigheter, med uppgift även om det du ännu saknar. Om en kopia av systemet ska kontrolleras behöver du dokumentera skillnaderna mot systemet som används till vardags och komma överens om hur de ska redovisas i rapporten, så att läsaren senare kan förstå vilken miljö resultaten gäller och vilka frågor som förblivit obesvarade därför att dokument, åtkomst eller den aktuella funktionen inte var tillgängliga. Kom överens om konkreta testtider och kommunikationsrutiner för det tekniska arbetet, och sätt en tidsgräns för när dina kollegor får lämna förtydliganden till dokumentgranskningen, så att det kontrollerade tydligt skiljs från det som ännu inte har bekräftats.

Om utföraren hittar ett väsentligt problem under arbetet bör du begära att det rapporteras enligt den överenskomna rutinen medan resten av arbetet fortsätter, utan att invänta leveransdatumet för den fullständiga rapporten. Kom också överens om vem som beslutar om fortsatt testning på den punkten och hur tillstånd eller begränsningar ska dokumenteras, eftersom de besluten behövs för att förklara hur långt det gick att bekräfta det aktuella fyndet.

Tidsplanen behöver även ge utrymme för åtgärder

En granskning med vårt system tar några dagar, medan själva arbetet med en manuell granskning tar 1–3 veckor beroende på revisionsomfattningen, och det kan tillkomma väntetid före starten eftersom den beror på granskarens beläggning. På tjänstesidan anges ett totalt genomförandeintervall på 1–60 dagar, så behandla inte beskrivningarna som en enda garanterad tidsfrist, utan kom överens om startdatum, rapportleverans och omtestning innan du beställer. Om en kund eller upphandling har satt ett datum behöver du också planera tid för att gå igenom och åtgärda fynden och för ditt teams svar på frågor, eftersom datumet då kontrollen avslutas och datumet då du vill ha åtgärdat bristerna är olika hållpunkter i planeringen.

I vårt erbjudande om manuell expertgranskning ingår omtestning inom 30 dagar efter åtgärderna. För att använda den på ett meningsfullt sätt bör du vid överlämningen av rapporten komma överens om vem som åtgärdar varje fynd, vem som meddelar att arbetet är klart och vilka belägg utföraren ska kontrollera på nytt; precisera själva åtgärdsarbetets omfattning och betalning separat, eftersom granskningspriset inte är en överenskommelse om all efterföljande utveckling. Du kan låta ditt eget team genomföra åtgärderna och sedan låta oss kontrollera dem, eller anlita oss för ett separat arbete som vi uppskattar efter rapporten. Begär att uppföljningsrapporten skiljer en åtgärdad brist från en uppskjuten eller ännu inte omtestad brist och anger vilket systemtillstånd som användes, så att ditt team och rapportmottagaren får ett gemensamt, begripligt svar om varje ursprungligt fynd.

Vad du ska begära i granskningsrapporten

Begär att rapporten börjar med en översikt som ledningen kan förstå över kontrollens syfte, vilka system som omfattas och de viktigaste fynden, så att beslut om arbete och resurser kan fattas utan att allt tekniskt material behöver läsas, och be att arbetets begränsningar anges på samma ställe. Om källkoden inte var tillgänglig eller en viss användarroll inte granskades ska det sägas uttryckligen, så att läsaren slipper gissa vad det korta omdömet om systemets tillstånd betyder; bedöm översikten utifrån om din chef med hjälp av den kan ange nästa beslut, en ansvarig och en fråga som fortfarande saknar svar.

För varje tekniskt fynd bör du begära uppgift om var i systemet det finns, under vilka förhållanden det hittades, vilken användarroll som användes, hur förloppet kan upprepas och vilka belägg som styrker resultatet, medan en organisatorisk avvikelse utöver kravhänvisningen bör ange det dokument eller arbetsexempel som bedömningen bygger på. Åtgärdsrekommendationen ska göra det begripligt exakt vad som behöver ändras, så precisera formuleringen ”ordna behörigheterna” till de konkreta behörigheter och den funktion som din utvecklare behöver ändra, och ange det förväntade beteendet efter åtgärden, så att rapporten kan användas både vid överlämning av uppgiften och vid senare kontroll utan att varje ny läsare behöver tolka granskarens avsikt på nytt.

Om rapporten använder CVSS bör du även begära att versionen anges: FIRST publicerar CVSS, inklusive version 4.0, vars skala för allvarlighetsgrad har beteckningarna ”ingen” (0,0), ”låg” (0,1–3,9), ”medelhög” (4,0–6,9), ”hög” (7,0–8,9) och ”kritisk” (9,0–10,0); det är frivilligt att använda dessa beteckningar i ord. Begär en motivering bredvid poängen och en förklaring av betydelsen för företagets arbete, till exempel vilken aktivitet eller datamängd fyndet berör och varför den föreslagna åtgärdsordningen rekommenderas, så att prioriteringen kan diskuteras utifrån de beskrivna omständigheterna och inte bara siffran.

Vi använder erfarenheten av sådana kritiska fel för att begära en tydlig beskrivning av konsekvenserna, inte för att hävda att varje webbplats behöver byggas om: rapporten ska kunna skilja en konkret rättning från ett problem som kräver att systemets grundläggande funktion ses över. Om rapporten föreslår en omfattande omarbetning bör du begära att få se vilka belägg som stöder rekommendationen, vad som går att åtgärda separat och vilken fråga som förblir olöst om företaget väljer bara en del av det föreslagna arbetet.

Begär skannerns rådatafil som bilaga om det tekniska teamet behöver den, men knyt godkännandet av rapporten till de belägg, prioriteringar och genomförbara åtgärdsrekommendationer som du har begärt i beställningen; välj inte antalet rader som kvalitetsmått. Be utföraren förklara ett fynd från början till slut: hur det upptäcktes, vad resultatet styrker, hur det berör ditt system och hur man efter ändringarna ska kontrollera att det är åtgärdat, och ange allt som fortfarande är ett antagande i slutsatsen; en sådan genomgång ger en konkret grund för att godkänna rapporten och fördela det fortsatta arbetet.

Varför priserna för granskningar skiljer sig så mycket

Priserna skiljer sig främst därför att erbjudandena omfattar olika antal system och olika ingående arbete: automatisk skanning och versionsgenomgång kostar hundratals euro, medan manuella test av åtkomstkontroll och test av affärslogik, säker kodgranskning och omtestning kräver arbetsdagar av en expert. I vår tjänst för säkerhetsgranskning kostar den automatiserade säkerhetskontrollen 89–890 € beroende på omfattningen och är avsedd för WordPress-, Laravel-, Drupal-, Joomla- och Moodle-system. Erbjudandet omfattar automatisk sårbarhetsskanning, kontroll av versioner, tillägg och beroenden, bedömning av konfiguration och serverinställningar samt en rapport med fynd och prioriteringar; använd det innehållet när du jämför priset med ett annat erbjudande, och precisera vilka av dina installationer som ska granskas. Se intervallets lägsta belopp i relation till den överenskomna omfattningen, så att du inte överför priset för kontroll av en webbplats till företagets samtliga system, vars gränser utföraren ännu inte har bedömt.

Vår manuella expertgranskning finns från 3 500 € och omfattar manuell kontroll enligt OWASP Top 10, test av åtkomstkontroll och test av affärslogik för att försöka kringgå reglerna, säker kodgranskning och ett tillåtet penetrationstest. Säker kodgranskning erbjuds för Laravel, WordPress och specialutvecklade lösningar, och i rapporten ordnar vi fynden efter faktisk risk och ger varje fynd en åtgärdsrekommendation; erbjudandet omfattar även omtestning efter åtgärderna. Orden ”från” gäller även om ditt system bara har en publik adress, eftersom funktioner, roller och koden som ska granskas fortfarande behöver avtalas för prisberäkningen.

En fullständig kontroll med vårt system kostar vanligen 500–800 €. Det är det belopp vi oftast ser inom prisintervallet för den automatiserade säkerhetskontrollen, inte ett separat pris för en gemensam bedömning av företagets styrning, samtliga system och certifiering, så knyt ordet ”fullständig” till den konkreta tekniska omfattning som vi har kommit överens om. För de flesta webbplatser rekommenderar vi regelbunden automatiserad säkerhetskontroll som kan upprepas ofta, och manuell expertgranskning när systemet hanterar betalningar eller personuppgifter eller är verksamhetskritiskt, eftersom fel i behörigheter och möjligheter att kringgå affärslogiken bara hittas av en människa; i praktiken fungerar regelbunden automatiserad säkerhetskontroll och manuell granskning en gång om året bra tillsammans.

Den skillnaden hjälper även i budgetdiskussionen: om du behöver svar om webbplatsens komponenter och inställningar bör du begära en beräkning för det uppdraget, medan du bör inkludera motsvarande manuella tester och låta utföraren bedöma arbetet separat om huvudfrågan gäller kringgående av användarbehörigheter eller affärsregler.

Ta fram en likadan beskrivning av system, applikationer, användarroller och, om även den organisatoriska delen behövs, företagets verksamhetsställen för jämförelsen, och be sedan att automatiska och manuella aktiviteter anges separat. Föreställ dig en prisberäkning enbart för den publika webbplatsen och en annan för samma webbplats tillsammans med kundportal, administration och källkod: klargör gränserna för varje erbjudande innan du jämför beloppen. Dokumentera även nödvändiga behörigheter, valda efterlevnadskriterier och rapportmottagare för varje del, eftersom det ger utföraren ett konkret beräkningsunderlag och dig möjlighet att upptäcka en utelämnad uppgift.

Klargör separat om priset omfattar att förklara fynden för din utvecklare, koppla dem till kraven i den valda standarden och genomföra omtestning, samt var granskningsarbetet slutar och utvecklingen av rättningarna börjar, och vi rekommenderar att granskningsbudgeten även tar ställning till åtgärdandet av de konstaterade bristerna. Om priserna fortfarande skiljer sig betydligt mellan erbjudanden med samma omfattning bör du be utförarna förklara arbetet och dess gränser genom en konkret funktion, exempelvis ändring av en användares behörigheter, i stället för med fler tjänstenamn; då kan du välja utifrån ett konkret resultat och ansvar utan att förlita dig på ett löfte om heltäckande säkerhet.

När företaget behöver en säkerhetsgranskning

Vi rekommenderar att du beställer en granskning när företaget behöver fatta ett konkret säkerhetsbeslut eller lämna ett verifierbart intyg, och att du redan från början anger om beslutet gäller styrningen, det tekniska tillståndet eller båda. Om anledningen är NIS2 bör du först klargöra din status och de tillämpliga kraven, även med hjälp av vår artikel om NIS2 och vilka som omfattas, och därefter formulera uppdraget. Här är ordningen viktig: klargör om kravet är tillämpligt och vilket intyg som behövs innan du väljer tjänst, så att beställningen av en teknisk rapport inte blir ditt enda svar på en fråga där även företagets ansvar och processer behöver bedömas. Om webbplatsen saknar användarkonton, betalningar och behandling av personuppgifter och ingen kräver ett intyg behövs vanligen ingen omfattande granskning: installera först uppdateringarna, och det räcker med en automatiserad säkerhetskontroll.

Om en försäkringsgivare eller kund begär kontrollen bör du be om ett förtydligande av det förväntade resultatet och ge utföraren själva kravtexten; skilj exempelvis frågan om medarbetarutbildning eller test av återställning från en säkerhetskopia från kravet på att kontrollera applikationens behörigheter, och förbered relevanta belägg för svaren. Om ett leverantörsformulär kräver att du intygar en bredare säkerhetsprocess än din tekniska granskning omfattar bör du komma överens med kunden om kompletterande information och utse någon på företaget som samlar in den, i stället för att ge den tekniska rapporten en vidare innebörd; klargör samtidigt om mottagaren förväntar sig själva rapporten, svar på konkreta frågor eller någon annan form av intyg och vilken tidsfrist som gäller.

Vid en upphandling ska du behålla den begärda kontrolltypen och utförarens kvalifikationskrav exakt som beställaren har formulerat dem och reda ut oklarheter innan du begär pris, så att erbjudandet inte behöver skrivas om efter arbetsstart. Vi behandlar valet närmare i artikeln om säkerhetskontrollen som upphandlingen kräver, och för att ta fram en teknisk uppdragsbeskrivning kan du skicka kravets formulering och en systembeskrivning till oss. Ange även sista inlämningsdatum, tillgänglig dokumentation och vem på din sida som ska genomföra åtgärderna, eftersom samtalet om genomförandet behöver omfatta både rapportframtagningen och ditt teams möjlighet att arbeta med resultaten före det nödvändiga datumet.

Efter en incident och mellan planerade kontroller

Efter en incident rekommenderar vi att granskningens uppdrag styrs av den konkreta obesvarade frågan: om rättningen löser det konstaterade problemet, om ett liknande behörighetsfel behöver sökas i en annan funktion och hur företaget framöver ska kontrollera att den aktuella rutinen följs. Ge utföraren en beskrivning av det kända händelseförloppet och skilj bekräftade fakta från antaganden. Om du vill utreda händelseförloppet behöver även det arbetet anges separat och resultatet avtalas, utan att du förutsätter att en allmän webbplatsgranskning automatiskt besvarar alla frågor om incidenten; behåll samtidigt kopplingen mellan rättningarna som ska kontrolleras och de ursprungliga fynden, så att du efter ändringarna kan säga exakt vilket problem du testade igen och hur.

Våra kunder beställer vanligen en granskning en eller två gånger om året; det är en observation från vår erfarenhet, inte ett fastställt intervall för alla företag. Vi rekommenderar att du i planen, bredvid nästa datum, även anger de ändringar som ska utlösa en ny bedömning av kontrollens omfattning, exempelvis en ny användarroll, en omskriven behörighetsfunktion eller ett leverantörsbyte där leverantören har behörigheter i systemet. Ge den ansvariga personen i uppgift att jämföra ändringarna med den föregående granskningens revisionsomfattning och föreslå den konkreta del som ska kontrolleras, och behåll de olösta fynden från den föregående rapporten i nästa uppdragsbeskrivning tillsammans med besluten om att skjuta upp dem, så att den nya kontrollen börjar utifrån den kända situationen.