ISO 27001 Annex A 5.32: intellectual property rights in practice

The enterprise questionnaire asks how you track open-source licences and who owns the code your contractors write. Your answer is a shared spreadsheet and a hope. This guide covers ISO 27001 Annex A 5.32 for UK teams of 25–250 people: what the control asks, how to evidence it without a standalone policy or a software asset management suite, and what auditors sample.

It is written for the security manager, head of IT or compliance lead who also has a product to ship. Most of the work turns out to be one contract clause, one quarterly reconciliation and a scanner you may already run.

What do ISO 27001 intellectual property rights require under Annex A 5.32?

Annex A 5.32 requires procedures that protect intellectual property in both directions. Outbound, you use licensed software, open-source components, fonts and media strictly within their terms. Inbound, you keep your own source code, designs and brand from leaving with contractors or being contaminated by a licence you never read.

Read the control as two lists. One covers other people's property and the other covers yours. Together they are what ISO 27001 Annex A intellectual property rights come to for a B2B technology firm.

The scope breaks down like this:

• Outbound, software: every application in the estate runs within its licence terms, with nothing cracked, keygenned or pirated.
• Outbound, open source: components are used on the terms their licences set, which depend on how you distribute the product.
• Outbound, content: fonts, stock imagery, paid research and standards documents are used within their commercial terms.
• Inbound, your own IP: source code, designs and brand stay with the company when a contractor leaves.
• Inbound, contamination: no licence you never read ends up governing your proprietary product.

For a technology firm the intellectual property often is the company value, so the control guards it at both ends. The nightmare scenario isn't a fine. It's an acquirer's scan finding a copyleft library compiled into your product while lawyers argue over whether you owe the world your source code.

The quieter failures still cost money: a vendor licence true-up after seats quietly doubled, a marketing site built on unlicensed fonts, or a contractor who was never asked to assign their work and therefore owns part of your codebase. Enterprise buyers now probe the same ground in procurement. Questions about SBOMs and open-source governance are now common in security reviews of software vendors.

A.5.32 is a preventive control. Procedures, sourcing rules and contract clauses work before the damage, because there is nothing to correct once proprietary code has shipped under a copyleft licence. It is the intellectual property slice of A.5.31, which covers your wider legal and contractual obligations. It leans on the A.5.9 asset inventory to show what is licensed, what is proprietary and what carries conditions.

What is the difference between ISO 27001:2013 Annex A 18.1.2 and A.5.32?

The 2013 control, A.18.1.2, asked for procedures to meet legal and contractual duties on intellectual property and proprietary software. A.5.32 keeps that purpose and reads it more widely: data-sharing agreements and the software habits of staff now sit in scope. The focus moves from counting licences to how people and contracts handle intellectual property.

Existing evidence rarely goes to waste. A licence register and a record of software reviews still matter, but they become one input rather than the whole answer. Treat the migration as a gap review: pull the old register, list the contracts that touch shared data, and read your acceptable use policy for software rules.

If you certified against the 2013 edition, three additions usually close the gap:

• Data-sharing agreements. Contracts with clients and suppliers should say who owns the data and outputs exchanged, and on what terms each side may use them.
• Everyday software behaviour. The acceptable use policy should state what staff may install, from where, and what happens to cracked or unapproved tools.
• Your own IP. Assignment and confidentiality clauses and offboarding revocation, covered below, protect what you own rather than counting what you rent.

A licence count alone is the 2013 mindset. A company can hold enough seats for every installed application and still have a freelance developer who owns its core module.

Do you need a standalone IP policy?

No. At 25–250 staff, rules embedded in your acceptable use policy satisfy the control: software from approved sources only, no cracked or keygen tools, licence terms respected, company IP kept on company systems. A dedicated intellectual property policy is large-enterprise furniture and adds drafting time without adding protection.

Put the rules in a short IP and licensing section of the acceptable use policy and point to it from onboarding. Each line should be testable. "Software from approved sources only" implies an approved list and a request route. "No cracked tools" implies a way to find one, which your MDM inventory already provides.

Awareness material then covers copyright and licensing in plain language, using the cases staff actually meet: a designer downloading a free font for a client deck, a developer pasting a snippet from a forum, a salesperson reusing a paid industry report.

The effort is small. Expect a day or two of policy and contract-template work, plus switching on dependency scanning you likely already have. The evidence trail is the policy itself, the software inventory and the contract templates, all of which you need anyway.

How do you prove every piece of software is licensed without a SAM suite?

Let your MDM tooling export the software inventory, then reconcile it quarterly against invoices, licence keys and SaaS subscription lists. At 50 people that is an afternoon per quarter, not a software asset management programme. The same pass checks SaaS seat counts, fonts, stock imagery and paid research against their licence terms.

Start with the export, not the spreadsheet. Your MDM tool already knows what is installed on every managed device, so the job is a comparison between two records you hold.

The quarterly pass runs in five steps:

1. Export the inventory. Pull installed software per device and reduce it to a unique application list with counts.
2. Match it to purchases. For each application, find the invoice, licence key or subscription that entitles you to run it, and record the seat count.
3. Check SaaS separately. Compare admin-console user counts with contracted seats, because SaaS never appears in the device inventory.
4. Ticket the gaps. Anything installed but unentitled, or entitled but unused, becomes a ticket with an owner and a decision: buy, remove or reassign.
5. File the result. Save the dated reconciliation with its tickets as evidence.

A licence spreadsheet nobody reconciles is a list of good intentions, not a control.

The pass should reach past software. Marketing and commercial teams infringe accidentally with fonts, stock imagery, paid research and standards documents, because each arrives with commercial terms nobody reads. Keep a short register of those assets: where each licence lives, who bought it and what it permits. When an auditor points at a stock image on your website and asks where the licence is, you answer from the register.

