Diagrama de flujo de solicitud de acceso a datos (petición a revocación)
Diagrama del proceso de solicitud de acceso a datos: declara la finalidad, lee la clasificación, deja decidir al propietario de los datos, comprueba la privacidad, concede con caducidad y recertifica o revoca.
Cómo funciona
Renombra los carriles con los roles de tu organización
Sustituye Solicitante, Custodio de datos, Propietario de los datos, Oficina de privacidad y Equipo de plataforma de datos por los roles que de verdad tienes. Mantén al propietario de los datos separado del equipo de plataforma aunque hoy sea la misma persona quien hace las dos cosas, porque fusionarlos es exactamente lo que produce un proceso en el que quien concede es también quien aprueba. Si no hay oficina de privacidad, nombra a la persona que carga con esa responsabilidad en lugar de borrar el carril, y si la custodia del dato es informal, pon ahí al responsable del dominio y déjalo por escrito.
Mete tu esquema de clasificación en el diagrama
«Leer la clasificación y sus normas de manejo» es un paso inerte hasta que existen los niveles. Ponles nombre —público, interno, confidencial, restringido, o los que use tu esquema— y anota junto a cada uno qué permite: solo consulta sin extracción, extracción permitida, enmascarado obligatorio, acuerdo firmado exigible. Después di qué nivel dispara la rama del acuerdo de uso y qué nivel no puede salir nunca del entorno de análisis. Sin esa tabla, cada solicitud se discute desde cero y las respuestas cambian según quién apruebe.
Haz que la finalidad trabaje de verdad
Define el mínimo que una solicitud tiene que decir: la pregunta que se quiere responder, las tablas y columnas necesarias, de quién son los registros afectados, cuánto tiempo se quiere el acceso y dónde se guardará cualquier extracción. «Para análisis» hay que devolverlo, no aprobarlo. Es el control más barato de la página, porque una finalidad bien escrita vuelve casi mecánicas la evaluación de mínimo privilegio, la decisión de enmascarado y la fecha de caducidad, mientras que una vaga vuelve arbitrarias las tres.
Fija caducidades por defecto según la clasificación
Asocia un valor por defecto a «Conceder el acceso con fecha de caducidad» para cada nivel: algo así como la ventana del incidente para el acceso de emergencia, noventa días para los datos restringidos, seis o doce meses para los datos internos, y la fecha de fin del proyecto cuando lo hay. Deja que quien solicita pida menos tiempo, y haz que cualquier plazo superior al valor por defecto sea una decisión explícita del propietario. La caducidad es el control que sobrevive a las reorganizaciones, a las migraciones de herramienta y a que todo el mundo se olvide de que el proceso existía.
Acuerda la vía de emergencia antes de necesitarla
Decide quién puede activar el acceso de emergencia, qué concede, desde qué cuenta se ejecuta, cómo se registra la sesión y a quién se avisa en el momento de la concesión. Fija después el plazo de ratificación —unos pocos días laborables— y, sobre todo, decide qué pasa cuando nadie ratifica. La revocación automática al vencer el plazo es la única versión de esto que se sostiene, porque una cola de aprobaciones a posteriori sin consecuencia se convierte en atasco permanente en un trimestre.
Recórrelo con quien lo usa y publica una versión
Lleva el diagrama terminado a un propietario de datos, a un analista que pide accesos a menudo, al ingeniero de plataforma que ejecuta las concesiones y a quien lleve la privacidad, y pruébalo contra tres solicitudes reales del último trimestre, incluida una que se denegara y otra que fuera por la vía de emergencia. Corrige el diagrama hacia lo que pasó de verdad y no hacia lo que dice la política. Publica después esa revisión, conserva las anteriores y enlázala desde la política de gobierno del dato, para que quien la abra sepa qué versión está leyendo.
Preguntas frecuentes
¿Cuáles son los pasos de un proceso de solicitud de acceso a datos?
Crear una solicitud que declare la finalidad y no el sistema; localizar el conjunto de datos en el catálogo y leer su clasificación y sus normas de manejo; confirmar que tiene un propietario asignado, y clasificarlo primero si no lo tiene; que ese propietario evalúe la finalidad frente al mínimo privilegio y decida; cuando hay datos personales, registrar la base jurídica, minimizar los campos y pasarlo por una revisión de privacidad o una EIPD; ofrecer una vista enmascarada o agregada antes que el acceso en bruto; añadir un acuerdo de uso firmado para los datos restringidos; conceder el acceso con fecha de caducidad; activar el registro de consultas; anotar el permiso en el registro de accesos; y después recertificarlo antes de que caduque o revocarlo, de inmediato si cambia el puesto de la persona o la finalidad. Los pasos que más se echan en falta en la práctica son la alternativa enmascarada, la fecha de caducidad y el disparador de revocación por cambio de rol.
¿Quién debe aprobar el acceso a un conjunto de datos, TI o el propietario de los datos?
El propietario de los datos, es decir, la persona que responde en el área de negocio que esos datos describen, y no el equipo que opera la plataforma donde están alojados. Lo que se juzga es si esta finalidad justifica estos datos, y eso solo lo puede juzgar quien entiende qué significan los registros. El equipo de plataforma ejecuta la concesión, fija la caducidad y activa el registro; no debería además decidir quién tiene derecho a leer nóminas, historiales de pacientes o datos de clientes. La aprobación del responsable directo merece la pena como primera puerta, porque confirma que la petición forma parte del trabajo de esa persona, pero no sustituye a la decisión del propietario. Que un conjunto de datos no tenga propietario es en sí mismo un hallazgo, y por eso este diagrama pone «¿Catalogado y con propietario asignado?» antes de la evaluación y no después.
¿Cuánto debe durar un acceso a datos antes de caducar?
Lo que dure la finalidad declarada y ni un día más, con el valor por defecto fijado por la clasificación en lugar de negociado solicitud a solicitud. Un patrón que funciona es la duración del incidente para el acceso de emergencia, unos noventa días para los datos restringidos o personales, entre seis y doce meses para los datos internos ordinarios, y la fecha de fin del proyecto cuando la petición va ligada a uno. El mecanismo importa más que las cifras: una fecha de caducidad convierte la retirada en lo que ocurre por defecto y la renovación en el acto deliberado, así que el acceso se degrada solo cuando el proceso se descuida. El acceso sin caducidad, en cambio, se acumula. Y cuando pidas a un propietario que recertifique, mándale el número de consultas junto a la lista: un permiso que nadie ha usado en seis meses se retira sin discusión, mientras que una lista de nombres sin datos de uso se aprueba casi siempre en bloque.
¿Cuándo necesita una EIPD una solicitud de acceso a datos?
El RGPD exige una evaluación de impacto relativa a la protección de datos (EIPD, la DPIA en inglés) cuando es probable que el tratamiento entrañe un alto riesgo para los derechos y libertades de las personas, y la da por esperable en particular en el tratamiento a gran escala de categorías especiales de datos, la observación sistemática y las decisiones automatizadas con efectos jurídicos o similarmente significativos (artículo 35 del RGPD). Las autoridades de control publican además sus propias listas de tratamientos que siempre la requieren; en España las publica la AEPD. Para una solicitud analítica interna, los disparadores honestos suelen ser el tamaño de la población afectada, si hay categorías especiales o datos relativos a infracciones penales, si las personas esperarían razonablemente este uso y si el resultado alimenta una decisión sobre ellas. Dos cosas ayudan en la práctica: cribar toda solicitud con datos personales en lugar de esperar a que alguien plantee una duda, y tratar el resultado como condiciones de la concesión —las columnas enmascaradas, el plazo de conservación, la prohibición de reidentificar— y no como un documento que se archiva y se olvida.
¿En qué se diferencia esto de un proceso general de solicitud de accesos?
El proceso general de solicitud de accesos en /es/templates/proceso-de-solicitud-de-accesos cubre sistemas y aplicaciones: alguien necesita un rol en un sistema de negocio, lo aprueban su responsable directo y el propietario del sistema, se comprueba la segregación de funciones y TI lo aprovisiona. Esta página cubre conjuntos de datos, y eso cambia tres cosas. El aprobador es el propietario de los datos y no el propietario del sistema, porque la pregunta va del significado de los registros y no de la función de una aplicación. En el medio aparece un paso de clasificación, porque la respuesta depende de lo que haya dentro de la tabla. Y existe una alternativa enmascarada o agregada, que no tiene equivalente en el acceso a aplicaciones: no puedes conceder a nadie el sesenta por ciento de un módulo financiero, pero sí puedes darle una vista con los identificadores eliminados. Si estás diseñando el formulario de la mesa de servicio para el acceso a aplicaciones, empieza por el proceso general; si estás gobernando quién puede consultar el almacén de datos, empieza por aquí.