Governance DocsGovernance Docs
Browse Toolkits

CART

No products in the cart.

ISO Compliance Insights & Best Practices

ISO 27001 intellectual property rights: the six categories in Annex A control 5.32

ISO 27001 Intellectual Property Rights: Complete 2026 Guide

ISO 27001 intellectual property rights is the plain-English name for Annex A control 5.32, and it is the control most likely to be answered with a single sentence in a policy and nothing else. The sentence usually reads something like “the organization respects the intellectual property of others.” An auditor will accept that as a statement of intent and then ask for the software register, the licence entitlements, the date of your last unlicensed-software review, and the file that shows which open-source licences your developers are allowed to pull in. That is the gap this guide closes.

A.5.32 sits in the organizational theme of ISO/IEC 27001:2022 — the 37 controls numbered 5.1 to 5.37, part of the 93 Annex A controls spread across four themes (37 organizational, 8 people, 14 physical, 34 technological). It is a preventive control, it carries all three information security properties, and in the ISO/IEC 27002:2022 attribute set it maps to the Identify cybersecurity concept, the legal and compliance operational capability, and the governance and ecosystem domain. In the 2013 edition the same ground was covered by A.18.1.2, so anyone migrating a legacy control set will find ISO 27001 intellectual property rights renumbered rather than new.

Free gap assessment

Where do you actually stand against ISO 27001?

Score every management system clause and all 93 Annex A controls, free, and get a prioritised gap list back.

Run the free ISO 27001 gap assessment →  or  View premium report sample

What ISO 27001 intellectual property rights actually requires

Stripped to its core, the control asks you to implement appropriate procedures to protect intellectual property rights. The stated purpose is compliance — meeting the legal, statutory, regulatory and contractual requirements that attach to intellectual property and to the use of proprietary products. That last phrase matters more than it looks: ISO/IEC 27002:2022 explicitly reaches proprietary software that is purchased, subscribed to, or leased, which means your SaaS estate is in scope just as much as the desktop installs.

Two points are worth settling before you write anything. First, ISO 27001 intellectual property rights is not a documented-information requirement. Annex A never says a register or a policy “shall be available as documented information” — that wording belongs to the main clauses. In practice you cannot demonstrate the control without records, so the register exists for evidential reasons rather than because the standard names it.

Second, if you decided this control does not apply to you, clause 6.1.3 requires your Statement of Applicability to carry that justification in writing. Excluding A.5.32 is a hard argument to make. Any organization that runs commercial software, buys standards, or ships code has intellectual property obligations, and the certification body will test the justification rather than accept it.

Free ISO 27001 risk assessment

Which of your risks sit above your appetite line?

Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.

Run the free risk assessment →  or  View premium report sample

Why ISO 27001 intellectual property rights is mostly about not infringing

The most common misreading is that this control exists to protect your own crown jewels. It does not, or at least not primarily. The purpose statement points outward: it is about you complying with somebody else’s rights. The job of protecting your own material is spread across different controls — A.5.12 and A.5.13 for classification and labelling, A.6.6 for confidentiality and non-disclosure agreements, A.8.12 for data leakage prevention, A.8.4 for access to source code.

Read that way, ISO 27001 intellectual property rights becomes a specific and useful control: it is the control that stops your organization being the infringer. The risk it manages is not a breach, it is a letter from a vendor’s compliance team, a licence true-up invoice, an injunction, or — for a software company — a copyleft obligation that forces disclosure of source you intended to keep closed.

The 2022 edition did widen it slightly. Compared with A.18.1.2, the current guidance adds the management of data-sharing agreements and recognises the value of shaping staff behaviour around intellectual property obligations. Both additions push the control towards people and contracts rather than pure asset counting.

One practical consequence: this control is rarely owned by the security team alone. Entitlement data lives in procurement and finance, licence interpretation sits with legal, and the install reality sits with IT asset management. Assign a single accountable owner for ISO 27001 intellectual property rights and name the contributors, or the register will quietly rot between three functions.

