ISACA CISA: Finding the Evidence Behind IT Controls

A payroll provider moves a critical processing system to a new platform. The change appears successful: staff can log in, reports arrive on time and management has approved the project closure. An auditor discovers that privileged accounts were migrated without an owner review and that the team cannot reconstruct who changed payroll rules during the cutover. That gap captures the work of a Certified Information Systems Auditor (CISA). Operational success and control assurance are different claims; the auditor must gather evidence about how systems were governed, built, operated and protected, then communicate what the evidence actually supports.

ISACA structures CISA around five job-practice domains: the information systems auditing process; governance and management of IT; information systems acquisition, development and implementation; information systems operations and business resilience; and protection of information assets. The current published outline dates from August 2024. These domains should not be studied as isolated vocabularies. A single payroll migration creates questions about governance approval, development controls, data conversion, production access, recovery capability and audit evidence. CISA preparation becomes useful when those connections guide an investigation rather than merely supply definitions.

Plan an audit around business exposure

A risk-based audit plan begins with what can go wrong for the enterprise, not with a generic checklist of technologies. Identify the service, its critical transactions, its reliance on vendors and the consequences of incorrect processing or interruption. Payroll accuracy, employee privacy and regulatory timing may matter more than whether every infrastructure setting follows a preferred pattern. Define audit objectives that address those exposures and select criteria against which evidence can be assessed. An objective such as “determine whether payroll change access is controlled” leads to testable questions; “review security” does not.

Consider a provider with payroll, customer support and a sandbox environment. If only production payroll can initiate bank transfers, its authorization and logging merit deeper sampling than the sandbox’s routine configuration changes. But a sandbox that contains copied employee records could still carry significant privacy risk. Planning should account for inherent exposure, previous audit findings, management changes, outsourced processing and known incidents. The audit charter also matters: obtain appropriate authority, protect independence and specify scope limitations before evidence collection creates conflict with the people whose work is under review.

Distinguish control design from operating effectiveness

A control can look excellent on paper and fail every day. Design effectiveness asks whether the control, if operated as intended, would address the stated risk. Operating effectiveness asks whether it actually worked throughout the relevant period. An access review policy may require quarterly manager approval, but an unsigned spreadsheet generated after the audit request proves little about the review process. Conversely, a working automated termination workflow may be poorly described while still generating strong transaction-level evidence. Both design and implementation deserve attention, and findings should identify which failed.

For a sample of departed employees, obtain authoritative departure dates, account disablement events, privileged entitlement history and relevant exceptions. Compare timestamps, not only current account status. If a terminated administrator remained active for a week, determine whether the exception was approved, whether sensitive actions occurred and whether compensating monitoring existed. Do not leap from one delayed disablement to a claim that every control is ineffective. Establish sample selection, time period, population completeness and supporting evidence before assessing how widespread or material the weakness is. security control evaluation requires that discipline.

Collect persuasive and reproducible evidence

Audit evidence has varying reliability. Independently obtained records, original system-generated logs and observed procedures may be more persuasive than unsupported oral explanations, but source integrity and completeness always matter. A screenshot can show a configuration on one day while saying nothing about the previous six months. A management report may be accurate but omit excluded subsidiaries or records that failed processing. Evaluate the source system, permissions, extraction method, time period and possible filtering before relying on an artifact as proof.

Sampling turns an unmanageable population into a defensible conclusion. Select items based on the test objective and population characteristics, document the method and keep enough detail to reproduce the selection. For a change-control test, include emergency fixes and rejected changes rather than examining only successfully completed standard requests. Trace approvals to the exact version deployed. If an automated exception report is central to the audit, verify its query logic and investigate whether the underlying data are complete. A precise conclusion is stronger than an impressive spreadsheet whose lineage nobody can explain.

Audit governance without confusing it with management

Governance determines direction, accountability and acceptable risk; management implements the decisions and supplies performance information. The auditor examines whether technology priorities connect to business goals and whether important decisions reach the proper authority. A board committee need not approve every firewall rule, but it should have visibility into material cyber exposure and major technology investments. Delegations, escalation triggers, risk appetite and reporting lines form part of the evidence. The objective is not to substitute the auditor’s preferences for management’s strategy.

