CISA: the full course

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.

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.

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.

Members only take on work they can reasonably complete with the skills, knowledge and competence they have, and they keep those skills current.

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.

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.

Exam questions describe a situation. Your job is to recognise which standard is involved and what it requires.

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.

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.

1. 1 Spot it Before or during the audit.
2. 2 Disclose it Tell audit management (and the audit committee if needed).
3. 3 Resolve it Reassign the work, or decline it.
4. 4 Report it If it affected the work, say so in the report.

"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.

The charter is about principles, so it stays short and changes rarely. Anything that changes every year or every audit lives somewhere else.

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.

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.

Ask yourself: is this procedure checking whether a CONTROL works, or whether the DATA is right?

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. 1 Don't rely on it Control risk is high.
2. 2 Look for backups Is there a compensating control?
3. 3 Test more data Larger substantive samples.
4. 4 Report it The control weakness is a finding.

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. 1 Pick a process Such as paying suppliers.
2. 2 List the risks Financial, operational and IT together.
3. 3 Find the controls Manual checks and the system controls behind them.
4. 4 Test once One team, no duplicated work.
5. 5 One report A complete picture for management.

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.

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.

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.

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.

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.

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 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.

1. 1 Assess inherent risk How error-prone is this area?
2. 2 Assess control risk Do the company's controls work? Test them.
3. 3 Set detection risk High risks above → set it low.
4. 4 Plan the testing Low detection risk = more, better, later testing.

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.

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.

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).

An objective is a question the audit must answer. It comes from the risks found during planning.

Most IS audit evidence is electronic: logs, settings, database records. Two cautions.

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.

Sampling also splits by the question you're asking. Counting yes/no results is attribute sampling. Measuring amounts is variable sampling.

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.

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.

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.

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.

Watching something happen gives direct evidence, obtained by the auditor personally. But it only proves what happened while you were watching.

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.

Generalised audit software (GAS) reads data files and runs audit tests on them. Common tests the exam mentions:

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.

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.

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.

1. 1 Automated systems High volumes processed electronically.
2. 2 Reliable controls General controls and data integrity in place.
3. 3 Built-in audit tools Audit logic inside or connected to systems.
4. 4 Alerts Exceptions reach the auditor quickly.
5. 5 Follow-up Someone acts on what's flagged.

Think about protecting your house.

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.

Application controls depend on ITGCs. Weak ITGCs undermine them in three ways.

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.

1. 1 Conflict matrix List which duties and system rights clash.
2. 2 Pull real access Actual roles and permissions, across all systems.
3. 3 Find conflicts Users holding clashing rights.
4. 4 Watch the work Who really does each task? Shared logins?
5. 5 Check cover Where conflicts exist, are there compensating controls?

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.

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.

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.

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.

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.

For significant findings, the auditor gets evidence that the fix is in place and working. An email saying 'done' isn't enough.

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.

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.

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.

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.

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.

Picture a boat. Someone decides where it should go and keeps checking it's on course: that's governance. The crew rows, manages the sails and fixes leaks: that's management.

Both matter. A brilliant crew rowing in the wrong direction gets nowhere useful, and a perfect course is useless if nobody rows.

IT runs smoothly and projects finish on time. But the board hasn't discussed IT since approving a budget three years ago, and the CIO alone decides what to invest in.

The board is accountable for the organisation's governance, including IT and security. It can hand activities to committees and managers, but it can't hand away the accountability.

Executive management, led by the CEO, turns the board's direction into action. Crucially, management is responsible for internal controls; internal audit only checks them.

When the exam asks for the MOST important factor in making a governance, risk or security program succeed, the answer is very often senior management commitment and support. Without it, policies have no authority and programs have no money.

Every department wants something from IT: a new CRM, a faster website, a payroll upgrade. There's never enough money or people for all of it.

The IT steering committee is where business leaders and IT decide together which projects get done, and then keep an eye on them.

Senior people from the business units that depend on IT, plus the CIO and key advisers such as security, architecture and finance, often chaired by a sponsoring executive. Business representation is the whole point.

1. 1 Charter Written purpose, authority and membership.
2. 2 Members Senior business people, not just IT.
3. 3 Meetings Held regularly; minutes kept.
4. 4 Decisions Traceable to business strategy.
5. 5 Follow-through Actions tracked; projects monitored.

