Preparing for an IT Audit: An Evidence Checklist for Your Team

Published by Horus Consultancy · About our consultancy

Start with the audit scope, assign an owner to each evidence request, and collect records that show how controls operated during the review period. A policy describes an intention; approvals, logs and review records help demonstrate what happened in practice.

This practical checklist is for IT managers, control owners and GRC teams preparing for an IT audit. Adapt it to the agreed criteria, systems and period. It is a preparation guide, not a complete audit program or a guarantee of compliance.

1. Confirm the scope before collecting documents

Agree which business processes, applications, infrastructure, suppliers and locations are included. Record the audit objectives, criteria, review period and key contacts. Ask how evidence should be transferred and whether the auditor needs a complete population before selecting samples.

For example, a review of access management for one finance application needs a different evidence set from an organization-wide cybersecurity assessment. Clarifying this early reduces unnecessary work and limits the disclosure of unrelated data.

2. Build a simple evidence register

Use a register with these fields: request ID, control or requirement, requested evidence, system, review period, owner, due date, secure file location and status. Keep original records intact and clearly identify later explanations or corrections.

An evidence file should make its source and coverage understandable. A screenshot without a date, system name or explanation may need additional context. Do not recreate historical approvals or present a new document as evidence of a past activity.

3. Gather evidence for the controls in scope

Governance and risk

• Approved policies, responsibilities and decision-making arrangements.
• Relevant risk assessments, risk owners and treatment decisions.
• Management reviews and records of accepted exceptions.

User access

• User and privileged-account listings for the relevant systems.
• Joiner, mover and leaver requests with approvals and completion records.
• Periodic access reviews, identified exceptions and follow-up actions.

Change management

• Change requests with risk assessment, testing and approval evidence.
• Deployment records and emergency-change reviews.
• Records showing how incompatible responsibilities are managed.

Operations and resilience

• Backup schedules, execution records and restoration-test results.
• Incident records, escalation decisions and lessons learned.
• Relevant monitoring, patching and vulnerability-remediation records.

Third parties

• A list of suppliers that support the in-scope services.
• Relevant contractual responsibilities and assurance information.
• Supplier reviews and follow-up on material issues.

These are examples, not universal evidence requirements. The auditor determines which records and tests are needed for the agreed engagement.

4. Check coverage and consistency

Confirm that evidence covers the requested period and the relevant population. Compare the documented process with what teams actually do. If a control did not operate, identify the gap honestly and explain any compensating measures rather than collecting unrelated documents.

The IIA’s Global Internal Audit Standards emphasize information that is relevant, reliable and sufficient to support analyses and conclusions. That is a useful reason to focus on evidence quality rather than the number of files. See the Global Internal Audit Standards, Standard 14.1.

5. Protect the evidence

Agree an approved transfer method, access permissions and retention arrangements with the audit team. Share only what is needed. If records contain personal information or commercially sensitive material, agree appropriate handling or redaction before transfer; avoid removing context the auditor needs to evaluate the evidence.

6. Turn gaps into an action plan

For each gap, document the risk, responsible owner, proposed action, target date and evidence that will demonstrate completion. Prioritize according to business impact and dependencies. A completed task is not necessarily an effective control, so define how the improvement will be checked.

For cybersecurity-focused work, NIST’s CSF 2.0 Organizational Profiles provide a way to compare current and target outcomes and plan improvements. A profile supports prioritization; it is not an audit certificate. See NIST’s guide to creating and using Organizational Profiles.

Common preparation questions

How early should we start?

Start when the scope is agreed. The time needed depends on the number of systems, the availability of evidence and any gaps. Controls that must operate over a period cannot be demonstrated simply by writing a policy immediately before the audit.

Is a policy enough to prove a control works?

Usually it addresses only part of the question. The auditor may also need records showing implementation and operation, and may use interviews, observations or testing.

Should we fix every gap before the audit?

Address risks according to priority and keep a transparent record of actions and unresolved issues. Do not conceal an issue or change historical evidence to suggest that a control operated when it did not.

Discuss your audit readiness

Horus Consultancy supports IT GRC and IT audit work for organizations in North America and the Gulf, with a physical base in Canada. Explore our services, read our FAQ, or book a call with Islam Elzayat to discuss your scope and priorities.