Política de seguridad

Última actualización: 8 de agosto de 2025

ARTÍCULO I: FINALIDAD Y ALCANCE

1.1 Objetivo

Este documento de seguridad describe las medidas de seguridad técnicas, administrativas y organizativas que Impulsum Me LLC («Impulsum», «nosotros», «nuestro» o «nos») aplica para proteger la confidencialidad, integridad y disponibilidad de los datos de los clientes procesados por la plataforma Impulsum ubicada en impulsum.me (la «Plataforma»). También explica las responsabilidades de los clientes, socios y empleados a la hora de respaldar esas medidas de seguridad.

1.2 Servicios cubiertos

Las protecciones de este documento se aplican a la aplicación web Impulsum, los servicios de backend, las API, las utilidades de línea de comandos y cualquier cliente móvil o de escritorio futuro que interactúe con el mismo backend. También se aplican a todas las integraciones que sincronizan los datos entre Impulsum y los sistemas de gestión de proyectos de terceros, actualmente Jira y, de forma prospectiva, Trello, Asana, ClickUp, Monday.com y cualquier otro sistema de gestión de proyectos de terceros integrado mediante API u OAuth, como, entre otros, Jira, Trello, Asana, ClickUp y Monday.com.

1.3 Relación con otras políticas

Este documento de seguridad funciona en conjunto con nuestra Política de privacidad, la Política de uso aceptable, los Términos y condiciones y el Manual interno del empleado, pero es distinto de ellos. Cuando surjan conflictos, prevalece el control más estricto, a menos que la ley aplicable lo invalide.

1.4 Naturaleza del documento y estado vinculante

Este documento de seguridad se proporciona únicamente con fines informativos y describe las prácticas de seguridad actuales de Impulsum. No crea ninguna obligación legalmente vinculante ni garantía contractual a menos que se incorpore explícitamente en un acuerdo independiente debidamente firmado (por ejemplo, un anexo sobre el procesamiento de datos o un acuerdo maestro empresarial). En caso de conflicto entre este documento de seguridad y los términos y condiciones, prevalecerán los términos y condiciones, a menos que se acuerde lo contrario por contrato. Este documento describe las prácticas actuales, pero está sujeto a modificaciones en respuesta a la evolución de las amenazas, los cambios en la tecnología o las actualizaciones normativas. Nada de lo dispuesto en este documento se interpretará como una renuncia a las exenciones de responsabilidad, limitaciones de responsabilidad u otras protecciones otorgadas a Impulsum en virtud de los Términos y condiciones.

1,5 No hay garantía de seguridad absoluta

Si bien Impulsum aplica controles de seguridad estándar de la industria alineados con marcos reconocidos, ningún sistema es impenetrable. En consecuencia, Impulsum no garantiza una protección absoluta contra todas las amenazas o vulnerabilidades.

1.6 Responsabilidades del cliente

Los usuarios son responsables de mantener la seguridad de sus propios entornos, lo que incluye:

a) Utilizar contraseñas o mecanismos de autenticación seguros y únicos;

b) Mantener la confidencialidad de las credenciales de la API y los tokens de sesión;

c) Habilitar la autenticación multifactorial cuando esté disponible;

d) Supervisar la actividad de la cuenta y denunciar con prontitud cualquier comportamiento sospechoso;

e) Cumplir con todos los acuerdos de servicio de terceros aplicables (por ejemplo, Jira, Trello);

f) Garantizar el cumplimiento de todas las reglas de uso de API aplicables a las integraciones de terceros (incluidos los límites de velocidad, las restricciones de acceso a los datos y los requisitos de atribución);

g) Permitir la autenticación multifactorial y cumplir con las políticas de uso para cualquier integración conectada, incluidos los proveedores de IA como OpenAI, Anthropic o Google Gemini, especialmente cuando dichas integraciones proporcionan acceso a datos administrativos o a nivel de proyecto.

ARTÍCULO II: GOBERNANZA Y CUMPLIMIENTO

2.1 Estructura de gobierno de seguridad

Impulsum mantiene un comité directivo de seguridad de nivel ejecutivo presidido por el director de seguridad de la información y al que asisten el director ejecutivo, el director de tecnología y el asesor legal. El comité se reúne al menos trimestralmente para revisar las métricas de seguridad, las evaluaciones de riesgos y las conclusiones de las auditorías.

