Reality IT: The Auditor: Friend and Foe

Internal and external audits are a necessary evil for the ACME IT shop. During the past three or four years they've become more common and now require more information. Although they're about as welcome as dental surgery, we've learned to survive them--and learn from them. For those of you blissfully unaware of these dealings, you should be sacrificing old routers and 10-Mbps hubs in thanks to the gods of networking.

In our experience, the information required in an audit falls into three categories: policies, documentation and log files.

On the policy front, auditors want copies of password policies, helpdesk operations, backup procedures, security policies and more. They've also asked for policies on things we hadn't thought were necessary so never wrote down--which means every once in awhile I've created simple policies on the fly in response to auditor questions.

Documentation requirements are legion. Auditors will want good high-level network diagrams, systems inventory, org charts and even job descriptions of key staff. They'll want your strategic plan and IT budget info. They will even ask for copies of agreements with major service providers. And, of course, they will want your disaster-recovery plan and most recent test results.

As for logs, they'll want files from pretty much every device or system in your network.

In addition to the chore of providing all the required materials, audits cause other grief. Once the auditors leave, for instance, we change all the admin passwords on all our servers, routers and telecom equipment. It's tedious but necessary because most auditing firms run their own tools, and you never know what detail they may have gathered.

As you can imagine, audits take up a substantial amount of time. We generally expect to devote about 50 hours of total IT staff time per audit, though that figure has climbed to more than 100 hours on occasion.

To keep the staff from going crazy as they do their own jobs while providing the auditors with everything they need, we treat audits as planned events and have gotten good at responding to them.

I find it best to be friendly with auditors. For example, my IT staff and I have used interpersonal skills to talk an auditor down from a "finding." A finding is something that gets documented as a deficiency on the official audit. Audits with more than a few findings bring down the wrath of senior management, and IT must address in writing how it will remediate any findings. And if the same finding appears in consecutive audits, your rear end is really in the wringer! We've found that by being friendly, auditors will give you a chance to respond to a potential finding to get it off the report before it's finalized.

They may also give you a break when you can't provide printed or electronic documentation of a procedure. Rather than have you write it up, they'll let you show them how a certain task is performed or how something is configured.

I was able to use the workload of audits as part of a larger justification for the creation of our first IT Security Manager position, which resulted in Bucky Rogers joining the team. Security is a major component of IT audits, so it makes sense to have Bucky act as our primary contact with the auditors.

And truthfully, at times audits do uncover issues we should deal with. We've put good IT controls into place, for instance, that we might not have otherwise, such as hardening and aging out passwords. Audits may not be pleasant, but they do keep us honest. n

Hunter Metatek is an enterprise IT director with 15 years' experience in network engineering and management. The events chronicled in this column are based in fact--only the names are fiction. Write to the author at [email protected].