SOC 2 · ISO 27001

Täcker en godkänd SOC 2- eller ISO 27001-certifiering licensredovisning?

Nej. Säkerhetscertifieringar och redovisning av tredjepartslicenser besvarar olika frågor, och båda kan gälla samtidigt: Du kan ha ett giltigt certifikat och ändå vara skyldig en granskad licensredovisning på produktnivå.

Senast uppdaterad: 2 juli 2026

01Vad den här sidan pekar på

De förbisedda felpunkterna

De här dyker upp i diligence och revisioner: Skyldigheter finns, bevis saknas, och artefakten köpare förväntar sig är frånvarande.

Open source-licenser är juridiska skyldigheter, inte önskemål
MIT, Apache, GPL, LGPL och proprietära SDK-avtal ålägger villkor: Meddelande, attribuering, copyleft, distributionsregler. Att missa dem är ett licensbrott, inte en stilistisk brist. SOC 2- och ISO-program får inte de skyldigheterna att försvinna. De frågar om dina kontroller fångar upp dem innan leverans.
ISO 27001: Immaterialrätt är uttryckligt
Bilaga A 5.32 kräver rutiner för att uppfylla immateriella rättigheter, inklusive mjukvarulicenser. Revisorer förväntar sig bevis, inte enbart en policy-PDF. Att inte inkludera obligatoriska licenstexter där licenserna kräver det är både ett IP-brott och ett bevismisslyckande för ISMS:et, när dina kontroller påstår att tredjepartsmjukvara hanteras.
SOC 2: Ingen kontroll för licenssidan, men revisorer följer trådar
Trust Services Criteria nämner inte “publicera alla licenser på en webbplats”. Revisorer spårar ändå juridisk efterlevnad och ändringshantering. Systematiska luckor (saknade meddelanden, ogranskad förteckning, ingen redovisning på produktnivå) framträder som kontrollbrister när stickprov inte matchar policyn.
Certifieringens omfång är inte produktens omfång
Ett SOC 2 Type II- eller ISO-certifikat täcker ditt system och din period, inte automatiskt varje beroende i varje SKU. Köpare ställer ändå produktspecifika frågor. Din certifiering hjälper, men ersätter inte redovisning av tredjepartslicenser för produkten i avtalet.
Bevispaket blir inaktuella mellan revisioner
Team lämnar in samma OSS-kalkylblad till ISO:s uppföljningsrevision som de lämnade förra året, medan utvecklingsteamet levererat tolv releaser. Uppföljningsrevisorer tar stickprov i skarpa system. Bristande överensstämmelse mellan bevis och produktion är en klassisk allvarlig avvikelse, och samma brist stjälper förnyelser av inköpsavtal.
Säkerhetsskanning är inte licensgranskning
Sårbarhetsskannrar och SBOM-verktyg identifierar komponenter och ibland licensfält. De bifogar inte fullständig licenstext, godkänner inte copyleft-risk, och publicerar inte köparklar redovisning. Att likställa utdata från AppSec-verktyg med licensefterlevnad skapar falsk trygghet i både SOC-bevis och RFP-svar.
Copyleft-överraskningar drabbar certifierade organisationer också
GPL eller AGPL i en levererad produkt utan källkodserbjudande eller efterlevnadsgranskning är ett juridiskt och revisionsmässigt problem oavsett ISO 27001-certifiering. Att det upptäcks under köparens diligence, inte vid intern granskning, är den dyra vägen.
Köpare vill ha bevis vid sidan av din rapport
Enterprise-kunder begär din SOC-rapport och en tredjepartslicensredovisning för produkten: Förteckning, fullständig text, underhållsprocess. Trustcentret täcker säkerhetsstatus. Licensredovisningen täcker IP-skyldigheter i kodbasen. Båda förekommer i mogna leverantörsgranskningar.

