“Should we get a red team assessment or a penetration test?” This is one of the most common questions we hear from banks across East Africa. The answer depends on where your institution sits on the security maturity curve, not on which sounds more impressive in a board presentation.
Both are legitimate offensive security services. Both involve skilled professionals attempting to compromise your systems. But they serve fundamentally 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. The client and tester agree on boundaries before testing begins
- Time-boxed: typically 1 to 4 weeks of active testing
- Comprehensive coverage: the goal is breadth. Find every vulnerability in the scoped environment
- Known to defenders: the security team usually knows testing is happening (though they may not know exactly when or what)
- Deliverable: a detailed report listing all findings with 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 like 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 attempting to achieve specific objectives while actively evading detection.
Characteristics:
- Objective-based: the goal is not to find every vulnerability but to achieve defined objectives. Examples: “access the SWIFT payment system,” “exfiltrate 10,000 customer records,” “compromise a board member’s email”
- Broad scope: the entire organisation is in scope, including people, processes, and technology. 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 your people and processes, not just your 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, access 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/apps | Entire organisation |
| Duration | 1-4 weeks | 4-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 + remediation | Attack narrative + detection gaps |
| Cost | $$ | $$$-$$$$ |
| Compliance | Satisfies BNR, PCI DSS, ISO 27001 | 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. Here is how to think about it:
Level 1: Foundation (start here)
Where you are: basic security controls in place, limited or no prior penetration testing, no dedicated security monitoring.
What you need: a comprehensive 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. Vulnerability scanning quarterly.
Most banks and fintechs in East Africa start here. This is not a criticism. It is a practical assessment of where to invest first. There is no point in hiring a red team to test detection capabilities you do not yet have.
Level 2: Developing
Where you are: you have conducted at least two penetration tests, remediated critical and high findings, have basic security monitoring (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 expanding scope, plus targeted exercises to begin testing your detection capabilities.
Testing approach: annual penetration testing, quarterly vulnerability scanning, and an initial purple team exercise to calibrate your detection capabilities.
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, incident response plan has been tested multiple 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 continuously improve detection.
Level 4: Advanced
Where you are: you have a mature security programme, dedicated threat hunting capability, and want to test against advanced persistent threat (APT) scenarios relevant to the financial sector.
What you need: advanced red team exercises simulating specific threat actors (e.g., financially motivated groups targeting East African banks), assumed breach scenarios, and supply chain attack simulations.
Very few institutions in East Africa are at this level today, but it is where the largest banks should be heading.
Purple teaming: the best of both
A purple team exercise combines the red team and blue team 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 (e.g., spear phishing with a malicious document)
- The blue team monitors their detection tools in real time
- After the technique, both teams discuss: was it detected? What alerts fired? What was missed?
- The blue team tunes their detection rules
- The red team re-executes the technique to verify improved detection
- Move 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 that, then fixes most of them during the engagement itself. You leave the engagement with improved detection, not just a report of failures.
Best for: institutions at maturity Level 2 or 3 that want to rapidly improve their detection capabilities 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 banking institution, 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 access the data centre or server room
Each objective tests a different aspect of your defences and provides specific, actionable intelligence about where your weakest points are.
Cost comparison
Costs vary based on scope and complexity, but here are realistic comparisons:
| Engagement type | Typical duration | Relative cost |
|---|---|---|
| Vulnerability scan (automated) | 1-2 days | $ |
| Web application pentest | 1-2 weeks | $$ |
| Comprehensive pentest (network + web + mobile + API) | 2-4 weeks | $$$ |
| Purple team exercise | 2-3 weeks | $$$ |
| Full red team exercise | 4-8 weeks | $$$$-$$$$$ |
For specific pricing guidance on penetration testing in Rwanda, see our penetration testing cost guide.
The key question is not “what can we afford?” but “what will give us the most security improvement per dollar?” For most institutions in East Africa, the answer is comprehensive penetration testing until critical gaps are closed, followed by 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 your web application has SQL injection, your admin panels use default credentials, and your network is flat tells you the same things a penetration test would have told you at one-third 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. However, BNR expects institutions to have and test incident response capabilities, which is exactly what red teaming validates.
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 toward red team exercises as part of their security programme.
Red teaming is not about compliance. It is about knowing whether your institution can withstand a real attack. Compliance is the floor. Red teaming tests whether you are above it.
How we can help
We are an OSCP-certified offensive security firm based in Kigali. We deliver penetration testing, purple team exercises, and red team engagements for banks and financial institutions across East Africa. We understand the specific threats facing the region and can help you choose the right testing approach for your institution’s maturity level.
For full details on our testing methodology and deliverables, see our penetration testing service page. For broader security assessments, see our security assessments service page. Contact us to discuss the right testing approach for your institution.