CISA is an audit certification, not a build-and-operate one, and that distinction is the key to passing it. Where ISACA’s own CISM tests how you manage a security programme from the inside, CISA tests how you audit information systems from the outside: examining controls, weighing evidence, and reporting whether an organisation’s IT supports its goals and meets its obligations. The mindset you have to build is the auditor’s, and it is unusual enough that candidates from engineering or management backgrounds routinely pick the “wrong” best answer until they internalise it. For any scenario, the strong answer assesses, verifies, or reports on a control. It does not design, run, or fix one. This guide is a full self-study course. It teaches the five domains in depth, builds the auditor mindset that the questions hinge on, and turns it all into a week-by-week plan. It is original teaching material only and contains no real or simulated exam questions, and you should always confirm current rules and weights against ISACA’s own exam content outline before you book.
Chapter 1: Exam overview and how to use this guide
What CISA actually measures
CISA measures whether you can think and act like an information-systems auditor: plan a risk-based audit, judge whether evidence is sufficient and appropriate, evaluate whether controls are designed and operating effectively, and report findings objectively. It is ISACA’s long-standing flagship for IS and IT auditors, and it is built around assurance, not engineering. The recurring competence is judgement about controls and evidence rather than technical depth, which is why a strong systems engineer can find the exam harder than expected: the technology is familiar, but the seat is different.
The exam is 150 multiple-choice questions over four hours, delivered year-round through Continuous Testing at a centre or via remote proctoring. It is a linear exam, not adaptive, which has a practical consequence worth planning around: you can flag questions and return to them. Scoring is on a scaled range of 200 to 800, with 450 to pass, and the scaled score is deliberately not a raw percentage, so you cannot convert it cleanly to questions answered correctly. The credential is maintained on a three-year cycle through continuing professional education.
The five domains and their weights
The current blueprint, updated in 2024, organises the exam into five domains: Information Systems Auditing Process at 18%, Governance and Management of IT at 18%, Information Systems Acquisition, Development and Implementation at 12%, Information Systems Operations and Business Resilience at 26%, and Protection of Information Assets at 26%. The two 26% domains together are over half the exam, so they earn the most study time. The two 18% domains are next, and the 12% Acquisition domain is the smallest. One caveat to that allocation: even though the Auditing Process domain is only 18%, its principles - independence, evidence, risk-based scoping - shape the best answer across the entire exam, so it deserves more attention than its weight alone suggests.
The experience requirement
CISA has a real gate beyond the exam, and you should understand it from the start because it affects when the credential actually becomes yours. To certify, you need five years of professional information-systems auditing, control, or security experience, earned within the ten years before you apply. You may pass the exam first and then apply for certification within five years of passing, and some waivers can substitute for part of the requirement. In other words, passing the exam and becoming a CISA are two separate milestones, and the experience is the one that gates the title. Confirm the current rules on ISACA’s site, since the details matter for your timeline.
How to use this course
Read the chapters in order. Each domain chapter follows the same shape - what it covers, why it matters, how to study it, and the common pitfalls - and they build on one another, with the Auditing Process domain laying the foundation the others rest on. Treat the bold terms as a checklist you can explain in a sentence. The later chapters consolidate the auditor mindset, turn the content into a schedule and a final-preparation routine, and describe exam day and format. Short teaching illustrations appear where an idea is easy to misread, but none of them are exam questions. The single habit this whole course is trying to build is the reflex to ask, for any situation, what an independent auditor would do, conclude, or recommend.
Chapter 2: Information Systems Auditing Process (18%)
This domain is the discipline of auditing itself, and although it is only 18% of the exam, its principles run through every other domain. Study it first and study it well, because it defines the lens you look through everywhere else.
What this domain covers
The domain covers the full arc of an audit: risk-based planning, executing the audit against ISACA’s audit standards, gathering evidence, sampling, and reporting findings objectively. Underpinning all of it are two ideas that recur constantly. The first is independence and objectivity: an auditor must be free of relationships that could bias the work and, critically, must not audit work they themselves performed or own. The second is sufficient and appropriate evidence: conclusions must rest on evidence that is enough in quantity and both relevant and reliable in quality, with corroboration preferred over assertion. Around these sit the mechanics - the audit charter that grants the function its authority, sampling methods, materiality (whether a weakness is significant enough to matter), and the audit finding itself, which is a gap between an observed condition and the expected control criterion.
Why it matters
This domain matters out of all proportion to its weight because it teaches you how an auditor reasons, and that reasoning is what the exam tests everywhere. Risk-based scoping tells you where audit effort belongs - where the impact of control failure is greatest - which is exactly the judgement the questions reward across the technical domains. The evidence standard tells you why an auditor trusts some conclusions and not others, which shapes the right answer whenever a scenario hinges on what the auditor actually knows versus assumes. And independence is the reason the auditor’s correct action is so often to report or recommend rather than to fix: stepping in to remediate a control would compromise the very objectivity the role depends on.
How to study it
Internalise the principles until they are instinct, then practise applying them. For independence, train yourself to spot the situations that impair it, the clearest being an auditor reviewing systems they built or operate. For evidence, practise asking of any conclusion whether the evidence behind it is sufficient and appropriate, and prefer reliable, corroborated evidence over a single assertion. For risk-based auditing, practise scoping: given limited time, where would an auditor focus, and why. As a teaching example of the evidence standard at work: a control that someone says is operating is weaker evidence than a control you have tested and seen operate, and an auditor’s confidence should track that difference. Make the habit of reasoning from independence, evidence, and risk so automatic that it carries into the other domains without conscious effort.
Common pitfalls
The defining pitfall of the whole exam shows up first here: answering as an engineer or a manager who fixes and operates, rather than as an auditor who assesses and reports. Resist the urge to solve the problem; the auditor’s job is to evaluate it and recommend that the owner act. A second pitfall is underrating evidence quality, treating an assertion as if it were tested fact. A third is neglecting this domain because it is mid-weighted, when in truth its principles are the connective tissue of every other answer. Give it the foundational attention it deserves.
Chapter 3: Governance and Management of IT (18%)
This domain moves up a level from the audit process to what the auditor examines at the top of an organisation: how IT itself is directed and controlled. You are assessing whether governance exists and works, not setting it.
What this domain covers
The domain covers auditing IT governance frameworks, IT strategy and its alignment to the business, the policies and organisational structures that direct IT, the roles and responsibilities that make accountability clear, and IT-related risk management. The recurring theme is alignment: does the organisation’s IT actually serve its business goals, and are the structures in place to keep it that way. You assess whether a strategy exists, whether it ties to business objectives, whether policies and roles support it, and whether IT risk is being managed in a way leadership can see and govern.
Why it matters
Governance matters because it is where IT either connects to the business or drifts from it, and the auditor’s job is to judge that connection. A scenario in this domain typically asks not how to build a governance structure but whether an existing one is adequate and how the auditor would assess it. That framing reinforces the core stance of the exam: the auditor evaluates and reports on governance rather than designing it. Understanding the distinction between governance (the framework of oversight and decision rights) and management (the execution within that framework) helps you place where a control or a weakness actually sits, which the exam expects you to do.
How to study it
Focus on the auditor’s evaluative questions rather than on how to construct governance from scratch. For any governance element, ask how an auditor would assess whether it exists, whether it is appropriate, and whether it is working. Learn the difference between policies, standards, and procedures so you can recognise which level a given document sits at, and understand how roles and responsibilities create the accountability an auditor looks for. Study IT risk management from the assessment angle: not how to run a risk programme, but how to judge whether the organisation’s risk management is adequate. Keep returning to alignment, because “does this serve the business goal” is the question the domain keeps asking.
Common pitfalls
The main pitfall is slipping into the consultant’s chair and answering as if your job were to design the governance framework, when the exam wants you to assess the one that exists. A second is blurring governance and management, which makes it hard to place where a weakness belongs. A third is treating this as abstract: tie every governance concept back to the concrete auditor action of evaluating and reporting, and it stays grounded.
Chapter 4: Information Systems Acquisition, Development and Implementation (12%)
This is the smallest domain, but it covers a stretch of an organisation’s life where a great deal can go wrong: how systems are chosen, built, and put into production. The auditor’s interest is in the controls at each stage.
What this domain covers
The domain covers auditing the whole lifecycle of getting a system in place: the business case that justifies it, the project governance that steers it, the systems development life cycle (SDLC) and the controls at each of its stages, testing, data migration, and the post-implementation review that confirms after go-live that the system delivered the intended benefits and controls. Whether the organisation builds the system or acquires it, the auditor asks the same kind of question at each stage: what control should be here, and is it present and working.
Why it matters
This domain matters because projects are where controls are most often skipped under deadline pressure, and the consequences land later. The exam expects you to know which control belongs at which stage of the SDLC, so that you can recognise when one is missing. The post-implementation review is a recurring focus because it closes the loop: it is the auditor’s check that the promised benefits actually materialised and that controls came across into the live system intact. A project that shipped on time but skipped its controls or never confirmed its benefits is exactly the kind of finding this domain trains you to surface.
How to study it
Learn the SDLC well enough to walk it stage by stage and name the control that belongs at each one, because that is the mental model the exam draws on. Practise mapping a control to its stage: what should happen during requirements, during development, during testing, during migration, during deployment, and at the post-implementation review. Understand the business case as the justification an auditor checks back against, and the post-implementation review as the confirmation that the justification was met. Because this domain is the smallest, do not over-invest, but do make sure the stage-to-control mapping is solid, since that is where its questions concentrate.
Common pitfalls
The most common pitfall is misplacing controls in the lifecycle - knowing controls exist but not which stage each belongs to - which leaves you unable to spot the missing one. A second is overlooking the post-implementation review, which is a favourite focus precisely because it verifies outcomes rather than activity. A third is over-investing here at the expense of the 26% domains; keep this domain proportionate to its 12% weight.
Chapter 5: Information Systems Operations and Business Resilience (26%)
This is one of the two joint-largest domains, and it covers the running of IT day to day plus the organisation’s ability to survive disruption. Give it heavy time, both because of its weight and because its resilience content carries a chain of reasoning the exam loves to test.
What this domain covers
The domain has two halves. The first is IT operations: change, problem, and incident management, job scheduling, and backups - the controlled, repeatable running of the IT estate. The second is business resilience: business continuity and disaster recovery. The chain to know cold is BIA leads to RTO and RPO, which lead to BCP and DRP. A Business Impact Analysis (BIA) identifies the critical functions and the impact of their disruption. From it come the Recovery Time Objective (RTO), the target time to restore a process, and the Recovery Point Objective (RPO), the acceptable amount of data loss. Those objectives drive the Business Continuity Plan (BCP), how the business keeps operating through disruption, and the Disaster Recovery Plan (DRP), how IT services are restored after a disaster.
Why it matters
This domain matters because resilience is where the cost of getting it wrong is existential, and the exam tests whether you understand the logic, not just the acronyms. The chain matters because each link justifies the next: the plans are only adequate if they actually meet the RTO and RPO, and those objectives are only right if they reflect the BIA. The auditor’s recurring check follows that logic - do the plans match the BIA, and are they actually tested - because an untested plan or a plan that does not meet its objectives is a finding regardless of how polished the document looks. On the operations side, the exam expects you to recognise the controls that keep day-to-day IT disciplined, especially around change management.
How to study it
Memorise the resilience chain until you can recite it and, more importantly, explain why each link depends on the one before it. Then practise the auditor’s questions: does this plan trace back to the BIA, does it meet the stated RTO and RPO, and has it been tested. The word “tested” deserves emphasis, because the existence of a plan is not the same as a plan that works, and the exam consistently rewards the auditor who checks that resilience has actually been exercised. For operations, study change, problem, and incident management as controls an auditor evaluates, and understand backups in terms of how they support the RPO. As a teaching example of the chain in action: a polished continuity plan that has never been tested against its own recovery objectives is exactly the gap this domain trains you to call out.
Common pitfalls
The headline pitfall is treating the resilience chain as four loose acronyms instead of a logical sequence, which leaves you unable to reason about whether plans are adequate. A second is accepting that a plan exists as proof that resilience is in place, when the auditor’s standard is a plan that matches the BIA and is tested. A third is underweighting this domain; at 26% it is too large to treat lightly, and its reasoning is some of the most testable in the exam.
Chapter 6: Protection of Information Assets (26%)
This is the other joint-largest domain, and it is the closest CISA comes to traditional security content. The crucial reframing is that you are still the auditor: you evaluate whether the controls protecting data and systems are designed and operating effectively, not whether you can configure them.
What this domain covers
The domain covers auditing the controls that protect information: logical and physical access controls, network and endpoint security, encryption and key management, data classification, and incident response from the assurance angle. Two control concepts recur throughout and are worth holding precisely. The first is the family of control types - preventive controls that stop an event, detective controls that spot it after it happens, corrective controls that fix or restore afterwards, and compensating controls that cover a gap when the primary control is impractical. The second is segregation of duties (SoD), splitting a sensitive task so that no single person controls an entire process, which is one of the most important access-control ideas in the whole exam.
Why it matters
This domain matters because protecting assets is where security and audit meet, and the exam wants you to evaluate protection rather than build it. The control-type vocabulary matters because questions frequently hand you a control and expect you to classify it, or ask which type of control fits a situation, so knowing the four types precisely is directly tested. Segregation of duties matters because its absence is a classic, recurring finding: when one person can both initiate and approve a transaction, the control has failed by design, and recognising that is exactly the auditor’s contribution. The recurring judgement across the domain is whether a control is both well designed and operating effectively, since a control that looks right on paper but is not actually working is still a finding.
How to study it
Learn the four control types cold and practise classifying real controls into them, because that classification is a direct exam skill. Study access control through the lens of segregation of duties and least privilege, and practise spotting where duties are not properly separated. For encryption, data classification, network, and endpoint security, keep your study at the auditor’s level: understand what each control is for and how an auditor would judge whether it is designed and operating effectively, rather than the implementation detail. Always ask the two-part question the domain is built on - is the control well designed, and is it actually working - because design without operation, or operation without design, is the gap the exam wants you to find.
Common pitfalls
The main pitfall, again, is reaching for the engineer’s answer and trying to configure or fix the control instead of evaluating it. A second is muddling the control types, which makes classification questions guesswork; drill them until they are crisp. A third is checking only design or only operation, when the auditor’s standard requires both. Keep the evaluative, two-part question front of mind and this domain rewards you well for its weight.
Chapter 7: The auditor mindset and how to choose answers
Every domain in CISA is solved by the same underlying instinct, and this chapter pulls it into the open because it is the single thing that most determines results. The exam is not testing what you would do as an engineer or a manager. It is testing what an independent auditor would do, conclude, or recommend.
What the auditor mindset is
The auditor’s stance has a few defining features. The auditor is independent and objective, which means they do not audit their own work and do not step in to run the controls they examine. The auditor assesses, verifies, and reports rather than designing, building, or fixing. The auditor reasons from evidence, preferring what has been tested and corroborated over what has merely been asserted. And the auditor scopes by risk, focusing effort where control failure would hurt most. Hold those four together and you have the lens that resolves most CISA scenarios.
How to choose the best answer
Approach each scenario the same way. Identify the control or the issue, then ask what an independent auditor would do about it, and let independence steer you away from any option that has the auditor implementing or operating a control. Among the remaining options, prefer the one that gathers evidence, tests effectiveness, reports a finding, or recommends that the responsible owner act. The reliable distinction is between assessing and doing: if an option has you fixing or operating something, it is usually the CISM-style answer rather than the CISA one. As a teaching example of the pattern: when a scenario reveals a weak control, the strong CISA answer is typically to document the finding and recommend the control owner remediate it, not to have the auditor remediate it personally, because the latter would impair the independence the role depends on.
CISA versus CISM in one line
Same provider, opposite seat. CISA is the auditor checking the controls from the outside; CISM is the manager building and running the security programme from the inside. If a question tempts you to fix or operate something, that is the manager’s reflex, and on CISA it is usually wrong. Keeping that contrast sharp is one of the most reliable ways to pick the best answer, and it is exactly where candidates with a management or engineering background lose marks until the auditor’s stance becomes second nature. If you are weighing the two credentials before committing, the CISA vs CISM comparison lays out how the auditor and manager paths differ.
Chapter 8: Study plan, final preparation, and exam day
With the domains understood and the mindset in place, the remaining work is pacing the study so the two big domains and the auditor’s reasoning get the time they need.
Choose a timeline and weight it
Most candidates need roughly 80 to 120 hours over three to four months, and working IS auditors who already live in this material can compress that. A balanced plan runs about fourteen weeks at six to eight hours: the first weeks on the Auditing Process and IT Governance domains (18% each), a shorter block on the 12% Acquisition domain, then the most time on the two 26% domains, Operations and Business Resilience and Protection of Information Assets, and a final fortnight of full-length, timed reviews and weak-area revision. Front-load the smaller domains and give the 26% domains the largest share, while remembering that the Auditing Process principles deserve early, careful attention because they shape every other answer. To turn whichever timeline you pick into dated weeks for your own start date, use the free study-plan generator.
Build the auditor’s answer throughout
Do not leave the mindset work to the end. For every topic you study, practise the auditor’s questions - how would I assess this, what evidence would I want, what would I report - so that by the time you reach full-length practice, choosing the assess-and-report answer over the fix-it answer is automatic. This is the habit that most separates passing from failing candidates, and it is built over weeks of deliberate practice, not crammed in the final days.
Final preparation and exam day
In the last weeks, take full-length, timed reviews at the full 150-question length to build the stamina a four-hour exam demands, and concentrate revision on the two 26% domains while keeping the Auditing Process principles fresh. Read each review as a diagnosis: for every miss, articulate why the best answer is the one an independent auditor would give, rather than only noting the correct option. On the day, the exam is 150 multiple-choice questions in four hours, delivered year-round through Continuous Testing at a centre or with remote proctoring, with government-issued identification required. Because it is linear rather than adaptive, make the flag-and-return strategy part of your plan: answer everything you are confident about on the first pass, flag the ones that need thought, and come back to them with time and a clearer head. The score is scaled 200 to 800 with 450 to pass, so do not try to track a running percentage in your head; focus on choosing the best audit answer each time. And keep your application records accurate alongside your studying, because the five years of qualifying experience is what turns a passing score into the CISA credential, and a clean record removes a source of late stress.