SOC 2 · ISO 27001

Dekker det å bestå SOC 2 eller ISO 27001 lisensoffentliggjøring?

Nei. Sikkerhetssertifiseringer og offentliggjøring av tredjepartslisenser svarer på ulike spørsmål, og begge kan være sanne samtidig: Du kan ha et gyldig sertifikat og likevel skylde en gjennomgått lisensoversikt på produktnivå.

Sist oppdatert: 2. juli 2026

01Hva denne siden peker på

De oversette svake punktene

Disse dukker opp i due diligence og revisjoner: Forpliktelsene finnes, dokumentasjonen mangler, og artefakten kjøpere forventer, er fraværende.

Open source-lisenser er juridiske forpliktelser, ikke preferanser
MIT, Apache, GPL, LGPL og proprietære SDK-avtaler pålegger betingelser: Notice, navngivelse, copyleft, distribusjonsregler. Å mangle dem er lisensbrudd, ikke et stilistisk hull. SOC 2- og ISO-programmer får ikke disse forpliktelsene til å forsvinne; de spør om kontrollene deres fanger dem opp før levering.
ISO 27001: Immaterielle rettigheter er eksplisitt
Annex A 5.32 krever rutiner for å overholde immaterielle rettigheter, inkludert programvarelisenser. Revisorer forventer dokumentasjon, ikke bare en PDF med retningslinjer. Å ikke inkludere påkrevd lisenstekst der lisensene krever det, er både et brudd på immaterielle rettigheter og en svikt i ISMS-dokumentasjonen, når kontrollene deres hevder at tredjepartsprogramvare håndteres.
SOC 2: Ingen egen kontroll for lisensside, men revisorer følger sporene
Trust Services Criteria navngir ikke "publiser alle lisenser på et nettsted." Revisorer sporer likevel juridisk etterlevelse og endringshåndtering. Systematiske hull (manglende notice, ikke-gjennomgått oversikt, ingen oversikt på produktnivå) dukker opp som kontrollsvakheter når stikkprøver ikke stemmer med retningslinjene.
Sertifiseringsomfang er ikke produktomfang
Et SOC 2 Type II- eller ISO-sertifikat dekker systemet og perioden deres, ikke automatisk hver avhengighet i hver SKU. Kjøpere stiller produktspesifikke spørsmål uansett. Sertifiseringen hjelper; den erstatter ikke offentliggjøring av tredjepartslisenser for produktet avtalen gjelder.
Dokumentasjonspakker blir utdaterte mellom revisjoner
Team sender inn det samme OSS-regnearket til ISO-oppfølgingen som de sendte i fjor, mens ingeniørene har levert tolv utgivelser. Oppfølgingsrevisorer tar stikkprøver av systemer i drift. Avvik mellom dokumentasjon og produksjon er et klassisk alvorlig avvik, og det samme misforholdet ødelegger fornyelser hos innkjøp.
Sikkerhetsskanning er ikke lisensgjennomgang
Sårbarhetsskannere og SBOM-verktøy identifiserer komponenter og noen ganger lisensfelt. De legger ikke ved fullstendig lisenstekst, godkjenner ikke copyleft-risiko, og publiserer ikke kjøperklar offentliggjøring. Å likestille resultatet fra AppSec-verktøy med lisensetterlevelse skaper falsk trygghet, både i SOC-dokumentasjon og RFP-svar.
Copyleft-overraskelser rammer sertifiserte organisasjoner også
GPL eller AGPL i et levert produkt uten kildekodetilbud eller etterlevelsesgjennomgang er et juridisk og revisjonsmessig problem, uansett ISO 27001-sertifisering. Å bli oppdaget under en kjøpers due diligence, i stedet for intern gjennomgang, er den kostbare veien.
Kjøpere vil ha dokumentasjon i tillegg til rapporten deres
Enterprise-kunder ber om SOC-rapporten deres og en tredjepartslisensoversikt for produktet: Oversikt, fullstendig tekst, vedlikeholdsprosess. Trust center dekker sikkerhetsstatus; lisensoffentliggjøring dekker immaterialrettslige forpliktelser i kodebasen. Begge inngår i modne leverandørgjennomganger.

På denne siden

SOC 2 og ISO 27001 beviser at dere driver et sikkerhets- og styringssystem: Tilgangskontroll, endringshåndtering, risikobehandling, leverandøroppfølging. Revisorer undersøker utforming og operativ effektivitet av kontrollene. Ingen av sertifiseringene fører automatisk opp hver open source-lisensforpliktelse i hvert levert produkt.

