Plan de Respuesta a Incidentes de Seguridad en Repositorios Documentales: Guía para Empresas en Perú

La cadena de sanciones regulatorias: un solo incidente, múltiples reguladores

El error más crítico en respuesta a incidentes es tratar una brecha documental como problema exclusivamente técnico. En Perú, un repositorio comprometido activa hasta seis reguladores de forma simultánea, cada uno con plazos, sanciones y criterios de supervisión distintos. La tabla siguiente mapea esta realidad:

El contador de 48 horas de la ANPD

El DS 016-2024-JUS impone el plazo más exigente: 48 horas desde que la organización confirma el incidente, no desde que comenzó el ataque ni desde el reporte de terceros. La confirmación requiere evidencia técnica verificada: archivos con extensiones modificadas, alertas de SIEM, logs con patrones anómalos o instrucciones del atacante.

La notificación debe especificar descripción de los hechos, categorías y volumen de datos personales comprometidos, número estimado de titulares afectados y medidas de contención implementadas hasta ese momento. Si los derechos de los titulares están en riesgo directo, la notificación a ellos debe realizarse en el mismo plazo. Incumplir este plazo sin justificación válida convierte una infracción grave en muy grave, incrementando la sanción base significativamente.

Lección del caso Interbank: credenciales de terceros sin auditoría

En octubre de 2024, un actor identificado como “kzoldyck” utilizó credenciales robadas de New Relic, herramienta de monitoreo que Interbank empleaba para supervisar sus sistemas. Con permisos privilegiados, accedió a información de aproximadamente tres millones de clientes, transacciones y expedientes de empleados. El banco rechazó pagar; los datos se publicaron en foros clandestinos.

La lección documental es precisa: el acceso de proveedores externos con permisos elevados equivale a dejar la bóveda de documentos bajo administración de terceros sin auditoría continua. Esto requiere dos controles inmediatos: auditoría trimestral de credenciales de proveedores y revocación automática tras rotación de credenciales corporativas. Para microformas bajo D.L. 681, la comprensión de este riesgo es aún más crítica porque el documento original en papel ya no existe; el costo de una pérdida es jurídicamente irreversible.

Clasificación de severidad por tipo de documento: la matriz P0-P3

No todos los documentos generan el mismo impacto regulatorio si se comprometen. Esperar a evaluarlos durante un incidente activo cuesta horas críticas. La clasificación debe estar predefinida.

Escenario extremo: microformas bajo el Decreto Ley 681

El D.L. 681 permite que una microforma digital certificada conforme a NTP 392.030-2:2015 (con auditoría de entidad acreditada como SGS) tenga el mismo valor probatorio que el documento original en papel. Tras la certificación, la empresa puede destruir el original físico legalmente. En operaciones normales, esto optimiza almacenamiento. En un incidente de ransomware, se convierte en el escenario más crítico posible: si el repositorio se cifra sin backup certificado con cadena de custodia verificable, la empresa pierde el único soporte legal del documento. No existe recurso al papel destruido. La pérdida es jurídicamente irreversible y no puede remediarse restringiendo acceso futuro.

Plan de respuesta en 7 fases

Fase 1 — Preparación (antes del incidente)

La preparación determina si la respuesta dura horas o semanas. Comprende cinco elementos:

Inventario y clasificación documental. Identificar todos los repositorios (servidor local, nube, sistemas heredados, archivos compartidos no supervisados) y clasificar cada tipo de documento según P0-P3. Documentar el plazo legal de retención: tributario (5 años), laboral y SST (entre 5 y 20 años según tipo de registro), judicial (según la causa activa). Una empresa sin este inventario no tiene forma de evaluar severidad durante un incidente.

Equipo de respuesta con roles definidos. El equipo mínimo es: Líder IT o CISO (decisiones técnicas inmediatas), Abogado corporativo (implicancias legales y regulatorias), Oficial de Datos o DPO (obligaciones DS 016-2024-JUS), Responsable de Comunicaciones (mensajes a clientes, prensa y reguladores), y Gerencia General (decisiones ejecutivas sobre P0 y P1 en menos de 30 minutos). Cada rol tiene autoridad documentada y cadena de escalonamiento clara.

Canales fuera de banda. El correo corporativo puede estar comprometido en el mismo incidente. Los números de teléfono del equipo de respuesta deben estar impresos en papel e integrados en aplicaciones de mensajería cifrada alternativas (Signal, por ejemplo). Esta información no puede existir solo en el servidor bajo ataque.

