Archive for March, 2008

IT Audit Rule #2: IT Audits don’t prevent loss

March 19, 2008

Sorry to leave this topic open for so long since the last post. Financing activities take top priority for a private company….enough said.

Let’s talk about IT Audit Rule #2. Remember these are my rules, not an official set of commandments. But based on some experience in auditing.

IT Audit Rule #2: IT Audits don’t prevent loss.

Security’s intent is to stop loss. Audit’s intent is to verify the accuracy of something; typically by checking a sample of outcomes but also by making sure that critical controls are functioning. The theory of an audit is that if the right controls are consistently working then the thing being asserted (in this case your data’s accuracy or the state of your data security or privacy) is probably accurate.

Does an IT Audit help security? Absolutely. It will help to point out where weaknesses exist; where controls might be needed to prevent loss or inaccuracy.

And here’s one of the beauties of technology and automation. You literally can audit every event as it happens with automation. So instead of sampling a few transactions and seeing if the outcome was right, you can audit every transaction to see if the outcome was right. Not only that it occurred (see last post for flaws of IdA products for auditing) but that it was right.

But here is the Corollary to Rule #2: Don’t ask an IT Audit product to provide security. For the simple reason that if an IT Audit product now is reversing or stopping inappropriate events, it can no longer be trusted to audit (See Rule #1). It is tampering with the evidence of whether the processes and controls it is auditing are actually working.

Two separate processes need to exist in IT. The security process that tries to create an outcome. And the IT Audit process which verifies that the security process is working. If you have the option, don’t trust the vendor providing one solution to provide the other (Back to Rule #1).