1.1SASRA instruments

Interpretation: Several key numbers come from secondary reports of Circular SASRA/GG/1/2023: the 12-hour reporting window, the 10% guarantee and the audit frequency. Get the PDF from SASRA's “Guidelines & Circulars” page and put its exact terms into every integrator contract. The 2026 circular's warning about officer liability means directors and CEOs who sign non-compliant vendor contracts are personally exposed.

Losses from vendor contracts that breach Circular SASRA/GG/1/2023 “shall be visited upon the officers of the SACCO Society responsible.”SASRA holiday cyber circular, 2026

Pending reform: The Sacco Societies (Amendment) Bill 2025 was introduced on 10 June 2025. It proposes a secondary co-operative tier, a Central Liquidity Fund, deposit protection, and a wider SASRA mandate. Government has also floated shared digital platforms “to reduce technology costs and enhance cyber resilience.” In June 2026 the Cabinet Secretary told SASRA to “prepare for an expanded mandate.” Expect a formal SASRA ICT/cyber risk guideline to follow; none had been published as of this writing.

1.2Data Protection Act 2019 (DPA) and ODPC

1.3Computer Misuse and Cybercrimes Act 2018 (CMCA), as amended 2025

1.4National KE-CIRT/CC

1.5Central Bank of Kenya (payments and mobile-money integrations)

SACCOs are not supervised by the CBK. However, the mobile-money operators, aggregators and payment gateways they connect to are CBK-authorised Payment Service Providers (PSPs), and SASRA's circular requires integrators to comply with the National Payment System Act.

1.6AML/CFT obligations touching digital channels

3.1What the board must do

• Assign oversight to a Board Risk Committee or a combined Audit & Risk Committee. Put cyber on the agenda at least every quarter, and hold a special session after any material incident.
• Approve a cyber risk appetite statement. A sample is set out below.
• Approve the ICT strategy, ICT/cyber policy set and budget each year. Aim for a defined share of the ICT budget for security; many peers use 10–15%.
• Require independent assurance: an annual ICT audit by internal audit or an external firm, penetration testing of internet-facing and mobile channels, and evidence of vendor audits under SASRA/GG/1/2023.
• Approve every critical outsourcing and integrator contract only after legal and ICT confirm it complies with the circular.
• Build competence: at least one director with ICT or risk expertise, or an independent co-opted adviser, and yearly board cyber training.
• Take part in one tabletop exercise a year, for example “paybill float drained on Easter Saturday.”

A sample cyber risk appetite statement

3.2Board checklist (use quarterly)

• Has a named senior manager been accountable for information security this quarter, and does the head of ICT report to the CEO, with a dotted line to the Risk Committee?
• Have we received a dashboard of key risk indicators (see Part 7) and explanations for anything outside appetite?
• Are all integrator and core banking contracts compliant with SASRA/GG/1/2023: audits, 12-hour reporting, bank guarantee of at least 10% of float, SASRA access rights?
• Were offline backups taken and test-restored in the last quarter, with evidence?
• Is the SACCO registered with the ODPC, with a data protection officer (DPO) or privacy lead named, and have DPIAs been done for new digital products?
• Have all incidents, including near-misses, been reported to us, and did we meet SASRA, ODPC (72-hour) and KE-CIRT reporting duties?
• Has the incident response and BCP/DR plan been tested in the last 12 months?
• Are open audit findings on ICT being closed on schedule?
• Do we know our cyber insurance position: what is covered, what is excluded, and the limits?

5.1Identity and access management (highest priority)

• MFA everywhere it matters: email, VPN, remote access, core banking admin and approver roles, cloud consoles, bank and treasury portals, M-Pesa org portal and API management. Prefer app-based or FIDO2 authenticators over SMS OTP, because SIM swaps defeat SMS.
• Privileged access:
  • Separate admin accounts from daily-use accounts.
  • No shared “admin” or “sa” logins.
  • Keep privileged credentials in a password vault.
  • Grant just-in-time elevation.
  • Record database-level and OS-level admin sessions.
• Core banking segregation of duties (SoD):
  • Maker-checker on member creation, account-detail changes (phone number, bank account, next of kin), loan disbursement, write-offs, GL journals and interest parameters.
  • Dual control on paybill/B2C float top-ups and withdrawals above set thresholds.
  • Block direct database writes by application admins in production. Any “back-end fixes” need change tickets and a second approver, and must be logged.
  • Run a quarterly SoD conflict report: users with both create and approve rights, and IT users with transaction rights.
• Joiner/mover/leaver: disable accounts on the day someone leaves. Reconcile HR records against system users every month. Flag dormant accounts after 30 days.

