Cloudflare logra la certificación ISMS de Corea del Sur

Corea del Sur exige un ISMS local: el caso de Cloudflare

Diez días de auditoría con los auditores sentados junto al equipo, 80 controles revisados uno por uno y un año y medio de preparación. Eso necesitó Cloudflare, una compañía con sede en Estados Unidos y red global, para obtener la certificación ISMS de Corea del Sur bajo el marco ISMS-P. Para un founder que vende SaaS fuera de su país, la lección no está en el certificado: está en todo lo que el proceso obligó a cambiar dentro del producto.

Que es el ISMS-P y en que se diferencia de ISO 27001 o SOC 2

El ISMS coreano es una certificación localizada, no una versión más exigente de las que ya existen. Cubre política de seguridad, control de accesos, gestión de autenticación y permisos, cifrado, respuesta a incidentes, gestión de riesgos y recuperación ante desastres. La diferencia es contra qué se evalúa: cómo los datos personales circulan realmente por los sistemas de la empresa y qué espera la Ley de Protección de Información Personal (PIPA) de Corea junto a sus guías regulatorias.

El marco se establece principalmente en el Artículo 47 de la Ley de Promoción de la Utilización de Redes de Información y Comunicaciones y Protección de la Información de Corea, con los criterios y el procedimiento fijados en su Decreto de Aplicación y en la notificación pública sobre certificación ISMS emitida por el MSIT, el Ministerio de Ciencia y TIC.

El proceso exige una auditoría independiente realizada por un auditor designado por KISA, institución gubernamental afiliada al MSIT, seguida de la revisión de un comité especial. La certificación es válida por tres años y requiere una auditoría anual para mantenerse.

Cloudflare ya contaba con ISO/IEC 27001, ISO/IEC 27701, ISO/IEC 27017 e ISO/IEC 27018, entre otros marcos globales. La compañía describe el ISMS como una localización de los mismos principios, no como un reemplazo, y esa distinción cambia qué busca el auditor y cómo lo busca.

El problema real: los flujos de registro que nunca muestran formulario

La parte visible es simple. En Corea del Sur, la pantalla de registro del panel de Cloudflare desglosa el consentimiento en cuatro ítems etiquetados por separado: tres obligatorios (términos de servicio, recopilación y uso de datos personales, y transferencia limitada de datos personales al exterior) y uno opcional (cesión de datos personales a terceros con fines de marketing).

Los tres obligatorios son puertas duras: el botón de registro permanece deshabilitado hasta que los tres estén marcados, así que no existe un camino que cree una cuenta sin una acción afirmativa en cada uno. El ítem opcional solo gobierna el permiso de marketing y dejarlo sin marcar no afecta la creación de la cuenta.

La dificultad apareció en los accesos que se saltan el formulario. A nivel global, una cuenta de Cloudflare se puede crear con Google, Apple o GitHub: esos flujos entregan al usuario a un proveedor de identidad y vuelven con una identidad autenticada, sin renderizar nunca el formulario propio, que es justo donde viven los cuatro consentimientos. No hay paso en ese intercambio donde se puedan presentar tres ítems obligatorios, enlazar cada uno a su texto completo en coreano y exigir una acción afirmativa antes de que la cuenta exista. La pantalla del proveedor de identidad no es modificable por el proveedor del servicio.

La decisión que tomaron fue eliminar el registro social en Corea del Sur. Cada cuenta creada allí pasa por el formulario propio, que sí aplica los consentimientos exigidos. La otra opción era construir una pantalla de consentimiento posterior a la autenticación para un solo país.

Cómo se implementa: geolocalización por IP con confirmación del usuario

La señal de país es la misma que tiene disponible cualquier cliente de Cloudflare: un código de dos letras derivado de la IP del cliente, expuesto como cabecera CF-IPCountry en el origen y como dato de país dentro de un Worker. En esencia, la lógica es una comparación de cadenas: si el país es KR, se renderiza el formulario con locale coreano, consentimiento itemizado y sin login social.

Pero el código de país no es el disparador completo. La propia documentación de Cloudflare sobre geolocalización por IP advierte que es una estimación y no una ciencia exacta, que las direcciones rotan y cambian de dueño, y que no conviene usarla como única señal cuando el caso de uso es crítico para cumplir un requisito local. Un residente coreano de viaje, detrás de una VPN o de la NAT de una operadora móvil, puede llegar sin dirección coreana.

