Reglas del RBI: evalúe su app bancaria móvil antes y después de cada versión.

1. 01

   Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, párrafos 149 a 161

   Pruebe las apps críticas expuestas a Internet a intervalos fijos

   Qué dice el texto

   Realice ejercicios de VA y PT de forma periódica para todos los sistemas críticos y expuestos a Internet, y realice periódicamente VA y PT de las aplicaciones web y móviles críticas expuestas a Internet a lo largo de su ciclo de vida, incluidos el preimplementación, la postimplementación y los cambios. Para los sistemas de información críticos, y para los sistemas en la DMZ con interfaz de cliente, realice una VA al menos cada seis meses y una PT al menos una vez cada 12 meses; para los demás sistemas, adopte un enfoque basado en el riesgo. Las pruebas posteriores a la implementación se realizan en el entorno de producción, o en un entorno de prueba similar a producción con cualquier desviación documentada y aprobada. Corrija las vulnerabilidades identificadas en plazos definidos y presente el estado de cierre al Comité de Estrategia de TI y al Comité de Seguridad de la Información al menos cada trimestre.

   Fuente:Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, párrafos 149 a 161

   Qué supone para su app móvil

   Su app móvil es una aplicación crítica expuesta a Internet con interfaz de cliente. Necesita una VA semestral, una PT anual y pruebas después de cada cambio, no solo una vez en el lanzamiento.

   Cómo ayuda Ostorlab

   Mobile SAST analiza el binario, incluidos los SDK integrados, y Mobile DAST prueba la app en ejecución; ambos se ejecutan en CI/CD. El pentest con agentes de IA prueba la app y sus API con sesión iniciada, con un exploit funcional que puede reproducir para cada hallazgo de un agente de IA.

   Qué sigue en sus manos

   Definir el alcance y la frecuencia para servidores y componentes de red, designar a los auditores de VA y PT y reportar el cierre a los comités.

2. 02

   Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026, párrafo 68; Master Direction on Digital Payment Security Controls, 18 de febrero de 2021, capítulo IV, para la redacción anterior

   Aplique los controles de las apps de pago móvil

   Qué dice el texto

   Los controles de las aplicaciones de pago móvil exigen que el banco pueda verificar la versión de la app antes de habilitar las transacciones y que implemente la aplicación de políticas de dispositivo según su evaluación de riesgos, incluidas comprobaciones de sistema operativo vulnerable, aplicaciones vulnerables o maliciosas y configuraciones Wi-Fi inseguras; aislamiento o contenedorización y cifrado de la app; recogida y permisos mínimos de datos; identificación de aplicaciones de acceso remoto y prohibición del inicio de sesión desde ellas; y ofuscación del código. Las versiones antiguas deben desactivarse de forma gradual y en plazos definidos, sin superar los seis meses desde la publicación de una versión más nueva. El banco debe alojar la suma de verificación de la versión activa en una plataforma pública, implementar el vínculo del dispositivo, exigir reautenticación tras un periodo de inactividad y en cada inicio, e identificar conexiones desde redes no seguras. El banco también puede validar la seguridad y compatibilidad del dispositivo, el sistema operativo y la aplicación, y puede comprobar si un dispositivo tiene root o jailbreak antes de la instalación e impedir que la app se instale o funcione en ese caso.

   Fuente:Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026, párrafo 68; Master Direction on Digital Payment Security Controls, 18 de febrero de 2021, capítulo IV, para la redacción anterior

   Qué supone para su app móvil

   Son controles que su app tiene o no tiene, y cada uno es verificable en la versión que descargan sus clientes: comprobaciones de root y jailbreak, detección de acceso remoto, ofuscación, comprobaciones de versión y vínculo del dispositivo.

   Cómo ayuda Ostorlab

   Mobile Shielding Scan prueba en tiempo de ejecución la detección de root y jailbreak, la protección contra manipulación y el pinning, y muestra qué protecciones resistieron y cuáles se evadieron. Ostorlab también informa la versión de la app, los permisos y las conexiones de red que observa.

   Qué sigue en sus manos

   Redactar la política de dispositivo, alojar la suma de verificación, mantener los registros de vínculo de dispositivos y notificar a los clientes los nuevos registros de dispositivo.

