|
Frequently Avoided Questions
about IT auditing
Last avoided in March 2008
CLICK HERE to DOWNLOAD a
PRINTOUTABLE pdf VERSION
Clickable contents
Introduction
This document is published on the DubDubDub as a public resource. Our purpose is twofold: to inform and entertain. Please forgive the British humour, spelling*, InCorrecT CapitaLisatioN and distinctly cynical style ... but do experience the passion. We sincerely hope that it answers all your basic questions about IT auditing, but if not, please see the feedback section towards the end – we would really appreciate your feedback and suggestions on how to improve this FAQ. More questions. More answers. And better 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). 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 exhaustedly over your keyboard.
If you are an auditee (i.e. 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.
The FAQ should also prove beneficial for students and others nuts enough to consider actually becoming IT auditors. Nontechnical auditors (e.g. financial and operational auditors) might even learn a thing or two.
* Special apology for our American cousins. Try ignoring superfluous letter u’s and mentally swap the occasional ‘s’ for a ‘zee’ (or better still, for a ‘zed’). I speak the Queen’s English not “British”. You speak “American”, neither “English” nor “British”.
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 with governance (control) of information and communications technologies (computers). IT auditors primarily study computer systems and networks from the point of view of examining the effectiveness of their technical and procedural controls to minimise risks. Actually, to be honest, like all auditors we spend the bulk of our time dealing with the people who specify, develop, test, manage, administer, use and abuse the computer systems but it’s being able competently to audit the information technology that sets us apart from the riff-raff.
What do IT auditors actually do?
In short, IT auditors review risks relating to IT systems and processes including:
Inadequate information security (e.g. missing or out of date antivirus controls) Inefficient use of corporate resources, or poor governance (e.g. spending large on unnecessary IT projects) Ineffective IT strategies, policies and practices (including a lack of policies etc.) IT-related frauds
Management calls the auditors in to review stuff and they in turn produce formal reports and recommendations that circulate to management, but they operate independently in order to avoid management telling them what answers they want to hear!
Also known as ...
IT auditing is also known as IS, IT or ICT auditing and systems auditing. In certain quarters, auditors who challenge the status quo are known as “Red Teams” or sometimes simply “Them”.
OK, so what is auditing then?
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 - the 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 importantly, independence is also a state of mind i.e. freethinking, able to consider situations objectively. Switzerland has the right idea. Some judicial systems come close. 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. 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. Opinion - auditors provide both objective facts and subjective opinions on a given situation. Although subjective, their 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 do, 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 impressed. 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 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 mess out and don’t ever do it again’). Recommend - auditors generate “audit recommendations” but 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 comes out i.e. political clout. Control improvements - improving the system of controls generally means adding necessary controls that were missing. In rare cases, auditors may recommend removing controls, generally because they are ineffective, disruptive or wasteful. Limit - risks, like fraudulent politicians, spam emails and bugs, can be reduced but not totally eliminated. Good business involves minimising risks cost-effectively, and being prepared for the worst if things go wrong (contingency planning). Risk – is the chance that something might go horribly wrong. Formally, risk is the chance combination of threats (usually caused by someone with malicious intent, sometimes just due to carelessness or incompetence), acting on vulnerabilities (weaknesses in ‘the system’, typically due to a lack of controls in many computer systems and operating procedures) to cause impacts (adverse outcomes i.e. financial, human and political fallout when the brown stuff hits the fan).
Here’s another view: auditing is a mechanism for examining the effectiveness of organizations, systems, processes, risks and controls. Audits enable management and other stakeholders to:
Discover what’s really going on at a point in time Find out about potential problems, hopefully before it’s too late to fix them Evaluate business situations objectively 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 view: “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.” (Jim Dillon).
And for the last 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 (just 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 things really do 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 from a cynic. It gives auditors something in common with insurance salesmen, weather forecasters and soothsayers. IT auditors genuinely believe the lottery is simply 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 needs to understand that the insurance man sees the lock, the manager sees the cost of the lock, 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 see the risks, take risks with little thought as to the consequences, or conversely avoid taking perfectly acceptable risks because they fear the consequences. Good managers will often push the boundaries by cutting corners and taking acceptable risks, in order to minimise costs and maximise net gain. Outstanding managers consistently make good calls, consider the potential downside and often have contingency arrangements.
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 a new overtime spreadsheet”.
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 systems employ auditors with both IT audit and accounting qualifications, or teams containing each type of auditor.
Is it anything to do with counting PCs?
No! Absolutely not!! Unless, perhaps, it is necessary to substantiate a control failure e.g. a stock count 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 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.” [This was a genuine vacancy notice. I’m tempted to get some new business cards printed: “Gary Hinson, IsecT Ltd., Emergency IT Auditor. 24x7 callout. No job 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 modification of the finance system by unauthorized persons. It’s 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 if the Risk is 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. So long as the Controls are Good Enough, 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, an interesting concept in itself that raises 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?
Anyway let’s look at the available sources of Best Practice.
The most obvious source 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 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 other areas that could be considered Best Practice, at least within the specific scope of their intended applications Professional bodies such as (ISC)2, SANS, ISSA, ISF and ISACA also promote best information security practices in an international arena. The CISSP CBK (Common Body of Knowledge), C OBIT, the Information Security Forum’s Standard of Good Practice in Information Security Management and GAISP/GASSP (Generally Accepted Information/Systems Security Practices) are all examples of generally agreed standards of Best Practice, though whether an individual agrees with any or all of them is a moot point Some industry bodies define their own generic information security related standards too e.g. SAS 70 and PCI DSS for financial services Governments and legislatures define standards in the forms of laws and regulations e.g. for electronic signatures, copyright, privacy & governance. Some of these are really mandatory (comply or go to prison), most are highly recommended (comply or risk going to prison), and some are advisory (comply or risk spending a fortune on lawyers defending your position) Some companies set and promote their own best practice standards 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, and fall back on professional auditing standards defined by ISACA, the IIA and the audit/accountancy trade bodies and regulators such as the PCAOB Information security professionals (CISSPs, CISMs and others) typically bring with them their own individual sets of ‘accepted good practice’ based on their professional experiences which, in many happy cases, coincide with generally accepted best practice. This is in the nature of a skilled craft - the craftsman brings his own unique 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. However, beware the advice of recent college graduates without Real World Experience, some of whom scored higher on theory than common sense.
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 and interesting 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, regulations and contractual terms ... but compliance is really management’s day job. Good auditors are more likely to check whether management processes for achieving and assessing compliance are effective, 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 situations worth exploring in more depth.
Software license audits are a classic example. 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 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 in a secret DVD duplication factory at a Far Eastern subsidiary would probably be a different matter entirely ...
How does IT audit fit with governance, risk management and information security?
Governance is a genuine solid-gold buzzword, essentially meaning systems of control. 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 whole organization (taking in commercial, operational, market, financial, regulatory and other risks) or just to specific projects and systems.
For a rather formal perspective on the relationship between auditing and governance, read the Public Company Accounting Oversight Board (PCAOB)’s Auditing Standards. The PCAOB was established by the U.S. Securities and Exchange Commission - the SEC - as (yet another) independent oversight board to regulate/guide professionals involved in auditing companies, this time specifically regarding compliance with the Sarbanes Oxley Act of 2002 (SOX). Whether PCAOB was actually needed or not you can maybe judge for yourself from the fact that their Auditing Standard No. 1 stated: “The Board has adopted as interim standards, on an initial, transitional basis, the generally accepted auditing standards, described in the American Institute of Certified Public Accountants’ (AICPA) Auditing Standards Board’s Statement on Auditing Standards No. 95, Generally Accepted Auditing Standards, in existence on April 16, 2003.” The first standard goes on to provide template or example SOX audit reports that say virtually nothing of any practical use, but cost SEC-listed companies vast amounts to obtain. Auditing Standard No. 2 further states: “In the United States, the Committee of Sponsoring Organizations (“COSO”) of the Treadway Commission published Internal Control – Integrated Framework. Known as the COSO report, it provides a suitable and available framework for purposes of management’s assessment. For that reason, the performance and reporting directions in this standard are based on the COSO framework.” To give them their due, the 2nd standard does go on to describe the auditing processes in more depth but it is hardly revolutionary. <Rant over>
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 i.e. 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 in most organizations that fall well outside the scope of ICT (e.g. the use of non-executive directors to review and guide executive management has nothing to do with ICT). Good IT auditors have a solid understanding of the practicalities of implementing their recommendations, yet are able to persuade certain auditees to go well beyond their comfort zones. With a large pointy stick if necessary.
Go back to contents mind map
How is an IT audit performed?
“How do they do that”?
Different audit organizations go about IT auditing in different ways and individual auditors have their own favourite ways of working. Purely for the sake of illustration, you understand, the main stages of a ‘typical’ IT audit assignment have been extensively analysed and professionally illustrated by a highly paid graphic artist as follows:
Audit process flowchart
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 and, sometimes, subjective impressions that deserve further investigation. 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 checklist with a bunch of interesting questions, space to scribble some notes and some other impressive-looking columns). Fieldwork - gathering evidence by interviewing staff and managers, reviewing documents, printouts and data, observing processes etc. This step may include the use of Computer Aided Audit Techniques (CAATs) - more info below. Analysis - 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. Reporting - desperately reviewing and trying to make sense of the analysis, then writing it 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, and finally issuing it. [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.”]. Closure - 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 and chasing-up management to complete the actions they promised months earlier. 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 debacle).
Steps 3 and 4 may on occasions involve the use of automated data analysis tools such as ACL or IDEA, if not Excel, Access and hand-crafted SQL queries. Even Notepad.exe 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 a fairly involved sub-process all by itself. The wise auditor starts by converting his/her thoughts that have been developing throughout the fieldwork and analysis phases into rough notes and reviewing them against the checklist and evidence. The unwise auditor just starts writing. Anyway, audit findings are 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 the seasoned campaigners of the department 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 essentially means 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.
When at last everyone in Audit is thoroughly sick of it, the Final Draft Report is sent for its first external review by, or presented to, the auditees ... and then the real battle commences. The findings are challenged. The analysis is challenged. The scope is revisited. The laws of physics are called into question. Every phrase and nuance is challenged. The spelling is challenged. Even the font and font size are challenged. The quality of the paper is challenged. Challenges are challenged. The auditor’s competence is challenged. Even his/her parentage may be questioned if things really get nasty. 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 between senior auditees and senior auditors to reach a negotiated 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 or splash 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 schedule or audit plan. 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. 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 keep little black books locked away in their desks. Upset the Audit Director at your peril.
Finally, here’s another view of the process presented as a GANTT chart for the project managers among us:
How long does an audit take?
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 steps noted above. For the ‘numerically challenged’, that means an audit planned to include about a week of fieldwork will take approximately six 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 day week. Or very long days. Geddit?
Progressive organizations audit their IT developments and other major change projects throughout the project lifecycles, from cradle-to-grave. In these cases, audits last as long as the projects in elapsed time but consume just a few percent of the total project man-days.
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 my answer:
“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?). 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. You should definitely prioritize the ‘highs’ for obvious reasons (as all hippies know). These are the things that would keep you, the system owners, the CEO and the shareholders (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 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. Next, develop your ‘audit checklist’, mind-map or whatever you use to map out the things you want to check, the issues that concern you, and the boundaries of your audit. This is an important step, drawing on the control objectives and specific controls that you are going to go looking for. After all that preparation, the actual audit work 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 your main points, and always be prepared to go back and ‘take another look’ if someone insists you have got a fundamental point or finding wrong. And if that’s all too much, 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 answer 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. The best I can do is refer you to some generic audit checklists such as those at ASAP ... but don’t expect too much. 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). Clever 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 just deserve more time.
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 audit teams, IT Audit may have a number of dedicated and specialised 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) 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, ‘audit friendly’ folk tend to be more chilled-out to the extent that auditors may even occasionally be called upon to perform conventional (internal) consultancy rôles.
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 or implemented 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’ (‘business-critical’ applications may be reviewed annually), although lower-risk areas may be audited “on a less frequent basis” (don’t you just hate that 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 always align itself alongside risks to the organisation, plus or minus fudge-factors.
What is the difference between Internal and External (IT) audit?
Cynical answer: “Only the latter 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 organization to perform audits as part of the annual process of preparing company accounts. 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 …”.
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 supply, 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/programme management controls (often, the auditor is the only person with the knowledge, experience and balls nerve to point out that the average project manager’s progress reporting is “somewhat optimistic” at best); and (2) the specification, development, testing, implementation and operation of technical and procedural controls, including classical technical information security controls and the related business process controls such as divisions of responsibility. IT management audits: review the organization, structure, strategy, work planning, resource planning, 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). IT process audits: review processes which take place within IT 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, and the management of changes to the organisation as a result of ICT. Information security & control audits: review controls relating to confidentiality, integrity and availability of systems and data. IT legal compliance audits: review legal and regulatory aspects of IT systems (e.g. software copyright compliance, protection of personal data). Disaster contingency/business continuity planning/disaster recovery audits: review arrangements to restore some semblance of normality after a disaster affecting the IT systems, and perhaps assess the organisation’s approach to risk management. 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. “Special investigations”: this is audit-speak for contingency and other un-pre-planned/hush-hush work such as investigating suspected frauds or information security breaches, performing due diligence review of IT assets for mergers and acquisitions etc. Oh and Christmas parties.
Computer Aided Audit Techniques CAATs
CAATs don’t have fur, 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. Microsoft Excel, for example, has functions for tracing dependencies between cells, sorting data ranges etc. Database programs typically have custom reporting facilities (such as SQL) and sometimes include pre-configured reports intended for 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 - the most important skill being the ability to ask 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 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? Are any of our suppliers also employees? Who will win the Americas Cup? [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 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 slow machine) 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 simplest analysis that addresses the risks. Nothing to do with beards and shaving.
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 have to be resolved by next Tuesday. At 11.
In an experienced IT auditor’s hands, SQL can be a useful 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 complex queries are run on the Production system in peak hours or update commands are issued by mistake. In fact, even if update commands are not made but there is the potential for the auditor to have made updates, this can cause problems later if something goes wrong with the system and someone has it in for audit. Experienced IT auditors insist on read-only access.
Why don’t the auditors stop IT development projects going off-the-rails?
Developing systems audits are arguably the most difficult type 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 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 vast amounts of money since IT auditors seldom get the opportunity to audit small projects and particularly end-user developments perceived (by management at least) as low risk.
It is an unfortunate truth that in IT, professional, disciplined and effective project management is a welcome relief rather than the rule. An experienced IT auditor has generally witnessed all sorts of disasters at close range through bayonetting a number of development projects. For some obscure reason buried deep in human psyche, the symptoms of imminent disaster that loom large to an experienced IT auditor are mysteriously invisible to the average project manager … and indeed to their managers and senior management as a breed. But that’s only the start of it. Persuading the organisation that eventually, under sufferance, acknowledges its problems to actually stop a runaway project is very much like trying to stop a runaway Welsh coal train flying down a steep incline at full steam, bach. Ordinary brakes are simply not good enough. The reason is known as “corporate politics”: big projects are almost invariably led by bigger-than-life characters, specifically appointed by management because they are “good blokes” and because they have the big cajones to manage big projects. The IT auditor’s rôle is truly to proclaim that the king hath no clothes. And make like a rack-and-pinion rail or impersonate an enormous block of concrete and steel welded to the tracks.
Do you remember the rather boring definition of IT audit earlier? Audit is about encouraging management to manage and reduce if not eliminate their risks. Auditors help identify and find ways to limit the risks relating to IT developments. Proactive managers take note of audit recommendations and make 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 (see ISACA’s ValIT or read John Thorpe’s wonderful book The Information Paradox 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 a shoulder to cry on or a quiet word in your ear Reviewing risk assessments, system security designs etc. from audit’s governance and control specialist point of view Contributing to system 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 - the stuff we do Hands-on testing of key system controls (technical and procedural - please don’t tell me the user training and sysadmin docs will be finished “later”, do them first or failing that now!) Reviewing implementation processes and process or quality assurance controls (e.g. have sensible plans been prepared to “cleanse” malodorous 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 fall off the Web in a smouldering heap 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). 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. You might say that auditors are irresponsible.
Who audits the auditors?
Look here smartarse my dear fellow, auditors are (mostly) highly trained and experienced professionals diligently following structured and formal processes that include all manner of process and quality assurance controls. Their work is routinely scrutinised by themselves, by other auditors and 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 reasonably objective hard 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. If you want to audit the auditors, go ahead punk sir, make my day be my guest.
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 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 perhaps bribery.
What happens to the audit evidence?
“Audit evidence” in a typical IT audit comprises system dumps and printouts, interview notes 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 megabytes of computer data. However, the value of an audit is emphatically NOT a function of the amount of material generated. Big is not necessarily better. Small is cool.
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).
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 makes 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 reported formally, including less material points and issues which they believe to be true but were perhaps unable to prove. 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). The audit-auditee relationship is based on distrust - audit has to report formally in order to get management to act at all, and expects that anything not stated formally in the final issued report will probably not happen. 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 vary in formality.
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 electronic databases plus locked cabinets or safes for paperbases) to protect audit evidence against unauthorised access. There have been far too many incidents where auditors’ laptops have been stolen or lost. It is entirely reasonable to make this a firm requirement of the contract with external auditors and a corporate policy covering internal auditors. [I’ll leave the question of who should check that the controls are properly implemented as an exercise for you, dear reader.]
Go back to contents mind map
How should I find a consultant IT auditor?
[In the dim and distant past, I have been a consultant IT auditor. I now have a real job. This is 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)?
I would say there are three key aspects to cover when preparing an ITT:
First is to define the audit 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, recommendations, structured audit files with evidence ... ?) [This information would of course still be needed if the audit was run by in-house employees] Secondly, what type 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? How important is personal hygiene to you? Thirdly, how will the assignment 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 someone to do the fieldwork to your specifications and 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 update, monthly reporting, 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 (the same applies to the consultant/s).
Who should I “Invite To Tender”?
You have already demonstrated your initiative by finding this FAQ on the web - the web is the natural place to search for potential suppliers. Googling “it audit consultant” finds over 1.1 million pages so you shouldn’t exactly be short of choice. The market is quite diverse, ranging from The Big Six Five Four 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 agencies that specialise in audit and information security, or perhaps consider contracting with an independent, trustworthy and experienced consultant to run the assignment for 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 English put it). Value-for-money is another way of saying you get what you pay for.
One more tip for selecting is to look at the quality of the suppliers’ proposals - this should be a guide to their ability to write a good audit report, and gives you a clue about the way they intend to approach the job. Can they write good English (or whatever)? Look for proposals that actually reflect what YOU want from the job, not standard boilerplate responses that have been cut-and-pasted to your assignment. By the way, glossy brochures and so on are more boilerplate. Look behind the gloss and polish to see the real quality. Think ‘second hand car salesmen’ and you’ve got the right idea.
Finally, make sure to review the CV/s of, and ideally speak to, the actual person/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 team of people, not a faceless “team”. It is not unknown for sales pitches to be fronted by top-notch consultants but wet-behind-the-ears juniors to be placed on the job. Juniors are not necessarily A Bad Thing (we all had to start somewhere) but audit teams should be balanced. And it is not unreasonable to expect to pay much less for juniors than 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, 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 will be all set to do the job.
Remember the third part of the ITT? This is where your preparation starts to pay off. Set up a management process to track and guide the audit as you wish, in conjunction with the audit 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. Nice going my son!
This section explains how to 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 rather curious credentials.
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 really listen to what you are actually being told. Read the lines and then between the lines. Especially between, like mental floss.
Then join ISACA. Click the link to see a 3 minute video extolling the virtues of ISACA membership. I endorse everything they say. Join up!
An editorial piece at CertMag.com advised people to think in terms of making a career move not just a job move, in other words you should invest in your chosen occupation. The article refers to careers information security but applies equally to IT auditing. 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.”
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 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 (Board positions) take a spell in Audit, which almost makes it sound like an interesting career move. Straight out of college is also possible but not recommended. Let the backs of your ears dry first.
Information security and IT risk management are probably the most closely allied fields to IT audit since they also encompasses 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. Higher pay and not having to complete the Agreed Action Plan 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 trade’.
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. A predilection for pizzas is a bit of a giveaway.
What qualifications do I need?
IT audit & information security qualifications
Roll up, roll up. Certification and Accreditation (C&A - nothing to do with the British clothes store of the same name) is something of a growth area for various professional IT audit, information security and certification organizations, partly because it is a ‘nice little earner’, so you face quite a choice. Check out our little list of qualifications:
ABCP, CBCP & MBCP: Associate, Certified & Master Business Continuity Professional certifications from DRII, the Disaster Recovery Institute International BSc, MSc, PhD and similar academic qualifications in information security and/or IT auditing from eminent institutions such as Royal Holloway, University of Houston, University of Nebraska, University of Texas, Norwich University (of Northfield, Vermont, not Norwich Business School at the University of East Anglia in Norwich, England), DePaul University, Colorado Technical University, Capella University and James Madison University. Accused by those with their ears too close together of being “too academic”, courses like these give students the conceptual framework, depth of understanding and confidence to tackle any infosec topic, including the most technical issues, provided they are still prepared to put in the time and effort to gain real-world experience and dry behind their ears CCO - Certified Confidentiality Officer from BECCA, the Business Espionage, Controls and Countermeasures Association CCSA, CCSE, CCSE Plus, CCMSE, CCMSE Plus VSX, CCSPA: are Check Point’s no-bones vendor-specific certifications ( CCSA shares the same acronym as the IIA’s Certified Control Self Assessor qualification - there’s more info in the next section) CEH: Certified Ethical Hacker, CHFI Computer Hacking Forensic Investigator, LPT Licensed Penetration Tester and ECSA EC-Council Certified Security Analyst, all from “EC Council” which is the self-styled International Council of E-Commerce Consultants and promoter of Defcons, not some obscure body of the European Commission CFE: Certified Fraud Examiner from ACFE, the Association of Certified Fraud Examiners CISA: Certified Information Systems Auditor (here’s an independent view of CISA which is also a well-established qualification from a well-respected professional body, probably the most widely trusted IT audit certification) and CISM Certified Information Security Manager (a newer certification, broadly similar to CISSP but with more emphasis on management judgment and experience on information security management matters), both from ISACA whose focus has shifted from IT audit to IT governance [Note: if you are registering for CISA or CISM or seeking study materials, beware lookalike phishing sites: register directly with ISACA.org. Similar advice applies to other similar situations, similarly.] EnCE - Encase Certified Examiner vendor-specific certification by Guidance Software, supplier of Encase the industry standard forensics software GIAC: Global Information Assurance Certification by SANS - includes a general information security course plus specialisations (“G7799” is the GIAC ISO/IEC 17799 [now ISO/IEC 27002] specialism, for example). GIAC originally involved a practical element to the assessment but unfortunately it was dropped like a clanger ISSPCS - the International Systems Security Professional Certification Scheme from the International Systems Security Engineering Association ( ISSEA) PCIP: Professional in Critical Infrastructure Protection is a certification from the Critical Infrastructure Institute, covering the design, maintenance and management of security architectures for critical infrastructure, SCADA and other high-availability environments, apparently Security+: a basic entry-level information security qualification from CompTIA, the Computing Technology Industry Association - a good place to start if you have minimal prior knowledge in this area SPS: Symantec Product Specialist, STA Symantec Technology Architect, SCSE Symantec Certified Security Engineer and SCSP Symantec Certified Security Practitioner claim to include “vendor neutral” ( i.e. non- Symantec) elements SSCP: Systems Security Certified Practitioner (aimed at practioners/professionals with a focus on information security implementation i.e. those people that enforce the information security policies, processes and procedures on a daily basis; requires 1 year’s work experience; said to be ideal for those working toward or who have already attained positions as Senior Network Security Engineers, Senior Security Systems Analysts or Senior Security Administrators) and CISSP Certified Information Systems Security Professional (the world leading qualification in information security; scope a mile wide but an inch deep; requires 4 years’ work experience), plus ISSAP, ISSEP, ISSMP and ISSJP (Information Systems Security Architecture/Engineering/Management/Japan Professional specialisations; an inch wide and a mile deep in each case; only available to those who already hold CISSP, with SSCP concentrations evidently under development), and CAP Certification and Accreditation Professional - all of these from (ISC)2, the International Information Systems Security Certification Consortium that exists purely to certify infosec professionals, not for profit you understand TICSA and TICSE: TruSecure’s ICSA Certified Security Associate/Expert program. Although TruSecure runs the program, it is said to be vendor-n |
