How to choose a penetration testing company in Kigali: criteria, questions to ask and red flags

Choosing a penetration testing company in Kigali comes down to three checks: is the testing manual, does the person doing it hold a credential you can verify, and will the report stand up in front of your board and your regulator. Everything else in this guide follows from those three.

Kigali's technology sector has matured quickly. With the growth of innovation hubs such as Norrsken House and kLab, more enterprises in the city are building and shipping digital products at speed. Banks are rolling out mobile banking platforms and fintechs process payments in real time, while SaaS companies serve international clients from engineering teams based in Kigali. Every one of those products adds attack surface that needs testing.

For institutions supervised by the National Bank of Rwanda (BNR), penetration testing is mandatory: BNR requires regular vulnerability assessments and penetration tests as part of each institution's cybersecurity programme. Beyond BNR, companies pursuing ISO 27001 certification or serving enterprise clients in Europe and North America are increasingly required to demonstrate security testing as a condition of doing business. For decision-makers, the harder question is how to tell a manual penetration test from an automated scan sold under the same name.

The sections below take the three criteria in turn, then the questions to ask before you sign and the red flags worth walking away from. For penetration testing in Rwanda more broadly, including scope, costs and BNR requirements, see our complete penetration testing guide for Rwanda.

Criterion one: a real, manual penetration test

The most important distinction for an enterprise evaluating providers in Kigali is the one between a penetration test and a vulnerability scan. Automated vulnerability scanners such as Nessus, Qualys or OpenVAS check systems against databases of known CVEs. They are useful for hygiene but fundamentally limited: they cannot find business logic flaws, authentication bypasses or chained attack paths that require human reasoning.

An effective penetration test simulates a real attacker. The tester begins with reconnaissance: mapping the target environment, understanding the application's business logic and identifying entry points. From there, they attempt exploitation (SQL injection, authentication bypass, privilege escalation, lateral movement across network segments) and, ultimately, data exfiltration or system compromise. The output is evidence of what an attacker could achieve, rather than a list of potential vulnerabilities.

The methodology matters. Look for providers who follow the OWASP Web Security Testing Guide for web applications and the Penetration Testing Execution Standard (PTES) for infrastructure assessments. These frameworks ensure systematic coverage rather than ad hoc poking. A structured approach means the tester covers authentication, authorisation, session management, input validation, cryptography and business logic in a repeatable way.

Manual testing is what separates a pentest from a scan. The tester should spend most of their time interacting with the application by hand, not watching a scanner run. Ask your provider what percentage of the engagement is manual versus automated. If they cannot answer that question clearly, that tells you something.

Criterion two: certifications held by the person who tests

Certifications are the most reliable way to verify a tester's capability before you see their work. They vary widely in rigour, and in penetration testing the gap between the demanding ones and the superficial ones is wide.

OSCP (Offensive Security Certified Professional) is a widely used benchmark of hands-on skill. The OSCP exam is a 24-hour practical test in which the candidate must compromise multiple machines in a live environment. It has no multiple-choice or theory component: the candidate either breaks in or fails. For regulated institutions in Rwanda, BNR Regulation N° 50/2022 names six qualifying certifications for the people who run penetration tests and vulnerability assessments (CISSP, CISM, CISA, CEH, OSCP and LPT) and accepts "any other similar certification". Ask which of them the tester assigned to your engagement holds, and ask for the certification ID so you can verify it.

OSWE (Offensive Security Web Expert) demonstrates deep web application exploitation capability, covering source code review, custom exploit development and advanced injection techniques. For engagements focused on web applications and APIs, OSWE is a strong differentiator. OSCE3 (the successor to OSCE) covers advanced exploit development and evasion techniques. CREST accreditation is the UK and international standard for penetration testing firms and adds a layer of organisational quality assurance.

Credentials measure different things, so check which one the individual tester holds rather than relying on the firm's logo page. Knowledge-based certifications such as CEH (Certified Ethical Hacker, one of the six BNR names) and CompTIA PenTest+ show breadth of knowledge; hands-on exams such as OSCP show the tester has exploited live systems under exam conditions. A sample report is the best evidence of how either translates into your engagement. Conference presentations at events such as BlackHat, DEF CON or regional security conferences are also strong signals, because they show the tester does original research alongside client work.

Criterion three: a report your board and engineers can both use

