Checklist de seguridad para el CFO: cómo evaluar a un proveedor wealthtech

Antes de dar acceso a los bancos del grupo a cualquier plataforma de consolidación patrimonial, el CFO tiene diez preguntas que hacer. No son preguntas técnicas. Son preguntas de negocio con consecuencias legales directas si la respuesta es insatisfactoria. Esta guía entrega el checklist completo, bloque a bloque, con las señales de alerta que conviene detectar ya en la reunión de venta.

Por qué el CFO es el primer auditor de seguridad del proveedor

El sector financiero es el segundo más caro del mundo en brechas de datos: 6,08 millones de dólares de coste medio por incidente en 2024, un 22% por encima de la media global. Los family offices no son excepción. El 43% sufrió un ataque en los últimos 12-24 meses, cifra que sube al 62% entre los que gestionan más de 1.000 millones de dólares. El 93% de los atacados recibió el vector por phishing, y el 31% no tenía plan de respuesta documentado.

En España, el INCIBE registró 97.348 incidentes en 2024, un 16,6% más que el año anterior, con el sistema financiero y fiscal como segundo sector empresarial más afectado, con un 23,8%. La ENISA documentó 488 incidentes en la UE entre enero de 2023 y junio de 2024 solo en el sector financiero, con los bancos concentrando el 46% y el 58% de los ataques DDoS.

Cuando el CFO firma un contrato con un proveedor wealthtech, asume responsabilidad directa como responsable del tratamiento de datos. Ningún responsable de ciberseguridad interno puede delegar esa carga ni absorberla por completo. Lo que sigue son diez bloques de evaluación, del perímetro técnico al contractual y regulatorio. Recórrelos antes de la reunión de decisión.

Para una visión complementaria sobre los riesgos de conectar cuentas a plataformas externas, puedes consultar la guía sobre seguridad al conectar bancos a una plataforma de consolidación.

Bloque 1: ¿Acceso solo lectura o transaccional?

Pregunta del CFO en reunión: "¿La plataforma puede ordenar pagos, mover fondos o ejecutar operaciones, o solo consultar saldos y posiciones?"

El perímetro de riesgo cambia por completo según la respuesta. Una plataforma de consolidación patrimonial no necesita transaccionalidad para cumplir su función; su trabajo es agregar información, no operar sobre ella. Si el proveedor solicita credenciales con permisos de escritura o ejecuta movimientos, el perfil de exposición ya no es el de un software de visibilidad: es el de una herramienta de tesorería operativa.

La señal de alerta es directa: acceso transaccional sin una justificación funcional explícita y documentada. En solo lectura, el peor escenario ante una brecha es la exposición de información patrimonial, grave pero contenible. Con acceso transaccional, el peor escenario incluye movimientos de fondos no autorizados.

Exige que el alcance del acceso esté especificado en el contrato, no solo en la presentación comercial.

Bloque 2: ¿API propia o conectividad subcontratada?

Pregunta del CFO en reunión: "¿Ustedes tienen integración directa con los bancos y custodios, o utilizan un agregador de terceros como intermediario?"

La conectividad bancaria es, con frecuencia, el eslabón más opaco de la cadena. Los agregadores de terceros añaden latencia, dependencia operativa y un segundo perímetro de seguridad que el CFO no controla ni audita directamente. Si el proveedor wealthtech subcontrata esa capa, la due diligence no termina con ese proveedor: empieza también con el tercero.

El Reglamento DORA (Reglamento UE 2022/2554, en vigor desde el 17 de enero de 2025) obliga a las entidades financieras reguladas a mapear y gestionar toda la cadena de proveedores TIC críticos, incluyendo la subcontratación. Aunque DORA no aplica directamente a una empresa familiar o holding no regulado, sí aplica a los proveedores wealthtech que sirven a entidades reguladas, y su marco es la referencia técnica razonable para cualquier due diligence seria.

Un proveedor con API de conexión propia, sin intermediarios, reduce la superficie de ataque, simplifica el due diligence y elimina el riesgo de concentración en un tercero no auditado. Para entender el panorama de los agregadores y su impacto en la seguridad del dato, la guía sobre la guerra de los agregadores ofrece un análisis detallado del sector.

Bloque 3: ¿Qué certificaciones de seguridad tiene el proveedor?

Pregunta del CFO en reunión: "¿Tienen ISO 27001:2022, SOC 2 Type II, u otra certificación auditada externamente? ¿Puedo ver el certificado vigente?"