Kjøpere behandler sertifisering som en selvfølge, og ber deretter separat om offentliggjøring av tredjepartslisenser (fullstendig tekst, navngivelse, produktavgrenset oversikt). Å bestå SOC 2 svarer ikke på "hvilke GPL-komponenter finnes i byggeversjonen vi har lisensiert."

Hva krever ISO 27001 egentlig når det gjelder open source-lisenser?

ISO/IEC 27001:2022 krever at dere har rutiner som sikrer overholdelse av immaterielle rettigheter, inkludert programvarelisensvilkår, under Annex A-kontroll 5.32. Standarden foreskriver ikke en offentlig lisensside, men en revisor kan be om dokumentasjon på at tredjepartslisensvilkårene i det dere leverer, faktisk er oppfylt.

Et kontrolldokument som sier "vi respekterer OSS-lisenser" uten dokumentasjon (gjennomgått oversikt, fullstendig tekst, samsvar med utgivelsen), er et avvik som venter på å skje. Spesielt når stikkprøver finner pakker i produksjon som ikke står på noen liste.

Retningslinjer for godkjente lisenser og godkjenningsprosesser.
Dokumentasjon på at leverte produkter overholder tredjepartslisensvilkårene.
Dokumentasjon på gjennomgang, ikke bare resultat fra en oppdagelsesskanning.
Samsvar mellom det ISMS-en hevder og det ingeniørene faktisk leverer.
Håndtering av lisensendringer når avhengigheter oppdateres.

Hva ser SOC 2-revisorer etter når det gjelder lisensetterlevelse i praksis?

SOC 2-revisorer krever ikke en offentlig lisensside; de sporer om AICPAs Trust Services Criteria-kontroller for juridisk etterlevelse, leverandørstyring og endringskontroll faktisk fanger opp tredjepartslisensforpliktelser. Slurvete OSS-hygiene viser seg der som svak dokumentasjon mot kriterier dere allerede hevder å oppfylle.

Revisorer tar stikkprøver av systemer. De spør hvordan dere vet at tredjepartsprogramvaren er korrekt lisensiert. "Vi kjører npm audit" er ikke et svar. Det er heller ikke et sertifiseringsmerke på nettstedet uten en produktnivå-oversikt.

Kontroll	Hva revisorer forventer	Dokumentasjon som oppfyller det
ISO 27001 A 5.32	Rutiner som sikrer overholdelse av immaterielle rettigheter og programvarelisenser	Gjennomgått oversikt med fullstendig lisenstekst per levert produkt
SOC 2 CC2.2	Styring og oppfølging av etterlevelsesforpliktelser	Gjennomgangslogger som viser hvem som godkjente hvilke komponenter, når
SOC 2 CC8.1	Endringer i avhengigheter går gjennom endringshåndtering	Avviksdokumentasjon som knytter lockfile-endringer til ny gjennomgang
SOC 2 CC9.2	Risiko knyttet til tredjeparts- og leverandørprogramvare håndteres	Produktavgrenset offentliggjøringsoversikt, oppdatert per utgivelsen

Avvik oppstår når retningslinjer finnes, men operativ dokumentasjon ikke gjør det.

Hvorfor sertifiseringer og kjøperes due diligence divergerer

Sertifiseringens omfang er kontrollmiljøet: Ofte et trust center, en periode, en systemgrense. Kjøperens due diligence-omfang er produktet de kjøper (denne SKU-en, denne utgivelsen, disse forpliktelsene i dag).

SOC 2-rapporten deres dekker hvordan dere håndterer endringer. Deres juridiske team ber om MIT-lisenstekst for libfoo 2.4.1 i installasjonsprogrammet de tar i bruk. Ulike spørsmål; begge trenger ærlige svar.

Hvorfor blir oversikten utdatert i sertifiserte organisasjoner?

Oversikten blir utdatert fordi sertifiseringen er periodisk mens avhengighetene endres kontinuerlig. Black Ducks Open Source Security and Risk Analysis-rapport fant open source-kode i 96 prosent av de reviderte kodebasene, og at de fleste inneholdt komponenter med lisenskonflikter eller uten identifiserbar lisens, så én årlig dokumentasjonspakke kan ikke følge med på hva hver utgivelse faktisk leverer.

