From Cybersecurity Policy to Proof: 8 Controls Kenyan Financial Institutions Should Be Able to Evidence

Cybersecurity policies matter. Security technologies matter. Audits matter. But none of them, by themselves, answer one of the most important questions facing an organisation:

This distinction is particularly important for SACCOs and microfinance institutions as financial services become increasingly dependent on mobile applications, digital channels, cloud platforms, APIs, third-party fintech integrations and interconnected ICT infrastructure.

It also applies well beyond financial services. Healthcare organisations, NGOs, government institutions and enterprises increasingly operate technology environments in which identity, data, applications, suppliers and infrastructure are interconnected.

A policy may describe what should happen. An implemented control shows what the organisation has done. Evidence begins to demonstrate what is actually happening. Technical validation goes one step further: it tests whether selected controls perform as expected when challenged.

That changes the cybersecurity conversation from “Do we have the control?” to “How do we know the control works?”

1. Identity & MFA — Who Can Actually Get In?

Identity is becoming one of the most important security boundaries in modern organisations. Employees, administrators, contractors and third-party providers access email, VPNs, cloud services, financial applications, databases, infrastructure and administrative consoles using digital identities.

Compromise one sufficiently powerful identity and an attacker may no longer need to defeat the organisation's perimeter. That makes the statement “we have MFA” insufficient.

• Is MFA enforced on critical systems, remote access and sensitive accounts?
• Are privileged and administrative accounts protected more strongly?
• Are dormant and former-user accounts disabled promptly?
• Do access rights still match current responsibilities?
• Are failed logins and suspicious authentication events monitored?
• Are periodic access reviews actually performed and evidenced?

Evidence may include identity-provider configurations, authentication logs, account inventories, access-review records and controlled technical validation.

2. Privileged Access — Who Holds the Keys to the Kingdom?

Not every user account represents the same level of risk. Administrators can often change system configurations, create users, access sensitive information, disable security controls and perform actions unavailable to ordinary employees.

An organisation should therefore be able to answer:

• Who currently has privileged access and why?
• When was that access last reviewed?
• Is MFA required for privileged activity?
• Are privileged credentials shared?
• Can administrator activity be attributed to an individual?
• What happens when an administrator changes role or leaves?

This becomes particularly important where external technology vendors support critical infrastructure. An external administrator with persistent elevated access can carry substantial risk even though the individual is not an employee.

3. Endpoint Protection — Installed Does Not Mean Protected

It is easy to prove that endpoint-security licences were purchased. That does not necessarily prove that the organisation's endpoints are protected.

Imagine an organisation with 1,000 endpoints. If 900 are correctly protected and reporting, stating simply that “endpoint protection is implemented” conceals the more important question: what is happening on the remaining 100?

Useful evidence may include endpoint-management dashboards, coverage reports, policy configurations, alert records, investigation records and selected technical testing.

4. Backup & Recovery — A Successful Backup Is Not a Successful Recovery

Backups are among the controls organisations frequently assume are working. Backup jobs run. Reports show green. Data is being copied. But the purpose of backup is not to create a successful backup log. It is to enable the organisation to recover.

• Which critical systems and data are backed up?
• How frequently, and for how long, are backups retained?
• Who can modify or delete backups?
• Are backups appropriately separated from production systems?
• Has restoration actually been tested?
• How long did recovery take, and was the restored data usable?

For SACCOs, this is especially relevant because disaster recovery and business continuity sit within the wider ICT-governance and resilience responsibilities expected of management and boards.

5. Incident Response — A Plan That Has Never Been Tested Is Still a Hypothesis

Many organisations have incident-response policies. The harder question is what actually happens when a serious incident occurs.

At 2:00 a.m., who can isolate a critical server? Who investigates? Who preserves evidence? Who contacts management? Who engages external technical support? Who determines whether customers, regulators or other stakeholders may need to be notified?

Evidence of incident-response capability should therefore go beyond the existence of a document. It may include defined responsibilities, escalation procedures, incident records, tabletop exercises, technical simulations, communication procedures, lessons learned and evidence that corrective actions were completed.

This also intersects with Kenya's data-protection obligations. The Office of the Data Protection Commissioner maintains a formal process for reporting personal-data breaches, reinforcing the need for organisations to identify, investigate, contain and document relevant incidents.

See the ODPC's official Report a Data Breach guidance.

6. Third-Party Access — Your Security Boundary May Extend Beyond Your Organisation