Las certificaciones no son un fin en sí mismas, pero son el proxy más eficiente para evaluar la madurez operativa de un proveedor cuando el CFO no dispone de capacidad de auditoría técnica directa.

ISO/IEC 27001:2022

La norma ISO 27001 define los requisitos de un Sistema de Gestión de Seguridad de la Información (SGSI) auditado por un organismo externo acreditado. En España, la versión vigente es UNE-EN ISO/IEC 27001:2023. Desde el 25 de octubre de 2025, las certificaciones bajo la versión 2013 ya no son válidas; un proveedor que muestre un certificado v2013 está descertificado (AENOR; Legitec). La versión 2022 incorpora 93 controles organizados en cuatro dominios, incluyendo 11 nuevos controles como inteligencia de amenazas y seguridad en la nube.

Exige que el organismo certificador esté acreditado por ENAC en España o por un miembro del IAF equivalente. Una declaración propia de "cumplimiento con ISO 27001" sin certificado emitido por tercero no equivale a la certificación.

SOC 2 Type II: un plus del entorno anglosajón

El SOC 2 Type II es el estándar de referencia para plataformas SaaS y fintech en el mercado anglosajón. A diferencia del Type I, que evalúa el diseño de los controles en un momento puntual, el Type II audita su funcionamiento efectivo durante un período de 6 a 12 meses, sobre cinco Trust Services Criteria: seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad (AICPA; nedigital).

En el mercado europeo, ISO/IEC 27001 cubre el mismo terreno y es la referencia equivalente. Un proveedor con ISO 27001 vigente no queda en desventaja por no tener SOC 2: son marcos paralelos, no acumulativos. La ausencia de SOC 2 no es, por sí sola, una señal de alerta si existe una certificación ISO 27001 acreditada. Pídelo solo si tu operativa lo requiere de forma específica.

ENS (Esquema Nacional de Seguridad)

El ENS es obligatorio para las Administraciones Públicas y sus proveedores de servicios digitales, pero no aplica a proveedores wealthtech que sirven a clientes privados (RD 311/2022; Audidat). Su presencia es un plus voluntario que indica orientación al sector público, no un requisito para esta evaluación. No penalices su ausencia, y no lo cuentes como sustituto de ISO 27001.

Bloque 4: ¿Qué estándares de cifrado aplica?

Pregunta del CFO en reunión: "¿Con qué algoritmo cifran los datos en reposo y qué versión de TLS usan en tránsito?"

El cifrado es el control más básico, y su ausencia o debilidad es una señal de alerta inmediata. Los estándares actuales son AES-256 para datos en reposo y TLS 1.3 en tránsito, con TLS 1.2 como mínimo aceptable. Microsoft retiró el soporte a TLS 1.0 y 1.1 en noviembre de 2024, y Azure Synapse exige TLS 1.2 o superior desde marzo de 2025 (Microsoft Learn). Un proveedor que admite TLS 1.0 o 1.1 en su stack opera con deuda técnica documentada.

La pregunta no requiere conocimientos de criptografía. Solo exige que el proveedor sepa responderla con precisión: versión, algoritmo y si la política está documentada. La incapacidad de responder con concreción es, en sí misma, una señal.

Bloque 5: ¿Cómo gestiona el acceso y la autenticación?

Pregunta del CFO en reunión: "¿El MFA es obligatorio para todos los usuarios o solo recomendado? ¿Qué método de segundo factor admiten?"

La autenticación multifactor correctamente implementada evita más del 95% de los ataques de phishing (GlobalSign). El dato es relevante porque el phishing fue el vector de entrada en el 93% de los family offices atacados en el informe Deloitte citado antes.

No todos los métodos de MFA tienen el mismo nivel de seguridad. TOTP (aplicaciones tipo Authenticator) y FIDO2 (llaves físicas o biometría de plataforma) son los métodos recomendados para accesos a datos financieros. El SMS como segundo factor es estructuralmente más débil por su exposición a ataques de SIM-swapping. Si el proveedor solo ofrece MFA por SMS, el control existe, pero no tiene la solidez que los datos del grupo merecen.

Pregunta también por la gestión de roles: ¿puede el administrador de tu organización limitar qué usuarios ven qué carteras o sociedades? ¿Los accesos tienen logs auditables?

Bloque 6: ¿Con qué frecuencia realiza pruebas de seguridad externas?

