The vision of the Software Audit Defense Process is to account for the fact that software audits are steadily becoming unavoidable. The consequences of a poorly conducted software audit could mean significant and unbudgeted monetary loss, damage to the relationship with your software vendors, and potentially a tarnished reputation should the software audit result in legal action.
Therefore, it is necessary to be prepared for the event of a software audit. You must ensure that whatever software products are adopted are managed by your IT department to offer clear visibility into your use of the software, and license compliance. Being equipped to handle a software audit will ensure that if you are audited, you can minimize the time invested into the audit process (organizations who are not prepared can spend a year or longer defending an audit) and limit your financial exposure. These goals can be achieved through clear visibility of data, including effective software asset management and license optimization.
In many organisations, software audits are a reactive process, where disorganization and rushed responses leaves the data produced from such efforts to be lacking in both detail and accuracy. This allows the auditors to create artificially inflated compliance gaps, giving the appearance that the organization owes more than they actually do.
To avoid this fate, processes to prepare any company for a software audit should not be postponed until the software audit has arrived, but instead should be a continuous effort throughout the year. An effective Software Audit Defense process will provide you with the tools that are needed to prove how much you are legally obligated to pay the software vendors and no more.
The primary objectives that are to be addressed through the implementation of this framework include the following:
Knowing exactly what has been deployed within your environment has many benefits. Data will act as evidence in any upcoming audit and therefore it is in your best interest to know how that data will contribute to your licensing position. Data visibility will also benefit your efforts to cut software spending as it will allow you to track the value of software that has been deployed when compared to actual usage data.
An unknown expense throughout a software audit is the amount of time and resources that is required when your company is found unprepared. By preparing for a software audit, you can streamline any processes so as to minimize the wastage of company time and resources.
By having insight into your software profile, you can reduce any risk of incurring heavy penalties that you would otherwise have to burden should you be found out of compliance by the software auditors. These penalties are often outside the planned budget.
Software audits can leave an unpleasant strain between your company and your software vendors. By maintaining a proactive approach to software audits, you can work to preserve the relationship and help nurture it for more beneficial exchanges between both parties in the future.
Scoping and Planning
Data Collection
Entitlement Analysis
Verification & Testing
Reporting
Software audits are only increasing in their regularity. Having the best technology will not prevent you from eventually incurring an audit. There are many reasons why software audits occur.
Software audits are an excellent form of revenue for the publishers and they will often use software audits to compensate for any shortcomings in sales. If you have decreased your spending with a vendor in any way, therefore, you are at a heightened risk of receiving an audit.
Software audits are treated as investments by the software publishers. This is why software audits tend to be geared towards companies with highly complex profiles. Companies that have multiple branches, companies who have gone through mergers or acquisitions, or companies who have simply failed to demonstrate to their publishers the procedures they have in place to monitor their complex infrastructure will be at a heightened risk of an audit. The software publishers will view auditing such companies as a guaranteed return on investment since there’s a great likelihood that they are disorganized enough to be out of compliance.
Since software audits are viewed by the publishers mostly as a means for fiscal gain, even the most organized companies with mature Software Asset Management practices are still likely to receive an audit. Since even the best policies will not remove this risk completely, it is important to prepare for such an event, should one ever occur.
A non-voluntary process that you are contractually obligated to adhere to. It allows the software vendor’s auditing team, or a third-party auditor hired by the vendor to examine your network’s data for evidence of non-compliance. Should you be found with a compliance gap, you may be obligated to purchase any missing licenses at full price. Some software companies may also charge an additional penalty (5 to 10%) while others might instead expect you to pay for the process of the audit, including the compensation of the auditors, and others still may require you to do both.
An optional software compliance review that is run internally using your own resources or by a partner of the vendor. Usually under a SAM Review, if you are found to be out of compliance, you are able to purchase the new products at your contracted prices. Despite the fact that you are technically at liberty to refuse a SAM review, it is highly ill-advised since refusing to comply with a SAM review will likely result in incurring a full legal audit, which is non-voluntary and can result in steeper penalties.
A list of all the licenses you own, which is then compared with your deployment data (what is actually deployed on your systems or in use by your employees), to come up with an Estimated License Position.
Towards the end of the software audit, the auditors will create an Estimated License Position (ELP), this document compares all of your compiled deployment data to your License Statement. This number is not guaranteed to be correct, as it is only the auditor’s findings based on how they chose to interpret the data you gave them. The auditors could potentially be paid to find the largest compliance gap possible, so when given the opportunity to make an assumption, they will assume the most expensive case is the reality. Poor data means that your ELP will most likely be artificially inflated to look like you owe far more than you actually do. Proving an already created ELP wrong can be difficult.
A lump-sum payment that is paid to the publishers at the end of a specific period of time laid out in your contracts. At the end of a software audit, your true-up payment may be inflated to cover the costs of any missing licenses.
Any discrepancies found between licenses that you have purchased as opposed to software you are using. Compliance gaps are the number of licenses that are required to purchase to become compliant.
The initial method of contact from the software publisher will depend on which type of audit you have received, whether it is a full audit or its lighter equivalent, a License Review (the exact name of these reviews varies from software vendor to software vendor). In the event of a full audit, you will most likely receive an official notice in the mail to an officer of the company (CIO or CFO). If it is a review, then you will be contacted through a more informal method such as an email or a phone call.
Regardless of the method of contact, any request received should be reviewed carefully to ensure it is legitimate. Recently, phishing scams have popped up trying to gain sensitive information from companies. Should there be suspicious elements to the request such as an invalid virtual signature, spelling and grammatical errors, an upside-down logo, or a request to click a suspicious looking link, you should contact your Sales Rep or your Reseller to gauge its legitimacy.
It is important to already have established who is responsible for corresponding with the auditors throughout the process. Having a single point of contact controlling the flow of information to the auditors will prevent any unknown statements or actions from employees within your company being used against you later in the audit process. Your auditing team should consist of experts in the procurement, legal, finance, and technology teams.
In most software contracts, you are legally obligated to adhere to a software audit request, and should you ignore an audit request, legal action can ensue which can result in serious fines. However, while reviews are optional, not responding may push the vendor to more formal audit processes. The review options can sometimes have lesser penalties and you may be allowed to conduct the process internally using your own resources, as opposed to having a third-party auditor conduct the audit.
If there is a third-party software auditor involved such as Deloitte or KPMG, your first order of business, before any data is handed over to the auditors, is to set up a three-way non-disclosure agreement between the third-party auditor and your company. This will ensure that no information is passed off to the software vendor without your approval.
You need to make sure that the scope of the audit is clear regarding the divisions that will be included and if the vendor has several products, which products will be examined. Failure to do this will result in the auditors requested information that is out scope of the audit and may cause unnecessary problems and time delays.
Having your own Estimated Licensing Position (ELP) ready will give you a strong case to oppose the auditor’s findings, which will most likely have an overly inflated compliance gap. Your Estimated License Position should effectively compare your deployment data with your purchased licenses, within the scope of the audit. You will want to review the vendor who is auditing you to see if you have the internal skills required to meet the demands of the audit, or if you need to hire external experts (like MetrixData 360) to assist.
You will need to take ownership of the timeline and potentially delay for time if you need longer to understand your data or you are lacking visibility. The auditors will want the process done as quickly as possible and you must push against that to ensure it is done effectively.
The kick-off meeting will be conducted between you and the software vendor, their auditors, and any other stakeholders that they wish to be present. Here are a few likely topics that will be discussed during the kick-off meeting:
The Timeline will prove an important area for you to negotiate in order to make sure that you have enough time to complete the tasks the audit requires. Unless you negotiate for more time, you could easily be left with having only fifteen days to respond to the auditor’s findings (which will mean sifting through hundreds of thousands of rows of data). Having an established timeline will also allow you to monitor any dilapidation of the software publisher and their auditors’ enthusiasm in the process. During your audit, it is possible for them to become distracted by other projects or lose interest when it becomes apparent your audit will not reap the anticipated rewards. If the software publisher or their auditors haven’t contacted you long past one of the dates for completion, your audit could become dormant.
The auditors will most likely declare that your inventory tools fail to collect all the data that is relevant for them to complete the audit and for that reason they will demand to exclusively use their own.
Even if you have an inventory tool that the auditing software publisher has approved, the auditor will often not accept the data that your tools have collected. It is in your best interest that your own tools are used; it ensures that the tools you are using to count and monitor usage will stand up to the audits. If there are areas of inefficiencies, using your tool(s) will allow you to create processes to fix those in the future. It also prevents you from having to do security reviews of inventory tools from the auditors. You can offer the auditors the option of supplementing any missing data from your inventory tools with their own, or you can offer the chance to extract data samples from your inventory tool to test its accuracy.
There are many things that the auditors will be intentionally vague about, such as the metrics that will be used to count your deployment data, your licenses, your user counts, or your authorized users. There will also be very little information provided on how virtualization will be monitored and determined. It is important that all these points are clearly defined. You must understand what exactly they will be asking for and why they need to see that data. Not everything they ask for will be relevant to the audit.
The auditors will most likely resort to collecting data remotely and will only travel onsite to do a data verification session, this is done for the sake of practicality. Remote data collection is a more ideal situation, as it will grant you strict control over what the auditors have access to.
The auditors might also schedule to gather data from the members of your team in person (usually through screen sharing sessions); more specifically, they will want to gather information from the IT and procurement departments. This will either be obtained through an interview or through a simple observation. In the interview, they will likely be seeking information regarding the following:
Interviews pose a strain on company resources as this process will take working hours out of your company’s day.
In some scenarios the auditors might either ask you to self-declare your data or provide request records. Self-declare is most typical in the event of a SAM review since SAM’s are usually governed internally. You will be allowed to gather your own data, or the auditor’s will simply send a form which will guide you through the steps of how to gather their requested data manually.
Before staff is interviewed, it’s important to make sure everyone is aligned on what will and won’t be said. While you should never strive to hide things from the auditor, you should have a clear understanding of what your stance is with the vendor.
In order to achieve this, it’s required that you know what questions the auditors are going to ask, and help employees know how to answer those questions completely and effectively. Giving the auditors generalized and over-simplified information can cause incorrect assumptions to be made on the part of the auditor.
Your Single Contact Person (SCP) needs to be reviewing all data requests to make sure the requests are reasonable and within the scope of the audit. It is important that you remain on high alert and ask questions. Always make sure you understand why the auditor has asked for something and understand the impact each piece of data will have on your overall stance with the vendor. The SCP should also review each piece of data that is sent to the vendor to ensure you fully understand all information that is provided to the vendor and what it will be used for.
Ensure all communication with the vendor is done exclusively through your SCP. Again, this is not done to keep things from the vendor, this will simply make it easier to keep effective tabs on your position with the vendor during the process.
Make sure that all the data your company releases to the auditors and the vendor are of good quality and do not conflict with each other. You must check to ensure the data released is not providing any unnecessary data that can be used to make assumptions that may harm your position.
Above all else, you must challenge the software auditors whenever you feel uncomfortable with the data you have been asked to release.
If you do not know something, do not attempt to guess why they are requesting the data, ask questions to fully understand why they are asking for and what they are going to do with it. If you don’t know how to answer a question or obtain the requested data, explain what you do not know and propose solutions on how to retrieve that missing information.
After all the data has been compiled, the auditors will produce the Estimated Licensing Position (ELP) for your company, and they will ask whether you agree or disagree with the findings. It is important to remember that their findings are not set in stone, it is a mere interpretation of the data and can be read multiple ways.
The ELP will be presented as a large spreadsheet that will display the number of each product you have and the versions deployed, and compare those deployments with the number of licenses you have purchased. In any areas where you are out of compliance, the numbers will be lit up with red. Depending on the software vendor, the ELP might also include extra tabs or workbooks for every product found during the audit. These workbooks will provide the detailed data behind the inventory, including on which desktop or server a product is installed, details of what users are accessing servers, which management packs are installed, and the list goes on. After the auditors have produced this ELP, they will grant you only a small window of time, usually 15 days, to review hundreds of thousands of lines of data or more.
Once you have come to an agreement with the auditors over the ELP (with a NDA in place, they should not be able to send anything to the vendor prior to your agreement), the auditors will send their findings back to the vendor. They will give the vendor a brief summary of their research and your compliance gap.
Being able to cross compare the auditor’s findings with your own will allow you to effectively challenge the auditor’s conclusions. One way to make sure you are prepared is to have an accurate count on both your licences and your deployment data well before this point in the audit (or even before the audit begins). Investigate every area of the auditor’s case that you know, suspect, or even feel to be inaccurate. Find which team provided the data that the auditor’s used in their inaccurate assumptions and ask for validation. Seek clarification on items you do not fully understand, and have the auditors explain what they’re planning on telling your vendor. Highlight any disagreements that you have on the auditor’s findings, submit explanations for any grey areas, or propose plans to fix any shortcomings.
After the data has been sent off and the fact-finding portion of the audit is closed, the vendor will begin setting up a timeframe for purchasing any license shortfalls. It is important to realize this is not a settlement but actually a negotiation at this point. You will need to push for a timeframe that works for your company’s goals and interests, not the vendor’s fiscal goals.
After the software vendor has reviewed the ELP and your license position, they will send a starting quote for how much is owed to them. You should expect this number to be extremely high initially, depending on how much your compliance gap has been inflated due to worst-case assumptions made by the auditors. This is still a negotiation, not a settlement. This quote is not the final price and that needs to be kept in mind.
If you are found to be non-compliant, the remedy will differ depending on whether you have been given a SAM review or a software audit, which we previously discussed. Remember though, this is a negotiation, and nothing is set in stone, including the penalties. For instance, if the vendor has a clause stating that you must pay list price, plus an additional 5% penalty and you are found to be non-compliant, you have the ability (that you should certainly use) to negotiate that you do not pay penalties.
One thing you are trying to accomplish during the negotiation is to have the vendor offer their initial findings, the concessions, and any discounts right away. You may be able to obtain this by ensuring that anything you disagree with in the ELP is documented with valid mitigation strategies to account for any faults in the ELP. There is no single formula that can be applied to every negotiation, as negotiations are an art form.
There are many people involved in the audit from the vendor’s side that are reporting to managers with different agendas from one another. Stakeholders involved in the audit include:
All of these different teams might be compensated in different ways; one team might be paid based on the revenue they manage to obtain, while another on whether this audit is conducted according to legal standards, or on how satisfied you are with their work. When the vendor’s representative says they need to obtain internal approval, these are the people they are consulting. You need to word your requests in a manner that appeals to all stakeholders involved.
Know that you have done everything you possibly can to prepare for this software audit. Do not be pressured into timelines. Your goal is to have an ELP created that reflects your actual use and license requirements. Do not be forced into a settlement that is not accurate because you were not given enough time or because the vendor’s year end is coming up.
Be ready to research the licensing terms and other claims the vendor makes.
Be willing to leverage senior executives within your company and the vendor’s. A well-timed call to the right person can be very effective to unblock a stalemate in the process.
Your goal is to purchase only what you need. Often software audits are used as a sales tactic. Just when you feel cornered in the software negotiations, you can expect to be pushed towards purchasing new products. You must stay focused and strategic with your software purchases regardless of the pressure the software audit puts you under.
During the negotiation process it is important to remember that it is a balancing act between four key factors. The first one is future revenue versus immediate revenue: the software vendor will try to lean more towards immediate revenue while you should try to put most of your argument towards future revenue, such as deals you can strike with the vendor in the future, given your company’s projected growth. The second two factors are time of payment versus the relationship between the vendor and your organization as a client. The vendor will try to push for getting their payment quickly and it would be helpful if you pushed from the angle of keeping the health of your relationship with that vendor intact.
Make sure you get a closing statement at the end of the negotiation, after final figures have been decided. Some vendors may indemnify you from future audits looking back past the date the audit closed and you should try and get this if possible. This will give you the freedom of not having to worry about another audit from that vendor for a minimum timeframe or they will be at liberty to audit you using findings that date back prior to the close of the audit.
While other software audit consultants are not willing to release their prices until after a potential client has contacted them, at MetrixData 360, we value transparency. There are a few factors that can influence the cost of your engagement with us, these include the size of your business, the length of your engagement, the vendor type, and your choice of payment method (flat rate, contingency, or based on the number of working hours). Roughly speaking our services can range between $35,000-$100,000 with the average being $75,000.
Software audit clauses are clauses that can be found in the EULA of any standard software contract that states the right of the software vendor to audit their customer. Despite the fact that you have made a purchase, you don’t own the software you are using, you have paid only for the right to use it and so software vendors on the market today will outline their right to ensure their software is being used properly in their contracts. It will be extremely difficult to negotiate an audit clause out of your contract completely, but you can negotiate restrictions around when your vendor can audit you.
There is no single cure that will allow you to avoid software audits completely but you can lower your chances of receiving one by having a strong software asset management process in place that is demonstrated to the software vendor and by conducting a software audit quickly and effectively. This will present you as more organized to the software vendors and a less appealing target for an audit.
The software audit process involves either the external or internal review of a company’s software environment in order to determine license compliance, quality verification, or the meeting of certain standards. There are six steps to a software audit:
Software audits exist to provide assurance to the software vendors that you are using their software in a way that aligns with your original agreement. This includes making sure you are paying the right amount given the software that you are using, which is referred to as a compliance gap if it is discovered you are using software you haven’t paid for.