Banks and regulated institutions across Africa often ask whether they need a red team assessment or a penetration test. The answer depends on where your institution sits on the security maturity curve. Which one sounds more impressive in a board presentation should not come into it.
Both are legitimate offensive-security services in which skilled professionals try to compromise your systems, but they serve different purposes, and choosing the wrong one wastes money and gives false assurance. This guide explains the differences, when each is appropriate, and how to build a testing programme that matures with your institution.
Penetration testing: finding vulnerabilities
A penetration test is a structured assessment designed to find as many vulnerabilities as possible within a defined scope and timeframe.
Characteristics:
- Defined scope: specific systems, applications or network segments are in scope, and the client and tester agree the boundaries before testing begins
- Time-boxed: typically 1 to 4 weeks of active testing
- Full coverage: the goal is breadth, meaning every vulnerability in the scoped environment
- Known to defenders: the security team usually knows testing is happening, though it may not know exactly when or what
- Deliverable: a detailed report listing every finding with its severity, evidence and remediation guidance
What it answers: "What vulnerabilities exist in our systems, and how could an attacker exploit them?"
A good penetration test covers the OWASP Top 10 for web applications, network-layer attacks, authentication weaknesses, authorisation bypass, business logic flaws and configuration issues. For banks, it should also cover banking-specific attack surfaces such as mobile banking apps, APIs, USSD gateways and mobile money integrations.
For a complete overview of what penetration testing covers in Rwanda, see our penetration testing guide.
Red teaming: testing the entire defence
A red team exercise simulates a realistic adversary trying to achieve specific objectives while actively evading detection.
Characteristics:
- Objective-based: the goal is to achieve defined objectives rather than to find every vulnerability, for example "access the SWIFT payment system", "exfiltrate 10,000 customer records" or "compromise a board member's email"
- Broad scope: the entire organisation is in scope, its people and processes as well as its technology, and physical access, social engineering and technical attacks are all on the table
- Extended timeframe: typically 4 to 8 weeks, sometimes longer
- Covert: the red team operates without the knowledge of the security or IT team (only senior management and a small "white team" know)
- Adversary simulation: the red team uses tactics, techniques and procedures (TTPs) that mirror real-world threat actors relevant to your industry
- Deliverable: a narrative report describing the attack path, what was detected, what was missed, and recommendations for improving detection and response
What it answers: "If a motivated, skilled attacker targeted our institution, could our defences detect and stop them?"
Red teaming tests people and processes as well as technology. A penetration test tells you that your web application has an SQL injection vulnerability. A red team exercise tells you that an attacker could exploit that vulnerability, pivot through three internal systems, reach the core banking database and exfiltrate customer records without your SOC team detecting any of it.
Side-by-side comparison
| Dimension | Penetration test | Red team exercise |
|---|---|---|
| Primary goal | Find vulnerabilities | Test detection and response |
| Scope | Defined systems and apps | Entire organisation |
| Duration | 1 to 4 weeks | 4 to 8 weeks |
| Stealth | Not required | Essential |
| Blue team awareness | Usually informed | Not informed (covert) |
| Attack vectors | Technical (defined scope) | Technical, physical, social |
| Depth vs breadth | Breadth (find everything) | Depth (achieve objectives) |
| Output | Vulnerability list and remediation | Attack narrative and detection gaps |
| Cost | $$ | $$$ to $$$$ |
| Compliance | Supplies the evidence BNR, PCI DSS, ISO 27001 require | Exceeds compliance requirements |
| Prerequisite maturity | Any (start here) | Moderate to high |
The security maturity model
The right testing approach depends on your institution's security maturity. The four levels below are a practical way to place yourself.
Level 1: Foundation (start here)
Where you are: basic security controls in place, little or no prior penetration testing, no dedicated security monitoring.
What you need: a full penetration test to establish your baseline. Find the vulnerabilities, fix them, and build from there.
Testing approach: annual penetration testing covering network, web applications, mobile banking and APIs, with quarterly vulnerability scanning.
Most banks and fintechs across Africa start here, and it is the sensible place to invest first: there is no point hiring a red team to test detection capabilities you do not yet have.
Level 2: Developing
Where you are: you have run at least two penetration tests and remediated the critical and high findings, you have basic security monitoring (security information and event management, or SIEM, with some alerting rules), and your incident response plan exists and has been tested at least once.
What you need: continued penetration testing with a widening scope, plus targeted exercises to start testing your detection capabilities.
Testing approach: annual penetration testing, quarterly vulnerability scanning, and an initial purple team exercise to calibrate your detection.
Level 3: Established
Where you are: penetration test results show a maturing security posture (mostly medium and low findings), you have a functioning SOC or managed detection and response (MDR) service, your incident response plan has been tested several times, and security awareness training is regular.
What you need: red team exercises to test whether your defences hold against a realistic adversary.
Testing approach: annual penetration testing, a red team exercise every 12 to 18 months, quarterly vulnerability scanning, and regular purple team exercises to keep improving detection.
Level 4: Advanced
Where you are: you have a mature security programme and a dedicated threat hunting capability, and you want to test against advanced persistent threat (APT) scenarios relevant to the financial sector.
What you need: advanced red team exercises that simulate specific threat actors (for example, financially motivated groups targeting African banks), assumed-breach scenarios, and supply chain attack simulations.
Very few institutions across Africa are at this level today, but it is where the largest banks should be heading.
Purple teaming: red and blue working together
A purple team exercise brings the red team and the blue team together in a collaborative engagement. It is often the most cost-effective way to improve your security posture.
How it works:
- The red team executes a specific attack technique (for example, spear phishing with a malicious document)
- The blue team monitors its detection tools in real time
- After the technique, both teams discuss whether it was detected, which alerts fired and what was missed
- The blue team tunes its detection rules
- The red team re-executes the technique to verify that detection has improved
- The teams move on to the next technique
Why it works: a traditional red team exercise might reveal that 15 attack techniques went undetected. A purple team exercise reveals the same gaps and fixes most of them during the engagement itself, so you leave with improved detection as well as a report.
Best for: institutions at maturity Level 2 or 3 that want to improve their detection quickly without the full cost and timeframe of a traditional red team exercise.
Common red team objectives for banks
When scoping a red team exercise for a bank, the objectives should reflect realistic adversary goals:
- Access the core banking system and demonstrate the ability to initiate transactions
- Compromise the SWIFT environment or payment switch infrastructure
- Exfiltrate customer personally identifiable information (PII) from the production database
- Gain access to executive email and demonstrate business email compromise capability
- Compromise the mobile banking backend and demonstrate the ability to manipulate customer accounts
- Achieve domain administrator access from an initial phishing email
- Bypass physical security controls to reach the data centre or server room
Each objective tests a different part of your defences and shows specifically where your weakest points are.
Cost comparison
Costs vary with scope and complexity, but these comparisons are realistic:
| Engagement type | Typical duration | Relative cost |
|---|---|---|
| Vulnerability scan (automated) | 1 to 2 days | $ |
| Web application pentest | 1 to 2 weeks | $$ |
| Full-scope pentest (network, web, mobile and API) | 2 to 4 weeks | $$$ |
| Purple team exercise | 2 to 3 weeks | $$$ |
| Full red team exercise | 4 to 8 weeks | $$$$ to $$$$$ |
For pricing guidance on penetration testing in Rwanda, see our penetration testing cost guide.
The more useful question is which option gives you the most security improvement for the money. For most institutions across Africa, the answer is full-scope penetration testing until the critical gaps are closed, then purple teaming to improve detection, and then red teaming to validate the overall defence.
Do not skip the fundamentals. A red team exercise that reveals SQL injection in your web application, default credentials on your admin panels and a flat network tells you the same things a penetration test would have told you at a third of the cost. Red teaming is most valuable when the basics are already solid and you need to test the detection and response layer.
BNR and regulatory context
BNR cybersecurity regulation requires regular vulnerability assessments and penetration testing. It does not explicitly require red team exercises, but BNR expects institutions to have and test incident response capabilities, which is exactly what red teaming validates. Some regulators on the continent now set red-team cadences directly: the Bank of Ghana's 2026 Cyber and Information Security Directive expects red-team exercises at intervals ranging from annually for its largest institutions to every three years for the smallest.
For PCI DSS compliance, Requirement 11.4 mandates penetration testing but does not require red teaming. That said, PCI DSS v4.0 encourages a risk-based approach that may lead mature institutions towards red team exercises as part of their security programme.
Red teaming answers a different question from compliance: whether your institution can withstand a real attack. Compliance sets the floor, and a red team exercise shows how far above it you are.
How we can help
IMIZI Cyber is a Kigali-based firm providing manual penetration testing and red team exercises for banks, fintechs, telecoms, government and healthcare institutions across Africa. Our testing is led by an OSCP- and PNPT-credentialled practitioner and follows recognised methodology, with evidence-led reporting that a board and a regulator can both act on. For most institutions, the right starting point is a full-scope manual penetration test that finds and proves the vulnerabilities to close before any adversary simulation makes sense. For mature programmes with working detection and response, we run objective-based red team exercises of the kind described above. We can help you work out where your institution sits on the maturity curve and choose the testing approach that will improve your security most.
For full details of our testing methodology and deliverables, see our penetration testing service page. For adversary-simulation engagements of the kind described above, see our red team services page. For broader security assessments, see our security assessments service page. Contact us to discuss the right testing approach for your institution.