1. Nuestro Compromiso con la Seguridad

En Kory Agencia Digital, la seguridad de los datos de nuestros Clientes es una prioridad fundamental. Kory Marketing Hub ha sido disenado con un enfoque de seguridad desde su concepcion ("security by design"), implementando multiples capas de proteccion para garantizar la confidencialidad, integridad y disponibilidad de la informacion procesada en nuestra Plataforma.

Este documento describe las medidas tecnicas y organizativas que implementamos para proteger los datos de nuestros Clientes y sus usuarios finales. Nuestro enfoque de seguridad se basa en los principios de defensa en profundidad, minimo privilegio y mejora continua.

Revisamos y actualizamos continuamente nuestras practicas de seguridad para adaptarnos a las amenazas emergentes y cumplir con las mejores practicas de la industria. Este documento se actualiza como minimo anualmente o cuando se producen cambios significativos en nuestra infraestructura o procesos de seguridad.

2. Infraestructura

Nuestra infraestructura esta alojada integramente en Google Cloud Platform (GCP), uno de los proveedores de servicios en la nube mas seguros y confiables del mundo, con centros de datos que cumplen con los estandares mas exigentes de seguridad fisica y logica.

2.1 Servicios Utilizados

• Firebase Firestore: base de datos NoSQL gestionada para el almacenamiento de datos de la aplicacion, con replicacion multi-region automatica que garantiza la durabilidad y disponibilidad de los datos.
• Firebase Authentication: servicio de autenticacion y gestion de identidades de usuarios, con soporte para multiples proveedores de identidad y gestion segura de credenciales.
• Firebase Storage: almacenamiento de archivos y contenido multimedia con cifrado automatico y control de acceso granular.
• Google Cloud Run: plataforma serverless para la ejecucion de servicios de backend con escalado automatico, aislamiento de contenedores y limite de memoria configurado (256 MiB por instancia).
• Google Cloud Functions: funciones serverless para procesamiento asincrono, webhooks y tareas programadas.
• Google Vertex AI: plataforma de inteligencia artificial para el procesamiento de lenguaje natural del asistente conversacional Kory AI.

2.2 Regiones y Ubicacion de Datos

Los datos de la Plataforma se procesan y almacenan en las siguientes regiones de Google Cloud:

• Firestore: configuracion multi-region (nam5 - Estados Unidos) que garantiza replicacion automatica en multiples centros de datos para alta disponibilidad y resistencia a desastres.
• Cloud Run: region us-central1 (Iowa, EE.UU.) como region principal de ejecucion del backend.
• Firebase Storage: almacenamiento multi-region en Estados Unidos con redundancia automatica.

2.3 Seguridad de Red

• Red de Google: todo el trafico entre servicios de GCP transita por la red privada de Google, sin exposicion a la Internet publica.
• Proteccion DDoS: Google Cloud Armor proporciona proteccion automatica contra ataques de denegacion de servicio distribuido (DDoS) a nivel de infraestructura.
• Firewall de aplicacion web: las reglas de firewall de GCP restringen el trafico entrante exclusivamente a los puertos y protocolos necesarios para la operacion de la Plataforma.
• CDN: los activos estaticos del frontend se sirven a traves de la red de distribucion de contenido de Vercel/Google, con puntos de presencia globales que reducen la latencia y proporcionan una capa adicional de proteccion.

2.4 Certificaciones de Infraestructura

Google Cloud Platform cuenta con las siguientes certificaciones de seguridad y cumplimiento:

• SOC 1, SOC 2 y SOC 3: auditorias independientes de controles de seguridad, disponibilidad y confidencialidad, realizadas anualmente por auditores externos.
• ISO 27001: sistema de gestion de seguridad de la informacion.
• ISO 27017: controles de seguridad especificos para servicios en la nube.
• ISO 27018: proteccion de datos personales (PII) en la nube publica.
• ISO 27701: sistema de gestion de informacion de privacidad.
• CSA STAR: certificacion de seguridad de Cloud Security Alliance.
• FedRAMP: programa de gestion de riesgos y autorizacion del gobierno de EE.UU.

2.5 Disponibilidad

