ISACA CISA: A Hands-On Study Plan

The CISA exam uses five current ISACA domains: Information Systems Auditing Process, Governance and Management of IT, Information Systems Acquisition/Development/Implementation, Information Systems Operations and Business Resilience, and Protection of Information Assets.

A hands-on CISA plan should not attempt to turn auditors into system administrators. The goal is to practice evidence, risk, control objectives, governance, testing, reporting, and follow-up across realistic information-system scenarios.

Week 1: learn to frame an audit objective

Choose one system such as payroll, CRM, cloud infrastructure, or identity management.

Write the business process, major risks, audit objective, scope, criteria, stakeholders, and likely evidence sources.

Avoid beginning with a checklist of controls before you understand what the engagement is trying to conclude.

This is the foundation of risk-based audit planning.

Add materiality and business impact to scope decisions. A technically weak control in a low-risk process may deserve less audit effort than a subtle control gap in a critical financial or regulated system. Risk-based audit planning is about allocating limited assurance work where a failure matters most.

Write one out-of-scope item deliberately and explain why excluding it does not prevent the engagement from meeting its objective. Scope discipline is important because audits can become so broad that evidence quality and deadlines suffer. A clear boundary also makes later findings easier to defend.

Week 2: practice evidence and sampling

Create a fictional population of changes, access reviews, transactions, or backups and decide how you would sample it.

Compare inquiry, observation, inspection, reperformance, system extracts, and data analytics as evidence methods.

Ask whether the evidence is sufficient, reliable, relevant, and independent enough to support the conclusion.

A clean sample does not prove much when the population or selection method is flawed.

Build one example where inquiry conflicts with system evidence. Management says access is reviewed quarterly, but the report shows inactive users still enabled. Decide what additional evidence you need before concluding the control failed. This develops professional skepticism without jumping to conclusions from one contradictory data point.

Create one exception in the sample and decide whether it indicates an isolated error, a broader control weakness, or a need to expand testing. The next audit step depends on risk and evidence, not on an automatic rule that one exception always proves system-wide failure.

Week 3: audit governance and third-party management

Review a mock organization chart, policy set, risk register, vendor contract, and performance dashboard.

Identify unclear accountability, missing oversight, weak service levels, privacy obligations, and risks that management has not assigned.

Practice distinguishing management ownership from audit independence.

Governance questions become easier when you see who has decision rights and who provides assurance.

Review whether the vendor agreement includes security obligations, service levels, incident notification, audit rights, data location, business continuity, subcontractor requirements, and termination support. Then ask what evidence management uses to monitor compliance. Vendor due diligence at procurement is weaker if oversight stops after contract signature.

Review a risk appetite statement and compare it with actual exception approvals. If management repeatedly accepts risks beyond stated tolerance without escalation, the issue may be governance rather than one technical control.

This exercise helps connect board-level policy with operational evidence.

Week 4: follow one project from business case to production

Use a small software or cloud migration project and review business case, requirements, security design, testing, approvals, data migration, release, and post-implementation review.

Ask where segregation of duties, quality assurance, acceptance, and change control should produce evidence.

If Agile or DevOps is used, identify automated controls in the pipeline rather than assuming traditional stage gates must exist.

The audit objective is control effectiveness, not methodology preference.

Include a failed test or rejected release in the mock project. Trace whether the issue is documented, fixed, retested, approved, and reflected in the release decision. Auditors need to see whether quality gates are real controls or ceremonial steps that can be bypassed whenever schedule pressure rises.

Add a data-conversion sample to the project audit. Compare source totals, transformed records, rejected items, reconciliation, and business-owner acceptance. Migration integrity is often where implementation controls become measurable rather than theoretical.

Week 5: audit operations and resilience

Review logging, change management, capacity, incident/problem management, service levels, backups, business impact analysis, and disaster-recovery tests.

Choose one critical service and compare its stated RTO/RPO with backup and recovery evidence.

A plan is not enough; look for test results, exceptions, remediation, and proof that recovery dependencies were considered.

