IT Audits in Rwanda

What is an IT audit, and who needs it

It’s a structured examination of specific IT controls, such as access management, backups and recovery, change management, licensing, security settings and policies, measured against agreed criteria. Each control is tested, the evidence is documented and the result is rated. It suits banks and microfinance institutions, NGOs reporting to international funders, companies preparing for investment or certification, and boards that want assurance from someone independent of the IT team.

The problem it solves

Boards and funders increasingly ask how IT risks are managed, and “the IT team says it’s fine” isn’t evidence. Meanwhile controls drift: access isn’t reviewed, backups aren’t tested, licences fall out of step with staff numbers. An audit tests what actually happens, against a recognised yardstick, and produces a record that stands up to scrutiny.

Choosing the yardstick

An audit is only as meaningful as its criteria. We agree them at the start:

• CIS Controls, a prioritised set of practical security safeguards, well suited to small and mid-sized organisations.
• NIST Cybersecurity Framework 2.0, for security governance and maturity.
• ISO/IEC 27001:2022, whose Annex A lists 93 information security controls, for organisations working towards certification.
• Regulatory requirements, such as the National Bank of Rwanda’s regulations on cyber security and business continuity for institutions it supervises.
• Funder or contractual conditions, where a donor or client sets specific IT requirements.
• Your own policies, testing whether what’s written is actually done in day-to-day practice.

How controls are tested

Inquiry. Asking the people responsible how the control works.

Inspection. Reviewing records, configurations, logs and reports.

Observation. Watching the control operate, such as a backup restore.

Re-performance. Checking a sample ourselves, such as whether leavers’ accounts were really disabled.

Each finding records the criterion, what we tested, what we found, the risk and a recommendation, and management adds its response and target date. Findings are rated by risk, so the board can see at a glance which matter most, and the next audit starts by checking whether agreed actions were completed.

What the work involves

1. Agree scope and criteria with management and, where relevant, the board or auditor relying on the report.
2. Plan the tests and the evidence needed.
3. Carry out fieldwork: interviews, inspection, observation and sampling.
4. Discuss findings with management for factual accuracy and responses.
5. Issue the report with an overall opinion, findings and the management action plan.
6. Follow up agreed actions at the next audit.

What’s included and what’s not

Typical timelines and what drives cost

A focused audit of a single-site organisation typically takes two to three weeks from planning to report. Cost is driven by the scope and criteria, the number of controls and systems, sites, how readily evidence is available, and whether the report must follow a specific format required by a regulator or funder.

Equipment typically used

Audit work programmes built on the chosen standard, evidence request lists, configuration and access exports, licence portal and device management reports, sampling worksheets, and a findings register that tracks management responses.

Common mistakes we see

Audits with no stated criteria, so findings are opinions. Scopes that don’t match what the board or funder actually needs. Evidence taken on trust without testing. Reports that list findings with no management response. Licence compliance never checked until a vendor asks. And last year’s findings never followed up.