diff --git a/SECURITY & TESTING.md b/SECURITY & TESTING.md
new file mode 100644
index 0000000..968fcde
--- /dev/null
+++ b/SECURITY & TESTING.md	
@@ -0,0 +1,226 @@
+# SECURITY & TESTING – Roles, Permisos y Estética
+
+Este documento define los **criterios de seguridad, control de acceso y pruebas** del sistema HR Platform, así como lineamientos visuales para mantener una estética **minimalista y consistente**.
+
+Su objetivo es garantizar que el sistema sea **seguro, verificable y gobernable**, incluso antes de escalar a producción.
+
+---
+
+## 1. Lineamientos de estética (UI / UX)
+
+### 1.1 Principios visuales
+
+* Estilo **minimalista**: menos ruido, más claridad.
+* Jerarquía visual clara.
+* Interfaces predecibles.
+* Priorizar legibilidad sobre decoración.
+
+---
+
+### 1.2 Paleta
+
+* Base: **Catppuccin Latte**.
+* Fondos claros, suaves.
+* Contrastes suficientes para accesibilidad.
+* Acentos discretos (no saturados).
+
+---
+
+### 1.3 Iconografía
+
+Se permite el uso de:
+
+* **Catppuccin Icons**.
+* **Google Material Icons**.
+
+Reglas:
+
+* Uso consistente.
+* Tamaños uniformes.
+* Íconos funcionales, no decorativos.
+
+---
+
+## 2. Modelo de seguridad
+
+### 2.1 Principios
+
+* **Menor privilegio** por defecto.
+* Todo acceso es explícito.
+* Los permisos se configuran, no se codifican.
+* La seguridad es verificable mediante pruebas.
+
+---
+
+## 3. Tipos de usuario
+
+El sistema acepta **tres tipos de usuario**.
+
+---
+
+### 3.1 Root
+
+Rol reservado para control total del sistema.
+
+Permisos:
+
+* Acceso completo a todos los módulos.
+* Gestión de configuraciones globales.
+* Definición de roles y permisos.
+* Acceso a logs y eventos.
+* Gestión de webhooks.
+
+Este rol debe existir en número mínimo.
+
+---
+
+### 3.2 Admin
+
+Rol operativo con permisos elevados.
+
+Permisos típicos:
+
+* Crear, editar y consultar socias.
+* Aprobar o rechazar vacaciones.
+* Aprobar o rechazar permisos.
+* Consultar reportes.
+* Acceso limitado a configuraciones.
+
+No puede:
+
+* Cambiar reglas globales críticas.
+* Modificar permisos del rol Root.
+
+---
+
+### 3.3 User
+
+Rol estándar.
+
+Permisos base:
+
+* Ver información permitida.
+* Crear solicitudes propias (vacaciones, permisos).
+* Modificar únicamente campos explícitamente autorizados.
+
+No puede:
+
+* Ver información sensible global.
+* Editar reglas.
+* Aprobar solicitudes.
+
+---
+
+## 4. Sistema granular de permisos
+
+### 4.1 Modelo
+
+El sistema utiliza un **modelo granular basado en checkboxes**, no en roles rígidos.
+
+Cada permiso es una bandera configurable.
+
+Ejemplos:
+
+* `socias.read`
+* `socias.update`
+* `vacaciones.create`
+* `vacaciones.approve`
+* `permisos.read`
+* `config.edit`
+
+---
+
+### 4.2 Niveles
+
+Los permisos pueden aplicarse a:
+
+* Rol completo.
+* Usuario específico.
+* Módulo.
+* Acción.
+
+Esto permite combinaciones finas sin crear nuevos roles.
+
+---
+
+### 4.3 UI de permisos
+
+* Interfaz con **checkboxes**.
+* Agrupación por módulo.
+* Visualización clara de lo permitido y lo bloqueado.
+* Cambios auditados.
+
+---
+
+## 5. Control de acceso
+
+* Middleware de autorización en backend.
+* Validación por permiso, no solo por rol.
+* Reglas evaluadas en tiempo de ejecución.
+
+---
+
+## 6. Pruebas de seguridad
+
+### 6.1 Tests de roles
+
+* Verificar acceso correcto por rol.
+* Validar bloqueos esperados.
+* Intentos de escalación de privilegios.
+
+---
+
+### 6.2 Tests de permisos granulares
+
+* Usuario con permisos parciales.
+* Usuario con combinaciones específicas.
+* Revocación dinámica de permisos.
+
+---
+
+### 6.3 Tests de endpoints
+
+* Acceso autorizado.
+* Acceso denegado.
+* Manipulación de payload.
+
+---
+
+### 6.4 Tests de eventos y webhooks
+
+* Emisión solo desde acciones válidas.
+* No emisión desde acciones no autorizadas.
+* Registro correcto de eventos.
+
+---
+
+## 7. Auditoría
+
+* Registro de:
+
+  * Cambios de permisos.
+  * Accesos críticos.
+  * Acciones administrativas.
+
+* Logs inmutables.
+
+---
+
+## 8. Criterios de aceptación de seguridad
+
+El sistema se considera válido cuando:
+
+* Un usuario nunca puede hacer más de lo permitido.
+* Todos los accesos están trazados.
+* Los permisos pueden cambiar sin deploy.
+* Las pruebas cubren roles y permisos.
+
+---
+
+## 9. Nota final
+
+La seguridad no es una capa.
+
+Es una **propiedad emergente** del diseño.
+
+Este documento define cómo se prueba y cómo se protege el sistema.