Cumplimiento en seguridad de los datos: proteja todo el ciclo de vida de la información

La seguridad de los datos resulta más fácil de evaluar cuando el equipo puede seguir la información desde su recogida hasta su eliminación. Los controles pertinentes dependen de la sensibilidad, la finalidad, los usuarios y las consecuencias de una pérdida o un uso indebido. Una base de datos de producción puede estar bien protegida mientras esos mismos registros quedan expuestos en hojas de cálculo exportadas, adjuntos de soporte, canalizaciones de analítica o copias de seguridad.

Para un CTO, el cumplimiento en seguridad de los datos es, por tanto, un problema de ingeniería y de evidencias: determinar qué requisitos son aplicables, traducirlos en controles en cada flujo de datos y demostrar que esos controles funcionan. Las políticas describen el comportamiento previsto. Las configuraciones, las pruebas, los registros y las excepciones revisadas muestran si el sistema se comporta realmente así.

Separe los requisitos de seguridad de las obligaciones generales sobre datos

El cumplimiento en seguridad de los datos se refiere a la protección frente al acceso, la divulgación, la alteración y la destrucción no autorizados y frente a la pérdida de disponibilidad. Abarca la información personal, pero también el código fuente, los registros financieros, la propiedad intelectual, las credenciales y otra información empresarial sensible.

El cumplimiento general en materia de datos incluye cuestiones que los controles de seguridad no pueden resolver por sí solos: si la recogida es lícita, qué finalidades están permitidas, qué avisos o contratos se necesitan, cómo ejercen las personas sus derechos y durante cuánto tiempo puede conservarse la información. El cifrado no convierte en lícita una recogida injustificada. Una finalidad de tratamiento válida no hace aceptable una implementación insegura.

Mantenga separadas tres fuentes de requisitos:

• Legislación y regulación: obligaciones determinadas por la jurisdicción, las actividades de tratamiento, el rol de la organización y el sector.
• Normas y marcos de aseguramiento: enfoques estructurados para la gestión de la seguridad o la evaluación independiente.
• Contratos y compromisos internos: condiciones de clientes, acuerdos con proveedores, políticas de tratamiento y compromisos de servicio.

Registre la fuente, el alcance, el responsable y la interpretación de cada requisito. Así, ingeniería puede implementar protecciones compartidas sin tratar erróneamente todos los marcos como jurídicamente equivalentes.

Determine la aplicabilidad antes de seleccionar controles

Un registro de aplicabilidad útil explica por qué se aplica un requisito, no simplemente que alguien lo añadió a una lista de comprobación.

Son preguntas de partida, no pruebas jurídicas completas. Por ejemplo, el software relacionado con la salud no está automáticamente sujeto a HIPAA por el mero hecho de tratar información sanitaria. Externalizar el procesamiento de pagos puede reducir el alcance de PCI DSS, pero no elimina automáticamente las responsabilidades del comercio.

El artículo 32 del RGPD exige una seguridad adecuada al riesgo, teniendo en cuenta factores como la naturaleza del tratamiento, los costes de aplicación y el estado de la técnica. Menciona medidas como el cifrado, la resiliencia, la restauración y la evaluación periódica; no impone una obligación general y universal de cifrado.

ISO 27001 se refiere a un sistema de gestión de seguridad de la información con un alcance definido. Sus requisitos incluyen el tratamiento de riesgos, la auditoría interna y la revisión por la dirección. Los controles del anexo A se consideran en función de una aplicabilidad basada en el riesgo, con las decisiones documentadas en la Declaración de Aplicabilidad. La certificación la realiza un organismo de certificación independiente.

SOC 2 es un informe de atestación, no una certificación. Sus criterios se refieren a la seguridad y, cuando se incluyen en el alcance, a la disponibilidad, la integridad del procesamiento, la confidencialidad y la privacidad. Ni un informe SOC 2 ni un certificado ISO acreditan el cumplimiento del RGPD.

