CISA Certified Information Systems Auditor Exam Topics and Questions

This is where the exam establishes whether you can actually conduct an audit, not just describe one. The domain splits into planning and execution, and both halves matter equally. Your exposure is highest when you conflate audit types, misread when a risk-based approach changes the scope, or misapply sampling logic. Eighteen percent of the exam lives here, so a weak grasp of the mechanics of evidence collection or reporting will show up in your score.

– Standards, ethics, and the shape of an engagement

ISACA's audit standards are not background reading; they are the authority the exam uses to judge every procedural decision. Know the hierarchy: standards set minimum requirements, guidelines offer guidance, and the Code of Professional Ethics sits above both. When a scenario describes an auditor making a judgment call, the standard in play determines which option holds.

Audit types matter because the scope, objective, and deliverable differ. An operational audit, a compliance audit, a financial audit, and a penetration-style assessment each impose different obligations on the auditor. The exam will describe a situation and expect you to identify what kind of engagement is appropriate, or what the auditor's obligations are within that engagement type. Controls come in preventive, detective, and corrective varieties, and the exam expects you to distinguish them by function, not just by name. Where two controls address the same risk, the exam rewards selecting the one that fits the control objective, not the one that sounds more thorough.

– Risk-based planning and scoping

Risk-based audit planning means the audit scope is driven by where material risk concentrates, and the exam tests whether you apply that logic consistently. A scenario may describe a large environment with limited audit resources and ask how scope should be set. Items reward prioritising areas of highest inherent risk adjusted by the strength of existing controls, not simply covering the broadest surface area.

When planning bleeds into execution, the exam checks whether you sequence steps correctly. Fieldwork cannot begin before objectives are set, and objectives must trace back to risk. Misreading that sequence is a common source of lost marks.

– Execution: testing, evidence, and data analytics

Sampling methodology is a frequent testing target. The exam distinguishes statistical from non-statistical sampling, and within statistical sampling it distinguishes attribute from variable sampling. The choice of method must match the audit objective; picking a method that cannot answer the question the auditor is trying to answer is a disqualifying error in exam logic.

Evidence collection techniques carry their own hierarchy. The exam rewards understanding which techniques produce the most reliable evidence: direct observation outranks inquiry, and documentary evidence from independent sources outranks evidence from the auditee. Audit data analytics is increasingly prominent; the exam expects you to understand what analytics can establish and where its limits lie, particularly around completeness and accuracy of source data.

– Reporting, communication, and quality assurance

Audit reporting is not just about format. The exam tests whether findings are supported by sufficient, appropriate evidence before they appear in a report, and whether exceptions are communicated to the right level of management at the right time. An auditor who escalates a minor finding to the board, or who buries a material control gap in an appendix, is making a judgment error the exam will penalise.

Quality assurance of the audit process itself is a sub-topic that candidates often skip. ISACA expects auditors to subject their own work to review, and the exam may present scenarios where an audit's conclusions are challenged. Items reward recognising that quality assurance applies throughout the engagement, not only at sign-off.

How INFORMATION SYSTEMS AUDITING PROCESS is tested

At 18%, this domain generates a meaningful share of the exam. Items are almost always scenario-based: a paragraph describes an auditor in a specific situation, and you select the most appropriate next step, technique, or judgment. The demand is procedural accuracy under ambiguity, not recall of definitions.

The traps cluster in three places. First, candidates choose the most thorough-sounding option rather than the one that fits the audit objective and risk level. Second, sampling questions trip candidates who confuse when to use each method. Third, evidence questions reward a clear mental model of the reliability hierarchy; candidates who treat all evidence as equivalent lose marks consistently.

Reporting items reward matching the communication to the audience and the materiality of the finding. Quality assurance items reward treating the audit itself as a controlled process subject to oversight. Spending time on the mechanics of each phase, rather than memorising definitions, is what separates passing scores from failing ones here.

Where the first domain asks how an audit is conducted, this one asks what the auditor is evaluating when they look at how IT is directed and controlled at the enterprise level. Governance and management are distinct in ISACA's model, and the exam exploits that distinction. Your risk here is treating this domain as a policy recitation exercise. The exam is interested in whether you can assess governance structures and management practices against a standard, not whether you can list what those structures contain.

– Legal, regulatory, and standards obligations

Laws, regulations, and industry standards create the floor below which an organisation cannot go, and the auditor's job is to verify that the floor is met. The exam tests whether you understand the auditor's role in a compliance context: assessing adherence, not designing the programme. Items will describe a regulatory environment and ask what the auditor should examine or conclude.