3. 03

   Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026, párrafos 27 a 39; Cybersecurity Directions, 2026, párrafos 83 a 87

   Integre la seguridad desde el diseño y pruebe antes y después de cada versión

   Qué dice el texto

   Adopte un enfoque de seguridad desde el diseño e integre la seguridad en todo el ciclo de vida de la aplicación: objetivos de seguridad en las fases de requisitos, diseño, desarrollo, pruebas, implementación y retirada; modelado de amenazas; prácticas de codificación segura; y pruebas de seguridad alineadas con estándares globales, incluidos OWASP y OWASP MASVS. Realice pruebas de seguridad, incluida la revisión del código fuente, VA y PT, de las aplicaciones de pago digital: VA al menos semestral, PT al menos anual, y ambas cuando se introduzca una nueva aplicación o infraestructura o se realice un cambio importante. Cuando el código fuente no sea propiedad del banco, obtenga del desarrollador un certificado de que la aplicación está libre de vulnerabilidades conocidas, malware y canales encubiertos. Compare los resultados con los escaneos anteriores para confirmar que no hay reincidencia y corrija las vulnerabilidades en plazos definidos. Las direcciones de ciberseguridad añaden pruebas de seguridad de aplicaciones web y móviles durante todo su ciclo de vida, en un entorno similar a producción.

   Fuente:Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026, párrafos 27 a 39; Cybersecurity Directions, 2026, párrafos 83 a 87

   Qué supone para su app móvil

   Cada versión de la app es un cambio en un canal expuesto a Internet. Las pruebas automatizadas en el pipeline cubren el antes; los escaneos de las versiones publicadas en las tiendas cubren el después.

   Cómo ayuda Ostorlab

   Ostorlab ejecuta escaneos automatizados desde su pipeline CI/CD en cada compilación y monitoriza las versiones publicadas en las tiendas sin activación manual. Mobile SAST funciona con el APK, AAB o IPA, sin necesidad del código fuente.

   Qué sigue en sus manos

   Los requisitos de seguridad, los modelos de amenazas, los estándares de codificación segura, las revisiones de código fuente y la aprobación de versiones.

4. 04

   Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025, párrafos 6, 8 y 9

   Dos factores, uno de ellos dinámico

   Qué dice el texto

   Todas las transacciones de pago digital deben autenticarse con al menos dos factores distintos, salvo exención, y para las transacciones distintas de las de tarjeta presente al menos un factor debe crearse o probarse de forma dinámica, es decir, la prueba enviada con la transacción es única para esa transacción. El factor debe ser robusto: el compromiso de un factor no debe afectar la fiabilidad del otro. Los emisores pueden ofrecer una elección de factores, añadir comprobaciones basadas en el riesgo según el comportamiento y el contexto, como la ubicación y los atributos del dispositivo, y deben garantizar la robustez e integridad del mecanismo antes de su despliegue. Si se produce una pérdida por una transacción que no cumplió, el emisor debe compensar al cliente en su totalidad sin demora. El cumplimiento era obligatorio el 1 de abril de 2026.

   Fuente:Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025, párrafos 6, 8 y 9

   Qué supone para su app móvil

   El segundo factor debe imponerlo el servidor en cada pago, y debe ser dinámico. El OTP por SMS es una opción, pero las direcciones permiten otras, como el vínculo del dispositivo, la biometría o la PKI.

   Cómo ayuda Ostorlab

   Las pruebas autenticadas completan códigos de un solo uso por SMS, correo o TOTP con sus cuentas de prueba y verifican la aplicación de la MFA, los flujos de autenticación reforzada y las llamadas de API detrás de los pagos.

   Qué sigue en sus manos

   Elegir los factores, el análisis de exenciones, la comunicación a los clientes y el proceso de compensación.

5. 05

   Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, párrafos 107, 110 y 115; Digital Payment Security Controls Directions, 2026, párrafo 46

   Autentique a los clientes y a los usuarios privilegiados

   Qué dice el texto

   El banco debe implementar un marco de autenticación que garantice la verificación positiva de la identidad de los clientes que acceden a sus servicios en todos los canales, y actuar como proveedor de identidad para el acceso de los clientes a sistemas asociados mediante tecnologías de autenticación seguras. Sobre la base de una evaluación de riesgos, debe implementar autenticación de dos factores o multifactor, incluida la MFA obligatoria para usuarios privilegiados de sistemas de información críticos y para actividades críticas, y proteger las credenciales de usuario, como los identificadores de acceso, la información de autenticación y los tokens, contra fugas y ataques. Las direcciones de seguridad de pagos digitales añaden MFA y alertas para todas las transacciones de pago, incluidos débitos y créditos, nuevas vinculaciones de cuentas, cambios en los datos de la cuenta y revisiones de los límites de transferencia.

   Fuente:Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, párrafos 107, 110 y 115; Digital Payment Security Controls Directions, 2026, párrafo 46

   Qué supone para su app móvil

   El inicio de sesión, los retiros, los cambios de beneficiarios y de límites son momentos en los que el backend debe exigir el factor correcto. El manejo de tokens en el dispositivo forma parte del mismo control.

   Cómo ayuda Ostorlab

   Ostorlab encuentra claves de API, tokens y credenciales en el paquete de la app y valida si funcionan, y prueba las API en busca de autorización rota (BOLA, BFLA, IDOR) y uso indebido de tokens y sesiones.

   Qué sigue en sus manos

   La verificación de identidad, la gestión de accesos privilegiados, las revisiones de acceso y la elección de tecnologías de autenticación.

