← España

AAPP-00025-2013

1/22 Procedimiento Nº AP/00025/2013 RESOLUCIÓN: R/03400/2017 En el procedimiento de Declaración de Infracción de Administraciones Públicas AP/00025/2013, instruido por la Agencia Española de Protección de Datos a la AYUNTAMIENTO DE GRANADA-CONSEJERIA DE PRESIDENCIA, y en virtud de los siguientes, ANTECEDENTES PRIMERO: Con fecha de 25 de junio de 2012 tiene entrada en esta Agencia un escrito D.D.D., ***CARGO.1 del Excmo. Ayuntamiento de Granada, en adelante EL ***CARGO.1, en el que notifica a la Agencia que el 14 de junio de 2012 se procedió a la apertura de una incidencia de seguridad debida a la existencia de informes técnicos que concluían la posibilidad de accesos indebidos o legítimos en el sistema informático municipal que podrían haber afectado a datos de carácter personal. El escrito adjunta copia de un informe emitido el 20 de junio de 2012 por el Director Técnico del Centro de Proceso de Datos del Ayuntamiento. El informe describe varios ataques informáticos ocurridos el 31 de mayo de 2012 que aprovecharon vulnerabilidades del sistema para acceder sin autorización para ello a datos económicos (nóminas y retenciones del IRPF) del personal del Ayuntamiento de Granada, en adelante EL AYUNTAMIENTO, y las medidas adoptadas para evitar dichos accesos no autorizados. Con fecha de 25 de junio de 2012 tiene entrada en esta Agencia un escrito E.E.E., en adelante EL DENUNCIANTE, en el que manifiesta lo siguiente: 1. “El Ayuntamiento de Granada publicó en Internet dos aplicaciones para visualizar recibos de nóminas y certificados de retenciones sin las medias de seguridad adecuadas, de modo que esos datos y otros han estado expuestos durante aproximadamente dos meses.” 2. Al ser descubierta la vulnerabilidad por funcionarios municipales el 31 de mayo de 2012, se dio cuenta verbalmente y por SMS al ***CARGO.1, a pesar de lo cual y dado que los datos seguían expuestos, se insistió el 4 de junio, momento en el que las aplicaciones dejaron de estar operativas. 3. Los funcionarios que informaron de los hechos remitieron un escrito explicando lo sucedido en el que se solicitaba que se abriera un incidente de seguridad y se informara tanto a los afectados como a la Agencia Española de Protección de Datos. 4. A lo largo del mes de junio aparecieron en distintos medios de C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 2/22 comunicación noticias que informaban sobre un ataque sufrido por la red municipal 5. Los hechos no han sido puestos en conocimiento de los afectados. 6. Entienden que los ficheros afectados deberían tener un nivel de seguridad alto por contener, entre otros, datos de afiliación sindical, y por ello no se encuentran correctamente inscritos en el Registro General de Protección de Datos. La denuncia aporta copia del escrito citado en el punto 3 que fue presentado el 5 de junio de 2012 por EL DENUNCIANTE, como ***CARGO.2, por F.F.F., como ***CARGO.3 y por A.A.A., como antiguo ***CARGO.4 en adelante EL EXDIRECTOR, cargo que ostentó hasta el 14 de junio de 2011. Con fecha de 17 de julio de 2012 tiene entrada en esta Agencia un escrito del Secretario General del SINDICATO INDEPENDIENTE DE LA POLICIA LOCAL DE GRANADA, en adelante EL SINDICATO, en el que manifiesta que han recibido una copia del escrito citado en el párrafo precedente y que en base a lo descrito en él sus afiliados pueden haberse visto afectados y entienden que pudiera haberse cometido un incumplimiento de las obligaciones por parte del responsable de seguridad del AYUNTAMIENTO DE GRANADA. SEGUNDO: A la vista de los hechos denunciados, en fase de actuaciones previas, por los Servicios de Inspección de esta Agencia se solicita información a la entidad AYUNTAMIENTO DE GRANADA, teniendo conocimiento de que: 1. En el Registro General de Protección de Datos consta un fichero denominado “NOMINAS” en el que LA CONSEJERIA DEL AYUNTAMIENTO ( ELAYUNTAMIETNO en lo sucesivo) consta como responsable. El fichero tiene declaradas un nivel medio de medidas de seguridad. 2. Durante la inspección llevada a cabo al AYUNTAMIENTO el 29 de octubre de 2012, los representantes de la entidad manifestaron que: 2.1. En el mes de abril de 2012 se puso en marcha un sistema de consulta de nóminas y certificados de retenciones de IRPF con el fin de eliminar la práctica de remitir una copia en papel de cada documento a los empleados del AYUNTAMIENTO. 2.2. El sistema fue desarrollado utilizando un entorno diseñado personalmente por EL EXDIRECTOR que incluye un programa denominado simcgi.exe, que permite a través de distintas plantillas acceder a los documentos almacenados en el gestor documental del AYUNTAMIENTO. C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 3/22 2.3. El sistema, que utiliza certificados digitales de la Fábrica Nacional de Moneda y Timbre para identificar a los usuarios, permite la consulta documentos en formato PDF que contienen las nóminas y de los certificados de retenciones del IRPF de los empleados del AYUNTAMIENTO. Los documentos en cuestión, que son generados por otros sistemas, son almacenados en el gestor documental del AYUNTAMIENTO y accedidos por este sistema. 2.4. El sistema fue diseñado para permitir el acceso al mismo desde la red del propio AYUNTAMIENTO pero también desde fuera de ésta ya que existen determinados colectivos de funcionarios que por sus funciones no disponen de un equipo informático en el AYUNTAMIENTO al que puedan acceder con facilidad. Los documentos contienen los siguientes datos de carácter personal:     Datos identificativos Datos del puesto de trabajo Datos económicos relativos a la nómina Código de cuenta de abono 2.5. El 31 de mayo de 2012, a las 11:59 horas se pone en producción una modificación del sistema destinada a agrupar las nóminas de forma que pudiesen ordenar por meses y facilitar su consulta. Aproximadamente a las 20:00 horas el ***CARGO.1 Delegado recibió un SMS remitido por el anterior Director del CPD del AYUNTAMIENTO en el que se le notificaba una vulnerabilidad existente en la aplicación y una URL que lo probaba. 2.6. Con el fin de evitar accesos utilizando esa función “sacanomina” el viernes día 1 de junio de 2012 se realizaron varias modificaciones, entre las que se encuentra el cambio del nombre de la función. 2.7. El lunes 4 de junio se detectó otra vulnerabilidad, en este caso una URL del sistema que permitía igualmente acceso a documentos de usuarios del sistema, con el agravante en este caso de que no era necesario estar previamente identificado. A pesar de ello los accesos se produjeron tras ser identificados los usuarios. 2.8. Ante la aparición de la nueva vulnerabilidad, se toma la decisión de parar el sistema. El sistema se encuentra fuera de servicio actualmente, siendo las nóminas y certificados remitidos a los funcionarios en formato papel. 2.9. Cuando EL EXDIRECTOR fue cesado, se le asigno aun puesto de trabajo en una entidad pública adscrita al AYUNTAMIENTO pero a pesar de ello en el momento de los hechos su puesto de trabajo estaba C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 4/22 ubicado en el CPD. EL EXDIRECTOR, por razón de su cargo y como parte de las personas que debían de ser notificadas, conocía el procedimiento de notificación de incidencias pero no lo siguió. En ningún momento fue notificado ni el Responsable de Seguridad ni el actual Director del CPD, a pesar de que EL EXDIRECTOR se encontraba físicamente en el mismo departamento. Las vulnerabilidades con eran conocidas por el AYUNTAMIENTO debido a que el EXDIRECTOR nunca documento el programa “simcig.exe” ni las plantillas “sacanomina” y “doc2”que se utilizaron para acceder a los datos. 2.10.El análisis de los registros de actividad del sistema llevó al AYUNTAMIENTO a la conclusión de que había sufrido un ataque informático, hecho que fue incluido el 14 de junio en el registro de incidencias de la entidad y el 18 de junio fue notificado a la fiscalía por si ésta entendiese que los hechos ocurridos son constitutivos de delito. A pesar de que se trasladaron los hechos a la Dirección de Personal para que tomaran las acciones disciplinarias que entendiesen oportunas con respecto al anterior Director del CPD, se optó por esperar a la decisión de la fiscalía para tomar una decisión definitiva. 2.11.Consultado el anterior Director del CPD sobre el motivo de los numerosos accesos irregulares éste manifiesta que únicamente está realizando su trabajo al evidenciar las carencias en materia de seguridad de los sistemas del AYUNTAMIENTO. 2.12.El AYUNTAMIENTO no informó a los funcionarios afectados. 2.13.El AYUNTAMIENTO notificó los hechos a la Fiscalía Provincial de Granada el 18 de junio de 2012. A la fecha de la inspección (29 de octubre de 2012) EL AYUNTAMIENTO no había recibido notificación alguna de la fiscalía pero con fecha 6 de febrero de 2013 diversos medios de comunicación informaban sobre la presentación por parte de la Fiscalía Provincial de Granada de una querella por revelación de secreto contra quienes, por sus siglas y sus cargos parecen ser EL EXDIRECTOR y EL DENUNCIANTE. 3. Tras los incidentes del 31 de mayo y 1 de junio, EL AYUNTAMIENTO trató de obtener del EXDIRECTOR información sobre distintos sistemas de información. Siendo los primeros intentos infructuosos al negarse EL EXDIRECTOR a ser notificado (según declaración de dos funcionarios) finalmente se le notifica la solicitud de información. En escrito remitido por EL EXDIRECTOR el 10 de septiembre de 2012 al Excmo. Sr. Alcalde de Granada le informa de que, no siendo parte del Centro de C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 5/22 Proceso de Datos (CPD) se le está solicitando una información, tarea que no está incluida en sus atribuciones, que debe de encontrarse en posesión el citado CPD por lo que desestima el requerimiento. Respecto de las vulnerabilidades que permitieron los accesos irregulares 4. De los documentos y los registros de actividad aportados por EL AYUNTAMIENTO de deduce que existían al menos dos URL (direcciones electrónicas) que permitieron el acceso irregular a los datos. El formato de las URL era: 4.1. ***URL.1 4.2. ***URL.2 Para poder obtener información mediante cualquiera de las dos URL el usuario debe de haberse identificado previamente mediante un certificado digital. Añadiendo a la primera de las URL un identificador de usuario, un número de cuatro dígitos que puede ser consultado en la Intranet del AYUNTAMIENTO, se accedía al menú que permite consultar las nóminas del usuario. Añadiendo a la segunda de las URL un identificador (un número de uso interno del gestor documental), un número de 7 dígitos sin vinculación evidente con el usuario al que está asociado el documento, se accedía a uno de los documentos almacenados en el gestor de contenidos del AYUNTAMIENTO. 5. Las URL no accedidas no eran mostradas por el sistema a los usuarios en sus navegadores, sino que eran accedidas de forma interna. 6. Si bien es cierto que para efectuar los accesos no autorizados descritos en esta investigación es necesario tener conocimientos sobre el funcionamiento del sistema, a juicio del Subinspector actuante, las vulnerabilidades descritas podrían haberse eliminado incluso en dicho caso modificando la configuración y el diseño del sistema tal y como se describe a continuación: 6.1. Configurando el sistema de forma que los accesos a las URL descritas únicamente pudiesen ser realizados desde las direcciones IP del servidor o servidores que dan servicio al AYUNTAMIENTO y no desde cualquier otra dirección IP. 6.2. Diseñando el sistema de forma que cada vez que el servidor recibiese una petición como las descritas en el punto 4: 6.2.1.Se verificase que la nómina o el certificado de retenciones solicitado pertenece al usuario que se autenticó (URL del punto 4.1). De esa forma, si un usuario con código X.X.X.1, remite al servidor una URL en la que el identificador de usuario es X.X.X.2, el sistema debería de responder con un mensaje de error. C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 6/22 Para poder hacerlo se podría comparar el “número de instancia” (NI, denominación del identificador de usuario utilizado en el AYUNTAMIENTO) con el usuario pasado en la URL y rechazar aquellas peticiones que no coincidan. Como quiera que el valor de NI almacenado en la cookie podría ser alterador por quien trata de acceder ilícitamente a las nóminas, podría almacenarse en el servidor, junto con el identificador de la sesión, el usuario para el que la sesión es válida. De esa forma se compararían dos valores almacenados en el servidor sobre los que un eventual atacante no podría interactuar. 6.2.2.Se verificase que el usuario autenticado tiene permisos para ver el documento solicitado (URL del punto 4.2). Respecto de los accesos irregulares 7. Todos los accesos irregulares se produjeron entre los días 31 de mayo y 4 de junio de 2012. 8. Se ha constatado que usando las vulnerabilidades descritas tanto el EXDIRECTOR como el DENUNCIANTE accedieron reiteradamente a nóminas y certificados de retenciones de otros trabajadores del AYUNTAMIENTO DE GRANADA. Los accesos irregulares de este tipo comienzan desde de la propia red del AYUNTAMIENTO, pero la mayor parte de ellos son realizados desde direcciones IP externas a éste. El AYUNTAMIENTO manifiesta que el certificado del EXDIRECTOR se utilizó para acceder al sistema el 31 de mayo de 2012 desde dos direcciones IP, la ***IP.1 y la ***IP.2. El proveedor de acceso a Internet que tiene asignada la dirección IP ***IP.2 confirmó que el EXDIRECTOR es el titular de la línea que tuvo asignada la dirección IP durante los hechos. Desde esas dos direcciones IP se accedió a 83 nóminas o certificados de retenciones de 7 usuarios distintos. El AYUNTAMIENTO manifiesta que el certificado del DENUNCIANTE se utilizó para acceder al sistema desde la dirección IP ***IP.3. El proveedor de acceso a Internet que tiene asignada la dirección IP ***IP.3 confirmó que EL DENUNCIANTE es el titular de la línea que tuvo asignada la dirección IP durante los hechos. Desde esa dirección IP se accedió a 18 nóminas y un certificado de retenciones de 3 usuarios distintos. El AYUNTAMIENTO manifiesta que el certificado del DENUNCIANTE se utilizó para acceder al sistema el 4 de junio de 2012 desde la dirección IP ***IP.4. C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 7/22 Desde esa dirección IP se accedió a 130 documentos y un certificado de retenciones de 3 usuarios distintos. 9. El día 31 de mayo, entre las 17:16 y las 17:22, desde la dirección IP ***IP.5 se accedió a 16 nóminas o certificados de retenciones de 5 usuarios distintos. El proveedor de acceso a Internet que tiene asignada la dirección IP ***IP.5 confirmó que Dña. B.B.B. es la titular de la línea que tuvo asignada la dirección IP durante los hechos. TERCERO: Con fecha de 12/06/2013, el Director de la Agencia Española de Protección de Datos, acordó iniciar procedimiento de Declaración de Infracción de Administraciones Públicas al AYUNTAMIENTO DE GRANADA-CONSEJERIA DE PRESIDENCIA con arreglo a lo dispuesto en el artículo 46 de LOPD, por la presunta infracción del artículo 9 de dicha norma, en relación con los artículos 91 y 93 del RDLOPD, tipificada como grave en el artículo 44.3

  1. h)de la citada Ley Orgánica. CUARTO: Con fecha de 20/06/2013 por el Instructor del Procedimiento se solicitó información al Juzgado de Instrucción nº 1 de ***LOCALIDAD.1 en referencia a las Diligencias Previas XXXX.1/2013, por un presunto delito de descubrimiento y revelación de secretos por funcionario público. QUINTO: Con fecha de 26/06/2013 el Director de la Agencia Española de Protección de datos acordó suspender el procedimiento sancionador de acuerdo con lo dispuesto en el art. 7 del Real Decreto 1398/1993, de 4 de agosto. SEXTO: Con fecha de 10/07/2013 el AYUNTAMIENTO DE GRANADA presenta escrito de alegaciones, en el que manifiesta en síntesis, lo siguiente: Primera. EL ayuntamiento actuó con la máxima diligencia inmediatamente despeas de serles comunicadas por el Teniente de Alcalde Delegado, mediante las actuaciones llevadas a cabo durante los días 1 y 4 de junio de 2012. Pese no haber cumplido los autores del ataque el procedimiento de comunicación de indecencias establecido en el Documento de Seguridad, del que eran plenamente conocedores, además de obviar al Director Tecnico del cPD y al Responsable de Seguridad CPD y tras modificar el indio empleado en el ataque, pasando desde el programa sacanomina al doc2. Pese no estar autorizados para el empleo de ninguno por no participar en el proyecto en el momento de los hechos, ni haber documentado las citadas vulnerabilidades de las que el Ayto no era conocedor ni podía prever, como queda dicho en el Informe del Director Técnico del CPD de 20/06/2012, mucho menos aun cuando el sistema de acceso a nóminas y certificados de IRPF quería certificados digitales de la FNMT que presuntamente dotaba de medidas de seguridad. Todo lo cual no es impedimento para la producción de un hecho de difícil previsión como es que fue el propio personal municipal el que violento el sistema, en C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 8/22 concreto el responsable de la seguridad de dicho sistema informático. Realizando el Ayto las actuaciones pertinentes tras lo ocurrido, por lo que fue impecable la actuación municipal. Segunda. El ayto no solo no era conocedor de las vulnerabilidades existentes, sino que no fueron atendidos sus requerimientos a unos de los denunciantes para la detección de las mismas. El exdirector del CPD no documento tampoco las mismas. El Director Tecnico del cPD requirió a A.A.A. por escrito de fecha 18/06/2012 para la remisión de información sobre el funcionamiento del sistema, y fue rehusada en fecha de 21/06/2012 y finalmente tras un nuevo requerimiento formulado por el responsable de Seguridad del CPD fue objeto de una respuesta evasiva en fecha de 11/07/2012. Tercera. No se comunicó a los afectados por el ataque, para no ocasionar alarma social. Se denuncia ante la Fiscalia y se puso a disposición del Juzgado de Instrucción la información de la que se disponía cuando fue requerido para ello. Cuarta. Errores subsanables en el Acuerdo de Incoación el AP/00025/2013(…) deben considerarse correctos: La fecha de cese de A.A.A. como Director del CPD, es 14/06/2011. La fecha correcta de cambio de nombre de la función “saca nomina” es 31/05/2011 a las 20,50h. El día 5 de junio de corrigió la segunda vulnerabilidad ( doc/doc) mediante cifrado y encriptación, pero se vieron nuevas vulnerabilidades y otras amenazas (…)y se optó por retirarla hasta que todo tuviera plenas garantías. La validación de la nómina con el usuario identificado no era posible con la configuración entonces existente, ya que en la base de datos documental no se guardaba ese dato y, por tanto, no se podía cotejar el mismo. Los accesos desde la IP ***IP.4 se realizaron con el certificado del exdirector. Para cuya clarificación se acompaña tabla resumen de los accesos efectuados desde las IPs, con identificación de los certificados de acceso SÉPTIMO: En el procedimiento sancionador PS/00318/2013 incoado contra E.E.E. y A.A.A., por hechos relacionados con los aquí valorados, éste último presento escrito de alegaciones mediante escrito de fecha 11/03/2014 en el que manifestaba, en síntesis, lo siguiente: (…)Las personas presentes en la inspección realizada manifestaron hechos que no se ajustan a la verdad, debiendo realizase las siguientes aclaraciones respecto de lo contenido en el Acta de Inspeccion, y después en el Acuerdo de Inicio del procedimiento: Registro de aplicaciones: los empleados municipales presentes en la C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 9/22 inspección ocultan que las aplicaciones que se publicaron sin las debidas medidas de seguridad operan sobre ficheros físicos diferentes y que el sistema de Información Municipal ( SIM) donde se almacenaban los datos, tenía aplicaciones defectuosas que no cumplían el requisito de registro de accesos. Información contenida en recibos de nómina: se ocultó que contienen datos sobre afiliación sindical y posiblemente otras circunstancias intimas y especialmente protegidas de los empleados municipales. Proyecto de visor de nómina. La aplicación estaba diseñada para su explotación en el entorno SIM, nunca a través del interfaz de usuario habitual en cualquier navegador web. Se publicó en internet y se eliminó una cautela relativa a impedir su uso fuera de SIM, y además no se protegía el historial de navegación. Cuando tuve conocimiento de tal circunstancia comunique la necesidad de proteger adecuadamente los activos de información implicados. No colabore en la decisión final de la publicación en internet, circunstancia ocultada tanto por el Director Técnico como el Subdirector de Administración electrónica. No es cierto que hubiera desconocimiento del modo de operar del programa SIM: la causa de la vulnerabilidad es la existencia de URLS invocadas desde el cliente que debían ser protegidas. Vulnerabilidad “sacanomina”. La url sacanomina es invocable desde el cliente pero no accede a datos de carácter personal y, por tanto, no muestra información sensible. Existen 3 urls vulnerables doc, doc2 y la que produce documentos pdf, las dos primeras devuelven un documento xml visualizado a través de reglas xslt. Responsabilidad. La ignorancia de las características de la aplicación es imputable a quienes se encargaron de su puesta en marcha tanto en internet como en intranet. En la fecha de los hechos estoy ubicado en el CPD y dependo directamente de la Autoridad Competente y no del Director del CPD, cuando tengo conocimiento del problema informo al Delegado del Alcalde para estos asuntos manifestando que la peor consecuencia es que las urls que acceden a datos personales quedan registradas en el historial de navegación. Como no dependía del Director del CPD, no atiendo la petición del código del programa SIM, pues ya dispone de él y que debe hacer efectiva la funcionaria encargad de su custodia, por lo que son otras motivaciones las que tiene el Director al realizarme dicho requerimiento. Incidente de Seguridad. Por el personal municipal en el Incidente de seguridad 1/2012 se considera que éste es la advertencia de las vulnerabilidades ( las comprobaciones) y no su causa ( la no disposición de medidas de seguridad adecuadas). No se produjeron “ataques” sino que accedí a la información como funcionario público, informático, encargado del tratamiento, y con autorización para acceder y tratar C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 10/22 masivamente datos de toda índole en el ejercicio de potestades públicas. El acceso para acreditar la naturaleza de los problemas de seguridad no puede constituirse un acceso irregular. Se observó el deber de sigilo y se utilizaron métodos para disociar la información de carácter personal: visualización de datos identificativos a los efectos de determinar la amplitud del problema. Avise del problema y no es hasta el 4 de junio cuando se inmovilizo la aplicación. Procedimiento del incidente de seguridad. Se arguye que debería haber advertido al Responsable de Seguridad. Sin que conozca disposición que lo determine, habiéndolo comunicado al Alcalde que ostenta la máxima representación. Siendo el Responable de Seguridad, partícipe en el problema al omitir las medidas de seguridad a toda la aplicación SIM, así como las faltas de verificación antes de la puesta en marcha en internet. Intervención del denunciado. En el Acta de inspección figura que se realizaron consultas a mi persona cuando no es cierto. No se intervino por mi persona en la inspección. Hechos que la AEPD considera acreditados y que son incorrectos, siendo adecuados a la verdad los siguientes:  Sacanomina no muestra datos de carácter personal.  Las URLS vulnerables eran accesibles a través de HTTP y no se necesitaba certificado digital. Del lado del servidor no se dispuso de código que verificase la existencia de sesión activa y por ende la identificación de usuario.  Las URLS vulnerables no solo eran accedidas internamente, sino que eran visibles tanto en el historial de navegación como a través de herramientas de desarrollo.  No era necesario tener conocimiento del sistema para explotar la vulnerabilidad, pues a través del historial de navegación se podía acceder indiscriminadamente a datos personales y a los documentos de la base documental del SIM.  El registro de accesos hubiese sido suficiente para proteger información confidencial, por eso esta en todas las aplicaciones SIM, pero las aplicaciones vulnerables explotan datos SIM pero no son aplicaciones SIM. Accesos entre el 31 de mayo y 4 de junio. Efectivamente se realizaron esos accesos con identificación, ejerciendo funciones del cargo como funcionario municipal activo, informático y encargado por el propio Ayuntamiento del tratamiento de datos personales. En ese momento ni disponía de medios ni autoridad suficiente para C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 11/22 encargarme personalmente de ello, ni recibí dicho encargo. No es hasta el día 6 de junio cuando el Subdirector de Administración Electrónica solicito la colaboración y se solucionó el problema. Interpretación del art. 46 de la LOPD. La AEPD obvia la condición de funcionario que está sometido al régimen disciplinario. La responsabilidad de lo ocurrido es de los empleados públicos responsables en la toma de decisiones o en la elaboración de programas defectuosos, Director Técnico del CPD, Subdirector de Administración Electrónica, Responsable de Seguridad, Responsable de Asesoría Jurídica, Coordinador General del Área y el ***CARGO.1 Delegado.(…) OCTAVO: Con fecha de 13/06/2017 por el Instructor del Procedimiento se requirió información a la Audiencia Provincial de Granada Sección Segunda aportando ésta la Sentencia núm. 252/2017 de 17/05/2017. NOVENO: Con fecha de 31/07/2017 por la Directora de la Agencia Española de Protección de Datos, se acordó el levantamiento de la suspensión del procedimiento. DÉCIMO: Mediante escrito de entrada 12/09/2017, el AYUNTAMIENTO DE GRANADA presento escrito en el que se informa de cambios producidos en el citado ayuntamiento derivados del Pleno Extraordinario celebrado el 5/05/2016 certificados por el Secretario en funciones de fecha 25/08/2017. Donde tras señalar los nuevos puestos y personas que ostentan los cargos relativos a éstos, se solicita que se tengan en cuenta los hechos probados de la Sentencia de la Sección Segunda de la Audiencia Provincial de Granada Rollo Sala 66/2016 de 26/06/2017. UNDÉCIMO: Por el Instructor del Procedimiento se acordó incorporar al expediente y dar por reproducida, a efectos probatorios la siguiente documentación: I.La documentación recabada en las actuaciones previas de inspección que forman parte del expediente E/04838/2012. II.Las alegaciones al acuerdo de inicio del procedimiento PS/00318/2013 presentadas por D. G.G.G.. III.La Sentencia de la Audiencia Provincial de Granada de la Sección Segunda núm. 252/ 2017 de 17/05/2017. IV.Los escritos del Ayuntamiento de Granada de fechas 10/07/2013 y 05/09/2017 aportados al presente procedimiento AP/000025/2013. V.Contenido de la Inscripción del Fichero ***FICHERO.1 del RGPD. VI.Impresión de pantalla de sitios web del Ayto. de Granada. DUODÉCIMO: En fecha de 13/11/2017 por el Instructor del Procedimiento se C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 12/22 emitió Propuesta de Resolución, en el sentido de que por la Directora de la Agencia Española de Protección de Datos se declare que EL AYUNTAMIENTO DE GRANADA. CONSEJERIA DE PRESIDENCIA ha infringido lo dispuesto en el artículo 9 de la LOPD, tipificada como grave en el artículo 44.3.
  2. h)de dicha norma. La citada propuesta de resolución, transcurridos 10 días desde su puesta a disposición mediante notificación electrónico, se entendió rehusada y a los efectos procedimentales, cumplido el trámite. DECIMOTERCERO: En fecha de 17/11/2017 por el AYUNTAMIENTO DE GRANADA se presentó escrito en relación con la diligencia de prueba remitida por el instructor y recibida en fecha de 7/11/2017, en la que manifiestan, en síntesis que existen dudas acerca de la legalidad de las actuaciones previas de inspección, en base a que ni A.A.A., ni E.E.E. estuvieron presentes en dicho trámite ni pudieron rebatir las conclusiones allí extraídas por la Agencia, asimismo tampoco se les solicito información al contrario de lo que consta en el acuerdo de apertura del procedimiento, en concreto se señala (…)se observa que el hecho de que por la Agencia Española de Protección de Datos se considere como hechos probados “la documentación recabada en las actuaciones previas de inspección que forman parte del expediente E/04838/2012. Asimismo, se dan por reproducidas a efectos probatorios, las alegaciones al acuerdo de inicio del procedimiento AP/00025/2013 presentadas por el AYUNTAMIENTO DE GRANADA”, podría no resultar ajustado a derecho si se hubiesen practicado las actuaciones previas en ausencia de parte demandante, todo ello, sin perjuicio de que se practiquen las pruebas que se consideren necesarias para la resolución del expediente (…) DECIMOCUARTO: En fecha de 13/12/2017 se incorporó al expediente las alegaciones formuladas por E.E.E. en fecha de 6/12/2017 en el procedimiento sancionador PS/318(2013, en las que señalaba en síntesis lo siguiente: El Ayuntamiento no incluyo en la inscripción en el Registro General de Ficheros de la AEPD, los datos especialmente protegidos como es la afiliación sindical. El cambio de nombre de la función que se cita en el punto 6.2 de los antecedentes, significa de la permanencia de una puerta trasera, con conocimiento de la organización municipal, que permite explorar la base de datos documental sin restricciones de ningún tipo. Respecto de lo contenido en el punto 2.7 de los antecedentes, debe indicarse que la vulnerabilidad SACANOMINA, tampoco se obliga a la utilización de un certificado valido de la FNMT y al igual que la otra vulnerabilidad DOC y DC2, podía explotarse sin necesidad de protocolo seguir ni certificado electrónico. Respecto de lo contenido en el punto 2.9 de los antecedentes, respecto de la no notificación a los responsables, debe indicarse que tal incumplimiento seria también exigible a todos los demás citados ya que ninguno lo comunico al Responsable de Seguridad. C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 13/22 Respecto de lo contenido en el punto 4 de los antecedentes, debe indicarse tal como consta en el folio 42 del expediente, ni se utilizaba un protocolo seguro ni era necesaria la identificación mediante certificado digital. Hecho especialmente grave puesto que permite la difusión a través de toda la red de la información intercambiada entre cliente y servidor. DECIMOQUINTO: de las actuaciones practicadas han resultado acreditados los siguientes HECHOS PROBADOS UNO.- En febrero del año 2012, el nuevo Director del CPD, encomendó a sus subordinados (Sr. I.I.I. y Sra. H.H.H.) el desarrollo del programa denominado “Visor de nóminas” para adaptar su uso a funcionarios municipales a través de internet. Dicho programa fue inicialmente desarrollado por A.A.A. para su utilización en la red intranet de la citada corporación. DOS.- El Sr. I.I.I. solicitó y obtuvo la autorización de A.A.A., para la utilización del programa desarrollado por éste siendo advertido por éste de que se necesitaban implantar las correspondientes medidas de seguridad para su explotación en internet. TRES.- El programa se puso en explotación en internet en marzo de 2012 y en abril del mismo año se adaptó para la consulta de certificados de retención de IRPF de los empleados públicos. CUATRO.- en la mañana del día 31/05/2012 el Sr. I.I.I. consulto a A.A.A. algunas cuestiones técnicas del programa, realizando éste diversas modificaciones, pese a no encontrarse adscrito al proyecto de adaptación, y advirtió la posibilidad de que la aplicación tuviera déficit de seguridad. CINCO.- Sobre el mediodía de esa fecha, A.A.A., desde su ordenador del CPD, comprobó que tras acceder a la aplicación identificándose con certificado digital, podía acceder a la URL que utilizaba la expresión “sacanomina” en la que, cambiando el parámetro del número de empleado, era posible ver recibos de nómina de cualquier funcionario municipal y comprobó que era posible la navegación a través de protocolos no seguros. Dicha circunstancia la comunico a E.E.E. ubicado a pocos metros de su puesto de trabajo. SEIS.- A.A.A., no comunico en ese momento los hechos, ni al Director Técnico del CPD, ni al Subdirector de Administración Electrónica, ni al Responsable de Seguridad, pese a que se encontraban en la sede del CPD. Conocía el procedimiento de notificación de incidencias pero no lo siguió. Asimismo tampoco documento las vulnerabilidades. SIETE.- Por la tarde de esa fecha, A.A.A., tras hablar por teléfono con el ***CARGO.1 responsable del Área, al Sr. D.D.D., le envió un SMS informando del C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 14/22 problema, y éste reenvió dicho SMS al Coordinador de Servicios, Director Técnico del CPD y éste a su vez al Subdirector de Administración electrónica, que cambio el parámetro sacanomina y user, estimo que el problema estaba resuelto. El día siguiente 1 de junio, el Subdirector de Administración electrónica realizo otras modificaciones en la aplicación. OCHO.- E.E.E. en la tarde noche del día 31/05/2012, desde su domicilio personal, realizo cinco accesos a la aplicación utilizando el parámetro sacanomina verificando que era posible acceder a nóminas de otro empleados. NUEVE.- Esa misma tarde/noche desde su domicilio personal, A.A.A., comprobó que usando los parámetros “doc/dos2” se podía acceder a toda la documentación del SIM, y que a través de consultar el historial de navegación era posible la recuperación de documentos, comunicándolo a E.E.E. quien realizo varias pruebas, cambiando el número de documento en la URL. DIEZ.- Durante el fin de semana del 2 y 3 de junio A.A.A., continúo realizando desde su domicilio personal, numerosos accesos a la aplicación y consultando documentos. ONCE.- En fechas de 31 de mayo de 2012 y durante el primer fin de semana del mes de junio de 2012, mediante el método denominado como “reescritura de URL”, a través de modificar los caracteres en los parámetros escritos en la URL se accedió a datos de carácter personal por terceros no autorizados, en los sistemas de información cuya responsabilidad es del Ayuntamiento de Granada, a pesar que desde el mes de febrero por parte de A.A.A., se informó de la necesidad de dotar al programa “Visor de nóminas” de medidas de seguridad adecuadas, y a pesar que mediante el SMS citado en el hecho probado siete, las personas responsables del ayuntamiento tuvieron conocimiento de la brecha de seguridad. DOCE: En fecha de 4 de junio de 2012, el Director Técnico del CPD decidió suspender el uso de la aplicación ante los citados problemas de seguridad. 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.
  3. g)en relación con el artículo 36 de la LOPD. II Establece la Disposición transitoria tercera bajo la rúbrica “Régimen transitorio de los procedimientos”, de la Ley 39/2015 de 1 de Octubre, que (…) A los procedimientos ya iniciados antes de la entrada en vigor de la Ley no les será de aplicación la misma, rigiéndose por la normativa anterior.(…) C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 15/22 Por lo que en el presente procedimiento son de aplicación los preceptos de la derogada Ley 30/1992 de 26 de noviembre y del R.D 1389/1993 de 4 de agosto. Establece el art. 7.3 del RD Real Decreto 1398/1993, de 4 de agosto, por el que se aprueba el Reglamento del procedimiento para el ejercicio de la Potestad Sancionadora, vigente a la fecha de los hechos, establece lo siguiente: 3. En todo caso, los hechos declarados probados por resolución judicial penal firme vinculan a los órganos administrativos respecto de los procedimientos sancionadores que substancien. En el presente caso se dictó de Sentencia de la Audiencia Provincial de Granada de la Sección Segunda núm. 252/ 2017 de fecha 17/05/2017, en la que resulta probado que los denunciantes procedieron a los accesos y en las circunstancias que recogen los Hechos Probados de la presente resolución. III En el presente caso, se atribuye al AYUNTAMIENTO DE GRANADA, la comisión de la infracción del art. 9 de la LOPD que establece que (…) “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 la 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 trascrito 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. Para poder delimitar cuáles sean los accesos que la Ley 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 al concepto de “fichero” el artículo 3.
  4. b)de la LOPD lo define como “todo conjunto organizado de datos de carácter personal”, con independencia de la modalidad de acceso al mismo. C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 16/22 Por su parte el artículo 3.
  5. c)de la citada Ley Orgánica considera tratamiento de datos cualquier operación o procedimiento técnico que permita, en lo que se refiere al objeto del presente procedimiento, la “comunicación” o “consulta” de los datos personales tanto si las operaciones o procedimientos de acceso a los datos son automatizados o no. Por su parte, el artículo 3.
  6. a)de dicha Ley añade que se entenderá por datos de carácter personal “cualquier información concerniente a personas físicas identificadas o identificables”. Para completar el sistema de protección en lo que a la seguridad afecta, el artículo 44.3.
  7. 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:
  8. a)Las operaciones y procedimientos técnicos automatizados o no, que permitan el acceso, –la comunicación o consulta- de datos personales, es un tratamiento sometido a las exigencias de la LOPD.
  9. 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.
  10. c)La LOPD impone al responsable del fichero la adopción de medidas de seguridad, cuyo detalle se remite a normas reglamentarias, que eviten accesos no autorizados.
  11. 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. IV Los artículos 91 y 93 del RDLOPD, 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 C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 17/22 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 acceso 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.
  12. 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 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, LA CITADA CORPORACIÓN LOCAL está obligada a adoptar, de manera efectiva, las medidas técnicas y organizativas necesarias y, entre ellas, las dirigidas a impedir el acceso no autorizado por parte de terceros a los datos personales C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 18/22 que constan en sus ficheros. En este caso, sin embargo, ha quedado acreditado que la citada entidad incumplió esta obligación, al establecer un sistema de gestión de la información relativa a la consulta de nóminas y declaraciones de IRPF que no impidió de manera fidedigna que por parte de un usuario determinado se pudiera acceder a datos personales de otros empleados, aun cuando no fueran titulares de la información a la que se refiere , nóminas y certificados de IRPF, o que tuvieran permisos al efecto, pues sin perjuicio de las funciones que las personas que realizaron los accesos tenían en la citada corporación y su adecuación , en ningún momento se establece ningún paso a realizar que pasara por utilizar un determinado permiso u otro, sino que cambiando los parámetros de la URL se tenía acceso a determinados recursos, lo que obviamente pone de manifiesto que el sistema era vulnerable pues ni existía control de acceso, ni autenticación. Las alegaciones formuladas por el AYUNTAMIENTO DE GRANADA tienen como finalidad excluir el elemento subjetivo en la comisión de la infracción , y poner de manifiesto la diligencia que prestó la citada corporación cuando tuvo conocimiento de los hechos que constituyen la brecha de seguridad, consistente en el acceso por terceros a datos personales mediante la técnica conocida como reescritura de URL. Sin embargo, debe tenerse en cuenta, en primer lugar, 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 X.X.X.2). C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 19/22 En segundo lugar, para analizar la diligencia prestada, y sin perjuicio de que la solución a brechas de seguridad derivadas de la escritura de URL se realizaría a través de la introducción de cambios de fácil implementación, no puede obviarse que según el relato de HECHOS PROBADOS que contiene la Sentencia de la Audiencia Provincial, desde el mes de febrero de 2012, estaba alertado el personal del Ayuntamiento de Granada, de la necesidad de implantación de medias de seguridad, y que tal como advirtió la persona que desarrollo la aplicación para su explotación en intranet, la puesta en funcionamiento de la misma para su explotación en internet podía suponer una riesgo para la seguridad de los datos personales. Mediante los accesos realizados por E.E.E. y A.A.A., se verifico, además de que era posible la navegación a raves de protocolos no seguros, que modificando los parámetros “sacanomina” y “doc/dos2” se podía acceder a documentación del SIM (Sistema de Información Municipal) y que a través de la consulta del historial de navegación era posible la recuperación de documentos. Finalmente indicar que resultan especialmente clarificadoras las alegaciones de E.E.E. formuladas en el procedimiento Sancionador PS/00318/2013, recogidas en el Antecedente Decimocuarto, dónde se pone de relieve las deficientes medidas de seguridad implementadas por la citada corporación, a cuyo contenido se hace la oportuna remisión. V La citada corporación local presento escrito en fecha de 17/11/2017 en el que pone en cuestión la legalidad del valor probatorio de unas actuaciones de inspección en las que no están presentes E.E.E. y A.A.A., y en las que se afirma lo contrario en el acuerdo de iniciación, dónde se señala que se les solicito información. Frente a ello, debe indicarse en primer lugar que en el presente caso se analiza la adecuación al principio de seguridad de los datos del sistema de la citada corporación, y no se está sancionando a las personas indicadas. No obstante lo anterior, conviene recordar la naturaleza de las actuaciones previas de inspección y la aplicación y vigencia de los distintos principios generales de la potestad sancionadora, a saber: Con reiterada jurisprudencia, cabe señalar que estas Actuaciones Previas de Inspección no forman parte del expediente sancionador, ya que no son propiamente expediente administrativo, sino antecedente del mismo (por todas, Sentencias del TS de 22 de febrero de 1985 [RJ 1985,502] o de 26 de mayo de 1987 [RJ, 1987,5850]. Con la Sentencia del TS de 13 de septiembre de 2002 (RJ 2002,8557) podemos decir que las actuaciones previas son el medio ordinario, habitual y ortodoxo desde el punto de vista legal de que dispone la administración para esclarecer hechos denunciados, constituyendo una garantía contra la precipitación en los casos en los que se considere preciso conocer datos y extremos de los hechos susceptibles de sanción. Sentado lo anterior, debe indicarse que en las actuaciones previas no rigen C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 20/22 las reglas esenciales de los procedimientos, ni siquiera el principio de contradicción – que es el que se infiere entendido vulnerado por LA CITADA CORPORACIÓN LOCAL que insisten en que las personas mencionadas no aportaron información -, pues los derechos de defensa se satisfacen después, en el seno del procedimiento. Son pronunciamientos de esta doctrina, la STS de 16 de enero de 2004 (…) en modo alguno la realización de información reservada a afecta a derechos fundamentales del imputado toda vez que sus contenidos pueden ser sujetos a contradicción con posterioridad en el trámite de audiencia y en la sucesiva actividad probatoria.(…)no supone una fase inculpatoria en ningún sentido y sobre sus contenidos y conclusiones habrán de recaer las actuaciones probatorias que el instructor practique con otorgamiento de plenas garantáis de contradicción(…); y en el mismo sentido la STSJ de la Comunidad Valenciana de 23/05/2006, y la STSJ de Aragón de 28/7/2003. Incluso no rige, en estas actuaciones previas, el derecho a conocer la acusación, como explica la STS de 27/02/2003 a señalar que sólo surge (…)cuando el expediente lo permita por haber llegado a un momento en que las imputaciones puedan ya formularse con fundamento sólido. En el inicio de las actuaciones del expediente no siempre resultara posible determinar contra quien se dirigirán ulteriormente las acusaciones, de modo que los sucesivos tramites pueden continuarse sin la notificación de los cargos que tendrán, más adelante su momento procesal oportuno (…). Finalmente y a mayor abundamiento, ni si quiera es necesario que quién luego resulto sancionado hubiera estado presente en la práctica de las actuaciones previas, incluidas las de inspección, así lo determinan las STJ de Madrid de 2/10/1998; la STSJ de La Rioja de 2/09/1998 entre otras. VI El artículo 44.3.
  13. 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 EL AYUNTAMIENTO DE GRANADA ha incurrido en la infracción grave descrita. En esta materia de seguridad se impone una obligación de 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 C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 21/22 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”. VII Según consta a fecha de 10/10/2017, en el Registro General de Ficheros Públicos de la AEPD, el responsable del fichero ***FICHERO.1 según última versión del mismo, de fecha 06/08/2010, denominado NOMINAS es la ***CARGO.1de Presidencia, entendiéndose por tanto la citada consejería como responsable del fichero a los efectos previstos en el artículo 43 y 46 de la LOPD. VIII Establece el artículo 46.1 de la LOPD que 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. En el presente caso no procede el requerimiento de adopción de medidas correctoras pues el incidente de seguridad consta solucionado, a través de la implantación de medidas que impiden que un usuario pueda acceder a recursos del sistema informático sin permiso y habilitación, y conocer datos de carácter personal sin la habilitación necesaria. Vistos los preceptos citados y demás de general aplicación, la Directora de la Agencia Española de Protección de Datos RESUELVE: PRIMERO: DECLARAR que LA CONSEJERIA DE PRESIDENCIA DEL AYUNTAMIENTO DE GRANADA ha infringido lo dispuesto en el artículo 9 de la LOPD, tipificada como grave en el artículo 44.3
  14. k)de la citada Ley Orgánica. SEGUNDO: NOTIFICAR la presente resolución a la CONSEJERIA DE PRESIDENCIA DEL AYUNTAMIENTO DE GRANADA y al superior jerárquico ALCALDE-PRESIDENTE DEL AYUNTAMIENTO DE GRANADA. TERCERO: 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á C/ Jorge Juan, 6 28001 – Madrid www.agpd.es sedeagpd.gob.es 22/22 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. El responsable del fichero de titularidad pública, de acuerdo con el artículo 44.1 de la LJCA, 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.