What A.5.32 asks for and why software licensing is the test
A.5.32 asks the organization to implement appropriate procedures to protect intellectual property rights, both its own and those of third parties it relies on. For an auditor, that means a documented, operating set of procedures that show how IP risk is identified, assigned and checked, not one technical setting. The control carries forward control A.18.1.2 from the 2013 edition, so organizations already certified to that version will find the same core expectation, now written with the 2022 attributes and purpose. ISO/IEC 27002:2022 gives implementation guidance for the control, and it is the right reference for designing the procedures, though your auditor will test against the procedures you actually run.
Software licensing is the area auditors test most often because it is where unlicensed or misused third-party software creates both legal exposure and security exposure. Unmanaged installations can breach license terms, and software used outside its permitted scope, such as a non-commercial edition in a production environment, can be an IP violation discovered during a dispute or a vendor audit. Restricted tools also tend to be the ones that are never patched or inventoried. NIST's crosswalk from SP 800-53 Rev. 5 relates A.5.32 to CM-10 Software Usage Restrictions, which is a useful reminder that auditors read this control alongside usage restrictions and software inventory.
What makes A.5.32 hard is that intellectual property is a wide subject, but the records that prove license compliance are scattered. Purchase orders and license agreements sit with procurement, subscription terms and open-source choices sit with engineering, and what is actually installed sits on endpoints and servers. Start by agreeing one owner for the software license register and one procedure that reconciles it against installed software. Then confirm with your certification body how it expects you to show that the procedure runs, and which related controls, such as A.5.9 on inventory and A.8.19 on software installation, it will sample alongside A.5.32.
Which assets, software and contracts are in scope for A.5.32
A.5.32 covers intellectual property the organization owns and intellectual property it uses from others. The practical scope is set by what the organization holds, installs, licenses and builds, so the boundary is drawn from the asset inventory and the contracts behind each item.
The organization's own IP
Source code, technical documentation, product designs, trade secrets and brand material are the assets the organization owns and must protect. Scope them by repository, document store and marketing archive, and record who owns each one. Check whether employment and contractor agreements transfer rights to the organization, since ownership gaps are the most common issue here. Confirm the owner of every repository before setting its scope.
Third-party software on endpoints and servers
Commercial and freeware applications installed on laptops, workstations and servers each carry a license with its own terms on number of installations, users and permitted use. Scope the full installed base, not only the purchased seats, because auditors compare installation records with entitlements. Include software installed by users without central approval, since those installations are where unlicensed use usually appears.
Open-source components and their license terms
Open-source libraries and containers used in products or internal systems are third-party IP with obligations attached to each license, such as attribution, source disclosure or restrictions on distribution. Scope them through a software bill of materials for each product and record the SPDX license ID of every component. Components pulled in indirectly through dependencies belong in scope too.
Licensed content and vendor data
Stock images, fonts, reference datasets, market data, published standards and vendor-supplied training or reference material are used under license and often limit redistribution or use outside named purposes. List each licensed content set with its licensor, permitted uses and renewal date. Confirm whether licenses cover contractors and affiliates, since those parties often use the content in deliverables.
Contractor-produced IP
Code, designs and documents produced by contractors, agencies and offshore teams may not transfer to the organization unless the contract says so. Scope each engagement by its statement of work and check the assignment clause, the handover of source files and any retained tools or pre-existing materials. Work done before the contract was signed needs separate treatment.
Cloud and SaaS subscriptions
The asset inventory under A.5.9 sets the boundary: an item enters the A.5.32 scope once it is recorded there with an owner. Cloud and SaaS subscriptions are in scope because their terms govern seat counts, permitted users and use of data or generated content. Record each subscription, its licensed user count and the administrator who can change it, and confirm that the inventory is reconciled with billing records and identity directories.
How an assessor tests intellectual property procedures
This table sets out each test an assessor typically runs for A.5.32, the evidence requested for it and the findings that most often lead to nonconformities. Read it as a checklist: confirm that the procedure exists, that installed software matches licenses, that open-source licenses are reviewed before adoption, that contracts carry IP terms and that staff know the rules. The main takeaway is that a written procedure alone rarely passes; assessors look for records that show it was followed.
| Test | Evidence requested | Common findings |
|---|---|---|
| Review the documented IP procedure | Approved procedure covering the organization's own IP and third-party IP, with owner, review date and scope | Procedure is generic, unsigned or does not name who handles license questions |
| Sample installed software against license entitlements | Software inventory export, matching purchase records, license keys or subscription terms, and the assessor's chosen sample of endpoints and servers | Installed software with no matching license record; more installations than entitlements |
| Check open-source license assessment before adoption | Request or approval records for new open-source components, license identified (for example by SPDX ID), and recorded decision | Open-source components adopted with no license review; copyleft licenses used in products without a recorded decision |
| Review contracts for IP clauses | Supplier and customer agreements showing ownership of deliverables, license grants, restrictions on reverse engineering and use of third-party content | Contracts silent on IP ownership of custom code; licenses that do not cover the way the software is actually used |
| Check staff awareness of permitted use | Acceptable use or software installation rules, acknowledgement records, and training attendance | Rules exist but staff were never told; no acknowledgement records for contractors |
| Check that the procedure is followed in practice | Tickets or change records for software requests, removal records for unlicensed software, and periodic compliance reviews | Procedures exist on paper but reviews are missing or overdue; findings not tracked to closure |
| Check the link to other controls | Evidence that the software inventory (A.5.9) and installation controls (A.8.19) feed the license check | License checks run from a list that does not reflect what is installed on systems |
How to implement A.5.32 step by step
This sequence turns intellectual property protection into evidence an auditor can sample: a named policy and owners, a software inventory tied to the A.5.9 asset register, reconciled entitlements, a review gate for new components, recorded contract terms and a scheduled reconciliation cycle.
Define the IP and license policy and owners
Start by writing a short policy that covers the organization's own intellectual property and the third-party software, open-source components, fonts, media and datasets it uses. Name an accountable owner for software licensing, typically in IT or procurement with legal input, and name asset owners who confirm entitlements for their systems. Record the policy's approval, the owners' acceptance and the review date. The output an auditor will ask for is the approved policy, the owner register and evidence that the owners know their duties. Confirm with your legal counsel which obligations in your contracts and jurisdictions must appear in the policy.
Build the software inventory from the asset register
Use the inventory of information and associated assets under A.5.9 as the base, then add every installed software product, version, license type and the system it runs on. Automated discovery helps here: GLPI's Assets module can record software manually or through the GLPI Agent, and Wazuh's Syscollector collects installed software from each endpoint. Cross-check discovered records against the asset register so that each software item links to an owner and a host. The output is a software inventory an auditor can sample against the running estate. Keep the discovery export dated so the sample can be traced to a point in time.
Reconcile installed software against entitlements
Compare each inventory entry with the proof that the organization is allowed to use it: purchase orders, subscriptions, enterprise agreements, volume licenses, open-source license texts and cloud marketplace terms. Record the entitled quantity, the installed count and the gap, then decide whether to uninstall, buy more, or document an exception with its owner's approval. Where the software is open source, record the license identifier and check that the intended use, such as distribution or network use, fits the license obligations. The output is a signed reconciliation report with each gap assigned to an owner and a closure date. Ask the vendor or your license manager to confirm the license metric for each product before you rely on it.
Set a review gate for new components
Add a checkpoint to procurement, software onboarding and the development pipeline so that no new commercial product or open-source component enters production without a license review. The reviewer confirms the license, its compatibility with planned use, and any restrictions on modification or redistribution. For application dependencies, generate a CycloneDX software bill of materials with Trivy or a similar tool and load it into OWASP Dependency-Track, which tracks license use by component using SPDX license IDs and flags license risk. The output is a recorded approval linked to the ticket or change request, plus the SBOM for the release. Ask the tool provider to confirm the license detection coverage for your languages before you depend on its alerts.
Record intellectual property terms in contracts
Review the contracts that carry intellectual property obligations, including customer and supplier agreements, development contracts, licenses for data and content, and terms that assign ownership of work product. Record who owns what, which rights the organization has granted or received, restrictions on use and the obligations that survive termination. Store the summary with the contract reference so that it can be found during an audit. The output is a contract register with IP terms and the owner responsible for each. Route any clause that conflicts with the policy to legal counsel before signature, and confirm the applicable requirements through the A.5.31 legal register.
Schedule periodic reconciliation and act on findings
Set a recurring reconciliation cycle, with its frequency fixed in the policy, that repeats the inventory discovery, the entitlement check and the component review. Track each finding through to closure, and feed repeated problems into the procurement or deployment controls so the gap does not reappear. Management should review the results, and an internal reviewer outside the team that manages the software should test the process periodically. The output is a dated history of reconciliations, findings and closures that shows the control operates over time. Confirm with your auditor how many cycles they expect to see before they test operating effectiveness.
How software license reconciliation produces evidence
Software license reconciliation produces evidence for A.5.32 by comparing three lists that are rarely the same: what is installed on systems, what the organization is licensed to run, and what is actually used. Discovery tooling is central because the installed list is the only one a machine can produce reliably. Purchase records and contracts describe entitlements on paper, and user habits are seldom written down. An auditor testing this control will usually ask for the discovered inventory first, then for the entitlement records, then for the differences between them.
In practice, the discovered inventory comes from agents or scans on endpoints and servers. GLPI can hold software records entered manually or pushed by the GLPI Agent, and Wazuh's Syscollector collects installed software from each endpoint into its indexer for reporting. Where software enters through containers or build pipelines, a scanner such as Trivy can list packages and dependencies so that they are not missed. Dependency-Track can then match components to license identifiers using SPDX license IDs, which helps when open-source components carry obligations of their own. Confirm with each tool's documentation which fields it populates for license and entitlement data and whether it can record a named owner per product.
Every mismatch needs a recorded decision: an installation with no matching entitlement, an entitlement with no installation, or an installation that is used by fewer people than the license allows. Each exception should have an owner, a reason, a deadline and a closing action, such as uninstalling the software, buying the entitlement, or documenting a valid exemption under the license terms. Keep the reconciliation dated and retain the exception log, because an auditor will sample closed items as well as open ones. Ask the organization's legal or procurement function to confirm which license terms count as valid evidence of entitlement, since the answer varies by vendor and contract.
Evidence that passes an A.5.32 audit
An auditor testing A.5.32 looks for a working intellectual property procedure and proof that it is followed in practice. The cards below cover the artifacts that usually carry that proof, from the procedure itself to the reconciliation reports that show licenses still match what runs. Each one needs an owner and a refresh routine, because stale records fail as quickly as missing ones.
Intellectual property and license procedure
This is the documented procedure that sets out how the organization protects its own intellectual property and how it uses third-party software and content. It should name who approves new software, who holds license entitlements, how open-source components are reviewed, and what happens when a license is breached. Auditors check that the procedure matches what staff actually do. Review it at a set interval and after any change in licensing models, such as a move to subscriptions or to a new cloud marketplace.
Software inventory with named owners
A software inventory lists each installed product, its version, the device or service it runs on, and the business owner accountable for it. Without owners, nobody can answer a license question. GLPI's Assets module can hold software records and receive automatic inventory from the GLPI Agent, while Wazuh's Syscollector reports installed software from endpoints. Confirm that the two sources agree, and sample a handful of entries against live machines before the audit.
License entitlement records
Entitlement records show what the organization is allowed to run: license type, quantity, term, permitted use and the agreement it comes from. Store the purchase terms and vendor agreements alongside the counts so an auditor can compare installed copies against purchased rights. Renewals and true-up dates belong in the same record. Update entitlements when a contract changes, not only at the annual review, because a lapsed term is a common source of findings.
Open-source license review records
Each open-source component pulled into a product or internal system needs a recorded license review. The record should state the SPDX license identifier, the obligations it creates (attribution, source offers, copyleft scope) and the approver. OWASP Dependency-Track tracks license use by component using SPDX identifiers and flags license risk, and it can ingest CycloneDX SBOMs produced by Trivy. Keep the review dated so that changes in a dependency's license are caught in the next cycle.
Contract clauses on IP ownership and use
Contracts with developers, contractors, suppliers and customers should state who owns the code, data and deliverables, what licenses are granted, and what restrictions apply on reuse. Auditors sample these clauses against the vendors and staff in the inventory. Keep a register that links each material contract to its IP terms and its renewal date. Legal counsel should confirm wording, since DeployOpen does not provide legal advice.
Exception, remediation and reconciliation logs
Exception logs record each unlicensed, expired or non-compliant install, the decision taken, its owner and its closure date. Periodic reconciliation reports compare entitlements with installed software and show the variance and the actions for each gap. Retain both, with the dates, so that the auditor can see that findings were tracked to closure rather than hidden. Set a fixed reconciliation interval and record who signed off each run.
What meeting A.5.32 costs in money and effort
This table breaks down the cost and effort components of meeting A.5.32 Intellectual property rights, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are given because none are supplied for this control, so use the table to structure your own estimate and quote requests.
| Cost component | Who is paid or who spends effort | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Software license purchases | Software vendors, through the organization's procurement budget | Recurring (subscriptions, maintenance, renewals) | Number of proprietary products and seats; audit of entitlements; consolidating vendors; open-source alternatives where fit allows |
| Discovery and inventory tooling | Tool vendors, or the team that deploys and runs open-source agents | Mostly one-time setup, then recurring operation | Number of endpoints and servers; whether discovery is agent-based or manual; reuse of an existing asset inventory |
| Engineering time for license reconciliation | Internal IT or platform staff, or an implementation partner under a fixed-scope agreement | One-time baseline, recurring reconciliation | Quality of the asset inventory; how many license models are in use; whether usage data is exported automatically |
| Legal review of contract and license terms | Internal counsel or external law firms | One-time for the baseline, recurring at renewals and new purchases | Volume of contracts; non-standard terms; whether a license register exists to guide review |
| Auditor sampling and evidence requests | The independent auditor's fees, plus staff time to answer sampling requests | Recurring at each audit cycle | How many samples the auditor selects; whether evidence is retrieved from a system or assembled by hand |
| Policy and procedure upkeep | Internal compliance or security staff | Recurring, usually at review intervals and after major changes | Frequency of review; how many topic-specific policies reference IP and licensing; changes in the software estate |
| Remediation of license gaps | Internal teams, software vendors, or both | One-time per gap, with potential recurring true-up costs | Number of unlicensed or excess installations found; speed of response; decommissioning versus purchasing |
| Retaining evidence of ownership and third-party rights | Internal records owners and contract managers | Recurring | Size of the contract repository; whether licenses and agreements are linked to asset records |
Who does what for A.5.32: your team, a partner and the auditor
Your organization owns A.5.32. The control asks you to implement appropriate procedures to protect intellectual property rights, and that means deciding what the rules are. Your legal, procurement and security leaders set the position on which licenses the business may use, how open-source components are approved, what happens when a license is breached, and which contract terms protect your own code, data and brand. Those decisions cannot be delegated to a partner or an auditor, because they are the substance of the control.
- Policy and procedure: Approve the procedure for protecting your own intellectual property and for respecting third-party rights, and name an owner for it.
- License decisions: Decide which license types are acceptable for each product line, and who can approve exceptions.
- Contract terms: Set the software licensing, reuse and ownership clauses that suppliers and contractors must accept.
- Review and sign-off: Review inventory reconciliations and exception records, and record the decisions behind them.
- Ownership of answers: Answer auditor questions about what the rules are and why they were chosen.
Before the audit, confirm that each decision is written down, dated and traceable to a named role.
An implementation partner can do the technical and operational work that makes A.5.32 provable. A partner such as DeployOpen can deploy software inventory tooling inside your own infrastructure, reconcile what is installed against what is licensed, and assemble evidence packs for the auditor to sample. The partner works to your written scope and does not decide your license positions. It also does not issue any report or certificate, and it should not be the party that tests the same controls it prepared.
- Inventory tooling: Deploy and configure asset and software inventory platforms in your environment, such as GLPI or Wazuh, with the data kept on your systems.
- Software bill of materials: Generate and analyze SBOMs for applications and images, for example with Trivy and Dependency-Track, to show which components and licenses are in use.
- Reconciliation: Compare installed software and entitlements, and list gaps for your owners to resolve.
- Evidence packs: Collect dated exports, configuration records and reconciliation logs, mapped to A.5.32 and linked to A.5.9 and A.8.19.
- Knowledge transfer: Document the procedures so your staff can run the tooling after handover.
Confirm in writing which of these tasks are in the scope, who keeps the credentials and who owns the outputs after the engagement ends.
The auditor is independent. An accredited certification body or the auditor you engage tests whether A.5.32 is implemented and operating, and it decides whether the evidence is sufficient. It does not write your policy, configure your inventory tools or assemble the evidence it will test. Where a partner prepared the evidence, the auditor's job is to check that the evidence is complete, accurate and traceable to the systems it came from. Only an independent auditor or certification body issues a report or certificate.
- Sampling: Select software and license records from the inventory and check them against actual installations or entitlements.
- Evidence testing: Confirm that exports and reconciliations come from the stated system, at the stated time, without gaps.
- Interviews: Ask owners how the procedure works in practice and how exceptions are handled.
- Findings: Record nonconformities where the procedure is missing, not followed or not reviewed.
- Independence: Decline to design the evidence it later tests, and disclose any conflict of interest.
Before engaging an auditor, check its accreditation and ask how it separates advisory work from certification work.
Common gaps that fail A.5.32 and how to close them
Most A.5.32 findings come from licensing and intellectual property records that exist but are not owned, complete or reviewed. The cards below cover the gaps assessors find most often, each with a closing action the organization can evidence. Treat them as a checklist for the internal audit before the certification body arrives.
No owner for software licenses
Licenses are often bought by IT or procurement and then forgotten, so nobody can say who is accountable for compliance with the terms. Assessors look for a named owner for each license pool, with the authority to approve installs and reclaim unused seats. Assign one accountable owner per license pool and record the owner in the asset inventory, together with the procedure for approving new installations.
Inventory misses endpoints and subscriptions
A license register built from purchase invoices misses machines that were provisioned outside procurement, developer laptops and SaaS seats bought on corporate cards. An unreconciled gap means the organization cannot prove what it runs against what it owns. Compare the register with what the endpoint agent and cloud accounts report. Use GLPI to hold the license records and the Wazuh Syscollector inventory to reconcile installed software against them.
Open-source licenses never reviewed
Teams pull open-source components into products without checking their licenses, and copyleft or license-conflicting components can create obligations the business never accepted. Assessors ask for evidence that component licenses were identified and reviewed before release. Generate a CycloneDX SBOM for each product, load it into Dependency-Track, and set a review step for license risk and SPDX license IDs that flags anything outside the approved list.
Contractor IP missing from agreements
Work produced by contractors, agencies and offshore teams can leave the organization without clear ownership of the code, documents and designs. The gap usually sits in a statement of work that never mentions intellectual property or assignment. Check each active contractor agreement for an ownership clause, a license for third-party material and a return-of-materials obligation, and involve counsel to confirm the wording matches the local law.
Procedures never reviewed
An intellectual property or software usage procedure written at certification time and never touched again will drift from how teams actually work. Auditors check the review date, the approval record and evidence that the last review led to changes where needed. Set a review interval in the procedure itself, assign the reviewer, and keep the signed minutes or change log that show the review took place and what it found.
Unlinked legal requirements
Licensing and IP duties often sit in contracts and vendor terms that are not connected to the controls that enforce them. Without a link, an audit finds rules that nobody applies. Map each license term, contract obligation and applicable legal requirement to the procedure and owner responsible, and record that link in the register that A.5.31 requires.
Questions buyers ask about A.5.32 cost, effort and outsourcing
How much effort does A.5.32 Intellectual property rights take to meet?
The effort depends mostly on how many software products and licensed content sources the organization uses, and on whether anyone already keeps a current inventory of them. No researched figure sets a duration for this control, so ask any consultant or auditor for an effort estimate tied to your own inventory. The work has three parts: writing the procedure, building a complete record of licensed software and content, and checking that usage stays within the licence terms. The first part is a one-time task. The other two recur, because new software, new users and new hosts appear constantly. Most of the effort sits in the inventory, which is why A.5.9 matters so much here.
Can a small team run A.5.32 without a dedicated compliance role?
Yes, a small team can run A.5.32 if one named person owns the procedure and the software inventory is kept current. The control asks for appropriate procedures, not a large program. The practical load falls on whoever approves software purchases and installs, so the procedure should route those requests through a single point. A small team usually needs a short written procedure, a list of licensed products with their terms and owners, a periodic check that installed software matches the purchased entitlements, and a record of who approved each exception. Those tasks fit alongside normal IT work if the approval path is simple and enforced.
Do open-source tools remove software licensing costs for A.5.32?
Open-source tools reduce the cost of tracking licences, but they do not remove the need to comply with licence terms. Tools such as GLPI, Wazuh, OWASP Dependency-Track and Trivy are published under open-source licences, so using them does not add a product licence fee. Their value lies in producing evidence: GLPI can hold software records, Wazuh collects installed software from endpoints, Dependency-Track tracks license use by component using SPDX license IDs, and Trivy can generate a software bill of materials. Commercial software you run, including operating systems, databases and proprietary libraries, still carries its own licence obligations. Confirm each tool's licence terms with its vendor or project before you rely on it.
What does the organization have to provide to meet A.5.32?
The organization has to own the control. It must decide the procedure, approve it, assign owners and keep records that show the procedure runs. In practice that means providing:
Which parts of A.5.32 can an implementation partner take on?
An implementation partner can prepare the systems and evidence that support A.5.32, but it cannot own the control or decide what the organization licenses. DeployOpen plans, implements and configures self-hosted tools inside your environment, including inventory collection, software bill of materials generation and licence tracking in Dependency-Track. It can also document how the procedure is evidenced and prepare records for an assessment. What stays with the organization is the policy decision, the approval of exceptions, the contract review and the final sign-off. An independent auditor or certification body reviews the evidence and issues any certificate. Scope and deliverables are agreed in writing before work starts, so ask for them in writing.
How does A.5.32 differ from A.5.31 and A.5.9?
A.5.32 covers the procedures that protect intellectual property rights, both your own and those of others you use. A.5.31 covers identifying and meeting the legal, statutory, regulatory and contractual requirements that apply to information security, so it is the wider obligation register. A.5.9 covers the inventory of information and associated assets, including owners. A.5.32 depends on A.5.9 because you cannot show licence compliance without knowing which licensed software you run and where. A.5.31 supplies the licence terms and contract obligations that A.5.32 procedures enforce. In an assessment, the three controls share evidence, so a single well-kept inventory and register can support all of them.
What should I ask for in a quote for A.5.32 work?
Ask for a written scope that names each deliverable, the systems in scope and the evidence the work will produce. Request the list of assumptions, such as how many endpoints, applications and licensed products the inventory must cover, because those numbers drive the effort. Ask which activities are one-time, such as drafting the procedure and deploying tools, and which recur, such as reviews, inventory upkeep and tool upgrades. Confirm who performs each task, what the organization must supply, and how changes to scope are priced. Ask the auditor or certification body separately about its own fees, since its work is not part of an implementation quote.
How DeployOpen prepares A.5.32 evidence
DeployOpen helps organizations prepare the systems, records and evidence behind A.5.32 Intellectual property rights inside their own infrastructure. The organization keeps ownership of its controls and its licensing decisions, while DeployOpen plans, builds and documents the supporting tooling. Independent auditors and certification bodies, not DeployOpen, assess the result and issue any certificate.
How we scope
- Agree in writing which software estate, license records and open-source components the A.5.32 work covers.
- Confirm which owners, approvers and procedures the organization must provide before implementation starts.
- Define deliverables, timelines and responsibilities in a fixed-scope agreement before any work begins.
How we build
- Deploy inventory tooling such as GLPI and Wazuh in the client's own cloud, data center or air-gapped network.
- Configure software bill of materials collection and license tracking in OWASP Dependency-Track against the organization's components.
- Test that inventory and license data match a sample of real installed software before relying on it.
How we hand over
- Document the software licensing procedure, roles and review cycle in a form the organization can own and maintain.
- Hand over exported inventory, license and compliance reports that show how A.5.32 evidence is produced.
- Train the named owners to run the reports and explain the evidence to an external assessor.
How we support
- Offer ongoing support, upgrades and maintenance of the tooling as a retainer if the organization wants it.
- Update license mappings and procedures when new software, suppliers or licensing terms are introduced.
- Confirm with the organization's assessor which evidence they expect before the next review or audit.