5.2Securing the core banking system

• Harden the database server. Put it on an isolated VLAN reachable only from application servers and a jump host. No internet access.
• Turn on the system's full audit trail (DT Reg. 4(3)(b) requires one) and forward it to a log store that system admins cannot modify.
• Run a daily independent reconciliation of core banking against bank statements and paybill/M-Pesa statements, done by Finance, not IT. Investigate breaks the same day.
• Build integrity alerts for:
  • balance changes without a matching transaction;
  • after-hours parameter changes;
  • mass phone-number re-linking;
  • loans to recently joined or dormant members.
• Test every upgrade in a non-production environment. Mask member data in test copies.

5.3Mobile, USSD, app and M-Pesa paybill/API integration security

• API security:
  • Mutual TLS or IP allow-listing for Daraja/B2C callbacks.
  • Validate callback signatures and amounts against your own initiated requests.
  • Rotate consumer keys and secrets and store them in a vault, never in code.
  • Rate-limit and alert on unusual B2C volume.
• Float controls:
  • Keep working float low and sweep excess to the bank.
  • Set per-transaction, per-member and daily caps on B2C.
  • Require manual approval above the threshold during holidays and at night.
• App security:
  • Certificate pinning, root/jailbreak detection, device binding, and no sensitive data cached on the device.
  • Independent mobile app penetration test before launch and every year after.
• USSD and SIM-swap defence:
  • Check SIM-swap status (via MNO APIs where available) before high-risk transactions.
  • Cool-off period after a PIN reset or phone change.
  • Step-up verification for first-time withdrawals to new destinations.

5.4Endpoint and network security

• Use endpoint detection and response (EDR) or at least managed next-gen antivirus on all servers and PCs, with central alerting.
• Use application allow-listing on teller and back-office PCs where you can. Block unapproved remote-access tools (AnyDesk, TeamViewer, etc.) by policy and at the firewall.
• Segment the network into user, server, core banking database, ATM/branch and guest/Wi-Fi zones. Only allow traffic that is explicitly permitted.
• Harden the firewall and VPN: MFA, geo-restrictions, and no management interfaces exposed to the internet. Scan your external attack surface every month.
• Enforce full-disk encryption on laptops. Block or control USB storage.

5.5Backups and ransomware resilience

Follow the 3-2-1-1-0 pattern:

• This meets and goes beyond DT Reg. 76(2) (daily copy to a fireproof safe, weekly off-site) and SASRA's offline-backup directive.
• Protect backup admin credentials with separate accounts and MFA. Backup servers should not be on the domain.
• Do a full restore test of core banking every quarter, timed against your RTO and RPO. Keep the evidence for the board and SASRA inspections.
• Keep a pre-holiday checklist: a verified offline backup before every long weekend, especially in the 12 hours before a holiday begins, which SASRA identifies as peak risk.

5.6Patch and vulnerability management

5.7Logging, monitoring and detection

• Centralise logs from core banking, AD, firewall, VPN, email, EDR and the integrator API gateway. Keep them at least 12 months online, and longer in archive, to support investigations and AML record-keeping.
• Arrange 24/7 monitoring as SASRA requires. For small and medium SACCOs this means an outsourced SOC or MSSP, or a vendor monitoring contract, plus a named on-call SACCO officer with authority to suspend channels.
• Priority detections:
  • privileged logins after hours;
  • new admin accounts;
  • core banking parameter changes;
  • B2C spikes;
  • large volumes of phone-number changes;
  • logins from unusual countries;
  • remote-tool execution;
  • backups being deleted.

5.8Email and phishing defences

• Publish SPF, DKIM and DMARC records, moving to p=reject. Use advanced attachment and link filtering, and tag external email.
• Require call-back verification using a known number for any change to payment instructions (BEC defence).
• Run monthly phishing simulations. Track click rate and reporting rate.

5.9Physical security at branches

• Keep server and communications rooms locked, with access logs and CCTV. Protect equipment against power, fire and water, and provide standby power (DT Reg. 78(h)).
• Store backup media in a fireproof safe (Reg. 76(2)). Use clear-screen and clear-desk rules at tellers. Lock network ports in public areas.

5.10Staff training

• Train new staff at induction and all staff every year. Give role-specific modules to tellers (social engineering, SIM-swap requests), finance (BEC), IT (secure admin) and the board.
• Include insider-threat awareness and whistleblowing channels. Make sure staff know that colluding with vendors is a criminal offence under the CMCA.

5.11Incident response and BCP/DR

