SOC 2 · ISO 27001

Does passing SOC 2 or ISO 27001 cover license disclosure?

No. Security certifications and third-party license disclosure answer different questions, and both can be true at once: You can hold a valid certificate and still owe a reviewed, product-level license record.

Last updated: July 2, 2026

01What this page is pointing at

The overlooked failure points

These show up in diligence and audits: Obligations exist, evidence is missing, and the artifact buyers expect is absent.

Open-source licenses are legal obligations, not preferences
MIT, Apache, GPL, LGPL, and proprietary SDK agreements impose conditions: Notice, attribution, copyleft, distribution rules. Missing them is license breach, not a stylistic gap. SOC 2 and ISO programs do not make those obligations disappear; they ask whether your controls catch them before shipment.
ISO 27001: Intellectual property is explicit
Annex A 5.32 requires procedures to comply with intellectual property rights, including software licenses. Auditors expect evidence, not a policy PDF alone. Failing to include required license texts where licenses demand it is both an IP violation and an ISMS evidence failure when your controls claim third-party software is managed.
SOC 2: No license-page control, but auditors follow threads
Trust Services Criteria do not name "publish all licenses on a website." Auditors still trace legal compliance and change management. Systemic gaps (missing notices, unreviewed inventory, no product-level record) surface as control deficiencies when samples do not match policy.
Certification scope is not product scope
A SOC 2 Type II or ISO certificate covers your system and period, not automatically every dependency in every SKU. Buyers ask product-specific questions anyway. Your certification helps; it does not replace third-party license disclosure for the product under contract.
Evidence packs go stale between audits
Teams submit the same OSS spreadsheet to ISO surveillance that they submitted last year while engineering shipped twelve releases. Surveillance auditors sample live systems. Mismatch between evidence and production is a classic major finding, and the same mismatch kills procurement renewals.
Security scanning is not license review
Vulnerability scanners and SBOM tools identify components and sometimes license fields. They do not attach full license text, approve copyleft risk, or publish buyer-ready disclosure. Equating AppSec tooling output with license compliance creates false confidence in both SOC evidence and RFP answers.
Copyleft surprises hurt certified orgs too
GPL or AGPL in a shipped product without source-offer or compliance review is a legal and audit problem regardless of ISO 27001 certification. Discovery during buyer diligence, not internal review, is the expensive path.
Buyers want proof alongside your report
Enterprise customers request your SOC report and a third-party license record for the product: Inventory, full text, maintenance process. The trust center covers security posture; license disclosure covers IP obligations in the codebase. Both appear in mature vendor reviews.

SOC 2 and ISO 27001 prove you run a security and management system: Access control, change management, risk treatment, vendor oversight. Auditors examine control design and operating effectiveness. Neither certification inventories every open-source license obligation in every shipped product by default.

Buyers treat certification as table stakes, then ask separately for third-party license disclosure (full text, attribution, product-scoped inventory). Passing SOC 2 does not answer "what GPL components are in the build we licensed."

What does ISO 27001 actually require on open-source licenses?

ISO/IEC 27001:2022 requires you to operate procedures that ensure compliance with intellectual property rights, including software license terms, under Annex A control 5.32. It does not prescribe a public license page, but an auditor can ask for evidence that third-party license terms in what you ship are actually met.

A control document saying "we respect OSS licenses" without evidence (reviewed inventory, full text, release alignment) is a finding waiting to happen. Especially when sample testing finds packages in production not on any list.

Policy for acceptable licenses and approval processes.
Evidence that shipped products comply with third-party license terms.
Records of review, not just discovery scan output.
Alignment between what ISMS claims and what engineering ships.
Handling of license changes when dependencies update.

What do SOC 2 auditors look for on license compliance in practice?

SOC 2 auditors do not require a public license page; they trace whether your AICPA Trust Services Criteria controls for legal compliance, vendor management, and change control actually catch third-party license obligations. Sloppy OSS hygiene shows up there as weak evidence against criteria you already claim to operate.

