So far in this series I've looked at what to do when an audit letter arrives and how to make sure the auditor doesn't get a head start by driving the scope and timelines of the audit process at your expense. This post covers the most important phase of a software audit - gathering data and sharing it. I'll start by reminding you of something I put in my last post:
"Yes, they may well have a legal right to audit your usage of their software, per the contract you agreed to, but the audit clause certainly won't have too much detail beyond that. Will it compel you to use certain tools to provide data outputs? No. Will it compel you to give them any data they ask for? No."
The reason I say this is that the auditors will ask for all sorts of data, some of which won't be relevant at all and a goodly portion of which will involve them running a discovery script of some sort. One of the most important rules of data gathering for an audit, and I can't emphasise this enough, is DO NOT TELL AN AUDITOR EVERYTHING THEY WANT TO KNOW. Yes, I know I just "shouted" that but I felt it was worth it. If you've followed the steps I outlined in the previous two posts, you will, hopefully, not be feeling too intimidated by the audit. That said, many organisations do believe they have to give the auditor everything they want.
Typically, an auditor will want to know all about your IT estate as a starter for ten, often supplying a scoping questionnaire for you to complete. This will include questions ranging from what discovery tools you have available, which is obviously relevant, to describing the organisation's password reset policy, which is clearly not. Make sure that you push back if you do not feel comfortable answering the question or if you feel it isn't relevant to the purpose of the audit. No one is going to escalate an audit because you refused to answer questions you are not compelled to answer.
Depending on who is conducting the audit, you will probably receive a list of data requests with the questionnaire, which may include deployment of scripts, getting the output of certain commands embedded into the software, producing an output of your discovery tools based on certain key words, or user lists accessing the software via AD security groups. What you would have already done, hopefully, is to evaluate your in-scope estate as soon as you got the audit letter, so you already know where your weaknesses are, if indeed there are any.
The most important activity, before sharing data, is to ensure you sense check every item before it goes to the auditor - you may want to anonymise some data (e.g. user names, server names etc) but do be sure to include a key so that the auditor can differentiate individual user accounts and devices. I have seen auditors double count in the past where such a key was not included. You may also want to ensure the data is not telling the auditor more than you want to with regards to your IT estate and its architecture.
Once the requested data has been shared, or you have justified why you are not going to share something, it's a matter of being patient until the auditor produces a draft report for you to validate. This is a step that should occur in every 3rd party audit before the report goes to the vendor. I will cover what to do at that stage in the next post in this series. As ever, if you need support with an ongoing audit, are under threat from a vendor, or would like Cortex Consulting to proactively review your estate to find any weaknesses, please do contact us to see how we can help you.