Política de Respuesta a Incidentes

La presente Política de Respuesta a Incidentes describe cómo SOMA9 Holdings, LLC («SOMA9») detecta, clasifica, contiene, erradica, recupera y aprende de los incidentes operativos y de seguridad. Constituye la pieza pública que acompaña al manual operativo interno de respuesta a incidentes y se alinea con los artículos 33 y 34 del RGPD (y disposiciones equivalentes del UK GDPR y la LGPD), la Directiva NIS2 (Directiva (UE) 2022/2555) cuando resulte aplicable, y las buenas prácticas internacionales recogidas en la norma ISO/IEC 27035.

Resumen en lenguaje sencillo

Cuando algo va mal — una caída, un compromiso confirmado, una infección de malware en un sitio del Cliente, una credencial filtrada — SOMA9 sigue un manual fijo: detectar, clasificar por gravedad, contener, comunicar, recuperar y documentar lo sucedido. Si el incidente afecta a datos personales, el Cliente recibe notificación dentro de las 72 horas. Cerrado el incidente, se publica un post-mortem redactado con criterio para que las lecciones queden visibles y el mismo problema no se repita en silencio.

1. Ámbito y definiciones

La presente Política se aplica a cualquier evento que afecte, o pueda afectar razonablemente, a la confidencialidad, integridad o disponibilidad de los Servicios o de los Datos Personales del Cliente tratados por SOMA9.

Evento — ocurrencia observable en un sistema o red. La mayoría de eventos son rutinarios.

Incidente — evento que, tras triaje, se confirma con efecto significativo sobre confidencialidad, integridad o disponibilidad. Todo incidente entra en el ciclo de la cláusula 3.

Violación de datos personales — incidente que cumple la definición del artículo 4(12) RGPD: violación de la seguridad que ocasione la destrucción, pérdida o alteración accidental o ilícita de Datos Personales transmitidos, conservados o tratados de otra forma, o la comunicación o acceso no autorizados a dichos datos. Las violaciones de datos personales activan siempre la cláusula 8.

2. Clasificación por gravedad

SOMA9 clasifica los incidentes en una escala de cinco niveles. La gravedad es el máximo de las dimensiones de impacto (confidencialidad, integridad, disponibilidad, alcance). La establece el Incident Commander de guardia en el triaje y puede revisarse a medida que el incidente evoluciona.

3. Ciclo de vida

Todo incidente confirmado atraviesa seis fases. Las transiciones se registran con marca temporal en el ticket del incidente.

1. Detectar. Una alerta automática, un reporte de Cliente, una comunicación de investigador o una verificación operativa abren el incidente.
2. Triaje y clasificación. El Incident Commander de guardia confirma el incidente, fija la gravedad conforme a la cláusula 2, abre el ticket y convoca los roles necesarios.
3. Contener. Detener el daño. Aislar cuentas o sistemas afectados, bloquear acceso del atacante y congelar el estado para forense en SEV-1/2.
4. Erradicar. Eliminar la causa raíz: parchear la vulnerabilidad, rotar credenciales, retirar archivos maliciosos, reconstruir hosts comprometidos.
5. Recuperar. Restablecer los servicios al estado normal de operación. Validar mediante señales independientes antes de declarar la recuperación.
6. Lecciones aprendidas. En los 14 días naturales posteriores a la recuperación para SEV-1 y SEV-2, redacción del post-mortem (cláusula 9) y asignación de las acciones de seguimiento.

4. Roles y responsabilidades

• Incident Commander. Titular del incidente desde el triaje hasta el cierre. Único decisor en clasificación, comunicación y declaración de recuperación. Rota entre operadores formados.
• Communications Lead. Redacta y emite las actualizaciones internas, los avisos al Cliente y, cuando proceda, las notificaciones al regulador. Puede coincidir con el Incident Commander en incidentes menores.
• Technical Lead. Conduce la contención y la erradicación; titular del relato técnico.
• Scribe. Mantiene la línea temporal del incidente y el borrador del post-mortem.
• Customer Liaison. Contacta a los Clientes materialmente afectados y atiende sus consultas durante el incidente.
• Executive Sponsor. Autoriza la contratación de asesoría externa, las notificaciones al regulador y las comunicaciones públicas materiales en SEV-1.

