Audit Evidence

Begin with the audit objective

Audit evidence is the information an auditor uses to evaluate a control or make a conclusion. Evidence collection is not a scavenger hunt for screenshots. Start with the audit objective and the risk it addresses. Then decide what condition would support the conclusion, what source could show that condition, and what test would give enough information for the purpose.

CISA Domain 1, Information Systems Auditing Process, explicitly includes audit testing and sampling, evidence collection techniques, audit data analytics, reporting, communication, and quality assurance. ISACA describes the exam as 150 questions across five job practice domains. This explainer focuses on evidence reasoning within Domain 1 and uses a new scenario; it does not reproduce secured CISA questions.

Suppose the objective is to determine whether terminated employees lose access to a finance application promptly under company policy. The control is the process that receives termination notices and disables application access. Evidence might include a population of termination events, identity-management records, application logs, tickets, and interviews with the teams responsible. Before collecting any of them, define the period, systems, population, and meaning of “promptly” from the applicable policy or audit criteria.

Match evidence to the assertion

Ask what each piece of evidence actually demonstrates. A written procedure shows what the organization intends people to do. It does not establish that the process ran. A completed ticket may show that someone recorded a step, but may not prove that access was removed from every relevant system. An interview can explain how a process works, but an auditor should not treat a confident answer as direct evidence of operating performance.

Observation can show a process at a particular time. Reperformance can show whether a control works on the items tested when the auditor independently carries out the relevant step. Inspection of records can support an assertion about documented events. Analytical procedures can identify unusual patterns or exceptions worth investigating. These methods answer different questions, so choose based on the audit objective rather than convenience.

Evidence should be relevant to the period, population, system, and control in scope. If the claim concerns application access, a human-resources status report alone may show that a person left employment, but it does not establish that the application account was disabled. If the test covers only one application, the conclusion should not silently extend to every system in the organization.

Criteria matter just as much as the evidence. The auditor needs a rule, contract term, policy, control objective, or other agreed basis for deciding whether a condition is acceptable. Without criteria, an observation may be accurate but still does not establish a finding. If criteria conflict or are unclear, resolve that issue before presenting a judgment as an audit conclusion.

Reliability depends on how the evidence was produced

Consider who created the evidence, how it was generated, whether it could be changed, and what independent corroboration exists. A system-generated report may be useful, but the auditor should understand the report parameters, source system, completeness, and integrity. A spreadsheet supplied by a process owner may be accurate, yet the auditor should establish how it was assembled and whether items were omitted or altered.

A screenshot is a record of what appeared on a screen at a point in time. By itself, it may not show which account produced the screen, whether the displayed data are complete, or what happened outside the capture. A database query can cover more records, but only if its logic and source data are understood. More technical evidence is not automatically more reliable; the method and boundary still matter.

Use corroboration when a conclusion depends on a material claim. For example, compare a termination population from the HR system to identity records and application logs, then investigate mismatches. Corroboration does not mean collecting multiple copies of the same underlying information. Evidence from sources with different creation paths may provide stronger support when the sources are relevant and their limitations are understood.

Design a test and handle sampling carefully

A test plan should make the selection logic visible. Identify the population, the period, the control frequency, the unit being tested, and the criteria for an exception. If an auditor selects a sample, the sample is a way to learn about a larger population under defined conditions. It is not a guarantee that every untested item is correct.

For the termination scenario, a sample drawn only from tickets marked “complete” would omit cases where the process failed to create a ticket. That selection could make the control appear more effective than it was. A stronger design starts with an independent population of termination events and traces selected items to the account-disablement evidence. The reverse direction can also be useful: start from disabled accounts and determine whether the events were authorized. Each direction tests a different risk.

Define an exception before running the test. If policy requires access removal within a stated time, an account disabled after that period may be an exception even if it is disabled by the audit date. If the policy is vague, the auditor may need to clarify the audit criteria with appropriate stakeholders rather than invent a threshold. Record the basis for selection and the work performed so another reviewer can understand the result.

Sampling method and sample size depend on the objective, population, control, and risk. A small set of deliberately chosen high-risk items can be useful for targeted testing, but it does not automatically support a statistical projection to the whole population. Likewise, a large sample cannot repair a biased or incomplete population. State what the method lets you conclude and what it does not.

Use analytics to find and investigate exceptions

