ISO 27001 · catálogo en autoevaluación
93 controles catalogados en autoevaluación · 4 dominios (Org 37 / People 8 / Physical 14 / Tech 34) · 15 CRITICAL + 43 HIGH + 29 MEDIUM + 6 LOW. No es una certificación.
Qué es esto (y qué NO es)
iForja cataloga en autoevaluación los 93 controles del Anexo A de ISO/IEC 27001:2022 dentro de core/forja/core/compliance.py, con su estado, prioridad y evidencia mapeada. Esto NO es una certificación ISO 27001 ni una afirmación de cumplimiento del 100 %: es la infraestructura de compliance que deja el sistema listo para preparar una certificación, con el catálogo estructurado y la evidencia trazable que un auditor necesita como punto de partida.
Catálogo completo
Cada control se declara con este contrato en core/forja/core/compliance.py:
# Cada control del Anexo A se declara como tupla catalogada:
# (control_id, domain, name, priority)
# ej. ("A.5.31", "Organizational", "Legal, statutory, regulatory...", "critical")
#
# En base de datos (ComplianceControl) se enriquece con:
# status # implemented | in_progress | not_started
# evidence_paths # paths a artifacts que respaldan el control
# implemented_in # commit / file de referencia
Las 4 familias del Anexo A · distribución verificada
Recuento real contado directamente sobre el catálogo del código:
Distribución por prioridad
critical 15 controles (nunca aceptables sin implementar)
high 43 controles (implementación obligatoria pre-auditoría)
medium 29 controles (implementación recomendada)
low 6 controles (best-effort)
─────────────────────────────────────
93 controles
Los controles con severidad HIGH o CRITICAL deben estar
implementedovalidatedantes de release. Objetivo de score en autoevaluación: ≥ 85 % pre-auditoría + 100 % de los HIGH/CRITICAL validados (calculate_compliance_scoreencore/forja/core/compliance.py).
Endpoints
Rutas reales expuestas por core/forja/api/routes/compliance.py (bajo prefijo /api):
GET /api/compliance/controls · listado completo (filtrable por severity)
GET /api/compliance/controls/{control_id} · detalle + evidencia
PATCH /api/compliance/controls/{control_id} · actualizar status
POST /api/compliance/controls/{control_id}/evidence · adjuntar evidencia
GET /api/compliance/status · estado agregado + score
GET /api/compliance/report · informe institucional (markdown)
GET /api/compliance/verify-integrity · verificación de la hash chain
Los 15 controles CRITICAL · lista completa
Extraída literalmente del catálogo (priority="critical"):
| ID | Dominio | Nombre | Status / Evidencia |
|---|---|---|---|
| A.5.15 | Organizational | Access control | implemented · RBAC HMAC + tenant scope |
| A.5.16 | Organizational | Identity management | implemented · tabla users + audit |
| A.5.17 | Organizational | Authentication information | implemented · password bcrypt + cookie HMAC |
| A.5.18 | Organizational | Access rights | implemented · 3 roles (viewer/operator/admin) |
| A.5.31 | Organizational | Legal, statutory, regulatory and contractual requirements | implemented · ADR-0011 (EU AI Act gap analysis) |
| A.5.34 | Organizational | Privacy and protection of PII | in_progress · PII masking en security_postfilter.py |
| A.8.2 | Technological | Privileged access rights | implemented · approval workflow HIGH risk |
| A.8.3 | Technological | Information access restriction | implemented · jail + workspace sandboxing |
| A.8.5 | Technological | Secure authentication | implemented · ADR-0008 rate limit /ui/login |
| A.8.8 | Technological | Management of technical vulnerabilities | implemented · pip-audit en hardening checks |
| A.8.13 | Technological | Information backup | implemented · backup_daily.sh + check_backup_freshness |
| A.8.15 | Technological | Logging | implemented · audit_events + SHA-256 chain (ADR-0007) |
| A.8.20 | Technological | Networks security | implemented · deny-by-default outbound |
| A.8.24 | Technological | Use of cryptography | implemented · RSA-2048 License Runtime Layer |
| A.8.25 | Technological | Secure development life cycle | implemented · ADRs + tests + gate ORO |
Los 43 HIGH controles · acceso completo
La lista es demasiado larga para una tabla legible. Acceso directo:
GET /api/compliance/controls?severity=high
# devuelve los 43 con status + evidence_paths
# o desde la DB:
sqlite3 forja.db "SELECT id, name, status FROM compliance_controls WHERE severity='high' ORDER BY id;"
Familias agrupadas (orientativo):
- A.5.1–A.5.14 · políticas organizativas
- A.5.19–A.5.30 · supplier + incident management
- A.6.1–A.6.8 · people (onboarding + training)
- A.7.1–A.7.14 · físicos (clear desk, secure disposal)
- A.8.x · tecnológicos adicionales
Score actual
El score depende del nivel de evidencia real recolectada, no solo del catálogo:
- Score declarativo (catálogo solo): 93/93 controles identificados
- Score con evidencia parcial (alpha-ready): subconjunto de HIGH/CRITICAL con artifact paths
- Score con evidencia completa (auditor-ready): 93/93 con artifacts referenciados
Nota de honestidad: identificar un control no equivale a haberlo implementado ni a tener su evidencia recolectada. El score de autoevaluación distingue explícitamente ambos planos.
Informe institucional
GET /api/compliance/report genera un informe en markdown que combina:
- Estado por control + evidencia mapeada
- Score por dominio (A.5 / A.6 / A.7 / A.8)
- Verificación tamper-evident de la hash chain del audit log (embebida en el documento)
- Aislamiento por tenant: el
tenant_idse deriva de la identidad firmada del principal, nunca de un query param
Es un material de partida para preparar una auditoría (SOC 2 / ISO 27001 / ENS): entrega el catálogo, el estado y la evidencia trazable en un único documento. No sustituye la auditoría formal ni constituye una certificación.