The distinction between a law, a regulation, and a voluntary industry standard matters because the audit response differs. Non-compliance with a law carries a different risk profile than a gap against a framework like COBIT or ISO 27001. The exam rewards applying the right level of scrutiny to the right type of obligation.

– Organisational structure, strategy, and architecture

IT governance is about decision rights and accountability: who decides what, and who is answerable for outcomes. The exam will present a scenario describing an organisational structure and ask whether governance is functioning effectively. Items reward identifying where accountability is unclear, where IT strategy is misaligned with business objectives, or where the architecture creates uncontrolled risk.

Enterprise architecture questions ask whether the architecture supports the organisation's strategic direction and whether control gaps exist at the architectural level. The exam is not testing your ability to draw an architecture diagram; it is testing whether you can read one critically and identify where the control environment is weak.

– Policies, risk management, privacy, and data governance

IT policies, standards, and procedures form the control framework that governance puts in place. The exam distinguishes between a policy (the what and why), a standard (the mandatory requirement), and a procedure (the how). Auditors evaluate whether each level exists, whether they are consistent with each other, and whether they are actually followed.

Enterprise risk management, privacy programmes, and data governance all appear in scenarios that ask the auditor to assess whether risk is being managed at the right level with the right ownership. Data classification is particularly testable: the exam rewards understanding that classification drives control selection, and that misclassification is itself a control failure.

– IT management: resources, vendors, performance, and quality

IT management translates governance intent into operational reality. Resource management questions test whether the auditor can assess whether IT capacity, staffing, and budget are aligned with organisational need and risk appetite. Vendor management is a consistent exam target: the exam expects you to know what due diligence looks like, what contract provisions matter for control purposes, and how the auditor evaluates third-party risk.

Performance monitoring and quality management questions reward a clear understanding of what a meaningful metric looks like versus a metric that produces data without enabling a decision. Items will describe a reporting structure and ask whether it gives management the information needed to act. The trap is selecting options that describe comprehensive reporting rather than reporting that is targeted and actionable.

How GOVERNANCE & MANAGEMENT OF IT is tested

At 18%, this domain matches the first in weight and in the style of its questions. Scenarios describe governance or management situations and ask the auditor to assess, conclude, or recommend. The exam is not testing whether you can define governance; it is testing whether you can tell good governance from weak governance when it is described in operational terms.

The most common source of lost marks is conflating governance with management. Governance sets direction and accountability; management executes. When a scenario describes a problem, the exam expects you to locate it correctly in that hierarchy before selecting a response. Choosing a management-level fix for a governance-level failure, or vice versa, is the dominant trap.

Privacy and data governance items reward understanding that these are not purely technical disciplines. The auditor's role is to assess whether the programme is designed appropriately and operating effectively, and items reward that framing over technical detail. Vendor management questions reward focusing on contractual rights and audit access, not on the vendor's internal practices.

After two domains focused on how auditors work and how enterprises are governed, this domain shifts to the system lifecycle. At 12%, it carries less weight than the domains on either side, but it is not safe to under-prepare. The exam tests whether you can audit the process by which systems are acquired, built, and deployed, not just whether you know the phases of a development methodology. Candidates who treat this as a technical domain and ignore the control and governance angles lose marks that are straightforward to recover.

– Acquiring and developing systems: governance, business case, and methodology

Project governance is the first control layer the exam tests in this domain. A project without clear sponsorship, defined scope, and change control is a control failure, and the exam expects the auditor to recognise that. Items will describe a project structure and ask whether governance is adequate; the trap is selecting options that focus on technical delivery quality rather than control and accountability.

Business case and feasibility analysis questions reward understanding that the auditor's role is to assess whether the analysis was rigorous and whether the assumptions are documented and reasonable, not to second-guess the business decision. System development methodology questions test whether the candidate can identify which methodology is in use from a description and what controls are appropriate to it. Agile environments, for example, carry different control considerations than waterfall, and the exam will exploit that difference. Control identification and design questions reward selecting controls that address the specific risk in the scenario, not controls that sound thorough in the abstract.

– Implementing systems: testing, release, migration, and post-implementation review

System readiness and implementation testing is a high-yield sub-topic. The exam tests whether the candidate knows what testing must be completed before a system goes live, who is responsible for each type of testing, and what the auditor should look for in testing documentation. Items reward understanding that user acceptance testing is a business-owned activity, not an IT-owned one, and that the absence of documented test results is itself a finding.

Configuration and release management questions test whether changes to a system are controlled from development through to production. The exam is alert to scenarios where the same person who writes code also promotes it to production; that segregation-of-duties failure is a recurring exam target. System migration and data conversion questions reward understanding the risks of data integrity loss during transition and what controls address them. Post-implementation review questions ask what the review should examine and when it should occur; items reward recognising that the review must assess whether the system delivered the benefits the business case promised.

