Picture a Monday morning in Kampala. A bank teller cannot reverse a wrong transfer, because the system will not let her. Across town, a hospital clerk opens a patient file that belongs to someone else. At a university, the portal shows last semester's marks to the wrong class. A mobile money agent holds two phones and says the float does not match.
In each place someone has to ask a plain question. Can we trust this system? That question is where an information systems audit begins. You will meet it properly this semester, and you will practise it on the BBC Bank capstone.
This is part 1 of Understanding IT and IS Audit. We will not open a checklist yet. First you need a clear picture of what an audit is, how it differs from security work, and the four phases every audit follows. The series will continue on this blog.
What an IS Audit Actually Is
An information systems (IS) audit is an independent, evidence-based check of the controls around information and technology. The check asks whether management can rely on those controls. People also say IT audit. In this series the two names mean the same job. IT audit often stresses the machines. IS audit also looks at the people and the process around the machines. A password rule that nobody enforces is still an IS problem.
Independent means the person doing the check is not marking their own homework. Evidence-based means the conclusion comes from things you can show, not from a feeling that the system looks fine. Controls are the rules, settings, checks, and separations that keep a process honest. Assurance is the result. It is a clear statement, backed by that evidence, about how much trust is reasonable.
Assurance is not a promise that nothing will ever go wrong. It is a reasoned opinion. "Based on the tests we did, these controls were operating during this period." That sentence is only worth something if the tests were real.
Here is the smallest difference between a guess and evidence.
Opinion: "Access control seems okay."
Evidence: "Of 25 sampled leavers in March, 25 had access removed within one working day. Screenshot of the leaver list, ticket numbers, and the access log are in working paper A-12."If you cannot point to the paper, you do not have a finding yet. You have a hunch. A hunch is useful. It tells you where to look. It is not the audit.
Security Builds, Audit Verifies
Information security designs and runs the protection. Security staff write the firewall rules, set up the backups, lock the server room, and teach people not to share passwords. Their job is to build controls and to keep them running.
IS audit comes after that work and asks three questions. Do the controls exist? Do they match the policy? Did they actually operate during the period under review? The auditor does not configure the firewall in order to help. The moment the auditor builds the control, they are no longer independent enough to judge it.
Think of a boda stage and a traffic officer. The stage master organises the riders. That is operations, closer to security and to management. The officer checks whether the rules were followed. That is closer to audit. If the officer also owns the stage, nobody trusts the check. The picture is not perfect. The conflict of interest is the point.
Security and audit need each other. A bank with strong security and no audit can drift. A bank with auditors and no security team has nothing solid to test. In this course your job is the check, not the build.
What Auditors Evaluate: The Control Objectives
A control is not "good" in the abstract. It is good if it meets a control objective. You will meet six objectives again and again. The first three are the classic security triad. The next three stop the work from being only a security exercise.
Confidentiality. Information is seen only by people who are allowed to see it.
Integrity. Information is complete, accurate, and changed only in an authorised way.
Availability. Information and systems are there when the business needs them.
Compliance. The organisation follows the laws, regulations, and internal policies that apply to it. In Uganda that includes the Data Protection and Privacy Act. For a bank it also includes the rules the bank itself has adopted, and the duties a regulator expects of it.
Efficiency. Resources are used without waste. A control that needs ten people to do what one system check could do is an efficiency question.
Effectiveness. The control actually achieves the goal. A tidy policy that nobody follows is not effective.
Three short pictures make this concrete. Each one has an objective, a failure, and a way to test.
The leaver who still has access. A member of staff leaves the bank on Friday. On Monday their user account still opens the core banking system. Confidentiality has failed. Customer data is open to someone who should now be a stranger. The objective was simple. Remove access on the last working day. The test is simple too. Take a sample of leavers. Compare the exit date with the date the account was disabled.
The wrong fee. A customer is charged 5,000 shillings for a transfer. The tariff says the fee is 2,500. Integrity has failed. The figure in the system is not the figure the rule allows. You do not settle this by arguing with the teller. You recompute a sample of fees from the tariff, then compare them with what the system posted.
The recovery plan in a drawer. The data centre floods. A disaster recovery document exists. Nobody has tested it in two years. The backups have never been restored onto a clean machine. Availability is a hope, not a control. The objective is that the bank can bring the promised services back, within the time it promised. A document alone does not meet that objective. A tested restore does.
Hold on to that trio. Objective, failure, test. You will use it when you write findings later in the series.
The Types of Audit You Will Meet
Not every audit asks the same question. The name tells you the purpose. You will hear these names in class, and you will meet them again in the CISA material.
Financial audit, on the IT side. The auditors are testing whether the figures in the accounts can be trusted. They care about the systems that produce those figures. Fees, interest, journals, and reconciliations sit here.
Compliance audit. Did the organisation follow a stated law, regulation, or policy? The Data Protection and Privacy Act is one example. A bank's own access policy is another.
Operational audit. Are the processes working with efficiency and effectiveness? Here you ask whether a control is slow, duplicated, or ignored, not only whether it exists on paper.
Integrated audit. The controls over the financial figures, and the IT controls that feed those figures, are tested together. The opinion on the numbers and the opinion on the systems should support each other.
Forensic audit. Something already looks wrong. A fraud, a dispute, or a loss. The aim is evidence that can stand up to an investigation. It is not a routine assurance opinion.
Internal and external. Internal auditors sit inside the organisation. They should report to the board, usually through an audit committee, not to the managers they review. External auditors come from outside, often for the statutory accounts or at a regulator's request. Both must be independent. They are independent from different places.
On the BBC Bank capstone you will mostly work like internal IS auditors. You will plan, test, and report. You will not be asked to prosecute anyone. That is the forensic lane, and it has extra rules.
The Auditor's Most Valuable Asset: Independence
ISACA's Code of Professional Ethics asks members to be objective, careful, and worthy of the trust people place in their work. In an audit, that demand shows up as independence. Students often remember only half of it.
Independence in fact means you are actually free of interests that would bend the opinion. You do not audit a system you configured last month. You do not hide a finding because the manager is your uncle. You do not take a gift that would make a quiet pass feel easier than a finding.
Independence in appearance means a reasonable person, looking from outside, would believe you are free. This half surprises people. You can be honest and still look captured. If you designed the control and then audited it, a classmate will ask a fair question. How do we know you were not protecting your own work? The question stands even when the work was good.
Appearance is also why internal audit does not report to the IT manager whose systems are under review. The reporting line is part of the control over the auditor. If the line is wrong, the best working papers in the building will still be doubted.
When you are unsure, use a plain test. Would I be comfortable if the audit committee read this chat, saw this lunch, or knew I built this script? If the answer is no, step back. Let someone else do that piece of the audit.
The Four Phases of the Audit Process
Every IS audit you will study moves through four phases. The CISA Review Manual describes them. So does ISACA's IT Audit Framework (ITAF). Firm names vary a little. The work does not.
Plan. Understand the business and the system. Identify what could go wrong. Decide which risks matter most. Write an audit plan that says what you will test, why, and how deep. A plan is a promise about scope. It stops the audit from wandering into every interesting screen.
Fieldwork. Walk through the process with the people who run it. Test the controls. Sometimes you inspect a setting. Sometimes you reperform the control yourself. Sometimes you sample transactions. Everything you rely on goes into working papers. If it is not in the papers, it did not happen.
Report. Turn the test results into findings. A finding needs a condition (what is), a criterion (what should be), a cause, and an effect. Rate the severity so management knows what to fix first. Hold an exit meeting so the people who run the system can correct a factual mistake before the report is final. Agree an action plan with an owner and a date.
Follow-up. Come back and check that the fix was made, and that the fix works. A closed meeting is not a closed finding. Whatever is still open feeds the next plan. Audit is a loop, not a single visit.
Here is one worked pass, because this is where a new auditor loses the thread. The plan says you will test leaver access on the core banking system, for the first quarter, with a sample of 25. Fieldwork produces working paper A-12, the note in the tiny example above. The report does not say "access is bad" in general. It says whether that test passed or failed, how serious any gap is, and who will fix it. Follow-up opens A-12 again and checks leavers who left after the fix. Skip a phase, and the next phase has nothing solid to stand on.
Read the figure from left to right. Each box is a phase. Each arrow is a handoff. The next phase should be able to pick up a document and continue.
Why Audit Is Risk-Based
A bank has thousands of settings. You cannot test all of them, and you should not pretend to. A risk-based audit spends time where a failure would hurt the most.
For this week, treat risk as two questions joined together. How likely is it that something goes wrong? How bad is it if it does? A wrong poster on the branch Wi-Fi can sit there for a month and the bank still stands. A failure in the night posting to customer balances can empty trust by morning. The second one gets more audit hours. That is not because the poster is fine to ignore forever. Scope is a choice, and the choice should follow risk.
ITAF expects this thinking. COBIT 2019 gives managers and auditors a shared language for governance and management objectives, so the risk conversation is not only an audit private dialect. You do not need to memorise every COBIT objective today. You do need the habit. Ask what can go wrong, who would be harmed, and how you would know.
Risk-based does not mean "only look at what management is already worried about". Management may be quiet about a system they built themselves. Your risk assessment has to be yours. Independence shows up here, not only in the reporting line.
A Grounded Example
Here is a teaching case, not a report on a named bank. The setting is a Ugandan bank. The problem is the night reversals.
Every evening the core banking system posts the day's transfers. Between midnight and 4 a.m. a small operations team can reverse a posting that failed, or a posting that was duplicated. The business needs that window. A customer should not wake up to a double debit. The same window can hide theft. A reversal can send money back to a friendly account. A second transaction can move it out before the branch opens.
You are the IS auditor. You do not start by accusing the night team. You start with objectives and with the controls that are supposed to meet them.
Access. Who can log in during that window? The list should be short, approved, and reviewed. A leaver, a day-shift teller, or a generic account called NIGHT01 is a failure of confidentiality and of accountability. If everyone shares NIGHT01, you cannot say who pressed the button.
Segregation of duties. The person who starts a reversal should not be the person who approves it. Neither of them should be the only person who reconciles the suspense account in the morning. Segregation of duties means splitting roles that, combined, would let one person both cause a problem and hide it. If the same officer can raise, approve, and clear the reversal, the objective is already missed. That is true even when the officer is honest.
Change control. Suppose a developer changed the reversal limit on a Thursday, called it temporary, and never changed it back. Change control means no change to a live system without a request, a test, an approval, and a record. You ask for the change tickets around the night-reversal program. A changed limit with no ticket is a finding. The criterion is the bank's own change policy.
Recomputation. Pull a sample of night reversals for one month. For each one, recompute the original amount and the reversed amount from the tariff and the transaction log. This test is called reperformance. You do the calculation again yourself. You are not asking the night team whether they usually get it right. The working paper shows the sample, any difference, and the source of each figure.
Now walk the four phases on this one risk. In planning you rank night reversals above the branch poster, and you write the tests into the plan. In fieldwork you test access, segregation, change tickets, and the recomputation. In the report you might have one finding on shared IDs, and another on a limit change with no ticket. Severity follows the effect. A shared ID on a reversal window can move customer money with no name attached, so that finding sits high. At the exit meeting the operations manager may say the generic ID was disabled last week. You check that claim against the log before you soften a single word. In follow-up, a month later, you sample new reversals. If names are now on the log, that action can close. If the limit change still has no ticket, it stays open and walks into the next plan.
That is an audit. It is not a tour of the server room. It is a question, a risk, a test, a paper, a report, and a return visit.
Where This Series Goes Next
Part 2 slows down on risk and the audit plan. A weak plan makes the later phases busy and useless. Part 3 covers fieldwork and the kinds of evidence. Part 4 covers findings, severity, and the report. Part 5 covers follow-up, and how audit sits inside governance.
Bring one question from this part with you. If you can explain, in your own words, why the night-reversal window needs segregation of duties, you are ready to write a plan.
Key Terms to Remember
IS audit. An independent, evidence-based check that gives assurance on controls over information and systems.
Control. A rule, setting, check, or separation that reduces a risk.
Control objective. The goal a control is meant to meet. In this article: confidentiality, integrity, availability, compliance, efficiency, and effectiveness.
Assurance. A reasoned conclusion about how much trust the evidence supports. Not a promise that nothing will fail.
Independence in fact. You are actually free of interests that would bend the opinion.
Independence in appearance. A reasonable outsider would believe you are free.
Working papers. The record of what you tested and what you found. The audit's memory.
Segregation of duties. Splitting roles so one person cannot both cause and conceal an error or a fraud.
Reperformance. Doing the control, or the calculation, again yourself as a test.
Risk-based audit. Putting effort where a failure would hurt the most, using your own assessment, not only management's comfort.
References
ISACA (2024). CISA Review Manual, 28th edition. Schaumburg, IL: ISACA.
ISACA (2020). IT Audit Framework (ITAF), 4th edition. Schaumburg, IL: ISACA.
ISACA (2019). COBIT 2019 Framework: Governance and Management Objectives. Schaumburg, IL: ISACA.
Hall, J. A. (2015). Information Technology Auditing, 4th edition. Boston: Cengage Learning.
ISO/IEC 27001:2022. Information security, cybersecurity and privacy protection. Information security management systems. Requirements.
Your Reflection and Peer Review
This section is a required learning activity. Read it carefully, because reflection is where understanding actually forms. Professionals who stop to write down what they have learned remember and apply far more than those who simply move on.
Part A: Write your own reflection (about 300 to 400 words)
In the comments below this article, post a reflection that answers the following. Write in full sentences and in your own words.
In two or three sentences, explain in your own words what an IS audit is, as if you were explaining it to a relative who has never studied computing.
State the single most important difference between information security and IS audit, and why that difference matters.
List your three key takeaways from this article. For each one, write a sentence on why it matters in a real organisation.
Describe one thing you found confusing or surprising, and what you now understand about it.
Give one example from your own life, school or community where a lack of independence or a missing control caused a problem.
Part B: Critique at least five peers' reflections
After posting your own reflection, read what your classmates wrote and give a thoughtful critique on at least five of them. A critique is not praise and it is not an attack. It is a constructive, specific response that helps the other person think more deeply. For each of the five, write two to four sentences that do the following.
Name one thing the peer explained well, and say specifically why it was clear or accurate.
Identify one idea that was missing, unclear, or not quite correct, and explain what you would add or change.
Ask one genuine question that pushes their thinking further.
What a good critique looks like
Weak critique: "Nice work, I agree with everything you said." This helps no one.
Strong critique: "Your explanation of independence was clear, especially the point that appearance matters as much as reality. I think you mixed up security and audit in point two, because configuring a firewall is a security task, not an audit task. If an auditor cannot see the firewall rules, how would you suggest they test whether the rules match policy?"
Ground rules
Be respectful. Critique the idea, never the person. Assume your classmate is intelligent and well-meaning. Your goal is to help the whole class understand audit more deeply, and in doing so you will understand it better yourself.