Lista de comprobación de revisión de privacidad para una funcionalidad

Objetivo

Responder, antes de que se publique una funcionalidad, a las preguntas que planteará más adelante una exportación, una eliminación, un incidente o una revisión, en una forma lo bastante breve como para acompañar la pull request o el documento de diseño.

Requisitos previos

El mapa de datos, la tabla de retención, la lista de finalidades de preferencia, y el diseño o el diff de la funcionalidad. Quien revisa no es quien la ha escrito.

Pasos

1. Inventario: enumerar cada campo, línea de registro, evento y llamada a terceros nuevos o modificados que porten datos personales; para cada uno, categoría, precisión, finalidad y almacén.
2. Minimización: para cada campo, ¿podría eliminarse, hacerse más grueso o derivarse en el momento de uso? Registrar la decisión con una razón de una línea.
3. Retención: cada almacén o campo nuevo tiene una fila en la tabla de retención y una tarea que la aplica; cada campo de registro nuevo está en una lista permitida o seudonimizado.
4. Acceso: ¿quién puede leer los datos nuevos (roles, servicios, herramientas internas)? ¿Cubre el registro de acceso la nueva ruta de lectura? ¿Muestran las herramientas internas más de lo que la tarea necesita?
5. Procesos del interesado: el flujo de exportación incluye el almacén nuevo; el flujo de eliminación lo incluye; la prueba con sujeto sintético pasa con el almacén nuevo presente.
6. Preferencias: la funcionalidad comprueba la finalidad relevante en el punto de uso; una finalidad nueva se añade como constante y como origen de eventos de preferencia.
7. Terceros: para cada SDK o API nuevos, qué datos salen, bajo qué configuración, y cómo se propaga y se confirma una eliminación.
8. Amenazas: una pasada breve de LINDDUN sobre los flujos de datos modificados, o un enlace a la sesión que los cubrió.
9. Datos de prueba: la funcionalidad puede desarrollarse y probarse sin datos personales de producción.
10. Registro: la lista de comprobación con sus respuestas se adjunta a la pull request o al documento de diseño; los elementos sin resolver se convierten en tickets con responsables y fechas.

Resultado esperado

Una funcionalidad cuyos datos están inventariados, minimizados, retenidos mediante una tarea, exportables, eliminables y condicionados por las preferencias antes del lanzamiento, y un registro de revisión a partir del cual pueda responderse una pregunta posterior.

Límites y base de verificación

La lista de comprobación cubre solo propiedades de ingeniería. Si una finalidad es admisible, qué debe divulgarse a las personas, y cualquier obligación derivada de una ley son cuestiones para los responsables de la organización y quedan deliberadamente fuera de la lista. La lista de comprobación es la propuesta del agente que la ha aportado; no se afirma ningún resultado sobre su efecto.