ATALAIALa mayoría de los conjuntos de políticas de seguridad se escriben para auditores y no los lee nadie más. Ocupan decenas de páginas, describen herramientas que se sustituyeron hace dos años y se actualizan a toda prisa antes de cada certificación. Los ingenieros aprenden que la política es algo que les pasa una vez al año.
Creemos que es al revés. Una política solo sirve si quienes construyen y operan los sistemas pueden leerla en unos minutos, reconocer su propio trabajo en ella y ver que se comprueba automáticamente. Así las escribiríamos.
Mejor corto que completo
Una buena política de ingeniería cabe en una pantalla. Dice qué debe ser cierto, quién es responsable y cómo sabrás que se cumple. Deja el cómo para estándares y runbooks, que pueden cambiar sin revisar la política.
Policy: Source code changes
Owner: Head of Engineering
Applies to: all repositories that build or deploy production software
1. Changes to default branches go through a pull request.
2. At least one reviewer who is not the author approves the change.
3. Secrets are never committed; CI blocks commits that contain them.
4. Exceptions are recorded with an owner and an expiry date.
Checked by: branch protection export and CI job results, monthly.Esa es toda la política. Cualquiera puede saber en un minuto si su repositorio la cumple. Una versión larga con contexto, definiciones y nombres de herramientas va en un estándar aparte que enlace aquí.
Asocia enunciados a controles
Cada línea numerada de una política debería mapearse al menos a un control, y cada control a un responsable y una comprobación. Si una línea no tiene ningún control detrás, añade uno o bórrala.
| Línea de políticas | Control | Responsable | Comprobar |
|---|---|---|---|
| Los cambios pasan por una pull request | Protección de branch en las ramas por defecto | Equipo de plataforma | Exportación de la API de control de código fuente |
| Revisión independiente | Aprobaciones obligatorias, sin autoaprobación | Equipo de plataforma | Misma exportación, ajustes de revisión |
| Sin secretos en el repositorio | Gitleaks en CI, push protection | Seguridad | Resultados de los jobs de CI por repositorio |
| Excepciones registradas | Registro de excepciones con caducidad | Seguridad | Revisión del registro, elementos caducados marcados |
Esta tabla es también lo que los auditores quieren ver de verdad. Muestra diseño, responsabilidad y operación en un solo lugar.
Evidencias del pipeline, no capturas de pantalla
Lo peor de la mayoría de las auditorías es la recopilación de evidencias: capturas de pantallas de ajustes, reunidas a mano, ciertas solo una tarde. Tus plataformas ya conocen las respuestas. Pregúntales con una periodicidad fija y guarda el resultado.
- RecogerUn job programado consulta las APIs de control de código, CI y nube para obtener los ajustes de los que depende cada control.
- EvaluarLos resultados se comparan con la política y dan pass, fail o excepción por activo.
- GuardarLa salida en bruto y los resultados se escriben en un bucket append-only con la fecha en la ruta.
- InformarLos responsables ven los fallos como tickets; los auditores ven el historial.
# evidence: default-branch protection, one JSON file per run
gh api repos/your-org/payments-api/branches/main/protection \
> "evidence/$(date -u +%F)/payments-api-branch-protection.json"Cuando la evidencia viene de la propia línea, la política deja de ser un documento y pasa a ser un conjunto de comprobaciones con responsable.
Dónde encajan los frameworks
Los equipos suelen partir de un marco y bajar hasta la política. Normalmente es más fácil al revés. SOC 2 e ISO 27001 esperan políticas documentadas, responsables asignados y evidencias de que los controles funcionan con el tiempo. NIS2 trae obligaciones de gestión de riesgos y notificación de incidentes para las organizaciones dentro de su ámbito. El Cyber Resilience Act de la UE añade requisitos para productos con elementos digitales, incluidos la gestión de vulnerabilidades y el desarrollo seguro durante todo el periodo de soporte del producto.
Las políticas cortas y mapeadas con evidencias automatizadas sirven para todo esto, porque todos premian lo mismo: controles que se demuestra que funcionan. Si un marco concreto te aplica y qué exige exactamente es una pregunta para tus asesores legales y de cumplimiento. Este artículo no es asesoramiento legal.
Qué haríamos
- Elige tus tres políticas más importantes, normalmente cambios en el código fuente, gestión de accesos y gestión de vulnerabilidades, y reescríbelas para que quepan en una pantalla.
- Construye la tabla de correspondencias para esos tres. Borra cualquier línea que no tenga un control.
- Automatiza una comprobación de evidencia este mes, guarda su salida con fecha y enséñasela al responsable.
- Fija una fecha de revisión en cada política y ponla en un calendario, no en el pie del documento.
Cuando los ingenieros pueden leer la política, ver la comprobación y arreglar el fallo ellos mismos, la auditoría pasa a ser una revisión de trabajo ya hecho.
Dónde encaja en la línea
En la torre (en desarrollo):