Plan de Respuesta ante Incidentes — Sherlock-docs v1.0¶
Sistema: Sherlock-docs v1.0
Entidad: Centro de Servicios Judiciales de Bello, Antioquia — Rama Judicial
Marco normativo: Ley 1581/2012 (Art. 17), Ley 1712/2014, Decreto 1377/2013, CONPES 4144 (2025), Acuerdo PCSJA24-12243, Ley 2502/2025
Fecha: 2026-03-19
Ultima actualizacion: 2026-04-02
Version: 2.0 (Actualizada con normativa 2025 — requiere revision juridica)
Referencia interna: GOB-15
Elaborado por: Equipo de desarrollo Sherlock-docs
Documentos relacionados: DATA_GOVERNANCE.md (§9), AI_ETHICS.md (§8.3), POLITICA_TRATAMIENTO_DATOS.md
1. Proposito y Alcance¶
1.1 Proposito¶
Este documento establece el procedimiento operativo para la deteccion, contencion, evaluacion, notificacion, remediacion y documentacion de incidentes de seguridad y datos en el sistema Sherlock-docs.
Complementa y operacionaliza el protocolo de alto nivel descrito en DATA_GOVERNANCE.md §9, proporcionando:
- Plantillas de registro de incidentes
- Responsables con datos de contacto
- Tiempos SLA por nivel de severidad
- Procedimientos de escalamiento
- Cumplimiento de la obligacion de notificacion a la SIC (Art. 17, Ley 1581 de 2012)
1.2 Alcance¶
Este plan aplica a todos los incidentes que afecten:
- Datos personales: Nombres, identificaciones y datos de contacto procesados por OCR/NER
- Datos judiciales: Contenido de tutelas, habeas corpus y documentos asociados
- Infraestructura: Servidor VPS, contenedores Docker, base de datos SQLite
- Disponibilidad: Interrupciones del servicio que afecten la operacion del CSJ
1.3 Definiciones¶
| Termino | Definicion |
|---|---|
| Incidente de seguridad | Evento que compromete la confidencialidad, integridad o disponibilidad de datos o sistemas |
| Incidente de datos personales | Incidente que involucra acceso, perdida, alteracion o divulgacion no autorizada de datos personales (Art. 17, Ley 1581) |
| Incidente etico | Comportamiento del sistema de IA que genera resultados sesgados, discriminatorios o incorrectos con impacto en derechos fundamentales |
| SIC | Superintendencia de Industria y Comercio — autoridad de proteccion de datos personales en Colombia |
| SLA | Acuerdo de Nivel de Servicio (Service Level Agreement) — tiempo maximo de respuesta segun severidad |
2. Clasificacion de Incidentes¶
2.1 Tipos de incidentes¶
| ID | Tipo | Ejemplo | Severidad |
|---|---|---|---|
| INC-01 | Acceso no autorizado | Login con credenciales comprometidas, acceso SSH no autorizado | Alta |
| INC-02 | Perdida de datos | Corrupcion de la base de datos sin backup reciente | Alta |
| INC-03 | Fuga de datos | Acceso externo al servidor por vulnerabilidad, exposicion de datos personales | Critica |
| INC-04 | Alteracion indebida | Modificacion de entidades NER o registros sin autorizacion | Media |
| INC-05 | Indisponibilidad | Servidor caido por mas de 4 horas | Media |
| INC-06 | Error sistematico IA | Sesgo NER que clasifica incorrectamente demandados/demandantes de forma sistematica | Alta |
| INC-07 | Vulnerabilidad descubierta | CVE en dependencia critica (PaddleOCR, Streamlit, etc.) | Alta |
2.2 Niveles de severidad¶
| Nivel | Criterio | Ejemplos |
|---|---|---|
| Critica | Datos personales expuestos a terceros no autorizados; impacto en derechos fundamentales | INC-03 |
| Alta | Perdida de datos, acceso no autorizado, error sistematico de IA con impacto operacional | INC-01, INC-02, INC-06, INC-07 |
| Media | Alteracion parcial de datos, indisponibilidad temporal, errores puntuales de procesamiento | INC-04, INC-05 |
| Baja | Incidentes menores sin impacto en datos personales ni en la operacion judicial | Errores de formato, lentitud temporal |
3. Roles y Responsabilidades¶
3.1 Equipo de respuesta a incidentes¶
| Rol | Responsabilidad principal | Contacto |
|---|---|---|
| Coordinador CSJ Bello | Decision final sobre escalamiento, comunicacion institucional, aprobacion de acciones correctivas | [A completar por la entidad] |
| Oficial de Proteccion de Datos | Evaluacion de impacto en datos personales, notificacion a SIC si aplica, seguimiento regulatorio | [Pendiente designacion — a completar por la entidad] |
| Administrador de TI | Contencion tecnica, analisis forense, restauracion de backups, aplicacion de parches | [A completar por la entidad] |
| Operador | Deteccion inicial, reporte de anomalias, preservacion de evidencia en su estacion | [A completar por la entidad] |
3.2 Matriz RACI por fase¶
| Fase | Coordinador CSJ | Oficial PDP | Admin TI | Operador |
|---|---|---|---|---|
| Deteccion | I | I | R | R |
| Contencion | A | C | R | I |
| Evaluacion | A | R | R | I |
| Notificacion (SIC) | A | R | C | I |
| Remediacion | A | C | R | I |
| Documentacion | A | R | R | I |
| Seguimiento | A | R | C | I |
R = Responsable (ejecuta), A = Aprueba, C = Consultado, I = Informado
4. Protocolo de Respuesta¶
4.1 Fase 1: Deteccion¶
Objetivo: Identificar el incidente lo antes posible.
Fuentes de deteccion:
- Logs de auditoria del sistema (audit_events table)
- Logs rotativos de aplicacion (Streamlit, OCR, NER)
- Reporte manual de operadores o usuarios
- Alertas de monitoreo de infraestructura (disco, CPU, conectividad)
- Resultado del comando CLI sherlock audit-report
Acciones inmediatas: 1. El detector (Operador o Admin TI) registra la hora exacta de deteccion 2. Clasifica el incidente segun la tabla §2.1 3. Asigna severidad segun §2.2 4. Notifica al Administrador de TI (inmediato para Critica/Alta, <2h para Media/Baja)
4.2 Fase 2: Contencion¶
Objetivo: Limitar el impacto del incidente.
| Severidad | Tiempo maximo de contencion | Acciones tipicas |
|---|---|---|
| Critica | 30 minutos | Aislar servidor, suspender acceso externo, preservar logs |
| Alta | 2 horas | Deshabilitar componente afectado, restringir accesos |
| Media | 8 horas | Monitoreo intensivo, restriccion parcial si es necesario |
| Baja | 24 horas | Registro y monitoreo |
Acciones de contencion:
- Suspender acceso al sistema si hay fuga de datos activa
- Aislar el contenedor Docker afectado (docker stop sherlock-docs)
- Preservar logs y snapshots antes de cualquier remediacion
- No borrar ni modificar evidencia
4.3 Fase 3: Evaluacion¶
Objetivo: Determinar el alcance e impacto del incidente.
Preguntas de evaluacion: 1. ¿Que datos fueron afectados? (personales, judiciales, operativos) 2. ¿Cuantos titulares de datos estan potencialmente impactados? 3. ¿Hubo acceso por terceros no autorizados? 4. ¿El incidente esta contenido o continua activo? 5. ¿Existe obligacion de notificacion a la SIC? (Art. 17, Ley 1581)
Criterios para notificacion obligatoria a SIC: - Datos personales sensibles comprometidos (Art. 5, Ley 1581) - Mas de 10 titulares afectados - Evidencia de acceso externo no autorizado - Fuga de datos con identificaciones, nombres o datos de contacto
4.4 Fase 4: Notificacion¶
Objetivo: Informar a las partes interesadas segun la severidad.
| Destinatario | Critica | Alta | Media | Baja |
|---|---|---|---|---|
| Coordinador CSJ Bello | Inmediato | <2h | <24h | Reporte semanal |
| Oficial de Proteccion de Datos | Inmediato | <2h | <24h | Reporte mensual |
| Superintendencia de Industria y Comercio (SIC) | <15 dias habiles (*) | Evaluar | No | No |
| Titulares afectados | <15 dias habiles (*) | Evaluar | No | No |
| Consejo Superior de la Judicatura | Evaluar | No | No | No |
(*) Art. 17, Ley 1581 de 2012: El responsable del tratamiento debe informar a la SIC y a los titulares cuando se presenten vulneraciones a los codigos de seguridad que generen riesgo en la administracion de la informacion.
4.5 Fase 5: Remediacion¶
Objetivo: Resolver la causa raiz y restaurar la operacion normal.
Acciones por tipo de incidente:
| Tipo | Acciones de remediacion |
|---|---|
| INC-01 (Acceso no autorizado) | Cambiar credenciales, revisar logs de acceso, reforzar autenticacion |
| INC-02 (Perdida de datos) | Restaurar desde backup (scripts/deploy/backup-sherlock.sh), verificar integridad |
| INC-03 (Fuga de datos) | Parchear vulnerabilidad, cambiar credenciales, notificar SIC |
| INC-04 (Alteracion indebida) | Restaurar datos originales, revisar permisos, auditar cambios |
| INC-05 (Indisponibilidad) | Reiniciar servicios Docker, escalar recursos si es necesario |
| INC-06 (Error IA) | Evaluar metricas NER (F1), ajustar pipeline, re-procesar documentos afectados |
| INC-07 (Vulnerabilidad) | Actualizar dependencia, reconstruir imagen Docker, verificar con tests |
4.6 Fase 6: Documentacion y lecciones aprendidas¶
Objetivo: Registrar el incidente completo y prevenir recurrencia.
- Completar la Plantilla de Registro de Incidente (§5)
- Archivar en
docs/governance/incidents/con nombreINC-YYYY-MM-DD-NNN.md - Realizar reunion post-mortem (Critica/Alta: obligatorio, Media: recomendado)
- Actualizar procedimientos si se identifican mejoras
- Registrar en la tabla de incidentes del reporte de auditoria
5. Plantilla de Registro de Incidente¶
# Registro de Incidente INC-YYYY-MM-DD-NNN
## Informacion General
| Campo | Valor |
|-------|-------|
| **ID del incidente** | INC-YYYY-MM-DD-NNN |
| **Fecha y hora de deteccion** | |
| **Fecha y hora de contencion** | |
| **Fecha y hora de resolucion** | |
| **Reportado por** | |
| **Tipo de incidente** | (INC-01 a INC-07, ver §2.1) |
| **Severidad** | Critica / Alta / Media / Baja |
## Descripcion del Incidente
[Descripcion detallada de lo ocurrido, incluyendo como se detecto]
## Datos Afectados
| Campo | Valor |
|-------|-------|
| **Tipo de datos** | Personales / Judiciales / Operativos |
| **Numero de titulares afectados** | |
| **Documentos afectados** | |
| **Periodo de exposicion** | |
## Acciones Tomadas
### Contencion
[Acciones inmediatas para limitar el impacto]
### Evaluacion
[Analisis del alcance e impacto]
### Notificaciones realizadas
| Destinatario | Fecha | Medio | Responsable |
|-------------|-------|-------|-------------|
| | | | |
### Remediacion
[Acciones correctivas aplicadas]
## Causa Raiz
[Analisis de la causa raiz del incidente]
## Lecciones Aprendidas
[Mejoras identificadas para prevenir recurrencia]
## Seguimiento
| Accion preventiva | Responsable | Fecha limite | Estado |
|-------------------|-------------|:--:|--------|
| | | | |
## Firmas
| Rol | Nombre | Firma | Fecha |
|-----|--------|-------|-------|
| Elaboro | _________________ | _______ | _______ |
| Coordinador CSJ | _________________ | _______ | _______ |
| Oficial PDP | _________________ | _______ | _______ |
6. Tiempos SLA por Severidad¶
| Severidad | Deteccion → Contencion | Contencion → Evaluacion | Evaluacion → Notificacion | Resolucion total |
|---|---|---|---|---|
| Critica | 30 min | 2 horas | 4 horas | 24 horas |
| Alta | 2 horas | 4 horas | 8 horas | 48 horas |
| Media | 8 horas | 24 horas | 48 horas | 5 dias habiles |
| Baja | 24 horas | 48 horas | Reporte periodico | 10 dias habiles |
Nota: Los tiempos de notificacion a la SIC estan regulados por la Ley 1581 de 2012. El plazo maximo de 15 dias habiles aplica para incidentes que generen riesgo en la administracion de datos personales.
7. Escalamiento¶
7.1 Ruta de escalamiento¶
Operador → Administrador de TI → Coordinador CSJ Bello
↓
Oficial de Proteccion de Datos
↓ (si aplica)
SIC (Art. 17, Ley 1581)
↓ (si aplica)
Consejo Superior de la Judicatura
7.2 Criterios de escalamiento¶
| Condicion | Escalar a |
|---|---|
| Incidente no contenido en tiempo SLA | Siguiente nivel jerarquico |
| Datos personales comprometidos | Oficial de Proteccion de Datos (inmediato) |
| Fuga de datos confirmada | Coordinador CSJ + Oficial PDP (inmediato) |
| Impacto en mas de 10 titulares | Coordinador CSJ + evaluar notificacion SIC |
| Error sistematico de IA con impacto en derechos | Coordinador CSJ + Oficial PDP |
8. Medidas Preventivas¶
8.1 Controles tecnicos implementados¶
| Control | Implementacion en Sherlock-docs |
|---|---|
| Autenticacion | Streamlit auth con credenciales cifradas (bcrypt) |
| Auditoria | Tabla audit_events con registro de todas las operaciones |
| Backups | Script backup-sherlock.sh (diario, retencion 30 dias) |
| Docker non-root | Contenedor ejecuta como usuario no privilegiado |
| Logs rotativos | Rotacion automatica para diagnostico y forense |
| HTTPS | Traefik con certificados Let's Encrypt |
| Firewall | UFW con whitelist de puertos |
8.2 Revisiones periodicas¶
| Actividad | Frecuencia | Responsable |
|---|---|---|
| Revision de logs de auditoria | Semanal | Administrador de TI |
Ejecucion de sherlock audit-report |
Mensual | Coordinador CSJ |
| Verificacion de backups | Semanal | Administrador de TI |
| Actualizacion de dependencias | Mensual | Administrador de TI |
| Simulacro de incidente | Semestral | Coordinador CSJ + Admin TI |
9. Marco Legal Aplicable¶
| Norma | Articulo relevante | Aplicacion |
|---|---|---|
| Ley 1581 de 2012 | Art. 17 | Obligacion de informar vulneraciones de seguridad a la SIC y titulares |
| Ley 1581 de 2012 | Art. 5 | Definicion de dato sensible — criterio para clasificar severidad |
| Ley 1581 de 2012 | Art. 6 | Excepciones al consentimiento en contexto judicial |
| Decreto 1377 de 2013 | Arts. 14-15 | Procedimiento de notificacion de incidentes |
| Ley 1712 de 2014 | Art. 18 | Excepciones de acceso a informacion — datos personales en expedientes |
| CONPES 3975 | Principio de seguridad | Medidas tecnicas y organizativas para proteger datos en sistemas IA |
| Acuerdo PCSJA24-12243 | Art. 9 | Supervision humana obligatoria de resultados de IA |
| Acuerdo PCSJA24-12243 | Art. 10 | Transparencia en el uso de herramientas de IA |
10. Historial de Versiones¶
| Version | Fecha | Cambio | Autor |
|---|---|---|---|
| 1.0 | 2026-03-19 | Documento inicial — operacionaliza GOB-15 | Equipo de desarrollo |
11. Aprobaciones¶
| Rol | Nombre | Firma | Fecha |
|---|---|---|---|
| Coordinador CSJ Bello | _____ | _ | _ |
| Oficial de Proteccion de Datos | _____ | _ | _ |
| Administrador de TI | _____ | _ | _ |
| Area Juridica CSJ | _____ | _ | _ |
Este documento es un borrador tecnico preparado por el equipo de desarrollo. Debe ser revisado, completado y aprobado por el area juridica del Centro de Servicios Judiciales de Bello antes de su aplicacion.
Referencias: Ley 1581 de 2012 (Art. 17), Ley 1712 de 2014, Decreto 1377 de 2013, CONPES 3975, Acuerdo PCSJA24-12243 Version: 1.0 (Borrador) — 2026-03-19