For example, a company centralizes its identity platform to reduce costs but concentrates outage risk. Review who approved the business case, whether dependencies were identified and whether acceptance of residual risk remained within delegated authority. A project delivered on time could still violate a governance requirement if its impact was misrepresented. enterprise governance audits should connect observed control weaknesses with the decision process that made them possible. CISA practitioners should recognize how CRISC risk management and CISM security leadership overlap the audit function without making auditors the owners of remediation decisions.

Follow controls through acquisition and delivery

Systems acquisition and development introduce risks before software reaches production. Trace business requirements into acceptance criteria, architecture decisions, testing, deployment and ongoing support. Evaluate separation of development and production duties, code review, test-data handling, change authorization and third-party dependencies. A purchase contract is not a substitute for due diligence on data retention, resilience or supplier responsibility. For internally developed software, successful functional testing does not establish that authorization, logging and recovery controls were also tested.

Return to the payroll migration. Reconcile source records to the converted target data using totals, counts and exception reports; check that reconciliation covers rejected records and special categories such as retroactive adjustments. Review whether users approved business results before the previous platform was decommissioned. Determine whether emergency fixes had retrospective review and whether deployment records match approved packages. If vendor representatives received temporary privileged access, trace its expiry and monitoring. These procedures illustrate why acquisition audits should follow a transaction or decision end to end rather than inspect isolated documentation folders.

Examine operations, continuity and recoverability

Availability claims are only useful when tied to service needs and tested recovery capability. Analyze incident records, monitoring coverage, job scheduling, backup processes, capacity, batch controls and problem management. Recovery time objectives and recovery point objectives express different constraints: one limits time to restore service; the other limits acceptable data loss. A backup marked successful does not prove that the organization can restore the application, dependencies, encryption keys and the correct business data within the required window. Evidence from a representative recovery exercise matters.

Auditors also evaluate whether incident escalation and post-incident action are consistent with policy. Review an outage whose root cause involved a database configuration change. Did monitoring detect the failure, did responders have authority to roll back and were customers told what they needed to know? Was the corrective action completed or merely scheduled? Do not require every minor incident to be escalated to the board. Apply defined business impact thresholds and verify that significant unresolved risk reached an accountable decision-maker. Operational resilience is about organizational capability, not simply redundant hardware.

Protect information assets through their lifecycle

Information security controls need to follow data from creation to disposal. Classification, ownership, least privilege, encryption, retention, secure transfer and evidence of deletion can all be material. The audit should assess the confidentiality, integrity and availability needs of the information involved, not treat every dataset identically. A customer-support export can become a sensitive record if it contains employee identifiers, even though the support application itself is not the primary payroll system. Asset inventories must also account for cloud stores, backups and vendors.

Test privileged roles, service accounts and third-party access according to what they can actually do. A user whose standard account is restricted but whose automation token can export the entire database remains a meaningful risk. Examine key-management ownership and break-glass use, not merely the presence of encryption. Data deletion requires an understanding of copies, retention obligations and recovery backups. The evaluator must be careful about evidence handling: collecting a full database containing personal records when a masked sample would suffice can create a new risk under the guise of auditing an old one.

Write findings that lead to accountable action

A useful finding explains the condition, the criterion, the underlying cause where established, the consequence and a proportionate recommendation. Distinguish confirmed failure from plausible exposure and avoid claiming that a hypothetical breach actually occurred. Management should be able to see what is wrong, why it matters and what evidence would demonstrate remediation. Auditors must not design a control so specifically that they become responsible for operating it; the action owner should select a practical correction within the business context.

Practice CISA by reviewing miniature evidence packs instead of memorizing terms alone. Give yourself a flawed access review, a migration reconciliation, an incident timeline and a continuity test report. State what conclusion can be supported, identify what evidence is missing and decide how to escalate a material limitation. Then write a short finding for an executive audience without inflating certainty. The qualification rewards disciplined assurance: objective procedures, appropriately skeptical interpretation and findings that help leaders make better decisions while preserving the auditor’s independence.