4. Son datos, pero son personas

4.1. ¿De qué va este tema?

Un formulario pide datos, una aplicación los guarda y alguien decide quién puede verlos. Parece una cuestión técnica. Pero detrás hay personas. ¿Necesitamos toda esa información? ¿Quién debería acceder? ¿Qué ocurre si se utiliza mal?

Vamos a diseñar y comprobar un tratamiento teniendo esas preguntas en cuenta desde el principio. El riesgo no es solo una multa o una pérdida para la empresa: importa lo que puede ocurrirles a las personas.

Este tema tiene una duración estimada de 14 horas.

4.2. Clases

4.2.1. Fuentes, sujetos y gobierno del tratamiento

¿A quién se refieren los datos y quién decide qué hacemos con ellos?

1. Dato personal no significa solamente nombre y DNI. El artículo 4 del RGPD se refiere a información sobre una persona física identificada o identificable.

   1. Un correo nominativo, una fotografía o un identificador vinculado a una cuenta pueden permitir identificar a alguien, también combinados con otros datos.

   2. Una dirección IP puede ser dato personal según el contexto y los medios razonablemente disponibles para identificar. No se decide solo por su formato.

   3. Recoger, consultar, almacenar, comunicar o borrar datos son tratamientos. No hace falta publicar los datos para estar tratándolos.

   4. Las categorías especiales del artículo 9 incluyen, entre otras, salud, origen racial o étnico, opiniones políticas y afiliación sindical. Los datos biométricos entran en esa categoría cuando se tratan para identificar de manera unívoca. Los datos penales tienen un régimen específico en el artículo 10.

2. Cambiar un nombre por un código no hace desaparecer a la persona.

   • Seudonimizar: separar o sustituir identificadores, conservando información adicional que permite atribuir los datos a alguien. Siguen siendo personales.

   • Anonimizar: conseguir que la persona no sea identificable considerando los medios razonablemente utilizables. Quitar el nombre o aplicar un hash no lo demuestra por sí solo: importan vínculos, combinaciones y contexto.

   • Datos sintéticos: datos creados para el ejercicio, sin proceder de personas reales. Son los que usaremos en el laboratorio; no son una anonimización de clientes.

3. Fuentes con funciones diferentes.

   1. El RGPD establece el marco europeo directamente aplicable dentro de su ámbito. La LOPDGDD lo complementa en España y regula también derechos digitales; no lo sustituye. Hay que contrastar además normativa sectorial cuando proceda.

   2. Las sentencias interpretan el Derecho. Podemos recuperar la sentencia C-340/21 trabajada antes: sus apartados 29–32 recuerdan que un incidente no demuestra por sí solo la inadecuación de todas las medidas.

   3. Las resoluciones de autoridades de control resuelven casos en su ámbito; sus hechos y fundamento importan. No son leyes nuevas.

   4. Las guías de AEPD y las directrices del Comité Europeo de Protección de Datos (EDPB o CEPD) orientan la aplicación. Enlazaremos cada recurso junto a su uso.

4. Los papeles se asignan por lo que se hace, no por el nombre del contrato.

   • Responsable: determina los fines y medios del tratamiento.

   • Encargado: trata datos por cuenta del responsable, con las condiciones del artículo 28 y las instrucciones correspondientes.

   • Personal autorizado: actúa bajo la autoridad del responsable o encargado; un técnico empleado no es automáticamente un encargado separado.

   • Puede haber corresponsabilidad si se determinan conjuntamente fines y medios. No todo proveedor es encargado: debe examinarse su actividad concreta.

   Ejemplo: una empresa decide ofrecer soporte a sus clientes y qué información necesita. Un proveedor aloja el portal por su cuenta y siguiendo instrucciones. En ese tratamiento, la empresa es responsable y el proveedor es encargado. El proveedor podría tener otros tratamientos propios con un papel distinto.

5. El delegado de protección de datos (DPD) asesora y supervisa.

   1. Su designación se comprueba en el artículo 37 del RGPD y el artículo 34 de la LOPDGDD: no depende únicamente del número de empleados. Hay supuestos públicos, de observación sistemática o de datos especialmente protegidos a gran escala, además de los previstos en la norma española.

   2. Los artículos 38 y 39 regulan recursos, participación, independencia y funciones. Informa, asesora, supervisa, coopera con la autoridad y actúa como contacto.

   3. Debe evitar conflictos de interés. Decidir fines y medios y supervisar esas mismas decisiones puede crear un conflicto que hay que analizar.

   4. El responsable decide sobre el tratamiento y responde de sus obligaciones. El DPD no es quien «firma para asumir toda la responsabilidad» ni un requisito de autorización previa de cualquier operación.

