Most financial services providers who have taken Joint Standard 1 and Joint Standard 2 seriously have arrived at roughly the same place. There is a policy suite, often a substantial one, produced by a consultant over a number of weeks and signed off by the governing body. There is an information security policy that specifies multi factor authentication on all remote access. There is an access control policy that requires privileged accounts to be reviewed. There is a backup policy that commits the business to a tested restoration cycle.

What there very often is not, is any evidence that a single one of those things is true.

This is the quiet structural problem with how information security compliance has been sold in South Africa. The policy is the deliverable, the consultant’s engagement ends when it is signed, and the technical implementation is left to an IT provider who was frequently not in the room when the policy was written and who has never been shown the document that now describes their obligations.

Why the gap opens

It is worth being precise about how this happens, because it is not the result of anybody behaving badly. It is a structural consequence of how the work is divided.

A compliance consultant writes policies. That is their discipline and they are usually good at it. They interview the business, establish the regulatory footprint, and produce a document set that would satisfy a reviewer reading it in isolation. What they generally cannot do, because it is a different profession, is log into a firewall and confirm that the rule base matches what the policy describes, or check whether multi factor authentication is enforced for every user or merely available to them.

An IT provider configures systems. That is their discipline and they are usually good at it too. What they generally do not have is the policy suite, an understanding of which specific clauses of Joint Standard 2 create a technical obligation, or a mandate to go looking for the difference between what the business has committed to in writing and what is actually running.

Neither party is failing. The work simply falls between them, and it stays there, invisible, until somebody asks for evidence rather than for documentation.

What the gap looks like in practice

These are the discrepancies that appear most consistently when the policy suite is checked against the environment it describes.

Multi factor authentication is described as mandatory and is in fact enabled for most staff but not for service accounts, shared mailboxes or the two directors who found it inconvenient. The policy says all users. The environment says most users, and the exceptions are frequently the highest value targets in the business.

Email authentication is specified in the policy, and the domain has a partial configuration where one of the three mechanisms is present, another is misconfigured, and the third was never implemented at all. The policy commits the business to protecting against domain impersonation. The configuration does not deliver it.

The backup policy commits to a tested restoration cycle. Backups are running. Nobody can name the date of the last successful restoration test, and in a meaningful proportion of cases nobody has ever performed one, which means the commitment in the policy has never been met since the day it was signed.

Endpoint protection is described as deployed across all devices. It is deployed across the devices that were present when the rollout happened, and not across the eleven that have been issued since, because no process connected the policy to the onboarding of new equipment.

Privileged access is described as reviewed. There is no record of a review having taken place, which for evidentiary purposes is identical to it not having happened.

Why this matters more than it used to

Joint Standard 2 is explicit that a financial institution must maintain a cybersecurity strategy supported by controls, incident response capability, staff awareness and regular controls assurance. That final phrase is the one that changes the position, because assurance is a process of verification rather than a document, and it cannot be satisfied by a policy that asserts a control exists.

Joint Standard 1 places the governance obligation on the governing body, meaning the directors or the owners personally, and the FAIS General Code of Conduct has for years required providers to employ appropriate technological systems to eliminate risk to clients. The direction of travel across all of it is the same. The obligation is not to have described a control. It is to have one, and to be able to show it.

The question to put to your own environment

If you have a policy suite already, and many providers do, there is a straightforward exercise that will tell you where you stand within an afternoon.

Take five specific technical commitments out of your own documents, ideally multi factor authentication coverage, email authentication configuration, endpoint protection deployment, the date of the last restoration test, and the date of the last privileged access review. Send those five to whoever runs your systems and ask for evidence rather than for confirmation, meaning a screenshot, an export or a report rather than an assurance that it is fine.

The gap between what comes back and what your policies say is your actual compliance position, and it is the position a reviewer would find. Discovering it yourself, at a time of your own choosing, is considerably cheaper than the alternative.

Siyaxhuma verifies each technical control your policy suite requires and documents the result in a signed IT Control Evidence Report, because we deliver both the compliance function and the IT capability rather than referring one out to the other. Get in touch to discuss where your environment currently sits.