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 satisfies the standard’s technical requirements, and what to expect in terms of 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 transition period for certain future-dated requirements runs until 31 March 2025, meaning 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 satisfies Requirement 11.4

Requirement 11.4 (formerly 11.3 in v3.2.1) is where our work directly supports your PCI DSS compliance. 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 structure we use for all our security assessment reports.

Common PCI DSS gaps in Rwandan institutions

From our experience working with financial institutions in 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): comprehensive internal and external testing of the 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 cost, ranging from $30,000 to $100,000+ depending on environment complexity. There are no QSAs based in Rwanda, so travel costs apply
• Remediation: highly variable depending on existing gaps. Network segmentation and encryption projects can be substantial
• Quarterly ASV scans: relatively low cost, typically $1,000 to $5,000 per quarter depending on IP scope
• Ongoing annual costs: annual reassessment, quarterly scans, and annual penetration testing

The cost of non-compliance is higher. Card brands can impose fines of $5,000 to $100,000 per month for non-compliance, 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

We are an OSCP-certified penetration testing firm based in Kigali. We conduct PCI DSS-compliant penetration tests for banks and payment processors across Rwanda and East Africa. Our testing covers external and internal network penetration testing, web application testing, API security assessment, and segmentation validation, all documented in reports structured to satisfy QSA requirements.

For full details on our testing 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.