Pregunta del CFO en reunión: "¿Cuándo fue el último pentest realizado por un tercero independiente? ¿Pueden compartir un resumen ejecutivo?"

Un proveedor que gestiona acceso a datos bancarios consolidados del grupo debe someterse como mínimo a un test de intrusión anual por una empresa independiente, y también tras cambios significativos en la arquitectura. En sectores regulados la frecuencia recomendada es semestral. El Reglamento DORA exige pruebas de penetración basadas en amenazas (TLPT) cada tres años para funciones esenciales de entidades financieras reguladas (Secra; EJASO sobre DORA).

Lo que debes recibir no es el informe técnico completo, sino un resumen ejecutivo que incluya la metodología usada, idealmente OWASP WSTG, la puntuación CVSS de las vulnerabilidades encontradas y el plan de remediación con fechas. Un proveedor que no comparte ningún resumen del último pentest, o que no ha realizado uno, no puede demostrar que conoce su propia superficie de ataque.

Bloque 7: ¿Cómo gestiona el riesgo de terceros según DORA?

Pregunta del CFO en reunión: "¿El contrato incluye cláusulas de disponibilidad, confidencialidad y auditoría conforme al artículo 30 de DORA? ¿Tienen mapeada su cadena de subcontratistas TIC?"

El Reglamento (UE) 2022/2554, conocido como DORA, entró en vigor el 17 de enero de 2025. Establece, entre otros requisitos, que las entidades financieras deben incluir en sus contratos con proveedores TIC un conjunto de cláusulas mínimas (art. 30): disponibilidad, integridad, confidencialidad, recuperación y derechos de auditoría. Además, el art. 28.3 exige mantener un registro actualizado de los acuerdos TIC, con fecha límite de reporte a supervisores el 30 de abril de 2025.

Una aclaración importante: DORA no aplica directamente a una empresa familiar o holding no regulado. El reglamento está dirigido a entidades financieras supervisadas, bancos, aseguradoras, gestoras, y a sus proveedores TIC críticos. Sin embargo, si el proveedor wealthtech que contratas sirve también a entidades reguladas, es probable que ya esté sujeto a DORA como proveedor, lo que actúa como garantía indirecta para ti. Las directrices EBA/GL/2019/02 sobre externalización son el marco análogo de referencia para clientes privados que quieran estructurar su due diligence con rigor.

La señal de alerta práctica: un contrato que no describe la cadena de subcontratistas TIC deja al descubierto qué terceros acceden a tus datos sin que lo sepas. Para una comparativa más amplia entre proveedores en este aspecto, consulta el análisis sobre banca privada vs software independiente de consolidación patrimonial.

Bloque 8: ¿Existe contrato de encargo del tratamiento (RGPD art. 28)?

Pregunta del CFO en reunión: "¿Tienen preparado un DPA conforme al artículo 28 del RGPD? ¿Qué plazo de notificación tienen comprometido ante un incidente?"

Este es el bloque con mayor exposición legal directa para el CFO. Cuando contratas a un proveedor que accede, almacena o procesa datos personales del grupo o de sus beneficiarios, ese proveedor pasa a ser un encargado del tratamiento. La relación debe formalizarse en un contrato escrito con las cláusulas mínimas del RGPD art. 28. La AEPD ha sancionado a organizaciones por ausencia de este contrato y por uso de subencargados no autorizados (AEPD; Legiscope).

Las cinco cláusulas mínimas que debe incluir el DPA son: objeto y duración del tratamiento; naturaleza, finalidad y tipo de datos; obligaciones y derechos del responsable; instrucciones documentadas del responsable; y notificación de incidentes en un plazo compatible con las 72 horas exigidas por el RGPD ante la AEPD. Si el proveedor no tiene un DPA preparado, o no puede comprometer un plazo de notificación que encaje en esa ventana, el contrato no está en condiciones de firmarse.

Bloque 9: ¿Qué SLA y soporte ofrece contractualmente?

Pregunta del CFO en reunión: "¿Qué uptime contractual tienen comprometido? ¿Cuál es el tiempo de respuesta garantizado ante una incidencia crítica? ¿Tengo un interlocutor con nombre o gestiono todo por ticketing?"

Los SLA verbales no protegen al cliente. Un proveedor serio formaliza en contrato el nivel de disponibilidad, el umbral mínimo razonable para una plataforma financiera es 99,5% mensual, y el tiempo de respuesta ante incidencias críticas, con la referencia del sector en igual o inferior a 4 horas para el primer diagnóstico.

