ISO 27001 A.5.32: Protect Intellectual Property Rights

What A.5.32 requires in practice

Control A.5.32 asks the organisation to put suitable procedures in place so that intellectual property rights are protected. This covers both sides: respecting the rights of others, for example by using software and content within licence terms, and protecting what the organisation itself owns or has been entrusted with.

In practice the control looks at how software and other licensed material are acquired and tracked, how use is kept within what was bought, and how staff are guided on copying and using third-party content. It also looks at how your own and clients' intellectual property, such as designs, code or documents, is protected. The standard leaves the procedures to the organisation. A simple record of licences against actual use is one practical method, not a stated requirement.

Identify material whose rights affect its use

Look beyond installed commercial software. Source code, datasets, drawings, publications, images and training materials can carry permissions or restrictions relevant to the organisation. The exact rights depend on ownership, agreements and applicable law, so avoid broad assumptions based on a material’s format or where it was found.

Connect relevant assets with their source and permitted use. A purchase receipt may prove acquisition without describing all licence conditions. Retain access to the applicable terms and identify who can resolve questions. Where permission is unclear, use an authorised review route before incorporating the material into a consequential deliverable.

Protect the organisation’s own material as well. Determine which information is proprietary, who may disclose it and what terms govern work created with employees, contractors or partners. The security process should support these decisions without assuming ownership merely because the organisation paid an invoice.

Make acquisition and reuse decisions deliberate

Use trusted acquisition routes and verify that the intended use fits the permission obtained. A tool approved for individual use may be deployed differently across a shared service or customer environment. A licence valid during development may not automatically answer questions about redistribution in a product.

Changes in use can require reassessment. More users, a different hosting arrangement or a new customer-facing function may alter the relevant terms. Connect procurement, technical deployment and business owners so that the actual use remains visible rather than relying on an old approval detached from the current environment.

Why protecting intellectual property matters to the business

Using software or content outside its licence invites claims, penalties and awkward conversations with vendors. Losing your own design, code or know-how to a former employee or careless sharing can erode the advantage you built. Clients also entrust their intellectual property to service providers and expect it to be handled with care. Procedures that make rights visible and use controlled lower these risks and make due diligence by customers and investors smoother. For an auditor, it is a practical test of whether policy reaches everyday behaviour on desktops and project teams.

How to implement A.5.32

Begin with what you use and what you hold, then set simple rules. A practical order is below. Most intellectual property issues arise from everyday convenience, such as a copied tool, an unlicensed font or a shared project file. Start where the risk is highest, which is usually software licences and client materials. Keep rules short and practical, and explain the reason so staff do not see them as bureaucracy. Ask project teams to flag any client or third-party material they receive, so its conditions of use are known from the start.

1. Identify the licensed software, content and services in use.
2. Record the terms that limit how each may be used.
3. Compare actual use with those terms and correct gaps.
4. Set rules on acquiring and installing software and on copying third-party material.
5. Identify the intellectual property you own or hold for clients and where it lives.
6. Protect it through access limits, agreements and handling rules.
7. Brief staff and review the position when tools or projects change.

Illustrative software example: an included component changes the product

Illustrative manufacturing example: supplier drawings in a sales pack

A hypothetical manufacturer receives detailed supplier drawings for installation and maintenance. A sales team proposes using them in promotional material because they are already available on the internal network. The original purpose of access does not answer the proposed publication question.

The drawing owner checks the applicable permission and obtains an authorised decision before release. Where necessary, the business creates its own suitable illustration or requests permission. Access controls and staff guidance then distinguish internal operational use from external distribution, preventing convenience from becoming an unsupported rights assumption.

Check actual use against evidence of permission

Manage transfer, retirement and exceptions

When software or information is transferred, retired or reused elsewhere, consider whether the original permission still applies. Disposal of a device may require attention to software and stored proprietary information as well as the hardware itself. Keep relevant evidence for as long as the organisation needs to demonstrate its rights and obligations.

Uncertain or nonconforming use should be investigated and resolved through an authorised process. Avoid silently deleting evidence of the issue or assuming that a later purchase automatically resolves every earlier question. Appropriate legal or commercial advice may be required for material concerns.

Evidence and common mistakes