2.2 Políticas y estándares

Las políticas de seguridad formales, que incluyen el control de acceso, el cifrado, la administración de cambios, el desarrollo seguro, la respuesta a incidentes y la administración de proveedores, se documentan, controlan las versiones, son aprobadas por la alta dirección y revisadas anualmente. Todos los empleados aceptan estas políticas en el momento de la contratación y en cada revisión importante.

2.3 Alineación regulatoria

Si bien Impulsum actualmente procesa datos principalmente de clientes con sede en los Estados Unidos, diseñamos controles para cumplir con una amplia gama de marcos y regulaciones, incluidos el SOC 2 de tipo II, la ISO 27001, el GDPR, la CCPA, la CPRA y el Marco de Ciberseguridad del Instituto Nacional de Estándares y Tecnología. Cuando los requisitos regionales difieren, adoptamos las medidas de protección más estrictas aplicables.

2.4 Evaluaciones independientes

Contratamos a auditores externos acreditados para que realicen un examen SOC 2 de tipo II anualmente. Los resúmenes ejecutivos y las cartas puente están disponibles sin divulgación para los clientes que reúnan los requisitos a través de nuestro Centro de confianza. También contratamos a una empresa independiente que realiza pruebas de penetración al menos una vez por año natural para evaluar el estado de las aplicaciones, la red y la nube. Los hallazgos identificados se corrigen de acuerdo con una matriz de niveles de servicio basada en la gravedad (crítico en un plazo de treinta días, alto en sesenta, medio en noventa y bajo en ciento veinte días).

2,5 Riesgo Administración

Un programa formal de gestión de riesgos evalúa las amenazas a los activos, la probabilidad de explotación y el posible impacto empresarial. Los resultados sirven de base para las asignaciones presupuestarias, las mejoras de control y la planificación de la recuperación ante desastres.

2,6 Estado informativo de los controles

Impulsum mantiene políticas y controles que reflejan nuestra alineación con las mejores prácticas de la industria y los estándares regulatorios. Sin embargo, todas estas medidas están sujetas a revisiones periódicas, mejoras continuas y un panorama de amenazas en evolución. Este documento ilustra esos controles actuales, pero no constituye una representación de las capacidades futuras.

2.7 Confidencialidad de las medidas de seguridad

Para proteger la integridad de nuestra infraestructura de seguridad, ciertos detalles técnicos y configuraciones se consideran información confidencial y no se divulgan públicamente. Toda la documentación, los resultados de las auditorías o los diagramas lógicos que se compartan con los clientes se proporcionan con arreglo a las restricciones de confidencialidad que se describen en nuestras condiciones y en los acuerdos pertinentes.

2.8 Prácticas de desidentificación

De acuerdo con los principios de privacidad desde el diseño, Impulsum emplea técnicas de desidentificación para eliminar o enmascarar los identificadores directos e indirectos de los conjuntos de datos de los clientes antes de usarlos para análisis internos, pruebas de seguridad o evaluación de modelos. Estas medidas están diseñadas para garantizar que los datos resultantes no puedan vincularse razonablemente con una persona, y está prohibida la reidentificación, excepto para validar la eficacia del proceso de anonimización.

ARTÍCULO III: SEGURIDAD DE LA INFRAESTRUCTURA

3.1 Entorno de alojamiento en la nube

Impulsum se basa en Amazon Web Services como su principal proveedor de infraestructura. Las cargas de trabajo principales se implementan en tres zonas de disponibilidad dentro de la región este de EE. UU., de AWS para garantizar la tolerancia a errores. La residencia de los datos en los Estados Unidos está garantizada, a menos que el cliente elija una implementación regional una vez que dicha función esté disponible de forma general.

3.2 Segmentación de red y firewalls

Las redes de producción están segmentadas lógicamente desde la puesta en escena y el desarrollo. Los grupos de seguridad y las listas de control de acceso a la red restringen estrictamente el tráfico entrante y saliente. Solo los hosts de bastión reforzados pueden iniciar sesiones administrativas, y todas estas sesiones requieren una autenticación multifactor y se registran de forma centralizada.

3.3 Cifrado en tránsito

