Most SACCOs experience technology risk as a series of surprises — a channel outage, a fraud loss, a regulator’s finding. Mature institutions experience it as a managed portfolio: identified, scored, owned, treated and reported. This guide sets out how a deposit-taking SACCO builds that discipline, step by step, in a way a board elected from the membership can genuinely govern.

Technology Risk Governance: Who Owns What

Technology risk management fails most often not for lack of tools but for lack of ownership. A workable SACCO governance model uses three lines of defense: management and ICT own and operate controls (first line); a risk or compliance function maintains the framework, challenges scoring and aggregates reporting (second line); and internal audit provides independent assurance (third line). The board’s risk committee approves the risk appetite, receives quarterly technology risk reports and holds management accountable for treatment actions.

In smaller SACCOs where one officer wears several hats, the principle still holds: whoever scores a risk should not be the only person who reviews that score, and the person operating a control should not be the one attesting to its effectiveness. Boards should also invest in their own technology literacy i.e directors elected from the membership cannot challenge what they do not understand.

Technology Risk Identification

Identification should be systematic, not anecdotal. Practical sources for a SACCO include:

Express each risk as a cause-event-consequence statement: “vendor remote access is permanently enabled and not monitored (cause) which may lead to an attacker accessing the core banking system (event), resulting in fraudulent transactions and member fund loss (consequence).” Vague entries like “cybersecurity risk” cannot be scored, owned or treated.

Risk Assessment Methodology

A consistent methodology turns a list of worries into comparable, decision-ready scores. The sequence every SACCO should follow:

Inherent Risk Calculation

Use a 5×5 scale: Inherent Risk = Likelihood (1–5) × Impact (1–5), giving scores of 1–25. Impact should be assessed across financial (KES loss relative to core capital), regulatory (SASRA/ODPC consequence), operational (hours of member-facing downtime), customer (number of members impacted) and reputational (Internal awareness only vs external visibility by media and members of public) dimensions — You should select the highest. Define each rating in a written scale so two assessors reach the same score: for example, Impact 4 (Major) might mean “loss above 1% of core capital, or member-facing outage exceeding 24 hours, or a reportable regulatory breach.”

Control Design and Effectiveness Assessment

For each key control, assess two questions separately. Design: If the control were performed as specified, by competent personnel, with the stated frequency and inputs, would it prevent or detect the risk on a timely basis? Operating effectiveness: Was the control performed consistently and completely over the defined period? Rate the combined result on a simple scale such as Effective, Partially Effective, Ineffective and record the evidence. A control that exists on paper but has never been tested must be rated Ineffective until proven otherwise.

Residual Risk Calculation

Residual risk is the inherent score adjusted to demonstrate control effectiveness. A practical convention: Effective controls may reduce likelihood by up to two rating points and/or impact by one; Partially Effective controls reduce likelihood by one point; Ineffective controls give no reduction i.e residual equals inherent. Document the rationale for every reduction. Two disciplines matter most: controls must be evidenced, not assumed; and appetite breach status must always be measured against the residual score, never the inherent score i.e comparing appetite to inherent risk overstates exposure and forces boards to “accept” breaches that don’t exist, eroding the credibility of the whole framework.

Risk Appetite, Tolerance and Capacity

These three terms anchor the framework and are frequently confused:

A practical example: An investment firm may have a capacity to lose KES 1 billion without threatening solvency, a risk appetite to invest up to KES 500 million in high-risk assets, and a tolerance allowing minor deviations of (risk appetite) ±KES 50 million due to market fluctuations. The board approves the appetite statement annually and management translates it into tolerances and thresholds embedded in the risk register and KRI framework.

Developing KRIs and KPIs

Key Risk Indicators provide early warning signals of increasing risk exposure before it materializes into a loss event i.e they are leading measures of rising exposure; Key Performance Indicators in terms of risk management evaluate how well internal controls are performing in achieving their intended objectives, such as risk mitigation, compliance, and operational efficiency. Good indicators are measurable from existing systems, trending over time, and tied to a tolerance threshold. A starter set for a SACCO:

Technology Risk Register Design

The risk register is the single source of truth. Each entry should carry, at minimum: a unique ID; risk statement (cause-event-consequence); category and affected assets; named risk owner; inherent likelihood, impact and score; key controls with design and effectiveness ratings and evidence references; residual likelihood, impact and score; appetite threshold and breach status (against residual); linked KRIs; treatment actions with owners and due dates; and review date. Keep it to the 15–30 risks that matter. A 200-line register that nobody reads is worse than a focused one the board actually discusses. Review scores quarterly and after every material incident or system change.

Board Reporting and Dashboards

Quarterly board reporting should be one page of signal, backed by detail on request: a heat map of residual risks against appetite; the KRI dashboard, RAG-rated and trended; appetite breaches with treatment actions, owners and dates; top movements since last quarter and why; and incident summary with lessons applied. An illustrative snapshot:

Every red or amber item arrives with a named owner, an action and a date — the dashboard is a management tool, not a scoreboard.

Risk Treatment Planning

For each residual risk outside the risk appetite, the board has four options: Treat (implement or strengthen controls i.e the default), Transfer (cyber insurance, contractual liability shifts to vendors i.e noting insurance transfers financial impact only, never regulatory accountability), Tolerate (formally accept, documented with rationale and review date, only where within appetite or treatment cost clearly exceeds benefit), or Terminate (exit the activity — e.g. suspending a channel until controls mature). Treatment plans need an owner, budget, milestone dates, and a projected post-treatment residual score, tracked to completion in the quarterly report.

Incident Management and Lessons Learned

Incidents are the risk framework’s reality check. Every material technology incident should follow a defined lifecycle — detect, contain, eradicate, recover, notify (SASRA and, for personal data breaches, the ODPC within statutory timelines), and review. The post-incident review asks three framework questions: Was this risk on the register? Were its scores realistic? Which control failed, and what does that mean for its effectiveness rating? Feeding answers back into the register — re-scoring, re-rating controls, adding treatment actions — is what makes the framework a living system rather than an annual document.

Technology Risk Maturity Assessment

SACCOs should honestly locate themselves on a five-level maturity scale and set a realistic target — most DT-SACCOs today sit at Level 1–2; Level 3 is an achievable 12–18 month goal:

SASRA Regulatory Alignment

SASRA’s risk management and IT expectations for deposit-taking SACCOs map directly onto this framework: a board-approved risk management framework covering IT risk; documented IT policies and governance structures; business continuity and disaster recovery arrangements that are tested; information security and member data protection controls (reinforced by the Data Protection Act, 2019); and board-level oversight evidenced through minutes and reports. A SACCO operating the framework in this guide does not need a separate compliance exercise — the risk register, appetite statement, KRI reports and board minutes are the evidence SASRA inspectors ask for. The same artefacts also serve annual external audit and licensing renewal processes.

Practical SACCO Case Studies and Worked Examples