La infraestructura de Google Cloud ofrece disponibilidad multi-region, lo que garantiza la continuidad del servicio incluso ante fallas en centros de datos individuales. Google Cloud garantiza un SLA de disponibilidad del 99.99% para Firestore multi-region y del 99.95% para Cloud Run. Para mas detalles sobre nuestros compromisos de disponibilidad, consulte nuestro Acuerdo de Nivel de Servicio (SLA).

3. Cifrado de Datos

3.1 Datos en Reposo

Todos los datos almacenados en Firestore estan cifrados en reposo de forma predeterminada utilizando AES-256, gestionado por el servicio de gestion de claves de Google Cloud (Cloud KMS). Adicionalmente, Kory implementa cifrado a nivel de aplicacion con AES-256-GCM para datos especialmente sensibles, incluyendo credenciales de integracion y tokens OAuth.

3.2 Datos en Transito

Todas las comunicaciones entre los usuarios y la Plataforma, asi como entre los servicios internos, estan protegidas mediante TLS 1.2 o superior (HTTPS). No se permite el acceso a la Plataforma a traves de conexiones no cifradas. Las configuraciones de TLS incluyen:

• Cipher suites: se utilizan exclusivamente cipher suites con forward secrecy (ECDHE), incluyendo TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 y TLS_CHACHA20_POLY1305_SHA256 para TLS 1.3.
• HSTS: se envian cabeceras HTTP Strict Transport Security (Strict-Transport-Security) para forzar conexiones HTTPS y prevenir ataques de downgrade de protocolo, con una duracion de max-age de al menos 1 ano.
• Certificados: los certificados TLS son gestionados automaticamente por la infraestructura de Google Cloud y se renuevan antes de su vencimiento.

3.3 Cifrado de Credenciales de Integracion

Las credenciales de integracion con servicios de terceros (Meta, Google) reciben un nivel adicional de proteccion mediante nuestra implementacion de cifrado a nivel de aplicacion:

• Algoritmo: AES-256-GCM (Advanced Encryption Standard con Galois Counter Mode), que proporciona tanto cifrado como autenticacion de integridad de los datos.
• Generacion de nonces: cada operacion de cifrado utiliza un nonce unico de 12 bytes generado criptograficamente mediante un generador de numeros aleatorios seguro (crypto/rand en Go), garantizando que el mismo texto plano produzca un texto cifrado diferente en cada operacion.
• Gestion de claves: la clave de cifrado maestra (INTEGRATION_ENCRYPTION_KEY) de 256 bits se gestiona de forma independiente y separada de los datos cifrados, almacenada como variable de entorno en el runtime de Cloud Run con acceso restringido.
• Rotacion de claves: la clave de cifrado se rota periodicamente conforme a la politica de gestion de secretos de Kory. La rotacion incluye el re-cifrado de todos los datos protegidos con la nueva clave.
• Datos protegidos: todos los tokens OAuth (access token y refresh token), los Client ID y Client Secret de las aplicaciones OAuth, y cualquier otra credencial de integracion se cifran antes de ser almacenados en la base de datos.

4. Seguridad de la Aplicacion

Kory Marketing Hub implementa multiples capas de seguridad a nivel de aplicacion para prevenir las vulnerabilidades mas comunes:

4.1 Validacion de Entrada

• Todas las entradas de usuario se validan tanto en el cliente (React Hook Form + Zod) como en el servidor (validacion en Go) antes de ser procesadas o almacenadas.
• Los esquemas de validacion de Zod definen tipos, formatos, longitudes maximas y patrones permitidos para cada campo de entrada.
• Se aplica sanitizacion de datos para prevenir la inyeccion de codigo malicioso.

4.2 Prevencion de XSS

• React 19 escapa automaticamente todo el contenido renderizado, previniendo ataques de Cross-Site Scripting (XSS) por defecto.
• No se utiliza dangerouslySetInnerHTML en la aplicacion, eliminando el riesgo de XSS a traves de contenido HTML sin sanitizar.
• Se implementan cabeceras Content-Security-Policy (CSP) para restringir las fuentes de contenido ejecutable.

4.3 Proteccion CSRF

