Two Frameworks, One Clock: The Operational Reality of CBK's Dual Cybersecurity Compliance Regime

The situation nobody's explained plainly

Here's what almost no one is telling Kenyan banks and SACCOs right now: you're not migrating from the old cybersecurity rules to the new ones. You're running both. At the same time. Indefinitely, CBK has said consolidation is coming but hasn't said when.

That's not a footnote. It's the actual operating condition for every regulated institution in the sector today.

The 2017 Commercial Banks Cybersecurity Guidelines and the 2019 PSP Cybersecurity Guidelines haven't gone anywhere. Now stack the Computer Misuse and Cybercrime (Critical Information Infrastructure and Cybercrime Management) Regulations, 2024 on top, Legal Notice No. 44, with its own reporting clock, its own definition of what counts as critical infrastructure, and its own enforcer: the NC4, working through the newly stood-up Banking Sector Cybersecurity Operations Centre (BS-SOC).

Translate that into a Tuesday morning for a bank's security team: one incident, and potentially two classification schemes, two clocks, two reporting channels, running in parallel, not in sequence.

SACCOs have it worse. Add SASRA's tightened IT audit requirements on top, and a mid-sized SACCO handling mobile payments is now threading three regulatory needles at once, with a fraction of a bank's compliance headcount.

Nobody's written about what that means day-to-day. The law firms have summarized the regulation. The news has covered the BS-SOC launch. No one has sat down and asked: what does an institution's security team have to do, this week, to not fall through the gap between two frameworks that were never designed to run together?

The technical spine: the 24-hour clock

Here's the number that should be pinned above every SOC dashboard in the sector: 24 hours.

Under the 2024 CMCA regulations, owners of critical information infrastructure must notify relevant authorities within twenty-four hours of detecting a cybersecurity incident. Not 24 hours from when the incident started. From when it's detected. That distinction is where most institutions are actually exposed, not in the reporting step itself, but in everything that has to happen before reporting even becomes possible.

Walk through what "detect, classify, and report within 24 hours" demands technically:

• You need to know something happened. That means log aggregation and correlation that's actually monitored, not just retained for audit purposes. A SIEM that ingests logs but has no one triaging alerts in real time doesn't give you detection, it gives you a very expensive archive you'll consult after the fact, which is exactly what the 24-hour rule is designed to prevent.
• You need to know what kind of incident it is, fast. The classification matters because it determines which framework's reporting obligation you're actually under, the CMCA regulations, the 2017/2019 CBK guidelines, or both. That triage decision has to happen inside the same clock as detection, which means someone with the authority and technical context to classify an incident needs to be reachable and equipped to do it at 2 a.m., not just during business hours.
• You need a reporting channel that actually works under pressure. Reporting to the BS-SOC isn't a form you fill in when convenient, it's a live obligation with license consequences attached to missing it. If your incident response plan says "notify compliance, who will notify CBK," and that chain has more than one human handoff, you're already eating into the clock before anyone external even knows there's a problem.

The uncomfortable truth: most institutions can produce a fully worked incident response plan on paper. Far fewer have tested whether their detection-to-classification-to-reporting chain executes inside 24 hours under real conditions, a compromised credential discovered on a Friday night, an anomalous transaction pattern flagged by a fraud system, a third-party vendor breach that touches your infrastructure. The gap between "we have a plan" and "we can execute the plan inside the mandated window" is where the real exposure sits, and it's invisible until you're tested against the clock, either by an actual incident, or by walking through the exercise honestly beforehand.

The business risk: what's actually on the line

Miss the 24-hour window, or misclassify an incident under the wrong framework, and the consequence isn't a strongly worded letter.

Under the 2024 CMCA regulations, non-compliance can result in the National Computer and Cybercrimes Coordination Committee recommending restriction, suspension, or revocation of an operator's license, in consultation with the sector regulator. Read that again slowly. For a bank or a payment service provider, license restriction isn't a compliance line item. It's an operational event that shows up in customer-facing service disruption, correspondent banking relationships, and shareholder disclosure, the kind of consequence that moves a cybersecurity gap from "IT problem" to board agenda within a single news cycle.

Then there's the cost that's already being incurred, independent of any regulatory action. According to CBK's Financial Sector Stability Report 2024, Kenyan banks lost more than Sh1.5 billion to cyber and technology-related fraud, with mobile banking platforms the hardest hit, Sh810.68 million lost through that channel alone. That figure isn't a hypothetical risk model. It's what already happened, in a single reporting year, before the 24-hour rule and the BS-SOC were even fully operational. It's reasonable to expect the regulatory response to tighten further, not loosen, as enforcement infrastructure catches up to that number.

For SACCOs, the stakes carry an added layer. SASRA-regulated deposit-taking SACCOs, 176 of them, now carry SASRA's tightened IT audit requirements alongside CBK's CMCA obligations for any SACCO handling payment services. A compliance failure here doesn't just risk CBK-level consequences; it risks SASRA's parallel enforcement track at the same time, for institutions that typically have far less compliance and security headcount than a bank to absorb either the operational burden or the two-front regulatory exposure.

The pattern across both incident cost and regulatory consequence points the same direction: the institutions most exposed right now are not the ones ignoring cybersecurity. They're the ones who have a plan on paper and haven't yet tested whether that plan survives contact with a live 24-hour clock and two overlapping regulatory frameworks.

Where institutions are actually exposed today

So where does that leave a security or compliance leader reading this on a Tuesday morning?

Not with a checklist. The honest answer is that the gap isn't usually in the paperwork — most regulated institutions can produce a board-approved incident response policy, a data classification scheme, an incident register. The gap is in the handful of questions almost no one has actually stress-tested:

• Who has the authority to classify an incident at 2 a.m., and do they know it? Not who's named in the policy document, who has actually been woken up, told "this might be reportable," and asked to make the call under real time pressure.
• Does your detection capability actually detect, or does it just log? There's a meaningful difference between "we retain six months of logs for audit purposes" and "someone is watching, correlating, and getting alerted in near-real-time." Only one of those starts the clock in your favor.
• When an incident touches both frameworks, who decides which one governs the report, and how long does that decision take? If the answer involves more than one internal handoff before someone picks up a phone to BS-SOC, that's time coming directly out of the 24 hours.
• Has anyone actually run the exercise, end to end, under time pressure, not just written the plan? A tabletop exercise that walks through detection-to-report with a stopwatch running tells you things a policy document never will.

None of this is a criticism of any single institution. It's a fair description of where an entire sector sits right now, mid-transition, running two regulatory frameworks that were never designed to operate concurrently, against a hard clock that doesn't care which framework you thought applied.

The institutions that come out ahead over the next eighteen months won't be the ones with the most polished policy documents. They'll be the ones who took the time now, before an incident forces the question, to find out whether their detection-to-report chain actually survives contact with 24 hours, on paper and in practice.