The penetration test report is the primary deliverable, and its quality determines whether the engagement was worth the investment. A report that your board cannot understand or your development team cannot act on has failed its purpose regardless of how thorough the testing was.

A quality report has two audiences and must serve both. The executive summary is for your board, your CISO and your compliance team. It should run to no more than two or three pages, written in plain language, and cover the overall risk posture, the number and severity of findings, the most critical risks in business terms (not technical jargon) and a clear recommendation on what to prioritise. A board member who reads only the executive summary should understand whether the organisation is in good shape or needs urgent remediation.

The technical findings section is for your development and infrastructure teams. Each finding should include a clear description of the vulnerability, proof-of-concept screenshots or code demonstrating exploitation, a risk rating mapped to business impact (rather than a bare CVSS score with no context) and specific remediation guidance written for your technology stack. Generic advice such as "implement input validation" is not actionable. Good guidance specifies which parameter, which endpoint and what validation logic to apply.

Risk ratings should be contextualised. A SQL injection vulnerability on a public-facing banking application is critical. The same vulnerability on an internal documentation system with no sensitive data is medium at best. The report should reflect this difference, connecting technical severity to your specific business context.

Questions to ask before you sign

Put these to every company on your shortlist, including us, and compare the answers side by side:

• Who will test our systems, and which certification does each tester hold? Ask for names and certification IDs, and verify them.
• How many testers will work on the engagement, and for how many days? The answer shows whether the effort matches the scope.
• What share of the engagement is manual, and what is automated? Expect a specific answer, not "a mix".
• Can you walk us through your methodology step by step, and send it in writing? Look for the OWASP Web Security Testing Guide and PTES, or an equivalent you can read.
• What does your rules of engagement document cover? Scope, timing, communication and escalation should all be in it, signed before testing starts.
• Can we see a redacted sample report? Read the technical findings as well as the executive summary.
• Is a re-test round included, and what does it cover? You want at least one round on the Critical and High findings, ending in a re-test report.
• Who reviews the report before it reaches us, and who will be available for next year's test? Peer review and continuity are what a firm provides that a single contractor cannot.
• For BNR-regulated institutions: is the report ready for the 15-day filing? An executive summary of the findings must reach BNR within 15 days of the test, so the report has to be written for a supervisory reader from the start. Our BNR cybersecurity requirements guide explains the deadline.

Red flags when evaluating providers

Watch for these warning signs when evaluating penetration testing firms in Kigali or elsewhere in East Africa:

• Flat-rate pricing without scoping. A fixed price quoted before anyone has looked at your environment is a guess, because scope determines effort.
• No named testers with verifiable credentials. You should know who will be testing your systems and be able to verify their certifications. If a proposal says "our team is certified" without naming individuals, ask for the names and certification IDs.
• Automated-only testing sold as penetration testing. If the deliverable is a Nessus or Qualys report with a cover page, you paid for a vulnerability scan, not a pentest. Ask to see a sample report before engaging.
• No methodology documentation. Ask for the testing methodology in writing before the engagement begins, so you can see what will and will not be covered.
• Report delivery without a walkthrough meeting. A PDF on its own leaves questions unanswered. A debrief meeting at which the testers walk your technical team through the findings, answer questions and discuss remediation approaches is essential.
• No Rules of Engagement document. Testing should never begin without a signed agreement defining scope, timing, communication protocols and escalation procedures. This protects both parties.
• Unrealistically short timelines. A thorough web application test cannot be done properly in one day. If a provider promises a full pentest in a day or two, the testing will be superficial.

How we can help

IMIZI Cyber is a penetration testing firm based in Kigali. We provide manual penetration testing for banks, fintechs, payment providers, telecoms, government bodies, healthcare providers and technology companies across Africa. Our engagements follow OWASP and PTES methodologies, the testers on each engagement are named in the report, our findings are structured for both board presentation and developer remediation, and every engagement includes one re-test round (every Critical and High finding, plus any Medium fixed by the re-test date) followed by a closure letter.

For full details on our testing methodology, scope options and deliverables, see our penetration testing service page. For the wider picture (scope, cost and what BNR requires), read our complete guide to penetration testing in Rwanda. If you are evaluating the difference between a vulnerability scan and a penetration test, our guide on penetration testing vs vulnerability scanning covers the distinction in detail.

Contact us to scope your next engagement. We send a fixed-price proposal within 48 hours of the scoping call.