A common artefact in a South African fintech's compliance folder is a one-page certificate from a generic IT vendor that says "vulnerability scan completed" with a date from over a year ago. That document does not, on its own, satisfy POPIA's security requirements. It does not satisfy what the FSCA expects of designated institutions on cyber resilience. It does not satisfy most enterprise insurance brokers. And it is the first thing the Information Regulator will ask to see after an incident.
This piece walks through what a real fintech-grade penetration test covers, what the South African regulatory environment actually requires (versus what people assume it requires), and how to scope a pentest that produces an artefact you can defend.
What the regulators actually say
You will not find a South African statute that says "you must run a penetration test every six months." That is not how our financial regulation is written. What you will find is a stack of obligations that, taken together, only have one defensible answer.
POPIA section 19 requires "appropriate, reasonable technical and organisational measures" to secure personal information. The Information Regulator has been active in issuing enforcement notices (Department of Justice, Department of Basic Education, Lancet Laboratories, and others), and "appropriate" is judged against the sensitivity of the data and the size of the responsible party. For a fintech holding ID numbers, account balances, source-of-funds documents, and transaction histories, the bar is high. A scanner-only check is not appropriate.
If your business is a licensed financial institution (FSP, bank, insurer, retirement fund, collective investment scheme manager) two recent instruments raise the bar further. Joint Standard 1 of 2023 (IT governance and risk management, jointly issued by the FSCA and Prudential Authority, commenced November 2024) makes the governing body explicitly accountable for IT and cyber risk. Joint Standard 2 of 2024 (cybersecurity and cyber resilience, published May 2024, compliance from June 2025) adds specific cyber resilience requirements across financial institutions. Both require evidence. Evidence is a tested report from someone qualified to produce it.
FICA, as amended by the General Laws (Anti-Money Laundering and Combating Terrorism Financing) Amendment Act 22 of 2022, raises the bar for accountable institutions on risk-based customer due diligence and record keeping. If your KYC pipeline can be subverted, your AML programme is compromised by definition. That is squarely in pentest territory.
If you operate inside the National Payment System (PSP, clearing house, settlement participant), SARB Directive 1 of 2024 on cybersecurity and cyber resilience in the NPS is the prescriptive instrument: regular, independent technical testing of critical systems, with board reporting. For card payments and payment infrastructure, this is not optional.
What this means in practice: nobody is going to send you a letter saying "you must pentest." But after an incident, every regulator listed above will ask the same question, and the right answer is a current, scoped, independent test report.
What a real fintech pentest covers
A generic "pentest" sold to small business is usually an external network scan plus a quick web app probe. That is not what a fintech needs. The surface to cover, at minimum:
External infrastructure
Your public IPs, DNS, mail records, exposed admin panels, VPN endpoints, cloud storage buckets. The first thing an attacker maps. Misconfigured S3 buckets, exposed RDP, outdated VPN appliances, and DNS takeovers are still the boring root causes of most fintech breaches we investigate.
Web and mobile applications
The customer portal, advisor portal, admin console, internal tools, and the mobile app if you have one. We test against the OWASP Top 10 (2025 edition) and the OWASP Top 10 for LLM Applications as a baseline, then add the fintech-specific cases: business-logic abuse on transfers, race conditions on balance updates, IDOR on customer records, JWT confusion, broken multi-tenancy. The boring OWASP items still find things, but the money is in business logic.
API surface
If you have a banking-as-a-service product, a partner API, or open banking endpoints, this gets its own track. API pentests find authentication bypasses, scope confusion, rate-limit failures, and the classic "the mobile app has admin endpoints the marketing team forgot about."
Identity and access
How accounts get created, reset, escalated, deprovisioned. Magic-link weaknesses, MFA bypass via SMS porting, OAuth misconfigurations, stale staff accounts with production access. This is where insider-threat and supply-chain risk live.
Cloud configuration review
IAM policies, network segmentation, secret management, logging coverage. Not strictly a "pentest" but you cannot defend a finding without it. A vulnerability in an EC2 instance that has no outbound network and no IAM role is different from one with full admin on your account.
Phishing and social
Optional but recommended for any fintech with more than 30 staff. Most breaches start with a phish. Testing the human layer once a year, with a debrief instead of a shaming exercise, is the most cost-effective control most fintechs are missing.
What you should get back
A real pentest report has three layers and you should ask for all three before you sign:
- An executive summary. One page, written for the board. Risk rating, scope, top three findings, and a plain-language statement of the residual risk. This is what your insurer, your regulator's enquiry letter, and your auditor will read.
- A technical findings register. Every finding ranked (CVSS or equivalent), with evidence, reproduction steps, and a specific remediation. Not "patch the system." Specific. "Upgrade nginx to 1.25.3 on these three hosts. Then re-deploy. Estimated effort four hours."
- A retest commitment. A second visit after you've remediated, narrowly scoped to the original findings, with a clean-bill report you can hand to anyone who asks. A pentest without retest is a problem statement without a sign-off.
Need a pentest scoped for SA fintech?
Our penetration testing engagements are scoped to your real attack surface and produce an artefact your auditors, insurers, and the Information Regulator can read. One to three weeks, depending on scope, with a retest included.
See the Penetration Testing serviceHow to scope the engagement
The single most common scoping mistake is testing the wrong thing. We see fintechs pay R80k for a pentest of their corporate website while the actual customer portal, where the money lives, is excluded because it sits on a different domain. Three things to nail down before the engagement starts:
What is in scope. Every host, every domain, every app. Write it down. The pentest team will use this as their rules of engagement. Anything not on this list will not be tested. If your most valuable system is on a forgotten subdomain, put the subdomain on the list.
What is out of scope and why. Often you exclude prod for safety. That is fine if and only if your prod and staging genuinely have parity. We have seen "tested staging" reports where staging had different auth, different DB, and different network controls. The report was technically true and substantively useless.
What the engagement style is. Black box (the tester knows what the public knows), grey box (the tester gets credentials and an architecture diagram), or white box (the tester gets source code and admin access). Black box is the most realistic. Grey box finds more, faster. White box is best for hardening a system you're about to launch. For a fintech compliance pentest you probably want grey box on the external surface and white box on a single high-value internal system.
When to run it and how often
Annually at minimum for any fintech holding customer data. Twice a year if you ship a lot of code, hold a banking licence, or run payment infrastructure. Always after a significant architectural change, a new partner integration, or a major hire/fire in the engineering or admin team. Always before a Series B raise, because diligence will ask.
The "every two years because that's what the certificate looks like" cycle is what you are running because nobody enforced anything in 2019. The Information Regulator and the FSCA are both ramping up technical enforcement. The baseline is moving up.
Key takeaways
- POPIA, FICA, the FSCA/PA Joint Standards (1 of 2023 and 2 of 2024), and the SARB NPS Directive 1 of 2024 don't name pentesting explicitly, but together they require independent, evidence-based security testing for any licensed fintech.
- A scanner certificate is not a pentest. The regulator will know the difference after an incident.
- A real fintech pentest covers external infra, web/mobile apps, APIs, identity, cloud config, and optionally social engineering.
- You should get back an executive summary, a technical findings register, and a retest commitment.
- Scope is the single highest-leverage decision. Test the systems where the money and the data actually live.
- Annual at minimum. Twice a year if you hold a banking licence or ship a lot of code.
If you have not run a real pentest in the last twelve months, your residual risk is higher than the board thinks. The cost of a properly scoped engagement is small compared to a POPIA section 109 administrative fine (capped at R10 million per infringement notice) and trivial compared to the reputational cost of an unreported breach landing in the news first.