En incidentes inferiores a SEV-2, un único operador podrá acumular varios roles. En SEV-1 y SEV-2, el Incident Commander, el Technical Lead y el Communications Lead deberán ser tres personas distintas.

5. Fuentes de detección

SOMA9 mantiene múltiples señales de detección independientes, sin que ninguna se considere autoritativa por sí sola:

• Imunify360 defensa proactiva en modo KILL, firewall de aplicaciones web, escáner de malware.
• ModSecurity con OWASP Core Rule Set.
• Monitorización de integridad de archivos sobre binarios y configuración de la plataforma.
• Logs de autenticación de cPanel y Exim con umbrales de anomalía.
• Heurística de abuso de salida (volumen de correo, patrones de rebotes, tráfico de escáneres).
• Monitor de CVE de kernel contra las versiones de paquetes instaladas.
• Reportes de Clientes mediante tickets de soporte, canal de seguridad (security@soma9.cloud) y el /.well-known/security.txt publicado.
• Comunicaciones de investigadores externos bajo la Política de Divulgación de Vulnerabilidades.

6. Contención, erradicación y recuperación

6.1 Principios de contención

Adóptese la acción de contención mínima que detenga el daño. Prefiérase la suspensión de una cuenta concreta a los bloqueos de red; prefiérase la modalidad temporal de sólo lectura a la destrucción. En SEV-1/2, preservar siempre el estado forense antes de cualquier acción destructiva.

6.2 Principios de erradicación

La erradicación no se considera completa hasta haber identificado la causa raíz, parcheado la vulnerabilidad, rotado las credenciales en riesgo y verificado mediante un escaneo de seguimiento la ausencia de indicadores de compromiso. No se omita el escaneo para declarar la erradicación de manera anticipada.

6.3 Principios de recuperación

La recuperación la declara el Incident Commander únicamente cuando señales independientes confirmen el estado normal (monitorización en verde, transacciones de Cliente de muestreo correctas y sin alertas nuevas en la ventana de observación correspondiente al nivel de gravedad).

7. Comunicación al Cliente

7.1 Cadencia

En incidentes que afecten materialmente al Cliente, SOMA9 emitirá actualizaciones con la siguiente cadencia:

• SEV-1: aviso inicial dentro de los 30 minutos posteriores a la confirmación; actualizaciones cada 30 minutos; aviso de resolución dentro de la hora siguiente a la recuperación; post-mortem en 14 días naturales.
• SEV-2: aviso inicial en 2 horas; actualizaciones cada 2 horas; aviso de resolución en las 4 horas siguientes a la recuperación; post-mortem en 14 días naturales.
• SEV-3: aviso inicial en 8 horas cuando el Cliente esté visiblemente afectado; aviso de resolución en las 24 horas siguientes a la recuperación; post-mortem a solicitud.
• SEV-4 y SEV-5: divulgación agregada en el resumen mensual de transparencia, cuando proceda.

7.2 Canales

Los avisos al Cliente se emiten por uno o más de los siguientes canales: (a) correo a la dirección del administrador de la cuenta registrada; (b) la página de estado de SOMA9; (c) la lista de correo del canal de seguridad para incidentes con relevancia de seguridad.

8. Notificación de violación de datos personales

Cuando SOMA9 actúe como Encargado y detecte una Violación de Datos Personales, SOMA9 lo notificará al Cliente afectado (Responsable) sin demora indebida y, en todo caso, dentro de las setenta y dos (72) horas posteriores al conocimiento de la violación, conforme al artículo 33(2) RGPD y a las disposiciones equivalentes del UK GDPR y la LGPD.

La notificación incluirá, en la medida en que la información se encuentre disponible en ese momento, los elementos del artículo 33(3) RGPD: naturaleza de la violación, categorías y número aproximado de Interesados y registros afectados, consecuencias probables y medidas adoptadas o propuestas.

