Trust Services Criteria och hur testet mappar mot dem

Många organisationer tänker på penetrationstest som en ren säkerhetsövning. Det är för snävt. Ett välplanerat test genererar bevis som stödjer flera av SOC 2:s fem kriterier.

Poängen: definiera testets scope utifrån vilka kriterier ni valt, inte bara "testa webbappen".

Tidplan: när och hur ofta

Timing är den mest underskattade faktorn. Vi ser regelbundet organisationer som beställer penetrationstest en vecka före revisionsperiodens slut. Resultatet? Kritiska fynd som inte hinner åtgärdas, och revisorn dokumenterar dem som brister.

Rekommenderad tidslinje

1. Vecka 1–2 (10 veckor före revisionsslut): Scopedefinition och leverantörsval. Säkerställ att testleverantören förstår SOC 2-kontexten.

2. Vecka 3–5: Genomförande av testet. Räkna med 2–3 veckor för en medelstor miljö (webbapp + API + molninfrastruktur).

3. Vecka 5–6: Rapportleverans och genomgång med ert säkerhetsteam.

4. Vecka 6–9: Åtgärda kritiska och höga fynd. Dokumentera varje åtgärd med tidstämpel — revisorn vill se detta.

5. Vecka 10: Verifieringstest (retest) av åtgärdade fynd. Denna rapport blir ett starkt bevis för revisorn.

Har ni en managerad SOC/NOC-tjänst som löpande övervakar er miljö kan steg 4 ofta komprimeras — åtgärder rullas ut snabbare när driftteamet redan känner miljön.

Scope: vad ska testas?

Ett för brett scope ger ytliga resultat. Ett för smalt scope missar kritiska angreppsvektorer. Vi rekommenderar att utgå från er riskbedömning (som ni redan bör ha inom SOC 2-arbetet) och prioritera enligt attackyta och affärspåverkan.

Typiskt scope för en SaaS-organisation

• Extern infrastruktur: publikt exponerade IP-adresser, DNS-konfiguration, TLS/SSL-implementering
• Webbapplikation och API:er: OWASP Top 10, autentiseringsflöden, sessionshantering, BOLA/IDOR-sårbarheter
• Molnkonfiguration: IAM-policyer i AWS/Azure/GCP, nätverkssegmentering, lagringsrättigheter (S3, Blob Storage), logging-konfiguration
• Intern nätverkssegmentering: lateral rörelse mellan VPC:er/VNets, mikrosegmentering
• Social engineering (valfritt men värdefullt): phishing-simulering mot personal med administratörsrättigheter

I AWS-miljöer utgår vi ofta från eu-north-1 (Stockholm) och testar specifikt hur IAM-roller, Security Groups och VPC-peering är konfigurerade. I Azure Sweden Central granskar vi NSG-regler, Private Link-konfiguration och Entra ID Conditional Access-policyer.

Välja testleverantör: vad ni ska kräva

Marknaden har inget brist på pentestföretag, men kvalitetsskillnaderna är enorma. Här är vad vi ser skilja bra leverantörer från mediokra:

Certifieringar som faktiskt betyder något

• OSCP (Offensive Security Certified Professional) — praktiskt orienterad, visar att testaren kan exploatera, inte bara skanna
• CREST-certifiering — internationellt erkänd standard för pentestföretag
• GPEN/GWAPT (GIAC) — solida certifieringar med fokus på nätverks- respektive webbtestning

Undvik leverantörer som bara kör automatiserade verktyg (Nessus, Qualys) och kallar det penetrationstest. Det är sårbarhetsskanning — en helt annan sak.

Krav på rapportformat

Revisorn behöver specifik information. Säkerställ att leverantören levererar:

• Executive summary med riskkategorisering (kritisk/hög/medel/låg)
• Teknisk detaljrapport med steg-för-steg-beskrivning av varje fynd
• Mappning mot SOC 2 Trust Services Criteria (detta missar de flesta standardrapporter)
• Åtgärdsrekommendationer prioriterade efter affärsrisk
• Verifieringsrapport efter retest

Oberoende från revisorn

