PIPEDA en la práctica: qué implementa quien programa

Resumen:

• La limitación de propósito obliga a saber para qué se recogió cada campo.
• Una política de retención que nadie ejecuta automáticamente no es una política.
• Atender una solicitud de acceso exige un inventario de dónde vive cada dato.
• Hay que registrar todas las brechas, también las que no se notifican.

La ley federal canadiense se organiza en diez principios que suenan razonables y abstractos. El trabajo de quien construye software es convertirlos en estructuras concretas.

Esto es la traducción, principio a principio, tal como la aplicamos en proyectos.

Consentimiento: un registro, no una casilla

El error más común es guardar la aceptación como un valor de sí o no.

Lo que hace falta es un historial: qué propósito, en qué fecha, con qué versión del texto y en qué estado está hoy. Un usuario puede haber aceptado comunicaciones comerciales hace dos años y haberlas revocado el mes pasado, y ambos hechos deben poder demostrarse.

La versión del texto es la parte que más se olvida. Si la política cambió, saber que alguien aceptó no dice nada si no se sabe qué aceptó exactamente.

Limitación de propósito: documentar el porqué de cada campo

Este principio tiene una consecuencia técnica concreta: cada dato recogido debe tener una finalidad declarada, y usarlo para otra cosa requiere nuevo consentimiento.

En la práctica significa mantener un inventario de campos con su propósito. No es un documento aparte que envejece: conviene que viva junto al modelo de datos, como metadatos de cada campo.

Retención: el principio que nadie implementa

Casi todos los sistemas que revisamos guardan todo para siempre. Es lo que ocurre por defecto cuando nadie decide lo contrario.

La obligación es conservar mientras haga falta para la finalidad y eliminar después. Eso exige tres cosas: un plazo definido por tipo de dato, un proceso que lo ejecute sin intervención humana, y un registro de qué se eliminó y cuándo.

La parte incómoda es que eliminar de verdad afecta a integridad referencial, a respaldos y a informes históricos. Por eso casi nadie lo hace, y por eso conviene diseñarlo desde el principio en lugar de añadirlo con la base llena.

Acceso del titular: el inventario que falta

Una persona puede pedir toda la información que la organización tiene sobre ella.

Un sistema pequeño lo resuelve con una consulta. Un sistema que creció durante años tiene datos personales repartidos en tablas que nadie recuerda: registros de actividad, adjuntos, sistemas de soporte, herramientas de terceros.

Sin un inventario de dónde vive cada dato, atender una solicitud se convierte en una búsqueda manual con riesgo de dejar algo fuera. Ese inventario es también lo que permite responder a una brecha con precisión.

Preguntas frecuentes

¿PIPEDA aplica a mi empresa si no está en Canadá?

Puede aplicar si tratas datos personales de personas en Canadá en el curso de actividades comerciales. La ubicación de la empresa no determina por sí sola la aplicabilidad, así que conviene analizarlo antes de abrir operación allí.

¿Qué significa limitación de propósito en el código?

Que los datos recogidos para una finalidad no se usan para otra sin nuevo consentimiento. Técnicamente implica poder responder para qué se recogió cada campo, lo que en la práctica exige documentarlo en el propio modelo de datos.

¿Cuánto tiempo se pueden conservar los datos?

El necesario para cumplir la finalidad, y no más. No hay un número universal: hay que definir un plazo por tipo de dato, documentarlo y aplicarlo de forma automática, porque una política de retención que nadie ejecuta no es una política.

¿Cómo se atiende una solicitud de acceso?

Entregando al titular la información personal que la organización tiene sobre él, en un plazo acotado. El sistema tiene que poder reunirla de todas las tablas donde vive, y ahí es donde fallan los sistemas que crecieron sin inventario de datos.

¿Cuándo hay que notificar una brecha?

Cuando exista riesgo real de daño significativo para las personas afectadas. Además de notificar, hay obligación de mantener un registro de todas las brechas, incluidas las que no llegaron al umbral de notificación.

El registro de brechas

Un detalle que sorprende: hay que registrar todas, también las que no alcanzan el umbral de notificación.

Eso implica tener un procedimiento interno para documentar cualquier incidente de seguridad que afecte a datos personales, con la evaluación de riesgo que llevó a notificar o a no hacerlo.

Es trabajo de proceso más que de software, y el software ayuda: un registro de accesos bien hecho es lo que permite determinar el alcance real de un incidente en horas en lugar de en semanas.

Los proveedores también cuentan

Un punto que se olvida: la responsabilidad sobre los datos no se transfiere al contratar un servicio externo.

Si tu aplicación manda datos personales a un proveedor de análisis, de correo o de almacenamiento, sigues siendo responsable de ese tratamiento. Eso obliga a mantener una lista de con quién se comparte qué, y a que exista un contrato que fije las obligaciones de cada parte.

En la práctica, el inventario de terceros suele revelar integraciones que alguien añadió hace años y que nadie recuerda: una herramienta de sesiones grabadas, un chat de soporte, un servicio de notificaciones.

Un orden de trabajo realista