Para hacer

1. Una tabla contiene «cliente-17» y sus incidencias; otra relaciona el código con un correo. ¿Los datos son anónimos? Justifica qué medida se ha aplicado.

2. Un usuario escribe en una incidencia un diagnóstico médico para explicar por qué no pudo conectarse. ¿Cambia algo aunque el formulario no pidiera salud?

3. Diferencia una norma, una sentencia y una guía. ¿Qué consultarías para saber qué exige el artículo 25 y qué recurso ayudaría a aplicarlo?

4. Un técnico consulta una incidencia sin modificarla ni enviarla a nadie. ¿Está realizando un tratamiento? Contrasta tu respuesta con el artículo 4 del RGPD.

5. En el ejemplo del portal, asigna quién define la finalidad, quién aloja bajo instrucciones y quién asesora sobre riesgos.

6. «Somos una empresa pequeña, nunca necesitamos DPD». ¿Qué comprobarías antes de aceptar esa conclusión?

7. El responsable quiere publicar todas las incidencias y pide al DPD que asuma la decisión. ¿Qué reparto de funciones propondrías?

4.2.2. De los principios a decisiones verificables

¿Para qué necesitas ese dato?

1. Los principios del artículo 5 deben cambiar decisiones.

   Del principio a una pregunta de diseño

   Principio	Decisión en un portal de soporte
   Licitud, lealtad y transparencia	Justificar el tratamiento y explicar de forma comprensible qué se hace.
   Limitación de la finalidad	Atender incidencias no autoriza automáticamente a crear perfiles comerciales.
   Minimización	Pedir contacto y datos del problema, no un documento identificativo por costumbre.
   Exactitud	Permitir corregir un contacto incorrecto para no enviar respuestas a otra persona.
   Limitación de conservación	Definir cuándo revisar, suprimir o conservar por otra obligación justificada.
   Integridad y confidencialidad	Limitar accesos y comprobar que las medidas funcionan.
   Responsabilidad proactiva	Poder explicar decisiones y aportar evidencia de su aplicación.

2. La base jurídica no se elige marcando una casilla por defecto. El artículo 6 contempla consentimiento, necesidad contractual, obligación legal, intereses vitales, misión de interés público o poderes públicos e interés legítimo, cada uno con sus condiciones.

   1. Para prestar soporte necesario dentro de un contrato con la propia persona, puede proceder la base contractual. No cualquier dato ni cualquier uso se vuelve necesario por incluirlo en las condiciones.

   2. Si los usuarios son empleados de un cliente empresarial, ese contrato entre empresas no convierte automáticamente a cada empleado en parte contractual. Debe analizarse la base adecuada a las operaciones y sujetos.

   3. El interés legítimo exige identificarlo, comprobar necesidad y ponderar derechos; no significa «nos viene bien». Tiene límites específicos en autoridades públicas.

   4. Si se utiliza consentimiento, debe ser libre, informado, específico e inequívoco. Retirarlo debe ser posible. Informar y obtener consentimiento son cosas distintas.

   5. Para categorías especiales hay que comprobar además una excepción del artículo 9.2; una base del artículo 6 no resuelve por sí sola esa condición.

3. Conservar lo necesario y atender derechos.

   1. Un plazo responde a la finalidad y las obligaciones, no a que el disco sea barato. Al terminar el soporte puede haber documentación que deba conservarse por otra razón; eso no justifica mantenerla visible para todo el equipo.

   2. Rectificación o supresión no son simplemente botones técnicos. Hay que verificar la solicitud de forma proporcionada, valorar su alcance y responder.

   3. El RGPD regula acceso, rectificación, supresión, limitación, portabilidad, oposición y garantías frente a ciertas decisiones automatizadas. Sus condiciones difieren: no todos proceden en cualquier tratamiento.

   4. El artículo 12 establece, con carácter general, respuesta sin dilación indebida y dentro de un mes, con posible prórroga en sus condiciones. La supresión puede tener excepciones; en España también debe examinarse el bloqueo del artículo 32 LOPDGDD. No prometas «borrado inmediato de todo» sin analizarlo.

