Joint Standard 2 has been in force for 11 months. Most SA financial institutions are still not compliant. Here is the enforcement reality

Joint Standard 2 of 2024, the FSCA and Prudential Authority’s cybersecurity and cyber resilience standard, commenced on 1 June 2025. Financial institutions were afforded 12 months from that date to comply fully. That window closes on 1 June 2026.

In November 2025, the FSCA and PA published a joint report summarising what they found when they asked financial institutions how they were tracking against the Standard. The findings are not reassuring. The Werksmans review of the 2025 regulatory year concluded that *”Enforcement action by the PA and FSCA is likely in 2026, and it is possible that significant fines may be issued for non-compliance, similar to those issued for Financial Intelligence Centre Act / FICA non-compliance.”*

This is not a blog post about what JS2 requires. The Standard itself, the Michalsons summary, and the Moonstone guidance notes cover that ground well. This is a post about what I am finding in the field with 45 days to go, and where I would focus if you are behind.

The pattern is the same almost every time. The organisation has strong technical controls in one or two domains — usually network security and endpoint protection, because these are where vendors sell hardest. They have weaker controls in three domains that JS2 treats as equally important: identity and access management, third-party risk, and cyber resilience testing. And they have almost no documented evidence that would satisfy a regulator asking *”show me how you comply.”*

The Standard is not primarily about whether you have controls. It is about whether you can prove they work, document who owns them, and demonstrate that you test them. In practice this is where most remediation work now sits.

1. Incident notification readiness

JS2 requires that material cyber incidents be reported to the responsible authority within 24 hours. Not 72. Not “as soon as reasonably practicable.” Twenty-four hours from the point at which the incident is classified as material.

Two questions to answer internally this week:

– Who decides whether an incident is material, and what is the documented threshold?
– If that person is on leave, who decides?

The second question is where most institutions fail. The material-incident decision is a judgement call, and it needs named alternates with the same authority, not a generic *”the CISO or their delegate.”*

2. Identity and access management evidence

The Standard requires that access to information is limited to authorised users and devices. In cloud-native and hybrid environments, this means you need to be able to show, on demand, who has access to what, when that access was granted, when it was last reviewed, and who approved it.

Most institutions cannot produce this on demand. They can produce it after a week of queries and spreadsheet joins. That is not the same thing.

If you run M365 or Google Workspace with a patchwork of app-specific SSO and SCIM, consolidating identity into a single governance layer — whether that is Okta, Entra ID Governance, or a similar platform — is no longer a nice-to-have. It is the shortest path to being able to answer the regulator’s first question.

3. Third-party and service provider risk

JS2 requires financial institutions to manage cybersecurity risks arising from juristic persons structured under a bank, insurer, or insurance group when applying the Standard. In plain language: your vendors, your outsourced service providers, your cloud platforms, and your fintech partners all fall within scope.

What I see: institutions with a supplier register that lists 80 vendors, of which maybe 15 have been through any form of cybersecurity due diligence in the last two years. The rest are assumed secure because they are large, or known, or because the contract was signed before the current CISO arrived.

The remediation is not to audit all 80. It is to triage. Classify each vendor by the sensitivity of data they process and the criticality of the service they provide. Focus due diligence on the top quartile and document why the rest are lower risk. A defensible triage is better than an undefended universal review.

4. Penetration testing and vulnerability management

JS2 explicitly requires regular penetration testing and vulnerability assessments, with swift remediation. The Standard goes further in some contexts — the responsible authority may specify black-box, grey-box, and white-box testing for critical IT systems.

Two things I consistently find that weaken the evidence base here:

First, the last pentest is older than twelve months. For an organisation that deploys code weekly, a twelve-month-old pentest is a historical document, not a current assurance statement. I have written separately about why annual pentests are structurally misaligned with CI/CD environments.

Second, the pentest report is closed without a documented remediation trail. Findings get noted, some get fixed, and the tracker becomes a PDF filed in SharePoint. There is no auditable trail showing that the finding was triaged, assigned, remediated, and retested.

5. Board-level cyber governance

This is where I see the most defensive posture from leadership, and where the regulatory focus is growing. JS2 requires a cybersecurity strategy that is reviewed regularly and aligned with the overall business strategy. That implies the board has seen it, asked questions about it, and can describe what it covers.

In too many boardrooms, cybersecurity is an item on the risk committee agenda that the CISO presents once a quarter and nobody engages with substantively. Under JS2, that posture does not hold. The regulator will want to see evidence that governance is active, not ceremonial.

The practical fix is to change how cyber is presented to the board. Stop reporting on incident counts and patching percentages. Start reporting on the residual risk position against the institution’s stated risk appetite, the top three unresolved risks, and the status of the control evidence that would be required if the regulator asked tomorrow. If the board cannot engage with that view, the problem is the view, not the board.

What enforcement will look like

The FSCA has not yet published a JS2-specific penalty matrix. It is unlikely to. Enforcement under the Financial Sector Regulation Act gives the authorities broad discretion on administrative penalties, and the comparison the legal commentary keeps making is to FICA enforcement, where fines have reached into the tens of millions of rand for institutions with material weaknesses.

The practical question is not *”how large could the fine be?”* It is *”what is the likelihood that the first round of enforcement targets institutions in our category?”* The answer depends on the sector — banks and larger insurers will get scrutiny first — but fintech and smaller financial services firms should not read that as permission to wait. Reputational consequence is often the sharper edge than the administrative one.

—

The honest executive view

If your institution has invested seriously in cybersecurity over the last two years — meaning an identified CISO or equivalent, a documented strategy, an active governance cadence, and independent assurance of your controls — you are probably in a recoverable position with six weeks of focused work.

If your institution has treated cybersecurity as an IT line item, with controls owned by infrastructure teams and no independent assurance, the runway is shorter than it looks. The first engagement to have is not with a compliance consultancy. It is an internal conversation about whether the current posture can be credibly described, documented, and defended to a regulator who has now been waiting 11 months to ask.

JS2 is not a compliance burden invented by regulators who do not understand how software is built. It is a response to a financial system that has been repeatedly and publicly breached. The Standard sets a floor, not a ceiling. Most of the institutions I work with know this. The question is whether the work to get there gets done in the next six weeks, or in the six weeks after a material incident.