What is an ITGC Audit?
ITGC stands for Information Technology General Controls. While it sounds general, there's a backing standard and set of documentation that auditors use to maintain some consistency from the IIA (Institute of Internal Auditors). Non-members of IIA can buy copies.
Some important points -
- It's a standard, not just a willy-nilly set of what your 3rd party auditor thought would be good to check.
- If you want to, you can buy a copy of the rules you're being compared against. (I make no claim that you, or I, could understand those rules! But it's something...)
I don't get the purpose of such an audit
That's a broad question. Here's an analogy - I have to take my car down for a Safety & Emissions inspection every year. They review a very limited number of aspects of my car (tailpipe emissions, turn and brake signals work, headlights aimed correctly, etc.) as a form of due diligence that my car is safe (for myself and others) to be driving on the road.
The purpose of an ITGC audit is to ensure that the car (computing resources) of your company is basically safe - not generating undue risk to your company. If my car causes an accident because the headlights don't work, myself and others can get hurt. If your company causes an accident because your databases don't work, then various people - employees, shareholders, customers - can get hurt. The ITGC audit is the test to make sure your setup is correct enough so as not to be a danger to yourself and others.
especially given the way it is conducted.
Also kind of broad. Let's drill into the example you've provided and make some guesses.
The kind of requests from the audit teams are: Can you give us a
screen shot of the installation folder of xyz financial applications
and what server(s) they are on?
Your company says to the auditor, "we run SAP ERP to manage our financials." Being an auditor, they can't just take your word for it. They need proof.
The audit world has been moving rather strongly over the last few years towards Proof. SOX audits are much more rigid about getting a screenshot to provide evidence of something. PCI 3 got much more explicit about the auditor needing to actually see evidence rather than just being told. Both are shifting to require that the evidence collection be under the eyes of an auditor, to ensure no evidence tampering takes place.
Installation directories are the simplest form of proof that something is installed. Screenshots are the cheapest, easiest form of proof to gather with any evidentiary integrity.
So they want to know that you've got financial software, what servers it's on, and have some sort of proof that that's true.
Later on in the audit, they're going to be asking you about disaster recovery. And when they get there, they're going to say "Show me the your list of assets and their DR rating, e.g., what's most important to return to service after a disaster." And they'll want to cross-check that the list of servers that you put your financial server on are all in the right tier. It's a basic safety check - if your ERP web frontends are tier 1 recovery, but your ERP database backends are tier 3, then oops! Your whole ERP solution is tier 3, which is probably not what you wanted.
This is of no material significance to anything / anyone.
Well, I disagree. I would rather know that my stock broker is using an enterprise-class database with redundancy and not hand-coded Berkeley DB files as a backend for my trading. I can't go in and demand they tell me, of course, but if they've gone through a reputable audit, I can feel comfortable that somebody looked at their setup and decided it was sane.
Not to mention, I can change this information from day to day given
the virtualized architecture of our company.
You could. You could do it deceptively and maliciously to mislead your auditors - which is they they now ask for screenshots and shoulder surfs, to make it more difficult. You could also do it legitimately in response to business need, but most likely, business need is not going to be to switch to something that wouldn't pass an audit the second the auditors leave the building.
In fact, it's likely to change multiple times before next year's
Audits are point-in-time only. However, the expectation is that
- You won't shuffle things in time for the purpose of fooling an audit, and
- If you're doing things in an audit-acceptable manner today, then hopefully you are doing your job correctly enough that you'll do it in an audit-acceptable way tomorrow when you have to change it.
I must be failing to grasp some significant relevance? What is the
purpose of one of these audits? Who / what is it meant to protect?
What is it meant to prove?
I think you're missing the following things about audits.
- "Audits" aren't called "Enforcements" for a reason. They're looking and making notes, and they'll make recommendations, but they're not going to touch your stuff, and they're not going to whip out the thumbscrews to force your cooperation.
- Audits presume reasonable levels of cooperation. Yes, they realize you could lie and cheat, and they do things (like screenshots) designed to make that harder. But at the most basic level, IT audits are not adversarial.
- ITGC Audits protect everybody. The make sure you're doing things properly enough not to be a meltdown waiting to happen - because when companies melt down, employees lose their jobs, shareholders lose their money, and consumers are impacted. (Other types of audits may be more limited in their protective focus - an IRS audit, for example, is focused on protecting the government and the taxpayer, and the company being audited is not being protected).
- Audits prove nothing except that the Audit was performed (and only up until the point in time the audit was completed). Now, due to standardization, that means a lot more than it used to. The only thing the audit proves is that someone came in, asked questions, collected answers and evidence, and applied an organized set of judgments to that data, resulting in recommendations. So while they prove nothing, they do have some beneficial side effects.
ITGC audits measure what you're doing against they way a set of auditors have decided things should be done, or should not be done, based on history, knowledge, and experience. They can be enormous, imprecise, and focused on inane details all at the same time. They can be helpful, or they can be a waste of your time. Half of that is getting a good auditor - and the other half is how you work with your auditor.