How INFORMATION SYSTEMS ACQUISITION, DEVELOPMENT & IMPLEMENTATION is tested

At 12%, this domain contributes a smaller but still material portion of the exam. Questions are scenario-based and nearly always describe a project or implementation situation. The demand is to identify the control weakness, recommend the right control, or assess whether the process followed meets an appropriate standard.

The traps here are distinct from the earlier domains. Candidates often focus on the technical correctness of a development decision rather than on the control and governance implications. The exam is not testing software engineering knowledge; it is testing audit judgment applied to a development or implementation context.

Segregation of duties failures in the development pipeline are a consistent source of items, and the exam rewards spotting them even when they are embedded in a scenario that appears to be about something else. Post-implementation review items reward understanding that the review is a formal audit activity with defined objectives, not a casual retrospective. Items in this domain tend to reward the candidate who asks what control was missing or what oversight was absent, rather than what technical step should have been taken.

At 26%, this is the joint-heaviest domain on the exam, and it earns that weight by covering the widest operational surface. Systems in production generate a continuous stream of audit concerns: change management, incident response, capacity, availability, vendor service levels, and the organisation's ability to survive disruption. The breadth is the challenge. Candidates who know business continuity well but are thin on operational topics like log management or job scheduling will feel the gap when a quarter of the paper is drawn from this domain.

– IT components, assets, and automation

IT components questions establish that the auditor understands what is in scope when auditing an operational environment: hardware, software, network infrastructure, and the relationships between them. The exam does not test deep technical knowledge; it tests whether the auditor can assess the control environment around these components.

IT asset management is a control discipline, not an inventory exercise. The exam rewards understanding that unmanaged assets are uncontrolled assets, and that an asset register that is not kept current is itself a finding. Job scheduling and production process automation questions focus on whether automated processes are authorised, monitored, and subject to change control. An automated job that runs without a defined owner or without alerting on failure is a control gap the exam expects you to spot.

– Interfaces, shadow IT, availability, and capacity

System interfaces are a control boundary. The exam tests whether the auditor understands that data passing between systems must be validated, that interface failures can corrupt data integrity, and that the control over an interface must be assigned to a responsible party.

Shadow IT and end-user computing are persistent exam targets because they represent systems and data outside the formal IT control framework. The exam rewards identifying the risks they introduce: uncontrolled data, unsupported applications, and gaps in change management. Systems availability and capacity management questions ask the auditor to assess whether the organisation has defined its availability requirements, whether capacity is monitored against those requirements, and whether there is a process for managing shortfalls before they become incidents.

– Incidents, change, configuration, logs, service levels, and database management

Problem and incident management questions distinguish between an incident (an unplanned interruption) and a problem (the underlying cause). The exam rewards applying the correct process to each. IT change, configuration, and patch management is one of the most heavily tested operational sub-topics. The exam is looking for whether changes are authorised before implementation, tested before deployment, and documented after. Emergency change procedures are a particular trap: the exam expects the auditor to verify that emergency changes are still subject to retrospective approval and documentation.

Operational log management questions reward understanding what logs must be retained, for how long, and who has access to them. Logs that can be modified by the people whose actions they record are not reliable audit evidence. IT service level management questions ask whether SLAs are defined, monitored, and enforced. Database management questions focus on access controls, integrity, and the separation between database administration and application development roles.

– Business resilience: BIA, continuity, backup, and disaster recovery

Business impact analysis is the foundation of everything that follows in the resilience sub-domain. The BIA establishes recovery time objectives and recovery point objectives, and every subsequent continuity and recovery decision must trace back to those figures. The exam rewards candidates who understand that a BCP or DRP that has not been tested against the BIA's objectives is not a reliable control.

System and operational resilience questions ask whether redundancy and failover mechanisms are adequate for the stated availability requirements. Data backup, storage, and restoration questions reward understanding that a backup that has not been tested for restoration is not a backup for audit purposes. Business continuity plan and disaster recovery plan questions are often presented as scenarios where something has gone wrong; items reward identifying the gap in the plan that allowed the failure, rather than describing what a good plan contains in the abstract.

How INFORMATION SYSTEMS OPERATIONS & BUSINESS RESILIENCE is tested

Twenty-six percent means roughly one in four questions comes from this domain. The volume of sub-topics means the exam can probe any corner of operations or resilience, and candidates who have prepared unevenly will encounter unfamiliar territory.

Operational items tend to be scenario-based and procedural: a situation is described and you identify the control failure or the correct auditor response. The trap across most operational items is selecting the option that addresses the symptom rather than the underlying control gap. A missing patch is a symptom; the absence of a patch management process is the finding.

