Foundations of a Software Publisher Audit Response Process Course
In this Lightning course we will cover some mid-level details and best practices around audit response and how to respond if you receive an audit notification. We also will share a couple of basic principles from the Anglepoint Audit Response Framework to get you started.
Lessons in this course:
- Identifying an audit
- The audit notification
- The audit response process
- Tips & tricks
- Elements of a good audity response process
Reach out to us if you have any questions or would like more details about the steps in a software publisher audit response process.
Identifying a Software Publisher Audit
First things first—you and your organization need to understand how to identify when you are about to be or are already being audited. It’s helpful to understand the basis and the facts about a software publisher audit to provide some further context.
Make no mistake—the typical software publisher audit is not really about license compliance. Software audits are a sophisticated negotiation tactic to get you as an organization to pay more money. Don’t believe me? When was the last time you received a statement following an audit formally certifying your license compliance? Likely you received a notification that the audit had concluded, but nothing more.
Now that we’re on the same page about the context for an audit, hopefully we can help you recognize other aspects you might not have focused on in the past. You’ll notice that audits will happen more often than not around fiscal quarter and year end sales cycles, and around major contractual events. If you have a software publisher with a 3-year contract cycle, for example, you can expect some increased audit activity in advance of those larger 3-year contract renewals.
Best practice here is twofold—first you need to have identified who your key software publishers are. We recommend analyzing your software spend and risk on an annual basis to make sure you are focusing where you need to be. Second, for this list of key software publishers, you need to understand what your major contractual events are and where they fit on your corporate calendar. You need to make sure you are managing them proactively and have trustworthy data AHEAD of major contract events, and that will also help you be better prepared to respond if you receive an audit notification.
You might not always know when you are being audited or when a publisher is attempting to put you under a level of scrutiny relative to license compliance. And this is by design. The first phase will be a contact from the software publisher, but this might be formal or informal and can come from multiple contact points in your organization.
The Software Audit Notification
Audit notifications take many forms.
Any part of your supply chain for software like a publisher, a reseller, a third-party distributor, or system integrator might send you a notification. You might get a phone call, receive an email, or be sent a physical letter.
Potentially if there is a significant allegation you might receive a notice from an industry group representing a software publisher, such as the Business Software Alliance (BSA) or Federation Against Software Theft (FAST).
Since there are multiple channels that software publishers might use to send notification, this means multiple areas within your organization need to be educated. This would include but not be limited to: Procurement/Sourcing, Vendor Management, Application Management, System Integrators, CIO, CFO or other C-Suite executives. The best practice is to raise awareness of the risk that software publisher audits represent to your organization and raise awareness via training and education with all of these areas. Best practice is to have any of these contact points inform the SAM Service as soon as the audit notification is received. They themselves should not take any other action.
Please note that things will not always be as black and white as ‘we are going to audit you’. The software publisher may take a softer approach—such as requesting a license consumption report or asking for ‘true up numbers’ ahead of a contact renewal. If the approach is very soft the language might be positive that is used—perhaps an ‘opportunity’ to ‘right size the environment’, or an ‘exercise to help improve your Software Asset Management’.
This brings up another best practice. As soon as the SAM service receives the audit notification, they should confer with IT Legal. The IT Legal department will be an integral part in assessing risk from a Legal perspective as well as helping to steer the general response. In summary, the flow should be: organization contact point >> SAM Team >> IT Legal.
The Software Publisher Audit Response Process
This brings us to the software publisher audit response process . Since this is a shortened training, we will not go into too much specific detail here.
However, this is definitely best practice. We recommend that before any audit notifications are received, you should develop this process with key stakeholders. Typically, those would include parties you would work with as the SAM team from a day-to-day perspective when understanding license compliance: Procurement/Sourcing, Vendor/Contract Management, Application Owners, Infrastructure Management, Tool/Platform managers, but also IT Legal.
You should establish and document a process flow and ensure that the roles and responsibilities are clear and communicated to all parties taking part in the software publisher audit response process . The goal is to make sure that there are no gaps or duplicated work, and the team can work efficiently together.
Secondly, this process should be implemented in a standardized way—whenever an audit notification is received, this process should be triggered. In this way you are managing each potential risk in a standardized and controlled way. This greatly increases your chances of success.
Once your internal process has been established, this needs to be included in communication and education campaigns to the rest of the business. It will make no difference having a robust process for your software asset management (SAM) team if the rest of the organization doesn’t know how they are supposed to support.
Software Audit Tips and Tricks
Every audit is different so you will not rely on all of these each time but are some good general principles to keep in mind.
1. Is this a valid audit?
I mentioned one of the first thing that the software asset management (SAM) Team should do is analyze the audit notification. You should compare this to the stated audit right(s) contained in any and all signed/accepted publisher agreement(s). Software publishers will send requests for information that are NOT audit notifications.
If they have no contractual right to audit, you are not obliged to disclose any information during the software publisher audit response process. You need to be careful in your response not to trigger a full audit, but you should verify this with IT Legal and push back—not all requests for information need to be answered.
2. Push the tempo.
Hopefully you are executing proactive IT Asset Management—meaning that for your top software publishers you have a capability to understand your compliance position. This should mean you have no cause to stall or dig your heels in during an audit.
Therefore, if you are in an audit situation, your organization should be doing all of the administrative legwork—scheduling all follow-up meetings, inviting all participants, taking notes and actions. This will let you control the written record of everything that is being agreed during the audit.
3. No external scripts.
This one should be a no-brainer. If the software publisher is requesting for information, they will likely provide a script or method that will ‘make it easier’ for your team to send them reports. You should never disclose information to a software publisher you have not had a chance to first review.
If you are running a script developed by the software publisher, you have no control over what data is being disclosed. They are likely collecting information that is far above and beyond the scope of data required for an audit. Your response to this type of request should be that external scripts are prohibited by your Information Security team.
4. Clarify the scope of License Entitlement BEFORE any data collection happens.
You will need to push back on this topic as the software publisher will likely say they want to start collecting data as soon as possible. Your response should refer back to the commonsense basis—if you have not clarified the products and license entitlement scope in the audit, how can you start collecting license consumption/usage data?
Software Audit Response Process Best Practices
I’d like to share some further best practice elements of a good software publisher audit response process.
1. Execute confidentiality agreement(s) with the Software Publisher.
You do not want to share any confidential data without an NDA in place with the Software Publisher. Try to limit 3rd party involvement here as well, but if there are 3rd parties involved you will need NDAs with them too. This can be leveraged as an opportunity to include further advantageous language—make sure that your Legal Department supports the SAM team in drafting this agreement.
2. Take a stepwise approach to Entitlement Baselining.
By this I mean follow a logical progression. First you’ll want to agree on the Legal Entities being reviewed by the software publisher. Then, the software product lines, specific products, and any applicable contracts. Make sure this is done BEFORE any purchase transactions are discussed and certainly before any calculations are agreed.
3. License Consumption and Deployment recognition should FOLLOW entitlement baseline.
This is always hard to pull off—the Software Publisher will push to collect license consumption data either up front or at least along side the collection of Entitlement data. Make sure you have a calm and logical approach here—that until you understand the scope and baseline of license entitlements, you can’t collect any license consumption data.
4. Baselining and Draft reporting.
Try to remain in control of the tempo of the overall audit. Delaying for the sake of delaying will not result in a positive outcome—in fact the auditor will think you are hiding a non-compliance or not prepared to respond. However—do not rush to confirm license consumption or license entitlement baselines until you are ready to do so.
Once you confirm a figure on either the license entitlement or license consumption baseline, it will be hard to walk back. So ensure you have enough time to analyze and confirm any logic, calculations, or conclusions that the Software Publisher’s audit team is making before you agree to any baselines.
These are a handful of best practice steps that you should be considering in your Audit Response process. The Anglepoint Audit Response Framework has all of these elements and more.
In Conclusion
I hope this has given you a few ideas that you can leverage to either establish a new audit response process or enhance your existing processes.
As I mentioned, in order to have the greatest chance of successful outcomes, your process should involve key stakeholders, be clearly documented and easily repeatable, and be widely communicated to the rest of the organization so there is awareness by all potential channels that could receive audit notifications.
It’s important to have a well thought out communications strategy and manage stage gates to maintain full control of the cadence of any audit.
Anglepoint has developed tried and true procedures and processes that have a very high success rate. If you’re interested in the full Anglepoint Audit Response Framework, contact us here.