PCI DSS compliance in Rwanda: what banks need to know (2026)

If your organisation in Rwanda processes, stores, or transmits payment card data, PCI DSS compliance is not optional. It is a contractual requirement enforced by the card brands (Visa, Mastercard) through your acquiring bank. With card-based transactions growing across East Africa and more Rwandan banks issuing debit and credit cards, PCI DSS is now a front-line compliance concern alongside BNR cybersecurity requirements.

This guide covers which Rwandan institutions need PCI DSS, what each compliance level requires, how penetration testing supplies the evidence the standard's technical requirements call for, and what to expect on timeline and costs.

Who needs PCI DSS in Rwanda?

PCI DSS applies to any entity that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD). In the Rwandan context, this includes:

• Commercial banks issuing Visa, Mastercard, or UnionPay cards
• Payment processors and gateways handling card transactions
• Fintech companies that process card payments through their platforms
• E-commerce merchants accepting card payments online
• Hotels, airlines, and retailers with significant card transaction volumes
• Third-party service providers that handle cardholder data on behalf of the above

If you accept card payments or touch cardholder data at any point in the transaction flow, you are in scope. The question is not whether PCI DSS applies but which level of compliance you need.

PCI DSS v4.0: what changed

PCI DSS v4.0 replaced v3.2.1 as the mandatory standard from 31 March 2024. The current version is v4.0.1, a limited revision published in June 2024 that clarified wording without adding or removing requirements; v4.0 itself was retired on 31 December 2024. The transition period for certain future-dated requirements ran until 31 March 2025, so all requirements are now fully enforceable. Key changes relevant to Rwandan institutions:

• Customised approach: organisations can now meet requirements through alternative controls if they demonstrate equivalent security, giving more flexibility to institutions with mature security programmes
• Targeted risk analysis: several requirements now allow organisations to define their own testing frequencies based on documented risk analysis rather than fixed schedules
• Enhanced authentication: multi-factor authentication (MFA) is now required for all access to the cardholder data environment, not just remote access
• Expanded penetration testing scope: Requirement 11.4 (formerly 11.3) now explicitly requires testing of segmentation controls and includes clearer guidance on methodology

PCI DSS merchant levels

The card brands define four merchant levels based on annual Visa or Mastercard transaction volume:

Level 1

Over 6 million transactions per year, or any merchant that has experienced a data breach, or any merchant the card brand designates as Level 1.

Requirements: annual on-site assessment by a Qualified Security Assessor (QSA), quarterly network scans by an Approved Scanning Vendor (ASV), annual penetration test, and Report on Compliance (ROC).

In Rwanda, the largest commercial banks and payment processors fall into this category.

Level 2

1 million to 6 million transactions per year.

Requirements: annual Self-Assessment Questionnaire (SAQ), quarterly ASV scans, annual penetration test. Some acquiring banks may require a QSA assessment even at Level 2.

Level 3

20,000 to 1 million e-commerce transactions per year.

Requirements: annual SAQ, quarterly ASV scans. Penetration testing is recommended but may be required by the acquiring bank.

Level 4

Fewer than 20,000 e-commerce transactions or up to 1 million total transactions per year.

Requirements: annual SAQ, quarterly ASV scans. This is where most smaller Rwandan merchants and fintechs fall.

Service provider levels

Service providers (payment processors, hosting providers, managed security providers that touch cardholder data) have two levels:

• Level 1: over 300,000 transactions per year. Requires annual QSA audit and ROC.
• Level 2: fewer than 300,000 transactions. Can self-assess with SAQ-D.

The 12 PCI DSS requirements

PCI DSS v4.0 organises its requirements into six goals and twelve requirement families:

1. Install and maintain network security controls (firewalls, network segmentation)
2. Apply secure configurations (no vendor defaults, hardened systems)
3. Protect stored account data (encryption, masking, retention policies)
4. Protect cardholder data in transit (TLS encryption for all transmission)
5. Protect against malicious software (anti-malware on all systems)
6. Develop and maintain secure systems (patching, secure SDLC)
7. Restrict access by business need (role-based access controls)
8. Identify users and authenticate access (unique IDs, MFA)
9. Restrict physical access to cardholder data environments
10. Log and monitor all access (audit trails, SIEM)
11. Test security regularly (vulnerability scans, penetration tests)
12. Support information security with policies and programmes (governance, awareness)

For Rwandan banks already working toward BNR compliance and ISO 27001, many of these controls will already be partially in place. The gap is usually in the specifics: PCI DSS requires particular encryption standards, specific logging retention periods, and a precisely defined cardholder data environment (CDE) scope.

How penetration testing supplies the evidence Requirement 11.4 requires

Requirement 11.4 (formerly 11.3 in v3.2.1) is where penetration testing directly supports your PCI DSS compliance, and where our engagements plug in. The standard requires:

External penetration testing

Testing from outside the network perimeter against all internet-facing systems in the cardholder data environment. This means your payment gateway endpoints, card processing APIs, web applications that handle card data, and any internet-facing infrastructure supporting the CDE.

Internal penetration testing

Testing from inside the network to simulate an attacker who has gained internal access. This must cover network segmentation controls to verify that the CDE is properly isolated from the rest of the corporate network.

