IT audit preparation: evidence and populations

Who this is for: IT and security managers facing their first external review, or their first in a while: a customer security assessment, an insurer’s questionnaire, an independent attestation engagement, or a certification audit. It is also for the executive who has to sign the management representation and wants to know what is behind it.

What an auditor is actually doing

Auditors do not look for security. They test whether what you say you do is what you do, and whether you can prove it. The unit of work is a control: a stated activity that is supposed to reduce a particular risk. For each control in scope, an auditor typically asks three things.

Is it described? Policy, procedure or standard that says what happens.
Is it designed sensibly? If the control is operated as described, would it address the risk it claims to?
Does it operate? Is there evidence it ran as described, throughout the period under review?

The third question is where most organisations are caught out. The usual testing techniques are inquiry (asking people), observation (watching a process), inspection (reading records and configurations) and re-performance (running the control again to see if the same result appears). Inquiry alone is the weakest, so expect to be asked for records.

Two distinctions matter in practice. Design versus operating effectiveness: a point-in-time review checks whether controls are suitably designed; a review over a period (for example six or twelve months) also checks that they ran repeatedly. And populations versus samples: the auditor will ask for the complete list of something, such as all new starters in the period, and then select a sample from it. If you cannot produce the complete list, you have a problem before sampling begins.

None of this is certification you get from this site. Preparing well makes an external reviewer’s work easier and your own findings fewer; it does not replace the review, and no tool or guide here constitutes an audit or evidence of compliance.

Define the scope before anything else

Audits go wrong from the start when nobody agrees what is being audited. Decide, in writing:

Which systems, locations, teams and processes are in scope, and which are explicitly out.
Which reference framework or customer requirement the review is against. Obtain it from its owner under whatever licence applies; this site does not republish framework text.
The review period, with fixed start and end dates.
The boundary with suppliers: which controls are yours and which sit with a supplier whose assurance you rely on. See vendor risk for how to read that supplier evidence.

Changes to scope mid-engagement cost far more than agreeing it up front.

The policy, procedure, evidence chain

For every control, build three links and check they join up.

Link	Question	Example for user access removal
Statement	What do we say we do?	Policy: leavers’ accounts are disabled by end of last working day
Practice	Who does it, how, with which tool?	Procedure: HR raises a ticket; service desk disables the account and removes group memberships
Evidence	What record proves it happened?	For every leaver in the period: the HR date, the ticket and the directory log showing disablement

A gap in any link is a finding. A policy without a procedure is an aspiration. A procedure without evidence is unprovable. Evidence without a policy suggests the control is accidental.

Build an evidence register

A working evidence register is a list of controls with, for each one, what the evidence is, where it lives, who produces it and how often. A short illustrative extract:

Control	Evidence	Source	Owner	Frequency
Quarterly privileged access review	Dated user export, reviewer sign-off, removal tickets	Directory export; ticketing system	Security lead	Quarterly
Backups restore-tested	Restore test record: date, system, result, who verified	Backup console log; test ticket	IT manager	Quarterly, with an annual full-site test
New starter onboarding	Approval ticket, access granted, training completion	Ticketing; learning system	Service desk	Per joiner
Change approval	Change record with approver and test note, linked to deployment	Change system	Change manager	Per change
Vendor review	Vendor record, report reviewed, contract terms checked	Vendor register	Internal owner	Annual

Fill it in once, then use it as the checklist for gathering evidence each period. The act of filling it in is itself a preparation test: every cell you cannot complete is a gap you have found before an auditor did.

What good evidence looks like

System-generated, not hand-made. An export or log from the system of record beats a screenshot, which beats a typed description.
Dated and attributable. It should show when it was produced and by whom or what. Include the date in the file name.
Complete for the population. The full list, from which a sample can be drawn, not a few hand-picked examples.
Reproducible. Record the query or report used so it can be run again. For example, “all enabled accounts in group X on 2026-09-30, extracted by Get-ADGroupMember with the output saved as group-x-2026-09-30.csv“.
Retained. Evidence from the middle of a twelve-month period needs to still exist at the end of it. Check retention settings on logs and ticketing systems well before the review. A log that rolls over after 90 days cannot evidence a control for a year.

Never create or alter evidence after the fact. Approving a change record retrospectively, backdating a sign-off or editing a log to fill a gap is an integrity problem far worse than the gap itself, and it is how a missing control becomes a credibility problem for the whole engagement. If a control did not operate, say so, explain what you found, and show what you changed.

A preparation timeline you can adapt

The durations below are illustrative; a larger scope needs more time.

Scope and framework confirmed. Agree boundaries and the period in writing.
Control inventory. List the controls you claim, mapped to your policies. Remove claims you cannot support.
Evidence register built and gaps listed. Each gap becomes a task or a register entry.
Fix and run. Where a control was not operating, start it now. Note that for a period-based review a control that started late does not cover the early period.
Dry run. Pick a sample of controls and have someone outside the control’s owner team try to find and verify the evidence from the register alone.
Document the exceptions. Where something did not happen, prepare a plain explanation.
Brief the people. Interviewees should know what will be asked and be honest about how things actually work.
Fieldwork support. One coordinator, a single place for requests and responses, and a log of what was supplied and when.

Handling exceptions and findings

You will have some. A good response states what happened, why, how many items were affected, what you have done and what prevents recurrence. For example: “Four of 52 leavers in the period had accounts disabled one to three working days late because HR notifications were sent after the leaving date. We have changed the process so HR raises the ticket at resignation, and we have added a weekly reconciliation of HR leavers to active accounts.” That reads as control; a defensive answer reads as concealment.

Do not argue about what a control says. If the auditor’s reading of your policy is different from your intention, that is information about your policy.

Do not over-promise remediation. A committed date you miss is worse than a later one you meet.

Security questionnaires and insurer forms

The same discipline applies to customer questionnaires and insurance applications, which are often completed in a hurry by whoever is available. Answer from the evidence register, not memory. If a yes/no question has a partial truth, qualify it. A statement such as “MFA enforced on all remote access” that is true for 90 per cent of users is not accurate, and an inaccurate answer on an application can put the cover itself in question. Keep a copy of every submitted questionnaire; it becomes a standing statement of your controls that you are expected to keep true.

How audit preparation fails

Policy-first, practice-never. A complete policy set and nothing operating.
Last-minute evidence gathering. Finding in the final week that logs were not retained.
Over-scoping. Claiming controls across the whole estate when only part is covered, creating more to test.
Evidence from the wrong population. A hand-picked sample presented as the full list.
Single points of knowledge. One person knows where everything is and is on leave during fieldwork.
Treating the audit as the goal. The objective is controls that work; the audit is a periodic check on that.
Changing systems during the period without updating the control descriptions.

What to do next

Build the evidence register for your five most important controls first, starting with access reviews and restore testing. Where a control cannot yet be evidenced, add it to the risk register as a gap with an owner and a date rather than hoping it will not be asked about. Findings that need senior decisions belong in the board report.