ISO 27001 Control 5.32: Intellectual Property Rights

A routine licensing audit uncovers dozens of unauthorized software installations across your organization. Within weeks, you’re facing six-figure fines, stalled vendor contracts, and a legal team scrambling to quantify exposure. Control 5.32 exists to prevent exactly this — establishing the procedures that protect your organization’s intellectual property and keep you compliant with third-party licensing obligations.

What 5.32 Requires

ISO 27001 Annex A Control 5.32 requires organizations to implement procedures that protect their own intellectual property and ensure compliance with legal and contractual obligations when using third-party proprietary materials. In practice, this means building a system that tracks what you own, what you’ve licensed, and how both categories are used across the organization.

The control covers a broad scope: software licenses, patents, trademarks, design rights, source code, database rights, and copyrighted documents. Your organization needs documented policies governing the acquisition, use, storage, and disposal of each category. This isn’t just about having a license spreadsheet — it requires procurement controls, acceptable use rules, and active monitoring to verify compliance. The ISO/IEC 27001:2022 standard positions this control within Annex A’s organizational controls, reflecting its governance-level importance.

Open-source components deserve specific attention. Many organizations treat open-source as “free software” without recognizing that open-source licenses carry their own obligations — some require derivative works to be published under the same license. Failing to track open-source dependencies and their license types creates legal exposure that’s easy to overlook until an audit or acquisition surfaces it.

Why 5.32 Matters

Picture a mid-sized technology firm preparing for a major enterprise deal. During the prospect’s vendor due diligence, the security questionnaire asks for evidence of software license compliance. The firm can’t produce a current software asset register. The prospect requests a license audit, which reveals unlicensed installations across development and operations teams. The deal stalls. Legal exposure materializes. The reputational damage spreads through an industry where word travels fast.

This isn’t hypothetical. The BSA | The Software Alliance found that 37% of software installed on personal computers worldwide was unlicensed, with a commercial value of $46.3 billion — suggesting the gap between what organizations think they have licensed and what’s actually running is far wider than most compliance teams assume.

The risks break down into three categories. Legal and regulatory risk comes first: copyright holders and software publishers actively pursue enforcement actions, and penalties scale with the number of installations. Organizations operating across multiple jurisdictions face compounded exposure, as IP enforcement regimes vary significantly — what triggers a warning letter in one country can result in criminal prosecution in another.

Financial risk follows. Settlements, back-licensing fees, and legal costs can dwarf the price of proper licensing. Beyond direct penalties, consider the cost of emergency remediation: pulling unlicensed software from production systems, renegotiating expired agreements under duress, and hiring external counsel to manage enforcement responses. These costs accumulate quickly when the scope of non-compliance spans hundreds of endpoints.

Then there’s reputational damage. Certification bodies, clients, and partners all view IP non-compliance as a governance failure that raises questions about broader control maturity. If your organization can’t manage software licenses, prospects and auditors will wonder what else is slipping through the cracks.

What Attackers Exploit

IP control failures create specific vulnerabilities that go beyond legal exposure:

• Unauthorized software installations introduce unvetted code into your environment, expanding the attack surface with applications that may lack security patches or vendor support
• Missing license inventories mean no one knows what’s running, making it impossible to verify patch status or end-of-life timelines
• Untracked open-source dependencies can include components with known vulnerabilities listed in the National Vulnerability Database or license conflicts that force emergency code rewrites
• Employees copying proprietary content — training materials, research reports, competitor analysis — without authorization creates data leakage risks
• Absent IP clauses in vendor contracts leave you exposed when a vendor’s software includes components with restrictive licensing terms

How to Implement 5.32

Implementation splits into two tracks: protecting and managing your own organization’s IP, and verifying that your vendors do the same. Most organizations start with first-party controls because the gaps are immediate and the evidence is easier to produce for auditors. An ISO 27001 implementation checklist can help you track progress across all controls, including 5.32.

For Your Organization (First-Party)

Start with policy. Create a topic-specific intellectual property rights policy that defines what categories of IP your organization handles, who is responsible for each, and what constitutes acceptable use. This policy should cover software, documents, designs, source code, and any proprietary data your organization creates or licenses.

Build a software asset register next. Map every installed application to its license entitlement — commercial, subscription, per-seat, site license, or open-source. The register must cover endpoints, servers, cloud instances, and development environments. Include license expiration dates, renewal terms, and the business owner responsible for each application. Incomplete registers are the most common audit finding for this control, and the gaps typically appear in cloud subscriptions and SaaS tools that bypass traditional procurement.

Establish procurement controls that require all software to be acquired through approved channels from reputable sources. This prevents shadow IT purchases and ensures every acquisition goes through a process that captures licensing terms before installation. The procurement workflow should include a step where legal reviews licensing terms for any restrictions on usage, redistribution, or modification — particularly for software that will be embedded in products you deliver to customers.

Implement periodic license compliance reviews. Quarterly or semi-annual reviews should compare the asset register against actual installations, identify discrepancies, and trigger remediation. Automated software asset management tools like Flexera or Snow make this manageable at scale, following the practices defined in ISO/IEC 19770-1 for IT asset management.

Define clear rules for copyrighted materials. Employees need to know the limits on reproducing published content, using stock imagery, and repurposing third-party materials in internal or external documents. This includes content used in presentations, training materials, marketing collateral, and customer-facing documentation — areas where unauthorized copying is common but rarely flagged until an external audit.

