ISO/IEC 5230 is the OpenChain standard for open source licence compliance management. It sets requirements for organisations to identify open source components, track their licences, keep notices and obligations, and maintain a documented compliance process across software development and distribution.
What ISO/IEC 5230 Actually Governs
ISO/IEC 5230 is not a technical security control in the narrow sense, it is a governance standard for running open source licence compliance as a repeatable organisational process. Its value is that it turns licence review, notice handling, obligation tracking, and release discipline into something auditable rather than ad hoc.
That matters because open source use is now embedded across modern software supply chains, including build systems, downstream distributions, and third-party components. A compliance programme built around the standard helps teams know which components are in use, which obligations attach to them, and which disclosures must travel with shipped software.
Why Open Source Licence Compliance Fails
Most failures are not caused by a single bad licence choice. They come from weak inventory, incomplete review, or teams assuming that permissive licences eliminate all obligations. Even when the code is free to use, there may still be notice, attribution, source-disclosure, distribution, or modification conditions to preserve.
ISO/IEC 5230 is designed to reduce that drift by creating a documented process for identifying components, classifying licences, and keeping evidence of decisions. In practice, that means compliance is tied to software development and distribution workflows instead of being left to memory, spreadsheets, or last-minute release scrambles.
What Organisations Need to Track
The standard is best understood as a control over information flow. Organisations need a reliable view of the components they consume, the licences attached to those components, the obligations that arise from those licences, and the notices or source references that must be retained or published.
For teams running at scale, this also means linking compliance work to build artefacts and release gates. A useful programme does not just say “we use open source,” it can answer which packages are present, where they entered the product, which declarations are required, and whether those obligations still hold after upgrades, forks, or redistribution.
That is why the Open Source Licence Compliance Guide is the most direct companion for this topic, because it explains how SPDX licence expressions, SBOM licence fields, and OpenChain-style compliance work together in practice.
How ISO/IEC 5230 Supports Software Supply Chain Governance
ISO/IEC 5230 sits inside broader software supply chain governance, even though its focus is licence compliance rather than build integrity. It helps organisations prove that open source usage is governed, that release outputs are reviewed, and that obligations are not silently dropped as code moves from development to distribution.
A mature programme often needs adjacent controls as well. Supplier onboarding, incident handling, secure development, and release management all influence whether compliance data stays accurate and whether obligations are handled before a product ships. The standard is therefore strongest when it is embedded in the software delivery lifecycle, not treated as a one-time legal review.
For organisations formalising that broader operating model, ISO/IEC 27036 Supplier Relationships Guide is useful context for third-party dependency governance, while ISO 27002 Controls Guide helps place compliance work alongside other security controls that support software assurance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.31 — Legal, statutory, regulatory and contractual requirements | Licence compliance is a contractual and legal obligation that must be identified and tracked. |
| A.8.9 — Configuration management | Licence data and notices depend on controlled software inventories and release artefacts. | |
| Recommendation — Document open source licence obligations in the ISMS and keep compliance evidence current. Control software baselines so licence records stay aligned with shipped builds. | ||
| SLSA | Supply-chain integrity | Open source compliance depends on trustworthy build and distribution provenance. |
| Recommendation — Tie licence checks to build provenance and release controls before publication. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Third-party software and upstream dependency handling are central to open source compliance. |
| Recommendation — Track supplier software obligations and verify downstream licence conditions before adoption. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Licence compliance is part of disciplined software architecture and release governance. |
| Recommendation — Embed licence review into software design and release governance workflows. | ||
Practitioner Guidance
Governance implication: Treat ISO/IEC 5230 as an operating model, not a policy statement. Someone must own the compliance process, define where licence decisions are recorded, and ensure releases cannot bypass the review path.
What to watch for: The biggest warning signs are unmanaged component intake, inconsistent notices, and licence records that live outside the build and release process. If teams cannot quickly explain which open source obligations apply to a release, the programme is not yet operationalised.
Practitioner takeaway: The standard is most effective when licence compliance is evidence-driven, version-aware, and wired into the product lifecycle before distribution begins.
Related resources from NHI Mgmt Group
- Who is accountable for ISO/IEC 42001 evidence and AI access control?
- Why does ISO/IEC 27001:2022 matter for IAM and NHI programmes?
- Why do organisations choose ISO/IEC 27001 when they already have other security frameworks?
- What is the difference between ETSI TS 119 461 and ISO/IEC 30107 in identity proofing?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org