Ciberseguridad del CBK: evalúe su app de banca móvil y las API que la sustentan.
La Guidance Note on Cybersecurity de 2017 del Central Bank of Kenya (CBK) pide a los bancos realizar un test independiente de ciberamenazas al menos una vez al año, e incluye las evaluaciones de amenazas y vulnerabilidades y las pruebas de penetración completas en el alcance de la auditoría interna y externa. Su directriz de 2019 para proveedores de servicios de pago fija escaneos de vulnerabilidades trimestrales y pruebas de penetración anuales. La ley de protección de datos de 2019 exige garantías desde el diseño y por defecto. Ostorlab prueba su app y las API en las que se apoya, detrás del inicio de sesión, en cada versión.
- Evalúa la app móvil y las API a las que llama, sobre la compilación que descargan sus clientes
- Prueba el inicio de sesión, los códigos de un solo uso, las verificaciones reforzadas y la gestión de sesiones con sus cuentas de prueba
- Enumera los SDK y las bibliotecas nativas de cada versión y los asocia a vulnerabilidades conocidas
- Demuestra cada hallazgo con un exploit reproducible o con evidencia de solicitudes y respuestas
- A quién se aplica
- Bancos autorizados en virtud del Banking Act y proveedores de servicios de pago autorizados en virtud del National Payment System Act de 2011
- Fecha clave
- Guidance Note on Cybersecurity publicada en agosto de 2017; directriz para proveedores de servicios de pago en julio de 2019; el CBK está actualizando la guía de 2017
- Objeto
- Test independiente de ciberamenazas, evaluación de vulnerabilidades y pruebas de penetración, riesgo de terceros y protección de datos
- Referencia principal
- Guidance Note on Cybersecurity for the Banking Sector del CBK, agosto de 2017
Los textos del CBK que rigen su canal móvil
La guía bancaria de 2017, la directriz para proveedores de servicios de pago y las normas del National Payment System conviven con la ley de protección de datos. Las fechas siguientes corresponden a los textos y novedades citados en esta página.
- 2011 y 2014
National Payment System Act y Regulations
El National Payment System Act (ley n.º 39 de 2011) otorga al CBK la supervisión del sistema de pagos y la facultad de emitir directivas y directrices. Los reglamentos de 2014 añaden obligaciones operativas, de pista de auditoría, de información y de auditoría anual de la seguridad del sistema para los proveedores de servicios de pago.
- Enero de 2013
Risk Management Guidelines
El CBK publica sus directrices de gestión de riesgos. La sección 7 trata el riesgo TIC, incluidos los escáneres de vulnerabilidades y las pruebas de penetración como herramientas para identificar vulnerabilidades, y el programa de seguridad de la información.
- Agosto de 2017
Guidance Note on Cybersecurity
El CBK publica la Guidance Note on Cybersecurity for the Banking Sector en virtud del artículo 33(4) del Banking Act. Exige un test independiente de ciberamenazas al menos una vez al año, incluye las evaluaciones de amenazas y vulnerabilidades y las pruebas de penetración completas en el alcance de la auditoría, y obliga a notificar al CBK los incidentes significativos en un plazo de 24 horas.
- Julio de 2019
Directriz para proveedores de servicios de pago
El CBK publica la Guideline on Cybersecurity for Payment Service Providers. Fija escaneos de vulnerabilidades trimestrales de los activos cibernéticos críticos, una prueba de penetración anual y evaluaciones de vulnerabilidades semestrales, con 90 días para cumplir.
- Marzo de 2025
Encuesta de adopción
El CBK encuesta la adopción de la Guidance Note de 2017 por los bancos. Todos los encuestados afirmaron realizar evaluaciones de vulnerabilidades y pruebas de penetración, con periodicidad anual, trimestral o mensual, y el 92 % contaba con auditores informáticos en sus equipos de auditoría interna. El informe se publica en junio de 2025.
- 22 de septiembre de 2025
SOC del sector bancario
El CBK anuncia el Banking Sector Cyber Security Operations Centre, integrado en su Cyber Fusion Unit, y comienza a alinear las guías de 2017 y 2019 con el reglamento de 2024 sobre infraestructuras de información críticas. Las instituciones deben seguir cumpliendo ambos conjuntos de requisitos y notificar los incidentes al centro.
- 22 de septiembre de 2026
Guía en revisión
El informe anual de supervisión bancaria de 2025 indica que el CBK ha iniciado la actualización de la Guidance Note de 2017. Los bancos encuestados pidieron que se cubrieran la seguridad de las API, la inteligencia artificial, la nube y la detección del fraude en el dinero móvil.
- Septiembre de 2026
Borradores en consulta
El CBK publica el 10 de septiembre de 2026 borradores revisados de las Prudential Guidelines, las Risk Management Guidelines y las Guidance Notes para comentarios, y el Tesoro nacional y el CBK publican el 21 de septiembre de 2026 el borrador del National Payment System Policy and Bill 2026. Son borradores, aún no en vigor.
Los textos del CBK, aplicados a su app móvil
Para cada norma: qué dice el texto, qué supone para una app de banca móvil, cómo ayuda Ostorlab y qué sigue correspondiendo a su equipo.
- Guidance Note on Cybersecurity for the Banking Sector, agosto de 2017, sección 3.2
Realice un test independiente de ciberamenazas al menos una vez al año
Qué dice el texto
Las instituciones deberían recurrir a consultores externos con experiencia suficiente en ciberseguridad para comprender su panorama de ciberamenazas, y deberían realizar un test independiente de ciberamenazas al menos una vez al año. Los auditores externos deberían realizar evaluaciones independientes de amenazas y vulnerabilidades y pruebas de penetración completas dentro del alcance de la auditoría informática, e informar anualmente al consejo y al Central Bank of Kenya sobre los hallazgos.
Fuente:Guidance Note on Cybersecurity for the Banking Sector, agosto de 2017, sección 3.2
Qué supone para su app móvil
El test anual es un mínimo, no un techo. La app y las API a las que llama forman parte de los sistemas incluidos, y cada versión publicada en las tiendas los modifica.
Cómo ayuda Ostorlab
Un pentest con agentes de IA prueba la app y sus API detrás del inicio de sesión, sobre la versión que publica, con un exploit funcional que puede reproducir para cada hallazgo de un agente de IA. Puede ejecutarse en cada versión, entre los tests anuales.
Qué sigue en sus manos
La elección de los consultores externos, el alcance de la auditoría y el informe anual al consejo y al CBK.
- Guidance Note on Cybersecurity for the Banking Sector, sección 3.2 (funciones de auditoría interna y gestión de riesgos)
Mantenga las pruebas de amenazas y vulnerabilidades en el alcance de la auditoría
Qué dice el texto
La auditoría interna debería incluir auditores TIC cualificados, propios o externalizados. Su alcance comprende revisar e informar de forma continua sobre los ciberriesgos y los controles de los sistemas TIC y las conexiones con terceros relacionadas, evaluar el diseño y la eficacia del marco de ciberseguridad, realizar evaluaciones independientes periódicas de amenazas y vulnerabilidades, realizar pruebas de penetración completas e informar de los hallazgos al consejo. La gestión de riesgos debería mantener un registro de ciberriesgos y un inventario completo de los activos informáticos clasificados por criticidad para el negocio, y realizar ejercicios de red team.
Qué supone para su app móvil
El alcance de la auditoría menciona las conexiones con terceros. Para una app de banca móvil, eso significa la app, los SDK que integra y las API a las que llama, no solo el sistema bancario central.
Cómo ayuda Ostorlab
Mobile DAST ejecuta la app y sus flujos y devuelve hallazgos con el contexto del código descompilado, el tráfico, las trazas y capturas de pantalla, para que el equipo de auditoría tenga evidencia utilizable.
Qué sigue en sus manos
El plan de auditoría, el ejercicio de red team y los hallazgos presentados al consejo.
- Guideline on Cybersecurity for Payment Service Providers, julio de 2019, secciones 3.2.5 y 4.0
Cumpla la cadencia de pruebas de los proveedores de servicios de pago
Qué dice el texto
La Guideline on Cybersecurity for Payment Service Providers de 2019 exige un programa de ciberseguridad con monitorización continua y pruebas de penetración y evaluaciones de vulnerabilidades periódicas. En ausencia de una monitorización continua eficaz, los proveedores deberían realizar escaneos de vulnerabilidades trimestrales de todos los activos cibernéticos críticos, una prueba de penetración anual que cubra al menos los activos cibernéticos críticos determinados para ese año a partir de la evaluación de riesgos, y evaluaciones de vulnerabilidades semestrales. Los proveedores disponían de 90 días desde la entrada en vigor de la directriz para cumplirla.
Fuente:Guideline on Cybersecurity for Payment Service Providers, julio de 2019, secciones 3.2.5 y 4.0
Qué supone para su app móvil
Si su institución o su grupo explota un servicio de pago, la cadencia es de escaneos trimestrales, una prueba de penetración anual y evaluaciones semestrales. El canal móvil y las API que lo sustentan son activos cibernéticos críticos.
Cómo ayuda Ostorlab
Ostorlab se ejecuta desde su pipeline de CI/CD en cada compilación y puede escanear las versiones publicadas en las tiendas sin activación manual, de modo que una cadencia trimestral o más frecuente es una planificación, no un proyecto.
Qué sigue en sus manos
Decidir qué cuenta como activo cibernético crítico, la monitorización continua y la evaluación de riesgos que determina el alcance anual.
- National Payment System Regulations, 2014, reglamentos 27 y 29
Proteja el servicio de pago y mantenga la pista de auditoría
Qué dice el texto
Los proveedores de servicios de pago deben establecer disposiciones operativas adecuadas para sus servicios, incluidas medidas que garanticen la seguridad, la protección y la fiabilidad operativa del servicio y disposiciones de contingencia. Deben utilizar sistemas que ofrezcan una pista de auditoría precisa y plenamente accesible de las transacciones, desde su origen hasta su finalidad, conservar los registros de cada transferencia electrónica durante al menos siete años, informar cada mes al Central Bank of Kenya de los incidentes de fraude y de las interrupciones materiales del servicio o las brechas de seguridad importantes, y presentar cada año un informe de auditoría de la seguridad del sistema elaborado por una firma de auditoría independiente de reputación.
Fuente:National Payment System Regulations, 2014, reglamentos 27 y 29
Qué supone para su app móvil
La pista de auditoría, la conservación durante siete años y el informe mensual son obligaciones del proveedor. La app y sus API son el punto de partida de las transacciones, así que su comportamiento forma parte de la evidencia.
Cómo ayuda Ostorlab
Ostorlab prueba la app y sus API y conserva la evidencia de solicitudes y respuestas de cada hallazgo, lista para adjuntarla a la auditoría anual de seguridad del sistema y al registro de correcciones.
Qué sigue en sus manos
La conservación de registros, los informes mensuales al CBK y la designación de la firma de auditoría independiente.
- Guidance Note on Cybersecurity for the Banking Sector, secciones 2.4 y 3.1
Despliegue autenticación sólida para los datos y las transacciones de los clientes
Qué dice el texto
La alta dirección debería supervisar el despliegue de medidas de autenticación sólidas para proteger los datos, las transacciones y los sistemas de los clientes. La Guidance Note cita los controles de autenticación deficientes entre las fuentes de ciberriesgo, y espera que el CISO garantice que la institución mantenga una base de conocimiento actualizada de toda la empresa sobre sus usuarios, dispositivos y aplicaciones, incluido el inventario de software y hardware y los mapas de red.
Fuente:Guidance Note on Cybersecurity for the Banking Sector, secciones 2.4 y 3.1
Qué supone para su app móvil
El servidor debe exigir el segundo factor en las operaciones clave, no solo mostrarlo la app. Los códigos de un solo uso, los tiempos de espera y las verificaciones reforzadas son comportamientos que se pueden probar.
Cómo ayuda Ostorlab
Las pruebas autenticadas cubren el inicio y el cierre de sesión, la renovación de tokens, los tiempos de espera, la invalidación de sesiones y la aplicación de la MFA, incluidos los flujos de autenticación reforzada, con sus cuentas de prueba.
Qué sigue en sus manos
La elección de los métodos de autenticación, el envío de códigos de un solo uso y la atención a los clientes bloqueados.
- Guidance Note on Cybersecurity, sección 3.3; Prudential Guidelines, CBK/PG/16 sobre externalización, secciones 4.1.4 y 4.5
Gestione los terceros y la externalización
Qué dice el texto
Las instituciones deberían asegurarse de que sus terceros cumplen los marcos legales y reguladores y las buenas prácticas internacionales. Deberían disponer de una gobernanza adecuada de los acuerdos de externalización, incluida la diligencia debida sobre los proveedores previstos, acuerdos documentados y un seguimiento adecuado de la prestación; seleccionar a los proveedores sobre la base de evaluaciones de cumplimiento y riesgo; exigir a los proveedores que cumplan los marcos legales y reguladores aplicables; vigilarlos para detectar cambios en su actividad y su postura cibernética; y contar con acuerdos de nivel de servicio con disposiciones sólidas sobre seguridad, disponibilidad, métricas de rendimiento y penalizaciones. En virtud de la Prudential Guideline CBK/PG/16, la externalización material requiere la aprobación del Central Bank of Kenya, y la provisión de canales o tecnologías de servicios financieros móviles figura como ejemplo de actividad material.
Qué supone para su app móvil
Los SDK de su app y los backends a los que llaman son terceros. Su postura de seguridad forma parte de su diligencia y su monitorización, y algunas externalizaciones necesitan la aprobación previa del CBK.
Cómo ayuda Ostorlab
SCA y SBOM enumeran los SDK y las bibliotecas nativas de cada versión con sus versiones, y el análisis de red muestra con qué backends se comunican la app y sus SDK.
Qué sigue en sus manos
La diligencia debida, los contratos, las aprobaciones del CBK y los planes de salida.
- Risk Management Guidelines, enero de 2013, secciones 7.3.4, 7.4 y 7.5
Implante un marco de riesgo TIC y pruebe con las herramientas adecuadas
Qué dice el texto
Las Risk Management Guidelines exigen un marco de gestión del riesgo TIC con supervisión del consejo, una política de riesgo TIC y un programa de seguridad de la información que promueva la concienciación e informe al consejo de la evaluación de la seguridad de la información. Para identificar vulnerabilidades, las directrices citan los escáneres de vulnerabilidades, que comparan un sistema o sus respuestas con una base de firmas de fallos, y las pruebas de penetración, un intento de analistas de seguridad humanos de ejercer amenazas contra un sistema, incluidas vulnerabilidades operativas como la ingeniería social. Los riesgos se evalúan, se miden, se mitigan y se documentan.
Fuente:Risk Management Guidelines, enero de 2013, secciones 7.3.4, 7.4 y 7.5
Qué supone para su app móvil
Los escáneres y las pruebas de penetración son las dos herramientas nombradas para encontrar vulnerabilidades. Una app móvil necesita ambas: análisis de la compilación y pruebas dinámicas de la app en ejecución y de sus API.
Cómo ayuda Ostorlab
Mobile SAST analiza el APK, AAB o IPA con análisis de propagación (taint) en toda la app y sus SDK integrados, y Mobile DAST ejecuta la app. Ambos se ejecutan en CI/CD en cada compilación.
Qué sigue en sus manos
La política de riesgo TIC, la información al consejo y el programa de seguridad de la información en su conjunto.
- Data Protection Act, 2019, secciones 41 y 42; Data Protection (General) Regulations, 2021, reglamento 32
Proteja los datos personales desde el diseño y por defecto
Qué dice el texto
La ley de protección de datos de 2019 exige a todo responsable o encargado del tratamiento implementar medidas técnicas y organizativas adecuadas diseñadas para aplicar eficazmente los principios de protección de datos e integrar las garantías necesarias en el tratamiento, tanto al determinar los medios del tratamiento como en el momento del tratamiento. Por defecto, solo deberían tratarse los datos personales necesarios para cada finalidad específica. Entre las medidas a considerar están identificar los riesgos internos y externos para los datos personales, mantener garantías frente a ellos, la seudonimización y el cifrado, restablecer la disponibilidad tras un incidente, verificar que las garantías funcionan y actualizarlas ante nuevos riesgos o deficiencias. Cuando el tratamiento implique transmisión por red, el responsable debe tener en cuenta el estado de la tecnología, el coste de las medidas, los riesgos especiales y la naturaleza de los datos. Los reglamentos generales enumeran los elementos del principio de integridad, confidencialidad y disponibilidad, incluidos la evaluación de los riesgos para la seguridad de los datos personales, las pistas de auditoría y la monitorización de eventos, y la revisión y prueba periódicas del software para descubrir vulnerabilidades de los sistemas que sustentan el tratamiento.
Qué supone para su app móvil
La app es donde se recogen, se almacenan y se envían los datos personales. Decisiones de diseño como qué se almacena en caché, cómo se cifra y qué se registra forman parte de las medidas que pide la ley.
Cómo ayuda Ostorlab
Ostorlab busca tokens de sesión y datos personales en el almacenamiento local, las cachés, los registros y las capturas de pantalla, comprueba las protecciones del transporte, y detecta claves de API, tokens y credenciales en el paquete de la app y valida si funcionan.
Qué sigue en sus manos
Las evaluaciones de impacto relativas a la protección de datos, el consentimiento, las reglas de conservación y la gestión de brechas.
- Guidance Note on Cybersecurity, parte IV; Data Protection Act 2019, sección 43; National Payment System Regulations, 2014, reglamento 29(2)
Notifique los incidentes y mantenga el registro
Qué dice el texto
La Guidance Note obliga a las instituciones a notificar al Central Bank of Kenya, en un plazo de 24 horas, cualquier incidente de ciberseguridad que pueda tener un impacto significativo y adverso en la capacidad de la institución de prestar servicios adecuados a sus clientes, en su reputación o en su situación financiera, y a presentar un informe trimestral sobre los incidentes y su tratamiento. La ley de protección de datos obliga al responsable del tratamiento a notificar al Data Commissioner sin dilación y dentro de las 72 horas el acceso o la adquisición no autorizados de datos personales con un riesgo real de daño para el interesado, y a comunicarlo por escrito al interesado; el encargado del tratamiento debe notificar al responsable sin dilación y, cuando sea razonablemente posible, dentro de las 48 horas. Los proveedores de servicios de pago también informan cada mes al CBK de las interrupciones materiales del servicio y las brechas de seguridad importantes.
Qué supone para su app móvil
La notificación de incidentes es suya, pero el reloj empieza cuando se detecta el incidente. Las pruebas ayudan a encontrar y corregir problemas antes de que se conviertan en sucesos notificables.
Cómo ayuda Ostorlab
Ostorlab aporta la evidencia técnica y los pasos de reproducción de cada hallazgo, y vuelve a probar tras la corrección, para que el registro esté completo cuando notifique.
Qué sigue en sus manos
La detección, los informes de 24 horas, de 72 horas y mensuales, y la comunicación con los clientes.
Resumen de textos públicos del CBK y la ODPC, consultados el 27 de septiembre de 2026. Los borradores en consulta no se tratan como requisitos en esta página. Esta página no constituye asesoramiento jurídico.
Normas del CBK, control por control
Los controles a los que apuntan los textos del CBK y la ODPC, cómo los prueba Ostorlab en su app y sus API, y la evidencia que puede conservar.
| Control | Cómo ayuda Ostorlab | Evidencia que conserva |
|---|---|---|
| Test independiente de ciberamenazas, al menos una vez al añoGuidance Note 3.2 | Pentest con agentes de IA de la app y de sus API, detrás del inicio de sesión, sobre la versión que publica. Detalles | Un exploit funcional que puede reproducir para cada hallazgo de un agente de IA, y un mapa de calor de cobertura |
| Evaluaciones de amenazas y vulnerabilidades y pruebas de penetración completasGuidance Note 3.2 | Mobile DAST ejecuta la versión y sus flujos, con hallazgos asociados al contexto descompilado, el tráfico, las trazas y capturas de pantalla. Detalles | Hallazgos con el contexto del código descompilado, el tráfico, las trazas y capturas de pantalla |
| Escaneos trimestrales, prueba de penetración anual y evaluaciones semestrales para proveedores de servicios de pagoDirectriz PSP 3.2.5 | Intercepta el tráfico incluso con TLS pinning y prueba la autorización, el uso indebido de tokens y abusos como la enumeración y la repetición. Detalles | Evidencia de solicitudes y respuestas para cada hallazgo de API, y resultados de escaneo por ciclo |
| Seguridad, protección y fiabilidad operativa del servicio de pagoNPS Regulations, reglamento 27 | Prueba los flujos de app y API que componen el servicio al cliente, incluida la gestión de fallos y errores. | Evidencia de prueba que puede adjuntar al informe anual de auditoría de seguridad del sistema |
| Pista de auditoría, registros y notificaciónNPS Regulations, reglamento 29 | Agrupa los hallazgos en tickets en la plataforma o en Jira y ServiceNow, y vuelve a probar tras la corrección. | Historial de tickets y resultado de la nueva prueba de cada hallazgo |
| Autenticación sólida para los datos y las transacciones de los clientesGuidance Note 3.1(b)(v) | Inicia sesión con códigos de un solo uso y prueba la aplicación de la MFA, los flujos de autenticación reforzada y las llamadas a la API que hay detrás. Detalles | Hallazgos sobre los flujos de inicio de sesión y de autenticación reforzada, con los pasos de reproducción |
| Riesgo de terceros y externalizaciónGuidance Note 3.3; CBK/PG/16 | Enumera los SDK y las bibliotecas nativas de cada versión con sus versiones, y muestra con qué backends se comunican la app y sus SDK. Detalles | Identidad, versión y ubicación de cada componente en el paquete de la app, por versión |
| Marco de riesgo TIC e identificación de vulnerabilidadesRisk Management Guidelines 7.3.4 | Mobile SAST analiza el binario con análisis de propagación (taint) en toda la app y sus SDK integrados. Detalles | Hallazgos con el contexto del código descompilado, por compilación |
| Datos personales en el dispositivo y en tránsitoData Protection Act, sección 41 | Busca tokens y datos personales en el almacenamiento, las cachés, los registros y las capturas de pantalla, y comprueba las protecciones del transporte. Detalles | Evidencia del sistema de archivos que muestra qué se escribió, dónde y cuándo |
| Revisión y prueba periódicas del software para descubrir vulnerabilidadesDP General Regulations 32(k) | Análisis estático de los binarios APK, AAB e IPA, en CI/CD en cada compilación. Detalles | Resultados de escaneo por compilación, con el contexto del código descompilado |
Ostorlab prueba los controles de la app y de sus API. La monitorización del SOC, la detección de incidentes y las notificaciones al CBK, al Data Commissioner o al BS-SOC, la continuidad y la recuperación, la opinión de la auditoría anual de seguridad del sistema, la gobernanza y la seguridad física siguen correspondiendo a sus equipos.
Controles del CBK que probar en su app móvil
Una lista práctica para los equipos de seguridad y auditoría, basada en la Guidance Note de 2017, la directriz para proveedores de servicios de pago y la ley de protección de datos de 2019.
Test independiente anual
Incluya la app móvil y las API a las que llama en el alcance del test independiente anual de ciberamenazas, y pruebe en cada versión entre auditorías.
Alcance de auditoría y riesgo
Incluya la app y sus conexiones con terceros en el alcance de la auditoría interna: evaluaciones de amenazas y vulnerabilidades, pruebas de penetración completas y evidencia para el consejo.
Cadencia de servicios de pago
Si su grupo explota un servicio de pago, planifique escaneos de vulnerabilidades trimestrales, una prueba de penetración anual y evaluaciones de vulnerabilidades semestrales de los activos cibernéticos críticos.
Autenticación y sesiones
Pruebe el inicio de sesión, los códigos de un solo uso, las verificaciones reforzadas, los tiempos de espera y la invalidación de sesiones, con los controles aplicados en el servidor.
Terceros y SDK
Mantenga una lista versionada de los SDK y los backends de cada versión, y compruebe si un acuerdo de externalización necesita la aprobación del CBK antes de empezar.
Datos en el dispositivo
Busque tokens y datos personales en el almacenamiento, las cachés, los registros y las capturas de pantalla, y también en el paquete de la app.
Protección de datos desde el diseño
Revise las secciones 41 y 42 para la app: qué se recoge, qué se almacena en caché, cómo se cifra y cómo verifica las garantías.
Notificar y volver a probar
Conozca los plazos de 24 horas para el CBK y de 72 horas para el Data Commissioner, conserve la evidencia técnica y vuelva a probar tras la corrección.
Una lista sugerida, no una plantilla del CBK. Esto no constituye asesoramiento jurídico.
Las capacidades detrás de esta página
Cada una tiene su propia página con los detalles.
- Mobile Agentic Deep ScanLos agentes de IA realizan el pentest de la versión publicada en cada release, con un exploit funcional que puede reproducir para cada hallazgo de un agente de IA.Más información
- Pruebas autenticadasPruebe el inicio de sesión, los códigos de un solo uso y la autenticación reforzada con sus cuentas de prueba.Más información
- Pruebas de API y backendIntercepte el tráfico de la app incluso con TLS pinning y pruebe las API y los backends detrás de cuentas y pagos.Más información
- Mobile SASTAnálisis estático basado en el binario de archivos APK, AAB e IPA, con análisis de propagación (taint) en toda la app y sus SDK integrados.Más información
- SCA y SBOMDetecte dependencias vulnerables, incluidas las bibliotecas nativas compiladas estáticamente, y haga un seguimiento de su cierre versión tras versión.Más información
- Mobile Shielding ScanPruebe en tiempo de ejecución la detección de root y jailbreak, la protección contra manipulación y el pinning, y vea qué protecciones resistieron y cuáles se evadieron.Más información
- Su propia clave de IAEjecute los escaneos con agentes de IA con la clave de su proveedor de IA y un límite de gasto por escaneo, según sus políticas internas.Más información
- Escaneo on-premisesEscanee apps de preproducción, API y repositorios detrás de su firewall o VPN, en una infraestructura que usted controla.Más información
Bancos y fintechs confían en nosotros, entre ellos
Fuentes
Los textos oficiales en los que se basa esta página, consultados el 27 de septiembre de 2026.
- National Payment System Act, No. 39 of 2011, and National Payment System Regulations, 2014La ley otorga al Central Bank of Kenya la supervisión del sistema nacional de pagos y la facultad de emitir directivas y directrices. Los reglamentos de 2014 exigen a los proveedores de servicios de pago mantener servicios seguros, protegidos y fiables (reglamento 27), llevar una pista de auditoría y conservar registros durante al menos siete años (reglamento 29(1)), informar cada mes de las interrupciones materiales del servicio y las brechas de seguridad importantes (reglamento 29(2)(c)), y presentar un informe anual de auditoría de seguridad del sistema por una firma de auditoría independiente de reputación (reglamento 29(3)(c))
- Risk Management Guidelines, enero de 2013Central Bank of Kenya. La sección 7 trata el riesgo TIC: responsabilidades del consejo y la alta dirección, el marco de gestión del riesgo TIC, la identificación de vulnerabilidades con escáneres de vulnerabilidades y pruebas de penetración (7.3.4), la evaluación y mitigación de riesgos (7.4), y el programa de seguridad de la información (7.5)
- Prudential Guidelines, 2013, incluida la Guideline on Outsourcing (CBK/PG/16)Central Bank of Kenya. CBK/PG/16 exige la aprobación del CBK para la externalización material, cita la provisión de canales o tecnologías de servicios financieros móviles como ejemplo de actividad material (4.1.4), y fija expectativas de diligencia, monitorización y contratos. La institución sigue siendo responsable de las actividades externalizadas (4.2)
- Guidance Note on Cybersecurity for the Banking Sector, agosto de 2017Central Bank of Kenya, publicada en virtud del artículo 33(4) del Banking Act y aplicable a todas las instituciones autorizadas en virtud de esa ley. Gobernanza, test independiente de ciberamenazas al menos una vez al año, pruebas de auditoría interna y externa incluidas las pruebas de penetración completas, externalización y notificación de incidentes en 24 horas (secciones 3.1 a 3.4 y parte IV)
- Guideline on Cybersecurity for Payment Service Providers, julio de 2019Central Bank of Kenya, publicada en virtud del artículo 31(2)(b) del National Payment System Act de 2011 y aplicable a los proveedores de servicios de pago autorizados en virtud de esa ley. Escaneos de vulnerabilidades trimestrales, prueba de penetración anual y evaluaciones de vulnerabilidades semestrales (3.2.5), notificación de externalizaciones con 30 días de antelación (3.4.2), y un periodo transitorio de 90 días (4.0)
- Data Protection Act, 2019República de Kenia, ley n.º 24 de 2019, publicada por la Office of the Data Protection Commissioner. Protección de datos desde el diseño y por defecto y las medidas que exige (secciones 41 y 42), notificación de brechas en 72 horas (sección 43), y condiciones para transferir datos personales fuera de Kenia (secciones 48 a 50)
- Data Protection (General) Regulations, 2021Office of the Data Protection Commissioner. Los elementos de la protección de datos desde el diseño y por defecto, incluidos la evaluación de los riesgos para la seguridad de los datos personales, las pistas de auditoría y la monitorización de eventos, y la revisión y prueba periódicas del software para descubrir vulnerabilidades de los sistemas que sustentan el tratamiento (reglamento 32)
- Nota de prensa: Establishment of the Banking Sector Cyber Security Operations Centre (BS-SOC)Central Bank of Kenya, 22 de septiembre de 2025. El CBK indica que ha comenzado a alinear las guías de ciberseguridad de 2017 y 2019 con el reglamento de 2024 sobre infraestructuras de información críticas, que las instituciones deben seguir cumpliendo ambos conjuntos de requisitos, y que los incidentes de ciberseguridad deben notificarse al BS-SOC dentro de los plazos de ese reglamento
Preguntas frecuentes
Respuestas claras sobre cobertura, configuración y cómo llegan los resultados a su equipo.
¿No encuentra su respuesta? Reserve una demo o contáctenos.
Evalúe su app de banca móvil como lo describe el CBK
Empiece con un escaneo gratuito de su app desde la tienda, o reserve una demo para realizar con nuestro equipo pruebas con sesión iniciada de su app y sus API.