• La autenticacion basada en tokens (Firebase Auth + Bearer tokens) es inherentemente resistente a ataques de Cross-Site Request Forgery (CSRF), ya que los tokens no se envian automaticamente con las solicitudes del navegador.
• Las cookies de sesion, cuando se utilizan, incluyen los atributos SameSite=Strict, Secure y HttpOnly.

4.4 Seguridad de Base de Datos

• Firestore es una base de datos NoSQL que no utiliza SQL, eliminando por naturaleza el riesgo de inyeccion SQL.
• Las consultas a Firestore se realizan a traves del SDK oficial de Google, que parametriza todas las consultas automaticamente.
• Las reglas de seguridad de Firestore proporcionan una capa adicional de control de acceso a nivel de base de datos.

4.5 Rate Limiting y Proteccion DDoS

• Se implementa rate limiting por tenant en las APIs del backend para prevenir abusos y garantizar la disponibilidad del servicio para todos los clientes.
• Google Cloud Run implementa escalado automatico con limites configurados para absorber picos de trafico sin degradacion del servicio.
• Google Cloud Armor proporciona proteccion automatica contra ataques DDoS a nivel de infraestructura.

4.6 Cabeceras de Seguridad HTTP

La Plataforma incluye las siguientes cabeceras de seguridad HTTP en todas las respuestas:

• Strict-Transport-Security: fuerza conexiones HTTPS.
• X-Content-Type-Options: nosniff: previene la interpretacion incorrecta de tipos MIME.
• X-Frame-Options: DENY: previene la inclusion de la Plataforma en iframes (proteccion contra clickjacking).
• Referrer-Policy: strict-origin-when-cross-origin: limita la informacion de referencia enviada a sitios de terceros.
• X-XSS-Protection: 1; mode=block: capa adicional de proteccion contra XSS en navegadores que lo soportan.

5. Gestion de Identidad y Acceso (IAM)

5.1 Autenticacion de Usuarios

• Firebase Authentication: servicio de autenticacion empresarial de Google para la gestion segura de identidades, con soporte para autenticacion por correo electronico/contrasena y proveedores de identidad federados.
• Gestion de sesiones: tokens de sesion seguros (JWT) con expiracion configurable. Los tokens de acceso de Firebase tienen una duracion maxima de 1 hora y se renuevan automaticamente mediante refresh tokens.
• Registro por invitacion: la Plataforma no permite el auto-registro. Los usuarios solo pueden acceder mediante invitacion de un administrador de organizacion, lo que reduce significativamente el riesgo de acceso no autorizado y garantiza que cada cuenta esta asociada a una organizacion verificada.
• Proteccion contra fuerza bruta: Firebase Authentication implementa protecciones automaticas contra ataques de fuerza bruta, incluyendo bloqueo temporal de cuentas despues de multiples intentos fallidos de inicio de sesion y deteccion de actividad sospechosa.
• Verificacion de correo electronico: los usuarios deben verificar su direccion de correo electronico como parte del proceso de registro para confirmar la propiedad de la cuenta.

5.2 Control de Acceso Basado en Roles (RBAC)

Kory Marketing Hub implementa un sistema de control de acceso basado en roles con 7 roles diferenciados. A continuacion se detalla la matriz de permisos por rol:

Cada rol tiene permisos especificos que limitan el acceso a funcionalidades y datos, siguiendo el principio de minimo privilegio. Los permisos se evaluan en cada solicitud a la API y en cada renderizado de componentes en el frontend.

5.3 Gestion de Sesiones

• Los tokens de acceso de Firebase tienen una duracion maxima de 1 hora y se renuevan automaticamente.
• Los refresh tokens se invalidan al cerrar sesion, cambiar contrasena o cuando un administrador revoca el acceso de un usuario.
• Las sesiones inactivas se cierran automaticamente conforme a la politica de expiracion configurada.
• El tenant activo del usuario se persiste de forma segura en el almacenamiento local del navegador y se valida contra las membresias del usuario en cada solicitud.

6. Aislamiento Multi-Tenant

Kory Marketing Hub es una plataforma multi-tenant donde cada organizacion opera en un entorno logicamente aislado. El aislamiento de datos es un principio arquitectonico fundamental de la Plataforma.

6.1 Aislamiento a Nivel de Base de Datos