Seat caps get quietly exceeded when nobody owns entitlement reconciliation, and the first sign is a vendor true-up invoice. Name one owner for the quarterly pass and the habit holds.

How do you stop copyleft licences reaching production?

Generate a software bill of materials (SBOM) from your CI pipeline's dependency scanning and let it flag restrictive licences on every build. GPL-family copyleft inside a proprietary product is the finding you want at commit time, not in an acquirer's due-diligence data room, where it can reprice or kill the deal.

An SBOM lists the component parts and software dependencies of a software package. The NCSC guidance on SBOMs and software inventory describes it as a tool that helps vendors and developers understand the open-source and third-party components their software contains. For this control, the useful part is the licence recorded against each component.

Your CI pipeline already resolves dependencies on every build, so licence checking is a configuration step rather than a project. A scanner reads the manifests, identifies each component, including transitive ones, and compares its licence with a policy you define.

A workable setup has four parts:

• A licence policy. Sort licences into allowed, needs review and blocked, based on how you distribute the product.
• A merge gate. The build fails, or waits for approval, when a blocked licence appears.
• A current SBOM. The scanner regenerates the inventory on each build and stores it with the release.
• A named reviewer. One person can approve, replace or reject a flagged component, and the decision is recorded.

Permissive licences are routine. The case that needs a decision is copyleft in proprietary code. The answer depends on how the product reaches customers: replace the library, isolate it, buy a commercial licence or accept the obligations. Take legal advice before you ship rather than after.

Run the first scan against existing repositories, not only new commits. Expect a handful of surprises, triage them once, and the gate holds the line from then on.

The pitfall this prevents is the copyleft library compiled in with no dependency tracking. It surfaces years later, when nobody remembers who added it and removing it means rewriting a module.

Who owns the code your contractors write?

Unless the contract says otherwise, the contractor does. GOV.UK states that self-employed people usually own the intellectual property in commissioned work unless their contract gives the rights to the client. An explicit IP assignment clause in every contractor agreement is the highest-stakes item in the control and costs one template clause.

The GOV.UK guidance on intellectual property ownership sets the default, and it reaches everyone you pay on an invoice: the freelance developer who built your first release, the designer who drew your logo, the agency that wrote your integration. Without a signed clause, ownership of your product becomes legally ambiguous.

A contractor without an assignment clause isn't a supplier. They're a co-owner you haven't met.

Four controls close the gap:

• Assignment and confidentiality clauses. Put both in every employment and contractor agreement, contractors first.
• Least-privilege repository access with MFA. Grant access per repository and role, and expire it with the engagement.
• Revocation at offboarding. Remove access to repositories and design tools, and collect a signed exit acknowledgement.
• Certified wiping. Wipe devices on disposal or return, and keep the certificate.

Least privilege matters because access is the practical form of ownership: whoever can clone the repository can leave with it. Review repository membership quarterly alongside the software reconciliation, since the evidence lands in the same folder.

The common gap is agencies and freelancers engaged on a purchase order with no assignment terms. It tends to surface at the worst moment, during diligence. Fix live engagements now by asking legal counsel to paper the assignment while the relationship is friendly.

What do auditors check for ISO 27001 Annex A 5.32?

Auditors ask you to show the software reconciliation, explain what stops cracked tools, produce the contractor IP assignment clause with a signed example, and describe how open-source licences and source-code access are tracked. They sample endpoints against licence records and read a contractor agreement. Certification bodies grade a missing procedure major and an isolated lapse minor.

Expect practical questions, and prepare an artefact for each:

• "How do you know every piece of software is licensed?" Show the dated reconciliation.
• "What stops someone installing a cracked tool, and how would you find it?" Show the acceptable use rule and the MDM inventory.
• "Show me the assignment clause in your contractor template, and a signed example." Show the template and one executed agreement.
• "How are open-source licences tracked, and what happens when a restrictive one appears?" Show the SBOM, the scan output and a recorded decision.
• "Who can access your source code, and what happens when they leave?" Show repository membership and offboarding records.
• "Where's the licence for these stock images on your website?" Show the asset licence register.

Run your own sample the week before. Pick five endpoints, trace each application to an entitlement, pull one contractor agreement and read the assignment clause as a stranger would. Software firms should also open the dependency inventory and check that every copyleft component has a recorded decision.

The artefacts to have ready are short:

• The acceptable use policy with its IP and licensing rules.
• The MDM software inventory and the latest reconciliation.
• SBOM or dependency-scan output.
• Employment and contractor templates, plus one executed example.
• Supplier and client contracts that address IP ownership.
• Awareness material and disposal records with wiping certificates.

A software firm with no open-source governance at all is the classic major finding. Watch the pattern rule too: several minor lapses in one area read as a missing procedure, so fix the cause rather than each instance.

The commercial cost of a licence dispute or a poisoned acquisition is often worse than any audit finding. This is a control you run for the business, not the certificate.

How does GRC engineering automate Annex A 5.32?

Three automations carry most of the control: dependency scanning in CI that gates merges on restrictive licences, an MDM inventory diffed against the entitlement record with exceptions raised as tickets, and HR leaver events that trigger revocation across repositories and design tools. Each job files its own evidence.

None of this needs a new platform. The jobs sit in tools you already run, and the evidence accumulates as a by-product instead of a pre-audit scramble.

The commercial return is quieter than the audit one. A diligence scan finds an SBOM with decisions on file. A procurement questionnaire about open-source governance is answered with an export, not a week of archaeology. Setting the IP rules and getting assignment clauses into templates is governance work a fractional CISO can own. The gates, jobs and triggers below are the engineered form of the control.

Frequently asked questions