FSCA and PA joint standards: assess your mobile banking app before and after every release.
Joint Standard 2 of 2024 asks financial institutions to run regular vulnerability assessments and penetration tests, to test web-based and critical applications during development, and to require multi-factor authentication for accounts that reach sensitive applications over the internet. The older Joint Standard 1 of 2023 sets the IT governance and risk management framework around it, and POPIA adds security safeguards and a breach notification duty with no risk threshold. Ostorlab tests your app and the APIs behind it, behind login, on every release.
- Assesses the mobile app and the APIs it calls, on the build your customers download
- Tests login, one-time codes, step-up checks and session handling with your test accounts
- Lists the SDKs and native libraries in each release and maps them to known vulnerabilities
- Proves each finding with a replayable exploit or request and response evidence
- Who it applies to
- Banks, insurers, market infrastructures, pension funds and the other financial institutions named in the joint standards
- Key dates
- Joint Standard 1 of 2023 applied from 15 November 2024, Joint Standard 2 of 2024 from 1 June 2025, and the incident notification template from 1 September 2026
- Focus
- Vulnerability assessment, penetration testing and application security testing, MFA and data protection, with POPIA security safeguards on top
- Main reference
- Joint Standard 2 of 2024 - Cybersecurity and Cyber Resilience Requirements
The texts behind your mobile channel
Two joint standards from the FSCA and the Prudential Authority, the PA cloud communications and POPIA. The dates below are for the texts cited on this page.
- 26 November 2013
POPIA in the Gazette
The Protection of Personal Information Act 4 of 2013 is published in the Government Gazette. Chapter 9 restricts transfers of personal information outside the Republic.
- 1 July 2021
POPIA fully enforceable
POPIA commenced on 1 July 2020 and the one-year grace period ended on 30 June 2021. Security compromises must be reported to the Information Regulator.
- 10 November 2023
Joint Standard 1 of 2023
The FSCA and the Prudential Authority publish the IT Governance and Risk Management Requirements for Financial Institutions, the first binding joint standard of its kind for the sector.
- 17 May 2024
Joint Standard 2 of 2024
The Cybersecurity and Cyber Resilience Requirements are published, with fundamentals, hygiene practices, testing and a material incident notification duty.
- 15 November 2024
Joint Standard 1 of 2023 commences
The IT governance and risk management requirements take effect for the financial institutions in scope.
- 1 June 2025
Joint Standard 2 of 2024 commences
Joint Notice 1 of 2024, published with Joint Communication 5 of 2024, determines 1 June 2025 as the effective date of the cybersecurity requirements.
- 25 July 2025
Cloud and offshoring communication
Joint Communication 2 of 2025 recalls PA Directive 3 of 2018 and Guidance Note 5 of 2018 and sets out recommended practice for cloud computing and data offshoring, while a Joint Standard is developed.
- 1 September 2026
Incident notification template
Joint Notice 2 of 2026 determines the Reporting of Material IT and Cyber Incident Template under both joint standards. Banks submit it on the Umoja Portal; other financial institutions use the FSCA Joint Standards Submission Portal.
The joint standards and POPIA, applied to your mobile app
For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team.
- Joint Standard 1 of 2023, paragraphs 7.3(e) and 9.3(a); Joint Standard 2 of 2024, paragraphs 7.1.1(d), 7.1.2 and 7.7.5(c)
Keep an inventory of what you run, including third parties
What the text says
Joint Standard 1 of 2023 requires the IT risk management framework to identify and prioritise IT assets and protect them from unauthorised access, misuse or fraudulent modification, and to keep an up-to-date IT asset inventory. Joint Standard 2 of 2024 requires an inventory of all information assets, including location and ownership, reviewed regularly but at least every two years, and a policy on the use and update of third-party and open-source software code so that it is reviewed and tested before it is integrated.
What it means for your mobile app
A mobile banking app is an information asset that bundles third-party SDKs and native libraries. Each one needs a place in the inventory, with a version and an owner.
How Ostorlab helps
Ostorlab lists the SDKs and native libraries in each release with their versions and their location in the app bundle, and shows which backends the app and its SDKs talk to.
What stays with you
The asset inventory itself, third-party due diligence and contracts.
- Joint Standard 2 of 2024, paragraphs 7.7.2 and 7.7.3
Assess and penetration test the app and its APIs, regularly
What the text says
Financial institutions must conduct regular vulnerability assessments on IT systems and information assets, at a frequency commensurate with their criticality and the security risk they face. They must carry out penetration testing on critical IT systems and information assets to obtain an in-depth evaluation of their cybersecurity defences, with black box, grey box or white box testing or a combination as the responsible authority may specify. For IT systems and information assets directly accessible from the internet, penetration testing must be conducted whenever they undergo major changes or updates, and at least annually if there are none.
What it means for your mobile app
Your mobile banking app and the APIs it calls are directly accessible from the internet. Plan testing on every major release and at least one a year, and include logged-in testing.
How Ostorlab helps
An AI-agent pentest tests the app and its APIs behind login, on the build you ship, with a working exploit you can replay for each AI-agent finding. Findings are rated, tracked as tickets and retested once the fix ships.
What stays with you
Choosing who runs the annual penetration test, black or grey box decisions, testing in production and reporting to the governing body.
- Joint Standard 2 of 2024, paragraphs 7.2.4 and 7.7.5
Build security in and test applications as you develop
What the text says
The standard requires a security-by-design approach, building security into every phase of software development to minimise system vulnerabilities and reduce the attack surface. Security requirements relating to access control, authentication, transaction authorisation, data integrity, logging, audit trails, security event tracking and exception handling must be specified at the initial stages of development or acquisition, and changes to business-critical applications must be reviewed and tested. Standards on secure coding, source code review and application security testing must be adopted, and security functionality on web-based and critical applications tested during development and implementation.
What it means for your mobile app
Every app release is a change to an internet-facing channel, and each one should pass automated security testing before it reaches the store, including the SDKs and libraries it bundles.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA directly, with no source code needed, including taint analysis across embedded SDKs. Mobile DAST runs the app, and both run from your CI/CD pipeline on every build.
What stays with you
Secure coding standards, developer training, manual code review and release approval.
- Joint Standard 2 of 2024, paragraphs 7.7.6 and 8.5
Remediate with severity, priority and patch deadlines
What the text says
The remediation process must include severity assessments and classification of issues, prioritisation based on the risk posed, timeframes to remediate issues of different severity, and risk assessments and mitigation strategies where appropriate. All issues from cybersecurity testing, and software defects found in source code review and application security testing, must be tracked, and known major issues and security flaws must be remediated before production deployment. Security patches must be applied within a timeframe commensurate with the risks posed, with compensating controls where no patch exists, testing before production and a remediation plan with timelines where a patch cannot be applied.
What it means for your mobile app
Each finding in the app or an API needs a severity, a fix deadline and a record. Loose ends in third-party libraries are the easiest to forget.
How Ostorlab helps
Ostorlab rates each finding critical, high, medium or low, tracks it as a ticket in the platform or in Jira and ServiceNow, and retests it after the fix. Component findings include upgrade or replace recommendations.
What stays with you
Patch windows, server and infrastructure patching, risk acceptance and production deployment decisions.
- Joint Standard 2 of 2024, paragraphs 7.2.2, 8.2 and 8.3
Identity, access and MFA for internet-facing accounts
What the text says
Access to information assets must be limited to authorised users, processes and devices, managed commensurate with the assessed risk of unauthorised access, with identity management and access control mechanisms, security and access control policies, remote access only from secured devices and connections, and strong authentication for remote access. Every administrative account must be secured against unauthorised access and use, and privileged access granted on a need-to-use basis with activity logged. Multi-factor authentication is required for users with access to critical system functions, for all administrative and privileged accounts, and for all user accounts used to access applications containing sensitive information through the internet.
Source:Joint Standard 2 of 2024, paragraphs 7.2.2, 8.2 and 8.3
What it means for your mobile app
The mobile app is exactly the kind of application the MFA rule describes. The second factor has to be enforced by the server, whatever the app sends.
How Ostorlab helps
Authenticated testing covers login and logout, token refresh, timeouts, session invalidation and MFA enforcement, including step-up flows, together with the API calls behind them.
What stays with you
Choosing authentication methods, privileged access management, access reviews and device policy.
- Joint Standard 2 of 2024, paragraph 7.2.3; Joint Standard 1 of 2023, paragraph 10
Protect data on the device and in transit
What the text says
Joint Standard 2 of 2024 requires data loss prevention policies for sensitive information whether in motion, at rest or in use, measures to prevent and detect unauthorised access to data, modification, copying, transmission and data theft in systems and endpoint devices, encryption or access control commensurate to the risk for sensitive information stored in systems and endpoint devices, and use of only authorised systems and devices for sensitive information. Joint Standard 1 of 2023 requires measures to protect customer personal account and transaction data, logical access control with controls for monitoring anomalies, and measures against data theft, data loss and data leakage from endpoint devices.
Source:Joint Standard 2 of 2024, paragraph 7.2.3; Joint Standard 1 of 2023, paragraph 10
What it means for your mobile app
Passwords, tokens and customer data should not sit in clear text on the phone or travel unprotected to the backend. Rooted or jailbroken devices weaken every one of these controls.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, checks transport protections, and tests what the app does in rooted and jailbroken environments.
What stays with you
Data classification, DLP tooling, mobile device management and key management.
- Joint Standard 2 of 2024, paragraph 7.2.6
Manage cryptography and protect keys
What the text says
Where cryptography is used, policies, standards and procedures must cover key generation, distribution, installation, renewal, revocation, recovery and expiry. Cryptographic algorithms must come from well-established international standards, keys must be securely generated and protected from unauthorised disclosure in hardened and tamper resistant systems, expired or revoked keys must be destroyed so they are not recoverable, and all algorithms must be subject to rigorous testing or vetting to meet the identified security objectives.
What it means for your mobile app
Certificate pinning, code signing and keystore use are all cryptography in the app. What sits in the app package or the device keystore can be attacked on a modified device.
How Ostorlab helps
Mobile Shielding Scan attempts to bypass root and jailbreak detection, anti-tampering and TLS pinning at runtime, and shows which protections held and which were bypassed. Ostorlab also finds keys and secrets in the app package.
What stays with you
Key management systems, HSMs, certificate lifecycle and the choice of algorithms.
- Protection of Personal Information Act 4 of 2013, sections 19, 21, 22 and 72
Meet the POPIA safeguards and breach duties
What the text says
POPIA requires a responsible party to secure the integrity and confidentiality of personal information with appropriate, reasonable technical and organisational measures. It must identify reasonably foreseeable internal and external risks, establish and maintain safeguards against them, regularly verify that the safeguards are effectively implemented, and update them in response to new risks or deficiencies. A written contract must require an operator to maintain the same security measures, and an operator must notify the responsible party immediately where there are reasonable grounds to believe that personal information has been accessed by an unauthorised person. Where there are reasonable grounds to believe that personal information has been accessed or acquired by an unauthorised person, the responsible party must notify the Information Regulator and, subject to the exceptions, the data subject, as soon as reasonably possible. Transfers of personal information outside the Republic require an adequate level of protection or another ground under section 72.
Source:Protection of Personal Information Act 4 of 2013, sections 19, 21, 22 and 72
What it means for your mobile app
App testing is one way to verify the section 19 safeguards on the device and in the API. The Information Regulator says there is no risk threshold for reporting: every security compromise must be reported, and it does not have to be confirmed first.
How Ostorlab helps
Ostorlab tests the technical controls in the app and its APIs and gives you evidence for each result. What counts as a security compromise, and the notifications, stay with your information officer.
What stays with you
Information officer duties, breach assessment, notification to the Regulator and data subjects, and cross-border transfer decisions.
- Joint Standard 1 of 2023, paragraph 15.1; Joint Standard 2 of 2024, paragraph 9.1; Joint Notice 2 of 2026
Notify material incidents in the determined form
What the text says
Both joint standards require a financial institution to notify the responsible authority, in the form and manner the Authorities determine, after classifying a systems failure, cyber incident or information security compromise as a material incident. Joint Notice 2 of 2026, published with Joint Communication 5 of 2026, determines the Reporting of Material IT and Cyber Incident Template and takes effect on 1 September 2026. Banks, mutual banks, insurers and their controlling companies submit the template on the Umoja Portal; the other financial institutions in scope use the FSCA Joint Standards Submission Portal.
What it means for your mobile app
Your incident classification and notification runbook needs the template, the portal and the period set out on the template cover page. Scan evidence helps establish the scope.
How Ostorlab helps
Ostorlab does not classify or report incidents. It gives you evidence of the vulnerability or control failure behind an incident and retests the fixes afterwards.
What stays with you
Classification, notification, regulator and customer communication, and forensics.
- Joint Communication 2 of 2025, section 4; PA Directive 3 of 2018; Joint Standard 1 of 2023, paragraph 7.3(i)
Govern cloud use and the offshoring of data
What the text says
Joint Communication 2 of 2025, issued on 25 July 2025, recalls PA Directive 3 of 2018 and Guidance Note 5 of 2018 for banks and sets out recommended practice for cloud computing and data offshoring: a risk-based approach aligned with the institution's risk appetite, governance that covers a defined policy and a board-approved data strategy and data governance framework, attention to contractual and other legal requirements, and due diligence before strategic investments. Offshoring means the storage or processing of data outside the borders of South Africa. The Authorities state that a cloud computing and data offshoring Joint Standard is in development. Joint Standard 1 of 2023 also requires careful screening of service providers and contractors, and contractual requirements to protect sensitive or confidential information.
What it means for your mobile app
If the app's backend or its SDKs send personal information to services outside South Africa, POPIA section 72 and the cloud expectations both apply. The app can still be scanned where the data lives.
How Ostorlab helps
On-premises scanning runs on infrastructure you control, inside your network. It scans staging apps, APIs and repositories behind your firewall or VPN.
What stays with you
Cloud strategy, due diligence, contracts, data localisation decisions and the coming Joint Standard.
Summary of the public joint standards, Prudential Authority communications and POPIA text, checked on 27 September 2026. The joint standards do not name mobile apps: they apply to IT systems, information assets and applications generally, and this page applies them to the mobile channel. This page is not legal advice.
Joint standard controls, control by control
The controls the joint standards and POPIA point to, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Vulnerability assessment of the app and its APIsJS2 7.7.2, 7.7.3 | AI-agent pentest of the app and its APIs, behind login, on the build you ship. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
| Penetration testing on major changes, at least annuallyJS2 7.7.3(a)(iii) | Tests the internet-facing app and APIs on every release, so the annual test never starts from a stale baseline. Details | Scan results per release, with a replayable exploit for each finding |
| Application security testing during developmentJS2 7.7.5 | Mobile SAST on the binary and Mobile DAST on the running app, from CI/CD on every build. Details | Findings with decompiled source context, traffic, stack traces and screenshots |
| Third-party and open-source componentsJS2 7.7.5(c), 7.7.6(b)(iii) | Fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Details | Mapped vulnerabilities with upgrade or replace recommendations, and closure tracked across releases |
| Software inventory and versionsJS1 9.3(a); JS2 7.1.1(d) | Lists the SDKs and native libraries in each release with their versions, and shows which backends the app and its SDKs talk to. Details | Component identity, version and location in the app bundle, per release |
| Credentials and privileged accessJS2 7.2.2, 8.2 | Finds API keys, tokens and credentials in the app package and validates whether they work. Details | Validated secrets, with the permissions and services they expose |
| MFA and sessions on internet-facing accountsJS2 8.3, 7.2.2(a) | Logs in with one-time codes, tests MFA enforcement and step-up flows, then logout, token refresh, timeouts and session invalidation. Details | Findings on login, step-up and session flows, with reproduction steps and request logs |
| Data protection on the device and in transitJS2 7.2.3; POPIA s19 | Looks for tokens and personal data in storage, caches, logs and screenshots, and checks transport protections. Details | File system evidence showing what was written, where and when |
| Cryptography and tamper resistanceJS2 7.2.6 | Attempts to bypass root and jailbreak detection, anti-tampering and TLS pinning at runtime. Details | A hardening score, with bypass evidence for each protection that failed |
| Remediation deadlines and retestingJS2 7.7.6, 8.5 | Groups findings into tickets, retests after the fix, and tracks component closure across releases. | Ticket history and retest result for each finding |
Ostorlab tests controls in the app and its APIs. Governance, SOC monitoring, incident response and reporting, simulation exercises, backups and recovery, cloud contracts and physical security stay with your teams.
Joint standard controls to test in your mobile app
A practical list for security and technology risk teams, based on Joint Standard 2 of 2024, Joint Standard 1 of 2023 and POPIA.
Mobile app in scope
Put the mobile app in the scope of your vulnerability assessment and penetration testing programme, with a frequency and a pre-release step.
Internet-facing APIs
Assess the APIs the app calls as internet-facing systems: authorization, tokens, session handling and requests for other customers' data.
Every release
Run automated application security testing on every build and scan each store release, not only the version you tested last quarter.
Components and deadlines
Keep a versioned list of the SDKs and libraries in each release, and set fix deadlines by severity.
Secrets and credentials
Check the app package for API keys, tokens and credentials, rotate any that work, and test privileged access paths.
MFA and sessions
Verify that internet-facing logins require the second factor on the server, and test token refresh, timeouts and session invalidation.
Data and tamper protections
Look for tokens and personal data in storage, caches, logs and screenshots, and test root, jailbreak, tamper and pinning protections on a modified build.
Report, retest and notify
Track findings to closure with retests, rehearse the material incident notification through the determined template and portal, and keep the POPIA breach notification path to the Information Regulator ready.
A suggested list, not a joint standard template. POPIA notification duties belong to your information officer. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- Mobile Agentic Deep ScanAI agents pentest the store build on every release, with a working exploit you can replay for each AI-agent finding.Learn more
- Authenticated testingTest login, one-time codes and step-up flows with your test accounts.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.Learn more
- Mobile SASTBinary-based static analysis of APK, AAB and IPA files, with taint analysis across the app and its embedded SDKs.Learn more
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.Learn more
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.Learn more
- Bring your own AI keyRun AI-agent scans on your own AI provider key with a spend cap per scan, so usage follows your internal policies.Learn more
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- Joint Standard 2 of 2024 - Cybersecurity and Cyber Resilience Requirements for Financial InstitutionsFSCA and Prudential Authority, published 17 May 2024, effective 1 June 2025. Fundamentals, cybersecurity hygiene practices, testing (7.7) and notification of material incidents (9). Applies to banks, mutual banks, insurers, market infrastructures, pension funds and the other institutions listed in the standard
- Joint Standard 1 of 2023 - Information Technology (IT) Governance and Risk Management Requirements for Financial InstitutionsFSCA and Prudential Authority, published 10 November 2023, commenced 15 November 2024. IT risk management framework (7), IT operations (9), handling of sensitive or confidential information (10), IT assurance (14) and notification (15)
- Joint Communication 5 of 2024 - Publication of the Joint Notice 1 of 2024 (commencement)FSCA and Prudential Authority, published 28 June 2024. Joint Notice 1 of 2024 determines 1 June 2025 as the effective date of Joint Standard 2 of 2024, under its paragraph 10.2
- Joint Notice 2 of 2026 - Determination of the Notification Template for Material IT and Cyber IncidentsFSCA and Prudential Authority, dated 31 August 2026 and published with Joint Communication 5 of 2026, takes effect 1 September 2026. Made under paragraph 15.1 of Joint Standard 1 of 2023 and paragraph 9.1 of Joint Standard 2 of 2024; banks submit on the Umoja Portal
- Joint Communication 2 of 2025 - Cloud computing and data offshoringFSCA and Prudential Authority, dated 25 July 2025, published on the Prudential Authority website on 28 July 2025. Recommended practice for cloud computing and data offshoring, and notice that a Joint Standard is being developed
- PA Directive 3 of 2018 - Cloud computing and the offshoring of dataPrudential Authority, published 6 September 2018 for banks, with Guidance Note 5 of 2018. Recalled by Joint Communication 2 of 2025
- Protection of Personal Information Act 4 of 2013 (POPIA)Republic of South Africa, gazetted 26 November 2013, commenced 1 July 2020 with the last commencement provisions in 2021. Sections 19, 21 and 22 (security safeguards, operators and breach notification) and section 72 (transfers outside the Republic)
- Fact Sheet: Handling of Security CompromisesInformation Regulator, 19 August 2025. POPIA has no risk threshold for reporting security compromises; report to the Regulator and the data subjects as soon as reasonably sure, through the eServices portal
Frequently asked questions
Straight answers on coverage, setup, and how results reach your team.
Can't find your answer? Book a demo or contact us.
Assess your mobile banking app the way the joint standards describe
Start with a free scan of your app from the store, or book a demo to run logged-in tests of your app and APIs with our team.