Snow Software has been acquired by Flexera. Learn More.

Software Audit Defense Principles and Ground Rules

This article aims to provide you with best practice advice on in-bound vendor audits, how to be prepared, who should be involved, what to do during the audit process.

Before you receive a notification of an audit from a vendor, it’s crucial to have effective hardware and software asset management processes in place to make sure that your license compliance positions are current and accurate. This will reduce the time required to prepare for an audit and reduce the risk of submitting inaccurate data as evidence which can lead to elevated audit settlement figures.

What triggers a software audit?

Software vendors audit because they have a legal right to do so and a duty to protect their technology from unauthorized use. Triggers for software audits include:

Be aware of information requests from vendors offering an assessment review. These are essentially an audit request and an attempt to covertly find you out of compliance. Do not send any data to the requestor, simply state your Information Security guidelines around not sending company confidential data to third parties. This is an ideal time to review your compliance for that software vendor and address known issues as it’s likely the vendor will issue a formal audit notification in the not-too-distant future.

Preparing your response to a vendor audit

The notification or request for audit can be a letter or email sent by the vendor or a third-party auditor to a contact within the organization. Usually this is the person within the organization who last signed the vendor contract or last known buyer of the product/renewal. Very rarely would the ITAM team be the recipient of an audit request.

Upon receiving the notification letter from the vendor or third-party auditor you should forward this to the ITAM team promptly. Do not ignore the audit request. This could result in the vendor restricting or terminating any current and/or future contracts.

Understand that at this point that you are effectively under audit and no changes should take place to the applications in question on the estate, unless the change is business-critical and there is a clear audit trail.

Assemble the audit board

Do not assume that your key stakeholders understand the audit process. Clearly define roles and responsibilities of management and other key stakeholders to support the audit. Potential key stakeholders are but not limited to finance, procurement IT service management, legal, IT risk management, IT security, SAM team and application owners.

Identify a single point of contact

Appoint a single point of contact (SPOC) with the auditor from that point on. The SPOC will control the information flow in order to make sure correct information is shared with the auditor.

Absolutely no other communication should take place whilst the audit is active.

Obtain proof of entitlement (PoE) documentation

Gather and review all license entitlements, contracts and agreements associated with the audit. The following sources should be able to assist if you do not already hold license entitlement documentation centrally.

You’ll need to understand any constraints with your entitlement agreements, such as: territory-based licensing, environmental restrictions, reassignment restrictions, license metrics and virtualization restrictions.

Only certain types of documentation can be deemed as proof of ownership and therefore considered official entitlement, which are:

The information from these sources above will also be used to create a draft effective license position (ELP) to identify any non-compliant applications and issues.

Data can be difficult to obtain if you don’t have a software asset management tool in place. At this point it’s not advised to contact the vendor or a reseller to request any license entitlement information. As this might raise concerns with the vendor and they may not negotiate the scope of the audit. Also, vendors’ entitlement information may be wrong, so be prepared to challenge it if necessary. Regarding internally produced reports:

Decision to delay

Normally, you should have 45 days’ written notice to engage with the auditor. This can be interpreted as 45 days between audit notification and the initial kick-off meeting. The auditor might ask for a meeting before that time has passed. There are multiple ways to delay this meeting. Actions which can pose delay before the audit starts:

There is no actual risk in delaying the audit, but you should not use this time to rectify any known compliance issues.

Responding to the vendor audit

First, issue receipt of the request for audit. This can be a formal letter or email to the auditor. This is also the time to notify the auditor who the single point of contact is and that they should not approach anyone else. Additional information can also be requested at this point, such as:

Obtain an NDA

An NDA often represents the only opportunity to put a fence around the scope of a software audit. Many software publishers and their hired auditors may refuse to consider comprehensive pre-audit agreements. However, most typically will agree to negotiate NDAs to control the handling of audit data. An audited business needs to make the most of that opportunity by ensuring that the data to be disclosed is relevant to the kinds of questions that the auditor is allowed to ask. Almost always it is a good idea to include appropriate, corresponding protective measures in the NDA to protect all parties involved.

Although completion of the NDA phase can take time, it’s advised not to proceed with the audit until this step is complete.

Define the scope and audit approach with the auditor

Clearly define the scope before starting the audit – what products, legal entities, geographies, etc. are covered under the audit.

Request the license entitlement documentation from the vendor to verify your internal data and agree on any limitations. Be transparent of any migration or hardware refresh projects that are in flight as this can adversely affect compliance but can be taken into account if communicated.

Request definitions of terminology and license metrics for what you are being audited against to avoid ambiguity when forming your draft ELP and understanding the audit results.

Agree on the audit approach to include next steps, timelines and evidence required.

Vendor audit required evidence

The auditor will discuss the required data and form of evidence. It’s important to be transparent if there is any data that you are not willing to share for business-sensitive reasons or if you know of difficulties obtaining certain data.

You should be able to obtain evidence from your software asset management tool. If none exists, you may be able to pull data from IT management systems such as System Center Configuration Manager (SCCM), vCenter, and Active Directory.

Normally, the data required includes:

The auditor may offer use of their scripts. It’s important that this approach is agreed by the audit board before progressing further. Don’t accept that the vendor tools are required to collate the data, you can challenge this and use SAM tools that you already have on your estate, as these should be sufficient.

Submitting audit evidence

Once all the required data has been obtained and understood, it can be prepared for submission to the auditor. E.g., sensitive information can be redacted from screenshots, device and usernames can be anonymized, etc.

If scripts or tools have been deployed, review and analyze the output. There are often mistakes as the scripts and tools are continuously being developed and contain limitations (e.g., discovery of out-of-scope devices and some license metrics are notoriously difficult to track).

Only submit the data that has been agreed and make sure that the audit board is happy with the data beforehand. You don’t want to submit any ‘commercial in confidence’ data to an auditor.

It’s important to be transparent and do not omit or manipulate any data, as this can have legal repercussions.

Due to the business sensitive nature of the data you will be submitting for audit evidence, you’ll need to discuss and agree on the best way to send the data to the auditor. Information security principles will apply specifically to data encryption standards.

Audit results

The auditor will require time to evaluate your submitted evidence against the vendor’s entitlement position. Once this is completed, the auditor will produce a reconciliation report. If a third party is conducting the audit, you may have an opportunity to view the report before it goes to the vendor.

When the vendor publishes the audit results, it’s crucial to never agree on the findings in the first instance. You’ll need to thoroughly validate the results against your draft ELP. Be prepared to challenge the results and make sure that the auditor is aware of any inaccurate data or assumptions that have been made.

The audit results can be amended and reissued by the vendor many times. Meticulously check each report for any vendor mistakes.

You may wish to seek a second option of the audit report, either with the assigned third-party auditor or one of your service providers/resellers. Only agree to the audit report once your due diligence is complete and the audit board is comfortable with the results.

Audit settlement

Often the audit settlement is a considerable amount, and you can negotiate this with the vendor. The audit results and settlement are to make sure that you are compliant after the audit is closed. You can negotiate to purchase additional licenses, support or contract renewals as part of the settlement and offset future costs.

Once the audit settlement figure has been agreed on by all parties, you can negotiate a waiver not to audit for 2-3 years. This would be beneficial for your priority vendors.