What ISO 27001 intellectual property rights covers: six categories

ISO/IEC 27002:2022 names six categories of intellectual property. Most registers built for ISO 27001 intellectual property rights only cover the first one.

CategoryWhat it covers in practiceWhere the evidence lives
Software copyrightCommercial applications, operating systems, firmware, SaaS subscriptions, plug-ins and extensionsLicence certificates, order forms, subscription admin consoles
Document copyrightPurchased standards, analyst reports, market research, stock imagery, training material, font filesPurchase records, seat counts, usage terms
Design rightsRegistered designs in hardware, packaging, user interface elementsSupplier contracts, design files, IP assignments
Trademark rightsLogos and marks used in your marketing, partner badges, certification marksBrand guidelines, partner agreements, mark usage permissions
PatentsLicensed technology, standards-essential patents in products you build or embedPatent licences, freedom-to-operate advice
Source code licencesOpen-source dependencies, third-party SDKs, code generated by AI assistantsSoftware bill of materials, dependency manifests, attribution notices

The document copyright row is the one that embarrasses people. If you bought a single-user PDF of ISO/IEC 27001 and pasted clause text into your ISMS policies, you have a finding against the very control you were documenting. The same applies to pasting ISO/IEC 27002 control text into a Statement of Applicability. Paraphrase, cite the clause number, and keep the licensed text where the licence says it can live.

The 12 implementation items behind ISO 27001 intellectual property rights

The guidance for ISO 27001 intellectual property rights breaks down into twelve items in ISO/IEC 27002:2022. Grouped by what you actually have to build:

Policy and procedure (items 1–2). A topic-specific policy on protecting intellectual property, scaled to your operations, plus published procedures that define what compliant use of software looks like. “Topic-specific” is the standard’s own term for the policies that sit under the top-level information security policy — see our guide to ISO 27001 policy templates for how that layering works.

Sourcing, register and proof (items 3–5). Acquire software only through known and reputable sources. Maintain an asset register that identifies which assets carry intellectual property obligations. Keep proof of ownership — licences, master media, order confirmations, vendor correspondence — available at all times.

Limits, reviews and renewals (items 6–8). Stay inside the usage limits in the agreement, which increasingly means concurrent users, named users, virtual cores or container instances rather than seats. Review periodically to confirm nothing unlicensed is installed. Run the operational and financial process that keeps licences current, because an expired licence and an unlicensed install look identical to a vendor’s auditor.

Transfer and disposal (item 9). Have a procedure for transferring or disposing of software compliantly. Reassigning a leaver’s named licence and wiping a decommissioned server both touch this.

Public domain, media and text (items 10–12). Comply with the terms, conditions and fair-use guidelines of software acquired from the public domain. Control the extraction, copying or conversion of commercial recordings in line with their terms and copyright law. Respect the copyright and licensing attached to textual data — articles, reports, books and standards.

Evidence auditors ask for on ISO 27001 intellectual property rights

Three artefacts carry ISO 27001 intellectual property rights through a stage 2 audit. The table below is the shortlist an assessor works from.

What the auditor asks forEvidence that satisfies itWhere it usually fails
“Show me what software you are licensed to run”Software register with title, publisher, version, business purpose, entitlement count and ownerRegister lists installs, not entitlements, so the two can never be compared
“Prove you own these licences”Licence certificates, purchase orders, vendor portal exports, subscription invoicesProof held in individual inboxes or expensed on personal cards
“When did you last check for unlicensed software?”Dated review output with findings and remediation, signed off by the control ownerDiscovery scan exists but no one reconciled it against entitlements
“Which open-source licences are your developers allowed to use?”Approved and prohibited licence list, dependency scan report, attribution file in the buildNo position has ever been taken, so the answer is “whatever is on npm”
“How do you handle a leaver’s licences?”Joiner-mover-leaver checklist including licence reclaim and reassignmentOffboarding revokes access but leaves the subscription billing and seat allocated