Cuando SOMA9 actúe como Responsable (respecto a datos que SOMA9 recaba directamente, como información de facturación), SOMA9 notificará a la Autoridad de Control competente dentro de las 72 horas y a los Interesados afectados sin demora indebida cuando la violación sea susceptible de generar un alto riesgo, conforme a los artículos 33(1) y 34 RGPD.

En incidentes sometidos a las obligaciones de notificación de la NIS2 (cuando SOMA9 califique como entidad esencial o importante en el Estado miembro correspondiente), SOMA9 emitirá una notificación de alerta temprana en 24 horas y una notificación más completa en 72 horas a la autoridad competente y al CSIRT, según lo exigido.

9. Comunicación pública y post-mortems

SOMA9 publica un post-mortem redactado con criterio para todo incidente SEV-1 y SEV-2 en soma9.cloud/security/incidents/<fecha>-<slug>. El post-mortem incluye:

• Una línea temporal factual (qué sucedió y cuándo).
• La causa raíz técnica.
• El alcance del impacto (a quién y a qué afectó).
• Las acciones de remediación adoptadas durante el incidente.
• Las acciones de ingeniería de seguimiento comprometidas, con fechas objetivo.
• Cuando proceda, la cronología de notificaciones a regulador y a Clientes.

El post-mortem se redacta en lenguaje claro. No asigna culpas individuales: se centra en fallos sistémicos y mejoras (cultura de post-mortem sin culpa).

10. Objetivos de nivel de servicio

Los siguientes son objetivos internos de nivel de servicio (no SLA contractuales, regulados por separado en el SLA de SOMA9 cuando corresponda). Establecen las expectativas operativas frente a las que SOMA9 se mide a sí misma.

11. Forense y custodia de pruebas

En incidentes SEV-1 y SEV-2, SOMA9 preserva las pruebas forenses (volcados de memoria, imágenes de disco de las cuentas afectadas, registros con marca temporal acotada) antes de cualquier remediación destructiva. Las pruebas se almacenan cifradas, con control de accesos, y se conservan al menos un año salvo instrucción en contrario de la asesoría legal. La cadena de custodia se documenta cuando las pruebas se compartan con autoridades policiales o de control.

12. Simulacros y revisión

SOMA9 realiza al menos anualmente un simulacro de mesa que reproduce un incidente SEV-1. El ejercicio cubre la rotación de roles, la autoridad para decidir, la comunicación al Cliente, la notificación a regulador y la declaración de recuperación. Las conclusiones se registran y alimentan la revisión anual de la presente Política. La Política se revisa y vuelve a aprobarse al menos anualmente y tras cada incidente SEV-1.

13. Cómo reportarnos un incidente

Si observa un incidente de seguridad que afecte a SOMA9 o a un sitio alojado por SOMA9, repórtelo por uno de los siguientes canales, en orden de prioridad:

1. Crítico / explotación activa: correo a security@soma9.cloud con asunto [CRITICAL]. Clave PGP en soma9.cloud/.well-known/security.txt.
2. Vulnerabilidad sin explotación activa: seguir la Política de Divulgación de Vulnerabilidades.
3. Abuso, spam, escaneo: correo a abuse@soma9.cloud.
4. Retirada por derechos de autor: seguir la Política DMCA.

Los reportes son leídos por personas en horario laboral; los reportes SEV-1 generan aviso 24x7.

Revisión legal y operativa pendiente

Antes de su publicación, la presente Política debe contrastarse con: (a) la rota real de guardia y árbol de escalado (la Política pública debe reflejar lo realmente cubierto); (b) el SLA del Cliente en el Contrato Marco — los SLO de la cláusula 10 son objetivos operativos y deben distinguirse de cualesquiera penalizaciones contractuales del SLA; (c) evaluación de aplicabilidad de NIS2 para la entidad prestadora de los Servicios en cada Estado miembro; (d) URL de la página de estado y lista de correo de notificaciones (deben existir antes de que la Política las prometa); (e) convención de URL de publicación de post-mortems en la cláusula 9.