4. Registro de actividades de tratamiento (RAT). El artículo 30 describe el contenido del registro, con obligaciones de responsable y encargado distintas.

   • Para practicar como responsable: contacto y papel, finalidad, categorías de personas y datos, destinatarios, transferencias, plazos previstos y medidas. Añadiremos la base jurídica para justificar la decisión, aunque no sea un campo expresamente enumerado en el artículo 30.1.

   • Tener menos de 250 empleados no supone exención general: el apartado 5 contempla excepciones a esa dispensa cuando hay riesgo, tratamiento no ocasional o ciertas categorías de datos. Un soporte habitual no es un tratamiento ocasional.

   • Una ficha de aprendizaje no acredita un RAT completo ni reemplaza otras obligaciones.

5. Proveedor internacional: mirar más allá de la ubicación del servidor.

   1. Identificar entidades que intervienen, sus papeles, accesos y subencargados. El contrato de encargo del artículo 28 es una pieza, no una garantía total.

   2. El acceso por otra entidad desde un tercer país puede implicar una transferencia aunque el alojamiento esté en Europa. Hay que examinar los flujos reales.

   3. El capítulo V regula transferencias: decisiones de adecuación dentro de su alcance, garantías del artículo 46 y excepciones del 49 en sus condiciones. No elegimos una excepción como solución ordinaria a cualquier transferencia.

   4. Ni una casilla de consentimiento ni unas cláusulas firmadas resuelven siempre todo el análisis. Hay que comprobar destino, garantías y protección efectiva.

Para hacer

Un servicio de reparación contratado por particulares quiere pedir para cada incidencia: nombre, correo, equipo afectado, descripción, DNI, estado civil y autorización obligatoria para enviar promociones.

1. Selecciona los datos necesarios y justifica qué eliminarías o limitarías.

2. ¿Qué base examinarías para atender el soporte necesario del contrato? ¿Sirve automáticamente para promociones ajenas a esa finalidad?

3. Reescribe la descripción del problema para orientar al usuario sobre qué información aportar y qué no debe incluir.

4. Prepara una ficha breve del soporte contratado por particulares: finalidad, personas y datos, base, destinatarios, conservación y medidas. Marca los plazos no conocidos como pendientes de justificar, no inventes una norma.

5. El proveedor dice «cumplimos porque el servidor está en la UE», pero su subencargado de otro país puede consultar incidencias. ¿Qué falta comprobar?

6. El servicio tiene diez empleados y atiende incidencias a diario. ¿Puede prescindir del RAT solo por su tamaño? Consulta el artículo 30.5 del RGPD.

7. Una persona pide suprimir una incidencia ya cerrada. Indica qué comprobarías sobre la solicitud y la conservación antes de prometer el borrado de todo.

4.2.3. Privacidad desde el diseño y análisis preliminar

¿Podemos evitar el problema antes de recoger los datos?

1. Diseñar privacidad es decidir durante todo el ciclo de vida.

   1. Recogida: qué campos, qué instrucciones y qué finalidad.

   2. Uso: quién necesita cada dato y para qué tarea.

   3. Comunicación: destinatarios y canales, también exportaciones y correos.

   4. Conservación: revisiones, restricciones, supresión y copias.

   5. Derechos: cómo localizar, corregir o facilitar información de una persona sin revelar la de otras.

   El artículo 25 del RGPD vincula diseño y valores por defecto. Las directrices 4/2019 del EDPB desarrollan su aplicación: el enlace sirve para profundizar, no se pide leer toda la guía.

2. Una configuración por defecto protege sin exigir que la persona la corrija.

   • Abrir una incidencia no debería publicar sus datos automáticamente.

   • Los campos opcionales también necesitan justificación: «no es obligatorio» no equivale a minimización.

   • El soporte no necesita un volcado completo si un extracto reducido permite resolver el fallo. Separar contacto y datos técnicos limita exposición.

   • Seudonimizar puede ayudar, pero no sustituye permisos ni justifica otra finalidad.

3. Requisitos que puedan probarse.

   Del propósito a la prueba

   Propósito	Requisito del ejercicio	Prueba prevista
   Evitar exposición entre solicitantes	A solo consulta sus incidencias; B solo las suyas; visitante no ve ninguna.	Comparar vistas y exportaciones con esos perfiles.
   Minimizar recogida	No recoger documento identificativo para resolver incidencias corrientes.	Crear una incidencia y examinar campos almacenados, no solo el formulario.
   Limitar acumulación	Depurar cerradas al vencer el plazo interno ficticio de 30 días.	Probar una cerrada antigua, otra reciente y una abierta.
   Restringir extracción masiva	Solicitantes sin exportación; técnico solo dentro de su alcance asignado.	Probar tanto permiso como contenido devuelto.

   Los 30 días son una decisión del supuesto simplificado, no un plazo impuesto por el RGPD. Para este ejercicio suponemos que no hay otra finalidad ni obligación de conservación de esas incidencias. En una implantación real hay que comprobarlo.

