Data Collection During The Software Audit Process

Congratulations and welcome to data collection. Data collection is probably going to be one of the longer videos, but don't worry, it actually gets a little bit easier after this point. In this video, we're going to talk about general data collection when it comes to inventory that's required in a software audit. So let's start with data collection in general. What's going to happen? The auditors likely are not going to come on site. They're probably going to be doing this remotely. They're likely going to be looking for you to run scripts in your environment, or maybe pulling data out of your inventory tools, or if you have a software asset management tool out of that tool for them to review. Once they feel that the data collection is complete, they may then request an on site to go through a data verification process or to look to fill in any of the gaps in the data that has been provided to them. This process, if you think about it, makes sense because you don't want to be paying unnecessary travel fees for auditors to be traveling to your site or to your various sites around the world in order to go through the simple process of collecting inventory data. One of the key things to be careful about when it comes to the data collection process in general is that there's kind of two data types that they're going to collect. There's data that you can actually get that is within inventory. So think of that as stuff that is actually installed on desktops, laptops, servers, et cetera. Then there's non inventory elements that are a lot of time required in order to do a license position. Those would be things such as HR records, active directory access logs to servers, and things like that. The more complete your data is, the more accurate the license position the vendor creates. But this is easier said than done sometimes. So other than the obvious of running scripts or getting data out of your inventory system, how are the auditors going to do this? Most of the time it's going to be left up to you. They're going to give you a list of the things that they require, and then you're going to go out and collect those and then send those to them. Once they have that and they've assembled their data together in a first glance, they're going to come back and look for you to fill in the holes where there are pieces of information missing. They will do that through things like remote screen sharing sessions. They might actually do interviews with your employees. There's a variety of techniques that they have. So let's take a look at a couple of those. Interviewing. So they're going to talk to various people throughout the organization, not just IT people, but also probably procurement and maybe even finance people. What are they going to be looking for in these interviews? They're going to be looking to fill in gaps of information that is missing or that you can't get out of inventory tools, for instance, what are your purchasing processes? Do you have the ability to collect all the software entitlements and do you have a good record of all the software entitlements that you own? Do you know how mergers and acquisitions play? Have you been collecting all of the different license contracts as those come together from an IT perspective, they might ask things like how are servers accessed? So if there's an application that's installed on a server, they might be looking at who has access and who's licensable via that access. Before anybody interviews anybody, make sure that your single point of contact has talked to them and prepared them for what makes sense to say to the auditors. Again, we're not going to hide anything from the auditors, but we want to make sure that the messaging is consistent from everybody throughout the organization. It's really important during the interview stage that if you don't know why they're asking questions, that these seek clarification. So often we see people say things that actually end up causing challenges further along in the audit because they give generic statements that the auditors then apply generically across the entire environment. An example of this is an auditor might ask how is that application on the server accessed? You may simply respond that all access to application on servers is done via Citrix, not knowing that that application is on a Citrix server. And, and then the rules of your Citrix server access are applied to that application on that server, which may be completely different. So it's really important to teach your people what not to say and what to say in an audit. Not that you're going to hide information from the auditors, but as my previous example illustrates, not understanding the root of the question could end up causing you problems a little later down the line. So make sure that they understand what's acceptable to say and what's not to say. And, and if they have any questions to say, I'm not sure. Let me get back to you with that. Just to make sure that there's no misrepresentations of your data in the future, Some information may not be able to be validated within your environment. In those cases, the vendor may actually have you do a self declaration. Actually, some Audits may be a full on self declaration where you just provide them what you believe to be your license position and they either accept it or not. But in most cases, self declaring means that there's information that you just can't get that the vendor or the auditor is going to want you to declare. A lot of the times you may hear things like, okay, we will accept that if your CIO or an officer of the company signs off on that. So again, when you're doing self declaration, make sure you understand what it is fully that you're declaring and make sure that you understand the implications down the line as to what that's going to indicate from a licensing perspective and be sure that you're comfortable with that. Review all data requests. You're going to get asked to provide a lot of data throughout this audit. You want to make sure that you review all requests and that you understand why that specific data is being requested and what the auditor is going to do with it. A lot of the times auditors will just request data that they may not require in order to create a license position, but they may end up using that against you. Further down the road, if it seems that they don't require it, you might want to actually have a discussion with them about why they need that and try and get that out of the audit so that they can't make assumptions on data that they do not require review. Data quality. There's going to be a big volume of data that's created in any audit. You need to review that data, no matter how large the data set is, to make sure that the quality is good and that there's nothing in there that is incorrect. So often we see data requests go through with data on devices that have been retired off the network, they're no longer there. Devices that are out of scope that then get put into scope. So you really want to review that data to make sure that everything that is in it is actually required. If it's not, we don't suggest you take it out because that would be hiding things from the auditors. But make sure you denote all of that so that it's out of scope from day one and not something that you then have to go and fight after the fact with the auditors. So I know this is a high level overview of data and the data collection process. You're going to be asked for a ton of data. I hope that's come across. A lot of this. Data may be things that are required, but there may be data in there that's not required. So again, make sure that you use your single point of contact, who understands the scope of this audit, to push back on anything that is not required within the data collection process. So the importance to this is going to become very important on the next topic, which is the creation of estimates at license positions. Thanks for watching and I'll see you in the next video. Back in the first video, we talked about creating your own elp. Now is the time to compare that ELP to the vendor or auditor's ELP to see where there's any differences.