← España

AAPP-00056-2016

1/26 Procedimiento Nº AP/00056/2016 RESOLUCIÓN: R/01143/2017 En el procedimiento de Declaración de Infracción de Administraciones Públicas AP/00056/2016, instruido por la Agencia Española de Protección de Datos a la entidad AGENCIA ESTATAL DE ADMINISTRACIÓN TRIBUTARIA, vista la comunicación remitida por la misma y en virtud de las denuncias presentadas, y en base a los siguientes, ANTECEDENTES PRIMERO: Con fecha de 6 de abril de 2016 tiene entrada en esta Agencia un correo electrónico de la AGENCIA ESTATAL DE ADMINISTRACIÓN TRIBUTARIA, en adelante la AEAT, en el que notifica lo siguiente: . Ese mismo día se ha producido una incidencia “…que ha podido poner en riesgo el carácter reservado y la custodia de datos personales de determinados contribuyentes.” . La incidencia consiste en que al utilizar la opción de generar una vista previa del borrador de la declaración del IRPF en la campaña de Renta 2015, en algunos casos puntuales el sistema ha podido facilitar la vista previa del borrador de un contribuyente distinto del solicitante. . Tan pronto como se tuvo conocimiento de la incidencia se deshabilitó la opción de generar la vista previa del borrador y no volverá a habilitarse en tanto no se tenga la certeza de que el problema ha sido subsanado. . No disponen de datos precisos sobre el número de afectados pero las condiciones que tenían que darse para que se produjese el error eran tan particulares que todos les lleva a pensar que haya sucedido en casos puntuales. El día 7 de abril de 2016 la AEAT notifica a través de la sede electrónica de esta Agencia la quiebra de seguridad previamente descrita. En esta notificación se ofrecen mayores detalles, como la fecha y hora de inicio y fin de la quiebra o los tipos de datos afectados. En el apartado “Descripción de los perjuicios que puede entrañar la quiebra” se indica: “Difusión de datos personales y posible utilización de la casilla de Renta para la obtención del número de referencia para el acceso de la campaña del año 2016”. Asimismo, en el apartado “Medidas para prevenir una nueva quiebra” de aquella notificación se indica: “Se reforzarán las medidas de inspección del código para evitar el error que ha provocado el incidente y se reforzarán las pruebas dirigidas a detectar este tipo de errores”. Entre el 6 y el 15 de abril de 2016 tuvieron entrada en esta Agencia escritos de 10 denunciantes, cuya identidad consta en el Anexo, que describen los hechos previamente citados (denunciantes 3 a 5, 7, 9, 10, 12 a 14 y 16). Varios de los escritos de denuncia aportan impresión parcial de los borradores a los que han tenido acceso. C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 2/26 El 8 de abril de 1016 la AEAT notifica a través de la sede electrónica de esta Agencia una nueva quiebra de seguridad, en adelante segunda quiebra. En este caso la incidencia tenía relación con la declaración del IRPF de unidades familiares y consistía en que, una vez autenticado el contribuyente, si volvía y modificaba los datos NIF, nombre y apellidos del cónyuge por otra combinación correcta la AEAT le devolvía los datos del tercero de quien había incluido los nuevos datos. Entre el 4 y el 27 de julio de 2016, tuvieron entrada en esta Agencia siete escritos de sendos denunciantes, cuya identidad consta en el Anexo, que tras recibir una notificación de la AEAT en la que se les informaba sobre la primera quiebra, ponen en conocimiento de esta Agencia los hechos (denunciantes 1, 2, 6, 8, 11, 15 y 17). SEGUNDO: A la vista de los hechos denunciados, en fase de actuaciones previas, por los Servicios de Inspección de esta Agencia se solicitó información a la entidad AEAT y se realizó visita de inspección a la misma, al objeto de aclarar las circunstancias de las dos quiebras notificadas y el alcance de las mismas, teniendo conocimiento de lo siguiente: 1. En relación con los sistemas afectados por las quiebras Los sistemas de información de la AEAT son desarrollados y mantenidos por la Dirección de Informática Tributaria (DIT) de la AEAT. La DIT está formada por unos 1.000 profesionales (entre personal interno y externo) que recibe formación continua en aspectos técnicos y funcionales de los sistemas de información. La declaración del IRPF se realizaba hasta 2015 a través de dos sistemas: el programa PADRE, que se instala en los ordenadores de los contribuyentes, y el “Borrador web”, que permitía gestionar el borrador de la declaración mediante una aplicación web. Hace varios años se estudió la necesidad de cambiar la arquitectura tecnológica de ambos sistemas para converger en uno sólo que fuese accesible a través de Internet. Tras realizar pruebas en las sedes de la AEAT a lo largo de 2015, el año 2016 se implantó una primera versión del nuevo sistema denominado RentaWeb. Rentaweb es un sistema complejo que está sujeto a cambios normativos. RentaWeb proporciona información completamente actualizada ya que calcula el borrador de la declaración en el momento de solicitarlo, mientras que la versión anterior del sistema calculaba y generaba el borrador con la información disponible a 31 de enero del año en curso y se limitaba a mostrar el documento generado. RentaWeb no cubre todos los casos que cubre el sistema PADRE pero si cubre más casos de los que cubría el “Borrador web” y en un futuro cubrirá todos los casos del sistema PADRE. 2. En relación con la quiebra notificada el día 6 de abril de 2016 a. Naturaleza de la quiebra Al utilizar la opción de generar una vista previa del borrador de la declaración del IRPF en la campaña de Renta 2015, en algunos casos el sistema facilitó en formato PDF un fichero con el borrador de un contribuyente distinto del solicitante. C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 3/26 b. Alcance de la quiebra a.1. Además de la propia AEAT, esta quiebra presenta varios tipos de intervinientes relevantes:  Los declarantes afectados, que son aquellos contribuyentes cuyos borradores han sido visualizados por otras personas.  Los terceros, que son aquellos contribuyentes que al tratar de visualizar el borrador de su declaración de la renta obtuvieron los datos de uno o varios de los declarantes afectados. Teniendo en cuenta que los borradores pueden tener datos de personas distintas del propio declarante, hay otras personas que pueden haberse visto afectados:  En su caso, el cónyuge.  En su caso, las personas menores de 25 años, mayores de 65 años o con discapacidad que conviven con los declarantes afectados.  En su caso, el arrendador del domicilio habitual del declarante.  En su caso, el representante del declarante, que puede ser persona física o jurídica. a.2. A pesar de que en la notificación de la quiebra el efecto principal de ésta se describe como la visualización del borrador, lo cierto es que al solicitar la vista previa del borrador Rentaweb genera un documento en formato PDF que es descargado en el equipo del contribuyente y que puede ser almacenado por éste. De hecho, varios de los denunciantes aportaban impresiones de los documentos que se les proporcionaron con datos de declarantes afectados y manifestaron mantener copias a disposición de las autoridades. a.3. Los datos que figuran en el borrador y a los que han tenido acceso los terceros son de los siguientes tipos:  Datos del declarante y del cónyuge como nombre, apellidos, domicilio, teléfonos, estado civil, grado de discapacidad y sobre su vivienda habitual como si es arrendada o de su titularidad.  En caso de que la vivienda sea arrendada, NIF del arrendador.  En el caso de que la declaración la presente un representante, su NIF, nombre y apellidos o razón social.  Datos identificativos, fecha de nacimiento, adopción o acogimiento y grado de discapacidad de las personas menores de 25 años o mayores de 65 años que conviven con el declarante.  Datos económicos como las bases imponibles y liquidables, deducciones y cuotas aplicables o el importe resultante de la declaración.  Número de la cuenta corriente en la que se desea que se realice la devolución o a través de la cual se realizará el pago. a.4. El número de declarantes afectados y de terceros fue calculado por la AEAT en un informe facilitado antes de la inspección del 5 de mayo, pero durante la misma, al comprobar los datos facilitados por los denunciantes en sus denuncias, se detectó un caso que no había sido contemplado en el cálculo inicial, lo que dio lugar a una revisión de la metodología empleada para el cálculo. En el periodo de 22 horas y 5 minutos durante el cual ocurrió la quiebra se realizaron 113.205 accesos a la vista previa de PDF, una media de más de 85 accesos por minuto. El número definitivo de terceros que al solicitar su borrador obtuvieron en su lugar el de un declarante afectado es de 2.886, lo que representa un 2,5 % del total de las solicitudes del periodo. En número definitivo de declarantes afectados es de 2.793. c. Cronología de la quiebra C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 4/26 La quiebra fue detectada el 6 de abril de 2016 por un contribuyente que lo puso en conocimiento de la AEAT a través de la cuenta de Twitter de su centro de atención del contribuyente y notificada a los equipos de desarrollo informático ese mismo día a las 10:51 horas. La quiebra comenzó el 5 de abril de 2016 a las 15:00 horas, que fue cuando se abre el sistema para que únicamente usuarios de la AEAT pudieran probar Rentaweb con sus propias declaraciones. A las 22:00 horas, al no detectar ninguna incidencia se cierra el sistema para volver a abrirlo para todos los contribuyentes a las 00:00 horas del día 6 de abril 2016. El 6 de abril de 2016 a las 13:05 horas se toman la primera medida que consiste en la inhabilitación del botón que permitía obtener el borrador de la declaración de la renta. El día 7 de abril de 2016, a las 15:30 horas, la AEAT sube a producción una nueva versión del software que solventa el error (en los entornos informáticos suele distinguirse entre desarrollo -el sistema en el que el equipo de desarrollo realiza los cambios-, preproducción -el sistema en el que se realizan las pruebas- y producción -el sistema real accesible a los usuarios. Subir a producción un software es actualizar la versión del software que es utilizado por los usuarios reales del sistema). d. Causas de la quiebra Durante la inspección se entró en el detalle de la arquitectura de programación y de las causas técnicas que llevaron a la quiebra de las medidas de seguridad. La causa de la quiebra fue un error de programación en el sistema Rentaweb. La nueva arquitectura seleccionada para el desarrollo de Rentaweb requiere de adaptaciones en la forma de programar que por error no fueron tenidas en cuenta en una clase concreta cuya función era gestionar la generación de los borradores de la declaración en formato PDF. El error de programación produjo que algunas de las peticiones de borrador realizadas bajo condiciones de carga de trabajo elevada en los servidores de Rentaweb no fueran correctamente gestionadas. A este respecto, en la visita de inspección realizada a la AEAT, los representantes de la misma declararon lo siguiente: “La violación de la seguridad de los datos personales notificada por la AEAT el día 6 de abril de 2015, que generó y permitió el acceso a los datos de contribuyentes por parte de otros contribuyentes autenticados, tuvo como causa originaria un error en la programación de la clase Java que permitía imprimir los borradores. La nueva arquitectura… requiere de adaptaciones en la forma de programar las clases Java que, por error, no fueron tenidas en cuenta para esta clase concreta. Además el error cometido únicamente tenía consecuencias en el caso de una elevada carga de los servidores que atienden al sistema”. Y en un informe sobre el incidente elaborado por la propia AEAT, al referirse a las causas del problema, se señala: “Error en la programación del programa de generación de PDFs de vista previa. C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 5/26 Presencia de variables de instancia en la clase…, valores que se utilizaban para generar la vista previa… (…) La utilización de este tipo de variables en una clase no es aconsejable para aquellas clases que se utilizan como servicios…, ya que pueden provocar el intercalado de datos provenientes de diferentes threads de ejecución”. e. Medidas preventivas Los profesionales que conforman la DIT de la AEAT tienen acceso a un centro de conocimiento web (Wiki) en el que, al menos desde agosto de 2015, se advertía explícitamente sobre el error de programación que representaba la codificación que ha dado lugar a la quiebra. La puesta en producción de cualquier sistema de la AEAT está sujeta a un programa de pruebas, que incluye pruebas unitarias, de integración, de funcionalidad, de carga, de seguridad y de compatibilidad de dispositivos. Estas pruebas son realizadas tanto por el personal de las unidades de desarrollo de la DIT como por personal de las delegaciones de la AEAT. Todas las pruebas se realizan en base a una planificación documentada y sus resultados se reflejan en una herramienta que gestiona los errores e incidencias detectados durante el desarrollo de las aplicaciones. Antes del despliegue o subida a producción de Rentaweb se detectaron y corrigieron 589 errores. Algunas de las pruebas, como las de carga, se realizan mediante el uso de herramientas de prueba automatizadas. Las pruebas de carga que se realizaron sobre los servidores no hallaron el error que dio lugar a la violación de seguridad porque están diseñadas para probar que los servidores responden a todas las peticiones y no el contenido de cada respuesta, que en este caso concreto, era un documento en formato PDF. La DIT de la AEAT dispone de una herramienta de comprobación automática de código que no incluye por defecto ninguna regla que permita identificar el error de programación citado. f. Medidas correctoras El mismo día 6 de abril de 2016 se procede a la corrección del error de programación en el componente afectado. Con la información proporcionada por el servicio de visualización previa se podría obtener, a partir de abril de 2017, un número de referencia para la campaña de Renta 2016 y con éste tramitar servicios asociados a dicha campaña. La AEAT dispone de un servicio que permite inhabilitar el acceso a los datos de la campaña de la renta de 2016 a través del uso de los datos que figuran en los borradores accedidos por terceros, y ha hecho uso de dicho servicio para todos los declarantes afectados. La Agencia Tributaria ha manifestado su intención de implantar un control para que en la próxima campaña no se pueda acceder a los datos de los declarantes afectados a no ser C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 6/26 que se acceda con certificado electrónico reconocido o con Cl@ve PIN (sistema para identificarse electrónicamente en las relaciones con las Administraciones Públicas, dirigido a personas físicas con NIF o NIE -siempre que no estén obligadas a usar certificado electrónico. Se basa en la utilización de una clave elegida por el usuario y un PIN comunicado mediante SMS, con la ventaja de que no es necesario recordar ninguna contraseña de forma permanente y la seguridad que aporta el que su validez sea limitada en el tiempo -10 minutos- y que el PIN sólo pueda ser utilizado una vez -en una única sesión en la que se permite realizar varios trámites). g. Notificación a los afectados y terceros En respuesta a la solicitud de información enviada por la inspección actuante, la AEAT informa en un escrito que tuvo entrada el 22 de abril de 2016 que, a dicha fecha, no había notificado los hechos ni a los declarantes afectados ni a los terceros. El 28 de abril de 2016, la Directora de la Agencia Española de Protección de Datos dirigió un escrito a la AEAT en el que se informa a la entidad que “…con el fin de mitigar los posibles perjuicios derivados de la violación, esta Agencia considera necesario que informe en el menor plazo posible a los afectados de la naturaleza de la violación, de las posibles consecuencias de ésta y de las medidas adoptadas para evitar que se produzca de nuevo así como de aquellas que ellos mismos podrían adoptar (e.g. revisar con frecuencia los movimientos de las cuentas bancarias afectadas)”. En el mismo escrito, y en relación con los terceros, se informa a la entidad que “…a fin de evitar que se produzcan nuevas vulneraciones a la normativa en materia de protección de datos, esta Agencia considera necesario que informe a los usuarios que tuvieron acceso a los datos de los afectados que el acceso se produjo como consecuencia de una violación en la seguridad de los datos, que dichos documentos contienen información tributaria confidencial no referida a ellos y que su uso o incluso su mera conservación puede contravenir lo dispuesto en la Ley General Tributaria y en la Ley Orgánica de Protección de Datos, por lo que deben proceder a borrar y suprimir cualquier información a la que hubieran accedido indebidamente.”. El 13 de junio de 2016 se remite a la AEAT un escrito solicitando información sobre las notificaciones realizadas a los declarantes afectados y los terceros. El 27 de junio de 2016 la AEAT proporciona copia de los textos utilizados para notificar a cada grupo e informa de que el proceso de notificación ha comenzado ese mismo día. Al estudiar los textos de las notificaciones enviadas se observa que:  A pesar de que la Directora de esta Agencia consideró necesario informar a los declarantes afectados de las medidas que ellos mismos pudiesen adoptar “(e.g. revisar con frecuencia los movimientos de las cuentas bancarias afectadas)”, la notificación enviada por la AEAT no incluye dicha información.  A pesar de que la Directora de esta Agencia consideró necesario informar a los terceros que la conservación o uso de los datos a los que tuvieron acceso “puede contravenir lo dispuesto en la Ley General Tributaria y en la Ley Orgánica de Protección de Datos”, la notificación enviada por la AEAT no incluye dicha información. Las denuncias que tuvieron entrada en la Agencia durante el mes de julio de 2016 hacen referencia a la primera de estas notificaciones. C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 7/26 3. En relación con la quiebra notificada el día 8 de abril de 2016 a. Naturaleza de la quiebra La declaración de la renta, además de ser un acto que puede realizar un contribuyente en su propio nombre, también puede ser realizada en nombre de terceros, en particular de otros miembros de la unidad familiar (p.e. declaraciones conjuntas) y personas dependientes. Para que este tipo de declaración a terceros sea viable, Rentaweb proporciona a un usuario autenticado la posibilidad de acceder a datos de un tercero, previa presentación de un número de referencia que la AEAT ha facilitado al tercero. La incidencia consiste en que, una vez proporcionado el número de referencia y recuperados los datos fiscales del tercero, si el usuario volvía atrás a la página de datos personales y modificaba del NIF, nombre y apellidos del tercero por los de otra persona física real, el sistema proporcionaba los datos del nuevo contribuyente sin exigir un nuevo número de referencia que permitiese comprobar que existe una relación entre el usuario y el nuevo contribuyente. b. Alcance de la quiebra No se tiene constancia de que la quiebra haya sido detectada o haya afectado a otro contribuyente distinto del que la notificó. El contribuyente manifiesta haber limitado las pruebas al uso de los datos de su socio, junto con quien estaba, y de otra persona de su entorno familiar. La AEAT proporciona a petición de la inspección actuante un formulario en blanco que muestre los tipos de datos expuestos. Los datos que figuran en el formulario incluyen los siguientes tipos:  NIF, nombre y apellidos del contribuyente.  Datos sobre rendimientos del trabajo, rentas exentas, premios y ganancias, incluyendo el pagador o pagadores y las retribuciones.  Datos sobre las actividades económicas del contribuyente incluyendo el código y tipo de actividad, el pagador o pagadores y los ingresos.  Datos sobre los rendimientos de cuentas bancarias (que incluyen los números de cuenta), letras del tesoro o capital mobiliario.  Información catastral de inmuebles en los que tiene participación.  Datos sobre donaciones, cuotas y aportaciones a partidos políticos.  Otros datos sobre donaciones, deducciones por maternidad, ascendientes, descendientes con discapacitados a cargo, etc... c. Cronología de la quiebra El día 8 de Abril a las 14:50 la Secretaría del Director General de la AEAT recibe una llamada telefónica en la que un contribuyente indica que usando la RentaWeb ha conseguido acceder a datos fiscales de otro contribuyente. Al haber recibido la notificación por un canal distinto de los centros de atención telefónica a contribuyentes, inicialmente no fue posible recoger todos los detalles asociados a la C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 8/26 incidencia ni los de la persona que llama. A pesar de ello, la Secretaría del Director General pone los hechos en conocimiento del DIT y desde ese momento el área de seguridad lógica del DIT trabaja para intentar reproducir el error a partir de los indicios disponibles. Aproximadamente a las 17:30 se pudo contactar con la persona que notificó el incidente y obtener más detalles del incidente. Se da máxima prioridad a la solución del incidente, que quedó subsanado a las 18:46 horas. d. Causas de la quiebra La causa de la quiebra fue un error en el diseño del módulo de Rentaweb que permite el acceso a los datos de contribuyentes distintos del declarante. El modulo en cuestión no impedía la modificación del NIF, nombre y apellidos del contribuyente distinto del declarante una vez facilitada una referencia válida. Parece que dicho bloqueo no fue incluido en el diseño inicial porque no se previó la posibilidad de que, en lugar de continuar con la tramitación de la declaración siguiendo los pasos en el orden habitual, el usuario retrocediese a la pantalla anterior. e. Medidas correctoras El mismo día 8 de abril de 2016, poco menos de 4 horas después de conocida la quiebra, se aplicó un parche de emergencia para impedir la modificación del NIF con posterioridad a la introducción del “número de referencia”. El jueves 13 de abril de 2016 se realiza un pase a producción de una nueva versión del programa Renta Web, que incluye las modificaciones de seguridad relacionadas con la quiebra. La AEAT ha expresado su intención de reforzar todos los controles relativos a cómo integrar en una declaración datos fiscales de otros contribuyentes e incluir pruebas específicas para evitar cualquier disfunción. TERCERO: Con fecha 11/11/2016, la Directora de la Agencia Española de Protección de Datos acordó iniciar procedimiento de declaración de infracción de Administraciones Públicas a la entidad AEAT por la presunta infracción del artículo 9 de la LOPD, en relación con los artículos 91 y 93 de su Reglamento de desarrollo, aprobado por Real Decreto 1720/2007, de 21 de diciembre, e infracción del artículo 10 de la citada Ley Orgánica, tipificadas como graves en los artículos 44.3.

  1. h)y 44.3.
  2. d)de la misma norma, respectivamente. CUARTO: Notificado el citado acuerdo de inicio de procedimiento de declaración de infracción de Administraciones Públicas, la entidad AEAT presentó escrito de alegaciones en el que solicita el archivo del mismo de conformidad con las consideraciones siguientes: 1. En relación con los hechos objeto de las actuaciones, se muestra conforme con el relato fáctico reseñado en el acuerdo de apertura del procedimiento, si bien estima oportuno formular algunas precisiones para resaltar, por un lado, que dispone de una consolidada normativa de seguridad en el uso de la información, aprobada conforme exige el Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica, y por otro lado, las medidas de seguridad específicas aplicadas a la producción de C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 9/26 aplicaciones informáticas, incluida la realización de planes de pruebas y la existencia de una herramienta colaborativa de compartición del conocimiento (Twiki), que se mantiene actualizada con información que es de utilidad para las Áreas de desarrollo y donde se recogen miles de criterios y buenas prácticas relacionadas con el entorno de desarrollo de aplicaciones tributarias. A este respecto, señala que cuando se indica en la resolución de inicio del expediente que en la herramienta colaborativa de compartición del conocimiento (Twiki) desde agosto de 2015 se “advertía explícitamente sobre el error de programación que representa la codificación que ha dado lugar a la quiebra”, se obvia que, además de este criterio de programación, se encontraban otros cientos de criterios y buenas prácticas, que se deben seguir para el desarrollo de aplicaciones, muchos de los cuales pueden, en hipótesis, ser causa de incidentes de seguridad. Por lo tanto, que existiera un criterio, que si no se seguía podía ser causa de un incidente de seguridad, no era ni es una situación excepcional. La gestión de riesgos en la seguridad de la información no puede pretender la eliminación total de los mismos, sino su reducción “hasta niveles aceptables”. Así dicha herramienta se configura para detectar los errores habituales y esperados, en condiciones de un normal uso de la aplicación, pero no se configura para detectar errores ante cualquier circunstancia imprevisible, pues ello haría inoperante la herramienta al detectar tantos falsos errores positivos y negativos que en la práctica exigiría una revisión “humana” y no automatizada de la aplicación, lo que haría innecesaria dicha herramienta informática (el desarrollo de la aplicación ya se realiza por personas que pueden cometer errores humanos, que son precisamente los que tratan de detectarse con una herramienta automatizada). En cuanto al número de afectados, aclara que cuando se indica que la quiebra afectó a 2793 personas se quiere decir que se generó de forma indebida un “pdf” con los datos de la declaración del IRPF de 2015 de 2793 personas, pero no que efectivamente se visualizaran por terceros dichos datos respecto de esa cantidad de personas, pues no es posible determinar si efectivamente tuvo lugar esa visualización y/o almacenamiento de los datos. Asimismo, reitera que ya puso en conocimiento de la AEPD la incidencia, que adoptó de forma inmediata medidas correctoras, complementado el plan de pruebas para la Campaña de Renta de 2016 para incluir pruebas específicas relacionadas con los incidentes reseñados, se han definido reglas orientadas a detectar la causa del error y se ha aprobado una Norma de Desarrollo Seguro de las aplicaciones de la Agencia Estatal de Administración Tributaria mediante Instrucción 1/2016, de 6 de septiembre de 2016, de la Dirección del Departamento de Informática Tributaria, con el objetivo de actualizar y reforzar los controles de seguridad que se aplican a los desarrollos de la Agencia Tributaria. Respecto de la información facilitada a los afectados y a terceros para notificar la quiebra de seguridad, advierte que se pretendió no generar una alarma indebida, evitando poner el foco en riesgos que se consideran muy poco probables (como es la utilización por parte de terceros de la cuenta bancaria, considerando que no se había producido un robo de datos), y utilizar un lenguaje comprensible para un colectivo heterogéneo e indeterminado Para ello, se evitó hacer referencia a la posible infracción de legislación que pudiera considerarse como una coacción o amenaza. Conscientes de la complejidad de estas notificaciones, en ambas cartas se incluía un número de teléfono de atención al contribuyente de la Agencia Tributaria en el que atender las posibles dudas relacionadas con el contenido de las mismas y se redactó un argumentario para dar respuesta a los contribuyentes. 2. El acuerdo de apertura del procedimiento no contiene un análisis del elemento subjetivo que C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 10/26 ha de concurrir para la existencia de una infracción, considerando que nuestro sistema punitivo (ya sea administrativo o penal) no admite supuestos de responsabilidad objetiva. En cuanto a la vulneración del deber de secreto, considera que no todo acceso por terceros a datos personales conlleva la comisión de la infracción tipificada en el art 44.3.d), pues como señala el artículo 28.1 de la Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público, “Sólo podrán ser sancionadas por hechos constitutivos de infracción administrativa las personas físicas y jurídicas, (…), que resulten responsables de los mismos a título de dolo o culpa”. En este caso es indudable la falta de intencionalidad en la infracción del deber de secreto. Si así fuera no es que se hubiera vulnerado el deber de secreto sino que se habría realizado una infracción del art 11 de la LOPD y la infracción cometida sería la del art 44.3.k), no siendo tampoco la comunicación un acto voluntario, dado que se realizó automáticamente por una aplicación informática. En consecuencia, únicamente cabe imputar la infracción a la AEAT a título de culpa, vinculada en un incumplimiento de medidas de seguridad, por lo que en puridad la infracción imputable a la AEAT en este caso no sería la del art 44.3.d), sino la del art 44.3.h). 3. No existe medida de seguridad alguna que elimine absolutamente el riesgo de un acceso indebido a la información. El propio artículo 9 utiliza como parámetro comparativo de las medidas de seguridad a adoptar al “estado de la tecnología”, debiendo recordarse que, en el ámbito de las Administraciones Públicas, dichas medidas de seguridad tienen una regulación específica en el RD 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica, más allá de lo recomendado por la AEPD en su Guía de Seguridad de Datos. Dicha norma, en su artículo 5 establece, como principios que deben regir la Seguridad de la Información, la seguridad integral, gestión de riesgos, prevención, reacción y recuperación, líneas de defensa, reevaluación periódica y función diferenciada. Y el artículo 6.2 del RD 3/2010 señala que la gestión de riesgos tiene por objeto “minimiza(
  3. r)los riesgos hasta niveles aceptables”, mientras que, en relación con la prevención, el artículo 7.2 dispone que “Las medidas de prevención deben eliminar o, al menos reducir, la posibilidad de que las amenazas lleguen a materializarse con perjuicio para el sistema”, porque el propio legislador es consciente de la imposibilidad de eliminar dichos riesgos totalmente o, al menos, que dicha eliminación incidiría negativamente en el derecho de los ciudadanos a la comunicación electrónica con las Administraciones. Por ello, dentro de la configuración de los Sistemas de Seguridad se contemplan medidas preventivas y reactivas. En este sentido, el artículo 8 del mismo Real Decreto establece que el sistema ha de disponer de una estrategia de protección constituida por múltiples capas de seguridad, dispuesta de forma que, cuando una de las capas falle, permita ganar tiempo para una reacción adecuada frente a los incidentes que no han podido evitarse, reducir la probabilidad de que el sistema sea comprometido en su conjunto y minimizar el impacto final sobre el mismo. Señala la AEAT que en este caso se ha cumplido escrupulosamente con dichos principios. De hecho, únicamente se ponen de relieve dos posibles circunstancias que hubieran podido evitar el incidente: . La primera de ellas hace referencia a que en la herramienta colaborativa de compartición del C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 11/26 conocimiento (Twiki) desde agosto de 2015 se “advertía explícitamente sobre el error de programación que representa la codificación que ha dado lugar a la quiebra”. Respecto a esta cuestión, imputar negligencia a la AEAT por dicho motivo supondría ignorar, por un lado, que la propia existencia de dicha herramienta ya supone una medida preventiva no exigida, y por otro lado que no puede apreciarse que fallara dicha medida preventiva pues, dada la complejidad que supone la programación de una aplicación informática como la desarrollada por la AEAT, resulta imposible asegurar que los programadores no cometan un error en algún código Precisamente, para minimizar ese riesgo de “fallo humano”, se utiliza una aplicación informática que revisa y valida la aplicación desarrollada. . En segundo lugar se alude como elemento negligente a que la Agencia Tributaria “dispone de una herramienta de comprobación automática de código que no incluye ninguna regla que permita identificar el error de programación citado”. Nuevamente, se utiliza una medida preventiva (muy compleja) adicional adoptada por la AEAT como justificación de una posible negligencia, obviando, además, que si se configurara dicha herramienta para detectar cualquier comando que considere, como un error de código, más allá de los más habituales que puedan producirse con un uso normal de la aplicación (que fue la forma en la que fue configurada la herramienta), se generaría tal cúmulo de falsos positivos y negativos que harían necesaria una revisión “humana” de los códigos de la aplicación, revisión que estaría, consecuentemente, sujeta a ese posible error humano que pretende precisamente limitarse con la herramienta de revisión En suma, los hechos reflejan que la AEAT ha actuado de forma diligente, estableciendo distintos filtros encaminados a minimizar los riesgos de seguridad en la información, lo cual no ha impedido que finalmente se produjera un incidente de seguridad que, no obstante, fue objeto de reacción inmediata, cumpliendo escrupulosamente con la normativa de seguridad por la que se rige la AEAT. 4. Considera innecesario tramitar el procedimiento por haberse adoptado ya las recomendaciones formuladas por la AEPD, puesto que la finalidad del mismo es, precisamente, la adopción de dichas medidas correctoras y no la imposición de sanciones, de acuerdo con lo establecido en el artículo 46 de la LOPD. En este caso, se han adoptado medidas correctoras y otras complementarias, tales como las siguientes: . Se corrigieron en apenas 24 horas los problemas de programación de la aplicación, suspendiendo su posible uso hasta que fuera corregido para poner fin a posibles accesos indebidos a los datos. . Se notificó a los potenciales afectados y a los terceros que pudieran haber accedido indebidamente a información de aquéllos, la incidencia y su transcendencia evitando crear una alarma innecesaria y utilizando un lenguaje comprensible a cualquier persona, poniendo incluso a su disposición un teléfono de atención personalizado para atender dudas sobre dichas incidencias. . Se adoptaron medidas adicionales de seguridad en el desarrollo de aplicaciones informáticas incluyendo pruebas específicas relacionadas con los incidentes. . Se ha plasmado en una Instrucción del Director del Departamento de Informática Tributaria, las prácticas de seguridad en el desarrollo de aplicaciones informáticas que ya venían implementándose. QUINTO: Con fecha 17/03/2017, se emitió propuesta de resolución en el sentido de que por la Directora de la AEPD se declare que la entidad AEAT ha infringido lo dispuesto en el artículo 9 de la LOPD, en relación con los artículos 91 y 93 de su Reglamento de desarrollo, aprobado por Real Decreto 1720/2007, de 21 de diciembre, tipificada como grave en el artículo 44.3.
  4. h)de la misma norma; y que se declare que la misma ha adoptado medidas de orden interno adecuadas C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 12/26 para impedir que en el futuro pueda producirse una nueva infracción similar a la analizada en el presente procedimiento. Se propuso, asimismo, que se comunique la Resolución que se adopte al Defensor del Pueblo, de conformidad con lo establecido en el artículo 46.4 de la LOPD. SEXTO: Notificada la citada propuesta, la entidad AEAT presentó escrito de alegaciones en el que reitera las formuladas a la apertura del procedimiento. Según la AEAT, la propuesta de resolución imputa una responsabilidad objetiva, por cuanto en la misma se considera que la mera existencia de una brecha de seguridad supone sin más la comisión de una infracción y que concurre el elemento de la culpabilidad por tratarse de una obligación de resultado en materia de seguridad de datos, lo cual supone automáticamente considerar que si no se consigue el resultado se habrá cometido la infracción. La propuesta de resolución omite cualquier motivación al respecto de las alegaciones formuladas a la apertura del procedimiento, exigiendo una infalibilidad contraria a los artículos 6.2 y 7.2 del RD 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica, los cuales prevén que la gestión de riesgos en la seguridad de la información no puede pretender la eliminación total de los mismos, sino su reducción “hasta niveles aceptables” y que “las medidas de prevención deben eliminar o, al menos reducir, la posibilidad de que las amenazas lleguen a materializarse”. De hecho, la aceptación de la imposibilidad de prevenir cualquier riesgo de acceso indebido a la información conlleva a que, dentro de la configuración de los Sistemas de Seguridad no se contemplen únicamente medidas preventivas, sino también reactivas. En consecuencia, la motivación no sólo de la existencia de culpabilidad, sino de la misma existencia de una conducta típica pasa por determinar si los ficheros se han mantenido sin las medidas de seguridad determinadas reglamentariamente que, en el caso de la AEAT, pasa por analizar si la misma ha cumplido con el RD 3/2010. De hecho, la propuesta de resolución únicamente identifica como posible fallo en el desarrollo del software que ocasionó la brecha de seguridad señalando lo siguiente: “En relación con la quiebra notificada el día 08/0412016, la AEAT tenía conocimiento de que el error podía producirse y advirtió de ello a los Integrantes de sus equipos de desarrollo de sistemas informáticos antes de que el error produjese la quiebra Además, dicha entidad dispone de una herramienta de revisión automática de código que podría haber detectado el error, pero no incluyó una comprobación que detectase ese tipo de error dentro del conjunto de comprobaciones a realizar. Por otra parte, las pruebas de carga realizadas por la AEAT podrían haber detectado las consecuencias del error de programación si en lugar de Limitarse a comprobar que el sistema era capaz de generar los borradores solicitados bajo determinadas condiciones de carga, también hubiese comprobado que los datos de los borradores so correspondían con los de los solicitantes”. No tiene en cuenta la AEPD las alegaciones sobre la complejidad de la herramienta, la cual, además, no estaba completamente implantada sino en proceso de integración en el ciclo de vida de desarrollo de las aplicaciones de la Agencia Tributaria y que por lo tanto, si se hubiera hecho uso de ella sin el tiempo adecuado de adaptación
  5. a)entorno de desarrollo de la AEAT, se podrían haber generado otros riesgos que podían haber sido origen de otras incidencias. En el C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 13/26 momento del desarrollo de las aplicaciones de la Campaña de Renta 2015, se trataba de una herramienta en proceso de pruebas e implantación, para determinar en qué grado se integraría en el ciclo de vida de desarrollo. En el grado de implantación en que se encontraba era materialmente imposible haberla utilizado con plenas garantías en el ciclo de vida de desarrollo de las aplicaciones de la Campaña de Renta 2015. HECHOS PROBADOS 1. El año 2016, para la Campaña de Renta 2015, la AEAT habilitó una aplicación web denominada RentaWeb, que permite a los contribuyentes generar y gestionar el borrador de Renta, así como realizar la autoliquidación del Impuesto sobre la Renta de las Personas Físicas. 2. Con fecha de 05/04/2016, a las 15:00 horas, se produjo un incidente de seguridad en el sistema RentaWeb, que fue notificado a esta Agencia por la propia entidad AEAT un día después. Este incidente dio lugar a la difusión de datos personales de contribuyentes correspondientes a la Renta de 2015 y la posible utilización de la casilla de Renta para la obtención del número de referencia que posibilitará el acceso al sistema durante la campaña del año 2016. La quiebra de seguridad fue detectada por un contribuyente que lo puso en conocimiento de la AEAT a las 10:51 horas del día 06/04/2016, motivando que a las 13:05 horas del mismo día se inhabilitara por la misma el botón que permitía obtener el borrador de la declaración de renta. La incidencia reseñada consistió en que al utilizar la opción de generar una vista previa del borrador de la declaración del IRPF en la campaña de Renta 2015, en algunos casos el sistema facilitó un fichero en formato pdf con el borrador de un contribuyente distinto del solicitante, el cual era descargado en el equipo de éste y podía ser almacenado en el mismo. Entre los datos personales a los que tuvieron acceso los terceros que obtuvieron un borrador de otro contribuyente figuran los datos del declarante y cónyuge (nombre, apellidos, domicilio, teléfonos, estado civil, grado de discapacidad y titularidad de su vivienda habitual), datos económicos (bases imponibles y liquidables, deducciones y cuotas aplicables o el importe resultante de la declaración), número de la cuenta corriente; y, en su caso, datos del arrendador (NIF), del representante del contribuyente (NIF, nombre y apellidos o razón social), datos de personas menores de 25 años, mayores de 65 años o con discapacidad que convivieran con los declarantes (datos identificativos, fecha de nacimiento, adopción o acogimiento y grado de discapacidad). El número definitivo de terceros que al solicitar su borrador obtuvieron en su lugar el de un declarante afectado es de 2.886, lo que representa un 2,5 % del total de las solicitudes del período. En número definitivo de declarantes afectados es de 2.793. La causa de esta quiebra fue un error de programación en el sistema Rentaweb. A este respecto, en la visita de inspección realizada a la AEAT, los representantes de la misma declararon lo siguiente: “La nueva arquitectura… requiere de adaptaciones en la forma de programar las clases Java que, por error, no fueron tenidas en cuenta para esta clase concreta. Además el error cometido únicamente tenía consecuencias en el caso de una elevada carga de los servidores que atienden al sistema. C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 14/26 (…) Las pruebas de carga que se realizaron sobre los servidores no hallaron el error que dio lugar a la violación de seguridad porque están diseñadas para probar que los servidores responden a todas las peticiones y no el contenido de cada respuesta, que en este caso concreto, era un documento en formato PDF. La DIT de la AEAT dispone de una herramienta de comprobación automática de código que no incluye por defecto ninguna regla que permita identificar el error de programación citado”. Por otra parte, en la misma visita de inspección se constató que la DIT dispone de un centro de conocimiento web en el que se incluye información sobre aspectos técnicos del trabajo. Se comprobó que en el apartado correspondiente a la arquitectura adoptada para el sistema RentaWeb ya se advertía desde agosto de 2015 sobre el error de programación que representaba la codificación que ha dado lugar a la quiebra. 3. El día 7 de abril de 2016, a las 15:30 horas, la AEAT sube a producción una nueva versión del software que solventa el error. Además, informó a la Agencia Española de Protección de Datos que “se reforzarán las medidas de inspección del código para evitar el error que ha provocado el incidente y se reforzarán las pruebas dirigidas a detectar este tipo de errores”. Asimismo, se inhabilitó el acceso a los datos de la campaña de la renta de 2016 a través del uso de los datos que figuran en los borradores accedidos por terceros. 4. La AEAT, a requerimiento de la Agencia Española de Protección de Datos, remitió un escrito a los contribuyentes afectados informándoles sobre el incidente de seguridad reseñado en el Hecho Probado Segundo y advirtiendo que para la campaña de Renta del año 2016 se ha inhabilitado la obtención del número de referencia a través de la casilla de la declaración de Renta 2015. Remitió, asimismo, un escrito a los terceros que pudieron acceder a los datos de otros contribuyentes, solicitando que eviten su utilización y conservación 5. Con fecha de 08/04/2016, se produjo un incidente de seguridad en el sistema RentaWeb, que dio lugar al acceso por parte de un contribuyente a los datos fiscales del año 2015 de otros (los relativos a un socio y un familiar de aquél), el cual fue comunicado a la AEAT por el contribuyente que tuvo acceso a la información del tercero mediante llamada telefónica realizada a las 14:50 horas. Dicha entidad, a su vez, lo notificó a la Agencia Española de Protección de Datos el mismo día. Este incidente estuvo relacionado con la declaración del IRPF de unidades familiares. En estos casos, Rentaweb proporciona a un usuario autenticado la posibilidad de acceder a datos de un tercero, previa presentación de un número de referencia que la AEAT ha facilitado al tercero. La incidencia consistió en que, una vez proporcionado el número de referencia y recuperados los datos fiscales del tercero, si el usuario volvía atrás a la página de datos personales y modificaba el NIF, nombre y apellidos del tercero por los de otra persona física real, el sistema proporcionaba los datos del nuevo contribuyente sin exigir un nuevo número de referencia que permitiese comprobar que existe una relación entre el usuario y el nuevo contribuyente. Los datos accedidos corresponden a NIF, nombre y apellidos del contribuyente, datos sobre rendimientos del trabajo, rentas exentas, premios y ganancias, incluyendo el pagador o pagadores y las retribuciones; datos sobre las actividades económicas del contribuyente incluyendo el código y tipo de actividad, el pagador o pagadores y los ingresos; rendimientos de C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 15/26 cuentas bancarias (que incluyen los números de cuenta), letras del tesoro o capital mobiliario; información catastral de inmuebles en los que tiene participación; donaciones, cuotas y aportaciones a partidos políticos; deducciones por maternidad, ascendientes, descendientes discapacitados a cargo; etc. La causa de esta quiebra fue un error en el diseño del módulo de Rentaweb que permite el acceso a los datos de contribuyentes distintos del declarante. El modulo en cuestión no impedía la modificación del NIF, nombre y apellidos del contribuyente distinto del declarante una vez facilitada una referencia válida. 6. El incidente quedó subsanado a las 18:46 horas. Inicialmente, se aplicó un parche de emergencia para impedir la modificación del NIF con posterioridad a la introducción del “número de referencia”. El 13/04/2016 se pasó a producción una nueva versión del programa RentaWeb, que incluyó las modificaciones de seguridad relacionadas con la quiebra. La AEAT ha expresado su intención de reforzar todos los controles relativos a cómo integrar en una declaración datos fiscales de otros contribuyentes e incluir pruebas específicas para evitar cualquier disfunción. FUNDAMENTOS DE DERECHO I Es competente para resolver este procedimiento la Directora de la Agencia Española de Protección de Datos, de conformidad con lo dispuesto en el artículo 37.
  6. g)en relación con el artículo 36 de la LOPD. II El artículo 18.4 de la Constitución Española establece en que: “la ley limitará el uso de la informática para garantizar el honor y la intimidad personal y familiar de los ciudadanos y el pleno ejercicio de sus derechos”, consagrándose así el derecho a la protección de datos como un derecho autónomo, incluso del propio derecho a la intimidad, tal y como ha indicado la Sentencia del Tribunal Constitucional 292/2000, de 30 de noviembre. El artículo 1 de la LOPD dispone: “La presente Ley Orgánica tiene por objeto garantizar y proteger, en lo que concierne al tratamiento de los datos personales, las libertades públicas y los derechos fundamentales de las personas físicas, y especialmente de su honor e intimidad personal y familiar”. En cuanto al ámbito de aplicación de la citada norma, el artículo 2.1 de la misma señala que “La presente Ley Orgánica será de aplicación a los datos de carácter personal registrados en soporte físico que los haga susceptibles de tratamiento, y a toda modalidad de uso posterior de estos datos por los sectores público y privado”; definiéndose el concepto de dato de carácter personal en el artículo 3.
  7. a)de la citada LOPD como “Cualquier información concerniente a personas físicas identificadas o identificables”. En este mismo sentido se pronuncia el artículo 2.
  8. a)de la Directiva 95/46/CE, del Parlamento y del Consejo, de 24/10/1995, relativa a la Protección de las Personas Físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos (en lo sucesivo la Directiva), según el cual se entiende por dato personal “toda información sobre una C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 16/26 persona física identificada o identificable; se considerará identificable toda persona cuya identidad pueda determinarse, directa o indirectamente, en particular mediante un número de identificación o uno o varios elementos específicos, característicos de su identidad física, fisiológica, psíquica, económica, cultural o social”. En el presente caso, ha quedado acreditado que el fichero al que pertenecen los datos personales en cuestión, atendiendo a su contenido, que consta detallado en los Hechos Probados Segundo y Quinto (entre otros, nombre, apellidos, domicilio, teléfonos, estado civil, grado de discapacidad y titularidad de su vivienda habitual, datos económicos, número de cuenta corriente, datos de inmuebles; personas con las que convive el contribuyente, etc.), se encuentra incluido dentro del ámbito de aplicación establecido en la LOPD y sus normas de desarrollo. Interesa destacar que la cantidad de datos potencialmente expuestos proporcionan una imagen nítida de la situación familiar y económica de las personas afectadas. III El Titulo VII sobre Infracciones y sanciones, en el artículo 43, de la LOPD establece: “1. Los responsables de los ficheros y los encargados de los tratamientos estarán sujetos al régimen sancionador establecido en la presente Ley.” IV Se imputa a la entidad AEAT el incumplimiento del principio de seguridad de los datos personales que constan en sus ficheros. El Art. 7 del Convenio Nº 108 del Consejo de Europa, para la protección de las personas con respecto al tratamiento automatizado de datos de carácter personal, establece: “Seguridad de los datos: Se tomarán medidas de seguridad apropiadas para la protección de datos de carácter personal registrados en ficheros automatizados contra la destrucción accidental o no autorizada, o la pérdida accidental, así como contra el acceso, la modificación o la difusión no autorizados”. El Art 17.1 de la Directiva 95/46/CE relativa a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos, establece: “Seguridad del tratamiento: 1. Los Estados miembros establecerán la obligación del responsable del tratamiento de aplicar las medidas técnicas y de organización adecuadas, para la protección de los datos personales contra la destrucción, accidental o ilícita, la pérdida accidental y contra la alteración, la difusión o el acceso no autorizados, en particular cuando el tratamiento incluya la transmisión de datos dentro de una red, y contra cualquier otro tratamiento ilícito de datos personales. Dichas medidas deberán garantizar, habida cuenta de los conocimientos técnicos existentes y del coste de su aplicación, un nivel de seguridad apropiado en relación con los riesgos que presente el tratamiento y con la naturaleza de los datos que deban protegerse” La LOPD, traspuso al ordenamiento interno el contenido de la Directiva 95/46. En el artículo 9 de la citada LOPD se dispone lo siguiente: C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 17/26 “1. El responsable del fichero, y, en su caso, el encargado del tratamiento, deberán adoptar las medidas de índole técnica y organizativas necesarias que garanticen la seguridad de los datos de carácter personal y eviten su alteración, pérdida, tratamiento o acceso no autorizado, habida cuenta del estado de la tecnología, la naturaleza de los datos almacenados y los riesgos a que están expuestos, ya provengan de la acción humana o del medio físico o natural. 2. No se registrarán datos de carácter personal en ficheros que no reúnan las condiciones que se determinen por vía reglamentaria con respecto a su integridad y seguridad y a las de los centros de tratamiento, locales, equipos, sistemas y programas. 3. Reglamentariamente se establecerán los requisitos y condiciones que deban reunir los ficheros y las personas que intervengan en el tratamiento de los datos a que se refiere el artículo 7 de esta Ley”. El citado artículo 9 de la LOPD establece el “principio de seguridad de los datos” imponiendo la obligación de adoptar las medidas de índole técnica y organizativa que garanticen dicha seguridad, añadiendo que tales medidas tienen como finalidad evitar, entre otros aspectos, el “acceso no autorizado” por parte de terceros y su “perdida”. Para poder delimitar cuáles son los accesos que la LOPD pretende evitar exigiendo las pertinentes medidas de seguridad, es preciso acudir a las definiciones de “fichero” y “tratamiento” contenidas en la LOPD. En lo que respecta a los ficheros el artículo 3.
  9. a)los define como “todo conjunto organizado de datos de carácter personal” con independencia de la modalidad de acceso al mismo. Por su parte, la letra
  10. c)del mismo artículo 3 permite considerar tratamiento de datos cualquier operación o procedimiento técnico que permita, en lo que se refiere al objeto del presente expediente, la “conservación” o “consulta” de los datos personales tanto si las operaciones o procedimientos de acceso a los datos son automatizados como si no lo son. Para completar el sistema de protección en lo que a la seguridad afecta, el artículo 44.3.
  11. h)de la LOPD tipifica como infracción grave el mantener los ficheros “...que contengan datos de carácter personal sin las debidas condiciones de seguridad que por vía reglamentaria se determinen”. Sintetizando las previsiones legales puede afirmarse que:
  12. a)Las operaciones y procedimientos técnicos automatizados o no, que permitan el acceso –la conservación o consulta- de datos personales, es un tratamiento sometido a las exigencias de la LOPD.
  13. b)Los ficheros que contengan un conjunto organizado de datos de carácter personal así como el acceso a los mismos, cualquiera que sea la forma o modalidad en que se produzca, están, también, sujetos a la LOPD.
  14. c)La LOPD impone al responsable del fichero la adopción de medidas de seguridad, cuyo detalle se refiere a normas reglamentarias, que eviten accesos no autorizados.
  15. d)El mantenimiento de ficheros carentes de medidas de seguridad que permitan accesos o tratamientos no autorizados, cualquiera que sea la forma o modalidad de éstos, constituye una infracción tipificada como grave. Las medidas de seguridad se clasifican en atención a la naturaleza de la información tratada, esto es, en relación con la mayor o menor necesidad de garantizar la confidencialidad y C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 18/26 la integridad de la misma. Dichas medidas, en el caso que nos ocupa, deben salvaguardar la confidencialidad y seguridad de los datos de carácter personal tratados por la entidad AEAT pertenecientes a personas que perciben rentas sujetas al Impuesto sobre la Renta de las Personas Físicas, correspondiendo adoptar las reguladas en el Reglamento de desarrollo de la LOPD, aprobado por RD 1720/2007, de 21 de diciembre. Las medidas de seguridad de nivel básico están reguladas en los artículos 89 a 94, las de nivel medio se regulan en los artículos 95 a 100 y las medidas de seguridad de nivel alto se regulan en los artículos 101 a 104, del Reglamento de desarrollo de la LOPD. Los artículos 91 y 93 del citado Reglamento, aplicable a todos los ficheros y tratamientos automatizados, establecen: “Artículo 91. Control de acceso. 1. Los usuarios tendrán acceso únicamente a aquellos recursos que precisen para el desarrollo de sus funciones. 2. El responsable del fichero se encargará de que exista una relación actualizada de usuarios y perfiles de usuarios, y los accesos autorizados para cada uno de ellos. 3. El responsable del fichero establecerá mecanismos para evitar que un usuario pueda acceder a recursos con derechos distintos de los autorizados. 4. Exclusivamente el personal autorizado para ello en el documento de seguridad podrá conceder, alterar o anular el acceso autorizado sobre los recursos, conforme a los criterios establecidos por el responsable del fichero. 5. En caso de que exista personal ajeno al responsable del fichero que tenga acceso a los recursos deberá estar sometido a las mismas condiciones y obligaciones de seguridad que el personal propio”. Este artículo desarrolla las previsiones que deberá establecer el responsable del fichero para garantizar que los usuarios con accesos a datos personales o recursos, por haber sido previamente autorizados, sólo puedan acceder a tales datos y recursos. Para ello es necesario que se implanten mecanismos de control para evitar que un usuario pueda acceder a datos o funcionalidades que no se correspondan con el tipo de acceso autorizado para el mismo, en función del perfil de usuario asignado. “Artículo 93. Identificación y autenticación. 1. El responsable del fichero o tratamiento deberá adoptar las medidas que garanticen la correcta identificación y autenticación de los usuarios. 2. El responsable del fichero o tratamiento establecerá un mecanismo que permita la identificación de forma inequívoca y personalizada de todo aquel usuario que intente acceder al sistema de información y la verificación de que está autorizado. 3. Cuando el mecanismo de autenticación se base en la existencia de contraseñas existirá un procedimiento de asignación, distribución y almacenamiento que garantice su confidencialidad e integridad. 4. El documento de seguridad establecerá la periodicidad, que en ningún caso será superior a un año, con la que tienen que ser cambiadas las contraseñas que, mientras estén vigentes, se almacenarán de forma ininteligible”. El artículo 5.2.
  16. b)del citado Reglamento define la “autenticación” como el procedimiento de comprobación de la identidad de un usuario; y el mismo artículo, letra h), se refiere a la C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 19/26 “identificación” como el procedimiento de reconocimiento de la identidad de un usuario. Corresponde al responsable del fichero o tratamiento comprobar la existencia de la autorización exigida en el citado artículo 91, con un proceso de verificación de la identidad de la persona (autenticación) implantando un mecanismo que permita acceder a datos o recursos en función de la identificación ya autenticada. Cada identidad personal deberá estar asociada con un perfil de seguridad, roles y permisos concedidos por el responsable del fichero o tratamiento. En definitiva, como responsable del fichero, la entidad AEAT está obligada a adoptar, de manera efectiva, las medidas técnicas y organizativas necesarias previstas para los ficheros de los que es responsable, y, entre ellas, las dirigidas a impedir el acceso no autorizado por parte de terceros a los datos personales que constan en los mismos. En este caso, sin embargo, ha quedado acreditado que la citada entidad incumplió esta obligación, al establecer un sistema de acceso y gestión de borradores de declaraciones de IRPF para la renta del ejercicio 2015, disponible a través de su portal web, que no impidió de manera fidedigna que por parte de unos contribuyentes determinados se pudiera acceder a datos personales y fiscales de otros ciudadanos que hubiesen obtenido rentas en ese ejercicio o de otros afectados que hubiesen tenido alguna relación con los mismos, según los detalles que constan en los Hechos Probados Segundo y Quinto. Por tanto, el acceso al sistema RentaWeb permitió, no únicamente el acceso a la información del contribuyente respectivo, sino a la correspondiente a terceros. Concretamente, ha quedado acreditado que debido a un error de programación de uno de los componentes del sistema Rentaweb, con fecha 06/04/2016, los datos identificativos, económicos y financieros de 2.886 contribuyentes fueron puestos a disposición de personas que no estaban autorizadas para ello. La incidencia consistió en que al utilizar la opción de generar una vista previa del borrador de la declaración del IRPF en la campaña de Renta 2015, en algunos casos el sistema facilitó un fichero en formato pdf con el borrador de un contribuyente distinto del solicitante, el cual era descargado en el equipo de éste y podía ser almacenado en el mismo. Por otra parte, el 08/04/2016, se produjo un nuevo incidente de seguridad relacionado con la declaración del IRPF de unidades familiares, también por un error en el diseño del módulo de Rentaweb que permite el acceso a los datos de contribuyentes distintos del declarante. El modulo en cuestión no impedía la modificación del NIF, nombre y apellidos del contribuyente distinto del declarante una vez facilitada una referencia válida, de modo que, una vez proporcionado el número de referencia y recuperados los datos fiscales del tercero, si el usuario volvía atrás a la página de datos personales y modificaba del NIF, nombre y apellidos del tercero por los de otra persona física real, el sistema proporcionaba los datos del nuevo contribuyente sin exigir un nuevo número de referencia que permitiese comprobar que existe una relación entre el usuario y el nuevo contribuyente. Debe resaltarse, no obstante, que no se tiene constancia de que la quiebra haya sido detectada por personas distintas de la que comunicó el incidente a la AEAT. Se trata de deficiencias apreciadas en el sistema de información diseñado por la propia entidad AEAT que quedaron acreditadas por la documentación aportada por dicha entidad, que notificó voluntariamente las incidencias a esta Agencia Española de Protección de Datos; por los denunciantes que constan reseñados en Anexo, que aportaron copia de los archivos accedidos; y por las comprobaciones realizadas por los Servicios de Inspección. C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 20/26 Así, los datos personales tratados por la entidad AEAT, pertenecientes a contribuyentes del ejercicio 2015 y personas relacionadas con éstos, resultaron accesibles para otros contribuyentes no interesados desde la misma zona habilitada para los mismos, siendo ello consecuencia de una insuficiente o ineficaz implementación de las medidas de seguridad. Dado que ha existido vulneración del “principio de seguridad de los datos”, se considera que dicha entidad ha incurrido en la infracción grave descrita. AEAT es responsable de la infracción señalada, habiendo quedado justificada, al menos, una falta de la diligencia debida en los hechos constatados plenamente imputable a la misma. En relación con la quiebra notificada el día 06/04/2016, la AEAT tenía conocimiento de que el error podía producirse y advirtió de ello a los integrantes de sus equipos de desarrollo de sistemas informáticos antes de que el error produjese la quiebra. Además, dicha entidad dispone de una herramienta de revisión automática de código que podría haber detectado el error, pero no incluyó una comprobación que detectase ese tipo de error dentro del conjunto de comprobaciones a realizar. Por otra parte, las pruebas de carga realizadas por la AEAT podrían haber detectado las consecuencias del error de programación si en lugar de limitarse a comprobar que el sistema era capaz de generar los borradores solicitados bajo determinadas condiciones de carga, también hubiese comprobado que los datos de los borradores se correspondían con los de los solicitantes. A este respecto, en la visita de inspección realizada por los servicios de esta Agencia, los representantes de la entidad AEAT admitieron lo siguiente: “La nueva arquitectura… requiere de adaptaciones en la forma de programar las clases Java que, por error, no fueron tenidas en cuenta para esta clase concreta. Además el error cometido únicamente tenía consecuencias en el caso de una elevada carga de los servidores que atienden al sistema. (…) Las pruebas de carga que se realizaron sobre los servidores no hallaron el error que dio lugar a la violación de seguridad porque están diseñadas para probar que los servidores responden a todas las peticiones y no el contenido de cada respuesta, que en este caso concreto, era un documento en formato PDF. La DIT de la AEAT dispone de una herramienta de comprobación automática de código que no incluye por defecto ninguna regla que permita identificar el error de programación citado”. Asimismo, la quiebra notificada el día 08/04/2016 se debe a un error en el diseño del sistema que, al no prever una navegación distinta de la habitual, no incluyó la programación de medidas para evitar que se pudieran modificar los datos del tercero cuyos datos se estaban consultando, bien mediante el bloqueo del campo NIF una vez autenticado, bien mediante la solicitud de un número de referencia del nuevo tercero. V La AEAT ha alegado que disponía de las medidas de seguridad exigidas por la normativa aplicable, incluidas las establecidas en el Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica. Sin embargo, ha de tenerse en cuenta que en esta materia se impone una obligación de C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 21/26 resultado, que conlleva la exigencia de que las medidas implantadas deben impedir, de forma efectiva, el acceso a la información por parte de terceros. Esta necesidad de especial diligencia en la custodia de la información por el responsable ha sido puesta de relieve por la Audiencia Nacional, en su Sentencia de 11/12/08 (recurso 36/08), fundamento cuarto: “Como ha dicho esta Sala en múltiples sentencias…se impone, en consecuencia, una obligación de resultado, consistente en que se adoptan las medidas necesarias para evitar que los datos se pierdan, extravíen o acaben en manos de terceros…la recurrente es, por disposición legal una deudora de seguridad en materia de datos, y por tanto debe dar una explicación adecuada y razonable de cómo los datos han ido a parar a un lugar en el que son susceptibles de recuperación por parte de terceros, siendo insuficiente con acreditar que adopta una serie de medidas, pues es también responsable de que las mismas se cumplan y se ejecuten con rigor”. El principio de culpabilidad es exigido en el procedimiento sancionador y así la STC 246/1991 considera inadmisible en el ámbito del Derecho administrativo sancionador una responsabilidad sin culpa. Pero el principio de culpa no implica que sólo pueda sancionarse una actuación intencionada y a este respecto el artículo 130.1 de la Ley 30/1992, de 26 de noviembre, de Régimen Jurídico de las Administraciones Públicas y del Procedimiento Administrativo Común, dispone “sólo podrán ser sancionadas por hechos constitutivos de infracción administrativa las personas físicas y jurídicas que resulten responsables de los mismos aun a título de simple inobservancia.” El Tribunal Supremo (STS 16 de abril de 1991 y STS 22 de abril de 1991) considera que del elemento culpabilista se desprende “que la acción u omisión, calificada de infracción sancionable administrativamente, ha de ser, en todo caso, imputable a su autor, por dolo o imprudencia, negligencia o ignorancia inexcusable.” El mismo Tribunal razona que “no basta...para la exculpación frente a un comportamiento típicamente antijurídico la invocación de la ausencia de culpa” sino que es preciso “que se ha empleado la diligencia que era exigible por quien aduce su inexistencia.” (STS 23 de enero de 1998). A mayor abundamiento, la Audiencia Nacional en materia de protección de datos de carácter personal, ha declarado que “basta la simple negligencia o incumplimiento de los deberes que la Ley impone a las personas responsables de ficheros o del tratamiento de datos de extremar la diligencia...” (SAN 29de junio de 2001). Es la entidad AEAT la obligada última a garantizar la seguridad de los datos, asegurando la efectividad de las medidas adoptadas. Dicha entidad, en sus alegaciones a la propuesta de resolución, cuestiona este argumento señalando que no concurre en este caso el elemento de la culpabilidad, y presenta los hechos como una consecuencia inevitable y sin culpa, considerando los riesgos que conlleva cualquier sistema de seguridad de la información. Añade que los razonamientos de la AEPD justifican la comisión de la infracción únicamente en la existencia de una herramienta de revisión de código, que podría haber permitido detectar el error, sin haber tenido en cuenta que la misma se encontraba en proceso de integración en el ciclo de desarrollo de las aplicaciones de la AEAT. Entiende la AEAT que su actuación fue diligente y que ello no impidió que finalmente se produjera n los incidentes de seguridad. Sin embargo, omite dicha entidad que la infracción se consuma por el fallo de seguridad producido y la falta de medidas adecuadas para haberlo evitado, y no por un error en la detección del fallo, o una mala aplicación de las herramientas de revisión, o por errores en las pruebas de C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 22/26 carga realizadas. Es preciso tener presente la naturaleza de los incidentes de seguridad analizados y sus causas, reconocidas por la propia AEAT. Se produjo algo tan simple como que los datos de unos contribuyentes se facilitaron a otros contribuyentes a través de la aplicación web, algo tan elemental que no pueden justificarse por los riesgos inherentes a cualquier sistema de información. La AEAT misma calificó los fallos de seguridad como un error de programación y en el diseño de la aplicación, habiendo reconocido que no tuvo en cuenta las adaptaciones en la forma de programar que requiere la nueva arquitectura seleccionada para el desarrollo de “Rentaweb”. En el fallo que tuvo lugar el 06/04/2016 la propia AEAT admite un “error en la programación del programa de generación de PDFs de vista previa” (al utilizar la opción de generar una vista previa del borrador de declaración del IRPF el sistema facilitó el correspondiente a una persona distinta al solicitante). En el fallo detectado el 08/04/2016, al que no se refiere la AEAT en sus alegaciones, el acceso por unos contribuyentes a la información de otros fue consecuencia de una validación incorrecta del campo “NIF”. Las mejoras adoptadas para subsanar la incidencia confirman la falta de medidas de seguridad que han determinado la infracción, de la que es responsable la AEAT, según ha quedado expuesto, al menos por una falta de la diligencia debida en la implantación de medidas de seguridad adecuadas. El incumplimiento de lo establecido en el artículo 9 de la LOPD no se produce en exclusiva en supuestos de ausencia total de tales medidas, sino también en aquellos otros, como el analizado en este caso, en los que las adoptadas resultaran insuficientes o no efectivas y esta insuficiencia sea imputable a título de culpa. VI El artículo 44.3.
  17. h)de la LOPD, considera infracción grave: “Mantener los ficheros, locales, programas o equipos que contengan datos de carácter personal sin las debidas condiciones de seguridad que por vía reglamentaria se determinen”. Dado que ha existido vulneración del “principio de seguridad de los datos”, recogido en el artículo 9 de la LOPD, se considera que AEAT ha incurrido en la infracción grave descrita. VII El presente procedimiento se inicia, además de lo expuesto en los Fundamentos de Derecho anteriores, para determinar las responsabilidades que resultan del acceso efectuado por parte de terceros a los datos personales de contribuyentes contenidos en los sistemas de información de la entidad AEAT, concretamente a datos personales contenidos en borradores del Impuesto sobre la Renta de las Personas Físicas del ejercicio 2015, en los que constan, entre otros datos, los relativos a nombre, apellidos, domicilio, teléfonos, estado civil, grado de discapacidad y titularidad de su vivienda habitual, datos económicos, número de cuenta corriente, C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 23/26 datos de inmuebles; personas con las que convive el contribuyente, etc. Por tanto, procede analizar el cumplimiento por parte de la entidad AEAT del deber de secreto establecido en el artículo 10 de la LOPD, que dispone lo siguiente: El artículo 10 de la LOPD dispone: “El responsable del fichero y quienes intervengan en cualquier fase del tratamiento de los datos de carácter personal están obligados al secreto profesional respecto de los mismos y al deber de guardarlos, obligaciones que subsistirán aun después de finalizar sus relaciones con el titular del fichero o, en su caso, con el responsable del mismo”. El deber de confidencialidad obliga no sólo al responsable del fichero sino a todo aquel que intervenga en cualquier fase del tratamiento. Este deber de secreto comporta que el responsable de los datos almacenados no pueda revelar ni dar a conocer su contenido teniendo el “deber de guardarlos, obligaciones que subsistirán aún después de finalizar sus relaciones con el titular del fichero o, en su caso, con el responsable del mismo”. Es una exigencia elemental y anterior al propio reconocimiento del derecho fundamental a la libertad informática a que se refiere la Sentencia del Tribunal Constitucional 292/2000, de 30/11, y por lo que ahora interesa, comporta que los datos tratados no pueden ser conocidos por ninguna persona o entidad ajena fuera de los casos autorizados por la Ley, pues en eso consiste precisamente el secreto. Este deber de sigilo resulta esencial en las sociedades actuales cada vez más complejas, en las que los avances de la técnica sitúan a la persona en zonas de riesgo para la protección de derechos fundamentales, como la intimidad o el derecho a la protección de los datos que recoge el artículo 18.4 de la Constitución Española. En efecto, este precepto contiene un “instituto de garantía de los derechos de los ciudadanos que, además, es en sí mismo un derecho o libertad fundamental, el derecho a la libertad frente a las potenciales agresiones a la dignidad y a la libertad de la persona provenientes de un uso ilegítimo del tratamiento mecanizado de datos” (Sentencia del Tribunal Constitucional 292/2000, de 30/11). Este derecho fundamental a la protección de datos persigue garantizar a esa persona un poder de control sobre sus datos personales, sobre su uso y destino que impida que se produzcan situaciones atentatorias con la dignidad de la persona, es decir, el poder de resguardar su vida privada de una publicidad no querida. En el caso que nos ocupa, ha quedado acreditado que AEAT vulneró este deber de confidencialidad en relación con contribuyente que percibieron rentas sujetas al IRPF durante el año 2015. Esta información no puede ser facilitada a terceros, salvo consentimiento de los afectados o que exista una habilitación legal que permita su comunicación, que no concurren en el presente caso. Por tanto, queda acreditado que por parte de dicha entidad, se vulnera el deber de secreto garantizado en el artículo 10 de la LOPD, al haber posibilitado que terceras personas tuviesen acceso a datos personales de los contribuyentes afectados. VIII La vulneración del deber de secreto aparece tipificada como infracción grave en el artículo 44.3.
  18. d)de la LOPD. En este precepto se establece lo siguiente: “
  19. d)La vulneración del deber de guardar secreto acerca del tratamiento de los datos de carácter C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 24/26 personal al que se refiere el artículo 10 de la presente Ley”. En el presente caso, según ha quedado expuesto, consta acreditado que los datos personales de los contribuyentes y otros afectados (cónyuges, arrendadores, representantes, personas que conviven con el contribuyente, etc.) fueron divulgados a terceros por la entidad AEAT, no habiéndose acreditado que aquéllos hubiesen prestado el consentimiento necesario para ello. Por tanto, se concluye que la conducta imputada a dicha entidad se ajusta a la tipificación prevista en el 44.3.
  20. d)de la LOPD. IX Los hechos constatados, que resulta del acceso a los datos personales de contribuyentes registrados en los ficheros de AEAT por parte de otros contribuyentes, sin el consentimiento de sus titulares, constituye una base fáctica para fundamentar la imputación a dicha entidad de las infracciones de los artículos 9 y 10 de la LOPD. No obstante, nos encontramos ante un supuesto de concurso medial, en el que un mismo hecho deriva en dos infracciones, dándose la circunstancia que la comisión de una implica, necesariamente, la comisión de la otra. Esto es, si una información contenida en un fichero de contribuyentes sale del ámbito de la entidad responsable de su confidencialidad por un incidente de seguridad de los datos, se está produciendo un incumplimiento de las medidas de seguridad exigidas a dicho responsable que, a su vez, deriva en una vulneración del deber de secreto profesional. Por lo tanto, aplicando el artículo 4.4 del citado Real Decreto 1398/1993, procede subsumir ambas infracciones en una, procediendo imponer únicamente la sanción correspondiente a la infracción del artículo 9 de la LOPD que se trata de la infracción originaria que ha implicado la comisión de la otra. Por lo tanto, aplicando el artículo 29.5 de la Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público, procede subsumir ambas infracciones en una, declarando únicamente la infracción del artículo 9 de la LOPD, que se trata de la infracción originaria que ha implicado la comisión de la otra. X Tratándose de infracciones cometidas por Administraciones Públicas, procede aplicar el artículo 46 de la LOPD, que establece lo siguiente: “1. Cuando las infracciones a que se refiere el artículo 44 fuesen cometidas en ficheros de titularidad pública o en relación con tratamientos cuyos responsables lo serían de ficheros de dicha naturaleza, el órgano sancionador dictará una resolución estableciendo las medidas que procede adoptar para que cesen o se corrijan los efectos de la infracción. Esta resolución se notificará al responsable del fichero, al órgano del que dependa jerárquicamente y a los afectados si los hubiera. 2. El órgano sancionador podrá proponer también la iniciación de actuaciones disciplinarias, si procedieran. El procedimiento y las sanciones a aplicar serán las establecidas en la legislación sobre régimen disciplinario de las Administraciones Públicas. 3. Se deberán comunicar al órgano sancionador las resoluciones que recaigan en relación con las medidas y actuaciones a que se refieren los apartados anteriores. C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 25/26 4. El Director de la Agencia comunicará al Defensor del Pueblo las actuaciones que efectúe y las resoluciones que dicte al amparo de los apartados anteriores”. XI En el presente caso, la respuesta de la AEAT para mitigar los efectos de los incidentes de seguridad reseñados y corregir su causa fue inmediata. La primera medida en relación con la quiebra de 06/04/2016, consistente en la inhabilitación del botón que permitía obtener el borrador de la declaración de renta, se adopta por dicha entidad dos horas después de tener conocimiento de la misma mediante la comunicación realizada por un contribuyente. Y un día después, a las 15:30 horas, sube a producción una nueva versión del software que solventa el error. Asimismo, ha inhabilitado el acceso a los datos de la próxima campaña de renta de 2016 para todos los declarantes afectados y ha manifestado que implantará un control para que no pueda accederse a los datos relativos a los mismos salvo con certificado electrónico reconocido o con Cl@ve Pin y que “se reforzarán las medidas de inspección del código para evitar el error que ha provocado el incidente y se reforzarán las pruebas dirigidas a detectar este tipo de errores”. En su escrito de alegaciones, la AEAT manifiesta que ha complementado el plan de pruebas para la Campaña de Renta de 2016, para incluir pruebas específicas relacionadas con los incidentes reseñados, ha definido reglas orientadas a detectar la causa del error y se ha aprobado una Norma de Desarrollo Seguro de las aplicaciones de dicha entidad mediante Instrucción 1/2016, de 6 de septiembre de 2016, de la Dirección del Departamento de Informática Tributaria, con el objetivo de actualizar y reforzar los controles de seguridad que se aplican a los desarrollos de la misma. Por otra parte, informó sobre el incidente a los contribuyentes afectados y advirtió a los terceros que pudieron acceder a los datos de los mismos que evitasen su utilización y conservación. Con respecto a la quiebra notificada el día 8 de abril de 2016, la AEAT tomó acciones para resolver la incidencia el mismo día de su detección. Cuatro horas después de conocida la quiebra se aplicó un parche de emergencia para impedir la modificación del NIF con posterioridad a la introducción del “número de referencia” y el 13/04/2016 se pasó a producción de una nueva versión del programa Renta Web que incluye las modificaciones de seguridad relacionadas con la quiebra. Además, la AEAT ha expresado su intención de reforzar todos los controles relativos a cómo integrar en una declaración datos fiscales de otros contribuyentes e incluir pruebas específicas para evitar cualquier disfunción. Por tanto, se entiende que la entidad AEAT ha adoptado las medidas necesarias para impedir que en el futuro pueda producirse de nuevo una infracción de lo dispuesto en el artículo 9 de la LOPD similar a la examinada en el presente procedimiento. En consecuencia, no procede requerir la adopción de nuevas medidas para impedir en el futuro incidencias similares. Vistos los preceptos citados y demás de general aplicación, C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 26/26 la Directora de la Agencia Española de Protección de Datos RESUELVE: PRIMERO: DECLARAR que la entidad AGENCIA ESTATAL DE ADMINISTRACIÓN TRIBUTARIA ha infringido lo dispuesto en el artículo 9 de la LOPD, en relación con los artículos 91 y 93 de su Reglamento de desarrollo, aprobado por Real Decreto 1720/2007, de 21 de diciembre, tipificada como grave en el artículo 44.3.
  21. h)de la citada Ley Orgánica. SEGUNDO: DECLARAR que la entidad AGENCIA ESTATAL DE ADMINISTRACIÓN TRIBUTARIA ha adoptado medidas de orden interno adecuadas para impedir que en el futuro pueda producirse una nueva infracción del artículo 9 de la LOPD similar a la analizada en el presente procedimiento. TERCERO: NOTIFICAR la presente resolución a la entidad AGENCIA ESTATAL DE ADMINISTRACIÓN TRIBUTARIA. CUARTO: COMUNICAR la presente resolución al Defensor del Pueblo, de conformidad con lo establecido en el artículo 46.4 de la LOPD. De conformidad con lo establecido en el apartado 2 del artículo 37 de la LOPD, en la redacción dada por el artículo 82 de la Ley 62/2003, de 30 de diciembre, de medidas fiscales, administrativas y del orden social, la presente Resolución se hará pública, una vez haya sido notificada a los interesados. La publicación se realizará conforme a lo previsto en la Instrucción 1/2004, de 22 de diciembre, de la Agencia Española de Protección de Datos sobre publicación de sus Resoluciones y con arreglo a lo dispuesto en el artículo 116 del reglamento de desarrollo de la LOPD aprobado por el Real Decreto 1720/2007, de 21 diciembre. Contra esta resolución, que pone fin a la vía administrativa (artículo 48.2 de la LOPD), y de conformidad con lo establecido en los artículos 112 y 123 de la Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las Administraciones Públicas, se podrá interponer potestativamente recurso de reposición ante la Directora de la Agencia Española de Protección de Datos en el plazo de un mes a contar desde el día siguiente a la notificación de esta resolución, o, directamente recurso contencioso administrativo ante la Sala de lo Contenciosoadministrativo de la Audiencia Nacional con arreglo a lo dispuesto en el artículo 25 y en el apartado 5 de la disposición adicional cuarta de la Ley 29/1998, de 13 de julio, reguladora de la Jurisdicción Contencioso-administrativa (en lo sucesivo LJCA), en el plazo de dos meses a contar desde el día siguiente a la notificación de este acto, según lo previsto en el artículo 46.1 del referido texto legal. Sin embargo, el responsable del fichero de titularidad pública, de acuerdo con el artículo 44.1 de la LJCA, sólo podrá interponer directamente recurso contencioso administrativo ante la Sala de lo Contencioso-administrativo de la Audiencia Nacional con arreglo a lo dispuesto en el artículo 25 y en el apartado 5 de la disposición adicional cuarta de la LJCA, en el plazo de dos meses a contar desde el día siguiente a la notificación de este acto, según lo previsto en el artículo 46.1 del referido texto legal. Mar España Martí Directora de la Agencia Española de Protección de Datos C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es

🔗 A la fuente oficial

Explicación por IA a partir del texto oficial de la ley. Orientativa, no sustituye asesoramiento legal.