ISACA CISA: Auditing Information Systems with Reliable Evidence

The Certified Information Systems Auditor (CISA) credential validates the ability to plan, execute and report on audits of technology governance, controls, delivery and operations. ISACA's current examination spans five domains: information systems auditing; governance and management of IT; acquisition, development and implementation; operations and business resilience; and protection of information assets. Its subject is broader than checking whether a firewall rule exists. An auditor must determine which controls matter to a business objective, obtain dependable evidence, evaluate control design and operating effectiveness, and communicate findings without claiming certainty that the evidence cannot support. Passing the exam alone does not automatically satisfy ISACA's experience and certification requirements.

Build an audit around risks and assertions

A useful audit begins with a clear purpose. “Review cloud security” provides almost no scope; “determine whether production customer records are accessible only to authorized roles and changes are traceable” gives the auditor something testable. Identify business processes, material information, legal obligations, service owners, technology boundaries and possible failure consequences. Use those facts to select control objectives and design tests. A risk-based plan may concentrate on privileged access and data exports rather than spend equal time on every documented procedure. Scope must be agreed, but an auditor must retain independence when management pressures the team to exclude a sensitive area without adequate reason.

Develop an understanding of inherent risk and existing controls before selecting samples. A low-volume application that approves high-value transfers may demand more attention than a busy but informational website. Document assumptions, changes to scope and the reasons particular tests are performed. The plan should identify evidence sources, custodians, timing and the possibility that records could be incomplete or manipulated. Audit work is not simply collecting screenshots; it is creating a defensible chain from business objective to risk, control, test result and conclusion.

Distinguish design from operating effectiveness

Control design asks whether a measure could reasonably prevent or detect the relevant failure if it worked as described. Operating effectiveness asks whether the control actually worked through the period under review. A quarterly access review policy may be well designed yet ineffective if managers approve lists without identifying terminated employees. Review the procedure, then test completed reviews, exceptions, decisions and timely removals. When the control is automated, inspect configuration, changes and logs rather than assuming that a vendor's product description proves correct use.

Evidence quality depends on source and context. A system-generated audit log may be reliable only if time synchronization, retention, access and integrity controls are sound. A spreadsheet exported by the process owner may need reconciliation to the authoritative system. Inquiry alone rarely establishes operation. Use observation, inspection, reperformance or independent data analysis where appropriate. The value of continuous auditing versus monitoring is understanding that management monitors controls to run the service, while internal audit independently evaluates evidence and assurance.

Evaluate governance without becoming the decision maker

CISA includes governance and IT management because technical controls depend on accountable leadership. Determine whether roles are defined, strategy connects to business objectives, performance is evaluated and resources are allocated through controlled decisions. Examine whether important technology risks reach responsible executives and whether management acts on past findings. Governance failures often explain recurring operational incidents: unclear ownership, unrealistic project deadlines or a culture where exceptions are never formally accepted.

Maintain independence. An auditor can advise on control objectives and describe gaps but should avoid becoming the manager who designs and operates the corrective process being audited. If management asks the auditor to choose a cloud provider or approve an access exception, clarify the appropriate ownership. The CGEIT discipline centers on governing enterprise IT decisions; CISA evaluates whether that governance and the supporting controls are appropriate and functioning.

Audit system delivery and change management

Technology projects create risk before applications go live. For a new payments platform, inspect whether business requirements include security, availability, data integrity and auditability. Evaluate approval of architecture, separation of development and production duties, testing evidence, migration reconciliations and the decision to accept unresolved defects. Agile delivery does not remove the need for controlled change; it changes the cadence and evidence sources. Automated CI/CD can provide strong traceability, but only if repository permissions, approvals, pipeline secrets and production access remain protected.

For a deployed service, select changes across ordinary and emergency paths. Confirm requests were authorized, tested proportionately to risk and supported by rollback plans. A change that bypassed approval during an outage should be documented and independently reviewed afterward. When applications rely on third-party APIs or cloud infrastructure, determine which party is responsible for patching, access logging and incident reporting. The auditor should follow the service's actual architecture rather than use an outdated network diagram as its entire source of truth.

Test resilience and operational integrity

