ISACA CISA Course Notes

Domain 1 (18%) covers the IS auditing process. Start with the audit or assessment objective, then determine scope, risk, applicable standards, the control/object being assessed, the method, and the evidence required. Distinguish formal assessments, broader audits, and less-formal reviews by purpose, rigor, and documentation. Risk-based planning should focus audit effort on the systems, controls, and areas with the greatest exposure. Control assessment methods in the source material are examine, interview, and test. Evidence must be sufficient for the objective and relevant/verifiable. Audit analytics support continuous monitoring of risk, compliance, and change. Reporting should clearly state findings, conclusions, recommendations, and risk, with 'other than satisfied' results explicitly identified. Quality assurance evaluates whether methods, documentation, scope, and stakeholder engagement support a credible result.

• Treating audits, assessments, and reviews as interchangeable.

• Start every audit question with the objective.

Domain 2 (18%) covers governance and management of IT. Evaluate whether IT governance, strategy, policies, architecture, risk management, privacy, data governance, resources, vendors, performance monitoring, and quality activities align with business objectives and organizational risk tolerance. Governance questions often ask who has authority, at what organizational tier decisions are made, and whether monitoring and risk processes support mission/business needs. Architecture affects control selection and inheritance. Enterprise risk management is continuous: risk assessments use current threat and control information, feed organization-level decisions, and are revisited as conditions change. Privacy and information owners provide requirements and input to system owners. Data governance focuses on controlled information flow and appropriate policy filtering. Vendor and resource management should use risk-based evaluation. Monitoring frequency, metrics, and reporting should be driven by risk tolerance and strategic importance, not habit.

• Assuming a control is effective because it exists.

• Ask who owns the decision before choosing an answer.

Domain 3 (12%) covers acquisition, development, and implementation. Evaluate whether project governance, feasibility, methodology, control design, testing, release/configuration management, migration, data conversion, and post-implementation review support business needs and risk objectives. The source emphasizes organizational readiness and management support when evaluating Agile adoption. Waterfall is sequential; Agile is iterative; security must be deliberately integrated into any SDLC. Risk-based architecture, modularity, isolation, least privilege, version control, and continuous integration support secure implementation. Stakeholder involvement should fit the methodology: requirements and UAT are key validation points in Waterfall, while Agile uses frequent feedback. Configuration/release management should protect code, track versions, and align investment decisions to roadmap/value data. Migration and data conversion require controlled procedures and risk-aware design. Post-implementation review compares outcomes and metrics with expectations and confirms continuing sponsor support.

• Assuming Agile automatically fixes governance or delivery problems.

• Methodology questions are really fit-and-governance questions.

Domain 4 (26%) covers IT operations and business resilience. Evaluate whether infrastructure, assets, jobs, interfaces, capacity, incidents, changes, logs, service levels, databases, backups, continuity, and disaster recovery are managed in a controlled and recoverable way. Operations questions often ask whether architecture and monitoring support availability, capacity, and resilience. Incident questions depend on organizational definitions and the impact of disruption; formal incident response is different from ordinary administrative correction. Change, configuration, release, and patch activities need testing, versioning, rollback, and supporting logs. Logging should be redundant, secure, and granular enough for operations and investigations. Service-level evaluation correlates workload symptoms with CPU, memory, storage, network, services, and applications rather than using one metric in isolation. The BIA identifies business impact and recovery priority. Recovery design aligns RTO/RPO, dependencies, backup/restoration order, and validation. The source uses a seven-step contingency-planning sequence: policy, BIA, preventive controls, recovery strategies, plan development, testing/exercises, and maintenance. BCP is broader than ISCP; DRP focuses on IT recovery; ISCP addresses information-system contingency.

• Assuming one logging architecture works for every network.

• Operations questions usually reward root-cause and risk analysis over quick fixes.

Domain 5 (26%) covers protection of information assets. Evaluate whether security frameworks, physical controls, IAM, networks, endpoints, DLP, encryption, PKI, cloud, mobile/IoT, awareness, attack defenses, testing, monitoring, incident response, and forensics reduce risk appropriately. A key source theme is the distinction between common/inherited and system-specific controls, with authorization serving as formal risk acceptance. IAM questions emphasize identity proofing, authenticators, authenticator binding, and MFA. Network-security questions emphasize VPN architecture, gateway placement, and outage effects. DLP/sanitization questions require lifecycle tracking, data classification, controlled areas, media type, outsourcing, and verification. Key-management questions focus on key creation, inventory, use, cryptoperiod, deactivation, revocation, and destruction. Cloud and virtualization questions distinguish containers, virtual networks, and VPNs. Awareness programs should begin with needs assessment, then strategy, plan, materials, delivery, and evaluation. Attack questions focus on root cause, especially session-token security. Monitoring requires appropriate log-source configuration and redundancy. Incident response questions emphasize trigger criteria, impact, analysis, containment, escalation/elevation, and root cause. Forensics questions emphasize preserving evidence integrity, limiting unnecessary collection, defining scope, and isolating systems when appropriate.

• Treating common controls as automatically reliable.

• Security questions are usually risk-and-control questions, not product questions.