Software Audit Code of Conduct V1.0

Creative Commons License
Campaign for Clear Licensing Audit Code of Conduct V1.0 by CCL is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Based on a work at

Preface – Current Market Observations

  • Many software publishers choose not to implement controls, through technology, that would restrict the use of software that is not properly licensed – preferring an approach that enables flexibility and openness to customers developing solutions using either their own technology or manual controls.
  • Historically, software management controls have been two steps behind license program changes. Software is typically poorly labelled by the publishers and customers are not provided sufficient tools or guidance to accurately assess and/or proactively manage their consumption, nor are they provided clarity regarding changes to licensing programs.
  • Historically customers have been either poor at building controls around the deployment and use of software in their estates or have found difficulty in managing their software audit functions.
  • Customers, especially when downloading software,  accept terms to contracts that they do not clearly understand either through choice or ignorance.
  • Software publishers have the ability to use the lack of clarity over software, licensing and audit rights to their advantage during sales processes, contract negotiations or other points throughout a contractual arrangement, resulting in general market dissatisfaction and distrust.


Software publishers primarily audit their customers to examine if software is being used within agreed terms.

This code of conduct defines a set of acceptable practices for behaviour during such audits and covers types of audit, defining scope, the introduction of third parties, agreeing objectives and discussing results and outcomes.

Guiding principles:

  • Software publishers have the right to protect their intellectual property.
  • Software  publishers have the right to exercise clauses in the agreements and contracts established between themselves and their customers.
  • Software publishers and customers have both a responsibility and an obligation to adhere to clauses in the agreements and contracts established between themselves.
  • Customers have the right to deny audit requests that are not the result of contractual obligations or evidence based breaches of intellectual property.
  •  Both parties have the right to professionalism, complete transparency, clarity and openness throughout the audit process.

For customers: If you can’t manage it, don’t use it. For software publishers: If you can’t demonstrate how to manage it with everyday tools and techniques, don’t sell it

Terminology and Types of Audit

Any audit activity should state the type of audit as outlined in the table below:



  1. Voluntary audits and reviews may be incorrectly associated with, or labelled as, formal audits.
  2. Pre-sales led audits and voluntary reviews can be a positive experience to benchmark an environment. They must not be used inappropriately to benefit the sales or new business process, e.g. threaten legal recourse.

Audit Engagement

All audit communications should be routed through the formal communication/notification procedures defined within an agreement or, if such procedures are not defined, then through normal account management channels with appropriate escalation as appropriate.

Initial audit communications should cite:

  1. The main point of contact at both the publisher and the customer.
  2. Nature/type of audit as mentioned in the table above.
  3. Grounds for the audit including supporting evidence.
  4. Contract, Agreement or other unique identifier under which the audit is being activated.
  5. Audit scope in terms of products, geographies, companies, environments, device types, etc.
  6. Target dates for the audit to be conducted, results to be collated and published.
  7. Resolution process to be followed in the event of irreconcilable differences.
  8. Escalation channels within both the publisher’s and the customer’s organisations.


Agreed Measurement Criteria

The software publisher shall publish clear guidance on what constitutes:

  • proof of install for all titles in scope;
  • proof of entitlement for all titles in scope; and
  • any changes to the agreed licencing terms and condition between the publisher and the customer  in the “rights to use” for the software included in the audit scope.

Data and Working with Third Parties

Third parties (companies involved in the audit but not the customer or software publisher) should declare any, and all, commercial interests (either customer side or vendor side) before audit work commences.

Commercial interests may include:

  • Profiting (directly or indirectly) from the outcome
  • Compensation for the audit work undertaken
  • Relationships or commercial interests outside the audit work
  • How, when and between which parties the data relevant to the audit will be shared.
  • Agreements should be established between the third parties, the publisher and the customer, especially where the third party may also be the external auditing firm of the customer, to ensure that any data exchanged as part of the audit is only for use as part of the audit and may not be used by any of the parties for any other purposes.


Unless defined within the agreement or contract between the publisher and the customer, both parties will agree on a date by when the audit will commence and complete.