Segmentation testing

If you use network segmentation to reduce PCI DSS scope (and you should), penetration testing must specifically validate that segmentation controls are effective. This means attempting to access the CDE from out-of-scope network segments. Segmentation testing is required every six months for service providers.

Application-layer testing

Web applications in the CDE must be tested for application-layer vulnerabilities, at minimum against the OWASP Top 10. This covers SQL injection, broken authentication, cross-site scripting, and the business logic flaws that automated scanners consistently miss.

Testing frequency

• At least annually for all merchants and service providers
• After any significant change to the CDE (infrastructure changes, new applications, major configuration changes)
• Every six months for segmentation validation (service providers)

What the report must contain

A PCI DSS-compliant penetration test report must document the scope of testing, methodology used, all findings with severity ratings, evidence of exploitation, remediation guidance, and confirmation that critical and high findings have been retested after remediation. This is the same evidence-led structure our team uses for every security assessment report.

Common PCI DSS gaps in Rwandan institutions

From our work with financial institutions across the region, the most common PCI DSS gaps we encounter are:

• Undefined CDE scope: the cardholder data environment is not clearly defined, which means segmentation is weak or nonexistent, and the entire corporate network ends up in scope
• Flat networks: no segmentation between the CDE and general corporate networks, dramatically increasing both compliance scope and risk
• Cardholder data in unexpected places: PANs appearing in log files, email systems, test databases, and spreadsheets outside the defined CDE
• Weak key management: encryption keys stored alongside encrypted data, shared keys, or no documented key rotation procedures
• Missing MFA: multi-factor authentication not implemented for all CDE access as required by v4.0
• Insufficient logging: logs exist but are not centrally collected, monitored, or retained for the required 12 months
• Third-party gaps: payment processors and hosting providers included in the CDE without proper due diligence or Attestation of Compliance (AOC)

Timeline to compliance

For a Rwandan bank starting from a reasonable security baseline (basic firewalls, some access controls, antivirus deployed), expect the following timeline:

1. Gap assessment (4-6 weeks): detailed review of current state against all PCI DSS requirements, identifying gaps and prioritising remediation
2. Remediation (3-6 months): implementing missing controls, network segmentation, encryption, logging, access controls, and policy documentation
3. Penetration testing (2-4 weeks): internal and external testing across the full CDE, including segmentation validation
4. Remediation retest (1-2 weeks): verifying that critical and high findings from the penetration test have been resolved
5. QSA assessment or SAQ completion (4-8 weeks): formal compliance validation

Total: 6 to 12 months for initial compliance. Organisations with significant gaps in network segmentation or encryption may need longer.

Costs

PCI DSS compliance costs vary significantly based on scope and current maturity:

• Gap assessment: scoped based on environment complexity
• Penetration testing: depends on the size of the CDE and number of applications in scope. See our penetration testing cost guide for factors that affect pricing
• QSA audit (Level 1): typically the largest single line item, scaling with the size and complexity of the cardholder data environment. If the assessor travels from outside Rwanda, travel costs add to the engagement
• Remediation: highly variable depending on existing gaps. Network segmentation and encryption projects can be substantial
• Quarterly ASV scans: the smallest recurring cost in the programme, priced by the number of external IPs in scope
• Ongoing annual costs: annual reassessment, quarterly scans, and annual penetration testing

The cost of non-compliance is higher. The card brands do not publish an official fine schedule, but acquiring banks pass on monthly non-compliance fines that escalate the longer the gap persists, and a payment card data breach triggers forensic investigation costs, card reissuance costs, and potential loss of the ability to process card payments entirely. For context on breach costs in the region, see our data breach cost analysis.

How PCI DSS and BNR requirements overlap

Rwandan banks that comply with both frameworks can use the significant overlap:

| Control area | BNR requirement | PCI DSS requirement | | ------------------- | ----------------------------- | ---------------------------------------- | | Penetration testing | Annual VAPT | Annual pentest + quarterly ASV | | Risk assessment | Regular risk assessments | Annual risk assessment (Req 12.3) | | Incident response | Documented IRP, report to BNR | Documented IRP (Req 12.10) | | Access control | Role-based access | Need-to-know access (Req 7) | | Encryption | Data protection requirements | Specific encryption standards (Req 3, 4) | | Third-party risk | Vendor risk management | Service provider management (Req 12.8) | | Security training | All staff training | Annual security awareness (Req 12.6) |

A well-planned compliance programme addresses both frameworks simultaneously, reducing duplication and cost.

How we can help

IMIZI Cyber is an offensive security firm based in Kigali, conducting PCI DSS-aligned penetration tests for banks, payment processors, fintechs, and other regulated institutions across Rwanda and the wider region. Our team covers external and internal network penetration testing, web application testing, API security assessment, and segmentation validation, all documented in reports written to support your Requirement 11.4 evidence and your assessor's review. We deliver the readiness side of compliance: gap preparation, the technical testing evidence, and remediation guidance. Formal attestation is always issued by an independent assessor, and where it helps we coordinate independent audit firms through our partner network.

For full details on our methodology and deliverables, see our penetration testing service page. For broader compliance-oriented assessments, see our security assessments service page. Contact us to scope your PCI DSS penetration test.