IT exists to help the business do what it's trying to do. A beautifully run IT department building things the business doesn't need is wasting money.

IT strategic planning makes sure IT is heading the same way as the business. When the exam asks what IT strategic planning is mainly for, the answer is alignment.

1. 1 Business strategy Start here, always.
2. 2 IT strategy Written, approved, current?
3. 3 Map initiatives Each one to a business goal.
4. 4 Check the budget Does spending follow the strategy?
5. 5 Check measurement Are benefits tracked?

If you only judged a football team by last season's prize money, you'd miss that its best players are leaving and its training is falling apart. Next season will be a disaster, and the money figures won't warn you.

Budget figures are like that: they show what already happened. A balanced scorecard adds measures that show what's coming.

A scorecard measures progress against a strategy. If there's no agreed strategy with clear goals, there's nothing to measure against.

COBIT is ISACA's framework for governing and managing IT. Think of it as a very complete checklist of everything an organisation should have in place to run IT well, organised so that it maps to other standards like ITIL and ISO 27001.

For auditors, it's a ready-made source of criteria: 'here's what good looks like'.

Each process can be rated from 0 (incomplete) to 5 (optimising), on a scale based on CMMI. The organisation sets a target level for each one; not everything needs level 5.

Users don't care about servers and networks. They care that email works, payroll runs and the website is up. IT service management treats IT as a set of services, each with an agreed level of quality.

ITIL is the most widely used guide to doing that well.

Buying a firewall doesn't make you secure. Security needs to be managed: risks assessed, controls chosen, people trained, results checked, and improvements made, over and over.

ISO/IEC 27001 describes how to run that management system, called an ISMS (information security management system).

Annex A lists reference controls, but organisations pick the ones their risk assessment says they need. The Statement of Applicability records every Annex A control with three answers.

Certification means the ISMS met 27001's requirements, for the certified scope, when the certification body last checked. Before relying on it, the auditor asks three questions.

COSO defines internal control as a process, run by the board, management and staff, that gives reasonable assurance an organisation will achieve its goals for operations, reporting and compliance.

Note 'reasonable'. Controls can be overridden, people make mistakes, and some controls cost more than they're worth. No system of control is perfect.

If leaders ignore the rules, the best-written controls fail.

COSO also publishes a separate enterprise risk management framework. Its big idea: consider risk when SETTING strategy, not just when carrying it out.

1. 1 Approve By the right level.
2. 2 Communicate Staff receive it and acknowledge it.
3. 3 Enforce Technical controls and consequences.
4. 4 Handle exceptions Approved, risk-assessed, time-limited.
5. 5 Review Regularly and after big changes.

DBAs, system administrators and network administrators can bypass application controls. The answer isn't to remove them; it's to limit and watch them.

1. 1 Least privilege Only the rights the job needs.
2. 2 Named accounts No shared admin logins.
3. 3 Log everything Privileged actions recorded.
4. 4 Independent review Someone else reads the logs.

The org chart shows security administration under the CISO. In practice, the operations manager approves all access requests and the security administrator just types them in.

The general idea is simple: no one person should be able to both do something wrong and cover it up. IT adds its own twist, because some IT jobs come with enormous power: changing programs, changing data, granting access.

Put two of those powers in one pair of hands and a single person can change anything and erase the evidence.

1. 1 Conflict matrix Which IT roles and rights clash.
2. 2 Pull real access Servers, databases, deployment tools, admin consoles, service accounts.
3. 3 Analyse Who holds clashing rights? Tools help in ERP.
4. 4 Observe Shared admin passwords defeat SoD on paper.
5. 5 Fix or cover Remove conflicts, or check compensating controls.

A five-person IT team can't split every job. The exam's expected answer is a compensating control, not hiring.

One engineer manages both Active Directory and the ERP database. Splitting the role isn't possible. Each month, the security monitoring system produces a report of all group changes, schema changes and privilege changes, and the finance controller checks each one against an approved request.

Imagine a city with no planning office. Everyone builds wherever they like: three hospitals on one street, no roads between neighbourhoods, pipes that don't connect.

Enterprise architecture is IT's planning office. It maps what exists, decides what the city should look like, and checks every new building fits the plan.

Three departments each buy their own CRM tool without telling IT. An architecture review, checking new systems against the target architecture, would have spotted the duplication and the integration cost before anyone signed a contract.