Plantillas pre-redactadas. Redactar bajo presión de 48 horas es fuente de errores legales. Preparar con antelación: notificación a ANPD (estructura formal, evitar admisiones de responsabilidad), comunicado a usuarios afectados (tono empático, medidas concretas), comunicado a prensa (revisado por Legal, sin especulaciones). Las plantillas aceleran la notificación y mejoran su calidad.

Backups certificados probados. La regla 3-2-1-1-0 debe estar implementada y verificada. Un backup nunca restaurado no es un backup; es una esperanza. La probabilidad de que funcione cuando más se necesita es cercana a cero.

Fase 2 — Detección y análisis (primeras 2 horas)

Confirmar el incidente. ¿Es real o falso positivo? La evidencia concreta incluye: extensiones de archivo modificadas masivamente en repositorios críticos, alerta de SIEM o antimalware con firma confirmada, logs de acceso con patrones anómalos (volumen masivo, usuarios fuera de horario, IP no corporativas), o archivos de rescate con instrucciones del atacante.

Iniciar el contador de 48 horas de la ANPD. Documentar formalmente: quién detectó el incidente, en qué momento exacto, con qué evidencia, quién confirmó la brecha, qué datos están comprometidos. Esta documentación es la base del informe regulatorio posterior y prueba de que la empresa actuó dentro del plazo.

Recopilación de información inicial. Determinar qué repositorios están comprometidos, si contienen datos personales (DNI, correos, teléfonos, datos de salud), si hay datos financieros (SBS) o tributarios (SUNAT). Si la respuesta es afirmativa respecto a datos personales, la ANPD se activa automáticamente.

Fase 3 — Clasificación de severidad

Aplicar la matriz P0-P3 a los documentos confirmados como comprometidos. Si el resultado es P0 o P1, se activa el equipo completo de respuesta inmediatamente, se notifica a Gerencia General en menos de 30 minutos y se inicia el proceso de notificación regulatoria. Cada clasificación debe quedar documentada: quién tomó la decisión, en qué momento, con qué justificación.

Fase 4 — Contención (menos de 4 horas para P0/P1)

Aislar el repositorio comprometido mediante desconexión lógica inmediata de la red corporativa. Esto previene la propagación a otros sistemas. Punto crítico: no apagar los servidores afectados durante esta fase, porque apagar destruye evidencia forense en memoria RAM (claves de cifrado activas, procesos de malware en ejecución que podrían revelar su origen).

Revocar inmediatamente todos los tokens de acceso, sesiones activas y contraseñas de cuentas de servicio relacionadas con el repositorio comprometido. Esto incluye credenciales de proveedores integrados, APIs y sincronizaciones automáticas.

Crear un snapshot forense del estado completo del sistema comprometido, incluyendo malware, logs de acceso, archivos cifrados y procesos activos. Esta imagen debe transferirse a hardware aislado sin conexión a la red principal y mantenerse bajo cadena de custodia para eventual denuncia penal ante la Fiscalía de Ciberdelitos.

Fase 5 — Erradicación (4 a 48 horas)

Analizar el vector de entrada: ¿explotación de vulnerabilidad CVE conocida? ¿Credencial comprometida por phishing? ¿Acceso de tercero sin MFA? ¿Token de API robado?

Si fue CVE, aplicar el parche en todos los sistemas antes de restaurar datos. Si fue credencial comprometida, investigar el mecanismo de robo y rotar todas las credenciales privilegiadas: contraseñas de administrador, cuentas de servicio, tokens de API, certificados digitales. Para terceros sin acceso con MFA, establecer autenticación multifactor obligatoria en todas las futuras credenciales privilegiadas.

Eliminar el malware completamente. Para ransomware sofisticado, esto puede requerir análisis de código por especialista externo para garantizar que no quedan puertas traseras.

Fase 6 — Recuperación (entre 1 y 7 días según severidad)

Restaurar desde la copia más reciente del backup verificada anteriormente (nunca restaurar desde una copia cuya integridad no se comprobó en simulacros previos). El orden de preferencia es: copia inmutable (WORM) primero, luego copia fuera de sitio desconectada de la red principal, finalmente copia local. Esto asegura que el backup restaurado no fue comprometido por el mismo ataque.

