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.

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:

• Change in spend, including a reduction in volume needed at renewal, moving support to a third party or contract termination
• Changing licensing model by the vendor
• Mergers, acquisitions or divestitures
• Historical proof of entitlement (PoE) requests
• Periodic audits usually aligned to renewal dates
• Unhappy employees notifying the vendor of compliance issues

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.

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.

• Do not uninstall vendor applications, unless the device is being decommissioned.
• Limit the deployment of new installations.

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.

• Legal: Legal should be able to help with the validity of the audit. If the audit isn’t valid for any reason, this can be challenged, and if agreed with the vendor, the audit can be cancelled and a closure letter issued. Your legal team should answer questions such as:
  • Does the vendor agreement contain the audit clause?
  • Is the vendor auditing the most recent contract?
  • Customized clauses in the contracts?
  • Is there a conflict of interest with third-party auditors?
• Commercial team: Commercial may wish to stop or restrict all activity with the vendor whilst the audit is active. They may decide to delay future renewals until the outcome of the audit is known.
• Application owners, IT, IT risk management: What are the goals and IT strategy for this vendor? Is there a drive to find an alternative solution to better support business objectives or is the application critical to operations? The audit can be used to accelerate these business decisions.

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.

• Nobody else speaks to the vendor and/or auditor (except urgent support calls).
• Vendor sales reps may ask for information. Do not send anything. Your only contractual obligation is to comply with a formal audit notification.

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.

• Vendor license portals
• Accounts payable records
• Purchase-to-pay systems
• Project records
• Users and/or system owners

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:

• Full packaged product including media
• Electronic software distribution licenses (license keys/files)
• Contract documentation (agreements, invoices and receipts)
• Email from the company that sold the software containing product and quantity information
• Volume licensing reports (reports based on records that resellers provide to the vendor and can be 45 days out of date).

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:

• Don’t share reports containing inaccurate data as this can lead to miscommunication and uninformed decisions being made. Be transparent about the level of data accuracy and completeness within your ITAM tools and processes. Raise with the audit board the known risks and issues for resolution.
• Enforce quality and controls to any data feeds and understand their limitations that can be used to support the audit. This will strengthen trust in any reports produced.

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:

• “We are in the middle of an IT roll-out.”
• “We’ll need to wait for legal department feedback.”
• “This is the 3rd/4th audit this quarter.”
• “Before meeting, we would like our NDA to be signed.”
• “The person responsible is not available due to…”

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

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:

• Confirmation of the products that are subject to the audit
• Provision(s) that the vendor/auditor believes entitles them to undertake the audit

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.

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:

• Device name
• Device hardware details (manufacturer, model, processor, cores, etc.)
• Device type (physical or virtual)
• Operating system
• Application details (including edition, version, etc.)
• Environment
• User

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.

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.

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.