4. Riesgos para personas y cribado de EIPD.

   1. Una incidencia expuesta puede revelar contactos, circunstancias laborales o incluso datos de salud escritos en texto libre. Piensa en posibles usos indebidos: suplantación, acoso, discriminación o pérdida de confidencialidad.

   2. Una evaluación de impacto (EIPD) se requiere antes del tratamiento si es probable un alto riesgo, conforme al artículo 35 y los criterios aplicables. Es más que puntuar una tabla o rellenar un asistente.

   3. Examina naturaleza, escala, contexto, personas vulnerables, categorías de datos, observación y decisiones automatizadas. Consulta las listas de la autoridad y, como apoyo, Evalúa-Riesgo RGPD en las herramientas de AEPD.

   4. No todo portal de soporte exige automáticamente EIPD; tampoco basta decir «solo es soporte» para descartarla. Registra hechos, criterios y conclusión provisional, y revisa si cambian el alcance o los riesgos.

Para hacer

1. Reformula «protegeremos bien las incidencias» en dos requisitos y sus pruebas.

2. El portal básico atiende a 20 clientes, sin perfiles automatizados ni datos especiales previstos. Una ampliación propone evaluar automáticamente a miles de trabajadores usando incidencias y datos de salud para tomar decisiones sobre su empleo. ¿Puede reutilizarse sin más el cribado inicial?

3. ¿Qué riesgo se reduce al no recoger el DNI y cuál permanece si los textos siguen pudiendo contener información delicada?

4. El formulario deja el DNI como opcional en lugar de eliminarlo. ¿Basta para justificar su recogida? Relaciona la respuesta con necesidad y minimización.

5. Propón qué información debería recibir un técnico para resolver un fallo sin obtener un volcado completo de los datos del cliente.

6. Diseña una prueba para comprobar que la depuración del supuesto elimina cerradas antiguas y conserva abiertas y cerradas recientes. ¿Qué datos de prueba necesitas?

7. Redacta una conclusión provisional de cribado de EIPD para el portal básico: qué sabes, qué falta comprobar y qué cambio obligaría a revisarla.

4.2.4. Configuración corporativa por defecto

¿Qué ocurre si el usuario no cambia ninguna opción?

1. Entorno preparado: laboratorio local de incidencias.

   Descarga el laboratorio de privacidad y abre el archivo HTML con un navegador actual y JavaScript habilitado. Funciona sin instalación, cuentas ni conexión de red. Solo utiliza datos ficticios fijos.

   • El panel superior es del laboratorio: modifica el modelo de configuración.

   • La vista del portal muestra lo que el modelo permite al perfil seleccionado.

   • El diario registra pasos, configuración y resultados; puedes descargarlo.

   • Recargar o reiniciar restaura el escenario inicial y borra el diario de esa sesión. Guárdalo si quieres comparar después.

   Es una simulación de configuración, no un portal corporativo desplegado. Todos los datos están en el archivo y el navegador; el selector de perfiles no autentica usuarios ni aísla datos frente a inspección del código. Las pruebas demuestran el comportamiento del modelo, no seguridad de servidor o cumplimiento de un producto real. No introduzcas datos reales.

2. Datos iniciales y permisos esperados.

   • I1: solicitante A, abierta.

   • I2: solicitante B, cerrada hace 45 días.

   • I3: solicitante A, cerrada hace 5 días.

   • El técnico del supuesto tiene asignadas las tres. El visitante no tiene cuenta.

   La configuración inicial es deliberadamente excesiva: comparte con todos, recoge un documento identificativo y permite exportar a solicitantes. La conservación no está configurada. Los días son una edad ficticia fija, no el reloj del ordenador.

3. No recoger, no mostrar y borrar son operaciones distintas.

   1. La restricción de vistas limita lo que presenta el modelo por perfil.

   2. Desactivar recogida cambia nuevos registros; los anteriores requieren una decisión y operación separadas de depuración de datos excesivos.

   3. La eliminación del campo actúa sobre los registros de esta sesión. No borra exportaciones que hubieras copiado ni acredita supresión de copias de un servicio real.

   4. El diario del laboratorio contiene IDs y acciones, no debe confundirse con un registro de auditoría protegido. También los registros de un sistema real necesitan finalidad, acceso limitado y conservación justificada.