Las obligaciones sectoriales requieren su propia evaluación. SOX se refiere a la información financiera y a los controles internos asociados de las empresas afectadas; CMMC se refiere a requisitos definidos de los contratos de defensa y a sus entornos de información. En Europa, la NIS2 exige analizar el sector, el tamaño, el servicio y las reglas de inclusión conforme a la transposición nacional. DORA abarca principalmente determinadas entidades financieras, con obligaciones contractuales para los proveedores de TIC y un régimen de supervisión para los proveedores críticos designados. No dé por hecho que todas las fintech o todos los proveedores tecnológicos tienen las mismas obligaciones directas.

Elabore un mapa del ciclo de vida que incluya las copias secundarias

Empiece por un proceso de negocio importante, como el alta de pacientes, la nómina, la atención al cliente o la conciliación de pagos. Identifique a su responsable de los datos y a su responsable técnico y, a continuación, siga la información a través de la recogida, el uso, la comunicación, el almacenamiento, la recuperación y la eliminación.

Para cada conjunto de datos, registre:

• Su finalidad, su sensibilidad y los requisitos de tratamiento aplicables.
• Sistemas de origen, ubicaciones de almacenamiento, interfaces y destinatarios.
• Usuarios humanos, cuentas de servicio, proveedores y vías de acceso privilegiado.
• Conjuntos de datos derivados, exportaciones, cachés, copias de prueba, registros y copias de seguridad.
• Desencadenantes de conservación, métodos de eliminación y excepciones.

La clasificación debe conducir a decisiones. Una etiqueta como «datos sanitarios restringidos» solo es útil si determina los destinos permitidos, las reglas de acceso, el registro, el cifrado y la eliminación. Combine la confidencialidad con la integridad y la disponibilidad: una receta alterada o una historia clínica no disponible pueden causar daños incluso sin que haya divulgación.

Valide el mapa contra diagramas de arquitectura, esquemas de bases de datos, configuraciones de integración, inventarios de almacenamiento y entrevistas con el personal de soporte y de operaciones. Las herramientas de descubrimiento pueden identificar candidatos, pero un responsable debe confirmar la finalidad y el tratamiento. Continúe con el descubrimiento de datos si el equipo todavía no puede explicar dónde reside la información sensible.

Implemente protecciones en cada fase del ciclo de vida

Recogida: minimice los datos y limite la entrada

Recoja lo que exige la finalidad aprobada. Elimine los campos de formulario innecesarios y evite aceptar adjuntos sin restricciones cuando baste con una entrada estructurada. Valide el tamaño, el tipo y el contenido de la carga útil; proteja los puntos de entrada frente a envíos no autorizados y abusos.

En el caso de los datos personales, conecte la interfaz de recogida con la finalidad de tratamiento documentada y la base jurídica aplicable. En el RGPD, el consentimiento es una de las posibles bases del artículo 6, no un requisito previo universal. Cuando se utilice el consentimiento, la aplicación debe dar soporte a todo su ciclo de vida, en lugar de limitarse a mostrar una casilla.

Mantenga los secretos y las cargas útiles sensibles fuera de las URL, los mensajes de error y la telemetría de la aplicación. Pruebe las vías de error: un envío rechazado no debe dejar una copia completa en un servicio de depuración.

Uso y acceso: aplique la autorización cerca de los datos

La autenticación establece la identidad; la autorización determina a qué registros y operaciones puede acceder esa identidad. Implemente ambas. Un usuario que ha iniciado sesión no debe obtener acceso a los registros de otro cliente cambiando un identificador.

Aplique el mínimo privilegio, separe las funciones administrativas cuando proceda y exija una autenticación más robusta para el acceso sensible o privilegiado. Conceda a las cuentas de servicio permisos estrictamente acotados en lugar de reutilizar credenciales personales. Asegúrese de que los procesos de altas, cambios y bajas abarquen los roles de las aplicaciones, los permisos cloud, los tokens de API y el acceso de proveedores.