Modern financial institutions rarely operate technology entirely themselves. They may depend on core banking providers, fintech companies, mobile platforms, payment providers, software developers, cloud providers, managed-service providers, consultants and infrastructure vendors.

Every trusted connection potentially expands the organisation's technology boundary.

• Which third parties can access the environment?
• What can they access, and why is it required?
• How are they authenticated?
• Is their activity logged and reviewed?
• Is access limited by role, system, time and business need?
• What happens when the contract or assignment ends?

For SACCOs, outsourcing does not remove management accountability. SASRA's governance guidance keeps responsibility for monitoring ICT governance with the SACCO's board and management even where ICT services are delegated to third parties.

SASRA has also issued specific minimum requirements concerning engagement of third-party fintech providers. Vendor due diligence before procurement is therefore only one part of the problem; cyber-risk assurance should continue throughout the relationship.

See SASRA's official Circular on Third-Party Fintechs.

7. Monitoring & Detection — Would You Know If Something Was Happening?

Preventive controls cannot guarantee that every attack will be stopped. Eventually every organisation must answer another question:

Security monitoring may involve authentication activity, privileged actions, endpoint alerts, network events, application activity, cloud services and changes to critical systems. But collecting logs is not the same thing as monitoring.

Management should understand which critical systems generate security logs, whether those logs are protected, which events generate alerts, who receives them, what happens after an alert and how unresolved events are escalated.

This is also where cybersecurity begins to move from periodic assessment toward continuous visibility and assurance.

8. Vulnerability Remediation — Finding the Problem Is Only Half the Job

A vulnerability assessment or penetration test can reveal significant security weaknesses. But identifying a vulnerability does not reduce the risk. Remediation does.

Material findings should have an identified owner, severity, remediation action, target date, current status and supporting evidence. Where appropriate, remediation should then be independently retested.

An organisation may report “90% of vulnerabilities have been closed.” That sounds reassuring. But what if the remaining 10% contains the most exploitable attack path into a critical system?

The stronger management questions are: what remains unresolved, what business systems are affected, who owns remediation, why is it still open, and has the corrective action been technically verified?

For a deeper look at this lifecycle, read Your VAPT Report Says “High Risk.” What Happens Next?

From Controls to Assurance

The eight areas above reveal a broader cybersecurity principle. There is a meaningful progression between a control being declared, documented, implemented, evidenced and technically validated.

This should not be interpreted as an official regulatory maturity model. It is a practical assurance lens.

An organisation may declare that a control exists. Documentation can describe how it should operate. Implementation establishes that something has been deployed. Evidence provides information about actual operation. Technical validation can then challenge whether selected controls perform as expected.

This evidence-led philosophy is reflected in the broader architecture of the proprietary Quest Cyber Risk Assurance Framework™ (Q-CRAF™).

Q-CRAF™ does not reduce organisational cyber risk to one vulnerability score. Its current assurance architecture considers multiple domains, including governance and leadership, asset and data inventory, identity and access management, endpoint protection, network/cloud/physical IT security, core banking and digital channels, data protection/backup/recovery, monitoring and detection, incident response/BCP, and third-party/vendor risk.

Its executive assurance model also recognises that an aggregate score should not automatically override material control failures. Critical gates, mandatory controls, evidence quality, regulatory-control assurance and governance may affect progression independently of the overall score.

The Board Question Should Become: “Show Me the Evidence”

A board does not need to become a penetration-testing team. A CEO does not need to interpret firewall logs. A risk committee does not need to administer MFA. But leadership should be capable of asking better questions.

This does not turn cybersecurity into a paperwork exercise. Done properly, it does the opposite: it connects governance with what is actually happening inside the technology environment.

Cyber Resilience Is Demonstrated, Not Declared

An organisation can have cybersecurity policies. It can buy sophisticated security products. It can conduct audits. It can commission penetration tests. It can outsource security operations. All of those may be valuable.

But meaningful assurance requires another question:

That is the transition from cybersecurity policy to cybersecurity proof.

For SACCOs and microfinance institutions, it can strengthen the conversation between ICT, risk, management and the board. For corporate and enterprise environments, the same principle helps transform cybersecurity from a collection of technologies into a measurable risk-management discipline.

And for any organisation becoming increasingly dependent on digital services, that evidence can be the difference between assuming a control works and knowing why you trust it.

Editorial & Regulatory Note: This article is provided for cybersecurity education and risk-management awareness. It does not constitute legal, regulatory, compliance, insurance or underwriting advice. Q-CRAF™ is a proprietary Quest Technologies framework and is not a SASRA framework, SASRA certification, regulatory rating or regulatory approval.