Data analytics can help an auditor compare populations, identify duplicates, find missing events, or locate timing patterns that deserve follow-up. In the example, an analysis could compare termination dates with access-removal timestamps and flag accounts that remain active beyond the policy window. The result is a lead for audit work, not a complete conclusion by itself.

Before relying on an analysis, confirm that the source data cover the period and systems in scope, inspect relevant fields, check for duplicates or null values, and understand any filters or joins. A query can return a precise number from an incomplete dataset. The logic should be documented and, when material, validated against known records or an independent source.

Investigate exceptions rather than deleting them as noise. Some may be explained by approved leave, a delayed notification, or a valid business reason. Others may expose a process failure or an incomplete interface between systems. Record the evidence for the explanation and distinguish a justified exception from a control failure. Do not silently change the criteria after seeing the results.

Keep the test trail reproducible. Record the source file or system, extraction date, filters, fields used, transformation steps, and how a reviewer can trace a result back to the underlying record. Protect sensitive evidence and limit copies. If data were changed to normalize formats or remove duplicates, preserve the logic so another auditor can assess whether that change affected the result.

Work a control evidence scenario

An auditor receives a monthly access-review spreadsheet from a system owner. It lists user accounts and has a manager approval column. The audit objective is to determine whether privileged access is reviewed and inappropriate access is removed. What should the auditor do?

First clarify the control criteria: what counts as privileged access, which systems and period are in scope, who must review it, how often the review occurs, and what happens when a manager identifies excess access. Then evaluate the spreadsheet as evidence. Determine its source, how the account population was generated, whether it includes service and emergency accounts where relevant, and how its completeness can be corroborated.

Next select records using a method aligned to the objective. Trace selected privileged accounts to the review evidence and verify that the reviewer had appropriate responsibility and that identified access changes were completed. Also consider whether the population includes all privileged accounts by reconciling it to a suitable independent source. A signed approval column alone may establish that an approval was recorded; it does not show that the list was complete or the resulting removals occurred.

If the audit finds a discrepancy, preserve the record, establish the facts, and determine whether it meets the pre-defined exception criteria. Ask for an explanation and supporting evidence. Assess whether the issue is isolated or indicates a broader population or process problem. Then communicate the condition, applicable criteria, risk or effect, and supported recommendation through the audit's reporting process.

Why common shortcuts fail

Accepting the spreadsheet because a manager signed it relies on evidence without testing its completeness or operation. Requiring a new tool before understanding the failure prescribes a solution before the cause is known. Expanding the conclusion from one application to the entire environment exceeds the tested scope. The auditor should first establish what the evidence supports and then make the conclusion no broader than the work performed.

Document a conclusion another auditor can follow

A clear workpaper connects the objective, criteria, population, selection, procedures, evidence, exceptions, and conclusion. Include enough detail for a reviewer to understand how the work was performed and why the conclusion follows. Keep the underlying evidence protected according to the engagement's confidentiality, retention, and access requirements.

A finding should distinguish the expected condition from what occurred. Describe the relevant evidence and scope, explain the risk or consequence, and state a recommendation that addresses the cause where the cause is supported. If management disagrees, document the response and resolve factual disagreements before reporting. A recommendation should be practical and tied to the control objective; an auditor should not claim that a particular technology is required unless the criteria or risk analysis support that conclusion.

Reporting and communication are part of Domain 1. An audit conclusion is not made stronger by dramatic wording. If the evidence supports a conclusion only for the tested period or sample, state that boundary. If evidence is insufficient or contradictory, describe the limitation and obtain additional evidence or qualify the conclusion as appropriate to the engagement's standards and methodology.

A compact reasoning checklist

For an exam scenario, move in this order: identify the audit objective; define the criteria and scope; choose evidence that directly addresses the claim; understand how the evidence was created; test population completeness where it matters; select and perform a suitable procedure; investigate exceptions; and write a conclusion that matches the evidence. This sequence is a study aid drawn from the skills named in the CISA outline. It is not a separate ISACA scoring formula.

The GAO Yellow Book provides Government Auditing Standards for specified government audit contexts. GAO's June 2026 FISCAM revision provides a methodology for assessing the design, implementation, and operating effectiveness of information-system controls in accordance with the Yellow Book. These resources are useful technical references, but their scope does not make every CISA audit a government audit or replace the criteria and standards that govern a particular engagement.