CISA Exam Domains and Current Topic Weights

The current CISA outline has five domains

The CISA exam content outline groups the work of an information systems auditor into five domains. Their published weights total 100 percent. Operations and Business Resilience and Protection of Information Assets each carry the largest share at 26 percent. Auditing Process and Governance and Management each carry 18 percent, while Acquisition, Development and Implementation carries 12 percent.

The outline describes tested responsibilities and tasks, not five isolated school subjects. Real audit scenarios can cross boundaries. A system migration involves acquisition and implementation, operational readiness, information protection, and the auditor's evidence and reporting process. Study each domain's concepts, then practice deciding which issue matters most in a specific scenario.

Domain 1: Information Systems Auditing Process (18%)

This domain covers the audit lifecycle: planning, execution, reporting, and follow-up. Candidates need to understand how to define the audit objective and scope, assess risk, establish criteria, select procedures, and align testing with the question being answered. Audit work should be risk based and connected to the organization's business objectives and relevant requirements.

During execution, the auditor obtains and evaluates evidence. The outline expressly includes audit testing and sampling, evidence collection techniques, audit data analytics, and evaluating whether evidence supports a conclusion. It also includes reporting results, communicating recommendations, and quality assurance. A key distinction is between a control that is well designed and one that operated consistently. Design review alone cannot establish operating effectiveness.

Example: a company says departing employees lose system access on the final workday. To test operation, the auditor needs a complete population of departures and access-removal records with timestamps, then compares the two. A manager's description of the procedure may help understand the control design, but it does not establish that each account was removed on time. This is an evidence question before it becomes a recommendation question.

Domain 2: Governance and Management of IT (18%)

This domain addresses how IT direction, accountability, risk, and resources are governed. Candidates should recognize the role of business alignment, policies and standards, organizational responsibilities, risk management, performance monitoring, and communication between management and oversight bodies. The auditor evaluates whether governance processes provide appropriate direction and oversight; management remains responsible for running the organization and accepting risk.

A governance issue often appears as a gap between strategic expectations and actual decisions. For example, a business has approved a customer-facing cloud service, but no owner is accountable for service risk, supplier performance, or recovery objectives. The auditor should establish the applicable governance criteria and evaluate who has authority, what oversight evidence exists, and whether risks are tracked. The best answer is usually not to assign the auditor the role of service owner.

Study topics include IT strategy and alignment, enterprise governance, organizational structure, policies, risk management, compliance, resource management, and measurement. Pay attention to the difference between governance and operational control. A board or executive forum sets direction and oversight; process owners implement and monitor controls under that direction.

Domain 3: Acquisition, Development and Implementation (12%)

This domain focuses on acquiring or building systems and moving them into production. It includes feasibility and business justification, project governance, system development approaches, requirements, design, testing, configuration, implementation, data conversion, and post-implementation review. The auditor considers whether business needs and risks were translated into controlled delivery and whether the resulting service meets approved requirements.

An implementation can be technically complete while the business outcome remains unverified. Suppose a finance system migration loads transactions successfully but the reconciliation control was not run and users have not approved results. A claim that the migration completed is weaker than evidence that completeness, accuracy, access, and operational readiness criteria were met. The auditor tests against pre-established acceptance criteria; management decides whether to authorize go-live.

Learn how project risk, change control, testing independence, defect handling, conversion, training, and rollback or contingency plans relate. A question may ask what should happen first. If requirements and acceptance criteria are unclear, evaluating final test results may not yet support a reliable conclusion. If those criteria are defined, evidence of test execution and issue resolution becomes central.

Domain 4: Operations and Business Resilience (26%)

This large domain covers day-to-day delivery and the ability to continue or recover services. Topics include IT operations, service management, infrastructure and architecture, asset and configuration management, change and release practices, incident handling, problem management, job scheduling, backups, capacity, and business impact, continuity, and disaster recovery. The auditor connects technical operations to the business service they support.

A recovery test is not successful merely because one component restarted. If a customer service also depends on identity, network connectivity, and a third-party payment gateway, the recovery plan should identify those dependencies and test the service objective. Measure evidence against the approved recovery time and recovery point objectives. A backup log alone does not show that data can be restored and the business can resume.

Operations questions often test sequencing. For a high-risk production change, verify authorization, impact assessment, testing, approval, and deployment records. If an incident has already occurred, preserve relevant records and follow the incident process before making assumptions about root cause. If the question asks whether service continuity is effective, compare actual test outcomes with defined requirements and dependencies.

Domain 5: Protection of Information Assets (26%)

This domain examines security governance and controls that protect information and systems. Its scope includes security policies and roles, identity and access management, logical and physical safeguards, data classification and handling, network and endpoint protections, cryptography, vulnerability and configuration management, monitoring, and security incident response. The auditor evaluates whether controls address the risks and whether evidence demonstrates that they function.