Sertifiserte selskaper merger oppdateringer av avhengigheter mellom revisjonssyklusene. Utviklere legger til pakker uten å oppdatere regnearket fra fjorårets ISO-dokumentasjonspakke. Sertifikatet er gyldig; oversikten er utdatert.

Operativ lisensetterlevelse betyr ny import ved utgivelse, ny gjennomgang, republisering. Den samme vedlikeholdssløyfen som CRA og innkjøp krever, innenfor en ISMS som allerede hevder at dere håndterer tredjepartsrisiko.

Dokumentasjon både revisorer og kjøpere godtar

Gjennomgått tredjepartsoversikt knyttet til utgivelses-tagger. Fullstendig lisenstekst lagret sammen med hver godkjent komponent. Publiserings- eller eksportøyeblikksbilde med dato og godkjenner. Avviksdeteksjon når lockfiler endres. Offentlig eller kundevendt offentliggjøring når kontrakter krever det.

Formatet varierer (URL, PDF-eksport, JSON-pakke). Dokumentasjonen er den gjennomgåtte oversikten og prosessen, ikke filtypen.

Import fra lockfiler eller SBOM-er per utgivelse.
Menneskelig gjennomgang før godkjenning, spesielt for copyleft.
Revisjonsspor: Hvem godkjente hva, og når.
Eksporter lagt ved ISO-dokumentasjon eller SOC-revisorforespørsler.
Kjøres på nytt ved endringer i avhengigheter, ikke bare årlig.

Vanlige feilmønstre i revisjoner og avtaler

Retningslinjer uten oversikt. Oversikt uten fullstendig lisenstekst. Fullstendig tekst samlet inn én gang og aldri oppdatert. Sikkerhetsskanning forvekslet med lisensgjennomgang. Trust center som nevner personvern og sikkerhet, men tier om OSS. GPL i produksjon oppdaget av kjøperens skanning, ikke deres egen.

Hvert mønster skaper ISO-avvik, SOC-unntak eller forsinkede avtaler. Løsningen er operativ infrastruktur for lisensforpliktelser, parallelt med (ikke erstattet av) sertifiseringsprogrammene.

Slik kobler team kontroller til lisensarbeidet

Koble kontroll 5.32 og SOC-kriteriene for endringshåndtering til konkrete steg: Import, gjennomgang, publisering, avvikssjekk. Navngi ansvarlige i ingeniørteamet og etterlevelsesteamet. Legg offentliggjøringseksporter ved ISMS-dokumentasjonsmappene. Ta stikkprøver av produkter under intern revisjon, på samme måte som eksterne revisorer vil gjøre.

Sertifisering beviser prosessmodenhet. Lisensoversikter på produktnivå beviser at dere oppfyller forpliktelsene i programvaren dere selger. Kjøpere og ISO-stikkprøver forventer i økende grad begge deler sammen.

Hvordan SourceTrust støtter sertifiseringsbasert dokumentasjon

Sertifiseringer beviser at dere har et styringssystem. Lisensoversikter på produktnivå beviser hva som ble levert: Gjennomgått, med fullstendig tekst, oppdatert når avhengigheter endres.

SourceTrust importerer pakkefiler og SBOM-er, krever gjennomgang før publisering, og lager en vedlikeholdt offentliggjøringsoversikt per produkt, pluss eksporter til ISO-dokumentasjonsmapper og kjøperspørreskjemaer. Avvikssjekker holder lisensoversiktene på linje med de samme endringene i avhengigheter som endringshåndteringskontrollene deres allerede følger opp for SOC 2.

Se hvordan plattformen fungerer

Importer fra repoer, manifester og SBOM-er. Hver rad er en lisens som skal oppfylles
Gjennomgangs- og publiseringssperrer. Dokumentasjon revisorer kan stikkprøvekontrollere mot produksjon
Offentliggjøringsoversikt per produkt. Det kjøpere ber om utover SOC-rapporten
Avviksvarsler når avhengigheter eller lisenser endres mellom revisjonssykluser

SourceTrust er etterlevelsesinfrastruktur, ikke juridisk rådgivning, og ikke en erstatning for ISO- eller SOC-revisjonsselskapet deres. Det hjelper dere med å operasjonalisere lisensforpliktelser; juridisk rådgiver og revisorene deres er fortsatt de som avgjør utformingen av kontrollene deres.