Track open-source dependencies in your development pipeline. Every codebase should have a software bill of materials identifying each open-source component, its license type, and any obligations that license imposes. Tools like Snyk and Black Duck automate dependency scanning and flag license conflicts.

Train employees on IP obligations during onboarding and annually thereafter. Training should cover what IP the organization owns, how to handle third-party materials, and the consequences of non-compliance. Role-specific training matters here: developers need guidance on open-source license obligations, marketing teams need rules for using third-party imagery and content, and procurement staff need to understand how license terms affect downstream usage.

Common mistakes to avoid:

• Treating license management as purely an IT function — legal, procurement, and finance must be involved
• Relying on an honor system for software installations rather than automated discovery
• Ignoring open-source license obligations because the code is “free”
• Having no process for software disposal, transfer, or decommissioning when employees leave or hardware is retired

For Your Vendors (Third-Party Assessment)

Your IP compliance posture is only as strong as your vendors’. ISO 27001’s third-party risk requirements extend to IP compliance. When assessing third-party IP practices, build these questions into your security questionnaires:

• Do you maintain a software asset register? How frequently is it updated?
• How do you verify license compliance across your organization?
• What is your policy on open-source usage? Can you provide a software bill of materials for products you deliver to us?
• Have you been subject to any IP-related disputes or enforcement actions?

Request supporting evidence, not just attestation. Self-reported compliance claims without documentation are a consistent weakness in vendor assessments — particularly for IP, where the evidence is either concrete (license records exist) or it isn’t. A credible vendor should be able to provide a current software license inventory, an IP protection policy, open-source bills of materials for delivered products, and results from recent license audits.

Red flags during assessment:

• No formal IP policy exists or the vendor cannot locate it
• Inability to produce license records or a software asset register
• Resistance to sharing open-source dependency lists for delivered software
• History of IP disputes, BSA enforcement actions, or licensing settlements

To verify beyond self-attestation, conduct a third-party risk assessment that includes evidence of periodic license audits conducted by internal or external parties. Check whether the vendor holds BSA compliance certification or equivalent, and consider ongoing vendor monitoring to catch compliance drift between assessments. For software vendors specifically, ask for their SBOM process documentation and compare it against what they actually deliver.

Audit Evidence for 5.32

Auditors assess this control by verifying that procedures exist, are followed, and produce documented evidence. The distinction matters: having a policy on paper satisfies documentation requirements, but auditors will test whether the policy translates into operational practice. They do this by sampling records from your registers, reviewing recent compliance actions, and interviewing staff about their awareness of IP obligations. The table below maps the evidence types most commonly requested during certification and surveillance audits.

When you prepare for an ISO 27001 audit, auditors typically select a sample of entries from the software asset register and cross-reference them against license documentation and actual installations. Gaps between what the register shows and what’s installed trigger non-conformities. Having remediation records for previously identified gaps demonstrates ongoing compliance, not just point-in-time accuracy.

Cross-Framework Mapping

No competitor covering this control maps it to other frameworks, but the crosswalk matters. If your organization is managing multiple certifications — ISO 27001 alongside SOC 2, NIST, or DORA — understanding where controls overlap lets you consolidate evidence collection and avoid duplicating audit preparation work. Use the mappings below to identify which 5.32 evidence satisfies parallel requirements.

NIST SP 800-53 Rev. 5 CM-10 is the closest equivalent, covering software usage restrictions and license tracking requirements. The CIS Controls v8.1 cluster addresses the inventory and discovery aspects but doesn’t extend to legal compliance. SOC 2 CC6.7 overlaps on access restrictions to software but doesn’t specifically address intellectual property obligations. DORA Article 9 introduces asset management requirements for EU financial entities that align with the inventory and tracking elements of 5.32.

Related ISO 27001 Controls

Control 5.32 doesn’t operate in isolation. It connects to several other Annex A controls that address adjacent compliance, asset management, and data protection requirements.

The strongest functional dependency is with 5.9 (asset inventory) and 5.31 (legal requirements). Without a complete asset inventory, you can’t verify license compliance. Without understanding your legal and contractual obligations, you can’t define what compliance looks like for your specific context. Control 8.28 (secure coding) is particularly relevant for software development organizations, as open-source governance during development is where many IP compliance failures originate — long before the software reaches production.

Frequently Asked Questions

What is ISO 27001 5.32?

ISO 27001 Annex A Control 5.32 requires organizations to implement procedures that protect intellectual property — their own and third parties’ — including software licenses, copyrights, patents, and proprietary materials. It ensures your organization tracks what IP it holds, complies with licensing terms, and has policies preventing unauthorized use or duplication.

What happens if 5.32 is not implemented?

Failure to implement this control exposes your organization to legal penalties from copyright holders, software publisher enforcement actions, and financial settlements that can reach six or seven figures. It can also lead to ISO 27001 certification non-conformities, lost business during vendor due diligence, and reputational damage within your industry.

How do you audit 5.32?

Auditors review your intellectual property rights policy, then sample entries from the software asset register and cross-reference them against license documentation and actual installations. They check for training records, open-source governance documentation, and evidence of periodic compliance reviews. Gaps between registered and installed software are the most common finding.

How UpGuard Helps

When your vendors can’t demonstrate IP compliance, it becomes your risk. UpGuard Vendor Risk lets you assess third-party intellectual property practices at scale — evaluating whether vendors maintain software asset registers, track license compliance, and govern open-source usage across their operations. See how UpGuard Vendor Risk helps you identify IP compliance gaps before they become audit findings.