Ciberresiliencia del RBNZ: evalúe su app de banca móvil antes y después de cada versión.
La Guidance on Cyber Resilience del RBNZ pide a las entidades realizar pruebas de seguridad en sus sistemas y redes, de forma periódica y cada vez que se produce un cambio importante. La Deposit Takers (Operational Resilience) Standard 2027, consultada en 2026 y prevista para entrar en vigor el 1 de diciembre de 2028, añade la gestión de vulnerabilidades y parches, el aseguramiento de los sistemas TIC y la notificación de incidentes TIC materiales en 72 horas. Ostorlab prueba su app y las API que hay detrás, tras el inicio de sesión, en cada versión.
- Prueba la app y las API que llama, en la compilación que descargan sus clientes
- Inicia sesión con sus cuentas de prueba y completa códigos de un solo uso para probar pagos, cambios de beneficiario y sesiones
- 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 registrados, entidades no bancarias de depósito con licencia y aseguradoras para los textos de ciberresiliencia del RBNZ; depositantes con licencia para los estándares de la DTA
- Fechas clave
- Notificación de incidentes cibernéticos materiales desde el 8 de abril de 2024; estándar de resiliencia operativa previsto para el 1 de diciembre de 2028
- Objeto
- Pruebas de seguridad, gestión de vulnerabilidades y parches, aseguramiento de los sistemas TIC, riesgo de terceros y notificación de incidentes
- Referencia principal
- Guidance on Cyber Resilience del RBNZ, abril de 2021
Los textos neozelandeses que enmarcan su canal móvil
Primero llegaron la guía y la recopilación de datos de ciberresiliencia; después, la Deposit Takers Act 2023 y sus estándares, y las normas de privacidad que se aplican a los datos de los clientes. Las fechas corresponden a los textos citados en esta página.
- Abril de 2021
Guidance on Cyber Resilience
El RBNZ publica una guía para todas las entidades que regula: prácticas básicas y avanzadas de gobernanza, desarrollo de capacidades, intercambio de información y gestión de terceros, incluidas las pruebas de seguridad de sistemas y redes.
- Julio de 2023
Deposit Takers Act 2023
El Parlamento aprueba la ley que crea un régimen prudencial único para bancos y entidades no bancarias de depósito, con estándares dictados como legislación secundaria. El Depositor Compensation Scheme entra en vigor el 1 de julio de 2025.
- 8 de abril de 2024
Notificación de incidentes cibernéticos materiales
Los bancos registrados, las entidades no bancarias de depósito y las aseguradoras deben notificar al RBNZ los incidentes cibernéticos materiales lo antes posible y en un plazo de 72 horas desde su detección, con una plantilla compartida con la FMA.
- 1 de octubre de 2024
Notificación periódica y encuesta de capacidades
Comienzan la notificación periódica de todos los incidentes cibernéticos y la autoevaluación frente a la Guidance on Cyber Resilience. Las entidades grandes notifican incidentes cada seis meses y se autoevalúan cada año; las demás, anualmente y cada dos años. La encuesta de notificación de incidentes está en pausa a mayo de 2026.
- 18 de junio de 2026
Borrador del estándar de resiliencia operativa
El RBNZ abre la consulta sobre la Deposit Takers (Operational Resilience) Standard 2027 y su guía preliminar, uno de los seis estándares del último tramo. El plazo de comentarios cierra el 11 de septiembre de 2026.
- 1 de diciembre de 2028
Entrada en vigor de los estándares de la DTA
Todos los estándares de la DTA deben publicarse antes del 31 de mayo de 2027 y entrar en vigor el 1 de diciembre de 2028, incluido el estándar de resiliencia operativa con sus requisitos para sistemas TIC, proveedores de servicios materiales y continuidad de negocio.
- Cada 12 meses
Pruebas de continuidad de negocio
Según el borrador, un depositante debe probar su plan de continuidad de negocio al menos una vez cada 12 meses, con escenarios graves pero plausibles, y documentar los resultados.
Las normas neozelandesas, 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 su equipo. El estándar de resiliencia operativa es un borrador consultado del 18 de junio al 11 de septiembre de 2026.
- Guidance on Cyber Resilience del RBNZ, abril de 2021, A1; Deposit Takers (Operational Resilience) Standard 2027, borrador, cláusulas 13 y 33
Asumir la ciberresiliencia en el consejo
Qué dice el texto
El consejo debe ser en última instancia responsable de la ciberresiliencia de la entidad, con un directivo responsable de la estrategia y el marco de ciberresiliencia. Debe comprender el entorno de riesgo cibernético, determinar la tolerancia y el apetito de riesgo, aprobar la estrategia y el marco, y supervisar su implementación. El borrador del estándar de resiliencia operativa hace al consejo responsable de aprobar los niveles de tolerancia de las operaciones críticas y los sistemas TIC, el marco de gestión del riesgo operativo, la política de sistemas TIC y los planes de continuidad de negocio.
Qué supone para su app móvil
La gobernanza está por encima de la app, pero decide si el canal móvil se prueba con una periodicidad y si los hallazgos llegan al consejo.
Cómo ayuda Ostorlab
Ostorlab ofrece a los equipos de seguridad y a la dirección evidencia por versión: qué se probó, qué se encontró, qué se corrigió y qué se volvió a probar.
Qué sigue en sus manos
Las aprobaciones del consejo, el apetito de riesgo, la rendición de cuentas, la auditoría interna y los recursos del programa de pruebas.
- Guidance on Cyber Resilience del RBNZ, B3.7 a B3.7.2; guía preliminar del estándar de resiliencia operativa, junio de 2026, párrafos 71.3 y 97.3
Realizar pruebas de seguridad periódicas y tras cambios importantes
Qué dice el texto
La entidad debe realizar pruebas de seguridad en sus sistemas y redes para detectar debilidades que puedan ser explotadas por un ciberataque o dejarla expuesta a un incidente. Las pruebas deben realizarse de forma periódica y cada vez que se produzca un cambio importante en el panorama de amenazas, por ejemplo al implantar nuevos sistemas o tecnologías, e implicar a los equipos internos y a los terceros relevantes cuando sea necesario. La guía preliminar del estándar de resiliencia operativa espera evaluaciones de vulnerabilidades de los sistemas TIC, incluidas pruebas de eficacia de los controles de seguridad y aseguramiento, y pruebas adversarias como ejercicios de red team para validar los controles frente a escenarios de ataque plausibles.
Qué supone para su app móvil
Cada versión móvil es un cambio importante en un canal expuesto a Internet. La app y las API que llama deben probarse antes de la actualización en la tienda y con una cadencia periódica entre versiones.
Cómo ayuda Ostorlab
Una prueba de penetración con agentes de IA prueba la app y sus API tras el inicio de sesión, en la compilación que usted publica, con un exploit funcional que puede reproducir para cada hallazgo. Los escaneos automatizados se ejecutan desde su canal CI/CD en cada compilación.
Qué sigue en sus manos
El alcance, los ejercicios de red team o TLPT y cómo se incorporan los resultados al marco de riesgo.
- Guía preliminar del estándar de resiliencia operativa, junio de 2026, tabla 6; borrador del estándar, cláusula 21(4)
Gestionar vulnerabilidades y parches con plazos documentados
Qué dice el texto
La guía preliminar enumera los controles de seguridad de la información que espera: procesos de gestión de vulnerabilidades para identificar, evaluar, priorizar y abordar vulnerabilidades de forma oportuna, también cuando se descubren nuevas vulnerabilidades y amenazas, y procesos de gestión de parches para evaluar, probar cuando proceda y aplicar parches y otras actualizaciones en los activos de hardware y software, incluidos los componentes de proveedores. Cuando una debilidad de control material pueda provocar un incidente TIC material y sea improbable corregirla a tiempo, el borrador exige notificar al RBNZ en un plazo de 10 días hábiles.
Qué supone para su app móvil
Los SDK y las bibliotecas nativas de su app son software que usted publica, con versiones y parches. Una vulnerabilidad que no ve es una vulnerabilidad sin plazo de corrección.
Cómo ayuda Ostorlab
SCA identifica las bibliotecas compiladas estáticamente y las asocia a vulnerabilidades conocidas, versión tras versión. Los hallazgos se clasifican como críticos, altos, medios o bajos, se gestionan como tickets en la plataforma o en Jira y ServiceNow, y se vuelven a probar una vez publicada la corrección.
Qué sigue en sus manos
El parcheo de servidores e infraestructura, las decisiones de calendario, los contratos de mantenimiento y la aceptación de riesgos.
- Deposit Takers (Operational Resilience) Standard 2027, borrador, cláusula 20; guía preliminar, párrafos 99 a 102
Proporcionar aseguramiento de que los controles funcionan, también en las TIC de terceros
Qué dice el texto
Un depositante debe mantener controles de seguridad de la información que restrinjan el acceso a la información a personas autorizadas, y procesos de aseguramiento que confirmen la eficacia de esos controles y de sus procesos de intercambio de información. El aseguramiento debe ser adecuado para confirmar que los controles responden a amenazas y vulnerabilidades cambiantes, y debe extenderse a los sistemas TIC proporcionados o mantenidos por otra persona. La guía preliminar espera un proceso de aseguramiento documentado, periódico y basado en riesgos, repetido tras cambios o incidentes materiales.
Qué supone para su app móvil
La app, su backend y los servicios que hay detrás forman un solo sistema. El aseguramiento debe cubrir las partes gestionadas por otros, incluidos los servicios de identidad, fraude y nube de los que depende la app.
Cómo ayuda Ostorlab
Ostorlab prueba los controles de la app y sus API y produce evidencia por hallazgo, que puede alimentar el expediente de aseguramiento junto con el resto del entorno de control.
Qué sigue en sus manos
El propio marco de aseguramiento, el diseño de los controles y la decisión sobre qué evidencia es suficiente.
- Guidance on Cyber Resilience del RBNZ, B1.4.1, B2.5 y B2.8; guía preliminar del estándar de resiliencia operativa, tabla 6
Integrar la seguridad y probar cada cambio
Qué dice el texto
La entidad debe disponer de políticas, procedimientos y controles de gestión del cambio, con la ciberseguridad considerada a lo largo del ciclo de vida del cambio. Como práctica avanzada, debe adoptar un enfoque de resiliencia desde el diseño, incorporando medidas de resiliencia desde la primera etapa de diseño y desarrollo, y realizar evaluaciones de riesgo cibernético antes de introducir tecnologías, productos, servicios o procesos nuevos o modificados. Las áreas de control de la guía preliminar incluyen la gestión del cambio, la gestión de la configuración y entornos seguros de despliegue y prueba de nuevas funcionalidades.
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
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 y capturas de pantalla. Ambos se ejecutan desde su canal CI/CD en cada compilación, y las versiones publicadas en las tiendas se monitorizan sin disparadores manuales.
Qué sigue en sus manos
Los estándares de desarrollo seguro, las revisiones de diseño, la formación de desarrolladores y la aprobación de la publicación.
- Guidance on Cyber Resilience del RBNZ, D1.1, D2.1, D4.1 y D5.1; Deposit Takers (Operational Resilience) Standard 2027, borrador, cláusulas 12 y 22 a 26
Evaluar a terceros y proveedores de servicios materiales
Qué dice el texto
La entidad debe evaluar la criticidad y sensibilidad de las actividades antes de externalizarlas, realizar y documentar la diligencia debida antes de firmar, diseñar y verificar controles para detectar y prevenir intrusiones desde conexiones de terceros, integrar a los terceros críticos en su plan de respuesta y evaluar periódicamente sus capacidades de ciberseguridad. Según el borrador, un proveedor de servicios material es un tercero que presta una operación crítica; el depositante debe indagar su capacidad antes de formalizar el acuerdo, documentar y vigilar los términos, llevar un registro y tener una política para gestionar a estos proveedores.
Qué supone para su app móvil
Una app de banca móvil incluye SDK de terceros que hablan con sus propios backends, y puede depender de un proveedor de fraude o identidad. Todos pertenecen a su inventario y a su visión de 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, muestra qué intercambian la app y sus SDK con los backends por la red, y puede probar las API que un proveedor expone a la app.
Qué sigue en sus manos
Los contratos, el registro de proveedores de servicios materiales, los expedientes de diligencia debida, la vigilancia y los planes de salida.
- Cyber resilience for regulated entities del RBNZ, recopilación de datos, actualizada el 6 de mayo de 2026; Material Cyber Incident Notification FAQs; Deposit Takers (Operational Resilience) Standard 2027, borrador, cláusula 21
Notificar incidentes materiales y autoevaluarse según el calendario
Qué dice el texto
Los incidentes cibernéticos materiales deben notificarse al RBNZ lo antes posible y en un plazo de 72 horas desde su detección, con una plantilla que también sirve para la FMA. La notificación periódica de todos los incidentes cibernéticos está en pausa a mayo de 2026. Las entidades también presentan una autoevaluación frente a la Guidance on Cyber Resilience: las grandes cada año y las demás cada dos años. El borrador añade el deber de notificar al RBNZ un incidente TIC material a más tardar 72 horas después de conocerlo, con la gravedad, el impacto y cualquier solución viable.
Qué supone para su app móvil
El reloj empieza cuando se detecta el incidente. La información de triaje sobre la app y sus API debe poder reconstruirse, y un problema de app o API puede ser el desencadenante.
Cómo ayuda Ostorlab
Ostorlab no gestiona la respuesta a incidentes ni presenta notificaciones. Ofrece hallazgos sobre la app y las API con pasos de reproducción, versiones afectadas y evidencia de solicitudes y respuestas que su equipo puede usar durante una investigación, y vuelve a probar la corrección.
Qué sigue en sus manos
La detección, el triaje, la notificación al RBNZ y a la FMA, la respuesta a incidentes y el relato de la autoevaluación.
- Deposit Takers (Operational Resilience) Standard 2027, borrador, cláusulas 8, 27 y 29
Probar el plan de continuidad de negocio
Qué dice el texto
Un depositante debe tener un plan de continuidad de negocio documentado para sus operaciones críticas, revisado y probado periódicamente. El programa de pruebas debe cubrir cada operación crítica del registro, centrarse en los riesgos materiales que enfrenta el depositante y probar la eficacia del plan con escenarios graves pero plausibles. Debe realizarse una prueba al menos una vez cada 12 meses. Las revisiones y pruebas deben documentarse y las debilidades abordarse de forma oportuna.
Fuente:Deposit Takers (Operational Resilience) Standard 2027, borrador, cláusulas 8, 27 y 29
Qué supone para su app móvil
Los pagos, los depósitos y las liquidaciones del registro pasan por el canal móvil. El plan decide cómo se atiende a los clientes cuando la app o sus API fallan.
Cómo ayuda Ostorlab
Ostorlab no es una herramienta de continuidad de negocio. Mantiene probada la parte de app y API del plan entre ejercicios, con hallazgos, tickets y resultados de reprobación en los que pueden apoyarse sus escenarios.
Qué sigue en sus manos
El plan en sí, el diseño de escenarios, la ejecución de las pruebas, el aseguramiento al consejo y la notificación al RBNZ cuando se activa el plan.
- Privacy Act 2020, artículo 22, IPP 5 y 12, y parte 6; Office of the Privacy Commissioner, Principle 5; Privacy Amendment Act 2025
Proteger la información personal y notificar las brechas graves
Qué dice el texto
Según la Privacy Act 2020, una agencia que posee información personal debe protegerla con salvaguardas razonables en las circunstancias contra pérdida, acceso, uso, modificación o divulgación no autorizados y otros usos indebidos. Las divulgaciones fuera de Nueva Zelanda solo se permiten si el destinatario está sujeto a la ley, está sujeto a salvaguardas comparables, o la persona autoriza la divulgación tras ser informada de que las protecciones pueden diferir. Una brecha que pueda causar daño grave debe notificarse al Comisionado de Privacidad y a las personas afectadas lo antes posible; la expectativa del Comisionado es notificarla en 72 horas. La Privacy Amendment Act 2025 añadió el IPP 3A sobre recogida indirecta, en vigor desde el 1 de mayo de 2026.
Qué supone para su app móvil
Los números de cuenta, los datos de identidad y los tokens de sesión no deben quedar sin protección en el teléfono ni viajar sin protección al backend, y el tratamiento en el extranjero exige comprobar que haya salvaguardas comparables.
Cómo ayuda Ostorlab
Ostorlab busca tokens de sesión y datos personales en el almacenamiento local, cachés, registros y capturas de pantalla, comprueba las protecciones de transporte y muestra a qué servicios y ubicaciones de terceros envía datos la app.
Qué sigue en sus manos
Las evaluaciones de impacto en la privacidad, los avisos y consentimientos, los contratos con proveedores en el extranjero y la notificación de brechas.
Resumen de textos públicos neozelandeses, consultados el 27 de septiembre de 2026. La Deposit Takers (Operational Resilience) Standard 2027 es un borrador consultado del 18 de junio al 11 de septiembre de 2026 y puede cambiar antes de publicarse y entrar en vigor el 1 de diciembre de 2028. La Guidance on Cyber Resilience del RBNZ es una guía, no un reglamento. Esta página no constituye asesoramiento jurídico.
Las normas neozelandesas, control por control
Los controles a los que apuntan los textos neozelandeses, 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 de seguridad periódicas de sistemas y redesGuía de ciberresiliencia B3.7 | 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 |
| Pruebas tras cambios importantes y nuevas tecnologíasGuía de ciberresiliencia B3.7.1; guía RO 71.3 | Mobile SAST y DAST en CI/CD en cada compilación, y supervisión de las versiones publicadas en las tiendas. Detalles | Resultados del escaneo por compilación y por versión publicada en la tienda |
| Gestión de vulnerabilidades y parches para activos de softwareGuía RO, tabla 6 | Identifica mediante huellas las bibliotecas compiladas estáticamente y las relaciona con vulnerabilidades conocidas, de una versión a otra. Detalles | Vulnerabilidades asociadas con recomendaciones de actualización o sustitución, y seguimiento del cierre entre versiones |
| SDK, bibliotecas nativas e inventario de componentesGuía RO, párrafo 96 | 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 de la app, por versión |
| Aseguramiento de que los controles de seguridad de la información funcionanBorrador del estándar RO, cláusula 20 | Prueba los controles de la app y sus API y produce evidencia por hallazgo para el expediente de aseguramiento. Detalles | Hallazgos con pasos de reproducción y evidencia, por control |
| Gestión del cambio y despliegue seguroGuía de ciberresiliencia B2.5 y B2.8 | Mobile SAST sobre el binario y Mobile DAST sobre la app en ejecución, antes de la publicación. Detalles | Hallazgos con el contexto del código descompilado, el tráfico, las trazas de pila y capturas de pantalla |
| Conexiones de terceros y proveedores de servicios materialesGuía de ciberresiliencia D4.1; borrador del estándar RO, cláusulas 22 a 26 | Enumera los SDK y backends con los que habla la app y prueba las API que exponen esos servicios. Detalles | Evidencia de componentes y red para la diligencia debida y la vigilancia |
| Notificación de incidentes materiales en 72 horasFAQ MCIN; borrador del estándar RO, cláusula 21 | Ostorlab no notifica incidentes; los hallazgos incluyen pasos de reproducción, versiones afectadas y evidencia de solicitudes y respuestas para su investigación. | Resultados de reprobación que muestran que la corrección cerró el hallazgo |
| Pruebas del plan de continuidad de negocio cada 12 mesesBorrador del estándar RO, cláusulas 8 y 29 | Mantiene probada la parte de app y API del plan entre ejercicios, con tickets y reprobaciones. Detalles | Historial de tickets y resultado de la nueva prueba de cada hallazgo |
| Información personal en el dispositivo y en tránsitoPrivacy Act 2020, IPP 5 y 12 | 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 |
Ostorlab prueba controles en la app y sus API. La respuesta y notificación de incidentes, la continuidad de negocio, la gobernanza del consejo, la monitorización SOC, los ejercicios de red team o TLPT y las decisiones de privacidad siguen en sus equipos.
Controles neozelandeses que probar en su app móvil
Una lista práctica para equipos de seguridad y riesgo operativo, basada en los textos de ciberresiliencia del RBNZ, el borrador de resiliencia operativa y la Privacy Act 2020.
La app móvil en el alcance
Incorpore la app móvil al alcance de su programa de pruebas de seguridad, con una periodicidad y un paso previo a la publicación.
Pruebas en cada cambio
Dispare pruebas de la app y las API en cada versión, no solo en la revisión anual, y registre los resultados.
Vulnerabilidades y plazos
Mantenga una lista versionada de los SDK y bibliotecas de cada versión, y fije plazos de corrección por gravedad.
Aseguramiento sobre terceros
Compruebe que el aseguramiento de la app y sus API llega a los servicios prestados por otros, incluidos los backends de los SDK y la nube.
Hallazgos que llegan al consejo
Alimente con los resultados de cada versión la información de gestión y de consejo que espera la guía.
Preparación ante incidentes
Pruebe qué registran y exponen la app y las API, para que la notificación en 72 horas y la de 10 días hábiles se apoyen en hechos.
Continuidad de negocio
Incluya un escenario de canal móvil entre los escenarios graves pero plausibles que se prueban al menos cada 12 meses.
Privacidad en el dispositivo
Busque tokens y datos personales en almacenamiento, cachés, registros y capturas de pantalla, y compruebe adónde envía datos la app.
Una lista sugerida, no una plantilla del RBNZ. 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.
- Guidance on Cyber ResilienceRBNZ, abril de 2021. Prácticas básicas y avanzadas para bancos registrados, entidades no bancarias de depósito con licencia, aseguradoras con licencia e infraestructuras de mercado financiero designadas, incluidas las pruebas de seguridad de sistemas y redes (B3.7) y la gestión de terceros (parte D)
- Cyber resilience for regulated entities y recopilación de datos de ciberresilienciaRBNZ, página publicada el 28 de febrero de 2022, actualizada el 6 de mayo de 2026. Notificación de incidentes cibernéticos materiales en 72 horas, notificación periódica de todos los incidentes (encuesta en pausa) y autoevaluación frente a la guía
- Material Cyber Incident Notification FAQsRBNZ, guía de la plantilla. La obligación de notificar incidentes cibernéticos materiales comenzó el 8 de abril de 2024 y los incidentes deben notificarse en las 72 horas siguientes a su detección; la plantilla también sirve para la FMA
- Deposit Takers (Operational Resilience) Standard 2027, borradorRBNZ, junio de 2026. Dictado al amparo del artículo 72 de la Deposit Takers Act 2023, consultado del 18 de junio al 11 de septiembre de 2026 y previsto para entrar en vigor el 1 de diciembre de 2028. Cláusulas 8, 12, 13, 18 a 21, 22 a 26, 27 a 29 y 33
- Guidance Note: Operational Resilience Standard (guía preliminar)RBNZ, junio de 2026. Guía de acompañamiento del borrador, con controles de gestión de vulnerabilidades y parches (tabla 6), expectativas de aseguramiento (párrafos 99 a 102) y pruebas adversarias (párrafo 97.3)
- Deposit Takers Act 2023 (2023 No 35)New Zealand Legislation. Crea el régimen prudencial único de los depositantes y la potestad de dictar estándares como legislación secundaria. Todos los estándares de la DTA deben publicarse antes del 31 de mayo de 2027 y entrar en vigor el 1 de diciembre de 2028
- Privacy Act 2020 (2020 No 31)New Zealand Legislation. Principios de privacidad 5 y 12, y disposiciones sobre brechas notificables de la parte 6. Modificada por la Privacy Amendment Act 2025 (2025 No 53), que añadió el IPP 3A sobre recogida indirecta, en vigor el 1 de mayo de 2026
- New Zealand Anti-Scam Alliance Work Programme 2026Ministry of Business, Innovation and Employment, acciones de junio a diciembre de 2026. Incluye la expansión del sistema Confirmation of Payee de los bancos, un servicio del sector que comprueba si el nombre del titular coincide con el número de cuenta
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 frente a las expectativas del RBNZ
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.