Business resilience items are particularly prone to a specific error: candidates select options that describe a good plan rather than options that identify whether the plan has been tested and validated. The exam rewards the auditor's skepticism about untested controls. Change management items reward strict adherence to the principle that no change, including emergency changes, is exempt from documentation and authorisation. Log management items reward understanding that log integrity is a prerequisite for log usefulness.

This domain shares the top weight with the previous one, and it sits on different ground. Where Domain 4 is about keeping systems running and recovering when they fail, Domain 5 is about keeping them protected and detecting when protection fails. Cybersecurity concepts run through every sub-topic, and the auditor's role is to assess controls, not to implement them. That distinction is easy to lose in a domain this technical, and losing it is where candidates drop marks.

– Security frameworks, physical controls, and identity management

Security frameworks, standards, and guidelines establish the reference point against which the auditor measures an organisation's control environment. The exam expects you to know that the auditor selects an appropriate framework for the context and then assesses conformance; it does not expect you to memorise every control in every framework.

Physical and environmental controls are often treated as background material, but the exam will test them directly. Access to data centres, environmental monitoring, and physical media handling all carry specific control requirements, and a scenario describing a physical control gap expects the auditor to recognise it as such. Identity and access management is one of the most tested sub-topics in this domain. The exam rewards understanding the principle of least privilege, the separation of duties, and the lifecycle of access rights from provisioning through to revocation. Orphaned accounts and excessive privileges are recurring exam targets.

– Network, endpoint, data protection, and cryptography

Network and endpoint security questions ask the auditor to assess whether the control architecture is appropriate for the threat environment and the data being protected. The exam is not testing network engineering; it is testing whether the auditor can read a network design and identify where controls are absent or insufficient.

Data loss prevention questions reward understanding that DLP is a detective and preventive control, and that its effectiveness depends on accurate data classification upstream. Data encryption questions focus on when encryption is required, what it protects against, and critically, what it does not protect against. Encryption does not compensate for weak access controls. Public key infrastructure questions test understanding of certificate authority trust, certificate lifecycle management, and what happens when a certificate is compromised or expired. The exam rewards candidates who understand PKI as a governance and control problem, not a cryptographic one.

– Cloud, virtualisation, mobile, wireless, and IoT

Cloud and virtualised environments introduce shared-responsibility questions that the exam exploits consistently. The auditor must understand which controls the cloud provider owns, which the customer owns, and where the boundary sits. Items reward selecting the option that assigns responsibility correctly for the scenario's cloud model: IaaS, PaaS, and SaaS carry different responsibility splits.

Mobile, wireless, and IoT device questions focus on the control challenges created by devices that operate outside the traditional network perimeter. The exam rewards understanding that these devices expand the attack surface and that the auditor's role is to assess whether the organisation has extended its control framework to cover them. IoT devices in particular often lack the ability to receive security patches, and the exam expects the auditor to identify that as a risk that requires a compensating control.

– Security event management: awareness, attacks, testing, monitoring, response, and forensics

Security awareness training questions reward understanding that training effectiveness must be measured, not assumed. A training programme that is delivered but not assessed for retention is not a reliable control, and the exam will present scenarios that test whether the auditor can make that distinction.

Attack methods and techniques are covered at the level needed to assess controls, not to conduct offensive security. The exam expects you to recognise what an attack vector implies about the control that failed, not to describe the attack in technical detail. Security testing tools and techniques questions ask the auditor to assess whether testing is appropriate for the risk and whether results are acted upon. Security monitoring questions reward understanding that monitoring without a defined response process is incomplete. Incident response management is tested procedurally: items reward the correct sequence of containment, eradication, recovery, and lessons learned. Evidence collection and forensics questions focus on chain of custody and the preservation of evidence integrity, because forensic evidence that cannot be authenticated is inadmissible.

How PROTECTION OF INFORMATION ASSETS is tested

At 26%, this domain demands the same preparation depth as Domain 4 but in a different direction. Items are scenario-based and consistently ask the auditor to assess a control, identify a gap, or determine the appropriate response to a security event. The technical vocabulary is present, but the exam is always testing audit judgment, not technical execution.

The dominant trap is selecting the most technically sophisticated option rather than the one that addresses the audit objective. A sophisticated control that is not aligned with the data classification or the threat model is not a good control for the scenario. Items reward proportionality.

Cloud shared-responsibility items are among the most frequently missed. Candidates assign responsibility to the wrong party because they have not internalised the model for the specific service type described. Forensics items reward chain-of-custody discipline above all else: the exam treats evidence that has not been properly preserved as evidence that cannot be used. Incident response items reward sequencing; acting before containing, or containing before documenting, are the errors the exam is designed to catch.