Todas las comunicaciones entre los terminales de los usuarios, nuestros servidores y los procesadores posteriores se realizan a través de la versión 1.2 o superior de Transport Layer Security. Los conjuntos de cifrado débiles y los protocolos obsoletos (por ejemplo, SSLv3) están deshabilitados. La administración de certificados está totalmente automatizada con AWS Certificate Manager.

3.4 Cifrado en reposo

Los datos de los clientes, incluidas las instantáneas de respaldo, se cifran en reposo con las claves administradas por el cliente de AWS Key Management Service con el estándar de cifrado avanzado que emplea una longitud de clave de doscientos cincuenta y seis bits. Las claves se rotan anualmente o de forma inmediata si se sospecha que están comprometidas.

3.5 Fortalecimiento de la infraestructura

Las imágenes del sistema operativo se originan en líneas base reforzadas de Amazon Linux o Ubuntu LTS e incorporan puntos de referencia de nivel 1 del Center for Internet Security. Se eliminan los paquetes y servicios innecesarios, y un sistema de administración de la configuración impone el cumplimiento básico desde el momento del lanzamiento y de forma continua a partir de entonces.

3,6 Análisis de vulnerabilidades

Los escaneos de vulnerabilidad externos e internos se realizan con una cadencia semanal. Los hallazgos se clasifican de acuerdo con las puntuaciones del CVSS y se parchean según la misma matriz de niveles de servicio que se indica en la cláusula 2.4.

ARTÍCULO IV: FLUJO Y MANEJO DE DATOS

4.1 Clasificación de datos

Clasificamos los datos en cuatro categorías: públicos, internos, confidenciales y restringidos. Los artefactos del proyecto sincronizados desde Jira y otras integraciones se consideran restringidos, lo que genera el nivel de protección más alto.

4,2 Diagrama de flujo de datos

Cuando un usuario emite una consulta en lenguaje natural, el cliente transmite la consulta, los identificadores de proyecto relevantes y cualquier contexto requerido al punto final de la API Impulsum. El backend obtiene los datos de proyecto más recientes de Jira y de cualquier otro sistema de gestión de proyectos de terceros integrado mediante API u OAuth, como, entre otros, Jira, Trello, Asana, ClickUp y Monday.com, mediante tokens de API con ámbito de OAuth, enriquece esos datos con funciones predictivas y empaqueta el mensaje resultante para GPT-4 u otros modelos de lenguaje configurados. Las respuestas modelo se procesan posteriormente en nuestros servidores y luego se devuelven al cliente a través de un canal cifrado. Un diagrama lógico completo está disponible a pedido.

4.3 Ubicaciones de almacenamiento

Los datos de las aplicaciones transaccionales residen en Amazon Relational Database Service. Los índices de búsqueda funcionan en Amazon OpenSearch. Los registros de auditoría se envían a Amazon CloudWatch y se conservan durante siete años. Las copias de seguridad en frío se almacenan en Amazon Simple Storage Service con la replicación entre regiones habilitada.

4.4 Datos Minimización

Almacenamos solo los datos necesarios para ofrecer la funcionalidad contratada. Los archivos efímeros que contienen instantáneas de los proyectos del cliente se eliminan en un plazo de veinticuatro horas, a menos que el cliente habilite explícitamente el almacenamiento en caché analítico.

4,5 Segregación de datos

El aislamiento de los inquilinos se aplica mediante esquemas de bases de datos únicos con la clave de un identificador de inquilinos y mediante la lógica de la aplicación que valida las solicitudes de los inquilinos en todos los límites de datos.

ARTÍCULO V: GESTIÓN DE IDENTIDAD Y ACCESO

5.1 autenticación

Los clientes pueden autenticarse con credenciales de plataforma con un motor de complejidad y un mínimo de doce caracteres, o mediante el inicio de sesión único mediante SAML 2.0 u OpenID Connect. Todas las cuentas administrativas requieren una autenticación multifactor.

5.2 Autorización

El control de acceso basado en roles se ajusta al principio de privilegio mínimo. Las funciones predefinidas incluyen propietario, administrador, administrador y visor. Los roles personalizados están disponibles para los clientes empresariales. Las solicitudes de escalamiento de privilegios se registran y requieren una doble aprobación.