SOC 2 och ISO 27001 bevisar att du driver ett säkerhets- och ledningssystem: Åtkomstkontroll, ändringshantering, riskbehandling, leverantörsuppsikt. Revisorer granskar kontrollernas utformning och operativa effektivitet. Ingen av certifieringarna förtecknar som standard varje open source-licensskyldighet i varje levererad produkt.

Köpare betraktar certifiering som en grundförutsättning, och ber sedan separat om redovisning av tredjepartslicenser (fullständig text, attribuering, produktavgränsad förteckning). Att klara SOC 2 besvarar inte “vilka GPL-komponenter finns i bygget vi licensierat”.

Vad kräver ISO 27001 egentligen kring open source-licenser?

ISO/IEC 27001:2022 kräver att du tillämpar rutiner som säkerställer efterlevnad av immateriella rättigheter, inklusive villkor i mjukvarulicenser, enligt bilaga A punkt 5.32. Standarden föreskriver ingen offentlig licenssida, men en revisor kan begära bevis på att villkoren i tredjepartslicenserna i det du levererar faktiskt uppfylls.

Ett kontrolldokument som säger “vi respekterar OSS-licenser” utan bevis (granskad förteckning, fullständig text, koppling till release) är en avvikelse som väntar på att hända. Särskilt när stickprov hittar paket i produktion som inte finns på någon lista.

Policy för godtagbara licenser och godkännandeprocesser.
Bevis på att levererade produkter uppfyller villkoren i tredjepartslicenser.
Dokumenterad granskning, inte bara utdata från en upptäcktsskanning.
Överensstämmelse mellan det ISMS:et påstår och det utvecklingsteamet levererar.
Hantering av licensändringar när beroenden uppdateras.

Vad letar SOC 2-revisorer efter kring licensefterlevnad i praktiken?

SOC 2-revisorer kräver ingen offentlig licenssida. De spårar om dina kontroller enligt AICPA Trust Services Criteria för juridisk efterlevnad, leverantörshantering och ändringskontroll faktiskt fångar upp tredjepartslicensskyldigheter. Slarvig OSS-hygien syns där som svagt bevis mot kriterier du redan påstår att du tillämpar.

Revisorer tar stickprov i system. De frågar hur du vet att tredjepartsmjukvara är korrekt licensierad. “Vi kör npm audit” är inget svar. Det är inte heller en certifieringsbadge på din webbplats utan en förteckning på produktnivå.

Kontroll	Vad revisorer förväntar sig	Bevis som uppfyller den
ISO 27001 A 5.32	Rutiner som säkerställer efterlevnad av immaterialrätt och mjukvarulicenser	Granskad förteckning med fullständig licenstext per levererad produkt
SOC 2 CC2.2	Styrning och uppsikt över efterlevnadsskyldigheter	Granskningsloggar som visar vem som godkände vilka komponenter, och när
SOC 2 CC8.1	Beroendeändringar går genom ändringshantering	Avvikelseregister som kopplar ändringar i lockfiles till förnyad granskning
SOC 2 CC9.2	Risker kring tredjeparts- och leverantörsmjukvara hanteras	Produktavgränsad redovisning, aktuell per releasen

Avvikelser uppstår när en policy finns men operativt bevis saknas.

Varför certifieringar och köpares diligence skiljer sig åt

Certifieringens omfång är kontrollmiljön: Ofta ett trustcenter, en period, en systemgräns. Köparens diligence-omfång är den produkt de köper (det här SKU:t, den här releasen, de här skyldigheterna idag).

Din SOC 2-rapport täcker hur du hanterar förändring. Deras juridikavdelning ber om MIT-licenstexten för libfoo 2.4.1 i installationsprogrammet de driftsätter. Olika frågor, båda behöver ärliga svar.

Varför blir förteckningen inaktuell i certifierade organisationer?

Förteckningen blir inaktuell eftersom certifiering sker periodiskt medan beroenden ändras kontinuerligt. Rapporten Black Duck Open Source Security and Risk Analysis fann open source-kod i 96 procent av de granskade kodbaserna, och att de flesta innehöll komponenter med licenskonflikter eller ingen identifierbar licens, så ett enda årligt bevispaket kan inte följa vad varje release faktiskt levererar.

