CISA Domain 1 — The Information Systems Auditing Process — Examines how you execute an audit, gather evidence, and document what you find. This is the core of what an IT auditor actually does: you leave your desk, go look at systems, collect proof that controls work (or don't), and write up a file that would hold up in court or under regulatory scrutiny. Without a solid approach to execution, evidence, and documentation, your entire audit is worthless.
Jump to a section
A simple way to picture Audit Execution, Evidence, and Documentation
A home inspector is the person who walks through a house someone wants to buy, checks the wiring, looks under the sinks, tests the smoke alarms, and writes up a detailed report. They don't fix anything themselves — they observe, test, and note what's working and what isn't.
Your audit of the company's IT systems works exactly the same way. First, the inspector plans the route: which rooms to check, which tools to bring. That's audit planning. Next, they walk through and test: they flip switches, run the taps, look for cracks, measure moisture. That's audit execution — gathering evidence by testing controls. Every time they find a loose wire or a slow drain, they take a photo and write a note. That's evidence collection. Finally, they write the home inspection report with photos, measurements, and a clear verdict: "this house is sound" or "the roof needs replacing before winter." That's audit documentation.
The whole point is that the buyer — or in an IT audit, the board of directors, the regulators, or the CEO — gets a trustworthy, independent opinion on whether the house is safe and worth the price. The inspector doesn't guess or rely on what the seller claims. They have proof: the photos, the meter readings, the dated notes. In an IT audit, your evidence is the audit trail — logs, screenshots, signed documents, configuration files. Without it, your opinion is just talk.
Audit execution, evidence, and documentation are the three practical activities that turn an audit plan into a finished engagement. They are the "doing" part of auditing, after the planning and before the reporting.
First, what is an audit? An audit is a systematic, independent examination of information, systems, and processes to determine whether they meet certain criteria — typically internal policies, industry standards, or legal regulations. The auditor's job is to form an opinion and back it up with objective evidence.
Audit execution means carrying out the procedures you planned. You don't just sit in a meeting; you physically (or virtually) inspect systems. For an IT auditor, this often includes interviewing staff, reviewing configuration files, running automated scanning tools, observing operations, and testing controls. A control is any policy, procedure, or technical measure designed to protect information or ensure accurate processing. For example, a password policy requiring 12-character passwords is a control. The auditor executes by checking whether users actually follow that policy — perhaps by reviewing system logs that show password lengths.
During execution, you collect evidence. Evidence is any information that supports your audit findings. It must be sufficient (enough to convince a reasonable person), reliable (from a trustworthy source), relevant (directly related to what you're testing), and useful (it actually helps you form a conclusion). Evidence comes in many forms:
Physical evidence: printed reports, signed authorisation forms, hardware inventories
Documentary evidence: policies, procedures, contracts, system logs
Testimonial evidence: interviews with staff, management, or third parties
Analytical evidence: data analysis results, trend reports, calculations
You must preserve evidence carefully. If evidence is lost, altered, or not properly labelled, it may become inadmissible or unconvincing. That's why auditors use evidence indexes, sign-off sheets, and secure storage.
Documentation is the written record of everything you did, saw, and concluded. It includes workpapers — the detailed notes, checklists, and forms you fill out during the audit. Documentation must be clear, complete, and organised so that another auditor (or a regulator) can follow your logic and verify your conclusions. Good documentation answers the question: "What did you do, why did you do it, what did you find, and what did you conclude?"
Why does this all matter? Because without proper execution, you might miss critical weaknesses. Without reliable evidence, your findings are just opinions. Without thorough documentation, no one can trust your work or reproduce it. Every failed audit I've seen traces back to sloppy execution, weak evidence, or messy documentation.
Think of it as a three-legged stool. If one leg is weak, the whole audit collapses.
Plan the evidence collection approach
Before collecting anything, decide what evidence you need, from what sources, and in what format. This prevents you from realising mid-audit that you missed a critical log or document. You also decide which sampling method to use (statistical or non-statistical) based on the population size and risk.
Execute audit procedures and gather evidence
Now you do the actual work: interview staff, run queries, review configurations, observe processes, and collect printouts or screenshots. Each piece of evidence must be labelled with a unique identifier, date, and source. This is the busiest phase and the one most likely to produce surprises.
Evaluate evidence for sufficiency and reliability
After collecting evidence, you assess whether it is enough to support your conclusions. If a control appears weak but you only tested one transaction, you need more evidence. You also check that the evidence is reliable — for example, by verifying that a log file hasn't been tampered with. If evidence is insufficient, you go back and collect more.
Document findings in workpapers
You transfer your evidence and observations into formal workpapers. Each workpaper should contain the control objective, the procedures performed, the evidence obtained (with cross-references to your evidence index), your findings, and your conclusion. You sign and date each workpaper. This step is where the audit becomes a permanent, defensible record.
Review workpapers for completeness and accuracy
Before the audit report is drafted, a supervisor or peer reviewer checks the workpapers. They ask: Is every finding supported by evidence? Are the procedures described clearly? Are cross-references correct? If the reviewer finds gaps, the auditor must go back and fix them. This step ensures the audit meets professional standards.
Store workpapers securely and assign retention period
Finalised workpapers are stored in a secure, read-only repository — either physical or electronic. You assign a retention period (usually 5-7 years) and document who can access them. This protects the evidence from alteration or loss and ensures it will be available if challenged in the future.
Let's say you're the IT auditor at a mid-sized company that processes credit card payments. The company must comply with PCI DSS — the Payment Card Industry Data Security Standard, a set of rules to protect cardholder data. You've been assigned to audit the company's firewall configuration.
Your audit execution begins. You request a current copy of the firewall rule base from the network team. Then you schedule a walk-through with the network administrator. During the walk-through, you ask: "Who approves new firewall rules?" and "How often do you review existing rules for unused or risky entries?" You take notes on the answers. That's testimonial evidence.
Next, you examine the actual firewall configuration file. You look for rules that allow any-to-any traffic — that's a red flag because it means anyone can reach any server, which violates the principle of least privilege. You find three such rules. You take a screenshot showing the rule numbers and the source/destination IPs. You label that screenshot "Firewall_Rule_Review_2025-03-12_Exhibit1.png" and save it in your evidence folder. That's documentary evidence.
You also run an automated vulnerability scanner against the firewall itself to see if it has any known security weaknesses. The scan returns two medium-severity findings. You print the scan report, highlight the two findings, and initial and date the printout. That's physical evidence.
Now, documentation. You create a workpaper called "PCI DSS Firewall Audit Workpaper." In it, you list:
The control objective: "Firewall rules restrict traffic to only what is necessary for business operations."
The procedures performed: reviewed rule base, interviewed admin, ran vulnerability scan.
The evidence gathered: screenshot, scan report, interview notes.
The findings: three any-to-any rules exist, two medium vulnerabilities unpatched.
Your conclusion: the control is partially effective; three exceptions require remediation.
You attach the evidence to the workpaper and cross-reference it. You sign and date the workpaper. Then you store everything in a secure, read-only audit repository.
Later, when the audit committee asks why you flagged those firewall rules, you can produce the workpaper and evidence in minutes. The documentation proves you did the work, collected reliable evidence, and reached a defensible conclusion. Without it, the network team could claim you never asked, or that the rules were temporary. Your documentation protects you and the audit's credibility.
The CISA exam tests audit execution, evidence, and documentation heavily. Expect at least 8-12 questions on this topic across both the core domains and the scenario-based questions. Here is what the exam specifically focuses on:
Types of evidence: You must know the four categories (physical, documentary, testimonial, analytical) and which is strongest in a given scenario. The exam loves to ask: "Which type of evidence is most reliable?" The answer is almost always documentary evidence — especially original documents under the auditor's direct control — because it is less subject to interpretation or memory failure than testimonial evidence.
Evidence characteristics: Sufficiency, reliability, relevance, and usefulness are the four criteria. A common trap question asks: "Which is the most important characteristic?" There is no single 'most important'; they all matter. But the exam will present scenarios where evidence is abundant but not reliable (e.g., a manager's verbal assurance vs. a system log). The correct answer is the one that provides reliable evidence.
Workpaper standards: Workpapers must be clear, complete, organised, and cross-referenced. They must include the audit objective, procedures performed, evidence obtained, findings, conclusions, and the auditor's signature and date. The exam will ask about retention periods (typically 5-7 years, or per regulatory requirement) and who owns the workpapers (the audit function, not the auditee).
Sampling: When you cannot test every transaction (which is almost always), you use audit sampling. The exam tests your understanding of statistical vs. non-statistical sampling, attribute sampling (for testing controls), and variable sampling (for testing monetary values). A common question: "When should you use statistical sampling?" Answer: when you need to project results to the entire population.
Audit evidence traps:
Do not accept evidence that the auditee prepared specifically for the audit without verifying it against original sources.
Oral evidence alone is insufficient unless corroborated by other evidence.
Evidence from a single source is less reliable than evidence from multiple independent sources.
Evidence obtained by the auditor directly (e.g., running a query yourself) is more reliable than evidence provided by the auditee.
Documentation traps:
The exam tests that documentation must be prepared concurrently with the audit, not after the fact.
Workpapers must be reviewed by a supervisor before the audit report is issued.
Workpapers are confidential and should not be shared with the auditee without approval.
Key definitions to memorise:
Workpaper: a record of audit procedures performed, evidence obtained, and conclusions reached.
Audit trail: a sequence of records that shows the history of a transaction or event.
Control risk: the risk that a material misstatement will not be prevented or detected by internal controls.
Detection risk: the risk that the auditor's procedures will not detect a material misstatement.
Substantive testing: testing the actual amounts or details of transactions, not just the controls.
Compliance testing: testing whether controls are operating as designed.
Exam question pattern: The scenario will describe an auditor who relied on a single source of evidence, or who documented findings a week after the audit visit. The correct answer will point out the reliability issue or the documentation timing issue. Always look for the option that emphasises direct, contemporaneous, objective evidence.
Evidence must be sufficient, reliable, relevant, and useful — quantity never compensates for poor quality.
Documentation (workpapers) must be prepared concurrently with the audit, not reconstructed from memory afterward.
The auditor owns the workpapers; the auditee owns the original data — never mix up these ownership rights.
Directly obtained evidence (e.g., system logs the auditor runs) is more reliable than evidence provided by the auditee.
You must document the audit objective, procedures performed, evidence obtained, findings, conclusions, and your signature and date.
Audit evidence falls into four categories: physical, documentary, testimonial, and analytical — know which is strongest in each scenario.
Statistical sampling allows you to project results to the entire population; non-statistical sampling does not.
Workpapers must be retained for a defined period (typically 5-7 years) to support the audit report.
Failure to document properly can lead to audit failure — even if the controls were actually fine.
These come up on the exam all the time. Here's how to tell them apart.
Compliance Testing
Tests whether controls are operating as designed
Focuses on process and procedure
Example: checking that approval forms are signed before purchases
Substantive Testing
Tests the actual accuracy of transactions or balances
Focuses on outcomes and amounts
Example: checking that a specific purchase amount matches the invoice and bank statement
Statistical Sampling
Uses probability theory and random selection
Allows projection of results to the entire population
Requires larger sample sizes for high confidence
Non-Statistical Sampling
Uses auditor judgment and non-random selection
Cannot project results to the population
Faster and cheaper but less defensible
Workpaper (Documentation)
Detailed record of procedures, evidence, and conclusions
Internal document, not shared with auditee without approval
Retained for years as evidence of the audit work
Audit Report
Summary of findings, opinions, and recommendations
External document shared with management and board
Issued at the end of the audit and acted upon by stakeholders
Direct Evidence
Obtained directly by the auditor (e.g., system query result)
Higher reliability because no third-party filtering
Example: auditor runs SQL query against the database
Indirect Evidence
Provided by the auditee or a third party (e.g., management report)
Lower reliability because it may be incomplete or altered
Example: auditee prints a database report for the auditor
Mistake
If I have a lot of evidence, my audit is automatically good.
Correct
The quality of evidence matters far more than the quantity. A single system-generated log file is more valuable than a hundred pages of printed interview transcripts. You need sufficient evidence, but it must also be reliable and relevant.
Beginners often think more is better because they don't yet understand the concept of evidence reliability. They collect everything, which makes the workpaper messy and harder to review.
Mistake
Once I've written my audit report, I can throw away my workpapers.
Correct
Workpapers must be retained for a defined period (typically 5-7 years, or per regulatory requirements) because they are the underlying support for your report. If someone challenges your findings later, you need to produce the original evidence.
People confuse the report (the final output) with the workpapers (the supporting detail). In their daily life, once a document is final, they discard drafts. But audit standards require retention.
Mistake
The auditee can keep my workpapers because they own the data I looked at.
Correct
Workpapers belong to the audit function, not the auditee. They contain the auditor's confidential analysis, conclusions, and judgments. Sharing them without authorisation compromises independence.
It's a boundary confusion. The auditee owns the systems and data; the auditor owns the interpretation and documentation of that data. Beginners mix up ownership of the original data vs. ownership of the audit record.
Mistake
I should only test controls that I think are weak, because that's where the real problems are.
Correct
Auditors must follow a risk-based approach, but they must also test a representative sample of controls across the whole system. Cherry-picking only weak areas creates bias and can make you miss compensating controls that are working well.
People naturally focus on problems they already suspect. But auditing requires objectivity. You test what you planned, not what your gut tells you.
Mistake
If a control fails during my testing, I should immediately tell the auditee how to fix it.
Correct
The auditor's role is to identify and report control weaknesses, not to design or implement fixes. Giving specific remediation advice can compromise your independence for future audits and create a conflict of interest.
It feels helpful to 'consult' and fix things. But CISA standards distinguish between auditing (independent assurance) and consulting (advisory services). Doing both for the same client reduces objectivity.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Audit evidence is any information used to support the auditor's findings and conclusions. It can be physical (printed reports), documentary (logs, policies, contracts), testimonial (interviews), or analytical (data analysis results).
Label each piece of evidence with a unique identifier, the date you obtained it, and the source. Cross-reference it in your workpaper. Store it securely and in a read-only format to prevent tampering. Workpapers must include the audit objective, procedures, evidence, findings, conclusions, and your signature.
Compliance testing checks whether controls are operating as designed — e.g., testing that passwords really expire after 90 days. Substantive testing checks the actual amounts or details of transactions — e.g., verifying that a specific payment was correctly authorised and recorded.
You need sufficient evidence to convince a reasonable person of your conclusions. The exact amount depends on the risk level, the complexity of the system, and the strength of the controls. A general rule: more evidence is needed for high-risk areas and weak controls.
Yes, but you must verify it against original sources whenever possible. Evidence the auditee hands you directly is less reliable than evidence you collect yourself. Always compare provided evidence with independent records (e.g., system logs) to confirm it hasn't been modified or cherry-picked.
A workpaper is a detailed record of the audit procedures you performed, the evidence you obtained, and the conclusions you reached. It backs up your audit report and must be clear, complete, and organised. Workpapers are confidential and owned by the audit function, not the auditee.
You've finished Audit Execution, Evidence, and Documentation. Continue through the CISA study guide to build a complete picture of the exam.
Done with this chapter?