5.3 Almacenamiento de credenciales

Las contraseñas de los usuarios se cifran con Argon2ID configurado para diez iteraciones, ochenta megabytes de memoria y cuatro subprocesos paralelos. Los secretos de las aplicaciones, como los tokens de API, se almacenan en AWS Secrets Manager y se rotan al menos cada noventa días.

5,4 Administración de sesiones

Los Web Tokens JSON firmados con RSA cuatro mil noventa y seis bits representan sesiones y caducan después de sesenta minutos de inactividad de forma predeterminada. Los tokens de actualización están sujetos a estrictos controles de origen y se pueden revocar a través del panel de control.

5.5 Acceso de empleados

Solo los empleados asignados a los equipos de ingeniería o soporte pueden acceder a los datos de producción y únicamente con fines comerciales legítimos. Todos los accesos tienen un límite de tiempo, se basan en solicitudes y se revocan automáticamente. Los registros de auditoría muestran el solicitante, el revisor, el propósito y la duración.

ARTÍCULO VI: SEGURIDAD DE LAS APLICACIONES

6.1 Segura Ciclo de vida del desarrollo

Los desarrolladores siguen un SDLC que incorpora puntos de control de seguridad en las etapas de planificación, diseño, implementación, revisión del código, pruebas e implementación. El modelado de amenazas es obligatorio para todos los proyectos épicos de funciones nuevas. Las revisiones del código deben ser realizadas por un autor y dos aprobadores, de los cuales al menos uno tenga formación en seguridad.

6.2 Gestión de dependencias

Un repositorio central aplica las confirmaciones de procedencia y confirmaciones de procedencia firmadas para las bibliotecas de terceros. Los manifiestos estáticos se escanean a diario con herramientas como OWASP Dependency‑Check y Snyk. Las dependencias de alto riesgo se parchean o reemplazan en un plazo de treinta días.

6.3 Análisis estático y dinámico

Los artefactos compilados estáticamente son analizados por CodeQL en cada solicitud de extracción. Un conjunto de pruebas de seguridad dinámicas que se realizan todas las noches pone a prueba el entorno de ensayo con Zed Attack Proxy y escenarios personalizados que abarcan la autenticación, la inyección y la creación de scripts entre sitios.

6,4 Canalización de construcción e implementación

La canalización de integración continua se ejecuta dentro de contenedores aislados de AWS CodeBuild. Los artefactos se firman con doscientos cincuenta y seis resúmenes de SHA‑y se publican en Amazon Elastic Container Registry. Solo los artefactos firmados pueden implementarse en producción a través de AWS CodeDeploy, con una reversión automática de las comprobaciones de estado fallidas.

6,5 Registro y monitoreo

Los registros de aplicaciones estructurados incorporan identificadores de solicitud únicos, identificadores de usuario (con hash) y geolocalización aproximada. Las cargas sensibles, como los campos de datos personales, están enmascaradas. Un sistema de gestión de eventos e información de seguridad recopila los registros casi en tiempo real y activa alertas sobre patrones anómalos.

ARTÍCULO VII: SEGURIDAD DEL MODELO DE INTELIGENCIA ARTIFICIAL Y GOBERNANZA DE DATOS

7,1 Proveedores de modelos

La inferencia principal del modelo de lenguaje grande la proporciona OpenAI GPT-Four, hospedado en los Estados Unidos. Entre los proveedores secundarios, evaluados para determinar la paridad en cuanto a la postura de seguridad, se encuentran Anthropic Claude y Google Gemini. Mantenemos acuerdos de retención cero con todos los proveedores de modelos de IA, incluidos, entre otros, OpenAI, Anthropic, Google Gemini o equivalentes, y nos aseguramos de que no se utilicen los datos de los clientes con fines de formación. No mantenemos ninguna infraestructura ni subprocesador en ninguna jurisdicción sujeta a requisitos de localización de datos que entren en conflicto con las regulaciones de exportación de los Estados Unidos.

7.2 Acuerdos de retención cero

Todos los proveedores de modelos han establecido cláusulas contractuales sin retención en las que se comprometen a no almacenar los datos puntuales o de finalización durante más de treinta días y a no utilizar nunca dichos datos para la formación o la mejora del servicio. Estos acuerdos de retención cero están sujetos a las leyes de exportación de EE. UU. y a las restricciones de localización de datos, e Impulsum prohíbe contractualmente cualquier uso de los datos puntuales de los clientes con fines de formación, excepto cuando se permita explícitamente por escrito.