Por eso la geolocalización decide qué formulario aparece por defecto, pero el país que el usuario elige al registrarse anula esa detección y lleva la decisión de ahí en adelante. La IP indica de dónde viene una petición; solo el usuario puede decir dónde reside. Separar esas dos cosas es lo que hace que el consentimiento sea real y no presunto.

ISO 27001 y SOC 2 no cubren esto: qué mira distinto el auditor

Lo que cambió en la auditoría no fueron los controles, sino la forma de la evidencia. El equipo presentó diagramas detallados de flujos de datos: cada ruta por la que un empleado puede acceder a información personal que la compañía recopila, procesa y almacena. Los flujos no son específicos de Corea; lo específico fue que los auditores no aceptaron una descripción narrativa, querían diagramas legibles e interrogables.

Para cada diagrama se examinaron todas las capas de control de acceso y se probó su eficacia, en sistemas internos, sitios públicos, páginas de eventos y el panel de Cloudflare, cubriendo el ciclo de vida completo del dato del usuario desde el primer contacto hasta su destrucción. La auditoría también escrutó el lenguaje exacto del consentimiento: la redacción en el registro, la estructura de cada aviso y si los ítems se presentaban por separado y con claridad.

El alcance también funciona distinto. KISA define el alcance certificado como una frontera de servicio, no como una lista de productos. La Declaración de Alcance se describe en tres partes: el perímetro organizativo y operativo con las entidades, equipos y procesos que operan el servicio; el perímetro de infraestructura, es decir la red y la plataforma sobre la que corre; y los activos de información y flujos de datos personales dentro de esa frontera. Si un producto se entrega a través de esa frontera certificada, queda cubierto aunque no aparezca nombrado en ningún documento. Es lo inverso a un reporte SOC 2 o a un certificado ISO 27001, donde la cobertura se confirma buscando el producto en una lista.

La preparación se extendió a aproximadamente año y medio, en parte porque cada auditoría cubre un periodo anual único. Al cruzar de un año de auditoría al siguiente hubo que retraducir políticas actualizadas, volver a recopilar y evaluar evidencia, republicar la política de privacidad y absorber cambios de formato y diseño que los equipos de marketing y web habían introducido en el camino.

¿Qué significa esto para tu startup?

Si vendes software a clientes en Corea del Sur, o estás a punto de hacerlo, este caso deja lecciones muy concretas.

• Presupuesta el ciclo anual, no la fecha de entrega. Una certificación local puede cruzar periodos de auditoría y obligarte a repetir traducciones, evidencia y políticas. Si tu plan comercial para Asia depende del certificado, suma meses de colchón, no semanas.
• El consentimiento es código, no un documento legal. Un formulario desglosado por ítem, con los obligatorios funcionando como puertas duras, requiere trabajo de producto. Si tu registro pasa por Google o Apple, decide de antemano entre construir una pantalla de consentimiento posterior a la autenticación o deshabilitar ese camino en el país. Son las dos únicas opciones.
• No asumas que la IP te dice dónde reside tu usuario. Si vas a segmentar por país para cumplir una norma local, deja que el usuario confirme o corrija el país durante el registro. La geolocalización por IP es una estimación, no un dato legal.
• Anticipa qué evidencia te van a pedir. En Corea, los auditores pidieron diagramas de flujo de datos en lugar de descripciones escritas. Si tu equipo de seguridad documenta sus controles solo en prosa, ese material no va a servir para una auditoría local.
• Verifica el respaldo antes de firmar. El certificado de Cloudflare es consultable en el registro público de organizaciones certificadas de KISA, lo que da a los equipos de compras y riesgos una confirmación independiente junto a su portafolio de ISO 27001 y SOC 2.

Un ecosistema con equipos chicos y ciclos de venta largos no puede permitirse descubrir a mitad de una negociación que el certificado que tiene no responde la pregunta que el comprador está haciendo.

Conclusión

Cloudflare obtuvo el ISMS coreano con una decisión de producto de alcance nacional y un cambio en el camino de creación de cuentas. No fue un ejercicio de papeleo: fue rediseñar cómo se pide consentimiento, cómo se prueba el flujo de datos y cómo se define el alcance de lo certificado.

Para cualquier startup que apunte a mercados regulados de Asia, el mensaje es directo. Las certificaciones globales abren conversaciones, pero cada mercado exige que tu producto se comporte como un producto local, en su idioma, con sus expectativas de consentimiento y con sus reglas de protección de datos. Cuanto antes lo trates como una decisión de ingeniería y no como un trámite legal, más barato te va a salir.

Fuentes

• Localizing compliance at scale: achieving South Korea's ISMS certification