Risks change with new systems, threats, suppliers and laws. Reassess regularly AND after significant change. Key risk indicators give early warning in between.

Ask two people how worried to be about a house fire. One says 'low chance, terrible if it happens'. The other says 'about a 0.3% chance a year, costing about 300,000 if it does'.

The first is a qualitative assessment. The second is quantitative. Both are useful, for different jobs.

A data loss prevention tool costs 40,000 a year. It would cut breaches from once every 5 years to once every 20 (ARO 0.2 → 0.05).

Insurance and contracts move the money. They don't move the responsibility.

Responses can be combined. A legacy system can't support MFA, and replacing it costs 2 million and takes 18 months.

No organisation can remove all risk; doing business means taking some. The question is how much is acceptable.

Think of a family deciding how risky their investments should be. Young savers might accept big swings for bigger returns; a family about to retire wants safety. Organisations make the same kind of choice, and it's called risk appetite.

1. 1 Inherent risk Before any controls.
2. 2 Controls Reduce likelihood or impact.
3. 3 Residual risk What remains.
4. 4 Compare with appetite Within? Owner accepts it. Above? Treat more or escalate.

Two kitchens can both serve good food. In one, it depends on the head chef's mood that day. In the other, there are standard recipes, everyone follows them, results are measured, and the recipes keep getting better.

Maturity models put a number on that difference.

1. 1 Rate today Current level for each key process.
2. 2 Set a target Based on business need and risk.
3. 3 Find the gap Which practices are missing?
4. 4 Plan Prioritise improvements; reassess later.

A small company doesn't need level 5 change management. A critical regulated process might need level 3 or 4. The auditor compares the current level with the target the organisation set, not with the maximum. And maturity describes discipline; it doesn't prove a particular control worked.

Think about a marathon runner. Their finishing time is the result (a goal indicator). Their weekly training distance shows whether they're on track (a performance indicator). A sore knee is an early warning that something could go wrong (a risk indicator).

IT governance uses the same three kinds of measure.

IT reports '500 incidents closed this month' as its headline number. That's just activity: it doesn't say whether services are good.

Plenty of organisations hand IT work to specialists: payroll processing, data centres, the service desk, whole applications. Done well, it brings skills and savings. Done badly, it brings outages, breaches and lock-in.

And whichever way it goes, the organisation remains accountable. The exam returns to this again and again.

A bank outsources card processing. The processor is breached. Regulators fine the bank, which is still accountable for its customers' data. Whether the bank can recover any of its losses depends entirely on what the contract says about liability.

Cloud computing is renting IT instead of owning it. Like renting a home, the landlord looks after some things and you look after others, and arguments start when nobody's sure who fixes what.

The three main models differ in how much the provider handles.

Outsourcing to another country adds its own risks.

The marketing team signs up for a cloud analytics tool on a credit card and uploads customer lists. The provider stores data in another region, and nobody checked its security.

A sensible investor doesn't put all their money into whichever stock their friend recommends most loudly. They choose a balanced mix, review it regularly, and sell what's no longer working.

IT portfolio management does the same with IT projects and services.

1. 1 Evaluate Score business cases: value, fit, risk, cost.
2. 2 Select Fund the best mix within budget and capacity.
3. 3 Balance Keep the lights on, grow, transform.
4. 4 Monitor Track benefits, cost and risk.
5. 5 Adjust or stop Kill what no longer makes sense.

A licence check finds 1,200 copies of a design tool installed, but only 800 licences. Users have admin rights on their laptops and install it themselves.

The auditor matches HR's leaver list to VPN accounts and finds 14 people who left over a month ago still active, including a dismissed systems administrator. IT finds out about leavers by email, which is often missed.

1. 1 Identify Which requirements apply here?
2. 2 Review the process How does management track and meet them?
3. 3 Test controls The key ones for each requirement.
4. 4 Ask the lawyers Legal counsel for interpretation.
5. 5 Report Non-compliance to the right level.

A new HR system stores employees' health information, which privacy law treats as especially sensitive. No privacy impact assessment was done, and the compliance team didn't even know the system existed.

Quality management is about getting good results every time, not by luck. A quality management system (QMS) sets out the policies, processes and checks that make that happen, and keeps improving them.

ISO 9001 is the certifiable standard for a QMS.

Developers mark their own changes as 'QA passed' in the ticket system. On paper there's a QA step, but it's done by the people who wrote the code.

