Una institución de fondos de pago electrónico, una plataforma de financiamiento colectivo, una SOFOM digital o un procesador de pagos comparten un mismo problema: su producto es dinero representado en datos. Un acceso indebido, una API mal protegida o una caída prolongada no son solo incidentes técnicos; se convierten en pérdidas para clientes, reportes al regulador y daño reputacional difícil de revertir. Implementar ISO 27001 en una fintech o empresa de servicios financieros en México es la forma más ordenada de convertir obligaciones regulatorias dispersas en un sistema de gestión verificable.
Esta guía está dirigida a directores generales, CISO, oficiales de cumplimiento y directores de tecnología de fintechs autorizadas o en proceso de autorización, así como a proveedores tecnológicos de entidades financieras. Verás cómo se relaciona ISO/IEC 27001:2022 con la Ley Fintech y su regulación secundaria, qué controles del Anexo A pesan más, qué evidencia pide un auditor y qué errores repetidos hemos visto en este sector.
Marco regulatorio de seguridad de la información para fintech en México
La regulación financiera mexicana no exige expresamente una certificación ISO/IEC 27001, pero sí exige resultados que un SGSI bien implementado produce: gobierno de la seguridad, gestión de riesgos tecnológicos, control de accesos, monitoreo, gestión de incidentes, continuidad y supervisión de terceros. Conviene tener claro qué instrumento aplica a tu figura jurídica antes de diseñar el alcance.
| Instrumento | Autoridad | Relevancia para el SGSI |
|---|---|---|
| Ley para Regular las Instituciones de Tecnología Financiera (DOF 09-03-2018) | Congreso de la Unión; supervisión de CNBV y Banxico | Crea las figuras de Institución de Financiamiento Colectivo (IFC) e Institución de Fondos de Pago Electrónico (IFPE), el régimen de autorización y las bases para el intercambio de datos mediante interfaces de programación (API) |
| Disposiciones de carácter general aplicables a las Instituciones de Tecnología Financiera (DOF 10-09-2018 y reformas) | CNBV | Requisitos de seguridad de la información, infraestructura tecnológica, gestión de incidentes, continuidad operativa y uso de terceros |
| Circular 12/2018 | Banco de México | Operaciones de las IFPE: emisión, administración, redención y transmisión de fondos de pago electrónico |
| Circular 4/2019 | Banco de México | Operaciones con activos virtuales de instituciones de crédito e ITF |
| Ley Federal de Protección de Datos Personales en Posesión de los Particulares (DOF 20-03-2025) | Secretaría Anticorrupción y Buen Gobierno | Deber de seguridad, avisos de privacidad, relación con encargados y atención de vulneraciones |
| Disposiciones de prevención de operaciones con recursos de procedencia ilícita aplicables a ITF | SHCP; supervisión de CNBV | Integridad y resguardo de expedientes de identificación, alertas y reportes |
| PCI DSS v4.0.1 (PCI Security Standards Council, 2024) | Marcas de tarjetas (contractual) | Obligatorio si almacenas, procesas o transmites datos de tarjetahabientes |
Si tu organización es una institución de crédito o presta servicios críticos a bancos, las Disposiciones de carácter general aplicables a las instituciones de crédito (conocidas como Circular Única de Bancos) también contienen un capítulo de seguridad de la información que tu cliente bancario trasladará a ti por contrato. Si participas en sistemas de pago administrados por Banxico, como el SPEI, sus reglas imponen requisitos adicionales de seguridad a los participantes.
Certificación no es cumplimiento regulatorio
Un certificado ISO/IEC 27001 no sustituye ninguna obligación ante la CNBV, Banxico o la autoridad de datos personales. Lo que sí hace es darte un sistema para identificar esas obligaciones (control 5.31), asignarlas a dueños, implementarlas y demostrar su eficacia con evidencia. Diseña el SGSI para que el regulador y el auditor de certificación encuentren la misma información.
Qué aporta ISO 27001 a una fintech frente a la regulación
La regulación dice qué debes lograr; ISO/IEC 27001:2022 aporta el cómo gestionarlo de forma sistemática. En la práctica, las fintechs que obtienen más valor del SGSI lo usan para cuatro fines:
Gobierno y rendición de cuentas
Las cláusulas 5.1 a 5.3 obligan a que la dirección asigne roles, recursos y responsabilidades. Eso se alinea con la expectativa regulatoria de que el órgano de administración conozca y supervise el riesgo tecnológico.
Gestión de riesgos repetible
El §6.1.2 exige criterios de aceptación y resultados consistentes y comparables. Esa trazabilidad es la que un supervisor espera ver cuando pregunta por qué se priorizó un control sobre otro.
Evidencia continua
Auditoría interna (§9.2), revisión por la dirección (§9.3) y acción correctiva (§10.2) producen un historial que demuestra mejora, no solo cumplimiento puntual.
Confianza de socios
Bancos patrocinadores, procesadores, adquirentes e inversionistas piden evidencia independiente. El certificado emitido por un organismo acreditado bajo ISO/IEC 17021-1 reduce cuestionarios y auditorías de segunda parte.
Si además necesitas demostrar continuidad operativa, el SGSI se integra de forma natural con un sistema de gestión de continuidad conforme a ISO 22301; ambos comparten la estructura armonizada y el control 5.30 de ISO/IEC 27001 hace de puente.
Requisitos de ISO 27001 aplicados a fintech y evidencia que pide el auditor
La siguiente tabla relaciona los requisitos que el auditor revisa con mayor profundidad en entidades financieras con la evidencia que normalmente resulta suficiente. Úsala como base para tu matriz de cumplimiento regulatorio.
| Requisito ISO/IEC 27001:2022 | Expectativa en servicios financieros | Evidencia típica |
|---|---|---|
| §4.2 y Anexo A 5.31 Requisitos legales y contractuales | Inventario de obligaciones de la Ley Fintech, disposiciones CNBV, circulares de Banxico, LFPDPPP y PCI DSS | Matriz regulatoria con artículo o disposición, dueño, control asociado y fecha de última revisión |
| §5.3 Roles y responsabilidades | Responsable de seguridad con independencia de la operación de TI | Nombramiento, descripción de puesto, línea de reporte al consejo o comité |
| §6.1.2 Apreciación de riesgos | Riesgos de fraude, robo de identidad, abuso de API, indisponibilidad de canales | Matriz con escenarios por producto y canal, aprobada por el comité de riesgos |
| Anexo A 5.15 a 5.18 y 8.2, 8.5 Accesos | Mínimo privilegio, factor múltiple, revisión periódica | Reportes de revisión de accesos firmados; configuración de autenticación robusta |
| Anexo A 8.24 Criptografía | Cifrado en tránsito y en reposo; gestión de llaves | Política criptográfica, inventario de llaves y certificados, rotaciones registradas |
| Anexo A 8.15, 8.16, 8.17 Registro, monitoreo y sincronización | Trazabilidad de operaciones y eventos con hora confiable | Bitácoras centralizadas, retención definida, fuente de tiempo sincronizada |
| Anexo A 5.24 a 5.28 Incidentes | Clasificación, escalamiento y, cuando aplique, notificación al regulador y a titulares | Procedimiento con criterios de severidad, registros de incidentes, simulacros |
| Anexo A 5.19 a 5.23 Terceros y nube | Supervisión de proveedores críticos y servicios en la nube | Evaluaciones de proveedores, cláusulas contractuales, informes de atestación vigentes |
| Anexo A 5.29, 5.30, 8.13, 8.14 Continuidad | Recuperación de canales transaccionales en tiempos definidos | BIA, plan de recuperación, pruebas de restauración y conmutación documentadas |
| Anexo A 8.29 y 5.35 Pruebas y revisión independiente | Pruebas de penetración por terceros con capacidad técnica | Informes de pruebas, plan de remediación y verificación de cierre |
Requisito normativo: requisitos legales identificados y actualizados
El control 5.31 de ISO/IEC 27001:2022 pide identificar, documentar y mantener actualizados los requisitos legales, regulatorios y contractuales relevantes para la seguridad de la información, así como el enfoque para cumplirlos. En una fintech, el auditor esperará ver la regulación secundaria de la CNBV y de Banxico en esa matriz, con evidencia de que se revisa cuando hay reformas.
Controles del Anexo A con mayor peso en servicios financieros
Los 93 controles del Anexo A se agrupan en cuatro temas: organizacionales (5.1 a 5.37), de personas (6.1 a 6.8), físicos (7.1 a 7.14) y tecnológicos (8.1 a 8.34). En una fintech, la mayoría aplica, pero estos merecen un diseño especialmente cuidadoso:
Identidad y autenticación de clientes y personal
La autenticación segura (8.5) debe distinguir entre usuarios internos y clientes. Para personal con acceso a sistemas transaccionales, el factor múltiple y el acceso privilegiado temporal (8.2) son el estándar mínimo defendible. Para clientes, la autenticación y el registro de dispositivos deben estar ligados a tu análisis de riesgo de fraude y a los requisitos que establezca la regulación de tu figura.
Seguridad de API y arquitectura
Las fintechs exponen servicios a socios, agregadores y aplicaciones móviles. Los controles 8.26 (requisitos de seguridad de aplicaciones) y 8.27 (arquitectura segura) deben cubrir autenticación entre servicios, limitación de tasa, validación de entradas, control de autorización por objeto y versionado. Las pruebas de seguridad (8.29) deben incluir explícitamente las API, no solo la interfaz web.
Criptografía y gestión de llaves
El control 8.24 exige reglas para el uso eficaz de la criptografía, incluida la gestión de llaves. En la práctica, el auditor pregunta dónde se generan las llaves, quién puede usarlas, cada cuándo se rotan y cómo se revocan. Un módulo de seguridad de hardware o un servicio de gestión de llaves en la nube con políticas de acceso restrictivas suele ser la respuesta.
Monitoreo, inteligencia de amenazas y fraude
El control 5.7 (inteligencia de amenazas), nuevo en 2022, es especialmente relevante: campañas de phishing que suplantan tu marca, filtraciones de credenciales y nuevas técnicas de fraude deben alimentar tus reglas de monitoreo (8.16). Documenta qué fuentes consultas, quién analiza la información y qué decisiones se tomaron con ella.
Proveedores y servicios en la nube
Muchas fintechs dependen de proveedores de identidad digital, validación biométrica, nube, procesadores de pago y mensajería. Los controles 5.19 a 5.22 y 5.23 exigen evaluar, contratar con requisitos de seguridad, supervisar y gestionar cambios en esos servicios. La regulación financiera suele añadir requisitos sobre ubicación de datos, acceso del supervisor y continuidad del servicio; inclúyelos en tus contratos.
Implementación de ISO 27001 en una fintech paso a paso
- Matriz regulatoria primero. Antes de redactar políticas, construye el inventario de obligaciones (5.31) a partir de la Ley Fintech, las disposiciones de la CNBV aplicables a tu figura, las circulares de Banxico, la LFPDPPP de 2025, la regulación de prevención de lavado y tus contratos con bancos y marcas de tarjetas.
- Alcance alineado a la autorización. Define el alcance (§4.3) con los productos y canales autorizados o en proceso de autorización. Excluir el canal móvil o la operación de soporte suele generar dudas en el auditor y en el supervisor.
- Apreciación de riesgos por producto y canal. Combina amenazas técnicas (abuso de API, robo de sesión, configuración errónea en la nube) con riesgos de negocio (fraude, suplantación, indisponibilidad en horas pico). Usa criterios aprobados por el comité de riesgos (§6.1.2).
- Declaración de Aplicabilidad trazable. Para cada control incluido, indica la obligación regulatoria o el riesgo que atiende. Esa trazabilidad doble es la que más valor da en una visita de supervisión.
- Controles técnicos prioritarios. Identidad y factor múltiple, gestión de llaves, bitácoras centralizadas con hora sincronizada, gestión de vulnerabilidades con plazos por severidad y separación de ambientes.
- Incidentes y continuidad. Define criterios de severidad que incluyan los supuestos de notificación regulatoria y a titulares; realiza un BIA de los procesos transaccionales y prueba la recuperación.
- Terceros críticos. Evalúa y contrata con cláusulas de seguridad, derecho de auditoría, notificación de incidentes y plan de salida.
- Auditoría interna y revisión por la dirección. Audita contra ISO/IEC 27001 y contra tu matriz regulatoria en el mismo ejercicio; lleva los resultados al consejo o comité correspondiente.
Ejemplo resuelto: IFPE ficticia preparando su certificación
Ejemplo aplicado: "Billetera Sierra", institución de fondos de pago electrónico con 70 colaboradores
Contexto. Fintech ficticia con operación en Monterrey, aplicación móvil para pagos entre usuarios y comercios, infraestructura en nube pública, conexión con un banco patrocinador y un procesador de tarjetas. El banco solicita evidencia independiente de seguridad para renovar el contrato.
BIA simplificado de procesos críticos.
| Proceso | Tiempo máximo tolerable de interrupción | RTO definido | RPO definido |
|---|---|---|---|
| Transferencias entre usuarios | 4 h | 1 h | 0 (sin pérdida de transacciones confirmadas) |
| Alta de clientes (KYC) | 24 h | 8 h | 1 h |
| Conciliación con banco patrocinador | 24 h | 12 h | 4 h |
Riesgo prioritario. Abuso de la API de consulta de saldos mediante credenciales robadas. Criterios: Probabilidad × Impacto en escala 1–5; tratamiento obligatorio con nivel ≥ 10.
Controles seleccionados. Factor múltiple y vinculación de dispositivo (8.5), limitación de tasa y detección de anomalías (8.16), autorización por objeto en la API (8.26), inteligencia de amenazas sobre filtraciones de credenciales (5.7), prueba de penetración específica de API por tercero (8.29). El residual de 8 fue aceptado por el comité de riesgos con revisión trimestral.
Resultado de la auditoría interna. Tres no conformidades menores: una revisión de accesos trimestral omitida, un proveedor de verificación de identidad sin evaluación anual y una prueba de restauración sin evidencia del tiempo alcanzado. Las tres se cerraron con análisis de causa antes de la etapa 2. Datos ilustrativos.
Indicadores de seguridad recomendados para fintech
| Indicador | Cálculo | Criterio sugerido | Control |
|---|---|---|---|
| Disponibilidad de canales transaccionales | Minutos disponibles ÷ minutos totales del periodo | Según tu compromiso contractual y regulatorio | 8.14, 5.30 |
| Vulnerabilidades críticas abiertas fuera de plazo | Número al cierre del mes | 0 | 8.8 |
| Cobertura de factor múltiple en accesos privilegiados | Cuentas privilegiadas con MFA ÷ total | 100 % | 8.2, 8.5 |
| Tiempo de clasificación de incidentes | Minutos entre detección y clasificación | Definido por severidad en tu procedimiento | 5.25 |
| Proveedores críticos evaluados en el año | Evaluados ÷ críticos | 100 % | 5.22 |
| Pruebas de recuperación dentro del RTO | Pruebas exitosas ÷ pruebas ejecutadas | 100 % | 5.30, 8.13 |
| Obligaciones regulatorias con dueño y control asignado | Asignadas ÷ identificadas | 100 % | 5.31 |
Hallazgos típicos de auditoría en fintech y servicios financieros
| Hallazgo | Requisito | Cómo corregir |
|---|---|---|
| Matriz regulatoria sin las disposiciones de la CNBV aplicables a la figura o sin actualización tras reformas | Anexo A 5.31; §4.2 | Revisión jurídica de la matriz, dueño por obligación y vigilancia periódica del DOF |
| Criterios de severidad de incidentes que no contemplan supuestos de notificación al regulador o a titulares | Anexo A 5.24, 5.26 | Actualizar procedimiento con árbol de decisión y responsables de notificación |
| Llaves criptográficas sin inventario ni rotación documentada | Anexo A 8.24 | Inventario, política de ciclo de vida y evidencia de rotaciones |
| Proveedor de verificación biométrica sin evaluación ni cláusulas de seguridad | Anexo A 5.19, 5.20 | Evaluación de riesgos del proveedor, adenda contractual y seguimiento anual |
| Relojes de servidores desincronizados que impiden correlacionar eventos | Anexo A 8.17 | Fuente de tiempo única y monitoreo de desviaciones |
| Riesgo residual aceptado por TI sin aprobación del dueño del riesgo | §6.1.3 f) | Formalizar aceptación por el dueño del riesgo o comité |
| Pruebas de penetración que excluyen la API pública | Anexo A 8.29 | Ampliar alcance de pruebas y verificar remediación |
| Datos personales de clientes en ambientes de prueba | Anexo A 8.11, 8.33, 5.34 | Enmascaramiento obligatorio y depuración verificada |
Checklist de ISO 27001 para fintech
- Matriz regulatoria completa: Ley Fintech, disposiciones CNBV, circulares de Banxico aplicables, LFPDPPP 2025, prevención de lavado, PCI DSS y contratos.
- Alcance que cubre productos y canales autorizados, incluida la aplicación móvil y las API.
- Responsable de seguridad con independencia de la operación de TI y reporte a la dirección.
- Apreciación de riesgos por producto y canal, con escenarios de fraude y abuso de API.
- SoA con trazabilidad a riesgo y a obligación regulatoria por control.
- Factor múltiple en todos los accesos privilegiados y revisión periódica de accesos.
- Política criptográfica e inventario de llaves con rotaciones evidenciadas.
- Bitácoras centralizadas, hora sincronizada y alertas con responsable.
- Procedimiento de incidentes con criterios de notificación regulatoria y a titulares.
- BIA de procesos transaccionales y pruebas de recuperación dentro del RTO.
- Proveedores críticos evaluados, con cláusulas de seguridad, auditoría y salida.
- Pruebas de penetración anuales por terceros, incluidas API, con cierre verificado.
- Ciclo completo de auditoría interna y revisión por la dirección con acuerdos documentados.
Para comparar ISO 27001 con el reporte SOC 2 que piden algunos socios estadounidenses, consulta ISO 27001 vs SOC 2. Si estás en etapa temprana, la guía para startups y SaaS explica cómo dimensionar un SGSI lean, y para elegir al organismo que te auditará revisa cómo elegir organismo certificador. Más información en ISO 27001 y en nuestra página de tecnología, SaaS y Fintech.
Cómo lo abordamos en Quality College
En servicios financieros iniciamos con un diagnóstico que contrasta tu operación contra ISO/IEC 27001:2022 y contra tu matriz regulatoria al mismo tiempo, para que el SGSI produzca la evidencia que piden tanto el auditor de certificación como tu banco patrocinador o el supervisor. Acompañamos la definición de alcance, riesgos y SoA, la implementación de controles, la formación de auditores internos, la auditoría interna y las etapas 1 y 2 ante el organismo certificador acreditado. Los proyectos típicos van de 8 a 16 semanas según alcance y madurez; la interpretación jurídica de la regulación financiera debe validarla tu área legal o asesor especializado.
Usamos Qualitix Bot® para generar borradores de políticas, procedimientos y matrices a partir de tu contexto, siempre revisados por un consultor, e ISO Track® para gestionar riesgos, incidentes, acciones correctivas e indicadores en un solo lugar. Contamos con más de 150 organizaciones acompañadas desde 2018 y con garantía contractual de certificación.