Frequently Avoided Questions
about IT auditing
Last avoided in December 2015
This is a public resource. My purpose in publishing it is twofold: to inform and entertain. Please forgive the British humour, spelling, InCorrecT CapitaLisatioN and distinctly cynical style ... but do experience the passion. I sincerely hope that it answers all your basic questions about IT auditing, but if not, please see the feedback section towards the end – I would really appreciate your feedback and suggestions on how to improve this FAQ. More questions. More answers. Oh and funnier jokes.
The FAQ explains IT auditing to someone with limited prior knowledge of the topic (a.k.a. the Clueless But Interested). Reading the whole FAQ will give you a good overview of the whole subject and should help put it into context but don’t feel too embarrassed about being bored stiff by the tenth line or earlier if you are a quick reader. Like Earl Grey, it’s not everyone’s cup of tea. Just pick some slightly-less-boring topics from the weird contents brain thingummy above and browse the hyperlinks until you slump exhausted over your keyboard.
If you are an auditee, an Ordinary Mortal about to be visited for the first time by an IT auditor, you will find herein some clues about the dreadful grilling you are about to endure. Our aim in fact is to allay your worst fears by explaining the IT audit process straightforwardly. Have a dream meeting not a nightmare. Sleep soundly.
The FAQ should also prove beneficial for students and others
nuts brave enough to consider actually becoming IT auditors. Nontechnical auditors (e.g. financial and operational auditors) might even learn a thing or three, if they aren’t scared bitless.
Go back to contents mind map
All about IT auditing
What is IT auditing all about?
IT auditing is a branch of general auditing concerned primarily with governance, risk, control and compliance in relation to IT, i.e. information and communications technologies. IT auditors are interested in how IT systems, networks and peripherals, plus the related procedures for designing, developing, testing, configuring, implementing, using, managing and maintaining them, handle risks to the organization. We spend the bulk of our audit time dealing with the people rather than the IT but being able competently to audit the IT is what sets us apart from the riff-raff and hoi-palloi. Like many IT professionals, we may at times appear to view people as peripheral devices responsible for generating inputs and consuming outputs, and as the principle generators of flaws, bugs and errors, but that’s a cynical perspective.
What do IT auditors actually do?
In short, IT auditors review the organization’s risks relating to IT systems, networks, processes, data and information. In long, that means digging the dirt to reveal issues such as:
Inadequate information security (e.g. missing or out of date antivirus controls);
Inadequate information risk management (e.g. substantial but unrecognized and hence untreated risks relating to ICT);
Inadequate governance and management (e.g. sinking the budget into unnecessary, inappropriate and ill-conceived IT projects, equipment and services, and then passively watching them overspend as if it’s someone else’s problem);
Ineffective and inappropriate IT strategies, policies, practices and metrics (including the lack thereof);
Neglected or missed opportunities, including opportunities for improvement;
IT-related frauds, embezzlement and other malfeasance or criminal activities (most of which involve IT systems and networks incidentally as mere tools or machines for the commission of crime, while some involve actively undermining or bypassing the associated security controls, or exploiting their absence);
Non-compliance - or rather the potentially adverse consequences and penalties arising from, or relating to, disregard of various internally-derived and externally-imposed obligations (laws, regulations, strategies, policies, standards, contracts, agreements, understandings and ethical codes) in the IT and information sphere (e.g. privacy).
Also known as ...
IT auditing is also known as IS, IT or ICT auditing and systems auditing. In certain quarters, auditors, testers and reviewers tasked with challenging the status quo are known as Red Teams or sometimes simply “Them”.
OK, so what is auditing then?
Management call-in the auditors to review stuff and the auditors in turn produce formal reports and recommendations that circulate to management, but they operate independently in order to avoid management directing them away from or turning a blind ear to the things they would rather not deal with.
Auditing, in general, is formally described as: “The independent examination of records and other information in order to form an opinion on the integrity of a system of controls and recommend control improvements to limit risks”. There are several significant, if somewhat boring terms in that description:
Independent - whereas managers “do”, auditors “do not”. Auditors should not be directly involved with the operations or management of a function being audited. They should report to a separate line of management and be free to state the facts of a situation and their honest opinions without fear of recrimination from those in the subject area. Just as if not more importantly, independence is also a state of mind. It’s about being freethinking, able to gather the facts and consider situations objectively. Switzerland has the right idea. Some judicial systems come close. Think ‘referee’ and you have the right idea.
Examination - auditing involved the gathering and assessment of factual information from various sources. It is important that the formal outputs of the auditing process (primarily audit reports containing recommendations for control improvements) are traceable to valid information sources. This has nothing to do with college exams or what the doctor does to your private parts. It’s science.
Records and other information, including what are often called “audit records”. Auditors need to refer to information regarding the business processes and systems under review (such as completed data-entry forms, system-generated reports and, of course, the people involved in doing or managing the relevant business processes). IT auditors often use data analysis tools to examine computer records. Furthermore, all auditors normally interview staff in the business areas under review and may use other observational techniques to examine business processes in action. Audit records such as “The most creative use of language to out a totally incompetent auditee this year” don’t count, despite being awarded at many audit Christmas parties.
Opinion - auditors provide both objective facts and informed but subjective opinions on a given situation. Although subjective and often jaundiced, our opinions are based on an interpretation of the facts and are open to legitimate challenge. You don’t have to agree with us but if you don’t, you’d better be ready for a ‘full and frank discussion’.
Integrity - literally means completeness, accuracy and trustworthiness. A control system which is only partially effective may be better than nothing or it may give a false sense of security: either way, the auditor will probably not be entirely impressed. Personal integrity is a core value for auditors. Our grit is true.
System of controls - different types of control operate at many levels. IT auditors work with technical controls built-in to the computer systems, of course, but also procedural controls (operations procedures etc.), legal controls (software licenses etc.), Human Resources controls (employment contracts, disciplinary procedures etc.) etc. These controls may be preventive (‘You can’t do that’), detective (‘I know exactly what you did and I’m really not happy about it’) or corrective in nature (‘Sort that bloody mess out, quickly, and don’t ever let it happen again’).
Recommend - auditors generate “audit recommendations” but despite appearances have neither the authority to implement suggested changes nor can we force management to do so. We achieve improvements mostly by a process of explanation, justification and persuasion, explaining the risks represented by control weaknesses, justifying the need to change systems and/or processes, and persuading management to apply the necessary resources and direction in order to address the risks. As a last resort, audit’s big stick is political clout, a.k.a. friends in high places. Steadfastly refusing to sign off the company accounts without an adverse audit comment, no matter how carefully crafted, has a strangely galvanic effect on most CEOs.
Control improvements - improving the system of controls generally means adding necessary controls that were missing, or at least improving those that were in place before the auditors started poking around. In very rare cases, auditors may actually recommend removing controls, generally because they are ineffective, disruptive or wasteful but this concept is so counter-cultural that Heads of Audit take a lot of persuading, I can tell you.
Limit - risks, like fraudulent politicians, porn, spam and bugs, can be reduced but not totally eliminated. Good business involves minimising unnecessary risks cost-effectively and being prepared for the worst if, despite everything, things go wrong (contingency planning). Paradoxically, it also involves taking calculated risks or exploiting opportunities to make a profit or other objectives - the key word being ‘calculated’. If you have a fool-poof way to calculate the net effect of information security risks and controls, tell me privately and I’ll patent it.
Risk – to an auditor - is the chance that something might go horribly wrong to the organization, mostly. In an IT or information processing context, risk is the chance combination of threats (usually caused by someone with malicious intent, sometimes just due to carelessness, incompetence or rotten weather) acting on vulnerabilities (weaknesses in ‘the system’, typically exposed by a lack of controls in the computers and associated procedures) to cause business impacts (adverse outcomes i.e. financial, human and political fallout when the brown stuff hits the fan). Formally, risk has an upside too (see previous bullet point).
Here’s another view: auditing is a mechanism for examining the effectiveness of organizations, systems, processes, risks and controls. Audits enable management, owners, regulators and various other stakeholders or interested bystanders to:
Discover what’s really going on in the organization at a point in time;
Reveal and substantiate potential problems or risks, hopefully before it’s too late to avoid, fix or at least learn from them;
Evaluate business situations, decisions and opportunities objectively and rationally;
Face up to the truth and make informed, if difficult decisions;
Implement corrective actions, changes and improvements where needed;
Do what they really wanted to do all along but didn’t have the nerve to carry off (provided, that is, the auditors agree!);
Sleep more soundly ... in the end.
Yet another fascinating perspective on IT audit: “An IT Auditor often is the translator of business risk, as it relates to the use of IT, to management, someone who can wade through the technical morass well enough to understand the risk (not necessarily manage the technology) and make a sound assessment and present risk-oriented advice to management. To me the key word is translator, someone capable enough in business strategy and policy and in technology to provide a sound assessment of the risk environment.” (thanks to Jim Dillon for that pearl of wisdom).
For the last, final and ultimate word on this subject, read the IIA’s FAQs about the profession of internal auditing, governance And All That.
What’s so interesting about risk and control?
Risk and control are what makes auditors of all persuasions tick ... much like cartoon bombs.
The independent eye can often see risks in a situation that those intimately involved with it either cannot see or cannot face. With training and experience, auditors come to appreciate that risk is not a purely theoretical concept – bad stuff really does happen sometimes. This is what gives auditors a bad name. If an auditor sees a boy taking his first tentative ride on a new bicycle, he sees the potential for grazed knees. His father sees a supreme athlete. His mother sees her little boy leaving home. This sense of perspective and foreboding is what distinguishes a good auditor, or indeed an information security professional from a cynic. It gives auditors something in common with insurance salesmen, weather forecasters and soothsayers. IT auditors genuinely believe that the lottery is, in reality, a tax on the numerically-challenged.
Controls help to minimise risks. The insurance man expects his client to install pick-proof locks as a condition of insuring against burglary. The auditor tries to persuade management that fitting a shiny new 5-lever mortise lock on a rotten door is a false economy. He understands that the insurance man sees the sales bonus, the manager sees the hole in his budget, the carpenter sees the hole in the door and the burglar sees a business opportunity.
At the same time, the auditor needs to recognise that business is about profit. Bad managers don’t appreciate the risks, take risks with little thought as to the consequences, or live in hope of being long gone before the brown stuff hits the fan, or they conversely avoid taking perfectly acceptable risks because they misunderstand and inappropriately fear the consequences. Good managers will often push the boundaries by cutting corners and deliberately taking acceptable risks in order to minimise costs and maximise net gain, but first they make the effort to understand what they are getting into. Outstanding managers consistently make good calls at the perfect time, consider the potential downsides and often have contingency arrangements just-in-case.
This line of reasoning introduces the issue of the cost of control. We all know first hand that controls are a pain. Login controls, for instance, interfere with our legitimate use of technology. Controls are costly to specify, implement, manage and maintain. The obvious problem when designing, implementing, managing and maintaining a system of controls is to strike a balance between the cost of control and the cost of impacts resulting from risks that materialise. The real issue is that the costs we are supposed to take into account are not hard-and-fast facts, which brings us back to commercial judgement and net benefit: “Can I expect to save more by implementing control X and reducing the incidents, than I would save by not implementing control X and suffering the incidents?”
The bottom line here is that auditors inevitably take a greater interest if the stakes are high. “Let’s implement an Enterprise Resource Planning system” rates somewhat above “We need to update the overtime spreadsheet” in the grand scheme of things.
Isn’t it really just accounting?
Um, well no, not really. Honest. An IT auditor might be asked to review certain aspects of accounting within the IT department (e.g. financial management of IT projects, budgeting or forecasting) but that kind of assignment is more likely to be performed by a conventional internal/external auditor or accountant with a recognised accountancy qualification. The study of an organization’s financial/management accounting system would typically be done by an IT auditor (checking the technical design and operation of the system) and/or an accountant (checking that the system was being used correctly, accounting rules were being followed etc.): the most effective audits on accounting and other financial systems employ auditors with both IT audit and accounting qualifications, or mixed audit teams containing both, like oil and vinegar with just a dash of mustard to stop them separating. [The same thing applies to audits involving other specialist IT e.g. process control/SCADA/ICS, medical, engineering and safety-critical systems, and cloud computing: the risks of concern go well beyond your bog-standard IT textbook stuff].
Is it anything to do with counting PCs?
No! Absolutely not!! Unless, that is, the count is necessary to substantiate a suspected control failure e.g. a stock check in the store room if someone may have been stealing PCs, or if there are more PCs than licensed copies of operating systems … IT auditors don’t normally count boxes, in the same way that other auditors and accountants don’t usually count beans (even if they do work for Heinz). That said, certain recruitment companies persist in advertising “PC audit” jobs that turn out to be assignments for school-leavers to count PCs and check software licenses. Applicants’ intellectual capacity is presumably less important than their dress sense. Here’s a classic example: “Large IT service provider are urgently looking for Audit Engineer to cover site tonight from 4.00pm until midnight. Must be able to start tonight. Call for more information.” [Having spotted this genuine vacancy notice, I was sorely tempted to get some new business cards printed: “Gary Hinson, IsecT Ltd., Emergency IT Auditor. 24x7 mobile callout, no job too small or too large. Own overalls and grubby white van.”]
What do IT auditors audit against?
All audits are performed in relation to certain Risks identified by the auditor which he/she believes are important (“material” in the lingo, in other words “things that would keep the shareholders up at night if they ever found out”). Analysis of the Risks leads to the definition of Control Objectives: for example, the auditor might be concerned that a finance system could be modified by unauthorized persons, so would determine that there is a Control Objective to <ahem> Prevent unauthorized people meddling with the finance system. Occasionally it really is that simple.
The specific Controls that are actually embedded in or associated with IT systems and processes are then assessed to determine whether they adequately address (“mitigate”, “reduce”, “minimize”, “avoid” or otherwise make insignificant) the Risks, meaning that they satisfy the Control Objectives. The specific Controls that the auditor looks for are typically derived from the auditor’s experience, although there are often many alternative controls that might be adequate to satisfy the Control Objectives in a given situation: the auditor should be reasonably happy with almost any Control so long as the Risk is adequately addressed, although there are advantages and disadvantages to certain Controls over others that may make them more or less attractive. And, let’s be honest, security is relative not an absolute concept. ‘Adequate’ is more relative than absolute. So long as the Controls are Good Enough to address the Risks, that should be fine. Many lengthy and impassioned arguments stem from the ambiguity in that last statement.
A common way out of this, um, mess is for the auditor, instead of looking for what he/she believes should be in place, to look for Best Practice Controls. Best Practice is an interesting concept in itself that raises yet more questions. Who defines Best Practice, and on what basis? What gives them the authority anyway? And if I have some other non-Best Practice control, is that necessarily A Bad Thing? If you have a control that is better, in your context, than my control in my context, which is Best? [Before you ask, yes we could call them Good Practices or Commonly Accepted Practices or Commonsense Practices or The Prevailing Wisdom or whatever, but changing the terminology doesn’t affect the core issue of context.]
Anyway let’s look at the available sources of Best Practice.
One of the most obvious sources of Best Practice for information security is ISO, the coordinating body for most of the world’s national standards bodies. For example ISO/IEC 27002, the Code of Practice for Information Security Management, is part of a coherent and growing suite of information security standards (the ISO27k series) that is being actively developed and extended. In information security, Best Practice is definitely not a static goal.
There are several other sources of infosec Best Practice:
National standards bodies such as BSI, ANSI and NIST issue lots of carefully-considered guidance on information security and related areas that could be considered Best Practice, at least within the specific scope of their intended applications;
Professional bodies such as ISACA
also document and promote infosec Best Practices. The CISSP CBK (Common Body of Knowledge), COBIT
, the Information Security Forum’s Standard of Good Practice in Information Security Management (once free, now incarcerated for its own protection) are examples of generally agreed standards of Best Practice, though whether any given individual agrees with any or all of them is a moot point;
Some industry bodies define their own information risk and security related standards too e.g. PCI DSS (whose true purpose is probably more to do with risk transfer than risk reduction);
Governments and legislatures define standards in the forms of laws and regulations for electronic signatures, copyright, privacy, governance etc. Some of these are truly mandatory (comply or go to prison), most are highly recommended (comply or risk going to prison), some are merely advisory (comply or risk spending a fortune on lawyers and media coverage defending your position) and a few are collecting dust on the shelves like far too many corporate security policies;
Some companies define and mandate their own internal best practice or baseline standards: this tends to happen in large group structures, especially multinationals where <shock horror> “foreigners” are doing security “overseas”;
Consultancies such as KPMG, PwC, E&Y etc
. typically have their own interpretations of security standards but are increasingly using ISO/IEC 27002
and the like as the benchmarks, supplementing professional auditing standards defined by the IIA, audit/accountancy trade bodies and regulators such as the PCAOB;
Information risk, security and audit professionals (CISSPs, CISMs and others) typically have in their heads their own unique professional experiences, some of which they genuinely believe to be best practices. We could argue all day about whether they truly are best, good or indifferent according to the professional’s volume (length, breadth and depth) of experience but in some happy cases, they actually are. This is in the nature of a skilled craft - the craftsman brings his own individual mix of skills, competencies, attributes and experience to each job, and is well placed to select and adapt generic standards to the task at hand. The craftswoman brings her own unique mix too but in a prettier package. However, beware the advice of recent college graduates without Real World Experience, some of whom scored higher on theory than common sense. And you’re right to be distinctly wary if not cynical about anyone professing to know The Answer, especially if he/she has spent a lifetime in one industry, or for that matter on hundreds of “assignments” lasting no more than a few weeks. If she/he/it can’t eloquently and convincingly explain why her/his/its preferred solution is better than all the others (for authentic reasons that it/she/he can also describe in some depth), then don’t feel bad about preferring generally accepted good practices instead.
Auditing is just compliance testing, right?
Not exactly although some senior auditees would find it convenient to lock it in this particular box, since they can declare that anything not explicitly related to a stated requirement is Out Of Scope (no matter how valid, interesting or concerning it may be). Many audits do include an element of checking that someone or something conforms to “the rules”, whether that’s internally-generated corporate policies/standards/procedures or externally-imposed laws, standards, regulations and contractual terms ... but compliance is really management’s day job. Auditors are more inclined to check whether management’s mechanisms are successfully monitoring and achieving compliance, and that “the rules” are suitable and sufficient, and so on. They mostly see compliance failures not so much as findings as symptoms of deeper problems, indicators of diseases worth probing in more depth.
Software license audits are a classic illustration of the compliance aspect. Auditors will naturally look for and report unlicensed software. Depending on scope, they may also examine and report on the organization’s processes for managing software licenses, for procuring software, reallocating licenses when people leave, licensing corporate software to third parties, controlling valuable intellectual property and all manner of other things, perhaps even the corporate stance on “ethics”. The auditors might trace the origin of the unlicensed software to understand why the control processes failed (this is one reason why auditors are turned on by good audit trails). Undeniable evidence of a few unlicensed copies of Office may be insignificant in the grand scheme of things but might be exactly the lever necessary to get management to wake up and smell the coffee, then fix a broken IT asset management system. It’s all a matter of risk.
That said, finding twenty seven thousand unlicensed copies of Debbie Does Dallas stashed in a secret DVD duplication facility at a Far Eastern subsidiary would probably be another matter entirely, a different kettle o’ fish as we say ...
The formal certification audits conducted by accredited auditors against standards such as ISO/IEC 27001 and PCI-DSS are just straightforward compliance tests, which is why the standards are written in such formal, stilted language with the intention of leaving no wriggle room whatsoever for both the auditors and the auditees. Don’t make the mistake of presuming that certified organizations are actually secure - oh no, they were merely sufficiently compliant to have convinced the auditors of that fact at some point. Worse still, the scope of the certification may cover only a specific and perhaps minor part of the organization. “Joe, over there, yes he’s the bloke who was ISO/IEC 27001-certified. The rest of us honestly couldn’t care less. We don’ need no steenking cert.”
How does IT audit fit with governance, risk management and information security?
For more than a decade now, governance has been a genuine solid-gold buzzword, essentially referring to the overall direction, monitoring and control of the corporation as a hole. Governance can be considered at various levels such as broad pan-organizational controls (corporate governance) or controls over individual projects or systems (project and systems governance). Similarly in respect of risk management, the scope can apply across the entire enterprise (taking in commercial, operational, market, financial, regulatory and other risks) or just to specific business units, projects, systems, departments or whatever.
Governance is also a mechanical principle. The governor on a steam engine uses two brass spheres spinning around a central valve. The quicker the engine runs, the wider spheres swing, thereby closing the steam valve. In other words, governance takes balls.
In relation to Information and Communications Technology (ICT – another buzzword), proactive risk management generally implies the need to design and implement appropriate technical, procedural and physical controls, in other words information security control systems which are part of governance.
Information security managers develop, implement and operate information security control systems for ICT governance. IT auditors review ICT governance/control systems in order to ascertain whether risks (including information security risks) are minimised. These may sound similar but are fundamentally different rôles: information security managers have executive responsibilities for securing the organisation’s information assets against hackers, malware and other threats whereas IT auditors are irresponsible (if you get my drift). Auditors review, advise, report and persuade. Executive managers ‘execute’ … and carry the can. The common ground is minimisation of risks.
Whilst that may be reasonably straightforward in theory, there is a lot of confusion about the terms in practice. The term ‘governance’, for instance, is often used as shorthand for ‘corporate governance’. ICT controls may be an important part of corporate governance, especially in organizations that are critically reliant on information processing, but there are many other types of control that fall well outside the scope of ICT (e.g. the use of non-executive directors to review and guide executive management).
For a rather formal perspective on the relationship between auditing and governance, read the Public Company Accounting Oversight Board (PCAOB)’s Auditing Standards. ISACA is also pretty strong on this stuff.
Good IT auditors have a solid understanding of the practicalities of implementing their recommendations, yet are able to push certain auditees beyond their comfort zones, with a big pointy stick or electric cattle prod if absolutely necessary.
Go back to contents mind map
How is an IT audit performed?
This section describes the phase that auditors call execution. Luckily, there is seldom any actual blood-letting involved in the process, though at times it can be tempting ...
“How do they do that”?
Audits typically follow a logical sequence vaguely approximating this black-n-white GANTT chart/timeline:
However, different organizations go about IT auditing in different ways and individual auditors have their own favourite and often far more colourful ways of working. Purely for the sake of illustration, you understand, the main stages of a ‘typical’ IT audit assignment have been extensively analysed by our crack team of experts and professionally illustrated by a highly-qualified graphic artist as follows:
Scoping and pre-audit survey
- the auditors determine the main area/s of focus and any areas that are explicitly out-of-scope, based normally on some
form of risk-based assessment. Information sources at this stage include background reading and web browsing, previous audit reports, the Head of Audit’s Little Back Book and, sometimes, the auditors’ subjective impressions that something simply deserves further investigation (a.k.a. gut feel or Auditors’ Nose Syndrome).
Planning and preparation
- during which the scope is broken down into greater levels of detail, usually involving the generation of an audit workplan or risk-control-matrix (don’t be fooled, it’s only a fancy checklist with a bunch of interesting questions, space to scribble some notes and some other impressive-looking columns).
- gathering evidence by interviewing staff and managers, reviewing documents, printouts and data, observing processes in action etc
. This step may include the use of Computer Aided Audit Techniques (CAATs) - more info below
- this step involves desperately sorting out, reviewing and trying to make sense of all that evidence gathered earlier. SWOT (Strengths, Weaknesses, Opportunities, Treats) or PEST (Political, Economic, Social, Technological) techniques may come in handy. It often involves retracing one’s steps, going back to the previous steps in an attempt to either fill-in or divert-around unfortunate holes and inconvenient inconsistencies in the gathering dossier of evidence.
- the biggest step involves desperately reviewing and trying to make sense of the evidence and the analysis, figuring out how to relate what was actually examined and found back to the original audit objectives, then gradually writing it all up, re-writing it, re-re-writing it ... circulating it within the department for peer review, modifying it again, then circulating or presenting it to clients and client managers to have their say, making final corrections, and finally issuing it. Read ahead for more on this step.
- in addition to sorting out the mess somewhat mistakenly called ‘indexing and cross-referencing’ and literally shutting the audit files, closure involves preparing notes for future audits, chasing-up management to complete the actions they promised months earlier, and . This is ‘closure’ in the sense of finding and burying the bodies of loved ones. Neither the best nor the worst organizations do audit follow-ups, in both cases because there is literally no point.
Most organizations however do need to ‘close the loop’ (as in ‘form the noose’). Sometimes, there really are valid reasons why previously-agreed actions are not undertaken (one of the most common excuses being “Things have moved on”). Sometimes a quiet word in the CEO’s ear about the consequences (in terms of share price, career progression or jail sentence) if certain governance issues are not promptly resolved can work wonders. At the end of the day, Management not Audit carry the can (except perhaps for Arthur Anderson LLP
as a result of the Enron
Steps 3 and 4 may on occasions involve the use of automated data analysis tools such as ACL or IDEA, if not MS Excel (perhaps with bolt-on-goodies such as TopCAATs), Access and hand-crafted SQL queries. Even Notepad.exe comes in handy on a bad day. These can help sift through vast amounts of data on a system to identify problem areas such as out-of-range values and Things That Simply Don’t Add Up (aka the Fishy Smell Test). Automated system security analysis, configuration or vulnerability management and security benchmarking tools are also a boon for reviewing security parameters, and of course basic security management functions that are built-in to modern systems can help with log analysis, reviewing user access rights etc. IT auditors have big toy boxes overflowing with shiny toys and clever things that go ‘ping’. See the section below on CAATs.
Step 5 - Reporting - is the official focus of the audit process and a great deal of attention is paid to it by both auditors and auditees. It is an involved and convoluted sub-process all by itself.
The wise auditor starts by converting his/her/its thoughts that have been quietly brewing or festering throughout the fieldwork and analysis phases into rough notes and reviewing them against the checklist and evidence while the thoughts are still fresh and there are opportunities to snoop further. He/she/it aims not just to record the literal facts, but to frame and interpret them in order to influence or motivate the reader to make changes that will improve the organization (whatever ‘improve’ actually means in the context of the audit). Sometimes it helps to think like a journalist, asking “What’s my angle?”.
The unwise auditor simply finishes the fieldwork and starts writing. Anyway, somehow the audit findings are expressed, summarised and analysed, and tentative recommendations are made in the First Draft Report.
Audit’s fabled quality control process then springs lithely into action, in other words the First Draft is savaged by more seasoned campaigners of the Audit function and rewritten by the auditor with their ‘assistance’ until it barely resembles the original draft. Remember, editing is a rewording activity. Someone sometimes checks that ‘everything reportable is reported and everything reported is reportable’ which fancy words mean a file review. The audit manager/reviewer looks at the evidence, discounts much of the auditor’s analysis due to their ‘inexperience’ and (in the back of his mind) rewrites the Audit Report in his/her own inimitable style. The red-penned draft report is handed back for yet another round of ‘slight revision’ and so the game continues through even more tedious episodes than American Idle.
When at last everyone in Audit is thoroughly sick of it, the Final Draft Audit Report is sent for its first external review by, or is presented to, the auditees ... and then the real battle commences. The findings and evidence are challenged. The analysis is challenged. The scope is revisited. The so-called ‘laws’ of physics are called into question. Every phrase and nuance is challenged. The speling is challenged. Even the punctuation, font and font size are challenged. The quality of the paper and excessive margins are challenged. Challenges are challenged. The auditor’s competence is challenged. Even his/her parentage may be brought into question if things really get nasty. [I bet this was a challenging process when the US Department of Health and Human Services (HHS) was audited by the Government Accountability Office (GAO), judging by the HHS comments after the report was published: “The frequent use of the word ‘significant’ to describe control weaknesses documented throughout this GAO assessment evokes a negative connotation that is not reflective of the progress or current state of HHS’ information security program,” according to the HHS response. Can’t you just picture those long, tedious, intense yet largely unedifying discussions about the unwelcome and undeserved implications of the word “significant”?]
The actual issues and recommendations are blithely ignored as long as humanly possible until, eventually, cold hard reality finally starts to dawn. Shock! Horror! The indignant auditees are being asked to change! And maybe, just maybe, the auditor has a point. This realisation is often a trigger to revisit the findings and analysis and to perhaps challenge those split infinitives just for good measure. Frustration mounts. Tempers fray. The full-and-frank discussion continues apace. Gallows are prepared. Clandestine meetings are held in dimly-lit corridors between senior auditees and senior auditors to reach a negotiated but fragile settlement not unlike the Gaza Strip. And so, eventually, the Final Final Final Definitely The Last Draft Ever becomes Issued with a dull thud, ripple, splash or fireworks depending on the reception it receives.
To auditees, I say “Get a life. Deal with it. You know it makes sense.” To auditors, this: “Walk a mile in a man’s shoes before criticising him. That way, when you voice your criticisms, you’re a mile away ... and you still have his shoes.”
By the way, there’s also a step 0 (the first ordinal number for IT geeks everywhere), namely the audit scheduling/planning step. Like babies, audits don’t just happen. Someone somewhere makes a decision to ‘look at situations X and Y this year but leave Z until next year’, according to their assessment of the risks in X, Y and Z. “How do you know the risks if you don’t examine them first?” I hear you ask. Good question Einstein! That’s why there are high-level and low-level audits, periodic audits, and management requested Special Investigations. Oh and Fudge Factors in risk-based audit planning tools. It’s also why Audit Directors and Heads of Audit keep those Little Black Books locked away in their desks. Upset the guv’nor at your peril.
How long does an audit take?
It takes precisely the period of time between the start and the finish. To calculate this, simply enter those dates and times into a spreadsheet and have the spreadsheet calculate and display the difference. Easy.
In our limited and distinctly cynical experience, the complete sequence of events for a discrete audit assignment normally takes months from start-to-finish, almost regardless of the amount of time spent actually doing the fieldwork and analysis. The reporting and closure phases are often very drawn out, especially for those audits that are too broadly scoped, reveal particularly unwelcome news or recommend substantial changes. Conversely, narrowly focused audits on uncontentious material may be completed in just a few days … but then one would have to ask why such audits are ever performed as audit resources are normally best directed to investigate high-risk and generally more controversial issues.
As a rule of thumb, roughly equal amounts of elapsed time should be allocated to each of the six or seven steps noted above. For the arithemetically-challenged, that means an audit planned to include about a week of fieldwork will take approximately six or seven weeks in total. At a push, it is possible to do a complete audit start-to-finish in a week provided you don’t expect more than about a day’s actual fieldwork. And the auditor works a six or seven day week. Or very l o n g days. Geddit?
Progressive organizations audit their IT development projects and other major change projects throughout the project lifecycles, from cradle-to-grave (well from inception to Post Implementation Review at least). The auditors typically sit-in on project management meetings, observing and quietly commenting or mentoring where it helps. In these cases, audits last as long as the projects in elapsed time but hopefully consume just a few percent of the total project man-days and biscuits.
What questions should an auditor ask?
Here’s a fairly typical query from someone who has read this FAQ and wants to give it a go themselves: “I’d like to know more about the specific questions that an auditor should ask a Systems Administrator about the types of system/application access controls in an application. I have compiled a brief list of questions that I think I would like to ask my systems administrators however, I don’t want to miss anything important ...” And here’s our response:
First of all, I’d suggest that the best way to start is to conduct some form of risk assessment as a starting point to your audit/review (it’s only an audit if you are truly independent of the area under review). You can use a formal risk assessment method (there’s plenty to choose from) but personally I prefer simply to think carefully and separately about the threats (generally the people, things or situations that could potentially cause loss), vulnerabilities (any weaknesses in the system of controls that might be exploited by threats) and impacts (what would be the [worst case] effects if some of those threats actually materialized and hit some of your vulnerabilities?), or to contemplate the likelihood and severity of various incidents. An interesting way to do this in practice is to brainstorm, perhaps with a colleague who understands the situation you are reviewing, someone who knows about risk and control (an experienced auditor or information security/risk manager, maybe a consultant), and ideally someone representing the business/IT owner(s) of the system under review (this person will probably end up being your main ‘client’ contact on the audit, and they will understand what’s driving you to ask lots of awkward questions later on). You can safely ignore the ‘low’ threats, vulnerabilities and impacts, and you can probably set aside the ‘mediums’ too for now. As any hippie will tell you, you should definitely prioritize the ‘highs’ for obvious reasons. These are the things that would keep you, the system owners, the CEO, the shareholders, the business partners and the regulators (if only they knew!) awake at night. They are the main areas of concern that you will need to explore in the actual audit fieldwork.
Next, I like to develop some reasonably realistic, business-oriented scenarios in which the high risks could conceivably come to pass. These help me think-through the risks and are helpful if, later on, people start pushing back when I’m asking those awkward questions. “Just imagine this ...” I say. Audits on well-established IT systems and processes often have the dubious benefit of drawing on a long, painful history of actual security incidents - so incident records and reports may be another source of ammo.
Next, develop your ‘audit checklist’, ‘workplan’, ‘mind-map’ or whatever you use to figure out and structure the things you want to check, the issues that concern you, and the boundaries or scope of your audit. This is an important step, drawing on the control objectives and specific controls that you are going to go looking for. Use coloured crayons if that helps.
After all that preparation (which the auditees generally never see and don’t appreciate), the actual audit fieldwork is quite straightforward! It’s time to gather your evidence, ask questions, take copious notes, explore the threats/vulnerabilities/impacts, check the controls, challenge things that seem suspect, ask more questions, look for evidence that the controls are actually working or not, think hard and ask the really awkward/tough questions that nobody wants to answer, and generally probe around, following your nose until the time is up.
The hardest bit of all involves taking all the information from the previous steps into account, thinking it over, checking the details and making sense of it in your head, then developing rational arguments for why Something Must Be Done. This is the primary output of the audit - the impetus for change.
The last bits are to prepare a draft report, decide on some recommended changes, discuss/negotiate these with the client, update the report and finally present and ‘issue’ the report. Easy peasy ... OK not really, but not too hard if the previous steps have been done thoroughly. You should be in a strong position to argue your point, but even now you sometimes need to be prepared to concede weaker points in order to push through the key ones, and always be prepared to go back and ‘take another look’ if someone insists you have got a fundamental point or finding wrong. Occasionally they are correct: trust me, it’s better to discover the error of your ways than later, in a heated audit meeting, when the CEO reaches that peculiar shade of purple.
And if that’s all too much for you to take on, find yourself a real IT auditor
but stick to them the way non-stick paint sticks on a frying pan so, next time, maybe you’ll have the nerve to fly solo.
OK, now to address your original question. You’re asking me to go directly to step 3 and come up with specific audit questions to ask your sysadmins about access control on a system of which I have no knowledge at all. Sorry, no way Jose. If you want to do a good job and be reasonably certain of not missing any serious risks, you really need to start with steps 1 and 2 above to figure out your own questions. Cutting but true.
What is the scope of IT audit?
The scope of a particular IT audit is normally defined by the scoping document produced near the start of the assignment. Typically it relates to certain key risks of concern to management that centre around the computer and/or telecommunications systems. The scope of an audit assignment is normally a balance between breadth (i.e. the range of matters to be reviewed) and depth (i.e. the amount of detail reviewed in each matter). Sensible audit plans allow for a bit of both through mixing broadly-scoped high-level audits (designed to find the most important risk areas) with narrowly-scoped in-depth audits (to give those pesky high risk areas a thorough going-over), and clever audit managers allow staff to blow the budget on certain jobs that somehow deserve more time. It takes a brave audit manager to accept that an audit finding nothing reportable should be stopped early but it does happen, when the planets align and the moon turns blue.
The scope of IT Audit, the function, is hard to define as it depends on the size and make-up of the audit team: in large teams, IT Audit may have a number of dedicated, specialised and qualified staff solely responsible for technology auditing, but more often the IT auditors are expected to contribute to other types of audit (and vice versa). In really small, unenlightened audit teams, it is not uncommon for the IT auditor to be treated as the Ravenous Bugblattered Beast of Traal.
The scope of the IT Audit function is defined by a combination of factors, including:
The remit of the Department (for Internal Audit) or the contract (External Audit) in relation to other review and control functions (e.g. information security, risk management, legal/compliance);
Audit resources i.e. the number of IT auditors, other auditors and their managers, plus the breadth and depth of their experience in IT audit (e.g. in some departments, IT-skilled business auditors cover a lot of areas that would be left to IT auditors elsewhere);
Scope of the individual IT audit assignments;
The audit plan for the period - usually documents the high-risk topics the auditors are likely to cover;
State of relations with client functions. Whereas some departments refer to formal definitions and relations remain distinctly frosty or strained, audit-friendly or audit-tolerant folk tend to be more chilled-out to the extent that auditors may occasionally be called upon to perform conventional (internal) consultancy rôles. [This is as much down to the way the audit function operates as the prejudices of auditees. Truly effective audit functions earn their stripes by being consistently thorough and professional, firm but fair. A bit of internal marketing by the Head of Audit and indeed Audit Managers and even lowly auditors can definitely improve audit’s brand. In other words, don’t fret if you hear an auditor stating their wish to “brand someone” ...]
Typically, however, the IT audit function covers the following areas:
Operational computer systems (servers, workstations), networks (LANs, WANs) and data;
Computer systems under development and/or being tested, implemented, configured, patched or retired/replaced;
The IT Department whether central or distributed and their relationship with management, user departments, end-users, support/admin functions (e.g. Human Resources, Legal), customers, suppliers, partners, regulators etc.
In each case, IT audit resources are primarily directed towards high-risk situations (e.g. business-critical applications that may be reviewed annually), although lower-risk areas may be audited “on a less frequent basis” (don’t you just hate that hackneyed phrase? What I really mean is infrequently, perhaps reviewed on a 3 year cycle, soon after an ‘incident’ or ‘breach’, or more prosaically ‘when senior management finally notices that an important company system or department has never been independently reviewed
and is a pile of poo’). There is an important point here: audit should align itself with risks that should be of concern to the organisation, plus or minus fudge-factors.
What is the difference between Internal and External (IT) audit?
Cynical answer: “Externals have leather seats in their cars” ... in fact the main distinction is the degree of independence from the organization being audited.
External Auditors are always employed by a separate organization and are normally contracted by the client to perform audits as part of the process of preparing formal company accounts, or for accredited certification purposes. In practice, External Auditors are mostly employed for a few months a year to examine and provide a formal opinion on the veracity of the organization’s financial accounts. Their formal opinion is normally presented in a highly-stylised form in the organization’s annual report to shareholders. IT auditors working for an External Audit company engaged on financial audit work are primarily concerned with integrity of the client’s core financial data and accounting systems (general ledger etc.) and other important systems involved in generating and processing financial records (e.g. sales order processing systems). They read SOX for kicks.
Internal Auditors, by contrast, are permanently employed by the organization to examine and comment on its control systems and processes on an ongoing basis, although (as noted earlier) they do not normally report to the organization’s conventional executive management structure. [Some organizations outsource Internal Audit to external consultancies but this merely clouds the issue and gives the auditors ridiculous business cards.] Their remit usually extends well beyond the core financial systems, encompassing the broader systems of corporate governance (also known as ‘management controls’). In some organizations, the External and Internal Auditors have separate but complementary areas of scope: External Auditors primarily cover the core financial systems whilst Internal Auditors primarily cover the remainder. In most cases, however, the two functions overlap, working together on some parts. They wear socks for kicks.
Certain External Auditors like to sell consultancy services to their audit clients but this creates an interesting moral dilemma and a governance paradox. “As your game-keeper, I’m delighted to recommend the services of my favourite poacher …”. Decent regulations and certification schemes forbid this.
Another way of considering internal/external audit is to think of black box versus white box testing. External auditors have limited internal knowledge of the organization, just as black box testers start with only a general understanding of the application systems they test. This gives them no choice but to deal with what they find as they find it, being essentially in the same situation as external hackers. Internal auditors have much greater knowledge of the organization, just as white (or crystal) box testers have access to application system specifications, designs etc. They are akin to internal threats, but in the nicest possible way you understand.
What are the main types of IT audit?
Operational computer system/network audits: review the controls within and surrounding operational computer systems and networks, at various levels e.g. network, operating system, layered software, application software, databases, logical/procedural controls, preventive/detective/corrective controls, crypto, logging ...
IT installation audits: take a look at the computer building, suite, room or cupboard, including aspects such as physical security (walls, CCTV, locks, guards, barbed wire, visitor procedures ...), environmental controls (fire and flood protection, power supplies and UPSs, hair conditioning), computer and network operations processes and management systems, oh and the IT equipment itself.
Developing systems audits
: typically cover either or both of two aspects: (1) project or programme management controls (often, the auditor is the only person with the knowledge, experience and
nerve to point out that the average project manager’s progress reporting is “somewhat optimistic” at best); and (2) the specification, development, testing, implementation (installation and configuration) and initial operation of technical and procedural controls, including classical technical information security controls and the related business process controls such as divisions of responsibility. Read more about these audits below
IT management or governance audits: review the organization, structure, strategy, work planning, resourcing, budgeting, cost controls etc. and, where applicable, relationships with outsourced IT providers (in some cases, these aspects may be audited by operations and financial auditors, leaving the IT auditors to the more technological aspects, although mixed teamworking can be more productive and insightful).
IT process audits: review the processes which take place within IT department such as application development, testing, implementation, operations, maintenance, housekeeping (backups, preventive maintenance etc.), support, incident handling.
Change management audits: review the planning and control of changes to systems, networks, applications, processes, facilities etc., including configuration management, control over the promotion of code from development through testing to production, testing and acceptance, and (often more importantly) the broader management of changes to the organisation, business activities, relationships and risks as a result of new technology.
Information security & control audits: review the controls intended to ensure the confidentiality, integrity and availability of systems and data.
IT compliance audits: review legal and regulatory aspects of IT systems (e.g. copyright and other intellectual property rights, privacy and protection of personal data, and contractual obligations such as PCI-DSS) and/or compliance with corporate policies, standards and other missives from management
ISMS internal audits:
periodic audits of an organisation’s Information Security Management System are an important part of checking security performance and driving security improvements which is of course why the ISO27k
standards mandate ISMS internal audits.
: compliance with information security standards such as ISO27k
and industry standards such as PCI-DSS is normally audited by IT auditors working for accredited certification bodies. Formal certification audits typically have strictly defined scopes, but the auditors may be persuaded to open up a little in pre-audits or post-audit drinks at the bar, to find out what they really
Business continuity management audits: review the resilience, recovery and contingency arrangements intended to restore some semblance of normality after a disaster affecting the IT systems, and perhaps assess the organisation’s approach to risk management, reviewing the links between (a) identifying and protecting critical business processes, and (b) securing the supporting IT services, systems, network and processes. Business continuity audits are especially important if there are any lingering traces of doubt as to the validity of the tests and exercises that should be performed routinely, since the residual risks could lead to an unmitigated disaster, literally.
IT strategy audits: review various aspects of IT strategy, vision and plans, including their relationship to other strategies, visions and plans, or not as the case may be. Video clips of managers scribbling furiously on whiteboards and waving their hands about are worth a thousand audit words each. If the strategies cannot be clearly and eloquently described, drawing out the points of alignment with and support for the business as a whole, that is a deeply troubling finding in its own right.
“Special investigations”: this is audit-speak for contingency and other un-pre-planned or hush-hush work such as investigating suspected frauds or information security breaches, performing due diligence reviews of IT and other information assets for mergers and acquisitions etc. Oh and it’s the official Time Management System code for things connected with the departmental Christmas party.
By the way, if you find it mildly disturbing to think of auditors enjoying a party, perhaps you should re-examine your prejudices. Contrary to appearances, auditors are human beings. Those who still possess it like to let their hair down occasionally. There’s no harm in a bit of drunken revelry - so long as there is no forensic evidence anyway.
What do we feed the CAATs?
CAATs don’t have fur and whiskers, don’t scratch and don’t poop in the neighbour’s garden. CAATs are tools/utilities to help auditors select, gather, analyse and report audit findings. Starting with the basics, many computer applications have useful built-in data analysis/audit facilities. Out of the box Microsoft Excel, for example, has functions for tracing dependencies between cells, sorting data ranges etc., with a more extensive range of functions (Benford’s law analysis, random selection etc.) being added by proprietary bolt-ons such as TopCAATs. Database programs typically have custom reporting facilities (often allowing the use of SQL to construct queries on-the-fly) and sometimes include pre-configured reports intended for use by auditors (these are usually written for specific applications such as SAP). Practically any specific database auditing queries can usually be crafted in SQL if the auditor has the expertise and access rights - by far the most important skill being the ability to construct meaningful questions in the first place. Specialised CAAT tools such as ACL (Audit Control Language) and IDEA (Interactive Data Extraction and Analysis) include libraries of prewritten queries to ask typically meaningful questions on data sets. Other utilities such as WizRule help explore complex data sets and applications.
Here are the sorts of questions an IT auditor (or an ‘ordinary’ auditor working on a computer system) might want to ask:
What were the top 10% of transactions by value last March?
How many changes were made to the customer details file during the previous year?
Are there any out-of-range or unusual data values in column 4, or any suspicious data patterns?
Do any of our suppliers’ addresses, contact or bank details coincide with those of our employees?
Who will win the next election? [worth asking perhaps but can you trust the answer?]
CAATs are wonderful for asking bizarre audit questions that ordinary system users, managers, analysts and developers have probably never even considered, some of which can lead to the identification of frauds or (conversely) confirmation that control weaknesses have not been exploited. Complex, highly convoluted and especially cunning CAAT queries can take hours to run against large data sets and are a great excuse for the IT auditor to slip away from the desk for quick coffee or (on a dreadfully slow machine that coincidentally happens to be running a disk defrag at the same time) a very long liquid lunch ... but the quality of the output is proportional to the quality of the question asked, not necessarily the time taken or the size of the report. Big thick auditors produce big thick reports. The real trick is to apply Occam’s razor - find the explanation that most simply and convincingly explains the findings. Nothing to do with beards and shaving after all.
Information security applications such as intrusion detection systems, penetration testing and vulnerability assessment tools could also be considered CAATs since they can be used by auditors to find information security control weaknesses. This is a good example of the use of automation to leverage limited available skilled human resources. The Center for Internet Security’s excellent free system security benchmarking tools, for instance, make it a breeze to find common security weaknesses in Windows, UNIX and other platforms. Still it takes skill and judgement to figure out which of the long list of system security issues just has to be resolved by next Tuesday. At 11. Or else.
In an experienced IT auditor’s hands, SQL can be a superb and elegant CAAT when auditing a database system that accepts SQL commands, which many do. It can also be a dangerous and potentially career-limiting tool if poorly-considered, unduly-complex and badly-constructed queries are run on the Production system in peak hours ... or if update commands are issued by mistake. In fact, even if update commands are not made but there is the possibility that the auditor may have made updates, this can cause problems later if something goes wrong with the system and someone has it in for audit. Experienced and cautious IT auditors insist on being allowed read-only access. Experienced sysadmins, DBAs and information systems owners violently agree with them.
What’s the coolest thing about IT audit?
THE coolest thing, by far, is Benford’s Law, made famous by somebody called Law although allegedly discovered and published some 50 years earlier by a shy, retiring Mr. Newcomb. These clever geezers noticed that individual digits are not evenly distributed in series of numbers such as columns in a typical spreadsheet. Essentially, more numbers start with a 1 than start with a 2, more start with 2 than 3, and so on up to 9 (ignoring leading zeroes). This pattern has a statistical basis (logarithmic, I’m told) that makes it possible to compare the distribution of digits in a given series of numbers to what would be expected by chance, and (this is the cool bit) spot anomalies that may indicate a fraudster at work (making up numbers with a bias towards higher initial digits, perhaps) or some other factor affecting the digital distribution that could be equally intriguing.
Here’s a simple way to visualise Benford’s Law: look through any large document that contains numbered lists. Every list will start with the number 1. Virtually all lists will have a number 2 item. Most will have a number 3. Some may have a number 9 and a few lists will have 10 or more items. Now count the number of number 1’s (including those initial 1’s in the tens), 2’s, 3’s and so on, and plot the frequency of each initial digit. If you have counted enough lists, you will be able to plot a beautiful Benford’s Law curve that will seriously impress the ladies, or the men depending on your persuasion. Put it on your Facebook profile and wait for the emails from admiring viewers to flood in, as they surely will. [Just be aware that many of your new-found admirers will be mathematicians, auditors, engineers and other geeks who consider this THE coolest thing ever.]
Clever fraudsters who are aware of Benford’s Law could use cunning and guile to ensure that the numbers they concoct in fact follow the law, but if they were that clever, maybe they wouldn’t need to commit fraud. Maybe they would become IT auditors.
Even clevererer IT auditors ought perhaps to be equally suspicious of number series that fit Benford’s Law just a little too closely, but now we’re drifting into serious paranoia territory and at this point, the recursion is obvious. See here.
Who is cooler: IT Auditors or Security Architects?
IT Auditors are cool because:
Security Architects are cool because:
- They hang out with Senior Management
- They can access-all-areas
- They are highly skilled and experienced professionals
- They take independent thought to a whole new level, taking nothing at face value and checking everything
- They are thick skinned, tough and resilient
- I say so, OK? Trust me.
- They hang out with Business Leaders
- They help define access rights
- They are highly skilled and experienced professionals
- They are creative thought leaders, helping to drive the corporation to new heights
- They are sensitive, approachable and responsive
- They are the Font Of All Knowledge
Why do IT auditors give us such a hard time?
It’s what we are paid to do. We are meant to ask difficult questions, probe into sensitive areas, challenge, obtain and assess the evidence objectively. It’s no secret: most of us actually enjoy it and we always aim to give as good as we get (how’s that for fairness?).
If your organization, business unit, team, systems, processes etc. have been audited before and the results were less than satisfactory, you should expect the auditors to be a bit more harsh in their probing the next time, seeking additional assurance that issues raised previously have been adequately resolved and there are no more skeletons lurking in closets. Likewise if a serious incident has occurred or if they are testing compliance with mandatory requirements, especially legal and regulatory obligations. If you or your managers gave the auditors the run-around last time, and particularly if promised corrective actions were not really taken to heart let alone completed, don’t be surprised if they are just a bit more single-minded and diligent this time. They may bring clubs, but probably only the small ones without nails.
What if we disagree with the auditor?
You are mistaken. Take your medicine. It’s good for you. Move along.
But what if the auditor really is wrong?
There is a flip side to the audit method that can be used to your advantage. Auditors are seeking The Truth and, if presented with undeniable factual evidence of something, they find it much harder to claim or argue otherwise. Facts are your friends.
[Aside: if you really want to mess with an auditor’s head, find yourself a skilled magician to pull off a sneaky sleight-of-hand trick on him. The fundamental disconnect between “What I just saw with my own two eyes” and “What I know to be true, according to the inviolate laws of physics” will rip a hole in his space-time continuum that will remain with him for the rest of his sad, sorry life.]
Whether and how to resist or push back if you vehemently disagree with the auditors about something is tricky. Asking to see and discuss the requirement or the evidence in question is a good start, provided you both approach things with sufficiently open minds and reasonably positive attitudes. Can you see the audit checklist and file, the relevant parts at least?
Rather than relying purely on memory, go take a dispassionate, honest look at what the auditor saw. Try to see it through his eyes. Review the evidence. Ask some searching questions of the people involved. Take note of what they actually say, and the way they express it, rather than hearing what you want to hear.
There’s no harm and a lot to be gained by auditor and auditee asking questions of each other and jointly exploring both the issues/findings and the audit recommendations, informally at first, and perhaps coming up with a compromise that achieves the desired ends.
While you are at it, think as dispassionately as you can about the auditor’s credibility, professionalism, competence and experience. On the whole, aside from the specific issues at hand, does he clearly know his stuff, or is he clearly from another planet? Try to divorce this consideration from the question of whether his parents were unmarried. If the auditor is a greybeard, a seasoned campaigner and scarred veteran who has survived many prior battles, do you honestly want to go to war over this?
There is usually some latitude on the precise wording of audit reports, findings and recommendations, and a pragmatic auditor appreciates that painting the auditee as a selfish, incompetent, lazy liar and traitor is perhaps not the best way to get him on board. He will probably draw the line at ignoring (what he believes are) material, reportable facts or rewriting history, but you might be able to persuade him to round-off the very sharpest corners, especially if you can convince him that his points are well taken and improvements are already in train.
If that still doesn’t resolve matters, it may be worth escalating and formalizing things, drawing in more senior and experienced people on both sides of the table. Occasionally you might need a ‘full and frank discussion’ or robust argument to clear the air and decide what, if anything, needs to be done. Sometimes, it may be best simply to ‘agree to differ’, backing down in the interest of closing-out the audit and getting the certificate. [That point applies equally to auditors AND auditees by the way! The optimal solution in the end may be to cut the other side a tiny bit more slack and negotiate a workable settlement.]
Regardless of the path you choose, please remember that, beneath it all, both auditors and auditees are mostly-humans trying to do a good job. Keep the lines of communication open, and try to maintain a professional discourse without taking or making it personal. Arguably the most valuable part of auditing is the auditors’ independence, which inevitably means they see some things differently to the auditees. It may be tempting to discount their advice out of hand ‘because they don’t really appreciate the realities of the situation’ but there are usually genuine risk, security, governance and/or control issues lurking beneath the rhetoric. Focus on those issues. Holster your weapon.
Why don’t auditors stop IT development projects going off-the-rails?
Developing systems audits are arguably one of the most difficult types of IT audit assignment. They often involve a cat-and-mouse game of ‘show me’ and ‘watch my lips’, in other words the auditor asks for something truly obscure and weird such as “the business case” or “the risk analysis” or “the security specifications” and someone with nothing better to do is sent into a dark corner to knock one together, quickly. Audited development projects almost invariably involve large budgets since IT auditors seldom get the opportunity to audit small ones, particularly end-user developments that are perceived (by management if not SOX auditors) as low risk.
It is a sad truth that in IT, professional, disciplined and effective project management is a welcome relief rather than the rule. A greybeard IT auditor has generally witnessed all sorts of horrendous disasters at close range through bayonetting a number of IT development projects. For some obscure reason buried deep in human psyche, the symptoms of imminent disaster that loom large as an obese blue whale to an experienced IT auditor are mysteriously invisible to the average project manager … and indeed to their managers and senior management as a breed. A kind of corporate blind-spot often develops, way beyond mere blinkers and myopia, we’re talking opaque cataracts in both eyes and lead-lined blindfolds. But that’s only the start of it. Persuading managers who eventually, under sufferance and using Braille, acknowledge the undeniable presence of the whale, to actually stop a runaway project is very much like trying to catch and stop an unhitched Welsh coal wagon full of anthracite flying down a steep incline, bach. Ordinary common-or-garden brakes are simply not up to the task. The reason is known as “corporate politics”: big projects are almost invariably led by larger-than-life characters, specifically appointed by management because they are “good blokes” and because they have the big cajones necessary to manage big projects. The IT auditor’s rôle is truly to proclaim that the king hath no clothes. And become an enormous block of concrete and steel welded to the tracks.
Recall the rather boring definition of IT audit earlier? Audit is largely about encouraging management to manage and reduce if not eliminate untenable risks. Auditors help identify and find ways to limit the risks relating to IT developments. Proactive managers take note of audit recommendations and make more effective business decisions. Others don’t.
IT auditors, operational auditors and financial auditors potentially have a lot to offer the development projects such as:
Reviewing business cases to see if they hold water and conform to corporate investment policies and 'risk appetite', and ideally checking that they are updated to reflect inevitable changes in the lifetime of the project (read John Thorpe’s outstanding
book Information Paradox
or check out ValIT from ISACA
for the reasons why this is so important);
Reviewing project management controls through attending the Project Control Group as a “nonvoting observer”, reviewing project plans & progress reported, reviewing project risk and quality management processes etc. (including periodic or phase-end audits);
Mentoring project managers, user management, project team members, sponsors, users, testers etc. - whether that’s offering a shoulder to cry on or having a quiet word in their shell-like;
Reviewing risk assessments, system security designs etc. from audit’s governance and control specialist point of view;
Contributing to system specifications and designs, acting as specialist advisors to assist management in specifying “audit trails”, “anti-fraud controls”, “divisions of responsibility”, “accountability”, “rôles and responsibilities” and various other arcane aspects of governance, risk, security and control - you know, the stuff we do;
Hands-on testing of key system controls (technical and procedural - please don’t tell me the user training, sysadmin and support documentation will be finished “later”, do them first or, failing that, now!);
Reviewing implementation processes/activities and process- or quality-assurance controls (e.g. have sensible plans been prepared to “cleanse” malodorous old data from the old system? Have new users, sysadmins and support people received appropriate puppy training? Have new users, sysadmins and support people been assigned to suitable rôles with appropriate access rights? Has “enough” testing been done? Are all approvals complete i.e. have appropriate people been involved in testing and signing-off the system? Is there clear accountability just in case the new system should happen to take down the global Interweb at half past nine on day 1?);
Facilitating post-implementation review meetings to tease out the lessons learnt for future reference (often resulting in new entries in the Audit Director’s little black book).
Aren’t IT auditors meant to stop (IT) frauds?
NO! At least not directly, unless the frauds are perpetrated within the IT audit function anyway. Audit independence means that auditors do not form part of the routine system of controls in operational areas of an organization - that dubious honour usually belongs to “management” or, more broadly, “someone else”. Managers and staff are responsible for designing, implementing, operating and maintaining the appropriate system of controls to prevent fraud or other control failures (e.g. accidental loss of key data, or even the keys to the fire safe). They are also personally accountable for their decisions, actions and inactions. Auditors are responsible for examining and commenting on those controls but again it is management's duty to respond appropriately to audit reports and recommendations, or not. You might say that auditors are irresponsible. I will say no more.
Who audits the auditors?
... or, if you want to appear more erudite, quis custodiet ipsos custodes?
smartarse my dear fellow, auditors are highly trained and experienced professionals diligently following structured and formal processes that include all manner of process- and quality-assurance controls. Auditors themselves uphold the utmost principles of integrity. Most belong to professional bodies that espouse only the very finest standards of auditor behaviour and conduct. Their work is routinely scrutinised by themselves, by other auditors and by well-practiced and professionally-picky audit managers, by auditees and by senior management. Conventional audit working practices ensure that everything considered reportable is in fact reported, and that everything reported can be traced to objective evidence. The audit reporting process consists largely of repeated cycles of review and revision, including ‘quality reviews’ and/or painstaking ‘file reviews’ comparing reports to the actual evidence and analysis.
Most professional audit qualifications involve some sort of examination to confirm that candidates know their stuff, and incorporate the element of continuous professional education to make sure we keep up with the state of the art.
If you want to audit the auditors, go ahead
punk sir, make my day be my guest.
Auditors, just remember this: illegitimi non carborundum. [I just knew one day I’d be glad to have learned amo, amas, amat at school.]
Do IT auditors give technical support to the rest of audit?
Sometimes but that is certainly not their main purpose in life. Because of their technical competence, familiarity with technology and their links within IT (OK, because they are self-effacing geeks), IT auditors often find themselves nominated as local IT co-ordinators within the audit function but have to balance this rôle with the demands of their scheduled audit work. In much the same way, financial auditors might be willing to give advice to colleagues on their tax returns etc. but should not be expected to do so to the extent that audit assignments run late. It’s all a matter of balance and judgement. And discreet bribery.
What happens to the audit evidence?
“Audit evidence” in a typical IT audit comprises system dumps and printouts, interview notes, incriminating photos and a whole variety of audit working papers (e.g. risk analysis, assessment of key risks, controls review checklists and draft audit reports). A full-scope detailed audit can easily generate several lever-arch files stuffed with paperwork and hard drives the size of Saturn containing gigglebites of computer data. However, the value of an audit is emphatically NOT a function of the amount of material generated. You know the score: size isn’t everything. It’s what you do with it.
There is no hard-and-fast rule about what goes into the audit files, nor what stays there - it's mostly down to local practice and relates to the primary objective of the audit function. If the purpose is essentially to ‘improve the organization’ through improved controls, reduced risks and greater efficiency (a classic consultancy-type mission for internal audit), then there is a different need to obtain and retain evidence, audit reports etc. than if the rôle is to ‘assess compliance with laws, regulations and policies, and identify and report weaknesses’ (more like external audit):
Contrary to appearance and common opinion, reports from the former type of audit function are not ends in themselves but are means of persuading management to make improvements. They are typically the basis for an open discussion with management. So long as management eventually accepts the report and actually makes the agreed improvements, the aim is met. The final report plus management feedback (typically an agreed action plan naming responsible parties and with deadlines) should be sufficient record, although it is normal to retain other key audit evidence, working papers, risk assessments etc. for future work in the same area. The relationship between auditor and auditee/management is based on trust - management are responsible for enacting the recommendations as they see fit, audit merely advises and provides the motivation to act. Audit anticipates action even on items that were not officially reported, including less material points and issues which they believe to be true but were perhaps unable to prove formally.
Reports from the latter tend to be more formalized. They are the formal statements from audit which management had better act on, or else! In some cases, they are a matter of public record. The final issued report, plus the key evidence, plus the discussion on drafts - all are important elements of this formal style of auditing, and will probably be required if there is an ‘inquest’ later (whether The Person In Charge demands an inquiry into the debacle, or someone’s decomposing remains are discovered in a cupboard). The audit-auditee relationship is based on distrust - audit has to report formally in order to get management to act at all, and has no expectations regarding anything not stated formally in the final issued report. Unfortunate but essentially true.
Clearly, the differences have been exaggerated for the sake of emphasis. In practice, there is a continuum between these extremes and even more extreme versions are possible I guess. Also, individual audits and individual auditors vary in formality. Some still wear ties!
A more prosaic method is simply to retain everything for, say, six months to a year in case they are needed, then trim out the junk and close the file. Even more pragmatic is the ‘dump it in a dark corner of the filing cabinet until we have no more storage space left, then drop it in the shreddy bin while the boss is out’ approach, common in practice but seldom acknowledged (except by Arthur Anderson LLP, perhaps).
By the way, it is A Jolly Good Idea to insist that all auditors routinely use strong access controls (such as decent encryption and multifactor authentication for their databases plus locked cabinets or safes for paperbases) to protect audit evidence and findings against unauthorised access. There have been far too many incidents where auditors’ laptops have been stolen or lost. It is entirely reasonable for management to make this an explicit requirement in the contract with external auditors and a mandatory corporate policy covering internal auditors. [I’ll leave the question of who should check that the controls are properly implemented as an exercise for the reader.]
Go back to contents mind map
How should I find a consultant IT auditor?
[Ed.: in the dim and distant past, I have from time to time plied my trade as a consultant IT auditor, loitering on street corners, putting cards in phone boxes (which term hints at how long ago it was). I now have a life, and a Proper Job. What follows not a sales pitch. I am not for sale.]
If you don’t have the skills in-house, it is possible to contract with third party IT audit specialists but, before you sign on the dotted line, there are a few little things to consider ...
How should I word an Invitation To Treat (ITT)?
There are three key aspects to cover when preparing an ITT:
First is to define the audit/s
such as the scope (what risks you want examining, depth and breadth of coverage, any constraints, any especially ‘interesting’ elements that need a really good poke around, number or percentage of locations/systems/networks/users to be reviewed and what they are to be reviewed against e.g
. good practice information security management such as ISO/IEC 27002
or relevant legislation) and reporting (how and when is the assignment to be reported, and to what level of detail e.g
. executive summary, management report with or without detailed supporting appendices, recommendations, structured audit files with all the supporting evidence neatly indexed and cited ... ?) [This information would of course still be needed if the audit was run by in-house employees]
Secondly, what type/s of auditor are you looking for?
What qualifications and experience (e.g
. CISA, CISSP, relevant industry and management experience - there’s more information in the next section
of this FAQ)? What are the personal characteristics that would suit the job, or conversely would not be suitable? What kind of person would you personally like to work with? Are you looking for a consultative or confrontational approach? Just how important is personal hygiene to you?
Thirdly, how will the assignment/s be managed? How would you like to relate to/manage/deal with the consultant(s)? Do you want them to take the lead, drive the job, report the findings, generate an agreed management action plan etc. or do you purely want a lap-dog to do the fieldwork to your specifications and under your strict guidance? Or something else? Are you thinking about someone to organise and coordinate/manage a team of auditors, a whole team, or someone to work alone? Do you want a weekly status update, monthly reporting, a completion statement and invoice, or what? This is an important section of the ITT, often neglected. If you get this section right, your relationship with the consultant/s should be much less stressful all round (exactly the same point applies, by the way, to the consultant/s).
Who should I “Invite To Tender”?
You have already demonstrated your supreme initiative by finding this FAQ on the web - the World Wide Wonderweb is the natural place to search for potential suppliers. Googling “it audit consultant” finds more than ten pages so you shouldn’t exactly be short of choice. The market is quite diverse, ranging from The Big
Six Five Few up to little one-man-bands, but don’t mistake sheer size for competence or suitability. If you need help to choose or manage the assignment, look for recruitment agencies that specialise in audit and information security, or perhaps consider contracting with an independent, trustworthy and experienced consultant to run and resource the assignment for and with you.
How should I select from the proposals?
Assuming you sent your ITT to a bunch of potential suppliers, and assuming that you thought carefully about your requirements and prepared a detailed ITT in the first place, it should be fairly straightforward to shortlist a small handful of suppliers simply by excluding those who clearly do not stand up to one or more of your selection criteria. Be ruthless: the amount of ruth should be inversely proportional to the number of respondents.
Now comes the interesting part: final selection.
Value for money is arguably the most important matter. I’m deliberately using ‘value’ not ‘price’: I don’t mean that price is not important but if you have prepared a good ITT as described above, the consultants who propose should be more or less in the same range for man-day rates - those who look expensive are probably ‘pricey’ (dare I say, “taking you for a ride”) but may be offering additional value services, whereas those who look like bargains are probably ‘cheap and nasty’ (or “bargain basement” as the Brits might say). Value-for-money is another way of saying mostly you get what you pay for, but then you may just strike lucky.
One more insider tip for selecting suppliers is to take note of the quality of the proposals themselves as a guide to their ability to write and clues about the way they intend to approach the job. Do they rite proper good Eeennglish (or whatever)? Look for proposals that actually reflect what you want from the job, not standard boilerplate responses that have been crudely cut-and-pasted for your assignment. By the way, glossy brochures and so on are more boilerplate. Peek behind the gloss and polish to see the real quality lurking beneath, or not. Think ‘Trotters Independent Trading Co.’ and you’ve got the right idea.
Finally, make sure to review the CVs (résumés) of, and ideally speak to, the actual person or people who will be leading and performing the assignment ... which means, by the way, that you really want to contract with a specific person or list of people, not some faceless “team”. It is not unknown for the sales pitches to be fronted by top-notch smartly besuited consultants who then place soaking-wet-behind-the-ears juniors on the job. Juniors are not necessarily A Bad Thing (we all had to start somewhere, and often they make up for inexperience with energy and enthusiasm) but audit teams should be balanced. And it is not unreasonable to expect to pay much less for unqualified juniors than for seniors. Now is the time to deal with this issue. If you’d like to meet the team, ask. If half the team is still in kindergarten and someone needs to ask their mummies, you have your answer.
OK, what next?
Prepare and sign a solid legally-binding contract, of course, but the contract is really just a last resort in case everything goes horribly wrong. Your real task is to initiate the relationship with the supplier, reiterate your requirements to the person or team, and launch the assignment on the front foot. This is not an excuse to abdicate all responsibility - all auditors need management support and guidance from time to time. At the start, especially, the auditor/s will welcome background information and contact details. If you can provide a well-written scope document, or else generate one now in conjunction with the auditor/s, and get it signed-off by your management, they should be all set to do the job.
Remember the third part of the ITT? This is where your preparation pays off. Set up a management process to track and guide the audit as you wish, in conjunction with the audit team leader. Invest some of your valuable time to get this process working smoothly and you will not regret it. The trick is to develop a management style that avoids nasty surprises for you but gives the auditors the latitude to apply their qualifications and experience. Good luck.
Go back to contents mind map
I think I want to become an IT auditor
Mad fool! First seek medical attention. See your shrink. Get some therapy. You must be off your rocker. Can’t you get a proper job? Polish your bayonet! Good on yer, sunshine!
This section explains how one might go about becoming an IT auditor by describing the competencies, qualifications and experience necessary. It may also prove useful for those interviewing, selecting and appointing IT auditors, especially if candidates claim to hold long lists of rather curious credentials and yet have never heard of that nice Mr Benford.
How should I start?
The best place to start anything is, ahem, at the start. Alice in Wonderland’s “Begin at the beginning and go on till you come to the end; then stop” is still my favourite (well OK, my only) literary example of a computer program. Read the whole of this FAQ. No really. Go back and read the bits you skipped earlier because they were just TOO boring. Read the whole of this section. Read the end bits. Follow the hyperlinks. Devour all you can read about IT auditing. The first, and for that matter the last lesson about auditing is to learn to listen to what you are actually being told. Read the lines and then between the lines. Especially between, like mental floss.
An editorial piece at CertMag.com advised people to think in terms of building a career not just moving jobs, in other words you should invest in your chosen occupation. Bill Royds offers some more sage advice: “Find something to do that you love doing and are passionate about. You then will be willing to work the hours and spend the effort to achieve in that field. You are unlikely to be successful in a field where you are not really willing to spend the effort of your peers who love it.” Right on Bill.
Your organization may advertise audit rôles on the standard jobs boards but it’s probably worth taking the initiative and approaching the Head of Audit, the Head of IT audit, an IT or ordinary (lesser) auditor or someone in HR to ask if there are any job opportunities in audit. If you’re not absolutely certain that audit is for you, you could try asking for a temporary secondment into audit, perhaps to help out on a planned IT audit (so long as it is not an audit of your own area!).
There are two main routes into IT audit: firstly, from technology (often information security, operations, project management, development or business analysis), alternatively from accountancy (general or financial audit, financial or management accounting). Other accepted entry routes include risk management, quality assurance and general management. A surprising number of companies insist that those destined for the Top Table (C-suite or Board positions) take a spell in Audit, which almost makes it sound like an interesting career move.
It is also possible, but not recommended, to leap straight out of college into IT audit. Try to spend a teeny bit of your life actually doing things before expecting to tell other people what they are doing wrong. Job satisfaction revolves around your effectiveness at making things better, and that hinges on providing sensible, credible and pragmatic advice in a way that persuades auditees to change their ways. Naive and unworkable proposals, no matter how well meaning, do you and the audit profession no favours.
Information security and IT risk management are probably the most closely allied fields to IT audit since they also encompass the concepts of risk and control in relation to computer and telecommunications systems, and senior information security/IT risk management staff normally have reasonably good working relationships with both IT and ‘the business’ (outside of IT). Speaking personally, the whole of my professional career has alternated (not to say ‘careered’) between information security and IT audit rôles and I still enjoy both sides of the fence immensely. Just remember not to fall with one leg each side.
Finally, some of us became auditors because we were once audited and appreciated a job well done. A pay rise, and being able to leave the Agreed Action Plan to our successors, were just the icing on the cake, you understand.
I am already an auditor – can I become an IT auditor?
Probably – it depends on your level of technical awareness/competence and your willingness to improve on those areas. If you have a technology background, you may have sufficient awareness/competence already. If not, you will have to learn the ropes.
If you have been auditing business processes for the past N years, you are almost certainly familiar with auditing the use of computer systems and have maybe used one yourself once or twice. At one level, IT auditors simply take a deeper interest in the IT systems that, until now, may have seemed merely like tools of the trade to you. They have a fascination with the technology for technology’s sake. They actually enjoy fiddling around in the back of a computer box, snooping around the source code for a database application or figuring out which protocols and ports are being used. Many of them have computer networks at home that they play with during their evenings and weekends, without even being paid, and some of them are proud of it. If pressed, they mostly admit to being nerds or geeks. A predilection for pizzas is a bit of a giveaway.
Then, it’s simply a matter of having the requisite implant which requires only a local anaesthetic.
What qualifications do I need?
It depends what you mean by “need” ...
IT audit, information risk, security, governance and related qualifications
Roll up, roll up. Certification credentials are a growth area because they are a nice little earner for the organizations behind them. Presumably, students find plenty of value in their credentials. SANS, for instance, is charging students over $1,000 just to take an exam and (hopefully) become certified under each one of the GIAC credentials. On top of that comes the heavily-promoted training courses, conferences and learning materials, plus periodic credential/certification maintenance and membership fees - like the Greek national debt, it all mounts up.
On the other hand, this is in the nature of a specialist trade heading towards becoming a recognized and trusted profession like our financial, legal and medical colleagues. Good quality training and meaningful qualifications, along with frequent if not continuous updates to maintain currency in this rapidly-developing field, is an essential part of the professionalization. At the end of the day, it’s a free market driven by supply and demand.
As a prospective student, you face a bewildering choice of products so you’d best be clear about your requirements or objectives first. What are you personally hoping to achieve from qualifications? Learn new tricks? Challenge yourself? Beat yourself up? Extend your capabilities? Maturity? Get letters after your name (or before)? Land a better job? Get promoted? Avoid redundancy? Land a contract? Earn more money? (that’s a biggie). Impress your boss/partner/mum? Launch a career? Change career? Get back into a former career? Do something new? Start a side-project? Feel good about yourself? Meet hot women/men/auditors? Further the professionalisation of the field? Demonstrate your commitment? Be busy for a while? Stand out from the crowd? Join the crowd? Move the crowd along - nothing to see here? Join the ranks of the overqualified and underemployed? Knock a few hundred/thousand dollars off the training budget? Hold the qualifications that recruiters recognise, giving more keyword matches for your CV? Hold the qualifications that interviewers don’t recognise, giving you something to talk about at interview? Provide a credible cover story for various nefarious activities? A variant on the above or something else entirely?
When your requirements are clarified, or to help clarify/confuse your thoughts, check out this incomplete list of qualifications or simply browse the ads on any jobs site and Google to see which if any might suit your purposes:
There’s one important rider: experience counts. A few years back in one of their workforce surveys, (ISC)2 sagely stated: “As managers have come to understand the limits of certification, hiring managers may be becoming less impressed with the book learning a candidate has than with the belief that the candidate can roll up his or her sleeves and take action. It is important to note, however, that all certifications are not created equal, and hiring managers should take note of the specific requirements of a certification or certification sponsor rather than simply the fact that there is a certification.”
On that score, dear reader, if you are an employer/interviewer reviewing job applicants’ CVs prior to gently grilling them over a low heat at interview, it is worth following the links above if you see qualifications listed that you do not recognise. Take a good look at the entry criteria and continuing education process (if any) to assess whether they actually mean anything useful or are merely wallpaper. Ask candidates what they have done lately (this quarter!) in the way of professional education, reading/study etc. How many CPEs have they earnt? If they stumble, tell them about some of the things YOU have been doing in the way of personal development to get them started ...
Oh and one last thing. Don’t believe everything you read. Internal auditing is a responsible job often requiring privileged access to highly sensitive information. As well as checking that they actually do hold the claimed qualifications, it’s A Pretty Good Idea to validate applicants’ identities and to assess their personal integrity and ethics before letting them loose on, say, a technical audit of the Accounts Payable, Salary, Personal Banking or <gulp> Missile Launch And Control system ...
Other handy CV fillers
Being experienced - there really is no better way to appreciate the auditees’ points of views. Genuine down-in-the-mud experience certainly makes one think twice before recommending actions one would not be prepared to take oneself (a.k.a. “putting your money where your mouth is”). Along with auditing experience, experience of IT (architecture, programming, operations, networking, testing), information risk, information security and project management are helpful, along with having faced up to and surmounted challenges at work. Successful hands-on team leadership experience demonstrates at least an awareness of issues such as motivation and direction (cat herding), while true management experience and a familiarity with manager-speak helps immensely when discussing strategy and governance with
the big nobs senior management;
IT technical qualifications, especially those with significant information security content such as BSc (Bachelor of Science) or MSc (Maid of Science) in computing, programming, abacus design etc.;
General IT (not audit/security specific) qualifications
- there are loads of these such as ACP
Associate Computing Professional and Certified Computing Professional qualifications from the Institute for Certification of Computing Professionals. Also PMP
Project Management Professional and others from the Project Management Institute. In some countries, ‘official’ financial audits must be signed-off (“attested”) by an audit professional who has qualified under the regulator’s conditions;
General management qualifications - e.g. MBA (Master of Business Administration), useful to understand how IT fits into the business/commercial world and to relate to business managers in their strange native tongue. Most colleges, universities and other institutions with business schools offer MBAs or similar business degrees, hence there is a very wide choice. Some specialise in particular types of manager or industry, while others are more general. Most are an excellent way to learn about business, management, governance, finance, HR, operations, marketing, strategy etc., providing a fabulous grounding for all kinds of audit work. Some are less highly regarded: it pays to check out the school’s reputation, the course content and the standing of the academic tutors before committing to an intensive year or two of study;
Accountancy qualifications e.g. CA, ACA, CPA, CIMA, thirteen-times table and long division. Tip: bring your slide rule to interview and fiddle idly with it as the panel pontificates;
Language skills - a strong command of the Queen’s English (and/or your own native tong) and the ability to write in a formal, objective yet curiously persuasive if not overtly coercive style is essential, but there’s more to it than that: top auditors love communicating, putting things across, debating. Certain auditees have been known to argue about the syntax and spelling of a draft audit report as a deliberate ploy to avoid discussing the actual issues at hand (outrageous - but true! Former auditors, especially former Heads of Audit are by far the worst. Trust me, been there, done that). Auditors skilled in the cryptic symbolic shorthand language beloved of teenagers everywhere shudnt Xpect 2 rel8 2 mgmt in TXT speek;
- this is a great one for those of us who yearn for more impressive letters after our names. While implying something to do with being a “professor” or “professional”, it actually means “Proficient Cyclist” but who’s to know? Similarly SPEOE
(Self-Proclaimed Expert On Everything
). Just hope your interviewer doesn’t read this FAQ, or if she does, that she has a good sense of humour and irony.
What resources would you suggest for those studying towards qualifications in IT audit?
That depends partly on your level of experience in IT audit. If you are starting from ground zero, you will have a tough time to absorb sufficient knowledge from any single book - even one-on-one teaching will be tough! Almost any decent textbooks on information security, auditing and/or IT auditing will help though, supplementing the officially-sanctioned study materials. If, on the other hand, you have several years' experience in the field, then you might get away with reading the exam outline provided by the examining bodies, a quick skim through the body of knowledge or revision manuel, and maybe some sample questions.
Other useful resources include:
. Membership is strongly recommended for all IT audit professionals, giving access to a substantial quantity of relevant information, methods (such as COBIT
, Risk IT
), standards etc
. I insist. Save $10 off the joining fee by quoting my ISACA member number 064227
, a longstanding (read: old-skool) peer-reviewed professional journal covering IT auditing, governance, risk management and related topics;
The official journals/organs from professional bodies such as ISACA, The IIA, (ISC)2 and ISSA are worth the effort to skim/read, not least because they often publish articles expounding on new stuff. Better still, why not research write and submit an article on something that’s hot and sexy in IT audit (so to speak)? Give a little back.
Bruce Schneier’s CRYPTO-GRAM
is pretty good, popular anyway;
Electronic Frontier Foundation’s EFFector
from the Electronic Privacy Information Center;
groups (various) - some are better than others but most are inundated with spam from vendors desperate to promote themselves. Shame they don’t make the effort to provide useful content instead of the lame “Visit my company’s blog” or “Read my latest marketing piece”...;
from the ACM Committee on Computers and Public Policy;
- always good for a laugh, as well as news about information security challenges and failures;
Training courses of course. I am compelled to mention that because I’m a trainer;
plus a million blogs, Google+ pages, vendor sites and more;
oh and books. Let’s not forget good old books, eh? For the price of a single SANS GIAC exam, I can buy roughly 20 good books written by acknowledged experts
and invest my valuable time in reading, thinking and learning about numerous topics in depth. If your bookshelf is not literally heaving
under the weight of dozens
of books, either you have a Kindle or iPad or you are missing out on a vast and valuable pool of information. Even better, set up a private library in or near your office or on the network (copyright permitting) to share the knowledge with your colleagues, and claim back the expenses.
What are the commonest career paths into IT auditing?
The somewhat cynical view that audit is where failed accountants go to curl up and die is thankfully outdated (although, come to think of it, I have met one or two dinosaurs in my time in audit - no names but you know who you are [well maybe you do, the rest of us certainly do]).
Some people become auditors as a definite and explicit career choice but most seem to become auditors more or less accidentally - they kind of fall into it, a bit like tumbling into an open manhole. It is policy in some organizations for managers earmarked for the top Board or C-level positions to have “a spell in audit” (not in the Harry Potter sense) in order to expose them to the whole breadth of the organization, with their greater personal appreciation of audit, governance, risk and control concepts, and the passing of business knowledge into the fabled knowledgebanks of audit, as valuable supplementary benefits for the audit department. Less senior people may also be seconded into audit to help out with specific audits and star auditees are often earmarked by canny audit managers as potential future recruits.
Many IT auditors came directly from IT (developers, operations, IT security, technical architecture, business analysts, testers, IT managers etc.) but some have, shall we say, less conventional backgrounds such as:
Accountancy e.g. traditional financial audit
Other types of auditing e.g. quality audit, health and safety audit, PC audit
IT and/or management consultancy
Military intelligence and other oxymoronic job titles
IT sales, marketing or product support, especially tech support
Legal or regulatory compliance work, certification, law
Risk management, hazards, things that go bump in the night
“Security” as in the Police, security guards, bodyguards and nightclub bouncers (well maybe - some former military people in the field have that kind of background and I wouldn’t want to argue with them)
Other technical management rôles and sometimes even non-technical managers (who rely heavily on the support of technologically-competent IT auditors in their team)
University, college or school-leavers (who typically enter at junior/apprentice level called 'auditor' grade a.k.a. “gofer” or, in India and the UK, “charwallah”)
What competencies should I have to be an IT auditor?
The following personal characteristics or competencies are important for all auditors in my opinion:
Open-minded and mature in approach;
Sound judgement, analytical skills and tenacity;
Able to perceive situations in a realistic way;
Professionalism, confidently exuding an air of competence;
Able to understand complex operations from a broad perspective;
Able to understand the role of individual business units, systems, processes, functions, data flows etc. within the overall organizational context;
ISO 19011 Guidelines for auditing management systems values the following auditor attributes:
Ethical conduct i.e. fair, truthful, sincere, honest and discreet;
An open mind i.e. willingness to consider alternative ideas or points of view;
Diplomacy i.e. tact in dealing with awkward people and situations;
Observation i.e. active observation of physical surroundings and activities;
Perceptiveness i.e. instinctive awareness of and ability to understand situations;
Versatility i.e. adjusts readily to different situations;
Tenacity i.e. persistence, focused on achieving objectives like a dog with a bone;
Decisiveness i.e. reaching timely conclusions based on logical reasoning and analysis;
Self contained i.e. acts and functions independently while interacting effectively with others;
Professional behaviour i.e. exhibiting a courteous, conscientious and generally business like demeanour in the workplace;
Courage i.e. willing to act responsibly and ethically even though these actions may not always be popular and may sometimes result in disagreement or confrontation;
Self-organization i.e. effective time management, prioritization, planning and efficiency;
Willingness to improve i.e. learning from situations, striving for better audit results, pushing themselves for more.
Aside from the formal qualifications, of course, practical on-the-job experience is a major advantage as I said earlier, particularly for the softer skills such as interviewing techniques and establishing rapport especially with evasive or nervous auditees. Whilst computer systems can provide quite a lot of information, I gather, very few if any IT audits can be completed successfully without actually talking to real people such as end-users, middle-managers and top-and-bottom operations staff in the flesh in order to gather more facts and opinions. This becomes increasingly important in the latter stages of an audit since audit recommendations are unlikely to be adopted unless management understands and supports them, so you will need to lay out your case and sell it. Gaining management’s commitment to action or implement or get on with the recommendations involves persuading and negotiating, along with a degree of tenacity and resilience. Auditing is practically worthless unless it achieves positive change within the organization. It takes real strength of character to stand up for what’s right (“The Truth, The Light”) and push what needs to be done (“The Way”) given the significant risk of upsetting powerful figures within the management hierarchy (“The Establishment”) because the independence of audit more-or-less inevitably results in conflict situations at a personal as well as professional level. It goes with the badge.
Perhaps the most important benefit of audit experience is a thorough understanding of risk and control concepts. Auditors specialise in advising management on the need for controls to address the risks that they observe and/or surmise. IT auditors need to:
Identify actual and potential risks to the business associated with computer systems, networks, IT installations, applications, development projects etc.;
Observe and review technical, physical and procedural controls in operation;
Assess whether the level of risk is reasonable or whether control improvements are required;
Justify and recommend more-or-less specific control improvements, persuading management to commit to resourcing and making the changes within a sensible timeframe (remembering that it’s management’s job to make the decisions, not theirs).
IT auditors’ core expertise is naturally focused on ICT but their expertise in risk and control concepts has broader application. Reviewing and discussing ICT risks and controls in relation to the organisational environment as a whole is a powerful technique for influencing management. After all, in most organisations, ICT is a means to an end not an end in itself. This therefore implies a further competence at bridging between the worlds of technology and business.
A reasonable understanding of, and respect for, change management concepts and business management in general, are likely to make the IT auditor more effective overall. A good example is the notion that there is really no such thing as “an IT project”: computer systems are developed to change the organisation in some way, normally to facilitate new, more efficient business processes. Reviewing major software/system development projects that happen to be run within IT as if they are in fact catalysts for substantial organisational and business changes is an extremely powerful technique.
Cognitive abilities, coupled with the dedication for systematic, insightful analysis (a posh phrase for “brains”) and presentational skills such as formal writing, are very important for success in IT audit or indeed in any branch of auditing. Proactivity and diligence (a.k.a. “get up and go”) are useful characteristics, along with both an eye for detail and the ability to ‘see the bigger picture’. IT auditors who focus purely on technology and put too much emphasis on specific technical controls risk alienating senior management who have a business to run. Therefore, they need to be able to put their findings in context and work with management to find pragmatic solutions to business problems stemming from the technical weaknesses.
An incessant thirst for knowledge helps the IT auditor get through the day. The same is true of other auditors but IT auditors have a significant advantage: they can browse the Internet or intranet for hours on end with a more legitimate excuse. Constant learning and updating of skills is the real aim, of course, and is especially important in the case of ICT. It really helps to be a nerd – someone who loves technology for technology’s sake and is not afraid to stay up late grappling with the intricacies of TCP/IP or AES.
IT auditors, like all auditors, need to be well aware of corporate politics to cope with the strong personalities characteristic of most senior managers. At times, we surely need thick skins! Being overly assertive with tinges of pure unbridled aggression, though, is definitely not the answer. Good auditors learn to manipulate the organization, not just the individual.
You have enemies? Good.
That means you've stood up for something,
some time in your life.
Sir Winston Churchill
If this all sounds daunting, don’t worry. Audit presents opportunities to learn and improve the skills and competencies listed here, if you are prepared to put in the effort. It is also a wonderful way to find out about the organization and the senior managers and others who run the show, often behind-the-scenes. Audit opens doors.
Institute of Internal Auditors’ categories of IT knowledge for internal auditors
Some while back, the IIA’s International Advanced Technology Committee identified the following three categories of IT knowledge required by internal auditors.
Category 1 – All Auditors from new recruits up through the Chief Audit Executive
“Basic” IT knowledge encompasses understanding concepts such as the differences in software as used in applications, operating systems and systems software, and networks. It includes understanding basic IT security and control components such as perimeter defences, intrusion protection, authentication, and application system controls. Basic knowledge includes understanding of how business controls and assurance objectives can be impacted by vulnerabilities in business operations and the related and supporting systems, networks, and data components.
Category 2 – Audit Supervisors
Audit supervisors must have basic knowledge, but must also understand IT issues and elements sufficiently to address them in audit planning, testing, analysis, reporting, follow-up, and the assignment of auditor skills to the elements of audit projects. Essentially, the audit supervisor must:
Understand the threats and vulnerabilities associated with automated business processes;
Understand business controls and risk mitigation that can, and should, be provided by IT;
Plan and supervise audit tasks to address IT-related vulnerabilities and controls, as well as the effectiveness of IT in providing controls for business applications and environments where it is used;
Ensure the audit team has sufficient competence, including IT proficiency, for audits;
Ensure the effective use of IT tools in audit assessments and testing;
Approve plans and techniques for testing of controls and information;
Assess audit test results for evidence of IT vulnerabilities or control weaknesses;
Analyze symptoms detected, and relate them to causes that may have their sources in business or IT: planning, execution, operations, change management, intrusion protection, authentication, or other risk areas;
Provide audit recommendations based on business assurance objectives appropriate to the sources of problems noted rather than simply reporting on problems or errors detected.
Category 3 – Technical IT Audit Specialists
IT auditors may or may not function at the supervisory category but must understand the components and underlying technologies supporting business components and be familiar with the threats and vulnerabilities associated with the technologies. Technical IT auditors may also specialize in certain areas of technology.
What are the personality traits and abilities of good IT auditors?
Good IT auditors are like other good auditors, only better. Here are some of our defining characteristics:
Inquisitiveness - more than just idle curiosity, this is the incessant not to say desperate urge to find out how things (computer systems and subsystems, networks, work processes, organizational units, people ... and things) work and figure out why they don't work better. Asking questions, both literally and figuratively, is what fieldwork or audit testing is all about, isn’t it?;
Independence of thought - distinct formal reporting lines for the audit function are only part of this. Auditors need to 'think outside the box' more than most. It’s all too easy to get drawn into the “that’s how we've always done it” thought patterns constraining most auditees. Trustworthy computer hackers (if that’s not an oxymoron) would probably make good IT auditors. Auditors might be called professional cynics, trained and encouraged to challenge the status quo and other aging rock groups;
Assertiveness - assertiveness (neither aggression nor arrogance) can be a subtle blend of charm, wit and forceful personality, or the more direct carrot-and-stick approach (“Do you think your manager would be surprised to know that you promised me this information six weeks ago?”). At times, auditors also need a degree of humility: auditees often know more about the realities of the detailed situation under review than the auditor - they are the real experts, it’s what they do;
Analyticality (??) - making sense of all that information you've gathered is quite a job. When you find yourself surrounded by an enormous pile of computer printouts, interview notes, findings sheets, checklists and half-eaten pizzas, and with the audit reporting deadline fast approaching, it's sometimes worth taking a break or asking for help. Personally, I recognize being in this state when I feel like I have a head-full of spaghetti until the time finally comes to strain the information out and rinse it off ready for consumption. The next step - writing up - comes as a great relief, a bit like serving a big meal and sitting down with a napkin around your chops (OK OK enough of the analogy already);
Report writing skills - writing formal audit reports well is a skill that takes many years of trial-and-error and 'constructive criticism' from audit management and more-or-less direct feedback from auditees. Reports have to present bad news in such a fashion that auditees see little alternative to making the improvements oh so helpfully suggested under 'audit recommendations'. [Dear auditee, if you are trying to bend or avoid the truth, be careful how you put things to an experienced auditor: they are probably more practised wordsmiths than you];
Presentational skills - presenting audit findings and recommendations to middle, senior and ancient management can be daunting, career-threatening or career-enhancing, depending on the circumstances, the auditor's skills and the eventual outcome. Whatever it takes, there is little point being an auditor unless you are prepared to (figuratively and/or literally) stand up straight and say what needs to be said. Achieving positive changes in the organization is the real prize sine qua non. It takes special skills to explain the ins-and-outs of a typical firewall ruleset and point out the omissions, errors and catch-alls to your average non-technical manager.
By the way, presenting is of course related but different to report-writing: reports can and usually are written and rewritten incessantly, crafted into literary masterpieces. An auditor may only have one short opportunity to stand up and present findings to the Board, C-Suite or Mahogany Row in the full glare of the corporate spotlight. This is where the auditors’ most powerful secret weapon comes into its own. Auditors speak from knowledge of the key facts. Facts are an auditor’s indisputable ally. Be nice to facts. Treat facts with love and respect, like your best friends, and they will be there when you need them most.
What experience is required?
That depends on the seniority of the post and the level of support available, as well as the organization’s Human Relations policies. Most organizations that have a dedicated IT audit function within Internal Audit have an experienced IT audit Manager who has, typically, at least four or five years experience in IT audit. He/she may be the only person in small organizations and is often expected to perform other work outside of the normal remit of IT audit. In large organizations, he/she usually manages a team of perhaps five to ten individual IT auditors, possibly supplemented with additional resources (consultants, contractors, secondees from the business and other auditors).
Larger teams such as this usually include inexperienced trainees and part-experienced staff (juniors) but IT audit is not really an ideal 'entry level’ profession. It may be hot with a high profile in the press these days, and may look more interesting than the drudgery of being a sysadmin or application programmer for a large and faceless corporation, but the reality is more than that. Technology knowledge alone is insufficient. You will need more than a Batchelors or Masters degree in IT or Information Security or a shiny CISA certificate to make a successful career of it. It means communicating effectively with corporate politicians and dealing with commercial constraints and practical realities. Good IT auditors understand topics as diverse as management accounting, motivational psychology, social anthropology, public speaking, organisational design and business law. They combine empathy with assertiveness. Like the best generals, they have been knocked about in the trenches for a few years, dodging bullets. They are battle-scarred and wizzened, a trifle deaf on one side and walk with a limp.
Go back to contents mind map
I’m about to be audited: what will happen?
The end of the world is nigh
Should I fear being interviewed by an IT auditor?
Of course not! Trust me, the auditors are here to help! It is entirely natural to be a little nervous (not so much blind panic as 'exam nerves'), especially the first time you are audited. Auditors grow accustomed to working with nervous auditees. They should explain the audit process and confirm their scope with you, and give you plenty of opportunities to ask your own questions or make relevant comments to amplify your responses to their questions. Auditors are really just professionals trying to do a good job. They may ask lots of questions and can occasionally appear somewhat dubious about your responses, but they are not ‘out to get you’. Most of the time they are simply trying to gather relevant information and understand complex and ill-defined control systems.
How much information should I give an IT auditor?
Experienced auditors become adept at filtering large quantities of information and rapidly identifying key facts or concerns. It is difficult for auditees to swamp auditors with relevant information, although dumping reams of irrelevant or badly structured information on them just as the audit report is due tends to make them somewhat grumpy.
Conversely, auditees who are too terse can also create a problem. It is normally better to offer additional information which you feel may be relevant, than to wait to be asked for it specifically. Auditees who consistently fail to open-up, typically only answering audit questions with highly specific and succinct answers, may simply be forgetful or nervous, or may in fact be trying to conceal something important, perhaps concealing a fraud, theft, accident or misdemeanour. Similarly, auditors who only ask direct or closed questions (encouraging monosyllabic “Yes” or “No” answers) may themselves limit the breadth of information to the extent that they may miss certain important and relevant facts. In this sense, auditing is truly a bidirectional communications process.
Only a small fraction of the information gathered during an audit will ever be formally reported. IT auditors, in particular, often have access to computerised data analysis tools to help them examine large databases, spreadsheets, logs or other data files provided by auditees. They can select records of interest for further study using a variety of statistical methods ranging from random or stratified sampling (e.g. “Identify transactions in the top 5% by value”) to highly sophisticated and complex data-correlation techniques (e.g. “Find any sales transactions above $100 in the past year where the delivery address does not match the cardholder's address, sorting them by curiosity factor”).
How can an IT auditor who does not work in my department and has limited knowledge of what I do, possibly criticise our systems and procedures? What on Earth does he/she know?! What gives him/her the nerve to come in here, asking all these ridiculous questions …
Good point! All auditors have a thirst for reliable evidence and the ability to evaluate business situations for control weaknesses and risks. This typically requires having sufficient background knowledge of the auditees' area to ask appropriate questions and understand the answers, coupled with careful observation skills and, at times, the humility to seek help. Interviewing, analytical and reporting skills add to the auditor's armoury, coupled with seriously heavy senior management support and the sheer nerve to ask dumb questions or challenge naive or ridiculous-sounding answers. Blind luck helps sometimes too - but then, the harder I work, the luckier I get.
IT Auditors’ favourite phrases
“I'm from audit, and I'm here to help”
“Trust me, I'm an auditor”
“I come in peace - take me to your leader”
“Your manager said I should speak to you about this”
“Tell me about ...”
“Just because you’ve always made this mistake doesn’t mean you should continue to do so”
“Call me a cynic, but ...”
“Go ahead – make my day”
“I'm not a proper auditor, I have a heart”
“More coffee please, an extra shot”
“Here, hold this wire a moment”
“This will only take a second”
“What does this button do?”
“Oooh look, something shiny!”
“Is there anything else you’d like to tell me?”
“Is there anything else you feel you want to get off your chest?”
“Is there anything you are reluctant even to mention?”
“Can I have a read-only userID to take a little look at your system, please?”
“Who else should I speak to about this?”
“Oh, I don't suppose it was meant to do that”
“When would you say you’d have this issue resolved?”
“I need your cell number, for the audit file”
“Just one more thing ...”
“Get a life”
“Beam me up Mr. Scott.”
IT auditees’ favourite phrases
“It's in the post”
“It's never done that before”
“Look, I'll show you just how confident I am ... oh-oh ...”
“But that's just the way we've always done it!””
“I just do what I'm told”
“It wasn’t me”
“It was my predecessor”
“I have absolutely no idea”
“Don't be ridiculous, that'll never happen here”
“The last lot of auditors told me I had to do it this way”
“My manager hasn’t a clue what I do”
“I’ll send it round straight away, honest”
“Exactly how many is 'many' control failures?”
“It was working perfectly just a moment ago”
“Which planet do you come from?”
“There’s no need to document our strategies/procedures: everyone knows what they are”
“Source code comments are for wimps. Real programmers write self-documenting code.”
“I'll email it to you”
“That is out of scope”
“It’ll be fixed in the next release”
“Are we done?”
“NO! DON'T PRESS THAT ...”
Go back to contents mind map
Setting up (IT) audit
I’ve just been invited to establish an Internal Audit function: where do I start?
The following advice is derived from guidance originally from the Institute of Internal Auditors:
Interview senior executives, directors and board of directors/audit committee chairmen to build rapport, to ensure those at the top have a clear picture of the internal audit function, and to clarify expectations of all. Use this opportunity to discover what management and the board believe are the greatest risks to the organization, while keeping in mind issues, problems and opportunities that have already been identified. Develop a system for cataloging such information.
Review the audit committee charter.
Benchmark the internal audit functions in your industry peers, specialty groups, organizations of a similar size etc
. Check out IIA's GAIN services
and review past GAIN surveys
Review the organization’s policies and procedures, especially those pertaining to governance or management's responsibility to control the organization.
Discuss with the external auditors open and closed internal control issues that they have identified (ideally including any concerns that have not been formally reported).
Develop the audit universe - [not, in fact, a weird parallel existence where the conventional laws of physics are suspended but] a list or map of all auditable entities defining the scope of internal audit’s work.
Map out the major processes/operations within the organization. Meet with operations managers, including those in IT, in order to understand their risks and concerns.
Undertake a high-level risk assessment for the organization taking account of both external and internal risk factors.
Develop a charter for the internal audit department or function. Ensure that both senior management and the audit committee review and approve the charter.
Build your budget and, based on the risk assessment, an audit plan addressing risks in decreasing order. The amount of the plan that can be accomplished in the planning period (usually a year) will depend partly on the quantity and nature of risks and issues identified by audit work, partly on the internal audit resources (particularly staff) and partly on auditee resources and support from the organization. Set aside sufficient time and resources in your audit plan for management requests, special investigations (e.g. fraud work) and contingency (at least 10%, preferably rather more at the start: in the unlikely event that you complete the plan early, you can always tackle risks and issues further down the priority list).
Hire your staff and develop a plan for staff training. Ensure your staff covers the range of expertise needed. You may also consider outsourcing portions of your audit plan to external service providers or seconding professionals within the organization.
Ensure that senior management notifies other departments of your existence and requires their complete cooperation. Explicit, overt support from senior management is a critical success factor, hinting that you should probably invest some energy in making them first familiar then then comfortable with the internal audit approach. Work with management to establish effective relationships, reporting mechanisms and metrics.
Establish a quality assurance program.
The IIA is undoubtedly a valuable source of guidance, advice and assistance on internal audit matters generally, but is not the sole source. COBIT, ISO 20000 (or ITIL) and ISO27k are well respected standards for example that can usefully be incorporated into the IT audit function’s working practices and can influence the way the function plans its work. ITIL can help IT auditors appreciate the set of idealized or best practice IT operational and management processes characteristic of a well-run IT department. Standards such as ISO/IEC 27002 and ISO/IEC 27007 can help scope the bulk of the technology audit universe. COBIT might entice you down into a deep, dark, rabbit warren of concerns but at least there are carrots.
Special bonus section for the humour-impaired
IT auditing is a very very boring career frequented by nerds and geeks with extreme personality disorders and BO. It is undervalued and not in the least bit attractive to those of the opposite sex. Only high-school dropouts and those who cannot make it as proper accountants become IT auditors.
My advice is very clear. Do not under any circumstances consider becoming an IT auditor. Accountancy the way to go, my son. Learn those tax tables like your life depends on it!
I've finished this FAQ. What other resources are there to help me?
The best advice is to join ISACA. Tell them I sent you and you’ll save $10 off the joining fee (my ISACA member number is 064227). If enough of you do that, one day I’ll earn a rice steamer or maybe an electric slipper.
The web is an excellent source of information on IT audit, especially on the technical aspects (e.g. information security vulnerabilities). Websites such as www.ISACA.org, www.theiia.org, www.ISSA.org and www.ISC2.org have information relating to their professional qualifications as well as broader topics of interest to practising IT auditors, as well as those who have finished practising and started doing.
Please let us know what you think of this FAQ (good and bad!). We especially welcome additional relevant questions or topics that you feel should be included, and of course any corrections or extensions to the existing answers, including links to other web resources.
Who on Earth wrote this stuff and what were they on?
This FAQ was conceived and written by me, Gary Hinson of IsecT Ltd. I maintain and update it from time to time to incorporate feedback suggestions and new answers to common questions from readers plus my own sporadic brainwaves. Before I saw the light and Got A Life (aka became a consultant), I was a certified IT auditor who experienced or at least tried most of the things written in the FAQ in the course of my 25+ years as an Infernal Auditor and Information Security Manager. I didn’t (often) bayonet the wounded (ho ho ho, how that phrase makes me laugh, every time I hear it for the first time). (But I like ((parentheses))). Please forward any complaints, corrections, improvement suggestions, feedback or other comments to me personally by email (Gary@isect.com). I especially welcome additional FAQ topics (questions, with or without answers!), and links to other related information sources on the WWW. Or folding money. Gold bullion. Books from my Amazon wishlist. Whatever. If you think I’m desperately wrong about something, tell me. I can take it. I’m a full-blooded fire-breathing reformed former auditor with specially toughened scaly skin.
Copyright notice and formal bits
Copyright © 2015 IsecT Ltd. You are not permitted to modify this document, include it within other documents or websites, or sell/circulate it for commercial gain … but, by all means, please use it for study. You are welcome to link to the original source published and occasionally maintained on the IsecT website. These words before you now constitute the most up-to-date, definitive version, the real thing - accept no substitute. Feel free to share the official permanent URL for this FAQ:
You are very welcome to refer to this FAQ in awareness briefings and training courses on IT audit and information security, and to include hypertext links to it on your corporate intranet or Internet website. Print it out and spend odd hours leafletting fellow commuters and shoppers if you wish. Drop whole boxes on enemy territory. Use it for Origami practice if you will but please help spread the good word about IT auditing! If you link to this FAQ from a public website, do please let us know so that we may reciprocate.
This is not legal advice. If it were, you’d be charged an arm and a leg for the privilege of reading it and we’d be paying a huge professional indemnity premium. Nor is this information risk or security advice. Go find a salt cellar, turn it upside down for a few seconds and take a great big pinch ...
December 2015: having not touched it for N-moons, plenty of stuff needed updating, particularly in the certifications section. The IIA’s IT Audit BBS seems to have expired - shame as it was good to be able to share some knowledge and contribute to the development of the profession, in my own little way. Other broken links repaired or expunged. I’ve left some to keep you on your toes.
March 2014: tidied up a few broken links.
February 2014: oh joy, another IT audit qualification! FITSP-Auditor added.
December 2013: a smattering of twiddles. I really ought to check all those off-site URLs but, to be perfectly honest, it’s fast approaching rum o’clock on a Friday evening. Made the hyperlinks hidden beneath those clickable areas on the contents mind map point in vaguely the right direction to the corresponding sections of text. Added some notes about how to disagree with the auditor in the unlikely and remarkable event that he is actually, provably, Wrong, with my thanks to various learned colleagues on the ISO27k Forum for their inputs.
March 2013: noted the perspective aspect of report-writing.
April 2011: noted ISMS internal audits as a type of IT audit.
May 2010: lightly sprinkled a sprinkling of minor adaptations, nothing serious.
February 2010: added the CIPP privacy qualification from IAPP.
January 2010: a shoal of tweaks. A shake. A twist. A convolution.
September 2009: tarted up here and there. Whatever happened to the Master CCE qualification?
January 2009: likened internal vs external audits to white vs black box testing, thanks to an idea from Anup and Thomas.
October 2008: slight adjustments. Re-coloured the mind map to be readable without squinting.
July 2008: a few tweaks.
June 2008: linked to a new CISA FAQ (thanks Dinesh).
February 2008: minor tweaks, as is my wont.
December 2007: fixed broken links to ISO27001security dotcom (another one of my side interests) and various others. Please will someone stop the Internet changing for a bit while I catch up?
November 2007: inserted a link to EDPACS under useful IT audit resources.
August 2007: added an audit put-down to the classic “But we’ve always done it this way” ‘argument’ put forward by so many lemmings.
July 2007: finally caved in to the inevitable and changed “computer audit” to “IT audit” throughout. Referenced ISC2’s Global Information Security Workforce Study. Added links to the IIA piece about setting up an Internal Audit function (as in establishing, not duping).
June 2007: partially reviewed and revised the contents whilst working on a long-since threatened article on ‘state of the art IT auditing’ in EDPACS. Fixed link to DRII’s certification page. Meanwhile ISC2 has quietly introduced the CAP qualification without asking me, and the IIA has dropped QiCA. “Prof C” caught my eye too - think I’ll add that to my business card.
March 2007: added a warning about the inscrutable “CISACA” lookalikey phishing websites targeting CISA registrants.
January 2007: incorporated slightly-paraphrased (para-paraphrased? Meta-paraphrased?) sage advice and other herbal encouragement to those studying for CISSP by kind permission of Professor Mich Kabay at Norwich University. Thanks Prof. You are a hero.
December 2006: referenced the masters degree course in computer & network security from DePaul Uni.
October 2006: finally corrected the spelling of Clement Dupuis’ surname. Sorry Clement - je suis un imbecile. Updated the PDF version too. Fixed broken link to IIA’s ITaudit BBS. Added the description of IT auditor as ‘translator of business risk’, lifted with permission from an excellent posting on CISSPforum by IT audit sage, Jim Dillon (good luck Jim).
September 2006: advised the use of strong access controls to protect often highly sensitive audit evidence.
August 2006: added yet more qualifications/certifications namely PCIP, CEH (and similar) and Symantec’s certs. Thinking about offering the FAQA (FAQ Author) qualification to fellow FAQers. Added a bunch of suggestions on the value auditors can bring to development projects, and a link to WizRule CAAT, shamelessly lifted from a discussion thread on the IIA’s IT Audit bulletin board. Inserted two missing words (thanks to Winnie, and no thanks to the dumb spellchecker on this PC).
July 2006: added a link to dmeissler.com’s list of infosec and audit certifications (subsequently dropped when that site went to pot). Added a link to the CCO qualification from BECCA.
June 2006: the phrase ‘All rights reserved’ is no longer necessary on our copyright notification, I believe. Let’s hope the magic © incantation still works anyway. Thoroughly updated the PDF version. Added a mind map contents index thing to confuse aliens.
April 2006: added a classic quote from an auditee complaining about ‘frequent use of the word “significant”’ in an audit report that was evidently rather uncomplimentary towards them.
March 2006: fixed broken links to the BCS. Referred to American English. Updated the PDF version.
December 2005: inserted a rant about the PCAOB, having been prompted to mention them in the FAQ by one of our valued FAQ readers, and updated the Andersen and Enron links (thanks Darian). If anyone disagrees with the rant, by all means tell me.
August 2005: added advice on setting up an (IT) audit function based on IIA advice sent to the IT Governance mailing list. There’s plenty more to say in that section, when I find the time to write it ... Beefed-up the qualification write-ups
July 2005: wrote a section on auditing against Best Practice, whatever that means
May 2005: updated the ACL link (thanks Jacqueline).
April 2005: added Q&A about what questions to ask as an auditor (thanks for asking, Maurie). Correctly named the IIA (oops). Added the CCcure recommendation (go Clement go!).
March 2005: made a number of minor amendments. A smattering. A tweak. An indecision maybe. What is the collective noun for minor amendments? Included PMP qualification. Noted that GIAC no longer has a practical bit (shame).
October 2004: added a paragraph on careers vs. jobs. PDF updated.
September 2004: added the Amazon wish-list link for those generous and kind readers who want to express their gratitude for the extraordinary effort involved in writing and maintaining this FAQ. Added yet more qualifications (this is getting silly) plus a snippet of advice for interviewers. SMS/TXT gets a mention.
August 2004: increased the font size for those with dimensionally-challenged pixels and added more about experience (thanks Anton). Wrote about compliance auditing. Added CFE and ISSPCS qualifications. Boy Scouts’ badge for knots coming soon.
June 2004: expanded on the report-writing sub-process (warning: I’m in an especially cynical frame of mind today. The medication must be wearing off.). Also added a section on choosing audit consultants, a link to the IIA ITaudit bulletin board (thanks for the suggestion Len), and a brief word on getting qualified to earn more money. PDF updated June 30th at 11pm, just before bedtime. Night night.
May 2004: added CAAT section, yet more infosec certifications and the IIA’s categories of IT knowledge to this webpage ... although not yet to the PDF. Too busy. Sorry. Maybe next month.
March 2004: more types of audit added. Converted the web page back into a Word document and then to an Acrobat PDF for easier printing. Added the ‘rate this paper’ link below.
January 2004: linked to CISA article in NetworkMagazineIndia. Expanded on the traits and competencies of auditors.
December 2003: added notes about retention of audit evidence. Deleted reference to anoraks and things going pear-shaped for non-Brits. Added feedback section.
November 2003: added SSCP qualification.
September 2003: narrowed the page to fit pixel-challenged 800x600 displays and printers. Added still more IT audit related qualifications.
August 2003: more minor wording changes. Added CISM and NoticeBored links and contents. This project is starting to intrigue me.
June 2003: minor style amendments to match new sexy-looking IsecT website.
March 2003: various minor amendments, nothing significant enough to name.
December 2002: FAQ launched on an unsuspecting world from www.IsecT.com.
If you enjoyed this FAQ, please rate it at the excellent CCcure.org website and put a link to it on your website to help spread the good word about IT auditing. Like it on Facebook if you like, and if you know what that means (I don’t). If you hated it, found errors or omissions or know of a better way to put/do something (which is entirely possible), tell me and I’ll
send the boys round pretend to do something positive about it.
If you disagree with what’s written here, have a much better way of putting it or feel there is something else that definitely ought to be said, please share your wisdom. I am grateful for all knowledge contributions, questions and answers. Telling me the humour is not appropriate and my spelling is “funny” will simply make me laugh. Auditing is a game for grownups.
I am happy to spend laborious hours researching, writing and updating the text and to fund the web hosting and bandwidth for the FAQ through IsecT in order to give a little back to the Internet community that gives us so much but if you insist on contributing, please consider buying books through the Amazon links above (we receive commission) or mentioning my ISACA number when you join (I get points, and points make prizes). As a last resort, please express your gratitude by telling someone else about the FAQ, giving your partner a gratuitous hug, grinning broadly at a complete stranger or writing a security haiku.
Either way, whether you enjoyed it or not, I would love to hear from you. Well OK, especially if you enjoyed it. Go ahead, make my day. Seriously, thank you everyone who has taken the trouble to spread the warm glow of appreciation. Your kindness spurs me on.
P.S. The big blank space below is brought to you courtesy of one of many bugs in Net Objects Fusion which claims to be WYSIWYG but is really WYSINWYG. As you scroll down, imagine what an IT auditor would make of a software company that produces such shoddy work and remains indifferent to customer feedback/complaints about readily reproduced bugs such as this ... harrumph. My audit recommendation: do not buy this program.