6. 06

   Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026, párrafos 48 a 51

   Sesiones, intentos fallidos y alertas

   Qué dice el texto

   Una sesión autenticada y su protocolo de cifrado deben mantenerse intactos durante toda la interacción; si hay interferencias o el cliente cierra la aplicación, la sesión debe terminar y las transacciones afectadas resolverse o revertirse, notificando al cliente con prontitud. El banco debe fijar el número máximo de intentos fallidos de inicio de sesión o autenticación tras el cual se bloquea el acceso, disponer de un procedimiento seguro de reactivación y notificar al cliente los intentos fallidos. También debe implementar medidas contra ataques de intermediario, de intermediario en el navegador y de intermediario en la aplicación, de modo que los datos en tránsito estén protegidos y las transacciones solo se autentiquen desde una fuente o proceso genuino.

   Fuente:Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026, párrafos 48 a 51

   Qué supone para su app móvil

   La gestión de sesiones es un comportamiento verificable: tiempos de espera, renovación de tokens, invalidación al cerrar sesión o la app, bloqueo tras intentos fallidos y las llamadas de API detrás de cada uno.

   Cómo ayuda Ostorlab

   Las pruebas autenticadas cubren inicio y cierre de sesión, renovación de tokens, tiempos de espera, invalidación de sesiones y bloqueo, junto con las llamadas de API detrás de ellos, e incluyen pasos de reproducción para cada hallazgo.

   Qué sigue en sus manos

   Los canales de alerta, el proceso de reactivación y las reglas de monitorización de fraude que consumen las alertas.

7. 07

   Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026, párrafos 22, 24 y 68(10) a 68(13); Digital Lending Directions, 2025, párrafos 12 y 13

   Proteja los datos en el dispositivo y en tránsito

   Qué dice el texto

   Las aplicaciones web no deben almacenar información sensible en campos ocultos HTML, cookies u otros almacenes del lado del cliente. Los controles criptográficos deben usar longitudes de clave, algoritmos, suites de cifrado y protocolos robustos, no obsoletos ni demostrados inseguros. La aplicación móvil no debe almacenar ni retener en el dispositivo información personal o de autenticación sensible, como identificadores, contraseñas, claves, hashes o referencias codificadas, y debe borrar de forma segura la información sensible del cliente de la memoria cuando este salga. Debe limitar lo que se escribe en archivos temporales y proteger lo que se escriba, evitar consultas SQL sin procesar y la inyección SQL, y negarse a cargar contenido web cuando se detecten errores de negociación SSL o TLS. La información sensible escrita en la base de datos de la app debe estar cifrada. Para las apps de préstamo, las Digital Lending Directions prohíben el acceso a recursos del teléfono como archivos y medios, listas de contactos, registros de llamadas y funciones de telefonía, y exigen que los datos de préstamos digitales se almacenen en servidores en la India.

   Fuente:Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026, párrafos 22, 24 y 68(10) a 68(13); Digital Lending Directions, 2025, párrafos 12 y 13

   Qué supone para su app móvil

   Las contraseñas, tokens y datos personales nunca deben estar en texto claro en el teléfono, en archivos temporales, registros o capturas de pantalla, ni viajar sin protección al backend.

   Cómo ayuda Ostorlab

   Ostorlab busca tokens de sesión y datos personales en el almacenamiento local, cachés, registros, archivos temporales y capturas de pantalla, detecta configuraciones que debilitan la protección del transporte y las sesiones, y captura evidencia del sistema de archivos que muestra qué se escribió, dónde y cuándo.

   Qué sigue en sus manos

   La clasificación de datos, la gestión de claves, las copias de seguridad, los avisos de privacidad y la prevención de fugas de datos.

8. 08

   Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, párrafos 47 y 126 a 135; Digital Payment Security Controls Directions, 2026, párrafo 32

   Conozca sus componentes y sus terceros

   Qué dice el texto

   Mantenga un inventario actualizado de los activos de información, incluidas las aplicaciones de negocio, la infraestructura de TI de soporte, el hardware, el software y los servicios, indicando su criticidad. Las direcciones de seguridad de pagos digitales exigen obtener del desarrollador o proveedor de la aplicación un certificado o confirmación escrita de que la aplicación está libre de vulnerabilidades conocidas, malware y canales encubiertos, cada vez que se realicen cambios importantes en el código, y poner en marcha un depósito del código fuente u otros acuerdos para las aplicaciones licenciadas por terceros. Los acuerdos con terceros necesitan una evaluación del riesgo del proveedor proporcional al riesgo y la materialidad, diligencia debida y supervisión, contratos que prevean derechos de auditoría, y atención a la ubicación geográfica de la infraestructura y a los movimientos transfronterizos de datos.

   Fuente:Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, párrafos 47 y 126 a 135; Digital Payment Security Controls Directions, 2026, párrafo 32

   Qué supone para su app móvil

   Una app bancaria móvil incluye SDK de terceros que hablan con sus propios backends. Deben estar en su inventario de activos, su SBOM y su visión del riesgo de terceros.

   Cómo ayuda Ostorlab

   Ostorlab enumera los SDK y bibliotecas nativas de cada versión con sus versiones y su ubicación en el paquete de la app, los relaciona con vulnerabilidades conocidas versión tras versión y muestra qué intercambian la app y sus SDK con los backends por la red.

   Qué sigue en sus manos

   El inventario de activos, la diligencia debida de proveedores, los certificados, los acuerdos de depósito y los contratos.

