Understanding your true PCI scope
The Payment Card Industry Data Security Standard (PCI DSS) applies unconditionally to any entity that stores, processes, or transmits cardholder data (CHD), or to any entity that could impact the security of that data. For Nigerian fintechs, the cost, timeline, and sheer operational complexity of compliance depend entirely on one architectural decision: how your systems handle the Primary Account Number (PAN).
Full Scope (Level 1 Processors)
If you build your own payment gateway (like Interswitch or NIBSS) and process millions of transactions directly through your own servers, your entire infrastructure is in scope. You require a grueling annual onsite audit by a QSA and mandatory quarterly external network scans.
Reduced Scope (Tokenization via API)
If you use a third-party processor API to capture the card data and they return an opaque token (which you store in your database), your scope is significantly reduced. You only handle the token, which cannot be mathematically reverse-engineered to reveal the PAN.
Minimal Scope (Hosted Redirects)
If you redirect the user to a third-party hosted checkout page (e.g., Paystack Standard Checkout) or use an IFRAME, your backend servers never touch the data. You simply need to validate that your front-end site isn't compromised (SAQ-A).
The Nigerian context: Local QSAs and CBN overlap
In Nigeria, achieving PCI DSS compliance often requires working with local or regional Qualified Security Assessors (QSAs) licensed by the PCI Security Standards Council. PCI DSS compliance does not operate in a vacuum. The Central Bank of Nigeria (CBN) expects all licensed Payment Service Providers (PSSP), Payment Terminal Service Providers (PTSP), and switches to maintain PCI DSS certification as a baseline condition of their operating licenses. A failure to renew your RoC can lead to immediate operational suspension by the CBN.
Key changes introduced in PCI DSS v4.0
The industry has fully transitioned to v4.0. This version abandons the "check-the-box" mentality and focuses heavily on modern architectural threats, particularly those targeting cloud-native web applications and APIs.
- Targeted Risk Analysis (Customized Approach): Organizations are now allowed to meet the intent of a requirement using alternative security controls, provided they conduct and document a highly rigorous Targeted Risk Analysis to prove the alternative control is effective.
- Magecart and E-skimming Defense: Requirements 6.4.3 and 11.6.1 explicitly demand the management and securing of all payment page scripts that are loaded and executed in the consumer's browser. You must now have mechanisms to detect unauthorized changes to HTTP headers and the JavaScript payloads on your payment pages.
- Stricter Authentication Protocols: Multi-Factor Authentication (MFA) is now strictly required for all access to the Cardholder Data Environment (CDE), not just for remote access originating from outside the corporate network. Passwords must be longer, and service accounts must be tightly managed.
- Continuous Vulnerability Management: Vulnerabilities must be ranked according to risk, and high-risk vulnerabilities must be patched immediately, abandoning the relaxed grace periods of the past.
Requirement 11 explicitly mandates internal and external penetration testing.
Schedule a PCI-Compliant PentestRequirement 11: Security testing mandates decoded
Requirement 11 is where your software engineering and DevOps teams interact most directly with the standard. It mandates that you regularly test the efficacy of your security systems.
Vulnerability scanning vs. Penetration testing
PCI DSS requires both; they are not interchangeable. Vulnerability scans (Requirement 11.3) are automated checks that must be run quarterly by an Approved Scanning Vendor (ASV). Penetration testing (Requirement 11.4) is a manual, intelligence-driven exercise that must be conducted at least annually, and crucially, after any significant infrastructure or application upgrade. The pentest must include both network-layer infrastructure assessments and deep application-layer logic testing.
The critical segmentation check
To reduce the massive cost of an audit, most companies isolate their Cardholder Data Environment (CDE) onto a separate, highly secure subnet, entirely cut off from the rest of the corporate network (where HR and marketing operate). However, if you claim segmentation, you must mathematically prove it. The standard requires independent penetration testers to explicitly perform segmentation checks every six months to verify that absolutely no unauthorized traffic can bridge the gap from the untrusted corporate network into the pristine CDE.
De-scope at absolutely all costs
The single most effective PCI compliance strategy is to aggressively minimize the scope of the Cardholder Data Environment. Use tokenization, strict network segmentation, and third-party hosted fields (IFRAMEs). The less your infrastructure touches, stores, or transmits the 16-digit PAN, the cheaper, faster, and less painful your compliance audit will be.
Frequently asked questions
Do we need PCI DSS compliance if we use Paystack or Flutterwave?
Yes. Even if you redirect users to Paystack or Flutterwave to enter their card details and your servers never touch the Primary Account Number (PAN), you still have a compliance obligation. Your scope is drastically reduced, but you must complete a Self-Assessment Questionnaire (SAQ-A) to formally validate that your site isn't compromised and funneling users to a fake checkout page.
What is the difference between an SAQ and an RoC?
A Self-Assessment Questionnaire (SAQ) is a validation tool for lower-volume merchants (typically Levels 2, 3, and 4) to self-report their compliance status. A Report on Compliance (RoC) requires a comprehensive, rigorous external audit conducted by a Qualified Security Assessor (QSA) and is strictly mandatory for high-volume processors handling over 6 million transactions annually (Level 1).
How does the shift to PCI DSS v4.0 change penetration testing requirements?
Version 4.0 shifts from a checklist approach to a risk-based approach. It introduces significantly more rigorous testing requirements for authentication bypasses, the implementation of Multi-Factor Authentication (MFA) across the CDE, and the security of e-commerce payment redirects (explicitly targeting Magecart and e-skimming attacks via Requirement 6.4.3 and 11.6.1).
Can the Central Bank of Nigeria (CBN) penalize us for PCI non-compliance?
Indirectly, yes. While the PCI Security Standards Council (PCI SSC) sets the standard, the card brands (Visa, Mastercard, Verve) enforce it via your acquiring bank. However, the CBN’s Risk-Based Cybersecurity Framework explicitly mandates adherence to international payment security standards. A breach resulting from PCI non-compliance will trigger severe CBN regulatory scrutiny and potential license suspension.
Related reading
Blog: Webhook Security for Payment Platforms · The Most Dangerous API Vulnerability · Secure your fintech API in Nigeria
Guides: Fintech Security Checklist · OWASP for Fintech
Services: Penetration Testing · Secure Architecture Review