• Rutas de documentos separadas:los datos de cada organizacion se almacenan en rutas de documentos independientes en Firestore (clients/{clientId}/...), impidiendo el acceso cruzado a nivel de base de datos. Cada coleccion y subcoleccion esta anidada bajo el documento del tenant correspondiente.
• Reglas de seguridad de Firestore: las reglas de seguridad de Firestore validan que el usuario autenticado pertenezca al tenant cuyos datos intenta acceder, proporcionando una capa de proteccion a nivel de base de datos independiente de la logica de la aplicacion.

6.2 Aislamiento a Nivel de API

• Middleware de validacion de tenant: cada solicitud a la API del backend incluye validacion del tenant mediante middleware. El middleware extrae el tenant ID del token de autenticacion y verifica que el usuario tenga una membresia activa en ese tenant antes de procesar la solicitud.
• Inyeccion de contexto: el tenant ID validado se inyecta en el contexto de la solicitud y se utiliza en todas las operaciones de base de datos, garantizando que las consultas esten siempre filtradas por tenant.

6.3 Prevencion Arquitectonica

• Imposibilidad de acceso cruzado: el acceso a datos entre tenants esta prevenido a nivel de arquitectura. No existe una ruta de codigo que permita a un usuario de una organizacion acceder a datos de otra organizacion, excepto para Super Admins (personal de Kory) a traves de la funcionalidad de impersonacion, la cual queda registrada en los logs de auditoria.
• Membresias explicitas: los usuarios solo pueden pertenecer a organizaciones a las que han sido explicitamente invitados, y cada membresia tiene un rol y permisos especificos. Un usuario puede pertenecer a multiples organizaciones, pero solo puede operar en una a la vez.
• Aislamiento de integraciones:las credenciales de integracion (tokens OAuth) son especificas de cada tenant y se almacenan en la ruta del tenant correspondiente (clients/{clientId}/integrations/...).

7. Seguridad de Integraciones

Las integraciones con servicios de terceros (Meta Platforms, Google) se gestionan con las siguientes medidas de seguridad:

• OAuth 2.0: todas las conexiones con servicios de terceros utilizan el protocolo estandar OAuth 2.0, que permite la autorizacion sin compartir credenciales del usuario. Kory nunca almacena ni tiene acceso a las contrasenas de las cuentas de terceros del Cliente.
• Renovacion automatica de tokens: los tokens de acceso se renuevan automaticamente antes de su expiracion mediante un pool de conexiones (Connection Pool) con auto-refresh, evitando interrupciones en el servicio y reduciendo la ventana de exposicion de tokens activos.
• Cifrado de credenciales: todos los tokens y credenciales se cifran a nivel de aplicacion con AES-256-GCM antes de almacenarse en Firestore, conforme a lo descrito en la seccion 3.3.
• Revocacion al desconectar: al desconectar una integracion, Kory revoca los tokens de acceso en el servicio de terceros (mediante la URL de revocacion del proveedor) y elimina permanentemente todos los tokens y metadatos de conexion de sus sistemas.
• Alcances minimos: las integraciones solicitan unicamente los permisos (scopes) estrictamente necesarios para proporcionar las funcionalidades contratadas. Por ejemplo, Google Search Console solicita unicamente el scope de solo lectura (webmasters.readonly).
• Configuracion como datos: las credenciales maestras de las aplicaciones OAuth (Client ID/Secret) se almacenan cifradas en Firestore, no como variables de entorno, lo que permite la rotacion sin necesidad de redesplegar la aplicacion.

8. Seguridad de Endpoints y APIs

8.1 Autenticacion de APIs

• Todas las APIs del backend requieren autenticacion mediante tokens Bearer (Firebase Auth ID tokens) en la cabecera Authorization.
• Los tokens son verificados en cada solicitud contra Firebase Authentication para confirmar su validez, integridad y vigencia.
• Las APIs publicas (webhooks de Meta) utilizan mecanismos de verificacion especificos del proveedor (firma HMAC, token de verificacion).

8.2 Rate Limiting por Tenant

• Se aplican limites de tasa por tenant para prevenir que una organizacion afecte la disponibilidad del servicio para otras organizaciones.
• Los limites se configuran segun el plan de suscripcion del Cliente y se aplican tanto a solicitudes de API como a operaciones de mensajeria.