• Keep a written incident response plan (see the Part 7 playbook) and a contact tree covering the core banking vendor, integrator, bank, Safaricom, insurer, forensic firm, SASRA, the ODPC, KE-CIRT and the DCI.
• Keep pre-authorised kill switches: the ability to suspend B2C, the mobile app or USSD within minutes, without waiting for vendor sign-off.
• BCP: a documented alternative site (DT Reg. 78(d)), manual fallback procedures for tellers, and member communication templates.

5.12Cyber insurance

• The Kenyan market is maturing. In December 2024, CIC General's MD said SACCOs and banks top the list of organisations showing more interest in cyber insurance. The Association of Kenya Insurers did not yet track uptake.
• SASRA's risk guideline says insurance should be “complementary to, rather than a replacement for” controls. Buy cover for incident response costs, business interruption, data breach liability and regulatory defence. Check carefully for exclusions on insider fraud (often only covered under fidelity or crime policies), social engineering, unpatched systems and war or state-actor events.
• Pair cyber cover with a fidelity guarantee or crime policy, because insider fraud is the SACCO's largest single exposure.

7.3Self-assessment

Score each item: 0 = not in place, 1 = partial or informal, 2 = documented and implemented, 3 = implemented, tested and evidenced. Scores below 2 on items marked ★ are priority gaps.

7.4Incident response playbook: “Unauthorised funds movement via digital channel”

1. 0–1 hour

   Detect and triage

   A reconciliation break, B2C spike, member complaint or vendor alert comes in. The on-call officer confirms it and opens an incident record, and the CEO is informed.

2. within 1 hour

   Contain

   • Use the kill switch to suspend the affected channel (B2C, app, USSD).
   • Freeze suspect member and staff accounts.
   • Revoke API keys and vendor remote sessions, and reset privileged credentials.
   • Ask the bank and Safaricom to freeze or recall the receiving accounts and wallets.
3. before any rebuild

   Preserve evidence

   Snapshot logs (core banking audit trail, API gateway, firewall, EDR). Image affected machines. Keep a chain-of-custody record. Do not wipe or rebuild anything before imaging.

4. same day → 72 h

   Notify

   • Follow the matrix in Part 4.5: SASRA; the ODPC within 72 hours if personal data is involved; KE-CIRT/CC; the DCI; the insurer; FRC if needed.
   • Board chair notified the same day.
5. ongoing

   Investigate

   Establish the root cause (insider, vendor, credential theft, API flaw), scope, and amount lost. Bring in a forensic firm, approved by the insurer if you are claiming. Invoke the vendor's bank guarantee if the vendor was at fault.

6. staged

   Eradicate and recover

   Patch or fix the weakness, rotate all related secrets, and restore from known-good backups if data integrity is in doubt. Reopen the channel in stages, with lower limits.

7. throughout

   Communicate

   Give members factual messages about whether their funds are safe and what action they should take. Brief staff. Prepare a media holding statement.

8. within 14 days

   Post-incident review

   Write a report for the board covering lessons, control changes, disciplinary or legal action, and updated KRIs.

Build variants for ransomware (isolate, do not pay without board, legal and insurer consultation, restore from offline backups), data breach (the ODPC 72-hour clock is the critical path) and BEC (bank recall within hours matters most).

7.5Sample key cyber risk indicators (KRIs)

7.6Local resources

• SASRA (sasra.go.ke): regulations, the Risk Management and MIS guidelines, circulars including SASRA/GG/1/2023 and the holiday cyber alerts, and the DTS/NW-DTS returns portals.
• ODPC (odpc.go.ke): registration portal, breach notification portal, guidance notes, and the Data Protection (General) Regulations 2021.
• National KE-CIRT/CC (ke-cirt.go.ke, housed at the Communications Authority): incident reporting, advisories, quarterly Cyber Security Reports, and the text of the 2025 CMCA amendment.
• DCI (including its cybercrime units) and the Banking Fraud Investigations Unit / Cyber Fusion Unit at CBK.
• Financial Reporting Centre: goAML registration and reporting.
• Central Bank of Kenya: the PSP Cybersecurity Guideline (2019) and the banking Guidance Note (2017), useful as benchmarks.
• Apex and sector bodies: Cooperative Alliance of Kenya (CAK); KUSCCO (has published SACCO cybersecurity readiness research); Sacco IT Professionals Association (SITPA); ISACA Kenya Chapter.
• Research and training: Serianu's Africa Cybersecurity Report (Kenya editions) and Cyber Shujaa programme; the Co-operative University of Kenya; ODPC-accredited data protection trainers; CA/KE-CIRT capacity-building events.