Annex A 5.32: Intellectual Property Rights

Annex A 5.32 sits in the organizational controls of ISO/IEC 27001:2022 and focuses on intellectual property rights (IPR): your organization’s rights (what you create and own) and other parties’ rights (what you buy, subscribe to, download, embed, or otherwise use). For a CCO or GRC lead, the fastest path to “ready for audit” is to treat IPR as a control that spans three systems you already run: procurement and third-party management, software asset management (SAM), and secure development governance.

Auditors rarely accept “we don’t pirate software” as a control. They want to see repeatable mechanisms: who approves software and content, how licenses are tracked, how open-source obligations are managed, how usage is monitored, and what happens when something is out of compliance. The biggest operational risk is silent drift: teams install tools outside procurement, developers copy code snippets with unclear licensing, marketing uses images without rights clearance, or contractors bring in assets under their own terms.

This page gives requirement-level implementation guidance you can put into your ISMS quickly, with artifacts to retain and exam questions to prepare for, aligned to ISO/IEC 27001:2022 Annex A control 5.32. ¹

Regulatory text

Control focus (provided excerpt): “ISO/IEC 27001:2022 Annex A control 5.32 implementation expectation (Intellectual Property Rights).” ¹

Operator interpretation of what ISO expects:
You need documented rules and working processes to:

• Identify intellectual property relevant to your business (software, source code, documentation, training content, designs, data products, trademarks, patents, copyrighted materials).
• Protect your organization’s IP from unauthorized use, disclosure, or loss.
• Respect third-party IP and licensing terms (including software licensing, content licensing, and open-source license obligations).
• Demonstrate control operation with recurring evidence, not a one-time policy. ¹

Practically, auditors look for two things:

1. Governance: policy/standards and clear ownership for IP and licensing decisions.
2. Execution: inventories, approval workflows, monitoring, and remediation records.

Plain-English interpretation (what the requirement means day-to-day)

If your staff can install software, download libraries, copy images into decks, reuse code, or share product documentation, you have IPR risk. Annex a 5.32: intellectual property rights requirement expects you to run basic guardrails so the organization:

• Uses software/content only under valid rights (license, subscription, contract, or permission).
• Can prove what it owns, what it’s allowed to use, and under what conditions.
• Prevents accidental IP leakage (for example, proprietary source code posted to public repos).
• Responds to suspected infringement or license violations with documented corrective actions. ¹

Who it applies to

Entities

• Service organizations seeking ISO/IEC 27001 certification or alignment, including SaaS, managed services, consultancies, and shared services functions. ²

Operational contexts (where it shows up)

• Procurement and third-party onboarding: purchased software, subscriptions, outsourced development, content creation agencies.
• IT operations: endpoint software installs, admin tooling, cloud marketplace purchases, SaaS sprawl.
• Engineering/SDLC: open-source libraries, code reuse, AI-generated code and training data questions, repository hygiene.
• Marketing and enablement: images, fonts, brand assets, customer references, training material distribution.
• HR and contractors: contractor-provided tools, BYOD policies, and offboarding access to IP repositories.

What you actually need to do (step-by-step)

Use this sequence to operationalize fast and make it auditable.

1) Define your IPR policy + minimum standards

Create or update an IPR and Software Licensing Policy that answers, in plain terms:

• What counts as IP at your org (source code, docs, models, designs, product data).
• Who can approve acquisition and use of third-party software/content.
• Rules for open-source use (allowed licenses, review triggers, attribution requirements).
• Restrictions on copying, sharing, publishing, and reuse.
• Consequences and remediation path for violations.

Keep it short; put detail in standards/procedures.

2) Assign ownership and a RACI that matches reality

Minimum ownership model:

• Legal/Compliance: license terms interpretation, contract clauses, infringement response.
• IT/SecOps: software installation controls, asset inventory tooling, monitoring.
• Engineering: open-source governance in SDLC, repository controls.
• Procurement/Vendor management: purchasing channels and records of entitlement.

Document decision rights: who can approve exceptions, who can accept residual risk, and who signs renewals.

3) Build a single inventory that an auditor can follow

Maintain an IPR register that links:

• Owned IP: key repositories, critical documentation sets, trademarks/domain names, proprietary datasets (as applicable).
• Third-party IP entitlements: software licenses, SaaS subscriptions, content licenses, marketplace purchases. For each item: owner, business purpose, system/asset mapping, renewal/expiry cues, and evidence location (contract, invoice, order form, license key, or subscription admin record).

If your organization is large, start with “material to the ISMS scope” assets, then expand.

4) Put IPR controls into procurement and third-party workflows

Implement gates that prevent untracked buying and ambiguous rights:

• Approved purchase channels only (procurement system, expense tool with approvals, cloud marketplace guardrails).
• Contract intake checklist: license scope, user counts, geographic restrictions, subcontractor rights, audit clauses, and termination/offboarding terms for IP.
• Third-party work-for-hire and contractor agreements: confirm IP assignment, confidentiality, and deliverable ownership.

Evidence should show the gate ran, not just that it exists.

5) Control software installation and access to IP repositories

Pick controls that fit your stack:

• Endpoint management or app allowlisting for employee devices where feasible.
• Restricted admin rights; documented exception handling for developers/admins.
• Access control and logging for source code repositories and documentation platforms.
• Offboarding checklist that removes access to code, design systems, and document stores.

6) Govern open-source use in the SDLC (the common audit pressure point)

Minimum viable open-source program for ISO:

• Maintain a standard for approved licenses and review triggers.
• Require dependency inventory for production builds (often via SBOM-capable tooling).
• Review process for copyleft/reciprocal licenses when applicable.
• Attribution and notice file process where required by license terms.
• Track exceptions with documented approval and rationale.