A well-written access policy is not proof that users have appropriate access. The auditor can compare approved access requests with current entitlements, inspect privileged accounts, and test whether access recertification identified and resolved excessive privileges. Likewise, encryption at rest does not establish that every information path is protected; the relevant data flows, key management, transport, storage, and user access need to match the control objective.

Questions may present several plausible safeguards. Choose the control that addresses the stated risk and objective. If the problem is stale privileged accounts, stronger perimeter monitoring may be useful but does not directly remove excessive entitlements. If the issue is detection of unauthorized changes, a policy statement without alert review evidence does not establish effective monitoring.

How to use weights without studying mechanically

Weights are a guide to relative exam coverage, not a promise of an exact count of questions in every individual appointment. ISACA publishes domain percentages; it does not require candidates to pass each domain separately. Use the 26 percent domains to protect substantial study time, but do not ignore the three other domains. A weakness in an 18 percent area can still matter, and a 12 percent domain can contain essential concepts that appear in integrated scenarios.

1. Read the official task statements for each domain and convert them into observable actions you can explain.
2. For each topic, distinguish the objective, the responsible actor, the evidence, and the decision being made.
3. Study the two 26 percent domains in depth while maintaining review time for governance, audit process, and system acquisition.
4. Use mixed practice so that you must identify which domain or task applies instead of seeing a topic label in advance.
5. Track errors by reasoning cause and task statement, then revisit only the underlying concept that needs work.

An integrated example across domains

A health insurer is replacing its claims platform. The new service will be hosted by a supplier, handles sensitive records, and must remain available during peak enrollment. Domain 3 questions concern business justification, requirements, testing, migration, and authorization to launch. Domain 2 concerns ownership, supplier oversight, risk acceptance, and alignment with service objectives. Domain 5 concerns access, encryption, monitoring, and incident handling. Domain 4 concerns capacity, change, backups, and recovery. Domain 1 concerns how the auditor scopes the work, selects evidence, tests controls, and reports the conclusion.

If the prompt asks for the auditor's first step, identify the audit objective, scope, criteria, and risk before choosing a detailed test. If it asks whether data conversion is complete, compare a defined source population with converted records and inspect reconciliations. If it asks whether the service can recover, examine a test that includes the full service and dependencies against the approved recovery objective. The best answer depends on the question's requested decision, even when the same project context spans all five domains.

Use the outline as a boundary

The current outline is the source for the exam's domain structure and weights. A prep article should not imply that every vendor product, framework, regulation, or technology is tested just because it is relevant to IT audit. Learn the task-level ideas and apply them to new settings. For frameworks, know how governance, risk, controls, evidence, and accountability operate; do not spend all study time memorizing a list unrelated to the published tasks.

The five domains provide a map of the CISA role: plan and execute audit work, evaluate how IT is governed, assess systems as they are acquired or changed, understand reliable service operations, and evaluate protection of information assets. Read the official outline alongside practice scenarios and use the weights to set priorities. The aim is a connected understanding that supports sound audit decisions.

Distinguish adjacent domains in a scenario

Some topics overlap because an auditor may evaluate one event from several angles. The useful question is not simply which label fits a technology. Ask what decision the prompt is testing. A failed change can raise a Domain 4 question about change management, a Domain 5 question about unauthorized configuration or access, and a Domain 1 question about what evidence supports the audit finding. A project deployment can be Domain 3 when the focus is acceptance and migration, but Domain 4 when the focus is operating the service after release.

Translate topic labels into audit decisions

A practical way to study the outline is to turn each task into a question you can answer. For Domain 1, can you explain how to obtain sufficient evidence for an audit objective? For Domain 2, can you identify who sets direction, who owns risk, and how oversight is demonstrated? For Domain 3, can you decide what evidence establishes that a system meets requirements before launch? For Domain 4, can you connect operational controls to the service and continuity target? For Domain 5, can you evaluate whether a security control addresses the specific information risk?

Use an example from a different industry than the one in which you work. An auditor with banking experience can practice on a hospital scheduling system; a technology professional can consider a public utility. Changing the context reveals whether you understand the principle or only recognize familiar vocabulary. In each case, identify the business objective, expected control, evidence source, and possible consequence of failure.

A brief self-check across the five domains

1. For an audit conclusion, can you distinguish an interview, a policy, a system record, and a reperformance as evidence for a particular objective?
2. For governance, can you explain how risk acceptance differs from control operation and audit assurance?
3. For implementation, can you describe why acceptance criteria and conversion reconciliation should be defined before interpreting test results?
4. For operations, can you explain why a component restoration does not necessarily meet a service recovery objective?
5. For information protection, can you evaluate whether access approval and monitoring are independent and traceable?

If an answer is vague, return to the relevant task statement and construct a small scenario. State the audit question, the evidence needed, and what conclusion that evidence would allow. This method aligns study to the work described by the outline and supports the judgment tested in multiple-choice scenarios.