Certifierade företag mergar beroendeuppdateringar mellan revisionscykler. Utvecklare lägger till paket utan att uppdatera kalkylbladet från förra årets ISO-bevispaket. Certifikatet är giltigt. Förteckningen är inaktuell.

Operativ licensefterlevnad innebär ny import vid release, ny granskning, ny publicering. Samma underhållsloop som CRA och inköp kräver, inuti ett ISMS som redan påstår att du hanterar tredjepartsrisk.

Bevis som både revisorer och köpare accepterar

Granskad tredjepartsförteckning kopplad till releasetaggar. Fullständig licenstext lagrad tillsammans med varje godkänd komponent. Publicerad eller exporterad ögonblicksbild med datum och godkännare. Avvikelsedetektering när lockfiles ändras. Offentlig eller kundvänd redovisning när avtal kräver det.

Formatet varierar (URL, PDF-export, JSON-paket). Beviset är den granskade redovisningen och processen, inte filtypen.

Importera från lockfiles eller SBOM:er per release.
Mänsklig granskning innan godkännande, särskilt för copyleft.
Granskningsspår: Vem som godkände vad, och när.
Exporter bifogade till ISO-bevis eller SOC-revisorers förfrågningar.
Körs om vid beroendeändringar, inte bara årligen.

Vanliga felmönster i revisioner och affärer

Policy utan förteckning. Förteckning utan fullständig licenstext. Fullständig text insamlad en gång och aldrig uppdaterad. Säkerhetsskanning som förväxlas med licensgranskning. Trustcenter som nämner integritet och säkerhet men är tyst om OSS. GPL i produktion upptäckt av köparens skanning, inte din egen.

Varje mönster skapar ISO-avvikelser, SOC-undantag eller försenade affärer. Lösningen är operativ infrastruktur för licensskyldigheter, parallellt med (inte ersatt av) certifieringsprogram.

Hur team kopplar kontroller till licensarbete

Koppla kontroll 5.32 och SOC:s kriterier för ändringshantering till konkreta steg: Importera, granska, publicera, kontrollera avvikelser. Namnge ägare inom utveckling och efterlevnad. Bifoga redovisningsexporter till ISMS:ets bevismappar. Stickprovsgranska produkter internt på samma sätt som externa revisorer kommer göra.

Certifiering bevisar processmognad. Licensredovisningar på produktnivå bevisar att du uppfyller skyldigheterna i mjukvaran du säljer. Bevis som köpare och ISO:s stickprov i allt högre grad förväntar sig tillsammans.

Källor

Så stöttar SourceTrust certifieringsstött bevis

Certifieringar bevisar att du har ett ledningssystem. Licensredovisningar på produktnivå bevisar vad som levererades: Granskat, med fullständig text, uppdaterat när beroenden ändras.

SourceTrust importerar paketfiler och SBOM:er, kräver granskning innan publicering, och tar fram en underhållen redovisning per produkt plus exporter för ISO:s bevismappar och köparformulär. Avvikelsekontroller håller licensredovisningarna i linje med samma beroendeändringar dina kontroller för ändringshantering redan följer upp för SOC 2.

Se hur plattformen fungerar

Importera från repon, manifest och SBOM:er. Varje rad är en licens att uppfylla
Gransknings- och publiceringsgrindar. Bevis revisorer kan stickprovsjämföra mot produktion
Redovisning per produkt. Det köpare efterfrågar utöver SOC-rapporten
Avvikelsevarningar när beroenden eller licenser ändras mellan revisionscykler

SourceTrust är infrastruktur för efterlevnad, inte juridisk rådgivning och ingen ersättning för din ISO- eller SOC-revisionsfirma. Det hjälper dig omsätta licensskyldigheter i praktiken. Din jurist och dina revisorer förblir de som avgör hur dina kontroller ska utformas.