Para el acceso de soporte, defina las condiciones de aprobación, los límites de tiempo, las acciones permitidas y los registros de auditoría. Revise el acceso en función de la necesidad de negocio actual, no solo de si una cuenta sigue activa. Las evidencias deben incluir pruebas de autorización, decisiones de revisión de accesos y ejemplos de permisos revocados.

Los datos de producción no deben convertirse en el conjunto de pruebas por defecto. Prefiera los datos sintéticos. Si una excepción con datos reales está justificada, apruebe su alcance, restrinja el acceso y fije una caducidad. La seudonimización puede reducir la exposición, pero los datos personales seudonimizados siguen estando sujetos al RGPD cuando las personas pueden volver a identificarse mediante información adicional.

Almacenamiento y transferencia: proteja los datos y sus claves

Distinga el cifrado en reposo del cifrado en tránsito. El cifrado del almacenamiento protege frente a determinados escenarios de pérdida o acceso; el cifrado del transporte protege los canales de comunicación. Ninguno de los dos impide que una aplicación autorizada devuelva registros al usuario equivocado.

Utilice implementaciones criptográficas consolidadas y mantenidas y un cifrado moderno autenticado. Configure protocolos de transporte compatibles, valide los certificados y elimine las configuraciones obsoletas. Evite diseñar criptografía propia.

La gestión de claves forma parte del control, no es una nota a pie de página de la implementación. Documente quién puede utilizar, administrar, rotar, revocar y recuperar las claves. Un KMS permite operaciones de claves gestionadas; un HSM puede proporcionar protección basada en hardware para el material criptográfico. Elija el enfoque en función del modelo de amenazas y de los requisitos operativos.

Separe la administración de claves del acceso rutinario a los datos cuando sea viable. Compruebe que la revocación del acceso impide realmente el descifrado y que la recuperación sigue siendo posible tras un fallo legítimo de la infraestructura. Perder la única clave utilizable puede convertir unas copias de seguridad intactas en datos no disponibles. Consulte cifrado y gestión de claves para conocer las distinciones operativas.

Las transferencias también necesitan controles sobre los destinatarios. Utilice destinos aprobados, credenciales de API con alcance limitado y acceso de descarga con límite temporal cuando proceda. Haga seguimiento de las exportaciones como copias con responsables y reglas de caducidad, no como sucesos que ponen fin a la responsabilidad.

Integridad y disponibilidad: pruebe las afirmaciones operativas

Proteja la integridad mediante la validación de entradas, las restricciones de la base de datos, los cambios controlados, la conciliación y los registros de auditoría adecuados a los datos. Una suma de comprobación puede detectar algunos cambios; no establece quién estaba autorizado a realizarlos.

Defina los objetivos de recuperación a partir de las consecuencias para el negocio. Elija la frecuencia de las copias de seguridad y el diseño de la restauración en consecuencia. Proteja las copias de seguridad frente a eliminaciones accidentales y administradores comprometidos, y restrinja el acceso a ellas con independencia del acceso ordinario a la aplicación cuando sea viable.

Una afirmación sobre la recuperación debe estar vinculada a una prueba, no solo a una configuración de copias de seguridad. Restaure en un entorno aislado, verifique la integridad y la coherencia de los registros, compruebe las dependencias de la aplicación y mida el rendimiento real de la recuperación. Registre los fallos y el trabajo correctivo. Una restauración satisfactoria de la base de datos no basta si faltan las claves, los archivos o los servicios de identidad necesarios.

Conservación y eliminación: haga que el borrado sea ejecutable

Defina la conservación por categoría de datos y finalidad, con un desencadenante claro: el cierre de una cuenta, la finalización de un contrato, un suceso de registro u otra condición justificada. Conecte la política con reglas implementadas en bases de datos, almacenes de objetos, índices de búsqueda, sistemas de analítica y servicios de proveedores.

El borrado necesita reintentos y conciliación. Un proceso que informa de éxito mientras ignora una solicitud fallida en un sistema posterior no demuestra la eliminación. Mantenga excepciones revisadas para retenciones legales u otras conservaciones justificadas, con responsable y condición de finalización.

