The Audit Process: Planning, Fieldwork, and Reporting
ISACA structures the audit process in five phases. Planning: define scope (what systems, processes, and time periods are in scope?), set objectives (what questions will the audit answer?), conduct risk assessment (where is risk highest — focus resources there), develop audit programme (test procedures and sample sizes). Fieldwork: gather evidence through observation (watching processes happen in real time), inquiry (interviewing personnel — corroborate with other evidence), inspection (reviewing documents, logs, configurations), reperformance (independently re-executing a control to verify it works). Reporting: communicate findings to management, classify deficiencies by severity (observation, finding, significant finding, material weakness — material weakness means a control cannot prevent or detect a material misstatement), issue formal report with management responses and remediation commitments. Follow-up: verify that remediation actions were completed.
IS Audit Standards and ISACA Code of Professional Ethics
CISA holders must comply with ISACA's IS Audit Standards, which set minimum requirements for audit work. The Code of Professional Ethics requires: support the implementation of appropriate standards, perform duties with objectivity and due care, serve stakeholders in a lawful and honest manner, maintain confidentiality of information acquired in audits, support professional education, inform appropriate parties of illegal activity discovered, do not engage in conduct that discredits the profession. Auditor independence is the cornerstone of audit credibility. Organisational independence means the audit function reports to the board or audit committee, not to the executives being audited. Individual independence means the auditor has no financial interest in, or personal relationship with, the auditee that would bias judgment.
Control Frameworks: COBIT, ITIL, and ISO 27001
CISA candidates need to understand the major IT governance and control frameworks. COBIT 2019 (Control Objectives for Information and Related Technologies): a governance and management framework published by ISACA itself. It organises IT governance into five domains: Evaluate, Direct, Monitor (governance), and Align, Plan, Organise; Build, Acquire, Implement; Deliver, Service, Support; Monitor, Evaluate, Assess (management). COBIT maps goals from enterprise level down to IT processes and specific control objectives — useful for justifying controls in audit findings. ISO/IEC 27001: international standard for information security management systems (ISMS). Annex A lists 93 controls across four themes. Certification requires documented implementation and third-party audit. ITIL (IT Infrastructure Library): service management framework — focuses on service delivery quality, not security controls per se, but overlaps with change management and availability controls.
IT Risk and Control Assessment
Risk assessment in audit context: identify threats to information assets (confidentiality, integrity, availability), assess likelihood and impact, determine inherent risk (before controls), assess control effectiveness, determine residual risk (after controls). Control types: preventive (stop the error before it happens — access controls, input validation), detective (identify errors that occurred — logs, reconciliations, exception reports), corrective (fix errors identified — backup restoration, patch management). Control testing approaches: test of design (is the control designed to prevent the risk?), test of operating effectiveness (is the control working correctly every time?). Sampling: statistical sampling allows inference to the whole population; non-statistical sampling uses auditor judgment. For high-risk controls, auditors typically require larger samples and may require 100% population testing.
Business Continuity and Disaster Recovery Audit
BC/DR auditing is a major CISA domain. Key audit objectives: Is there a documented BCP/DRP? Has it been tested within the past 12 months? Are RTOs and RPOs defined per system and aligned with business impact analysis? Is the alternate processing site tested and viable? Are backup tapes/snapshots stored offsite and tested for restorability? Audit evidence for BCP: BIA document (identifies critical processes and recovery priorities), test exercise reports (tabletop exercises, simulation exercises, full failover tests), backup logs and restoration test records, vendor contracts for cloud failover capacity. Common findings: BCP exists but has never been tested; recovery time assumptions are not based on actual timed tests; critical systems have no documented RTO; offsite backups are not encrypted.