Frågor vi faktiskt får.

En skanner läser ett versionsnummer och talar om vad som kan vara fel. Den lämnar över en lista med hypoteser och låter er sköta triagen — vilket är dit ungefär 40 % av de flesta teams säkerhetstid går, innan någon har åtgärdat något alls.

Vi gör triagen. En agent provar varje kandidat, säkert, och en människa sätter sitt namn på utlåtandet. Ungefär 91 % av alla råa fynd når er aldrig, eftersom de inte var verkliga. Det som når fram kommer med anropet, svaret och en skärmbild, så att diskussionen med utvecklarna tar tio sekunder i stället för en sprint.

Den andra halvan av skillnaden är omfattning. En skanner kontrollerar listan ni gav den. Vi går och tar fram listan — certifikattransparens, DNS, molnadressblock, kodvärdar, den där lagringsbucketen någon glömde 2021 — och kontrollerar om var sjätte timme. En CVSS 9.8 som ingen kan nå är ett rykte. En öppen adminpanel på en subdomän ni hade glömt bort är en tisdag.

Nej, och vi vill helst inte att ni köper det som ett sådant.

Ett penetrationstest är avgränsat, tidsbegränsat och utfört av namngivna människor, vanligtvis en gång om året, och det slutar i en signerad rapport. Vi kör löpande, över allt ni exponerar, och berättar vad som är sant den här veckan. Olika uppdrag. Om någon säljer er det ena som det andra: fråga vilken vecka deras rapport täcker.

Ni kan ändå få ett genom oss. Ett penetrationstest kan läggas till vilken prenumeration som helst och köras enligt schema. Eftersom vi redan har kartlagt er yta bygger omfattningen i upphandlingsunderlaget på vad ni faktiskt har, inte på vad någon minns att ni har. Vi skriver underlaget, skickar ut det till flera leverantörer samtidigt och hjälper er jämföra svaren på lika villkor. Deras fynd landar sedan på samma ställe som våra — verifierade, spårade och omtestade vid deploy — i stället för i en PDF i en mapp som ingen öppnar förrän revisorn frågar.

Vi utför inte testet själva, så vi har ingen anledning att vilja att det hittar mycket eller lite.

Nej. MDR- och SOC-tjänster bevakar era enheter och era loggar efter någon som redan är inne. Vi bevakar det ni exponerar utåt och bevisar vad någon skulle kunna nå innan de tar sig dit. De två överlappar knappt: ert MDR-avtal utesluter nästan säkert er egen produkt, som är den största attackytan ni äger och den enda ni styr fullt ut.

Vi arbetar kontorstid, med flit. Behöver ni någon vaken klockan tre på natten behöver ni även en MDR — och vi sitter uppströms om den, och lämnar färre vägar in för dem att bevaka.

Det betyder ett snävt uppdrag och en hård regel: bevisa det utan att ha sönder något. En agent tar ett kandidatfynd, försöker bekräfta det med läsbara metoder och registrerar anropet, svaret och en skärmbild. Destruktiva klasser är avstängda som standard och förblir det tills ni skriver under på något särskilt.

Ingenting når er på en agents ord allena. En människa läser bevisen och signerar utlåtandet — vilket också är varför det finns ett namn att ge revisorn när hen frågar vem som granskade det.

Inte för att börja. Den kostnadsfria genomgången av angreppsytan kräver ingenting från er — kan vi nå det från internet, så kan vi det, och det är just poängen med övningen.

När ni är på en plan behöver ändringsgranskningen läsbehörighet till era repon och er CI. Inga agenter, inga ändringar i pipelinen, ungefär en arbetsdag av ert teams tid.

Ni får veta det på lördagen. Agenterna kör hela veckan; människor verifierar på kontorstid. När en agent bekräftar något kritiskt utanför kontorstid går larmet och bevisen till er omedelbart, märkta som agentbekräftade och ännu inte granskade, så att ni kan agera utan att vänta på oss. Det skriftliga utlåtandet och åtgärdsrådet kommer nästa arbetsdag.

Vi är ingen 24/7-tjänst och påstår inte att vi är det. Var skeptisk mot alla i vår storlek som gör det.

Ni får gärna försöka. Vi säger nej, skriftligen.

Behörigheten är en del av uppstarten, inte en efterhandsformalitet. Ni skriver under ett standardavtal som listar vad som ingår — domäner, repon, miljöer — och bekräftar att ni har rätt att låta det testas. Ingenting utanför den omfattningen rörs, och att utöka den är en signerad ändring, inte ett supportärende. För den kostnadsfria genomgången verifierar vi dessutom ägarskap med en DNS-post innan något körs.

Leverantörssystem testas under era avtalsrättigheter gentemot den leverantören, med leverantören informerad. Aldrig i tysthet.

Det är till stor del därför folk köper det. ISO 27001-revisorer stickprovar numera enskilda ändringar (A.8.29, A.8.32) i stället för att godta ett policydokument, och bevisen finns antingen den dag de frågar eller inte. DORA och NIS2 trycker ner samma fråga från era reglerade kunder, i form av leverantörsenkäter ni måste besvara.

Det vi producerar är daterade bevis per ändring och per release — vad som ändrades, vad som granskades, av vem, vad som kördes, vad som omtestades. Det är vad de frågorna faktiskt ber om. Vi reviderar själva finansiella institut under DORA och NIS2, så bevismodellen är byggd från den frågande sidan av bordet.

Ja. Det är vad de är till för. Ur samma underlag kommer två rapporter: en ledningsrapport — exponering, trend, vad som passerat sin SLA och vems namn som står på det — och en teknisk rapport med fynden, stegen för att återskapa dem och omtestresultaten. Båda finns i sin helhet på plattformssidan.

På de högre planerna signerar vi dessutom ett årligt intyg, för kunden som frågar hårdare än en enkät.

En sak ni levererar, plus ytan som betjänar den: dess repon, dess domäner och subdomäner, dess miljöer. En SaaS-applikation med en marknadssajt och en testmiljö är en produkt. Två applikationer som råkar dela inloggning är två.

Planerna mäts i produkter eftersom det är enheten er exponering faktiskt växer i — aldrig per utvecklare, per enhet eller per fynd vi rapporterar.