APRA y ASIC: pruebe su app de banca móvil como lo describen los textos.
CPS 234 exige un programa de pruebas sistemáticas de los controles que protegen los activos de información, y CPG 234 indica que un conjunto suficiente de controles debe probarse al menos una vez al año, y que los controles expuestos a entornos no controlados deben probarse a lo largo del año. Una app de banca móvil y las API que la sustentan están exactamente en ese entorno. Ostorlab las prueba en cada release, con sesión iniciada, y el marco de prevención de estafas y el Consumer Data Right añaden sus propios controles a la misma app.
- Prueba la app y las API que la sustentan en la versión que descargan los clientes, con evidencia para cada release
- Cubre los controles que cita CPG 234, desde la gestión de vulnerabilidades hasta el desarrollo seguro y la protección del cliente
- Inicia sesión con sus cuentas de prueba y completa códigos de un solo uso para probar pagos, cambios de beneficiario y sesiones
- Asocia cada hallazgo con las cláusulas de APRA, del marco de prevención de estafas y del Consumer Data Right que ayuda a documentar
- A quién aplica
- A las ADI y otras entidades reguladas por APRA para CPS 234 y CPS 230; a los bancos como titulares de datos del Consumer Data Right; a los bancos del sector bancario del marco de prevención de estafas
- Fechas clave
- CPS 234 en vigor desde el 1 de julio de 2019; CPS 230 desde el 1 de julio de 2025, con enmiendas efectivas el 1 de julio de 2026; la mayoría de las obligaciones del marco de prevención de estafas desde el 31 de marzo de 2027
- Enfoque
- Pruebas sistemáticas de los controles de seguridad de la información, pruebas de apps y API, riesgo de terceros y de datos, controles antifestafas y seguridad de las API del Consumer Data Right
- Referencias principales
- CPS 234 y CPG 234, CPS 230, CPG 235, la Scams Prevention Framework Act 2025, las Consumer Data Right Rules y la Privacy Act 1988
Los textos australianos detrás de su canal móvil
Las normas prudenciales fijan la base de seguridad de la información y riesgo operativo. Los regímenes de estafas y de intercambio de datos se han añadido desde 2025. Las fechas corresponden a los textos citados en esta página.
- Septiembre de 2013
CPG 235 Managing Data Risk
APRA publica su guía sobre el riesgo de datos a lo largo de su ciclo de vida: captura, procesamiento, retención, publicación y eliminación, incluida la externalización y la deslocalización.
- 1 de julio de 2019
CPS 234 Information Security
Entra en vigor la norma prudencial: capacidad de seguridad de la información, controles y un programa de pruebas sistemáticas. Los requisitos para activos gestionados por terceros se aplicaban desde la renovación del contrato o el 1 de julio de 2020, lo que ocurriera antes.
- 1 de julio de 2025
CPS 230 Operational Risk Management
Entra en vigor la nueva norma transversal: controles de riesgo operativo, continuidad de negocio y gestión de proveedores, con un periodo de transición para los contratos existentes.
- 29 de mayo de 2026
Designación del marco de prevención de estafas
Entra en vigor la designación de los servicios bancarios cubiertos. ASIC pasa a ser el regulador sectorial y la adhesión a AFCA es obligatoria desde el 1 de septiembre de 2026. La mayoría de las obligaciones se aplican desde el 31 de marzo de 2027.
- 1 de julio de 2026
Enmiendas de CPS 230 en vigor
Entran en vigor las enmiendas específicas finalizadas el 30 de abril de 2026, y todos los requisitos de CPS 230 se aplican ya a todas las entidades reguladas por APRA, incluidas las instituciones financieras no significativas.
- 31 de marzo de 2027
Obligaciones antifestafas para los bancos
La mayoría de las obligaciones del marco de prevención de estafas se aplican al sector bancario: gobernanza, prevención, detección, notificación, interrupción, resolución interna de disputas y adhesión al esquema externo.
Las normas australianas, aplicadas a su app móvil
Para cada regla: qué dice el texto, qué supone para una app de banca móvil, cómo ayuda Ostorlab y qué sigue en sus manos. CPS 234 y CPS 230 son normas prudenciales; CPG 234 y CPG 235 son guías.
- CPS 234, párrafos 27 a 31; CPG 234, Testing control effectiveness
Probar sistemáticamente los controles de seguridad de la información
Qué dice el texto
Una entidad regulada por APRA debe probar la eficacia de sus controles de seguridad de la información mediante un programa de pruebas sistemáticas. La naturaleza y la frecuencia deben ser proporcionales a la velocidad de cambio de las vulnerabilidades y amenazas, la criticidad y sensibilidad del activo, las consecuencias de un incidente, los riesgos de exposición a entornos donde la entidad no puede hacer cumplir sus políticas, y la materialidad y frecuencia de los cambios en los activos de información. Las pruebas deben realizarlas especialistas con la cualificación adecuada y funcionalmente independientes, y la suficiencia del programa debe revisarse al menos una vez al año o cuando haya un cambio material. CPG 234 añade que la frecuencia y el alcance deben cubrir un conjunto suficiente de controles al menos una vez al año, y que los controles que protegen activos expuestos a entornos no controlados, incluido internet, deben probarse a lo largo del año.
Fuente:CPS 234, párrafos 27 a 31; CPG 234, Testing control effectiveness
Qué supone para su app móvil
Una app de banca móvil y sus API son activos de información expuestos a internet que cambian en cada release. Deben formar parte del programa de pruebas sistemáticas, y la cadencia de releases debe marcar la frecuencia de las pruebas, no solo la revisión anual.
Cómo ayuda Ostorlab
Ostorlab ejecuta escaneos automatizados desde su canal CI/CD en cada build y vigila las versiones publicadas en las tiendas sin activación manual. Un pentest con agentes de IA prueba la app y sus API con sesión iniciada, y cada hallazgo de un agente de IA incluye un exploit funcional que puede reproducir.
Qué sigue en sus manos
El propio programa de pruebas, las decisiones sobre la independencia de los probadores, la escalada de deficiencias de control que no puedan corregirse a tiempo y la auditoría interna.
- CPS 234, párrafo 21; CPG 234, Implementation of controls
Gestionar vulnerabilidades con plazos de respuesta
Qué dice el texto
Los controles de seguridad de la información deben ser proporcionales a las vulnerabilidades y amenazas de los activos. CPG 234 espera controles de gestión de vulnerabilidades que las identifiquen y aborden de forma oportuna, y controles de gestión de parches que gestionen la evaluación y aplicación de parches y otras actualizaciones que corrigen vulnerabilidades conocidas de forma oportuna. Estas expectativas cubren los activos gestionados por terceros y partes relacionadas, y alimentan la seguridad que recibe el consejo sobre el entorno de control.
Fuente:CPS 234, párrafo 21; CPG 234, Implementation of controls
Qué supone para su app móvil
Los SDK y las bibliotecas nativas dentro de su app son software que usted distribuye. Cada uno necesita una versión conocida, una severidad cuando aparece una vulnerabilidad y un plazo de corrección que pueda demostrar. Lo mismo se aplica a los componentes de backend de los que depende la app.
Cómo ayuda Ostorlab
SCA identifica las bibliotecas compiladas estáticamente y las asocia a vulnerabilidades conocidas, release tras release. 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 con proveedores, las decisiones de aceptación del riesgo y la información al consejo.
- CPG 234, Attachment D (Software security) y Security in change management
Integrar la seguridad y probar cada cambio
Qué dice el texto
APRA espera consideraciones de seguridad de la información en todo el ciclo de vida de entrega de software, incluso cuando se usan métodos ágiles: requisitos, diseño, selección y configuración, pruebas e implementación. La seguridad en la gestión de cambios incluye pruebas y revisiones para identificar vulnerabilidades y confirmar que se cumplen los requisitos de seguridad, con una naturaleza de las pruebas proporcional al alcance del cambio y a la sensibilidad del activo afectado, y aprobación de los cambios antes del despliegue en producción. Los estándares de software deben cubrir áreas como autenticación, autorización, gestión de sesiones, validación de datos, criptografía, registro y manejo seguro de entradas y salidas.
Fuente:CPG 234, Attachment D (Software security) y Security in change management
Qué supone para su app móvil
Cada release de la app es un cambio en un activo expuesto a internet. Las pruebas automatizadas pertenecen al canal antes de que el build llegue a la tienda, y los SDK incluidos forman parte del cambio.
Cómo ayuda Ostorlab
Mobile SAST analiza directamente el APK, AAB o IPA, sin código fuente, con análisis de propagación (taint) en los SDK integrados. Mobile DAST ejecuta la app y captura tráfico, trazas de pila y capturas de pantalla. Ambos se ejecutan desde su canal CI/CD en cada build.
Qué sigue en sus manos
Los estándares de codificación segura, la formación de desarrolladores, la revisión manual del código y la decisión de aprobación antes de producción.
- CPS 234, párrafos 16, 20, 22 y 28; CPG 234, Information asset identification and classification
Conocer sus activos de información y sus terceros
Qué dice el texto
Una entidad regulada por APRA debe clasificar sus activos de información, incluidos los gestionados por partes relacionadas y terceros, por criticidad y sensibilidad. Cuando los activos los gestiona una parte relacionada o un tercero, la entidad debe evaluar la capacidad de seguridad de la información de esa parte, evaluar el diseño de sus controles de seguridad y, cuando se apoye en las pruebas de control de esa parte, evaluar si la naturaleza y frecuencia de esas pruebas son proporcionales a los factores de la norma.
Fuente:CPS 234, párrafos 16, 20, 22 y 28; CPG 234, Information asset identification and classification
Qué supone para su app móvil
Su inventario de activos debe incluir la app móvil, las API que llama y los SDK que integra. Una app de marca blanca o una versión creada por un proveedor sigue conllevando sus obligaciones.
Cómo ayuda Ostorlab
Ostorlab lista los SDK y las bibliotecas nativas de cada release con sus versiones y su ubicación en el paquete de la app, y muestra qué intercambian la app y sus SDK con los backends por la red. Ostorlab cuenta con auditoría SOC 2 Type II, y el informe está disponible bajo petición.
Qué sigue en sus manos
El registro de activos, la diligencia debida de terceros, los contratos y las decisiones de apoyarse en las pruebas de un proveedor.
- CPG 235, Data life-cycle management, Retention, Desensitisation y Outsourcing/offshoring; CPS 230, párrafo 23
Gestionar el riesgo de datos en todo su ciclo de vida
Qué dice el texto
CPG 235 espera que el riesgo de datos se considere en cada etapa del ciclo de vida: captura, procesamiento, retención, publicación y eliminación. Espera controles de retención y una estrategia formal de retención, desensibilización como cifrado o desidentificación cuando los datos pasan a un entorno menos fiable, auditabilidad de los datos y sus cambios, y una evaluación prudente de la externalización y la deslocalización, incluida la capacidad de continuar las operaciones, cumplir los requisitos prudenciales y dar a APRA acceso oportuno a los datos en forma utilizable. CPS 230 nombra el riesgo de datos entre los riesgos operativos que la entidad debe gestionar.
Qué supone para su app móvil
Los datos de cuentas, los tokens y la información personal del teléfono forman parte del ciclo de vida de los datos. Las decisiones de retención y desensibilización se aplican a cachés, registros, capturas de pantalla y almacenamiento local, no solo a las bases de datos.
Cómo ayuda Ostorlab
Ostorlab busca tokens de sesión y datos personales en el almacenamiento local, cachés, registros y capturas de pantalla, y comprueba configuraciones erróneas que debilitan las protecciones de transporte y sesión.
Qué sigue en sus manos
La clasificación de datos, los calendarios de retención, la política de desensibilización, la gobernanza de datos y las evaluaciones de deslocalización.
- CPG 234, Attachment F (Customer security)
Proteger a los clientes en los canales digitales
Qué dice el texto
CPG 234 describe controles para productos y servicios prestados por canales digitales: autenticación proporcional a las amenazas; notificación o confirmación por un segundo canal para eventos como transferencias, nuevos beneficiarios, cambio de dirección o acceso desde un dispositivo no reconocido; límites como los de transferencia y transacción diaria; monitorización de la actividad transaccional; procedimientos documentados para fraude, fuga de datos y suplantación de identidad; y minimización de la recogida de información sensible del cliente usada para autenticación, como contraseñas y PIN.
Qué supone para su app móvil
La MFA, los controles reforzados, las notificaciones y los límites deben aplicarse en el backend en cada operación clave, incluso cuando la app o un atacante intenta saltarse un paso.
Cómo ayuda Ostorlab
Ostorlab inicia sesión con sus cuentas de prueba, completa códigos de un solo uso por SMS, correo o TOTP, y prueba la aplicación de la MFA y los flujos de autenticación reforzada, incluidas las formas en que los atacantes intentan manipularlos, junto con las llamadas API detrás de cambios de cuenta, beneficiarios y transferencias.
Qué sigue en sus manos
La elección de los métodos de autenticación, los límites de transacción, la monitorización de fraude y la concienciación del cliente.
- CPS 230, párrafos 29, 48 a 50 y 60
Tratar el riesgo operativo y los proveedores como un solo sistema
Qué dice el texto
CPS 230 exige que una entidad monitorice, revise y pruebe regularmente sus controles en cuanto a diseño y eficacia operativa, con una frecuencia proporcional a la materialidad de los riesgos controlados, que informe de los resultados a la alta dirección y corrija lagunas o deficiencias de forma oportuna. Debe identificar y mantener un registro de proveedores materiales, enviar ese registro a APRA cada año, notificar a APRA en un plazo de 20 días hábiles la celebración o modificación sustancial de un acuerdo de un servicio del que depende para una operación crítica, y notificar a APRA antes de un acuerdo material de deslocalización. La gestión de riesgos, los servicios tecnológicos esenciales y la auditoría interna deben clasificarse como proveedores materiales salvo justificación en contrario.
Qué supone para su app móvil
La app depende de servicios tecnológicos esenciales y de proveedores de SDK y API. Los controles que la mantienen en funcionamiento forman parte del perfil de riesgo operativo, y la evidencia que conserve debe corresponder al registro y a la información al consejo.
Cómo ayuda Ostorlab
Los escaneos automatizados en cada build dan un resultado fechado por release, y el pentest con agentes de IA cubre la app y sus API con sesión iniciada. Con el plan Enterprise puede elegir residencia de datos en Asia-Pacífico o ejecutar los escaneos on-premises, y Ostorlab cuenta con auditoría SOC 2 Type II.
Qué sigue en sus manos
El registro de proveedores, los contratos, la información al consejo, las notificaciones a APRA y la continuidad de negocio.
- Scams Prevention Framework Act 2025, secciones 58BD, 58BE, 58BJ, 58BM, 58BN, 58BO, 58BX, 58BZC, 58BZD y 58BZG; Designation 2026, secciones 11, 12 y 101
Preparar la app para el marco de prevención de estafas
Qué dice el texto
La Scams Prevention Framework Act 2025 añadió el marco a la Competition and Consumer Act 2010. Las entidades reguladas deben documentar e implantar políticas y procedimientos de gobernanza para prevenir, detectar e interrumpir estafas, responder a ellas e informar sobre ellas, con métricas de rendimiento y una certificación escrita anual de un alto directivo. Deben tomar medidas razonables para impedir que otra persona cometa una estafa, detectar una estafa mientras ocurre y después, investigar la inteligencia accionable en un plazo de 28 días, identificar a los consumidores afectados, tomar medidas razonables en un plazo razonable para interrumpir la actividad o prevenir pérdidas o daños, ofrecer un mecanismo accesible para denunciar estafas, gestionar un proceso interno de resolución de disputas accesible y transparente, y pertenecer a un esquema externo de resolución de disputas. La designación de 2026 incorpora los servicios bancarios cubiertos al marco, con ASIC como regulador sectorial. La mayoría de las obligaciones se aplican desde el 31 de marzo de 2027, y la adhesión a AFCA es obligatoria desde el 1 de septiembre de 2026.
Qué supone para su app móvil
Varias de estas obligaciones recaen en la app: la interrupción de pagos, los avisos en la app, el mecanismo de denuncia y el flujo de reclamaciones. Si un control puede eludirse a través de la app o sus API, el argumento de las medidas razonables se debilita.
Cómo ayuda Ostorlab
El pentest con agentes de IA prueba la lógica de negocio de los pagos y los flujos de cuenta, y las pruebas de API comprueban la autorización y la repetición en las llamadas detrás de pagos y cambios de cuenta, para ver si las protecciones del lado de la app se mantienen en el backend.
Qué sigue en sus manos
Las políticas y métricas de gobernanza, la certificación anual, la vigilancia de estafas y la notificación a ASIC, la gestión de reclamaciones y la adhesión a AFCA.
- Consumer Data Right Rules 2020, reglas 1.15, 4.25 y 4.27 y Schedule 2; Consumer Data Standards 1.36.0, Security Profile (Authentication Flows); Competition and Consumer Act 2010, sección 56ES
Cumplir el perfil de seguridad de las API del Consumer Data Right
Qué dice el texto
En virtud del Consumer Data Right de la Parte IVD de la Competition and Consumer Act 2010, los bancos son titulares de datos que deben divulgar datos CDR a través de API CDR cuando lo pida un consumidor o una persona acreditada en su nombre, y ofrecer un panel del consumidor que permita gestionar y retirar sus autorizaciones para divulgar datos CDR. Los Consumer Data Standards fijan la base técnica. En el perfil de seguridad, los titulares de datos deben soportar FAPI 1.0 Advanced, y también JARM y PKCE; el software de los receptores de datos debe usar PAR con PKCE y el método de desafío S256. Las reglas establecen los pasos y los controles de seguridad mínimos para los receptores de datos acreditados y las pasarelas designadas, y las brechas de datos elegibles con datos CDR se rigen por el régimen de notificación de brechas de datos.
Qué supone para su app móvil
Si su app móvil es el panel del consumidor, las pantallas de autorización y el flujo de retirada forman parte de la superficie CDR. Los endpoints de las API CDR necesitan las mismas pruebas que el resto de su parque de API, con los requisitos FAPI añadidos.
Cómo ayuda Ostorlab
Ostorlab intercepta el tráfico de la app, incluso con TLS pinning, y prueba la autenticación y la autorización en las API, incluidos flujos OIDC, manejo de tokens, llamadas de retirada de autorización y acceso a datos de otros clientes.
Qué sigue en sus manos
Las cuestiones de acreditación y política CDR, el diseño del consentimiento y del panel, la gobernanza de datos CDR y la notificación de brechas.
- Privacy Act 1988, Schedule 1, APP 11 y Part IIIC; OAIC APP Guidelines, Chapter 11 (actualizado el 3 de octubre de 2025); Privacy Amendment (Personal Data Protection) Bill 2026 (borrador)
Proteger la información personal según la Privacy Act
Qué dice el texto
La Privacy Act 1988 exige a las entidades APP tomar medidas razonables para proteger la información personal frente al uso indebido, la interferencia y la pérdida, así como frente al acceso, la modificación o la divulgación no autorizados, y destruir o desidentificar la información que ya no sea necesaria. Desde el 11 de diciembre de 2024, el APP 11.3 aclara que las medidas razonables incluyen medidas técnicas y organizativas. Según el régimen de notificación de brechas de datos de la Parte IIIC, una entidad debe notificar a la OAIC y a las personas afectadas cuando una brecha de datos pueda causar un daño grave. La guía de la OAIC sobre el APP 11, actualizada en octubre de 2025, señala la seguridad de las TIC, la seguridad de acceso y los proveedores terceros entre las áreas a cubrir. Una segunda fase de reformas de privacidad se publicó como borrador en agosto de 2026 y aún no es ley.
Qué supone para su app móvil
Las contraseñas, los tokens, los números de cuenta y los datos personales no deben quedar en claro en el teléfono ni viajar sin protección al backend. Lo que la app escribe en registros, cachés y capturas de pantalla cuenta.
Cómo ayuda Ostorlab
Ostorlab busca tokens de sesión y datos personales en el almacenamiento local, cachés, registros y capturas de pantalla, y comprueba configuraciones erróneas que debilitan las protecciones de transporte y sesión.
Qué sigue en sus manos
El programa de privacidad, las decisiones de retención y destrucción, la evaluación y notificación de brechas y su política de privacidad.
Resumen de textos públicos de APRA, del Gobierno de Australia y de la OAIC, consultados el 27 de septiembre de 2026. CPS 234 y CPS 230 son normas prudenciales dictadas al amparo de la Banking Act 1959; CPG 234 y CPG 235 son guías. Los códigos y reglas del marco de prevención de estafas para el sector bancario seguían en borrador cuando se revisó esta página. Esta página no constituye asesoramiento jurídico.
Las normas australianas, control por control
Los controles a los que apuntan los textos, 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 |
|---|---|---|
| Pruebas sistemáticas de los controles de seguridad de la informaciónCPS 234, párrafos 27 a 31 | Pentest con agentes de IA de la app y sus API, con sesión iniciada, en la versión que distribuye, más escaneos automatizados en CI/CD. Detalles | Un exploit funcional que puede reproducir para cada hallazgo de un agente de IA, y resultados de escaneo por build |
| Gestión de vulnerabilidades y parches de los componentes distribuidosCPS 234, párrafo 21; CPG 234 | Identifica bibliotecas compiladas estáticamente y las asocia a vulnerabilidades conocidas, release tras release. Detalles | Vulnerabilidades mapeadas con recomendaciones de actualización o sustitución, y cierre seguido entre releases |
| Pruebas de seguridad en la gestión de cambios y el desarrollo seguroCPG 234, Attachment D y gestión de cambios | Mobile SAST sobre el binario y Mobile DAST sobre la app en ejecución, desde su canal CI/CD. Detalles | Hallazgos con contexto de código descompilado, tráfico, trazas de pila y capturas de pantalla |
| Capacidad de terceros y diseño de controlesCPS 234, párrafos 16, 22 y 28 | Lista los SDK y bibliotecas nativas de cada release y muestra los backends con los que hablan, para que los componentes de proveedores sean visibles. Detalles | Identidad, versión y ubicación del componente en el paquete de la app, por release |
| Controles del ciclo de vida de los datos en el dispositivoCPG 235, gestión del ciclo de vida de los datos | Busca tokens y datos personales en almacenamiento, cachés, registros y capturas de pantalla, y comprueba las protecciones de transporte. Detalles | Evidencia del sistema de archivos que muestra qué se escribió, dónde y cuándo |
| Autenticación, notificaciones y límites en canales digitalesCPG 234, Attachment F | Inicia sesión con códigos de un solo uso y prueba la aplicación de la MFA, los flujos reforzados y las llamadas API detrás de beneficiarios y transferencias. Detalles | Hallazgos en el inicio de sesión y los flujos reforzados, con pasos de reproducción |
| Pruebas de controles y proveedores materialesCPS 230, párrafos 29 y 48 a 50 | Resultados de escaneo fechados por release, y un informe SOC 2 Type II para su diligencia debida de proveedores. Detalles | Informe SOC 2 Type II, bajo petición en el Trust Center |
| Prevención, detección e interrupción de estafasSPF Act 2025, principios de la Parte IVF | Prueba la lógica de negocio de pagos y flujos de cuenta, incluido si las protecciones del lado de la app se mantienen en el backend. Detalles | Pasos de reproducción y evidencia de peticiones y respuestas para cada flujo |
| Perfil de seguridad de las API del Consumer Data RightCDR Rules 2020 y Consumer Data Standards 1.36.0 | Intercepta el tráfico incluso con TLS pinning y prueba la autenticación, los tokens y la autorización, incluidas las llamadas de retirada de autorización. Detalles | Evidencia de peticiones y respuestas para cada hallazgo de API |
| Seguridad de la información personal en la appPrivacy Act 1988, APP 11 | Encuentra claves de API, tokens y credenciales en el paquete de la app y valida si funcionan, junto con comprobaciones de los datos que quedan en el dispositivo. Detalles | Secretos validados, con los permisos y servicios que exponen |
Ostorlab prueba los controles de la app y de sus API. La gobernanza, la información al consejo, las notificaciones de incidentes a APRA, la vigilancia de estafas, la gestión de reclamaciones, el TLPT y el red teaming, la recuperación y la seguridad física siguen correspondiendo a sus equipos.
Controles australianos que probar en su app móvil
Una lista práctica para equipos de seguridad y riesgo tecnológico, basada en los textos de APRA, el marco de prevención de estafas y la Privacy Act.
Programa de pruebas
Incluya la app móvil y sus API en el programa de pruebas sistemáticas, y deje que la frecuencia de releases y la evolución de las amenazas marquen la cadencia.
Componentes y plazos
Mantenga una lista versionada de los SDK y bibliotecas de cada release, y fije plazos de corrección por severidad.
Barreras del canal
Ejecute pruebas estáticas y dinámicas en cada build antes de que llegue a la tienda, y conserve los resultados por release.
Terceros
Incluya los SDK y componentes de proveedores en sus registros de activos y proveedores, y pida evidencia de pruebas a los proveedores.
Datos en el dispositivo
Busque tokens y datos personales en almacenamiento, cachés, registros y capturas de pantalla, y contraste las decisiones de retención y desensibilización con la app.
Protecciones del cliente
Pruebe la MFA, los controles reforzados, las notificaciones y los límites con sesión iniciada, incluidos cambios de beneficiario y transferencias.
Preparación ante estafas
Revise la interrupción de pagos, la denuncia en la app y el flujo de reclamaciones frente a los principios del marco de prevención de estafas antes de marzo de 2027.
Consumer Data Right y privacidad
Pruebe la retirada de autorización y el control de acceso en las API CDR, y conserve evidencia para las obligaciones de brechas de datos y privacidad.
Una lista sugerida, no una plantilla de APRA, ASIC o la OAIC. 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.
- Prudential Standard CPS 234 Information SecurityAPRA, dictada el 30 de noviembre de 2018, en vigor desde el 1 de julio de 2019. Capacidad de seguridad de la información, controles, pruebas sistemáticas, auditoría interna y notificación (párrafos 13 a 36)
- Prudential Practice Guide CPG 234 Information SecurityAPRA, junio de 2019. Guía sobre CPS 234, incluidas las pruebas de eficacia de los controles, la clasificación de activos de información, la seguridad del software (Attachment D), la seguridad del cliente (Attachment F) y las técnicas de prueba (Attachment G)
- Prudential Standard CPS 230 Operational Risk ManagementAPRA, en vigor desde el 1 de julio de 2025. La versión aplicable desde el 1 de julio de 2026 incorpora las enmiendas específicas finalizadas el 30 de abril de 2026. Controles de riesgo operativo, continuidad de negocio e identificación y seguimiento de proveedores materiales (párrafos 29, 42 a 45 y 46 a 61)
- Prudential Practice Guide CPG 235 Managing Data RiskAPRA, septiembre de 2013. Riesgo de datos en todo el ciclo de vida, retención, desensibilización, auditabilidad y externalización o deslocalización de responsabilidades de gestión de datos
- Scams Prevention Framework Act 2025 (No. 15, 2025)Sancionada el 20 de febrero de 2025 y en vigor desde el 21 de febrero de 2025. Introduce la Parte IVF en la Competition and Consumer Act 2010, con obligaciones de gobernanza, prevención, detección, notificación, interrupción y respuesta (secciones 58BD a 58BZH)
- Scams Prevention Framework Regulated Sectors Designation 2026Registrada el 28 de mayo de 2026 y en vigor desde el 29 de mayo de 2026 (F2026L00627), tras su adopción el 22 de mayo de 2026. Designa los servicios bancarios cubiertos y a ASIC como regulador sectorial, con disposiciones transitorias que escalonan las obligaciones hasta el 31 de marzo de 2027
- Competition and Consumer (Consumer Data Right) Rules 2020F2020L00094, compilación 1004 del 4 de marzo de 2025, junto con los Consumer Data Standards versión 1.36.0. Obligaciones de los titulares de datos, paneles del consumidor, y pasos de seguridad y controles mínimos para receptores de datos acreditados y pasarelas designadas
- Privacy Act 1988 y OAIC APP GuidelinesAustralian Privacy Principle 11 y el régimen de notificación de brechas de datos de la Parte IIIC. El APP 11.3 fue añadido por la Privacy and Other Legislation Amendment Act 2024 y se aplica a la información personal en poder de las entidades desde el 11 de diciembre de 2024. El capítulo 11 de las APP Guidelines se actualizó el 3 de octubre de 2025
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.
Pruebe su app de banca móvil como lo describen APRA y ASIC
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.