Política de Respuesta a Incidentes

Última actualización: May 22, 2026

POLÍTICA DE RESPUESTA A INCIDENTES DE DATACRED

Versión del Documento: 1.0

Fecha de Vigencia: 22 de mayo de 2026

Clasificación: INTERNO - CONFIDENCIAL

Ciclo de Revisión: Semestral

Propietario: Director de Seguridad de la Información (CISO)

1. [PROPÓSITO Y ALCANCE](#1-propósito-y-alcance)

2. [DEFINICIÓN Y CLASIFICACIÓN DE INCIDENTES DE SEGURIDAD](#2-definición-y-clasificación-de-incidentes-de-seguridad)

3. [EQUIPO DE RESPUESTA A INCIDENTES](#3-equipo-de-respuesta-a-incidentes)

4. [MECANISMOS DE DETECCIÓN DE INCIDENTES](#4-mecanismos-de-detección-de-incidentes)

5. [FASES DE RESPUESTA A INCIDENTES](#5-fases-de-respuesta-a-incidentes)

6. [PROCEDIMIENTOS ESPECÍFICOS PARA VIOLACIONES DE DATOS](#6-procedimientos-específicos-para-violaciones-de-datos)

7. [OBLIGACIONES DE NOTIFICACIÓN](#7-obligaciones-de-notificación)

8. [EXCEPCIONES A LA NOTIFICACIÓN](#8-excepciones-a-la-notificación)

9. [DOCUMENTACIÓN Y REGISTRO DE INCIDENTES](#9-documentación-y-registro-de-incidentes)

10. [PRUEBAS DE RESPUESTA A INCIDENTES](#10-pruebas-de-respuesta-a-incidentes)

11. [COORDINACIÓN DE INCIDENTES CON TERCEROS](#11-coordinación-de-incidentes-con-terceros)

12. [OBLIGACIONES DEL USUARIO](#12-obligaciones-del-usuario)

13. [EXENCIONES DE RESPONSABILIDAD Y LIMITACIONES](#13-exenciones-de-responsabilidad-y-limitaciones)

14. [MANTENIMIENTO Y MODIFICACIÓN DE LA POLÍTICA](#14-mantenimiento-y-modificación-de-la-política)

15. [DECLARACIÓN DE CUMPLIMIENTO VOLUNTARIO NORMATIVO](#15-declaración-de-cumplimiento-voluntario-normativo)

16. [INFORMACIÓN DE CONTACTO](#16-información-de-contacto)

DataCred ("DataCred," "nosotros," "nos," "nuestro") es una plataforma venezolana de puntuación de reputación conductual financiera nativa en IA que opera bajo una estructura legal de Wyoming, Estados Unidos. DataCred NO es un banco, prestamista, institución financiera regulada ni empresa de servicios monetarios. La presente Política de Respuesta a Incidentes (la "Política") establece el marco integral que rige la preparación, detección, respuesta y recuperación de DataCred ante incidentes de seguridad que afecten sus sistemas de información, datos, infraestructura y operaciones.

DataCred es una plataforma privada e independiente de información y reputación financiera. No es el buró ni el registro oficial del Estado, no está autorizada, certificada ni respaldada por la Superintendencia de las Instituciones del Sector Bancario (SUDEBAN), el Banco Central de Venezuela (BCV), el Sistema de Información Central de Riesgos (SICRI) ni ningún otro organismo del gobierno, y no está conectada a ellos. Los puntajes y la información que DataCred ofrece son estimaciones para apoyar decisiones; no constituyen decisiones oficiales ni garantías.

El propósito de esta Política es:

1.1.1 Definir el marco de respuesta a incidentes, incluyendo preparación, detección, análisis, contención, erradicación, recuperación y revisión posterior al incidente;

1.1.2 Establecer roles, responsabilidades y rutas de escalamiento claras para la respuesta a incidentes;

1.1.3 Asegurar una respuesta oportuna y efectiva ante incidentes de seguridad para minimizar el daño a DataCred, sus usuarios, socios y partes interesadas;

1.1.4 Proveer procedimientos para la determinación de violaciones de datos, evaluación de riesgos y obligaciones de notificación;

1.1.5 Establecer requisitos de documentación y registro para incidentes;

1.1.6 Asegurar el cumplimiento de los requisitos legales, normativos y contractuales aplicables en materia de notificación;

1.1.7 Permitir la mejora continua de los controles de seguridad a través de las lecciones aprendidas.

Esta Política aplica a:

1.2.1 Todo el Personal: Todos los empleados, contratistas, consultores, pasantes, personal temporal y cualquier individuo con acceso a los sistemas o datos de DataCred (colectivamente, el "Personal") que está obligado a reportar incidentes de seguridad sospechados.

1.2.2 Todos los Sistemas: Todos los sistemas de información, redes, servidores, dispositivos finales, entornos en la nube, aplicaciones, bases de datos y dispositivos propiedad de, operados o arrendados por DataCred.

1.2.3 Todos los Datos: Todos los datos procesados, almacenados, transmitidos o accedidos por DataCred, incluyendo pero no limitado a datos de usuarios, puntuaciones de reputación conductual, datos conductuales financieros, información de identificación personal (PII), credenciales de autenticación, datos comerciales, propiedad intelectual y datos operativos.

1.2.4 Todas las Ubicaciones: Todas las ubicaciones físicas donde DataCred opera o mantiene instalaciones.

1.2.5 Todas las Relaciones con Terceros: Todos los proveedores, prestadores de servicios, socios y contratistas cuyos sistemas o servicios están integrados con DataCred o que tienen acceso a datos de DataCred.

1.2.6 Todos los Tipos de Incidentes: Todos los incidentes de seguridad que afecten a DataCred, ya sean causados por atacantes externos, amenazas internas, error humano, falla del sistema, desastre natural o falla de un tercero.

ESTA POLÍTICA NO ES UN CONTRATO Y NO CREA DERECHOS U OBLIGACIONES CONTRACTUALES. DATACRED PUEDE MODIFICAR ESTA POLÍTICA EN CUALQUIER MOMENTO SIN PREVIO AVISO, SUJETO A LO DISPUESTO EN LA SECCIÓN 14.

Un "Incidente de Seguridad" es cualquier evento que:

2.1.1 Comprometa real o potencialmente la confidencialidad, integridad o disponibilidad de los sistemas de información o datos de DataCred;

2.1.2 Constituya una violación de las políticas de seguridad o políticas de uso aceptable de DataCred;

2.1.3 Represente un intento o acceso no autorizado exitoso, uso, divulgación, modificación o destrucción de sistemas de información o datos;

2.1.4 Represente una violación de leyes, regulaciones u obligaciones contractuales aplicables relacionadas con la seguridad de la información;

2.1.5 De otro modo represente una amenaza a la postura de seguridad de DataCred.

Un incidente de seguridad puede ser causado por una acción maliciosa intencional, una acción accidental, una falla del sistema, un desastre natural u otros eventos.

DataCred clasifica los incidentes de seguridad en cinco niveles de gravedad. La clasificación se basa en el impacto real o potencial para DataCred, sus usuarios, socios y partes interesadas. La clasificación de gravedad es dinámica y puede ser elevada o reducida a medida que se disponga de información adicional.

#### 2.2.1 NIVEL 1 - CRÍTICO

Definición: Un incidente que representa una amenaza inmediata y grave para las operaciones de DataCred, sistemas críticos o datos sensibles. Requiere respuesta inmediata, escalamiento a la dirección ejecutiva y puede requerir notificación externa.

SLA de Respuesta: Notificación inmediata; respuesta inicial en 15 minutos; movilización del equipo de respuesta 24/7.

Criterios Detallados (uno o más de los siguientes):

  • Acceso no autorizado confirmado o exfiltración de datos RESTRINGIDOS (según se definen en la Política de Seguridad);
  • Ataque activo de ransomware o extorsión que afecte sistemas de producción;
  • Compromiso de cuentas administrativas privilegiadas (CISO, administradores de sistemas, cuentas raíz de proveedores en la nube);
  • Interrupción generalizada del servicio que afecte a la totalidad o una parte sustancial de los usuarios;
  • Explotación activa de una vulnerabilidad crítica (CVSS 9.0-10.0) en sistemas de producción;
  • Evidencia de compromiso por parte de un actor estatal;
  • Compromiso de claves de cifrado o autoridades certificadoras;
  • Ataque activo de denegación de servicio que cause degradación o interrupción del servicio;
  • Violación de seguridad física del centro de datos principal;
  • Cualquier incidente que requiera notificación obligatoria a las autoridades regulatorias.

Ejemplos:

  • Violación de datos confirmada que involucre PII, credenciales de autenticación o puntuaciones de reputación conductual;
  • Cifrado por ransomware de bases de datos de producción;
  • Compromiso de la cuenta raíz de Google Cloud/GCP o secretos del pipeline CI/CD;
  • Interrupción prolongada del servicio que exceda 4 horas;
  • Explotación de una vulnerabilidad de día cero en un sistema crítico.

Notificación:

  • CISO: Inmediata
  • CEO: Dentro de 30 minutos
  • Junta Directiva: Dentro de 4 horas
  • Asesor Legal: Dentro de 1 hora
  • Autoridades Regulatorias: Según la ley aplicable (72 horas para GDPR)
  • Usuarios Afectados: Sin demora injustificada después de la confirmación

#### 2.2.2 NIVEL 2 - ALTO

Definición: Un incidente que representa una amenaza significativa para DataCred, sus datos o sus usuarios, pero que está contenido o tiene un impacto limitado. Requiere respuesta pronta y escalamiento al liderazgo apropiado.

SLA de Respuesta: Respuesta inicial en 1 hora durante horas hábiles; respuesta inicial en 2 horas fuera del horario laboral.

Criterios Detallados (uno o más de los siguientes):

  • Acceso no autorizado confirmado a datos CONFIDENCIALES (según se definen en la Política de Seguridad) que NO incluya datos RESTRINGIDOS;
  • Ransomware o malware detectado en el entorno de producción pero contenido antes de causar impacto;
  • Compromiso de cuentas de usuario no privilegiadas, incluyendo múltiples cuentas;
  • Interrupción del servicio que afecte a un subconjunto de usuarios (10-50% de la base de usuarios);
  • Ataque de phishing exitoso que resulte en compromiso de credenciales;
  • Explotación de vulnerabilidad en un sistema de producción no crítico;
  • Cambio de configuración no autorizado en un sistema de producción;
  • Pérdida o robo de un dispositivo no cifrado que contenga datos CONFIDENCIALES.

Ejemplos:

  • Campaña de phishing dirigida que resulte en 5 o más cuentas comprometidas;
  • Infección de malware en un servidor de pruebas (no en producción);
  • Ataque exitoso de inyección SQL en una aplicación no crítica;
  • Acceso no autorizado a documentación interna que contenga planes comerciales.

Notificación:

  • CISO: Dentro de 2 horas
  • CTO: Dentro de 4 horas
  • Asesor Legal: Dentro de 4 horas
  • Usuarios Afectados: Según lo determine la investigación

#### 2.2.3 NIVEL 3 - MEDIO

Definición: Un incidente que representa una amenaza moderada y requiere investigación, pero no requiere escalamiento inmediato a la dirección ejecutiva. Puede representar un incidente potencial que requiere confirmación.

SLA de Respuesta: Respuesta inicial en 4 horas durante horas hábiles; respuesta inicial al siguiente día hábil para incidentes fuera del horario laboral.

Criterios Detallados (uno o más de los siguientes):

  • Violación de datos sospechada pero no confirmada que requiera investigación forense;
  • Campaña de phishing reportada por múltiples usuarios sin compromiso confirmado;
  • Intento de acceso no autorizado detectado pero bloqueado (sin éxito confirmado);
  • Vulnerabilidad descubierta en un sistema no crítico (CVSS 7.0-8.9);
  • Violación de política por parte del Personal que podría afectar la seguridad;
  • Pérdida o robo de un dispositivo cifrado que contenga datos CONFIDENCIALES (cifrado del dispositivo verificado);
  • Compromiso de una sola cuenta en una cuenta no privilegiada;
  • Ataque DDoS que fue mitigado exitosamente sin impacto en el servicio.

Ejemplos:

  • Usuario reporta correo electrónico de restablecimiento de contraseña inesperado;
  • Alertas IDS/IPS que indiquen actividad de reconocimiento;
  • Portátil perdido con cifrado de disco completo (verificable);
  • Empleado accediendo a datos sin autorización (reportado);
  • Intento de ingeniería social reportado por recepción.

Notificación:

  • Líder del Equipo de Seguridad: Dentro de 4 horas
  • CISO: Dentro de 8 horas (resumen)
  • Asesor Legal: Si se sospecha violación de datos personales

#### 2.2.4 NIVEL 4 - BAJO

Definición: Un incidente con impacto potencial mínimo que requiere documentación, monitoreo y posiblemente remediación menor. No requiere escalamiento más allá del equipo de seguridad.

SLA de Respuesta: Respuesta inicial al siguiente día hábil.

Criterios Detallados (uno o más de los siguientes):

  • Un solo usuario reporta actividad sospechosa sin evidencia de compromiso;
  • Vulnerabilidad de baja gravedad (CVSS 4.0-6.9) en un sistema que no es de producción;
  • Violación menor de política sin evidencia de intención maliciosa;
  • Escaneo de puertos o actividad de reconocimiento detectada (bloqueada);
  • Spam o phishing reportado por un solo usuario (sin indicadores de compromiso);
  • Intento de ataque de fuerza bruta bloqueado por limitación de tasa;
  • Alerta de falso positivo que requiere documentación.

Ejemplos:

  • Usuario hizo clic en un enlace de simulación de phishing (oportunidad de capacitación);
  • Escáner de vulnerabilidades descubre un hallazgo de baja gravedad;
  • Empleado dejó la estación de trabajo desbloqueada (sin datos accedidos);
  • Dirección IP externa escanea endpoints públicos.

Notificación:

  • Equipo de Seguridad: Siguiente día hábil
  • No se requiere escalamiento a menos que el incidente escale

#### 2.2.5 NIVEL 5 - INFORMATIVO

Definición: Eventos que no son incidentes de seguridad pero son relevantes para la concienciación de seguridad, monitoreo o inteligencia de amenazas. Requiere documentación pero no respuesta activa.

SLA de Respuesta: Documentado dentro de 5 días hábiles.

Criterios Detallados (uno o más de los siguientes):

  • Alerta de seguridad de falso positivo confirmada;
  • Resultados de pruebas de seguridad rutinarias (programadas);
  • Indicadores de inteligencia de amenazas sin relevancia actual para DataCred;
  • Consultas de concienciación de seguridad del Personal;
  • Actividades de mantenimiento o pruebas programadas que generen eventos relevantes para la seguridad;
  • Cambios de configuración que afecten el monitoreo pero no la postura de seguridad.

Ejemplos:

  • El equipo de seguridad recibe un informe de inteligencia de amenazas sobre una vulnerabilidad en una tecnología que DataCred no utiliza;
  • La prueba de penetración programada genera alertas (documentadas y correlacionadas);
  • Empleado pregunta al equipo de seguridad sobre un correo de phishing que recibió (no hizo clic).

Notificación:

  • Solo documentación del equipo de seguridad

La clasificación inicial de gravedad es realizada por el primer respondedor (analista SOC, ingeniero de guardia o Personal que reporta). La clasificación puede ser cambiada en cualquier momento por el Líder de Respuesta a Incidentes o el CISO en función de nueva información. La clasificación final con fines de documentación se determina durante la revisión posterior al incidente.

El Equipo de Respuesta a Incidentes (ERT) está compuesto por los siguientes roles. No todos los roles son necesarios para cada incidente; el Líder de Respuesta a Incidentes determina qué roles se activan según la gravedad y el tipo de incidente.

#### 3.1.1 Líder de Respuesta a Incidentes (Líder del ERI)

El Líder del ERI es el coordinador general del esfuerzo de respuesta a incidentes. Este rol es típicamente ocupado por el CISO o un miembro senior designado del equipo de seguridad.

Responsabilidades:

  • Coordinación y dirección general del ERI;
  • Clasificación y reclasificación de la gravedad del incidente;
  • Activación de recursos adicionales del ERI según sea necesario;
  • Comunicación con la dirección ejecutiva y la Junta Directiva;
  • Comunicación con el asesor legal;
  • Comunicación con partes externas (reguladores, autoridades, socios);
  • Toma de decisiones sobre estrategias de contención, erradicación y recuperación;
  • Aprobación de comunicaciones y notificaciones externas;
  • Facilitación de la revisión posterior al incidente.

Principal: CISO

Alterno: Gerente Senior de Seguridad

#### 3.1.2 Coordinador de Respuesta a Incidentes

El Coordinador del ERI apoya al Líder del ERI en la coordinación operativa.

Responsabilidades:

  • Programación y facilitación de reuniones y llamadas del ERI;
  • Mantenimiento de la cronología y documentación del incidente;
  • Seguimiento de elementos de acción y tareas de remediación;
  • Gestión de los canales de comunicación del incidente;
  • Coordinación con departamentos ajenos al ERI (RRHH, RP, Legal);
  • Gestión de la documentación del incidente y registros de evidencia.

Principal: Gerente de Operaciones de Seguridad

Alterno: Ingeniero de Seguridad

#### 3.1.3 Líder Técnico

El Líder Técnico dirige la investigación técnica y los esfuerzos de remediación.

Responsabilidades:

  • Dirección de la investigación técnica;
  • Coordinación del análisis forense;
  • Implementación de la estrategia de contención;
  • Implementación de la erradicación y recuperación;
  • Análisis de causa raíz;
  • Documentación técnica;
  • Coordinación con los equipos de ingeniería y operaciones.

Principal: Ingeniero Senior de Seguridad

Alterno: Ingeniero DevOps Principal

#### 3.1.4 Analista Forense

El Analista Forense realiza el análisis forense de los sistemas y datos afectados.

Responsabilidades:

  • Adquisición y preservación de evidencia forense;
  • Documentación de la cadena de custodia;
  • Forense de disco, memoria y redes;
  • Análisis de malware;
  • Análisis de cronología;
  • Apoyo en la determinación de la causa raíz;
  • Manejo y almacenamiento de evidencia.

Principal: Ingeniero de Seguridad (Forense)

Alterno: Consultor Forense Externo

#### 3.1.5 Líder de Comunicaciones

El Líder de Comunicaciones gestiona todas las comunicaciones externas e internas relacionadas con el incidente.

Responsabilidades:

  • Redacción de comunicaciones internas al Personal;
  • Redacción de comunicaciones externas a usuarios, socios y partes interesadas;
  • Coordinación con el equipo de RP/comunicaciones;
  • Gestión de comunicaciones a través de canales aprobados;
  • Asegurar el cumplimiento de los plazos de notificación regulatoria;
  • Seguimiento de comunicaciones para verificar su integridad.

Principal: Director de Comunicaciones

Alterno: CMO o designado

#### 3.1.6 Asesor Legal

El Asesor Legal proporciona orientación legal durante todo el proceso de respuesta a incidentes.

Responsabilidades:

  • Asesoría legal sobre acciones de respuesta a incidentes;
  • Gestión de privilegios e implementación de retención legal;
  • Evaluación de obligaciones de notificación regulatoria;
  • Coordinación con autoridades;
  • Evaluación de obligaciones de notificación contractual;
  • Revisión de comunicaciones por exposición legal;
  • Evaluación de riesgo legal posterior al incidente.

Principal: Consejero General o asesor externo

Alterno: Subconsejero General

#### 3.1.7 Líder de Ingeniería/Operaciones

El Líder de Ingeniería/Operaciones dirige la remediación técnica desde el lado de ingeniería.

Responsabilidades:

  • Implementación de medidas de contención;
  • Restauración y recuperación de sistemas;
  • Parches y remediación de vulnerabilidades;
  • Cambios en la infraestructura para prevenir recurrencia;
  • Coordinación con proveedores en la nube y vendedores;
  • Verificación técnica de la recuperación.

Principal: VP de Ingeniería o CTO

Alterno: Gerente Senior de Ingeniería

#### 3.1.8 Líder de RRHH (si hay involucramiento de empleados)

El Líder de RRHH maneja los asuntos de personal relacionados con el incidente si se sospecha la participación de un empleado.

Responsabilidades:

  • Coordinación de la investigación de personal;
  • Relaciones con empleados y procesos disciplinarios;
  • Coordinación con el asesor legal en asuntos laborales;
  • Comunicaciones con empleados sobre su participación en el incidente.

Principal: Director de RRHH

Alterno: Gerente Senior de RRHH

#### 3.1.9 Representantes de Unidades de Negocio

Los representantes de las unidades de negocio proporcionan contexto comercial y evaluación de impacto.

Responsabilidades:

  • Evaluación del impacto comercial;
  • Evaluación del impacto al usuario;
  • Coordinación de continuidad del negocio;
  • Apoyo en comunicación con clientes;
  • Priorización de necesidades comerciales durante la recuperación.

Principal: Designado por el Líder del ERI por incidente

Alterno: Designado por el Líder del ERI por incidente

DataCred puede contratar recursos externos para apoyar la respuesta a incidentes:

  • Consultores Forenses Externos: Firmas especializadas en investigación forense para incidentes complejos;
  • Retenedores de Respuesta a Incidentes: Servicios de retención de respuesta a incidentes prenegociados con firmas de respuesta a incidentes;
  • Asesor Legal: Asesores legales especializados en privacidad y ciberseguridad;
  • RP/Comunicaciones de Crisis: Firmas externas de comunicaciones de crisis para incidentes de alto impacto;
  • Seguro Cibernético: Recursos de respuesta a incidentes del asegurador cibernético;
  • Inteligencia de Amenazas: Fuentes y servicios de análisis de inteligencia de amenazas externos;
  • Equipos de ERI del Proveedor en la Nube: Equipos de respuesta a incidentes del proveedor en la nube para incidentes a nivel de infraestructura.

#### 3.3.1 Escalamiento Interno

Nivel 1 - SOC/Ingeniero de Guardia:

  • Triaje y respuesta inicial;
  • Clasificación del incidente;
  • Escalamiento al Nivel 2 si la gravedad del incidente es Nivel 2 o superior.

Nivel 2 - Equipo de Seguridad:

  • Investigación y respuesta completa para incidentes de Nivel 2-3;
  • Escalamiento al Nivel 3 si el incidente es Nivel 1 o requiere decisión ejecutiva.

Nivel 3 - CISO/Dirección Ejecutiva:

  • Dirección estratégica para incidentes de Nivel 1;
  • Decisiones de asignación de recursos;
  • Aprobaciones de comunicaciones externas.

Nivel 4 - Junta Directiva:

  • Notificación de incidentes materiales;
  • Supervisión de actividades de respuesta significativas.

#### 3.3.2 Escalamiento Externo

  • Asesor Legal: Contratado para incidentes de Nivel 1-2 y cualquier incidente que involucre notificación regulatoria;
  • Autoridades: Contactadas cuando se sospecha actividad delictiva (FBI, CISA, Servicio Secreto, autoridades locales);
  • Autoridades Regulatorias: Notificadas de conformidad con la ley aplicable;
  • Seguro Cibernético: Notificado de conformidad con los términos de la póliza;
  • Forense Externo: Contratado para incidentes complejos o cuando las capacidades internas son insuficientes.

Durante la respuesta a incidentes, el ERI utiliza los siguientes canales de comunicación:

  • Canal Principal: Canal de chat dedicado para respuesta a incidentes (Slack, Teams o equivalente con seguridad y retención apropiadas);
  • Puente de Voz: Puente de conferencia para llamadas de coordinación del ERI;
  • Comunicación Segura: Comunicación cifrada para detalles sensibles del incidente;
  • Comunicación Externa: Plataformas de correo electrónico y comunicación aprobadas para notificaciones externas;
  • Actualizaciones de Estado: Actualizaciones periódicas de estado a las partes interesadas a través de canales aprobados.

IMPORTANTE: Las comunicaciones relacionadas con incidentes deben tratarse como confidenciales y sujetas a privilegio cuando corresponda. Las comunicaciones con el asesor legal deben marcarse claramente como sujetas al privilegio abogado-cliente.

Los incidentes de seguridad pueden detectarse a través de los siguientes sistemas de monitoreo automatizado:

  • SIEM: Reglas de correlación y alertas del sistema de Gestión de Información y Eventos de Seguridad;
  • EDR: Alertas del sistema de Detección y Respuesta de Endpoints para actividad maliciosa;
  • IDS/IPS: Alertas del sistema de Detección y Prevención de Intrusiones de Red;
  • WAF: Alertas del Cortafuegos de Aplicaciones Web para ataques a nivel de aplicación;
  • DLP: Alertas del sistema de Prevención de Pérdida de Datos para transferencias de datos no autorizadas;
  • FIM: Alertas de Monitoreo de Integridad de Archivos para cambios no autorizados en archivos;
  • Monitoreo de Seguridad en la Nube: Monitoreo de seguridad del proveedor en la nube (GuardDuty, Security Command Center, etc.);
  • Escáner de Vulnerabilidades: Alertas de escaneo de vulnerabilidades para nuevas vulnerabilidades;
  • UBA/UEBA: Alertas de Análisis de Comportamiento de Usuarios y Entidades para comportamiento anómalo;
  • Monitoreo de Disponibilidad: Alertas de monitoreo de disponibilidad de sistemas y servicios;
  • Fuentes de Inteligencia de Amenazas: Ingestión y correlación automatizada de inteligencia de amenazas.

Los incidentes de seguridad pueden ser reportados por:

  • Personal: Cualquier miembro del Personal de DataCred que sospeche un incidente de seguridad debe reportarlo inmediatamente a través de los canales de reporte establecidos;
  • Usuarios: Los usuarios de las plataformas de DataCred pueden reportar actividad sospechosa a través de los canales de soporte;
  • Socios/Proveedores: Los socios y proveedores pueden reportar incidentes de seguridad que afecten los sistemas o datos de DataCred.

Los socios y proveedores con acceso a sistemas o datos de DataCred están contractualmente obligados a notificar a DataCred sobre incidentes de seguridad que puedan afectar a DataCred dentro de los plazos definidos (típicamente 24-72 horas después de la confirmación).

DataCred puede recibir notificaciones de incidentes de seguridad de las autoridades. Dichas notificaciones se escalan inmediatamente al CISO y al Asesor Legal.

Los incidentes de seguridad pueden ser identificados proactivamente a través de:

  • Fuentes de Inteligencia de Amenazas: Inteligencia de amenazas comercial y de código abierto;
  • Intercambio de Información: Asociaciones de intercambio de información (ISAC, ISAO, grupos de la industria);
  • Investigación de Seguridad: Investigación proactiva de seguridad en comunidades relevantes de actores de amenazas;
  • Monitoreo de la Dark Web: Monitoreo de fuentes de la dark web en busca de datos relacionados con DataCred;
  • Monitoreo de Credenciales: Monitoreo de credenciales de DataCred que aparezcan en bases de datos de violaciones.

DataCred sigue un modelo de respuesta a incidentes de siete fases: Preparación, Detección, Análisis, Contención, Erradicación, Recuperación y Revisión Posterior al Incidente. Estas fases pueden superponerse o iterarse a medida que avanza la respuesta al incidente.

Objetivo: Asegurar que los sistemas, procesos y el personal estén listos para responder a incidentes de seguridad antes de que ocurran.

Actividades:

5.1.1 Mantener y probar las capacidades de respuesta a incidentes, incluyendo:

  • Plan y procedimientos de respuesta a incidentes;
  • Herramientas de respuesta a incidentes y capacidades forenses;
  • Canales de comunicación y listas de contacto;
  • Rutas de escalamiento y matriz de autoridad;
  • Servicios de retención de respuesta a incidentes.

5.1.2 Realizar capacitaciones y ejercicios regulares de respuesta a incidentes (ver Sección 10).

5.1.3 Establecer y mantener relaciones con recursos externos:

  • Consultores forenses;
  • Asesor legal;
  • Contactos en autoridades;
  • Aseguradora cibernética.

5.1.4 Preparar el kit de herramientas de respuesta a incidentes:

  • Hardware y software de imagen forense;
  • Almacenamiento seguro de evidencia;
  • Plantillas de comunicación preaprobadas;
  • Plantillas de documentación de incidentes.

Objetivo: Identificar y reportar rápidamente posibles incidentes de seguridad a través de todos los mecanismos de detección disponibles.

Actividades:

5.2.1 Monitorear sistemas de seguridad y alertas de forma continua (SOC 24/7 para sistemas críticos).

5.2.2 Recibir y triar reportes de incidentes de:

  • Sistemas de monitoreo automatizado;
  • Reportes del Personal;
  • Reportes de usuarios;
  • Notificaciones de socios/proveedores;
  • Notificaciones de autoridades;
  • Inteligencia de amenazas.

5.2.3 Todo el Personal debe reportar incidentes de seguridad sospechados inmediatamente a través de los siguientes canales:

  • Emergencia (24/7): Contactar al ingeniero de seguridad de guardia a través del número de contacto de emergencia (proporcionado al Personal autorizado);
  • No Emergencia: [email protected];
  • Anónimo: Canal interno de denuncias.

5.2.4 El primer respondedor (analista SOC o ingeniero de guardia) realiza el triaje inicial:

  • Determinar si el evento es un incidente de seguridad sospechado;
  • Asignar clasificación inicial de gravedad;
  • Documentar hallazgos iniciales;
  • Escalar según la gravedad.

5.2.5 Crear registro del incidente en el sistema de seguimiento de incidentes con:

  • Identificador único del incidente;
  • Fecha y hora de detección;
  • Fuente de detección;
  • Breve descripción del evento;
  • Clasificación inicial de gravedad;
  • Nombre del primer respondedor;
  • Sistemas, datos y usuarios afectados (si se conocen).

Objetivo: Evaluar la gravedad, el alcance y el impacto del incidente para determinar el nivel de respuesta apropiado.

Actividades:

5.3.1 El Líder del ERI (o su designado) realiza la evaluación inicial:

  • Revisar la información del triaje inicial;
  • Confirmar o revisar la clasificación de gravedad;
  • Determinar si se activa el ERI completo;
  • Asignar tareas de investigación inicial.

5.3.2 Recopilar información inicial:

  • ¿Qué sucedió? (tipo de incidente);
  • ¿Cuándo sucedió? (cronología);
  • ¿Dónde sucedió? (sistemas, redes, ubicaciones afectados);
  • ¿Quién está afectado? (usuarios, titulares de datos, clientes);
  • ¿Cómo sucedió? (vector de ataque, causa raíz si se conoce);
  • ¿Cuál es el impacto? (datos, operaciones, reputación, legal);
  • ¿El incidente está en curso? (activo o contenido).

5.3.3 Determinar los desencadenantes de la investigación:

  • ¿Hay evidencia de exfiltración de datos?
  • ¿Hay evidencia de escalamiento de privilegios?
  • ¿Hay evidencia de movimiento lateral?
  • ¿Hay indicios de mecanismos de persistencia?
  • ¿Existen obligaciones de notificación legal o regulatoria?

5.3.4 Activar recursos adicionales según sea necesario según la gravedad:

  • Nivel 1: Activación completa del ERI, recursos externos según sea necesario;
  • Nivel 2: Activación del ERI central, recursos externos selectos;
  • Nivel 3: Investigación del equipo de seguridad, recursos externos limitados si es necesario;
  • Nivel 4: Documentación y monitoreo del equipo de seguridad;
  • Nivel 5: Solo documentación.

5.3.5 Establecer estructura de comando del incidente y canales de comunicación:

  • Programar llamadas periódicas de estado del ERI (frecuencia basada en la gravedad);
  • Establecer canales de comunicación seguros;
  • Informar a la dirección ejecutiva según corresponda.

Objetivo: Detener el incidente para evitar daños mayores y prevenir su expansión.

Actividades:

#### 5.4.1 Contención a Corto Plazo

Acciones inmediatas para detener amenazas activas:

  • Contención de Red: Aislar los sistemas afectados de la red (desconectar cables de red, deshabilitar interfaces de red, actualizar reglas de cortafuegos);
  • Contención de Cuentas: Deshabilitar cuentas comprometidas, restablecer credenciales, revocar sesiones/tokens;
  • Contención de Procesos: Terminar procesos maliciosos, bloquear la ejecución de binarios maliciosos;
  • Contención de Servicios: Poner fuera de línea los servicios afectados, redirigir tráfico, activar modo de mantenimiento;
  • Contención en la Nube: Aplicar cambios en grupos de seguridad, deshabilitar claves IAM, crear instantáneas de instancias afectadas;
  • Contención de Endpoints: Aislar endpoints a través de EDR, desconectar de la red.

Las acciones de contención a corto plazo deben documentarse con marca de tiempo y autorización.

#### 5.4.2 Contención a Largo Plazo

Medidas para mantener la contención mientras continúan la investigación y la remediación:

  • Imagen Forense: Crear imágenes forenses de los sistemas afectados antes de cualquier remediación (cuando sea factible);
  • Segmentación de Red: Implementar segmentación de red adicional para restringir los sistemas afectados;
  • Restricciones de Acceso: Implementar controles de acceso adicionales o aplicación temporal de MFA;
  • Filtrado de Tráfico: Implementar reglas WAF temporales, bloques de IP o limitación de tasa;
  • Restauración de Copias de Seguridad: Restaurar sistemas afectados a partir de copias de seguridad limpias (si se determina que es seguro);
  • Reconstrucción del Sistema: Reconstruir sistemas afectados a partir de configuraciones conocidas como seguras.

#### 5.4.3 Marco de Decisión de Contención

Todas las decisiones de contención equilibran los siguientes factores:

  • Riesgo de Operación Continua: ¿Cuánto daño ocurrirá si la contención se retrasa?
  • Impacto Comercial: ¿Cuál es el impacto operativo de las acciones de contención?
  • Valor Forense: ¿Las acciones de contención destruirán evidencia?
  • Consideraciones Legales: ¿Existen obligaciones de retención legal o preservación?
  • Impacto al Usuario: ¿Cuál es el impacto en los usuarios y titulares de datos?

Las decisiones de contención en Nivel 1-2 son tomadas por el Líder del ERI en consulta con el CTO y el Asesor Legal. Las decisiones se documentan con su fundamento.

Objetivo: Realizar una investigación forense exhaustiva para determinar la causa, el alcance y el impacto del incidente.

Actividades:

#### 5.5.1 Preservación de Evidencia

  • Identificar y preservar todas las fuentes de evidencia relevantes:
  • Registros del sistema (SO, aplicación, seguridad, autenticación, auditoría);
  • Registros de red (cortafuegos, IDS/IPS, proxy, DNS, DHCP);
  • Registros en la nube (CloudTrail, registros de auditoría, registros de acceso);
  • Datos de endpoint (volcado de memoria, imagen de disco, telemetría EDR);
  • Datos de aplicación (registros de base de datos, registros de API, registros de errores);
  • Registros de comunicación (correo electrónico, chat, herramientas de colaboración);
  • Establecer cadena de custodia para toda la evidencia:
  • Documentar quién recopiló la evidencia, cuándo y cómo;
  • Documentar quién ha accedido a la evidencia y cuándo;
  • Almacenar la evidencia en un entorno seguro y con control de acceso;
  • Usar hashes criptográficos (SHA-256) para verificar la integridad de la evidencia;
  • Mantener la evidencia en su forma original cuando sea posible.

#### 5.5.2 Análisis Forense

  • Análisis del Sistema: Análisis de cronología, análisis del sistema de archivos, análisis del registro, análisis de artefactos;
  • Análisis de Memoria: Análisis de procesos, conexiones de red, archivos abiertos, código inyectado;
  • Análisis de Red: Análisis de captura de paquetes, análisis de conexiones, análisis de protocolos;
  • Análisis de Malware: Análisis estático, análisis dinámico, ingeniería inversa;
  • Análisis de Registros: Correlación de registros entre sistemas, reconstrucción de cronología;
  • Análisis en la Nube: Revisión de registros del proveedor en la nube, actividad IAM, cambios en recursos;
  • Análisis de Base de Datos: Análisis de consultas, patrones de acceso a datos, revisión de modificaciones de datos.

#### 5.5.3 Análisis de Causa Raíz

Determinar la causa raíz del incidente:

  • Vector de Ataque: ¿Cómo obtuvo el atacante el acceso inicial? (phishing, explotación de vulnerabilidad, robo de credenciales, acceso físico, etc.);
  • Ruta de Ataque: ¿Cuál fue la ruta completa del ataque? (acceso inicial, persistencia, escalamiento de privilegios, movimiento lateral, acceso a datos, exfiltración);
  • Vulnerabilidad: ¿Qué vulnerabilidad o debilidad permitió el ataque? (vulnerabilidad técnica, debilidad de proceso, error humano, problema de configuración);
  • Falla de Control: ¿Qué controles de seguridad fallaron en prevenir o detectar el ataque? (controles preventivos, controles detectivos, controles de respuesta).

#### 5.5.4 Evaluación de Impacto

Determinar el impacto completo del incidente:

  • Impacto en Datos: ¿Qué datos fueron accedidos, exfiltrados, modificados o destruidos? (tipos de datos, volúmenes de datos, titulares de datos);
  • Impacto en Sistemas: ¿Qué sistemas fueron afectados? (criticidad, funcionalidad, dependencias);
  • Impacto en Usuarios: ¿Cuántos usuarios fueron afectados? ¿Cuál fue el impacto en los usuarios? (interrupción del servicio, compromiso de datos, compromiso de cuenta);
  • Impacto Operativo: ¿Cuál fue el impacto operativo? (tiempo de inactividad, costos de remediación, pérdida de productividad);
  • Impacto Financiero: ¿Cuál fue el impacto financiero? (costos de remediación, costos legales, costos de notificación, multas regulatorias, pérdida de negocio);
  • Impacto Reputacional: ¿Cuál fue el impacto reputacional? (atención de los medios, confianza del usuario, relaciones con socios);
  • Impacto Legal/Regulatorio: ¿Qué obligaciones legales o regulatorias se activan? (notificación de violación, investigación regulatoria, litigio).

Objetivo: Eliminar completamente la amenaza del entorno y abordar la causa raíz.

Actividades:

5.6.1 Eliminar artefactos maliciosos:

  • Eliminar malware, backdoors, troyanos, rootkits;
  • Eliminar mecanismos de persistencia (tareas programadas, servicios, elementos de inicio, claves de registro);
  • Eliminar herramientas y scripts del atacante;
  • Eliminar cuentas de usuario y credenciales no autorizadas;
  • Eliminar métodos de acceso no autorizados.

5.6.2 Remediación de vulnerabilidades:

  • Aplicar parches y actualizaciones de seguridad;
  • Corregir debilidades de configuración;
  • Actualizar controles de seguridad (reglas WAF, reglas de cortafuegos, políticas IAM);
  • Implementar controles detectivos adicionales.

5.6.3 Cerrar vectores de ataque:

  • Deshabilitar servicios, puertos y protocolos no utilizados;
  • Eliminar permisos de acceso innecesarios;
  • Revocar credenciales comprometidas y emitir nuevas;
  • Implementar requisitos de autenticación adicionales.

5.6.4 Rotación de contraseñas/credenciales:

  • Rotar todas las credenciales que puedan haber sido comprometidas;
  • Rotar credenciales como precaución incluso sin evidencia de compromiso;
  • Notificar a los usuarios sobre cambios de credenciales y facilitar restablecimientos de contraseñas.

5.6.5 Verificar la erradicación:

  • Realizar escaneos de vulnerabilidades en los sistemas remediados;
  • Verificar que los artefactos maliciosos hayan sido eliminados;
  • Confirmar que los mecanismos de persistencia estén eliminados;
  • Monitorear en busca de signos de reinfección.

Objetivo: Restaurar los sistemas y datos afectados a la operación normal de manera controlada y monitoreada.

Actividades:

5.7.1 Desarrollar plan de recuperación:

  • Priorizar sistemas para la recuperación según su criticidad;
  • Definir secuencia de recuperación y dependencias;
  • Establecer criterios de éxito para cada paso de recuperación;
  • Definir criterios y procedimientos de reversión.

5.7.2 Restauración de sistemas:

  • Restaurar sistemas a partir de copias de seguridad conocidas como seguras (verificadas limpias);
  • Reconstruir sistemas a partir de configuraciones conocidas como seguras;
  • Desplegar sistemas actualizados y parcheados;
  • Restaurar datos a partir de copias de seguridad limpias.

5.7.3 Verificación de integridad:

  • Verificar la integridad del sistema (comprobaciones de integridad de archivos, escaneos de vulnerabilidades, revisión de configuración de seguridad);
  • Verificar la integridad de los datos (validación de datos, conciliación);
  • Verificar que los controles de seguridad funcionen correctamente;
  • Realizar pruebas de seguridad antes de regresar a producción.

5.7.4 Retorno monitoreado a producción:

  • Devolver los sistemas a producción en fases cuando sea factible;
  • Implementar monitoreo mejorado para todos los sistemas restaurados;
  • Mantener un umbral más bajo para alertar sobre sistemas restaurados;
  • Mantener las medidas de contención hasta que se verifique la recuperación completa.

5.7.5 Monitoreo posterior a la recuperación:

  • Monitoreo mejorado durante un mínimo de 30 días posteriores a la recuperación;
  • Monitorear signos de reinfección o actividad relacionada;
  • Monitorear comportamiento anómalo en sistemas restaurados;
  • Documentar cualquier problema posterior a la recuperación.

5.7.6 Comunicación de la recuperación:

  • Notificar a las partes interesadas sobre la restauración del servicio;
  • Actualizar la cronología y documentación del incidente;
  • Coordinar comunicaciones externas sobre la recuperación.

5.8 Revisión Posterior al Incidente (Revisión de Acciones Posteriores)

Objetivo: Aprender del incidente para mejorar los controles de seguridad y las capacidades de respuesta a incidentes.

Actividades:

5.8.1 Programar revisión posterior al incidente:

  • Nivel 1-2: Dentro de 2 semanas del cierre del incidente;
  • Nivel 3: Dentro de 1 mes del cierre del incidente;
  • Nivel 4-5: Dentro del siguiente ciclo de revisión trimestral.

5.8.2 Realizar reunión de revisión posterior al incidente con el ERI y las partes interesadas relevantes:

  • Revisar la cronología y documentación del incidente;
  • Discutir qué salió bien y qué se puede mejorar;
  • Identificar causas raíz y factores contribuyentes;
  • Identificar fallas y brechas de control;
  • Desarrollar plan de acción de mejora.

5.8.3 Documentar las lecciones aprendidas:

  • Resumen del incidente (anonimizado para distribución apropiada);
  • Cronología de eventos clave;
  • Análisis de causa raíz;
  • Efectividad de la detección, contención, erradicación y recuperación;
  • Efectividad de la comunicación;
  • Brechas en recursos, herramientas o capacitación;
  • Elementos de acción de mejora con responsables y plazos.

5.8.4 Desarrollar y dar seguimiento al plan de acción de mejora:

  • Asignar elementos de acción con responsables y plazos específicos;
  • Priorizar elementos de acción según el riesgo;
  • Dar seguimiento a los elementos de acción hasta su finalización;
  • Verificar el cierre de los elementos de acción.

5.8.5 Actualizar los procedimientos de respuesta a incidentes:

  • Incorporar lecciones aprendidas en el plan y procedimientos de respuesta a incidentes;
  • Actualizar los manuales para tipos específicos de incidentes;
  • Actualizar reglas de detección y lógica de correlación;
  • Actualizar plantillas de comunicación.

5.8.6 Determinar si quedan obligaciones de notificación o reporte:

  • Determinación final de obligaciones de notificación regulatoria;
  • Notificación final al usuario (si aplica);
  • Notificación al socio (si aplica);
  • Coordinación con autoridades (si aplica).

Una "Violación de Datos Personales" es una violación de la seguridad que conduce a la destrucción, pérdida, alteración, divulgación no autorizada o acceso accidental o ilícito a datos personales transmitidos, almacenados o procesados de otro modo.

La determinación de si un incidente de seguridad constituye una violación de datos personales es realizada por el Líder del ERI en consulta con el Asesor Legal. La determinación considera:

  • Tipo de datos involucrados (¿incluye datos personales?);
  • Circunstancias de la violación (acceso no autorizado, divulgación accidental, pérdida, destrucción);
  • Si los datos personales fueron realmente accedidos o solo potencialmente accedidos;
  • Si los datos personales fueron exfiltrados;
  • Si los datos estaban cifrados y la clave de cifrado no fue comprometida;
  • Si existen copias de los datos;
  • Si los datos pueden ser recuperados.

Cuando se confirma una violación de datos personales, DataCred realiza una evaluación de riesgos para determinar el impacto probable en los titulares de datos afectados:

  • Factores de Riesgo:
  • Tipo y sensibilidad de los datos personales involucrados;
  • Facilidad de identificación de los titulares de datos;
  • Gravedad de las consecuencias potenciales para los titulares de datos (robo de identidad, fraude, discriminación, daño reputacional);
  • Características especiales de los titulares de datos (poblaciones vulnerables);
  • Volumen de datos personales y número de titulares de datos;
  • Si los datos están cifrados o protegidos de otro modo;
  • Duración de la violación;
  • Medidas ya adoptadas para mitigar el daño.
  • Niveles de Riesgo:
  • RIESGO ALTO: Es probable que resulte en daño significativo para los titulares de datos (robo de identidad, fraude, daño físico, discriminación). Requiere notificación a los titulares de datos sin demora injustificada.
  • RIESGO MODERADO: Podría resultar en daño para los titulares de datos, pero el riesgo no es alto. La decisión de notificar se toma caso por caso.
  • RIESGO BAJO: Es poco probable que resulte en daño para los titulares de datos. Generalmente no se requiere notificación, pero se mantiene documentación.

Además de las fases generales de respuesta a incidentes, la respuesta a violaciones de datos incluye:

6.3.1 Contención inmediata para prevenir pérdida adicional de datos.

6.3.2 Investigación forense para determinar el alcance de la violación:

  • ¿Qué datos fueron accedidos o exfiltrados?
  • ¿Quién accedió a los datos?
  • ¿Cuándo se accedió a los datos?
  • ¿Cómo se accedió a los datos?
  • ¿A dónde fueron enviados los datos (si fueron exfiltrados)?

6.3.3 Identificación de titulares de datos:

  • Identificar todos los titulares de datos afectados;
  • Determinar la información de contacto de los titulares de datos;
  • Preparar el contenido de la notificación.

6.3.4 Preparación y entrega de la notificación (ver Sección 7).

6.3.5 Remediación para prevenir recurrencia.

6.3.6 Revisión posterior al incidente con enfoque en mejoras de protección de datos.

Cuando se determine que una violación de datos personales representa un riesgo para los titulares de datos, DataCred notificará a los usuarios afectados sin demora injustificada.

#### 7.1.1 Plazo de Notificación

  • Obligación General: Sin demora injustificada después de la confirmación de la violación;
  • GDPR: Dentro de 72 horas desde que se tenga conocimiento de la violación (cuando aplique GDPR);
  • CCPA/CPRA: Según lo requerido por la ley aplicable de California;
  • Otras Jurisdicciones: Según lo requerido por las leyes aplicables de notificación de violaciones de datos;
  • Obligaciones Contractuales: Según lo especificado en los acuerdos aplicables.

#### 7.1.2 Contenido de la Notificación

La notificación al usuario incluye, en la medida conocida:

  • Naturaleza de la violación de datos personales, incluyendo:
  • Categorías de datos personales involucrados;
  • Número aproximado de titulares de datos afectados;
  • Número aproximado de registros de datos personales concernidos;
  • Nombre y datos de contacto del punto de contacto de DataCred para obtener más información;
  • Consecuencias probables de la violación de datos personales;
  • Medidas adoptadas o propuestas por DataCred para abordar la violación y mitigar sus efectos;
  • Recomendaciones para que los usuarios afectados se protejan (por ejemplo, cambios de contraseña, alertas de fraude, monitoreo de crédito).

#### 7.1.3 Métodos de Notificación

La notificación al usuario se realiza a través de canales apropiados:

  • Notificación por correo electrónico a los usuarios afectados (método principal);
  • Notificación en la aplicación (suplementaria);
  • Publicación en el sitio web (para violaciones generalizadas);
  • Comunicación directa (para violaciones de alto riesgo cuando el correo electrónico es insuficiente).

Cuando lo requiera la ley aplicable, DataCred notificará a las autoridades de supervisión competentes sobre las violaciones de datos personales.

#### 7.2.1 GDPR (Titulares de Datos de la UE)

  • Plazo de Notificación: Dentro de 72 horas desde que se tenga conocimiento de la violación;
  • Si se exceden las 72 horas: La notificación debe incluir las razones de la demora;
  • Contenido de la Notificación:
  • Descripción de la naturaleza de la violación de datos personales;
  • Categorías y número aproximado de titulares de datos y registros concernidos;
  • Nombre y datos de contacto del delegado de protección de datos u otro punto de contacto;
  • Consecuencias probables de la violación de datos personales;
  • Medidas adoptadas o propuestas para abordar la violación;
  • Autoridad de Supervisión Principal: Determinada según el establecimiento principal o representante de DataCred en la UE.

#### 7.2.2 CCPA/CPRA (Residentes de California)

  • Notificación: Sin demora injustificada;
  • Notificación a: Procurador General de California (cuando sea requerido);
  • Contenido: Según lo requerido por la ley de California.

#### 7.2.3 Otras Leyes Estatales de EE. UU.

DataCred cumplirá con las leyes aplicables de notificación de violaciones de datos en todos los estados donde residan los usuarios afectados. El plazo y contenido de la notificación cumplirán con cada ley estatal aplicable, rigiendo los requisitos más estrictos cuando varios estados estén afectados.

#### 7.2.4 Otras Jurisdicciones

Cuando DataCred procese datos personales de titulares de datos en otras jurisdicciones con requisitos de notificación de violaciones, DataCred cumplirá con los requisitos de la ley local aplicable.

DataCred notificará a las autoridades competentes cuando:

  • Se sospeche actividad delictiva (por ejemplo, acceso no autorizado, robo, fraude);
  • Exista evidencia de un delito (por ejemplo, ransomware, robo de datos, intrusión al sistema);
  • La notificación a las autoridades sea requerida por la ley aplicable;
  • Se necesite asistencia de las autoridades para la investigación o remediación.

Los contactos con las autoridades pueden incluir:

  • Federal Bureau of Investigation (FBI) - División Cibernética;
  • Cybersecurity and Infrastructure Security Agency (CISA);
  • Servicio Secreto de los Estados Unidos (para delitos financieros);
  • Autoridades estatales o locales;
  • Autoridades internacionales (Europol, unidades nacionales de ciberdelincuencia) para incidentes transfronterizos.

DataCred notificará a socios, proveedores y otros terceros cuando:

  • Sus datos se vean afectados por el incidente;
  • Sus sistemas se vean afectados por el incidente;
  • Puedan estar legalmente obligados a notificar a sus propios usuarios o reguladores;
  • Puedan ayudar en la investigación o remediación;
  • Las obligaciones contractuales requieran notificación.

Cuando un incidente de seguridad involucre datos de tarjetas de pago (si DataCred procesa dichos datos), DataCred:

  • Notificará al procesador de pagos y al banco adquirente;
  • Notificará a las redes de tarjetas (Visa, Mastercard, etc.) según lo requerido;
  • Contratará a un investigador forense PCI (PFI) si es requerido;
  • Cumplirá con todos los requisitos aplicables de respuesta a incidentes de las marcas de tarjetas de pago.

La notificación a los usuarios o al público puede retrasarse cuando:

  • Las autoridades hayan solicitado una demora para evitar comprometer una investigación criminal;
  • La solicitud de demora esté documentada por escrito por la agencia investigadora;
  • La demora sea limitada en el tiempo y razonable bajo las circunstancias;
  • DataCred haya confirmado la legitimidad de la solicitud de las autoridades.

La notificación puede retrasarse cuando:

  • La notificación inmediata comprometería la investigación de seguridad;
  • La notificación alertaría al atacante y le permitiría destruir evidencia o escalar el ataque;
  • La demora sea necesaria para identificar y contener la amenaza;
  • La demora se limite al tiempo más breve necesario.

La notificación puede limitarse o retrasarse cuando:

  • La ley aplicable prohíba la notificación (por ejemplo, obligaciones de secreto);
  • Una orden judicial restrinja la notificación;
  • La notificación violaría el privilegio legal profesional aplicable;
  • La notificación entraría en conflicto con otras obligaciones legales.

Cuando DataCred no pueda identificar a todos los usuarios afectados debido a datos insuficientes o limitaciones técnicas, DataCred:

  • Realizará esfuerzos razonables para identificar a los usuarios afectados;
  • Proporcionará notificación pública a través de los canales disponibles;
  • Solicitará a los usuarios afectados que se presenten;
  • Documentará las razones por las que no fue posible la notificación individual.

DataCred mantiene un registro de incidentes que documenta todos los incidentes de seguridad, independientemente de su gravedad. El registro de incidentes incluye:

  • Identificador único del incidente;
  • Fecha y hora de detección;
  • Fecha y hora del reporte inicial;
  • Fuente de detección;
  • Tipo y categoría de incidente;
  • Clasificación de gravedad inicial y final;
  • Sistemas, datos y usuarios afectados;
  • Descripción del incidente;
  • Acciones de respuesta tomadas;
  • Causa raíz;
  • Evaluación de impacto;
  • Acciones de remediación;
  • Hallazgos de la revisión posterior al incidente;
  • Lecciones aprendidas;
  • Notificaciones regulatorias realizadas (si las hubo);
  • Fecha de cierre del incidente.

Toda la evidencia relacionada con incidentes de seguridad se preserva y mantiene:

  • Las imágenes forenses y la evidencia se almacenan en un entorno seguro y con control de acceso;
  • La cadena de custodia se documenta para toda la evidencia;
  • La evidencia se retiene por un período mínimo según lo requerido por la ley o determinado por retención legal;
  • La eliminación de evidencia sigue procedimientos seguros de eliminación.

Los registros de notificaciones y comunicaciones regulatorias se mantienen:

  • Copias de todas las notificaciones regulatorias;
  • Marca de tiempo de las notificaciones;
  • Información de contacto de la autoridad regulatoria;
  • Comunicaciones de respuesta y seguimiento regulatorio;
  • Comprobante de entrega de las notificaciones;
  • Registros de cualquier investigación o consulta regulatoria.

Los registros de incidentes se retienen según el siguiente cronograma:

  • Incidentes de Nivel 1-2: Mínimo 6 años desde el cierre del incidente;
  • Incidentes de Nivel 3: Mínimo 3 años desde el cierre del incidente;
  • Incidentes de Nivel 4-5: Mínimo 1 año desde el cierre del incidente;
  • Evidencia (imágenes forenses): Retenida hasta que se libere la retención legal o se cumplan las obligaciones regulatorias;
  • Registros de Notificación: Retenidos durante la duración del plazo de prescripción aplicable.

10.1 Ejercicios de Simulación (Tabletop)

DataCred realiza ejercicios de simulación para validar los procedimientos de respuesta a incidentes y la preparación del equipo:

  • Frecuencia: Al menos semestralmente;
  • Participantes: Miembros del ERI y partes interesadas relevantes;
  • Escenarios: Escenarios variados que incluyen ransomware, violación de datos, phishing, amenaza interna, compromiso en la nube, DDoS e incidente de terceros;
  • Formato: Ejercicios facilitados basados en discusión con escenarios realistas;
  • Documentación: Los resultados del ejercicio y las acciones de mejora se documentan;
  • Seguimiento: Las acciones de mejora se rastrean hasta su finalización.

DataCred realiza ejercicios de simulación técnica para probar las capacidades de detección y respuesta:

  • Frecuencia: Al menos anualmente;
  • Tipos:
  • Ejercicios de equipo rojo (simulación de adversario de alcance completo);
  • Ejercicios de equipo púrpura (mejora colaborativa de detección);
  • Simulación de phishing (continua, mensual);
  • Simulación técnica de violación;
  • Alcance: Puede incluir sistemas en vivo en entornos de prueba o ejercicios programados en entornos de producción;
  • Seguridad: Los ejercicios de simulación se realizan con controles de seguridad para evitar daños reales.

DataCred puede contratar facilitadores externos para ejercicios de respuesta a incidentes:

  • Diseño y facilitación independiente de ejercicios;
  • Desarrollo de escenarios realistas basados en inteligencia de amenazas actual;
  • Evaluación objetiva de las capacidades de respuesta;
  • Comparación con pares de la industria;
  • Reporte imparcial de acciones posteriores.

| Tipo de Ejercicio | Frecuencia Mínima | Participantes |

|------------------|-------------------|---------------|

| Ejercicio de Simulación (Tabletop) | Semestral | ERI Completo |

| Simulación Técnica | Anual | Equipo de Seguridad, Ingeniería |

| Simulación de Phishing | Mensual | Todo el Personal |

| Equipo Rojo/Púrpura | Anual | Equipo de Seguridad, Externo |

| Ejercicio DR/BCP | Anual | ERI, Operaciones |

Cuando un incidente de seguridad involucra a los proveedores de infraestructura en la nube de DataCred:

  • DataCred confía en las capacidades de respuesta a incidentes del proveedor en la nube para incidentes a nivel de infraestructura;
  • El ERI de DataCred se coordina con el equipo de seguridad del proveedor en la nube;
  • DataCred investiga sus propios datos y aplicaciones afectados por el incidente del proveedor en la nube;
  • DataCred evalúa el impacto en sus usuarios y datos;
  • DataCred notifica a los usuarios afectados según corresponda.

Cuando un incidente de seguridad involucra a un proveedor con acceso a datos de DataCred:

  • El proveedor está obligado a notificar a DataCred de acuerdo con las obligaciones contractuales;
  • El ERI de DataCred evalúa el impacto en los datos y usuarios de DataCred;
  • DataCred puede realizar su propia investigación junto con el proveedor;
  • DataCred notifica a los usuarios afectados según corresponda;
  • DataCred evalúa la idoneidad continua del proveedor.

Cuando un incidente de seguridad involucra a un socio cuyos sistemas están integrados con DataCred:

  • El ERI de DataCred se coordina con el ERI del socio;
  • DataCred investiga el impacto en sus sistemas integrados;
  • DataCred puede deshabilitar temporalmente las integraciones para proteger sus sistemas y usuarios;
  • DataCred notifica a los usuarios afectados según corresponda.

La coordinación de incidentes con terceros incluye:

  • Identificación del contacto apropiado en el tercero;
  • Establecimiento de canales de comunicación;
  • Acuerdos de intercambio de información (qué se puede compartir);
  • Coordinación conjunta de la investigación;
  • Coordinación de notificaciones a usuarios;
  • Revisión posterior al incidente y mejora.

Los usuarios de las plataformas de DataCred tienen las siguientes obligaciones con respecto a los incidentes de seguridad:

  • Reporte Inmediato: Los usuarios deben reportar cualquier incidente de seguridad sospechado que involucre su cuenta de DataCred inmediatamente, incluyendo pero no limitado a:
  • Acceso no autorizado a su cuenta;
  • Actividad sospechosa en su cuenta;
  • Cambios inesperados de contraseña o cambios de MFA;
  • Recepción de comunicaciones sospechosas que pretendan ser de DataCred;
  • Descubrimiento de transacciones o cambios de datos no autorizados;
  • Pérdida o robo de dispositivos utilizados para acceder a DataCred;
  • Compromiso de su correo electrónico u otros métodos de autenticación.
  • Canales de Reporte:
  • Correo Electrónico: [email protected]
  • Soporte: A través de los canales de soporte de DataCred
  • Emergencia: A través del contacto de emergencia designado (para incidentes verificados y urgentes)

Los usuarios aceptan cooperar con los esfuerzos de respuesta a incidentes de DataCred, incluyendo:

  • Proporcionar información oportuna y precisa sobre el incidente;
  • Preservar la evidencia según las instrucciones (por ejemplo, no eliminar correos electrónicos, registros o mensajes);
  • Cumplir con las medidas de seguridad razonables durante la respuesta (por ejemplo, cambios de contraseña, cierre de sesión, verificación adicional);
  • Participar en el seguimiento posterior al incidente según se solicite razonablemente.

El incumplimiento por parte del usuario de sus obligaciones de reporte de incidentes puede:

  • Limitar la capacidad de DataCred para responder y mitigar el incidente;
  • Aumentar el daño al usuario o a otros;
  • Resultar en la imposibilidad de DataCred para determinar las obligaciones de notificación;
  • Afectar la capacidad de DataCred para restaurar servicios o datos.

DATACRED NO ES RESPONSABLE POR DAÑOS RESULTANTES DEL INCUMPLIMIENTO DEL USUARIO EN REPORTAR OPORTUNAMENTE INCIDENTES DE SEGURIDAD SOSPECHADOS.

DATACRED MANTIENE ESTA POLÍTICA DE RESPUESTA A INCIDENTES Y LOS PROCEDIMIENTOS ASOCIADOS COMO MEDIDAS COMERCIALMENTE RAZONABLES PARA DETECTAR, RESPONDER Y RECUPERARSE DE INCIDENTES DE SEGURIDAD. SIN EMBARGO, ESTAS MEDIDAS NO GARANTIZAN QUE LOS INCIDENTES DE SEGURIDAD SERÁN PREVENIDOS, DETECTADOS O QUE SE LES DARÁ RESPUESTA EFECTIVA. A PESAR DE LA EXISTENCIA DE ESTA POLÍTICA Y LOS PROCEDIMIENTOS ASOCIADOS:

  • Pueden ocurrir incidentes de seguridad que no sean detectados;
  • La detección puede retrasarse;
  • La respuesta puede ser incompleta o ineficaz;
  • La recuperación puede ser parcial o retrasada;
  • La notificación puede no llegar a todas las partes afectadas;
  • Puede ocurrir daño a DataCred, sus usuarios y partes interesadas.

EN LA MÁXIMA MEDIDA PERMITIDA POR LA LEY APLICABLE, DATACRED Y SUS AFILIADAS, DIRECTIVOS, DIRECTORES, EMPLEADOS, AGENTES Y PROVEEDORES DE SERVICIOS NO SERÁN RESPONSABLES POR NINGÚN DAÑO DIRECTO, INDIRECTO, INCIDENTAL, ESPECIAL, CONSECUENTE O PUNITIVO QUE SURJA DE O ESTÉ RELACIONADO CON INCIDENTES DE SEGURIDAD, INCLUYENDO PERO NO LIMITADO A:

  • Violación de datos o pérdida de datos;
  • Acceso no autorizado a cuentas de usuario;
  • Interrupción o indisponibilidad del servicio;
  • Pérdida financiera o fraude resultante de un incidente de seguridad;
  • Robo de identidad o daño reputacional;
  • Costos de respuesta a incidentes, notificación, monitoreo de crédito u otra remediación;
  • Sanciones legales o regulatorias;
  • Cualquier otro daño o pérdida que surja de un incidente de seguridad.

Esta limitación de responsabilidad aplica independientemente de si DataCred implementó las medidas de respuesta a incidentes descritas en esta Política e independientemente de si se alegó que la respuesta de DataCred fue negligente, inadecuada o inoportuna.

ESTA POLÍTICA DE RESPUESTA A INCIDENTES NO ES UNA PÓLIZA DE SEGURO. DATACRED NO PROPORCIONA COBERTURA NI COMPENSACIÓN POR PÉRDIDAS QUE SURJAN DE INCIDENTES DE SEGURIDAD. LOS USUARIOS Y OTRAS PARTES AFECTADAS DEBEN MANTENER SU PROPIA COBERTURA DE SEGURO, INCLUYENDO SEGURO CIBERNÉTICO, PARA ABORDAR POSIBLES PÉRDIDAS DERIVADAS DE INCIDENTES DE SEGURIDAD.

ESTA POLÍTICA NO ES UN CONTRATO Y NO CREA DERECHOS U OBLIGACIONES CONTRACTUALES. ESTA POLÍTICA ES UN DOCUMENTO DE GOBIERNO INTERNO QUE DESCRIBE EL PROGRAMA DE RESPUESTA A INCIDENTES DE DATACRED. ESTA POLÍTICA NO CREA DERECHOS DE BENEFICIARIO TERCERO. NINGÚN USUARIO, PROVEEDOR, SOCIO U OTRO TERCERO PUEDE CONFIAR EN ESTA POLÍTICA COMO CREANDO CUALQUIER OBLIGACIÓN DE DATACRED DE RESPONDER A INCIDENTES DE CUALQUIER MANERA PARTICULAR O DENTRO DE CUALQUIER PLAZO PARTICULAR.

NADA EN ESTA POLÍTICA CONSTITUYE UNA RENUNCIA DE LOS DERECHOS LEGALES O DEFENSAS DE DATACRED, INCLUYENDO PERO NO LIMITADO A:

  • Privilegio abogado-cliente;
  • Protección del producto del trabajo;
  • Protección de secreto comercial;
  • Protecciones de confidencialidad;
  • Cualquier otro privilegio o protección legal aplicable.

ESTA POLÍTICA NO ES:

  • Una garantía de notificación en todos los casos;
  • Una renuncia a la cooperación con las autoridades;
  • Una póliza de seguro;
  • Un compromiso contractual;
  • Una representación ante terceros;
  • Una garantía de respuesta efectiva a incidentes;
  • Una garantía de seguridad o protección de datos;
  • Un sustituto de las prácticas de seguridad del usuario.

Esta Política es revisada al menos semestralmente por el CISO y el Comité Directivo de Seguridad. La revisión incluye la evaluación de:

  • Efectividad de los procedimientos de respuesta a incidentes;
  • Lecciones aprendidas de incidentes y ejercicios reales;
  • Cambios en el panorama de amenazas;
  • Cambios en los requisitos legales y regulatorios aplicables;
  • Cambios en el entorno empresarial, la tecnología y las operaciones;
  • Retroalimentación de los miembros del ERI y partes interesadas;
  • Recomendaciones de las revisiones posteriores a incidentes.

DATACRED SE RESERVA EL DERECHO DE MODIFICAR, ENMENDAR O REEMPLAZAR ESTA POLÍTICA Y LOS PROCEDIMIENTOS DE RESPUESTA A INCIDENTES AQUÍ DESCRITOS EN CUALQUIER MOMENTO SIN PREVIO AVISO. LAS MODIFICACIONES PUEDEN INCLUIR CAMBIOS EN LOS PROCEDIMIENTOS DE RESPUESTA, CRITERIOS DE CLASIFICACIÓN DE GRAVEDAD, REQUISITOS DE NOTIFICACIÓN, ESTRUCTURAS DE EQUIPO O CUALQUIER OTRO ASPECTO DEL PROGRAMA DE RESPUESTA A INCIDENTES. DATACRED REALIZARÁ ESFUERZOS RAZONABLES PARA NOTIFICAR AL PERSONAL SOBRE CAMBIOS MATERIALES A ESTA POLÍTICA.

Se mantiene el control de versiones de esta Política. El número de versión actual y la fecha de vigencia se indican al inicio de este documento. Las versiones anteriores se conservan de acuerdo con el cronograma de retención de registros.

LAS MEDIDAS DE RESPUESTA A INCIDENTES DESCRITAS EN ESTA POLÍTICA SON VOLUNTARIAS. DATACRED NO ES UN BANCO, PRESTAMISTA, INSTITUCIÓN FINANCIERA REGULADA NI EMPRESA DE SERVICIOS MONETARIOS. DATACRED NO ESTÁ SUJETA A LOS REQUISITOS DE RESPUESTA A INCIDENTES REGULATORIOS APLICABLES A LAS INSTITUCIONES FINANCIERAS, INCLUYENDO PERO NO LIMITADO A:

  • Requisitos de respuesta a incidentes de la Regla de Salvaguardas GLBA (Gramm-Leach-Bliley Act);
  • Requisitos de la FCRA (Fair Credit Reporting Act) para burós de crédito;
  • Requisitos de respuesta a incidentes de la Reserva Federal, OCC o FDIC;
  • REQUISITOS DE SEGURIDAD Y RESPUESTA A INCIDENTES BAJO CUALQUIER RÉGIMEN REGULATORIO FINANCIERO.

A MENOS QUE SE INDIQUE EXPRESAMENTE EN UN DOCUMENTO ESCRITO SEPARADO, EL PROGRAMA DE RESPUESTA A INCIDENTES DE DATACRED NO ESTÁ CERTIFICADO, AUDITADO, APROBADO NI RESPALDADO POR NINGÚN ORGANISMO REGULATORIO. Las referencias a marcos regulatorios (GDPR, CCPA/CPRA, etc.) en esta Política indican los esfuerzos de cumplimiento voluntario de DataCred cuando son aplicables a sus operaciones.

Cuando DataCred cumple con requisitos regulatorios (como la notificación de violaciones del GDPR), dicho cumplimiento es voluntario y se basa en la interpretación de buena fe de DataCred de los requisitos aplicables. DataCred no admite que está sujeta a la jurisdicción o autoridad de ningún organismo regulatorio a menos que se indique expresamente.

CONTROL DEL DOCUMENTO

| Versión | Fecha | Autor | Cambios |

|---------|-------|-------|---------|

| 1.0 | 22 de mayo de 2026 | Seguridad de DataCred | Versión inicial |

APROBACIONES

| Rol | Nombre | Fecha |

|-----|--------|-------|

| CISO | DataCred LLC | 22 de mayo de 2026 |

| CEO | DataCred LLC | 22 de mayo de 2026 |

| CLO | DataCred LLC | 22 de mayo de 2026 |

FIN DE LA POLÍTICA DE RESPUESTA A INCIDENTES

Política de Respuesta a Incidentes | DataCred