7.3 Construcción rápida

El ensamblaje rápido se produce en el lado del servidor en un microservicio sin estado. Las solicitudes incluyen solo el contexto mínimo viable para realizar predicciones precisas. La información de identificación personal se tokeniza antes de su transmisión siempre que sea posible.

7,4 Modo confidencial

Los clientes empresariales pueden habilitar el modo confidencial, una función de privacidad obligatoria que evita que cualquier parte de los datos sincronizados del proyecto persista más allá de la sesión inmediata y evita el almacenamiento en caché analítico. Las réplicas de servicios dedicadas al modo confidencial excluyen todos los registros de la capa de aplicación. Si una solicitud es ambigua con respecto al modo, el sistema pasa al modo confidencial de forma predeterminada. En el modo confidencial, los datos no persisten más allá de la sesión y ayudan a mitigar los riesgos de sesgo en virtud de leyes como la Ley de Privacidad de Colorado (CPA) al limitar la exposición de mensajes confidenciales a cualquier proveedor de IA (incluidos, entre otros, OpenAI, Anthropic o Google Gemini). En los casos de uso de alta sensibilidad, incluidos aquellos sujetos a las obligaciones de gestión de riesgos de la IA a nivel estatal, como la Ley de Inteligencia Artificial de Colorado, se recomienda encarecidamente a los clientes que eviten introducir datos confidenciales o propensos a sesgos en las instrucciones y que operen exclusivamente en modo confidencial para reducir el riesgo de sesgos inadvertidos o de persistencia no intencionada de los datos.

7,5 Modelo Fine‑tuning

Las actividades de ajuste fino utilizan conjuntos de datos sintéticos o totalmente anónimos. Los datos de los clientes nunca se introducen en un proceso de ajuste de datos sin un anexo de procesamiento de datos independiente que permita explícitamente dicho uso. Los datos de los clientes nunca se utilizan para el perfeccionamiento o la formación de modelos, a menos que un anexo independiente sobre el procesamiento de datos permita expresamente dicho uso. Impulsum recomienda encarecidamente habilitar el modo confidencial en entornos regulados para evitar que los datos rápidos persistan en los registros de terceros durante el período de retención temporal.

ARTÍCULO VIII: SUBPROCESADORES Y SERVICIOS DE TERCEROS

8.1 Clasificación de subprocesadores

Mantenemos una lista publicada de subprocesadores autorizados agrupados por nivel de exposición de datos. Las categorías son:

un. Ve y almacena los datos del proyecto

b. Ve los datos del proyecto (transitorios)

c. Solo ve datos personales

d. No ve datos de clientes

8.2 Inventario de subprocesadores principales

El inventario actual se proporciona en la tabla siguiente y se actualiza al menos treinta días antes de incorporar cualquier subprocesador nuevo que vea o almacene los datos del proyecto.

‍

‍

8.3 Diligencia y supervisión

Cada subprocesador se somete a una evaluación de riesgos del proveedor, que incluye la revisión de las certificaciones de cumplimiento, las pruebas de penetración y los compromisos contractuales de confidencialidad, privacidad y notificación de incidentes.

8,4 Garantías legales y contractuales

Todos los subprocesadores que accedan, almacenen o procesen datos de clientes o proyectos deben ejecutar acuerdos escritos que contengan obligaciones estrictas de confidencialidad, protección de datos y notificación de infracciones. Impulsum garantiza que los subprocesadores cumplan con los requisitos aplicables de transferencia y localización de datos y que sean evaluados en función de las certificaciones de cumplimiento (como la ISO 27001, el SOC 2 y la PCI DSS), la postura de seguridad y la aplicabilidad contractual. Cuando los subprocesadores presten servicios modelo de IA (incluidos, entre otros, OpenAI, Anthropic y Google), dichos subprocesadores están obligados contractualmente a cumplir con las leyes de control de exportaciones de EE. UU., las restricciones de localidad de datos aplicables y a cumplir con los compromisos de retención cero y no formación de los datos de los clientes, a menos que un anexo de procesamiento de datos firmado y explícito permita dicho uso. La retención por parte de dichos subprocesadores, si la hubiera, se limita a los períodos operativos temporales descritos en nuestra Política de privacidad (actualmente hasta treinta días).