8.3 Validacion de Solicitudes

• Todas las solicitudes entrantes se validan contra esquemas definidos en el backend (tipos, formatos, rangos, longitudes maximas).
• Los parametros de ruta, query string y cuerpo de la solicitud se sanitizan antes de ser procesados.
• Las solicitudes que no cumplen con el esquema definido se rechazan con errores descriptivos sin revelar informacion interna del sistema.

9. Seguridad de IA

Las funcionalidades de inteligencia artificial de Kory Marketing Hub se implementan con las siguientes garantias de seguridad:

• Google Vertex AI: el procesamiento de IA se realiza a traves de Google Vertex AI, que ofrece seguridad de nivel empresarial y cumplimiento certificado (SOC 2, ISO 27001). Los datos se procesan en infraestructura dedicada de Google, no en modelos publicos compartidos.
• Sin uso para entrenamiento: los datos enviados a los modelos de IA no se utilizan para entrenar o mejorar los modelos de Google. Los datos se procesan exclusivamente para generar respuestas y se eliminan conforme a las politicas de retencion de Vertex AI. Google proporciona esta garantia contractualmente en sus Cloud Data Processing Terms.
• Base de conocimiento cifrada: los archivos cargados por los Clientes para la base de conocimiento del asistente de IA se almacenan cifrados en Firebase Storage y solo se acceden durante el procesamiento de consultas relacionadas.
• Aislamiento por tenant: cada organizacion tiene su propia configuracion de IA (system prompt, base de conocimiento, parametros) que esta aislada de las configuraciones de otros tenants.
• Retencion limitada: los registros de interacciones con IA (prompts, respuestas, tokens consumidos) se retienen durante un periodo maximo de 30 dias para fines de monitoreo y mejora del servicio, y se eliminan automaticamente al vencer este plazo.
• Minimizacion de datos: los prompts enviados a Vertex AI contienen unicamente el contexto minimo necesario para generar respuestas relevantes. Se implementan tecnicas de reduccion de tokens para limitar la cantidad de datos personales transmitidos al modelo.

10. Seguridad del Ciclo de Desarrollo

Kory implementa practicas de desarrollo seguro a lo largo de todo el ciclo de vida del software:

10.1 Practicas de Desarrollo

• Revision de codigo: todo el codigo pasa por un proceso de revision antes de ser integrado a las ramas principales (staging, main), con enfoque especial en seguridad.
• TypeScript strict mode: el frontend utiliza TypeScript en modo estricto, lo que previene errores de tipo comunes y mejora la seguridad del codigo.
• ESLint con reglas de seguridad: se aplican reglas de linting que previenen patrones de codigo inseguros, incluyendo la prohibicion de console.log en produccion.
• Go vet y analisis estatico: el backend en Go utiliza go vet y herramientas de analisis estatico para detectar errores y patrones inseguros antes del despliegue.

10.2 Gestion de Dependencias

• Las dependencias del frontend (pnpm) y del backend (Go modules) se auditan regularmente para identificar vulnerabilidades conocidas.
• Se aplican actualizaciones de seguridad de dependencias de forma prioritaria cuando se identifican vulnerabilidades criticas o altas.
• Se utiliza un archivo de bloqueo (pnpm-lock.yaml, go.sum) para garantizar la reproducibilidad y la integridad de las dependencias.

10.3 Pipeline CI/CD

• El pipeline de integracion continua ejecuta automaticamente: compilacion del proyecto, analisis de linting, verificacion de tipos TypeScript, y pruebas automatizadas.
• Los despliegues a produccion solo se realizan desde la rama main, despues de pasar por la rama staging y todas las verificaciones automatizadas.
• Las variables de entorno y secretos de produccion no son accesibles desde los entornos de desarrollo o staging.

11. Gestion de Secretos