Validar la integridad criptográfica de cada documento restaurado comparando el hash SHA-256 con el hash registrado antes del incidente. Si el hash no coincide, el backup está corrupto o fue manipulado; usar la siguiente copia en el orden.

Para microformas D.L. 681: documentar formalmente la restauración con acta firmada por IT, Legal y DPO (si aplica). Incluir quién autorizó la restauración, resultado de verificación de integridad, marca de tiempo completa y si participó auditor externo. Esta documentación es parte de la cadena de custodia que da validez legal a la microforma restaurada.

Reactivar el acceso de usuarios de forma escalonada por departamento, validando que cada grupo solo accede a los documentos que le corresponden. Esto previene que un error de restauración afecte la totalidad de las operaciones.

Fase 7 — Post-incidente (1 a 4 semanas)

Informe forense completo. Documentar quién realizó el ataque (atribución si es posible con evidencia técnica), cómo accedió (vector de entrada verificado), cuándo comenzó y cuándo se detectó (tiempo de permanencia del atacante, duración total del acceso no autorizado), qué datos y documentos se comprometieron, cuánto tiempo estuvo el malware activo sin ser detectado. Este informe es para reguladores, abogados y uso interno; no se divulga públicamente.

Retrospectiva estructurada. Qué funcionó bien en la respuesta, qué falló, qué cambios se incorporan al plan para futuras brechas. Documentar lecciones específicas: si el backup no restauró en el tiempo esperado, qué cambios se realizan; si la comunicación con la ANPD fue lenta, qué procedimientos se ajustan.

Presentación a Gerencia y Directorio. Resumen ejecutivo del impacto real: reguladores activados, multas estimadas, tiempo de paralización operativa, costo total de remediación. Incluir recomendaciones concretas de inversión en seguridad documental para el próximo ciclo presupuestario.

Cifrado AES-256 y controles de acceso granular

Qué protege el cifrado y qué no

El cifrado AES-256 protege documentos en reposo (si el hardware es robado físicamente, el contenido cifrado no es legible sin clave) y en tránsito (si la red es interceptada, los datos cifrados no pueden extraerse sin clave). El DS 016-2024-JUS exige controles criptográficos proporcionales al riesgo; AES-256 es el estándar de facto certificado por NIST y supera esta exigencia.

Lo que AES-256 no protege: si un atacante obtiene las credenciales de un usuario autorizado mediante phishing, ingeniería social o malware en una estación de trabajo, el ransomware se ejecuta con esos permisos. El sistema descifra el documento legítimamente porque tiene las claves. El cifrado es necesario pero insuficiente sin controles de acceso complementarios.

RBAC: limitar el radio de explosión

El control de acceso basado en roles (RBAC) define qué puede hacer cada tipo de usuario con cada categoría de documento. Ejemplo: un analista tributario puede leer comprobantes de Contabilidad, pero no puede descargarlos, no puede enviarlos a correos externos y no puede ver expedientes laborales ni judiciales. Si el atacante roba esas credenciales, solo compromete comprobantes de Contabilidad, no la totalidad del repositorio. Esto es el radio de explosión limitado: el daño se contiene al permiso específico y no se propaga horizontalmente.

ABAC: restricciones contextuales y comportamentales

El control de acceso basado en atributos (ABAC) amplía RBAC con reglas condicionales dinámicas:

• Red de origen: acceso solo desde IP corporativa o VPN con certificado válido.
• Horario: acceso permitido únicamente en días y horas laborales; fuera de horario requiere autorización dual.
• Dispositivo: solo desde equipos corporativos registrados en MDM, con cifrado de disco completo y antimalware actualizado.
• MFA obligatorio: para documentos P0 y P1 en cualquier acción (lectura, descarga, modificación).
• Detección de comportamiento anómalo: si un usuario descarga cientos de documentos en minutos, muy por encima de su patrón habitual, se activa alerta de seguridad y se requiere autenticación adicional de inmediato.

Un ransomware que opera fuera de horario, desde una red no corporativa y sin MFA válido quedaría bloqueado incluso con credenciales robadas. Estos controles transforman la defensa documental de reactiva a anticipatoria.

Logs inmutables de auditoría