Auditors sample systems. They ask how you know third-party software is licensed correctly. "We run npm audit" is not an answer. Neither is a certification badge on your website without a product-level inventory.

Control	What auditors expect	Evidence that satisfies it
ISO 27001 A 5.32	Procedures that ensure IP and software-license compliance	Reviewed inventory with full license text per shipped product
SOC 2 CC2.2	Governance and oversight of compliance obligations	Review logs showing who approved which components, when
SOC 2 CC8.1	Dependency changes flow through change management	Drift records tying lockfile changes to re-review
SOC 2 CC9.2	Third-party and vendor software risk is managed	Product-scoped disclosure record, current as of the release

Findings appear when a policy exists but operational proof does not.

Why certifications and buyer diligence diverge

Certification scope is the control environment: Often a trust center, a period, a system boundary. Buyer diligence scope is the product they purchase (this SKU, this release, these obligations today).

Your SOC 2 report covers how you manage change. Their legal team asks for MIT license text for libfoo 2.4.1 in the installer they deploy. Different questions; both need honest answers.

Why does the inventory go stale in certified organizations?

The inventory goes stale because certification is periodic while dependencies change continuously. The Black Duck Open Source Security and Risk Analysis report found open-source code in 96 percent of the codebases it audited, and that most contained components with license conflicts or no identifiable license, so a single annual evidence pack cannot track what each release actually ships.

Certified companies merge dependency updates between audit cycles. Developers add packages without updating the spreadsheet from last year's ISO evidence pack. The certificate is valid; the inventory is stale.

Operational license compliance means re-import on release, re-review, re-publish. The same maintenance loop CRA and procurement demand, inside an ISMS that already claims you manage third-party risk.

Evidence auditors and buyers both accept

Reviewed third-party inventory tied to release tags. Full license text stored with each approved component. Publish or export snapshot with date and approver. Drift detection when lockfiles change. Public or customer-facing disclosure when contracts require it.

Format varies (URL, PDF export, JSON bundle). The evidence is the reviewed record and the process, not the file type.

Import from lockfiles or SBOMs per release.
Human review before approve, especially copyleft.
Audit trail: Who approved what and when.
Exports attached to ISO evidence or SOC auditor requests.
Re-run on dependency changes, not annual-only.

Common failure patterns in audits and deals

Policy without inventory. Inventory without full license text. Full text collected once and never updated. Security scan mistaken for license review. Trust center mentioning privacy and security but silent on OSS. GPL in production discovered by buyer's scan, not yours.

Each pattern creates ISO findings, SOC exceptions, or deal delays. The fix is operational infrastructure for license obligations, parallel to (not replaced by) certification programs.

How teams map controls to license work

Map control 5.32 and SOC change-management criteria to concrete steps: Import, review, publish, drift check. Name owners in engineering and compliance. Attach disclosure exports to ISMS evidence folders. Sample products during internal audit the way external auditors will.

Certification proves process maturity. Product-level license records prove you meet the obligations in the software you sell. Evidence buyers and ISO sample tests increasingly expect together.

Sources

How SourceTrust supports certification-backed evidence

Certifications prove you have a management system. Product-level license records prove what shipped: Reviewed, with full text, updated when dependencies change.

SourceTrust imports package files and SBOMs, requires review before publish, and produces a maintained disclosure record per product plus exports for ISO evidence folders and buyer questionnaires. Drift checks align license records with the same dependency changes your change-management controls already track for SOC 2.

See how the platform works

Import from repos, manifests, and SBOMs. Every row is a license to satisfy
Review and publish gates. Evidence auditors can sample against production
Disclosure record per product. What buyers ask for beyond the SOC report
Drift alerts when dependencies or licenses change between audit cycles

SourceTrust is compliance infrastructure, not legal advice and not a substitute for your ISO or SOC audit firm. It helps you operationalize license obligations; your counsel and auditors remain the authority on your control design.