La transición a ISO 27001:2022 ya no es opcional — los certificados bajo la versión 2013 expiraron en octubre de 2025. Para las fintechs argentinas, esto no es solo un trámite: los 11 controles nuevos del Anexo A abordan directamente los riesgos que más les preocupan. Cloud, terceros, DLP, privacidad y threat intelligence ahora tienen controles explícitos.
En este artículo te explicamos exactamente qué cambió, por qué importa para el ecosistema fintech argentino y cómo prepararte sin frenar tu operación.
📋 En este artículo
- Contexto: por qué se actualizó la norma
- Cambios en la estructura del SGSI
- Nuevo Anexo A: de 114 a 93 controles
- Los 11 controles nuevos (detallados)
- Impacto específico en fintechs argentinas
- Relación con BCRA y CNV
- Cronograma de transición
- Checklist de preparación
- Errores frecuentes en la transición
- Preguntas frecuentes
1. Contexto: por qué se actualizó la norma
ISO 27001:2013 llevaba casi una década sin cambios sustanciales. En ese período, el panorama de amenazas cambió radicalmente:
- Migración masiva a cloud — el 87% de las empresas argentinas usa al menos un servicio cloud crítico.
- Cadenas de suministro digital — ataques como SolarWinds demostraron que un proveedor comprometido puede afectar a miles de organizaciones.
- Regulaciones de privacidad — GDPR, LGPD y la evolución de la ley 25.326 en Argentina exigen controles más granulares sobre datos personales.
- Ransomware y extorsión digital — los ataques a empresas argentinas crecieron 300% entre 2020 y 2025.
- Trabajo remoto permanente — el perímetro de seguridad tradicional dejó de existir.
La versión 2022 fue publicada el 25 de octubre de 2022 y establece un período de transición que finalizó el 31 de octubre de 2025. Si tu certificado dice "ISO 27001:2013", ya no es válido.
2. Cambios en la estructura del SGSI (cláusulas 4–10)
Los cambios en las cláusulas principales son quirúrgicos pero importantes:
| Cláusula | Qué cambió | Impacto práctico |
|---|---|---|
| 4.2 | Se aclara que hay que identificar cuáles requisitos de partes interesadas se abordan a través del SGSI | Debés mapear explícitamente qué necesidades de clientes, reguladores y socios cubre tu sistema |
| 4.4 | Se agrega "incluyendo los procesos necesarios y sus interacciones" | Los auditores van a pedir que muestres cómo interactúan los procesos de tu SGSI |
| 6.2 | Los objetivos deben ser monitoreados y estar disponibles como información documentada | Necesitás KPIs de seguridad medibles, no solo declaraciones de intención |
| 6.3 (nueva) | Se agrega "Planificación de cambios" — cómo gestionás cambios al SGSI | Debés tener un proceso formal para cambios en el sistema de gestión |
| 8.1 | Se pide establecer criterios para los procesos y aplicar control basado en esos criterios | Más énfasis en la operación diaria del SGSI, no solo en la documentación |
| 9.3 | Revisión por la dirección se divide en entradas y salidas definidas | Tus actas de revisión gerencial van a necesitar estructura más formal |
| 10 | Se reordena: mejora continua primero, no conformidades después | Cambio de enfoque: primero proactividad, después corrección |
3. Nuevo Anexo A: de 114 a 93 controles
El cambio más visible es la reorganización completa del Anexo A. Los 114 controles en 14 dominios de la versión 2013 se consolidaron en 93 controles en 4 categorías:
Importante: no se eliminaron controles. Se fusionaron, reorganizaron y agregaron 11 nuevos. Si ya tenías controles implementados bajo la versión 2013, la mayoría sigue siendo válida — solo cambia la referencia.
Cada control ahora incluye una tabla de atributos (#Preventivo, #Detectivo, #Correctivo, #Confidencialidad, #Integridad, #Disponibilidad) que facilita el mapeo y la trazabilidad.
4. Los 11 controles nuevos en detalle
Estos son los controles que no existían en la versión 2013 y que vas a necesitar implementar:
| Control | Nombre | Qué implica para una fintech |
|---|---|---|
| A.5.7 | Threat Intelligence | Recopilar y analizar inteligencia sobre amenazas relevantes. Implica monitorear feeds de amenazas, CERTs y alertas del sector financiero. |
| A.5.23 | Seguridad en servicios cloud | Definir requisitos de seguridad para adquisición, uso y gestión de servicios cloud. Crítico para fintechs que operan 100% en AWS/GCP/Azure. |
| A.5.30 | Preparación TIC para continuidad | Planes de continuidad específicos para infraestructura tecnológica. Incluye RPO/RTO definidos y probados. |
| A.7.4 | Monitoreo de seguridad física | Vigilancia continua de instalaciones. Aplica incluso si tu equipo es remoto — los data centers y oficinas de procesamiento necesitan monitoreo. |
| A.8.9 | Gestión de configuraciones | Configuraciones de seguridad documentadas y controladas. Infrastructure as Code (IaC) es la mejor forma de demostrarlo. |
| A.8.10 | Eliminación de información | Borrado seguro cuando ya no se necesita. Incluye datos en cloud, backups, dispositivos y bases de datos de clientes dados de baja. |
| A.8.11 | Enmascaramiento de datos | Anonimización/pseudonimización para ambientes de test y analytics. Fundamental para fintechs que manejan CBUs, DNIs y datos financieros. |
| A.8.12 | Prevención de fuga de datos (DLP) | Controles para prevenir exfiltración. Incluye monitoreo de endpoints, email, repositorios y APIs expuestas. |
| A.8.16 | Monitoreo de actividades | SIEM, logging centralizado y detección de anomalías. Las fintechs que ya usan herramientas como Datadog o Splunk tienen ventaja. |
| A.8.23 | Filtrado web | Control de acceso a sitios web según categorías de riesgo. Aplica a estaciones de trabajo y servidores con acceso a internet. |
| A.8.28 | Codificación segura | Principios de desarrollo seguro aplicados. Code review, SAST/DAST, dependencias auditadas. Esencial para fintechs que desarrollan su propio software. |
5. Impacto específico en fintechs argentinas
Las fintechs argentinas tienen un perfil de riesgo particular que hace que varios de estos cambios las impacten de lleno:
🔗 Cadena de proveedores crítica
La fintech típica depende de 8–15 proveedores tecnológicos: cloud (AWS/GCP), core bancario (Mambu, Temenos), pagos (COELSA, DEBIN), KYC/AML (Nosis, Equifax), comunicaciones (Twilio, SendGrid). El control A.5.23 (cloud) y la mayor exigencia en gestión de terceros impactan directamente.
Lo que te van a pedir: evidencia de evaluación de riesgos de cada proveedor crítico, cláusulas contractuales de seguridad, monitoreo periódico y plan de salida.
💻 Desarrollo continuo
Las fintechs deployean varias veces por día. El control A.8.28 (codificación segura) pide que esto esté formalizado: pipeline de CI/CD con SAST, code review obligatorio, gestión de dependencias y ambientes de test con datos enmascarados (A.8.11).
📊 Datos financieros sensibles
CBUs, CVUs, DNIs, scores crediticios, movimientos bancarios — el tipo de datos que manejan las fintechs tiene máxima sensibilidad. Los controles nuevos de DLP (A.8.12), eliminación (A.8.10) y enmascaramiento (A.8.11) son la respuesta directa.
⚡ Operación 24/7
Una billetera digital o una plataforma de inversiones no puede parar. El control A.5.30 (preparación TIC para continuidad) exige RPO y RTO definidos, testeados y documentados. No alcanza con tener backup — necesitás probar que funciona.
🌍 Aspiración internacional
Muchas fintechs argentinas operan o planean operar en otros países de LATAM. ISO 27001:2022 es el estándar que piden Visa, Mastercard, socios bancarios internacionales y reguladores de Brasil, Chile y Colombia.
6. Relación con regulación argentina (BCRA / CNV)
Si bien ISO 27001 no es obligatoria por ley en Argentina, existe una convergencia cada vez mayor con los requisitos regulatorios:
| Regulación | Qué exige | Cobertura ISO 27001:2022 |
|---|---|---|
| Com. A 4609 (BCRA) | Gestión de riesgos tecnológicos, control de accesos, continuidad, gestión de incidentes | ~85% cubierto por los controles del Anexo A + cláusulas 6-10 |
| Com. A 6017 (BCRA) | Lineamientos para outsourcing tecnológico | ~90% cubierto — A.5.19 a A.5.23 abordan gestión de proveedores y cloud |
| RG CNV 704 | Ciberseguridad para agentes del mercado de capitales | ~80% cubierto — el SGSI cubre la mayoría de los requisitos |
| Ley 25.326 (Datos Personales) | Medidas de seguridad para datos personales | Alto solapamiento — A.8.10, A.8.11 y A.8.12 refuerzan la protección de datos |
Punto clave: certificar ISO 27001:2022 no reemplaza el cumplimiento regulatorio, pero simplifica enormemente la demostración ante auditores del BCRA y la CNV, y reduce la carga de evidencias duplicadas.
7. Cronograma de transición
8. Checklist de preparación para la transición
Si estás en proceso de transición o certificación inicial, usá esta lista como guía:
✅ Checklist de transición ISO 27001:2022
- ☐ Realizar gap analysis: mapear tus controles actuales vs. Anexo A 2022
- ☐ Actualizar la Declaración de Aplicabilidad (SoA) al nuevo formato de 93 controles
- ☐ Implementar los 11 controles nuevos que apliquen a tu alcance
- ☐ Actualizar la evaluación de riesgos incluyendo proveedores cloud y terceros críticos
- ☐ Revisar y actualizar políticas de seguridad alineadas a las nuevas cláusulas
- ☐ Documentar el proceso de gestión de cambios del SGSI (nueva cláusula 6.3)
- ☐ Definir KPIs de seguridad medibles y monitoreables
- ☐ Actualizar contratos con proveedores incorporando requisitos de seguridad cloud
- ☐ Implementar o documentar herramientas de DLP, SIEM y threat intelligence
- ☐ Probar planes de continuidad con RPO/RTO documentados
- ☐ Realizar auditoría interna bajo los nuevos criterios
- ☐ Ejecutar revisión por la dirección con las entradas/salidas actualizadas
- ☐ Coordinar auditoría de transición con organismo de certificación acreditado
9. Errores frecuentes en la transición
Después de decenas de auditorías de transición, estos son los patrones que más se repiten:
❌ Cambiar solo la numeración
Renumerar controles del SoA sin evaluar si los 11 nuevos aplican. Los auditores lo detectan inmediatamente.
❌ Ignorar la gestión de cloud
Decir "es responsabilidad del proveedor" no alcanza. Necesitás demostrar que evaluaste y monitoreás los riesgos.
❌ No probar continuidad
Tener un plan de continuidad escrito pero sin pruebas documentadas. A.5.30 pide evidencia de pruebas realizadas.
❌ KPIs decorativos
Definir métricas que nadie mide. Los objetivos de seguridad (cláusula 6.2) ahora deben ser monitoreados activamente.
10. Preguntas frecuentes
Los certificados emitidos bajo la versión 2013 dejaron de ser válidos el 31 de octubre de 2025. Si todavía no migraste, necesitás hacer la transición lo antes posible o iniciar una certificación nueva directamente bajo ISO 27001:2022.
Ambas opciones. Si nunca certificaste, arrancás directo con la versión 2022. Si ya tenías certificación 2013, hacés una auditoría de transición que evalúa los cambios y tu adaptación.
Depende del estado actual de tu SGSI. Con buen nivel de madurez, la transición puede hacerse en 3–4 meses. Si necesitás implementar los 11 controles nuevos, calculá 5–8 meses.
No la reemplaza, pero la cubre en gran parte. ISO 27001 aborda gestión de riesgos, control de accesos, continuidad y gestión de incidentes — todos requisitos de la A 4609. Certificar facilita el cumplimiento regulatorio.
93 controles agrupados en 4 categorías (Organizacionales, Personas, Físicos, Tecnológicos), versus los 114 controles en 14 dominios de la versión 2013.
No es legalmente obligatorio, pero es cada vez más exigido por bancos, aseguradoras y socios internacionales como requisito para operar como proveedor. El BCRA y la CNV recomiendan marcos de seguridad alineados a estándares internacionales.
El costo varía según el alcance, cantidad de empleados y complejidad tecnológica. Contactanos para una cotización personalizada — respondemos en 24 horas con alcance y tiempos claros.
¿Necesitás certificar o migrar a ISO 27001:2022?
Te respondemos en 24 horas con alcance técnico, tiempos y presupuesto. Sin compromiso.