Audit evidence is documentation or data — logs, screenshots, tickets, configuration exports — that proves whether a control was actually followed, not just that a policy says it should be. This is the core difference between GRC work and simply reading policy documents: an auditor doesn't take "the policy says so" as an answer. They want proof it happened.
Testing a control against evidence
Say a policy requires that terminated employees have their system access revoked within 5 business days. To test that control, you don't reread the policy — you pull the actual offboarding log: the last working day, when the IT ticket to revoke access was opened, and when it was actually closed. Compare the dates. If the gap is longer than 5 business days, the control fails, regardless of what the policy document says should happen.
How a failure becomes a finding
Once a control fails, the next question is severity — usually against a simple rubric like: a few days late is a low-severity finding, a couple of weeks is medium, and well beyond that is high. This is exactly the calculation the Audit Evidence Review Challenge works through with a real (fictional) offboarding log.
Why "the policy exists" isn't enough
Organizations sometimes assume that having a well-written policy is the same as being compliant. It isn't. A policy is a promise; evidence is proof the promise was kept. GRC and audit work exists specifically because those two things drift apart in every organization, usually not from bad intent but from busy teams not following up on every clause.
Who does this work
Internal GRC and Compliance Analysts collect and review evidence on an ongoing basis — not just once a year when an external auditor shows up. Catching a failed control internally, with time to fix it, is a very different outcome than an external auditor finding it first.