8,5 Integración con fuentes de datos de clientes

El uso de sistemas de gestión de proyectos de terceros (por ejemplo, Jira, Trello, Asana) mediante integraciones de API supone que el cliente tiene los derechos suficientes para autorizar a Impulsum a acceder a dichos datos y procesarlos. Impulsum cumple con todos los términos de la API aplicables e impone límites de acceso y almacenamiento de acuerdo con nuestros protocolos internos de gestión de datos.

ARTÍCULO IX: GESTIÓN Y DIVULGACIÓN DE VULNERABILIDADES

9,1 Pruebas internas

Nuestro ingeniero de seguridad realiza revisiones manuales de código mensuales y ejercicios de equipo rojo para corregir las fallas de la lógica empresarial.

9,2 Canal de informes externo

Se anima a los investigadores de seguridad a enviar informes de vulnerabilidad a través de https://github.com/impulsum‑security/vuln‑reports. Reconocemos las presentaciones en un plazo de cinco días hábiles y actualizamos el estado al menos cada catorce días hasta el cierre.

9.3 Programa de recompensas

Se puede conceder una recompensa discrecional por informes originales y válidos que generen cambios en el código o la configuración. El alcance, las recompensas y los términos se detallan en el portal de divulgación.

9,4 Período de no divulgación

Los investigadores deben abstenerse de divulgar información pública hasta que se haya implementado una solución o hayan transcurrido noventa días, lo que ocurra primero, a menos que se acuerde lo contrario.

ARTÍCULO X: RESPUESTA A INCIDENTES Y NOTIFICACIÓN DE INCUMPLIMIENTO

10,1 Plan de respuesta a incidentes

Un plan formal establece las fases de preparación, identificación, contención, erradicación, recuperación y lecciones aprendidas. Las rotaciones de guardia garantizan una disponibilidad de veinticuatro horas.

10,2 Detección y alertas

Las alertas automatizadas se activan cuando se producen patrones de autenticación inusuales, inicios de sesión fallidos excesivos, exportaciones de datos anómalas o desviaciones de los umbrales de referencia de la red.

10,3 Comunicación con el cliente

En caso de que se confirme una violación que involucre los datos de los clientes, Impulsum notificará a los clientes afectados sin demora indebida y a más tardar setenta y dos horas después de la confirmación, proporcionándoles los hechos conocidos, el alcance del impacto, los pasos de mitigación y los puntos de contacto. Todas las notificaciones cumplirán con las leyes de notificación de infracciones aplicables, incluidas las leyes estatales recientemente promulgadas, como la Ley de privacidad de datos en línea de Maryland (MODPA), que exigen la divulgación de las categorías de información afectada, los posibles daños y las medidas de mitigación específicas adoptadas.

10,4 Coordinación regulatoria

Si un incidente implica datos personales de residentes de la UE o obliga a Impulsum a informar obligatoriamente en virtud de las leyes estatales de incumplimiento, el asesor legal coordinará las presentaciones con las autoridades supervisoras.

10,5 Excepciones de aplicación de la ley

De acuerdo con las leyes estatales y federales aplicables, la notificación de incumplimiento a los clientes afectados puede retrasarse si la policía lo solicita por escrito si dicha divulgación pudiera impedir una investigación penal o representar un riesgo para la seguridad nacional. Impulsum documentará y conservará dichas solicitudes de demora cuando corresponda. Por motivos de coherencia, las notificaciones de incumplimiento también se ajustarán a los procesos y plazos descritos en nuestra Política de privacidad, garantizando la coherencia entre todos los compromisos asumidos con los clientes.

ARTÍCULO XI: SEGURIDAD DEL LADO DEL CLIENTE

11,1 Navegadores compatibles

Admitimos las dos últimas versiones estables de Chrome, Firefox, Safari y Edge. El uso de navegadores no compatibles puede reducir los controles de seguridad, como el cumplimiento de la política de seguridad del contenido.

11,2 Política de seguridad del contenido

