Joint standards de la FSCA y la PA: evalúe su app de banca móvil antes y después de cada versión.
El Joint Standard 2 de 2024 pide a las instituciones financieras realizar periódicamente evaluaciones de vulnerabilidades y pruebas de penetración, probar las aplicaciones web y críticas durante el desarrollo y exigir autenticación multifactor para las cuentas que acceden a aplicaciones sensibles por internet. El Joint Standard 1 de 2023 fija el marco de gobernanza y gestión de riesgos de TI, y la POPIA añade garantías de seguridad y una obligación de notificar brechas sin umbral de riesgo. 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, aseguradoras, infraestructuras de mercado, fondos de pensiones y las demás instituciones financieras citadas en los joint standards
- Fechas clave
- Joint Standard 1 de 2023 aplicable desde el 15 de noviembre de 2024, Joint Standard 2 de 2024 desde el 1 de junio de 2025, y la plantilla de notificación de incidentes desde el 1 de septiembre de 2026
- Objeto
- Evaluación de vulnerabilidades, pruebas de penetración y pruebas de seguridad de aplicaciones, MFA y protección de datos, con las garantías de seguridad de la POPIA
- Referencia principal
- Joint Standard 2 de 2024 - Cybersecurity and Cyber Resilience Requirements
Los textos que rigen su canal móvil
Dos joint standards de la FSCA y la Prudential Authority, las comunicaciones de la PA sobre la nube y la POPIA. Las fechas siguientes corresponden a los textos citados en esta página.
- 26 de noviembre de 2013
La POPIA en el Boletín Oficial
El Protection of Personal Information Act 4 of 2013 se publica en el Government Gazette. El capítulo 9 regula las transferencias de datos personales fuera del territorio.
- 1 de julio de 2021
La POPIA plenamente aplicable
La POPIA entró en vigor el 1 de julio de 2020 y el periodo de gracia de un año terminó el 30 de junio de 2021. Las brechas de seguridad deben notificarse al Information Regulator.
- 10 de noviembre de 2023
Joint Standard 1 de 2023
La FSCA y la Prudential Authority publican los requisitos de gobernanza de TI y gestión de riesgos para las instituciones financieras, el primer joint standard vinculante de este tipo para el sector.
- 17 de mayo de 2024
Joint Standard 2 de 2024
Se publican los requisitos de ciberseguridad y ciberresiliencia: fundamentos, prácticas de higiene, pruebas y obligación de notificar incidentes importantes.
- 15 de noviembre de 2024
Entra en vigor el Joint Standard 1 de 2023
Los requisitos de gobernanza y gestión de riesgos de TI surten efecto para las instituciones financieras incluidas en su ámbito.
- 1 de junio de 2025
Entra en vigor el Joint Standard 2 de 2024
El Joint Notice 1 de 2024, publicado con la Joint Communication 5 de 2024, fija el 1 de junio de 2025 como fecha de efecto de los requisitos de ciberseguridad.
- 25 de julio de 2025
Comunicación sobre la nube y el offshoring
La Joint Communication 2 de 2025 recuerda la Directive 3 de 2018 y la Guidance Note 5 de 2018 de la PA y expone las prácticas recomendadas para la computación en la nube y el offshoring de datos, mientras se prepara un joint standard.
- 1 de septiembre de 2026
Plantilla de notificación de incidentes
El Joint Notice 2 de 2026 determina la Reporting of Material IT and Cyber Incident Template en virtud de ambos joint standards. Los bancos la envían por el portal Umoja; las demás instituciones financieras usan el Joint Standards Submission Portal de la FSCA.
Los joint standards y la POPIA, 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. Las citas de la POPIA se basan en el texto de la ley.
- Joint Standard 1 de 2023, párrafos 7.3(e) y 9.3(a); Joint Standard 2 de 2024, párrafos 7.1.1(d), 7.1.2 y 7.7.5(c)
Mantenga un inventario de lo que opera, incluidos los terceros
Qué dice el texto
El Joint Standard 1 de 2023 exige que el marco de gestión de riesgos de TI identifique y priorice los activos de TI y los proteja frente a accesos no autorizados, usos indebidos o modificaciones fraudulentas, y que mantenga un inventario actualizado de los activos de TI. El Joint Standard 2 de 2024 exige un inventario de todos los activos de información, con su ubicación y propietario, revisado periódicamente y al menos cada dos años, y una política sobre el uso y la actualización de código de terceros y de código abierto, de modo que se revise y pruebe antes de integrarlo.
Qué supone para su app móvil
Una app de banca móvil es un activo de información que integra SDK de terceros y bibliotecas nativas. Cada uno debe figurar en el inventario, con una versión y un responsable.
Cómo ayuda Ostorlab
Ostorlab enumera los SDK y las bibliotecas nativas de cada versión con sus versiones y su ubicación en el paquete de la app, y muestra con qué backends se comunican la app y sus SDK.
Qué sigue en sus manos
El propio inventario de activos, la diligencia debida sobre terceros y los contratos.
- Joint Standard 2 de 2024, párrafos 7.7.2 y 7.7.3
Evalúe y pruebe periódicamente la app y sus API
Qué dice el texto
Las instituciones financieras deben realizar evaluaciones periódicas de vulnerabilidades de los sistemas y activos de información, con una frecuencia acorde con su criticidad y el riesgo de seguridad al que están expuestos. Deben realizar pruebas de penetración de los sistemas y activos de información críticos para obtener una evaluación en profundidad de sus defensas, con pruebas black box, grey box o white box, o una combinación, según especifique la autoridad responsable. Para los sistemas y activos directamente accesibles desde internet, las pruebas de penetración deben realizarse siempre que sufran cambios o actualizaciones importantes y, si no los hay, al menos una vez al año.
Qué supone para su app móvil
Su app de banca móvil y las API a las que llama son directamente accesibles desde internet. Planifique pruebas en cada versión importante y al menos una al año, incluidas las pruebas con sesión iniciada.
Cómo ayuda Ostorlab
El 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. Los hallazgos se clasifican, se gestionan como tickets y se vuelven a probar tras la corrección.
Qué sigue en sus manos
La elección de quién realiza la prueba de penetración anual, las decisiones black o grey box, las pruebas en producción y la comunicación a la alta dirección.
- Joint Standard 2 de 2024, párrafos 7.2.4 y 7.7.5
Integre la seguridad y pruebe las aplicaciones durante el desarrollo
Qué dice el texto
El estándar exige un enfoque de seguridad desde el diseño, incorporada en cada fase del desarrollo de software para minimizar las vulnerabilidades del sistema y reducir la superficie de ataque. Los requisitos de seguridad relativos al control de acceso, la autenticación, la autorización de transacciones, la integridad de los datos, el registro, las pistas de auditoría, el seguimiento de eventos de seguridad y el tratamiento de excepciones deben especificarse en las etapas iniciales del desarrollo o la adquisición, y los cambios en aplicaciones críticas deben revisarse y probarse. Deben adoptarse normas de codificación segura, revisión de código fuente y pruebas de seguridad de aplicaciones, y probarse la seguridad funcional de las aplicaciones web y críticas durante el desarrollo y la implementación.
Qué supone para su app móvil
Cada versión de la app es un cambio en un canal expuesto a internet y debería superar pruebas de seguridad automatizadas antes de llegar a la tienda, incluidos los SDK y las bibliotecas que integra.
Cómo ayuda Ostorlab
Mobile SAST analiza directamente el APK, AAB o IPA, sin necesidad del código fuente, con análisis de propagación (taint) en los SDK integrados. Mobile DAST ejecuta la app, y ambos se ejecutan desde su pipeline de CI/CD en cada compilación.
Qué sigue en sus manos
Las normas de codificación segura, la formación de desarrolladores, la revisión manual de código y la aprobación de versiones.
- Joint Standard 2 de 2024, párrafos 7.7.6 y 8.5
Corrija con gravedad, prioridad y plazos de parche
Qué dice el texto
El proceso de corrección debe incluir la evaluación de la gravedad y la clasificación de los problemas, su priorización según el riesgo que plantean, plazos para corregir problemas de distinta gravedad, y evaluaciones de riesgo y estrategias de mitigación cuando proceda. Todos los problemas de las pruebas de ciberseguridad y los defectos de software hallados en la revisión de código y las pruebas de seguridad de aplicaciones deben seguirse, y los problemas mayores y fallos de seguridad conocidos deben corregirse antes del despliegue en producción. Los parches de seguridad deben aplicarse en un plazo acorde con los riesgos, con controles compensatorios cuando no exista parche, pruebas antes de producción y un plan de corrección con plazos cuando un parche no pueda aplicarse.
Qué supone para su app móvil
Cada hallazgo en la app o en una API necesita una gravedad, un plazo de corrección y un registro. Las bibliotecas de terceros son lo más fácil de olvidar.
Cómo ayuda Ostorlab
Ostorlab clasifica cada hallazgo como crítico, alto, medio o bajo, lo gestiona como ticket en la plataforma o en Jira y ServiceNow, y lo vuelve a probar tras la corrección. Los hallazgos de componentes incluyen recomendaciones de actualización o sustitución.
Qué sigue en sus manos
Las ventanas de parcheo, la aplicación de parches en servidores e infraestructura, la aceptación del riesgo y las decisiones de despliegue en producción.
- Joint Standard 2 de 2024, párrafos 7.2.2, 8.2 y 8.3
Identidad, accesos y MFA en las cuentas expuestas a internet
Qué dice el texto
El acceso a los activos de información debe limitarse a usuarios, procesos y dispositivos autorizados, gestionarse en función del riesgo evaluado de acceso no autorizado, con mecanismos de gestión de identidades y control de acceso, políticas de seguridad y control de acceso, acceso remoto solo desde dispositivos y conexiones seguros, y autenticación sólida para el acceso remoto. Cada cuenta administrativa debe protegerse frente a accesos y usos no autorizados, y el acceso privilegiado debe concederse según la necesidad de uso, con registro de actividad. La autenticación multifactor es obligatoria para los usuarios con acceso a funciones críticas, para todas las cuentas administrativas y privilegiadas, y para todas las cuentas de usuario que acceden por internet a aplicaciones con información sensible.
Qué supone para su app móvil
La app móvil es exactamente el tipo de aplicación que describe la regla de MFA. El servidor debe exigir el segundo factor, haga lo que haga la app.
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, junto con las llamadas a la API que hay detrás.
Qué sigue en sus manos
La elección de los métodos de autenticación, la gestión de accesos privilegiados, las revisiones de accesos y la política de dispositivos.
- Joint Standard 2 de 2024, párrafo 7.2.3; Joint Standard 1 de 2023, párrafo 10
Proteja los datos en el dispositivo y en tránsito
Qué dice el texto
El Joint Standard 2 de 2024 exige políticas de prevención de pérdida de datos para la información sensible, ya esté en movimiento, en reposo o en uso, medidas para prevenir y detectar accesos no autorizados a datos, su modificación, copia, transmisión y robo en sistemas y dispositivos, cifrado o control de acceso acorde con el riesgo para la información sensible almacenada en sistemas y dispositivos, y el uso exclusivo de sistemas y dispositivos autorizados. El Joint Standard 1 de 2023 exige medidas para proteger los datos de cuenta y de transacción de los clientes, control de acceso lógico con vigilancia de anomalías, y medidas frente al robo, la pérdida y la fuga de datos desde los dispositivos.
Fuente:Joint Standard 2 de 2024, párrafo 7.2.3; Joint Standard 1 de 2023, párrafo 10
Qué supone para su app móvil
Las contraseñas, los tokens y los datos de clientes no deberían quedar en texto claro en el teléfono ni viajar sin protección hasta el backend. Los dispositivos rooteados o con jailbreak debilitan cada uno de estos controles.
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 prueba el comportamiento de la app en entornos rooteados y con jailbreak.
Qué sigue en sus manos
La clasificación de datos, las herramientas DLP, la gestión de dispositivos móviles y la gestión de claves.
- Joint Standard 2 de 2024, párrafo 7.2.6
Gestione la criptografía y proteja las claves
Qué dice el texto
Cuando se utiliza criptografía, las políticas, normas y procedimientos deben cubrir la generación, distribución, instalación, renovación, revocación, recuperación y expiración de claves. Los algoritmos criptográficos deben proceder de normas internacionales consolidadas, las claves deben generarse de forma segura y protegerse frente a divulgación no autorizada en sistemas endurecidos y resistentes a la manipulación, las claves expiradas o revocadas deben destruirse de forma irrecuperable, y todos los algoritmos deben someterse a pruebas o verificaciones rigurosas frente a los objetivos de seguridad identificados.
Qué supone para su app móvil
El pinning de certificados, la firma de código y el uso del keystore son criptografía en la app. Lo que está en el paquete o en el keystore puede atacarse en un dispositivo modificado.
Cómo ayuda Ostorlab
Mobile Shielding Scan intenta eludir en tiempo de ejecución la detección de root y jailbreak, la protección contra manipulación y el TLS pinning, y muestra qué protecciones resistieron y cuáles se eludieron. Ostorlab también encuentra claves y secretos en el paquete de la app.
Qué sigue en sus manos
Los sistemas de gestión de claves, los HSM, el ciclo de vida de los certificados y la elección de algoritmos.
- Protection of Personal Information Act 4 of 2013, artículos 19, 21, 22 y 72
Cumpla las garantías y las obligaciones de notificación de la POPIA
Qué dice el texto
La POPIA exige al responsable del tratamiento proteger la integridad y la confidencialidad de los datos personales con medidas técnicas y organizativas apropiadas y razonables. Debe identificar los riesgos internos y externos razonablemente previsibles, establecer y mantener garantías frente a ellos, verificar periódicamente que se aplican de forma efectiva y actualizarlas ante nuevos riesgos o deficiencias. Un contrato escrito debe exigir al operador mantener las mismas medidas de seguridad, y el operador debe notificar de inmediato al responsable cuando existan motivos razonables para creer que una persona no autorizada ha accedido a datos personales. Cuando existan motivos razonables para creer que una persona no autorizada ha accedido a datos personales o los ha adquirido, el responsable debe notificarlo al Information Regulator y, salvo las excepciones, a la persona afectada, lo antes razonablemente posible. Las transferencias de datos personales fuera del territorio exigen un nivel de protección adecuado u otra base del artículo 72.
Fuente:Protection of Personal Information Act 4 of 2013, artículos 19, 21, 22 y 72
Qué supone para su app móvil
Probar la app es una forma de verificar las garantías del artículo 19 en el dispositivo y en la API. El Information Regulator señala que no hay umbral de riesgo: toda brecha de seguridad debe notificarse, y no hace falta confirmarla antes.
Cómo ayuda Ostorlab
Ostorlab prueba los controles técnicos de la app y sus API y le da evidencia de cada resultado. La calificación de la brecha y las notificaciones siguen correspondiendo a su information officer.
Qué sigue en sus manos
Las obligaciones del information officer, la evaluación de brechas, la notificación al Regulator y a las personas afectadas, y las decisiones de transferencia transfronteriza.
- Joint Standard 1 de 2023, párrafo 15.1; Joint Standard 2 de 2024, párrafo 9.1; Joint Notice 2 de 2026
Notifique los incidentes importantes en la forma determinada
Qué dice el texto
Ambos joint standards exigen que una institución financiera notifique a la autoridad responsable, en la forma y manera que determinen las autoridades, todo fallo, incidente cibernético o compromiso de seguridad de la información que haya clasificado como incidente importante. El Joint Notice 2 de 2026, publicado con la Joint Communication 5 de 2026, determina la Reporting of Material IT and Cyber Incident Template y entra en vigor el 1 de septiembre de 2026. Los bancos, bancos mutualistas, aseguradoras y sus sociedades de control la remiten por el portal Umoja; las demás instituciones financieras incluidas en el ámbito usan el Joint Standards Submission Portal de la FSCA.
Qué supone para su app móvil
Su procedimiento de clasificación y notificación de incidentes necesita la plantilla, el portal y el plazo indicado en su portada. La evidencia de los escaneos ayuda a determinar el alcance.
Cómo ayuda Ostorlab
Ostorlab no clasifica ni notifica incidentes. Le da evidencia de la vulnerabilidad o del fallo de control que hay detrás de un incidente y vuelve a probar las correcciones después.
Qué sigue en sus manos
La clasificación, la notificación, la comunicación con el regulador y los clientes, y el análisis forense.
- Joint Communication 2 de 2025, sección 4; Directive 3 de 2018 de la PA; Joint Standard 1 de 2023, párrafo 7.3(i)
Gobierne el uso de la nube y el offshoring de datos
Qué dice el texto
La Joint Communication 2 de 2025, publicada el 25 de julio de 2025, recuerda la Directive 3 de 2018 y la Guidance Note 5 de 2018 de la PA para bancos y expone prácticas recomendadas en materia de computación en la nube y offshoring de datos: un enfoque basado en el riesgo alineado con el apetito de riesgo, una gobernanza que abarque una política definida y una estrategia de datos aprobada por el consejo, atención a los requisitos contractuales y legales, y diligencia debida antes de inversiones estratégicas. El offshoring es el almacenamiento o tratamiento de datos fuera de las fronteras de Sudáfrica. Las autoridades indican que se está preparando un joint standard sobre nube y offshoring. El Joint Standard 1 de 2023 también exige seleccionar con cuidado a proveedores y contratistas y proteger contractualmente la información sensible o confidencial.
Qué supone para su app móvil
Si el backend de la app o sus SDK envían datos personales a servicios fuera de Sudáfrica, se aplican tanto el artículo 72 de la POPIA como las expectativas sobre la nube. La app se puede escanear allí donde vivan los datos.
Cómo ayuda Ostorlab
El escaneo on-premises se ejecuta en infraestructura que usted controla, dentro de su red. Escanea apps de preproducción, API y repositorios detrás de su firewall o VPN.
Qué sigue en sus manos
La estrategia de nube, la diligencia debida, los contratos, las decisiones de localización de datos y el futuro joint standard.
Resumen de los joint standards públicos, las comunicaciones de la Prudential Authority y el texto de la POPIA, consultados el 27 de septiembre de 2026. Los joint standards no mencionan las apps móviles por su nombre: se aplican a sistemas de TI, activos de información y aplicaciones en general, y esta página los aplica al canal móvil. Esta página no constituye asesoramiento jurídico.
Los controles de los joint standards, control por control
Los controles a los que apuntan los joint standards y la POPIA, 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 |
|---|---|---|
| Evaluación de vulnerabilidades de la app y sus APIJS2 7.7.2, 7.7.3 | Pentest con agentes de IA de la app y 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 |
| Pruebas de penetración ante cambios importantes, al menos anualesJS2 7.7.3(a)(iii) | Prueba la app y las API expuestas a internet en cada versión, para que la prueba anual nunca parta de una base obsoleta. Detalles | Resultados de escaneo por versión, con un exploit reproducible para cada hallazgo |
| Pruebas de seguridad de aplicaciones durante el desarrolloJS2 7.7.5 | Mobile SAST sobre el binario y Mobile DAST sobre la app en ejecución, desde CI/CD en cada compilación. Detalles | Hallazgos con contexto de código descompilado, tráfico, trazas y capturas de pantalla |
| Componentes de terceros y de código abiertoJS2 7.7.5(c), 7.7.6(b)(iii) | Identifica mediante huellas las bibliotecas compiladas estáticamente y las relaciona con vulnerabilidades conocidas, versión tras versión. Detalles | Vulnerabilidades asociadas con recomendaciones de actualización o sustitución, y cierre seguido entre versiones |
| Inventario de software y versionesJS1 9.3(a); JS2 7.1.1(d) | Enumera los SDK y las bibliotecas nativas de cada versión con sus números de versión, 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, por versión |
| Credenciales y accesos privilegiadosJS2 7.2.2, 8.2 | Detecta claves de API, tokens y credenciales en el paquete de la app y valida si funcionan. Detalles | Secretos validados, con los permisos y servicios que exponen |
| MFA y sesiones en cuentas expuestas a internetJS2 8.3, 7.2.2(a) | Inicia sesión con códigos de un solo uso, prueba la aplicación de la MFA y los flujos de autenticación reforzada, y después el cierre de sesión, la renovación de tokens, los tiempos de espera y la invalidación de sesiones. Detalles | Hallazgos sobre inicio de sesión, autenticación reforzada y sesiones, con pasos de reproducción y registros de solicitudes |
| Protección de datos en el dispositivo y en tránsitoJS2 7.2.3; POPIA art. 19 | 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 |
| Criptografía y resistencia a la manipulaciónJS2 7.2.6 | Intenta eludir en tiempo de ejecución la detección de root y jailbreak, la protección contra manipulación y el TLS pinning. Detalles | Una puntuación de endurecimiento, con evidencia de elusión de cada protección que falló |
| Plazos de corrección y nuevas pruebasJS2 7.7.6, 8.5 | Agrupa los hallazgos en tickets, vuelve a probar tras la corrección y sigue el cierre de componentes entre versiones. | Historial de tickets y resultado de la nueva prueba de cada hallazgo |
Ostorlab prueba los controles de la app y de sus API. La gobernanza, la supervisión del SOC, la respuesta a incidentes y su notificación, los ejercicios, las copias de seguridad y la recuperación, los contratos de nube y la seguridad física siguen correspondiendo a sus equipos.
Controles de los joint standards que probar en su app móvil
Una lista práctica para los equipos de seguridad y riesgo tecnológico, basada en el Joint Standard 2 de 2024, el Joint Standard 1 de 2023 y la POPIA.
La app móvil en el alcance
Incluya la app móvil en el alcance de su programa de evaluación de vulnerabilidades y pruebas de penetración, con una frecuencia y una fase previa a la publicación.
API expuestas a internet
Evalúe las API a las que llama la app como sistemas expuestos a internet: autorización, tokens, gestión de sesiones y solicitudes de datos de otros clientes.
En cada versión
Ejecute pruebas de seguridad de aplicaciones automatizadas en cada compilación y escanee cada versión publicada en la tienda, no solo la que probó el trimestre pasado.
Componentes y plazos
Mantenga una lista versionada de los SDK y bibliotecas de cada versión, y fije plazos de corrección según la gravedad.
Secretos y credenciales
Revise el paquete de la app en busca de claves de API, tokens y credenciales, renueve los que funcionen y pruebe las rutas de acceso privilegiado.
MFA y sesiones
Verifique que los inicios de sesión expuestos a internet exigen el segundo factor en el servidor, y pruebe la renovación de tokens, los tiempos de espera y la invalidación de sesiones.
Datos y protecciones contra manipulación
Busque tokens y datos personales en el almacenamiento, las cachés, los registros y las capturas de pantalla, y pruebe root, jailbreak, manipulación y pinning en una versión modificada.
Informe, vuelva a probar y notifique
Siga los hallazgos hasta el cierre con nuevas pruebas, ensaye la notificación de incidentes importantes con la plantilla y el portal determinados, y tenga lista la vía de notificación de brechas de la POPIA al Information Regulator.
Una lista sugerida, no una plantilla de los joint standards. Las obligaciones de notificación de la POPIA corresponden a su information officer. 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.
- Joint Standard 2 of 2024 - Cybersecurity and Cyber Resilience Requirements for Financial InstitutionsFSCA y Prudential Authority, publicado el 17 de mayo de 2024, en vigor el 1 de junio de 2025. Fundamentos, prácticas de higiene, pruebas (7.7) y notificación de incidentes importantes (9). Se aplica a bancos, bancos mutualistas, aseguradoras, infraestructuras de mercado, fondos de pensiones y las demás instituciones enumeradas en el estándar
- Joint Standard 1 of 2023 - Information Technology (IT) Governance and Risk Management Requirements for Financial InstitutionsFSCA y Prudential Authority, publicado el 10 de noviembre de 2023, entró en vigor el 15 de noviembre de 2024. Marco de gestión de riesgos de TI (7), operaciones de TI (9), tratamiento de información sensible o confidencial (10), aseguramiento de TI (14) y notificación (15)
- Joint Communication 5 of 2024 - Publicación del Joint Notice 1 of 2024 (entrada en vigor)FSCA y Prudential Authority, publicado el 28 de junio de 2024. El Joint Notice 1 de 2024 fija el 1 de junio de 2025 como fecha de efecto del Joint Standard 2 de 2024, en virtud de su párrafo 10.2
- Joint Notice 2 of 2026 - Determination of the Notification Template for Material IT and Cyber IncidentsFSCA y Prudential Authority, con fecha del 31 de agosto de 2026 y publicado con la Joint Communication 5 de 2026, en vigor el 1 de septiembre de 2026. Dictado en virtud del párrafo 15.1 del Joint Standard 1 de 2023 y del párrafo 9.1 del Joint Standard 2 de 2024; los bancos lo remiten por el portal Umoja
- Joint Communication 2 of 2025 - Cloud computing and data offshoringFSCA y Prudential Authority, con fecha del 25 de julio de 2025, publicada en el sitio de la Prudential Authority el 28 de julio de 2025. Prácticas recomendadas para la computación en la nube y el offshoring de datos, y aviso de un joint standard en preparación
- PA Directive 3 of 2018 - Cloud computing and the offshoring of dataPrudential Authority, publicada el 6 de septiembre de 2018 para los bancos, con la Guidance Note 5 de 2018. Recordada por la Joint Communication 2 de 2025
- Protection of Personal Information Act 4 of 2013 (POPIA)República de Sudáfrica, publicada en el Boletín Oficial el 26 de noviembre de 2013, en vigor desde el 1 de julio de 2020, con las últimas disposiciones de entrada en vigor en 2021. Artículos 19, 21 y 22 (garantías de seguridad, operadores y notificación de brechas) y artículo 72 (transferencias fuera del territorio)
- Fact Sheet: Handling of Security CompromisesInformation Regulator, 19 de agosto de 2025. La POPIA no fija umbral de riesgo para notificar brechas de seguridad; notifique al Regulator y a las personas afectadas en cuanto haya certeza razonable, a través del portal eServices
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 la describen los joint standards
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.