Information-systems auditing depends on evidence that supports a defensible conclusion about a control, process, or risk. The auditor is not collecting documents merely to fill a workpaper. Evidence has to be relevant to the audit objective, reliable enough for the conclusion being drawn, and sufficient in quantity or coverage to reduce uncertainty to an acceptable level. Sampling and professional judgment sit at the center of that process because auditors rarely have unlimited time or a perfect data set.
The current CISA exam content outline places audit testing and sampling methodology, evidence collection techniques, audit data analytics, reporting, and quality assurance directly in Domain 1. The broader ISACA certifications connects those activities to governance, information-security management, and enterprise risk. Good audit work is therefore less about memorizing a sampling formula than about matching the evidence approach to the control objective and explaining why the resulting conclusion is reasonable.
Begin with the audit objective and the assertion being tested
Evidence is meaningful only in relation to a question. “Review user access” is too vague to guide testing. A stronger objective might be to determine whether privileged access is approved, limited to authorized administrators, reviewed periodically, and removed promptly when no longer required. Each part implies a different assertion and potentially a different evidence source.
The auditor should define what would constitute a control failure before selecting the sample. If the objective is to test timely termination, the population should include terminated or transferred users and the relevant removal dates. Sampling active employees would not answer the question even if the sample were statistically sound. The population has to represent the condition being tested.
Control design and operating effectiveness should also be distinguished. A policy, workflow diagram, or configured approval step can demonstrate that a control is designed, but it may not show that the control operated consistently during the audit period. Operating effectiveness usually requires evidence of actual transactions, reviews, logs, approvals, or system-enforced behavior.
Auditors should document the expected result and the criteria used to evaluate exceptions. Clear criteria reduce the temptation to reinterpret a test after inconvenient evidence appears. They also make supervisory review easier because another auditor can understand how the work supports the conclusion.
Clear assertions also prevent scope drift. If the assertion concerns timely termination, testing should focus on termination events and required completion windows rather than expanding into every IAM feature. Precision makes evidence easier to defend and findings easier for management to remediate.
Evaluate evidence for relevance, reliability, and sufficiency
Relevant evidence directly addresses the audit objective. A screenshot of a current firewall rule may be relevant to configuration at one moment, but it does not prove that the rule was effective throughout the year. A change log, configuration history, and approval record may provide stronger period evidence. Relevance depends on the time frame and assertion being tested.
Reliability depends on the source and the possibility of alteration. Evidence generated automatically by a controlled system can be stronger than a manually prepared spreadsheet, but only if the auditor understands the system that produced it. External confirmations can be persuasive because they are independent, while management representations are useful context but normally require corroboration for material conclusions.
Sufficiency is about whether enough evidence has been obtained to support the conclusion. More evidence does not automatically mean better evidence. A thousand records from the wrong population are less useful than a smaller set directly tied to the control objective. Auditors should consider risk, population size, expected exception rate, control frequency, and the consequences of an incorrect conclusion.
The professional perspective associated with CRISC is relevant because evidence effort should respond to risk. High-impact or poorly controlled areas may justify broader testing, additional corroboration, or lower tolerance for exceptions than low-risk administrative processes.
Evidence quality can change during the audit period. A report generated from a system after configuration changes may not represent the period being tested. Auditors should preserve timestamps, extraction logic, and source-system context so later reviewers can understand exactly what the evidence proves.
Choose evidence techniques that fit the control
Common techniques include inspection, observation, inquiry, reperformance, confirmation, and analytical procedures. Each answers different questions. Inspecting a configuration can show what was set; observing a process can show how staff perform it; reperformance can demonstrate whether the control logic produces the expected result; external confirmation can validate information that management supplied.
Inquiry alone is rarely enough for an important control because people may misunderstand, simplify, or describe the intended process rather than the actual one. Inquiry becomes stronger when combined with evidence such as logs, tickets, system settings, or transactions. Likewise, screenshots can be useful, but auditors should know who captured them, when they were captured, and whether the view can be reproduced from the source system.
Evidence obtained through data extraction needs its own validation. If the auditor receives a CSV of all privileged accounts, the auditor should understand the query, source tables, filters, time zone, and whether disabled or nested identities are included. Completeness and accuracy of the population are prerequisites for meaningful sampling.
An auditor can sometimes reduce evidence risk by using more than one technique. For example, a sample of access approvals can be inspected, selected identities can be re-performed against the current role mapping, and system logs can confirm that the approved change occurred. Triangulation is especially valuable when one evidence source is controlled by the same team being audited.
Combining techniques often produces stronger assurance than relying on one method. An auditor can inspect configuration, observe a process, select transactions, and reperform a control. Agreement across independent techniques increases confidence, while contradictions point to areas that need deeper investigation.
Define the population before selecting a sample
Sampling begins with a complete and appropriate population. The auditor should define the unit being sampled, the period covered, inclusion and exclusion criteria, and any subpopulations that have different risk. A list of “changes” may contain emergency changes, routine patches, infrastructure-as-code deployments, and application releases; treating them as one homogeneous population can hide control differences.
Population completeness should be tested independently where possible. Sequence numbers, reconciliation to system totals, record counts by month, or comparison with another source can help determine whether items are missing. If the population is incomplete, increasing the sample size does not fix the problem because omitted items still have no chance of selection.
Auditors should also look for stratification opportunities. High-value transactions, privileged changes, failed controls, or unusual items may warrant 100 percent review while lower-risk routine items are sampled. Stratification focuses effort without pretending that every item has the same significance.
Sampling should preserve traceability. Each selected item should be identifiable back to the population so the auditor can show how it was chosen and so a reviewer can reproduce the selection. Informal choices such as “we picked a few examples that looked representative” are difficult to defend because they can introduce unconscious bias.
Population design should consider completeness at both ends of the process. For example, testing approved changes from a ticketing system may miss production changes that never had tickets. Reconciling deployment logs back to the change population can reveal that kind of hidden exclusion.
Use statistical and judgmental sampling for different purposes
Statistical sampling uses probability-based selection and supports quantification of sampling risk. It can be useful when the auditor wants a defensible estimate about a large, relatively uniform population. Random or systematic selection helps ensure each unit has a known or structured chance of being chosen, and the auditor can relate sample results to confidence or tolerable deviation assumptions.
Judgmental sampling is not automatically inferior. It can be the right approach when the objective is to investigate high-risk, unusual, newly implemented, or material items. An auditor may deliberately select all administrator changes, the largest vendors, or transactions near a control threshold because those items provide more assurance about the risk than a purely random sample.
The key is not to use judgmental results as though they were statistically representative of the whole population. If the sample intentionally focuses on risky items, the auditor should explain the purpose and limit of the conclusion. Transparency about selection logic is more credible than applying statistical language to a nonstatistical method.
Sampling methodology should also consider control frequency. A monthly review produces only twelve instances per year, which may justify testing a large portion of the population. A high-volume automated control may be better tested through configuration, change management, exception logs, and data analytics than by inspecting hundreds of individual transactions.
Sample size should reflect risk, expected deviation, control frequency, and the purpose of the test. A rare privileged action may justify targeted selection, while a high-volume automated control may support a larger statistical sample or full-population analytics. The method should be explainable, not habitual.
Interpret exceptions instead of merely counting them
An exception is evidence that the tested condition did not meet the defined criteria, but not all exceptions have equal significance. A one-day delay in a low-risk review differs from an unauthorized production administrator account. Auditors should evaluate cause, frequency, control objective, compensating controls, and potential impact before deciding what the exception means for the overall conclusion.
Repeated exceptions with the same root cause may indicate a systemic problem even when the raw error rate is low. Conversely, one unusual failure caused by a documented outage may not indicate that the control generally fails. Professional judgment connects the observed evidence to the risk the control was intended to manage.
When a sampled item fails, auditors should consider whether additional testing is needed. Expanding the sample, testing a related control, or reviewing the period around the exception can determine whether the issue is isolated. The response should be risk-based rather than automatic.
Exceptions should also be discussed with process owners without allowing explanations to replace evidence. Management may provide context that changes the interpretation, but the auditor should verify material explanations. A claim that a missing approval existed in another system, for example, should lead to inspection of that record rather than immediate closure.
Exception analysis should separate isolated error from control-design weakness. Auditors can compare exceptions by owner, location, system, time period, and cause. Clustering often reveals whether a finding is local, process-wide, or driven by a specific configuration or training gap.
Use data analytics to complement sampling
Audit data analytics can test full populations for conditions that are easy to express as rules: duplicate payments, privileged accounts without owners, changes outside approved windows, inactive accounts with access, gaps in sequence numbers, or transactions above a threshold. Full-population testing reduces one form of sampling risk and can identify patterns that a small sample would miss.
Analytics does not eliminate judgment. The auditor still has to validate the data source, define the rule, understand false positives, and interpret the result. A query that identifies “accounts not used in 90 days” may not distinguish emergency accounts, machine identities, or seasonal users. Analytics can make testing broader while still requiring domain understanding.
Automated analysis is particularly useful for identifying populations to sample more intelligently. The auditor can review all records for unusual characteristics and then select targeted samples from high-risk clusters while maintaining a random sample for baseline assurance. This combines breadth with detailed inspection.
Examples of audit-readiness problems in environments such as SQL Server sprawl show why inventory quality matters. If systems, instances, owners, or licenses are not known, the evidence population may be incomplete before testing even begins.
Analytics results should be reproducible. Queries, filters, joins, thresholds, and excluded records need enough documentation that another reviewer can rerun the test. Reproducibility is especially important when a finding depends on logic rather than a small set of manually inspected records.
Protect independence, documentation, and review quality
Audit evidence should be documented so an experienced reviewer can understand what was tested, why the item was selected, what evidence was obtained, what result occurred, and how the conclusion followed. Workpapers do not need to reproduce every raw record, but they should contain enough traceability to support the finding and permit re-performance where appropriate.
Independence matters because evidence evaluation can become biased when the auditor designed or operates the control being tested. Where organizational structure creates unavoidable proximity, additional review, independent validation, or disclosure may be needed. Objectivity is not only an ethical concept; it affects the credibility of the evidence assessment.
The management and governance emphasis in CISM also helps explain why findings should be communicated in business terms. Evidence should connect the control failure to risk, impact, and accountability rather than presenting a technical exception without context.
Quality review should challenge whether the population was complete, whether the sample method matched the objective, whether exceptions were handled consistently, and whether the conclusion is stronger than the evidence supports. Good review is designed to catch overconfidence as much as missing paperwork.
Use professional judgment without making it arbitrary
Professional judgment is unavoidable because audits operate under uncertainty. The auditor decides which risks deserve attention, how much evidence is enough, whether an exception is material, whether compensating controls matter, and how strongly to word a conclusion. Judgment becomes credible when it is anchored in standards, defined criteria, evidence, risk, and transparent reasoning.
Experienced auditors also know when not to overstate precision. A sample does not prove that every item in a population is correct, and a clean sample does not erase weaknesses in population completeness or control design. Conclusions should reflect the level of assurance the work actually provides.
The CISA profession is broader than a certification label, but an overview of the Certified Information Systems Auditor role helps place evidence work in context: the auditor connects technical facts to control objectives and enterprise risk. The value lies in the defensible conclusion, not in the volume of artifacts collected.
A strong audit trail therefore tells a coherent story from objective to population, method, evidence, exception analysis, and conclusion. Sampling is one tool in that story, and judgment is the discipline that keeps the tool aligned with the risk being assessed.