Igual de relevante es el modelo de soporte. Un sistema de tickets con SLA de 48 horas no equivale a un interlocutor real con nombre y teléfono. Cuando el dato de un banco no carga la mañana del cierre mensual, la diferencia entre ambos modelos no es un matiz de experiencia de usuario. Es una diferencia operativa real. El soporte es un criterio de evaluación, no un accesorio del contrato.

Bloque 10: ¿Dónde están los servidores y qué pasa con tus datos si cancelas?

Pregunta del CFO en reunión: "¿En qué región está alojada la infraestructura? Si mañana cancelamos el contrato, ¿en cuánto tiempo recibo mis datos en formato portable y en qué formato?"

Tras la sentencia Schrems II (2020) y el Marco de Privacidad de Datos UE-EE.UU., el tratamiento de datos en servidores fuera de la UE requiere garantías contractuales adicionales. Infraestructura en la UE es la opción que elimina esa capa de complejidad regulatoria. Un proveedor que aloja en US East sin Cláusulas Contractuales Tipo (SCC) actualizadas está fuera de cumplimiento.

Sobre portabilidad y borrado: exige en contrato el plazo de entrega de tus datos al finalizar la relación, el formato, estructurado y legible por máquina, y el procedimiento de borrado verificable. La dependencia del dato es uno de los riesgos más subestimados al evaluar un proveedor de largo plazo.

Riesgo técnico vs riesgo contractual: la distinción que más se omite

Los bloques 1 a 6 abordan el riesgo técnico: qué puede ocurrir en la arquitectura del proveedor. Los bloques 7 a 10 abordan el riesgo contractual y regulatorio: qué responsabilidad asumes tú cuando el proveedor no tiene sus obligaciones por escrito.

La confusión más habitual es creer que un proveedor con ISO 27001 está "cubierto" legalmente. No es así. Una certificación técnica impecable sin DPA del artículo 28 del RGPD genera responsabilidad legal directa para el responsable del tratamiento, es decir, para la empresa que contrató el servicio. El riesgo técnico y el riesgo contractual son complementarios, no sustitutos.

La tabla siguiente resume los diez bloques, la pregunta clave de cada uno, la señal de alerta y el peso relativo en la evaluación:

Cómo responde VUMI al checklist

VUMI es una plataforma de consolidación patrimonial dirigida a family offices y a empresas familiares y holdings. Algunos puntos del checklist tienen respuesta verificable y pública; otros requieren validación directa con el equipo de producto antes de firmar cualquier contrato.

Lo que se puede afirmar con base en la arquitectura de VUMI:

Acceso solo lectura. VUMI accede a los bancos y custodios en modo solo lectura, sin transaccionalidad ni custodia de activos. El perímetro de riesgo es el de visibilidad del dato, no el de operativa financiera.

API de conexión propia. VUMI es el único proveedor en España con integración propia de la API de conexión a bancos y custodios. No depende de agregadores de terceros para la capa de conectividad. Esto elimina el riesgo de concentración en un subcontratista TIC y simplifica materialmente el due diligence del bloque 2.

Soporte con interlocutores reales. El modelo de soporte de VUMI incluye interlocutores con nombre y respuesta directa, no solo gestión por sistema de tickets. Es el criterio del bloque 9.

Modelo de suscripción sin comisión por patrimonio. VUMI no percibe comisión sobre el patrimonio gestionado. Es software de suscripción, no un servicio retribuido por volumen de activos.

Certificación ISO 27001. VUMI está certificada en ISO/IEC 27001, el estándar internacional de gestión de seguridad de la información auditado por un organismo externo (bloque 3). No dispone de SOC 2 Type II, que es la referencia equivalente del entorno anglosajón; en el marco europeo, ISO 27001 cubre ese terreno.

Infraestructura en la Unión Europea. Los datos se alojan en servidores ubicados en la UE, lo que mantiene el tratamiento bajo jurisdicción europea (bloque 10).

Contrato de encargo del tratamiento (RGPD art. 28). VUMI facilita el DPA del artículo 28 desde el proceso de alta (bloque 8).

Sobre la frecuencia y el alcance de las pruebas de penetración (bloque 6), conviene pedir el detalle directamente al equipo de producto. Si quieres profundizar en las categorías de software disponibles en el mercado, puedes consultar la guía de software de gestión patrimonial o el análisis de software de consolidación para empresa familiar y holding.