La aplicación web define una política estricta que limita las fuentes de scripts a impulsum.me, Cloudflare CDN y los subdominios enumerados en la cláusula 3.2. Los scripts en línea no están permitidos excepto cuando es necesario y, a continuación, se protegen con códigos de autenticación de mensajes basados en hash.

11,3 Cookies seguras

Las cookies de sesión se marcan como Secure, HttpOnly y SameSite Strict. Caducan después de sesenta minutos de inactividad.

11,4 Seguridad de extensiones

Cuando introduzcamos extensiones de navegador o escritorio, se firmará cada compilación y se publicarán las sumas de verificación. Las extensiones solo se comunican con los puntos finales de impulsum.me y nunca incorporan rastreadores de terceros.

ARTÍCULO XII: SEGURIDAD FÍSICA Y AMBIENTAL

12,1 Controles del centro de datos

Los centros de datos de AWS cumplen con los estándares de seguridad física reconocidos por el sector, incluidos el acceso con credenciales, los escáneres biométricos, la supervisión de televisión por circuito cerrado y el personal de seguridad in situ.

12,2 Corporativo Instalaciones

Impulsum opera primero como una empresa remota. La infraestructura física mínima (espacios de colaboración compartidos y una oficina registrada) no aloja datos de clientes. Los portátiles fabricados por la empresa utilizan el cifrado completo del disco, el bloqueo de pantalla automático y el borrado remoto.

ARTÍCULO XIII: GESTIÓN DEL CAMBIO Y DESARROLLO SEGURO

13,1 Tablero de control de cambios

Todos los cambios que se produzcan en la producción requieren la aprobación de un consejo de administración compuesto por ingeniería, seguridad, operaciones y gestión de productos. Las soluciones de emergencia siguen un proceso rápido, pero se someten a una revisión retrospectiva en un plazo de veinticuatro horas.

13,2 Control de versiones y reversión

Cada versión se etiqueta en Git y se asigna a los resúmenes de imágenes del contenedor. La reversión a una versión anterior válida conocida se automatiza mediante las implementaciones de CodeDeploy de color azul y verde.

13,3 Infraestructura como código

Todos los recursos de la nube se aprovisionan con Terraform. Los archivos de los planes se revisan por pares y se escanean con una política como motor de código para detectar configuraciones riesgosas (como puertos abiertos o cubos S3 públicos).

ARTÍCULO XIV: CONTINUIDAD EMPRESARIAL Y RECUPERACIÓN ANTE DESASTRES

14,1 Estrategia de respaldo

Las copias de seguridad incrementales se ejecutan cada quince minutos, con copias de seguridad completas sintéticas diarias. Los datos de respaldo se conservan durante treinta días en una región de AWS separada físicamente y se cifran con una jerarquía de claves secundarias.

14,2 Objetivos de punto y tiempo de recuperación

El objetivo estándar del punto de recuperación es de quince minutos. El objetivo de tiempo de recuperación para los servicios críticos es de cuatro horas. Las pruebas anuales de conmutación por error validan estos objetivos.

14,3 Pandemia y continuidad de la fuerza laboral

Las funciones críticas se pueden ejecutar de forma remota, y todo el personal esencial posee soluciones de alimentación y acceso a Internet redundantes.

ARTÍCULO XV: TERMINACIÓN DE LA CUENTA Y ELIMINACIÓN DE DATOS

15,1 Eliminación por autoservicio

Los clientes pueden iniciar la eliminación de la cuenta en el menú Configuración ▸ Avanzado. La verificación se completa mediante la autenticación multifactor.

15,2 flujo de trabajo de eliminación

En un plazo de veinticuatro horas, Impulsum programa la eliminación de las filas activas de la base de datos, los índices de búsqueda y los resultados analíticos almacenados en caché. Las copias de seguridad en frío que contienen los datos del cliente se eliminan en un plazo de treinta días.

15,3 Implicaciones de la formación modelo

Si el cliente deshabilitó el modo confidencial en algún momento, es posible que partes de sus datos residan en registros de mensajes guardados temporalmente por los proveedores de modelos. Esos registros caducan dentro del período contractual de treinta días. Impulsum no incorporará los datos eliminados de los clientes en ninguna actividad futura de perfeccionamiento o capacitación.

15,4 Aceptación por parte del cliente del riesgo de retención de registros modelo

