Preparing Evidence: What Auditors Actually Check

The first time an auditor sends an evidence request, it can read like a demand for everything you have ever done. It is not. An auditor is checking a specific claim: that the controls you say protect customer data were actually running during the period under review. Almost every item on the list exists to answer one question — did this control operate, and can you show it.

Once you see the list through that lens, the panic fades. You are not proving you are a perfect company. You are handing over ordinary records your systems already produce: who has access, what changed, who joined and left, what your logs captured, and which policies your team follows. The work is mostly about finding those records quickly and presenting them cleanly. This piece walks through the evidence auditors request most often, how to organize it, and the avoidable slips that turn a smooth audit into a list of exceptions.

Access is usually the first thing an auditor examines, because it is the control most likely to drift. People change teams, contractors finish projects, and admin rights quietly pile up. The auditor wants two things: a current list of who can reach your systems, and proof that someone with authority reviewed that list and acted on what they found.

A useful access review shows the date it happened, the reviewer, the accounts examined, and the outcome — including the accounts you removed or downgraded. A review that flags nothing, every quarter, reads as a rubber stamp rather than a real check. If you found and fixed a stale account, keep that evidence. It proves the control works, which is the whole point. Pull your reviews from the systems that matter most first: your cloud provider, your identity provider, your production databases, and your code repositories.

When you push a change to production, the auditor wants to see that it went through your process rather than straight from a laptop to live customers. That evidence usually lives in your ticketing and version control tools: a ticket describing the change, a record of who reviewed it, approval before it merged or deployed, and a link between the ticket and the actual code or configuration that shipped.

Auditors rarely read every ticket. They pull a sample, often 25 to 40 changes across the period, and trace each one end to end. So the health of your evidence depends on consistency, not volume. If most changes carry a review and approval but a handful of emergency fixes skipped the process with no follow-up, that gap is exactly what a sample tends to surface. Document your emergency change path in advance, and record the retroactive approval when you use it.

Two moments carry outsized risk: the day someone joins and the day someone leaves. For joiners, the auditor looks for evidence that access was granted based on role and approved by the right person, and often that the new hire completed security training. For leavers, the standard is stricter and the timing matters — access should be revoked promptly, and you need to show it happened.

The cleanest evidence ties each event to a date. An offboarding ticket that shows the departure date next to the access-removal date lets an auditor confirm the gap was short. This is a frequent source of exceptions, usually not because a company failed to remove access, but because it could not prove when. If a former employee's account sat disabled for three weeks before anyone recorded it, the record, not the reality, creates the finding. Capture the timestamps as the events happen.

Logging controls often confuse people, because the evidence is not the logs themselves — it is proof that you collect them, retain them, and respond when something looks wrong. An auditor may ask to see that logging is enabled across key systems, that alerts route to a real person or channel, and that when an alert fired, someone acted on it and closed it out.

The strongest evidence here is a worked example. Show one alert from the period: what triggered it, who picked it up, what they did, and when it resolved. That single trail proves the entire monitoring control operated far better than a screenshot of a dashboard with no follow-through. If you use a security tool that centralizes alerts, its own history is usually enough. Just confirm your retention window covers the full audit period before fieldwork starts.

Policies are the easiest evidence to produce and the easiest to get wrong. The auditor checks that the policies exist, that leadership approved them, that staff acknowledged them, and — the part teams forget — that they match what you actually do. A polished information security policy that requires quarterly access reviews you only run twice a year does not help you. It creates an exception, because your own document says one thing and your evidence says another. Write policies you can live up to, then live up to them.

Vendor reviews follow the same logic applied to the third parties who touch your data. The auditor wants to see that you keep an inventory of your critical vendors and that you assess their security, often by collecting their own audit reports and reviewing them. You do not need a 40-page assessment for every tool. You need evidence that you looked at the vendors that matter, judged the risk, and recorded the decision.

Good evidence badly organized still slows an audit to a crawl. The fix is simple structure. Build one folder per control area — access, change management, onboarding and offboarding, monitoring, policies, vendors — and drop each item where it belongs. Name files so a stranger can tell what they are without opening them: include the system, the control, and the date.

Two habits save the most time. First, label every screenshot with the date it was captured and the system it came from, because an undated screenshot proves nothing about when a control ran. Second, keep a short index that maps each control to the evidence that supports it, so your auditor is not hunting and your team is not answering the same question twice. Collect evidence throughout the period rather than scrambling at the end. A control you can only reconstruct after the fact is a control you cannot really prove operated all year.

Patterns repeat across audits, and nearly all of them are about records rather than security. Undated screenshots top the list — you did the work, but nothing shows when. Timing gaps come next, especially access that was removed but never timestamped, so the delay looks longer than it was. Then there is the policy that overpromises: a document describing a stricter process than you run, which turns your own words into the evidence against you.

The last common slip is treating evidence as a one-time collection at year end. Controls operate all period, so your proof has to span the period too. When you gather evidence continuously and check it against what your policies claim, the audit stops being an interrogation and becomes what it should be: a straightforward review of records you already keep. If you would like a second set of eyes before fieldwork, a readiness review maps your controls to the evidence an auditor will request, so you find the gaps before the auditor does.