Para hacer

Realiza los pasos en orden, partiendo del escenario inicial. No reinicies entre pasos; si lo haces, repite las operaciones anteriores antes de continuar.

1. Sin cambiar la configuración, consulta como A, B y visitante. Anota qué IDs aparecen. Como A, prueba exportar. ¿Qué requisitos anteriores incumple el modelo?

2. Desmarca compartir con todos, recoger documento y permitir exportación a solicitantes. Selecciona 30 días y pulsa Aplicar configuración.

3. Repite las consultas A/B/visitante y como técnico. Prueba exportar como A y como técnico. Registra esperado y observado, no solo «correcto».

4. Crea una incidencia ficticia como A y comprueba si tiene campo document. ¿Ha desaparecido también ese campo de I1, I2 e I3?

5. Pulsa Eliminar documentos identificativos ya almacenados y comprueba la vista y exportación del técnico. ¿Qué cambió respecto a desactivar recogida?

6. Ejecuta la depuración con 30 días. ¿Qué incidencia debería desaparecer? Comprueba que siguen una abierta y una cerrada reciente.

7. Descarga el diario y prepara una tabla breve: requisito, perfil, esperado, observado, acción correctora y límite de la prueba.

4.2.5. Riesgos, medidas y supervisión del DPD

¿Qué puede pasarle a la persona y cómo reducimos ese riesgo?

1. Valorar el daño, no solo el coste para la organización.

   • Escenario: incidencias visibles para otras personas.

   • Consecuencias posibles: uso del contacto para suplantar al soporte, exposición de circunstancias personales o discriminación si hay información sensible.

   • Medidas: visibilidad restringida, minimización, revisión del texto libre y formación del personal, además de controles técnicos comprobados.

   Para este ejercicio usa baja/media/alta, justificando cada dimensión:

   1. Probabilidad: baja con acceso restringido y controles comprobados; media cuando hay exposición limitada o eficacia incierta; alta con exposición abierta y condiciones que facilitan el acceso. La falta de datos debe anotarse.

   2. Gravedad: baja para perjuicio limitado y reversible; media para perjuicio relevante que requiere intervención; alta si puede afectar seriamente a derechos, seguridad, discriminación o información íntima. Justifica según datos y contexto.

   3. No multiplicamos etiquetas ni deducimos EIPD de un semáforo. Esta escala didáctica no sustituye el artículo 35 ni una evaluación completa.

2. Residual actual no es lo que esperamos conseguir.

   1. Solo atribuye reducción a medidas realmente implantadas y comprobadas dentro del alcance de la prueba. Una propuesta mantiene el riesgo pendiente.

   2. Restringir accesos puede reducir probabilidad; no hace inocuos los datos si alguien accede. Eliminar información innecesaria también reduce exposición.

   3. El simulador permite demostrar cambios del modelo; el residual de un servicio real seguiría pendiente de validar en su entorno y con sus otras vías de acceso.

   4. Si el tratamiento requiere EIPD, debe realizarse antes de comenzar. Si persiste alto riesgo que no se logra mitigar, procede analizar la consulta previa del artículo 36, no limitarse a «aceptarlo» como un coste empresarial.

3. Una brecha no es solo un ataque. Puede implicar pérdida, alteración, destrucción o acceso o comunicación no autorizados de datos personales, también por error. Fallos de disponibilidad e integridad pueden afectar a las personas.

   Actuaciones que conviene separar

   Actuación	Regla del RGPD, resumida
   Documentar	El responsable documenta cualquier brecha, hechos, efectos y medidas (33.5), también cuando concluye motivadamente que no procede notificar.
   Encargado a responsable	Comunica sin dilación indebida desde que tiene conocimiento (33.2). No tiene una franquicia automática de 72 horas para avisar al cliente.
   Responsable a autoridad	Sin dilación indebida y, de ser posible, como máximo 72 horas desde que tiene constancia, salvo que sea improbable el riesgo para derechos y libertades. Si se supera, explicar motivos (33.1).
   Responsable a personas afectadas	Sin dilación indebida cuando sea probable un alto riesgo, con las condiciones y excepciones del artículo 34. No es el mismo umbral ni un plazo general de 72 horas.

   1. Contener y conservar hechos necesarios: restringir acceso, comprobar alcance, qué datos, quién pudo acceder, cuándo se supo y qué medidas se tomaron.

   2. No esperar al informe perfecto si corresponde notificar; el artículo 33.4 permite aportar información por fases sin dilación indebida.

   3. El cifrado solo es relevante en sus condiciones: no sirve alegarlo si el destinatario recibió los datos legibles. Corregir un enlace tampoco revoca automáticamente lo ya descargado.

   4. El DPD asesora; el responsable decide y documenta. Los asistentes Asesora Brecha y Comunica-Brecha RGPD de AEPD apoyan decisiones diferentes: autoridad y personas afectadas, respectivamente. No deciden por la organización.