Las copias de seguridad requieren un modelo documentado. Explique los periodos de caducidad, las restricciones al uso ordinario y cómo se tratan los registros eliminados previamente si se restaura una copia de seguridad. No prometa un borrado inmediato en todas partes si la arquitectura no puede cumplirlo. La eliminación segura también incluye los archivos exportados, los dispositivos retirados y la baja de proveedores.

Trate el aseguramiento cloud como evidencia con un alcance definido

Los servicios cloud redistribuyen las responsabilidades; no las eliminan. Identifique qué opera el proveedor y qué configura su equipo, incluidos la identidad, la exposición de red, la configuración del cifrado, la autorización de las aplicaciones, el registro, la conservación y la recuperación.

Evalúe el aseguramiento del proveedor para el servicio real. Compruebe el alcance del informe, el periodo de evaluación, las exclusiones, las responsabilidades del cliente y los hallazgos sin resolver. El certificado de un proveedor no prueba que su bucket de almacenamiento, su aplicación o sus permisos de administrador estén configurados correctamente.

La ubicación es otra cuestión de alcance. Identifique el almacenamiento principal, las réplicas, la recuperación ante desastres, el acceso de soporte, los subencargados y los destinos de la telemetría. Alojar los datos en una región elegida no garantiza por sí solo la soberanía de los datos ni el cumplimiento del RGPD. Las evaluaciones de transferencias internacionales son independientes de los requisitos de los contratos de encargo del tratamiento del artículo 28 del RGPD.

Antes de incorporar a un proveedor, establezca las expectativas contractuales sobre incidentes, acceso, subencargados, recuperación de datos, eliminación y salida del servicio. Compruebe si los datos exportados son utilizables y si es posible obtener evidencias de eliminación del proveedor. Un proveedor que no puede dar soporte al ciclo de vida que usted necesita plantea una decisión de arquitectura, no una simple nota de compras.

Aplique el contexto HealthTech sin mezclar obligaciones distintas

El sector HealthTech ilustra por qué importa el contexto de los datos. Los datos de salud reciben el tratamiento de categoría especial del artículo 9 del RGPD, además de requerir una base jurídica del artículo 6. Documente la condición del artículo 9 pertinente en lugar de suponer que todas las operaciones con datos de salud pueden basarse en la misma justificación.

Evalúe si es probable que el tratamiento entrañe un alto riesgo y, por tanto, requiera una evaluación de impacto relativa a la protección de datos conforme al artículo 35. Las evidencias de seguridad deben reflejar los daños probables: registros incorrectos, accesos inadecuados del personal, divulgación a través de notificaciones y servicios no disponibles pueden ser todos relevantes.

Las obligaciones relativas a los productos sanitarios dependen del producto y de su finalidad prevista. La evaluación conforme al MDR o al IVDR es una vía separada de la privacidad y la seguridad de la información. Los productos de historia clínica electrónica y las actividades de uso secundario también deben evaluarse a la luz de las disposiciones aplicables del Espacio Europeo de Datos Sanitarios y de sus requisitos escalonados. Las normas nacionales sanitarias y de reembolso pueden añadir restricciones adicionales.

Vender a un hospital no determina automáticamente la situación de cada proveedor respecto a las obligaciones directas de la NIS2. Documente la aplicabilidad jurídica por separado de los requisitos contractuales de seguridad del hospital. Las solicitudes de los clientes de certificación ISO, SOC 2 u otro aseguramiento pueden ser comercialmente importantes sin ser requisitos legales universales.

Construya las evidencias en torno a las afirmaciones y vigile las desviaciones

Para cada control relevante, defina la afirmación, el responsable de la implementación, el alcance, la fuente de las evidencias, la prueba, el revisor y el desencadenante de revisión. Mantenga separadas las evidencias de política, de configuración y de eficacia.

Reutilice las evidencias cuando respalden varios requisitos, pero preserve la interpretación de cada requisito. La correspondencia de controles es de muchos a muchos; una revisión de accesos compartida no acredita todas las obligaciones legales.

