ISO certification for banks and fintechs in Kenya: which standard actually matters first
We have had more calls this year from digital lenders, payment processors and mid-size banks than from almost any other sector, and the question behind most of them is some version of the same thing: our bigger competitors are now ISO certified, our regulator keeps raising IT risk in supervisory conversations, and we need to know which standard to chase first before we commit budget to the wrong one. It is a reasonable worry, because the financial sector has more overlapping standards in play than almost any other industry we work in.
What's actually driving this
Three things are converging at once. The Central Bank's prudential guidelines on IT risk and cyber resilience are getting more specific every revision cycle, not less. Kenya's Data Protection Act is pushing every institution handling customer financial data to demonstrate real controls, not a policy binder nobody has read. And competitively, once one or two larger banks start publicising ISO certification for information security and IT service management, it quietly becomes an expectation that smaller players feel in due diligence questionnaires from partners, correspondent banks and payment networks.
ISO/IEC 27001 versus ISO/IEC 20000: which one gets asked for
ISO/IEC 27001 is almost always the first ask, because it covers information security management broadly: access control, data handling, incident response, vendor risk, and the controls a regulator or auditor wants to see evidence of after any data breach headline in the sector. If you process customer financial data, hold payment card information, or run a mobile money or digital lending platform, this is very likely your starting point.
ISO/IEC 20000 covers IT service management: how reliably you deliver and support IT services internally and to customers, incident and problem management, change control, and service continuity. It matters more once you are running a live platform at scale where downtime has direct financial consequences, and it tends to come second, built on top of the discipline a 27001 implementation already put in place.
We rarely see a convincing case for starting with 20000 before 27001 in this sector. Security control gaps are usually the more urgent risk, and the documentation discipline from an ISMS implementation makes the service management layer faster and cheaper to add afterward.
What regulation is actually nudging you toward
Neither the CBK nor the ODPC currently mandates ISO certification outright. What they mandate is evidence of adequate controls, a registered data protection framework, and in some cases a formal DPIA for higher risk processing. ISO 27001 is simply the most recognised, auditable way to produce that evidence in one package rather than assembling it ad hoc every time a regulator, auditor, or partner asks a new question. Institutions that already hold the certificate consistently tell us their supervisory conversations and partner due diligence have gotten shorter, not because the standard is a magic pass but because the evidence is already organised.
A quick framework for deciding where to start
1. Map what customer and financial data you actually hold and where it physically and digitally lives, across your own systems and any third party processors.
2. List every partner, correspondent or payment network due diligence questionnaire you've filled out in the last year and flag which questions you answered weakly.
3. Check your incident history honestly, including near misses that never became public, not just confirmed breaches.
4. Confirm whether a DPIA is already required for any of your processing activities under the Data Protection Act, since that work feeds directly into an ISMS risk assessment.
5. Decide your realistic go-live platform scale for the next two years, because that determines whether ISO 20000 belongs on this cycle's roadmap or the next one.
What smaller fintechs and digital lenders get wrong
The most common mistake is treating ISO 27001 as a documentation exercise handled entirely by one compliance officer in isolation from engineering. The standard expects the information security management system to be genuinely operational: access reviews that actually happen on schedule, incident logs that get used, change management that engineering follows under deadline pressure, not just when an auditor is watching. We have seen implementations stall at Stage 1 purely because the system existed on paper and nowhere else. The fix is almost always the same: fewer, better controls that the team will actually sustain, rather than a comprehensive policy set nobody can keep up with.
Third-party and vendor risk: the blind spot
Almost every fintech and digital lender we scope runs on a stack of third parties: a cloud host, a payment gateway, an SMS or USSD aggregator, sometimes a core banking vendor hosted entirely outside the business. ISO 27001 explicitly requires you to assess and manage that risk, not just secure your own four walls, and this is where we see the most incomplete implementations. A business can have excellent internal access control and still fail an audit, or worse, suffer a real breach, because nobody formally reviewed what a key vendor can actually see or touch. Before your next renewal cycle, pull the data processing agreements for your three most critical vendors and check whether they actually describe what happens to your customers' data in practice, not just what the contract template says in general terms.
Local versus international certification bodies
A certification body with real presence and sector experience in Kenya's financial services market will understand CBK and ODPC expectations in a way a purely international body sometimes does not, and that familiarity shows up in a smoother audit, not just a lower invoice. Confirm what accreditation your specific partners or correspondent banks require before committing to either path.
Get a straight read on where to start
We would rather look at your actual data flows, partner questionnaires and incident history than guess which standard you need. If regulatory pressure or a partner's due diligence has put this on your desk, it is worth a short conversation before you commit budget to the wrong sequence.