If any install inspections are to be conducted by the software publisher or their nominated third party, then the processes and timing to complete such information capture are to be agreed by all parties.

  • Voluntary Audit: At client discretion
  • Contractual Audit: Minimum 60 day notice prior to commencement unless otherwise agreed
  • Legal Audit: According to local jurisdiction

In any event, all parties agree that any audit related work will not impact any business processes.

Onsite Inspections and Operational Details

The third party conducting the audit on behalf of the software publisher is to liaise with the customer to confirm the operational aspects of the audit. This might include (but is not exclusive to):

  • arrangement of a client chaperone to escort the auditors about the client’s premises;
  • duration of time permitted on site(s);
  • access to hardware systems;
  • access to audit software installations and usage.

All information captured or created as a result of the audit is to be classed as commercial-in-confidence and not relayed beyond the software publisher, the third party and the customer, without the express permission of all parties.  This includes the third party not relaying any information to other parts of its own organisation.

100% disclosure between the software publisher and the customer is essential, so that both parties understand what data is being used to derive the results of the audit.  Therefore, if a third party does conduct any on-site data capture on behalf of a software publisher, then such data capture must also be copied to the customer.

Audit Results

Audit results / closure / recommendations

The software publisher will provide the customer with a full set of the findings from the audit, including details of:

  • all known licence entitlements;
  • all software installed and in use;
  • all licence positions for all products;
  • all spare licence entitlements that were not required to licence software installed and/or in use
  • all shortfalls in licence entitlements for software installed and/or in use;
  • all calculations of any potential licence fees owed for shortfalls in licence entitlements, including how such figures were arrived at. Summary figures are not fit for purpose as they fail to account for a comparison to existing market prices, or pre-arranged contract prices that might be in force but forgotten about.

Note: Detailed transparency regarding shortfalls can also help the customer with root cause analysis – preventing such short falls in the future, benefiting all parties.

Dispute resolution

Both the software publisher and the customer reserve the right to dispute the figures arrived at and, if the differences cannot be resolved between the parties, take recourse via mediation with the CCL, arbitration with an agreed arbitrator to be agreed and appointed by both sides, and/or legal proceedings. It is important that an escalation route exists in the event of any dispute arising over the outcome of the audit and any fees felt due.

The auditor / publisher or third party should explain any discrepancies, the likely root causes of such discrepancies and what steps the customer might take and best practices they can reference to prevent the same issues happening again in the future. Audit results and recommendations should be delivered in plain English with minimal technical or licensing jargon so that the key messages can be understood and acted upon by the customer across their organisation.

The Campaign for Clear Licensing will consider all complaints against organizations that have not followed the code with a view to stamping out unprofessional behaviour and raising standards. Contact us in confidence to discuss breaches of this code.

 Version History


With thanks to:

Creative Commons License
Campaign for Clear Licensing Audit Code of Conduct V1.0 by CCL is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Based on a work at

6 thoughts on “Software Audit Code of Conduct V1.0”

  1. I think that all paper work should be on the table before the engagement starts. We have had KPMG here doing an IBM Audit. They were unwilling to disclose our purchase history until we have provided all mesurement data to them.

    I also think think that the software publishers should take the entire software life cycle seriously. Example: Microsoft is terrible to deal with when it comes to software transfers. In a large corporation, license transfers are inevitable. In my case it has taken over two years to transfer licenses and to get all the supporting documents/contracts back from Microsoft. Transfering 2.000 Office licenses that constitutes a value of over 1M USD is a majot transaction. The only supporting eveidence (or receipt) I got back from Microsoft was a scanned copy of a faxed document, in the year of 2014.
    On top of this, they do not bother to update their MLS.

    1. Great comments. This could be added to code of conduct expected from publishers and their audit partners – specially around software transfers

  2. Great document Martin. It establishes minimal expectation and code of conduct for all parties. Now the challenge is to get this disseminated and supported by customers and major vendors. We are here to help.

Leave a Reply

Your email address will not be published.