Vigile los cambios que pueden invalidar el modelo: nuevas integraciones, cambios de permisos, registros de auditoría desactivados, copias de seguridad fallidas, errores de borrado y nuevos destinos. Dirija las alertas a los responsables con una vía de escalado. Las auditorías periódicas deben comprobar mediante muestreo si estas comprobaciones funcionaron, no simplemente si existe un cuadro de mando. Las pruebas de penetración pueden ser adecuadas en función del riesgo o de los requisitos contractuales, pero no son una prueba obligatoria universal según ISO 27001 o SOC 2.

Incluya la respuesta a incidentes en el plan de evidencias. Según el RGPD, los encargados del tratamiento notifican a los responsables sin dilación indebida. Los responsables valoran la notificación a la autoridad de control sin dilación indebida y, a ser posible, en un plazo de 72 horas desde que tengan constancia de la violación, salvo que sea improbable que constituya un riesgo para los derechos y libertades de las personas. Las violaciones de alto riesgo también pueden exigir la comunicación a los interesados, con las excepciones del artículo 34. Documente el razonamiento cuando no se notifique y evalúe por separado otras obligaciones de notificación contractuales o sectoriales.

Ejemplo práctico: cerrar una brecha en las exportaciones de soporte

Supongamos, a modo ilustrativo, que un proveedor SaaS del sector HealthTech trata registros de citas y síntomas para clínicas. Su base de datos principal está cifrada, el acceso a la aplicación está limitado por cliente y existen copias de seguridad. Una revisión del ciclo de vida descubre que el personal de soporte exporta registros a hojas de cálculo y los adjunta a tickets.

La exportación crea dos almacenes adicionales: los dispositivos locales y el proveedor de tickets. Los controles de la base de datos no protegen automáticamente a ninguno de los dos. El equipo confirma primero si se necesitan los registros completos para diagnosticar el problema de soporte, si el destino está aprobado y qué restricciones contractuales se aplican.

A continuación, sustituye las exportaciones rutinarias por vistas de diagnóstico con datos ocultados. Las exportaciones excepcionales requieren aprobación, un destino restringido, campos limitados y una caducidad. Se revisan la configuración de acceso y de conservación del proveedor; las descargas locales se limitan mediante los controles de endpoint aprobados por la organización.

El paquete de evidencias incluye el mapa de flujos actualizado, pruebas de los permisos de exportación, una excepción revisada, evidencias de la configuración del proveedor y resultados de eliminación. Una prueba negativa confirma que un rol de soporte ordinario no puede exportar los registros de otra clínica. Una prueba de caducidad comprueba tanto la copia de la aplicación como el adjunto del ticket.

La brecha restante es explícita: los adjuntos históricos requieren investigación y eliminación cuando esté justificada. Un responsable recibe esa tarea con un criterio de finalización. El equipo no afirma cumplir con todo el ciclo de vida solo porque el nuevo botón de exportación sea más seguro.

Haga primero revisable un flujo sensible

Empiece con un flujo acotado y genere cinco entregables: un mapa de datos verificado, las decisiones de aplicabilidad, los responsables de los controles, evidencias probadas y un registro de brechas priorizado. Aborde la exposición y los fallos de recuperación antes que las mejoras estéticas de la documentación. Asigne a las excepciones un aprobador, una justificación, medidas compensatorias y una fecha de revisión.

En Secani, modele las aplicaciones, sistemas, servicios y proveedores externos que sustentan ese flujo. Conecte las evidencias con requisitos, controles y decisiones; asigne como tareas las evidencias que faltan o las responsabilidades poco claras. Contraste las sugerencias asistidas por IA con sus fuentes y conserve las aprobaciones humanas y las marcas temporales. Así, los activos, requisitos, riesgos y evidencias se mantienen en contexto sin sustituir con una herramienta las pruebas técnicas ni el análisis jurídico.

El siguiente paso práctico es una revisión de extremo a extremo: elija un registro sensible, siga cada copia y pregúntese qué demuestra que su recogida, acceso, recuperación, conservación y eliminación están controlados.