Build the register once and it serves several controls at the same time. The same inventory underpins A.5.9, feeds vulnerability management, and answers CIS Controls 1 and 2 — our asset inventory guide covers the mechanics of keeping it accurate.

ISO 27001 intellectual property rights and open-source software

Open source is where ISO 27001 intellectual property rights bites hardest in 2026, and it is the half most templates skip entirely. “Source code licences” is one of the six named categories, and item 10 of the guidance deals specifically with software acquired from the public domain. Free of charge is not the same as free of obligation.

Permissive licences such as MIT and Apache-2.0 impose notice and attribution duties: you must retain the copyright and licence text, and Apache-2.0 additionally requires you to pass on any NOTICE file and grants patent rights with it. Copyleft licences go further. GPLv2 and GPLv3 obligations are triggered by distribution — internal use does not, by itself, oblige you to publish anything — while AGPLv3 extends the trigger to users interacting with the software over a network. If you ship a product, embed a dependency, or operate a hosted service built on copyleft code, that distinction decides whether your source stays closed.

The practical mechanism is a software bill of materials plus automated dependency scanning in the build pipeline, with a short approved-and-prohibited licence list behind it. CIS Controls v8.1 reaches the same place from the other direction: safeguard 2.6 asks you to allowlist authorized libraries, and 2.7 authorized scripts.

AI coding assistants add a live question. Generated code arrives without provenance, vendor terms differ on indemnity and on what may be reproduced, and “source code licences” is exactly the category that has to absorb it. You do not need to resolve the law to satisfy ISO 27001 intellectual property rights — you need a documented position on which assistants are approved, what the vendor’s terms say about generated output, and how that output is reviewed before it enters the codebase.

How ISO 27001 intellectual property rights compares with NIST and CIS

If you already run another framework, most of the work behind ISO 27001 intellectual property rights is done. The mapping is unusually clean.

RequirementISO 27001 A.5.32NIST SP 800-53 Rev. 5CIS Controls v8.1
Use software per contract and copyright lawItems 1, 2, 6CM-10 aControl 2 rationale
Track usage against quantity licencesItem 6CM-10 b2.1 (number of licences recorded)
Inventory of licensed softwareItems 4, 5CM-8 with CM-102.1, review bi-annually or more often
Only supported software authorisedItem 8 (keeping licences current)SA-22 unsupported components2.2, verify at least monthly
Find and remove unauthorised softwareItem 7CM-7(5) allow-by-exception2.3, 2.5
Open-source restrictionsItems 10, source code licencesCM-10(1)2.6, 2.7
Peer-to-peer file sharingItem 11 (commercial recordings)CM-10 cNot addressed directly

Two details are worth knowing. CM-10 is in the Low, Moderate and High NIST SP 800-53 baselines — copyright compliance is treated as a floor requirement, not an enhancement — while CM-10(1), the open-source restrictions enhancement, is in no baseline at all and is therefore a deliberate organizational choice. And on the CIS side, safeguard 2.1 is Implementation Group 1, meaning the smallest in-scope enterprise is expected to maintain a detailed inventory of licensed software recording title, publisher, install date and business purpose, with the number of licences where applicable, reviewed at least every six months. Safeguard 2.2 tightens the cadence to monthly verification that authorised software is still vendor-supported, with documented exceptions and residual risk acceptance where it is not.

If you are mapping in the other direction, the NIST Cybersecurity Framework places this work in the asset management and risk management categories rather than giving it a dedicated subcategory, which is one reason organizations running CSF 2.0 alone often arrive at certification with no licence evidence at all.

Five mistakes that produce A.5.32 findings

Counting installs instead of entitlements. A discovery scan tells you what is running, not what ISO 27001 intellectual property rights asks you to prove. Only the entitlement record tells you what you are allowed to run. Without both sides, you cannot answer the one question the control exists for.