• Sin secretos en codigo: ningun secreto, credencial o clave de cifrado se almacena en el codigo fuente, archivos de configuracion versionados o imagenes de contenedor. Se utilizan exclusivamente variables de entorno inyectadas en el runtime.
• Variables de entorno: los secretos se gestionan como variables de entorno en Google Cloud Run, con acceso restringido a los servicios autorizados.
• Credenciales de integracion: las credenciales maestras de las aplicaciones OAuth se almacenan cifradas en Firestore (configuracion como datos), no como variables de entorno, lo que permite la rotacion sin necesidad de redesplegar.
• Clave de cifrado: la clave de cifrado maestra (INTEGRATION_ENCRYPTION_KEY) se inyecta como variable de entorno en Cloud Run con acceso restringido. Su rotacion requiere el re-cifrado de todos los datos protegidos.
• Archivos .env: los archivos .env estan incluidos en .gitignore y nunca se versionan en el repositorio de codigo.

12. Monitoreo y Registro

Kory implementa monitoreo continuo y registro de actividades para detectar y responder a eventos de seguridad:

12.1 Logs de Auditoria

• Registro de todas las acciones administrativas, incluyendo cambios de configuracion, gestion de usuarios, modificaciones de roles y cambios en integraciones.
• Los logs de auditoria incluyen: identidad del usuario, accion realizada, timestamp, direccion IP, tenant afectado y resultado de la operacion.

12.2 Registro de Accesos Sensibles

• Registro de acceso a operaciones sensibles como visualizacion de credenciales, exportacion de datos, cambios de permisos y eliminacion de datos.

12.3 Seguimiento de Impersonacion

• Cuando un Super Admin utiliza la funcionalidad de impersonacion para acceder a una organizacion, todas las acciones quedan registradas con la identidad real del administrador, el tenant impersonado y la duracion de la sesion de impersonacion.

12.4 Politica de Retencion de Logs

Los logs se almacenan de forma segura con cifrado en reposo y acceso restringido. Los logs no contienen datos personales completos; se utilizan identificadores opacos para proteger la privacidad de los usuarios.

13. Respaldo y Recuperacion

• Copias de seguridad automaticas: Firestore realiza copias de seguridad automaticas de todos los datos de forma continua, con replicacion multi-region.
• Recuperacion a un punto en el tiempo (PITR): capacidad de restaurar datos a un estado anterior en caso de perdida accidental o corrupcion, con una granularidad de hasta 1 hora.
• Cifrado de respaldos: todas las copias de seguridad estan cifradas con los mismos estandares de cifrado AES-256 que los datos en produccion.
• Rotacion de respaldos: las copias de seguridad se rotan automaticamente conforme al ciclo de retencion de Firestore (maximo 90 dias para copias incrementales).

14. Pruebas de Seguridad

Kory mantiene un programa activo de pruebas de seguridad que incluye:

• Escaneo de vulnerabilidades: monitoreo continuo de dependencias y bibliotecas de software para identificar vulnerabilidades conocidas (CVEs) mediante herramientas automatizadas.
• Revision de codigo con enfoque en seguridad: todo el codigo que se integra a las ramas principales pasa por revision con atencion especifica a patrones de seguridad.
• Pruebas de penetracion: Kory realiza o encarga pruebas de penetracion periodicas para identificar vulnerabilidades que no pueden detectarse mediante herramientas automatizadas. Los resultados se documentan y las vulnerabilidades identificadas se remedian conforme a su criticidad.
• Aplicacion de parches: los parches de seguridad criticos se aplican dentro de las 72 horas siguientes a su disponibilidad. Los parches de seguridad altos se aplican dentro de los 7 dias habiles.

15. Respuesta a Incidentes

Kory cuenta con un plan de respuesta a incidentes de seguridad estructurado en las siguientes fases:

15.1 Fase 1: Deteccion y Alerta

• Monitoreo continuo de la infraestructura y la aplicacion para detectar anomalias.
• Alertas automaticas configuradas para actividades sospechosas (intentos de acceso no autorizado, patrones de trafico anormales, errores de autenticacion masivos).
• Canal de reporte interno para que el personal de Kory informe de posibles incidentes.

15.2 Fase 2: Triaje y Clasificacion

Los incidentes se clasifican segun su severidad e impacto:

