Control Definition
The organization must implement appropriate procedures to protect intellectual property rights — which in practice means both honoring the rights attached to software, content, and components it uses under license from others, and safeguarding the intellectual property it creates and owns.
Control Objective
To keep the organization compliant with the legal, regulatory, and contractual requirements that attach to intellectual property and the use of proprietary or licensed products.
What This Really Means
This control runs in two directions, and most organizations only see one of them. Direction one is a ledger: an accurate account of everything you use that someone else owns — commercial software, open-source components, fonts, images, datasets, training material — and proof that your use stays inside the license terms. Direction two is a vault: deliberate protection of the intellectual property you own — source code, product designs, ML models, methodologies, client deliverables. Reading A.5.32 as just an anti-piracy policy covers maybe a third of what an auditor will probe.
On the ledger side, commercial licensing is harder than it looks: entitlements have counts, editions, user definitions, and virtualization or indirect-access rules that infrastructure changes silently break. Open source adds a second layer — free to download is not free of obligations. Permissive licenses (MIT, Apache 2.0) ask little more than attribution; copyleft licenses (GPL, and especially AGPL for SaaS) can attach source-disclosure obligations to your own code. Software vendors run active license audit programs, and OSS compliance gets examined hardest during funding and acquisition due diligence — the worst possible moments to discover a problem.
On the vault side, the control expects you to know what IP you own, who may access it, and how ownership was secured in the first place. That means employment and contractor agreements that assign work-product IP to the organization, client contracts that are explicit about who owns deliverables, NDAs for what is shared outward, and access controls on the repositories where the crown jewels live. For a software company, source code is simultaneously an asset, a trade secret, and — if it embeds a mishandled copyleft component — a liability.
Auditors treat reconciliation as the heart of this control: can you put an installed-software report next to a license entitlement record and explain the difference? Can you show how an engineer gets a new dependency approved, and what stops an unlicensed tool from entering the estate? And on the protective side — if your code or designs walked out the door, what control would have prevented it, and what record would tell you it happened?
Why It Matters
License noncompliance is one of the few security failures with a guaranteed enforcement mechanism attached. Major software vendors operate audit programs as a revenue function — a true-up bill after a surprise audit can reach years of back-dated licensing plus penalties. Open-source noncompliance is quieter but sharper: a single copyleft dependency in a proprietary product can surface as a due-diligence finding that stalls a funding round or reprices an acquisition.
The protective direction matters just as much because for many organizations — software companies, consultancies, design firms — intellectual property is most of the company's value. Staff churn is normal, repositories are cloud-hosted, and copying is frictionless. Without deliberate controls on ownership and access, the question is not whether proprietary work leaks across boundaries, but whether anyone would notice.
Failure here typically shows up as:
- •Vendor audit true-ups – surprise license audits ending in back-dated fees, penalty multipliers, and forced enterprise-agreement upgrades
- •Copyleft exposure – a GPL or AGPL component inside a proprietary product creating source-disclosure obligations and derailing diligence
- •Trade secret loss – source code, designs, or pricing models leaving with departing staff because access and ownership were never nailed down
- •Client IP breach – reusing one client's deliverables, code, or data on another engagement, violating contract and destroying trust
- •Infringement liability – pirated or unlicensed software and content exposing the organization to legal claims and reputational damage
Regional Compliance Context
For India's IT services and GCC sector this control carries extra contractual weight: client master agreements almost always assign deliverable IP to the client and prohibit cross-pollination between engagements, so reusing code or artifacts across client projects is a contract breach even when it feels like efficiency. India's copyright law protects software as a literary work, and global vendors run active license audit programs in the Indian market — a delivery center is as auditable as a headquarters. Export-oriented development shops should also expect OSS license review as a standard item in customer and acquirer due diligence.
Implementation Guidance
Publish an IP and Licensing Policy People Actually See
Define the rules in a topic-specific policy or a clearly marked section of the acceptable use policy: only licensed software, defined acquisition channels, open-source usage rules, no unauthorized copying of protected material, and who owns work created on the job. Have personnel acknowledge it — the acknowledgment record is audit evidence under A.5.10 as well.
Tie License Records to the Asset Inventory
Extend the asset inventory from A.5.9 with license entitlements: product, edition, license count or metric, proof of purchase, renewal date, and an owner per major vendor. Software asset management (SAM) tooling helps at scale, but a disciplined spreadsheet reconciled on a schedule passes audits too.
Control How Software Enters the Estate
Route acquisition through a defined channel — an approved-software catalog, a procurement step that captures the license, restricted local-admin rights, and application allowlisting where the environment supports it. The goal is simple: nothing runs in the estate whose license nobody recorded.
Govern Open-Source Intake
Set an OSS policy by license class: permissive licenses pre-approved, weak copyleft reviewed, strong copyleft (GPL, AGPL) gated behind explicit approval for anything that ships or serves users. Run software composition analysis (SCA) in the build pipeline to keep a live dependency and license inventory, and maintain the attribution notices your licenses require.
Identify and Protect Your Own IP
List what the organization owns that is worth protecting — source code, designs, models, methodologies, content, client deliverables — and give each an owner and a classification under A.5.12. Protect it with repository access control (A.8.4 for source code), NDAs under A.6.6, and egress-conscious handling rules for anything leaving the organization.
Fix Ownership in Employment and Client Contracts
Ensure employment and contractor agreements assign work-product IP to the organization before any work starts — retrofitting ownership after a dispute is expensive and uncertain. On the client side, make deliverable ownership, license-back rights, and reuse rights explicit, and check them before any code or artifact is reused across engagements.
Reconcile Periodically and Prepare for Audits
Reconcile installed software against entitlements on a fixed cadence — quarterly or semiannually is typical — and record the result, including remediations. Define how a vendor license audit or an infringement claim (in either direction) would be handled and who responds. The reconciliation trail is what turns this control from policy into evidence.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.32:
Documentation
- IP and licensing policy (or acceptable use section) with personnel acknowledgment records
- Software and license inventory linked to the asset register, with entitlement details and owners
- License reconciliation records showing installed-versus-entitled comparisons and remediation actions
- Open-source policy plus a current dependency/license inventory or SCA report
- IP assignment clauses in employment and contractor agreement templates, and deliverable-ownership clauses in client contracts
Interviews
- IT asset or SAM owner on how licenses are recorded, reconciled, and trued up
- Engineering lead on how open-source dependencies are approved, scanned, and attributed
- Legal or procurement on IP assignment in employment contracts and ownership terms in client agreements
Observations
- A live reconciliation: installed-software report for a sample of endpoints or servers set against license entitlements
- SCA or dependency-scan output in the build pipeline, including how a disallowed license would be flagged
- Software installation restrictions on a sample endpoint — approved catalog, blocked local admin, or allowlisting in effect
Practitioner Insights
The pattern I see most in smaller companies is licensing drift, not piracy: a single-user design tool shared by a team, a "free for personal use" utility quietly doing commercial work, a SaaS seat count that stopped matching headcount a year ago. Nobody decided to infringe — the estate just grew faster than the records. The fix is unglamorous: one acquisition channel, one inventory, and a quarterly reconciliation someone actually owns. Auditors do not expect perfection; they expect you to be able to explain the difference between what is installed and what is licensed.
Open source is where this control gets expensive, and it is usually discovered by outsiders. The organizations that struggle are the ones where IP is treated as a legal-department topic while engineering ships AGPL components into a proprietary SaaS — two functions, each assuming the other has it covered. Certification auditors increasingly ask for the dependency inventory, and acquirers always do. If you cannot produce a license-aware list of what is inside your product, you do not control this risk, whatever the policy says.
Common Challenges & Solutions
Challenge
SaaS sprawl and shadow IT mean nobody knows what software the organization is actually using, let alone its license terms.
Solution
Discover before you control: pull the application list from SSO logs, expense reports, and endpoint inventories, then triage it into approved, tolerated, and retired. Publish the approved catalog, route new requests through one channel, and review discoveries monthly. Visibility converts an unbounded legal exposure into a managed list.
Challenge
Developers add open-source dependencies daily, and manual license review cannot keep up.
Solution
Automate the gate: run SCA in the CI pipeline with a license policy — permissive licenses pass silently, copyleft and unknown licenses block the build or open a review ticket. Keep the human review for the small minority that needs judgment. Developers tolerate a fast automated gate far better than a slow manual one.
Challenge
Complex commercial license metrics — per-core, virtualization, indirect access — get broken by routine infrastructure changes.
Solution
Record the metric details at procurement, not just the product name, and assign a license owner for each major vendor. Add a license-impact check to the change process for virtualization, cloud migration, and integration projects, since these are the changes that silently multiply liability. For the largest agreements, a specialist review before renewal usually pays for itself.
Challenge
Code written by contractors or freelancers has ambiguous ownership because agreements were silent on IP.
Solution
Make IP assignment a precondition: no repository access until a signed agreement assigns work product to the organization. Have contractors work in organization-controlled accounts and repositories rather than personal ones, and verify at offboarding that nothing lives outside them. For past gaps, have counsel execute confirmatory assignments before the code becomes load-bearing.
Challenge
Delivery teams reuse code and artifacts across client engagements without checking who owns what.
Solution
Separate client-owned IP from firm-owned IP structurally: distinct repositories or projects per client, labeled under your classification scheme, with reuse requiring a documented check of the contract's ownership and license-back clauses. Train delivery leads on the distinction between reusable firm methodology and client-owned deliverables — the line is contractual, not intuitive.
