TL;DR: Un Libro de Reclamaciones virtual maneja datos personales sensibles (DNI, teléfono, dirección, descripción de hechos). Por eso debe operar sobre TLS 1.3, almacenar en reposo con AES-256, autenticar con OAuth 2.0 + JWT corto, segregar accesos por RBAC, anonimizar exports y cumplir Ley 29733 más DS 016-2024-JUS. Estándares globales como ISO 27001 y SOC 2 Type II son señal de madurez del proveedor. La filtración de Interbank en octubre-noviembre de 2024 mostró el costo reputacional de una arquitectura débil.
Estándares de seguridad y cifrado para Libros de Reclamaciones virtuales: SSL, AES-256, ISO 27001 y Ley 29733
Cada reclamo cargado a un libro virtual contiene, como mínimo, un nombre completo, un DNI, un correo, un teléfono y la narración de un hecho que muchas veces incluye datos sensibles: enfermedades, situaciones financieras, conflictos personales. Si esa data se filtra, no se filtra «una queja»: se filtra el perfil de un cliente identificable junto con su problema. Esta guía describe el estándar mínimo de seguridad que un Libro de Reclamaciones virtual debe cumplir en Perú en 2026, desde el certificado SSL hasta la auditoría SOC 2, alineado con la Ley 29733 de Protección de Datos Personales y el reciente DS 016-2024-JUS. Está pensada para CISOs, security officers, abogados de compliance y CTOs que deben aprobar o auditar al proveedor SaaS.
El estándar mínimo de seguridad que exige el 2026
La AGPD (Autoridad Nacional de Protección de Datos Personales del MINJUSDH) elevó la vara con el DS 016-2024-JUS, vigente desde el 31 de marzo de 2025. El reglamento amplía el principio de seguridad del Art. 9 de la Ley 29733 y exige medidas técnicas y organizativas proporcionales al tipo de dato y al volumen tratado. Para un libro virtual con miles de reclamos al año, el piso mínimo no negociable es:
- TLS 1.3 en tránsito: sin excepciones para versiones inferiores. TLS 1.2 todavía se acepta pero con cipher suites modernas (ECDHE, ChaCha20-Poly1305).
- AES-256 en reposo: base de datos cifrada a nivel de columna para campos PII y a nivel de disco para volúmenes completos.
- Autenticación robusta: 2FA obligatorio para usuarios administradores, JWT con expiración corta para sesiones, password hashing con Argon2id o bcrypt cost ≥12.
- Control de acceso por roles (RBAC): el operador de tienda no ve más que sus propios reclamos; el legal corporativo ve los que se escalaron; el auditor externo ve metadata pero no contenido.
- Logs inmutables de auditoría: quién accedió a qué reclamo, cuándo y desde dónde. Retención mínima 12 meses.
- Backups cifrados con rotación geográfica: al menos un sitio adicional fuera de la región principal, también cifrado AES-256.
- Plan de respuesta a incidentes documentado: obligación de notificar a la AGPD dentro de las 48 horas si la brecha afecta datos de identificación.
SSL/TLS: certificado válido y TLS 1.3 sin compromisos
Que el navegador muestre el candadito ya no basta. En 2026 lo mínimo es TLS 1.3 con perfect forward secrecy (PFS). TLS 1.2 sigue aceptado solo si se desactivan cipher suites antiguas (RC4, 3DES, CBC sin AEAD). Las versiones SSL 2.0, 3.0 y TLS 1.0/1.1 deben rechazarse a nivel de servidor.
El certificado debe ser válido, emitido por CA confiable (Let’s Encrypt, Sectigo, DigiCert), con renovación automática y cabeceras HTTPS forzadas:
- HSTS (HTTP Strict Transport Security): max-age mínimo de seis meses. Idealmente con preload.
- OCSP Stapling: reduce latencia de validación del certificado.
- Certificate Transparency: emisión registrada en logs públicos.
Verifica el estado de tu libro virtual en SSL Labs y exige al proveedor SaaS calificación A o A+ como mínimo. Calificación B o inferior es señal de configuración descuidada.
AES-256 para datos en reposo: cifrado por columna y por disco
El estándar AES (Advanced Encryption Standard) con clave de 256 bits es el patrón mundial para datos en reposo y la AGPD lo da por descontado en cualquier sistema que trate PII a escala. Lo importante es dónde se aplica:
- Cifrado a nivel de columna: campos como DNI, teléfono y correo se almacenan cifrados con clave gestionada por KMS (Key Management Service). Si alguien obtiene un dump de la base, ve hash, no datos.
- Cifrado a nivel de disco (TDE): el volumen entero del servidor de base de datos está cifrado. Protege contra robo físico del disco o snapshot mal expuesto.
- Cifrado de backups: los respaldos guardados en S3, GCS o Azure Blob también van cifrados, con clave separada de la de producción.
La práctica que separa proveedores serios de los demás: rotación periódica de claves. Las claves de cifrado se rotan cada 90 días automáticamente, sin intervención humana. KMS de AWS, Cloud KMS de GCP o Azure Key Vault traen esto de fábrica.
Tokens JWT con expiración corta
Los JSON Web Tokens son la forma estándar de mantener sesión autenticada en un libro virtual. Pero un JWT mal configurado es peor que no tener autenticación, porque se cree segura. Las reglas mínimas:
- Algoritmo de firma: RS256 o ES256 con clave asimétrica. Nunca HS256 con secret compartido entre cliente y servidor.
- Expiración corta: access token máximo 15 minutos. Si el atacante captura el token, su ventana de daño es limitada.
- Refresh token rotativo: al renovar, el refresh anterior se invalida. Detecta robo de refresh token.
- Claims mínimos: el JWT no transporta datos sensibles. Solo identificador del usuario, rol, scope y expiración.
- Revocación inmediata: al cerrar sesión, el token se incluye en denylist hasta su expiración natural.
Estas reglas se aplican igual al login del operador interno y al login del consumidor que consulta el estado de su reclamo. Para 2FA del rol administrador, exige TOTP (Google Authenticator o equivalente) o WebAuthn (llave física tipo YubiKey). SMS como 2FA es vulnerable a SIM swapping y la mejor práctica es desactivarlo.
RBAC: control de acceso por rol
El error más común en SaaS de libro virtual: todos los usuarios internos ven todos los reclamos. Si el cajero de la sucursal de Arequipa puede leer el reclamo presentado en la tienda de Piura, hay un problema de minimización de datos. El principio de menor privilegio exige roles segregados:
| Rol | Acceso a reclamos | Acciones | Notas |
|---|---|---|---|
| Operador de tienda | Solo su sucursal | Ver, responder en borrador | No puede exportar masivamente |
| Jefe de zona | Sucursales asignadas | Aprobar respuestas, escalar | Auditoría de aprobaciones |
| Legal corporativo | Todos los escalados | Responder definitivamente, archivar | Acceso a casos sensibles |
| Compliance officer | Todos (lectura) | Reportes agregados, auditoría | Sin modificación |
| Administrador | Configuración del sistema | Crear usuarios, definir roles | 2FA obligatorio, logs intensos |
| Auditor externo | Solo metadata | Conteo, plazos, cumplimiento | Sin contenido del reclamo |
El SaaS debe permitir crear roles personalizados, no solo trabajar con presets. Las empresas medianas y grandes usualmente requieren entre 8 y 12 roles según organigrama.
Anonimización de exports y reportes
Cuando un compliance officer descarga un Excel con todos los reclamos del trimestre para análisis, esa exportación es un riesgo si lleva PII completa. Las opciones para anonimizar:
- Pseudonimización: el DNI se reemplaza por un hash determinístico que permite cruzar registros sin identificar al sujeto.
- Enmascaramiento parcial: mostrar solo los últimos 3 dígitos del DNI o solo el dominio del correo.
- Agregación: reportes que muestran «X reclamos del rubro Y en la zona Z», sin individuos.
- K-anonimato: garantía de que cada combinación de atributos cuasi-identificadores aparece en al menos K registros.
El SaaS debe ofrecer al menos pseudonimización por defecto en exports. Quien descarga la versión con PII completa firma una constancia y queda registrado en el log de auditoría con motivo declarado.
Compliance Ley 29733 y DS 016-2024-JUS
La Ley 29733 (vigente desde 2011) establece principios y derechos. El reglamento original (DS 003-2013-JUS) los aterrizó. El nuevo DS 016-2024-JUS, vigente desde el 31 de marzo de 2025, eleva el estándar técnico y procedimental. Lo más relevante para un libro virtual:
- Obligación de inscripción de bancos de datos: el banco de datos del libro virtual se inscribe ante la AGPD en el Registro Nacional de Protección de Datos Personales.
- Designación de DPO (Delegado de Protección de Datos): obligatorio en empresas que tratan datos sensibles a escala. El SaaS también debe tener DPO.
- Evaluación de impacto (EIPD): obligatoria antes de implementar tratamientos que impliquen riesgo alto. Documentar y archivar.
- Notificación de brechas: 48 horas a la AGPD si afecta identificación. Comunicar al titular si hay riesgo alto a sus derechos.
- Derechos ARCO+: acceso, rectificación, cancelación, oposición, más portabilidad y limitación. El libro debe permitir ejercerlos.
El proveedor del SaaS firma un Acuerdo de Encargado de Tratamiento con la empresa contratante. Este acuerdo, exigido por el Art. 26 del DS 016-2024-JUS, define quién es responsable y quién es encargado, qué medidas aplica el encargado y qué pasa al terminar el contrato (devolución o destrucción de datos).
ISO 27001 y SOC 2 Type II: estándares globales que valen oro
La Ley peruana fija el piso. Los estándares globales fijan la madurez. Dos son los que importan para un proveedor SaaS de libro virtual:
ISO/IEC 27001: norma internacional de gestión de seguridad de la información. Certifica que la organización opera un Sistema de Gestión de Seguridad de la Información (SGSI) con controles documentados (Anexo A: 93 controles en la versión 2022). La auditoría es anual con vigilancia y recertificación cada tres años.
SOC 2 Type II: reporte de aseguramiento emitido por auditor independiente que evalúa los controles a lo largo de un periodo (mínimo 6 meses). Cubre criterios de seguridad, disponibilidad, confidencialidad, integridad de procesamiento y privacidad. Es el estándar exigido por compradores B2B en EE.UU. y crece en Perú.
| Estándar | Costo aprox. inicial | Vigencia | Frecuencia auditoría | Quién lo exige |
|---|---|---|---|---|
| ISO 27001:2022 | USD 25,000-60,000 | 3 años | Anual con recertificación | Banca, telco, gobierno |
| SOC 2 Type II | USD 30,000-80,000 | 12 meses | Anual | Empresas globales B2B |
| PCI DSS (si maneja tarjetas) | USD 15,000-50,000 | 1 año | Anual | Procesadores de pago |
| ISO 27701 (privacidad) | USD 20,000-40,000 | 3 años | Anual con recertificación | Empresas globales privacy-first |
Si tu proveedor SaaS no tiene ISO 27001 al menos en proceso, el riesgo de incidente está subestimado. SOC 2 es deseable pero no obligatorio para mercado peruano todavía. Si maneja datos de salud (HIS, IPRESS) revisa también HIPAA-equivalente local.
Penetration testing y bug bounty
Las certificaciones miden controles documentados. El pentest mide la realidad operativa. Buenas prácticas:
- Pentest anual obligatorio con consultora externa, alcance white-box y black-box.
- Pentest tras cambios mayores: nueva integración, nuevo módulo, migración de infra.
- Bug bounty público o privado: programa permanente que paga por vulnerabilidades reportadas. Plataformas como HackerOne o Bugcrowd.
- SAST y DAST en CI/CD: análisis estático y dinámico automatizado en cada despliegue.
El SaaS responsable publica su política de divulgación coordinada y un informe ejecutivo del último pentest (versión sanitizada) para clientes corporativos que lo soliciten bajo NDA.
Caso de referencia: la filtración de Interbank en octubre-noviembre de 2024
En octubre-noviembre de 2024 trascendió públicamente que Interbank sufrió una exfiltración de datos de clientes. La cobertura periodística (Bloomberg, El Comercio, Gestión, Infobae) reportó que se vieron afectados nombres, números de cuenta, correos y teléfonos. La AGPD inició actuaciones. El caso, más allá de los detalles técnicos que la institución no ha revelado completamente, dejó tres lecciones aplicables a cualquier sistema que trate PII a escala —incluyendo libros virtuales:
- El daño reputacional supera al daño regulatorio: la multa potencial es alta pero el costo de comunicación de crisis y pérdida de confianza es mayor.
- La notificación rápida y honesta importa: demorar el reconocimiento amplifica el daño. La AGPD valora la transparencia post-incidente.
- El proveedor de tu SaaS es tu eslabón más débil: si el SaaS sufre brecha, la responsable ante el consumidor es tu empresa. La diligencia debida en selección y monitoreo del proveedor es parte del compliance, no opcional.
Este episodio elevó la prioridad del tema seguridad en directorios bancarios y de retail peruano, con presupuestos crecientes en 2025 y 2026.
Checklist de evaluación al elegir SaaS de libro virtual
- ¿TLS 1.3 forzado y calificación A+ en SSL Labs? Verifica.
- ¿AES-256 en reposo, con KMS y rotación cada 90 días? Pide documento.
- ¿RBAC con roles personalizables y log de accesos inmutable? Demo.
- ¿2FA obligatorio para administradores, JWT corto, refresh rotativo? Comprueba.
- ¿Anonimización por defecto en exports? Prueba en sandbox.
- ¿ISO 27001 vigente o en proceso? SOC 2 Type II como diferencial. Pide certificado.
- ¿Pentest anual y bug bounty? Pide informe ejecutivo del último ejercicio.
- ¿Acuerdo de Encargado de Tratamiento listo para firma según DS 016-2024-JUS? Lee y revisa con tu DPO.
- ¿DPO designado en el proveedor? Pide nombre y CV.
- ¿Plan de respuesta a incidentes documentado y notificación a AGPD en 48 horas? Pide procedimiento.
Para complementar el lado de privacidad por diseño en escenarios sensibles, revisa la guía sobre protección de datos médicos y educativos. Para el patrón de arquitectura headless con seguridad reforzada, mira la guía técnica para React y Next.js headless.
Preguntas frecuentes
¿Es obligatorio SSL en el libro virtual?
Sí, sin excepciones. La transmisión de PII por HTTP plano viola el principio de seguridad de la Ley 29733 y el DS 016-2024-JUS. El estándar 2026 es TLS 1.3 con HSTS y certificado válido emitido por CA confiable. TLS 1.2 sigue aceptado solo con cipher suites modernas (ECDHE, ChaCha20-Poly1305). SSL 2.0/3.0 y TLS 1.0/1.1 deben rechazarse a nivel servidor.
¿AES-256 es el estándar para datos en reposo?
Sí. AES con clave de 256 bits es el patrón mundial. Aplícalo en tres capas: cifrado a nivel de columna para campos PII (DNI, teléfono, correo), cifrado a nivel de disco para volúmenes completos (TDE) y cifrado de backups. Las claves se gestionan con KMS y rotan cada 90 días automáticamente. AWS KMS, Google Cloud KMS y Azure Key Vault traen esto de fábrica.
¿TLS 1.3 vs 1.2: cuál exigir?
TLS 1.3 es el objetivo. Es más rápido, elimina cipher suites vulnerables y simplifica el handshake. TLS 1.2 sigue válido si se desactivan suites antiguas (RC4, 3DES, CBC sin AEAD). Versiones SSL 2.0/3.0 y TLS 1.0/1.1 deben rechazarse. Verifica con SSL Labs y exige calificación A o A+. Calificación B o menos es señal de mantenimiento descuidado.
¿Tokens JWT son seguros?
Sí cuando se configuran bien. Reglas: firma con RS256 o ES256 (clave asimétrica), expiración corta (15 minutos para access token), refresh rotativo que invalida el anterior, claims mínimos sin datos sensibles, revocación inmediata al cerrar sesión. JWT mal configurado (HS256 con secret compartido, expiración larga, claims sensibles) es peor que no autenticar. Para 2FA usa TOTP o WebAuthn, no SMS.
¿RBAC: cómo configurarlo?
Define roles con principio de menor privilegio. Operador ve solo su sucursal, jefe de zona aprueba sus zonas asignadas, legal corporativo gestiona escalados, compliance officer ve todo en lectura, auditor externo solo metadata. Cada acceso queda en log inmutable con retención mínima 12 meses. Exige al SaaS que permita crear roles personalizados, no solo presets. Empresas medianas suelen requerir 8-12 roles.
¿Necesito ISO 27001?
Tu empresa no necesariamente, pero tu proveedor SaaS sí debería tenerlo o estar en proceso. ISO 27001:2022 certifica la operación de un Sistema de Gestión de Seguridad de la Información con 93 controles documentados. Vigencia 3 años con auditorías anuales. Costo inicial USD 25,000-60,000 para el proveedor. Si el SaaS no lo tiene ni en proceso, el riesgo está subestimado.
¿Y SOC 2 Type II?
SOC 2 Type II es reporte de aseguramiento emitido por auditor independiente sobre controles a lo largo de mínimo 6 meses. Cubre seguridad, disponibilidad, confidencialidad, integridad de procesamiento y privacidad. Es estándar en EE.UU. y empieza a exigirse en grandes B2B peruanos. Diferencial competitivo del proveedor SaaS. No es obligatorio aún por ley peruana pero sí útil si compras evalúa proveedores con criterios globales.
¿Penetration test es obligatorio?
No por ley específica, pero sí por buenas prácticas y porque ISO 27001 lo incluye en sus controles. Mínimo: pentest anual con consultora externa, pentest tras cambios mayores y SAST/DAST en CI/CD. Bug bounty público o privado es señal de madurez. Pide al proveedor SaaS un informe ejecutivo sanitizado del último pentest bajo NDA. Si no lo entrega, considéralo bandera roja.
Conclusión
La seguridad de un libro virtual no es un nice-to-have, es la condición para operar legalmente y proteger la confianza del consumidor. Tres takeaways accionables: primero, exige al proveedor SaaS evidencia documentada de TLS 1.3, AES-256, RBAC con logs y 2FA; sin esto, no firmes. Segundo, audita la inscripción del banco de datos en la AGPD y firma el Acuerdo de Encargado de Tratamiento conforme al DS 016-2024-JUS. Tercero, verifica que el proveedor tenga ISO 27001 vigente o en proceso, pentest anual y plan de respuesta a incidentes con notificación a AGPD en 48 horas. La seguridad mal hecha es la deuda técnica más cara que existe.
¿Necesitas un Libro de Reclamaciones virtual con seguridad de nivel banca? claimbook.pe opera sobre TLS 1.3, AES-256, RBAC granular, logs inmutables y proceso ISO 27001 en marcha. Crea tu cuenta y duerme tranquilo con el cumplimiento de Ley 29733 y DS 016-2024-JUS.