• P1 (Critico): datos personales comprometidos, acceso no autorizado confirmado a datos de clientes, interrupcion total del servicio. Tiempo de respuesta: inmediato.
• P2 (Alto): intento de acceso no autorizado exitoso sin evidencia de exfiltracion, degradacion significativa del servicio. Tiempo de respuesta: 1 hora.
• P3 (Medio): vulnerabilidad identificada sin evidencia de explotacion, degradacion menor del servicio. Tiempo de respuesta: 4 horas.
• P4 (Bajo): anomalia que requiere investigacion, mejora de seguridad preventiva. Tiempo de respuesta: 24 horas.

15.3 Fase 3: Contencion

• Aislamiento de sistemas afectados para prevenir la propagacion del incidente.
• Revocacion de credenciales potencialmente comprometidas.
• Bloqueo de accesos no autorizados identificados.
• Preservacion de evidencia forense para investigacion posterior.

15.4 Fase 4: Erradicacion

• Identificacion y eliminacion de la causa raiz del incidente.
• Aplicacion de parches o correcciones necesarias.
• Verificacion de que la amenaza ha sido completamente eliminada.

15.5 Fase 5: Recuperacion

• Restauracion de servicios afectados a su operacion normal.
• Monitoreo intensificado durante el periodo de recuperacion.
• Notificacion a los Clientes afectados dentro de las 72 horas siguientes a la confirmacion del incidente, incluyendo descripcion del incidente, datos potencialmente afectados y medidas adoptadas.
• Asistencia al Cliente en la notificacion a las autoridades de proteccion de datos y a los Titulares de Datos afectados, conforme a la legislacion aplicable.

15.6 Fase 6: Revision Post-Incidente

• Analisis detallado del incidente (post-mortem) dentro de los 15 dias habiles siguientes a su resolucion.
• Identificacion de lecciones aprendidas y oportunidades de mejora.
• Actualizacion de procedimientos y medidas de seguridad segun corresponda.
• Documentacion completa del incidente y las acciones tomadas.

16. Politica de Divulgacion Responsable

Kory valora la contribucion de investigadores de seguridad independientes que nos ayudan a mantener la seguridad de la Plataforma. Si descubre una vulnerabilidad de seguridad, le solicitamos que la reporte de forma responsable.

16.1 Como Reportar una Vulnerabilidad

• Envie un correo electronico a info@kory.com.co con el asunto "Reporte de Vulnerabilidad de Seguridad".
• Incluya una descripcion detallada de la vulnerabilidad, pasos para reproducirla, impacto potencial y, si es posible, una propuesta de solucion.
• No divulgue la vulnerabilidad publicamente hasta que haya sido resuelta.

16.2 Que Esperar

• Acuse de recibo: dentro de las 48 horas habiles siguientes a la recepcion del reporte.
• Evaluacion inicial (triaje): dentro de los 5 dias habiles siguientes, le proporcionaremos una evaluacion inicial de la severidad y el impacto de la vulnerabilidad.
• Resolucion: nos comprometemos a resolver vulnerabilidades criticas dentro de las 72 horas, altas dentro de 7 dias habiles, y medias dentro de 30 dias habiles.
• Notificacion de resolucion: le notificaremos cuando la vulnerabilidad haya sido resuelta.

16.3 Safe Harbor

Kory no tomara acciones legales contra investigadores de seguridad que:

• Realicen pruebas de seguridad de buena fe, sin causar danos a la Plataforma ni a los datos de los Clientes.
• No accedan, modifiquen ni eliminen datos de otros usuarios.
• No realicen ataques de denegacion de servicio ni de fuerza bruta.
• Reporten la vulnerabilidad de forma responsable y confidencial.
• No divulguen la vulnerabilidad publicamente antes de que haya sido resuelta y se haya acordado un plazo de divulgacion con Kory.

16.4 Alcance de las Pruebas Permitidas

Las pruebas de seguridad estan permitidas unicamente en:

• Su propia cuenta y organizacion en Kory Marketing Hub (no en cuentas de otros Clientes).
• La aplicacion web de la Plataforma (frontend y APIs).

Quedan excluidas del alcance: la infraestructura de Google Cloud, los servicios de Meta, los servicios de Google y cualquier otro servicio de terceros.

17. Formacion y Concientizacion

Kory mantiene un programa de formacion y concientizacion en seguridad para su personal:

