Skip to content Get in touch

Contact form

Social Aspect of Audits

Software auditing is a delicate matter. Normally, the customer of the audit owns the code. It makes it pretty simple. Even though the programmers might have an emotional relationship with the code, they usually can hold that back as long as they’re fully aware of who the actual owner of the code is. It’s not at all fun to get your work and your decisions scrutinized even then, but it’s understandable.

The game is totally different when doing an acquisition audit. This is when there’s only a tendering process for a possible purchase of a company owning the code. After a couple of NDAs signed here and there, a third party, the auditing consultant, will come and take possession of the code he or his customer has no ownership over. This is also the part where it gets really tricky.

Acquisition audits are normally done when a bigger company buys a smaller one. Usually the smaller one is a startup and the main owner or owners are actually working in the company. They even might be the only employees in the company and thus responsible for the whole codebase the audit involves.

When the consultant comes rushing through the door demanding the source code, read access to production servers and answers from the developers, the atmosphere can get very tense. This requires good social skills from the auditing consultant.

These are the tips I have found useful in these cases:

  • First introduce yourself, your background and your expertise.
  • Explain what your task is and what it’s not.
  • Use positive language when talking with the audited party (you’re not there to find out problems, you’re there to verify everything is as good as expected).
  • Don’t speak any of your findings out loud (if for example you get to access production only supervised).
  • When asking questions about the code, be very understanding of the situations and the solutions done.
  • When writing the document, never bash. Only list the problems and the suggested solutions neutrally in the document.
  • If they deny you of something you need, take that up with your customer and do not pressure or force the audited party. Let your customer do that for you.

Even though the audit results (as the audit document) are not usually released to the audited party, they’ll get their hands on the document if the acquisition goes through. Expect them not to like you after that, especially if any of the findings were used in the price negotiations. If they were, your findings might have contributed to a huge personal financial loss to them. It’s understandable you’re not loved because of that.

But if you keep your professionalism to the end, don’t bash, only list your findings and act neutral, you’ll probably get hired for the next audit, too.

I’ll be talking about audits in DrupalCon Prague, focusing on Drupal audits. Be sure not to miss that!

Other thoughts

More thoughts