1. 1 Business case Approved before real money is spent.
2. 2 Stage gates Is the project still worth it? Ready for the next stage?
3. 3 Change control Scope, budget and time changes approved at the right level.
4. 4 Status reports Honest progress, risks and issues.
5. 5 Closure Acceptance, handover, lessons learned.

A project shows green status every month, but the auditor finds the baseline schedule was quietly reset three times without steering committee approval.

Imagine making Sunday lunch. The roast takes 2 hours; the vegetables take 30 minutes; you can't carve before the roast is done. Some jobs can happen at the same time, some must wait for others, and one long chain decides when lunch is ready.

Project schedules work the same way. Three tools help: Gantt charts, PERT and the critical path.

A Gantt chart shows each task as a bar along a timeline, often with milestones and how far along each task is. Easy to read and great for tracking progress. Its weakness: you can't easily see which tasks depend on which, so you can't tell which delays will push out the end date.

Before you can estimate cost and time, you need to know how big the job is. A builder estimates a house by floor area, not by counting bricks after it's built.

Function points are the 'floor area' of software: a measure of how much it does for its users, which you can count from the requirements before any code exists.

1. 1 Count The five components, from requirements.
2. 2 Weight Low, average or high complexity.
3. 3 Adjust For things like performance needs or complex processing.
4. 4 Function points The system's size.
5. 5 Effort and cost Using past productivity, e.g. hours per function point.

'We've spent half the budget and we're halfway through the schedule.' Sounds fine. But what if only a third of the work is done?

Earned value management answers the real question: how much work have we actually done, compared with the plan and with what we've spent?

1. 1 Identify Early and often: workshops, past lessons.
2. 2 Assess How likely, how bad.
3. 3 Respond Avoid, mitigate, transfer, accept; contingency.
4. 4 Assign owners Someone responsible for each risk.
5. 5 Monitor Risk register reviewed at steering meetings.

Before buying a car, you'd think about why you need it, what you could afford, the running costs as well as the price, and whether a bike or the bus would do instead.

A business case does the same for an IT project. It's owned by the sponsor and it's the reason the project exists.

A warehouse system was approved at 1.2 million, promising 400,000 a year in savings. Halfway through, costs are forecast at 2.5 million and half the warehousing has been outsourced, halving the savings.

Buying a gym membership doesn't make you fit. Going to the gym does. In the same way, a new system working perfectly doesn't deliver value until people use it and the business changes how it works.

Benefits realisation is about making sure the promised value actually shows up.

If you ask a builder for 'a nice kitchen', you'll get their idea of nice. Ask for 'a 4-metre worktop, a double sink under the window, and space for a dishwasher', and you'll get what you want.

Requirements are that precise list for a system. Most failed projects trace back to requirements that were vague, incomplete or never really agreed.

1. 1 Find stakeholders Users, owners, security, compliance, operations.
2. 2 Gather Interviews, workshops, observation, prototypes.
3. 3 Write down Clear, testable statements or user stories.
4. 4 Check with users Complete and accurate?
5. 5 Sign off and baseline Later changes through change control.

Requirements are the wish list: 'three bedrooms, a big kitchen'. Design is the architect's blueprint: where every wall, pipe and socket goes.

Builders follow the blueprint. If it doesn't show a smoke alarm, nobody fits one. Software is the same: if the design doesn't specify a control, developers won't build it.

1. 1Input, processing and output controls for critical data.
2. 2Audit trails: who did what and when, with before and after values for sensitive changes.
3. 3Access roles that support segregation of duties.
4. 4Error handling and exception reports.
5. 5Interface controls such as record counts and control totals.

Before coding starts, users, QA, security, operations and sometimes the auditor review the design against the requirements.

Gaps found here cost a meeting. Once approved, the design becomes a baseline, and later changes go through change control.

Each phase finishes and is approved before the next starts: requirements, design, build, test, implement.

It gives clear structure, strong documentation and defined approvals, which suits stable requirements and regulated work. The catch: users only see the system near the end, and changing requirements late is expensive.

A quick working model lets users react to something real, which clarifies fuzzy requirements. But prototypes are built fast and loose.

1. 1Controls, security and audit trails are left out.
2. 2The prototype gets put into production as-is.
3. 3Scope creep from endless feedback.
4. 4Users expect the real system as fast as the prototype.