Domain 1: Information System Auditing Process
Arrow keys or space to move, F for full screen. Read the notes
Information System Auditing Process
26 topics · Standards and ethics · Audit basics · Planning · Evidence and testing · Controls · Reporting and quality
D1ISACA Code of Professional Ethics
The seven principles every CISA holder signs up to, what each one means in everyday audit work, and how the exam turns them into 'what should the auditor do?' questions.
Why auditors need a code
People rely on an auditor's word. A board approves budgets, a regulator closes an inquiry, a customer signs a contract, all because an auditor said "this is sound". That only works if auditors are honest, careful and discreet.
ISACA's Code of Professional Ethics sets out what that means. Every member and every CISA holder agrees to it, and breaking it can cost the certification.
Seven principles on one page
The code has seven principles. They're easier to remember as one idea: do honest, competent work in the interest of the people who rely on it.
Objectivity and due care
Members perform their duties objectively, with due diligence and professional care, following professional standards. In plain words: no favouritism, no shortcuts, and do the job properly even when nobody is checking.
Confidentiality, and its limit
Information gathered during audits stays private. It isn't shared with people who shouldn't have it, and it's never used for personal benefit. The one exception: when a legal authority requires disclosure.
Competence
Members only take on work they can reasonably complete with the skills, knowledge and competence they have, and they keep those skills current.
Report everything significant
Members inform the appropriate parties of the results of their work, including every significant fact they know about. Leaving out an important fact can mislead just as much as stating something false.
The other three
When something feels wrong
How the exam asks about it
| Scenario | What the code expects |
|---|---|
| Regulator legally demands audit working papers | Disclose: legal requirement overrides confidentiality |
| Asked to audit something you have no skills in | Get training or expert help, or decline |
| Management asks you to drop a significant finding | Report it; include management's view if they disagree |
| You learn something that would help you invest | Don't use it: confidentiality and integrity |
| Close friend runs the area you're auditing | Disclose the conflict; you may be reassigned |
Key takeaways
- ✓The Code of Professional Ethics applies to all ISACA members and certification holders. Breaking it can lead to an investigation and disciplinary action, including losing the certification.
- ✓There are seven principles: support good standards, act with objectivity and due care, serve stakeholders lawfully, keep information confidential, stay competent, report all significant findings, and support education.
- ✓Confidentiality has a limit: information can be disclosed when a legal authority requires it.
- ✓Competence means only taking on work you can complete with the skills you have, or can get.
- ✓Reporting means disclosing every significant fact you know, because leaving something out can mislead as much as a false statement.
- ✓When the code and an instruction from management conflict, the code wins.
Exam traps
- !Confidentiality isn't absolute. A legal requirement, such as a court order, overrides it.
- !Taking on an engagement you aren't qualified for breaks the code, even if the result turns out fine. The fix is training, help from an expert, or declining.
- !Leaving a significant finding out of a report because management asked breaks the 'inform appropriate parties' principle.
- !Using audit information for personal gain (such as trading shares on it) breaks confidentiality, even if nobody else finds out.
- !The code is binding for members and certification holders. It's not just guidance.
ITAF: The Standards Framework
ISACA's rulebook for IS auditors: what's mandatory, what's guidance, and the handful of standards the exam turns into scenarios.
What ITAF is
Every profession has a rulebook. Accountants have accounting standards; IS auditors have ITAF, the IT Assurance Framework, published by ISACA.
It tells an IS auditor what they must do on every audit, gives guidance on how to do it, and points to practical tools. The exam rarely asks about ITAF directly. Instead it describes a situation and expects you to know which rule applies.
Three layers, from must to might
Three groups of standards
The standards themselves are organised in three groups that follow the life of an audit.
The general standards, in plain words
| Standard | What it means |
|---|---|
| Audit charter | Audit's purpose, authority and responsibility are written down and approved by the board or audit committee |
| Independence | The audit function isn't controlled by the people it audits |
| Objectivity | Each auditor is unbiased, and looks unbiased, on each job |
| Reasonable expectation | Only accept work that can be done properly, with the access and scope needed |
| Due professional care | Be careful and sceptical, like a competent auditor would |
| Proficiency | Have the skills for the job, or get them |
| Assertions and criteria | Judge things against clear, suitable yardsticks such as a policy or framework |
The performance and reporting standards
| Standard | What it means |
|---|---|
| Risk-based planning | Spend audit effort where the risks are highest |
| Planning and supervision | Plan each audit; supervise staff and review their work |
| Materiality | Focus on what's big or important enough to matter |
| Evidence | Get enough reliable evidence to back up conclusions |
| Using others' work | Check an expert is competent and independent before relying on them |
| Irregularities | Watch for fraud; document and report it to the right people |
| Reporting and follow-up | Report findings and limits; check fixes were made |
Spot the standard
Exam questions describe a situation. Your job is to recognise which standard is involved and what it requires.
| Situation | Standard | What to do |
|---|---|---|
| You helped design the system you're now auditing | Objectivity | Disclose; someone else should audit it |
| Access to key data is refused halfway through | Reasonable expectation | Escalate; report the scope limitation |
| Only evidence is a manager saying 'it's fine' | Evidence | Get documentary or system evidence |
| A consultant's penetration test is offered as evidence | Using others' work | Check their competence, independence and scope |
| You find signs of fraud | Irregularities | Document; report to appropriate management |
Key takeaways
- ✓ITAF (the IT Assurance Framework) is ISACA's framework for IS audit and assurance work.
- ✓It has three layers: standards (mandatory), guidelines (how to apply the standards) and tools and techniques (practical help).
- ✓Standards come in three groups: general (the auditor and the function), performance (doing the work) and reporting (communicating results).
- ✓Departing from a guideline is allowed if the auditor can justify it; not following a standard is a serious matter.
- ✓Key standards to recognise in scenarios: charter, independence, objectivity, reasonable expectation, due care, proficiency, risk-based planning, evidence, using others' work, irregularities, reporting and follow-up.
- ✓The exam tests what each standard requires, not its number.
Exam traps
- !Don't memorise standard numbers. Learn what each standard asks the auditor to do.
- !Guidelines aren't mandatory, but the auditor must be able to justify not following one.
- !Reasonable expectation means only accepting work that can be completed to the standards. It doesn't mean finding every problem.
- !Fraud indicators are reported to an appropriate level of management or the audit committee, not to the press or the police by the auditor alone.
Standards vs. Guidelines vs. Tools
A short one: which of ISACA's documents you must follow, which you should follow, and which are just there to help.
Must, should, may
ISACA publishes three kinds of material for IS auditors. The difference is simply how much you're obliged to follow them.
An everyday comparison
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| What is mandatory for an IS auditor? | Standards (and the Code of Ethics) |
| Can the auditor depart from a guideline? | Yes, if the departure is justified |
| An ISACA audit program is… | A tool or technique: optional |
Key takeaways
- ✓Standards are mandatory. They set the minimum an IS auditor must do.
- ✓Guidelines explain how to apply the standards. They aren't mandatory, but a departure must be justified.
- ✓Tools and techniques are practical aids such as audit programs and white papers. They're optional.
- ✓When a question asks what is MANDATORY for an IS auditor, the answer is the standards (and the Code of Ethics).
Exam traps
- !Guidelines aren't mandatory, but 'ignore them freely' is also wrong: the auditor needs a justification.
- !Audit programs published by ISACA are tools, not requirements.
- !The Code of Professional Ethics is mandatory too, alongside the standards.
Auditor Independence and Objectivity
Why an auditor's opinion is only worth something if they're free from influence, the difference between independence and objectivity, and what to do when either is at risk.
Why it matters
An audit opinion is only valuable if the auditor is free to say what they found. If the auditor works for the person they're auditing, or audits their own work, nobody can be sure the opinion is honest, even if it is.
So the standards demand two things: an independent audit function, and objective auditors.
Two related ideas
Who audit reports to
The standard arrangement splits audit's reporting into two lines. The audit committee handles everything that affects audit's freedom; the CEO handles day-to-day administration.
Five threats to an auditor's objectivity
| Threat | Everyday example |
|---|---|
| Self-review | Auditing a system you designed, or a process you used to run |
| Self-interest | Owning shares in a vendor you're reviewing |
| Familiarity | Auditing your best friend's department, or the same area for years |
| Intimidation | A manager hinting your career will suffer if a finding stays in |
| Management participation | Approving transactions or making decisions for the auditee |
Auditors on projects
Auditors are encouraged to get involved early in projects, because fixing a missing control in design is cheap. The line is between advising and doing.
What to do when objectivity is at risk
- 1 Spot it Before or during the audit.
- 2 Disclose it Tell audit management (and the audit committee if needed).
- 3 Resolve it Reassign the work, or decline it.
- 4 Report it If it affected the work, say so in the report.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Best way to protect audit's independence | Functional reporting to the audit committee |
| Auditor previously designed the system under review | Disclose; another auditor should do it |
| Auditor joins a development project | OK as an adviser, not in design or approval |
| Greatest threat to independence | Audit reporting to, or controlled by, the area it audits |
| Auditee offers expensive gifts | Decline or disclose: objectivity in appearance |
Key takeaways
- ✓Independence is about the audit FUNCTION: where it sits and who controls it. Objectivity is about the individual AUDITOR's state of mind on a job.
- ✓Both must exist in fact and in appearance. If an outsider would doubt it, there's a problem.
- ✓Audit reports functionally to the audit committee (charter, plan, budget, hiring) and administratively to senior management (day-to-day admin).
- ✓An auditor must not audit work they designed, built or ran, or an area they recently worked in.
- ✓Advising a project on controls is fine. Designing, approving or running the controls is not.
- ✓When objectivity or independence is at risk: disclose it, and normally reassign the work.
Exam traps
- !'I'm sure I can stay objective' doesn't solve anything if it doesn't LOOK objective.
- !Audit reporting to the CIO or CFO is an independence problem when it audits their areas.
- !Rotating auditors helps with familiarity. It doesn't fix a bad reporting line.
- !The fix for an impaired auditor is disclosure and reassignment, not 'being extra careful'.
- !An auditor on a project steering committee should be an adviser or observer, not a voting member.
Audit Charter: Purpose and Contents
The document that gives the audit function its authority: what it contains, who approves it, and how it differs from an engagement letter.
The question the charter answers
"Who says you're allowed to look at our systems?"
Sooner or later every auditor hears this. The answer is the audit charter: a short, formal document, approved by the board or audit committee, that creates the audit function and gives it the right to see what it needs.
What's in it
What's NOT in it
The charter is about principles, so it stays short and changes rarely. Anything that changes every year or every audit lives somewhere else.
Charter, plan, engagement letter
Charter vs engagement letter
| Audit charter | Engagement letter | |
|---|---|---|
| Covers | The whole audit function | One specific audit |
| Approved by | Board or audit committee | Client management and the audit provider |
| Lasts | Ongoing; reviewed periodically | Until the audit ends |
| Typical use | Internal audit | External or outsourced audit work |
Using the charter in real life
The database team refuses to give the auditor read access, saying 'audit isn't allowed in production'. The auditor shows them the charter's access clause. If they still refuse, the matter goes to the audit committee, which approved the charter.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Which document gives the auditor authority? | The audit charter |
| Who approves the charter? | The board or audit committee |
| Auditee refuses access: first step? | Refer to the charter; escalate if needed |
| Where is an outsourced audit's scope defined? | The engagement letter |
Key takeaways
- ✓The audit charter is the document that sets up the audit function: its purpose, authority, responsibility and accountability.
- ✓It's approved by the board or audit committee. That approval is where audit's authority comes from.
- ✓It gives audit unrestricted access to records, systems, premises and people needed for audits.
- ✓It sets the reporting lines: functional to the audit committee, administrative to senior management.
- ✓It's short and high level, and should be reviewed regularly (usually annually).
- ✓An engagement letter covers one specific audit, often by an external or outsourced provider. The charter covers the whole audit function.
Exam traps
- !The charter does NOT contain the annual audit plan or detailed test steps.
- !If an auditee refuses access, the auditor points to the charter first, then escalates.
- !IT management or the CIO doesn't approve the charter. The board or audit committee does.
- !A charter that hasn't been reviewed for years is a finding in itself.
Audit Testing: Compliance vs. Substantive
The two kinds of audit test: checking that controls work, and checking that the data itself is right. How one decides how much of the other you need.
Two questions an auditor can ask
Imagine checking whether a bank's vault is safe. You could watch the guards: are they checking ID, locking the door, logging visitors? Or you could open the vault and count the money.
Auditors do both. Checking the guards is a compliance test. Counting the money is a substantive test.
Compliance vs substantive
Which comes first?
The auditor normally tests the controls first, because the result decides how much substantive testing is needed.
Recognising each test
Ask yourself: is this procedure checking whether a CONTROL works, or whether the DATA is right?
| Procedure | Type |
|---|---|
| Check sampled user accounts had an approved request | Compliance |
| Inspect evidence that backup logs were reviewed daily | Compliance |
| Run test data to see if the system rejects invalid input | Compliance |
| Recalculate interest on a sample of loans | Substantive |
| Confirm account balances directly with customers | Substantive |
| Use data analytics to find duplicate payments | Substantive |
When a control fails
A failed control doesn't prove the numbers are wrong. It means the auditor can't trust the control to have kept them right, so they check the data directly instead.
- 1 Don't rely on it Control risk is high.
- 2 Look for backups Is there a compensating control?
- 3 Test more data Larger substantive samples.
- 4 Report it The control weakness is a finding.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Purpose of compliance testing | Check controls operate as designed |
| Purpose of substantive testing | Check the accuracy and integrity of data |
| Controls tested and effective: next step? | Reduce (not eliminate) substantive testing |
| Key control found not working | Increase substantive testing |
| Sampling type for compliance tests | Attribute sampling |
Key takeaways
- ✓A compliance test (test of controls) checks whether a control exists and works as designed throughout the period.
- ✓A substantive test checks whether the data itself (transactions, balances, records) is complete, accurate and valid.
- ✓Compliance testing comes first. Controls that work mean less substantive testing; controls that fail mean more.
- ✓Substantive testing is reduced, never eliminated, even when controls are excellent.
- ✓Compliance tests use attribute sampling (yes/no); substantive tests use variable sampling (amounts).
- ✓A failed control doesn't prove the data is wrong. It means the auditor can't rely on the control and must check the data directly.
Exam traps
- !Checking that changes were approved is a compliance test, even though you're looking at change records.
- !Recalculating interest or confirming balances with customers is substantive.
- !Weak controls mean MORE substantive testing, not stopping the audit.
- !Strong controls let the auditor reduce substantive testing, not skip it.
- !Running test data to see if an edit check rejects bad input is a compliance test: the edit check is a control.
Financial vs. Operational vs. Integrated Audits
The kinds of audit the exam names, the question each one answers, and how to tell from a scenario which one is being described.
Same company, different questions
Auditors can look at the same company and ask very different questions. The type of audit is just a name for the question being asked.
The main types
| Type | The question it answers |
|---|---|
| Financial | Are the financial statements fairly presented? |
| Operational | Are processes and controls effective and efficient? |
| Integrated | Combined view of one process: financial, operational and IT |
| Compliance | Are we following this law, regulation, contract or policy? |
| Administrative | Is this function run efficiently and productively? |
| IS audit | Are systems and data protected, reliable and well managed? |
The integrated audit
Instead of three teams auditing the same process separately, an integrated audit puts business and IT auditors together. They look at the business risks and the IT controls they depend on, test once, and write one report.
- 1 Pick a process Such as paying suppliers.
- 2 List the risks Financial, operational and IT together.
- 3 Find the controls Manual checks and the system controls behind them.
- 4 Test once One team, no duplicated work.
- 5 One report A complete picture for management.
Compliance audit vs compliance testing
How the exam asks about it
| If the scenario describes… | It's a… |
|---|---|
| Checking the fairness of financial statements | Financial audit |
| Evaluating whether a process is efficient and achieving its goals | Operational audit |
| Business and IT auditors reviewing one process together | Integrated audit |
| Checking adherence to a regulation or contract | Compliance audit |
| Gathering evidence for possible legal action | Forensic audit |
Key takeaways
- ✓An audit's type is defined by its objective: the question it's trying to answer.
- ✓Financial audit: are the financial statements fairly presented? IT is looked at only as far as it affects them.
- ✓Operational audit: are processes and their controls effective and efficient?
- ✓Integrated audit: financial, operational and IS audit work combined to look at one business process end to end.
- ✓Compliance audit: does the organisation follow a specific law, regulation, contract or policy?
- ✓Administrative audits look at efficiency and productivity; IS audits look at systems, controls and data.
- ✓Forensic audits gather evidence to a legal standard.
Exam traps
- !An integrated audit combines audit TYPES on one process. It doesn't mean auditing the whole company.
- !Compliance AUDIT (a type of audit) and compliance TESTING (testing controls) are different things.
- !A financial audit doesn't assess whether IT is efficient; it only looks at IT as it affects the financial statements.
Forensic and Specialized Audits
What changes when an audit might end up in court, what an auditor should (and shouldn't) do on finding fraud, and how to rely on a service provider's SOC report.
When the audit might end up in court
Most audits end with a report to management. A forensic audit might end in a courtroom or a disciplinary hearing, where the other side's lawyer will try to prove the evidence was tampered with.
So everything about how evidence is collected and handled has to stand up to challenge.
Who is responsible for fraud?
| Job | Whose |
|---|---|
| Preventing and detecting fraud | Management, through internal controls |
| Thinking about fraud risk when planning and testing | The auditor |
| Reporting signs of fraud | The auditor, to an appropriate level |
| Investigating suspected fraud | Authorised, qualified investigators |
Finding signs of fraud during an audit
Relying on someone else's audit
When a company outsources payroll or hosting, its auditors can't visit every provider. Instead, providers hire an independent auditor to write a SOC report, which their customers can rely on.
Before you rely on a SOC report
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| First step with a seized hard drive | Make a verified forensic image; work on the copy |
| What keeps evidence admissible | Chain of custody |
| Auditor suspects fraud | Document and report; don't confront |
| Who is responsible for detecting fraud | Management |
| Report supporting reliance over a period | SOC 1 or SOC 2 Type 2 |
| SOC report ends in September, your year ends in December | Bridge letter plus extra procedures |
Key takeaways
- ✓A forensic audit gathers evidence to a standard that will stand up in legal or disciplinary proceedings.
- ✓Evidence must be preserved before analysis, copied without changing it, and tracked with a chain of custody.
- ✓Preventing and detecting fraud is management's job. The auditor considers fraud risk and reports red flags, but isn't expected to find all fraud.
- ✓On suspecting fraud: document, don't tip anyone off, report to an appropriate level, and leave investigation to authorised specialists.
- ✓SOC reports let you rely on a service provider's controls without auditing them yourself. SOC 1 covers financial reporting controls; SOC 2 covers security and related areas.
- ✓Type 1 reports describe design on one date. Type 2 also tests whether controls worked over a period, so it supports reliance.
- ✓Before relying on a SOC report, check its scope, period, exceptions, sub-service providers and the controls you're expected to run yourself.
Exam traps
- !The auditor shouldn't confront a suspect or start investigating without authority and expertise.
- !Make a verified copy (image) of a seized drive first; never analyse the original.
- !A Type 1 report gives no evidence that controls worked during the year.
- !A SOC report on the provider doesn't cover the controls YOUR organisation is supposed to operate.
- !If the SOC report period doesn't cover your whole year, ask for a bridge letter and consider extra procedures.
Risk-Based Audit Approach
Why auditors spend their limited time where things are most likely to go badly wrong, the steps of a risk-based audit, and the 'what should the auditor do FIRST?' questions.
You can't check everything
An audit team has limited time and people. A company has thousands of processes, systems and transactions. If auditors spread their effort evenly, they'd spend as long checking the stationery cupboard as the payment system.
A risk-based approach fixes that: spend the most effort where a problem would hurt the most.
The steps
What risk decides
Where the auditor gets risk information
| Source | Why it helps |
|---|---|
| Business strategy and goals | Risk only means something against what the organisation wants to achieve |
| Process and system documents | Show where errors or misuse could happen |
| Management's risk register | A good starting point, but checked, not just copied |
| Previous audits | Known weaknesses, and how fast they get fixed |
| Recent changes | New systems, reorganisations, outsourcing, new laws |
| Industry news and threats | What's hitting similar organisations |
A worked example
An auditor plans a review of a bank's online banking. Rather than testing every control in the security standard equally, they rank the risks first.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| First step in planning an audit | Understand the business and its risks |
| Main benefit of risk-based auditing | Effort goes to the highest-risk areas |
| What drives the nature, timing and extent of tests | The risk assessment |
| How to treat management's risk assessment | Use it as input; evaluate it independently |
| A big new system arrives mid-year | Reassess risk; update the plan |
Key takeaways
- ✓A risk-based audit focuses effort on the areas where problems would hurt the organisation's objectives most.
- ✓The first step is always understanding the business: its goals, processes, systems and the risks to them.
- ✓Risk decides what gets audited, how it's tested, and how much testing is done.
- ✓The auditor assesses inherent risk and control risk to decide how much testing is needed.
- ✓Management's own risk assessment is a useful input, but the auditor forms an independent view.
- ✓The risk assessment is updated when things change: new systems, incidents, regulations.
Exam traps
- !Reviewing last year's report and interviewing management are useful, but understanding the business and its risks comes FIRST.
- !Auditors don't test every control equally. Key controls over big risks get the most attention.
- !Copying management's risk assessment without evaluating it isn't a risk-based approach.
- !A risk-based plan isn't fixed for the year; it changes when risks change.
Inherent, Control, Detection, and Audit Risk
Why an auditor can still get it wrong, the three things that cause it, and how the auditor decides how hard to look. Explained with a simple 'nets' picture.
Can an auditor get it wrong?
Yes. An auditor tests a sample, not every transaction, and works with limited time. So there's always some chance the auditor says "everything looks fine" when there's actually a significant problem.
That chance is called audit risk. The auditor's job is to keep it acceptably low, not to make it zero.
Three nets, one leak
Picture errors as balls rolling towards the financial statements. Some are created in the first place, some are caught by the company's controls, some by the auditor's tests. Whatever slips past both nets is audit risk.
Inherent risk: how easy is it to get wrong?
Inherent risk is the chance of a significant error happening if there were no controls at all. Some things are simply more error-prone than others.
Control risk: will the company's net catch it?
Every company puts controls in place: approvals, reconciliations, system checks. Control risk is the chance those controls fail to prevent or catch a significant error in time. Missing, badly designed or ignored controls mean high control risk.
Detection risk: will the auditor's net catch it?
Detection risk is the chance that the auditor's own testing misses an error that got past the company's controls. It's the only one of the three the auditor controls, by choosing how much, how well and when to test.
Putting it together
The three multiply: Audit risk = inherent risk × control risk × detection risk. The auditor wants audit risk to stay low. Inherent and control risk are what they are, so detection risk is the dial the auditor turns.
The auditor's dial, step by step
- 1 Assess inherent risk How error-prone is this area?
- 2 Assess control risk Do the company's controls work? Test them.
- 3 Set detection risk High risks above → set it low.
- 4 Plan the testing Low detection risk = more, better, later testing.
How the exam asks about it
| If the question says… | Think… |
|---|---|
| Which risk can the auditor control? | Detection risk |
| Risk assessed without considering controls | Inherent risk |
| Controls might not stop or catch an error | Control risk |
| Inherent and control risk are both high | Set detection risk low: more substantive testing |
| Auditor misread the evidence | Non-sampling risk (part of detection risk) |
Key takeaways
- ✓Audit risk is the risk that the auditor reaches the wrong conclusion, usually saying things are fine when there's a significant problem.
- ✓Inherent risk is how likely errors are in the first place, before any controls. Think: how easy is it to get this wrong?
- ✓Control risk is the chance that the company's own controls fail to stop or catch an error.
- ✓Detection risk is the chance that the auditor's own tests miss an error that got past the controls.
- ✓Audit risk = inherent risk × control risk × detection risk.
- ✓The auditor can't change inherent or control risk, only measure them. The one thing the auditor controls is detection risk: how much, how well and when they test.
- ✓High inherent and control risk mean the auditor must lower detection risk, which means more and better testing.
- ✓Detection risk includes sampling risk (an unlucky sample) and non-sampling risk (the auditor's own mistakes).
Exam traps
- !The auditor ASSESSES inherent and control risk but SETS detection risk. 'Which risk can the auditor control?' → detection risk.
- !Inherent risk is judged as if there were no controls at all.
- !Weak controls mean MORE substantive testing, not less.
- !Choosing the wrong test or misreading evidence is non-sampling risk. A bigger sample won't fix it; training and supervision will.
- !Business risk (the company failing to meet its goals) is not one of the audit risk components.
Audit Universe and Annual Audit Plan
How audit decides what to look at each year: list everything that could be audited, rank it by risk, and build a plan the audit committee approves.
The menu and the order
Think of the audit universe as a restaurant menu: everything audit could possibly look at. The annual plan is this year's order: the dishes audit will actually serve, chosen because they matter most right now.
Audit can't order the whole menu every year, so it picks by risk.
From universe to plan
What makes an area high risk?
A plan that bends
The plan is approved at the start of the year, but it isn't fixed. When risks change, audit re-ranks and asks the audit committee to approve the change.
Short-term and long-term planning
| Short-term | Long-term | |
|---|---|---|
| Looks ahead | The coming year | Several years |
| Decides | Which audits, when, who does them | How the whole universe gets covered; skills needed |
| Driven by | Current risk ranking | Strategy and technology direction |
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Basis for choosing areas for the annual plan | A documented risk assessment |
| Who approves the annual audit plan | The audit committee |
| A major new system appears mid-year | Reassess risk; revise the plan |
| Not enough staff to cover high-risk areas | Report the gap to the audit committee |
| First step in building the annual plan | Define the audit universe and assess risks |
Key takeaways
- ✓The audit universe is the full list of things that could be audited: processes, systems, locations, legal entities, projects and key suppliers.
- ✓The annual audit plan picks from the universe using a documented risk assessment.
- ✓The audit committee approves the plan, and any significant changes to it.
- ✓The plan must be flexible: when risks change, the plan changes.
- ✓Short-term planning covers the coming year; long-term planning looks at covering the universe over several years and at future skills needs.
- ✓If audit can't cover the high-risk areas with its resources, it tells the audit committee rather than quietly dropping them.
Exam traps
- !Auditing everything on a fixed rotation regardless of risk isn't a risk-based plan.
- !The audit committee approves the plan, not the CIO or the areas being audited.
- !Dropping a high-risk area because management asked is an independence problem.
- !A plan never revised during the year may be ignoring new risks.
Audit Objectives, Scope, and the Audit Program
Planning a single audit: deciding what it must conclude, where its boundaries are, and the step-by-step tests in the audit program. Plus what to do when someone blocks the scope.
Planning one audit
The annual plan says WHICH areas get audited this year. Before each audit starts, the auditor plans it in detail.
It's like planning a trip: first decide where you want to end up (objectives), then which roads are in bounds (scope), then the turn-by-turn route (audit program), then who's driving and when (resources and timing).
Four planning decisions
Good objectives
An objective is a question the audit must answer. It comes from the risks found during planning.
What's in an audit program
| Part | Why it's there |
|---|---|
| Objectives and scope | Every test traces back to what must be concluded |
| Test steps | What to check and how: ask, inspect, re-perform, analyse data |
| Evidence needed | What counts as enough, reliable proof |
| Who and when | Responsibility and deadlines |
| Sign-off and review | Shows the work was supervised |
When someone blocks the scope
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| What is set first when planning an audit | The audit objectives |
| Main purpose of an audit program | Set out tests that meet the objectives |
| The auditee restricts the scope | Resolve or escalate; report it if unresolved |
| Using last year's program unchanged | Inappropriate; tailor it to current risks |
| Who sets the scope | The auditor, based on risk and the objectives |
Key takeaways
- ✓Audit objectives say what the audit must conclude. They're set first, before scope, tests or sample sizes.
- ✓Scope sets the boundaries: which systems, processes, locations and time period.
- ✓The audit program is the step-by-step list of tests that meet the objectives. It's also the record of work done.
- ✓Programs are tailored to the current risks; copying last year's without review is a weakness.
- ✓Planning also covers people, skills, experts, timing and communication with the auditee.
- ✓If the scope is restricted and it can't be resolved, the limitation must be reported.
Exam traps
- !Objectives come first. Tests are chosen to meet the objectives, not the other way round.
- !A generic program used without tailoring to the area's risks is a weakness.
- !Management restricting the scope doesn't make the restriction acceptable. Report it.
- !The auditor sets the scope, based on risk, not on what the auditee is comfortable with.
Types and Reliability of Audit Evidence
What counts as good audit evidence, why some evidence is more trustworthy than others, and how to pick the 'most reliable' answer on the exam.
What counts as proof?
An auditor's conclusion is only as good as the proof behind it. "The IT manager told me it's fine" isn't proof. "I pulled the data myself and checked every case" is.
The standards say evidence must be sufficient and appropriate. That sounds dry, but it boils down to three questions.
Ranking evidence
Imagine the question is 'were leavers' accounts removed?'. Here are four kinds of evidence, from weakest to strongest.
The reliability rules
| More reliable | Less reliable |
|---|---|
| From an independent outside source | From inside the auditee |
| Obtained directly by the auditor | Handed over by the auditee |
| Written or system-generated | Spoken |
| Original documents | Copies, printouts, scans |
| Produced where controls are strong | Produced where controls are weak |
| From someone qualified and independent | From someone with a stake in the result |
Ways to gather evidence
Electronic evidence
Most IS audit evidence is electronic: logs, settings, database records. Two cautions.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Most reliable evidence | Independent confirmation, or what the auditor obtained directly |
| A manager's verbal assurance | Weak; back it up with other evidence |
| Auditee gives a printout of user access | Less reliable than extracting the data yourself |
| Evidence a control worked all year | A sample across the year, not one observation |
| Can't get enough evidence | Scope limitation; report it |
Key takeaways
- ✓Evidence must be sufficient (enough of it) and appropriate (relevant to the question and reliable).
- ✓Evidence from an independent outside source beats evidence from inside the auditee.
- ✓Evidence the auditor gets directly (observing, re-performing, extracting data) beats evidence handed over by the auditee.
- ✓Written or system-generated evidence beats what people say; spoken answers need backing up.
- ✓Evidence produced where controls are strong is more reliable than where they're weak.
- ✓Before analysing system data, check it's complete: record counts and totals should match the source.
- ✓Work papers record the evidence and link it to the conclusions; they're retained and protected.
Exam traps
- !A management representation letter is evidence, but weak. It never replaces testing.
- !A printout given by the auditee is less reliable than data the auditor extracts directly.
- !More of a weak kind of evidence doesn't make it strong.
- !Interviewing staff alone never proves a control works.
- !Logs and electronic records may be overwritten; request them early.
Sampling: Statistical vs. Non-Statistical
Why auditors test a sample instead of everything, statistical versus judgement sampling, attribute versus variable sampling, and the selection methods the exam names.
Why sample at all?
A company processes 400,000 payments a year. Checking every one by hand would take months. So auditors test a sample, maybe 60, and use it to judge the whole lot.
It works the same way a chef tastes one spoonful to judge the whole pot. The trick is making sure the spoonful is representative, and knowing how much to trust it.
Two ways to pick a sample
How often, or how much?
Sampling also splits by the question you're asking. Counting yes/no results is attribute sampling. Measuring amounts is variable sampling.
The variants the exam names
Choosing the items
Sample or test everything?
When data is electronic and the test can be automated, the auditor can often test the whole population with data analytics. That removes sampling risk entirely.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Main advantage of statistical sampling | Sampling risk can be measured; objective conclusions |
| Sampling to test a control | Attribute sampling |
| Sampling to estimate a money error | Variable sampling |
| Fraud suspected; one case matters | Discovery sampling |
| Method that avoids over-sampling | Stop-or-go sampling |
| Shrink the sample for a varied population | Stratification |
Key takeaways
- ✓Sampling means testing part of a population to draw a conclusion about all of it.
- ✓Statistical sampling uses random selection and maths to set the sample size and evaluate results, so the risk of a wrong conclusion can be measured.
- ✓Judgement (non-statistical) sampling uses the auditor's experience to pick items; it can target known risks but can't state a measured confidence.
- ✓Attribute sampling asks 'how often?' (a rate of control failures) and suits compliance tests.
- ✓Variable sampling asks 'how much?' (an amount of misstatement) and suits substantive tests.
- ✓Stop-or-go sampling avoids over-testing when few errors are expected; discovery sampling is used when finding even one case (like fraud) matters.
- ✓Stratification splits a varied population into similar groups, which shrinks the sample needed.
Exam traps
- !Discovery sampling is for rare events like fraud, not for estimating an error rate.
- !Stop-or-go sampling exists to prevent excessive sampling, not to find fraud.
- !Judgement sampling isn't wrong; it just can't quantify sampling risk.
- !Attribute sampling gives a rate, not an amount of money.
- !Haphazard selection isn't random selection, so it doesn't support statistical conclusions.
- !If the data is electronic and the test can be automated, testing 100% with analytics is often better than sampling.
Sampling Terms: Confidence Level, Tolerable Error and Friends
The sampling vocabulary in plain words, and the exam favourite: which changes make the sample bigger or smaller.
Why the vocabulary matters
Sampling questions on the exam usually aren't calculations. They describe a change, like "controls are strong" or "more errors are expected", and ask whether the sample gets bigger or smaller.
So the goal here is intuition: what each term means, and which way it pushes the sample size.
The terms in plain words
What makes the sample bigger or smaller
A worked example
Last year, testing 60 user access approvals found no problems, and nothing has changed. This year the auditor accepts 90% confidence instead of 95%, keeping tolerable error at 5%. The sample gets smaller.
The two traps
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Effect of strong internal controls | Lower confidence level; smaller sample |
| Which change REDUCES sample size | Higher tolerable error, lower confidence, looser precision, stratification |
| Which change INCREASES sample size | Higher expected error, higher confidence, tighter precision, more variability |
| Level of risk at 95% confidence | 5% |
| Effect of doubling a large population | Very little |
Key takeaways
- ✓Confidence level (confidence coefficient) is how sure you want to be that the sample reflects the population. Higher confidence needs a bigger sample.
- ✓Level of risk is 100% minus the confidence level: 95% confidence means 5% risk.
- ✓Precision is how close to the true answer the estimate must be. Tighter precision needs a bigger sample.
- ✓Expected error rate is how many errors you expect. More expected errors need a bigger sample.
- ✓Tolerable error rate is the most error you can accept. Accepting more error allows a smaller sample.
- ✓More variety (standard deviation) in the population needs a bigger sample; stratification reduces it.
- ✓Strong internal controls let the auditor use a lower confidence level, so a smaller sample.
- ✓For large populations, population size hardly affects sample size.
Exam traps
- !Strong controls mean a LOWER confidence level and a SMALLER sample, not a higher one.
- !When expected errors get close to tolerable errors, the sample gets very large. If expected is above tolerable, sampling isn't worth it.
- !Doubling a large population doesn't double the sample.
- !Tighter precision means a BIGGER sample.
Interviews, Observation, and Walkthroughs
How auditors learn how things really work: asking, watching, and following one transaction through. What each one proves, and what it doesn't.
Learning how things really work
Before an auditor can test anything, they need to know how the process actually works: who does what, using which system, and where the checks are.
Three techniques help: asking people, watching them, and following one real transaction from start to finish. Each proves something different.
Interviews
Interviews are how auditors understand a process and hear about concerns. But an answer is only someone's word, so important answers are always backed up by documents, system data or observation.
Observation
Watching something happen gives direct evidence, obtained by the auditor personally. But it only proves what happened while you were watching.
Walkthroughs
A walkthrough follows one real transaction through every step, using the actual documents and systems, and asking the people involved what they do.
What a walkthrough proves, and what it doesn't
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Purpose of a walkthrough | Confirm understanding of the process and control design |
| Best way to test segregation of duties in practice | Observe the process and review actual system access |
| Value of interviewing the control owner | Understanding; needs backing up |
| Weakness of observation | Only proves the moment observed |
| Evidence that a control worked all year | Sample testing across the year |
Key takeaways
- ✓Interviews help the auditor understand a process, but answers must be backed up with other evidence.
- ✓Observation is direct evidence that something happened at the moment it was watched, not at other times.
- ✓A walkthrough follows one real transaction from start to end to confirm the auditor understands the process and its controls.
- ✓Walkthroughs confirm design and implementation. They don't prove a control worked throughout the year.
- ✓Questionnaires and checklists are efficient, but they're still just asking.
- ✓Segregation of duties often leaves no paper trail, so observing who actually does each task is a key way to test it.
Exam traps
- !Interviewing the system administrator isn't evidence that access controls work.
- !People may behave differently when they know they're being watched.
- !A walkthrough of one transaction doesn't test operating effectiveness over the year.
- !Process documents from management show how things SHOULD work, not how they DO.
CAATs and Data Analytics
Using computers to audit computers: audit software, test data, integrated test facilities and parallel simulation, explained simply, with when each one fits.
Using computers to audit computers
When a company processes millions of transactions with no paper in sight, the evidence only exists as data. Testing 25 transactions by hand would barely scratch the surface.
CAATs let the auditor use software to read the data directly, often checking every single transaction.
Audit software in action
Generalised audit software (GAS) reads data files and runs audit tests on them. Common tests the exam mentions:
Testing the program itself
Sometimes the auditor wants to test the program's logic, not the data. Three techniques do that, and the exam loves to mix them up.
ITF: a fake branch in the real system
An integrated test facility creates a dummy entity, such as a fictitious branch or customer, inside the live system. The auditor's fake transactions are processed alongside real ones, and the results are checked.
Using CAATs safely
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Greatest advantage of CAATs | Testing whole populations efficiently and independently |
| Main risk of an ITF | Polluting production data; test transactions must be reversed |
| Technique using real data and the auditor's own program | Parallel simulation |
| Technique using fake transactions in a test system | Test data |
| First step before analysing extracted data | Check it's complete and accurate |
| Tool to find duplicate payments | Generalised audit software |
Key takeaways
- ✓CAATs (computer-assisted audit techniques) let the auditor test large volumes, or every transaction, directly from system data.
- ✓Generalised audit software (GAS), like ACL, IDEA or scripts, reads data to sample, recalculate, match, and find duplicates and gaps.
- ✓Test data: the auditor's fake transactions run through the program, usually in a test system, to check its logic.
- ✓Integrated test facility (ITF): fake transactions for a dummy entity run in LIVE production alongside real ones.
- ✓Parallel simulation: the auditor's own program reprocesses REAL production data and compares results with the real system.
- ✓Before relying on extracted data, check it's complete: record counts and control totals match the source.
- ✓Use read-only access or copies, so the audit can't change production.
Exam traps
- !ITF's main risk: fake transactions polluting real data and reports. They must be clearly marked and reversed.
- !Test data only proves the logic for the cases you thought of, and only for the program version you tested.
- !Parallel simulation uses REAL data; test data uses FAKE data.
- !Don't accept data files prepared by the auditee without checking them.
- !Running CAATs with write access to live production files is never right.
Continuous Auditing and Monitoring
Moving from once-a-year checks to near real-time assurance: the difference between monitoring and auditing, and the online audit techniques (audit hooks, snapshots, SCARF, ITF, CIS).
From yearly check-ups to a heart monitor
A traditional audit is like an annual check-up: thorough, but a problem that starts in February might not be found until next January.
Continuous auditing is more like a heart monitor: automated checks run all the time, and the auditor hears about trouble within days.
Monitoring vs auditing
The online audit techniques
These are pieces of audit logic placed inside, or connected to, the business systems. The exam usually describes what a technique does and asks for its name.
Audit hooks: a real example
A bank sets an audit hook that alerts internal audit whenever a payment over a threshold is released by someone who also changed the beneficiary's details in the previous 24 hours. Auditors review each alert within a day, instead of finding the pattern at year end.
What continuous auditing needs
- 1 Automated systems High volumes processed electronically.
- 2 Reliable controls General controls and data integrity in place.
- 3 Built-in audit tools Audit logic inside or connected to systems.
- 4 Alerts Exceptions reach the auditor quickly.
- 5 Follow-up Someone acts on what's flagged.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Main benefit of continuous auditing | Earlier detection; more transactions tested |
| Prerequisite for continuous auditing | Highly automated systems with reliable controls |
| Flag suspicious transactions early, simply | Audit hooks |
| Provide an audit trail of a transaction's path | Snapshots |
| Who owns continuous monitoring | Management |
| Can audit rely on management's monitoring? | Yes, after evaluating it; it reduces but doesn't replace audit testing |
Key takeaways
- ✓Continuous monitoring is done by management as part of running controls. Continuous auditing is done by audit to give ongoing, independent assurance.
- ✓Continuous auditing shortens the gap between something happening and the auditor knowing about it.
- ✓It needs highly automated systems, reliable general controls, and audit tools built into or connected to the systems.
- ✓Audit hooks flag suspicious transactions for immediate attention. They're simple and catch problems early.
- ✓Snapshots record a transaction's values at each step, giving an audit trail.
- ✓Embedded audit modules (SCARF) collect transactions that meet audit criteria into a file for later review.
- ✓Continuous and intermittent simulation (CIS) re-checks selected transactions as they're processed.
Exam traps
- !Management's monitoring can reduce audit's testing, but never replaces the auditor's independent view.
- !'Flag suspicious transactions early, with little complexity' → audit hooks.
- !Snapshot = audit trail of the path. SCARF = collecting transactions for later.
- !Continuous auditing needs automated systems; it doesn't suit manual, paper-based processes.
Preventive, Detective, Corrective Controls
Sorting controls by what they do (put off, block, spot, fix), why prevention usually wins, and how the exam asks you to pick the best control.
What controls are for
A control is anything that reduces the chance or the damage of something going wrong. Locks, passwords, approvals, reviews and backups are all controls.
The easiest way to sort them is by WHEN they act: before something happens, or after.
An everyday example
Think about protecting your house.
The same idea in IT
| Type | IT examples |
|---|---|
| Preventive | Access controls, segregation of duties, input validation, encryption, approvals, firewalls |
| Detective | Log reviews, reconciliations, hash totals, intrusion detection, exception reports, audits |
| Corrective | Restore from backup, incident response, disaster recovery, fixing root causes |
| Deterrent | Policies with penalties, login warning banners, visible cameras |
| Compensating | Supervisory review where segregation of duties isn't possible |
Which is the BEST control?
A log nobody reads
Logs and reports are detective controls only if someone reviews them and acts on what they find. A log that nobody reads is just a record.
Other ways to sort controls
| By… | Types |
|---|---|
| How they work | Manual, automated, IT-dependent manual (a person reviewing a system report) |
| What they are | Administrative (policies), technical (system settings), physical (locks) |
| Where they apply | General IT controls (everywhere), application controls (one system) |
| How important | Key controls, secondary controls |
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Best control to stop an unauthorised transaction | A preventive control at the point of entry |
| Type of control: a reconciliation | Detective |
| Type of control: backup and restore | Corrective |
| Logs generated but not reviewed | No effective detective control |
| Why automated controls are preferred | Consistent, if change management is effective |
| Type of control: a login warning banner | Deterrent |
Key takeaways
- ✓Preventive controls stop a problem happening. Detective controls notice it after it happens. Corrective controls fix it and limit the damage.
- ✓Deterrent controls discourage people from trying; compensating controls cover for a missing or weak control.
- ✓Prevention is usually preferred, because stopping a problem is cheaper than finding and fixing it.
- ✓Detective controls are still essential: prevention can fail, and detection proves prevention is working.
- ✓A log is only a detective control if someone reviews it.
- ✓Controls can also be manual or automated, and administrative, technical or physical.
- ✓Automated controls are more consistent than manual ones, as long as change management protects them.
Exam traps
- !Logs nobody reviews don't detect anything.
- !Backups are corrective (recovery), not preventive.
- !When asked for the BEST control, preventive usually beats detective, unless prevention isn't possible.
- !Warning banners are deterrent, not preventive.
- !Supervisory review of a report is detective, even though it may stop the next error.
General vs. Application Controls
The two layers of IT controls: general controls that protect the whole IT environment, and application controls inside individual systems. Why the first must be tested before the second can be trusted.
Two layers
Think of a house. The foundations, walls and roof protect everything inside: those are IT general controls. The locks on individual cupboards and the safe in the bedroom protect specific things: those are application controls.
A great safe is pointless if anyone can walk in and carry it out. In the same way, application controls are only as good as the general controls underneath.
The four ITGC areas
Application controls
| Type | Examples |
|---|---|
| Input | Validation and edit checks, approvals, batch totals |
| Processing | Correct calculations, run-to-run totals, limit and sequence checks |
| Output | Reconciliations, controlled distribution of reports, exception review |
| Application access | Roles and segregation of duties inside the application |
Why ITGCs come first
Application controls depend on ITGCs. Weak ITGCs undermine them in three ways.
The 'test of one'
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Which controls are tested first | IT general controls |
| ITGCs are weak: effect on application controls | Less reliance on automated controls; more substantive testing |
| Example of an ITGC | Change management, user access management, backup |
| Example of an application control | Input validation, run-to-run totals, output reconciliation |
| When is testing one instance of an automated control enough? | When access and change ITGCs were effective all period |
Key takeaways
- ✓IT general controls (ITGCs) apply across the IT environment: access, change management, development and acquisition, and operations.
- ✓Application controls work inside one application: input checks, processing checks, output reconciliations, and roles within the application.
- ✓Application controls depend on ITGCs. If ITGCs are weak, automated application controls can't be trusted.
- ✓Auditors test ITGCs first, then use them to test application controls efficiently.
- ✓An automated control can be tested once and relied on all year, but only if access and change ITGCs were effective.
- ✓Weak ITGCs mean more substantive testing of the application's results.
Exam traps
- !Strong edit checks don't make up for weak change management: the edit could be changed without anyone knowing.
- !Backup, continuity and security management belong to ITGCs, not application controls.
- !Roles inside an application are application controls; the process that gives users access is usually an ITGC.
- !A 'test of one' for an automated control is only valid if ITGCs were effective all year.
Compensating Controls and Segregation of Duties
Why one person shouldn't control a whole process, the four duties to keep apart, how auditors test it, and what to do when a team is too small to split the work.
Why split the work?
If one person can order goods, approve the order, receive the delivery and pay the invoice, they could pay a fake supplier they set up themselves, and nobody would ever notice.
Segregation of duties splits a process between people so that one person's error or fraud gets caught by another. To beat it, two people would have to work together (collude), which is much less likely.
The four duties to keep apart
How auditors test SoD
- 1 Conflict matrix List which duties and system rights clash.
- 2 Pull real access Actual roles and permissions, across all systems.
- 3 Find conflicts Users holding clashing rights.
- 4 Watch the work Who really does each task? Shared logins?
- 5 Check cover Where conflicts exist, are there compensating controls?
When the team is too small
A five-person IT team can't separate every duty. The exam's expected answer isn't 'hire more people'. It's a compensating control: someone independent checks what the person did.
A compensating control in practice
One IT administrator can create users, change settings and access the finance system. Each month, the finance manager receives a system-generated report of every user created, role changed and admin login, checks each against an approved request, and signs it.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Purpose of segregation of duties | Stop one person making and hiding errors or fraud |
| Small organisation can't separate duties | Compensating controls, such as independent review of logs |
| Best way to find SoD conflicts in a system | Compare actual access rights with a conflict matrix |
| Control that detects fraud needing constant hiding | Mandatory leave or job rotation |
| Administrator reviews their own log | Not effective; the reviewer must be independent |
Key takeaways
- ✓Segregation of duties (SoD) splits incompatible jobs between people so no one person can both make and hide a mistake or a fraud.
- ✓The four duties to keep apart: authorising, recording, holding the asset (custody), and checking (verification).
- ✓SoD is tested by comparing actual system access with a conflict matrix, reviewing job descriptions, and watching who really does each task.
- ✓When duties can't be separated, compensating controls reduce the risk: independent review, logs reviewed by someone else, reconciliations, job rotation, mandatory leave.
- ✓Most compensating controls are detective: they don't stop the act, but make hiding it hard.
- ✓Check conflicts across systems; access in two applications can add up to a conflict.
Exam traps
- !In small organisations, the expected answer is a compensating control, not hiring more people.
- !Role-based access doesn't guarantee SoD; a role itself can contain a conflict.
- !A review only compensates if the reviewer is independent of the activity.
- !Mandatory leave is a detective control for fraud that needs constant hiding.
- !An administrator reviewing their own activity log is not a compensating control.
Materiality and Evaluating Findings
Deciding what's important enough to matter: why IS materiality is mostly about impact rather than money, why small findings can add up, and how a good finding is written.
What 'material' means
Material simply means important enough to matter. If knowing about it would change what the board, management or a regulator decides, it's material.
In a financial audit that's often a money figure. In an IS audit, a weakness rarely comes with a price tag, so the auditor asks what it could lead to.
Same weakness, different importance
What the auditor weighs up
Small findings can add up
Each finding is first judged on its own, then together with related findings. Several 'medium' issues around the same objective can add up to one serious problem.
Writing a finding
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| How materiality is judged in an IS audit | Mainly by impact: criticality, sensitivity, consequences |
| Several minor weaknesses found | Consider their combined effect before reporting |
| A weakness that hasn't caused a loss yet | Judge by potential impact; it may still be material |
| An immaterial finding | Tell management, usually informally |
| Effect of a lower materiality threshold | More testing |
Key takeaways
- ✓Something is material if it could change the decisions of the people relying on the audit, because of its size or its nature.
- ✓In IS audits, materiality is mostly qualitative: how critical the system is, how sensitive the data is, and what the weakness could lead to.
- ✓A weakness can be material even if no loss has happened yet, if it could allow a significant loss.
- ✓Several small findings can be material together, so the auditor looks at their combined effect.
- ✓Findings are rated by risk: the likelihood and impact of what the weakness could allow.
- ✓A good finding states the criteria, condition, cause, effect and a recommendation that addresses the cause.
Exam traps
- !No loss so far doesn't make a weakness immaterial. Judge the potential impact.
- !Several small weaknesses affecting the same control objective may together be significant.
- !Immaterial findings are still communicated to management, usually informally.
- !IS materiality isn't just a money threshold.
- !Anything involving fraud or deliberate override is significant regardless of the amount.
Audit Report Structure and Communication
What goes in an audit report, how findings are agreed with management before it's issued, and what happens when management disagrees or has already fixed the problem.
The report is the product
All the planning and testing exists to produce one thing: a report that tells the right people what's working, what isn't, and what to do about it.
A good report has no surprises. Findings are discussed with management along the way, so by the time the report arrives everyone already knows what's in it.
From fieldwork to final report
What goes in it
When management disagrees
Already fixed? Still reported
If a problem is fixed during the audit, it still goes in the report, with a note of the fix. It existed during the period, and readers need to know.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Purpose of the exit meeting | Agree the facts and discuss recommendations |
| Management disagrees with a finding | Report it, with management's response |
| Finding fixed before the report is issued | Still report it, noting the fix |
| Who decides the report's content | The auditor |
| Where significant findings go | Senior management and the audit committee |
| Most important thing about a recommendation | It addresses the root cause |
Key takeaways
- ✓The report states the scope, objectives, period, what work was done, findings, conclusions, recommendations and any limitations.
- ✓Findings are discussed with the auditee before the report is final, to confirm the facts and get management's responses.
- ✓The auditor decides what's in the report. Management can respond, but can't have valid findings removed.
- ✓Management responses include agreed actions, owners and target dates.
- ✓Significant findings go to senior management and the audit committee.
- ✓Problems fixed during the audit are still reported, noting the fix.
Exam traps
- !If management disagrees, the finding isn't dropped. Both views can appear in the report.
- !A problem fixed before the report is issued is still reported, because it existed during the period.
- !The exit meeting confirms facts and discusses recommendations; it's not for negotiating findings away.
- !Don't issue a report based on facts that haven't been checked with the auditee.
Follow-Up and Management Action Plans
After the report: who fixes the problems, how audit checks they're really fixed, and what happens when management decides to live with the risk instead.
The report isn't the end
A report full of findings is worthless if nothing changes. Follow-up is how audit makes sure the agreed fixes actually happen.
The split of jobs is simple: management fixes, audit checks.
A good action plan
Verify, don't just ask
For significant findings, the auditor gets evidence that the fix is in place and working. An email saying 'done' isn't enough.
When management accepts the risk
Management may decide not to fix something, perhaps because the fix costs more than the risk. That's their call, if it's within the organisation's risk appetite and decided by someone with the authority.
Overdue actions
A finding on missing MFA for remote access had a March deadline. In June it's still open, and the owner has moved the date twice. Audit reports it as overdue to the audit committee, which asks the CIO to explain at the next meeting.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Who implements corrective action | Management |
| Purpose of follow-up | Check management took appropriate, timely action |
| Management says an action is complete | Verify it's in place and working |
| Management accepts a significant risk | Escalate if it's beyond appetite |
| How follow-up is prioritised | By how serious the finding is |
Key takeaways
- ✓Management owns the fixes. Audit monitors and verifies that agreed actions are actually done.
- ✓A good action plan has a specific action, a named owner and a target date.
- ✓Follow-up timing depends on how serious the finding is.
- ✓The auditor checks the fix works, not just that management says it's done.
- ✓Management may accept a risk instead of fixing it; if that risk is beyond appetite, it's escalated to senior management or the audit committee.
- ✓The status of open findings is reported to the audit committee regularly.
Exam traps
- !Audit doesn't implement the fix; that would impair its independence.
- !'It's done' from management isn't enough evidence for a significant finding; verify it.
- !Repeatedly missed deadlines get escalated, not quietly re-dated.
- !A different fix from the one recommended can be fine, if it deals with the risk.
Control Self-Assessment (CSA)
Getting the people who run a process to assess its risks and controls themselves, with the auditor as facilitator. What it's for, its benefits, and the risk of mistaking it for an audit.
Asking the people who know best
The people who run a process every day usually know where it's weak: the workaround everyone uses, the check that's often skipped. Control self-assessment taps into that.
In a CSA, process owners and staff assess their own risks and controls, usually in a workshop guided by an auditor.
CSA vs a traditional audit
How CSA is done
Benefits and risks
| Benefits | Risks |
|---|---|
| Risks spotted earlier, by those closest | Treated as a substitute for audit |
| The business owns its controls | Staff lack objectivity or skills |
| Better awareness among staff | Ideas raised but never acted on |
| Audit reaches more areas | Extra workload for the business |
| Better communication | Big issues avoided in a group setting |
CSA feeding the audit plan
Instead of auditing 40 branches every year, audit runs yearly CSA workshops with branch managers on cash handling, customer data and access. Five branches give weak answers, and those go into the audit plan for on-site testing.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Primary objective of CSA | Shift control monitoring to the business; leverage audit |
| The auditor's role in CSA | Facilitator and adviser |
| Can CSA replace internal audit? | No; it adds to it |
| Main benefit of CSA | Early detection of risks; business ownership of controls |
| Main risk of CSA | Mistaken for audit, or actions not taken |
Key takeaways
- ✓In control self-assessment (CSA), the people who run a process assess its risks and controls themselves, usually in facilitated workshops.
- ✓The main objective is to shift some responsibility for monitoring controls to the business, extending audit's reach.
- ✓The auditor acts as facilitator and adviser; the business owns the conclusions.
- ✓Benefits: risks spotted earlier, ownership of controls by the business, better awareness, wider coverage.
- ✓Risks: being mistaken for a replacement for audit, staff lacking objectivity or skills, and improvements not being made.
- ✓CSA results can guide audit planning, but the auditor still tests key controls independently.
Exam traps
- !CSA does NOT replace internal audit.
- !The primary objective is to leverage audit by shifting control monitoring to the business, not to cut audit costs.
- !In CSA the auditor facilitates; the business owns the assessment.
Audit Quality and Using Other Experts' Work
How the audit function makes sure its own work is good, and what an auditor must check before relying on someone else's work.
Who audits the auditors?
Audit tells everyone else to check their work. So it had better check its own.
Quality is built in during each audit, through supervision and review, and checked across the whole function by internal and external assessments.
Leaning on experts
IS auditors often rely on others: a penetration testing firm, a lawyer, an actuary, another audit team, or a provider's SOC report. That's fine, but only after checking them out.
Responsibility doesn't move
Using an expert doesn't hand over responsibility. The IS auditor's name is on the conclusion, so the IS auditor must be satisfied the expert's work is good enough.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| First thing to check before relying on an expert | Their competence, independence and objectivity |
| Expert's work misses part of the scope | Do additional procedures |
| Who is responsible for conclusions when an expert is used | The IS auditor |
| How quality is ensured during an audit | Supervision and work paper review |
| Purpose of an external quality assessment | Independent check that audit meets the standards |
Key takeaways
- ✓Audit quality comes from supervision, review of work papers, and a quality program with internal and external assessments.
- ✓External assessments are done periodically by an independent, qualified outsider.
- ✓Before relying on an expert's work, the auditor checks their competence, independence and objectivity.
- ✓The auditor also checks the expert's scope, methods and conclusions are good enough for the audit's needs.
- ✓Using an expert doesn't transfer responsibility: the IS auditor still owns the conclusions.
- ✓The same logic applies when external auditors rely on internal audit, or vice versa.
Exam traps
- !The auditor can't rely on an expert's report without reviewing its scope and quality.
- !A vendor's own consultants assessing their product aren't independent.
- !Using an expert doesn't reduce the auditor's responsibility for the opinion.
- !Quality reviews should be done by people who weren't involved in the work.