En grundregel: CPA-firman som utför er SOC 2-revision får inte genomföra penetrationstestet. Det bryter mot revisorns oberoendekrav. Välj en separat leverantör och koordinera rapportformaten i förväg.

Vanliga fynd: vad vårt SOC ser gång på gång

Baserat på Opsios erfarenhet från kundmiljöer i drift ser vi återkommande mönster i penetrationstestresultat som är direkt relevanta för SOC 2:

1. Överprivilegierade IAM-roller

Det vanligaste fyndet i molnmiljöer. Utvecklare har produktionsåtkomst de inte behöver, service accounts har wildcardpolicyer. Detta underminerar kontroller under CC6.1 (Logical Access Controls).

2. Bristande nätverkssegmentering

Staging- och produktionsmiljöer kan nå varandra fritt. En angripare som komprometterar en testserver får lateral åtkomst till produktionsdata. Relevant för CC6.6 (System Boundaries).

3. Saknad eller bristfällig loggning

System loggar, men loggarna skickas inte till en central SIEM, eller retentionen är för kort. Revisorn granskar detta under CC7.2 (Monitoring Activities). Utan bevis på att ni upptäcker anomalier fallerar hela detektionskedjan.

4. Felkonfigurerade molnlagringstjänster

S3-buckets med publika ACL:er, Azure Blob-containrar utan Private Endpoint. Klassiskt, fortfarande vanligt, direkt relevant för C1 (konfidentialitet).

5. Svaga autentiseringsflöden

Avsaknad av MFA på administrativa konton, svag lösenordspolicy, tokens med för lång livstid. Grundläggande men kritiskt under CC6.1.

Har ni en managerad molnsäkerhetstjänst på plats fångas många av dessa brister löpande — men penetrationstestet verifierar att skydden verkligen håller.

Från fynd till åtgärd: så maximerar ni testets värde

Ett penetrationstest som resulterar i en PDF på en delad mapp är bortkastade pengar. Så här integrerar ni resultaten i SOC 2-arbetet:

Steg 1: Triage inom 48 timmar

Samla säkerhetsteam, driftteam och en representant från ledningen. Kategorisera varje fynd efter:

• Allvarlighetsgrad (kritisk/hög/medel/låg)
• Exploaterbarhet (kräver det intern åtkomst eller kan det nås utifrån?)
• Berörd SOC 2-kontroll (mappa till specifikt CC-nummer)

Steg 2: Åtgärdsplan med ägare och deadline

Varje fynd får en namngiven ägare och en realistisk deadline. Kritiska fynd bör åtgärdas inom 72 timmar, höga inom 2 veckor. Dokumentera allt i ert ärendehanteringssystem — revisorn vill se spårbarheten.

Steg 3: Implementera och verifiera

Rulla ut åtgärder via er befintliga DevOps-pipeline — inte manuella ändringar i produktionen. Använd Infrastructure as Code (Terraform, Pulumi) för att säkerställa att åtgärder är reproducerbara och versionshanterade.

Steg 4: Retest

Låt pentestleverantören verifiera att åtgärderna faktiskt stänger sårbarheterna. Denna verifieringsrapport är guld värd i revisionen.

Steg 5: Uppdatera riskregistret

Justera riskvärden baserat på testresultaten. Nya fynd kan indikera risker ni inte identifierat tidigare. Riskregistret är ett levande dokument som revisorn granskar.

SOC 2 + NIS2: dubbel hävstång för svenska organisationer

Sedan NIS2-direktivet trädde i kraft har svenska organisationer inom kritisk infrastruktur och deras leverantörskedjor nya krav på sig. Det intressanta: NIS2:s krav på riskhantering, incidentrapportering och tekniska skyddsåtgärder överlappar i hög grad med SOC 2:s Trust Services Criteria.

Ett penetrationstest som genomförs med SOC 2 i åtanke kan, med rätt scopedefinition, samtidigt ge bevis som stödjer NIS2-efterlevnad. Specifikt:

• NIS2 Artikel 21.2(e) — säkerhet vid förvärv, utveckling och underhåll → mappar mot CC8 (Change Management)
• NIS2 Artikel 21.2(g) — bedömning av cybersäkerhetsriskers effektivitet → mappar mot CC4 (Monitoring) och CC7
• NIS2 Artikel 21.2(d) — leveranskedjans säkerhet → pentestet kan inkludera tredjepartsintegrationer

Organisationer som hanterar persondata under GDPR och övervakas av Integritetsskyddsmyndigheten (IMY) har ytterligare incitament: penetrationstest stärker argumentet för att ni vidtagit "lämpliga tekniska åtgärder" enligt Artikel 32.

Automatisering och löpande testning: bortom det årliga pentestet

Ett penetrationstest per år är miniminivån. Organisationer med snabba releasecykler bör komplettera med:

• Löpande sårbarhetsskanning (veckovis eller efter varje deploy) integrerad i CI/CD-pipelinen
• DAST (Dynamic Application Security Testing) som del av staging-validering
• Bug bounty-program för kontinuerlig extern testning
• Red team-övningar var 18–24 månader för att testa hela detektions- och responskedjan

Flexeras State of the Cloud har konsekvent visat att säkerhet är bland de högst prioriterade molnutmaningarna för organisationer av alla storlekar. Automatiserad testning adresserar detta genom att flytta säkerhetsvalidering från en årlig händelse till en löpande process.

Med en FinOps-strategi på plats kan ni dessutom mäta säkerhetsinvesteringarnas ROI — vad kostar testningen jämfört med vad en incident hade kostat?

Checklista: penetrationstest inför SOC 2-revision

Att göra det praktiskt: Opsios perspektiv

Vi driver SOC/NOC dygnet runt och ser dagligen vad som händer i kundmiljöer. Det ger oss ett perspektiv som renodlade konsultfirmor saknar: vi vet inte bara vilka sårbarheter som finns, utan vilka som faktiskt exploateras i produktion. Den insikten gör att vi kan hjälpa er prioritera rätt — inte bara åtgärda allt som står i pentestraporten, utan fokusera på det som faktiskt utgör risk i er specifika kontext.

Vill ni diskutera hur penetrationstest passar in i ert SOC 2-arbete, eller hur ni kan kombinera det med NIS2-krav? Vi hjälper er gärna med scopedefinition, leverantörsval och integration av resultat i er molnsäkerhetsstrategi.

Vanliga frågor

Är penetrationstest ett krav för SOC 2?

Formellt kräver AICPA inte penetrationstest i sina Trust Services Criteria. I praktiken förväntar sig de flesta revisorer det som stödjande bevis för kontroller inom CC7 (övervakning) och CC8 (ändringshantering). Utan test riskerar du kvalificerade undantag eller att revisorn begär kompletterande bevis som tar längre tid.

Hur ofta bör vi penetrationstesta för SOC 2?

Minst en gång per revisionsperiod, alltså årligen. Har ni frekventa releaser eller hanterar högriskdata (finans, hälsa) rekommenderar vi halvårsvis testning kombinerad med löpande sårbarhetsskanning.

Vad kostar ett penetrationstest riktat mot SOC 2?

Kostnaden varierar kraftigt beroende på scope. En webbapplikation med API:er kan ligga på 80 000–200 000 SEK. Ett bredare test som inkluderar molninfrastruktur, intern nätverkssegmentering och social engineering landar ofta på 200 000–500 000 SEK. Begär alltid fast pris med definierat scope.

Kan vi använda automatiserade sårbarhetsskanningar istället?

Nej, inte som ersättning. Automatiserade skanningar hittar kända sårbarheter men missar logiska brister, felkonfigurerade IAM-policyer och kedjeangrepp. Revisorer gör tydlig skillnad mellan skanning och penetrationstest. Använd skanning löpande och pentest som fördjupad kontroll.

Ska vi välja samma leverantör för SOC 2-revision och penetrationstest?

Nej. CPA-firman som utför er SOC 2-revision får inte genomföra testet — det bryter mot revisorns oberoendekrav. Välj en separat leverantör och koordinera rapportformaten i förväg.

For hands-on delivery in India, see managed disaster recovery.

For hands-on delivery in India, see managed gcp managed.