9. 09

   Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, párrafos 37, 98 a 103 y 153

   Gestione vulnerabilidades y parches con plazos

   Qué dice el texto

   Establezca políticas documentadas de gestión de cambios y parches que evalúen el impacto de negocio de los parches, los apliquen de forma segura y oportuna con las aprobaciones necesarias y prevean una forma de recuperarse de despliegues fallidos. Adopte una estrategia documentada y basada en el riesgo para mantener un inventario de los componentes que requieren parches, identificar los parches aplicables y aplicarlos a tiempo para minimizar el número de sistemas vulnerables y la duración de la exposición. Vigile las fechas de fin de soporte del software y evite software obsoleto o sin soporte. Corrija las vulnerabilidades identificadas en plazos definidos y compruebe que las vulnerabilidades conocidas, como las de la base CVE, no reaparezcan.

   Fuente:Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, párrafos 37, 98 a 103 y 153

   Qué supone para su app móvil

   Las bibliotecas y SDK dentro de su app son software que usted entrega. Cada uno necesita una versión conocida, una severidad cuando aparece una vulnerabilidad y un plazo de corrección que pueda demostrar.

   Cómo ayuda Ostorlab

   SCA identifica las bibliotecas compiladas estáticamente y las relaciona con vulnerabilidades conocidas, versión tras versión. Los hallazgos se clasifican como críticos, altos, medios o bajos, se siguen como tickets en la plataforma o en Jira y ServiceNow, y se vuelven a probar cuando se publica la corrección.

   Qué sigue en sus manos

   El parcheo de servidores e infraestructura, los contratos de mantenimiento de proveedores y las decisiones de aceptación de riesgos.

10. 10

    Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, párrafo 182; directrices CERT-In No. 20(3)/2022-CERT-In, 28 de abril de 2022; Digital Personal Data Protection Rules, 2025, reglas 6 y 7

    Notifique incidentes y brechas, conserve los registros en la India

    Qué dice el texto

    Los incidentes cibernéticos deben notificarse en las seis horas siguientes a su detección en la plataforma DAKSH, el sistema avanzado de supervisión del RBI, y el banco también debe notificar a CERT-In. Según las directrices de CERT-In de 2022, los incidentes especificados deben llegar a CERT-In en las seis horas siguientes a su detección, los registros de los sistemas TIC deben conservarse de forma segura durante 180 días móviles dentro de la jurisdicción india, y los relojes de los sistemas deben sincronizarse con la hora de NIC o NPL. Según las DPDP Rules de 2025, una brecha de datos personales debe comunicarse sin demora a los titulares de los datos afectados y a la Junta de Protección de Datos, con información detallada en 72 horas, y los registros de seguridad deben conservarse un año.

    Fuente:Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, párrafo 182; directrices CERT-In No. 20(3)/2022-CERT-In, 28 de abril de 2022; Digital Personal Data Protection Rules, 2025, reglas 6 y 7

    Qué supone para su app móvil

    Una brecha descubierta a través de la app o de una API pone en marcha el reloj. Las ventanas de seis horas y 72 horas empiezan en la detección, y la evidencia debe estar lista.

    Cómo ayuda Ostorlab

    Ostorlab no notifica incidentes al RBI, a CERT-In ni a la Junta de Protección de Datos. Le entrega la evidencia técnica, exploits reproducibles y registros de solicitudes y respuestas, que sus equipos de incidentes y legal necesitan para el informe.

    Qué sigue en sus manos

    La detección y la monitorización, las notificaciones a DAKSH y CERT-In, la notificación de brechas y la evaluación jurídica.

Resumen de textos públicos del RBI, el MeitY y CERT-In, verificados el 27 de septiembre de 2026. Las direcciones de julio de 2026 se aplican a los bancos comerciales; el RBI publicó direcciones similares por tipo de entidad para las demás entidades reguladas, y los textos de 2021 y 2023 citados aquí fueron derogados para los bancos comerciales el 31 de julio de 2026. Esta página no constituye asesoramiento jurídico.