Preparing for an IT audit: what auditors look for
The controls an IT audit usually tests, the evidence auditors ask for, and how to get ready without a last-minute scramble.
IT audits are becoming routine. External auditors look at IT controls because financial figures depend on the systems that produce them. Regulators, clients and partners ask how technology risks are managed. Boards want reassurance that the organisation could recover from an outage or an attack.
An IT audit does not have to be stressful. Most of the work is showing, with evidence, that sensible controls exist and are followed.
What auditors usually test
Access to systems
- Every user has their own account, with no shared logins.
- Access is approved before it is granted and matches the person’s role.
- Administrator rights are limited and reviewed.
- Leavers lose access promptly, ideally on their last day.
- Multi-factor sign-in protects email, finance systems and remote access.
Changes to systems
- Changes to important systems are requested, approved and tested before they go live.
- Developers cannot change live systems without control.
- Emergency changes are recorded and reviewed afterwards.
Backups and continuity
- Backups run automatically and cover the systems and data that matter.
- Restores are tested, not assumed.
- There is a plan for keeping critical work going during an outage.
Operations and security
- Devices are patched and protected.
- Important events are logged, and someone looks at the logs.
- Incidents are recorded and followed up.
Assets and licences
- There is a current list of hardware and software.
- Software is properly licensed.
- Unsupported systems are known and have a plan.
Data protection
- Personal data is mapped, access is limited and retention rules are applied, in line with the Nigeria Data Protection Act.
The evidence auditors ask for
Auditors rely on evidence, not descriptions. Expect requests such as:
- user lists from key systems, with roles and last sign-in dates;
- records of access approvals and removals for a sample of joiners and leavers;
- change requests and approvals for a sample of changes;
- backup reports and the results of a recent test restore;
- policies, with evidence that they are followed;
- asset and licence registers.
If the evidence does not exist, the control is treated as not working, even if it is.
How to prepare
- Agree the scope early. Ask which systems and controls are in scope and which standard is used.
- Collect evidence as you go. Keep approvals, reviews and test results in one place, rather than reconstructing them later.
- Run your own review first. Pull the user lists, check leavers, test a restore. Fix what you find.
- Name an owner for each area, so requests are answered quickly and consistently.
- Be honest about gaps. A known gap with a credible plan is better than a surprise finding.
After the audit
Turn every finding into an action with an owner and a date, and track it to completion. Many organisations ask for a follow-up review a few months later to confirm the fixes worked. Over time, the controls become routine, and audits become a formality rather than a project.