• Capacitacion en seguridad: todo el personal de Kory con acceso a datos de clientes recibe capacitacion periodica en seguridad de la informacion y proteccion de datos personales.
• Acuerdos de confidencialidad: todo el personal de Kory firma acuerdos de confidencialidad (NDA) como condicion de empleo.
• Revision de accesos: los permisos de acceso del personal de Kory a los sistemas de produccion se revisan periodicamente y se revocan cuando ya no son necesarios.
• Principio de necesidad de conocer: el acceso a datos de clientes se limita estrictamente al personal que lo necesita para cumplir con sus funciones.
• Procedimientos de offboarding: cuando un miembro del personal de Kory deja la organizacion, todos sus accesos se revocan inmediatamente y se realizan los cambios de credenciales compartidas que sean necesarios.

18. Continuidad del Negocio

Kory mantiene un plan de continuidad del negocio (BCP) para garantizar la disponibilidad del servicio ante eventos adversos:

• Infraestructura multi-region: la utilizacion de Google Cloud Platform con configuracion multi-region garantiza la continuidad del servicio ante fallas en centros de datos individuales.
• Arquitectura serverless: la arquitectura basada en Cloud Run y Firebase elimina la dependencia de servidores fisicos y proporciona escalado automatico y alta disponibilidad.
• Trabajo remoto: el equipo de Kory opera de forma remota, lo que garantiza la continuidad operativa ante eventos que afecten ubicaciones fisicas especificas.
• Redundancia de personal clave: las funciones criticas de operacion y desarrollo cuentan con personal de respaldo documentado.
• Procedimientos de recuperacion: se mantienen procedimientos documentados para la restauracion del servicio en caso de incidentes mayores.

19. Cumplimiento y Certificaciones

Kory Marketing Hub opera en cumplimiento de las siguientes normativas y politicas:

19.1 Normativa Colombiana

• Ley 1581 de 2012: Ley de Proteccion de Datos Personales. Kory opera como Encargado del Tratamiento en nombre de sus Clientes.
• Decreto 1377 de 2013: Decreto Reglamentario de la Ley 1581 de 2012.
• Decreto 886 de 2014: Registro Nacional de Bases de Datos ante la SIC.

19.2 Normativa Internacional

• GDPR (Union Europea): Kory mantiene conciencia y preparacion para el cumplimiento del Reglamento General de Proteccion de Datos cuando se procesan datos de Titulares ubicados en el Espacio Economico Europeo.

19.3 Cumplimiento de Plataformas de Terceros

• Meta Platform Terms: cumplimiento de los Terminos de la Plataforma de Meta para el uso de las APIs de WhatsApp, Instagram, Messenger y Facebook, incluyendo las politicas de privacidad de datos del usuario.
• Google API Services User Data Policy: cumplimiento de la Politica de Datos de Usuario de los Servicios de API de Google para el uso de Search Console, Analytics y Ads.
• PCI DSS (via Mercado Pago): el procesamiento de pagos se delega a Mercado Pago, certificado PCI DSS. Kory no almacena ni procesa directamente datos de tarjetas de credito.

19.4 Certificaciones de Infraestructura

La infraestructura subyacente de Google Cloud Platform cuenta con las siguientes certificaciones:

• SOC 1 / SOC 2 / SOC 3 (AICPA)
• ISO 27001 (Seguridad de la Informacion)
• ISO 27017 (Seguridad en la Nube)
• ISO 27018 (Proteccion de PII en la Nube)
• ISO 27701 (Gestion de Informacion de Privacidad)
• CSA STAR (Cloud Security Alliance)
• FedRAMP (Gobierno de EE.UU.)

Para mas informacion sobre como gestionamos los datos personales, consulte nuestro Acuerdo de Procesamiento de Datos (DPA).

20. Contacto

Para consultas sobre nuestras practicas de seguridad, reportar vulnerabilidades o solicitar informacion adicional, puede contactarnos a traves de:

• Correo electronico: info@kory.com.co
• Reporte de vulnerabilidades: info@kory.com.co con asunto "Reporte de Vulnerabilidad de Seguridad"
• Direccion postal: Kory Agencia Digital, CL 157A #154-169, AP 1208 T-2, Floridablanca, Santander, Colombia 681004