What a Software Audit Means for You

Editorial Note: I originally wrote this post for the SmartBear blog.  Check out the original, here, at their site.  While you’re there, have a look around at some of the other authors’ posts.

“We’re being audited.”

Now there’s a sentence to strike fear into anyone’s heart. The most famous and iconic example of an audit is the dreaded IRS audit. This audit is the IRS’s way of saying, “you did something wrong during the course of an extremely byzantine process we force on you, and now we’re going to make your life miserable by going through every inch of your life with a fine-toothed comb.” Or at least, that is the reputation.

Now, while I’m not here to defend the US tax code nor bureaucracy in general, I will say that this is not exactly what the IRS is saying. Rather, they’re saying, “we’ve noticed inconsistencies between what you’ve reported and what we’ve observed elsewhere, and we are going to investigate further.” And, while this investigation does, in fact, mean a lot of unpleasantness for you, that is not the purpose. An audit, per its dictionary definition, is “a methodical examination and review.”

Audits at Your Place of Business

Considered this way, the word loses some of its onerousness, since it is not deliberately punitive. But it’s still not exactly a cause to throw a party – it means that someone is about to come take a very close look at something you’ve done, with exacting rules and detailed expectations. You’re about to be under a microscope.

Having established that an audit is strict and not punitive, what are the implications for you, as a software developer? What does it mean for you code/software to be audited? If your boss or a colleague utters those three fateful words, “we’re being audited,” what does this mean for your organization and for you?

Well, I’m a consultant, so you can probably predict my answer: “it depends.” “We’re being audited” is informative, but it’s not quite enough information. There are, after all, different kinds of audits, conducted for different purposes. Let’s consider a few of them.

Not All Audits are Created Equal

For practical purposes, let’s introduce a constraint to the discussion here. If you and I are on a team and I take a very detailed, formal look at your code, this is not an audit; it’s a rigorous code review. An audit, for our purposes, means that an outsider is taking a look at the software.

With this in mind, perhaps the simplest form of audit is analysis by an outside consultant or firm. I actually perform this sort of audit fairly routinely for clients. This is generally the result of someone in a leadership position wanting an independent, strategic assessment of the code – the equivalent in the medical world of seeking a second opinion. This style of audit can vary quite widely, and its purview is generally answering some qualitative questions asked by the leader hiring the auditing party. Examples might include, “is our site secure?” or “do we have a well designed code base that we can build on?” Presumably, this audit will involve some combination of manual inspection and automated analysis of source code, version history, build artifacts, and the technical work product in general.

Another type of audit that you might see, particularly at large organizations, is a legal compliance audit. In the world of software, this revolves around making sure everything is above board with licensing. Are proper attributions happening with any open source software that’s used? Are there any expired license dependencies? This style of audit will be heavily intertwined with the organization’s legal department.

Standards compliance is another common style of audit.  You’ve most likely heard of ISO 9000, at least in passing.  This is an example.  Basically, a standards organization is an outfit that establishes and certifies standards.  For a simple example, let’s say that an entrepreneur in your home town decided that employees not washing hands in restaurants was a problem.  She establishes the “Hand Standard” and advertises that you can believe that any restaurant showing off the “Hand Standard Certification” is one where you can trust that employees are washing their hands.  In order to preserve her brand, she performs an intensive audit on any restaurant seeking her certification, by, say, doing random swabs of employees on their shifts.  She has staked her livelihood and brand on being able to identify hand-washing restaurants, which means that she’s going to be very strict about who gets her certification.  The same thing happens in software and software development process — your company can seek to be certified according to a standard.  But doing this will subject it to audits from that organization.

Impact on The Average Developer

I can tell you two things with a high degree of confidence.  The experience is almost certainly going to be aggravating but not harrowing.  You’re likely to find yourself spending time on awkward and mundane tasks: walking someone through sections of your source code, digging up documentation, meeting with auditors, going through version control history looking for specific things, etc.  It’s going to distract you from the coding and delivery work you like and would prefer to do; it’ll turn some of your time from development to filling out income taxes.

But, it’s also not likely to be something where your feet are held to the fire.  As I said earlier, audits are about reconciling perceptions and claims with reality.  And the reason that organizations do things like this are typically to provide air cover.  They get security certified so that they don’t suffer as much blowback later if a security hole is exposed (“hey, according to Acme Security Inc, we did our part!”)  They get legal compliance so that they have cover on subsequent lawsuits.  The name of the game is usually some variant of insurance.  Even in the case of bringing in consultants to examine code, it’s generally not about blame or evaluation, but rather about getting leadership more in touch with reality.

The upshot of all of this is that, while an audit won’t make your life fun, it’s also not aimed at finding fault with you.  Dutifully complying with it will most likely result in no real fallout for you one way or the other.

Your Personal Strategy

So what should you actually do before, during, and after an audit?  Well, as I’ve already alluded to, I definitely suggest complying to the best of your ability.  I loathe bureaucracy, so it makes me wince to say this, but there’s no upside here to being an iconoclast.  Go home and grumble about it over a beer, but grin and bear it at the office.

More importantly, though, you should, under no circumstances, fudge anything to avoid looking bad somehow.  You’ll likely be caught and then it goes from “annoying but not damaging” to “you’ve really stepped in it now.”  Even if some mistake of yours is exposed, it’s not a problem — audits are about air cover more than blame.

It’s really not going to be as bad as it sounds.  So, before, during, and after, go along with what’s needed, be cooperative, and try to maintain a sense of humor about it.  Washing one’s hands isn’t especially fun, but it’s a whole lot better than bad hygiene, sick customers and lawsuits.