Operations and resilience carry 26% of the current exam, so give this week substantial time.

Add one ransomware scenario and test whether backup isolation, access separation, retention, and restoration evidence support the recovery objective. This distinguishes availability from resilience. A backup that exists but is encrypted by the same compromised identity or cannot be restored in time may not satisfy the business requirement.

Review whether incident, problem, and change records connect. Repeated incidents without problem analysis can reveal weak root-cause management, while emergency changes without follow-up can create hidden configuration risk. Audit operations as a system rather than as separate ticket counts.

Week 6: audit security controls

Review IAM lifecycle, privileged access, network security, encryption, endpoint controls, cloud responsibility, vulnerability management, monitoring, incident response, and forensics readiness.

The auditor should understand the technology well enough to evaluate evidence without becoming the system owner.

Ask whether controls are designed, operating, monitored, and periodically reviewed.

Protection of Information Assets is another 26% domain, making security assurance a major part of the exam.

Use an access-review sample and trace users from HR or business ownership through provisioning, role changes, periodic review, privileged access, and termination. Identity lifecycle is a good CISA exercise because it combines governance, evidence, operations, privacy, and technical access control without requiring the auditor to administer the IAM platform.

Include one cloud SaaS or IaaS service so shared responsibility becomes explicit. Identify which controls the provider operates, which the customer configures, and which evidence the organization receives. An auditor should not report a provider-controlled control as missing merely because it cannot be inspected through the customer console.

Week 7: write findings and management-ready reports

Turn three observed control weaknesses into findings with condition, criteria, risk or impact, cause, and recommendation.

Then rewrite the same findings for executive and technical audiences.

Avoid dramatic language that the evidence does not support and avoid vague recommendations that cannot be owned.

CISA tests professional communication because assurance only creates value when stakeholders understand and act on it.

Ask management to provide a response and target date for each mock finding, then assess whether the response addresses the root cause or only the symptom. Auditors should not negotiate away a risk because remediation is inconvenient, but they should distinguish recommendation from management’s responsibility to accept or treat risk.

Keep CISM, CISSP and AAISM as role boundaries

The CISM certification is the information-security management branch.

The CISSP certification is a broader security-professional path.

The AAISM certification adds AI assurance and security-management adjacency.

CISA remains centered on independent assurance, audit evidence, governance, and control effectiveness.

Security-management or architecture knowledge can help an auditor understand context, but CISA questions often reward independence rather than operational ownership. When an answer asks the auditor to configure the control directly, check whether doing so would impair objectivity. The correct role may be to recommend, observe, test, or follow up instead.

Finish with a full mock audit

The CISA certification provides the credential context for the role.

The ISACA exam inventory can help with internal navigation.

Complete one final case from planning through evidence, control testing, findings, management response, report, and follow-up.

If you can stay in the auditor role—assess, conclude, report, and verify—without taking ownership of the process being audited, the five domains are working together correctly.

Use ISACA’s 18/18/12/26/26 weighting to review the mock case. Make sure operations/resilience and protection of information assets receive the most practice, while the smaller acquisition domain is still covered. End by writing a one-page report that a board member can understand and a technical appendix that an owner can act on.

Close the mock audit with follow-up evidence several weeks later: a revised policy, completed access review, restored backup test, or corrected deployment control. Decide whether the remediation fixes the root cause and whether the finding can be closed.

This final step reinforces that assurance continues after report issuance.

Build a final review matrix with the five CISA domains on one axis and evidence, risk, governance, operations, security, reporting, and follow-up on the other. Fill each cell with one scenario or control example.

This exposes blind spots quickly and keeps the study plan weighted toward assurance judgment rather than technology trivia.

Then write one follow-up note for each unresolved finding that states owner, target date, evidence required for closure, and residual risk if remediation remains incomplete. That last step reinforces the auditor’s responsibility to verify corrective action without taking over management’s control ownership.

Close only when evidence supports the conclusion and the remaining risk is clearly understood.

Verify closure.

• Category: All Certifications Certifications