Learn
Audit evidence is records, statements of fact or other information that are relevant to the audit criteria and verifiable. That is the ISO 19011:2018 definition, and its two conditions do most of the work. Relevant means the item answers the specific criterion being tested rather than a neighbouring one. Verifiable means a second person can trace it back to its source. A screenshot with no date, taken by the person who owns the control, can fail both tests at once.
Collecting audit evidence well therefore means five things: indexing every control to the requirement it answers, defining in advance what evidence proves each control, collecting it from the system that generated it rather than from a person's memory of it, storing it with a date and an owner, and reviewing it on a cycle so that it is still current when someone asks. The rest of this article takes each step in turn, names the regulations that give a supervisor the right to ask, and sets out what the auditing standards say about how much is enough.
| Fact | Detail |
|---|---|
| Definition | ISO 19011:2018: records, statements of fact or other information, relevant to the audit criteria and verifiable. |
| The auditor's two tests | ISA 500: sufficiency is the quantity of evidence, appropriateness is its quality, meaning its relevance and its reliability. |
| Who can demand it | GDPR Article 58(1), NIS2 Article 32(2)(g), DORA Article 50(2)(a), your ISO 27001 certification body under clause 9.2, and your SOC 2 auditor for the review period. |
| What makes it reliable | Independent sources, effective controls over internally generated records, direct observation, documentary rather than oral form, originals rather than copies. |
| What makes it current | The cycle the requirement sets: yearly under DORA Articles 6(5), 8(1) and 24(6), at planned intervals under ISO 27001 clause 9.2.1, across the whole review period for a SOC 2 Type 2. |
| What it is not | A policy that promises something. A policy proves the policy exists. The record of the thing happening proves the control. |
What counts as audit evidence?
Auditors group evidence by how it was obtained, and the grouping matters because it predicts how much weight the item will carry. The categories below are the ones auditing standards use, translated into the compliance records a security or GRC team actually holds.
| Type | Examples | Weight |
|---|---|---|
| System-generated records | Access logs, change tickets, backup job results, vulnerability scan output, identity provider exports | Strongest, provided the system's own controls are sound and the export is dated |
| Documents | Approved policies, risk assessments, contracts, board minutes, test reports | Strong for showing a decision was taken; weak on their own for showing a control operates |
| Third-party evidence | A provider's SOC 2 report, a penetration test report, a certificate from an accredited body | Strong, because the source is independent of you |
| Observation and re-performance | The auditor watches a restore, runs the query, or repeats the calculation | Strongest of all, and the reason on-site inspections exist |
| Inquiry | Interviews and written explanations | Weakest alone. Auditing standards treat it as corroborating, not conclusive |
| Screenshots | A capture of a configuration page or a dashboard | Acceptable as a last resort, only with a visible timestamp, the capturing user and the system identified |
ISA 500, the international standard on audit evidence for financial statement audits, states the generalisations that every other assurance discipline borrows: evidence is more reliable when obtained from independent sources outside the entity, internally generated evidence is more reliable when the related controls are effective, evidence obtained directly by the auditor is more reliable than evidence obtained indirectly, evidence in documentary form is more reliable than oral evidence, and original documents are more reliable than copies. Read down that list and you have a ranking of your own evidence sources.
How do you collect audit evidence, step by step?
1. Index every control to the requirement it answers
Evidence with no requirement attached is a file. Evidence attached to a control that is mapped to ISO 27001 Annex A 8.15, NIS2 Article 21(2)(b) and DORA Article 17(2) is proof three times over. Build the index first, because it decides what you need to collect at all. Where several frameworks apply, one control mapped to each of them means one evidence item serves all of them, which is the single largest saving available in this work. Our guide to NIS2 and ISO 27001 shows what that mapping looks like for one common pair.
2. Define the evidence per control before collecting any
For each control, write down four things: what artefact proves it, which system produces that artefact, how often it must be refreshed, and who owns it. A control for access reviews might read: the quarterly review export from the identity provider, showing reviewer, date and every decision, owned by the IT operations lead, refreshed every quarter. That definition is itself evidence that the control was designed, and it stops the collection step becoming an argument about what would be good enough.
3. Collect at the source
Pull the export from the system that did the work. Where a system has an API, automate the pull so that the artefact is generated the same way every time and cannot be edited on the way in. Where it does not, take the export from the system's own reporting function rather than a screen capture. Reserve screenshots for configurations that cannot be exported, and when you take one, capture the URL, the system clock and the logged-in user in the frame.
4. Store it with a date, an owner and a link to the control
An evidence item is a record of a fact at a moment in time, so the moment has to travel with it. Store the collection date, the period the item covers, the person who collected it and the control it proves. Keep the original export rather than a summary of it. If an auditor cannot tell when an item was produced, it fails the verifiable test regardless of what it shows.
5. Review, refresh and retire on a cycle
Evidence ages. A board approval from two years ago proves that the board approved something two years ago. Set the refresh interval from the requirement that drives it, and treat an item past its refresh date as missing, because that is how an auditor will treat it. Retire superseded items rather than deleting them: an auditor testing a period wants the evidence that was current during that period, not the one that replaced it afterwards.
How much audit evidence is enough?
ISA 500 splits the question in two. Sufficiency is the measure of quantity, and it is driven by risk: the higher the risk that a control fails, the more evidence an auditor needs. Appropriateness is the measure of quality, meaning relevance and reliability, and the standard is explicit that more evidence of poor quality does not compensate for its inadequacy. Ten undated screenshots do not add up to one dated export.
The period matters as much as the quantity. A SOC 2 Type 1 report describes controls at a point in time, while a Type 2 tests whether they operated across a review period, so a Type 2 needs evidence spread across that period rather than a snapshot at the end of it. Our guide to SOC 2 Type 1 versus Type 2 covers what that means for the calendar. Under ISO/IEC 27001:2022, clause 9.2.1 requires internal audits at planned intervals, clause 9.2.2 requires the audit programme to define the criteria and scope for each audit and to ensure objectivity and impartiality, and the clause requires documented information to be available as evidence of the implementation of the audit programme and the audit results. DORA fixes the interval in the text: the framework is reviewed at least yearly under Article 6(5), and systems supporting critical or important functions are tested at least yearly under Article 24(6).
Which regulations let someone demand your evidence?
The phrase audit evidence sounds like something that belongs to your auditor. Under EU law it belongs to your supervisor, and the powers are specific.
| Regime | The duty to hold evidence | The power to demand it |
|---|---|---|
| GDPR | Article 5(2): the controller is responsible for, and must be able to demonstrate compliance with, the processing principles. Article 24(1) requires measures to ensure and be able to demonstrate compliance. Article 30 requires a record of processing activities. | Article 58(1): order the controller to provide any information required, carry out data protection audits, obtain access to all personal data and information, and access premises and equipment. |
| NIS2 | Article 21(2): the ten risk-management measures, on an all-hazards approach. | Article 32(2)(g): requests for evidence of implementation of cybersecurity policies, such as the results of security audits by a qualified auditor and the respective underlying evidence. Article 32(3): the authority must state the purpose and specify the information. |
| DORA | Article 6(3): complete and updated information on ICT risk and on the framework, on request. Article 6(5): the framework review report, on request. Article 28(3): the full register of information, on request. | Article 50(2)(a): access to any document or data held in any form that the authority considers relevant, and the right to receive or take a copy of it. |
| ISO/IEC 27001:2022 | Clause 9.2: internal audits at planned intervals, with documented information retained as evidence of the programme and the results. | Your certification body, at the certification and surveillance audits. |
| SOC 2 | The controls you describe in the system description, against the AICPA Trust Services Criteria. | Your service auditor, across the review period for a Type 2. |
Two of those rows deserve emphasis. NIS2 Article 32(2)(g) asks not just for the audit result but for the respective underlying evidence, which means the working papers behind a clean report are in scope. And DORA Article 50(2)(a) is not limited to documents you prepared for compliance: it reaches any data held in any form that the authority considers relevant. Our guides to what to expect in a NIS2 audit and what to expect in a DORA audit set out how each authority uses those powers.
What the other results get wrong
Three errors recur across the pages ranking for this query.
The first is treating screenshots as a primary evidence type. Most guides list them alongside logs and exports as if they carried the same weight. They do not. A screenshot is a copy of a display, produced by a person, with no integrity guarantee, and on the ISA 500 reliability generalisations it sits near the bottom on three counts at once. It has a place, but that place is where no export exists.
The second is equating collected with mapped. A folder of exports is not an evidence base until each item is attached to the control it proves and the requirement that control answers. Automated collection tools are useful precisely because they attach the item to a control at the moment of collection. A tool that collects without mapping has moved the problem, not solved it.
The third is claiming that evidence collection can be fully automated. Board minutes, risk acceptance decisions, training records, supplier due diligence and post-incident reviews are produced by people and have to be collected from them. ISO 27001 Annex A control 5.35, the independent review of information security, and control 5.36, compliance with policies, rules and standards, are both evidenced by judgements rather than by exports. What can be automated is the reminder, the storage and the mapping, which is enough to make the human part small.
Is your evidence base ready?
Fill this in for your own programme. Any row you cannot complete is the row an auditor will find first.
| Question | Your answer | Why it matters |
|---|---|---|
| Is every control mapped to at least one requirement, with an article or clause number? | Unmapped evidence is a file. Mapping is what turns it into proof. | |
| Does every control have a written evidence definition: artefact, source system, refresh interval, owner? | Without it, collection becomes a negotiation about what is good enough. | |
| What share of your evidence comes from a system export rather than a screenshot or an email? | The ISA 500 reliability ranking. Exports are verifiable, captures are not. | |
| How many evidence items are past their refresh date today? | Past its date, an item is missing. That is how the auditor will score it. | |
| Could you produce the underlying evidence behind your last audit report, not just the report? | NIS2 Article 32(2)(g) asks for exactly that. | |
| Could you answer a DORA Article 50(2)(a) request for any relevant data, in the form you hold it? | The power reaches data held in any form, not just the compliance folder. |
If most rows are blank, start with the index rather than the collection. Our SOC 2 readiness checklist and our guide to the 93 ISO 27001 Annex A controls give you two ready-made control lists to map against, and a free compliance check will show which requirements you can already evidence. Our ISO 27001 and SOC 2 workspaces store each item once, attach it to every framework that asks for it, and flag it before it goes stale.
Frequently asked questions
What is the difference between audit evidence and documentation?
Documentation describes what should happen. Evidence records what did happen. A policy is documentation. The access review export showing the policy was followed on a date is evidence. Auditors need both, but they draw conclusions from the second.
Are screenshots acceptable audit evidence?
As a last resort, and only with the timestamp, the system and the capturing user visible. On the ISA 500 reliability generalisations a screenshot is a copy, produced internally, obtained indirectly, so it needs corroboration that an export from the same system would not.
How long should we keep audit evidence?
Long enough to cover every period an auditor or supervisor may test. A SOC 2 Type 2 tests a defined review period, ISO 27001 surveillance runs on the certification cycle, and DORA and NIS2 supervisors can look back at any period the obligation applied. Retire superseded items rather than deleting them.
Can one piece of evidence serve more than one framework?
Yes, and it should. A dated access review export proves an ISO 27001 Annex A control, a NIS2 Article 21(2)(i) measure and a SOC 2 common criterion at once, provided the control is mapped to each of them. Mapping once is what makes multi-framework compliance affordable.
Who owns evidence collection?
The control owner produces it, the compliance function defines and checks it, and internal audit tests it. Keeping those three separate is what DORA Article 6(4) calls the three lines of defence, and it is what makes the evidence credible to an outsider.
Primary sources
The definition of audit evidence is from ISO 19011:2018, Guidelines for auditing management systems. Sufficiency, appropriateness and the reliability generalisations are from ISA 500, Audit Evidence, issued by the IAASB. Internal audit requirements are from ISO/IEC 27001:2022, clause 9.2, and control titles from its Annex A. Regulatory powers are taken from Regulation (EU) 2016/679 (Articles 5, 24, 30 and 58), Directive (EU) 2022/2555 (Articles 21 and 32) and Regulation (EU) 2022/2554 (Articles 6, 24, 28 and 50). Confirm the current text before relying on a specific provision.