Para hacer

Las tres primeras tareas retoman el laboratorio de la clase anterior. Si lo has cerrado, vuelve a aplicar su configuración restringida antes de probarla. Las restantes usan esta variación ficticia, sin introducirla en el simulador: el proveedor avisa al responsable de que varias incidencias fueron accesibles públicamente y hay descargas confirmadas. Incluían contacto y datos de salud escritos en texto libre. El responsable tiene constancia suficiente el lunes a las 10:00. Se restringe el acceso, pero no puede garantizarse la eliminación de las copias. No se ha identificado una excepción que evite comunicar a las personas afectadas.

1. Valora exposición de contactos y recogida innecesaria de documentos en el escenario inicial. Justifica probabilidad y gravedad pensando en las personas.

2. En el laboratorio, descarga primero el diario. Reactiva temporalmente compartir con todos, pulsa Aplicar configuración y prueba visitante; vuelve a restringirlo, aplica y repite. Registra la prueba negativa y la corrección.

3. Para cada riesgo indica medida, comprobación y qué permanece sin resolver. Redacta tres líneas de asesoramiento del DPD y una decisión separada del responsable.

4. Para la brecha ficticia, prepara un registro con hechos, hora de constancia, datos y personas por determinar, consecuencias, medidas, información pendiente y decisión provisional.

5. Justifica la notificación a la autoridad y la comunicación a las personas. ¿Cuándo se cumplen 72 horas? ¿Se debe esperar hasta entonces?

6. Escribe una nota breve del DPD y una decisión del responsable; explica por qué restringir ahora el acceso no resuelve las descargas anteriores.

7. Aún falta determinar el número de personas afectadas. ¿Qué harías con la notificación y sus actualizaciones? Consulta el artículo 33.4 del RGPD.

No se envía ninguna notificación real. Fundamenta las decisiones y distingue quién actúa, con qué información y cuándo.

4.2.6. Revisión de privacidad del portal

¿Podemos ponerlo en servicio y explicar por qué?

1. Recorre la cadena: finalidad → fundamento → datos → requisitos → configuración → pruebas → riesgos y revisión.

   • Finalidad y base: no justificar toda recogida con «acepta las condiciones».

   • Datos y conservación: necesarios, acotados y revisables.

   • Perfiles: vista y exportación coherentes con sus tareas.

   • Pruebas: resultado observado, límites y correcciones.

   • Riesgos y gobierno: recomendaciones del DPD y decisiones del responsable.

2. Seguridad no equivale a licitud. ENS y NIS2 aportan referencias de protección, pero cifrar una base no justifica recoger datos innecesarios o reutilizarlos para otra finalidad. Tampoco un aviso de privacidad corrige permisos excesivos.

Para hacer

Un portal tiene aviso de privacidad, recoge el DNI «por seguridad», muestra incidencias a todos los solicitantes, conserva todo indefinidamente y afirma que cumple porque usa cifrado. Se pide al DPD que autorice la puesta en servicio.

Responde brevemente sobre este único supuesto, reutilizando lo trabajado.

1. ¿Qué finalidad y base jurídica necesitarías comprobar antes de valorar el portal?

2. ¿Qué justificación falta para recoger el DNI? Propón una alternativa mínima.

3. Formula una prueba de consulta entre dos solicitantes: resultado esperado y evidencia que guardarías.

4. Formula una prueba que distinga no recoger un campo nuevo de eliminar los valores ya almacenados.

5. ¿Qué debe decidirse sobre conservación y posibles copias antes de aplicar un borrado? Indica quién debe justificar esa decisión.

6. ¿Qué corresponde asesorar al DPD y qué corresponde decidir al responsable? Explica por qué el aviso y el cifrado no resuelven las demás carencias.

7. Redacta una conclusión de tres frases al responsable, indicando límites de las pruebas del laboratorio y qué faltaría validar en una plataforma real.

Test de autoevaluación

(Pendiente)

Actividad final integradora

(Pendiente)