Política de Evaluación de Riesgos
Política operativa interna. Rige el proceso de evaluación y gestión de riesgos de seguridad, tecnológicos y regulatorios de Lawra, S.R.L. Aprobada por la Asamblea en [__]. Versión: 1.0.
1. Propósito y Alcance
1.1. Esta política establece el marco formal mediante el cual Lawra, S.R.L. identifica, analiza, evalúa y trata los riesgos que puedan comprometer la confidencialidad, integridad o disponibilidad de sus activos de información, sus operaciones y los datos de sus clientes.
1.2. — Aplica a: todos los socios, empleados, contratistas, sistemas, procesos y activos de información de Lawra, incluyendo los servicios gestionados por sub-procesadores.
1.3. — Objetivos:
- Identificar riesgos antes de que se materialicen en incidentes;
- Priorizar recursos de mitigación de forma racional y documentada;
- Cumplir con los criterios SOC 2 CC3.1–CC3.4 y CC9.1;
- Mantener un Registro de Riesgos actualizado y auditable.
2. Marco Metodológico
2.1. Lawra adopta una metodología de evaluación de riesgos inspirada en NIST SP 800-30 Rev. 1 (Guide for Conducting Risk Assessments) y alineada con ISO/IEC 27005 para la gestión del riesgo de seguridad de la información.
2.2. — Fórmula base:
Nivel de Riesgo = Probabilidad (Likelihood) × Impacto (Impact)2.3. — Escalas de medición:
| Valor | Probabilidad (Likelihood) | Impacto (Impact) |
|---|---|---|
| 1 | Muy baja — ocurrencia excepcional (≤1 vez en 5 años) | Mínimo — sin interrupción material |
| 2 | Baja — ocurrencia esporádica (1 vez en 2-5 años) | Bajo — interrupción menor, recuperable en horas |
| 3 | Moderada — posible dentro de 12 meses | Moderado — interrupción de 1-3 días, pérdida financiera limitada |
| 4 | Alta — probable dentro de 6 meses | Alto — pérdida de cliente(s), exposición legal, daño reputacional |
| 5 | Muy alta — inminente o recurrente | Crítico — interrupción prolongada, violación grave de datos, cierre operativo |
2.4. — Matriz de riesgo resultante:
| Impacto 1 | Impacto 2 | Impacto 3 | Impacto 4 | Impacto 5 | |
|---|---|---|---|---|---|
| Prob. 5 | 5 | 10 | 15 | 20 | 25 |
| Prob. 4 | 4 | 8 | 12 | 16 | 20 |
| Prob. 3 | 3 | 6 | 9 | 12 | 15 |
| Prob. 2 | 2 | 4 | 6 | 8 | 10 |
| Prob. 1 | 1 | 2 | 3 | 4 | 5 |
Umbrales de tolerancia:
- 1–5: Riesgo bajo — aceptable con monitoreo.
- 6–12: Riesgo medio — plan de mitigación requerido dentro de 90 días.
- 13–19: Riesgo alto — acción prioritaria dentro de 30 días.
- 20–25: Riesgo crítico — acción inmediata; informar a la Asamblea.
3. Inventario de Activos
3.1. El proceso de evaluación de riesgos depende de un inventario actualizado de activos que incluya, como mínimo:
| Categoría | Ejemplos |
|---|---|
| Datos | Base de datos de clientes, historiales de conversación del AI Suite, registros de suscriptores, documentos legales cargados |
| Software / Aplicaciones | lawra.io (Astro), AI Suite backend (Firebase), repositorio de código fuente (GitHub), pipelines de CI/CD |
| Infraestructura | Firebase project, Google Cloud Platform, servicios de AI (Gemini, OpenAI), CDN (GitHub Pages) |
| Endpoints | Computadoras corporativas, laptops personales con acceso corporativo (BYOD) |
| Personal | Empleados, contratistas, socios fundadores con acceso a sistemas |
| Físico | Oficinas, medios de almacenamiento externos, documentos impresos confidenciales |
3.2. El inventario es mantenido por el CTO con colaboración del Oficial de Cumplimiento. Se actualiza al menos trimestralmente y siempre que se incorpore un nuevo sistema o proveedor crítico.
3.3. Cada activo debe tener asignado un propietario de activo responsable de su protección y de informar cambios que alteren su perfil de riesgo.
4. Catálogo de Amenazas
4.1. Lawra reconoce las siguientes categorías de amenazas en su modelo de riesgo:
4.1.1. — Amenazas internas (Insider Threats):
- Empleado o contratista malintencionado con acceso a datos de clientes o código fuente;
- Error humano: borrado accidental, configuración incorrecta, envío de información a destinatario equivocado;
- Uso no autorizado de credenciales corporativas;
- Fuga de información mediante dispositivos personales no gestionados.
4.1.2. — Amenazas externas (External Threats):
- Phishing / spear-phishing dirigido a empleados o socios;
- Credential stuffing / brute force sobre cuentas de Firebase o Google Workspace;
- Vulnerabilidad en dependencias de software (supply chain attack);
- Ransomware o malware en endpoints;
- Ataque de denegación de servicio (DDoS) a lawra.io.
4.1.3. — Amenazas regulatorias:
- Incumplimiento de Ley 172-13 (protección de datos personales);
- Violación de GDPR aplicable a clientes europeos;
- Incumplimiento de condiciones contractuales de sub-procesadores (cambios unilaterales de TOS por parte de proveedores de AI);
- Cambio normativo que afecte el modelo de negocio de AI legal (ej. regulación de sistemas de AI de alto riesgo).
4.1.4. — Amenazas de terceros / cadena de suministro:
- Brecha de seguridad en proveedor crítico (Google Firebase, Gemini API, GitHub);
- Sub-procesador que incumple obligaciones del DPA;
- Proveedor que cesa operaciones o es adquirido, afectando continuidad del servicio;
- Acceso indebido por contratista externo.
4.1.5. — Amenazas ambientales / continuidad:
- Corte de luz o conectividad en ubicaciones de trabajo del equipo;
- Desastre natural que afecte el acceso a sistemas o equipos;
- Indisponibilidad de servicios cloud críticos (Firebase / GCP outage).
4.1.6. — Amenazas específicas de IA (AI-specific Risks):
- Alucinaciones del modelo: respuestas incorrectas o fabricadas que el cliente puede tomar como asesoramiento legal válido;
- Prompt injection: usuario malintencionado que manipula el sistema prompt de los asistentes de Lawra para extraer información, suplantar roles o evadir controles;
- Data leakage en LLM: envío inadvertido de datos confidenciales de un cliente a los logs o contexto de otro;
- Model drift: cambio en el comportamiento del modelo base (Gemini, OpenAI) que afecta calidad o seguridad de las respuestas;
- Dependencia de proveedor único: interrupción o cambio de precios de un proveedor AI que compromete la operación del producto.
5. Proceso de Evaluación de Riesgos
5.1. — Ciclo anual:
- Convocatoria: El Oficial de Cumplimiento convoca la evaluación anual en el Q4 de cada año, o a más tardar en enero del año siguiente.
- Actualización del inventario de activos (antes de iniciar la evaluación).
- Identificación de nuevas amenazas incorporando cambios tecnológicos, normativos y operativos del período.
- Puntuación de riesgos por el equipo (Oficial de Cumplimiento + CTO + representante de cada área funcional).
- Clasificación y priorización según la matriz de la Sección 2.
- Definición de tratamiento para cada riesgo calificado ≥6 (ver Sección 6).
- Actualización del Registro de Riesgos (ver Sección 7).
- Presentación de resultados a la Asamblea de Socios dentro de los 30 días siguientes.
5.2. — Evaluaciones ad-hoc: Se realizarán evaluaciones fuera del ciclo anual ante:
- Incorporación de un nuevo sistema, proveedor o proceso crítico;
- Incidente de seguridad relevante;
- Cambio normativo material;
- Solicitud justificada de un socio o del Oficial de Cumplimiento.
5.3. — Revisión trimestral del Registro: El CTO y el Oficial de Cumplimiento revisan trimestralmente el estado de los planes de tratamiento activos y actualizan el nivel de riesgo residual para los 5 riesgos de mayor puntuación.
6. Opciones de Tratamiento de Riesgos
6.1. Para cada riesgo identificado con puntuación ≥6, el propietario del riesgo selecciona una de las siguientes estrategias:
| Estrategia | Descripción | Cuándo aplicar |
|---|---|---|
| Mitigar | Implementar controles para reducir probabilidad y/o impacto | Cuando el costo del control es inferior al costo del riesgo materializado |
| Aceptar | Reconocer el riesgo y no tomar acción adicional | Solo para riesgos bajos (1–5) o cuando mitigación es desproporcionada |
| Transferir | Contratar seguro, externalizar responsabilidad, incluir limitaciones de responsabilidad en contratos | Cuando el riesgo residual no puede eliminarse completamente internamente |
| Evitar | Discontinuar la actividad o activo que genera el riesgo | Cuando el riesgo crítico no tiene mitigación viable |
6.2. Riesgos críticos (20–25) no pueden ser simplemente aceptados sin aprobación explícita de la Asamblea y documentación del razonamiento.
6.3. — Asignación de propietario de riesgo: Cada riesgo tiene un propietario nominalmente responsable de ejecutar el plan de tratamiento y reportar el estado en cada revisión trimestral. El propietario es típicamente el director del área funcional más relevante.
7. Registro de Riesgos (Risk Register)
7.1. El Oficial de Cumplimiento mantiene un Registro de Riesgos actualizado que incluye por cada entrada:
| Campo | Descripción |
|---|---|
| ID | Identificador único (ej. R-2025-001) |
| Fecha de identificación | Cuándo fue identificado el riesgo |
| Activo(s) afectado(s) | Referencia al inventario de activos |
| Amenaza | Descripción de la amenaza y escenario |
| Vulnerabilidad | Debilidad que permite que la amenaza se materialice |
| Probabilidad | Puntuación 1–5 con justificación |
| Impacto | Puntuación 1–5 con justificación |
| Riesgo inherente | Prob × Impacto |
| Controles existentes | Controles actuales que ya reducen el riesgo |
| Riesgo residual | Riesgo tras controles existentes |
| Estrategia de tratamiento | Mitigar / Aceptar / Transferir / Evitar |
| Plan de acción | Acciones concretas con responsable y fecha límite |
| Propietario del riesgo | Persona responsable |
| Estado | Abierto / En progreso / Cerrado / Aceptado |
| Fecha de próxima revisión | — |
7.2. El Registro de Riesgos se almacena en un repositorio confidencial con acceso restringido a socios y al Oficial de Cumplimiento. No se comparte externamente salvo requerimiento regulatorio o auditoría SOC 2.
8. Comunicación y Concienciación
8.1. Los resultados agregados de la evaluación anual (sin detallar vulnerabilidades específicas) son comunicados a todos los empleados para fortalecer la cultura de seguridad.
8.2. Los riesgos críticos son informados a la Asamblea de Socios con suficiente detalle para la toma de decisiones, incluyendo implicaciones financieras, legales y operativas.
9. Referencias Normativas
Esta política se basa en:
- NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments
- ISO/IEC 27001:2022 — Anexo A, Sección 6.1 (Acciones para tratar riesgos)
- ISO/IEC 27005:2022 — Gestión del riesgo de seguridad de la información
- SOC 2 Trust Services Criteria: CC3.1, CC3.2, CC3.3, CC3.4, CC9.1
- Ley No. 172-13 (R.D.) — Art. 26 (medidas de seguridad adecuadas al riesgo)
- GDPR Art. 32 — Análisis de riesgo para medidas de seguridad apropiadas
- Ley No. 53-07 (R.D.) — Crímenes y Delitos de Alta Tecnología
10. Revisión y Modificación
Esta política se revisa anualmente junto con el ciclo de evaluación de riesgos, o ante cambios materiales en la operación, el entorno de amenazas o el marco normativo aplicable.
Próxima revisión: [fecha de adopción + 12 meses].
Adoptada por la Asamblea General de Socios de LAWRA, S.R.L. en fecha [__], conforme consta en el Libro de Actas.
Por LAWRA, S.R.L. — Gerente
Comments
Loading comments...