Forgetting subscriptions. The control explicitly covers products that are subscribed to or leased. Departmental SaaS bought on a card, seat counts that drifted upward after a reorganisation, and per-user tools still billing for leavers are all in scope — and all invisible to an endpoint scan.

Leaving developer tooling out. Engineering machines carry the highest density of licence risk: IDE licences with commercial-use thresholds, container base images with embedded licences, and dependency trees nobody has read. Your acceptable use policy should state who may install what, and the register should reflect it.

Treating the true-up as a finance exercise. A vendor audit clause is a contractual obligation inside the ISMS scope. If the only person who knows the renewal date works in procurement, the control has no owner.

Writing the policy from the standard’s own text. It is the one mistake that is self-defeating, and it happens constantly. Paraphrase the requirement, reference the control number, and leave the licensed wording in the licensed document.

For context on how widespread the underlying problem is: BSA’s 2018 Global Software Survey, still the most widely cited global measurement, put the worldwide unlicensed-software rate at 37% with a commercial value of $46.3 billion, ranging from 17% in North America and 28% in Western Europe to 57% in Asia Pacific. Those figures describe 2017 and should be read as directional rather than current, but the shape of the problem has not changed: the exposure is concentrated in organizations that never reconciled installs against entitlements.

ISO 27001 intellectual property rights FAQ

Is A.5.32 a mandatory control?

No Annex A control is mandatory in the way a main clause is. Clause 6.1.3 requires you to compare your necessary controls against Annex A and to justify inclusions and exclusions in the Statement of Applicability. In practice ISO 27001 intellectual property rights is applicable to nearly every organization, because nearly every organization runs licensed software or purchased documents.

Do I need a separate intellectual property policy?

The guidance asks for a topic-specific policy on intellectual property protection, so a dedicated document is the cleanest answer. A section inside an acceptable use or asset management policy can work if it covers sourcing, entitlement records, review cadence, open-source licence approval and disposal. What does not work is a sentence of intent with no procedure behind it.

Does ISO 27001 intellectual property rights cover open-source software?

Yes. Source code licences are one of the six named categories, and the guidance deals separately with software acquired from the public domain, including its terms, conditions and fair-use guidelines. Copyleft obligations and attribution duties both fall inside the control.

Can I exclude A.5.32 from the Statement of Applicability?

You can, but you must justify it, and the justification will be tested. An organization with no commercial software, no purchased standards, no licensed imagery and no third-party code is rare. If you exclude it, record the reasoning and the evidence that supports it rather than writing “not applicable.”

How often should we run a software licence review?

The standard says periodically and sets no interval, so pick one, write it down and keep the evidence. Annual is common and defensible for a small estate. If you want an external benchmark, CIS asks for the software inventory to be reviewed at least every six months and for support status to be verified at least monthly.

Where to start with ISO 27001 intellectual property rights

Build the register before you write the policy. Pull an install list from your endpoint tooling, pull entitlements from procurement and vendor portals, and reconcile the two in a spreadsheet — the gaps are the findings, and they will tell you what the policy actually needs to say. Then write the topic-specific policy, set the review cadence, and take a position on open-source licences before your next release rather than after.

If you would rather start from drafted documents, our ISO 27001 Toolkit covers the full Annex A control set with 165 templates for $149, including the policy, register and review records this control needs. It is the same documentation set used for certification projects, and it ships ready to populate rather than ready to rewrite.

For the wider picture, start with our pillar guide to ISO 27001, or read the Annex A controls breakdown to see where 5.32 sits among the other 92. The standard itself is available from ISO as edition 3, published October 2022, currently with one amendment.

When a standard changes, know first

One email a month: edition changes, new deadlines, and what they mean for documentation you already have. No sales sequence.

We don’t spam! Read our privacy policy for more info.