Cada acción sobre documentos P0 y P1 debe registrarse en logs que no pueden ser eliminados ni modificados, ni siquiera por el administrador del sistema (WORM o Write-Once, Read-Many). El registro debe incluir: usuario que realizó la acción, marca de tiempo con zona horaria precisa, tipo de acción (lectura, descarga, modificación, eliminación, cambio de permisos), dispositivo y red de origen, y resultado (éxito, rechazo y razón del rechazo). La retención mínima es dos años bajo DS 016-2024-JUS, extendida si hay litigio activo. Estos logs constituyen evidencia forense en caso de disputa regulatoria.

Backups certificados: la última línea de defensa

Regla 3-2-1-1-0 adaptada a documentos con valor legal

La regla 3-2-1 clásica establece: tres copias de datos, en dos tipos de soporte distintos, con una copia fuera de sitio. Para documentos con valor legal en Perú, se agregan dos elementos críticos:

• +1 copia inmutable (WORM): Write-Once, Read-Many. Una vez escrita, no puede ser cifrada ni eliminada incluso si el atacante obtiene acceso administrativo total. Para microformas D.L. 681, esta copia en bóveda segura (física o digital con hardware certificado) es el elemento que permite recuperar el valor legal tras un ataque de ransomware.
• +0 errores sin verificar: cada backup debe probarse periódicamente mediante restauración completa y validación con hash SHA-256. Un backup que nunca se restauró con éxito no garantiza nada; es solo almacenamiento de datos sin garantía de recuperabilidad.

Implementación práctica:

• Copia 1 (local): servidor primario con cifrado AES-256, acceso RBAC/ABAC y logs inmutables.
• Copia 2 (distinto soporte): almacenamiento en nube con replicación diaria, acceso restringido a cuenta de servicio dedicada sin permisos de eliminación.
• Copia 3 (fuera de sitio): backup en bóveda segura física o hardware WORM certificado, desconectado de cualquier red, con cadena de custodia documentada.

Testing de recuperación

Cada tres meses para documentos P0 y P1; cada seis meses para P2. El proceso implica restaurar en un ambiente aislado (nunca en producción), validar integridad mediante comparación de hashes, verificar que no falten documentos esperados, confirmar que los documentos se abren correctamente y documentar el resultado en acta firmada por IT, Legal y DPO. La copia de prueba se destruye al finalizar para garantizar que no queda acceso no controlado a datos restaurados.

RTO (Recovery Time Objective) por nivel:

• P0: menos de 2 horas.
• P1: menos de 4 horas.
• P2: menos de 24 horas.

RPO (Recovery Point Objective): si los backups se ejecutan diariamente, el RPO es de 24 horas. La empresa debe decidir conscientemente cuánta pérdida de datos es aceptable y ajustar la frecuencia de backup en consecuencia. Para microformas bajo D.L. 681, la empresa debe evaluar si ese plazo cubre sus necesidades de reconstructibilidad legal.

Estos objetivos deben estar definidos por escrito, comunicados a Gerencia antes de cualquier incidente y revisados en retrospectivas post-incidente.

Checklist de autoevaluación: 15 preguntas binarias

Responde estas preguntas antes de enfrentar un incidente real. Cada “no” es un gap concreto que requiere remediación inmediata.

Preparación:

• ¿Todos los documentos están clasificados según tipo y nivel de sensibilidad (P0-P3)?
• ¿Existe un equipo de respuesta con roles claros, autoridad documentada y canales fuera de banda?
• ¿Se han identificado los reguladores específicos que aplican a la empresa (ANPD, SBS, SUNAT, SUNAFIL, INDECOPI, Fiscalía de Ciberdelitos)?
• ¿Hay plantillas pre-redactadas de notificaciones regulatorias revisadas por Legal?
• ¿El backup fue probado con restauración exitosa en los últimos tres meses y documentado en acta?

Defensa técnica:

• ¿Los documentos P0 y P1 están cifrados con AES-256 en reposo?
• ¿Existe control de acceso granular (RBAC + ABAC) con restricciones de red, horario, dispositivo y MFA para documentos críticos?
• ¿Los logs de auditoría son inmutables (WORM) con retención mínima de dos años?
• ¿Se realizan revisiones de acceso trimestrales para eliminar privilegios acumulados?
• ¿El SIEM o sistema de monitoreo alerta sobre accesos anómalos (volumen masivo, horario inusual, origen no corporativo)?

Recuperación y cumplimiento:

• ¿Se aplica la regla 3-2-1-1-0 con copia inmutable (WORM) y sin errores sin verificar?
• ¿Los RTO y RPO están definidos por escrito y comunicados a Gerencia para cada tipo de documento?
• ¿Hay un DPO designado responsable de las notificaciones a la ANPD dentro del plazo de 48 horas?
• ¿Se realiza un simulacro de respuesta a incidente anualmente, documentado en acta?
• ¿El equipo de respuesta ha participado en al menos un simulacro de recuperación desde backup?

Interpretación:

• 15 de 15: IRP robusto. Prioridad en testing continuo y actualización de políticas conforme cambie la normativa.
• Entre 10 y 14: Gaps concretos identificables. Plan de remediación en 30 días.
• Entre 5 y 9: Vulnerabilidades críticas en defensa técnica o regulatoria. Cierre en 60 días máximo.
• Menos de 5: Riesgo alto de incidente no manejable. Buscar asesoría externa con urgencia.

Preguntas frecuentes

¿Tengo que pagar el rescate si me atacan con ransomware?

No. Pagar no elimina la obligación regulatoria de notificar a la ANPD dentro de 48 horas, no aumenta significativamente la probabilidad de recuperar datos (menos del 10% recupera la totalidad tras pagar) y financia a actores criminales. Además, ejecutivos pueden incurrir en riesgos legales bajo D.L. 1182 por financiamiento de operaciones ilícitas. La salida confiable es la recuperación desde backup certificado y probado, respaldado por control de acceso y auditoría.

¿Cuánto tiempo tengo para notificar a la ANPD?

48 horas desde el momento en que se confirma el incidente con evidencia técnica verificada. El reloj comienza cuando el equipo IT valida que hubo brecha de datos personales, no desde el inicio del ataque. La notificación debe incluir descripción de hechos, categorías y volumen de datos comprometidos, número estimado de titulares afectados y medidas de contención implementadas. Una demora injustificada convierte una infracción grave en muy grave, incrementando la sanción base.

Si debo priorizar, ¿cuál es la primera medida de defensa?

Backups certificados fuera de sitio con desconexión física de la red principal (air gap) o copia WORM inmutable. Un ransomware que cifra el repositorio principal también cifra cualquier backup accesible en la misma red. La segunda prioridad es control de acceso granular con MFA para documentos P0 y P1. La tercera, logs inmutables de auditoría. El cifrado AES-256 es necesario en todo caso, pero es insuficiente sin estos tres elementos de defensa en profundidad.

¿Qué diferencia hay entre notificar a la ANPD y a la SBS si trabajo en banca?

La ANPD protege datos personales (DNI, correo, teléfono, fecha de nacimiento) en cualquier contexto. La SBS protege la confidencialidad e integridad de información financiera de entidades bajo su supervisión (bancos, aseguradoras, cajas municipales, transacciones). Un banco debe notificar a ambas de forma independiente: a la ANPD por datos personales comprometidos (plazo 48 horas) y a la SBS por brecha de confidencialidad o integridad bajo Res. 504-2021 (plazo 24 horas según propuesta vigente). Son obligaciones paralelas, no alternativas; incumplir una no exime de la otra.

Conclusión

Un plan de respuesta a incidentes documentales no es un PDF almacenado en una carpeta y olvidado. Es una práctica continua de preparación, testeo y actualización: inventario clasificado actualizado, equipo entrenado con simulacros, backups probados trimestralmente, reguladores mapeados con contactos actualizados y canales de crisis listos antes de cualquier ataque.

Las consecuencias de no tenerlo son concretas y cuantificables: paralización operativa que puede durar semanas, multas regulatorias simultáneas de ANPD, SBS, SUNAFIL y SUNAT que suman cientos de miles de soles, pérdida de confianza de clientes y socios comerciales, y en casos graves, responsabilidad penal para ejecutivos bajo D.L. 1182. El costo de prepararse es una fracción del costo de responder sin preparación.

El siguiente paso es completar la checklist de 15 preguntas. Si el resultado es inferior a 10, los gaps identificados forman el plan de trabajo de los próximos 30 a 60 días. Si es inferior a 5, la exposición regulatoria y operativa justifica buscar asesoría externa de inmediato. AyP Digital ofrece diagnósticos de dos horas con consultor técnico y abogado especializado en datos para empresas que necesiten construir o revisar su plan de respuesta desde la normativa peruana vigente.