Cuando un cliente desactiva el modo confidencial, reconoce y acepta que ciertos datos efímeros (como las indicaciones y las respuestas) pueden ser almacenados temporalmente (hasta 30 días) por proveedores de modelos externos únicamente por motivos de integridad operativa, sujeto a los compromisos de retención cero detallados en la sección 7.2. Se recomienda encarecidamente a los clientes que operan en entornos de alta sensibilidad que habiliten el modo confidencial en todo momento.

ARTÍCULO XVI: CERTIFICACIONES E INFORMES DE AUDITORÍA

16,1 Informe SOC 2

El último informe del SOC 2 de tipo II que cubre los criterios de seguridad, disponibilidad y confidencialidad de los servicios de confianza está disponible a pedido en virtud de un acuerdo de confidencialidad.

16,2 Hoja de ruta de certificación ISO 27001

Estamos en proceso de obtener la certificación ISO 27001:2022 con una fecha de finalización prevista para el segundo trimestre de veintiséis. Una vez certificados, el certificado y la declaración de aplicabilidad aparecerán en nuestro Centro de confianza.

16,3 Auditorías de clientes

Los clientes empresariales pueden, una vez por período de doce meses y con un aviso por escrito de sesenta días, realizar una auditoría de seguridad o designar a un auditor independiente con sujeción a los términos de confidencialidad mutuamente acordados. Todas las auditorías deben evitar interferir en las operaciones de producción y respetar la confidencialidad de los demás clientes. Las auditorías no deben exponer la información confidencial de otros clientes ni revelar configuraciones sensibles a la seguridad que no estén relacionadas con el entorno del cliente solicitante.

16,4 Confidencialidad y no exención de responsabilidad

Todas las certificaciones, resúmenes de auditoría y documentos de seguridad compartidos con los clientes son confidenciales y no pueden reproducirse ni divulgarse sin el consentimiento previo por escrito de Impulsum. Compartir dichos materiales no constituye una renuncia a ninguna exención de responsabilidad o limitación de responsabilidad establecida en los Términos y condiciones o en cualquier acuerdo aplicable.

ARTÍCULO XVII: INFORMES, PREGUNTAS E INFORMACIÓN DE CONTACTO

17,1 Consultas de seguridad

Si tiene preguntas de seguridad, envíe un correo electrónico a info@impulsum.me. Las solicitudes de soporte rutinarias deben seguir utilizando info@impulsum.me o el chat de la aplicación. Todas las solicitudes de informes de seguridad o documentación de cumplimiento están sujetas a requisitos de confidencialidad y no divulgación y deben cumplir con las políticas de protección de datos y control de acceso de Impulsum.

17,2 Notificaciones urgentes

Si descubres una vulnerabilidad de alta gravedad que afecta a Impulsum u observas una actividad sospechosa que se cree que compromete los datos de los clientes, ponte en contacto con el puente de incidentes de veinticuatro horas escribiendo a info@impulsum.me. No incluyas información confidencial sobre las vulnerabilidades por voz. Proporcione un número de llamada y una prueba de concepto cifrada a través de PGP a nuestra bandeja de entrada de seguridad.

ARTÍCULO XVIII: MANTENIMIENTO Y REVISIÓN DE DOCUMENTOS

18,1 Calendario de revisiones

El Comité Directivo de Seguridad revisa este documento de seguridad al menos una vez al año o antes si se producen cambios importantes en los servicios, la infraestructura o las obligaciones reglamentarias. Las revisiones también se llevarán a cabo con prontitud tras la promulgación de nuevas e importantes leyes de privacidad o seguridad de los datos, incluida, entre otras, la Ley de protección de la información y de inteligencia artificial responsable de Tennessee (TIPRA), para garantizar que los controles reflejen los requisitos legales más recientes, como la minimización de datos y las normas de gobernanza de la IA.

18,2 Control de versiones

La versión canónica reside en la base de conocimiento corporativa con etiquetas de versión semánticas. El historial de cambios, que incluye la descripción, el autor, el revisor y la fecha de aprobación, se conserva durante siete años.

18,3 Fecha de entrada en vigor

Esta versión entrará en vigor el 8 de agosto de 2025 y sustituirá a todas las versiones anteriores.