Operational audit work spans capacity, monitoring, incident and problem management, backup, recovery and supplier dependencies. Compare recovery time and recovery point objectives with tested capability, not just policy. A backup job reporting “successful” is not evidence that the required application can be restored; test representative data, credentials, dependencies and recovery order. Understand batch scheduling, data transformations and reconciliation controls where financial or regulated processes depend on accurate processing. Material incidents should leave a record of classification, escalation, containment, root cause and corrective action.

Consider an outsourced SaaS platform that processes customer cases. Ask whether the organization can obtain event evidence, export its data, recover from a provider outage and exercise contract rights when security obligations are missed. Evaluate supplier assurance in relation to the customer's own responsibilities, not as a substitute for them. Auditing cloud and SaaS vendors requires connecting provider reports with service-specific risks, audit period, scope and unresolved exceptions.

Test identity and data protection in context

Protection of information assets includes classification, physical and logical access, encryption, key management, security events and incident handling. For privileged access, identify powerful roles, elevation paths, break-glass accounts and service identities. Then test whether permissions are justified and promptly revoked when roles change. A privileged access management tool may be present without protecting shared administrative passwords or API keys. Effective review asks what assets can be altered, what the identity can reach and which independent evidence would reveal misuse.

Data protection needs a lifecycle view. Determine how records are created, classified, transferred, retained, archived and destroyed. Investigate whether backup copies and analytics exports preserve access restrictions and whether deletion controls satisfy business and legal requirements. A vulnerability report can inform risk, but auditors must distinguish missing patches from exploitability and practical business impact. Equally, the absence of recent alerts does not prove monitoring is effective if data sources were never onboarded correctly.

Report findings that management can actually resolve

A strong finding explains the condition observed, the expected criterion, the underlying cause, the resulting business exposure and an actionable recommendation. Avoid assuming that every control deviation is a critical vulnerability. If a sampled review was late, assess the window of exposure and compensating controls. If a material audit log was unavailable, acknowledge the limitation rather than conclude the process operated correctly. Report severity using organizational context and communicate material issues promptly when delay could increase harm.

For example, an audit of a customer identity platform finds that terminated contractors retained active service tokens for weeks. Do not stop at “revocation is required.” Determine why HR offboarding did not reach the token inventory, how tokens were issued and whether activity was monitored. Recommend integration, explicit ownership, token expiry and testing of exception workflows. Assign management responsibility and follow up with evidence that the new control works. This sequence turns audit reporting into accountable improvement while preserving the auditor's independent position.

Design a cloud identity audit that tests the access actually exercised

Suppose a company migrates customer support data into a cloud SaaS platform and supplies auditors with a policy stating that access is reviewed quarterly. That policy establishes intended design; it does not prove effective execution. Obtain the identity inventory, privileged-role assignments, recent joiner and leaver records, authentication configuration and the platform's audit events. Reconcile actual roles with employment and contractual status. Select a sample that includes transfers, emergency grants, terminated contractors and service identities, rather than only ordinary active staff. A review that approves all accounts without identifying the owner or the evidence used may provide little assurance.

For each sampled access event, follow the chain from authorization through provisioning to actual use. If a service account can export thousands of records but has no named owner, evaluate both the missing review and the ability to detect improper exports. If a manager approved a role after it had already been assigned, distinguish the timing failure from the broader risk that the system permits unauthorized access before review. Query logs for privileged changes and test whether retention is sufficient for investigation. When a control is described as automated, inspect its configuration and exception handling rather than accepting a vendor assurance statement alone.

The finding should be proportionate and reproducible: define the requirement, evidence, control deficiency, exposure, root cause and suggested corrective action. Avoid claiming that a breach occurred merely because an exploitable condition exists. Also avoid designing the replacement control so prescriptively that audit assumes management responsibility. The result is an evidence-based opinion about assurance, not a collection of security tips.

Prepare with defensible workpapers

For each of ISACA's five domains, practice writing a concise audit objective, identifying a plausible risk, selecting evidence and explaining the conclusion. Ask whether a test shows design or operation, whether the population is complete and whether the sample supports the claim. Review practical distinctions between compliance, risk acceptance, control ownership and audit independence. CISA preparation should follow ISACA's current examination guide, but questions about the “best next action” are chiefly about judgment: obtain sufficient evidence, identify material risk and avoid usurping management responsibility.