Beware, beware, the auditor's coming

Actually, treated right, auditors are often pussy cats...

Comment "Know thy enemy." For developers, try talking to an IT auditor sometime.

For a start, your application increasingly risks being audited against regulatory requirements, governance good practice and the like (possibly requirements that weren't mentioned when you built the app) - and if it fails, your name will be mud and your career heading towards a brown slimy place at the bottom of the swamp. Even if it isn't your fault - you want the business user who asked for the application and told you "not to worry about any audit trails, just get it out fast" to take any blame? Shame on you...

On a more positive note, you may find that the auditor isn't such a bad guy. Like you, he wants a comfortable life. Give him reason to believe you know what you are doing; that if any risk manifests itself, your application can publish an associated metric which can be monitored and shown to decrease as the risk is managed - and you might just have some fans at board level.

On the other hand, hide things, resort to obfuscation and obscurity and the auditor will have to dig deeper, simply to protect his career. And, believe it or not, lawyers and auditors reading through poor documentation and obfuscated code or, more likely, building a defensive perimeter round your application and double checking everything that passes through it, are very expensive. You may think some programmers are paid well; but compared to lawyers; well, if you aren't a lawyer yet, you're probably being a fool to your family...

HP internal auditor Brad Ames confirmed my experience from years ago, when I once got a very nice "exceptional performance" bonus for taking a bank through an external audit of its development process. Yes, it did have one, it's just that I had to show that it actually followed it - and I found that the auditors liked me pointing to the training courses and feedback forums I implemented instead of to pithy notes from the MD saying "do this, or else"...

When the auditor asks a question, the "right" answer is "oh yes, we can track that, it's currently at such-and-such a level and if that's what you want to focus on, we can improve on those figures over, say, the next couple of months by doing this..." And the wrong answer? "Oh hell, never thought about that, what is it exactly..."

Brad talks about moving from where we often are with old-style auditing, with static, intrusive, point-in-time controls; to where we need to be with ongoing assurance and collaborative real-time transparency of the processes being governed. This means risk management, not risk elimination and adaptive governance that can respond to emerging threats instead of being bogged down in static rules (which often address risks from long ago instead of any real risks met in practice today).

The secret is to have systematic, configurable controls built into the application (which is where developers come in, of course); which work on detecting and correcting error exceptions as they occur. Think of systematic controls for completeness, accuracy and authorisation; complemented with exception reporting for transactions departing from the norm. And compliance-oriented BI (Business Intelligence) - trends, comparisons and analytics.

These controls should be linked to accepted governance frameworks such as ITIL; and for each control indicator there should be a physical control that can be verified. For instance, not installing security patches is an indicator of (lack of) IT operations control, and the auditor will expect to see this listed and be able to view a report showing patches currently not installed and patch installation trends over time.

Remember, the auditor isn't particularly interested in there being no outstanding security patches today, he wants assurance that this situation will continue tomorrow, when he isn't inspecting, and if some problem results in patches being missed in the future, that this will be noted and rapidly addressed. A few outstanding patches, for a good reason (scheduling patch testing, perhaps), with the number outstanding decreasing over time, is more impressive (to an auditor) than a successful attempt to get all outstanding patches installed the night before he arrived.

What auditors want to see is evidence of good process and trends over time. They then feel comfortable with what you're doing and go away to give someone else a hard time. What's in it for you? Well, the company sees you as someone in control of what is going on, as a "safe pair of hands" that can catch potentially troublesome issues before they cause problems - and, believe me, having to comply with the letter of, say, the SOX regulations in absolute detail (in front of a hostile regulator), because you've tried to hide problems, will cost you big time.

There must be a snag. Well, of course there is: you do need to do a professional job. Doing good governance is easier and cheaper than faking it, but you do need appropriate skills and training. You need to design applications for auditability, accountability and transparency. You need to manage risk; you need to design audit trails and controls that are as complete and thorough as the regulations require, but not more so.

"Keeping everything forever" is not a low cost option for IT governance - not only are storage and management costs significant, lawyers charge like wounded rhinos for reading through unnecessary material. Designing in IT governance may take a little longer in the short term - but it will pay dividends in the long term. But an organisation will only reap these dividends if senior management recognises the importance of IT governance as part of corporate governance as a whole - and rewards those who design holistic solutions with good governance built in.

And help is available. HP UK and Ireland compliance head Dave Green, for example, runs HP Compliance Services, which uses tools such as the HP Compliance Suite, together with HP's own experiences with SOX compliance (and Brad Ames' internal auditing experience), to help organisations put good governance (and compliance) in place. He talks about a three stage process: assessment (and this should be in terms of business-focussed governance objectives), remediation and, most important, sustainability.

Good governance isn't a one off thing you can then forget about. You must think in terms of a well-governed process, and one that is continually monitored to ensure that standards are maintained. Reward one developer for delivering ahead of schedule by cutting corners and all your developers will get the message. And you can kiss goodbye to IT governance generally... ®