Si quieres ver el checklist en acción con una plataforma concreta, el equipo de VUMI puede acompañarte en la revisión.

Preguntas frecuentes

¿Qué certificaciones debe tener un proveedor de software patrimonial?

La referencia en el mercado europeo es ISO/IEC 27001:2022, un SGSI auditado por un organismo acreditado independiente. SOC 2 Type II es el estándar equivalente del entorno anglosajón y funciona como un plus, no como un requisito: un proveedor con ISO 27001 vigente no queda en desventaja por no tenerlo. El ENS aplica a proveedores del sector público, no a proveedores de clientes privados. Lo esencial es que la certificación la emita un organismo acreditado independiente y que el certificado esté vigente y corresponda a la versión actual de la norma.

¿Qué diferencia hay entre SOC 2 Type I y Type II?

El Type I evalúa si los controles de seguridad están bien diseñados en un momento puntual; el Type II verifica que esos controles han funcionado efectivamente durante un período de entre 6 y 12 meses. Para un proveedor en producción con más de un año de operación, el Type II es el estándar pertinente. El Type I solo como certificación es insuficiente para demostrar madurez operativa continuada.

¿Cómo afecta DORA a la contratación de un software financiero?

DORA (Reglamento UE 2022/2554, vigente desde el 17 de enero de 2025) aplica directamente a entidades financieras reguladas y a sus proveedores TIC críticos. Una empresa familiar o holding no regulado no está sujeto a DORA como obligación directa. Sin embargo, el marco es la referencia técnica más rigurosa disponible para estructurar una due diligence de proveedores TIC, y sus cláusulas contractuales mínimas del artículo 30 son una guía de buenas prácticas aplicable a cualquier contratación.

¿Qué debe incluir el contrato con un proveedor que accede a mis datos bancarios?

Como mínimo: un DPA conforme al artículo 28 del RGPD (objeto, duración, naturaleza y finalidad del tratamiento; instrucciones documentadas; obligaciones del encargado); definición del alcance del acceso (solo lectura o transaccional); SLA de disponibilidad y respuesta a incidencias; cláusulas de notificación de incidentes en plazo compatible con las 72 horas ante la AEPD; y condiciones de portabilidad y borrado al finalizar el contrato.

¿Qué riesgo supone que el proveedor subcontrate la conectividad bancaria?

Cuando el proveedor wealthtech usa un agregador de terceros para conectarse a los bancos, se introduce un eslabón adicional en la cadena: mayor latencia, dependencia de un proveedor que no controlas, y un segundo perímetro de seguridad que requiere su propio due diligence. DORA obliga a las entidades reguladas a mapear y gestionar toda la cadena de subcontratistas TIC. Para cualquier cliente, regulado o no, la subcontratación de la conectividad complica la trazabilidad del dato y la auditoría del proveedor.

¿Es seguro dar acceso a mis cuentas a una plataforma de consolidación?

Depende del proveedor y de los controles que hayas verificado. Un acceso en modo solo lectura, con cifrado adecuado, MFA obligatorio y sin transaccionalidad, es un perfil de riesgo manejable y muy distinto al de una herramienta con permisos de escritura. El checklist de este artículo es precisamente el protocolo para tomar esa decisión con criterios objetivos, no con la confianza en la presentación comercial del proveedor.

¿Con qué frecuencia debe auditar su seguridad un proveedor wealthtech?

Como mínimo, un test de intrusión anual realizado por una empresa independiente, con metodología OWASP WSTG y entrega de informe con puntuaciones CVSS y plan de remediación. Además, una auditoría adicional tras cambios significativos en la arquitectura. En sectores regulados, la frecuencia recomendada es semestral. DORA exige pruebas TLPT cada tres años para funciones esenciales de entidades financieras. Un proveedor que no puede compartir el resumen ejecutivo de su último pentest no puede demostrar que conoce su propia superficie de ataque.

Este artículo tiene carácter exclusivamente informativo y no constituye asesoramiento legal, fiscal ni de inversión. Para la evaluación contractual de proveedores tecnológicos con acceso a datos financieros, consulta con asesoría jurídica especializada en protección de datos y normativa financiera.

Fuentes

• IBM Cost of a Data Breach 2024
• Deloitte Family Office Cybersecurity Report 2024
• INCIBE Balance de Ciberseguridad 2024
• ENISA/BitLifeMedia, febrero 2025
• Data Privacy Framework, 2023