Keep the workflow lightweight: engineers comply when it’s embedded into CI/CD.

7) Monitor, remediate, and capture recurring evidence

Control operation needs a cadence:

• Periodic reconciliation: license entitlements vs actual usage (SAM reports, SaaS admin exports).
• Spot checks for unapproved software and shadow IT.
• Ticketed remediation: uninstall, purchase entitlement, replace component, update attributions, or restrict access.
• Corrective action records tied to nonconformities, plus lessons learned.

Daydream tip: many teams fail audits on “evidence scatter.” If you use Daydream to map Annex A 5.32 to a control narrative and schedule recurring evidence capture, you reduce last-minute evidence hunts and keep a consistent audit trail.

Required evidence and artifacts to retain

Auditors want objective evidence. Keep these artifacts organized by control:

Evidence type	What “good” looks like
IPR / Software Licensing Policy	Approved, versioned, in-scope, communicated
IPR register + license inventory	Owner, scope mapping, entitlement source, renewal data
Procurement/workflow records	Approved requests, PO/invoice/order forms, contract repository links
Open-source governance artifacts	Dependency lists/SBOM outputs, review approvals, attribution files, exception tickets
Access control evidence	Repo access lists, role definitions, offboarding completion records
Monitoring outputs	SAM/SaaS usage exports, endpoint inventory, alert summaries
Incident/nonconformity records	Tickets showing investigation, decision, remediation, corrective actions

Common exam/audit questions and hangups

Expect these questions and prepare “show me” evidence:

• “How do you ensure staff cannot install unlicensed software?”
• “Show your inventory of software licenses and how you reconcile usage.”
• “How do you manage open-source licensing risk in released products?”
• “Where is IP ownership defined for contractors and third parties?”
• “How do you prevent proprietary code from being published externally?”
• “Show a recent example of an exception and how it was approved and closed.” ¹

Common hangup: teams have a policy and contracts, but no operational proof that approvals, monitoring, and remediation happen consistently.

Frequent implementation mistakes (and how to avoid them)

1. Inventory equals a spreadsheet with no owners.
   Fix: require an accountable owner per entitlement and per critical IP asset, with a review workflow.

2. Open-source is treated as “engineering’s problem.”
   Fix: define a single governance standard, and require evidence from CI/CD outputs and approvals.

3. Procurement bypass is tolerated.
   Fix: enforce approved purchasing channels and require exceptions to be ticketed and time-bound.

4. Offboarding misses IP repositories.
   Fix: add repo/documentation access removal to the offboarding checklist and retain completion evidence.

5. No linkage to ISMS scope.
   Fix: map IPR assets and licenses that support in-scope services first, then expand coverage.

Enforcement context and risk implications

ISO 27001 is a certification standard, not a regulator. The “enforcement” you feel is certification audit outcomes: major/minor nonconformities, surveillance audit findings, and corrective action requirements. Operationally, weak IPR controls also increase the odds of:

• Contract disputes with third parties over usage and audit rights.
• Forced software true-ups or subscription termination.
• Product release delays when licensing issues are discovered late.
• Reputational and customer trust impacts after IP leakage (for example, source code exposure). ²

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Confirm ISMS scope and list the in-scope products/services and supporting systems.
• Publish or refresh the IPR and software licensing policy, plus an open-source standard.
• Establish owners (Legal, Procurement, IT, Engineering) and the exception workflow.
• Stand up an initial IPR register focused on: core repos, critical documentation, top software/SaaS in scope.

Days 31–60 (instrument and prove operation)

• Implement procurement intake checklist and require approvals for new tools and content.
• Start SAM/SaaS usage exports and reconcile against entitlements for in-scope tools.
• Add SDLC checks: dependency inventory and license review triggers for releases.
• Run one internal control test: pick a sample of tools and show entitlement, approval, and usage evidence.

Days 61–90 (close gaps and make it repeatable)

• Remediate gaps found: remove unapproved software, buy entitlements, replace problematic libraries, fix attributions.
• Formalize recurring evidence capture and review cadence (inventory review, monitoring outputs, exception log review).
• Train targeted teams (Procurement, Engineering, Marketing) with role-based guidance.
• Prepare an audit pack in Daydream (or your GRC system): control narrative, mapped artifacts, last-run evidence, and corrective actions.

Frequently Asked Questions

Does Annex A 5.32 only apply to software licenses?

No. It covers intellectual property more broadly, including content, documentation, source code, designs, and other copyrighted or licensed materials used by the organization. ¹

What’s the minimum inventory an auditor will accept?

Start with an inventory for items that support your ISMS scope: core SaaS, endpoint software, production dependencies, and key IP repositories. The inventory must show ownership, entitlement source, and how you review it.

How do we handle open-source libraries without slowing releases?

Embed the check in CI/CD: automatically generate dependency inventories and require review only for flagged licenses or new high-impact components. Keep an exception path with documented approval.

We have decentralized purchasing. Can we still pass?

Yes, if you enforce an approval mechanism and can produce consistent evidence of entitlement and review. Decentralization fails audits when teams cannot prove controls ran across the environment.

What evidence is strongest for “we prevent unlicensed installs”?

Endpoint/app management configurations, admin privilege restrictions, software inventory reports, and tickets showing remediation of unapproved installs. Pair configuration evidence with actual monitoring outputs.

How should contractors be handled under 5.32?

Contracts should address IP ownership/assignment and permitted tool use, and your access controls should limit contractor access to IP repositories to what they need. Offboarding must remove that access with retained records.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview