Libro Lopd V2 Alta

La protección de datos personales: Soluciones en entornos Microsoft

La protección de datos personales: Soluciones en entornos Microsoft Publicado por: Microsoft Ibérica S.R.L. Centro Empresarial La Finca Edificio 1 Paseo del Club Deportivo, 1 28223 Pozuelo de Alarcón – Madrid (España) Copyright © 2009 Microsoft Ibérica Unipersonal S.R.L. Aviso Legal: Los autores, colaboradores, organismos públicos y empresas mencionadas en este libro, no se hacen responsables de que lo contenido en este libro garantice el total cumplimiento de los requisitos establecidos en la legislación española sobre protección de datos personales. Este libro única y exclusivamente posee un propósito informativo en relación con la legislación española sobre protección de datos de carácter personal. La información sobre los productos de Microsoft representa la visión que los autores, colaboradores y empresas mencionadas en este libro tienen sobre los mismos, por lo que no otorgan ninguna garantía, ni expresa ni implícita, en referencia a la información incluida en este libro sobre los mencionados productos. Es responsabilidad del usuario el cumplimiento de toda la legislación sobre derechos de autor y protección de datos de carácter personal que sean aplicables. Sin limitar los derechos que se deriven sobre propiedad intelectual, ninguna parte de este documento puede ser reproducida, almacenada, ni introducida en ningún sistema de recuperación, ni transmitida de ninguna forma, ni por ningún medio, ya sea electrónico, mecánico por fotocopia, grabación o de otro tipo, con ningún propósito, sin la autorización por escrito de los titulares de los derechos de propiedad intelectual de este libro. Quedan reservados todos los derechos. Los nombres de las compañías y productos reales aquí mencionados pueden ser marcas comerciales de sus respectivos propietarios. EJEMPLAR GRATUITO. PROHIBIDA SU VENTA. Depósito Legal: M-14799-2009 Coordinador Editorial: Héctor Sánchez Montenegro Diseño y maquetación: José Manual Díaz. Newcomlab S.L.L. Revisión técnica: Newcomlab S.L.L. Imprime: Impreso en España – Printed in Spain Realizado en papel reciclado. II

Prólogo de María Garaña El derecho a la intimidad resulta tan irrenunciable como cualquier otro de los derechos que nos asisten en nuestra Constitución. Su valor ya se encuentra reconocido en el artículo 12 de la Declaración Universal de los Derechos Humanos (1944), así como en el artículo 18 de La Constitución Española, donde se recoge literalmen- te: “Se garantiza el derecho al honor, a la intimidad personal y familiar y a la propia imagen”… “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”. Sin perdernos en demasiados tecnicismos, el concepto de intimidad y privacidad, quizá sea de los más cercanos a nuestra experiencia y sentimiento. Especialmente cuando es vulnerado nuestro derecho a poder excluir a las demás personas del conocimiento de nuestra vida personal, de nuestros sentimientos, de nuestras emociones, de nuestros datos biográficos y personales etc. Así como el derecho a controlar el quién, cuándo y cómo puede tener acceso a estos aspectos de la vida personal de cada uno. El tratamiento automatizado y masivo de datos constituye un pilar de la Sociedad del Conocimiento, sobre la cual se ha cimentado el progreso de nuestras empresas, de nuestras administraciones, e incluso de nuestro propio desarrollo como individuos del siglo XXI. Pero es evidente que la facilidad inherente al tratamiento automatizado de datos requiere una especial atención que asegure la protec- ción efectiva de nuestro derecho a la intimidad. En este sentido, la legislación específica sobre Protección de Datos es la que establece los límites y condiciones para su tratamiento. El presente libro, aunque de carácter divulgativo, está dirigido a los responsables técnicos de empresas y administraciones, así como a los responsables de aplicar las salvaguardas y procesos contemplados en el Reglamento de la LOPD para el manejo de los datos de carácter personal de sus clientes, empleados, socios, etc... El libro busca su hueco en esa zona intermedia en la que necesitamos aplicar con garantías una serie de medidas técnicas, dictadas por un reglamento jurídico, pero trasladables al mundo real en la forma de conocimiento tecnológico. Es por ello por lo que la guía toma como hilo conductor todos y cada uno de los artículos contemplados en el reglamento de la LOPD, con transcendencia en el ámbito de las Tecnologías de la Información, para a continuación comentarlos de forma sencilla y detallar cual sería la configuración o recomendación técnica más adecuada para su cumplimiento desde la perspectiva de la tecnología Microsoft. Aun reconociendo la naturaleza eminentemente técnica del manual, no deja de ser una auténtica delicia el navegar por sus páginas de contenido reglamentario, que de forma amena y clara presenta con sencillez los conceptos más básicos y delicados del reglamento. La estructura del libro, aun manteniendo dos partes claramente diferenciadas (jurídica y técnica), establece un permanente vínculo entre ambas, y es en ese nexo precisamente donde reside el principal valor para los responsables técnicos de III

La protección de datos personales: Soluciones en entornos Microsoft aplicar las medidas del reglamento para los datos almacenados utilizando software de Microsoft. Tenemos la esperanza que, este manual, en su segunda edición, sirva para facilitar a los responsables de Seguridad/Privacidad/Sistemas, el cumplimiento de los aspectos tecnológicos derivados del cumplimiento de la Ley, así como servir de vehículo de difusión de un conocimiento importante como es el relativo a nuestros derechos y obligaciones en materia de Protección de Datos. Es un ejemplo más del compromiso incuestionable de Microsoft por colaborar, decidida y eficazmente, con la administración española en el desarrollo de la Sociedad del Conocimiento en nuestro país. María Garaña Presidenta de Microsoft Ibérica S.R.L. IV

Prólogo de Artemi Rallo Como Director de la Agencia Española de Protección de Datos, institución pública independiente, cuya labor primordial es la de velar por el cumplimiento de la normativa de protección de datos de carácter personal, supone para mí una enorme satisfacción poder presentar este libro, “La Protección de Datos Personales: soluciones en entornos Microsoft”, fruto de los trabajos realizados por entidades de la talla de Microsoft, Helas Consultores, IPSCA, Informática64 y Red.es. Debemos destacar el objetivo primordial que pretende conseguir una obra como la que en estos momentos se edita y que viene a reforzar la labor de difusión y divulgación del derecho fundamental a la protección de datos de carácter personal en nuestro país. El libro que tengo la oportunidad de prologar, una vez adaptado a la normativa vigente en materia de protección de datos personales debe, sin lugar a dudas, convertirse en una guía de consulta, no sólo para los responsables de ficheros y tratamientos de datos personales sino también para los posibles encargados de tratamientos que pudieran contratarse como consecuencia de la necesaria presta- ción de un servicio determinado, tanto en el ámbito privado como público y que el propio RLOPD regula de manera muy detallada en su articulado. Los conceptos mencionados en este libro y las obligaciones que todo responsable de un fichero o tratamiento deben cumplir dentro del marco de la protección de datos personales, analizados de una forma muy detallada a lo largo del mismo, pretenden aportar una claridad y una seguridad jurídica valiosa a la hora de interpretar la normativa vigente. Sin lugar a dudas, la lectura del presente texto debe servir para resolver gran parte de las posibles dudas que pudieran tener los responsables de ficheros o tratamientos al interpretar las normas concernientes a la protec- ción de datos de carácter personal. Principios como la calidad de los datos, la información previa que ha de ser prestada al titular de los datos para recabar su consentimiento, el deber de secreto, la seguridad de los datos recabados, la proporcionalidad que debe regir acorde con la finalidad que justifica la recogida de la información personal o la veracidad y exactitud de los datos personales tratados, son principios que han de ser respetados y considerados como una de las piedras angulares de la materia que nos ocupa. El reconocimiento de los derechos ARCO (acceso, rectificación, cancelación y oposición) en relación con el tratamiento de datos de carácter personal es uno de los pilares fundamentales de la protección de datos personales, sin duda muy vinculado al deber de información que en ocasiones los responsables de ficheros y tratamientos no cumplen con la minuciosidad que establece la Ley. Junto a la aplicación de los aspectos mencionados, los responsables de ficheros y tratamientos de datos personales deberán tener en cuenta las obligaciones relacionadas con la implementación de medidas de seguridad de índole técnica y organizativa acordes con la información personal gestionada tanto en soportes V

La protección de datos personales: Soluciones en entornos Microsoft automatizados como no automatizados y que de manera muy detallada regula el RLOPD. Otras cuestiones, como la autorregulación o los movimientos internacionales de datos, cuya ejecución requieren de la autorización previa del Director de la Agencia Española de Protección de Datos, salvo que se destinen a países que proporcionen un nivel adecuado de protección o se trate de los supuestos excepcionados que la propia LOPD establece, deberán igualmente ser tenidas en cuenta por los responsables de ficheros y tratamientos que pudieran verse involucrados en alguna de estas situaciones. El presente libro hace alusión a los diferentes procedimientos que la Agencia Española de Protección de Datos tramita y que el RD 1720/2007, de desarrollo de la LOPD, regula de manera muy detallada en relación con la notificación de los ficheros y tratamientos por parte de sus responsables, los vinculados a la tutela del ejercicio de los derechos ARCO, los posibles procedimientos sancionadores que pudieran iniciarse con motivo de la comisión de las infracciones tipificadas en la LOPD, así como otros procedimientos relacionados con la inscripción de códigos tipo, las solicitudes de autorización para realizar una transferencia internacional de datos y otros procedimientos más excepcionales relacionados con el deber de informar y la conservación de datos para fines específicos (históricos, estadísticos o científicos). El alto nivel de competencia que rige en determinados sectores del ámbito empresarial no debe ser, de ninguna manera, una licencia que permita olvidar la existencia de una información personal que, salvo las excepciones que la propia Ley establece, son los propios titulares de esos datos personales quienes deben decidir el uso, las aplicaciones, cesiones y finalidades que se les puede dar a los mismos. La actuación empresarial, conforme a lo regulado en la Ley, debe interpretarse como un valor añadido para la empresa y para su imagen, aportando una mayor calidad y una mejor gestión de sus recursos y, en ningún caso, el cumplimiento de la normativa vigente debe entenderse como un obstáculo de difícil superación. La entidades e instituciones a las que va dirigida la normativa de protección de datos no sólo deben colaborar en la defensa de los derechos de los ciudadanos, sino que además deben ser conscientes de que el cumplimiento de la Ley redundará en una mayor seguridad propia, de sus sistemas, de la información que registren, en ocasiones muy valiosa y cuya pérdida puede suponer una secuencia irreparable de daños económicos de gran envergadura. Por todo ello, la implementación de medidas de seguridad, de carácter técnico y organizativo, acorde con la información gestionada, debe ser una prioridad y un procedimiento incorporado al quehacer diario del ámbito empresarial. La aplicación de las nuevas tecnologías, en la sociedad en la que nos encontramos inmersos, debe tener en cuenta la existencia de distintas modalidades de tratamiento de la información personal que permitan identificar a una persona física, en todas sus variantes (dato identificativo, imagen, fotografía, dato biométrico, voz, etc.). VI

Debemos ser conscientes de que en muchas ocasiones el incumplimiento de la Ley se debe a una falta de conocimiento y de información de las normas, derechos y procedimientos existentes. He de destacar que la Agencia Española de Protección de Datos, como autoridad garante de este derecho fundamental, apoyará siempre iniciativas como la que en esta ocasión han impulsado entidades como Microsoft, Helas Consultores, IPSCA y Red.es, que avanzan en el camino de una mayor concienciación y difusión de la normativa de protección de datos de carácter personal, siempre desde la perspectiva de la prevención e información. Artemi Rallo Director de la Agencia Española de Protección de Datos VII

La protección de datos personales: Soluciones en entornos Microsoft Prólogo de Sebastián Muriel Actualmente asistimos a un cambio del uso social de la tecnología sin precedentes en la historia de la humanidad. Sería difícil tratar de entender este repentino aumento de la permeabilidad social hacia lo tecnificado, sin la ubicua presencia de las tecnologías de la información y de las comunicaciones (TIC) y de todos los servicios asociados a las mismas, hasta el punto de que lo que distingue a las economías avanzadas de las economías emergentes, es la intensidad en el uso de estas tecnologías. Gracias a importantes logros como el Plan Avanza, puesto en marcha por la Secretaría de Estado de Telecomunicaciones y para la Sociedad de la Información en 2005, se puede decir que España está ya en posición de liderazgo en muchos de los indicadores que miden el uso de las TIC. Un uso que es creciente en todas las actividades y áreas que se nos puedan ocurrir: en el plano profesional, en la esfera del ocio (cada vez más interactivo y más digital, donde los contenidos digitales y las redes sociales juegan un papel cada vez más relevante), en las maneras de acceder a las noticias y a la información en los medios de comunicación, en la educación, en la sanidad, en la relación de los ciudadanos y empresas con las diferentes administraciones, pero además, sobre todo, en las maneras de relacionarnos unos con otros, con nuestras familias, amigos y conocidos. Es evidente que éste es el camino y que los esfuerzos realizados suponen una ventaja comparativa como país. En este entorno es importante educar y sensibilizar a los usuarios en el buen uso de las TIC. Porque la creciente expansión del mundo digital conlleva un reto a la gestión adecuada de la privacidad. Por eso estoy convencido de que iniciativas como la segunda edición de este manual realizado por Microsoft, van a servir, gracias a su carácter divulgativo, a mejorar el cumplimiento de la LOPD y que derivará en beneficios y ventajas de inmenso valor para la empresa y Administraciones Públi- cas, además de concienciar a todos los sectores (empresas, administraciones) y a los usuarios, especialmente a los más jóvenes, de que los datos personales son un bien que debe protegerse y, por ello, deben establecerse procedimientos, normas y medidas para conseguir tal fin. Sebastián Muriel. Director General de red.es. Secretaría de Estado de Telecomunicaciones y para la Sociedad de la Información VIII

Autores El coordinador de los contenidos de esta obra es Héctor Sánchez Montenegro, National Technology Officer de Microsoft Ibérica, y los autores de este libro son: José María Alonso Cebrián de Informática 64, Microsoft MVP en el área de Seguridad. Juan Luís García Rambla de Informática 64, Microsoft MVP en el área de Seguridad. Antonio Soto. Director de Solid Quality. David Suz Pérez. Consultor de Microsoft Ibérica. José Helguero Sainz. Director General de Helas Consultores. Economista. Miembro de la Comisión de Seguridad de ASIMELEC. María Estrella Blanco Patiño, Responsable de publicaciones de Helas Consul- tores. Miguel Vega Martín, Director de Marketing de IPS Certification Authority. Miembro de la Comisión de Seguridad de ASIMELEC. Héctor Sánchez Montenegro. National Technology Officer de Microsoft Ibérica. IX

La protección de datos personales: Soluciones en entornos Microsoft Agradecimientos Los autores quieren agradecer a las siguientes personas, quienes sin su inesti- mable colaboración, hubiera resultado mucho más difícil la edición de este libro:  Dña. María Garaña, Presidenta de Microsoft Ibérica.  D. Artemi Rallo, Director de la Agencia de Protección de Datos Española.  D. Sebastián Muriel, Director General de Red.es.  D. Alberto Amescua de Microsoft Ibérica, programa Technet.  D Fernando Bocigas de Microsoft Ibérica.  Dña. Barbara Olagaray de Microsoft Ibérica.  D. Luis Miguel García de la Oliva de Microsoft Ibérica.  D. Francisco Camina Álvarez. Gerente de Soluciones de Microsoft Ibérica.  D. Fernando García Varela. Director Comercial de Industria. De Microsoft Ibérica.  D. Rodolfo Lomascolo Szittyay, Director General de IPS Certification Authority, S.L.  D. Ignacio de Bustos Martín, Director General de Newcomlab S.L.L.  D. Manuel Sánchez Chumillas de Informática64.  Los técnicos de la “guarida del sótano” de Informática64.  Dña. María Martín Pardo de Vera, Responsable del Departamento de Consultoría de Helas Consultores.  Dña. Carmen de Prada Hernández, Responsable del Departamento de Instituciones de Helas Consultores.  Dña. María de la Rica Ortega, Responsable del Departamento de Auditoría de Helas Consultores.  Dña. Cristina Palomino Dávila, Consultora senior en el Departamento de Consultoría de Helas Consultores.  D. Miguel Prieto Quintana, Director Comercial de Helas Consultores.  D. María Rita Helguero Sainz, Directora de Administración de Helas Consultores.  Dña. Mónica Pujadó Coll, Directora Financiera de ipsCA.  Dña. Vera Sánchez - Carpintero Rodríguez, Responsable de Marketing Internacional ipsCA.  Dña. Irene Corral López, Departamento Marketing ipsCA.  Dña. Marta Corral López, Departamento Marketing ipsCA.  D. Guillermo Alcázar, Departamento Marketing ipsCA.  D. Alfonso Dominguez, Departamento Marketing ipsCA. X

Índice de contenidos Introducción .............................................................................................. XVII Parte I Legal ................................................................................................... 1 1. Breve historia de la protección de datos de carácter personal ..................... 3 1.1. La protección de datos personales, un derecho fundamental .............. 4 2. Legislación vigente ........................................................................................... 7 2.1. Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (LOPD) ................................................................. 7 2.2. Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de Desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (RLOPD) ..... 7 2.2.1. Plazos de adaptación ................................................................... 8 3. Datos de carácter personal ............................................................................. 11 3.1. Tipos de datos personales ..................................................................... 12 3.2. Novedades RLOPD en la aplicación de algunas medidas de seguridad (Artículo 81.5 y 81.6) ...................................................... 14 3.3. Otros datos personales .......................................................................... 15 4. Obligaciones básicas ...................................................................................... 17 4.1. Con carácter previo a la recogida de los datos .................................... 17 4.1.1. La creación y notificación de ficheros ....................................... 17 4.1.2. La calidad de los datos ............................................................... 25 4.1.3. La información al interesado ..................................................... 26 4.1.4. El consentimiento del interesado .............................................. 32 4.2. Durante el tratamiento de los datos ..................................................... 37 4.2.1. La calidad de los datos ............................................................... 37 4.2.2. El deber de secreto ..................................................................... 38 4.2.3. La seguridad de los datos .......................................................... 39 4.2.4. La cesión de los datos ................................................................ 54 4.2.5. El acceso a datos por cuenta de terceros ................................... 56 4.2.6. Prestaciones de servicios sin acceso a datos personales .......... 60 4.2.7. La modificación de ficheros ....................................................... 61 4.2.8. Las transferencias internacionales de datos .............................. 61 4.3. Una vez finalizado el tratamiento ........................................................ 63 4.3.1. La cancelación y el bloqueo de los datos .................................. 63 4.3.2. La supresión de ficheros ............................................................ 63 XI

La protección de datos personales: Soluciones en entornos Microsoft 5. Los derechos de los titulares de los datos .................................................... 65 5.1. La impugnación de valoraciones ......................................................... 65 5.2. El derecho de consulta al Registro General de Protección de Datos .. 65 5.3. El derecho de indemnización ............................................................... 66 5.4. Los derechos ARCO .............................................................................. 66 5.4.1. El derecho de acceso .................................................................. 68 5.4.2. El derecho de rectificación ......................................................... 68 5.4.3. El derecho de oposición ............................................................. 69 5.4.4. El derecho de cancelación .......................................................... 70 5.5. La tutela de los derechos ...................................................................... 70 6. Tratamientos especiales ................................................................................. 73 6.1. Prestación de servicios de información sobre solvencia patrimonial y crédito ................................................................................................. 73 6.1.1. Requisitos para la inclusión de los datos .................................. 74 6.1.2. Información previa a la inclusión .............................................. 74 6.1.3. Notificación de la inclusión ....................................................... 74 6.1.4. Conservación de los datos ......................................................... 75 6.1.5. Acceso a la información contenida en el fichero ...................... 75 6.1.6. Responsabilidad ......................................................................... 75 6.1.7. Ejercicio de los derechos ARCO ................................................ 75 6.2. Tratamientos con fines de publicidad y de prospección comercial .... 76 6.2.1. Campañas publicitarias ............................................................. 77 6.2.2. Depuración de bases de datos ................................................... 77 6.2.3. Exclusión del envío de comunicaciones comerciales ............... 77 6.2.4. Ejercicio de derechos .................................................................. 78 6.3. Sistemas de videovigilancia ................................................................. 78 7. La autorregulación: los códigos tipo ............................................................. 81 7.1. Objeto de los códigos tipo .................................................................... 83 7.2. Naturaleza de los códigos tipo ............................................................. 83 7.3. Sujetos habilitados para la adopción de códigos tipo ......................... 83 7.4. Procedimiento para la elaboración de códigos tipo ............................ 84 7.5. Contenido de los códigos tipo .............................................................. 84 7.6. Ventajas derivadas de la creación de códigos tipo .............................. 87 7.7. Garantías del cumplimiento de los códigos tipo ................................. 88 7.8. Obligaciones posteriores a la inscripción del código tipo .................. 88 7.9. Códigos tipo inscritos ........................................................................... 89 XII

8. Infracciones y sanciones ................................................................................ 95 8.1. Los responsables ................................................................................... 95 8.2. Las infracciones: tipos ........................................................................... 95 8.2.1. Leves ........................................................................................... 95 8.2.2. Graves ......................................................................................... 96 8.2.3. Muy graves ................................................................................. 97 8.3. Prescripción ........................................................................................... 98 8.4. La infracción continuada ...................................................................... 98 8.5. Las sanciones ......................................................................................... 99 8.5.1. Las sanciones en el sector privado ............................................ 99 8.5.2. Las sanciones en el sector público ........................................... 101 8.6. El procedimiento sancionador ........................................................... 102 8.6.1. Procedimiento sancionador ..................................................... 102 8.6.2. Procedimiento de tutela de derechos ...................................... 103 9. Los órganos de control ................................................................................. 105 9.1. La Agencia Española de Protección de Datos (AEPD) ..................... 105 9.2. Las agencias de protección de datos de las comunidades autónomas ........................................................................................... 107 9.2.1. Agencia de Protección de Datos de la Comunidad de Madrid (APDCM) ............................................................... 107 9.2.2. Agencia Catalana de Protecció de Dades (APDCAT) ............ 107 9.2.3. Agencia Vasca de Protección de Datos (AVPD) ...................... 108 9.3. Conclusiones ....................................................................................... 108 Parte II Técnico ............................................................................................ 111 10. La seguridad en sistemas Microsoft ........................................................... 113 10.1. TrustWorthy Computing (TWC). La estrategia de Microsoft ........... 114 10.2. Soluciones seguras .............................................................................. 114 10.2.1.Seguridad en el diseño ............................................................. 115 10.2.2.Seguridad predeterminada ...................................................... 115 10.2.3.Seguridad en el despliegue ...................................................... 116 10.2.4.Comunicación ........................................................................... 117 10.3. ¿Que se ha conseguido con TWC? ..................................................... 117 10.3.1.Common Criteria ..................................................................... 118 10.3.2.Evaluación de FIPS 140 (Federal Information Processing Standard) ........................................................................................ 120 10.3.3.Iniciativa de recursos compartidos ......................................... 121 XIII

La protección de datos personales: Soluciones en entornos Microsoft 10.3.4.Programa para la cooperación de la seguridad (SCP) ........... 122 10.3.5.Seminarios de seguridad ......................................................... 122 11. La aplicación del reglamento de seguridad en los sistemas Microsoft ... 123 11.1. Tecnología de seguridad en Microsoft Windows .............................. 124 11.2. Tecnologías aplicables a medidas de nivel básico ............................. 125 11.2.1. Ficheros temporales ................................................................. 126 11.2.2. Artículo 89. Funciones y obligaciones del personal ............... 127 11.2.3. Artículo 90. Registro de incidencias ........................................ 130 11.2.4. Artículo 91. Control de acceso (puntos 1 y 3) ......................... 130 11.2.5. Artículo 91. Control de acceso (punto 2) ................................. 145 11.2.6. Artículo 91. Control de acceso (puntos 4 y 5) ......................... 146 11.2.7. Artículo 92. Gestión de soportes y documentos ..................... 146 11.2.8. Artículo 93. Identificación y autenticación (puntos 1 y 2) ..... 153 11.2.9. Artículo 93. Identificación y autenticación (punto 3) ............. 165 11.2.10. Artículo 93. Identificación y autentificación (punto 4) ........ 167 11.2.11. Artículo 94. Copias de respaldo y recuperación .................. 169 11.3. Tecnología aplicable a medidas de nivel medio ................................ 174 11.3.1. Artículo 98. Identificación y autenticación ............................. 175 11.4. Tecnología aplicable a medidas de nivel alto .................................... 176 11.4.1. Artículo 101. Gestión y distribución de soportes ................... 177 11.4.2. Artículo 102. Copias de respaldo y recuperación ................... 177 11.4.3. Artículo 103. Registro de accesos ............................................ 178 11.4.4. Artículo 104. Telecomunicaciones ........................................... 215 11.4.5. Confidencialidad en Exchange 2007 ....................................... 218 12. La aplicación del reglamento de seguridad en SQL Server ..................... 223 12.1. Artículo 91. Control de acceso ............................................................ 223 12.2. Artículo 93. Identificación y autenticación ........................................ 225 12.3. Artículo 94. Copias de respaldo y recuperación ............................... 226 12.4. Artículo 98. Identificación y autenticación ........................................ 229 12.5. Artículo 101. Gestión y distribución de soportes .............................. 230 12.6. Artículo 103. Registro de accesos ....................................................... 231 12.6.1.Auditoría en SQL Server 2008 ................................................. 231 12.7. Artículo 104. Telecomunicaciones ...................................................... 232 13. Implementación de la LOPD sobre SQL Server (SQL Server 2005-2008) 235 13.1. Introducción ........................................................................................ 235 13.2. Objetivos del documento .................................................................... 235 13.3. Ejemplo teórico ................................................................................... 236 XIV

13.4. Requisitos ............................................................................................ 237 13.5. Implementación .................................................................................. 238 13.5.1.Implementación del proceso de Registro de Accesos ............ 238 13.5.2.Acceso a la información de Registro de Accesos .................... 245 13.5.3.Recomendaciones en casos especiales .................................... 248 13.6. Rendimiento ........................................................................................ 248 13.6.1.Sobrecarga del proceso de traza .............................................. 248 13.6.2.Almacenamiento físico de los ficheros de traza ..................... 250 13.7. Nuevas características en SQL Server 2008 ....................................... 251 13.8. Apéndices ............................................................................................ 252 13.8.1.Implementación de trazas sobre SQL Server 2005 ................. 252 13.8.2.Posibilidades de Backup y Restore en SQL Server 2005 ........ 253 13.8.3.Seguridad en SQL Server 2005 ................................................ 253 13.8.4.Seguridad en SQL Server 2008 ................................................ 253 14. Política de seguridad .................................................................................... 255 14.1. Introducción ........................................................................................ 255 14.2. Fases fundamentales ........................................................................... 255 14.2.1.Fase 1. Organización y análisis ................................................ 256 14.2.2.Fase 2. Desarrollo de un estudio sobre las necesidades de privacidad ............................................................................ 258 14.2.3.Fase 3. Evaluación de las necesidades tecnológicas para la protección de la privacidad ................................................. 260 Parte III Anexos ............................................................................................. 263 Anexo A. Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal ................................................................................. 265 Anexo B. Real decreto por el que se aprueba el reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal .................................................................................................... .. 295 Glosario de términos ........................................................................................... 383 XV

La protección de datos personales: Soluciones en entornos Microsoft XVI

I Introducción El Tribunal Constitucional, en su sentencia 292/2000, define la Protección de Datos de Carácter Personal como el derecho fundamental que garantiza a toda persona “un poder de control sobre sus datos personales, sobre su uso y destino, con el propósito de impedir su tráfico ilícito y lesivo para la dignidad y derecho del afectado”. La automatización del tratamiento de datos, fruto de la aplicación y desarrollo de la informática, proporciona numerosas ventajas, aumentando la productividad y la competitividad, tanto de las personas como de las empresas. Los beneficios sobrepasan con mucho los problemas que se derivan del tratamiento de datos personales, pero debemos de poner límite al grado de intrusión en nuestra intimidad que las nuevas tecnologías pueden generar. La legislación sobre protección de datos establece esos límites y, por ello, afecta a todas las empresas y organismos públicos de nuestro país, porque todos -en mayor o menor medida- manejan datos de carácter personal de personas físicas (empleados, clientes, proveedores, accionistas, colaboradores…). Así pues, todos ellos deben adecuarse a la legislación actual sobre protección de datos contemplan- do una doble perspectiva: por un lado, el respeto a los derechos de los ciudadanos y, por otro, su funcionamiento interno y la seguridad de su información. Hoy en día la actividad empresarial y pública no se concibe sin el apoyo de la informática, ya que gracias a programas y aplicaciones (software) podemos manejar un gran volumen de datos. Por tanto, no son discutibles las enormes ventajas de la informática. Sin embargo, también es cierto que ésta puede conllevar cierta peligrosidad si se hace un mal uso de ella. Pensemos en la cantidad de información que se puede obtener de una persona si miramos sus movimientos bancarios: podemos saber qué tipo de restaurantes le gustan, a qué tipo de colegio lleva a sus hijos, dónde va de vacaciones, sus gustos y aficiones, qué deporte practica, si es una XVII

La protección de datos personales: Soluciones en entornos Microsoft persona solvente, etc. Este conocimiento ordenado de los datos puede arrojar un perfil de la persona, que quizás ni ésta misma conoce, y que puede ser utilizado, favorable o desfavorablemente, para todo tipo de actividades, como es, por ejemplo, la selección de personal. No debemos tampoco olvidar los ficheros y los tratamientos en formato papel, que adquieren una especial importancia con el Nuevo Reglamento aprobado mediante el Real Decreto 1720/2007 (RLOPD). Por ello, ha sido necesario establecer una serie de mecanismos que protejan al individuo de este tipo de actuaciones. La legislación actual desarrolla una serie de obligaciones que las empresas deben cumplir, y el objetivo de este libro es describir- las y facilitar a los responsables de ficheros y tratamientos la comprensión y el alcance de dichas obligaciones. Cualquier empresa o institución que tenga, mantenga, utilice o trate datos de carácter personal, en soporte informático o papel, se encuentra obligada al cumplimiento de la normativa vigente en materia de protección de datos; por tanto, en la práctica todas las empresas e instituciones. Pero además debemos tener en cuenta que la normativa aplicable protege al titular de los datos en cada una de las fases que conlleva la utilización de los mismos en una empresa, y que son básicamente tres: 1. Con carácter previo a la recogida de los datos. 2. Durante el tratamiento de los datos. 3. Una vez finalizado el tratamiento. Por tanto, podemos concluir que las obligaciones de las organizaciones no se reducen a un momento en concreto; sino que el cumplimiento con la legislación es un proceso permanente que afecta a la actividad que desarrollan de manera cons- tante. Las preguntas que siempre se hace el responsable de los ficheros cuando se le plantea la necesidad de adecuar su organización a una nueva legislación son: ¿Qué beneficio obtengo de esa adecuación?, ¿No es otra vez un gasto de dinero inútil? El caso de la Protección de Datos de Carácter Personal no es ajeno a este tipo de preguntas. Como premisa importante hay que tener en cuenta que la adaptación a la legislación en materia de Protección de Datos de Carácter Personal no es, en ningún caso, un problema del departamento de Informática o de Sistemas. Para que una empresa tenga éxito en dicha adaptación debe implicar a todos los departamentos de la compañía, y si este proceso se afronta únicamente como un problema informático, el fracaso está asegurado. Las cinco principales causas por las que una empresa debe adaptarse a la legislación en materia de Protección de Datos de Carácter Personal son: XVIII

Introducción 1. Cumplir con la legislación vigente: la adecuación a la realidad normativa es cada vez más un requisito del mercado para llevar a buen fin nuestros negocios. Las administraciones públicas y nuestros clientes demandan el cumplimiento de la legislación vigente, y el cumplimiento en materia de Protección de Datos se está ya exigiendo como un requisito indispensable en grandes áreas de negocio (informática, publicidad, sanidad, etc.). 2. Evitar sanciones de la Agencia Española de Protección de Datos (AEPD): éstas, las más elevadas de la Unión Europea, varían desde los 601,01 a los 601.012,10 €, como analizaremos más adelante en este libro. 3. Evitar el deterioro de la imagen pública: la publicación en prensa de noticias relacionadas con de la aparición en la vía pública de expedientes médicos abandonados o de currículos con anotaciones xenófobas como resultado de la selección de personal de un supermercado, causan un enorme perjuicio para los responsables de esos ficheros, que en muchas ocasiones es mayor que la sanción impuesta posteriormente por la AEPD. 4. Gestionar la información en la empresa: la adaptación a la normativa en materia de Protección de Datos ayuda a iniciar una gestión moderna de la información dentro de la empresa. La empresa española tiene en la gestión de la información una asignatura pendiente y la implementación de las normas a que nos obliga la protección de datos es, en la mayoría de los casos, el inicio de la concienciación y de la toma de medidas destinadas a la salvaguarda de uno de los mayores activos de la empresa moderna: la información. 5. Mejorar la gestión de la calidad: la integración de las medidas a implementar en materia de protección de datos en todos los departamentos de la empresa, debe realizarse como un proceso de mejora de nuestros sistemas de trabajo, y nunca como una traba o impedimento. Concebir la protección de datos como un proceso más dentro de la calidad de la empresa es vital para el éxito de nuestra adaptación a la LOPD y es por ello que debemos implicar a las fuerzas vivas de la empresa (Dirección, Administración, Recursos Humanos, Marketing, Informática, Comercial, Calidad, etc.), y en especial debemos tener en cuenta el factor humano, donde la formación debe tener un papel muy relevante. XIX

Parte I Legal 1. Breve historia de la protección de datos de carácter personal 3 2. Legislación vigente 7 3. Datos de carácter personal 11 4. Obligaciones básicas 17 5. Los derechos de los titulares de los datos 65 6. Tratamientos especiales 73 7. La autorregulación: los códigos tipo 81 8. Infracciones y sanciones 95 9. Los órganos de control 105

La protección de datos personales: Soluciones en entornos Microsoft 2

1 Breve historia de la protección de datos de carácter personal La evolución de la informática, que ha facilitado la gestión masiva de la información relativa a las personas, ha supuesto que se genere un nuevo derecho de las personas a la protección de los datos de carácter personal, que se ha desarrollado en un tiempo récord. Antes de adentrarnos en la evolución de la protección de datos en nuestro país, debemos hacer referencia a tres importantes declaraciones internacionales en las que se ha reconocido el derecho a la intimidad y a la protección de datos de carácter personal. Como punto de partida, el artículo 12 de la Declaración Universal de Derechos Humanos1 establece lo siguiente: “Nadie será objeto de injerencias arbitrarias en su vida privada, su familia, su domicilio o su correspondencia, ni de ataques a su honra o reputación. Toda persona tiene derecho a la protección de la ley contra tales injerencias o ataques”. Dos años después, el Convenio Europeo para la Protección de los Derechos Humanos y Libertades Fundamentales del Consejo de Europa 2 establece en su artículo 8: “Toda persona tiene derecho al respeto de su vida privada y familiar, de su domicilio y de su correspondencia”. 1. Proclamada por la Asamblea General de las Naciones Unidas el 10 de septiembre de 1948. 2. Firmado en Roma por el Consejo de Europa el 4 de noviembre de 1950. 3

La protección de datos personales: Soluciones en entornos Microsoft En tercer lugar, el Convenio 108 del Consejo de Europa3 establece en su artículo 1: “…garantizar… a cualquier persona física… el respeto de sus derechos y libertades fundamentales, concretamente su derecho a la vida privada, con respecto al tratamiento automatizado de los datos de carácter personal correspondientes a dicha persona”. En España, la Ley Orgánica 5/1992, de 29 de octubre, de Regulación del Tratamiento Automatizado de los Datos de Carácter Personal (LORTAD), desarrolla lo recogido en el artículo 18 de la Constitución Española de 1978 y establece, por primera vez, la limitación del uso de la informática para garantizar la intimidad personal. Posteriormente, la Directiva 95/46/CE del Parlamento Europeo y del Consejo de 24 de octubre de 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 (Directiva 95/46/CE), establece el marco jurídico en el que se desarrolla la actual legislación española en Protección de Datos de Carácter Personal. La LORTAD tardó siete años en disponer de su desarrollo reglamentario, que llegó con el Real Decreto 994/1999, de 11 de junio: Reglamento de Medidas de Seguridad de los Ficheros Automatizados que contengan Datos de Carácter Perso- nal (RMS). Pocos meses después de la aprobación de dicho reglamento se promulgó la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (LOPD), vigente en la actualidad, y que adapta la legislación española a la Directiva europea, desarrollando la protección de datos más allá de los datos informatizados, incluyendo dentro de su ámbito de aplicación los datos de carácter personal registrados en soporte físico, que los haga susceptibles de tratamiento automatizado o no, y toda modalidad de uso de los mismos. Por fin, la LOPD, tras un periodo de ocho años conviviendo con el RMS, ha visto cómo su desarrollo reglamentario ha sido plasmado mediante el Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de Desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (RLOPD). 1.1. La protección de datos personales, un derecho fundamental Si bien durante muchos años ha habido muchas y enfrentadas fuentes doctrinales que discutían si el derecho a la protección de datos es un derecho independiente o se encuentra enmarcado dentro de la esfera del derecho a la intimidad, la Sentencia del Tribunal Constitucional 292/2000 expone en su fundamento jurídico 7: 3. Firmado en Estrasburgo el 28 de enero de 1981. 4

Breve historia de la protección de datos de carácter personal “…el contenido del derecho fundamental a la protección de datos consiste en un poder de disposición y de control sobre los datos personales que faculta a la persona para decidir cuáles de estos datos proporcionar a un tercero, sea el Estado o un particular, o cuáles puede este tercero recabar, y que también permite al individuo saber quién posee esos datos personales y para qué, pudiendo oponerse a esa posesión o uso…”. Así mismo, expone que este derecho se concreta en: “…la facultad de consentir la recogida, la obtención y el acceso a los datos personales, su posterior almacenamiento y tratamiento, así como su uso o usos posibles, por un tercero, sea el Estado o un particular…” y considera indispensable para hacer efectivo este derecho: “…el reconocimiento del derecho a ser informado de quién posee sus datos personales y con qué fin, y el derecho a poder oponerse a esa posesión y uso requiriendo a quien corresponda que ponga fin a la posesión y empleo de los datos”. Por tanto, el derecho a la protección de datos es un derecho independiente porque se protege cualquier dato de carácter personal que identifique a la persona, y no sólo los datos de su esfera íntima. 5

2 Legislación vigente 2.1. Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (LOPD) Es la Ley vigente en la actualidad y que adapta la legislación española a la Directiva europea. Su ámbito de aplicación comprende todos los ficheros que contengan datos de carácter personal, con independencia de que se trate de ficheros automatizados o en formato papel. Incluye como otras novedades principales la definición del Encargado del Tratamiento, la regulación de los tratamientos de datos y las relaciones entre Responsable del Fichero y Encargado del Tratamiento, la definición de fuentes accesibles al público, el censo promocional e incorpora el nuevo derecho de oposición. 2.2. Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de Desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (RLOPD) El RLOPD (que entró en vigor el día 19 de abril de 2008) desarrolla la LOPD y consolida la doctrina reguladora establecida por la AEPD en sus instrucciones y expedientes sancionadores, así como la interpretación que de la LOPD han efectuado los Tribunales a través de la jurisprudencia. El RLOPD incrementa la protección ofrecida a los datos de carácter personal, pero, por otra parte, establece ciertas especialidades para facilitar la implantación de medidas de seguridad, que inciden sobre todo en el ámbito de las PYMES. Este nuevo Reglamento, que sustituye al RMS 994/99, establece, entre otras cosas, las medidas de seguridad para los ficheros no automatizados, regula las 7

La protección de datos personales: Soluciones en entornos Microsoft relaciones entre el Responsable del Fichero y el Encargado del Tratamiento (permitiendo además la subcontratación), introduce novedades importantes con respecto a los ficheros sobre solvencia patrimonial y crédito y respecto al ejercicio de derechos, así como otras novedades que se desarrollan en detalle en este libro más adelante. Las infracciones, sanciones o cuantía de las multas no se han modificado, pero sí se ha introducido, con respecto a las actuaciones previas al Procedimiento Sancionador de la AEPD, un límite temporal de doce meses a contar desde la fecha de la denuncia. El vencimiento del plazo sin que se haya dictado y notificado el acuerdo de inicio de procedimiento sancionador producirá la caducidad de las actuaciones previas. 2.2.1. Plazos de adaptación La Disposición transitoria segunda del RLOPD recoge los plazos de implanta- ción de las medidas de seguridad con arreglo a las siguientes reglas: 2.2.1.1. Respecto de los ficheros automatizados que existieran en la fecha de entrada en vigor del RLOPD (19 abril 2008): a) En el plazo de un año desde su entrada en vigor (19 de abril de 2009), deberán implantarse las medidas de seguridad de nivel medio exigibles a los siguientes ficheros:  Aquéllos de los que sean responsables las Entidades Gestoras y Servicios Comunes de la Seguridad Social y se relacionen con el ejercicio de sus competencias.  Aquéllos de los que sean responsables las mutuas de accidentes de trabajo y enfermedades profesionales de la Seguridad Social.  Aquéllos que contengan un conjunto de datos de carácter personal que ofrezcan una definición de las características o de la personalidad de los ciudadanos y que permitan evaluar determinados aspectos de la personalidad o del comportamiento de los mismos. b) En el plazo de un año (19 de abril de 2009) deberán implantarse las medidas de seguridad de nivel medio a aquéllos de los que sean responsables los operadores que presten servicios de comunicaciones electrónicas disponibles al público o exploten redes públicas de comunicaciones electrónicas respecto a los datos de tráfico y a los datos de localización. c) En el plazo de dieciocho meses (19 de octubre de 2009) las de nivel alto exigibles a los ficheros que contengan datos derivados de actos de violencia de género. d) En los demás supuestos, cuando el RLOPD exija la implantación de una medida adicional no prevista en el RMS. Dicha medida deberá implantarse en el plazo de un año (19 de abril de 2009). 8

Legislación vigente 2.2.1.2. Respecto de los ficheros no automatizados que existieran en la fecha de entrada en vigor del RLOPD: a) Las medidas de seguridad de nivel básico deberán implantarse en el plazo de un año desde su entrada en vigor (19 de abril de 2009). b) Las medidas de seguridad de nivel medio deberán implantarse en el plazo de dieciocho meses desde su entrada en vigor (19 de octubre de 2009). c) Las medidas de seguridad de nivel alto deberán implantarse en el plazo de dos años desde su entrada en vigor (19 de abril de 2010). 2.2.1.3. Respecto de los ficheros creados con posterioridad a la fecha de entrada en vigor del RLOPD: Los ficheros, tanto automatizados como no automatizados, creados con posterioridad a la fecha de entrada en vigor del RLOPD deberán tener implantadas, desde el momento de su creación, la totalidad de las medidas de seguridad reguladas en el mismo. 9

3 Datos de carácter personal El artículo 2.a 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 circula- ción de esos datos, define el dato personal del siguiente modo: “ toda información sobre una persona identificada o identificable (...) se considerará identificable toda persona, 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”. El artículo 3 de la LOPD utiliza una definición muy genérica de Datos de Carácter Personal: “cualquier información concerniente a personas físicas identificadas o identificables”. Esta definición ha sido ampliada por el artículo 5 del RLOPD al referirse a los mismos como: “cualquier información numérica, alfabética, gráfica, fotográfica, acústica o de cualquier otro tipo concerniente a personas físicas identificadas o identificables”. Asimismo, el RLOPD ha incluido en el Glosario de Términos la definición de persona identificable, entendiendo como tal: “toda persona cuya identidad pueda determinarse, directa o indirectamente, mediante cualquier información referida a su identidad física, fisiológica, psíquica, económica, cultural o social. Una persona física no se considerará identificable si dicha identificación requiere plazos o actividades desproporcionados”. Aun así, el término sigue siendo poco preciso. 11

La protección de datos personales: Soluciones en entornos Microsoft 3.1. Tipos de datos personales Una vez que la organización ha comprobado que tiene datos personales, hay que clasificarlos en función de su tipología, pues no es lo mismo tratar datos meramente identificativos (nombre y apellidos, teléfono, dirección...), que tratar datos que puedan comprometer a la persona (enfermedades, deudas, orientación sexual...). Esta clasificación determinará el nivel de medidas de seguridad que posteriormente tenemos que aplicar a los ficheros. Legalmente, hay varios tipos de datos personales y la clasificación se puede llevar a cabo según dos criterios: 1. Según su importancia: clasifica a los datos personales en función de la relación que tienen esos datos personales con el derecho a la intimidad. Hay datos personales especialmente protegidos que están recogidos en los artículos 7 y 8 de la LOPD: los referidos a la ideología, religión, creencias, afiliación sindical, origen racial o étnico, salud, vida sexual, y comisión de infracciones penales o administrativas. El RLOPD (Art. 81.3.c) considera que también deben aplicarse medidas de seguridad de nivel Alto a los datos derivados de actos de violencia de género. Al resto de datos personales no se les concede una protección especial. 2. Según su seguridad: la clasificación se realiza basándose en las medidas de seguridad que se deben cumplir cuando se posean datos personales, y existen tres niveles (Art. 81 RLOPD):  Datos de nivel Básico: Son aquellos datos personales que no se clasifican como de nivel Medio o de nivel Alto.  Datos de nivel Medio:  Los relativos a la comisión de infracciones administrativas o penales.  Los relativos a prestación de servicios de información sobre solvencia patrimonial y crédito.  Aquellos de los que sean responsables Administraciones tributarias y se relacionen con el ejercicio de sus potestades tributarias.  Aquellos de los que sean responsables las entidades financieras para finalidades relacionadas con la prestación de servicios financieros.  Aquellos de los que sean responsables las Entidades Gestoras y Servicios Comunes de la Seguridad Social y se relacionen con el ejercicio de sus competencias. De igual modo, aquellos de los que sean responsables las mutuas de accidentes de trabajo y enfermedades profesionales de la Seguridad Social. 12

Datos de carácter personal  Aquellos que contengan un conjunto de datos de carácter personal que ofrezcan una definición de las características o de la personalidad de los ciudadanos y que permitan evaluar determinados aspectos de la personalidad o del comportamiento de los mismos.  Datos de nivel Alto:  Los que se refieran a datos de ideología, afiliación sindical, religión, creencias, origen racial, salud o vida sexual.  Los que contengan o se refieran a datos recabados para fines policiales sin consentimiento de las personas afectadas.  Aquellos que contengan datos derivados de actos de violencia de género. Datos de nivel Básico Datos de nivel Medio Datos de nivel Alto  Identificativos.  Hacienda Pública.  Salud.  Características persona-  Los de las Administracio-  Vida sexual. les. nes tributarias relaciona- Ideología. dos con el ejercicio de sus  Circunstancias sociales. potestades tributarias.   Creencias.  Académicos y profesiona- Los de las Entidades les.   Afiliación sindical. Gestoras y Servicios Comunes de la Seguridad Religión. Empleo y puestos de   trabajo. Social y se relacionen con  Violencia de género. el ejercicio de sus  Información comercial. competencia s.  Económico-financieros.  Los de las mutuas de  Transacciones. accidentes de trabajo y enfermedades profesionales de la Seguridad Social.  Servicios financieros.  Solvencia patrimonial y crédito.  Infracciones penales y administrativas.  Los que permitan evaluar determinados aspectos de la personalidad o del comportamiento de los mismos. 13

La protección de datos personales: Soluciones en entornos Microsoft 3.2. Novedades RLOPD en la aplicación de algunas medidas de seguridad (Artículo 81.5 y 81.6) Los departamentos de RR.HH suelen tener ficheros a los que hay que aplicar las medidas de seguridad de nivel alto ya que se pueden recoger datos de Nivel Alto, como Afiliación sindical (por ejemplo, para cómputos de horas sindicales, pago de la cuota en el sindicato correspondiente, etc.) o de Salud (por ejemplo, datos de minusvalías a efectos de practicar las retenciones en el IRPF, reconocimien- tos médicos, etc.). Ahora bien, en algunos casos puntuales, aunque esos datos se sigan considerando de Nivel Alto, pueden concurrir determinadas circunstancias que permiten adoptar las medidas de Nivel Básico:  Los ficheros o tratamientos de datos de ideología, afiliación sindical, religión, creencias, origen racial, salud o vida sexual cuando: a) los datos se utilicen con la única finalidad de realizar una transferencia dineraria a las entidades de las que los afectados sean asociados o miembros. b) se trate de ficheros o tratamientos no automatizados en los que de forma incidental o accesoria se contengan aquellos datos sin guardar relación con su finalidad.  Los ficheros o tratamientos que contengan datos relativos a la salud, referentes exclusivamente al grado de discapacidad o la simple declara- ción de la condición de discapacidad o invalidez del afectado, con motivo del cumplimiento de deberes públicos. Datos de salud Como consecuencia de ello, los datos relativos a una minusvalía siguen siendo datos relativos a la salud (es decir, datos de nivel alto), pero se permite adoptar medidas de seguridad de Nivel Básico cuando su uso se encuentre afectado o vinculado al cumplimiento de deberes públicos. Los supuestos más habituales en relación con los ficheros de nóminas son:  Cuando aparece un porcentaje de minusvalía para calcular el nivel de retención aplicable en nómina.  Cuando contienen información relativa a apto/no apto de un reconocimien- to médico, discapacidad (sí o no), invalidez, incapacidad laboral (sí o no y fecha), enfermedad común, accidente laboral o enfermedad profesional. Si, por el contrario, se describe, por ejemplo, la enfermedad o situación de salud concreta que la causa, o se incluye un código numérico que permita estable- cerla, hay que aplicar el Nivel Alto. 14

Datos de carácter personal Datos relativos a la afiliación sindical Aunque siguen siendo datos de Nivel Alto, se pueden proteger únicamente con medidas de seguridad de Nivel Básico cuando se utilicen exclusivamente para realizar la detracción de la cuota sindical o la domiciliación bancaria. Por el contrario, si contiene, por ejemplo, datos de aquellos afiliados a un sindicato que han disfrutado de las llamadas “horas sindicales”, hay que aplicar el Nivel Alto. 3.3. Otros datos personales La AEPD a través de sus Resoluciones ha ido concretando qué debe entenderse por Datos de Carácter Personal, disipando dudas y ampliando los conceptos, por lo que también deberemos considerar Datos Personales los siguientes:  La imagen (fija o grabación de vídeo): “…la grabación de la imagen de una persona, ya sea trabajador o no de la empresa, es un dato personal, siendo éste el criterio de la Agencia Española de Protección de Datos…” (Resolución R/ 00035/2006, Cuestiones Generales sobre Videovigilancia).  Datos biométricos (huella, iris, etc.): “los datos biométricos tenían la condición de datos de carácter personal y que, dado que los mismos no contienen ningún aspecto concreto de la personalidad, limitando su función a identificar a un sujeto cuando la información se vincula con éste, su tratamiento no tendrá mayor trascendencia que el de los datos relativos a un número de identificación personal, a una ficha que tan solo pueda utilizar una persona o a la combinación de ambos”. (Tratamiento de la huella digital de los trabajadores. Informe AEPD 1/ 1999.)  La dirección de correo electrónico: “…no existe duda de que la dirección de correo electrónico identifica, incluso de forma directa, al titular de la cuenta, por lo que en todo caso dicha dirección ha de ser considerada como dato de carácter personal”. (Cribado de correo electrónico. Informe Jurídico 0391/2007.)  La dirección IP: “…las direcciones IP tanto fijas como dinámicas, con independencia del tipo de acceso, se consideran datos de carácter personal resultando de aplicación la normativa sobre protección de datos”. (Carácter de dato personal de la dirección IP. Informe AEPD 327/2003.) El artículo 5 del RLOPD también define como Persona Identificable a toda persona cuya identidad pueda determinarse, directa o indirectamente, mediante cualquier información referida a su identidad física, fisiológica, psíquica, económi- ca, cultural o social. Una persona física no se considerará identificable si dicha identificación requiere plazos o actividades desproporcionados. Por ello, cualquier dato que permita identificar a una persona deberá considerarse Dato Personal, y su nivel se establecerá en cada caso dependiendo de la tipología del dato y de la finalidad del fichero. 15

La protección de datos personales: Soluciones en entornos Microsoft Por otra parte, el RLOPD no se aplica a: 1. Tratamientos de datos referidos a personas jurídicas. 2. Ficheros que se limiten a incorporar datos de personas físicas que presten sus servicios en aquéllas (nombre y apellidos, las funciones o puestos desempeñados, dirección postal o electrónica, teléfono y número de fax profesionales). 3. Datos relativos a empresarios individuales, cuando hagan referencia a ellos en su calidad de comerciantes, industriales o navieros. 4. Datos referidos a personas fallecidas. 16

4 Obligaciones básicas En este apartado haremos una exposición de las obligaciones principales que la normativa de protección de datos impone a los responsables de los ficheros de datos de carácter personal y demás personas que intervienen en algún momento en el tratamiento de los mismos. Para ello, y con el objetivo de aportar una visión práctica en su desarrollo, hemos dividido el transcurso del tratamiento de los datos en tres momentos principales:  con carácter previo a la recogida de los datos,  durante el tratamiento de los datos y  una vez finalizado el tratamiento. De este modo, analizaremos cada una de las obligaciones, ubicándolas en el momento en el que deben ser tenidas en cuenta para una correcta aplicación de la normativa de protección de datos, ya que la propia LOPD establece en qué punto del tratamiento deben ser apreciadas unas y otras. 4.1. Con carácter previo a la recogida de los datos 4.1.1. La creación y notificación de ficheros ¿Qué es un fichero de datos de carácter personal? Debemos comenzar analizando qué es un fichero de datos de carácter personal y qué se entiende como tal a efectos de notificación. La definición legal de fichero se encuentra recogida en el artículo 3.b) de la LOPD que se expresa en los siguientes términos: 17

La protección de datos personales: Soluciones en entornos Microsoft “todo conjunto organizado de datos de carácter personal, cualquiera que fuere la forma o modalidad de su creación, almacenamiento, organización y acceso”, definición que ha sido desarrollada por el RLOPD, en su artículo 5.1.k), quedando finalmente como: “todo conjunto organizado de datos de carácter personal, que permita el acceso a los datos con arreglo a criterios determinados, cualquiera que fuere la forma o modalidad de su creación, almacenamiento, organización y acceso”. Nos encontramos ante una definición de carácter genérico y que puede resultar tan amplia que en la práctica no ha sido de gran ayuda, creando incluso confu- sión en numerosas ocasiones en las que, atendiendo a la misma, no queda claro si nos encontramos ante un fichero protegido por la normativa de protección de datos personales y que, por consiguiente, debe ser declarado ante la AEPD para su ins- cripción en el RGPD o, por el contrario, podríamos estar ante varios ficheros cuya declaración debe hacerse de forma independiente. Dentro de esta definición podemos englobar muchos términos utilizados habitualmente, tales como base de datos, aplicación, programa, tabla, fichero... -en relación con el tratamiento informatizado-, o cajonera, armario, archivo... -si nos referimos a tratamientos no informatizados, sino manuales-. Estos términos vienen a identificar los denominados ficheros físicos. Frente a estos, existen los llamados ficheros lógicos, que podemos definir como ficheros o conjunto de ficheros físicos que contienen el mismo tipo de datos y son tratados para la misma finalidad. La AEPD ha considerado que sólo los ficheros lógicos son objeto de declara- ción. Esto significa que, una vez identificados los ficheros físicos, el responsable de los mismos podrá agruparlos en ficheros lógicos atendiendo a los criterios indicados. Así por ejemplo, en una empresa pueden existir diversos ficheros físicos con datos de clientes (datos bancarios, gestión de la relación comercial, marketing, gestión de impagados). Todos estos tienen datos de clientes y comparten la finalidad consistente en gestionar la relación con los mismos, de manera que se pueden agrupar en un único fichero lógico y declararse ante la AEPD, por ejemplo, bajo el nombre de clientes. El concepto anteriormente indicado puede matizarse aún más teniendo en cuenta lo establecido en el artículo 2.c) de la Directiva 95/46/CE, dado que el mismo aclara la referencia a la forma de creación, almacenamiento, organización y acceso del fichero al indicar que el conjunto de datos tendrá esa consideración “ya sea centralizado, descentralizado o repartido de forma funcional o geográfica”. En cuanto al reparto geográfico, podemos afirmar que el concepto de fichero no va directamente vinculado a la exigencia de que el mismo se encuentre en una única ubicación. Es posible la existencia de ficheros distribuidos en lugares geográfi- cos remotos entre sí, siempre y cuando la organización y sistematización de los datos responda a un conjunto organizado y uniformado de datos, sometido a algún tipo de gestión centralizada. 18

Obligaciones básicas La AEPD se ha pronunciado en este sentido a través de un informe jurídico4 emitido en respuesta a una consulta planteada por una entidad que disponía de diversos centros, ubicados en distintos lugares y carentes de personalidad jurídica propia, disponiendo de información sometida a tratamiento similar repartida en ficheros idénticos y alojada en servidores diferentes, dada su ubicación en los distintos centros, pero administrados y gestionados de forma centralizada. En relación con este tema, el RLOPD -artículo 56- viene a aclarar que: “la notificación de un fichero de datos de carácter personal es independiente del sistema de tratamiento empleado en su organización y del soporte o soportes empleados para el tratamiento de los datos” y que “cuando los datos de carácter personal objeto de tratamiento estén almacenados en diferentes soportes, automatizados y no automatizados, o exista una copia en soporte no automatizado de un fichero automatizado, sólo será preciso una sola notificación, referida a dicho fichero”. La creación de ficheros de datos de carácter personal. Lo primero que debemos pensar si deseamos crear un fichero que contenga datos personales, es que tenemos que enfrentarnos a un requisito, establecido en el artículo 25 de la LOPD, en virtud del cual es imprescindible que el fichero “resulte necesario para el logro de la actividad u objeto legítimos de la persona, empresa o entidad titular y se respeten las garantías que esta Ley establece para la protección de las personas”. Si bien, del respeto de las garantías establecidas en la LOPD iremos hablando a lo largo de todo este apartado, debemos analizar antes de seguir adelante el significado de la expresión “[...] resulte necesario para el logro de la actividad u objeto legítimos [...]”. Dicha “necesidad”, con frecuencia viene establecida o se deriva del cumplimiento de la legislación aplicable a la actividad u objeto desarrollados por el responsable, tanto en términos generales como fruto de alguna norma sectorial. De ahí que algunos ficheros resultan imprescindibles para el desarrollo de cualquier actividad u objeto legitimo (ya sea empresarial, comercial, profesional...) y otros resultan específicos de cada sector. Incluso, al margen de los ficheros creados por imposición, cualquier persona, empresa o entidad, puede sentir la necesidad de crear ficheros con distintas finalidades, pero para su creación siempre ha de haber una justificación directamente vinculada a la actividad u objeto legítimos, sin existir limitación alguna en relación con el número de ficheros inscribibles. En este orden de cosas, podemos poner como ejemplos más claros en los que se cumple este primer requisito para la creación de ficheros, aquellos en los que la necesidad de su creación es consecuencia directa del cumplimiento de una Norma que el titular debe aplicar para el desarrollo de su actividad u objeto legítimos, de lo que no cabe duda en ficheros como los que se describen a continuación: A. Los ficheros tradicionalmente denominados personal, empleados, gestión laboral..., permiten llevar a cabo la gestión laboral de la actividad desarro- 4. Vid. AEPD, Informe Jurídico 368/2003 Inscripción de ficheros situados en múltiples ubicacio-nes, https:// www.agpd.es/portalweb/canaldocumentacion/informes_juridicos/inscripcion_ficheros/common/pdfs/2003- 0368_Inscripci-oo-n-de-ficheros-situados-en-m-uu-ltiples-ubicaciones.pdf. 19

La protección de datos personales: Soluciones en entornos Microsoft llada por el responsable del fichero, así como un control detallado de las cuestiones relativas al personal laboral. En este sentido, la Ley 42/1997, de 14 de noviembre, Ordenadora de la Inspección de Trabajo y Seguridad Social, hace referencia a la conservación de información del personal laboral por parte del empleador, al disponer en su artículo 11 que “toda persona natural o jurídica estará obligada a proporcionar a la Inspección de Trabajo y Seguridad Social toda clase de datos, antecedentes o información con trascendencia en los cometidos inspectores, siempre que se deduzcan de sus relaciones económicas, profesionales, empresariales o financieras con terceros sujetos a la acción inspectora, cuando a ello sea requerida en forma”. B. Otros de los ficheros más habitualmente declarados por los responsables son los denominados gestión fiscal y contable, gestión económica, factura- ción... No cabe duda de la necesidad de estos ficheros para el logro de la actividad legítima de cualquier actividad económica. En este sentido, el artículo 142 de la Ley 58/2003, de 17 de diciembre, General Tributaria, que se expresa en los siguientes términos: “Las actuaciones inspectoras se realizarán mediante el examen de documentos, libros, contabilidad principal y auxiliar, ficheros, facturas, justificantes, correspondencia con trascendencia tributaria, bases de datos informatizadas, programas, registros y archivos informáticos relativos a actividades económi- cas, así como mediante la inspección de bienes, elementos, explotaciones y cualquier otro antecedente o información que debe de facilitarse a la Adminis- tración o que sea necesario para la exigencia de las obligaciones tributarias”, justifica la creación de dichos ficheros. C. Poniendo como ejemplo el sector sanitario, en el que los derechos a la intimidad y a la protección de datos tienen una relevancia especial, cualquier centro sanitario, desde las clínicas en las que un único profesional desarrolla su actividad de forma autónoma hasta los grandes hospita- les, tienen la obligación de disponer de un fichero con las historias clínicas de sus pacientes, cuya finalidad es la gestión de la prestación sanitaria prestada a los mismos. Fruto de la obligación de conservación de la documentación clínica, establecida en el artículo 17.1 de la Ley 41/2002, de 14 de noviembre, reguladora básica de la autonomía del paciente y de derechos y obligaciones en materia de información y documentación clínica, se especifica que: “los centros sanitarios tienen la obligación de conservar la documentación clínica en condiciones que garanticen su correcto mantenimiento y seguridad, aunque no necesariamente en el soporte original, para la debida asistencia al paciente durante el tiempo adecuado a cada caso y, como mínimo, cinco años contados desde la fecha del alta de cada proceso asistencial”. De lo anteriormente expuesto, podemos concluir que cualquiera de estos ficheros cumple con el requisito de necesariedad para el logro de la actividad u objeto legítimos de sus responsables. A pesar de que no siempre tiene que ser así, ni 20

Obligaciones básicas es la única justificación para que un fichero cumpla el requisito de necesariedad que venimos analizando, los más habituales surgen de la necesidad de cumplir con requisitos impuestos por diferentes legislaciones. No podemos olvidar que, fuera de estos supuestos, cualquier persona, empresa o entidad, puede necesitar crear ficheros con distintas finalidades, lo que no supondrá ningún problema siempre que exista una justificación directamente vinculada a su actividad u objeto legítimos. 4.1.1.1. Ficheros de titularidad privada Los ficheros de titularidad privada son definidos en el artículo 5.1.l) del RLOPD como aquellos de los que son responsables las personas, empresas o entidades de derecho privado, independientemente de quien ostente la titularidad de su capital o de la procedencia de sus recursos económicos, así como los ficheros de los que sean responsables las corporaciones de derecho público, pero no se encuentran estrictamente vinculados al ejercicio de potestades de derecho público atribuida por su normativa específica. Para la creación de estos ficheros hay que cumplir un procedimiento formal establecido en el artículo 27 de la LOPD, siguiendo los pasos que se describen a continuación: A. Notificación previa a la AEPD, cumplimentando los modelos o formularios electrónicos aprobados al efecto por la AEPD en resolución de 12 de julio de 2006 y publicados en el Boletín Oficial del Estado de 31 de julio 2006, en los que se detallará necesariamente la identificación del responsable del fichero, el nombre del fichero, sus finalidades y los usos previstos, el sistema de tratamiento empleado, el colectivo de personas sobre el que se obtienen los datos, el procedimiento y la procedencia de los datos, las categorías de datos, el servicio o unidad de acceso, la identificación del nivel de medidas de seguridad básico, medio o alto exigible y, en su caso la identificación del encargado de tratamiento donde se encuentre ubicado el fichero y los destinatarios de cesiones y transferencias internacionales de datos. Además, se declarará un domicilio a efectos de notificación. En función de lo establecido en el RLOPD, esta notificación podrá realizarse en diferentes soportes, tal y como se explica a continuación:  En soporte electrónico -mediante comunicación electrónica o en soporte informático-, utilizando el programa NOTA (Notificaciones Telemáticas a la Agencia) para la generación de notificaciones que la AEPD ha puesto a disposición de todos los ciudadanos.  En soporte papel, utilizando igualmente los modelos aprobados por la AEPD. Estos formularios se pueden obtener gratuitamente en la página web de la AEPD (www.agpd.es). B. Si la notificación se ajusta a los requisitos exigibles, el Director de la AEPD, a propuesta del Registro General de Protección de Datos (en adelante, RGPD), acordará la inscripción del fichero asignándole el correspondiente 21

La protección de datos personales: Soluciones en entornos Microsoft código de inscripción. En caso contrario, dictará resolución denegando la inscripción, debidamente motivada y con indicación expresa de las causas que impiden la inscripción. El art. 59.3 del RLOPD, introduce como novedad la posibilidad del Director de la AEPD de establecer procedimientos simplificados de notificación en atención a las circunstancias que concurran en el tratamiento o el tipo de fichero al que se refiere la notificación. La notificación de la creación de ficheros de datos de carácter personal ante la AEPD es una obligación que corresponde al responsable de los mismos, de manera que cuando se tenga previsto crear un fichero del que resulten responsables varias personas o entidades simultáneamente, cada una de ellas deberá notificar, a fin de proceder a su inscripción en el RGPD, la creación del correspondiente fichero. Además, esta obligación no conlleva coste económico alguno. Es importante destacar que la inscripción de los ficheros debe encontrarse actualizada en todo momento y es meramente declarativa, sin calificar que se estén cumpliendo las restantes obligaciones derivadas de la LOPD. Como consecuencia, que el RGPD acepte la inscripción de un fichero no conlleva, en ningún caso, un reconocimiento por parte de la AEPD de cumplimiento de ninguna otra obligación establecida en la normativa vigente en materia de protección de datos. Tal y como se expresa la propia AEPD en sus notificaciones: “La inscripción de un fichero en el Registro General de Protección de Datos, únicamente acredita que se ha cumplido con la obligación de notificación dispuesta en la Ley Orgánica 15/1999, sin que se esta inscripción se pueda desprender el cumplimiento por parte del responsable del fichero del resto de las obligaciones previstas en dicha Ley y demás disposiciones reglamentarias.” No por ello, debemos restar importancia al cumplimiento de la obligación de notificar los ficheros ya que permite dar publicidad de su existencia, poniendo a disposición de todos los ciudadanos, los ficheros en los que podrían encontrarse sus datos personales, facilitándoles de este modo el conocimiento de lo siguiente:  La totalidad de ficheros en los que podrían encontrarse sus datos personales.  La identificación del fichero, sus finalidades y los usos previstos, el sistema de tratamiento empleado, el colectivo de personas sobre el que se obtienen los datos, el procedimiento y procedencia de los datos, las categorías de datos, el servicio o unidad de acceso, la identificación del nivel de medidas de seguridad básico, medio o alto exigible y, en su caso, la identificación del encargado de tratamiento donde se encuentre ubicado el fichero y los destinatarios de cesiones y transferencias internacionales de datos.  Los responsables ante los que pueden ejercitar los derechos de acceso, rectificación, cancelación u oposición. Pero las ventajas de la inscripción registral no alcanzan únicamente a los ciudadanos, sino que se extienden tanto a la AEPD como a los propios responsables de los ficheros. 22

Obligaciones básicas En relación con la AEPD, podemos destacar que la inscripción de los ficheros le permite disponer de una relación actualizada de los ficheros inscritos, facilitándole:  el cumplimiento de la obligación de velar por la publicidad de la existencia de los ficheros de datos con carácter personal5,  el conocimiento de todos los ficheros que deben cumplir con las obligaciones establecidas en la LOPD y su normativa de desarrollo,  el ejercicio de las actividades que la normativa le encomienda como Autoridad de Control y  el ejercicio del derecho de consulta de los ciudadanos. Desde la perspectiva del responsable de los ficheros, podemos apreciar las siguientes ventajas respecto de la inscripción de ficheros en el RGPD:  Evitar la imposición de sanciones.  Mostrar el compromiso o la intención de cumplir con la normativa de protección de datos.  Facilitar a los titulares de los datos contenidos en sus ficheros el ejercicio de los derechos de acceso, rectificación, cancelación y oposición. Como resumen de lo expuesto hasta el momento, podemos hacernos eco de los principios que rigen la inscripción de ficheros, recogidos en la Memoria de la AEPD del año 2000:  El responsable del fichero deberá efectuar una notificación de un tratamiento o de un conjunto de tratamientos.  La inscripción de un fichero de datos no prejuzga que se hayan cumplido el resto de las obligaciones derivadas de la Ley.  La notificación de ficheros implica el compromiso por parte del responsable de que el tratamiento de datos personales declarados para su inscrip- ción cumple con todas las exigencias legales.  La notificación de los ficheros al Registro supone una obligación de los responsables del tratamiento, sin coste económico alguno para ellos, y facilita que las personas afectadas puedan conocer quiénes son los titulares de los ficheros ante los que deben ejercitar directamente los derechos de acceso, rectificación, cancelación y oposición.  Toda persona o entidad que proceda a la creación de ficheros de datos de carácter personal lo notificará previamente a la AEPD.  En la notificación deberán figurar necesariamente el responsable del fichero, la finalidad del mismo, las medidas de seguridad, con indicación del nivel básico, medio o alto exigible y las cesiones de datos de carácter 5. Artículo 37.1. j) LOPD. 23

La protección de datos personales: Soluciones en entornos Microsoft personal que se prevean realizar y, en su caso, las transferencias de datos que se prevean a países terceros.  Deberá comunicarse a la APD cualquier cambio que se produzca con respecto a la declaración inicial y particularmente en la finalidad del fichero, en su responsable y en la dirección de su ubicación.  El RGPD inscribirá el fichero si la notificación se ajusta a los requisitos exigibles. En caso contrario podrá pedir que se completen los datos que falten o se proceda a su subsanación.  Transcurrido un mes desde la presentación de la solicitud de inscripción sin que la AEPD hubiera resuelto sobre la misma, se entenderá inscrito el fichero a todos los efectos. ¿Deben inscribirse los ficheros temporales? El RLOPD recoge la primera definición legal de ficheros temporales en su artículo 5.2.g). En virtud de esta se entienden como tales los “ficheros de trabajo creados por usuarios o procesos que son necesarios para un tratamiento ocasional o como paso intermedio durante la realización de un tratamiento”. Estos ficheros no tienen que inscribirse, pero sí tiene que estar inscrito el fichero de origen. En este sentido se ha pronunciado la AEPD 6, facilitando además algunos ejemplos: “Ej. si se crea un fichero temporal para organizar las vacaciones del personal a partir del fichero de recursos humanos, tendrá que estar inscrito el fichero de recursos humanos. Respecto del fichero de vacaciones tendrán que adoptarse las medidas de seguridad correspondientes. Un fichero creado para realizar tratamientos de datos periódicos, SI que tendrá que inscribirse. Ej. censo agrario, preinscripción anual en un polideportivo, ….”7. 4.1.1.2. Ficheros de titularidad pública Los ficheros de titularidad pública son definidos en el artículo 5.1.m) del RLOPD como “los ficheros de los que sean responsables los órganos constitucionales o con relevancia constitucional del Estado o las instituciones autonómicas con funciones análogas a los mismos, las Administraciones públicas territoriales, así como las entidades u organismos vinculados o dependientes de las mismas y las Corporaciones de derecho público siempre que su finalidad sea el ejercicio de potestades de derecho público”, como por ejemplo los colegios profesionales. 6. Vid. AEPD, I Sesión Anual Abierta de la AEPD “El nuevo reglamento de desarrollo de la ley orgánica de protección de datos: problemática, interpretación y aplicación”, Madrid, 22 de abril de 2008. https://www.agpd.es/portalweb/jornadas/1_sesion_abierta/common/faqs_bloque_2.pdf. 7. Véase nota número 6 anterior. 24

Obligaciones básicas En relación con estos ficheros hay que tener en cuenta las disposiciones sectoriales establecidas por la LOPD. Con base en las mismas, podemos afirmar que la creación de los ficheros de las Administraciones Públicas sólo podrá hacerse por medio de disposición general publicada en el Boletín Oficial del Estado o diario oficial correspondiente -artículo 22 LOPD-. Dicha disposición deberá indicar:  La finalidad del fichero y los usos previstos para el mismo.  Las personas o colectivos sobre los que se pretenda obtener datos de carácter personal o que resulten obligados a suministrarlos.  El procedimiento de recogida de los datos de carácter personal.  La estructura básica del fichero y la descripción de los tipos de datos de carácter personal incluidos en el mismo.  Las cesiones de datos de carácter personal y, en su caso, las transferencias de datos que se prevean a países terceros.  Los órganos de las Administraciones responsables del fichero.  Los servicios o unidades ante los que pudiesen ejercitarse los derechos de acceso, rectificación, cancelación y oposición.  Las medidas de seguridad con indicación del nivel básico, medio o alto exigible. El artículo 55 del RLOPD, establece un plazo de treinta días desde la publica- ción de su norma o acuerdo de creación en el diario oficial correspondiente, para que todo fichero de datos de titularidad pública sea notificado a la AEPD para su inscripción en el RGPD. Cuando la actividad relacionada con la finalidad del fichero no pueda ser considerada como “pública” en sentido estricto, este se considerará privado, como por ejemplo el fichero de formación de un colegio profesional, cuya finalidad es dar formación a los colegiados o terceras personas. 4.1.2. La calidad de los datos El principio de calidad de los datos, establecido en el artículo 4 de la LOPD, regirá el tratamiento de los datos de carácter personal en todas sus fases, desde el momento previo a la recogida de los mismos hasta que se cesa en su tratamiento. Con carácter previo a la recogida de los datos el responsable del fichero o tratamiento debe tener en cuenta que, únicamente, podrá recogerlos para su tratamiento, así como someterlos al mismo, cuando sean adecuados, pertinentes y no excesivos en relación con el ámbito y las finalidades determinadas, explícitas y legítimas de su obtención, estando prohibida su recogida por medios fraudulentos, desleales o ilícitos. El artículo 8 del RLOPD desarrolla los principios relativos a la calidad de los datos. En concreto, en relación con el momento previo al tratamiento de los datos podemos destacar los principios de lealtad y licitud y finalidad. En relación con 25

La protección de datos personales: Soluciones en entornos Microsoft estos, no añade nada a lo ya dispuesto en la LOPD, recordando la prohibición de recoger datos por medios fraudulentos, desleales o ilícitos, así como la única circunstancia que legitima su recogida, es decir, el cumplimiento de finalidades determinadas, explícitas y legítimas del responsable del tratamiento. 4.1.3. La información al interesado El artículo 5 de la LOPD establece uno de los principios fundamentales que, junto al consentimiento, regirá el tratamiento de los datos de carácter personal: “Derecho de información en la recogida de datos”. El derecho establecido en este principio a favor de los titulares de los datos se convierte en una obligación para los responsables de los ficheros, en virtud de la cual tiene que informar al interesado, con carácter previo a la recogida de sus datos de carácter personal sobre algunos aspectos relacionados con el tratamiento de los datos, de manera que el interesado pueda tener la suficiente información como para consentir el tratamiento de forma consciente y libre. El legislador ha considerado, con buen criterio, que para ello es necesario conocer:  La existencia de un fichero o tratamiento de datos de carácter personal.  La finalidad de la recogida de los datos.  Los destinatarios de la información.  El carácter obligatorio o facultativo de la respuesta a las preguntas planteadas a los titulares de los datos.  Las consecuencias de la obtención de los datos o la negativa a suministrarlos.  La posibilidad de ejercitar los derechos de acceso, rectificación, cancela- ción y oposición.  La identidad y dirección del responsable del tratamiento o, en su caso, de su representante. Debemos plantearnos que no siempre los datos son recabados del propio titular o interesado, de manera que analizaremos a continuación las vías más habituales a través de las cuales se obtienen datos personales para insertarlos en un fichero. Del propio interesado Cuando los datos son recabados de sus titulares, habrá que facilitar directamente a los mismos la información detallada anteriormente. De terceros Cuando los datos hayan sido facilitados por persona distinta al titular de los mismos, el responsable del fichero dispone de un plazo de tres meses desde el momento del registro de los datos para facilitarle la información que le permita consentir el tratamiento de sus datos de forma libre y consciente. Como consecuencia, tendrá que informarle del contenido del tratamiento, la procedencia de los 26

Obligaciones básicas datos, la existencia de un fichero o tratamiento, la finalidad para la que se han recabado los datos, los destinatarios de la información, la posibilidad de ejercitar los derechos de acceso, rectificación y oposición, así como de la identidad y dirección del responsable del tratamiento o su representante. La propia LOPD estable excepciones a esta obligación, afirmando que no será de aplicación cuando: A. El interesado ya hubiera sido informado con anterioridad. B. Una Ley lo prevea expresamente. Es preciso aclarar esta excepción, ya que, en ocasiones nos encontramos con previsiones normativas que no tienen rango de Ley en las que se prevé el tratamien- to o cesión de datos de carácter personal o preceptos legales en los que la excepción del deber de informar no es fruto de la interpretación literal del artículo, ya que no se recoge expresamente. Para la correcta aplicación de esta excepción han de darse dos requisitos: que la norma en la que se prevé el tratamiento o la cesión de datos tenga rango de Ley y, además, que dicho tratamiento o cesión haya sido recogido por el legislador de forma expresa. Así se desprende de un Informe emitido por la AEPD en el año 20048, en el que concluye que la excepción del artí-culo 5.5 a la que venimos haciendo referencia será aplicable a supuestos “en que el tratamiento o cesión de los datos de carácter personal aparece recogido expresamente en una norma con rango de Ley, pero no a aquellos supuestos en que la Ley “autorice” o “habilite” la cesión de datos, pero no la recoja de modo expreso y taxativo en su articulado, sin perjuicio de que en dichos supuestos la cesión se encontrará amparada por lo dispuestos en los artículos 6.2 u 11.2 a) de la Ley Orgánica 15/1999” 9. C. El tratamiento tenga fines históricos, estadísticos o científicos. D. La información al interesado resulte imposible o exija esfuerzos desproporcionados, a criterio de la AEPD o del organismo autonómico equivalente, en consideración al número de interesados, a la antigüedad de los datos y a las posibles medidas compensatorias. Esta excepción sólo será posible a través de un acto administrativo de la AEPD en que se decida acerca de la procedencia o improcedencia de la excepción alegada en cada caso concreto. Dicho acto implicará la tramita- 8. Vid. AEPD, Informe Jurídico 60/2004 Exención del deber de informar cuando el tratamiento o la cesión están expresamente previstos en una Ley, https://212.170.242.196/portalweb/canaldocumentacion/ informes_juridicos/deber_informacion/common/pdfs/2004-0060_Exenci-oo-n-del-deber-de-informar- cuando-el-tratamiento-o-la-cesi-oo-n-est-aa-n-expresamente-previstos-en-una-Ley.pdf. 9. En el mismo sentido se pronunció la AEPD en una resolución de 8 de octubre de 2004: “El artículo 5.5. también exceptúa de la obligación de informar cuando expresamente una Ley lo Prevea. De la interpretación literal del artículo resultaría que la obligación de informar debe estar expresamente exceptuada en una Ley para que se cumplan las condiciones previstas en este supuesto. Sin embargo la Directiva 95/46/CE, que ha sido traspuesta por la Ley 15/1999, en su artículo 11.2 especifica que no existe el deber de informar en particular para el tratamiento con fines estadísticos o de investigación histórica o científica, cuando la información al interesado resulte imposible o exija esfuerzos desproporcionados o el registro o la comunicación a un tercero estén expresamente previstos por ley, por lo que ha de interpretarse este supuesto de exclusión en los términos previstos en la Directiva, quedando excluida la obligación de informar cuando la cesión esté expresamente prevista en una Ley”. 27

La protección de datos personales: Soluciones en entornos Microsoft ción del correspondiente procedimiento administrativo, iniciado en todo caso por la propia solicitud del interesado10. De fuentes de acceso público Quizás convenga empezar preguntándose qué son fuentes de acceso público. Estas se encuentran definidas en el artículo 3.j) de la LOPD como aquellos ficheros cuya consulta puede ser realizada por cualquier persona, no impedida por una norma limitativa o sin más exigencia que, en su caso, el abono de una contraprestación. Son, exclusivamente:  El censo promocional.  Las guías de teléfonos.  Las listas de colegios profesionales que contengan únicamente los datos de nombre, título, profesión, actividad, grado académico, dirección profesional e indicación de su pertenencia al grupo. El RLOPD, en su artículo 7 determina el alcance de las siguientes expresiones:  Dirección profesional: podrá incluir los datos del domicilio postal completo, número telefónico, número de fax y dirección electrónica.  Datos de pertenencia al grupo: considera como tales los de número de colegiado, fecha de incorporación y situación de ejercicio profesional.  Los diarios y boletines oficiales.  Los medios de comunicación social. Ha planteado muchas dudas si Internet es una fuente de acceso público. Con base en la definición, únicamente, podríamos considerarlo como tal si se encontrara incluido dentro de los medios de comunicación, pero a día de hoy los únicos medios de comunicación legalmente reconocidos son la prensa, la radio y la televisión. Co- mo consecuencia de ello, podemos afirmar que Internet, como tal, no es una fuente de acceso público. No obstante, a través de Internet podemos acceder a fuentes de acceso público. Por ejemplo, la lista de los profesionales pertenecientes a un colegio profesional no dejará de ser fuente de acceso público si accedemos a los datos a través de la página web del mismo. La AEPD ha confirmado esta interpretación, afirmando que “Internet no es, a los efectos de protección de datos un “medio de comunica- ción social”, sino un “canal de comunicación”, por lo que no es fuente accesible al público”11. Cuando los datos recabados en un fichero proceden de estas fuentes, el responsable tiene que informar al interesado de la procedencia de sus datos, la identidad y dirección del responsable del fichero o tratamiento y de la posibilidad de ejercitar 10. Vid. AEPD, Informe Jurídico2002-0000 Procedimiento para la exención del deber de informar, https:// 212.170.242.196/portalweb/canaldocumentacion/informes_juridicos/deber_informacion/common/pdfs/ 2002-0000_Procedimiento-para-la-exenci-oo-n-del-deber-de-informar.pdf. 11. Vid. AEPD, I Sesión Anual Abierta de la AEPD “El nuevo reglamento de desarrollo de la ley orgánica de protección de datos: problemática, interpretación y aplicación”, Madrid, 22 de abril de 2008, https:// www.agpd.es/portalweb/jornadas/1_sesion_abierta/common/faqs_bloque_1.pdf. 28

Obligaciones básicas sus derechos de acceso, rectificación, cancelación y oposición. Información que acompañará cada comunicación que el responsable le realice. En relación con el censo promocional o las listas de personas pertenecientes a grupos de profesionales, establece la LOPD (artículo 28) la limitación de incluir en dichas fuentes los datos estrictamente necesarios para cumplir la finalidad a que se destina cada listado, de manera que la inclusión de datos adicionales por las entidades responsables del mantenimiento de las mismas requerirá el consentimiento del interesado, que podrá ser revocado en cualquier momento. Además, la LOPD establece los siguientes derechos a favor de los interesados:  Respecto de los datos que consten en el censo promocional, a exigir gratuitamente la exclusión de la totalidad de los mismos por las entidades encargadas de su mantenimiento.  En relación con los listados de los colegios profesionales, a que la entidad responsable de su mantenimiento indique gratuitamente que sus datos personales no podrán ser utilizados para fines de publicidad o prospección comercial. La atención a la solicitud de exclusión de la información innecesaria o de inclusión de la objeción al uso de los datos para fines de publicidad o venta a distancia deberá realizarse en el plazo de diez días respecto de las informaciones que se realicen mediante consulta o comunicación telemática y en la siguiente edición del listado cualquiera que sea el soporte en que se edite. Las fuentes de acceso público que se editen en forma de libro o algún otro soporte físico, perderán el carácter de fuente accesible con la nueva edición que se publique y, en el caso de que se obtenga telemáticamente una copia de la lista en formato electróni- co, en el plazo de un año, contado desde el momento de su obtención. Una vez tratada la información que debemos facilitar al titular de los datos en los supuestos más habituales de recogida de los mismos, podemos avanzar un poco más profundizando de forma muy somera pero clarificadora los extremos que, por resultar menos precisos o haber sido expresados de una forma muy genérica por el legislador, pueden dar lugar a dudas o interpretaciones erróneas. En principio, parece que no tiene porqué generar problema alguno informar acerca de la identidad y dirección del responsable del tratamiento o su representante, la existencia de un fichero o tratamiento de datos de carácter personal, el carácter obligatorio o facultativo de la respuesta a las preguntas planteadas por el titular de los datos, las consecuencias de la obtención de los datos o la negativa a suministrarlos o la posibilidad de ejercitar los derechos de acceso, rectificación, cancelación u oposición. Por el contrario, consideramos oportuno desarrollar las siguientes expresiones en aras a aportar una mayor claridad en relación con la intención del legislador. La finalidad de la recogida de los datos Cuando el responsable de un fichero recaba datos para una finalidad específi- ca, seguramente no le plantee ningún problema informar sobre la misma. No 29

La protección de datos personales: Soluciones en entornos Microsoft obstante, en la vida comercial, empresarial o profesional, no son pocos los casos en los que resulta muy importante para el responsable del fichero el uso de los datos para finalidades que exceden de una finalidad específica y fácil de definir. Desde que se ha establecido la relación inicial con el titular de los datos, lo más habitual y con tendencia ascendente, es que el responsable del fichero desee utilizar los datos con finalidades diferentes a la inicial. Entre las más comunes se encuentran la fidelización de clientes -basada en acciones como el envío de felicitaciones en fechas tan señaladas como Navidad, Año Nuevo o cumpleaños-, ofrecer otros productos o servicios que puedan resultar de interés -a través de campañas comerciales-, valorar la calidad de los productos o servicios prestados -utilizando encuestas de calidad o satisfacción-, enviar revistas informativas destinadas a lectores con un perfil predeterminado y hacer estudios de mercado de los gustos de los clientes. Para el uso de los datos facilitados inicialmente con todas estas finalidades, lo que permitiría al responsable del fichero sacar un mayor aprovechamiento del mismo, traducido normalmente en un mayor beneficio económico, resulta imprescindible haber informado correctamente. Es a la hora de informar del uso de los datos para todas estas finalidades cuando el responsable del fichero puede encontrarse con problemas, principalmente, que el interesado se niegue a facilitar sus datos. La experiencia nos ha aportado soluciones prácticas para solventar este problema, basadas en el redacción de cláusulas que, sin saltar las fronteras de lo legítimo, nos permiten ampliar y generalizar la finalidad para la que se recaban los datos. Los destinatarios de la información A medida que evoluciona la industria, el comercio e, incluso, la prestación de servicios por los profesionales, se extiende la colaboración con diversas personas, empresas o entidades en el desarrollo de un objeto social o actividad legítima, fruto de la necesidad de recurrir a personas o empresas especializadas para cubrir carencias propias o abordar proyectos de mayor envergadura a la que una sola compañía puede hacer frente. En numerosas ocasiones, estas colaboraciones llevan implícita la necesidad de facilitar datos de carácter personal que constan en un fichero propio. Si la LOPD no obligara a informar previamente al titular de los datos de los destinatarios de los mismos, correríamos el grave riesgo de que esto se convirtiera en una cadena de cesiones desconocidas para el afectado, rompiéndose de este modo su posibilidad de decisión acerca del tratamiento de sus datos personales, quebrando el derecho a la protección de los mismos. El ejemplo más claro en el que se producen constantemente este tipo de cesiones es entre las empresas pertenecientes a un mismo grupo. No obstante, tal y como ha ocurrido con la finalidad de la recogida de los datos, en la práctica se han desarrollado soluciones que permiten que no resulte necesario dar una información detallada de cada destinatario de los datos que puede llegar a intervenir en el tratamiento de los mismos -nombre o razón social-, resultando suficiente informar acerca de la categoría de los destinatarios de la información y la finalidad de las cesiones. 30

Obligaciones básicas Esta posibilidad se ha visto reforzado por el RLOPD, en el que el legislador ha manifestado de forma expresa que: “Cuando se solicite el consentimiento del afectado para la cesión de sus datos, éste deberá ser informado de forma que conozca inequívocamente la finalidad a la que se destinarán los datos respecto de cuya comunicación se solicita el consentimiento y el tipo de actividad desarrollada por el cesionario. En caso contrario, el consentimiento será nulo”12. Forma que se debe adoptar para facilitar la información y acreditación del cumplimiento del deber de informar La LOPD no impone a los responsables de ficheros o tratamientos forma alguna para facilitar al titular de los datos la información necesaria para el tratamiento de los mismos. Lo más habitual y sencillo, a priori, es utilizar el mismo medio que se utiliza para la recogida de los datos también para facilitar la información. Si nos traslada- mos a la práctica podemos afirmar que los sistemas de recogida de datos utilizados más frecuentemente son:  Oralmente. En principio, teniendo en cuenta que la LOPD no impone a los responsables de ficheros o tratamientos forma alguna para informar al titular de los datos, sería suficiente con prestarlo de forma oral. Una alternativa es la colocación de carteles informativos en un lugar visible para las personas que facilitan los datos.  A través de formularios. El artículo 5.2 de la LOPD establece expresamente que cuando se usen formularios o impresos para la recogida, figurará en los mismos la información necesaria, en forma claramente legible.  Contratos. Si el titular de los datos firma un contrato se debe incluir en el mismo la información relativa al tratamiento de sus datos.  Telefónicamente. Podría proporcionarse la información por el mismo medio, pero otra alternativa es enviar una comunicación posterior, aprovechando por ejemplo la entrega del producto adquirido por teléfono. En la práctica, se venía recomendando adoptar siempre medios que permitan disponer de una prueba del cumplimiento de dicha obligación con fundamento en un Informe jurídico de la AEPD13. De este modo, a efectos de la Ley, será necesario que el responsable del tratamiento acredite la realización del envío, lo que sería posible tanto en el caso de que el envío se realice por el propio consultante como en caso de que el mismo se encomiende a una tercera empresa, que se certifique de algún modo la efectiva realización de los envíos, y exista un principio de prueba de que el envío efectiva- 12. Art. 12.2 RLOPD. 13. Vid. AEPD, Informe Jurídico 0111/2005 Prueba en relación con el cumplimiento del deber de información, https://www.agpd.es/portalweb/canaldocumentacion/informes_juridicos/deber_informacion/ index-ides-idphp.php. 31

La protección de datos personales: Soluciones en entornos Microsoft mente realizado ha llegado a su destino, lo que podría conseguirse, por ejemplo, mediante el acceso a las listas de devoluciones del servicio de correos. El RLOPD -artículo 18- ha regulado de forma novedosa la acreditación del deber de informar, estableciendo el deber de utilizar un medio que permita acreditar su cumplimiento, debiendo conservarse mientras persista el tratamiento de los datos del afectado. Asimismo, el responsable deberá conservar el soporte en el que conste el cumplimiento del deber de informar, pudiendo utilizar medios informá- ticos o telemáticos para el almacenamiento de los soportes. Añade el legislador que, “en particular podrá proceder al escaneado de la documentación en soporte papel, siempre y cuando se garantice que en dicha automatización no ha mediado alteración alguna de los soportes originales”. La información dirigida a los menores de edad Cuando el tratamiento se refiera a datos de menores de edad, la información dirigida a los mismos deberá expresarse en un lenguaje que sea fácilmente comprensible por aquellos. Supuestos especiales El artículo 19 del RLOPD ha introducido como novedad lo siguiente: “En los supuestos en que se produzca una modificación del responsable del fichero como consecuencia de una operación de fusión, escisión, cesión global de activos y pasivos, aportación o transmisión de negocio o rama de actividad empresarial, o cualquier operación de reestructuración societaria de análoga naturaleza, contemplada por la normativa mercantil, no se producirá cesión de datos, sin perjuicio del cumplimiento por el responsable de lo dispuesto en el artículo 5 de la Ley Orgánica 15/1999, de 13 de diciembre”. Consecuencia de ello, podemos afirmar que en los supuestos indicados en el precepto trascrito, habrá que informar al titular de los datos de los nuevos destinatarios de la información, adquiriendo también especial importancia la información relativa a la finalidad, dado que en principio, el tratamiento debe limitarse a la finalidad para la que se consintió inicialmente y ésta sólo podrá ampliarse en el caso de que se facilite la información acerca de nuevas finalidades y el afectado consienta el tratamiento de sus datos para las mismas. 4.1.4. El consentimiento del interesado El principio del consentimiento del interesado, establecido en el artículo 6 de la LOPD, constituye una de las obligaciones principales en materia de protección de datos. Como norma general, el tratamiento de los datos de carácter personal reque- rirá el consentimiento inequívoco del afectado. Antes de seguir adelante, resulta conveniente detenerse en la definición de consentimiento del interesado, recogida en el artículo 3.K) de la LOPD: “toda manifestación de voluntad libre, inequívoca, específica e informada, mediante la que el interesado consienta el tratamiento de datos 32

Obligaciones básicas personales que le conciernen” y analizar el significado de libre, inequívoco, específico e informado. Para ello, nada mejor que recurrir a la interpretación de la AEPD, expresada en un Informe jurídico emitido en el año 200014.  Libre. Supone que el mismo deberá haber sido obtenido sin la interven- ción de vicio alguno del consentimiento en los términos regulados por el Código Civil.  Específico. Referido a una determinada operación de tratamiento y para una finalidad determinada, explícita y legítima del responsable del tratamiento.  Inequívoco. Implica que no resulta admisible deducir el consentimiento de los meros actos realizados por el afectado (consentimiento presunto), siendo preciso que exista expresamente una acción u omisión que implique la existencia del consentimiento.  Informado. Requiere que el afectado conozca con anterioridad al tratamiento la existencia del mismo y las finalidades para las que el mismo se produce. Precisamente por ello, el artículo 5.1 de la LOPD impone el deber de informar a los interesados de una serie de extremos que en el mismo se contienen. De este modo, el consentimiento se encuentra ínti- mamente relacionado con la información para la recogida de los datos, ya que para que se cumplan los requisitos del mismo el responsable del fichero o tratamiento debe informar previa y correctamente al titular de los datos de la existencia del fichero o tratamiento y de las finalidades para las que se destinarán los datos. Como consecuencia de ello, la solicitud de consentimiento debe referirse a un tratamiento o serie de tratamientos concretos, con delimitación de la finalidad para la que se recaban los datos y las restantes condiciones que concurran en el tratamiento o serie de tratamientos. Así lo ha recogido el RLOPD en su artículo 12.1. No obstante, la propia LOPD establece excepciones a la obligación de obtener el consentimiento para el tratamiento de los datos de carácter personal, en concreto: A. Que la Ley disponga otra cosa. B. Que los datos de carácter personal se recojan para el ejercicio de las funciones propias de las Administraciones Públicas en el ámbito de sus competencias. C. Que los datos se refieran a las partes de un contrato o precontrato de una relación negocial, laboral o administrativa y sean necesarios para su mantenimiento o cumplimiento. D. Que el tratamiento de los datos tenga por finalidad proteger un interés vital del interesado, cuando dicho tratamiento resulte necesario para la prevención o el diagnóstico médicos, la prestación de asistencia sanitaria 14. Vid. AEPD, Informe Jurídico 2000-0000 Caracteres del consentimiento definido por la LOPD, https:// www.agpd.es/portalweb/canaldocumentacion/informes_juridicos/consentimiento/index-ides-idphp.php. 33

La protección de datos personales: Soluciones en entornos Microsoft o tratamientos médicos o la gestión de servicios sanitarios, siempre que dicho tratamiento de datos se realice por un profesional sanitario sujeto al secreto profesional o por otra persona sujeta asimismo a una obligación equivalente de secreto. E. Que los datos figuren en fuentes accesibles al público y su tratamiento sea necesario para la satisfacción del interés legítimo perseguido por el responsable del fichero o por el del tercero a quien se comuniquen los datos, siempre que no se vulneren los derechos y libertades fundamentales del interesado. En estos casos, en los que no sea necesario el consentimiento del afectado para el tratamiento de los datos de carácter personal y, siempre que una Ley no disponga lo contrario, la LOPD concede al mismo la posibilidad de oponerse a su tratamiento cuando existan motivos fundados y legítimos relativos a una concreta situación personal. Revocación del consentimiento El derecho del titular de los datos a revocar el consentimiento prestado para el tratamiento de sus datos ha sido reconocido por el legislador en la LOPD, a través de los artículos 6.3, en el que se recoge expresamente este derecho15 y 16.1, en el que se establece la obligación para el responsable del tratamiento de hacer efectivo el derecho del titular de los datos a que sean cancelados, lo que conlleva la imposibilidad para el responsable de continuar en el tratamiento consentido anteriormente. Asimismo, en el artículo 11.4 se reconoce expresamente el derecho del titular de los datos a revocar el consentimiento prestado para la cesión de los mismos 16. El RLOPD -artículo 17- ha desarrollado la revocación del consentimiento en relación con la forma de llevarlo a cabo, estableciendo la posibilidad de realizarlo a través de un medio sencillo, gratuito y que no implique ingreso alguno para el responsable del fichero o tratamiento. En concreto, reconoce como medios adecuados un envío franqueado al responsable del tratamiento o, incluso, la llamada a un número de teléfono gratuito o a los servicios de atención al público establecidos por el mismo. Por el contrario, no se considerarán conformes a lo dispuesto en la LOPD, los supuestos en que el responsable establezca como medio para que el interesado pueda manifestar su negativa al tratamiento el envío de cartas certificadas o envíos semejantes, la utilización de servicios de telecomunicaciones que implique una tarificación adicional al afectado o cualesquiera otros medios que impliquen un coste adicional al interesado. Las consecuencias que implica la revocación del consentimiento para el responsable del tratamiento se detallan a continuación: 15. Art. 6.3 de la LOPD: “El consentimiento a que se refiere el artículo podrá ser revocado cuando exista causa justificada para ello y no se le atribuyan efectos retroactivos”. 16. Art. 11.4 de la LOPD: “El consentimiento para la comunicación de los datos de carácter personal tiene también un carácter revocable”. 34

Obligaciones básicas  Cesar en el tratamiento de los datos del interesado en un plazo máximo de diez días a contar desde la fecha de la recepción de la revocación.  Si el interesado hubiera solicitado la confirmación del cese en el tratamien- to de sus datos, deberá responder expresamente a la solicitud.  Si los datos hubieran sido cedidos previamente, deberá comunicar la revocación del consentimiento a los cesionarios, en el plazo indicado en el punto anterior, para que éstos cesen en el tratamiento de los datos en caso de que aún lo mantuvieran. Forma de prestar el consentimiento Teniendo en cuenta que la LOPD establece la necesidad de manifestar el consentimiento de forma expresa y por escrito, únicamente, para el tratamiento de algunos tipos de datos, podemos afirmar que, como norma general, admite el consentimiento tácito. Dentro del consentimiento inequívoco que exige para el tratamiento de los datos de carácter personal, distingue tres categorías de consentimiento en función de los datos objeto de tratamiento:  Tácito. Suficiente para el tratamiento de todos los datos, salvo los especialmente protegidos -ideología, afiliación sindical, religión, creencias, origen racial, salud y vida sexual-. En este sentido se ha pronunciado la AEPD en un informe jurídico recien- te17 afirmando que: “El consentimiento, salvo cuando el tratamiento se refiera a los datos especialmente protegidos, regulados por el artículo 7 de la Ley Orgánica, podrá obtenerse de forma expresa o tácita, es decir, tanto como consecuencia de una afirmación específica del afectado en ese sentido, como mediante la falta de una manifestación contraria al tratamiento, para la que se hayan concedido mecanismos de fácil adopción por el afectado y un tiempo prudencial para dar la mencionada respuesta negativa”.  Expreso. En función de lo establecido en el artículo 7.2 de la LOPD, los datos de carácter personal que revelan la ideología, afiliación sindical, religión y creencias del afectado sólo podrán ser tratados con su consentimiento expreso y por escrito, salvo en los casos de ficheros mantenidos por los partidos políticos, sindicatos, iglesias, confesiones o comunidades religiosas y asociaciones, fundaciones y otras entidades sin ánimo de lucro, cuya finalidad sea política, filosófica, religiosa o sindical, en cuanto a los datos relativos a sus asociados o miembros.  Expreso y por escrito. Los datos de carácter personal que hagan referencia al origen racial, a la salud y a la vida sexual sólo podrán ser recabados, 17. Vid. AEPD, Informe Jurídico 93/2008 Formas de obtener el consentimiento mediante web: Consentimientos tácitos, https://www.agpd.es/portalweb/canaldocumentacion/informes_juridicos/ consentimiento/index-ides-idphp.php. 35

La protección de datos personales: Soluciones en entornos Microsoft tratados y cedidos cuando, por razones de interés general, así lo disponga una Ley o el afectado consienta expresamente. Así se desprende del artículo 7.2 de la LOPD. Teniendo en cuenta que corresponde al responsable del tratamiento la prueba de la existencia del consentimiento del titular de los datos para su tratamiento, por cualquier medio de prueba admisible en derecho, a pesar de no resultar necesario, lo más recomendable es disponer del consentimiento expreso y por escrito. El responsable del tratamiento podrá solicitar el consentimiento del interesado para el tratamiento de sus datos de carácter personal a través del procedimiento establecido en el artículo 14 del RLOPD, salvo cuando la Ley exija al mismo la obtención del consentimiento expreso para el tratamiento de los datos, en virtud del cual, una vez que el responsable ha informado al afectado, deberá concederle un plazo de treinta días para manifestar su negativa al tratamiento, advirtiéndole de que en caso de no pronunciarse a tal efecto se entenderá que consiente el tratamien- to de sus datos de carácter personal. En concreto, cuando se trate de responsables que presten al afectado un servicio que genere información periódica o reiterada, o facturación periódica, la comunicación podrá llevarse a cabo de forma conjunta a esta información o a la facturación del servicio prestado, siempre que se realice de forma claramente visible. En todo caso, será necesario que el responsable del tratamiento pueda conocer si la comunicación ha sido objeto de devolución por cualquier causa, en cuyo caso no podrá proceder al tratamiento de los datos referidos a ese interesado. Finalmente, el RLOPD establece que cuando se solicite el consentimiento del interesado a través de este procedimiento, no será posible solicitarlo nuevamente respecto de los mismos tratamientos y para las mismas finalidades en el plazo de un año a contar desde la fecha de la anterior solicitud. Consentimiento para el tratamiento de los datos de menores de edad Una novedad importante del RLOPD es la regulación del consentimiento para el tratamiento de los datos de menores de edad -ya que nada se regula al respecto en la LOPD-, estableciendo la edad de catorce años para poder consentir en el tratamiento de los datos de carácter personal, salvo en aquellos casos en los que la Ley exija para su prestación la asistencia de los titulares de la patria potestad o tutela. En el caso de los menores de catorce años se requerirá el consentimiento de los padres o tutores. No obstante, se establece una limitación para el responsable del fichero o tratamiento en relación con los datos que se pueden obtener del menor, ya que en ningún caso podrán recabarse a través de este datos que permitan obtener informa- ción sobre los demás miembros del grupo familiar o las características del mismo, como los datos relativos a la actividad profesional de los progenitores, información económica, datos sociológicos o cualesquiera otros, sin el consentimiento de los titulares de tales datos. Únicamente podrán recabarse los datos de identidad y dirección del padre, madre o tutor con la única finalidad de recabar la autorización de los mismos para el tratamiento de los datos. 36

Obligaciones básicas Finalmente, se impone al responsable del fichero o tratamiento la obligación de articular los procedimientos que garanticen que se ha comprobado de modo efectivo la edad del menor y la autenticidad del consentimiento prestado en su caso, por los padres, tutores o representantes legales. En algunos supuestos, como el de ob- tención de los datos a través de una página web, parece difícil articular un sistema que permita al responsable disponer de esta garantía. Para este caso concreto la AEPD ha propuesto y admitido como válida la opción de poner una casilla en la que se deba indicar la edad en la que resulte imposible introducir una fecha más antigua a dieciocho años desde la fecha 18. 4.2. Durante el tratamiento de los datos 4.2.1. La calidad de los datos De nuevo está presente el principio de calidad de los datos que, si bien no se puede olvidar en ninguna de las fases en las que hemos dividido el tratamiento de los mismos, adquiere especial relevancia en este momento. En virtud de lo establecido en el artículo 4 de la LOPD, los datos personales:  no pueden usarse para finalidades incompatibles con aquellas para las que se han recogido,  tienen que ser exactos y puestos al día, de forma que respondan con veracidad a la situación actual de su titular y  tienen que ser almacenados de forma que permitan el ejercicio del derecho de acceso. El uso de los datos en relación con la finalidad para la que se obtuvieron En virtud de lo establecido en el artículo 4 de la LOPD, los datos de carácter personal objeto de tratamiento no pueden usarse para finalidades incompatibles con aquellas para las que los datos hubieran sido recogidos y no se considerarán como tales el tratamiento posterior de éstos con fines históricos, estadísticos o científicos. Después de esta afirmación, parece casi inevitable detenerse a analizar la expresión “finalidades incompatibles”, utilizada por primera vez en la LOPD, suponiendo un cambio de redacción respecto del artículo 4 de la LORTAD, en el que se establecía que los datos no podrían usarse para “finalidades distintas” a aquellas para las que hubieran sido recogidos. La utilización del término incompatibles puede suponer un peligro para el respeto al derecho a la protección de datos por parte de los responsables de los ficheros y tratamientos, ya que interpretando el término incompatible en su sentido estricto, pocas finalidades resultarían incompatibles con aquella para la que se obtuvieron los datos. 18. Vid. AEPD, I Sesión Anual Abierta de la AEPD “El nuevo reglamento de desarrollo de la ley orgánica de protección de datos: problemática, interpretación y aplicación”, Madrid, 22 de abril de 2008, https:// www.agpd.es/portalweb/jornadas/1_sesion_abierta/index-ides-idphp.php. 37

La protección de datos personales: Soluciones en entornos Microsoft Debemos seguir interpretando este principio como la imposibilidad de uso de los datos para finalidades distintas, tal y como se recogía en la LORTAD, ya que así lo ha interpretado el Tribunal Constitucional, en su Sentencia 292/2000, de 30 de noviembre, que viene a identificar el citado término con “fines distintos”. Así, dispone la citada sentencia en su Fundamento Jurídico 5 que “La garantía de la vida privada de la persona y de su reputación poseen hoy una dimensión positiva que excede el ámbito propio del derecho fundamental a la intimidad (art. 18.1 CE), y que se traduce en un derecho de control sobre los datos relativos a la propia persona. La llamada «libertad informática» es así derecho a controlar el uso de los mismos datos insertos en un programa informático («habeas data») y comprende, entre otros aspectos, la oposición del ciudadano a que determinados datos personales sean utilizados para fines distintos de aquel legítimo que justificó su obtención (SSTC 11/1998, F. 5, 94/1998, F. 4)”. Asimismo, la sentencia vuelve a interpretar este precepto cuando indica que “la cesión de los mismos (datos) a un tercero para proceder a un tratamiento con fines distintos de los que originaron su recogida, aun cuando puedan ser compatibles con éstos (art. 4.2 LOPD), supone una nueva posesión y uso que requiere el consentimiento del interesado”19. La AEPD reproduce esta interpretación en su informe jurídico 0078/2005: “Tratamiento de datos para fines incompatibles”20. La propia LOPD afirma que no se considerará incompatible el tratamiento posterior de los datos con fines históricos, estadísticos o científicos y el artículo 9 RLOPD desarrolla el tratamiento de los datos con estos fines, estableciendo que para la determinación de los mismos se estará a la legislación que en cada caso resulte aplicable y, en particular, a lo dispuesto en la Ley 12/1989, de 9 de mayo, Reguladora de la función estadística pública, la Ley 16/1985, de 25 junio, del Patrimonio histórico español y la Ley 13/1986, de 14 de abril de Fomento y coordi- nación general de la investigación científica y técnica y sus respectivas disposiciones de desarrollo, así como a la normativa autonómica en estas materias. Exactitud de los datos Los datos de carácter personal objeto de tratamiento tienen que ser exactos y puestos al día de forma que respondan con veracidad a la situación actual de su titular, de manera que si los datos registrados resultan inexactos, en todo o en parte, o incompletos, el responsable del fichero o tratamiento se verá obligado a cancelarlos y sustituirlos de oficio por los correspondientes datos rectificados o completados 21. Ejercicio del derecho de acceso Los datos de carácter personal tienen que ser almacenados de forma que permitan el ejercicio del derecho de acceso, salvo que sean legalmente cancelados. Este derecho será desarrollado en el apartado 5.4.1. 19. Este argumento es reiterado en el posterior Fundamento Jurídico 14. 20. Vid. AEPD, Informe Jurídico 0078/2005 Tratamiento de datos para fines incompatibles, https:// www.agpd.es/portalweb/canaldocumentacion/informes_juridicos/consentimiento/index-ides-idphp.php. 38

Obligaciones básicas 4.2.2. El deber de secreto El deber de secreto es uno de los principios básicos en materia de protección de datos de carácter personal, establecido en el artículo 10 de la LOPD. Al margen del deber de secreto profesional establecido en relación con algunas profesiones, tales como la abogacía o la medicina, la LOPD establece una obligación de guardar secreto que afecta, no sólo al responsable del fichero, sino a todas las personas que intervienen en cualquier fase del tratamiento de los datos de carácter personal, con independencia de la actividad profesional de cada una de ellas. En concreto, establece el sometimiento al secreto profesional respecto de los datos de carácter personal y al deber de guardarlos. Al margen de las sanciones en materia de protección de datos en las que pudiera derivar la vulneración de este principio, es importante tener en cuenta que la revelación de secretos se encuentra tipificada como delito en el Código Penal - artículos 197 a 200-, castigando el apoderamiento, utilización o modificación de datos de carácter personal o familiar de un tercero que se encuentren registrados en ficheros o soporte informáticos, electrónicos o telemáticos o en cualquier otro tipo de archivo o registro público o privado, sin autorización y en perjuicio de tercero. Del mismo modo, se castiga a los que accedan a los mismos por cualquier medio, sin autorización, así como a quien los altere o utilice en perjuicio del titular de los datos o de un tercero. Para evitar sanciones de la AEPD como consecuencia de la vulneración de este principio por parte de los usuarios de los datos, se recomienda al responsable del fichero o tratamiento establecer por escrito una política de información y formación con el objetivo de ponerles en conocimiento de sus funciones y obligaciones en materia de protección de datos personales. 4.2.3. La seguridad de los datos Este principio, establecido en el artículo 9 de la LOPD, impone al responsable del fichero, todos los posibles encargados del tratamiento y todas las personas que intervienen en el mismo, la obligación de 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. De este modo, no se podrán registrar datos de carácter personal en ficheros que no reúnan 21. La Jurisprudencia ha tenido ocasión de analizar el alcance de este principio en las siguientes sentencias: Sentencia de la Sala de lo Contencioso Administrativo de la Audiencia Nacional, de 6 de julio de 2001; Sentencia de la Sección Novena de la Sala de lo Contencioso Administrativo del Tribunal Superior de Justicia de Madrid, de 5 de noviembre de 1998; Sentencia de la Sección Octava de la Sala de lo Contencioso Administrativo del Tribunal Superior de Justicia de Madrid, de 18 de octubre de 2000; Sentencia de la Sección Octava de la Sala de lo Contencioso Administrativo del Tribunal Superior de Justicia de Madrid, de 26 de mayo de 1999; Sentencia de la Sala de lo Contencioso Administrativo de la Audiencia Nacional, de 19 de enero de 2001; Sentencia de la Sección Octava de la Sala de lo Contencioso Administrativo del Tribunal Superior de Justicia de Madrid, de 9 de febrero de 2000; Sentencia de la Sala de lo Contencioso Administrativo de la Audiencia Nacional, de 9 de marzo de 2001. 39

La protección de datos personales: Soluciones en entornos Microsoft las condiciones determinadas por el RLOPD con respecto a su integridad y seguridad y a las de los centros de tratamiento, locales, equipos, sistemas y programas. El RLOPD dedica todo su Título VIII al desarrollo de las medidas de seguridad en el tratamiento de datos de carácter personal, estableciendo unas disposiciones generales -relativas a todos los ficheros o tratamientos de datos de carácter personal, independientemente del soporte en el que se encuentren- y las medidas de seguridad aplicables con carácter específico a los ficheros y tratamientos automatizados y manuales, respectivamente. Las medidas de seguridad exigibles a los ficheros y tratamientos se clasifican en tres niveles (básico, medio y alto), definidos en función del tipo de datos contenidos en dichos ficheros o sometidos a tratamiento. Las medidas incluidas en cada uno de estos niveles tienen la condición de mínimos exigibles, sin perjuicio de las disposiciones legales o reglamentarias específicas vigentes que pudieran resultar de aplicación en cada caso o las que por propia iniciativa adoptase el responsable del fichero. A. Nivel básico. Todos los ficheros o tratamientos de datos de carácter personal deberán adoptar las medidas de seguridad calificadas de nivel básico. Las medidas de seguridad aplicables para los ficheros y tratamiento de datos de nivel básico son las que se detallan a continuación: 1. Para todos los ficheros (automatizados o no). 1.a. Personal.  Definir las funciones y obligaciones de los diferentes usuarios o de los perfiles de usuarios.  Definir las funciones de control y las autorizaciones delegadas por el responsable.  Difundir entre el personal, de las normas que les afecten y las consecuencias por su incumplimiento. 1.b. Incidencias.  Llevar un registro de incidencias en el que se detalle: tipo, momento de su detección, persona que la notifica, efectos y medidas correctoras.  Elaborar un procedimiento de notificación y gestión de las incidencias. 1.c. Control de acceso.  Disponer de una relación actualizada de usuarios y accesos autorizados. 40

Obligaciones básicas  Controlar los accesos permitidos a cada usuario según las funciones asignadas.  Implantar mecanismos que eviten el acceso a datos o recursos con derechos distintos de los autorizados.  Conceder permisos de acceso sólo el personal autorizado.  Adoptar las mismas medidas para personal ajeno con acceso a los recursos de datos. 1.d. Gestión de soportes.  Crear un inventario de soportes.  Identificar el tipo de información que contienen los soportes.  Restringir el acceso al lugar de almacenamiento de los soportes.  Autorizar las salidas de soportes (incluidas a través de e-mail).  Implantar medidas para el transporte y el desecho de soportes. 2. Solo para ficheros automatizados. 2.a. Identificación y autenticación.  Implantar mecanismos de identificación y autenticación personalizada de los usuarios.  Crear un procedimiento de asignación y distribución de contraseñas.  Almacenar las contraseñas de forma ininteligible.  Cambiar las contraseñas con una periodicidad mínima de 1 año. 2.b. Copias de respaldo.  Hacer una copia de respaldo semanal.  Establecer procedimientos de generación de copias de respaldo y recuperación de datos.  Verificar semestralmente los procedimientos.  Reconstruir los datos a partir de la última copia o grabarlos manualmente en su caso, si existe documentación que lo permita.  Realizar copia de seguridad y aplicar el nivel de seguridad correspondiente, si se realizan pruebas con datos reales. 3. Solo para ficheros no automatizados. 3.a. Criterios de archivo.  El archivado de documentos debe realizarse según criterios que faciliten su consulta y localización para garantizar el ejercicio de los derechos de acceso, rectificación, cancelación y oposición. 41

La protección de datos personales: Soluciones en entornos Microsoft 3.b. Almacenamiento.  Dotar a los dispositivos de almacenamiento de mecanismos que obstaculicen su apertura. 3.c. Custodia de soportes.  Establecer criterios de diligente y custodia de la documentación por parte de la persona a cargo de la misma, durante su revisión o tramitación, para evitar accesos no autorizados. B. Nivel medio. Además de las medidas de seguridad de nivel básico, deberán implantarse las de nivel medio, en los siguientes ficheros o tratamientos de datos de carácter personal:  Los relativos a la comisión de infracciones administrativas o penales.  Los relacionados con la prestación de servicios de información sobre solvencia patrimonial y crédito.  Aquellos de los que sean responsables Administraciones tributarias y se relacionen con el ejercicio de sus potestades tributarias.  Aquellos de los que sean responsables las entidades financieras para finalidades relacionadas con la prestación de servicios financieros.  Aquellos de los que sean responsables las Entidades Gestoras y Servicios Comunes de la Seguridad Social y se relacionen con el ejercicio de sus competencias. De igual modo, aquellos de los que sean responsables las mutuas de accidentes de trabajo y enfermedades profesionales de la Seguridad Social.  Aquellos que contengan un conjunto de datos de carácter personal que ofrezcan una definición de las características o de la personalidad de los ciudadanos y que permitan evaluar determinados aspectos de la personalidad o del comportamiento de los mismos. Las medidas de seguridad aplicables para los ficheros y tratamiento de datos de nivel medio son las que se detallan a continuación: 1. Para todos los ficheros (automatizados o no). 1.a. Personal.  Definir las funciones y obligaciones de los diferentes usuarios o de los perfiles de usuarios.  Definir de las funciones de control y las autorizaciones delegadas por el responsable  Difundir entre el personal, de las normas que les afecten y las consecuencias por su incumplimiento. 42

Obligaciones básicas 1.b. Incidencias.  Llevar un registro de incidencias en el que se detalle: tipo, momento de su detección, persona que la notifica, efectos y medidas correctoras  Elaborar un procedimiento de notificación y gestión de las incidencias. 1.c. Control de acceso.  Disponer de una relación actualizada de usuarios y accesos autorizados.  Controlar los accesos permitidos a cada usuario según las funciones asignadas.  Implantar mecanismos que eviten el acceso a datos o recursos con derechos distintos de los autorizados.  Conceder permisos de acceso sólo el personal autorizado.  Adoptar las mismas medidas para personal ajeno con acceso a los recursos de datos. 1.d. Gestión de soportes.  Crear un inventario de soportes.  Identificar el tipo de información que contienen los soportes.  Restringir el acceso al lugar de almacenamiento de los soportes.  Autorizar las salidas de soportes (incluidas a través de e-mail).  Implantar medidas para el transporte y el desecho de soportes. 1.e. Auditoría.  Realizar una auditoría, interna o externa, al menos cada dos años.  Realizar una auditoría ante modificaciones sustanciales en los sistemas de información con repercusiones en seguridad, pese a no haber transcurrido el plazo indicado en el punto anterior.  Verificar y controlar la adecuación de las medidas de seguridad implantadas.  Emitir un informe de las detecciones de deficiencias y propuestas correctoras.  Analizar el informe del responsable de seguridad y remitir las conclusiones al responsable del fichero. 2. Sólo para ficheros automatizados. 2.a. Gestión de soportes.  Registrar la entrada y salida de soportes en el que se detalle: documento o soporte, fecha, emisor/destinatario, número, tipo 43

La protección de datos personales: Soluciones en entornos Microsoft de información, forma de envío, responsable autorizada para recepción/entrega. 2.b. Identificación y autenticación.  Implantar mecanismos de identificación y autenticación personalizada de los usuarios.  Crear un procedimiento de asignación y distribución de contraseñas.  Almacenar las contraseñas de forma ininteligible.  Cambiar las contraseñas con una periodicidad mínima de 1 año. 2.c. Copias de respaldo.  Hacer una copia de respaldo semanal.  Establecer procedimientos de generación de copias de respaldo y recuperación de datos.  Verificar semestralmente los procedimientos.  Reconstruir los datos a partir de la última copia o grabarlos manualmente en su caso, si existe documentación que lo permita.  Realizar copia de seguridad y aplicar el nivel de seguridad correspondiente, si se realizan pruebas con datos reales. 3. Solo para ficheros no automatizados. 3.a. Criterios de archivo.  El archivado de documentos debe realizarse según criterios que faciliten su consulta y localización para garantizar el ejercicio de los derechos de acceso, rectificación, cancelación y oposición. 3.b. Almacenamiento.  Dotar a los dispositivos de almacenamiento de mecanismos que obstaculicen su apertura. 3.c. Custodia de soportes.  Establecer criterios de diligente y custodia de la documentación por parte de la persona a cargo de la misma, durante su revisión o tramitación, para evitar accesos no autorizados. C. Nivel alto. En los siguientes ficheros o tratamientos de datos de carácter personal, ade- más de las medidas de nivel básico y medio, se aplicarán las medidas de nivel alto:  Los que se refieran a datos de ideología, afiliación sindical, religión, creencias, origen racial, salud o vida sexual.  Los que contengan o se refieran a datos recabados para fines policiales sin consentimiento de las personas afectadas. 44

Obligaciones básicas  Aquéllos que contengan datos derivados de actos de violencia de género. Las medidas de seguridad aplicables para los ficheros y tratamiento de datos de nivel básico son las que se detallan a continuación: 1.- Para todos los ficheros (automatizados o no). 1.a. Personal.  Definir las funciones y obligaciones de los diferentes usuarios o de los perfiles de usuarios.  Definir de las funciones de control y las autorizaciones delegadas por el responsable  Difundir entre el personal, de las normas que les afecten y las consecuencias por su incumplimiento. 1.b. Incidencias.  Llevar un registro de incidencias en el que se detalle: tipo, momento de su detección, persona que la notifica, efectos y medidas correctoras  Elaborar un procedimiento de notificación y gestión de las incidencias. 1.c. Control de acceso.  Disponer de una relación actualizada de usuarios y accesos autorizados.  Controlar los accesos permitidos a cada usuario según las funciones asignadas.  Implantar mecanismos que eviten el acceso a datos o recursos con derechos distintos de los autorizados.  Conceder permisos de acceso sólo el personal autorizado.  Adoptar las mismas medidas para personal ajeno con acceso a los recursos de datos. 1.d. Gestión de soportes.  Crear un inventario de soportes.  Identificar el tipo de información que contienen los soportes, utilizando un sistema de etiquetado que dificulte la identifica- ción para las personas diferentes de los usuarios.  Restringir el acceso al lugar de almacenamiento de los soportes.  Autorizar las salidas de soportes (incluidas a través de e-mail).  Implantar medidas para el transporte y el desecho de soportes.  Cifrar los datos en la distribución de soportes. 45

La protección de datos personales: Soluciones en entornos Microsoft  Cifrar la información en dispositivos portátiles fuera de las instalaciones (evitar el uso de dispositivos que no permitan cifrado, o adoptar medidas alternativas). 1.e. Auditoría.  Realizar una auditoría, interna o externa, al menos cada dos años.  Realizar una auditoría ante modificaciones sustanciales en los sistemas de información con repercusiones en seguridad, pese a no haber transcurrido el plazo indicado en el punto anterior.  Verificar y controlar la adecuación de las medidas de seguridad implantadas.  Emitir un informe de las detecciones de deficiencias y propuestas correctoras.  Analizar el informe del responsable de seguridad y remitir las conclusiones al responsable del fichero. 2.- Solo para ficheros automatizados. 2.a. Registro de accesos. (No resulta de aplicación si el responsable del fichero es una persona física y es el único usuario.)  Llevar un registro de accesos en el que se haga constar: usuario, hora, fichero, tipo de acceso, autorizado o denegado.  Revisar el responsable de seguridad el registro de accesos men- sualmente.  Conservar la información del registro de accesos al menos 2 años. 2.b. Gestión de soportes.  Registrar la entrada y salida de soportes en el que se detalle: documento o soporte, fecha, emisor/destinatario, número, tipo de información, forma de envío, responsable autorizada para recepción/entrega. 2.c. Identificación y autenticación.  Implantar mecanismos de identificación y autenticación personalizada de los usuarios.  Crear un procedimiento de asignación y distribución de contraseñas.  Almacenar las contraseñas de forma ininteligible.  Cambiar las contraseñas con una periodicidad mínima de 1 año. 2.d. Copias de respaldo.  Hacer una copia de respaldo semanal.  Establecer procedimientos de generación de copias de respaldo y recuperación de datos. 46

Obligaciones básicas  Verificar semestralmente los procedimientos.  Reconstruir los datos a partir de la última copia o grabarlos manualmente en su caso, si existe documentación que lo permita.  Realizar copia de seguridad y aplicar el nivel de seguridad correspondiente, si se realizan pruebas con datos reales.  Conservar una copia de respaldo en lugar diferente del que se encuentren los equipos informáticos que los tratan. 3. Solo para ficheros no automatizados. 3.a. Control de acceso.  Limitar el acceso al personal autorizado.  Establecer mecanismos que permitan identificar los accesos a documentos accesibles por múltiples usuarios. 3.b. Criterios de archivo.  El archivado de documentos debe realizarse según criterios que faciliten su consulta y localización para garantizar el ejercicio de los derechos de acceso, rectificación, cancelación y oposición. 3.c. Almacenamiento.  Dotar a los dispositivos de almacenamiento de mecanismos que obstaculicen su apertura.  Localizar los armarios, archivadores u otros elementos donde se almacenen los ficheros en áreas con acceso protegido con puertas con llave u otro dispositivo equivalente. 3.d. Custodia de soportes.  Establecer criterios de diligente y custodia de la documentación por parte de la persona a cargo de la misma, durante su revisión o tramitación, para evitar accesos no autorizados. 3.e. Copia o reproducción.  Limitar la posibilidad de realización a los usuarios autorizados.  Destruir las copias desechadas. Como resumen de las medidas de seguridad aplicables a los ficheros o tratamientos de datos de carácter personal, haremos uso de un cuadro extraído de la Guía de Seguridad creada por la AEPD en abril de 200822. 22. Vid. AEPD Guía de Seguridad, https://www.agpd.es/portalweb/canalresponsable/guia_documento/ common/pdfs/guia_seguridad.pdf. 47

La protección de datos personales: Soluciones en entornos Microsoft NIVEL BÁSICO NIVEL MEDIO NIVEL ALTO Responsable  El responsable del seguridad fichero tiene que designar a uno o varios responsables de seguridad (no es una delegación de responsabilidad).  El responsable de seguridad es el encargado de coordinar y controlar las medidas del docu mento. Personal  Funciones y obligaciones de los diferentes usuarios o de los perfiles de usuarios claramente definidas y documen- ta da s.  Definición de las funciones de control y las autorizaciones delegadas por el responsable.  Difusión entre el personal, de las normas que les afecten y de las consecuencias por incumplimiento. Incidencias  Registro de inciden- SOLO FICHEROS cias: tipo, momento AUTOMATIZADOS de su detección, persona que la  Anotar los procedi- notifica, efectos y mientos de recupera- medidas correctoras. ción, persona que lo ejecuta, datos  Procedimiento de restaurados, y en su notificación y gestión caso, datos grabados de las incidencias. manu a lmente.  Autorización del responsable del fichero para la recuperación de da tos. 48

Obligaciones básicas NIVEL BÁSICO NIVEL MEDIO NIVEL ALTO Control de  Relación actualizada SOLO FICHEROS SOLO FICHEROS acceso de usuarios y accesos AUTOMATIZADOS AUTOMATIZADOS autorizados.  Control de acceso  Registro de accesos:  Control de accesos físico a los locales usuario, hora, fichero, permitidos a cada donde se encuentren tipo de acceso, usuario según las ubicados los sistemas autorizado o funciones asignadas. de información. denega do.  Mecanismos que  Revisión mensual del eviten el acceso a registro por el datos o recursos con responsable de derechos distintos de seguridad. los autorizados.  Conservación 2 años.  Concesión de permisos de acceso  No es necesario este sólo por personal registro si el respon- autoriza do. sable del fichero es una persona física y  Mismas condiciones es el único usuario. para personal ajeno con acceso a los SOLO FICHEROS NO recursos de datos. AUTOMATIZADOS  Control de accesos autorizados.  Identificación accesos para documentos accesibles por múltiples usuarios. Identificación y SOLO FICHEROS SOLO FICHEROS autenticación AUTOMATIZADOS AUTOMATIZADOS  Identificación y  Límite de intentos autenticación reiterados de acceso personalizada. no autorizado.  Procedimiento de asignación y distribución de contra señas.  Almacenamiento ininteligible de las contra señas.  Periodicidad del cambio de contrase- ñas (>1 año). 49

La protección de datos personales: Soluciones en entornos Microsoft NIVEL BÁSICO NIVEL MEDIO NIVEL ALTO Gestión de  Inventario de SOLO FICHEROS SOLO FICHEROS soportes soportes. AUTOMATIZADOS AUTOMATIZADOS  Identificación del tipo  Registro de entrada y  Sistema de etiquetado de información que salida de soportes: confidencial. contienen, o sistema documento o soporte, de etiquetado. fecha, emisor/  Cifrado de datos en la destinatario, número, distribución de  Acceso restringido al soportes. lugar de almacena- tipo de información, miento. forma de envío,  Cifrado de informa- responsable autoriza- ción en dispositivos  Autorización de las da para recepción/ portátiles fuera de las salidas de soportes entrega. instalaciones (evitar (incluidas a través de el uso de dispositivos e-mail). que no permitan  Medidas para el cifrado). transporte y el desecho de soportes. Copias de SOLO FICHEROS SOLO FICHEROS respaldo AUTOMATIZADOS AUTOMATIZADOS  Copia de respaldo  Copia de respaldo y semana l. procedimientos de recuperación en lugar Procedimientos de diferente del que se  generación de copias encuentren los de respaldo y equipos. recuperación de da tos.  Verificación semestral de los procedimientos.  Reconstrucción de los datos a partir de la última copia. Grabación manual en su caso, si existe documentación que lo permita.  Pruebas con datos reales. Copia de seguridad y aplica- ción del nivel de seguridad correspondiente. 50

Obligaciones básicas NIVEL BÁSICO NIVEL MEDIO NIVEL ALTO Criterios de SOLO FICHEROS NO archivo AUTOMATIZADOS  El archivo de los documentos debe realizarse según criterios que faciliten su consulta y localización para garantizar el ejercicio de los derechos ARCO. Almacenamiento SOLO FICHEROS NO SOLO FICHEROS NO AUTOMATIZADOS AUTOMATIZADOS  Dispositivos de  Armarios, archivado- alma cenamiento res,… de documentos dotados de mecanis- en áreas con acceso mos que obstaculicen protegido con puertas su apertura. con llave. Custodia SOLO FICHEROS NO soportes AUTOMATIZADOS  Durante la revisión o tramitación de los documentos, la persona a cargo de los mismos debe ser diligente y custodiarla para evitar accesos no autorizados. Copia SOLO FICHEROS NO o reproducción AUTOMATIZADOS  Sólo puede realizarse por los usuarios autorizados.  Destrucción de copias desechadas. 51

La protección de datos personales: Soluciones en entornos Microsoft NIVEL BÁSICO NIVEL MEDIO NIVEL ALTO Auditoría  Al menos cada dos años, interna o externa.  Debe realizarse ante modificaciones sustanciales en los sistemas de informa- ción con repercusiones en seguridad.  Verificación y control de la adecuación de las medidas.  Informe de detección de deficiencias y propuestas correctoras.  Análisis del responsable de seguridad y conclusiones al responsable del fichero. Telecomunica- SOLO FICHEROS ciones AUTOMATIZADOS  Transmisión de datos a través de redes electrónicas cifrada. Traslado de SOLO FICHEROS NO documentación AUTOMATIZADOS  Medidas que impidan el acceso o manipulación. El RLOPD establece, además, algunos supuestos especiales en relación con las medidas de seguridad aplicables a los ficheros o tratamientos, en concreto, relativas a los siguientes: A. Ficheros de los que sean responsables los operadores que presten servicios de comunicaciones electrónicas disponibles al público o exploten redes públicas de comunicaciones electrónicas. Respecto a los datos de tráfico y a los datos de localización, se aplicarán, además de las 52

Obligaciones básicas medidas de seguridad de nivel básico y medio, la medida de seguridad de nivel alto contenida en el artículo 103 del RLOPD: “Registro de accesos”23. B. Ficheros o tratamientos de datos de ideología, afiliación sindical, religión, creencias, origen racial, salud o vida sexual. En relación con estos, será suficiente la implantación de las medidas de seguridad de nivel básico cuando:  Los datos se utilicen con la única finalidad de realizar una transferencia dineraria a las entidades de las que los afectados sean asociados o miembros. Por ejemplo, la detracción de la cuota sindical de la nómi- na a petición del empleado.  Se trate de ficheros o tratamientos no automatizados en los que de forma incidental o accesoria se contengan aquellos datos sin guardar relación con su finalidad. AEPD ha emitido un Informe Jurídico, relativo a las medidas de seguridad en los ficheros de nóminas y demás especialidades, en respuesta a la consulta planteada por un responsable de ficheros 24. C. Ficheros o tratamientos que contengan datos relativos a la salud referentes exclusivamente al grado de discapacidad o la simple declaración de la condición de discapacidad o invalidez del afectado. Del mismo modo que en el caso anterior, resultará suficiente la implantación de las medidas de seguridad de nivel básico, en los ficheros o tratamientos que contengan este tipo de datos, únicamente, con motivo del cumplimiento de deberes públicos (desarrollado en el apartado 3.2). 23. Artículo 103 del RLOPD: “Registro de accesos. 1. De cada intento de acceso se guardarán, como mínimo, la identificación del usuario, la fecha y hora en que se realizó, el fichero accedido, el tipo de acceso y si ha sido autorizado o denegado. 2. En el caso de que el acceso haya sido autorizado, será preciso guardar la información que permita identificar el registro accedido. 3. Los mecanismos que permiten el registro de accesos estarán bajo el control directo del responsable de seguridad competente sin que deban permitir la desactivación ni la manipulación de los mismos. 4. El período mínimo de conservación de los datos registrados será de dos años. 5. El responsable de seguridad se encargará de revisar al menos una vez al mes la información de control registrada y elaborará un informe de las revisiones realizadas y los problemas detectados. 6. No será necesario el registro de accesos definido en este artículo en caso de que concurran las siguientes circunstancias: a) Que el responsable del fichero o del tratamiento sea una persona física. b) Que el responsable del fichero o del tratamiento garantice que únicamente él tiene acceso y trata los datos personales. La concurrencia de las dos circunstancias a las que se refiere el apartado anterior deberá hacerse constar expresamente en el documento de seguridad.” 24. Vid. AEPD, Informe Jurídico 0156/2008 Medidas de seguridad en los ficheros de nóminas y demás especialidades, https://www.agpd.es/portalweb/canaldocumentacion/informes_juridicos/common/pdfs/ 2008-0156_Medidas-de-seguridad-en-los-ficheros-de-n-oo-minas-y-dem-aa-s-especialidades.pdf. 53

La protección de datos personales: Soluciones en entornos Microsoft Con el fin de facilitar la implantación de las medidas de seguridad, cuando en un sistema de información existan ficheros o tratamientos que en función de su finalidad o uso concreto o de la naturaleza de los datos que contengan, requieran la aplicación de un nivel de medidas de seguridad diferente al del sistema principal, el propio RLOPD otorga al responsable del fichero la posibilidad de segregar este último, siendo de aplicación en cada caso el nivel de medidas de seguridad correspondiente y siempre que puedan delimitarse los datos afectados y los usuarios con acceso a los mismos. Productos de software. En relación con las medidas de seguridad aplicables a los ficheros de datos de carácter personal, la disposición adicional única del RLOPD introduce una novedad, imponiendo una obligación a las empresa que desarrollan productos de software destinados al tratamiento automatizado de datos personales, que deberán incluir en su descripción técnica el nivel de seguridad, básico, medio o alto, que permitan alcanzar dichos productos. Por ello, todas las aplicaciones de software que utilicemos en nuestras organizaciones para el tratamiento de ficheros de datos de carácter personal deberán acreditar el nivel de seguridad que permiten alcanzar y deberemos evaluar si el mismo es suficiente de acuerdo con el nivel de seguridad que requiera cada fichero. Si no es así, deberemos sustituir la aplicación por otra que sí nos permita implementar las medidas de seguridad adecuadas. Asimismo, esta materia deberá ser incluida en la Auditoría bienal de aquellas organizaciones que posean ficheros de nivel medio o alto. 4.2.4. La cesión de los datos Como punto de partida, debemos saber que la LOPD -artículo 3.i)- define la cesión o comunicación de datos como “toda revelación de datos realizada a una persona distinta del interesado”, regulándola en su artículo 11. Como principio rector, los datos de carácter personal sólo podrán cederse si se cumplen dos requisitos:  Que se realice para el cumplimiento de fines directamente relacionados con las funciones legítimas del cedente y del cesionario.  Consentimiento previo del interesado. No obstante, existen algunos supuestos en los que no se exige el segundo requisito: consentimiento del interesado. El apartado segundo del citado precepto los recoge expresamente:  Cuando la cesión está autorizada en una Ley. Tradicionalmente, se ha discutido mucho sobre la posibilidad de interpretar esta excepción en sentido amplio, considerando que la cesión de datos puede encontrarse amparada por una norma con rango inferior al de Ley, pero la AEPD ha sentado a través de numerosos informes y resoluciones el 54

Obligaciones básicas criterio de que la interpretación de la misma ha de hacerse en sentido estricto y, únicamente, admite la aplicación de esta excepción cuando la cesión se encuentra recogida en una norma con rango de Ley o superior. El RLOPD -artículo 10.2.a)- ha desarrollado esta excepción añadiendo la posibilidad de que se encuentra autorizada en una norma de derecho comunitario y, en particular, cuando concurra uno de los supuestos siguientes: “El tratamiento o la cesión tengan por objeto la satisfacción de un interés legítimo del responsable del tratamiento o del cesionario amparado por dichas normas, siempre que no prevalezca el interés o los derechos y libertades fundamentales de los interesados previstos en el artículo 1 de la Ley Orgánica 15/1999, de 13 de diciembre. El tratamiento o la cesión de los datos sean necesarios para que el responsable del tratamiento cumpla un deber que le imponga una de dichas normas.”  Cuando se trate de datos recogidos de fuentes accesibles al público. En virtud de lo establecido en el artículo 10.2.b) del RLOPD podrá realizarse una cesión amparada en esta excepción cuando el tercero a quien se comuniquen los datos tenga un interés legítimo para su tratamiento o conocimiento, siempre que no se vulneren los derechos y libertades fundamentales del interesado. No obstante, las Administraciones públicas sólo podrán comunicar al amparo de la misma los datos recogidos de fuentes accesibles al público a responsables de ficheros de titularidad privada cuando se encuentren autorizadas para ello por una norma con rango de ley. n Cuando el tratamiento responda a la libre y legítima aceptación de una relación jurídica cuyo desarrollo, cumplimiento y control implique necesariamente la conexión de dicho tratamiento con ficheros de terceros. En este caso la comunicación sólo será legítima en cuanto se limite a la finalidad que la justifique.  Cuando la comunicación que deba efectuarse tenga por destinatario al Defensor del Pueblo, el Ministerio Fiscal o los Jueces o Tribunales o el Tribunal de Cuentas, en el ejercicio de las funciones que tiene atribuidas. Tampoco será preciso el consentimiento cuando la comunicación tenga como destinatario a instituciones autonómicas con funciones análogas al Defensor del Pueblo o al Tribunal de Cuentas.  Cuando la cesión se produzca entre Administraciones Públicas y tenga por objeto el tratamiento posterior de los datos con fines históricos, estadísticos o científicos. En relación con esta excepción, el RLOPD -artículo 10.4- ha recogido dos nuevos supuestos:  Que los datos de carácter personal hayan sido recogidos o elaborados por una Administración pública con destino a otra. 55

La protección de datos personales: Soluciones en entornos Microsoft  Que la comunicación se realice para el ejercicio de competencias idénticas o que versen sobre las mismas materias.  Cuando la cesión de datos de carácter personal relativos a la salud sea necesaria para solucionar una urgencia que requiera acceder a un fichero o para realizar los estudios epidemiológicos en los términos establecidos en la legislación sobre sanidad estatal o autonómica. Añade el artículo 10.5 del RLOPD que: “En particular, no será necesario el consentimiento del interesado para la comunicación de datos personales sobre la salud, incluso a través de medios electrónicos, entre organismos, centros y servicios del Sistema Nacional de Salud cuando se realice para la atención sanitaria de las personas, conforme a lo dispuesto en el Capítulo V de la Ley 16/2003, de 28 de mayo, de cohesión y calidad del Sistema Nacional de Salud.” Es importante indicar que el destinatario o cesionario, definido en el propio RLOPD como la persona física o jurídica, pública o privada, órgano administrativo o ente sin personalidad jurídica que actúa en el tráfico como sujeto diferenciado al que se revelen los datos, se obliga, por el solo hecho de la comunicación, al cumplimiento de la LOPD y su normativa de desarrollo. Cesión o comunicación de datos entre empresas del mismo grupo. Respecto de los grupos de empresas, es importante aclarar que la AEPD considera que las comunicaciones de datos realizadas entre las empresas integrantes de un mismo grupo se consideran cesiones a terceros, sometidas a los requisitos descritos. Como consecuencia, no se considera válido el consentimiento obtenido mediante cláusulas genéricas que se limiten a recoger el consentimiento para la cesión de datos a empresas del grupo. La AEPD emitió en el año 2004 un informe jurídico25, como respuesta a una consulta en la que se planteaba si resultaba conforme a derecho el tratamiento y comunicación de datos entre las empresas de un mismo grupo con fines de publicidad y promoción, en el que tras analizar la cláusula utilizada para la obtención del consentimiento, concluye considerar la cesión como ajustada a derecho porque dicha cláusula incluía todos los requisitos exigidos en el artículo 5.1 de la LOPD, lo que implica que el consentimiento ha sido otorgado válidamente. 4.2.5. El acceso a datos por cuenta de terceros La LOPD define al encargado de tratamiento en el artículo 3.g) como: “La persona física o jurídica, autoridad pública, servicio o cualquier otro organismo que, solo o conjuntamente con otros, trate datos personales por cuenta del responsa- 25. Vid. AEPD, Informe Jurídico 325/2004 Comunicación de datos entre empresas de un mismo grupo, https:// www.agpd.es/portalweb/canaldocumentacion/informes_juridicos/cesion_datos/common/pdfs/2004- 0325_Comunicaci-oo-n-de-datos-entre-empresas-de-un-mismo-grupo.pdf. 56

Obligaciones básicas ble del tratamiento” y el artículo 5.1.i) del RLOPD se expresa en los siguientes términos: “La persona física o jurídica, pública o privada, u órgano administrativo que, solo o conjuntamente con otros, trate datos personales por cuenta del responsable del tratamiento o del responsable del fichero, como consecuencia de la existencia de una relación jurídica que le vincula con el mismo y delimita el ámbito de su actuación para la prestación de un servicio”. La AEPD reproduce la doctrina de la Audiencia Nacional sobre el alcance de este concepto en su Informe jurídico 0309/2008 26, clarificando el significado de encargado de tratamiento y su alcance. Así, la Sentencia de 28 de septiembre de 2005 recuerda que: “La diferencia entre encargado del tratamiento y cesión en algunos casos reviste cierta complejidad, pero como ha señalado esta Sección en la reciente sentencia de 12 de abril de 2005 (recurso 258/2003) lo típico del encargo de tratamiento es que un sujeto externo o ajeno al responsable del fichero va a tratar datos de carácter personal pertenecientes a los tratamientos efectuados por aquél con objeto de prestarle un servicio en un ámbito concreto..... Siendo esencial para no desnaturali- zar la figura, que el encargado del tratamiento se limite a realizar el acto material de tratamiento encargado, y no siendo supuestos de encargo de tratamiento aquellos en los que el objeto del contrato fuese el ejercicio de una función o actividad independiente del encargado. En suma, existe encargo de tratamiento cuando la transmisión o cesión de datos está amparada en la prestación de un servicio que el responsable del tratamiento recibe de una empresa externa o ajena a su propia organización, y que ayuda en el cumplimiento de la finalidad del tratamiento de datos consentida por el afectado”. En consecuencia, para determinar si nos encontramos en presencia de un encargado del tratamiento deberá analizarse si su actividad se encuentra limitada a la mera prestación de un servicio al responsable, sin generarse ningún vínculo entre el afectado y el supuesto encargado. Además, será preciso que corresponda al responsable el poder de decisión sobre la finalidad que justifica el tratamiento, de manera que si el tratamiento procede de la voluntad del encargado, este tendrá en todo caso la condición de responsable. Se entenderá que una empresa es encargada del tratamiento cuando no puede decidir sobre el contenido, finalidad y uso del tratamiento y siempre que su actividad no le reporte otro beneficio que el derivado de la prestación de servicios propia- mente dicha, sin utilizar los ficheros generados en modo alguno en su provecho, puesto que en ese caso pasaría a ser responsable del fichero. El artículo 12 de la LOPD regula el acceso a datos por cuenta de terceros. En cumplimiento de lo establecido en el mismo, las prestaciones de servicios al respon- 26. Vid. AEPD, Informe Jurídico 0309/2008 Los ensobrados y recepción de direcciones de personas físicas para efectuar envíos configura a la empresa como encargado de tratamiento, https://212.170.242.196/ portalweb/canaldocumentacion/informes_juridicos/conceptos/common/pdfs/2008-0309_Los-ensobrados-y- recepci-oo-n-de-direcciones-de-personas-f-ii-sicas-para-efectuar-env-ii-os-configura-a-la-empresa-como- encargado-del-tratamiento.pdf. 57

La protección de datos personales: Soluciones en entornos Microsoft sable de los ficheros que impliquen un acceso a datos de carácter personal contenidos en los mismos, deben regularse a través de un contrato escrito en el que se establezcan los términos en los que se producirá el citado acceso o tratamiento de datos personales. El servicio prestado podrá tener o no carácter remunerado y ser temporal o indefinido. El contrato deberá recoger, como mínimo, el siguiente contenido:  Obligación del encargado del tratamiento de tratar los datos conforme a las instrucciones del responsable del fichero o tratamiento.  Prohibición de utilizar los datos con fin distinto al que figura en el contrato.  Prohibición de comunicar los datos a terceras personas, ni siquiera para su conservación.  Medidas de seguridad que, en virtud del Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la LOPD (en adelante, RLOPD), el encargado del tratamiento está obligado a cumplir en el tratamiento de los datos personales.  Obligación de devolver los datos al responsable del fichero o destruirlos una vez concluida la prestación contractual.  Responsabilidades del encargado del tratamiento por incumplimiento de las anteriores obligaciones, en cuyo caso será considerado también responsable del tratamiento, respondiendo de las infracciones en que hubiera incurrido personalmente. El RLOPD recoge que se considerará que existe comunicación de datos cuando el acceso tenga por objeto el establecimiento de un nuevo vínculo entre quien accede a los datos y el afectado, así como la obligación del responsable del tratamiento de velar por que el encargado del mismo reúna las garantías para el cumplimiento de lo dispuesto en dicho cuerpo normativo. Esto se traducirá en la práctica en la necesidad de que el responsable del fichero articule algún sistema que le permita llevar un control de la actividad desarrollada por su prestador de servicios. Por ejemplo, establecer en el contrato de acceso y tratamiento de datos la posibilidad del responsable del fichero de solicitar el informe de las auditorías realizadas. En el caso de que el encargado del tratamiento destine los datos a otra finalidad, los comunique o los utilice incumpliendo las estipulaciones del contrato en el que se ha regulado el acceso a datos, se considerará responsable del tratamiento, respondiendo de las infracciones en que hubiera incurrido personalmente. No obstante, el encargado del tratamiento no incurrirá en responsabilidad cuando, previa indicación expresa del responsable, comunique los datos a un tercero designado por aquél, al que hubiera encomendado la prestación de un servicio. Posibilidad de subcontratación de los servicios. La LOPD no establece nada en relación con la posibilidad de subcontratación de los servicios por parte del encargado de tratamiento. 58

Obligaciones básicas En su Memoria del año 2000, la AEPD realizaba la interpretación que se recoge a continuación, al analizar la figura del encargado de tratamiento: “En lo referente a la cesión de los datos, de lo establecido en la el artículo 12.2 se desprende que no se producirá esa cesión, de forma que los datos habrán de ser entregados única y exclusivamente al responsable del fichero. Ello implica, a nuestro juicio, la posibilidad de proceder a una subcontratación de este tipo de servicios por parte del encargado del tratamiento, debiendo siembre el responsable ser parte de la relación jurídica, ya que cualquier transmisión de los datos a un tercero que no corresponda al responsable del fichero habrá de ser considerada cesión”. No obstante, la AEPD consciente de que la subcontratación de servicios es una realidad y que prohibirla originaría muchos problemas en la práctica, establece en la citada Memoria fórmulas a través de las cuales se podría realizar y, además, la Memoria de 2001 admitió la subcontratación cuando se cumplieran determinados requisitos. El Artículo 21 del RLOPD regula por primera vez la posibilidad de subcontratar servicios por parte del encargado de servicios, sentando como regla general la prohibición del encargado del tratamiento de subcontratar con un tercero la realización de ningún tratamiento que le hubiera encomendado el responsable del mismo, salvo que hubiera obtenido de éste autorización para ello. En este caso, la contratación se efectuará siempre en nombre y por cuenta del responsable del tratamiento. No obstante, admite la posibilidad de subcontratar sin necesidad de autoriza- ción siempre y cuando se cumplan los siguientes requisitos:  Que se especifiquen en el contrato los servicios que puedan ser objeto de subcontratación y, si ello fuera posible, la empresa con la que se vaya a subcontratar.  Cuando no se identificase en el contrato la empresa con la que se vaya a subcontratar, será preciso que el encargado del tratamiento comunique al responsable los datos que la identifiquen antes de proceder a la subcontratación.  Que el tratamiento de datos de carácter personal por parte del subcontratista se ajuste a las instrucciones del responsable del fichero. Que el encargado del tratamiento y la empresa subcontratista formalicen el contrato, en los términos previstos en el artículo anterior.  En este caso, el subcontratista será considerado encargado del tratamiento y, como tal tendrá que cumplir las obligaciones que la normativa le impone. Si durante la prestación del servicio resulta necesario subcontratar una parte del mismo y dicha circunstancia no hubiera sido prevista en el contrato, deberán someterse al responsable del tratamiento los extremos señalados. 59

La protección de datos personales: Soluciones en entornos Microsoft Conservación de los datos por el encargado del tratamiento. Si bien el artículo 22 del RLOPD regula la conservación de los datos por el encargado de tratamiento, establece unas obligaciones que resultan sumamente confusas. En su primer apartado establece que, una vez cumplida la prestación contractual, los datos de carácter personal deberán ser destruidos o devueltos al responsable del tratamiento o al encargado que éste hubiese designado, al igual que cualquier soporte o documentos en que conste algún dato de carácter personal objeto del tratamiento y a continuación que no procederá la destrucción de los datos cuando exista una previsión legal que exija su conservación, en cuyo caso deberá procederse a la devolución de los mismos garantizando el responsable del fichero dicha conservación. También establece la obligación para el encargado de tratamiento de conservar, debidamente bloqueados, los datos en tanto pudieran derivarse responsabilidades de su relación con el responsable del tratamiento. Pensemos que aquí es donde se puede crear la confusión, dado que si se cumple esta obliga- ción, el encargado de tratamiento no podrá destruir o devolver los datos, cumpliendo la obligación impuesta en el primer apartado. Las medidas de seguridad en relación con el encargado del tratamiento. El artículo 82 del RLOPD establece algunas obligaciones en relación con este tema, en concreto:  Cuando un encargado de tratamiento preste sus servicios en los locales del responsable, esto deberá constar en el documento de seguridad del responsable, comprometiéndose el personal del encargado al cumplimien- to de las medidas de seguridad previstas en el mismo.  Cuando el acceso sea remoto, habiéndose prohibido al encargado incorporar los datos objeto de tratamiento a sistemas o soportes distintos de los del responsable, este deberá dejar constancia de ello en su documento de seguridad, comprometiéndose el personal del encargado al cumplimiento de las medidas de seguridad previstas en el citado documento.  Cuando un encargado de tratamiento preste los servicios contratados en sus propios locales, deberá elaborar un documento de seguridad o completar el que ya tuviera, identificando el fichero o tratamiento y el responsable del mismo e incorporando las medidas de seguridad a implantar en relación con dicho tratamiento.  En todo caso, el acceso a los datos por el encargado del tratamiento estará sometido a las medidas de seguridad contempladas en el RLOPD. 4.2.6. Prestaciones de servicios sin acceso a datos personales El RLOPD regula una figura novedosa en materia de protección de datos: las prestaciones de servicios sin acceso a datos personales, estableciendo la obligación 60

Obligaciones básicas para el responsable del fichero o tratamiento de adoptar las medidas adecuadas para limitar el acceso del personal a datos personales, a los soportes que los contengan o a los recursos del sistema de información, para la realización de trabajos que no impliquen el tratamiento de datos personales. Dispone, además, que cuando se trate de personal ajeno, el contrato de presta- ción de servicios recogerá expresamente la prohibición de acceder a los datos personales y la obligación de secreto respecto a los datos que el personal hubiera podido conocer con motivo de la prestación del servicio, no resultando necesario firmar un contrato de acceso y tratamiento de datos, en los términos establecidos en el artículo 12 de la LOPD. ¿En las prestaciones sin acceso a datos existen obligaciones de seguridad? La respuesta de la AEPD a esta pregunta se encuentra al alcance de todos los ciudadanos a través de su página web27: “Cualquier actividad que suponga un contacto directo o indirecto con el sistema de información y/o su entorno físico o lógico puede ser susceptible de poner en riesgo la seguridad de los datos:  Limpieza.  Seguridad.  Mantenimiento o reparación de instalaciones (que no se refiera al propio sistema de información). Incluye servicios de destrucción o almacenamiento de soportes cuando el prestador desconozca el criterio de archivo o no pueda recuperar dato alguno.” 4.2.7. La modificación de ficheros Siguiendo lo dispuesto en el artículo 58 del RLOPD y, dado que la inscripción de un fichero de datos de carácter personal que obra en el RGPD debe encontrarse actualizada en todo momento, cualquier modificación que afecte al contenido de la misma deberá ser previamente notificada a la AEPD o a las autoridades de control autonómicas competentes, a fin de proceder a su inscripción en el RGPD. Cuando se trate de un fichero de titularidad pública debe adoptarse, con carácter previo a la notificación, la correspondiente norma o acuerdo en los términos previstos al tratar la creación de ficheros. 4.2.8. Las transferencias internacionales de datos La norma general no permite al responsable de los ficheros realizar transferencias internacionales de datos de carácter personal que hayan sido objeto de trata- 27. Vid. AEPD, I Sesión Anual Abierta de la AEPD “El nuevo reglamento de desarrollo de la ley orgánica de protección de datos: problemática, interpretación y aplicación”, Madrid, 22 de abril de 2008, https:// www.agpd.es/portalweb/jornadas/1_sesion_abierta/common/faqs_bloque_1.pdf. 61

La protección de datos personales: Soluciones en entornos Microsoft miento o hayan sido recogidos para someterlos a dicho tratamiento con destino a países que no proporcionen un nivel de protección equiparable al que presta LOPD, salvo que cumplan los siguientes requisitos:  Se haya observado lo dispuesto en la LOPD.  Se obtenga autorización previa del Director de la AEPD. El carácter adecuado del nivel de protección que ofrece el país de destino se evaluará por la AEPD atendiendo a todas las circunstancias que concurran en la transferencia o categoría de transferencia de datos. En la actualidad se consideran países con nivel de protección adecuado al que presta la LOPD los Estados Miembros de la Unión Europea, Islandia, Liechtenstein, Noruega y los Estados que la Comisión Europea ha declarado que garantizan un nivel de protección adecuado: Suiza, Argentina, Guernsey, Isla de Man, las entidades estadounidenses adheridas a los principios de Puerto Seguro 28, Canadá respecto de las entidades sujetas al ámbito de aplicación de la ley canadiense de protección de datos y los datos personales incluidos en los registros de nombres de los pasaje- ros que se transfieren al Servicio de aduanas y protección de fronteras de los Esta- dos Unidos de América. La propia LOPD reconoce algunas excepciones a la norma general, de manera que no será necesaria la autorización previa del Director de la AEPD en los siguientes supuestos:  Cuando la transferencia internacional de datos de carácter personal resulte de la aplicación de tratados o convenios en los que sea parte España.  Cuando la transferencia se haga a efectos de prestar o solicitar auxilio judicial internacional.  Cuando la transferencia sea necesaria para la prevención o para el diag- nóstico médicos, la prestación de asistencia sanitaria o tratamiento médi- cos o la gestión de servicios sanitarios.  Cuando se refiera a transferencias dinerarias conforme a su legislación específica.  Cuando el afectado haya dado su consentimiento inequívoco a la transferencia prevista.  Cuando la transferencia sea necesaria para la ejecución de un contrato entre el afectado y el responsable del fichero o para la adopción de medidas precontractuales adoptadas a petición del afectado.  Cuando la transferencia sea necesaria para la celebración o ejecución de un contrato celebrado o por celebrar, en interés del afectado, por el responsable del fichero y un tercero. 28. La lista de entidades estadounidenses adheridas a los principios de Puerto Seguro se encuentra accesible en www.export.gov/safeharbor. 62

Obligaciones básicas  Cuando la transferencia sea necesaria o legalmente exigida para la salvaguarda de un interés público. Tendrá esta consideración la transferencia solicitada por una Administración fiscal o aduanera para el cumplimiento de sus competencias.  Cuando la transferencia sea precisa para el reconocimiento, ejercicio o defensa de un derecho en un proceso judicial.  Cuando la transferencia se efectúe, a petición de persona con interés legítimo, desde un Registro Público y aquélla sea acorde con la finalidad del mismo.  Cuando la transferencia tenga como destino un Estado miembro de la Unión Europea, o un Estado respecto del cual la Comisión de las Comuni- dades Europeas, en el ejercicio de sus competencias, haya declarado que garantiza un nivel de protección adecuado. El RLOPD introduce una novedad al definir la transferencia internacional de datos como el “Tratamiento de datos que supone una transmisión de los mismos fuera del territorio del Espacio Económico Europeo, bien constituya una cesión o comunicación de datos, bien tenga por objeto la realización de un tratamiento de datos por cuenta del responsable del fichero establecido en territorio español.” Esto supone un cambio ya que, si bien realizando una interpretación literal de la LOPD un movimiento de datos a países de la Unión Europea supone una transferencia internacional de datos para la que no se necesita autorización previa del Director de la AEPD, de la definición aportada por el RLOPD se desprende que dicho movimiento de datos no se considera transferencia internacional. 4.3. Una vez finalizado el tratamiento 4.3.1. La cancelación y el bloqueo de los datos En función de lo establecido en el artículo 4.5. de la LOPD, el responsable de ficheros se verá obligado a cancelar los datos de carácter personal cuando hayan dejado de ser necesarios o pertinentes para la finalidad para la cual hubieran sido recabados o registrados, de manera que no podrá conservarlos en forma que permita la identificación del interesado durante un período superior al necesario para los fines en base a los cuales los hubiera recabado o registrado. El RLOPD recuerda la obligación de cancelar los datos cuando dejan de ser necesarios o pertinentes para la finalidad para la cual han registrados o recabados, añadiendo que, no obstante, podrán conservarse durante el tiempo en que pueda exigirse algún tipo de responsabilidad derivada de una relación u obligación jurídica o de la ejecución de un contrato o de la aplicación de medidas precontractuales solicitadas por el interesado. Una vez cumplido el período al que se refieren los párrafos anteriores, los datos sólo podrán ser conservados previa disociación de los mismos, sin perjuicio 63

La protección de datos personales: Soluciones en entornos Microsoft de la obligación de bloqueo prevista en la LOPD y el RLOPD. En este sentido, debemos saber que un procedimiento de disociación es todo tratamiento de datos personales que permita la obtención de datos disociados. 4.3.2. La supresión de ficheros Cuando el responsable de un fichero decida su supresión, deberá notificarla a AEPD o a las autoridades de control autonómicas competentes, a fin de proceder a la supresión del mismo en el RGPD. Cuando se trate de un fichero de titularidad pública debe adoptarse con carácter previo a la notificación la correspondiente norma o acuerdo en los mismos términos que en los casos de creación y modificación de ficheros, ya tratados anteriormente. Una vez tramitado el procedimiento establecido, el Director de la AEPD dictará resolución acordando la cancelación de la inscripción del fichero. Hasta ahora hemos hablado de la supresión de ficheros a instancia de parte, pero el artículo 61 del RLOPD establece la posibilidad de que sea el propio Director de la AEPD quien, en ejercicio de sus competencias, acuerde de oficio la cancelación de la inscripción de un fichero. Para ello, han de concurrir circunstancias que acrediten la imposibilidad de que exista y ha de seguirse el mismo procedimiento que en los casos de supresión a instancia del responsable del fichero. 4.3.2.1. El deber de secreto El deber de secreto, es una obligación que subsistirá en relación con los usuarios de los datos, aun después de finalizar sus relaciones con el titular del fichero o, en su caso, con el responsable del mismo. 64

5 Los derechos de los titulares de los datos 5.1. La impugnación de valoraciones En función de lo establecido en el artículo 13.1 de la LOPD: “Los ciudadanos tienen derecho a no verse sometidos a una decisión con efectos jurídicos, sobre ellos o que les afecte de manera significativa, que se base únicamen- te en un tratamiento de datos destinados a evaluar determinados aspectos de su personalidad”. Como consecuencia de ello, el titular de los datos puede impugnar los actos administrativos o decisiones privadas que impliquen una valoración de su comportamiento, cuyo único fundamento sea un tratamiento de datos de carácter personal que ofrezca una definición de sus características o personalidad, disponiendo del derecho a obtener información del responsable del fichero sobre los criterios de valoración y el programa utilizados en el tratamiento que sirvió para adoptar la decisión en que consistió el acto. Finalmente, recoge que la valoración sobre el comportamiento de los ciudadanos basada en un tratamiento de datos, únicamente podrá tener valor probatorio a petición del afectado. 5.2. El derecho de consulta al Registro General de Protección de Datos El artículo 14 de la LOPD reconoce el derecho de consulta al RGPD, en virtud del cual: “Cualquier persona podrá conocer, recabando a tal fin la información oportuna del Registro General de Protección de Datos, la existencia de tratamientos de datos de 65

La protección de datos personales: Soluciones en entornos Microsoft carácter personal, sus finalidades y la identidad del responsable del tratamiento. El Registro General será de consulta pública y gratuita”. 5.3. El derecho de indemnización El artículo 19 de la LOPD reconoce el derecho a indemnización. Con base en este, todos los interesados que, como consecuencia del incumplimiento de lo dispuesto en la LOPD por el responsable o el encargado del tratamiento, sufran daño o lesión en sus bienes o derechos tendrán derecho a ser indemnizados. Cuando se trate de ficheros de titularidad pública, la responsabilidad se exigirá de acuerdo con la legislación reguladora del régimen de responsabilidad de las Administraciones Públicas. En el caso de los ficheros de titularidad privada, la acción se ejercitará ante los órganos de la jurisdicción ordinaria. 5.4. Los derechos ARCO De acuerdo con lo dispuesto en los artículos 15, 16 y 17 de la LOPD y 23 a 26 del RLOPD, los titulares de los datos de carácter personal tienen una serie de derechos personalísimos en relación con sus datos de carácter personal, que pueden ejercitar ante el responsable del fichero o ante el encargado del tratamiento. Ejercicio de los derechos Los derechos podrán ser ejercitados por:  el afectado acreditando su identidad,  su representante legal que habrá de acreditar tal condición, cuando el afectado se encuentre en situación de incapacidad o minoría de edad que le imposibilite el ejercicio personal de estos derechos,  el representante voluntario expresamente designado para el ejercicio del derecho, junto con copia del Documento Nacional de Identidad o documento equivalente del representado y la representación conferida por aquél. No es necesario poder notarial general o especial. Atención a las solicitudes Las solicitudes de acceso, rectificación, cancelación y oposición deben atenderse con independencia de que figuren o no datos personales del afectado en los ficheros del responsable y aun cuando el afectado no hubiese utilizado el procedimiento establecido específicamente por el responsable del fichero siempre que haya utilizado un medio que permita acreditar el envío y la recepción de la solicitud y ésta contenga lo siguiente: 66

Los derechos de los titulares de los datos  Nombre y apellidos del interesado; fotocopia de su documento nacional de identidad, o de su pasaporte u otro documento válido que lo identifique y, en su caso, de la persona que lo represente, o instrumentos electró- nicos equivalentes; así como el documento o instrumento electrónico acreditativo de tal representación. La utilización de firma electrónica identificativa del afectado eximirá de la presentación de las fotocopias del DNI o documento equivalente.  Petición en que se concreta la solicitud.  Dirección a efectos de notificaciones, fecha y firma del solicitante.  Documentos acreditativos de la petición que formula, en su caso. Cuando la solicitud no reúna alguno de los requisitos, el responsable del fichero solicitará la subsanación en un plazo de diez días. Una vez realizada la subsanación, empieza el plazo para contestar por el responsable. Cuando se hace referencia a plazos por días, son días hábiles y cuando el plazo sea por meses, se computa de fecha a fecha. Corresponde al responsable del tratamiento la prueba del cumplimiento del deber de respuesta, debiendo conservar la acreditación del cumplimiento del mencionado deber (de la respuesta). El responsable del fichero adoptará las medidas para garantizar que las personas de su organización con acceso a datos de carácter personal puedan informar del procedimiento a seguir por el afectado para el ejercicio de sus derechos. Cuando el responsable del fichero disponga de servicios de atención al público o el ejercicio de reclamaciones por el servicio prestado o productos ofertados, podrá concederse la posibilidad al afectado de ejercer dichos derechos a través de esos servicios. En tal caso, la identidad del interesado se considerará acreditada por los medios establecidos para la identificación de los clientes del responsable en la prestación de sus servicios o contratación de sus productos. Cuando se ejerciten los derechos ante un encargado del tratamiento, el encargado deberá dar traslado de la solicitud al responsable, a fin de que por el mismo se resuelva, a menos que en la relación existente con el responsable del tratamiento se prevea que el encargado atenderá, por cuenta del responsable, las solicitudes de ejercicio por los afectados de sus derechos de acceso, rectificación, cancelación u oposición. Los derechos se pueden ejercitar a través de correo electrónico y de llamadas a teléfonos gratuitos. Para comprobar la identidad del afectado se pueden pedir datos adicionales que sólo el afectado conozca o bien grabar las llamadas (informando de ello) para comprobar que se trata de la misma persona. Los derechos serán denegados cuando la solicitud sea formulada por persona distinta del afectado y no se acredite la representación. 67

La protección de datos personales: Soluciones en entornos Microsoft Estos derechos son los siguientes:  Derecho de acceso.  Derecho de rectificación.  Derecho de cancelación.  Derecho de oposición al tratamiento o cese en el tratamiento. 5.4.1. El derecho de acceso El derecho de acceso es el derecho del afectado a obtener información sobre si sus propios datos de carácter personal están siendo objeto de tratamiento, la finalidad del tratamiento que, en su caso, se esté realizando, así como la información disponible sobre el origen de dichos datos y las comunicaciones realizadas o previstas de los mismos. El afectado podrá obtener del responsable del tratamiento información relativa a datos concretos, a datos incluidos en un determinado fichero o a la totalidad de sus datos sometidos a tratamiento. El responsable del fichero responderá la solicitud de acceso en el plazo máxi- mo de un mes a contar desde la recepción de la solicitud. Transcurrido el plazo sin que de forma expresa se responda a la petición de acceso, el interesado podrá interponer una reclamación ante la AEPD y, en el caso de que no disponga de datos de carácter personal de los afectados, deberá igualmente comunicárselo en el mismo plazo. Si la solicitud fuera estimada y el responsable no acompañase a su comunica- ción la información solicitada, el acceso se hará efectivo durante los diez días siguientes a dicha comunicación. La información que se proporcione comprenderá todos los datos de base del afectado, los resultantes de cualquier elaboración o proceso informático, así como la información disponible sobre el origen de los datos, los cesionarios de los mismos y la especificación de los concretos usos y finalidades para los que se almacenaron los datos. El responsable del fichero o tratamiento podrá denegar el acceso a los datos de carácter personal cuando el derecho ya se haya ejercitado en los doce meses anteriores a la solicitud, salvo que se acredite un interés legítimo al efecto. En todo caso, el responsable del fichero informará al afectado de su derecho a recabar la tutela de la AEPD o, en su caso, de las autoridades de control de las Comunidades Autónomas. 5.4.2. El derecho de rectificación El afectado puede ejercitar su derecho de rectificación, solicitando la modifica- ción de los datos inexactos o incompletos relativos a su persona que estén incluidos 68

Los derechos de los titulares de los datos en ficheros. La solicitud debe indicar a qué datos se refiere, la corrección que haya de realizarse e ir acompañada de la documentación justificativa de lo solicitado. El responsable del fichero resolverá sobre la solicitud en el plazo máximo de 10 días a contar desde la recepción de la misma, tanto si se dispone de datos del afectado o no. Si los datos rectificados han sido cedidos previamente, el responsable del fichero debe comunicar la rectificación efectuada al cesionario en el mismo plazo para que éste, también en 10 días contados desde la recepción de dicha comunica- ción, proceda a rectificar los datos. 5.4.3. El derecho de oposición Mediante el derecho de oposición, el afectado solicita que no se lleve a cabo el tratamiento de sus datos personales o el cese en el mismo cuando:  no sea necesario su consentimiento para el tratamiento, como consecuencia de la concurrencia de un motivo legítimo y fundado, referido a su concreta situación personal, que lo justifique, siempre que una Ley no disponga lo contrario. La solicitud deberá recoger los motivos fundados y legítimos que lo justifiquen.  se trate de ficheros que tengan por finalidad la realización de actividades de publicidad y prospección comercial.  el tratamiento tenga por finalidad la adopción de una decisión referida al afectado y basada únicamente en un tratamiento automatizado de sus datos de carácter personal (destinado a evaluar determinados aspectos de su personalidad tales como su rendimiento laboral, crédito, fiabilidad o conducta). El responsable del fichero resolverá sobre la solicitud de oposición en el plazo máximo de diez días a contar desde la recepción de la solicitud, tenga o no datos personales del afectado. El responsable del fichero o tratamiento deberá excluir del tratamiento los datos relativos al afectado que ejercite su derecho de oposición o denegar motivadamente la solicitud del interesado en el plazo de diez días a contar desde la recepción de la solicitud. Se podrán conservar los mínimos datos imprescindibles de los afectados que hayan manifestado su negativa a recibir publicidad, con el fin de poder identificar- los y adoptar las medidas necesarias que eviten el envío de publicidad. Cuando el afectado manifieste su oposición a recibir publicidad, se le deberá informar de la existencia de ficheros comunes de exclusión generales o sectoriales, así como de la identidad de su responsable, su domicilio y la finalidad del tratamiento. 69

La protección de datos personales: Soluciones en entornos Microsoft Antes de realizar un tratamiento de datos con fines publicitarios o de prospec- ción comercial, será necesario consultar los ficheros comunes de exclusión que pudieran afectar a esta actuación, con el fin de evitar que sean objeto de tratamiento datos de afectados que hubieran manifestado su oposición o negativa al mismo. 5.4.4. El derecho de cancelación Mediante el ejercicio del derecho de cancelación el afectado solicita la cancela- ción de los datos que resulten ser inadecuados o excesivos indicando a qué datos se refiere, aportando en su caso, la documentación que lo justifique. El responsable del fichero resolverá sobre la solicitud en el plazo máximo de 10 días a contar desde la recepción de la solicitud, tanto si se dispone o no de datos personales del afectado. La cancelación implica el bloqueo de los datos, consistente en la identificación y reserva de los datos con el fin de impedir su tratamiento excepto para su puesta a disposición de las Administraciones públicas, Jueces y Tribunales, para la atención de las posibles responsabilidades nacidas del tratamiento y sólo durante el plazo de prescripción de dichas responsabilidades. Transcurrido ese plazo deberá procederse a la supresión de los datos. Si los datos cancelados hubieran sido cedidos previamente, el responsable del fichero comunicará la cancelación efectuada al cesionario, en idéntico plazo, para que éste, también en el plazo de diez días contados desde la recepción de dicha comunicación, proceda a cancelar los datos. Cancelación versus revocación del consentimiento La cancelación de los datos se puede solicitar siempre y cuando los datos resulten inadecuados o excesivos, por lo que es necesario justificar o motivar dicha inadecuación o exceso. La revocación se puede pedir cuando se ha consentido previamente al tratamien- to de los datos y se quiere retirar dicho consentimiento; por lo que no es necesario aportar justificación, se revoca sin más el consentimiento a tratar los datos y no se le puede pedir al afectado más de lo que se le pidió para recabar su consentimiento. Cancelación de datos relativos a personas fallecidas Las personas vinculadas al fallecido, por razones familiares o análogas, podrán dirigirse a los responsables de los ficheros o tratamientos que contengan datos de éste con la finalidad de notificar el óbito, aportando acreditación suficiente del mismo, y solicitar la cancelación de datos cuando haya lugar a ello. 5.5. La tutela de los derechos El artículo 18 de la LOPD regula la tutela de derechos, estableciendo las siguientes normas: 70

Los derechos de los titulares de los datos  Las actuaciones contrarias a lo dispuesto en la presente Ley pueden ser objeto de reclamación por los interesados ante la AEPD.  El interesado al que se deniegue, total o parcialmente, el ejercicio de los derechos de oposición, acceso, rectificación o cancelación, podrá ponerlo en conocimiento de la AEPD, en su caso, del Organismo competente de cada Comunidad Autónoma, que deberá asegurarse de la procedencia o improcedencia de la denegación. El plazo máximo en que debe dictarse la resolución expresa de tutela de derechos será de seis meses y contra las resoluciones de la AEPD procederá recurso contencioso-administrativo. En el apartado 8.6.2 veremos el procedimiento de tutela de los derechos de acceso, rectificación, cancelación y oposición. 71

6 Tratamientos especiales La normativa de protección de datos de carácter personal regula determinados tratamientos de datos que se consideran especiales por la finalidad de los ficheros que los contienen y los requisitos necesarios para la inclusión de datos en los mismos. 6.1. Prestación de servicios de información sobre solvencia patrimonial y crédito Para comenzar a hablar del régimen aplicable a los ficheros de solvencia patrimonial y crédito es necesario definir primero las partes intervinientes en este tipo de tratamiento de datos. En primer lugar encontramos al “responsable del fichero común” que será aquella entidad que acuerda la creación del fichero de información sobre solvencia patrimonial y crédito. Estos ficheros, según lo establecido en el artículo 29 de la LOPD, pueden incluir datos de carácter personal obtenidos de los registros y las fuentes accesibles al público o procedentes de informaciones facilitadas por el interesado o con su consentimiento. Asimismo, podrán incorporar datos relativos al cumplimien- to o incumplimiento de obligaciones dinerarias facilitados por el acreedor o por quien actúe por su cuenta o interés. En segundo lugar, y enlazando con el párrafo anterior, tendríamos a las “entidades que facilitan los datos al fichero común”. Dichas entidades serán las acreedoras que comunican datos relativos al incumplimiento de obligaciones dinerarias. En tercer lugar, es necesario hacer referencia a las “entidades participantes en el sistema” o terceros que serán aquellas que pueden consultar el fichero común accediendo a datos suministrados por otras entidades o procedentes de registros, fuentes accesibles al público o del propio interesado. 73

La protección de datos personales: Soluciones en entornos Microsoft Por último, estaría el “interesado” o deudor, que tendrá derecho a ser informado del tratamiento de sus datos así como a ejercitar sus derechos ARCO. De esta forma, cuando lo solicite, el responsable del fichero común le comunicará los datos, las evaluaciones y apreciaciones que sobre el mismo hayan sido comunicadas durante los últimos seis meses, y el nombre y dirección de la persona o entidad a quien se hayan revelado los datos. Sólo se podrán registrar y ceder los datos de carácter personal que sean determinantes para enjuiciar la solvencia económica de los interesados y que no se refieran, cuando sean adversos, a más de seis años, siempre que respondan con veracidad a la situación actual de aquellos. Los artículos 37 a 44 del RLOPD desarrollan las características especiales de estos ficheros, derechos de los interesados y obligaciones del responsable y entidades participantes en el sistema. 6.1.1. Requisitos para la inclusión de los datos Para poder incorporar datos de carácter personal en este tipo de ficheros será necesario: a) Que exista una deuda cierta, vencida, exigible, que haya resultado impagada y respecto de la cual no se haya entablado reclamación judicial, arbitral o administrativa, o tratándose de servicios financieros, no se haya planteado una reclamación en los términos previstos en el Reglamento de los Comisionados para la defensa del cliente de servicios financieros, aprobado por Real Decreto 303/2004, de 20 de febrero. b) Que no hayan transcurrido seis años desde la fecha en que hubo de procederse al pago de la deuda o del vencimiento de la obligación o del plazo concreto si aquélla fuera de vencimiento periódico. c) Requerimiento previo de pago a quien corresponda el cumplimiento de la obligación. En todo caso el acreedor, o quien actúe por su cuenta o interés, deberá conservar a disposición del “responsable del fichero común” y de la AEPD la documentación que acredite el cumplimiento de estos requisitos. 6.1.2. Información previa a la inclusión El acreedor deberá informar al deudor, en el momento en que se celebre el contrato y, en todo caso, al tiempo de efectuar el requerimiento previo de pago, que en caso de no producirse el pago en el término previsto para ello, los datos relativos al impago podrán ser comunicados a ficheros relativos al cumplimiento o incumplimiento de obligaciones dinerarias. 6.1.3. Notificación de la inclusión El “responsable del fichero común” deberá enviar una notificación respecto de los datos incluidos y la posibilidad de ejercitar los derechos ARCO, en el plazo de 74

Tratamientos especiales treinta días desde el registro de los datos. Dicha notificación se deberá realizar a través de un medio fiable, auditable e independiente de la entidad notificante, por cada deuda concreta y determinada con independencia de que ésta se tenga con el mismo o con distintos acreedores. Si la notificación ha sido objeto de devolución, no se podrá proceder al tratamiento de los datos referidos a ese interesado salvo que se trate de una devolución en la que el destinatario haya rehusado recibir el envío. 6.1.4. Conservación de los datos Puesto que sólo podrán conservarse en el fichero común datos que respondan con veracidad a la situación de la deuda en cada momento concreto, el pago o cumplimiento de la deuda implicará la cancelación inmediata de todos los datos relativos a la misma. Con independencia de esta obligación, en todo caso, los datos deberán ser cancelados cuando se hubieran cumplido seis años contados desde el vencimiento de la obligación. 6.1.5. Acceso a la información contenida en el fichero Los datos contenidos en el fichero común sólo podrán ser consultados por terceros cuando precisen enjuiciar la solvencia económica del afectado. Así pues el fichero podrá ser consultado en los siguientes supuestos: a) Que el afectado mantenga con el tercero algún tipo de relación contractual que aún no se encuentre vencida. b) Que el afectado pretenda celebrar con el tercero un contrato que implique el pago aplazado del precio. c) Que el afectado pretenda contratar con el tercero la prestación de un servicio de facturación periódica. No obstante, en los últimos dos supuestos los terceros deberán informar a los interesados de su derecho a consultar el fichero 6.1.6. Responsabilidad El acreedor deberá asegurarse de la concurrencia de los requisitos anteriormente expuestos siendo responsable de la inexistencia o inexactitud de los datos que haya facilitado para su inclusión en el fichero. 6.1.7. Ejercicio de los derechos ARCO A pesar de que existen disposiciones comunes que regulan el ejercicio de los derechos ARCO, en el caso de ficheros de solvencia patrimonial y crédito, el RLOPD ha establecido algunas particularidades. En relación con el ejercicio del derecho de acceso, habrá que distinguir dos supuestos: 75

La protección de datos personales: Soluciones en entornos Microsoft 1º La solicitud se dirige al responsable del fichero común, que deberá comunicar al interesado todos los datos relativos al mismo que obren en el fichero así como las evaluaciones y apreciaciones que sobre el afectado se hayan comunicado en los últimos seis meses y el nombre y dirección de los cesionarios. 2º La solicitud se dirige a cualquier otra entidad participante en el sistema, que deberá comunicar al interesado todos los datos relativos al mismo a los que ella pueda acceder, así como la identidad y dirección del responsable del fichero común. Sin embargo, en relación con el ejercicio de los derechos de rectificación y cancelación encontraríamos tres supuestos distintos: 1º La solicitud se dirige al responsable del fichero común, que debe trasladar dicha solicitud a la entidad que haya facilitado los datos, para que ésta la resuelva. Si no recibiese contestación por parte de la entidad en el plazo de siete días, deberá proceder a la rectificación o cancelación cautelar de los mismos. 2º La solicitud se dirige a quien haya facilitado los datos al fichero común que procederá a la rectificación o cancelación de los mismos en sus ficheros y a notificarlo al responsable del fichero común en el plazo de diez días, dando asimismo respuesta al interesado en los plazos establecidos por la LOPD. 3º La solicitud se dirige a otra entidad participante en el sistema, que no hubiera facilitado al fichero común los datos, por lo que deberá informar en el plazo máximo de diez días al interesado sobre este hecho, así como de la identidad y dirección del responsable del fichero común. 6.2. Tratamientos con fines de publicidad y de prospección comercial La LOPD es su artículo 30 establece que quienes se dediquen a la recopilación de direcciones, reparto de documentos, publicidad, venta a distancia, prospección comercial y otras actividades análogas, utilizarán nombres y direcciones u otros datos de carácter personal cuando los mismos figuren en fuentes accesibles al público o cuando hayan sido facilitados por los propios interesados u obtenidos con su consentimiento. El RLOPD desarrolla este artículo estableciendo que sólo podrán utilizar nombres y direcciones u otros datos de carácter personal cuando los mismos se encuentren en uno de los siguientes casos: a) Figuren en alguna de las fuentes accesibles al público definidas en la LOPD y el interesado no haya manifestado su negativa u oposición a que 76

Tratamientos especiales sus datos sean objeto de tratamiento para las actividades descritas en este apartado. b) Hayan sido facilitados por los propios interesados u obtenidos con su consentimiento para finalidades determinadas, explícitas y legítimas relacionadas con la actividad de publicidad o prospección comercial, habiéndose informado a los interesados sobre los sectores específicos y concretos de actividad respecto de los que podrá recibir información o publicidad. En el primer supuesto, es decir, cuando los datos proceden de fuentes accesibles al público, habrá que informar al interesado en cada comunicación que se le dirija del origen de los datos y de la identidad del responsable del tratamiento así como de los derechos que le asisten. 6.2.1. Campañas publicitarias Cuando una entidad quiere realizar una campaña publicitaria entre sus clientes, en principio será necesario el consentimiento de los mismos para recibir este tipo de comunicaciones. La campaña publicitaria puede ser realizada directamente por la entidad pero en múltiples ocasiones la entidad decide contratar a un tercero la realización de la misma, encomendándole el tratamiento de determinados datos. Así nos podríamos encontrar con diferentes supuestos: a) Cuando los parámetros identificativos de los destinatarios de la campaña sean fijados por la entidad que contrate la campaña, ésta será Responsable del tratamiento de los datos. b) Cuando los parámetros fueran determinados únicamente por la entidad o entidades contratadas, dichas entidades serán las Responsables del tratamiento. c) Cuando en la determinación de los parámetros intervengan ambas entidades, serán ambas Responsables del tratamiento. 6.2.2. Depuración de bases de datos El RLOPD ha regulado asimismo una práctica tan habitual como es la depura- ción de las bases de datos. De este modo, se considerará que existe una cesión o comunicación de datos, cuando dos o más entidades decidan constatar, sin consentimiento de los afectados, con fines de promoción o comercialización de sus productos o servicios y mediante un tratamiento cruzado de sus ficheros, quiénes ostentan la condición de clientes de una u otra o de varios de ellos. 6.2.3. Exclusión del envío de comunicaciones comerciales Tampoco se ha querido desaprovechar la oportunidad de regular la creación de ficheros de exclusión del envío de comunicaciones comerciales. De esta forma, 77

La protección de datos personales: Soluciones en entornos Microsoft los responsables a los que el titular de los datos o interesado haya manifestado su negativa a recibir publicidad podrán conservar los mínimos datos imprescindibles para identificarlo y adoptar las medidas necesarias que eviten el envío de publicidad. Asimismo, permite la creación de listas Robinson o ficheros comunes, de carácter general o sectorial, en los que sean objeto de tratamiento los datos de carácter personal que resulten necesarios para evitar el envío de comunicaciones comerciales a los interesados que manifiesten su negativa u oposición a recibir publicidad. 6.2.4. Ejercicio de derechos En los tratamientos para actividades de publicidad y prospección comercial también el Reglamento prevé algunas particularidades en el ejercicio de los derechos ARCO. Los interesados tendrán derecho a oponerse, previa petición y sin gastos, al tratamiento de los datos que les conciernan, en cuyo caso serán dados de baja del tratamiento, cancelándose las informaciones que sobre ellos figuren en aquél, a su simple solicitud. Deberá establecerse un medio sencillo y gratuito para oponerse al tratamiento, admitiendo su ejercicio mediante la llamada a un número telefónico gratuito o la remisión de un correo electrónico, o mediante los servicios de cualquier índole para la atención a sus clientes o el ejercicio de reclamaciones. En relación con los derechos de acceso, rectificación, cancelación y oposición, si el derecho se ejercitase ante una entidad que hubiese encargado a un tercero la realización de una campaña publicitaria, aquélla estará obligada, en el plazo de diez días, desde la recepción de la comunicación de la solicitud de ejercicio de derechos del afectado, a comunicar la solicitud al responsable del fichero a fin de que el mismo otorgue al afectado su derecho en el plazo de diez días desde la recepción de la comunicación, dando cuenta de ello al afectado. 6.3. Sistemas de videovigilancia El tratamiento de imágenes comprende la captación, grabación, transmisión, conservación y almacenamiento de las mismas, tanto a través de soportes físicos de carácter digital, como mediante soportes analógicos estructurados con arreglo a criterios personales. Con el fin de cumplir con lo dispuesto en la legislación vigente en materia de protección de datos de carácter personal en relación con el tratamiento de imágenes a través de cámaras o videocámaras con la finalidad de vigilancia, se seguirán las indicaciones que se detallan a continuación:  Inscripción del fichero: la grabación y conservación de imágenes captadas por cámaras o videocámaras de vigilancia, implica la creación de un fichero. Consecuencia de ello, se declarará ante la AEPD, con carácter previo a su puesta en funcionamiento, y quedará inscrito en el RGPD. 78

Tratamientos especiales  Información a los interesados: se colocarán en emplazamientos claramente visibles de las zonas videovigiladas tantos distintivos informativos como sean necesarios para garantizar que en todo momento los afectados conocen la existencia de videocámaras. Asimismo, se deberá tener a disposición de los interesados ejemplares de la nota informativa de VIDEOVIGILANCIA.  Conservación de las imágenes: las imágenes captadas sólo podrán ser almacenadas hasta que termine la finalidad para la que fueron captadas y nunca por un plazo superior a un mes desde que fueron capturadas.  Facilitación del ejercicio de los derechos a los interesados: si el afectado quiere ejercitar alguno de sus derechos (acceso, rectificación, cancelación u oposición), deberá remitir a la Compañía una solicitud en la que haga constar su identidad, a la que deberá adjuntar una fotografía reciente. MODELO DE CARTEL DE VIDEOVIGILANCIA (con grabación) NOMBRE ORGANIZACIÓN ZONA VIDEOVIGILADA LEY ORGÁNICA 15/1999, DE 13 DE DICIEMBRE, DE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL NOMBRE ORGANIZACIÓN le informa de los siguientes aspectos: 1. Por motivos de seguridad se han instalado cámaras de seguridad en el recinto de NOMBRE ORGANIZACIÓN. 2. Las imágenes grabadas formarán parte de un fichero que ha sido declarado ante la Agencia Española de Protección de Datos, utilizándose con la única finalidad de mantener la seguridad y controlar el acceso las instalaciones, cancelándose en el plazo máximo de un mes. Asimismo, sus datos podrán ser cedidos a las Fuerzas y Cuerpos de Seguridad del Estado. 3. Usted puede ejercitar sus derechos de acceso, rectificación, cancelación y oposición mediante solicitud por escrito y fotografía reciente dirigida a NOMBRE ORGANIZACIÓN, c/ XXXXXXXXXXX, CP XXXXX, CIUDAD. NOMBRE ORGANIZACIÓN le agradece su colaboración. Fecha, firma y sello 79

7 La autorregulación: los códigos tipo La aplicación de las obligaciones impuestas por la normativa vigente en materia de protección de datos de carácter personal no está resultando fácil. Las empresas, independientemente de la actividad que desarrollan, y, dentro de éstas, tanto los responsables de los ficheros que contienen datos personales como sus usuarios, se enfrentan, continuamente, a realidades complejas e importantes problemas a la hora de aplicar dicha normativa, suponiendo un gran esfuerzo hallar soluciones prácticas que permitan el desarrollo eficaz de su actividad. La autorregulación es una vía que puede resultar de gran ayuda para los responsables de los ficheros o tratamientos de datos de carácter personal inmersos en este confuso panorama, tratando de adaptar la aplicación de la normativa de protección de datos a las peculiaridades propias de cada sector de actividad a través de los denominados códigos tipo. La elaboración de estos códigos, así como la adhesión a los mismos por parte de los responsables de tratamientos, debe ser cada día más frecuente en todos los sectores. Pese a ello, en la actualidad, existe un desconocimiento generalizado en relación con estos códigos y, más en concreto, su existencia, qué son realmente y su naturaleza. Con carácter genérico y, en una primera aproximación, podríamos definir los códigos tipo como conjunto de normas de buena conducta, adoptados por entidades, generalmente pertenecientes al mismo sector, como modelos a seguir para el desarrollo de sus actividades profesionales; asimilables a los códigos deontológicos o de buena práctica profesional. Éstos constituyen una forma de complementar la regulación o, en algunos casos, suplir las lagunas o carencias de aquella, estableciendo, normalmente, medidas que no sólo respetan las previsiones legales sino que suponen garantías adicionales, reforzando el espíritu y finalidad de la Ley. 81

La protección de datos personales: Soluciones en entornos Microsoft Las actividades objeto de regulación por los códigos pueden ser de muy diversa naturaleza, dado que el fin perseguido en su elaboración se centra en predefinir pautas o estándares de actuación generales a tener en cuenta por los sujetos pertenecientes a un determinado sector. Al margen de los códigos tipo reguladores de otras materias concretas, se analizarán en este caso, aquellos que pretenden regular de forma unitaria, los tratamientos de datos de carácter personal realizados por personas físicas o jurídi- cas englobadas en el mismo sector de actividad. En este ámbito, la Directiva 95/46/CE, utilizando la denominación de códigos de conducta, establece la posibilidad de adoptar este tipo de códigos, requiriendo a la Comisión Europea y a los Estados miembros para fomentar su desarrollo: “los Estados miembros y la Comisión alentarán la elaboración de códigos de conducta destinados a contribuir, en función de las particularidades de cada sector, la correcta aplicación de las disposiciones nacionales adoptadas por los Estados miembros en aplicación de la presenta Directiva”. El Grupo de Trabajo Sobre la Protección de las Personas Físicas, en un Docu- mento de Trabajo adoptado el 14 de enero de 1998 29, estableció una definición para este tipo de códigos, denominándolos, en ese caso, códigos de autorregulación y expresándose en los siguientes términos: “cualquier conjunto de normas de protección de datos que se apliquen a una pluralidad de responsables del tratamiento que pertenezcan a la misma profesión o al mismo sector industrial, cuyo contenido haya sido determinado fundamentalmente por miembros del sector industrial o profesión en cuestión”. La LOPD, que contempla también la posibilidad de elaborar códigos tipo cuyo ámbito de aplicación se circunscriba a una sola empresa, se refiere a los códigos tipo en su artículo 32, indicando que son aquellos en los que se “establezcan las condiciones de organización, régimen de funcionamiento, procedimientos aplicables, normas de seguridad del entorno, programas o equipos, obligaciones de los implicados en el tratamiento y uso de la información personal, así como las garantías en su ámbito, para el ejercicio de los derechos de las personas con pleno respeto de los principios y disposiciones de la presenta Ley y sus normas de desarrollo”. Establece, además, la posibilidad de que contengan o no reglas operacionales detalladas de cada sistema particular y estándares técnicos de aplicación, de manera que, en el supuesto de que tales reglas no se incorporen directamente a los códigos, las instrucciones u órdenes que los establezcan deberán atenerse a los principios en ellos previstos. 29. Documento de Trabajo: Evaluación de la autorregulación industrial: ¿En qué casos realiza una contribución significativa al nivel de protección de datos en un país tercero ?, http:// europa.eu.int/comm/justice_home/fsj/privacy/docs/wpdocs/1998/wp7_es.pdf. 82

La autorregulación: los códigos tipo Analizaremos a continuación el objeto, la naturaleza, los sujetos habilitados para la adopción, el procedimiento de elaboración, el contenido, las ventajas, las garantías de cumplimiento, las obligaciones posteriores a su publicación, las ventajas que puede conllevar su adopción, así como los códigos que, a día de hoy, se encuentran registrados en el RGPD. 7.1. Objeto de los códigos tipo Los códigos tipo en materia de protección de datos de carácter personal tienen por objeto adecuar lo establecido en la normativa vigente en este ámbito a las peculiaridades de los tratamientos efectuados por quienes se adhieren a los mismos. A tal efecto, contendrán reglas o estándares específicos que permitan armonizar los tratamientos de datos efectuados por los adheridos, facilitar el ejercicio de los derechos de los afectados y favorecer el cumplimiento de lo dispuesto la LOPD y el RLOPD. 7.2. Naturaleza de los códigos tipo En relación con esta cuestión, la propia LOPD establece, únicamente, la posibilidad de formular códigos tipo y reconoce el carácter de códigos deontológicos o de buena práctica profesional de los mismos. Con base en ello, ya podíamos afirmar que su implementación y la adscripción a los mismos por parte de los profesionales son voluntarias. A pesar de constituir un instrumento de gran ayuda para cumplir la normativa vigente en materia de protección de datos, no son normas jurídicas vinculantes. Por su parte, el RLOPD nos recuerda este carácter de códigos deontológicos o de buena práctica profesional y que, únicamente, serán vinculantes para quienes se adhieran a los mismos. Debemos detenernos en este punto aclarando que los responsables de ficheros no están obligados a participar en la elaboración de este tipo de códigos y, una vez elaborados e inscritos, están, del mismo modo, facultados para elegir libremente sobre su adhesión o suscripción, además de no implicar dicha adhesión el cumplimiento de la LOPD y su normativa de desarrollo. No obstante, si un responsable se adhiere a un código tipo concreto, a partir de ese momento, queda obligado al cumplimiento de las disposiciones incluidas en el mismo y su incumplimiento podría ser sancionado por la entidad creada a estos efectos. Consecuencia de ello, el responsable suscriptor o adherido estará sometido a un control periódico por parte del citado órgano, que deberá verificar que cada una de las obligaciones aceptadas voluntariamente continúan siendo objeto de cumplimiento, resultando frecuente la creación de comités de control orientados a velar por el buen funcionamiento y aplicabilidad del código tipo. 83

La protección de datos personales: Soluciones en entornos Microsoft 7.3. Sujetos habilitados para la adopción de códigos tipo La Directiva 95/46/CE, además de autorizar a las asociaciones de profesionales, deja abierta la posibilidad a cualquier organización representante de otras categorías de responsables de tratamientos y, en transposición de ésta, el legislador español ha conferido dicha posibilidad a todos los responsables de tratamientos, ya sean de titularidad pública o privada, así como a las organizaciones en las que se agrupen, siempre que lo efectúen mediante acuerdos sectoriales, convenios administrativos o decisiones de empresas. Esto ha supuesto un cambio fundamental respecto de lo establecido en la LORTAD, dado que, si bien ésta no hacía alusión expresa a los sujetos habilitados para la adopción de códigos tipo, sí hacía referencia a los responsables de ficheros de titularidad privada, quedando excluidos, por tanto, todos los responsables de tratamientos de titularidad pública. El RLOPD no introduce ninguna novedad en este sentido, reconociendo igualmente la posibilidad de creación de códigos tipo por iniciativa de empresas, grupos de entidades pertenecientes a un mismo sector y Administraciones públicas y corporaciones de derecho público. 7.4. Procedimiento para la elaboración de códigos tipo La LOPD no contempla ningún procedimiento específico para la adopción de códigos tipo, existiendo por ello una laguna en este punto, posiblemente motivada por la propia naturaleza de estos códigos, cuya implementación es totalmente voluntaria, laguna que no ha sido cubierta por el RLOPD. Como consecuencia de ello, salvo los requisitos formales establecidos por la Ley 30/1992, de Régimen Jurídico de las Administraciones Públicas y del Procedimiento Administrativo Común (artículos 68 y 70) para la solicitud de inscripción de los códigos tipo, su procedimiento de elaboración se ajustará, en cada caso, a la voluntad de los sujetos intervinientes en el mismo. No obstante, el artículo 32.3 de la LOPD establece una obligación que se debe cumplir tras su elaboración, expresándose en los siguientes términos: “ser depositados e inscritos en el RGPD y, cuando corresponda, en los creados a estos efectos por las Comunidades Autónomas”. El Registro podrá denegar su inscripción cuando considere que no se ajusta a las disposiciones legales y reglamentarias sobre la materia, requiriendo, en este caso, el Director de la AEPD a los solicitantes a fin de que efectúen las correcciones oportunas. El RLOPD ha desarrollado la obligación de depósito y publicidad de los códigos tipo, estableciendo que para que estos puedan considerarse como tales deberán depositarse e inscribirse en el RGPD o, cuando corresponda, en el registro que fuera creado por las comunidades autónomas, que darán traslado para su inclusión al RGPD, así como la obligación de la AEPD de dar publicidad a los códigos tipo inscritos, preferentemente a través de medios informáticos o telemáticos. 84

La autorregulación: los códigos tipo 7.5. Contenido de los códigos tipo La LOPD no regula el contenido que tienen que tener estos códigos. Ante esta laguna la AEPD recogió en su página web los aspectos de fondo del contenido de estos códigos30. Se relaciona a continuación el contenido mínimo que, a tenor de lo expresado por la AEPD, deberían recoger:  Introducción. Se expresarán las razones que han conducido al desarrollo del código, enumerando los valores añadidos que aporta su cumplimien- to, a través de una exposición de motivos.  Ámbito de aplicación. El ámbito de aplicación responderá a la actividad de los responsables de ficheros que los suscriben, debiendo quedar perfectamente delimitado.  Principios específicos del sector que representa. El código tipo deberá incluir la aplicación de principios específicos en el sector que mejoren las previsiones legales, acotando estos principios y desarrollando el procedimiento de aplicación de los principios generales de protección de datos al caso concreto del sector representado.  Definiciones específicas. Deberá incluir las definiciones que amplíen conceptos de la Ley y, especialmente, definiciones de carácter técnico del sector involucrado.  Condiciones de organización y procedimientos. Entre otros aspectos, deberá singularizar los datos personales a tratar, identificar los posibles destinatarios de cesiones o transferencias internacionales y las leyes o previsiones que las amparan en el sector, delimitar las fuentes de recogida de los datos, permitir el ejercicio de los derechos de acceso, rectificación, cancelación y oposición en condiciones más favorables, estableciendo para ello el procedimiento que corresponda, así como incluir modelos para el ejercicio de estos derechos y cláusulas informativas para su introducción en los cuestionarios de recogida de los datos. Además, podrá incluir un sello de garantía identificativo del código tipo, que hará referencia a la vinculación al mismo.  Medidas de seguridad. Deberá indicar el nivel mínimo de medidas de seguridad que se van a aplicar y hacer una enumeración de las mismas, pudiendo establecer el compromiso de cumplimiento de un nivel de medidas de seguridad mas alto que el correspondiente a los ficheros objeto de tratamiento en el sector que elabora el código tipo.  Comunicaciones y transferencias internacionales de datos. Deberá analizar las diferentes situaciones que se puedan dar en el sector y el ámbito legal en el que se producen. 30. Vid. AEPD, Aspectos de fondo del contenido de un código tipo, https://www.agpd.es/ index.php?idSeccion=242. 85

La protección de datos personales: Soluciones en entornos Microsoft  Procedimiento de autorregulación y control. En relación con éste, resulta destacable el deber de aclarar que supone una vía opcional y que siempre se podrá acudir a la AEPD para presentar una reclamación ante el incumplimiento de la LOPD.  Régimen sancionador. Tendrá que establecer el régimen de sanciones por incumplimiento del código tipo.  Relación de adheridos. Contendrá la relación de adheridos, así como el compromiso del titular del código de comunicar altas, bajas o modificaciones de asociados a la Agencia.  Marco normativo. Deberá establecer el marco normativo general y el específico del sector, incluyendo todas las instrucciones y recomendaciones que sean aplicables al sector.  Conclusiones. Deberá contener un resumen de ventajas y/o garantías que ofrece el código a los titulares de los datos, modelos para el ejercicio de los derechos y un resumen de obligaciones que deben cumplir los responsables de los ficheros. El RLOPD ha cubierto la laguna de la LOPD, regulando el contenido mínimo que deben incluir los códigos tipo, tal y se detalla a continuación:  La delimitación clara y precisa de su ámbito de aplicación, las actividades a que el código se refiere y los tratamientos sometidos al mismo.  Las previsiones específicas para la aplicación de los principios de protec- ción de datos.  El establecimiento de estándares homogéneos para el cumplimiento por los adheridos al código de las obligaciones establecidas en la Ley Orgánica 15/1999, de 13 de diciembre.  El establecimiento de procedimientos que faciliten el ejercicio por los afectados de sus derechos de acceso, rectificación, cancelación y oposición.  La determinación de las cesiones y transferencias internacionales de datos que, en su caso, se prevean, con indicación de las garantías que deban adoptarse.  Las acciones formativas en materia de protección de datos dirigidas a quienes los traten, especialmente en cuanto a su relación con los afectados.  Los mecanismos de supervisión a través de los cuales se garantice el cumplimiento por los adheridos de lo establecido en el código tipo.  Cláusulas tipo para la obtención del consentimiento de los afectados al tratamiento o cesión de sus datos. 86

La autorregulación: los códigos tipo  Cláusulas tipo para informar a los afectados del tratamiento, cuando los datos no sean obtenidos de los mismos.  Modelos para el ejercicio por los afectados de sus derechos de acceso, rectificación, cancelación y oposición.  Modelos de cláusulas para el cumplimiento de los requisitos formales exigibles para la contratación de un encargado del tratamiento, en su caso. Este contenido deberá estar redactado en términos claros y accesibles y con suficiente grado de precisión. Al margen del contenido mínimo indicado, los códigos tipo podrán incluir cualquier otro compromiso adicional que asuman los adheridos para un mejor cumplimiento de la legislación vigente en materia de protección de datos. Además podrán contener cualquier otro compromiso que puedan establecer las entidades promotoras y, en particular, sobre:  La adopción de medidas de seguridad adicionales a las exigidas por la LOPD y el RLOPD.  La identificación de las categorías de cesionarios o importadores de los datos.  Las medidas concretas adoptadas en materia de protección de los menores o de determinados colectivos de afectados.  El establecimiento de un sello de calidad que identifique a los adheridos al código. Finalmente, en virtud de lo establecido en el artículo 76 del RLOPD, se deberá incorporar a los códigos tipo un anexo con la relación de adheridos, que tendrá que mantenerse actualizada y a disposición de la AEPD. En el plazo de un año desde la entrada en vigor del RLOPD deberán notificarse a la AEPD las modificaciones que resulten necesarias en los códigos tipo inscritos en el RGPD para adaptar su contenido a lo expuesto anteriormente. 7.6. Ventajas derivadas de la creación de códigos tipo Uno de los aspectos que debe tener en cuenta todo responsable de ficheros son las ventajas de distinta índole que la adopción de este tipo de códigos puede conllevar, como garantía frente a los titulares de los datos de carácter personal y a la propia AEPD, así como, de forma interna, a la organización del responsable del tratamiento. En primer lugar, para los titulares de datos personales -ya consten en los ficheros del responsable del tratamiento o se trate de sujetos que, potencialmente, pueden estar interesados en la actividad desarrollada por el mismo-, la adhesión a 87

La protección de datos personales: Soluciones en entornos Microsoft un código tipo en materia de protección de datos podrá ser interpretada como síntoma de conocimiento de las obligaciones impuestas por la normativa reguladora de esta materia y el modo más adecuado de llevarlas a la práctica en su sector concreto, demostrando el respeto por el derecho de los particulares a preservar sus datos personales. En aras a la consecución de la confianza de los titulares de los datos, lo más frecuente es que la suscripción por parte de los responsables de tratamientos de datos de carácter personal a estos códigos traiga como consecuencia la posibilidad de utilizar un sello de garantía que los identificará como tales, con la finalidad de que produzca en los titulares de los datos el efecto anteriormente expuesto. En relación con la AEPD, dado que, como ya se ha reflejado anteriormente, los códigos tipo deben ser inscritos en el RGPD, previa revisión de su adecuación a las disposiciones legales y reglamentarias sobre la materia, si con posterioridad la Agencia considera que una actuación acorde con lo establecido en el código tipo suscrito es sancionable, el responsable podrá argumentar la doctrina de los actos propios, a fin de que dicha práctica no sea considerada como contraria a la Ley. Del mismo modo, la adhesión a un código tipo tiene repercusiones internas para el propio responsable del tratamiento de datos, facilitándole información acerca de la manera de actuar en el proceso de tratamiento de los datos personales, especialmente, en relación con aquellos aspectos que generan a todos los profesionales una mayor inseguridad en sus actuaciones. 7.7. Garantías del cumplimiento de los códigos tipo El RLOPD establece la obligación de incluir en los códigos tipo procedimientos de supervisión independientes para garantizar el cumplimiento de las obligaciones asumidas por los adheridos, y establecer un régimen sancionador adecuado, eficaz y disuasorio. Estos procedimientos deberán garantizar:  La independencia e imparcialidad del órgano responsable de la supervisión.  La sencillez, accesibilidad, celeridad y gratuidad para la presentación de quejas y reclamaciones ante dicho órgano por los eventuales incumplimientos del código tipo.  El principio de contradicción.  Una graduación de sanciones que permita ajustarlas a la gravedad del incumplimiento. Esas sanciones deberán ser disuasorias y podrán implicar la suspensión de la adhesión al código o la expulsión de la entidad adherida. Asimismo, podrá establecerse, en su caso, su publicidad.  La notificación al afectado de la decisión adoptada. Del mismo modo, podrán contemplar procedimientos para la determinación de medidas reparadoras en caso de haberse causado un perjuicio a los afectados como consecuencia del incumplimiento del código tipo. 88

La autorregulación: los códigos tipo 7.8. Obligaciones posteriores a la inscripción del código tipo Una vez publicado un código tipo, las entidades promotoras o los órganos, personas o entidades que al efecto se designen en el mismo tendrán que cumplir las siguientes obligaciones establecidas en el RLOPD:  Mantener accesible al público la información actualizada sobre las entidades promotoras, el contenido del código tipo, los procedimientos de adhesión y de garantía de su cumplimiento y la relación de adheridos a la que se refiere el artículo anterior. Esta información deberá presentarse de forma concisa y clara y estar permanentemente accesible por medios electrónicos.  Remitir a la AEPD una memoria anual sobre las actividades realizadas para difundir el código tipo y promover la adhesión a éste, las actuaciones de verificación del cumplimiento del código y sus resultados, las quejas y reclamaciones tramitadas y el curso que se les hubiera dado y cualquier otro aspecto que las entidades promotoras consideren adecuado destacar. Cuando se trate de códigos tipo inscritos en el registro de una autoridad de control de una comunidad autónoma, la remisión se realizará a dicha autoridad, que dará traslado al RGPD.  Evaluar periódicamente la eficacia del código tipo, midiendo el grado de satisfacción de los afectados y, en su caso, actualizar su contenido para adaptarlo a la normativa general o sectorial de protección de datos existente en cada momento. 7.9. Códigos tipo inscritos A día de hoy, únicamente se han inscrito doce códigos tipo, constando dos de ellos en el RGPD con anterioridad a la entrada en vigor de la LOPD y en su totalidad con carácter previo a la entrada en vigor del RLOPD. A continuación, analizaremos brevemente cada uno de ellos, centrándonos en su objeto y ámbito de aplica- ción, dado que es suficiente para conocer su espíritu y entrar en más detalles nos obligaría a extendernos demasiado. Para ello, se seguirá un orden cronológico por fecha de inscripción del más antiguo al más reciente. Código Tipo de Telefónica de España, S.A. Fecha Inscripción: 20/12/1994 (modificado en diciembre de 2003). Siendo el primer código inscrito en el RGPD, concretó su objeto en establecer los principios a los que se sujeta la actuación de Telefónica de España en materia de protección de datos, regulando las condiciones organizativas y técnicas de los ficheros existentes en la actualidad o que puedan crearse en el futuro, así como las condiciones para la recogida y utilización de los datos, determinando el procedimiento a seguir en el ejercicio de los derechos de acceso, rectificación, cancelación y 89

La protección de datos personales: Soluciones en entornos Microsoft oposición por los afectados, así como los derechos específicos de los usuarios en el sector de las telecomunicaciones. Este código resulta aplicable a los tratamientos de datos de carácter personal que se efectúen en España por Telefónica de España, sirviendo de punto de referencia para el resto de las empresas del Grupo, como parámetros deseables a los que se debe tender aun cuando no exista legislación de protección de datos en los países en los que estén establecidas. Código Tipo de Asociación Multisectorial de la Información (ASEDIE). Fecha de inscripción: 15/09/1999. Constituye el objeto de este código establecer las condiciones de organización, régimen de funcionamiento, procedimientos aplicables, normas de seguridad del entorno, obligaciones de los implicados en el tratamiento y uso de la información personal, así como las garantías para el ejercicio de los derechos de las personas, en su ámbito; resultando de aplicación a las relaciones que mantengan las empresas asociadas a la ASEDIE (Sector de Información Comercial) con las personas objeto de informes comerciales, con los usuarios de los mismos, así como a las relaciones que dichos asociados mantengan entre sí y con terceras personas, empresas, entidades u organismos relacionados de forma directa o indirecta con el ejercicio de la actividad de información comercial. Del mismo modo, se aplica a los ficheros automatizados que contengan datos de carácter personal y de los que sean responsables las empresas asociadas a ASE- DIE, cuya finalidad sea la prestación de servicios de información sobre la solvencia patrimonial y crédito. Código Tipo de Fichero Histórico de Seguros del Automóvil (UNESPA). Fecha de inscripción: 11/10/2000. En relación con su objeto, este código se expresa en los términos que se recogen a continuación: “El Fichero Histórico, cumple con la finalidad descrita en el artículo 24.3, párrafo segundo de la Ley 33/1995 en cuanto a fichero de colaboración estadístico actuarial para la tarificación y selección de riesgos, recogiendo información sobre los contratos de seguros del automóvil que el tomador ha suscrito en los últimos cinco años así como de los siniestros vinculados a dichos contratos. Igualmente, el Fichero contribuirá a promover la transparencia en el mercado del seguro del automóvil y la aplicación equitativa y suficiente de las tarifas a los riesgos asegurados. Los asegurados tendrán un mayor acceso al conjunto de ofertas del sector y podrán buscar la que más se adecue a sus necesidades al permitírsele tener conocimiento de sus propios datos de siniestralidad, factor esencial para el cálculo de la prima del seguro. Por su parte las entidades aseguradoras tendrán una información exacta y precisa del riesgo que complementará la facilitada por el tomador en la solicitud de seguro, en su deber de declaración del riesgo. 90

La autorregulación: los códigos tipo Se entiende por siniestro el acaecimiento del hecho que, previsto en el contrato, es susceptible de dar lugar al pago de la indemnización por la entidad aseguradora con cargo a la póliza suscrita por el tomador.” Su ámbito de aplicación se extiende al responsable del fichero, la empresa de servicios de tratamiento automatizado y todas las entidades aseguradoras autorizadas para operar en España en el ramo de responsabilidad civil de automóviles, sean o no asociadas a UNESPA, teniendo como único requisito imprescindible que estén inscritas en el Registro Especial de la Dirección General de Seguros. Código Tipo de La Asociación Nacional de Fabricantes (ANF). Fecha de inscripción: 21/12/2001. El presente código arbitra un sistema, cuyo seguimiento asegura a los adheridos al mismo el pleno cumplimiento de sus obligaciones en materia de protección de datos de carácter personal. Podrán suscribir este código todas las empresas o profesionales adheridos a la ANF, resultando aplicable a los datos de carácter personal contenidos en ficheros sobre clientes. Código Tipo de Agrupación Catalana de Establecimientos Sanitarios (ACES). Fecha de inscripción: 28/12/2001. La ACES es una asociación empresarial que tiene como finalidad el asesoramien- to, defensa y representación de sus miembros, procurando en todo momento la optimización de métodos de trabajo y objetivos, en general, tendiendo fundamentalmente a la promoción de sus intereses sociales, laborales, profesionales y culturales. Atendiendo a dicha finalidad se creó este código, cuyo ámbito de aplicación abarca tanto a sus socios de número -personas físicas o jurídicas que siendo de titularidad privada desarrollen su actividad principal dentro del sector sanitario- como a los socios de honor -personas o entidades que presten o hayan prestado a la Agrupación o a la Sanidad ayudas o colaboraciones destacadas-, siempre previo acuerdo de la Asamblea General de ACES a propuesta de la Junta Directiva. Código Tipo de Unió Catalana D’Hospitals (UNIÓ). Fecha de inscripción: 12/07/2002 (modificado en julio de 2004). La indiscutible y, legalmente reconocida, naturaleza sensible de los datos personales concernientes a la salud unida a la posibilidad de establecer códigos tipo, arrastraron a la UNIÓ a utilizar este instrumento con la finalidad de que los adheridos a este código preserven de cualquier violación la privacidad de las personas físicas y garanticen su autodeterminación informativa. En relación con su ámbito subjetivo de aplicación, podemos afirmar que éste se extiende, no sólo a los asociados que manifiesten de forma expresa su adhesión al mismo, sino también a aquellas entidades no asociadas pero que, reuniendo las condiciones para poder serlo, con implantación territorial en cualquier territorio del estado, manifiesten su voluntad de adhesión al código de forma expresa. 91

La protección de datos personales: Soluciones en entornos Microsoft Por su parte, el ámbito objetivo se centra en el tratamiento de datos de carácter personal contenidos en los ficheros de pacientes/historia clínica, sea cual sea su soporte y modalidad de tratamiento. Código Tipo de Comercio Electrónico y Publicidad Interactiva (AUTOCONTROL-AECE-IAB SPAIN). Fecha Inscripción: 07/11/2002. Nos encontramos ante un sector extremadamente dinámico y en permanente evolución, donde las posibilidades de obsolescencia normativa son mayores que en cualquier otro. Adaptarse a los cambios previendo soluciones a estos problemas de regulación es uno de los objetivos que inspiran el presente código, aplicable a la publicidad y al comercio electrónico realizados a través de medios electrónicos de comunicación a distancia, por personas físicas o jurídicas con establecimiento permanente en España o dirigidos de forma específica al mercado español. Código Tipo de Odontólogos y Estomatólogos de España. Fecha de inscripción: 12/07/2004. Mediante la elaboración de este código el Ilustre Consejo de Colegios Oficiales de Odontólogos y Estomatólogos de España pretende ofrecer garantías para las personas cuyos datos de carácter personal se traten por los profesionales colegiados en los Colegios Oficiales de Odontólogos y Estomatólogos de España, fijando reglas específicas para el tratamiento de datos de carácter personal en el ámbito del ejercicio de esta profesión; todo ello, sin perjuicio de la aplicación de las obligaciones y deberes genéricos establecidos por las normas vigentes en materia de protec- ción de datos de carácter personal aplicables a todas las personas, entidades o empresas titulares de ficheros que contengan datos personales. Su ámbito de aplicación se extiende a todos los servicios profesionales prestados por odontólogos y estomatólogos colegiados en los Colegios Oficiales de Odontólogos y Estomatólogos españoles, que se adhieran al código, ya sean prestados en clínicas y/o consultorios dentales individuales o colectivos. Código Tipo Universidad de Castilla-La Mancha. Fecha de inscripción: 14/07/2004. Esta institución académica, que ha mostrado siempre una especial sensibilidad por los temas relacionados con la seguridad informática y el respeto a todo lo relacionado con la protección de datos de carácter personal, ha sido la primera institución pública en implementar un código tipo en esta materia, con la pretensión de cumplir de la forma más sencilla y segura con la legislación, a través de un documento único que reúna todos los documentos esenciales, y servir de referente al resto de universidades españolas, contribuyendo, al mismo tiempo, al conocimiento de este derecho fundamental. Se ha establecido como objeto de éste código garantizar y proteger, en lo que concierne al tratamiento de los datos personales, las libertades públicas y los dere- 92

La autorregulación: los códigos tipo chos fundamentales de las personas físicas y, especialmente, de su honor e intimidad personal y familiar, resultando de aplicación a los datos de carácter personal que figuren en ficheros automatizados de la Universidad de Castilla-La Mancha y a toda modalidad de uso posterior de estos datos. Código Tipo de la Asociación Catalana de Recursos Asistenciales (ACRA). Fecha de inscripción: 27/12/2004. Este código ha establecido la siguiente distinción en relación con su objeto: A. Respecto a los responsables de los ficheros: las condiciones de utilización y conservación de los datos de carácter personal, el régimen de cesión o comunicación, las directrices de la normativa interna de los asociados adheridos al código, la creación de un Comité de protección de datos en el seno de la ACRA y un régimen de infracciones y sanciones. B. Respecto a los titulares de los datos de carácter personal: definir y delimitar los procedimientos para ejercer los derechos de los titulares de los datos de carácter personal en aras a obtener las mayores garantías de estos derechos, tanto en lo que ser refiere a su difusión como a su ejercicio y la protección, en lo que concierne al tratamiento de los datos de carácter personal, de las libertades públicas y los derechos fundamentales de los residentes en cualquiera de los centros o establecimientos asociados y adheridos al código, así como, su derecho al honor e intimidad personal y familiar. En términos generales, es aplicable a los datos de carácter personal de los residentes registrados en soportes automatizados o no, que los hagan susceptibles de tratamiento, y a toda modalidad de uso posterior de los mismos, de los que sean responsables los asociados de ACRA que se adhieran al código tipo. Código Tipo del Sector de la Intermediación Inmobiliaria. Asociación Empre- sarial de Gestión Inmobiliaria (AEGI). Fecha de inscripción: 29/12/2004. La AEGI, conocedora de la problemática que en cuanto al tratamiento de datos de carácter personal presenta el sector de la gestión inmobiliaria, consideró imprescindible el establecimiento de un marco que recoja un conjunto de normas de auto- rregulación que garantice que el sector cumple con las previsiones que la LOPD y sus reglamentos establecen, lo que debe traducirse en un beneficio de imagen y gestión hacia el cliente, estableciendo como ámbito de aplicación, en general, los tratamientos efectuados por las empresas adheridas para la prestación de sus servicios de gestión inmobiliaria y, en concreto, los siguientes tratamientos: a) Tratamien- tos de datos destinados a captar clientes para compra, venta o alquiler de inmuebles (cliente potencial), b) tratamientos de datos involucrados directamente en operaciones de compraventa y/o alquiler de inmuebles o destinadas a la concreción futura de las mismas (fases previas o de reserva e intermediación concretada o no), c) tratamientos de datos relacionados en todo o en parte con la gestión inmobiliaria, 93

La protección de datos personales: Soluciones en entornos Microsoft como pudieran ser la gestión de la contratación de los suministros necesarios para la vivienda, de la financiación necesaria para la adquisición o arrendamiento de un inmueble (sea como mera intermediación o servicio propio), prestación de servicios de rehabilitación u obras en inmuebles, d) aquellos derivados de operaciones de promoción o construcción inmobiliaria en la parte que concierne a las acciones destinadas a la venta o arrendamiento de las viviendas construidas y e) cualesquiera comprendidos en el ámbito de la gestión inmobiliaria. Código Tipo Veraz-Persus. Soluciones Veraz ASNEF-EQUIFAX, S. L. Fecha de inscripción: 19/12/2006. El objeto de este código tipo es establecer las condiciones de organización y régimen de funcionamiento del fichero Veraz-Persus, con el objeto de ofrecer a los beneficiarios unas garantías más amplias que las contenidas en la normativa dictada en materia de protección de datos de carácter personal. El fichero Veraz-Persus, es un fichero de auto-inclusión en el que cualquier persona, por si misma, o a través de su tutor legal, podrá solicitar su incorporación con el objeto de evitar el uso fraudulento de sus datos personales por terceros en perjuicio de su identidad, solvencia y patrimonio económico. Después de este análisis de la figura de los códigos tipo en materia de protec- ción de datos y, ya para finalizar, debemos insistir en que, si bien éstos no tienen carácter normativo, sino, como ya se ha indicado, de códigos deontológicos o de buena práctica profesional, constituyen un importante instrumento para facilitar el cumplimiento de la normativa de protección de datos de carácter personal, que como decíamos al comienzo, está resultando muy complejo y requiriendo un gran esfuerzo por parte de las entidades o personas físicas a las que les resulta de obligado cumplimiento la citada normativa. 94

8 Infracciones y sanciones 8.1. Los responsables El artículo 5 de la LOPD define como Responsables a los Responsables de los Ficheros y los Encargados de los Tratamientos, que estarán sujetos al régimen sancionador. Es Responsable del Fichero o del Tratamiento la “persona física o jurídi- ca, de naturaleza pública o privada, u órgano administrativo, que sólo o conjuntamente con otros decida sobre la finalidad, contenido y uso del tratamiento, aunque no lo realizase materialmente. Podrán ser también responsables del fichero o del tratamiento los entes sin personalidad jurídica que actúen en el tráfico como sujetos diferenciados.” Es Encargado del Tratamiento la “persona física o jurídica, de naturaleza pública o privada, u órgano administrativo, que sólo o conjuntamente con otros, trate datos personales por cuenta del responsable del tratamiento o responsable del fichero, como consecuencia de la existencia de una relación jurídica que le vincula con el mismo y delimita el ámbito de su actuación para la prestación de un servicio. Podrán ser también encargados del tratamiento los entes sin personalidad jurídica que actúen en el tráfico como sujetos diferenciados.” 8.2. Las infracciones: tipos En materia de Protección de Datos, la LOPD (Art. 44) define tres tipos de infracciones: leves, graves y muy graves. 8.2.1. Leves Son infracciones leves: A. No atender, por motivos formales, la solicitud del interesado de rectifica- ción o cancelación de los datos personales objeto de tratamiento cuando legalmente proceda. 95

La protección de datos personales: Soluciones en entornos Microsoft B. No proporcionar la información que solicite la AEPD en el ejercicio de las competencias que tiene legalmente atribuidas, en relación con aspectos no sustantivos de la protección de datos. C. No solicitar la inscripción del fichero de datos de carácter personal en el RGPD, cuando no sea constitutivo de infracción grave. D. Proceder a la recogida de datos de carácter personal de los propios afectados sin proporcionarles la información que señala el artículo 5 de la LOPD. E. Incumplir el deber de secreto establecido en el artículo 10 de la LOPD, salvo que constituya infracción grave. 8.2.2. Graves Son infracciones graves: A. Proceder a la creación de ficheros de titularidad pública o iniciar la recogida de datos de carácter personal para los mismos, sin autorización de disposición general, publicada en el «Boletín Oficial del Estado» o diario oficial correspondiente. B. Proceder a la creación de ficheros de titularidad privada o iniciar la recogida de datos de carácter personal para los mismos con finalidades distintas de las que constituyen el objeto legítimo de la empresa o entidad. C. Proceder a la recogida de datos de carácter personal sin recabar el consentimiento expreso de las personas afectadas, en los casos en que éste sea exigible. D. Tratar los datos de carácter personal o usarlos posteriormente con concul- cación de los principios y garantías establecidos en la LOPD o con incumplimiento de los preceptos de protección que impone el RLOPD, cuando no constituya infracción muy grave. E. El impedimento o la obstaculización del ejercicio de los derechos de acceso y oposición y la negativa a facilitar la información que sea solicitada. F. Mantener datos de carácter personal inexactos o no efectuar las rectificaciones o cancelaciones de los mismos que legalmente procedan cuando resulten afectados los derechos de las personas que la LOPD ampara. G. La vulneración del deber de guardar secreto sobre los datos de carácter personal incorporados a ficheros que contengan datos relativos a la comisión de infracciones administrativas o penales, Hacienda Pública, servicios financieros, prestación de servicios de solvencia patrimonial y 96

Infracciones y sanciones crédito, así como aquellos otros ficheros que contengan un conjunto de datos de carácter personal suficientes para obtener una evaluación de la personalidad del individuo. H. Mantener los ficheros, locales, programas o equipos que contengan datos de carácter personal sin las debidas condiciones de seguridad que establece el RLOPD. I. No remitir a la AEPD las notificaciones previstas en esta Ley o en sus disposiciones de desarrollo, así como no proporcionar en plazo a la misma cuantos documentos e informaciones deba recibir o sean requeridos por aquél a tales efectos. J. La obstrucción al ejercicio de la función inspectora. K. No inscribir el fichero de datos de carácter personal en el RGPD, cuando haya sido requerido para ello por el Director de la AEPD. L. Incumplir el deber de información que se establece en los artículos 5, 28 y 29 de la LOPD, cuando los datos hayan sido recabados de persona distinta del afectado. 8.2.3. Muy graves Son infracciones muy graves: A. La recogida de datos en forma engañosa y fraudulenta. B. La comunicación o cesión de los datos de carácter personal, fuera de los casos en que estén permitidas. C. Recabar y tratar datos de ideología, afiliación sindical, religión y creencias cuando no medie el consentimiento expreso del afectado; recabar y tratar datos de origen racial, a la salud y a la vida sexual cuando no lo disponga una Ley o el afectado no haya consentido expresamente, o violentar la prohibición de crear ficheros con la finalidad exclusiva de almacenar datos de carácter personal que revelen la ideología, afiliación sindical, religión, creencias, origen racial o étnico, o vida sexual. D. No cesar en el uso ilegítimo de los tratamientos de datos de carácter personal cuando sea requerido para ello por el Director de la AEPD o por las personas titulares del derecho de acceso. E. La transferencia temporal o definitiva de datos de carácter personal que hayan sido objeto de tratamiento o hayan sido recogidos para someterlos a dicho tratamiento, con destino a países que no proporcionen un nivel de protección equiparable sin autorización del Director de la AEPD. 97

La protección de datos personales: Soluciones en entornos Microsoft F. Tratar los datos de carácter personal de forma ilegítima o con menosprecio de los principios y garantías que les sean de aplicación, cuando con ello se impida o se atente contra el ejercicio de los derechos fundamentales. G. La vulneración del deber de guardar secreto sobre los datos de carácter personal de ideología, afiliación sindical, religión, creencias, origen racial, salud y vida sexual, así como los que hayan sido recabados para fines policiales sin consentimiento de las personas afectadas. H. No atender, u obstaculizar de forma sistemática el ejercicio de los derechos de acceso, rectificación, cancelación u oposición. I. No atender de forma sistemática el deber legal de notificación de la inclusión de datos de carácter personal en un fichero. 8.3. Prescripción El artículo 47 de la LOPD establece los plazos de prescripción:  Las infracciones muy graves prescribirán a los tres años, las graves a los dos años y las leves al año.  El plazo de prescripción comenzará a contarse desde el día en que la infracción se hubiera cometido.  Interrumpirá la prescripción la iniciación, con conocimiento del interesado, del procedimiento sancionador, reanudándose el plazo de prescripción si el expediente sancionador estuviere paralizado durante más de 6 meses por causa no imputable al presunto infractor. 8.4. La infracción continuada Se considera Infracción Continuada aquella infracción en las que su consuma- ción se proyecta en el tiempo más allá de los hechos iniciales, extendiéndose hasta los finales. Es decir, que hasta que deja de producirse la lesión de los derechos del afectado que se comete mientras se mantienen datos de carácter personal inexactos en un registro, y el periodo de prescripción no comienza hasta que son eliminados o rectificados. Según la sentencia de la Audiencia Nacional de 7 de noviembre de 2002, la infracción es la prevista en el artículo 44.3.f): “Mantener datos de carácter personal inexactos o no efectuar las rectificaciones o cancelaciones de los mismos que legalmente procedan cuando resulten afectados los derechos de las personas que la presente Ley ampara.” El plazo de prescripción comienza a contarse desde el día en que la infracción se hubiera cometido, y la Audiencia Nacional considera que “…la infracción se 98

Infracciones y sanciones comete mientras se mantienen los datos en el registro, quebrando la correspondencia que debe mediar entre dichos datos y la situación real del afectado…”. 8.5. Las sanciones 8.5.1. Las sanciones en el sector privado 8.5.1.1. Las sanciones de la lopd En materia de Protección de Datos, la LOPD (Art. 45) define 3 tipos de sanciones:  Las infracciones leves serán sancionadas con multa de 601,01 € a 60.101,20 €.  Las infracciones graves serán sancionadas con multa de 60.101,20 € a 300.506,10 €.  Las infracciones muy graves serán sancionadas con multa de 300.506,10 € a 601.012,10 €. La cuantía de las sanciones se graduará atendiendo a la naturaleza de los derechos personales afectados, el volumen de los tratamientos efectuados, los beneficios obtenidos, el grado de intencionalidad, la reincidencia, los daños y perjuicios causados a las personas interesadas y a terceras personas, y a cualquier otra circunstancia que sea relevante para determinar el grado de antijuridicidad y de culpabilidad presentes en la concreta actuación infractora. También hay que tener en cuenta que habitualmente en un Procedimiento Sancionador se recogen varias infracciones, por lo que las sanciones son acumulativas, lo que implica que el importe total de las sanciones puede superar los 601.012,10 €. ¿Cuándo se aplica la posible rebaja del Art. 45.5 de la LOPD? Si, en razón de las circunstancias concurrentes, se apreciara una cualificada disminución de la culpabilidad del imputado o de la antijuridicidad del hecho, el órgano sancionador establecerá la cuantía de la sanción aplicando la escala relativa a la clase de infracciones que preceda inmediatamente en gravedad a aquella en que se integra la considerada en el caso de que se trate. La Audiencia Nacional31 establece que “sólo en los casos en los que la culpabilidad y la antijuricidad resulten sustancialmente atenuadas atendidas las circunstancias del caso concreto, de forma que repugne a la sensibilidad jurídica… la imposición de la sanción correspondiente al grado… lo cual puede darse, por excepción, en casos muy extremos y concretos.” Inmovilización de ficheros. Existe una sanción adicional desarrollada por el RLOPD (Art. 121) que establece que en caso de infracción muy grave por la utilización o cesión ilícita de los datos 31. Sentencia de la Audiencia Nacional, Sala de lo Contencioso-Administrativo, Sección 1ª, de 15 de noviembre 2002 (RJCA 2003, 16). 99

La protección de datos personales: Soluciones en entornos Microsoft de carácter personal en la que se impida gravemente o se atente de igual modo contra el ejercicio de los derechos de los ciudadanos y el libre desarrollo de la personalidad que la Constitución y las leyes garantizan, el Director de la AEPD podrá, en cualquier momento del procedimiento, requerir a los responsables de ficheros o tratamientos de datos de carácter personal, tanto de titularidad pública como privada, la cesación en la utilización o cesión ilícita de los datos. Este requerimiento deberá ser atendido en el plazo improrrogable de tres días, durante el cual el responsable del fichero podrá formular las alegaciones que tenga por convenientes en orden al levantamiento de la medida. Si el requerimiento fuera desatendido, el Director podrá, mediante resolución motivada, acordar la inmovilización de tales ficheros o tratamientos, a los solos efectos de restaurar los derechos de las personas afectadas. TABLA EVOLUCIÓN DE LAS SANCIONES Y LOS PROCEDIMIENTOS 2002-2007. Fuente: Memorias de la AEPD 2002-2007. Elaboración: HELAS CONSULTORES. 8.5.1.2.Las sanciones de la LSSICE El artículo 6 de la Ley 56/2007, de 28 de diciembre, de Impulso de la Sociedad de la Información (LISI) establece como autoridad sancionadora del incumplimien- to de algunos preceptos de la Ley 34/2002, de 11 de julio, de Servicios de la Socie- dad de la Información y de Comercio Electrónico (LSSICE) a la AEPD. En particular, corresponderá a la AEPD la imposición de sanciones por la comisión de las infracciones tipificadas en los artículos 38.3, c), d) i) y 38.4 d) g) h) de la LSSICE, que se detallan a continuación: 100

Infracciones y sanciones Infracciones Graves:  El envío masivo de comunicaciones comerciales por correo electrónico u otro medio equivalente, o el envío en 1 año de más de 3 comunicaciones comerciales no solicitadas o consentidas.  El incumplimiento de establecer procedimientos para la revocación del consentimiento.  El incumplimiento de las obligaciones de información o de establecimien- to de un procedimiento de rechazo de tratamiento de datos (Art. 22.2). Infracciones Leves:  El envío de comunicaciones comerciales por correo electrónico u otro medio de comunicación electrónica equivalente cuando en dichos envíos no se cumplan los requisitos establecidos (derechos de los destinatarios de comunicaciones comerciales, Art. 21) y no constituya infracción grave.  El incumplimiento de las obligaciones de información o de establecimien- to de un procedimiento de rechazo del tratamiento de datos (validez y eficacia de los contratos celebrados por vía electrónica, Art. 22), cuando no constituya una infracción grave.  El incumplimiento de la obligación del prestador de servicios en relación con los procedimientos para revocar el consentimiento prestado por los destinatarios cuando no constituya infracción grave. 8.5.2. Las sanciones en el sector público La LOPD (Art. 46) desarrolla las infracciones de las Administraciones Públicas, donde la peculiaridad principal es que no conllevan sanción económica, diferen- ciándose así de las entidades privadas.  Cuando las infracciones fuesen cometidas en ficheros de los que sean responsables las Administraciones Públicas, el Director de la AEPD 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.  El Director de la AEPD 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.  El Director de la AEPD comunicará al Defensor del Pueblo las actuaciones que efectúe y las resoluciones que dicte al amparo de los apartados anteriores. 101

La protección de datos personales: Soluciones en entornos Microsoft 8.6. El procedimiento sancionador La LOPD establece que el procedimiento sancionador se desarrollará por vía reglamentaria, y el RLOPD establece los procedimientos relativos al ejercicio de la potestad sancionadora. Cualquier actuación que sea contraria a las exigencias contenidas en la LOPD puede ser objeto de reclamación ante la Agencia, sin perjuicio de que se pueda interponer denuncia ante los Tribunales de Justicia. 8.6.1. Procedimiento sancionador El procedimiento sancionador se inicia normalmente como consecuencia de una denuncia. La práctica habitual es que previamente se informe a la empresa responsable de los ficheros de la inspección a realizar, indicando día y hora en que se personarán los inspectores, pero sin explicar el motivo de la denuncia ni identificar al denunciante. En empresas pequeñas, para no favorecer la eliminación de información, las inspecciones se realizan sin previo aviso. Los inspectores, que tienen la considera- ción de autoridad pública, deben acreditar su personalidad y mostrar la autoriza- ción de entrada expedida por el Director de la AEPD. Por su parte, el responsable del fichero tiene la obligación de facilitar la actividad inspectora, siendo una infrac- ción grave su obstrucción. También se han iniciado procedimientos sancionadores cuando tras una denuncia que afecta a una administración pública, la AEPD ha recabado informa- ción de dicho organismo, sin realizar inspección presencial, y basándose en las respuestas ha deducido que se habían realizado actividades susceptibles de ser sancionables. Los inspectores (siempre dos, inspector y subinspector) podrán solicitar la exhibición de documentos, inspeccionar equipos físicos y lógicos, y acceder a los locales donde se encuentren instalados. La inspección termina con el Acta de Inspección que ha de firmar el responsable del fichero. Es importante revisar el contenido de dicha acta, porque el expediente sancionador se basará en ella. Si tras la inspección, se comprueba que se ha cometido alguna infracción, se abrirá procedimiento sancionador por acuerdo del Director de la Agencia Española de Protección de Datos. El contenido de este acuerdo debe ser el siguiente:  Designación de instructor, con la indicación de la posibilidad de su recusa- ción.  Identificación el presunto responsable o responsables, concretando los hechos y la infracción que supuestamente ha cometido.  Las sanciones que se pudieran imponer.  Las medidas cautelares a adoptar, en su caso. 102

Infracciones y sanciones El acuerdo de inicio de expediente se comunica al instructor, se notifica al denunciante y al presunto responsable informándole de su derecho a formular las alegaciones que estime oportunas, así como a utilizar los medios de defensa procedentes. El procedimiento sancionador concluye con la resolución del Director de la Agencia, contra la que cabe recurso de reposición potestativo ante él mismo. Contra su resolución, cabe recurso contencioso-administrativo ante la Audiencia Nacional. CUADRO EXPLICATIVO PROCEDIMIENTO SANCIONADOR DE LA AEPD. 8.6.2. Procedimiento de tutela de derechos El procedimiento de tutela de derechos se inicia siempre a instancia del interesado, cuando éste considera que se ha vulnerado alguno de sus derechos, mediante un escrito de reclamación ante la Agencia. En este escrito se debe indicar cuál es el contenido de la reclamación y los artículos de la Ley que se consideran vulnerados. La AEPD da traslado de la misma al responsable del fichero (empresa titular), para que realice las alegaciones que estime oportunas en el plazo de 15 días. Después de dar audiencia al afectado y al responsable del fichero, el Director de la AEPD 103

La protección de datos personales: Soluciones en entornos Microsoft resolverá en el plazo máximo de 6 meses, comunicándolo a los afectados. La resolución puede ser:  “No ha lugar”, en cuyo caso se cierra el procedimiento.  “Sí ha lugar“, en cuyo caso se tutela el derecho vulnerado y se decide si se abre o no el procedimiento sancionador. Contra esta decisión cabe recurso contencioso-administrativo. 104

9 Los órganos de control 9.1. La Agencia Española de Protección de Datos (AEPD) Es el órgano que se encarga de velar por el control y cumplimiento de la normativa sobre Protección de Datos. Es un ente de Derecho Público, con personalidad jurídica propia y capacidad pública y privada, que actúa con independencia de las Administraciones Públicas en el ejercicio de sus funciones, pero dependiente del Ministerio de Justicia. Actualmente se rige por lo dispuesto en la LOPD y en su Estatuto, aprobado por Real Decreto 428/1993, de 26 de marzo. En defecto de lo que establezcan la LOPD y sus disposiciones de desarrollo, la AEPD actuará de conformidad con la Ley de Procedimiento Administrativo. Los ficheros de titularidad privada son de exclusiva competencia de la Agencia Estatal. La AEPD se estructura de la siguiente forma:  Director.  Consejo Consultivo.  Subdirección General del Registro General de Protección De Datos.  Subdirección General de Inspección de Datos.  Subdirección General de Secretaría General. Entre sus competencias y funciones, cabe destacar las siguientes:  Vigilar en el territorio español del cumplimiento de la legislación sobre protección de datos (excepto las funciones asumidas por las Agencias Autonómicas de Protección de Datos). 105

La protección de datos personales: Soluciones en entornos Microsoft  Controlar la aplicación de la legislación sobre protección de datos y, especialmente, lo relativo a los derechos de acceso, rectificación, oposición y cancelación (derechos ARCO).  Dictar Instrucciones sobre determinados aspectos de la protección de datos de carácter personal.  Atender a las peticiones, reclamaciones y consultas que formulen los titulares de los datos personales.  Proporcionar información a los titulares de datos personales sobre sus legítimos derechos en materia de protección de datos personales.  Señalar a las entidades que gestionen datos personales, las medidas que deberían implantar para la adecuación de sus actuaciones con la legisla- ción sobre protección de datos personales.  Ordenar a las entidades que gestionen datos personales, el cese de determinadas actuaciones que no se ajustan a la legislación sobre protección de datos.  Ejercer la potestad inspectora. El artículo 40 de la LOPD detalla los siguientes:  La AEPD podrá inspeccionar los ficheros con datos personales de las entidades que gestionan dichos tipos de datos.  Podrán solicitar e inspeccionar documentación, equipos físicos, lógicos y locales relacionados con datos personales.  Los funcionarios que actúen bajo esta función se consideran Autori- dad Pública y poseen, como obligación, deber de secreto.  Ejercer la potestad sancionadora (ver apartado 8.6).  Informar previamente los proyectos de disposiciones generales sobre protección de datos personales.  Recabar de las entidades que gestionan datos personales la ayuda e información que necesite para el ejercicio de sus funciones.  Comprobar la publicidad de los ficheros con datos personales. En este sentido, deberá publicar periódicamente la relación de ficheros con datos personales inscritos en ella.  Controlar y autorizar movimientos internacionales de datos personales.  Velar por determinados aspectos de la Ley de la Función Estadística.  Cooperar internacionalmente en materia de protección de datos personales. 106

Los órganos de control  Redactar una Memoria anual y remitirla al Ministerio de Justicia.  Otras funciones que sean atribuidas a la Agencia por vía legal o por vía reglamentaria (como por ejemplo las sancionadoras asignadas por la LSSICE). Toda persona tiene derecho a consultar en el Registro General de la AEPD qué ficheros existen inscritos. El Registro es de consulta pública y gratuita; se puede ejercitar cuantas veces se quiera, se puede realizar desde su página web (www.agpd.es) y nos proporcionará la identidad del responsable del fichero, la dirección y la finalidad. Si lo que queremos saber es qué datos tiene una empresa de nosotros, tendremos que dirigirnos al responsable del fichero mediante el ejercicio del derecho de acceso. Con la medida introducida en la Ley de Acompañamiento de los Presupuestos de 2004, la AEPD puede hacer públicas, a partir del 1 de enero de 2004, las resoluciones que adopta. 9.2. Las agencias de protección de datos de las comunidades autónomas En la actualidad existen tres Agencias autonómicas de Protección de Datos (Agencia de Protección de Datos de la Comunidad de Madrid, Agencia Vasca de Protección de Datos y Agencia Catalana de Protección de Datos) aunque algunas Comunidades Autónomas, como la de Valencia, ya han anunciado su voluntad de constituir su propio organismo de control. 9.2.1. Agencia de Protección de Datos de la Comunidad de Madrid (APDCM) Es la primera agencia autonómica en estar operativa y tiene su autoridad sobre los organismos públicos e instituciones de la Comunidad de Madrid. Es la más activa de las agencias autonómicas, tanto en su labor inspectora como en el desarrollo normativo y edición de publicaciones en materia de Protección de Datos. Es de destacar el Premio anual a las Mejores prácticas de las Administraciones Públicas europeas en materia de Protección de Datos. La APDCM se rige por la Ley 8/2001, de 13 de julio, de Protección de Datos de Carácter Personal en la Comunidad de Madrid. (BO. Comunidad de Madrid 25 julio 2001) y por el Decreto 40/2004, de 18 de marzo, por el que se aprueba el Estatuto de la Agencia de Protección de Datos de la Comunidad de Madrid (BO. Comunidad de Madrid 25 marzo 2004). 9.2.2. Agencia Catalana de Protecció de Dades (APDCAT) La APDCAT se rige por la Llei 5/2002, de 19 d’abril, de L’Agència Catalana de Protecció de Dades y tiene su autoridad sobre los organismos públicos e instituciones de la Comunidad Autónoma de Cataluña. 107

La protección de datos personales: Soluciones en entornos Microsoft 9.2.3. Agencia Vasca de Protección de Datos (AVPD) La AVPD se regula por la Ley 2/2004 del Parlamento Vasco, de 25 de febrero, de Ficheros de Datos de Carácter Personal de Titularidad Pública y de Creación de la Agencia Vasca de Protección de Datos, y tiene su autoridad sobre los organismos públicos e instituciones de la Comunidad Autónoma del País Vasco. 9.3. Conclusiones Cuando las organizaciones se enfrentan a un proceso de adaptación a una nueva concepción de la seguridad, la sensación es que falta tanto por hacer que no se sabe por dónde comenzar. El punto de partida para la implantación de un sistema de gestión de la seguridad de la información y los datos personales, debe ser el conocimiento del riesgo al que la organización se está enfrentando. Analizados los aspectos más importantes que afectan a las organizaciones españolas a la hora de enfrentarse a medidas que la adapten a la legislación sobre Protección de Datos, podemos exponer un decálogo de conclusiones que ayuden al empresario a tomar las decisiones más acertadas:  El uso generalizado de la informática ha hecho que los estados legislen para salvaguardar la intimidad de sus ciudadanos. España ha reaccionado imponiendo estrictos requisitos y fuertes sanciones, por lo que las organizaciones, tanto públicas como privadas, deben de optar por una gestión prudente de los datos personales que obran en su poder.  Debemos tener en cuenta que no sólo nos deben preocupar los datos de carácter personal procesados por nuestro sistemas informáticos, sino el uso y tratamiento que damos a los datos plasmados en papel, fuente actual de las mayores infracciones en materia de protección de datos.  La necesidad de definir una Política de Seguridad para la empresa se hace imprescindible, siendo la protección de datos el mejor inicio de una gestión integral de la información en la empresa. Debemos ser activos en adecuar nuestra organización a la protección de datos, y evitar actuar como reacción a un incidente, porque entonces será demasiado tarde y el riesgo de sanción y de pérdida de imagen pública demasiado elevado.  Desde el momento en que la protección de datos implica a todos y cada uno de los departamentos de la organización, sabemos que nos enfrentamos a un proyecto complejo. La creación de una Comisión de Seguridad con espíritu constructivo y formada por miembros con conocimiento en la materia, es vital para el éxito en la protección de datos.  La seguridad sólo se consigue implementando medidas tecnológicas y organizativas. Hay que huir del síndrome de la panacea: una medida 108

Los órganos de control técnica puede quedar obsoleta en cuestión de minutos, por lo que nunca es la solución definitiva de nuestros problemas.  Las medidas que implementemos en nuestra organización son parte de un proceso; no son un producto y no admiten excepciones. La excepción es la puerta abierta a graves problemas.  Enfocar nuestra adaptación a la legislación en materia de protección de datos como un proceso de mejora continuada de la calidad en nuestra organización.  Sin la formación de nuestros empleados, cualquier medida que se intente implementar en la organización será papel mojado. La concienciación de todos los que forman la organización a es la base fundamental de una buena adaptación a la protección de datos, y el primer escalón de una Política de Seguridad en un nivel más amplio.  En una evaluación de nuestros riesgos de seguridad, hay que evaluar tanto los riesgos externos (virus, hacking, craking, etc.) como los internos (usuarios autorizados). En la actualidad son los riesgos internos los que ocasionan un mayor número de incidentes en materia de protección de datos.  Por último, conviene tener siempre presente que los servicios de consultoría externos complementan, asisten y ayudan al empresario a una más rápida y personalizada adaptación a la legislación sobre Protección de Datos, pero nunca le sustituirán en su responsabilidad de cumplimien- to de la normativa implementada en su compañía. Este Libro es una guía de actuaciones y, aunque los autores han tratado de elaborarla de la forma más rigurosa posible para tener la absoluta certeza de que su empresa está cumpliendo con la legislación en materia de Protección de Datos, verifique que cumple con lo que se especifica en la LOPD y el RLOPD. 109

Parte II Técnico 10. La seguridad en sistemas Microsoft 113 11. La aplicación del reglamento de seguridad en los sistemas Microsoft 123 12. La aplicación del reglamento de seguridad en SQL Server 223 13. Implementación de la LOPD sobre SQL Server (SQL Server 2005-2008) 235 14. Política de seguridad 255

10 La seguridad en sistemas Microsoft En estos últimos años, el concepto de seguridad ha cambiado considerablemente en las empresas. Ya nadie cuestiona la importancia que ésta implica para los sistemas y la información. Sin embargo, la falta de rigor y los malos hábitos han provocado que no se aplicasen adecuadamente las medidas, aún disponiendo de medios para ello. Microsoft se ha planteado éste como uno de sus mayores retos: conseguir que los medios disponibles para mejorar la seguridad sean aplicados correctamente y a la par ir fomentando esa necesaria cultura de la seguridad informática. Ha decidi- do romper definitivamente con frases incorrectas pero habituales, como “la seguridad informática es un mito”. Transmitir la necesidad de asegurar nuestros sistemas e información son cuestiones importantes e imperativas. Para el profesional, todas estas cuestiones toman aún mayor peso cuando son otros los que depositan su confianza en nosotros para el mantenimiento de la seguridad de su información en niveles apropiados. Evidentemente, de todo lo anterior nace toda una serie de necesidades. La necesidad de proteger los datos, la de poder contar con ellos ante una eventuali- dad no deseada, o evitar que caigan en malas manos, así como que las comunicaciones de datos sean seguras, son algunos ejemplos críticos de necesidades que deben ser atendidas. En muchas circunstancias, toda esa operativa es totalmente transparente para el usuario. Éste deposita la confianza en los desarrolladores de productos. Se parte de la base de que ese primer escalón presenta una seguridad estable y apropiada. Lógicamente, éste no es más que un primer escalón, el resto se debe ir construyen- do con la participación de todos. Aunque se planifique y se disponga de los mecanismos necesarios para aplicar la adecuada securización de los sistemas, es necesario utilizarlos posteriormente con correspondencia. 113

La protección de datos personales: Soluciones en entornos Microsoft Microsoft es consciente de estas cuestiones. Son muchos los usuarios que depositan la confianza en sus productos. Su compromiso no puede ser otro que el de crear la solidez de la infraestructura desde ese primer peldaño, y facilitar las herramientas para construir cualquier infraestructura, independientemente de su complejidad, con la solidez y seguridad apropiadas. 10.1. TrustWorthy Computing (TWC). La estrategia de Microsoft Fruto de las necesidades que planteaban los usuarios, y con objeto de solidifi- car los mecanismos de seguridad, nace a principios de 2002 en Microsoft una iniciativa que modificará significativamente tanto la forma de ver como la de plantear los sistemas TI existentes: TrustWorthy Computing. Esta iniciativa presenta los pilares sobre los que se sustentan los mecanismos de Microsoft para proporcionar sistemas seguros. Abarca un amplio espectro de funciones que van desde determinar los ciclos de vida de desarrollo de seguridad de un software, a generar y estudiar tecnologías innovadoras que lideren iniciativas de prevención de nuevas formas de violaciones de seguridad (que pueden aparecer de las formas más insos- pechadas), junto otras muchas. Desde el nacimiento de la iniciativa de TrustWorthy Computing, numerosas aplicaciones han nacido bajo su paraguas. Éstas se han establecido bajo las siguiente cuatro directrices SD3+C: “Secure by Design”, “Secure by Default”, “Secure by Deployment” y “Communication” (Seguro por diseño, Seguro por definición, Seguro en distribución y Comunicaciones). Desde el nacimiento de una aplicación existe un criterio para establecer el mayor nivel de seguridad exigible: implementar procesos que de una forma confiable puedan establecer una mayor seguridad. Estos procesos deben ser diseña- dos con objeto de minimizar los fallos de seguridad presentes, tanto en el diseño de una solución, como en su programación. Una vez puesta en marcha ésta, los procesos de trabajo deben igualmente establecer los mecanismos de depuración adecuados. En todos y cada uno de estos procedimientos y apartados, un grupo de especia- listas de Microsoft en seguridad se encuentran presentes en todas las fases del ciclo de vida de desarrollo de la seguridad de los productos Microsoft. Además éstos no culminan la labor con el lanzamiento del producto, sino que continúan con el centro de respuestas de seguridad de Microsoft. La tecnología de TrustWorthy Computing va aún más allá, puesto que definen también los mecanismos para la inversión de seguridad en los equipos de desarrollo, la formación de la comunidad TI, evaluaciones externas, y otros muchos aspectos relacionados. 10.2. Soluciones seguras Como hemos comentado anteriormente, la necesidad de implementar elementos de seguridad se debe abordar desde la perspectiva de plantear mecanismos que 114

La seguridad en sistemas Microsoft observen la iniciativa SD3+C comentada. Bajo este marco de trabajo debe operar cada solución planteada en las diferentes fases por las que pasa un desarrollo, hasta los procesos de implantación del mismo, y la posterior puesta en práctica de los diferentes elementos software necesarios para una empresa. 10.2.1. Seguridad en el diseño Debemos considerar el objetivo de securización desde la parte inicial del diseño. En esta etapa se establecen los mecanismos que nos permiten reducir las posibles superficies de ataque en un contexto global a la hora de generar una solución de Software. Una consideración fundamental a tener en cuenta es que, aunque el software no consiga un entorno de seguridad total, todos aquellos elementos que sean utilizados de forma habitual, se instalen y se ejecuten con el menor privilegio posible. Evitaremos con ello, antes que el producto vea la luz, que posteriormente puedan aparecer vulnerabilidades de seguridad. De igual modo, también esto nos permitirá ir agregando otros elementos que incrementen la seguridad global del mismo. Otra evolución significativa asociada a esta iniciativa, y que implica una mejora en cuanto a los niveles de securización, es evitar que determinados servicios que antes requerían de privilegios administrativos muy elevados, ahora en sus equivalentes actuales demandan un nivel de privilegios considerablemente inferior. Se minimizan, de este modo, las posibles amenazas de seguridad que la situación original podía implicar. 10.2.2. Seguridad predeterminada Bajo este epígrafe abordamos la necesidad de que un sistema instalado “por defecto” reduzca su posible superficie de ataque no habilitando aquellos servicios que no sean necesarios. Evidentemente, esto requiere que un administrador que desee una determinada función, y ésta se encuentre asociada a un servicio no instalado por defecto, la tenga que instalar a propósito. Esto no implica ninguna pérdida de funcionalidad; simplemente por seguridad se limita la automatización en el despliegue de servicios que, sin embargo, no por ello dejan de estar disponibles. Una mala práctica habitual por parte de los administradores cuando se lleva a efecto la instalación de una plataforma o solución es desconocer o no interesarse por los elementos que han sido instalados. Si esta circunstancia se da, no se tendrá en cuenta qué elementos demandan un mantenimiento y cuáles de ellos implican riesgos de seguridad, o si es necesario aplicar medidas concretas de securización. Como ejemplo de la nueva filosofía que comentamos, la plataforma Windows Server 2008 establece un sistema por defecto con las mínimas características y funciones. A partir de éste, es tarea del administrador determinar los roles y las características que son necesarios para el servidor. Es por ello que aquellos administradores que no tengan la necesidad de hacer uso de determinados servicios no tendrán que plantearse cómo mantener su seguridad, ni conocer cómo deshabilitarlos y en qué medida puede afectar al resto del entorno. Por otro lado, 115

La protección de datos personales: Soluciones en entornos Microsoft aquel que sí necesite un determinado servicio deberá conocer cuál es su funcionamiento, preocupándose de mantener su seguridad, y de aplicar las mejores condiciones posibles para su entorno en explotación. De esta forma, conociendo cómo vamos configurando una solución en función de nuestras necesidades y partiendo de una base predeterminada más segura, llegamos a un mejor conocimiento de la plataforma que implementamos. Esto revierte forzosamente en mejoras en la seguridad de la misma. 10.2.3. Seguridad en el despliegue Una de las fases operativas que se antoja como más crítica es la puesta en producción de un producto y el inicio de la actividad continuada sobre el mismo. En función de esta consideración, Microsoft plantea determinadas iniciativas y programas dirigidos a la comunidad TI, con el objeto de que los profesionales conozcan cómo adaptar y configurar los mecanismos de seguridad necesarios y disponibles sobre sus elementos en explotación. Desde los programas STPP (Strategic Technology Protection Program), hasta los actuales mecanismos de Forefront, Microsoft aporta herramientas y elementos que permiten beneficiarse de ellos y elevar el nivel de seguridad en los sistemas. Microsoft plantea estrategias en relación a tres elementos fundamentales:  Personas. La formación de los administradores y usuarios TI es un aspec- to crítico en los mecanismos de seguridad, que no debe descuidarse. De nada vale disponer de los sistemas más eficaces y seguros, si las malas prácticas o el desconocimiento crean huecos de seguridad que con los conocimientos oportunos no existirían. Eventos, laboratorios de seguridad, o las diferentes formaciones planteados en los Centros de Formación Microsoft, entre otros, se ofrecen como alternativas cuyo objetivo es formar a administradores y usuarios en el manejo de las características de seguridad de sus entornos, mostrando además posibles soluciones que pudieran ser desconocidas para ellos.  Procesos. Plantear procedimientos de aplicación de modelos de seguridad y establecer los mecanismos de seguridad a utilizar son una referencia a considerar en todo momento. Estos procedimientos pueden establecerse y plantearse mediante diferentes guías de seguridad ( http:// www.microsoft.com/spain/technet/security/guidance/default.mspx), mediante mecanismos e instrucciones que permiten que los administradores gestionen sus sistemas con mayor facilidad, a través del centro de respuestas de seguridad de Microsoft (http://www.microsoft.com/spain/technet/security/ bulletin/notify.mspx), o mediante procedimientos de alerta a los usuarios (http://alerts.live.com/Alerts/Default.aspx). Estas y otras series de medidas van a suministrar el apoyo necesario al profesional de TI que le permita plantear procesos con los que aportar soluciones a cuestiones que se puedan dar en sus entornos operativos. 116

La seguridad en sistemas Microsoft  Tecnología. Para completar los ciclos de seguridad, además de poseer los conocimientos, debe contarse con una serie de herramientas que faciliten la administración de la seguridad y sean capaces de reducir la dedicación de tiempos administrativos. Microsoft proporciona diferentes herramientas y soluciones que facultan a los administradores para aplicar las correspondientes actualizaciones de seguridad mediante SCCM 2007 (System Center Configuration Manager), WSUS (Windows Server Update Services) o Microsoft Update. Suministra, de igual modo, herramientas para la evaluación de mecanismos de seguridad, tales como el MBSA 2.1 (Microsoft Baseline Security Analyzer), con los que establecer una auditoría de caja blanca, herramientas de elimina- ción de software malintencionado, o los servicios de Windows Rights Management, para aplicar gestión de derechos, entre otras posibilidades (http://www.microsoft.com/spain/technet/seguridad/herramientas/default.mspx). 10.2.4. Comunicación El cuarto elemento dentro de la arquitectura SD3+C establece la necesidad de crear un cauce de comunicaciones hacia el usuario de tal forma que se minimice el impacto de las vulnerabilidades, proporcionando guías y soluciones que mitiguen los posibles impactos en la seguridad. 10.3. ¿Que se ha conseguido con TWC? La iniciativa empezó a dar sus frutos rápidamente, y el primer balance signifi- cativo y positivo lo podemos hacer un año después de la aparición de la plataforma Windows 2003. Comparando sus números de seguridad con el mismo período de tiempo transcurrido desde la aparición de su antecesor Windows 2000, las mejoras son evidentes. Aunque por aquella época Microsoft no había categorizado las vulnerabilidades, con posterioridad se han evaluado los boletines de seguridad aplicados a Windows 2000 para asemejarlos al período actual y poder realizar una comparativa coherente. Durante el primer año de rodaje de ambos Sistemas Operativos, Windows 2000 presentó 62 boletines de seguridad importantes y críticos, frente a los 24 que tuvo Windows 2003. Además, el dato es más significati- vo aún si tenemos en cuenta que el índice de datos reportados al CERT (Computer Emergency Response Team), fue considerablemente más alto en el año 2003-04 que en el período 2000-01 (www.cert.org/stats/cert_stats.html). La evolución de las cifras, hasta las actuales, implica una considerable mejora. Gran cantidad de productos Microsoft presentan bajos índices de incidencias de seguridad desde su aparición. Internet Information Server 6.0 y 6.7, Windows Vista o Windows Server 2008, se encuentran dentro de estas tecnologías nacidos bajo el paraguas de TWC. Todos ellos han demostrado su eficacia, y se encontrarían dentro de esos productos con bajos niveles de incidencia que mencionamos. 117

La protección de datos personales: Soluciones en entornos Microsoft 10.3.1. Common Criteria Un gran problema subjetivo con el que nos encontramos en muchas circunstancias, es el de cuantificar el nivel de seguridad de una determinada aplicación o sistema operativo. Hablamos de subjetividad porque evidentemente cada cual lo verá desde su punto de vista y en función de la experiencia propia. Además, nos encontramos con los famosos “mitos de la seguridad”, que en ningún momento son analizados ni con números, ni teniendo en cuenta los factores que pueden llegar a deducirse de los mismos. Con objeto de determinar si un Sistema Operativo es o no seguro, éste debe poder ser cuantificado con datos objetivos y desde diversas perspectivas. El abanico de posibilidades es amplio, desde la perspectiva de una organización de tipo independiente, hasta la que puede tener cualquier compañía desarrolladora, junto a otras. Este sistema cuantificado debe aportar unos factores objetivos pudiendo medir así el nivel de seguridad ofrecido por el sistema. Esto es Common Criteria (ISO_IEC 15408). La importancia de encontrarse dentro del marco de Common Criteria queda establecida al ceñirse a una serie de parámetros de seguridad, aceptados en la actualidad por 24 de los países más industrializados en todo el mundo. Estos criterios de seguridad se utilizan como elementos de medida en entornos tan importantes como la administración y la banca, junto a otros. Dentro de esos 24 países, España actualmente participa directamente dentro del Common Criteria, y además es uno de los nueve miembros con capacidad de emisión, a través del Centro Nacional de Inteligencia, siendo el Centro Criptográfico el encargado de evaluarlo (http://www.commoncriteriaportal.org/members.html). La certificación Common Criteria ha tenido un largo camino hasta llegar a ser lo que conocemos hoy en día. Desde siempre, los diferentes estamentos administrativos han visto la necesidad de plantear una serie de juicios de valoración que pudieran dictaminar lo seguro que podían ser los sistemas. Desde principio de los años 80 en Estados Unidos se recogen una serie de criterios de seguridad que quedan unificados bajo el epígrafe TCSEC (Trusted Computer System Evaluation Criteria), siendo publicados a través del famoso “Libro Naranja” en el año 1985. La organización europea homónima, el ITSEC (Information Technology Security Evaluation Criteria), publica en junio de 1991 una serie de normas de seguridad consensuadas por Francia, Alemania, Holanda y el Reino Unido. A principios de 1993 en Canadá se desarrollan los criterios CTCPEC (Canadian Trusted Computer Product Evaluation) aunando criterios tanto de TCSEC como de ITSEC, a la vez que en Estados Unidos el NIST (Nacional Institute of Standards and Technology) y la NSA (National Security Agency) desarrollaron conjuntamente los FC (Federal Criteria) para la seguridad en la Tecnología de la Información versión 1.0. Se pretende combinar los conceptos tomando criterios de evaluación tanto de América del Norte como de Europa. Era evidente que tal cantidad de criterios y asociaciones necesitaban establecer una estandarización internacional para adoptar los criterios comunes que deben 118

La seguridad en sistemas Microsoft normalizar la seguridad. Así nació la ISO-IEC 15408, que determina el marco de la normalización para establecer pruebas y criterios que tienen como resultado la parametrización de sistemas seguros: Common Criteria. La valoración que Common Criteria realiza de los diferentes sistemas informáticos queda categorizada mediante Evaluation Assurance Level (EAL). Los niveles posibles van desde EAL1 a EAL7, en función de las diferentes pruebas a las que se somete a los sistemas en una serie de laboratorios y escenarios. Dentro de esta graduación, los niveles comprendidos entre el EAL5 y EAL7 están orientados principalmente a productos con técnicas y objetivos muy especializados, por lo que no suelen emitirse para productos que puedan ser distribuidos comercialmente. Actualmente, los Sistemas Operativos Windows Vista y Windows Server 2008 se encuentran en proceso de evaluación, para la adquisición del nivel “EAL4 con argumentos de certificación ALC_FLR.3, AVA_VLA.3” (http://www.niap- ccevs.org/cc-scheme/in_evaluation). Para este proceso de evaluación, es necesario desarrollar una serie de trámites, así como superar múltiples pruebas realizadas en más de 20 escenarios tipo, planteados por el SAIC (Science Aplications Internacio- nal Corp’s). Con anterioridad a la puesta en marcha del proceso de evaluación de Windows Server 2008 o Windows Vista, otros productos Microsoft ya han superado estas pruebas, adquiriendo la certificación EAL4:  Certificate Server 2003 (EAL4+).  Exchange Server 2003 Enterprise Edition (EAL4+).  Groove Workspace (EAL2+).  Internet Security and Acceleration Server 2004 (EAL4+).  Internet Security and Acceleration Server 2004 Enterprise Edition & Service Pack 2 (EAL4+).  ISA Server 2000 with Service Pack 1 and Feature Pack 1 (EAL2+).  SQL Server 2005 Database Engine Enterprise Edition (English) SP1 (EAL1).  Windows 2000 Professional Server & Advanced Server (EAL4+).  Windows 2003 and Microsoft Windows XP (EAL4+).  Windows 2003/XP with x64 Hardware Support (EAL4+).  Windows Mobile 5.0 MSFP (EAL2+).  Windows Mobile 6 (EAL2+).  Windows Rights Management Services (RMS) 1.0 SP2 (EAL4+). 119

La protección de datos personales: Soluciones en entornos Microsoft  Windows Server 2003 and Microsoft Windows XP (EAL4+).  Windows Server 2003 Certificate Server (EAL4+).  Windows Server 2003 SP2 including R2 Standard, Enterprise & Itanium Editions, Windows XP Professional SP2 & x64 SP2, Windows XP Embedded SP2 (EAL4+).  Internet Security and Acceleration Server 2006 (EAL4+).  Windows Mobile 6.1 (EAL2+).  SQL Server 2005 SP2 Database Engine (EAL4+).  Exchange Server 2007 SP1 x64 (EAL4+).  SQL Server 2008 Database Engine (EAL1+).  Vista SP1/Windows Server 2008 (EAL1+).  Vista SP1/Windows Server 2008 (EAL4+).  OpenXML SDK v1.0 (EAL1). La acreditación EAL4 es el nivel más elevado que puede ser otorgado a un sistema operativo de tipo comercial que no haya sido construido específicamente para cumplir los niveles EAL5-7. El agregado ALC_FLR.3 certification, identifica que también quedan evaluados los procedimientos que establece el fabricante para el seguimiento y la corrección de defectos que pueden surgir con el paso del tiempo. En el caso de Microsoft, el MSRC (Microsoft Security Response Center). La información de Sistemas Operativos y otros productos, así como el nivel de seguridad adquirido, puede ser consultada en la siguiente URL: http:// www.commoncriteriaportal.org/products_OS.html. Las guías de producto Common Criteria y los informes de Evaluación Técnica (ETR) para los productos Windows XP y Windows 2003, se encuentran disponibles a través de la siguiente URL de TechNet: http://www.microsoft.com/technet/security/ prodtech/windowsserver2003/ccc/default.mspx. Una vez que hayan sido evaluados Windows Server 2008 y Windows Vista, serán generadas y publicadas también las guías correspondientes. 10.3.2. Evaluación de FIPS 140 (Federal Information Processing Standard) FIPS 140-1 y su sucesor FIPS 140-2 proporcionan una serie de estándares de Estados Unidos para la cuantificación de los servicios criptográficos del software. Aquí se establecen los procedimientos recomendados para implementar los algoritmos de cifrado, el control de los búferes de datos y el manejo de material de clave, así como la integración con el sistema operativo. Determinadas agencias de los 120

La seguridad en sistemas Microsoft Estados Unidos sólo compran productos que hayan superado las especificaciones de FIPS 140-1 o FIPS 140-2 (según proceda). En el año 2008, siete componentes de seguridad han completado y superado los componentes de evaluación FIPS 140-2:  Proveedor Criptográfico avanzado de Windows Vista DSS y Diffie- Hellman (DSSENH).  Proveedor Criptográfico avanzado de Windows Vista (RSAENH).  Librerías de Primitivas Criptográficas de Microsoft Windows (bcrypt.dll).  Interfaz Proveedor de soporte de seguridad del Modo del Kernell para Windows Vista (ksecdd.sys).  Librería de Integridad de código (ci.dll).  Cargador de Sistema Operativo de Windows Vista (winload.exe).  Gestor de Arranque de Windows Vista (bootmgr). A través de las siguientes direcciones, pueden obtenerse las políticas de seguridad de los diferentes componentes certificados:  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp894.pdf  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp893.pdf  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp892.pdf  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp891.pdf  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp890.pdf  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp889.pdf  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp888.pdf 10.3.3. Iniciativa de recursos compartidos Esta iniciativa pretende establecer el equilibrio, haciendo disponible el código fuente y defendiendo los derechos de propiedad intelectual. Cada uno de los programas de licencias del código fuente se adapta a las necesidades específicas de cada una de las comunidades que comprende Microsoft. Como evolución de esta iniciativa, y en la búsqueda de un compromiso con la seguridad, se genera el Programa de Seguridad para Gobiernos (GSP), con el que se pretende aportar a gobiernos e instituciones públicas la capacidad de acceder al código fuente de Windows, pudiéndose así establecer una serie de procesos de depuración y herramientas de criptografía, cuyo objetivo final no es otro que establecer una mejor protección en los sistemas. Frutos de estos acuerdos aparecen toda una serie de iniciativas conjuntas para mejorar aspectos de la seguridad informática. En España, a modo de ejemplo, el 121

La protección de datos personales: Soluciones en entornos Microsoft Centro Nacional de Inteligencia y Microsoft colaboran conjuntamente para la elaboración de plantillas de seguridad para diferentes entornos de trabajo de la Administración. 10.3.4. Programa para la cooperación de la seguridad (SCP) En el año 2005, Microsoft establece un acuerdo de cooperativa global, por el que numerosas entidades públicas de 44 países reciben por parte de la corporación información y colaboración para contribuir al aumento de la seguridad de los entornos informáticos públicos: desde información detallada sobre vulnerabilidades informáticas, nuevas actualizaciones de seguridad o políticas generales de seguridad de los productos de Microsoft, hasta un canal de comunicación directa y cons- tante con los expertos de la compañía en esta área, para la identificación conjunta de problemas, así como el estudio de los mejores procesos de respuesta ante incidentes. En el año 2007, a través de acuerdos con INTECO, y 2008, a través del CCN- CERT (Capacidad de respuesta ante Incidentes de Seguridad de la Información del Centro Criptológico Nacional), adscrito al Centro Nacional de Inteligencia, España entra en el programa constituyendo el país número 45 en este acuerdo de coopera- ción. Con este acuerdo de cooperación, se pretende prevenir, mitigar y anticipar los efectos de incidentes y ataques a los sistemas de la administración. 10.3.5. Seminarios de seguridad Adicionalmente a las guías y herramientas de seguridad, proporcionadas a todos los usuarios de los sistemas de información, Microsoft planifica y ejecuta toda una serie de eventos, seminarios y sesiones técnicas cuyo objetivo es acercar las diferentes tecnologías al usuario final. A través de presentaciones y escenarios, se pretende aportar conocimientos, metodologías y posibilidades de resolución de diversas situaciones que pueden presentarse. Se capacitará a los asistentes a los diversos eventos para poner en marcha las diferentes tecnologías tratadas de forma segura. Aunque muchos de los seminarios son de tipo presencial, otros, como por ejemplo los Webcasts, se encuentran disponibles en fórmulas no presenciales, tanto en formato online, como en modo offline, permitiendo este último un seguimiento del mismo aunque ya se haya realizado. Dentro de este tipo de seminarios y en el área de seguridad, se incluye una serie de ellos donde se han evaluado desde un punto de vista técnico diferentes normas y reglamentos aplicables a las Tecnologías de la información. Entre ellos se encuentran los elementos de aplicación sobre la Ley Orgánica de Datos de Carácter Personal y su Reglamento en vigor. El acceso a dichas sesiones técnicas puede realizarse a través de la siguiente dirección: http://www.microsoft.com/spain/technet/jornadas/webcasts/ webcasts_ant.aspx?id=13. 122

11 La aplicación del reglamento de seguridad en los sistemas Microsoft Uno de los objetivos fundamentales a resolver por parte de los responsables de seguridad informática, es materializar el cumplimiento de las normas de seguridad. Sus soluciones deben observar múltiples factores, aunando la protección de datos, los sistemas de correo electrónico, las funcionalidades de los sistemas operativos, junto a otros criterios de actuación. Sin una referencia clave de cómo actuar, sus circunstancias operativas son realmente complejas. El nuevo Reglamento de Seguridad de desarrollo de la Ley Orgánica de Protección de Datos de Carácter Personal se publica con fecha de 19 de enero de 2008. Corresponde al Real Decreto 1720/2007 y entra en vigor el 19 de abril de 2008, fecha en la cuál los sistemas tendrán que haberse adaptado a las condiciones exigidas en este nuevo reglamento, habiendo acometido los cambios técnicos necesarios. Este manual tiene como objetivo dar respuesta a esas incertidumbres, estableciendo los criterios básicos para el cumplimiento de la norma y los mecanismos técnicos de aplicación en escenarios de utilización de Sistemas Microsoft. Abarcar en profundidad todos los aspectos de la seguridad demandaría un trabajo mucho más extenso. En el presente documento nos centraremos principalmente en todos aquellos elementos que la norma cita y que deben cuidarse para establecer unos mecanismos de seguridad consecuentes, tales como ficheros que puedan contener datos, la protección de los datos almacenados, el control de accesos y la protección de los medios de correo electrónicos, junto a otros. Considerando que el elemento aglutinador fundamental de los entornos son los sistemas operativos, se contemplarán inicialmente las características de seguridad que aportan los mismos, centrándonos en un aspecto fundamental como son 123

La protección de datos personales: Soluciones en entornos Microsoft las directivas de seguridad, para ir con posterioridad ampliando funcionalidades que pueden reportar otros productos tales como Microsoft Exchange Server 2007 o Microsoft Office 2007, como plataformas importantes dentro de las empresas y organismos y que sustentan documentos e información objeto de atención para la norma. En la actualidad, estas plataformas desempeñan labores críticas en las empresas y su uso es exhaustivo, por lo que tenemos que tener en cuenta los factores que marcan la norma con respecto a ellas, considerando que éstas presentan medidas propias que pueden ser utilizadas para salvaguardar la información y que serán tenidas en cuenta también en esta guía. 11.1.Tecnología de seguridad en Microsoft Windows La norma establece una serie de criterios básicos y fundamentales a considerar. Evidentemente, a partir de ahí, aplicar más o menos medidas de seguridad será un criterio del administrador, que dependerá también de los mecanismos disponibles en las organizaciones. La norma establece que debe ser salvaguardada aquella información “con datos de carácter personal”, indistintamente si ésta se encuentra almacenada localmente en un sistema o bien si la información se desplaza en cualquier proceso de comunicación. También será necesario valorar la existencia de información temporal generada por la utilización de ficheros, independientemente de cual sea su formato. La norma establece también que este tipo de ficheros temporales deben disponer de las mismas medidas de seguridad que el fichero original a partir del cuál se han creado. Bajo el término de seguridad informática englobamos un amplio espectro de elementos que se observan tanto a nivel local de una máquina, como a la totalidad de un sistema de red. Evidentemente, ni la norma, ni esta guía de aplicación, pretenden establecer todas las medidas posibles (que podrían ser interminables), sino una serie de características básicas que deben tenerse en cuenta y que pueden afectar fundamentalmente a los datos personales. Desde este criterio podemos indicar para un entorno Windows, que la gestión básica de la seguridad parte de las directivas de seguridad. Éstas establecen configuraciones para elementos críticos en la seguridad de un sistema y, por tanto, son parte fundamental para asegurar que estamos aplicando correctamente la norma. Tanto Windows Server 2008 como Windows Vista cuentan con sus directivas de seguridad. Éstas realmente lo que hacen es modificar la base de datos de seguridad del sistema, que se encuentra ubicada en la siguiente ruta: %systemroot%securityDatabasesecedit.sdb. Las directivas pueden definirse en un nivel local para una máquina concreta mediante las políticas locales, o bien, cuando los sistemas se encuentran ubicados en el marco de un domino, desplegarse para todo un entorno de red, mediante una estructura centralizada a través de las directivas de seguridad de dominio. La ventaja que nos aporta la utilización del Directorio Activo de Windows Server 2008 es la de permitirnos definir una configuración de la seguridad más controlada para todos los equipos de una red, minimizando los costes de administración. Esta 124

La aplicación del reglamento de seguridad en los sistemas Microsoft administración centralizada puede desplegar la base de datos en diferentes contenedores, sin necesidad de tener que desplazarse físicamente a cada uno de ellos. Además, la disposición jerarquizada dentro del Directorio Activo, basada en contenedores, permite establecer diferentes medidas de control de seguridad en función de los diferentes niveles que se quieran aplicar. Eso sí, no debe confundirse nunca las Directivas de Seguridad con las Políticas de Grupo (GPO), ya que estas últimas son objetos aplicados sobre Sitios, Dominios o Unidades Organizativas, que modifican mediante las Directivas los estados de los usuarios y equipos de un domino. Hay que matizar que las directivas de seguridad son, por tanto, una parte más de todo el conjunto de una GPO. Todo aquel que quiera llegar a aspectos más avanzados en la implementación de la seguridad cuenta con una serie de guías y procedimientos que Microsoft ha dispuesto para tal fin, basados en buenas prácticas, fruto de experiencias reales. Estas guías abordan aspectos fundamentales como pueden ser la gestión de las actualizaciones, la guía de administración de riesgos, y las guías de seguridad y operaciones para diferentes sistemas operativos. El acceso a dicha información puede realizarse a través del siguiente enlace: http://www.microsoft.com/spain/technet/ security/guidance/default.mspx. 11.2.Tecnologías aplicables a medidas de nivel básico Como indicábamos anteriormente, uno de los elementos fundamentales para la aplicación de los mecanismos de seguridad en los entornos Windows, son las directivas de seguridad. Agrupadas bajo el “Security Configuration Manager”, Microsoft ha establecido una serie de pautas, plantillas y mecanismos para establecer de forma conveniente la aplicación de estas medidas básicas de seguridad. Están basadas en el análisis de la configuración de seguridad y la aplicación de plantillas tanto a nivel local como a nivel de dominio o unidades organizativas. También aquí se determinan aspectos fundamentales para establecer los criterios de auditoría y el establecimiento de un patrón de seguridad para la asignación de permisos sobre objetos a través de las plantillas de seguridad. Para conocer las directivas de seguridad aplicadas sobre una máquina es necesario considerar diversos factores para determinar cuáles están siendo efectivas sobre la misma. Este resultante vendrá definido por la suma de directivas locales y los posibles objetos de políticas de grupo que pudieran estar afectándole, tanto en el nivel de dominio, como de unidades organizativas de las que pudiera depender el objeto equipo. En determinadas circunstancias, cuando no ha quedado muy claro qué directivas se encuentran aplicadas o realmente cómo ha quedado la seguridad de una máquina, podemos hacer uso de una herramienta denominada Conjunto Resultante de Directivas (RSoP, Resultant Set of Policy). Esta herramienta nos permite realizar esta comprobación o bien simular las configuraciones de directivas que se aplican a los equipos mediante directiva de grupo, evaluando así cómo podría quedar la seguridad si le aplicáramos otra directiva con anterioridad a hacer efectiva la nueva configuración. 125

La protección de datos personales: Soluciones en entornos Microsoft A todos los efectos, la aplicación de directivas de seguridad en el nivel de GPO por la inclusión de un equipo en Directorio Activo tiene dos efectos importantes. La centralización de la aplicación de directivas, que nos suministra la capacidad de generar contenedores para la aplicación de seguridad en equipos con características similares, y el avance en ciertas características de seguridad como el uso del protocolo Kerberos para los mecanismos de autenticación en la red o la posibilidad de utilizar los mecanismos de PKI (Public Key Infraestructure), con el despliegue automático de certificados a través de los mecanismos integrados en el Directorio Activo. Otro de los posibles mecanismos que modifican tanto aspectos básicos en la configuración como otros más avanzados, lo encontramos en Windows Server 2008 con la utilidad del Asistente para la configuración de seguridad (SCW). Esta herramienta nos permite, a través de una serie de asistentes, establecer una configuración de seguridad más global para el fortalecimiento de los servidores. SCW, además de posibles configuraciones de funciones de directivas de seguridad, nos permite establecer la configuración del Firewall, tanto de entrada como de salida, que incorpora Windows Server 2008, controlar los servicios que pudieran estar ejecutándose y controlar las autentificaciones y configuraciones de seguridad en el nivel de red. 11.2.1. Ficheros temporales Un aspecto importante en la protección de datos consiste en tener controlados todos aquellos ficheros que pudieran contener información que debe encontrarse sujeta a la norma. Recordemos que también están sujetos a la norma los ficheros temporales generados a partir de otros ficheros que pudiéramos tener abiertos. Estos temporales se generan con propósitos especiales, como el de mantener una copia de la información ante posibles contingencias del fichero original; otras veces supone un fichero para el paso y análisis de la información; y en otras circunstancias, cuando se está realizando algún proceso de implantación o instalación, supone el proceso de descompresión de ficheros antes de que sean procesados finalmente. En función de lo anterior, Microsoft, consciente de la importancia de mantener la seguridad sobre los ficheros temporales en los entornos Windows, marca una operativa en la que cuando un fichero de este tipo se genera adquiere los mismos permisos del original. Esto asegura la garantía de confidencialidad, proporcionando solamente derechos sobre el temporal a aquellos usuarios que los poseyeran sobre el fichero original. Como medida de protección en esta misma línea, de forma automática cada vez que un fichero es cerrado, el fichero temporal desaparece, evitando de esta forma tener que estar pendiente de los temporales generados automáticamente. Aún así, puede suceder que algún suceso no controlado, como un corte de luz que ocasiona un apagado inesperado, pudiera conllevar que el fichero temporal queda- se abierto. Este factor dependerá del tipo de aplicación sobre la que se estuviera trabajando. De todas formas, la protección anterior basada en la herencia de permisos protege contra accesos no permitidos a este fichero temporal. Para eliminar estos posibles residuos de nuestra máquina, podemos utilizar una herramienta que 126

La aplicación del reglamento de seguridad en los sistemas Microsoft incorpora el sistema: Liberador de espacio en disco. Además, esta herramienta puede programarse para que realice las operaciones de forma periódica y automáti- ca, liberándonos de estar atentos a esta tarea administrativa. Ficheros temporales. Otro aspecto también observado es el uso de la memoria virtual y los datos que puedan quedar aquí almacenados. El fichero de paginación es realmente una extensión de una parte del disco duro para ser utilizada como memoria RAM cuando se supera el tamaño de la memoria física instalada. Windows mueve parte del contenido a esta memoria virtual, liberando espacio y permitiendo disponer en memoria RAM de nueva información. Los datos almacenados en la memoria virtual son recuperables cuando sean necesarios. En todo ese movimiento de infor- mación de lectura y escritura sobre el fichero de paginación, es posible que queden también ficheros con datos personales aquí almacenados. Cuando el sistema está en activo, no se permite el acceso al mismo, por lo que los datos que se puedan encontrar estarían protegidos. El problema puede surgir cuando un atacante potencial tiene acceso físico a la máquina y ésta se encuentra apagada, pudiendo hacerse mediante algún método con dicho fichero. Con objeto de evitar este problema, Windows plantea la posibilidad, mediante una directiva de seguridad, de borrar el contenido del fichero de memoria virtual cuando se apaga la máquina. Para ello, dentro de las Directivas de Seguridad en Opciones de Seguridad deberíamos habilitar la opción de apagado: “borrar el archivo de páginas de la memoria virtual”. 11.2.2. Artículo 89. Funciones y obligaciones del personal 1. Las funciones y obligaciones de cada uno de los usuarios o perfiles de usuario con acceso a los datos de carácter personal y a los sistemas de información estarán claramente definidas y documentadas en el documento de seguridad. También se definirán las funciones de control o autorizaciones delegadas por el responsable del fichero o tratamiento. 127

La protección de datos personales: Soluciones en entornos Microsoft 2. El responsable del fichero o tratamiento adoptará las medidas necesarias para que el personal conozca de una forma comprensible las normas de seguridad que afecten al desarrollo de sus funciones, así como las consecuencias en que pudiera incurrir en caso de incumplimiento. Dentro de este articulado, el reglamento exige el cumplimiento de unos mecanismos para que los usuarios que hagan uso de ficheros de datos de carácter personal conozcan cómo deben manejar este tipo de datos, y cuáles serán sus derechos y obligaciones. Evidentemente, parte del artículo, y concretamente el punto 1, establece que esta necesidad debe quedar plasmada en el documento de seguridad que la empresa generará con respecto a este tipo de datos. Adicionalmente, en el punto 2 se establece la necesidad de que los usuarios puedan conocer de forma comprensible las normas de seguridad que afectan al desarrollo de sus funciones, y en este sentido la forma de comunicación puede ser de múltiples tipos. Por tanto, queda claro que uno de los aspectos fundamentales para la protec- ción de datos es la necesidad de que los usuarios conozcan que existen unas normas de seguridad al respecto, y que de una u otra forma están supeditados a ellas. Se hace de este modo necesario que éstos estén debidamente informados. Una de las posibilidades de asegurarse que los usuarios van ser conscientes de esta circunstancia, es la aparición de un texto con anterioridad al inicio de sesión de forma interactiva. Mediante las directivas de seguridad, es posible establecer un título y un texto que será presentado antes de que el usuario pueda iniciar su sesión, tanto en el dominio como localmente. En dicho texto se puede establecer una información para el usuario de que existe una norma de seguridad que le afecta, así como informarle de una ubicación donde pueda localizar datos más exhaustivos que le permitan conocer con detalle, si lo creyera oportuno, lo establecido en dicha norma. Funciones y obligaciones; directiva de aplicación. 128

La aplicación del reglamento de seguridad en los sistemas Microsoft La definición de dicho aviso legal se puede generar mediante la conjunción de las siguientes directivas de seguridad, en sus opciones de seguridad correspondientes:  Inicio de sesión interactivo: título del mensaje para los usuarios que intentan iniciar una sesión.  Inicio de sesión interactivo: texto del mensaje para los usuarios que intentan iniciar una sesión. En este texto podrían incluirse, además de la información preceptiva de notificación para el cumplimiento de la Ley Orgánica y de su correspondiente Reglamento, las posibles direcciones URL de consulta en la página de la intranet. En ella, los usuarios podrán conocer de forma particular los textos donde se describen las funciones y obligaciones que les atañen. También pueden quedar descritas aquellas acciones y procedimientos que deben acometer en caso de que se haya producido una incidencia. Funciones y obligaciones; mensaje en pantalla. Muchas empresas han optado por utilizar la solución de gestión documental Ms Office SharePoint 2007 como mecanismo para el almacenamiento y la publica- ción de textos y anexos, descritos en el documento de seguridad. Este servicio aporta dos funcionalidades importantes aplicables a éste y otros articulados del reglamento existente:  Publicación de documentos, como los planteados en este artículo, que permitan que los afectados por el documento de seguridad conozcan sus obligaciones y los procedimientos que pueden emplear, a quién dirigirse, o el canal de notificación a utilizar.  Flujo documental, que permite establecer un canal de gestión de documentos, consiguiendo por ejemplo, que aquellos que detecten una incidencia en ficheros afectados por la LOPD, puedan notificar al responsable 129

La protección de datos personales: Soluciones en entornos Microsoft del fichero dicha incidencia, mediante un procedimiento declarado a través del mismo sistema Ms Office SharePoint 2007. La aplicación de permisos en los diferentes documentos a través de Ms Sharepoint garantizará que sólo aquellos que se vean afectados por el documento de seguridad o participen en el sistema de gestión de datos de carácter personal, puedan acceder a la documentación existente. 11.2.3. Artículo 90. Registro de incidencias Deberá existir un procedimiento de notificación y gestión de las incidencias que afecten a los datos de carácter personal y establecer un registro en el que se haga constar el tipo de incidencia, el momento en que se ha producido, o en su caso, detectado, la persona que realiza la notificación, a quién se le comunica, los efectos que se hubieran derivado de la misma y las medidas correctoras aplicadas. A través de este artículo, el reglamento expresa la necesidad de plantear un procedimiento para que los usuarios puedan notificar cualquier incidencia que haya podido afectar a los ficheros que contengan datos de carácter personal. Por incidencia, el mismo reglamento establece su definición en el apartado i) dentro del artículo 5: Incidencia: cualquier anomalía que afecte o pudiera afectar a la seguridad de los datos. Dentro de estas anomalías podremos incluir la eliminación, pérdida o modifi- cación de la información que contuviera un fichero de carácter personal. Los mecanismos para el registro de la información deben quedar definidos en el documento de seguridad y ser comunicados a los usuarios, que de una u otra forma tendrán que notificar las incidencias para establecer por parte del responsable del fichero las medidas correctoras oportunas. Al igual que en el caso anterior, el procedimiento de notificación puede ser implementado a través del Microsoft Office SharePoint, que permitirá un flujo de trabajo de la información, permitiendo disponer una metodología bajo gestión documental para la notificación de dichas incidencias y su posterior resolución por parte del Responsable del Fichero. Aunque existe la posibilidad de establecer un procedimiento para el descubri- miento de incidencias a través de los diferentes sistemas de auditoría existentes para los servicios y sistemas Windows, tal tratamiento sólo es exigible de forma directa para los datos de nivel alto. En función de ello, los sistemas de registro de acceso serán tratados posteriormente en el capítulo dedicado a las tecnologías aplicables a datos de nivel alto. 11.2.4. Artículo 91. Control de acceso (puntos 1 y 3) 1. Los usuarios tendrán acceso únicamente a aquellos recursos que precisen para el desarrollo de sus funciones. 3. El responsable del fichero establecerá mecanismos para evitar que un usuario pueda acceder a recursos con derechos distintos de los autorizados. 130

La aplicación del reglamento de seguridad en los sistemas Microsoft 11.2.4.1. Control de acceso en Windows Vista y Windows Server 2008 Uno de los mecanismos más importantes que deben considerarse a la hora de establecer un sistema de seguridad aplicable a ficheros sujetos a LOPD, es la deci- sión y puesta en práctica de procedimientos que garanticen el acceso de los usuarios exclusivamente a aquellos datos que les corresponden por sus funciones. Evidente, el tratamiento de los datos dependerá de los sistemas de almacenamiento y servicios utilizados. Nosotros centraremos la valoración en los servidores de ficheros, los servidores de correo y el sistema documental de Ms Office. Cuando una aplicación bajo la acción de un usuario intenta acceder a un recurso con objeto de realizar una operación (este factor dependerá del objeto: fichero, carpeta, impresora, objetos del directorio activo, etc.), intervienen una serie de mecanismos contemplados en los descriptores de seguridad. Estos descriptores de seguridad los conforman por una parte las SACL (System Control Access List), de las que se tratarán posteriormente, y por otro lado un elemento importante, las DACL (Discretionary Access Control List). Cuando queremos establecer un control para acceder a un objeto, en Windows Server 2008 y Windows Vista se realiza a nivel del objeto, estableciendo diferentes niveles de permisos y accesos. Cuando se quiere asignar un control a un objeto, estos se establecen sobre los descriptores de seguridad, de tal forma que cada vez que un usuario intenta acceder al objeto el subsistema de seguridad del sistema operativo comprueba las autorizaciones para realizar las acciones sobre dicho objeto. Estos controles son asignados a través del descriptor de seguridad mediante la aplicación de DACL. Realmente, un descriptor de seguridad es una estructura de datos binaria que contiene los siguientes elementos:  Cabecera. Contiene un número de revisión y un conjunto de atributos que describen las características de seguridad del descriptor.  Propietario. Determina quién es el propietario del objeto mediante el SID del mismo. Este propietario puede modificar permisos y conceder a otros principales de seguridad la posibilidad de tomar posesión.  Grupo Primario. Contiene el SID del grupo primario del propietario. Este dato para compatibilidad sólo tiene validez en subsistemas POSIX, pero en el resto de Windows Vista es ignorado.  DACL. Lista las entradas de control de acceso (ACEs), que permiten o deniegan a un SID una funcionalidad.  SACL. Si las anteriores controlaban los accesos a objetos, éstas auditan las acciones efectuadas. Cuando un proceso intenta acceder a un objeto asegurable, el sistema determina si se concede o no dicho acceso. Si el objeto no tuviera un DACL, el sistema 131

La protección de datos personales: Soluciones en entornos Microsoft permite el acceso; para cualquier otra circunstancia, el sistema busca las ACEs correspondientes para dicho objeto y determinará el resultado final. Cada ACE contiene los derechos que se permiten o deniegan para un principal de seguridad o una sesión validada. Cada ACE incluye la siguiente información:  Un SID que identifica a un usuario o grupo.  Una máscara de acceso que determina los derechos.  Unas marcas de atributo que determinan cuándo un objeto hijo puede heredar esta ACE.  Un identificador que indica el tipo de ACE. Windows 2008 soporta 6 tipos de ACEs: 3 para todos los objetos (acceso denegado, acceso permitido y sistema auditado) y 3 específicos para objetos del directorio activo, donde se permiten, deniegan o auditar los accesos sobre propiedades, conjuntos de propiedades y herencias sobre los objetos del directorio activo. Cuando se intenta realizar un acceso, el sistema compara cada ACE con el Access Token que ha obtenido cada aplicación. Este Access Token contiene los SIDs que identifican al usuario y a los grupos a los que perteneciera, además del SID de validación que identifica la sesión actual. El resultado final de un acceso queda determinado pues por la suma de derechos asignados al usuario más los derechos concedidos a los grupos a los que perteneciera. Hay que tener en cuenta que las denegaciones prevalecen sobre la permisividad, por lo que si un usuario tiene todos los permisos pero pertenece a un grupo al que le deniegan el acceso, este no accede- ría. De la misma forma ocurriría si todos los grupos a los que pertenece un usuario tienen concedidos los derechos pero al usuario se los han denegado. Windows Vista y Windows Server 2008 implementan mecanismos para asegurar a nivel local el poder acceder a los datos mediante DACL. Para la utilización de estas DACL será necesario que el sistema de ficheros donde se aloja la información esté establecido en NTFS. La utilización de este sistema de ficheros puede realizarse durante la instalación del sistema operativo, o si en su momento fue instalado haciendo uso de los sistemas FAT o FAT32, se puede llamar a la aplicación convert.exe para convertir el sistema de fichero a NTFS. Este proceso es irreversible. La asignación de los permisos en todo caso es labor del administrador o el propietario de los ficheros y carpetas. El sistema operativo establece unos permisos predeterminados basados en la herencia sobre los objetos hijo. Habrá que tener siempre en cuenta todos los factores para determinar los permisos reales que tendrá un usuario sobre un objeto sumando los derechos tanto suyos como de los grupos a los que perteneciera. De cara a realizar una administración más cómoda, habría que pensar en establecer una administración de los permisos basados en los Grupos de Seguridad, de tal forma que el establecimiento de los mismos conlleve el menor coste administrativo posible. No es lo mismo ir asignando un permiso de lectura a 50 usuarios, permitirles imprimir a esos mismo 50 usuarios en una impresora determinada y concederles poder ver una serie de propiedades sobre otros objetos 132

La aplicación del reglamento de seguridad en los sistemas Microsoft del Directorio Activo, que incluirlos a todos en un grupo y conceder los derechos sobre el grupo. No sólo es más fácil la administración, pues sólo bastaría con incluir a un usuario en el grupo para obtener esos privilegios, sino que se gana en comodi- dad de cara a comprobar los permisos en los controles de seguridad. Si por algún motivo a uno de esos usuarios no quisiéramos concederle uno de los derechos, bastaría con denegarle el correspondiente permiso o sacarlo del grupo y concederle explícitamente los permisos que necesitara. Otro aspecto importante relacionado con los derechos de acceso es quién tiene la posibilidad de concederlos. Hay que tener en cuenta que un usuario, por ser el propietario de un objeto, tiene derechos para poder modificarlo aunque explícita- mente se le hubieran denegado, por lo cual hay que tener este dato en cuenta de cara a conceder o no este derecho. Por defecto, el grupo de administradores tiene el derecho de toma de posesión, es decir, podría modificar el SID del elemento propietario del descriptor de seguridad correspondiente para sobrescribirlo por el suyo. Mediante directivas se puede conceder una directiva que permite tomar posesión sobre ficheros u objetos a principales de seguridad. Sobre los derechos de usuario habría que conceder el de tomar posesión de archivos y otros objetos en la máquina que se deseara. Aunque la implementación de los permisos de seguridad aplicables sobre carpetas y ficheros para Windows Vista mantiene en su sistema básico el mismo planteamiento asignable a los sistemas en Windows XP y 2003, existe una serie de cambios que deben conocerse, puesto que condicionan algunos de los aspectos funcionales de los permisos de seguridad. Uno de los aspectos principales que se han modificado por defecto en Windows Vista son las ACL (Listas de control de acceso) predeterminadas para Windows XP. En este sentido, uno de los elementos de cambio más notables es la desaparición de los permisos asignados al grupo “Todos”, sustituidos por la asigna- ción al grupo de “Usuarios Autentificados”. Adicionalmente, en muchas de las ubicaciones originales, como por ejemplo las carpetas raíz de las particiones NTFS existentes, se han mejorado notablemente dichas ACL. Otro elemento significativamente diferente lo constituyen los permisos y propietario existentes en la carpeta Windows, así como todos los archivos y subcarpetas que ésta contiene. En las versiones anteriores a Windows Vista, el propietario de dicha carpeta era el grupo de administradores. Esta condición ha cambiado, para lo que Microsoft ha creado una nueva figura: “TrustedInstalled”, que permite establecer mecanismos adicionales de integridad del sistema, siendo esta cuenta la propietaria de la carpeta del sistema. Esto posibilita que un proceso que trabaje como administrador o cuenta del sistema pueda sustituir o eliminar una librería o aplicación existente en la máquina. Con los permisos asignados actualmente al grupo de administradores, éstos deben tomar posesión sobre un objeto, y aplicar unos nuevos permisos para poder eliminar un fichero o carpeta existente. También se han modificado algunas de las ACE (Access Control Entries, Entradas de control de acceso) funcionales de carpetas que han cambiado en su nomenclatura con respecto a las versiones anteriores. Aparece la carpeta “Usuarios” 133

La protección de datos personales: Soluciones en entornos Microsoft que sustituye a la antigua carpeta “Documents and settings”. Por funcionalidad, ésta se mantiene, aunque sólo en aquella vista en la que habilitamos las carpetas y ficheros ocultos del sistema. Igualmente, se ha mantenido por compatibilidad para aquellas aplicaciones que utilizaban dicha ruta a través de la variable de entorno “%userprofile%”, manteniendo una ACE que permite el acceso a través del objeto “Documents and Settings”, actualmente no una carpeta sino un punto de unión, si un objeto buscado se encuentra realmente en la ruta buscada; en caso contrario, devolverá un mensaje de denegación del acceso. Por ejemplo, si solicitamos un fichero que se encuentra en la siguiente ruta: “C:documents and settingsjlMy Documentsfichero.doc” el sistema nos permitirá abrir el fichero, cuando éste se encuentre en la ubicación referida; de lo contrario, nos devolverá un mensaje de error, denegándonos el acceso. Obviando estas modificaciones, el sistema de asignación de permisos, aunque cambia la perspectiva de la generación y aplicación de ACE a través de la consola, adaptándolo a la implementación del sistema de UAC (User Account Control), en su base mantiene las mismas pautas de aplicación que en los sistemas anteriores. Por tanto, la asignación según la aplicación del reglamento viene determinada por lo dispuesto en el Documento de Seguridad de la organización. Será labor del responsable del fichero que se establezcan de acuerdo a un criterio de asignación coherente para el desarrollo de las funciones del personal implicado. En muchas circunstancias, las anidaciones de grupos y los sistemas de membresía existentes en una organización pueden hacer complejo el conocer qué permisos finales tiene un usuario sobre un fichero que pudiera contener datos de carácter personal. Para dar una solución a esta posible problemática, tenemos la posibilidad de utilizar la herramienta de permisos efectivos que nos proporciona la visión de derechos finales que tendrá concedido un usuario o un grupo específico sobre un determinado objeto. Para iniciar este proceso se accederá a las propiedades de seguridad del objeto en cuestión. Permisos efectivos. 134

La aplicación del reglamento de seguridad en los sistemas Microsoft 11.2.4.2. Control de acceso en Microsoft Exchange 2003 Exchange Server 2007 cambia el modelo de permisos con respecto a versiones anteriores y crea nuevos roles de administración que permiten delegar de una forma más flexible. En Exchange Server 2003 existían tres tipos de administradores:  Exchange Full Administrator.  Exchange Administrator.  Exchange View Only Administrator. Ahora, con Exchange 2007 se crean los siguientes roles de administradores:  Exchange Organization Administrators.  Exchange Recipient Administrators.  Exchange View-Only Administrators.  Exchange Public Folder Administrators. Durante la fase de preparación de Directorio Activo y de los dominios, el asistente de instalación crea los roles de administrador en una nueva unidad organizativa de Exchange denominada Microsoft Exchange Security Group. Exchange Server 2007 implementa los llamados conjuntos de propiedades, los cuales son agrupaciones de atributos de Directorio Activo y cuyo control de acceso se realiza mediante ACE (entrada de control de acceso) al grupo, en lugar de configurar una ACE por cada propiedad. Gracias a estos conjuntos de propiedades, se puede realizar una delegación de acceso más detallado y flexible que en versiones anteriores. Además, Exchange 2007 incluye varias mejoras:  Los conjuntos de propiedades han dejado de basarse en los conjuntos de propiedades de Directorio Activo, por lo que se elimina la incertidumbre de cambios en las versiones futuras de los conjuntos de propiedades de Directorio Activo.  Los atributos creados por la extensión de esquema de Exchange son los únicos miembros de los conjuntos de propiedades específicos de Exchange.  Los conjuntos de propiedades específicos de Exchange permiten la crea- ción y la implementación de un modelo de permisos de seguridad delega- do, que es específico para la administración de los datos de destinatarios de correo de Exchange. Dado que los atributos se trasladan entre conjuntos de propiedades, se debe actualizar la estructura de permisos de destinatarios de Exchange 2003 al implementar Exchange 2007 en un entorno heredado. Esto se hace ejecutando el comando setup.exe /PrepareLegacyExchangePermissions. 135

La protección de datos personales: Soluciones en entornos Microsoft Los administradores de Exchange 2007 pueden administrar tres tipos de datos:  Datos globales. Los datos globales se encuentran almacenados en un contenedor de configuración de Directorio Activo y no están asociados a ningún servidor en particular. Entre los datos que se incluyen dentro de este grupo están las directivas de buzón, listas de direcciones y la configu- ración de mensajería unificada y, en general, los datos globales de organi- zación de Exchange, por lo que se recomienda que sólo a los usuarios de confianza se les permita el acceso a esta información.  Datos de destinatarios. En este grupo se incluye información de destinatarios, grupos de distribución, contactos habilitados para correo, buzones y otros tipos de destinatarios como carpetas públicas.  Datos de servidor. Se encuentran almacenados en los nodos de cada uno de los servidores Exchange en el Directorio Activo. En este grupo se encuentra la información particular de conectores de recepción, directo- rios virtuales, configuraciones por servidor y datos de grupos de almacenamiento y buzones. La función de administradores de la organización de Exchange ofrece a los administradores acceso completo a todas las propiedades y objetos de Exchange en la organización de Exchange. Cuando se instala Exchange 2007, se agrega la función Administradores de la organización de Exchange como miembro del grupo local de administradores en el equipo donde esté instalando Exchange. La función de administradores de destinatarios de Exchange tiene permisos para modificar cualquier propiedad de Exchange en un usuario, contacto, grupo, lista de distribución dinámica u objeto de carpeta pública de Directorio Activo. Los usuarios que son miembros de esta función de administrador de destinatarios de Exchange no tienen permisos sobre los dominios en los que no se ha ejecutado Setup.exe /PrepareDomain. La función de administradores de servidores de Exchange sólo tiene acceso a los datos de configuración de Exchange del servidor local, ya sea en Directorio Activo o en el equipo físico en el cual está instalado Exchange 2007. La función de administradores de sólo vista de Exchange tiene permiso de sólo lectura en todo el árbol de la organización de Exchange en el contenedor de configu- ración de Directorio Activo y permiso de sólo lectura en todos los contenedores de dominio de Windows que tienen destinatarios de Exchange. La función de Administradores de carpetas públicas de Exchange tiene permisos administrativos para administrar todas las carpetas públicas. Esta función de administrador tiene concedido el derecho extendido “Crear carpeta pública de alto nivel”. Los miembros de esta función pueden crear y eliminar carpetas públicas y administrar configuraciones de carpeta pública como réplicas, cuotas, límites de edad, permisos administrativos y permisos de cliente. 136

La aplicación del reglamento de seguridad en los sistemas Microsoft Con respecto a los destinatarios de correo, Exchange otorga de forma predeterminada permisos completos y permiso de enviar como al propietario del buzón. Ningún otro destinatario tiene permisos en otro buzón que no sea el suyo propio, ni siquiera el administrador de la organización. Estos permisos se gestionan en dos niveles: permisos del buzón y permisos de Directorio Activo. Permisos del buzón Dentro de los permisos del buzón se encuentra el permiso de acceso completo al buzón (Full Access). Cuando se le otorga a un usuario el acceso completo al buzón de otro usuario, éste adquiere la capacidad de abrir y leer el contenido de todo el buzón; sin embargo, no puede enviar mensajes como si fuera el otro usuario. Este diseño de seguridad lo implementa por defecto Exchange Server 2007 para evitar que, debido a la necesidad de acceder a un buzón, se pueda suplantar la identidad de otra persona, garantizando así la procedencia de los mensajes en la organización Exchange. Para otorgar permisos de enviar como otro usuario, existe el permiso independiente ReceiveAs a nivel de Directorio Activo. La lista de permisos aplicables a nivel de buzón es la siguiente:  FullAccess.  SendAs.  ExternalAccount.  DeleteItem.  ReadPermission.  ChangePermission.  ChangeOwner. Permisos de Directorio Activo El permiso SendAs o enviar como permite que un usuario envíe mensajes desde el buzón de otro usuario como si fuera el propietario del buzón. En ocasiones, algunos roles de personas requieren disponer de esta capacidad. Sin embargo, si se realiza sin el consentimiento del propietario se podría estar vulnerando su privacidad y confidencialidad. Otro de los permisos importantes es el de ReceiveAs o recibir como. Este permiso otorga privilegios de inicio de sesión en todos los buzones de la base de datos en donde se aplica el permiso. También se puede otorgar a nivel de grupo de almacenamiento; en este caso se heredaría a todas las bases de datos del grupo. Por ejemplo, es posible que desee conceder acceso a la base de datos de buzones para el acceso móvil o para una revisión legal. 137

La protección de datos personales: Soluciones en entornos Microsoft La lista de permisos aplicables a nivel de Directorio Activo es la siguiente:  CreateChild.  DeleteChild.  ListChildren.  Self.  ReadProperty.  WriteProperty.  DeleteTree.  ListObject.  ExtendedRight.  Delete.  ReadControl.  GenericExecute.  GenericWrite.  GenericRead.  WriteDacl.  WriteOwner.  GenericAll.  Synchronize.  AccessSystemSecurity. 11.2.4.3. Control de acceso a archivos de Microsoft Office 2007 Normalmente consideramos los ficheros generados a través de Ms Office System como ficheros convencionales, y como tal podemos emplear mecanismos a través de las DACL, descritas anteriormente. Éstos permiten extender dicha funcionalidad, asignando derechos digitales mediante el uso de la tecnología IRM (Information Rights Management). IRM supone una extensión de RMS (Rights Management Services). Este sistema se basa en conexiones de confianza que establece una implementación basada en el uso de certificados. Los mecanismos de seguridad quedan establecidos mediante reglas de uso, donde los usuarios reciben una licencia capaz de interpretar dichas reglas. 138

La aplicación del reglamento de seguridad en los sistemas Microsoft IRM: aplicación de restricción. Para la realización de la protección y autentificación de los documentos RMS emite una serie de certificados de cuenta de permisos que se encuentran asociados a cuentas de usuario y equipos específicos. Las licencias de uso van a permitir que los usuarios puedan utilizar contenido protegido con RMS. Los certificados de cuenta de permisos contienen la clave pública del usuario, que se utiliza para cifrar los datos que irán destinados a un usuario específico. Los elementos que intervienen en todo el proceso de funcionalidad de los mecanismos de RMS son:  Certificados emisores de licencias de servidor. Se expiden a servidores para que puedan emitir licencias para la publicación, de uso, certificados emisores de licencia de clientes y la generación de plantillas de permisos. El certificado emisor de licencias de servidor que se concede a un servidor de licencias contiene la clave pública del servidor de licencias, mientras que el certificado emisor de licencias de servidor que se concede al servidor de certificación raíz contiene la clave pública del servidor de certifica- ción raíz.  Certificados emisores de licencias de clientes. Se utilizan para otorgar a un usuario que pueda publicar contenido protegido mediante los mecanismos de RMS sin estar conectado a la red corporativa. Contiene las claves pública y privada del certificado; esta última cifrada con la clave pública del usuario que solicitó el certificado. Contiene, asimismo, la clave pública del servidor que emitió el certificado.  Certificados de equipo RMS. Otorga la confianza a equipos o dispositivos para el servicio de RMS. Contiene la clave pública del equipo activado. La clave privada correspondiente se encuentra en la caja de seguridad del equipo. Esta caja de seguridad es única para cada equipo y se recibe 139

La protección de datos personales: Soluciones en entornos Microsoft cuando se instala y activa el cliente RMS. Se basa en un identificador hardware y contiene la clave privada del equipo activado.  Certificados de cuentas de permiso. Identifica a un usuario con un equipo o dispositivo específico. Contiene las claves pública y privada del usuario, esta última cifrada con la clave pública del equipo activado.  Licencias de publicación. Contienen los permisos específicos que se aplican a los datos protegidos mediante RMS. Contiene la clave de contenido simétrica necesaria para descifrar el contenido que está cifrado con la clave pública del servidor que ha emitido la licencia.  Licencias de uso. Especifica los permisos que se aplican a contenido protegido con RMS en el contexto de un usuario autenticado. Contiene la clave de contenido simétrica necesaria para descifrar el contenido, que se encuentra cifrada con la clave pública del usuario. Los certificados que se pueden emitir pueden ser en función del tiempo de validez de utilización para el certificado. Estos tipos de certificados son permanen- tes, donde de forma predeterminada el valor de validez es de 365 y los certificados temporales presentan una duración de 15 minutos, y están especificados para equipos de uso múltiple y evitar que se pueda tener acceso a la información de dicho equipo. En la operativa de funcionalidad del sistema, cuando un usuario intenta acceder por primera vez a un documento que presenta asignados derechos digitales, el sistema se conecta al servidor de Licencias, donde se verifican las credenciales y se permite la descarga de una licencia para su uso. Ésta, como hemos comentado anteriormente, puede ser permanente o temporal. Mientras no dispongamos de esta licencia, no podremos acceder al documento. Una vez que la información se encuentra disponible, Microsoft Office envía las credenciales al servidor RMS, donde se comprobará si éstas son las necesarias para la apertura del documento. En el caso de que ya tuviéramos el certificado instalado en la máquina, sería necesario solamente comprobar si tenemos las credenciales correspondientes para acceder al documento, libro o presentación, así como qué derechos de los existentes tendremos sobre el mismo. Microsoft Office 2007 puede garantizar los derechos a diferentes tipos de documentos, así como a mensajes de correo electrónico mediante la tecnología IRM. Los documentos que admiten una posible implementación de la tecnología de IRM son los siguientes: Ficheros de Word Tipo de fichero Extensión Documento .doc Documento .docx 140

La aplicación del reglamento de seguridad en los sistemas Microsoft Documento con macros habilitadas .docm Plantilla .dot Plantilla .dotx Plantilla con macros habilitadas .dotm Ficheros de Excel Tipo de fichero Extensión Libro .xls Libro .xlsx Libro con macros habilitadas .xlsm Plantilla .xlt Plantilla .xltx Plantilla con macros habilitadas .xltm Libro binario No-XML .xlsb Complemento .xla Complemento con macros habilitadas .xlam Ficheros de PowerPoint Tipo de fichero Extensión Presentación .ppt Presentación .pptx Presentación con macros habilitadas .pptm Plantilla .pot Plantilla .potx Plantilla con macros habilitadas .potm Presentación .pps Presentación .ppsx Presentación con macros habilitadas .ppsm Tema de Office .thmx Adicionalmente a la información antes citada, Ms Outlook 2007 también presenta una extensión para la tecnología IRM, con objeto de asignar derechos digitales sobre los correos gestionados a través de este cliente de correo, ofreciendo además soporte de IRM para los diferentes archivos anteriormente citados. 141

La protección de datos personales: Soluciones en entornos Microsoft En caso de querer implantar esta tecnología, hay que tener presente que como mínimo es necesario que se encuentre instalado el cliente RMS Service Pack 1. Esta condición no es demandada en Windows Vista, puesto que dicha extensión ya se encuentra instalada por defecto. Para Word 2007, Excel 2007 y PowerPoint 2007, IRM permite que una cuenta asociada al servicio pueda asignar 3 tipos de permisos básicos a los documentos: lectura, cambio y control total. Una vez asignados estos derechos, sólo aquellos que tengan privilegios pueden acceder a dicho documento independientemente de donde pueda encontrarse o a donde haya podido llegar. Un usuario con permiso de lectura puede abrir el fichero, pero no modificarlo, copiar o imprimir el contenido. Un usuario con permisos de cambio puede leer, editar y guardar cambios en el fichero, pero no imprimirlo. Adicionalmente a estos tres permisos básicos, IRM permite la asignación de otros más especiales:  Establecer una fecha de caducidad para el documento.  Permitir imprimir el documento.  Permitir que usuarios con sólo lectura puedan copiar el contenido.  Permitir acceder al contenido del documento mediante programación. IRM: propiedades de permiso restringido. Cuando los permisos se establecen a mensajes de correo electrónico a través de Outlook 2007, se pueden controlar los destinatarios de estos, y que puedan ser copiados, reenviados o impresos. Además, una de las características que consiguen los mensajes de correo mediante el uso de IRM es el cifrado automático de los mismos, mediante los mecanismos de clave pública-privada de los destinatarios. El sistema permite, mediante un complemento para Internet Explorer, que documentos protegidos mediante la tecnología de IRM puedan ser visibles a través 142

La aplicación del reglamento de seguridad en los sistemas Microsoft del navegador, siempre y cuando el receptor de los mismos tuviera permisos de lectura sobre los documentos. El uso de esta tecnología en un escenario de aplicación de normativas de LOPD, garantizará el control del acceso independientemente del lugar desde donde haya podido llegar la información, y garantizará no solamente el control de acceso, sino la confidencialidad de los datos mediante el cifrado de los mismos. IRM: permiso restringido. La tecnología IRM puede combinarse con el uso de una solución como Microsoft Office SharePoint Server 2007 (MOSS 2007), permitiendo esta arquitectura el mantenimiento de la infraestructura y uso de la gestión de Derechos Digitales. En este sentido, MOSS 2007 permite el establecimiento de IRM para listas o bibliotecas, incluyendo protectores para los siguientes tipos de archivos:  Formularios de Microsoft Office InfoPath.  Formatos de archivo 97 a 2003 para los siguientes programas de Microsoft Office: Word, Excel y PowerPoint.  Formatos XML abiertos de Office para Microsoft Office Word 2007, Microsoft Office Excel 2007 y Microsoft Office PowerPoint 2007.  Formato XPS (XML Paper Specification). Las siguientes URLs presentan guías donde se describen paso a paso los procedimientos y mecanismos para implementar una solución de RMS con Microsoft Office SharePoint Server 2007. La primera en un escenario con RMS Service Pack 2 y la segunda con el servicio de Windows Server 2008 de Directorio Activo RMS. http://www.microsoft.com/downloads/details.aspx?FamilyID=7bab2321-71e6-4cf2- 8bcd-0880e0d1cda3&DisplayLang=en 143

La protección de datos personales: Soluciones en entornos Microsoft http://technet2.microsoft.com/windowsserver2008/en/library/07133490-20fe-4bb3- 9870-ced0cd01f5f61033.mspx?mfr=true Adicionalmente a los mecanismos que permiten realizar las implementaciones de derechos con IRM, Office 2007 proporciona otros mecanismos de seguridad para garantizar los accesos sobre los documentos. Entre estas características podemos citar como importantes la posibilidad de establecer procedimientos de cifrado para Office Access, Excel, Powerpoint y Word 2007, como trataremos con posterioridad, y la aplicación de listas de publicadores de confianza y firmas digitales, que permiten garantizar la integridad de la información disponible. Además de esta capacidad común, las diferentes aplicaciones de Office presentan funcionalidades específicas para la protección de documentos. En el caso de Word 2007, estas características para la protección de documentos se pueden activar desde el menú Revisar bajo el epígrafe de “proteger documento”. La activación y desactivación de estas configuraciones se establece bien por contraseña, bien por usuarios autentificados. Éstas son las diferentes restricciones que pueden aplicarse:  Restricción de formato. Limita los estilos que pueden aplicarse al documento.  Restricción de edición. El sistema admite sólo determinados tipos de edición: para cambios realizados (permite que los usuarios efectúen cambios pero los resalta para que el autor los controle y determine si son aceptados o los rechaza), comentarios (permite que un revisor especifique comentarios para cambiar el contenido del documento), formularios (protege el documento ante cambios, excepto en aquellos formularios o secciones no protegidos) o sin cambios (modo de solo lectura). Estas restricciones pueden aplicarse a usuarios y grupos, pudiendo establecerse combinaciones. Excel 2007 presenta también funcionalidades para la protección de elementos. Los elementos que son posibles proteger son:  Proteger hoja. Protege celdas seleccionadas dentro de una hoja de cálculo, impidiendo la modificación de las celdas estén o no bloqueadas. Esta protección permite también otorgar acceso a operaciones específicas dentro de la hoja.  Permitir que los usuarios modifiquen rangos. Establece rangos que pueden ser desprotegidos mediante contraseña para que puedan ser modificados. Se permitirá además que usuarios, grupos y equipos puedan modificar una celda sin necesidad de establecer la contraseña.  Proteger libro. Especifica los elementos dentro del libro que deben ser protegidos: estructuras y ventanas. Adicionalmente se puede especificar una contraseña que debe ser utilizada para quitar esta protección.  Proteger y compartir libro. Esta función hace que el libro sea compartido y activa el control de cambios. Se pueden realizar modificaciones sobre el 144

La aplicación del reglamento de seguridad en los sistemas Microsoft libro, pero se requiere el control de los mismos. Adicionalmente se puede especificar una contraseña que debe ser utilizada para quitar esta protec- ción. Access 2007 incluye un conjunto de funcionalidad para establecer protección sobre la base de datos y los objetos contenidos en ella.  Mostrar u ocultar objeto en la Base de datos. Permite ocultar objetos pero no va a impedir que un usuario pueda mostrar objetos que se encuentran ocultos.  Seguridad a nivel de usuario. Access 2007 permite el establecimiento de diferentes niveles de acceso a objetos sensibles. Para ello se establece una contraseña y un identificador para cada usuario. Cuando los usuarios abren la base de datos tendrán que introducir la contraseña, que junto con el identificador asigna las credenciales necesarias para acceder a determinados objetos únicamente.  Access 2007 admite el cifrado de la base de datos, haciendo ilegible su contenido. El cifrado se establece mediante contraseña y se puede invertir el procedimiento. Aunque el mecanismo es seguro, debería combinarse con la asignación de derechos, puesto que cualquiera que conociera la contraseña podría acceder a todos los objetos que tuviera.  También se admite el firmado digital en Access 2007. Cuando un usuario firma una base de datos se genera un hash para el proyecto VBA y las macros contenidas en la base de datos. El sistema permite garantizar mediante el uso de contraseñas la apertura o no de un documento, libro, presentación o base de datos, o bien si ésta es posible lle- varla a efecto en modo sólo lectura exclusivamente. Aunque esta protección es váli- da en muchos escenarios, nos encontramos que no podemos implementarla obser- vando la LOPD. En este sentido, el reglamento exige actualmente la existencia de cuentas diferenciadas para cada usuario que tenga acceso a la información de carác- ter personal, cuestión que no cumpliríamos mediante la aplicación de esta contrase- ña simplemente, por ser única para todo aquel que intentara abrir el documento. 11.2.5. Artículo 91. Control de acceso (punto 2) 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. Desde la ventana de seguridad, tanto en Windows Server 2008 como en Windows Vista, para cada uno de los objetos fruto del control de acceso, el sistema proporciona la capacidad para ver cuáles son los usuarios y grupos que tienen acceso y cuáles serán los derechos asignados. Debido a que el resultado final de los derechos resulta de la suma de permisos asignados al usuario más a aquellos grupos a los que perteneciera, en Windows 145

La protección de datos personales: Soluciones en entornos Microsoft Server 2008 y Windows Vista se pueden examinar los permisos efectivos que quedan sobre el objeto para los usuarios o grupos que se especifiquen. Dentro de las utilidades externas a Microsoft, Dumpsec de SystemTools es una herramienta gratuita que nos va a permitir realizar volcados de las ACL de objetos administrables, con lo que nos permite además facilitar la información de cara a la realización de informes o un dossier de seguridad. 11.2.6. Artículo 91. Control de acceso (puntos 4 y 5) 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. Como ya definimos en su momento, la asignación de los permisos se establece a través de las DACL, y será una capacidad inherente al creador del fichero o aquel para el que se establezca, tanto el control como la asignación de dichos permisos. Esta labor de asignación de permisos se realiza desde la pestaña de seguridad con las capacidades para cambiar los permisos y tomar la posesión si correspondiera. 11.2.7. Artículo 92. Gestión de soportes y documentos 1. Los soportes y documentos que contengan datos de carácter personal deberán permitir identificar el tipo de información que contienen, ser inventariados y sólo deberán ser accesibles por el personal autorizado para ello en el documento de seguridad. Se exceptúan estas obligaciones cuando las características físicas del soporte imposibiliten su cumplimiento, quedando constancia motivada de ello en el documento de seguridad. 2. La salida de soportes y documentos que contengan datos de carácter personal, incluidos los comprendidos y/o anejos a un correo electrónico, fuera de los locales bajo el control del responsable del fichero o tratamiento deberá ser autorizada por el responsable del fichero o encontrarse debidamente autorizada en el documento de seguridad. 3. En el traslado de la documentación se adoptarán las medidas dirigidas a evitar la sustracción, pérdida o acceso indebido a la información durante su transporte. 4. Siempre que vaya a desecharse cualquier documento o soporte que contenga datos de carácter personal deberá procederse a su destrucción o borrado, mediante la adopción de medidas dirigidas a evitar el acceso a la información contenida en el mismo o su recuperación posterior. Para el control de la información y teniendo en cuenta la posibilidad existente de que los datos puedan salir fuera de la organización, hay que tener previstos una serie de mecanismos que permitan: 146

La aplicación del reglamento de seguridad en los sistemas Microsoft  Establecer los procedimientos de comunicación y autorización de datos fuera del control del responsable del fichero.  Garantizar que en el transporte no se pueda producir un acceso o manipu- lación de la información contenida en los soportes. Al igual que ya hemos comentado anteriormente, MOSS 2007 puede establecerse como mecanismo para garantizar los procesos de comunicación de estos procedimientos, así como para el almacenamiento de la información correspondiente a la salida de los soportes. En el otro sentido, cuando determinamos la seguridad que establece el uso de mecanismos de autentificación y acceso controlado a recursos, estamos estableciendo procedimientos para asegurar esta información mediante los métodos convencionales que permiten llegar a los datos compartidos. Pero si alguien tuviera acceso físico, bien al depósito de datos o incluso a las copias de seguridad o las máquinas físicas que guardarán la información, podrían llegar a acceder a dicha información no utilizando los métodos convencionales, por lo cual la información se encontraría comprometida. Cómo evitar estos mecanismos de acceso físicos en muchas ocasiones puede ser complejo o inviable; se puede realizar un proceso de cifrado para los datos que garanticen que éstos, independientemente de quien haya podido obtenerlos, van a encontrarse salvaguardados por los mecanismos de encriptación. En los diferentes puntos que hemos ido viendo, nos hemos encontrado ya algunas de estas funcionalidades de cifrado, como el caso de la tecnología IRM, que perfectamente podrían servir para cubrir las necesidades para cumplir este artículo. Aunque de forma más generalizada para todo tipo de archivos, tanto Windows Vista como Windows Server 2008 nos ofrecen dos procedimientos que garantizan la confidencialidad de los ficheros:  El Sistema de ficheros cifrados (EFS o Encripted File System).  Bitlocker. EFS es un mecanismo que proporciona un sistema de cifrado totalmente transparente para el usuario y no ofrece integridad en los datos o autentificación, por lo que no deberán obviarse otros mecanismos de seguridad. EFS utiliza el sistema de certificados estándar X509 para las credenciales de acceso. Cada fichero que se protege es encriptado con una clave de encriptación de fichero (FEK) generada aleatoriamente mediante algoritmo AES. EFS posteriormente utilizará mecanismos de clave pública para cifrar la FEK. Cada usuario que accede a un fichero protegido mediante EFS debería tener una clave privada que corresponda a una de las claves públicas con las que se cifra la FEK, y así poder acceder a él. EFS presenta 4 operaciones: abrir, leer, escribir y convertir ficheros, que utilizan como cualquier otra aplicación las APIs Win32.  Abrir. La aplicación que intenta acceder a los ficheros comprimidos utiliza la API CreateFile() u Openfile(). Cuando el fichero es abierto, EFS estable- 147

La protección de datos personales: Soluciones en entornos Microsoft ce los mecanismos para proporcionar la clave de encriptación y crea los diferentes elementos para la desencriptación y encriptación de los datos. EFS: esquema de cifrado.  Lectura. Las aplicaciones utilizan las APIs ReadFile(), ReadFileEx() y RealFileScatter() para leer los ficheros encriptados. Cuando se lee un fichero cifrado, los datos son cargados en memoria y EFS los desencripta. Los datos descifrados son devueltos a la aplicación. Cuando la aplicación requiere que un fichero encriptado sea mapeado en memoria, los datos son desencriptados antes de ser mapeados en memoria.  Escritura. Las aplicaciones utilizan las APIs WriteFile(), WriteFileEx() y WriteFileScatter(). Cuando se escribe sobre un fichero cifrado, EFS encripta los datos donde se encuentren y posteriormente se escriben en el disco. Cuando una aplicación requiere que un fichero deje de estar mapeado en memoria, los datos mapeados son encriptados antes de ser escritos en el disco.  Convertir. Cuando se realiza el proceso de conversión de un fichero, se realizan una serie de procedimientos que comienzan con un chequeo de los datos y la comprobación de si existe espacio de disco suficiente. EFS genera posteriormente la clave de encriptación y realiza el cifrado con la clave pública del usuario activo. Una vez creada la FEK, EFS genera los metadatos que contienen el campo de desencriptación de datos (DDF), el cual mantendrá las claves públicas de los usuarios que puedan acceder al fichero. EFS genera un fichero temporal donde copia los datos del fichero de origen para propósitos de recuperación. Cada dato en el fichero original es truncado a longitud cero, devolviendo la longitud original y eliminando los datos. EFS escribe los metadatos en el fichero original que se encuentra vacío y marcado como encriptado y los datos en el fichero temporal. Para finalizar, EFS lee los datos del fichero temporal y los 148

La aplicación del reglamento de seguridad en los sistemas Microsoft escribe en el original de forma encriptada, realiza las comprobaciones para la coherencia de datos y elimina el fichero temporal. Si por algún motivo dado la encriptación no fuera satisfactoria, EFS devolvería el fichero al estado original. En caso de necesitar establecer una recuperación para los ficheros cifrados, debido a que el usuario propietario o la clave de desencriptación se han eliminado, existen mecanismos para la recuperación de dichos datos. Ésta dependerá de si el equipo se encuentra o no integrado en el dominio. EFS: agente recuperador de datos cifrados. Si la máquina está integrada en el dominio, se establece una política de recupe- ración que es automáticamente habilitada para todas las máquinas en el dominio, siendo distribuida a través de las políticas de grupo. Cuando se genera una política de recuperación, todas las FEKs son cifradas con las claves públicas de los agentes de recuperación de claves. EFS reescribe el campo de recuperación de datos (DRF) cada vez, para asegurarse que se utiliza la política de recuperación más actualizada. Cuando el administrador del dominio se valida por primera vez, en el controlador de dominio se genera un certificado de recuperación de EFS y se almacena en el perfil local, siendo además añadido a la política de recuperación. Además, cualquier administrador de dominio puede crear agentes de recuperación de datos en el dominio y generar certificados de EFS para estos agentes de recuperación pudiendo ser añadidos a las políticas de recuperación. En el caso de utilizar una máquina que no es miembro del dominio, el sistema no crea ningún agente recuperador de datos cifrados inicialmente y requiere que sea el administrador el que modifique la política y realice los procedimientos necesarios. Cuando estemos utilizando los mecanismos de cifrado de EFS tendremos que tener en cuenta que si una aplicación genera un temporal en base a un fichero cifrado mediante EFS, éste no se encontrará necesariamente encriptado, si no que dependerá de si hemos establecido el cifrado sobre la carpeta donde se creara. Para asegurarnos de que los ficheros temporales de ficheros cifrados mediante EFS tienen 149

La protección de datos personales: Soluciones en entornos Microsoft la misma seguridad, deberíamos habilitar EFS sobre la carpeta y no solamente sobre los ficheros. Con objeto de preservar los mecanismos de seguridad en las copias de seguridad, cuando se realice una copia de seguridad de ficheros cifrados mediante mecanismos de EFS, con herramientas certificadas por Microsoft, se garantiza que estos ficheros de respaldo mantienen su condición de cifrado mediante EFS. Esto también sucederá con los sistemas de medios extraíbles que utilicen NTFS y que son gestionados por el sistema operativo. Como estos medios no migran ni las claves de cifrado ni la de los agentes de recuperación de datos cifrados, la garantía de seguridad es muy alta. EFS: propiedades de un fichero cifrado. EFS: copia de seguridad de clave de cifrado. El otro mecanismo de implementación de sistemas de cifrado, viene proporcio- nado por el uso de la tecnología Bitlocker. Este nuevo sistema, disponible únicamen- te en los Sistemas Operativos Windows Vista (en sus versiones Enterprise y Ultimate) y Windows Server 2008, implementa mecanismos para el cifrado de 150

La aplicación del reglamento de seguridad en los sistemas Microsoft disco, a diferencia de EFS que basaba su funcionalidad en el cifrado de ficheros. Bitlocker utiliza AES (Advance Encription Standard) como algoritmo de cifrado en modo CBC (Cypher Block Chaining) y con objeto de evitar los ataques por manipu- lación de datos cifrados incorpora un difusor adicional independiente de AES-CBC. Los mecanismos de seguridad implementados por Bitlocker se complementan mediante unas nuevas especificaciones de seguridad hardware: Trusted Platform Module (TPM). Este nuevo chip TPM proporciona una plataforma segura para el almacenamiento de claves, contraseñas o certificados, dificultando el ataque contra las mismas. Aunque nuestros equipos no dispusieran de este mecanismo de seguridad, las especificaciones de Bitlocker admiten su funcionalidad sin el chip TPM. Bitlocker: configuración de cifrado. Bitlocker proporciona un filtro en el stack del sistema de Windows Vista encargado de realizar los procesos de cifrado y descifrado de una forma totalmente transparente, cuando se escribe o se lee en un volumen protegido. Este mismo mecanismo interviene también cuando el equipo entra en el modo de hibernación. De este modo se garantiza también la seguridad del fichero de paginación, los ficheros temporales y el resto de elementos que puedan contener información sensible. Una vez que el mecanismo de cifrado ha sido puesto en marcha, la clave de cifrado es eliminada del disco y posteriormente almacenada en el Chip TPM. Con objeto de evitar un posible ataque al sistema hardware por posibles vulnerabilidades, se proporcionan mecanismos de autentificación mediante sistemas adicionales tales como el uso de Token (llave USB) o una password (PIN) para evitar esta posibilidad. El uso combinado de mecanismos hardware y software evita determinados ataques que tienen como objetivo la modificación de datos que, aunque cifrados, podrían provocar una vulnerabilidad en el sistema, siendo explotada posteriormente para disponer de acceso al sistema. La implementación de Bitlocker requiere de la existencia de condiciones para ello. Un factor importante es que el sistema necesita dos particiones NTFS, una de las cuales, la partición activa, que albergará el sistema de arranque, no se encontrará cifrada. Bitlocker también proporciona mecanismos para garantizar que no se han producido modificaciones en el arranque del sistema, tales como aquellas que pueden proceder de ataques tipo malware, que pudieran producir una agresión colateral o el control del acceso al sistema. 151

La protección de datos personales: Soluciones en entornos Microsoft A la hora de establecer un sistema de implementación para el cifrado de la unidad de disco para Bitlocker, Microsoft tuvo en cuenta determinados factores y evaluó la posibilidad de incorporar algunos sistemas de implementación de cifrado. Uno de los elementos que se tuvieron en cuenta es que Bitlocker no debería consistir solamente en un elemento de cifrado, sino que debería garantizar, gracias a la autenticación de datos, el evitar que mediante una manipulación de los datos cifrados pudiera introducirse una modificación a ciegas en el código del sistema operativo, provocando una debilidad en el mecanismo de arranque con Bitlocker o conseguirse una escalada de privilegios en el sistema. Además, debería evitar la predicción de la función de cifrado mediante la manipulación de datos cifrados y la obtención de datos en texto plano. El mecanismo natural de implementación de cifrado para evitar estos mecanismos de ataque es la utilización de MAC (Message Autenthication Code) para cada bloque de datos del disco. El problema que plantea el uso de este mecanismo es que necesitaríamos establecer una reserva de sectores para almacenar el MAC, con lo cual tendríamos un uso limitado en la capacidad de almacenamiento de hasta un 50 %. Además, bajo las condiciones actuales de implementación de este mecanismo en sistemas de alto procesamiento de datos con accesos de lectura y escritura, podremos encontrarnos con problemas de rendimiento o corrupción de sectores. Si no queremos escribir en sectores x, sin dañar x+1 x-1 en procesos de caída del sistema no controlados o por pérdida de energía, tendremos que tener en cuenta que en el caso de escribir en un sector x el sistema deberá leer el sector, desencriptarlo, encriptarlo y nuevamente escribir todos los sectores que correspondan al bloque. Si falla el sistema cuando se escriben sectores en el bloque nuevo pero quedan pen- dientes otros, todo el bloque puede quedar corrompido. Poor-man consiste en otro de los posibles mecanismos para la implementación de seguridad que permite generar bloques cifrados con un tamaño que oscila entre los 512 bytes y los 8192 bytes, de tal forma que una leve modificación en uno de los caracteres del bloque modifica de forma aleatoria todo el bloque. Con objeto de evitar el mecanismo de secuenciación moviendo datos cifrados de un sector a otro, se generan cambios del algoritmo para cada sector. De esta forma, aunque el potencial atacante tuviera acceso a los datos tanto cifrados como en texto plano, la variedad del mecanismo de secuenciación y los cambios en el algoritmo evitan posibilidades de predicción del sistema de cifrado. Por mecanismos de rendimiento el mejor sistema que se puede emplear para el cifrado de datos de disco es AES-CBC, pero ya advertimos anteriormente el riesgo de posibles ataques al utilizar únicamente este mecanismo. La decisión finalmente establecía la utilización de AES-CBC para la encriptación primaria y una clave difusora independiente para texto plano. Este difusor tiene como objetivo fortificar frente a los ataques de manipulación, mejor que lo que puede realizar de forma única el algoritmo de AES-CBC. Inicialmente, la implementación de Bitlocker en Windows Vista sólo admitía el cifrado de la partición donde estaba instalado el Sistema Operativo, aunque desde 152

La aplicación del reglamento de seguridad en los sistemas Microsoft la salida de Windows Vista SP1, el sistema admite además el cifrado de otras particiones de datos, siempre y cuando no sea la de arranque. 11.2.8. Artículo 93. Identificación y autenticación (puntos 1 y 2) 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. 11.2.8.1. Autentificación Windows Vista y Windows Server 2008 Cuando definimos la capacidad para acceder a un objeto, lo realizamos claro está en función de los usuarios especificados para ello. Con objeto de evitar la confusión de usuarios, los sistemas presentan diferentes mecanismos con objeto de identificar quienes son. Tanto Windows Server 2008 como Windows Vista, utilizan para los procedimientos cuentas de usuario con diferentes procedimientos para la autentificación, sin que existan para ello procedimientos anónimos. Por tanto, independientemente de si los usuarios acceden a un recurso a través de la red o lo hacen localmente, ejecutan un proceso en una máquina o mediante un servicio de Terminal; cada una de estas acciones estará controlada y auditada para el usuario que la realizó. Una de las modificaciones más importante que ha tenido el Reglamento de Seguridad viene definida precisamente en este artículo. Por un lado, la necesidad de identificar de forma inequívoca y personalizada aquellos usuarios que accedan al sistema, y por otro la obligatoriedad del cambio de contraseña que como mínimo será anual. En este sentido, el reglamento limita el uso de cuentas genéricas (cues- tión que en el anterior reglamento sólo era requerido para los Datos de Nivel Me- dio), impidiendo su uso y requiriendo que cada usuario tenga su cuenta y la utilice con los fines para las que fue generada verificando por lo tanto su autorización. De cara a coordinar este proceso de identificación de los usuarios, Windows presenta una serie de mecanismos para poder autentificar los usuarios que intentan iniciar un proceso de validación de cuenta. En este sentido, este procedimiento podrá variar si el procedimiento es local o bien se realiza en un dominio. Cuando el procedimiento de autentificación se realiza localmente, existe un archivo local donde se depositan los datos para cotejar los datos de autentificación: SAM (Security Account Manager). Cuando la validación se realiza en un dominio, éste se establece contra los Controladores de Dominio. Aunque en ambos sistemas se ofrecen mecanismos para el control de usuarios, la administración en un sistema de red basado solo en cuentas locales, sería mucho más complicado de administrar que utilizando los mecanismos proporcionados en el Directorio Activo. Como en toda base de datos, y no debemos perder el punto de vista que tanto la SAM como el Directorio Activo lo son, existen una serie de identificadores con 153

La protección de datos personales: Soluciones en entornos Microsoft objeto de evitar incongruencias en los datos que se manejan. De cara a estas cuentas de usuario ambos sistemas presentan un único identificador de seguridad (SID) para cada cuenta de usuario, aunque hay que tener presente que el Directorio Activo presenta una flexibilidad de la que carece la base de datos local de un equipo. Este SID, que identifica inequívocamente a un usuario, presenta una serie de atributos que se asociarán al mismo, tales como nombres, contraseñas, descripcio- nes, etc. La definición de los atributos para los objetos usuarios definen muchas más propiedades para el Directorio Activo que para la SAM, por lo que se permite asociar un mayor número de datos a una cuenta. Otra de las ventajas que ofrecen los mecanismos del Directorio Activo es poder capacitar o delegar a otros usuarios acceder a determinadas o todas las propiedades de otra cuenta; por ejemplo, conocer las extensiones del teléfono del trabajo u otro dato que pudiera ser necesario. Los sistemas Windows Server 2008 y Windows Vista utilizan dentro de los procedimientos de autentificación un sistema basado en el modelo de autentifica- ción local: LSA (Local Security Authority). La LSA es la encargada de recoger las credenciales facilitadas para el inicio de sesión. Para ello, soporta unos paquetes de autentificación personalizables, que son los encargados de inicializar las subrutinas de autentificación. Estos paquetes admiten la extensión en los mecanismos de autentificación, por ejemplo para utilizar una tarjeta tipo ATM y un número de identificación personal (PIN), como mecanismos para presentar las credenciales necesarias con las que iniciar una sesión sustituyendo al clásico sistema de valida- ción basado en usuario y contraseña. Además, estos paquetes de autentificación son los encargados a través de la LSA de inicializar unos mecanismos que tendrán como resultado cotejar la información facilitada con las bases de datos que le pudieran corresponder. Estos mecanismos pueden ser tan variados como utilizar ticket de sesión Kerberos o utilizar certificados de sesión de cliente. Una vez que se ha realizado satisfactoriamente este proceso de autentificación, el correspondiente paquete de autentificación crea un inicio de sesión y devuelve la información a la LSA que la utilizará para crear un testigo para el nuevo usuario. Este testigo, entre otras características, incluye un identificador único local (LUID) que se llama formalmente LogonID. La sesión de validación (Logon Session) comienza cuando la autentificación se ha realizado satisfactoriamente y finalizará cuando el usuario cierra la sesión. En el caso de que la autentificación no haya sido satisfactoria, el paquete de autentifica- ción no creará la sesión de validación. Como hemos dicho anteriormente, la LSA nos facilita los mecanismos para el proceso de validación. Estos procedimientos quedan divididos según el tipo de autentificación que se intente:  Autentificación interactiva.  Autentificación no interactiva. La autentificación interactiva se produce cuando a un usuario se le solicita que proporcione las credenciales para la autentificación. En este procedimiento para los 154

La aplicación del reglamento de seguridad en los sistemas Microsoft sistemas anteriores a Windows Vista, intervenían dos componentes esenciales: Winlogon y GINA (Graphical Identification aNd Authentication). Los sistemas actuales han cambiado GINA por un nuevo proveedor de servicios de credenciales de seguridad (CredSSP) disponible a través del SSPI (Security Support Provider Interface). En el nuevo modelo de autentificación, los módulos LogonUI y Winlogon hablan entre ellos directamente. Si en el sistema tenemos un Módulo de Proveedor de Credenciales (como un servicio de autentificación basado en SmartCard) externo, la información de autentificación es requerida por LogonUI para comunicarse con el Proveedor de autentificación externa. Después de que el proveedor de autentifica- ción devuelve las credenciales de validación al módulo de LogonUI, éstas son enviadas a Winlogon. En este sentido, el proveedor de credenciales es totalmente transparente para Winlogon. En Windows Vista, al contrario que en versiones anteriores, no es necesario cambiar la pantalla de autentificación y se admite que puedan implementarse múltiples proveedores de servicio de autentificación, pudiendo ser seleccionados por el usuario. Por defecto, Windows proporciona proveedores de autentificación para acceso mediante usuario/password y la autenticación mediante Smartcard. Adicionalmente, mediante el Proveedor de seguridad, el sistema permite reutilizar las credenciales mediante el módulo CredUI. Sistema de autentificación en Windows Vista. La autentificación no interactiva se produce cuando ya previamente se ha producido una sesión interactiva, con lo cual no se solicitan nuevamente credenciales, sino que se utilizan aquellas previamente proporcionadas. Este tipo de autentifi- cación es la típica cuando se produce un acceso a un recurso de red. Cuando una aplicación intenta acceder a un recurso de red, entonces en el proceso de autentificación no intervienen ni los procesos del nuevo proveedor CredSSP ni del módulo de Winlogon, sino que el proceso que interviene es la SSPI (Security Support Provider Interface) y el paquete de seguridad encargado de establecer la conexión segura a la red. La SSPI es una interfaz que se posiciona entre 155

La protección de datos personales: Soluciones en entornos Microsoft la capa de transporte y de aplicación que permite hacer las llamadas a los proveedores de seguridad. Un ejemplo lo tenemos con la SSPI que interviene en los procesos de envíos de datos entre Microsoft Remote Procedure Call (RPC), y el proveedor de seguridad Windows Distributed Security. El procedimiento de trabajo sería el siguiente: una aplicación de un cliente inicia la llamada a la SSPI que requiere la autentificación a través de la conexión de red. La petición del cliente es procesada por un paquete de seguridad. Éste autentifica al usuario mediante una llamada a la LSA y el paquete de autentificación específico proporcionando las credenciales de Usuario existente. El resultado de la autentificación se pasa a través de la LSA al paquete de seguridad y finalmente a la SSPI. Ésta finalmente notifica a la aplicación cliente el resultado de la petición. Una vez que hemos visto los dos tipos de procedimientos para la autentifica- ción, solicitando o no credenciales, y los mecanismos que la implementan, el otro factor importante es dónde se produce la confrontación de la autentificación y los mecanismos utilizados para asegurar el paso de los datos de autentificación. Los mecanismos en este caso dependerán de si accedemos mediante cuentas locales o, por el contrario, utilizamos los mecanismos de dominio. Cuando se produce una validación contra la base de datos de seguridad local, la cuenta que se valida debe estar en la SAM de la máquina en la que se intenta autentificar. La SAM local se encuentra protegida en el registro de la máquina y como paquete de autentificación es utilizado MSV1_0. La LSA llama al MSV1_0 para recoger los datos proporcionados a través de GINA para el proceso de Winlogon. MSV1_0 realiza la comprobación en la base de datos SAM. Si los datos proporcionados son satisfactorios, se genera un Principal de Seguridad válido y se devuelve el resultado de validación a la LSA. Cuando se produce el paso de la contraseña para la verificación, ésta no se realiza directamente, sino mediante una clave secreta generada mediante una función Hash. Se trata de una fórmula mate- mática mediante la cual, a través de una cadena de caracteres, se obtiene un resultado único. La modificación de un carácter implica la generación de una nueva cadena, con lo cual no puede calcularse la cadena de caracteres que lo genera. Cuando la SAM recibe una petición de autentificación de un usuario, genera una función Hash sobre la contraseña que tiene almacenada, comparando el resultado con el hash recibido de la autentificación. El resultado es devuelto a la LSA que devuelve el resultado del procedimiento de verificación de la contraseña. Cuando la autentificación se realiza en un dominio Windows 2008, la metodo- logía cambia con respecto a lo expuesto anteriormente. En este caso se utiliza como SSP Kerberos V.5, aunque soporta la autentificación NTLM para clientes anteriores a Windows 2000. Para utilizar Kerberos V5 como protocolo de autentificación, Windows 2008 presenta una librería que es la encargada de elegir la autentificación: Kerberos.dll. Después de que la LSA establece un contexto de seguridad para la autentificación interactiva del usuario, se carga otra instancia de Kerberos para procesar en el contexto de seguridad del usuario, la firma y el envío de los mensajes. Kerberos es utilizado como metodología para la autentificación mutua entre el cliente y el servidor. Para todo el procedimiento de autentificación en Kerberos 156

La aplicación del reglamento de seguridad en los sistemas Microsoft intervienen los siguientes elementos: claves simétricas, objetos encriptados y servicios Kerberos. En el caso de Kerberos, los mecanismos de autentificación están basados en tickets necesarios para tener acceso a los servicios de red. Estos Tickets mantienen las claves de sesión para establecer comunicaciones cifradas cliente-servidor que garantizan la seguridad en los procesos de autentificación. La ventaja es que los servidores no tienen que almacenar la clave de sesión, sino que es el cliente el responsable de guardar el ticket en su caché y lo presentará cuando desee acceder al servidor. Cuando el servidor recibe el ticket utiliza la clave secreta para desencriptar el ticket y extraer la clave de sesión necesaria. El servicio encargado de mantener los mecanismos de funcionalidad de Kerberos son los Centros de Distribución de Claves (KDC). Este servicio se ejecuta en cada controlador de dominio de un Directorio Activo. El mecanismo de autenti- ficación Kerberos tiene los siguientes mecanismos de funcionalidad: 1. El usuario realiza un proceso de autentificación en el KDC mediante una contraseña o una tarjeta inteligente, a través de una trama de solicitud de autentificación que contiene los datos de pre-autenticación (PADATA). Este sistema de PADATA generada a partir de un algoritmo de cifrado, contiene una clave derivada de la contraseña, además de un sello de tiempo que evita determinados ataques de predicción de la contraseña. 2. El KDC se encarga de emitir un Ticket especial para la concesión de Ticket (TGT). Este ticket que sólo puede ser leído por un KDC, presenta el objetivo de tener acceso a las credenciales de un usuario, las claves de sesión y otros servicios. Se utiliza para el servicio de autentificación y para la petición de tickets de servicios; para ello, contiene una copia de la clave de sesión para el servicio de comunicación del KDC con el cliente. 3. Mediante el TGT, el cliente tendrá acceso al Servicio de Concesión de Ticket (TGS). Éste concede un Ticket de Servicio que va a permitir enviar las credenciales de usuario al servidor o servicio correspondiente de forma segura. 4. Los tickets solicitados también van a facultar el poder acceder a los servicios locales de la máquina en la cual se está o ha validado un usuario. 5. El servicio de Seguridad Genérico (GSS) establecerá posteriormente, a través de la Interfaz de programación de aplicación GSS (GSS-API) y el Proveedor de Soporte de negociación (GSS_SPNEGO), los mecanismos para la negociación segura que establecen el envío de mensajes entre cliente y servidor utilizando las claves derivadas del intercambio de Tickets Previos. Cuando se está realizando una validación en el dominio, la LSA será la encargada de recoger este Ticket y validarlo, creando un Token de seguridad asociándolo con el SID del usuario. 157

La protección de datos personales: Soluciones en entornos Microsoft Una de las mejoras introducidas en Windows Vista y Windows Server 2008 respecto al sistema de Autentificación Kerberos, es la implementación mejorada de los sistemas de cifrado, mediante el uso de AES (Advanced Encription Standard).  Soporte base de implementación Kerberos. AES es utilizado para la encriptación de TGTs, Tickets de Servicios y Claves de sesión.  Soporte AES para GSS (Generic Security Services). Además del uso base, los mensajes GSS para la comunicación entre cliente Windows Vista y servidor son protegidos mediante AES. Puesto que los sistemas previos no implementaban tal mecanismo, sino RC4 o DES, el siguiente cuadro establece qué mecanismos de encriptación se definen en función del Cliente, Servidor y Centro de Distribución de Tickets Kerberos existente. Cliente Servidor KDC Encriptación Sistema Operativo Sistema Operativo Windows Server 2008 TGT puede encriptar previo a Windows previo a Windows con una política Vista Server 2008 basada en AES Sistema Operativo Windows Server 2008 Windows Server 2008 Ticket de Servicio previo a Windows cifrado con AES Vista Windows Vista Windows Server 2008 Windows Server 2008 Todos los tickets y GSS cifrados con AES Windows Vista Windows Server 2008 Sistema Operativo GSS cifrado con AES previo a Windows Server 2008 Windows Vista Sistema Operativo Windows Server 2008 AS-REQ/REP y TGS- previo a Windows REQ/REP cifrado con Server 2008 AES Sistema Operativo Windows Server 2008 Sistema Operativo Sin soporte AES previo a Windows previo a Windows Vista Server 2008 Windows Vista Sistema Operativo Sistema Operativo Sin soporte AES previo a Windows previo a Windows Server 2008 Server 2008 Sistema Operativo Sistema Operativo Sistema Operativo Sin soporte AES previo a Windows previo a Windows previo a Windows Vista Server 2008 Server 2008 158

La aplicación del reglamento de seguridad en los sistemas Microsoft Otra de las mejoras de implementación en Windows Server 2008 con respecto al sistema de autentificación Kerberos, corresponde al mecanismo implementado con los Controladores de Dominio de Sólo Lectura (RODC) de Windows Server 2008. Puesto que se considera que en este escenario el procedimiento puede entra- ñar riesgo por la exposición posible, los RODC tienen una única cuenta KRBTGT que no tiene todas las capacidades de las cuentas estándar de un Controlador de Dominio. Lo que en caso de compromiso de dicha cuenta, estaría limitada a ser utilizada en este servidor RODC exclusivamente. En el caso de que las metodologías anteriormente expuestas para establecer los mecanismos de autentificación en el dominio no fueran posibles, alternativamente existe la posibilidad de utilizar las credenciales cacheadas localmente para iniciar una sesión local en la máquina con cuentas de usuario del dominio. Este mecanismo es utilizado en clientes itinerantes para facultarles el acceso localmente con credenciales de dominio. Como opción a través de las directivas de seguridad puede limitarse el uso de este mecanismo impidiendo que se guarden las credenciales localmente o limitarlas a un número determinado. Para realizar estas operaciones dentro de las opciones de seguridad podremos modificar el inicio de sesión interactivo y el número de inicios de sesión previos en la caché (en caso de que los controladores de dominio no estén disponibles). El valor predeterminado es de 10 inicios de sesión. 11.2.8.2. Autentificación en Microsoft Office 2007 Poco a poco, los sistemas ofimáticos han ido adquiriendo un valor muy importante en las empresas y por correspondencia en la aplicación de mecanismos de seguridad para asegurar la protección documental. Microsoft Office 2007 presenta la tecnología IRM (Information Right Management), como una medida para controlar los usuarios que pueden o no acceder a los documentos así como la forma en la cual pueden utilizarla. Además, como ya se incluía desde Microsoft Office XP, el sistema presenta la posibilidad de firmar digitalmente la tecnología Microsoft Authenticode para permitirle firmar digitalmente un archivo mediante el uso de certificados. Este certificado utilizado para crear esta firma garantiza que la macro o el documento se han originado por el firmante y la firma establece que no se ha modificado. Al establecer el nivel de seguridad de las macros, se pueden ejecutar macros en función de que estén firmadas digitalmente por un programador de la lista de confianza. El sistema funciona generando una huella digital (hash) única que representa un bloque de datos. Este hash se cifra con la clave privada de quien lo firma, de tal forma que todo aquel que posea la clave pública del que establece la firma pueda descifrarlo. Esta huella se genera mediante un algoritmo de cifrado en base a los datos que se desean firmar. La ventaja que ofrece es que es imposible modificar los datos sin cambiar el valor de hash. Además, el sistema genera una suma de compro- bación de los datos (CRC) con objeto de comprobar si los datos han sido modificados, que al ser firmados digitalmente se refuerza el mecanismo de seguridad. 159

La protección de datos personales: Soluciones en entornos Microsoft Cuando se quiere establecer el control de la firma, el destinatario comprueba el certificado del remitente para comprobar el período de caducidad y la validez de las firmas. Se realiza la comprobación mediante la clave pública del remitente del CRC obtenido del certificado del cliente. Si la comprobación es válida, se puede aseverar que los datos no han sido modificados desde el origen. Este mecanismo de seguridad permite establecer seguridad sobre archivos, documentos, presentaciones, plantillas y otros archivos de datos. Si el archivo entero es firmado, la firma garantiza que el archivo no sea modificado desde su aplicación. Además, el sistema admite la firma de código. Este término se refiere al uso de firmas en código ejecutable (incluyendo controladores de Microsoft ActiveX y macros). La firma de código se utiliza cuando se firman controladores para verificar que el código no haya sido cambiado desde el momento original de su creación. Los mecanismos de funcionalidad son similares a los utilizados para las firmas digitales. En el caso de que se desee firmar las macros y los archivos, estos procedimientos pueden realizarse por separado. 11.2.8.3. Autentificación en Exchange 2007 El correo electrónico constituye un modelo de intercambio de información, entre la que habitualmente pueden figurar datos de carácter personal. El problema lo encontramos en el hecho no sólo de que pueda ser utilizado como mecanismo de intercambio, sino también como sistema de almacenamiento, con lo cual tiene que cumplir unas pautas de seguridad al igual que tenemos en el resto de elementos que conforman los sistemas informáticos involucrados por la LOPD. Existen mejoras importantes de seguridad en los procesos de comunicación entre los diferentes roles de servidor disponibles en Exchange Server 2007. En una organización Exchange Server 2007 se pueden implantar los siguientes roles de servidor:  Servidor concentrador de transporte.  Servidor de acceso de clientes.  Servidor de mensajería unificada.  Servidor de buzones.  Servidor de transporte perimetral. La comunicación entre todos estos roles de servidor se realiza de forma autenticada y cifrada por defecto, incluso en un sistema recién instalado. Esto quiere decir que el administrador o responsable de seguridad puede garantizar desde el primer momento que las comunicaciones entre servidores están completamente securizadas. Para garantizar esta seguridad, Microsoft Exchange Server 2007 se apoya en Kerberos como protocolo de autenticación para aquellos equipos que son miembros 160

La aplicación del reglamento de seguridad en los sistemas Microsoft del dominio de Directorio Activo. De hecho, ninguno de estos roles acepta conexiones que no vayan previamente autenticadas, con la excepción del servidor de transporte perimetral. El servidor de transporte perimetral se encarga del envío y recepción de mensajes desde y hacia Internet; por tanto, debe estar configurado para aceptar conexiones anónimas de sesiones SMTP. Para incrementar el nivel de seguridad, este servidor no forma parte del dominio ni tiene comunicación con el Directorio Activo. Al no formar parte del dominio, no puede utilizar el protocolo Kerberos como protocolo de autenticación. Entonces, ¿cómo es capaz de autenticarse cuando va a iniciar una conexión contra un servidor concentrador de transporte? Arquitectura de comunica- ción entre roles de servidor Exchange 2007. Este problema lo resuelve la utilización de certificados X.509v3 de autentica- ción de máquina. Cuando se instala Exchange Server 2007, tanto el rol de concentrador de transporte como el rol de transporte perimetral, generan un certificado autofirmado que se utiliza en las comunicaciones del protocolo SMTP. Dicho certificado incluye el nombre del equipo y la clave pública que se enviará al servidor que lo solicite. Posteriormente, el administrador, mediante el proceso de sus- cripción perimetral, hace que el certificado del concentrador de transporte y el transporte perimetral se intercambien, estableciendo lo que se denomina confianza 161

La protección de datos personales: Soluciones en entornos Microsoft mutua por certificados. Esto se realiza durante el proceso EdgeSync o sincronización de perímetro. El procedimiento de suscripción se realiza mediante cmdlet de PowerShell new- edgesuscription, tanto en el servidor de transporte perimetral, para generar el fichero .XML de suscripción, como en el servidor concentrador de transporte para importar dicho fichero de suscripción. Procedimiento de suscripción del servidor perimetral. De esa forma, el servidor concentrador de transporte comienza a confiar en el equipo cuyo certificado ha sido incluido en la lista de confianza, y viceversa. Cada vez que el servidor de transporte perimetral necesita iniciar una nueva conexión con el servidor concentrador de transporte, utiliza su certificado para autenticarse y enviar su identidad de máquina. Además, aprovechando la capacidad que aportan los certificados X.509 para realizar un intercambio de claves simétricas, se crea un canal seguro basado en TLS en todas las comunicaciones SMTP entre servidores de transporte en general. Replicación de datos hacia ADAM. 11.2.8.4. Autenticación de clientes en Exchange Server 2007 Otros mecanismos de autenticación se dan cuando un cliente accede a su buzón o envía un mensaje de correo electrónico. En este caso, hay que diferenciar si el cliente se conecta a través de una aplicación web como el caso de OWA, un cliente POP3/SMTP o con el cliente nativo Outlook 2007.  Autenticación de clientes OWA, ActiveSync y Outlook Anywhere. Todos estos tipos de cliente tienen algo en común y es que todos utilizan aplicaciones web para acceder al buzón del usuario. Estas aplicaciones se 162

La aplicación del reglamento de seguridad en los sistemas Microsoft instalan en el rol de servidor de Acceso de Cliente o CAS. El CAS actúa como un proxy para este tipo de conexiones y, por defecto, utiliza el protocolo https. Al igual que con el rol de servidor anterior, el proceso de instalación del servidor de acceso de cliente genera un certificado autofirmado para comprobar la identidad del servidor y cifrar las comunicaciones con SSL. Si bien este certificado es técnicamente totalmente válido, funcionalmente no es viable para entornos en producción, ya que al ser autofirmado, los clientes no confían en dicho certificado y, por tanto, no ofrece las garantías de seguridad adecuadas. Para resolver este problema es necesario utilizar en todas las conexiones de clientes OWA, ActiveSync y Outlook Anywhere, certificados que hayan sido previamente emitidos por entidades de certificación (CA) de confianza para los usuarios. De esta forma, al iniciar una nueva conexión, el servidor nos envía su certificado y el usuario puede verificar la validez e identidad del equipo al cual se está conectando. Para este propósito, se pueden emplear tanto entidades públicas comerciales, como entidades privadas de la propia organización. Además, si la entidad de certificación privada de la organización es de empresa, es decir, integrada en Directorio Activo, podremos disponer de ventajas adicionales de administración y reducción de TCO ya que todos los equipos y usuarios del dominio van a confiar automáticamente en dicha entidad y las solicitudes de nuevos certificados se van a tramitar de forma transparente y utilizando la seguridad integrada de Kerberos y grupos de seguridad del Directorio Activo. Los usuarios también deben autenticarse contra el servidor para poder acceder a los servicios publicados. Esta labor la realiza la aplicación web o el propio servidor Internet Information Services. Los usuarios de OWA utilizan por defecto la autenticación basada en formularios, introduciendo sus credenciales en un formulario de inicio de sesión en la aplicación. En este escenario, es la propia aplicación la que realiza el proceso de autenticación contra el Directorio Activo. El formulario de inicio de sesión utiliza una cookie donde se almacenan las credenciales cifradas del usuario en el navegador del cliente. El seguimiento de esta cookie permite que Exchange monitorice la actividad de OWA en equipos públicos y privados. Si la sesión estuviera inactiva durante más tiempo del permitido, se solicitarían nuevamente las credenciales. Para los equipos públicos, la sesión se establece en 15 minutos, mientras que para los equipos privados es de 24 horas. Para mejorar la seguridad, cuando el usuario cierra el navegador o pulsa cerrar sesión en OWA, la cookie se elimina automáticamente. Las creden- 163

La protección de datos personales: Soluciones en entornos Microsoft ciales se envían al servidor únicamente durante el primer inicio de sesión; posteriormente se utiliza la cookie para continuar con la sesión iniciada. Aunque los tiempos máximos de inactividad reducen el riesgo de acceso no autorizado en escenarios como por ejemplo equipos compartidos, no eliminan dichos riesgos por completo; por tanto, es recomendable que los usuarios tomen precauciones adicionales como asegurarse de cerrar la sesión una vez finalizada su actividad con OWA. En el caso de disponer de un servidor avanzado de seguridad, como Microsoft ISA Server 2006, éste se puede configurar para que sea el propio ISA Server el que realice la autenticación del usuario, antes incluso de iniciar una conexión al servidor CAS. De este modo reducimos el riesgo de explotación de vulnerabilidades utilizando conexiones directas y no controladas al servidor CAS. Este modo de publicación de servicios se denomina Protocolo de Puente SSL en terminología de ISA Server y se puede utilizar para cualquiera de los servicios web disponibles en Microsoft Exchange Server 2007. Los clientes que utilizan PDAs con ActiveSync u Outlook Anywhere envían sus credenciales al servidor IIS, el cual se encarga de autenticarlas contra el Directorio Activo. En ambos casos, es habitual utilizar autenticación básica, por motivos de compatibilidad con cualquier escenario de movili- dad y red de acceso. Por ello, durante el proceso de instalación del servidor CAS, se configura automáticamente la opción de requerir canal seguro SSL para todas las conexiones de cliente en el sitio web predeterminado de Internet Information Services. Una forma de incrementar la seguridad para los usuarios móviles consiste en solicitar certificados de cliente al establecer nuevas conexiones. Los certificados de cliente actúan de forma similar a los certificados de servidor, salvo que en esta ocasión sirven para identificar al usuario. Por ejemplo, los usuarios de ActiveSync podrían enviar su certificado de cliente almacenado en el dispositivo móvil en el momento en que el servidor lo solicita, y mediante autenticación EAP – TLS se procede a iniciar sesión en el servicio ActiveSync.  Autenticación de clientes Outlook 2007. Los clientes que utilicen Outlook 2007 para conectarse a su buzón y estén en la intranet utilizan por defecto conexiones MAPI/RPC y autenticación basada en Kerberos. Además, si se ha iniciado sesión en el dominio en el equipo cliente, se utiliza el TGT obtenido desde el centro de distribución Kerberos para realizar un proceso de inicio de sesión único (Single Sign On); por tanto, no se requiere que el usuario introduzca de nuevo sus credenciales. 164

La aplicación del reglamento de seguridad en los sistemas Microsoft Los procesos de inicio de sesión únicos reducen el envío de credenciales en la red y, en consecuencia, el riesgo de captura de dichas credenciales. Además, mejoran la experiencia del usuario al no requerir recordar múltiples credenciales de autenticación para diferentes servicios. Si en algún escenario no estuviera disponible el servicio Kerberos para la autenticación del cliente Outlook, entonces se utilizaría como alternativa el protocolo NTLM v2, aunque estas opciones son configurables en el perfil de conexión del cliente. 11.2.9. Artículo 93. Identificación y autenticación (punto 3) 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. Como veremos posteriormente, los sistemas salvaguardan la información relativa a la contraseña para evitar que pueda ser robada. Estos mecanismos de protección evitarán el robo de la misma, pero será necesario que los usuarios establezcan esa contraseña de forma que sólo ellos sean conocedores de la misma para evitar que nadie pueda usurpar sus funcionalidades si la conocen. Con tal motivo, cuando se crea una nueva cuenta de usuario, el administrador podrá asignarle una contraseña, pero le podrá obligar a cambiarla en el primer inicio de sesión y de esta forma establecer una que solo él conocerá. Este procedimiento podrá también establecerse si el usuario olvida la contraseña y solicita que el administrador se la cambie, quedando siempre como objetivo principal que sea el usuario el único conocedor de la misma. También mediante los mecanismos predeterminados del sistema, la información de las contraseñas es cifrada mediante los mecanismos de Syskey que se analizarán con posterioridad. Este mecanismo saca fuera del sistema de ficheros la clave utilizada para realizar el cifrado de las contra- señas haciendo más inaccesible esta información. Nivel de autenticación de red. 165

La protección de datos personales: Soluciones en entornos Microsoft Cuando la información viaja por la red, ésta también debe encontrarse protegida. Cuando estamos en el marco de un dominio y utilizamos los mecanismos de Kerberos, ya vimos en el apartado anterior los mecanismos de defensa para salvaguardar dicha información, a la vez que se garantiza la integridad de los datos. Pero en función del tipo de cliente, si no tenemos un directorio activo, o se ha efectuado una autentificación local o entre dominios donde no se ha efectuado una relación de confianza, entonces las autentificaciones en la red vienen implementadas por el NTLMSSP (NTLM Security Support Provider). Este proveedor de seguridad proporciona mecanismos para el cifrado mediante desafío-respuesta y la firma digital de mensajes haciendo uso de una firma simétrica llamada MAC (Message Authentication Code). Con objeto de mantener la compatibilidad con sistemas más antiguos pero sin despreciar los avances en seguridad, el paquete NTLMSSP admite la autentificación con tres tipos de protocolos:  LM (Lan Manager).  NTLM.  NTLMv2. Cada uno estos protocolos presenta diferentes mecanismos de protección en los procesos de autentificación, siendo NTLMv2 el más robusto de los 3. En el sistema de LM no se distinguen mayúsculas de minúsculas y se puede generar una contraseña de un máximo de 14 caracteres. NTLM supone una evolución de LM donde se genera un hash a partir de una contraseña de un máximo de 128 caracteres, diferenciándose entre mayúsculas y minúsculas. NTLMv2 supone una mejora en la protección del tráfico de red frente a NTLM. La elección y limitación de los mecanismos de autentificación para el paquete NTLMSSP en Windows Server 2008 y Windows Vista pueden configurarse mediante las directivas locales. Las posibilidades que nos ofrece el sistema son las siguientes:  Nivel 0. Enviar respuestas de LM y NTLM: los clientes utilizan autentica- ción LM y NTLM, y nunca usan seguridad de sesión NTLMv2; los servidores aceptan autenticación LM, NTLM y NTLMv2.  Nivel 1. Enviar LM y NTLM. Usar la seguridad de sesión NTLMv2 si se negocia: los clientes utilizan autenticación LM y NTLM, y seguridad de sesión NTLMv2 si lo admite el servidor; los servidores aceptan autentica- ción LM, NTLM y NTLMv2.  Nivel 2. Enviar sólo respuesta NTLM: los clientes utilizan autenticación NTLM únicamente y seguridad de sesión NTLMv2 si lo admite el servidor; acepta autenticación LM, NTLM y NTLMv2.  Nivel 3. Enviar sólo respuesta NTLMv2: los clientes utilizan autenticación NTLMv2 únicamente y seguridad de sesión NTLMv2 si lo admite el servidor; los servidores aceptan autenticación LM, NTLM y NTLMv2. 166

La aplicación del reglamento de seguridad en los sistemas Microsoft  Nivel 4. Enviar sólo respuestas NTLMv2 y rechazar LM: los clientes utilizan autenticación NTLMv2 únicamente y seguridad de sesión NTLMv2 si lo admite el servidor; rechazan LM (sólo aceptan autentica- ción NTLM y NTLMv2).  Nivel 5. Enviar sólo respuestas NTLMv2 y rechazar LM y NTLM: los clientes utilizan autenticación NTLMv2 únicamente y seguridad de sesión NTLMv2 si lo admite el servidor; rechazan LM y NTLM (sólo aceptan autenticación NTLMv2). Evidentemente, de todas las posibles configuraciones, el Nivel 5 proporciona los métodos más seguros, pero el uso de estos mecanismos dependerá del tipo de sistema operativo que estemos utilizando. El sistema predeterminado para Windows Vista y Windows Server 2008 es utilizar NTLMv2. 11.2.10. Artículo 93. Identificación y autentificación (punto 4) 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. Cuando planteamos como objetivo securizar un entorno empresarial, uno de los primeros aspectos que se tratan de cubrir es plantear los mecanismos necesarios para asegurar que los usuarios utilicen contraseñas, forzando a que la implementación de la misma se base en una serie de características definidas para la empresa. Tanto en la figura de las cuentas locales, como las cuentas de dominio, podemos plantear a través del establecimiento de las políticas de seguridad el establecimiento de un patrón de seguridad para las cuentas de usuarios de la empresa. Como en otras funcionalidades, el uso del Directorio Activo reduce los costes de administración cuando queremos establecer estos valores a un número importante de cuentas. Estas características de las contraseñas son aplicables a nivel de las directivas de cuenta en la subcarpeta correspondiente a las directivas de contraseña: entre las características encontramos la longitud mínima en caracteres para la misma, la posibilidad de forzar a utilizar complejidad para la misma, y la necesidad de cambiarla periódicamente a la vez que se puede establecer un tiempo mínimo antes de que pueda ser cambiada, para evitar junto al histórico de contraseña que se pueda establecer un ciclo corto de cambio de contraseña para reiterarla. Aunque por seguridad el sistema mantiene el almacenamiento de hash para las contraseñas, en circunstancias y por motivos de compatibilidad con las aplicaciones que utilizan protocolos que requieren conocer la contraseña del usuario para la autenticación, será necesario activar la directiva que permite el almacenamiento de contraseñas con cifrado reversible; equivale básicamente a establecer el almacenamiento de versiones de texto simple de las contraseñas. Esta directiva no debe 167

La protección de datos personales: Soluciones en entornos Microsoft habilitarse nunca, a excepción de aquellas circunstancias para los que los requisitos de la aplicación sean más importantes que la necesidad de proteger la información de las contraseñas. Como habíamos definido con anterioridad, la información de las contraseñas quedará almacenada bien en el registro de la base de datos de la SAM cuando se establezca una autenticación local o en los controladores de dominio cuando realicemos la autenticación a través del Servicio de Directorio. Uno de los objetivos pri- mordiales será el establecer aquellas medidas que permitan proporcionar una línea de defensa adicional para evitar los ataques. Microsoft proporciona la utilidad Sys- key para proporcionar una seguridad mayor al almacenamiento de las contraseñas. Contraseñas de directiva de dominio. Syskey tiene como objetivo realizar una encriptación de los datos importantes de la máquina mediante una clave denominada “startup key”. Este sistema que ya viene habilitado por defecto puede ser invocado ejecutando el comando Syskey, y nos permitirá definir en qué modo es almacenada dicha clave. Para realizar el cambio en la operación del Syskey hay que pulsar el botón de actualización, con lo que nos aparece una plantilla donde podremos elegir las siguientes opciones:  Inicio con contraseña. Para este mecanismo, el sistema genera una clave aleatoria que se almacena de forma cifrada en el equipo local. Además, esta clave estará protegida por una contraseña que proporciona el administrador. Durante el arranque de la máquina se solicitará también esta clave para continuar con el proceso de arranque.  Contraseña generada por el sistema y almacenada la clave de inicio localmente. Se genera una clave aleatoria y se almacena una versión cifrada de la clave en el equipo local. En el inicio de la máquina no se requiere ninguna contraseña para iniciar los procesos de arranque.  Contraseña generada por el sistema y almacenada la clave de inicio en un disco. Mediante este mecanismo se genera nuevamente una clave de 168

La aplicación del reglamento de seguridad en los sistemas Microsoft forma aleatoria, pero es almacenada en un disco, de tal forma que no será solicitada durante el proceso de inicio de la máquina. Si se utiliza este mecanismo, se recomienda realizar una copia de respaldo del mismo para evitar posibles contingencias no previstas. En caso de que el sistema protegido por contraseña o disco nos fallara por falta de ese elemento necesario para inicializar el sistema, nos quedaría la posibilidad de restaurar el registro a un estado anterior de la utilización de la protección del sistema mediante uno de esos mecanismos. Una de las novedades significativas incorporadas en dominios nativos Windows Server 2008 es el establecimiento de granularidad para las contraseñas. Este sistema nos permite evitar una restricción existente hasta ahora, que impedía que usuarios de un mismo dominio fueran obligados a implementar tipos de contraseñas diferenciados en función de sus características, utilización de recursos o simplemente del valor de los datos manejados. A una empresa le podría interesar que el personal informático u otros usuarios con privilegios administrativos tuvieran, por ejemplo, una longitud de contraseña mayor que otros usuarios de la organización. Esta posibilidad no se encontraba disponible hasta Windows Server 2008, que a través del objeto de Configuración de Contraseñas en el Directorio Activo permite esta granularidad de las contraseñas. Inicialmente, el procedimiento para establecer esta característica seguía un proceso que implicaba la creación del objeto a nivel del Editor de Objetos ADSI, aunque actualmente ya se están desarrollando herramientas gráficas como “Specops Pass- word Policy Basic” que permiten una implementación más sencilla de la misma. Así, todos aquellos usuarios que de una u otra forma pudieran verse afectados, por una implementación de seguridad del Reglamento de Seguridad de la LOPD, podrían tener un tipo de contraseñas diferentes del resto de la empresa. 11.2.11. Artículo 94. Copias de respaldo y recuperación 1. Deberán establecerse procedimientos de actuación para la realización como mínimo semanal de copias de respaldo, salvo que en dicho período no se hubiera producido ninguna actualización de los datos. 2. Asimismo, se establecerán procedimientos para la recuperación de los datos que garanticen en todo momento su reconstrucción en el estado en que se encontraban al tiempo de producirse la pérdida o destrucción. Únicamente, en el caso de que la pérdida o destrucción afectase a ficheros o tratamientos parcialmente automatizados, y siempre que la existencia de documentación permita alcanzar el objetivo al que se refiere el párrafo anterior, se deberá proceder a grabar manualmente los datos quedando constancia motivada de este hecho en el documento de seguridad. 3. El responsable del fichero se encargará de verificar cada seis meses la correcta definición, funcionamiento y aplicación de los procedimientos de realización de copias de respaldo y de recuperación de los datos. 169

La protección de datos personales: Soluciones en entornos Microsoft 4. Las pruebas anteriores a la implantación o modificación de los sistemas de información que traten ficheros con datos de carácter personal no se realizarán con datos reales, salvo que se asegure el nivel de seguridad correspondiente al tratamiento realizado y se anote su realización en el documento de seguridad. Si está previsto realizar pruebas con datos reales, previamente deberá haberse realizado una copia de seguridad. Tan importante a veces es tener la información, como recuperarla en caso de desastres, y eso es uno de los elementos que más cuida el reglamento de seguridad. Los procedimientos de copia de seguridad y restauración quedan contemplados dentro del reglamento como una de las operaciones importantes a tener en cuenta. Windows Server 2008 y Windows Vista incorporan herramientas para la realización de copias de seguridad y la restauración en caso de contingencias no previstas. Para la realización tanto de las tareas de copia de seguridad como de la restauración de los datos, los usuarios deben tener los derechos correspondientes para su realiza- ción. Estos privilegios se conceden a través de las directivas asignables en los derechos de usuario. En principio, sólo los usuarios pertenecientes a los grupos de operadores de copia, de servidor y de administradores poseen esta capacidad. Desde el punto de vista más formal en el documento trataremos el sistema de copia de seguridad implementado en Windows Server 2008, por considerar que el almacenamiento de datos y, por tanto, el establecimiento de la copia de seguridad se efectuarán normalmente en un sistema servidor. Copia de seguridad. Instalación de la herramienta en Windows Server 2008. El sistema de copia de seguridad ha sufrido una profunda reestructuración con respecto al sistema empleado en las anteriores versiones de Windows Server. El sistema de copia de seguridad de Windows Server 2008 proporciona mecanismos de copiado basados en bloques y volúmenes, que lo diferencian de las versiones anteriores que estaban basadas en la copia de ficheros. Esta nueva característica 170

La aplicación del reglamento de seguridad en los sistemas Microsoft permite una mejor integración con la funcionalidad de las Instantáneas de Volumen, que comentaremos posteriormente, y que además limita el impacto en los sistemas de almacenamiento. La desventaja, sin embargo, es que la aplicación no permite la copia de ficheros o carpetas individuales. Copia de seguridad. La herramienta Copia de seguridad permite el volcado de copias sobre unidades de disco, unidades de red y DVD, pero no admite el almacenamiento directo en sistemas de cinta. Para esto último necesitaremos alguna aplicación de terceros, que vuelque las copias de seguridad en cintas. La herramienta de copia de seguridad está compuesta además de la propia aplicación, de funcionalidades controlables a través de PowerShell. Ambas caracte- rísticas no vienen implementadas por defecto y requieren ser activadas en Windows Server 2008. La consola de administración de copias de seguridad no permite la gestión de copias realizadas por NTBackup, aunque Microsoft ha desarrollado una herramienta que se puede implementar en Windows Server 2008 para la gestión de las copias de seguridad realizadas con dicha herramienta. http://www.microsoft.com/downloads/details.aspx?displaylang= es&FamilyID=7da725e2-8b69-4c65-afa3-2a53107d54a7 En cuanto a las tareas de administración y gestión, además de las funcionalidades aportadas por la consola y PowerShell, se ha definido una implementación mediante comandos con la aplicación Wbadmin. Además de estas herramientas, la aplicación cuenta con el servicio WBengine.exe que corresponde a la función servidor de la herramienta, siendo las anteriores citadas los componentes clientes del servicio. La herramienta Copia de seguridad de Windows permite realizar copias de seguridad programadas o manuales. Independientemente de la opción deseada, el sistema nos permite configurar mediante un asistente el tipo de copia a realizar: 171

La protección de datos personales: Soluciones en entornos Microsoft  Volúmenes a copiar.  Para el volumen de sistema o aquellos que contengan componentes del sistema operativo, se puede implementar también la recuperación del sistema.  Destino de la copia: local o remota. El destino de la copia nunca puede ser un volumen que contenga datos del sistema operativo.  Para finalizar, en opciones avanzadas nos permite determinar el sistema de Instantánea de Volumen (VSS) que queremos utilizar.  Copia de seguridad completa de VSS.  Copia de seguridad de copia de VSS. Compatible con otras herramientas de copia de seguridad de servicios y aplicaciones. En todas las circunstancias, Windows Server utiliza el servicio de instantáneas de volumen. Cuando determinamos que queremos realizar una copia completa, lo primero que hace el sistema es una instantánea de todos los volúmenes. Posterior- mente, realiza la copia de los bloques del volumen, en el destino, creando una imagen VHD (Virtual Hard Disk) de cada volumen. Este sistema de VHD es el mismo que emplean los sistemas de virtualización de Virtual Server y Virtual PC; de hecho, podrían montarse directamente en una máquina virtual. Copia de seguridad de fichero VHD. Una vez realizada la copia completa, el sistema se basa en la generación de instantáneas incrementales, que permite realizar un seguimiento de los bloques dentro del volumen que han sido modificados. Puesto que el uso de copias incrementales es más rápido pero puede impactar en el rendimiento general, nos permite establecer mecanismos de optimización de rendimiento, mediante 3 posi- 172

La aplicación del reglamento de seguridad en los sistemas Microsoft bles opciones relacionadas con VSS que pueden ser implementadas en función de la carga del volumen a copiar.  Copia completa. Sistema de copia más lento pero no impacta en el rendimiento general.  Copia incremental. El sistema de copia es más rápido pero tiene mayor impacto en el rendimiento.  Copia personalizada. Permite determinar qué tipo de copia queremos para cada volumen de disco. Copia de seguridad: optimización del rendimiento. El proceso de restauración mediante esta nueva herramienta es más rápido que los implementados anteriormente, pues al utilizar las instantáneas no es necesario que se carguen todas las copias incrementales como sucedía con la herramienta de copia de seguridad anterior. La restauración de una copia permite desde la restauración completa a la restauración de un único fichero. Para el proceso de restauración, se utiliza un asistente que nos guía en el proceso de recuperación de datos. Dicho asistente consta de una serie de pasos:  En primer lugar, seleccionaremos la fecha de la copia de seguridad que queremos utilizar para la restauración.  Determinaremos posteriormente qué deseamos restaurar: ficheros o carpetas, aplicaciones registradas con la herramienta de copia de seguridad o volúme- nes completos.  En función de la opción anterior, se establece qué elementos deseamos recuperar. 173

La protección de datos personales: Soluciones en entornos Microsoft  Para finalizar, determinaremos el destino de la restauración, si sobrescribimos los posibles ficheros existentes, los mantenemos y si deseamos además mantener la configuración de seguridad. Copia de seguridad: restauración. A través de la consola de copia de seguridad de Windows, se mantienen los mensajes de estado y un histórico de procedimientos de copia de seguridad y restauraciones, donde quedan detallados todos los elementos copiados o recupera- dos. Adicionalmente, el servicio de copia genera una serie de registros detallados en la siguiente ruta: %systemroot%logsWindowsServerBackup Aunque queda establecido para las copias de seguridad un sistema de ACL, que impide el acceso a usuarios no administradores, se puede complementar mediante un mecanismo de cifrado de carpeta a través de EFS, que impediría que un acceso de tipo Offline fuera utilizado para la recuperación de los datos almacenados. Además de esta herramienta de copia de seguridad, Microsoft a través de la gama de productos System Center, proporciona otra herramienta para la realización de copias de seguridad de ficheros y carpetas y también de diferentes servicios Microsoft como SQL Server, Exchange Server o SharePoint. Esta funcionalidad la aporta Data Protection Manager. http://www.microsoft.com/spain/dpm/default.mspx 11.3.Tecnología aplicable a medidas de nivel medio Para el establecimiento de las medidas de seguridad a datos en un nivel medio, además de aquellas de carácter básico que hemos valorado con anterioridad, deberán disponerse otros controles adicionales. A diferencia de lo que ocurría en el 174

La aplicación del reglamento de seguridad en los sistemas Microsoft anterior reglamento en vigor, las medidas incluidas en este nivel son menores, principalmente porque la mayoría de requerimientos han sido ya incluidos en las medidas de seguridad de tipo básico. La mayoría de las condiciones que se demandan actualmente a datos de carácter personal que afecten al tipo medio, lo constituyen medidas orgánicas y el establecimiento de controles, mecanismos y registros de la información. Claros ejemplos de ello son los artículos 97 de Gestión de Soporte y Documentos y el 100 de Registro de Incidencias. Para el flujo de dicha información, es óptima la utiliza- ción de Microsoft Office SharePoint Server 2007, como sistema de registro y almacenamiento de la información. A continuación se comentarán aquellos mecanismos técnicos exigibles para datos de tipo medio. 11.3.1. Artículo 98. Identificación y autenticación El responsable del fichero o tratamiento establecerá un mecanismo que limite la posibilidad de intentar reiteradamente el acceso no autorizado al sistema de infor- mación. Con objeto de evitar aquellos ataques por reintentos que pudieran dar con la contraseña de un usuario, el sistema ofrece la posibilidad de establecer el bloqueo de cuentas para evitar esta amenaza. Este mecanismo se habilita mediante directivas, bien con ámbito local, bien mediante políticas de grupo en un dominio de Directorio Activo. Cuando se habilitan los bloqueos de cuenta, se decide el número de intentos a disponer por parte del “supuesto” usuario, antes de que dicha cuenta quede bloqueada dentro de un tiempo específico, también configurable. Directiva de bloqueo de cuenta. Una vez que la cuenta se encuentre bloqueada no se podrá acceder a ella aunque se proceda a introducir de forma correcta la contraseña. Los mecanismos de desbloqueo se establecerán por espacio temporal, o bien el desbloqueo deberá 175

La protección de datos personales: Soluciones en entornos Microsoft realizarse manualmente por un administrador. A pesar de que el coste administrativo es más elevado cuando el desbloqueo es manual, el administrador tendrá constancia de que se ha intentado un ataque por reiteración y podrá establecer otras medidas adicionales, enfocadas a detectar posibles usos fraudulentos de cuentas. Si el desbloqueo se produce automáticamente transcurrido un tiempo, es posible que el ataque quede disfrazado y ni el usuario propietario de la cuenta ni un administrador sean conscientes con absoluta certeza de dicho intento de acceso reiterado y no autorizado. La implementación de estas características puede realizarse mediante la aplicación de Políticas de grupo, aunque esto, como en otras circunstancias, lo haría extensible a otros usuarios de la organización. Al igual que pasaba con aquellos aspectos referentes a los mecanismos de autentificación en Windows Server 2008 para usuarios y contraseñas, ya citados en el artículo 93 de Identificación y Autenti- ficación, puede establecerse también un sistema de Granularidad que permita afectar de forma independiente a todos los usuarios de una organización. Esto permitirá asimismo adecuar las necesidades de implementación de defensa frente a ataques reiterados, en función de las diferentes características de los usuarios u organizativas que pudiera determinar la empresa. Cabe destacar que aunque el bloqueo de cuentas se establece como un mecanismo para el cumplimiento de este articulado, la agencia no nos limita al uso exclusivo de este mecanismo, sino que permite el uso de otros, siempre que impidan los intentos reiterados. En entornos web pueden implementarse procedimientos que sin llegar a necesitar el bloqueo de las cuentas (cuestión importante en caso de acceso externo, para evitar otro tipo de ataque que pudiera conllevar a una denegación del servicio), pueden imponerse criterios automatizados para el filtrado de direcciones IP o sesiones en caso de la existencia de un ataque por reiteración, como es el empleado por las técnicas de fuerza bruta, para la obtención de cuentas y contraseñas con las que acceder a la organización. Aunque no se cita en el presente articulado, debemos considerar la necesidad de considerar esta amenaza de forma global. Aunque un servicio que presta un mecanismo de acceso a datos de tipo medio o alto pudiera estar securizado frente a ataques por reiteración, las cuentas podrían encontrarse en situación de riesgo en caso de que otro servicio, aunque no estuviera relacionado con datos de carácter personal pero que sí fuera utilizado por las mismas cuentas, no se encontrase protegido frente a ataques de fuerza bruta. La seguridad de los datos de carácter personal, aunque de forma indirecta, pueden ser accesibles a personas ajenas a la organización. 11.4.Tecnología aplicable a medidas de nivel alto Dentro de las tecnologías para la adopción de medidas de seguridad, éstas son lógicamente las que exigen un mayor esfuerzo por parte del personal de TI y las que pueden llevar un mayor coste de administración y de implantación. Aunque 176

La aplicación del reglamento de seguridad en los sistemas Microsoft algunas medidas como las de la auditoría ya fueron comentadas con anterioridad como una posibilidad de control, es ahora cuando se apliquen las medidas de nivel alto cuando es exigible su aplicación. 11.4.1. Artículo 101. Gestión y distribución de soportes 1. La identificación de los soportes se deberá realizar utilizando sistemas de etiquetado comprensibles y con significado que permitan a los usuarios con acceso autorizado a los citados soportes y documentos identificar su contenido, y que dificulten la identificación para el resto de personas. 2. La distribución de los soportes que contengan datos de carácter personal se realizará cifrando dichos datos o bien utilizando otro mecanismo que garantice que dicha información no sea accesible o manipulada durante su transporte. Asimismo, se cifrarán los datos que contengan los dispositivos portátiles cuando éstos se encuentren fuera de las instalaciones que están bajo el control del responsable del fichero. 3. Deberá evitarse el tratamiento de datos de carácter personal en dispositivos portátiles que no permitan su cifrado. En caso de que sea estrictamente necesario, se hará constar motivadamente en el documento de seguridad y se adoptarán medidas que tengan en cuenta los riesgos de realizar tratamientos en entornos desprotegidos. Unificando los clásicos mecanismos de EFS para el cifrado de ficheros en soportes que admitan el sistema de ficheros NTFS y la tecnología IRM en documentos de Office y correo electrónico podremos asegurar que esta información sea inteligible una vez que ha salido de nuestros sistemas. A estos mecanismos hay que sumarles el sistema Bitlocker ya mencionado anteriormente, que garantizará el cifrado de disco en sistemas, tanto para Windows Vista como para Windows Server 2008, garantizando la máxima confidencialidad de la información. Adicionalmente, en los sistemas de correo podremos utilizar los mecanismos de S-Mime para el cifrado y la firma del correo electrónico. También Office presenta los mecanismos necesarios, para que a través de la ficha de seguridad podamos establecer el cifrado de los documentos mediante cualquier proveedor CriptoApi que se encuentre instalado en el sistema, pudiendo para los diferentes tipos de proveedores especificar la longitud de la clave y si quedan cifradas también las propiedades del documento. 11.4.2. Artículo 102. Copias de respaldo y recuperación Deberá conservarse una copia de respaldo de los datos y de los procedimientos de recuperación de los mismos en un lugar diferente de aquel en que se encuentren los equipos informáticos que los tratan, que deberá cumplir en todo caso las medidas de seguridad exigidas en este título, o utilizando elementos que garanticen la integridad y recuperación de la información, de forma que sea posible su recuperación. 177

La protección de datos personales: Soluciones en entornos Microsoft Como ya vimos anteriormente, los mecanismos de copia de seguridad permiten realizar copias de seguridad sobre diferentes medios, permitiendo la portabilidad de los mismos que a su vez podrán se protegidos mediante los mecanismos de implementación de EFS o Bitlocker. 11.4.3. Artículo 103. Registro de accesos 1. De cada intento de acceso se guardarán, como mínimo, la identificación del usuario, la fecha y hora en que se realizó, el fichero accedido, el tipo de acceso y si ha sido autorizado o denegado. 2. En el caso de que el acceso haya sido autorizado, será preciso guardar la informa- ción que permita identificar el registro accedido. 3. Los mecanismos que permiten el registro de accesos estarán bajo el control directo del responsable de seguridad competente sin que deban permitir la desactivación ni la manipulación de los mismos. 4. El período mínimo de conservación de los datos registrados será de dos años. 5. El responsable de seguridad se encargará de revisar al menos una vez al mes la información de control registrada y elaborará un informe de las revisiones realizadas y los problemas detectados. 6. No será necesario el registro de accesos definido en este artículo en caso de que concurran las siguientes circunstancias: a) Que el responsable del fichero o del tratamiento sea una persona física. b) Que el responsable del fichero o del tratamiento garantice que únicamente él tiene acceso y trata los datos personales. La concurrencia de las dos circunstancias a las que se refiere el apartado anterior deberá hacerse constar expresamente en el documento de seguridad. Para la aplicación de los mecanismos de auditoría, las empresas deben ser conscientes de que tal registro debe ser observado tanto en un nivel informático como en la documentación no informatizada. Tanto Windows Server 2008 como Windows Vista garantizan medidas de auditorías para elementos únicamente informáticos; por tanto, debería preverse la necesidad de plantear otro sistema adicional para los elementos no informatizados. Tanto Windows Server 2008 como Windows Vista poseen un potente sistema de registro de información asociable a diferentes auditorías que deben contemplarse para el cumplimiento de la norma. Aunque la norma no establece cuál debe ser el nivel de registro para todos los posibles sucesos que pueden repercutir en la infor- mación de tipo personal, sí lo hace para los niveles más restrictivos. Además de los sistemas de auditoría e información recogida de los diferentes tipos de eventos relativos al registro de Windows accesibles a través del Visor de sucesos, tanto Windows Vista como Windows Server 2008 ofrecen otro potente sistema de registro de aplicaciones y servicios que proporcionan información 178

La aplicación del reglamento de seguridad en los sistemas Microsoft adicional para la resolución de incidencias. Aspectos tan importantes como el estado del Kernell, servicios como UAC o Terminal Services, pueden ser controlados a través de estos registros. El establecimiento de estas auditorías lo llevamos a efecto nuevamente mediante las directivas de seguridad, pudiendo realizarse tanto a nivel local como a nivel de dominio. El resultado final de estas auditorías quedará registrado en logs accesibles mediante la herramienta Visor de sucesos que acompaña a ambos sistemas operativos. Es necesario indicar que cada máquina tendrá constancia de los sucesos que le corresponden. Por ejemplo, si estamos interesados en conocer posibles inicios de sesión erróneos de determinados usuarios del dominio, dicha infor- mación quedará registrada en los controladores y no en las máquinas locales, puesto que la autentificación en el dominio se realiza ante la base de datos del mismo situada en los mencionados controladores. Ante la necesidad de auditar alguna acción, se nos ofrecen dos posibilidades: auditorías correctas y auditorías erróneas.  Una auditoría correcta es aquella que emite resultados satisfactorios cuando se han cumplido todas las condiciones para que el hecho se pudiera dar. Por ejemplo, un usuario que inicia una sesión utiliza correctamente el usuario para el inicio de la sesión y su contraseña correspondiente, o cuando un usuario modifica un fichero porque tiene los permisos correspondientes para poder hacerlo.  Una auditoría errónea es aquella que emite resultados cuando no se dan las condiciones establecidas. Siguiendo los ejemplos anteriores, cuando la contraseña o el nombre de inicio de sesión no son los correctos y el sistema nos deniega el inicio de sesión, se habrá producido una auditoría errónea, o cuando el usuario intenta modificar un fichero y no tiene la posibilidad de hacerlo al no disponer de los permisos correspondientes, se producirá nuevamente una auditoría errónea. Windows Server 2008 y Windows Vista incorporan el nuevo sistema de eventos, Windows Eventing 6.0, que permite una mejora para la gestión de eventos de seguridad y establecer mecanismo de correlación para los mismos. Entre los elementos destacados, Windows Eventing presenta una nueva consola, que permite la generación de vistas personalizadas y un texto descriptivo mejorado. El sistema de Windows Eventing 6.0 basa su funcionalidad en un motor de XML, lo que permite una mayor escalabilidad y accesibilidad. Almacenar la infor- mación en formato XML permite que soluciones particulares puedan acceder a dicha información aprovechando las características y potencia del sistema en XML. Otra de las características que otorgan una potencia mayor al servicio consiste en la capacidad de establecer asociaciones administrativas frente a eventos específicos. Esto nos permite disponer de un sistema reactivo ante determinados tipos de incidencias. El sistema que permite estos desencadenadores es una integración del Servicio Recopilador de Eventos y el nuevo sistema del Programador de tareas. 179

La protección de datos personales: Soluciones en entornos Microsoft A través del nuevo asistente contextual para cualquier evento generado en el Visor de sucesos, se permite iniciar un programa, enviar un correo electrónico o generar un mensaje, cuando se da un tipo de evento específico. Cuando establecemos auditorías a través de directivas, se especifican una serie de categorías para determinar diferentes evaluadores en lo referente a la seguridad, de tal forma que debemos plantear si necesitamos o no habilitar las auditorías correctas y erróneas para cada una de las circunstancias que se pudiesen producir. Tanto Windows Server 2008 como Windows Vista presentan las siguientes catego- rías para establecer registros:  Inicio de sesión.  Inicio de sesión de cuenta.  Administración de cuentas.  Acceso a objetos.  Accesos del servicio de directorio.  Usos de privilegios.  Seguimiento de procesos.  Sucesos del sistema.  Cambio de directivas. Auditoría política. Un problema frecuente que planteaban las auditorías de los sistemas operativos anteriores a Windows Vista, es que las nueve categorías que pueden habilitarse respecto de los sistemas de control establecían condiciones genéricas a 180

La aplicación del reglamento de seguridad en los sistemas Microsoft elementos aglutinados, no permitiendo realizar auditorías de elementos específicos. Por ejemplo, cuando establecíamos una auditoría para los eventos de inicio de sesión, no podía establecerse una diferenciación entre el inicio o el cierre de sesión, estando obligados a auditar ambas subcategorías. Para los sistemas operativos actuales, se establece una nueva funcionalidad: las directivas de auditoría granular (GAP), de tal forma que pueden habilitarse o deshabilitarse diferentes subcategorías, para los elementos principales de auditoría. Este sistema permite sobre todo filtrar la información importante de la que no lo es para la empresa, limitando la cantidad de información recibida a la estrictamente necesaria. Las diferente subcategorías en las que han quedado definidas las categorías principales son:  Sistema.  Cambio de estado de seguridad.  Extensión del sistema de seguridad.  Integridad del sistema.  Controlador IPsec.  Otros eventos del sistema.  Inicio/cierre de sesión.  Inicio de sesión.  Cierre de sesión.  Bloqueo de cuenta.  Modo principal de IPsec.  Modo rápido de IPsec.  Modo extendido de IPsec.  Inicio de sesión especial.  Otros eventos de inicio y cierre de sesión.  Servidor de directivas de redes.  Acceso de objetos.  Sistema de archivos.  Registro.  Objeto de kernel.  SAM.  Servicios de certificación. 181

La protección de datos personales: Soluciones en entornos Microsoft  Aplicación generada.  Manipulación de identificadores.  Recurso compartido de archivos.  Filtrado de paquetes.  Filtrados de conexión.  Otros eventos de acceso a objetos.  Uso de privilegios.  Uso de privilegio confidencial.  Uso de privilegio no confidencial.  Otros eventos de uso de privilegio.  Seguimiento detallado.  Creación del proceso.  Finalización del proceso.  Actividad DPAPI.  Eventos de RPC.  Cambio de plan.  Cambio en la directiva de auditoría.  Cambio de la directiva de autenticación.  Cambio de la directiva de autorización.  Cambio de la directiva del nivel de reglas de MPSSVC.  Cambio de la directiva de Filtering Platform.  Otros eventos de cambio de directivas.  Administración de cuentas.  Administración de cuentas de usuario.  Administración de cuentas de equipo.  Administración de grupos de seguridad.  Administración de grupos de distribución.  Administración de grupos de aplicaciones.  Otros eventos de administración de cuentas.  Acceso Servicio de Directorio.  Acceso del servicio de directorio. 182

La aplicación del reglamento de seguridad en los sistemas Microsoft  Cambios de servicio de directorio.  Replicación de servicio de directorio.  Replicación de servicio de directorio detallada.  Inicio de sesión de la cuenta.  Validación de credenciales.  Operaciones de vales de servicio Kerberos.  Otros eventos de inicio de sesión de cuentas.  Servicio de autenticación Kerberos. El control de las categorías y las auditorías que se activarán o no se realiza a través de la aplicación auditpol.exe, ejecutada a través del símbolo del sistema con privilegios administrativos. Entre otras posibilidades, la herramienta permite realizar una copia de seguridad de la directiva de auditoría, así como una recupera- ción posterior en caso de una manipulación incorrecta de los parámetros asignables. En el caso de querer vaciar la configuración de directivas de la auditoría predeterminada se utilizará la siguiente sentencia: Auditpol /clear Para habilitar una auditoría o deshabilitarla se utilizará esta otra sentencia: Auditpol /set /subcategory:”subcategoría” /success:enable /failure:enable En el caso de querer establecer una acción que implemente los mecanismos de gestión de auditorías, basados en categorías y subcategorías, en dominios existentes de Windows 2000 y Windows 2003, Microsoft ha generado un procedimiento que puede consultarse a través de la siguiente dirección: http://support.microsoft.com/kb/921469/ Auditoría de fichero. 183

La protección de datos personales: Soluciones en entornos Microsoft A continuación pasaremos a detallar los diferentes tipos de identificadores y su correspondencia con cada una de las categorías. 11.4.3.1. Eventos de inicio de sesión El resultado de auditar este evento tiene como objetivo determinar cuándo una instancia de un inicio o cierre de sesión se ha establecido en un equipo determinado. Existe una diferencia importante entre este tipo de eventos con los que veremos posteriormente referidos al inicio de sesión de cuenta. Los eventos de sesión de cuenta establecen los sucesos de cuentas para el dominio, quedando reflejados en los controladores de dominio. Por tanto, si tenemos habilitadas ambas categorías, cuando un usuario establezca un inicio de sesión, quedará registrado como un evento de inicio de sesión en la máquina local, y como un inicio de sesión de cuenta en los controladores de dominio. Cuando se establece la auditoría tanto a nivel correcto como erróneo, se generan una serie de identificadores que determinan la acción bajo la que queda establecida la auditoría. Se detallan a continuación todos los sucesos agrupados por las subcategorías correspondientes. Auditoría de evento de inicio de sesión y cuenta. Categoría: Inicio/Cierre Subcategoría: Bloqueo de cuentas 4625 Una cuenta falló al iniciar sesión. Subcategoría: Modo extendido IPsec 4978 Durante negociación del Modo Extendido, IPsec recibió un paquete de negociación no válida. 4979 Se estableció una asociación de seguridad del Modo principal de IPsec y del Modo Extendido. 184

La aplicación del reglamento de seguridad en los sistemas Microsoft 4980 Se estableció una asociación de seguridad del Modo principal de IPsec y del Modo Extendido. 4981 Se estableció una asociación de seguridad del Modo principal de IPsec y del Modo Extendido. 4982 Se estableció una asociación de seguridad del Modo principal de IPsec y del Modo Extendido. 4983 Una negociación Modo Extendido de IPsec falló. Se ha eliminado la asociación de seguridad correspondiente del modo principal. 4984 Una negociación Modo Extendido de IPsec falló. Se ha eliminado la asociación de seguridad correspondiente del modo principal. Subcategoría: Modo principal de IPsec 4646 Modo iniciado IKE DoS-prevention. 4650 Se estableció una asociación de seguridad Modo principal de IPsec. El modo extendido no está habilitado. No se utilizó la autenticación de certificados. 4651 Se estableció una asociación de seguridad del Modo principal de IPsec. El modo extendido no está habilitado. Un certificado se utilizó para la autenticación. 4652 Una negociación del Modo principal de IPsec falló. 4653 Una negociación del Modo principal de IPsec falló. 4655 Una asociación de seguridad del Modo principal de IPsec finalizó. 4976 Durante la negociación del modo principal, IPsec recibió un paquete de negociación no válido. 5049 Se eliminó un Asociación de seguridad de IPsec. 5453 Una negociación IPsec con un equipo remoto fracasó porque no se inicia el servicio IKE y los Módulos de IPsec de AuthIP (IKEEXT). Subcategoría: Modo Rápido de IPsec 4654 Una negociación Modo rápido de IPsec falló. 4977 Durante la negociación de Modo rápido, IPsec recibió un paquete de negociación no válida. 5451 Se estableció una asociación de seguridad Modo rápido de IPsec. 5452 Una asociación de seguridad Modo rápido de IPsec finalizó. Subcategoría: Cierre de sesión 4634 Se cerró la sesión de una cuenta. 4647 Un usuario inició el cierre de sesión. 185

La protección de datos personales: Soluciones en entornos Microsoft Subcategoría: Inicio de sesión 4624 Una cuenta inició una sesión correctamente. 4625 Una cuenta falló al iniciar sesión. 4648 Se intentó un inicio de sesión utilizando credenciales explícitas. 4675 Se filtró el SID. Subcategoría: Servidor de red de directiva 6272 Servidor de Directiva de red concedió acceso a un usuario. 6273 Servidor de Directiva de red denegó acceso a un usuario. 6274 Servidor de Directiva de red descartó la solicitud para un usuario. 6275 Servidor de Directiva de red descartó la solicitud de administración de cuentas para un usuario. 6276 Servidor de Directiva de red puso un usuario en cuarentena. 6277 Servidor de Directiva de red concedió acceso a un usuario pero lo colocó en pruebas porque el host no cumplió con la directiva de estado definido. 6278 Servidor de Directiva de red concedió acceso total a un usuario porque el host cumplió la directiva de estado definido. 6279 Servidor de Directiva de red bloqueó la cuenta de usuario debido a intentos de error repetidos de autenticación. 6280 Servidor de Directiva de red desbloqueó la cuenta de usuario. Los eventos de la subcategoría Servidor de Directiva de Red están disponibles solamente para Windows Vista Service Pack 1 y Windows Server 2008. Subcategoría: Otros eventos Inicio/Cierre 4649 Se detectó un ataque de reiteración. 4778 Se volvió a conectar una sesión de Windows. 4779 Se desconectó una sesión de Windows. 4800 Se bloqueó la estación de trabajo. 4801 Se desbloqueó la estación de trabajo. 4802 Se llamó al protector de pantalla. 4803 Se canceló el protector de pantalla. 5378 La delegación de credenciales solicitadas no fue permitida por directiva. 5632 Se realizó una solicitud autenticada en una red inalámbrica. 5633 Se realizó una solicitud que autentica una red cableada. 186

La aplicación del reglamento de seguridad en los sistemas Microsoft Subcategoría: Inicio de sesión especial 4964 Los grupos especiales se han asignado a un inicio de sesión nuevo. Los identificadores anteriores nos van a permitir visualizar diferentes circunstancias, como pueden ser intentos de acceso no autorizados con cuentas de usuarios que pueden no encontrarse en la empresa o se encuentran en desuso, intentos de validación con la cuenta de administrador, o accesos a recursos de red no autorizados. También pueden determinarse otras posibles restricciones como intentos de conexión en equipos no autorizados o restricciones horarias. También cobra importancia en lo relacionado con los ataques por reiteración, contra los que es necesario implementar a partir del nivel medio todos los eventos relacionados con este tema a través de la Subcategoría: Servidor de red de directiva, además de la correspondiente a la Subcategoría: bloqueo de cuentas. Determinados eventos, como los relacionados con IPSEC, será solo necesario habilitarlos en caso de utilizarlo para el cifrado de las comunicaciones. En el caso de uso de conectividad inalámbrica también es importante la identificación de determinados eventos que podemos encontrar en la Subcategoría: Otros eventos Inicio/Cierre. 11.4.3.2. Eventos de inicio de sesión de cuenta Estos identificadores establecen las instancias de inicio o cierre de sesión de cuenta en otro equipo distinto del utilizado para validar la cuenta. Cuando un usuario establece una validación en un dominio, se genera un evento de inicio de sesión de cuenta en un controlador de dominio. En el caso de que se quiera establecer un control global de los inicios de sesión de cuenta, procederemos a la visualización de los identificadores de sesión de las auditorías de todos los controladores de dominio, ya que la autentificación de una cuenta de dominio se puede haber realizado en cualquiera de ellos. Adicionalmente, el sistema nos reportará todos aquellos sucesos relacionados con la autentificación tipo Kerberos, mostrando aquellos sucesos críticos relacionados con este servicio para la autentificación y gestión de credenciales en un dominio Windows Server 2008. Subcategoría: Validación de credenciales 4774 Una cuenta se asignó para inicio de sesión. 4775 Una cuenta no se puede asignar para inicio de sesión. 4776 El controlador intentó validar las credenciales de una cuenta. 4777 El controlador de dominio no puede validar las credenciales de una cuenta. Subcategoría: Servicio de autenticación Kerberos 4768 Se solicitó un ticket (TGT) de autenticación Kerberos. 187

La protección de datos personales: Soluciones en entornos Microsoft 4771 La preautenticación Kerberos falló. 4772 Una solicitud de ticket de autenticación Kerberos produjo un error. Subcategoría: Kerberos atiende operaciones de Tickets 4769 Se solicitó un Ticket de servicio Kerberos. 4770 Se renovó un Ticket de servicio Kerberos. Estos sucesos, al igual que ocurre con los de inicios de sesión, pueden indicar intentos de acceso no autorizados en el dominio y los controles en los servicios de terminal. También se pueden indicar desajustes horarios de más de cinco minutos (valor predeterminado) entre las estaciones clientes y los controladores de dominio. Es necesario controlar especialmente los eventos 4774 y 4771 que indicarán los sucesos correctos y erróneos de autentificación en el dominio. 11.4.3.3. Eventos de administración de cuenta Cuando se establece una auditoria es importante saber quién está realizando cambios en los planes de cuenta con objeto de determinar posibles eliminaciones de huellas ante posibles ataques, cambios en la pertenencia de grupos de seguridad o uso indebido de credenciales de tipo administrativo. Aunque específicamente el reglamento de seguridad no establece la obligatoriedad de realizar este control de cuentas, el uso de las buenas prácticas y la necesidad de controlar el acceso a cuentas críticas, hacen recomendables la activación de este mecanismo de auditoría. Los siguientes eventos identifican cambios en las cuentas de usuarios, grupos y equipos, así como posibles bloqueos. Subcategoría: Aplicación Administración de Grupo 4783 Se creó un grupo de aplicación básica. 4784 Se cambió un grupo de aplicación básica. 4785 Un miembro se agregó a un grupo de aplicación básica. 4786 Un miembro se quitó de un grupo de aplicación básica. 4787 Un no-miembro se agregó a un grupo de aplicación básica. 4788 Un no-miembro se quitó de un grupo de aplicación básica. 4789 Se eliminó un grupo de aplicación básica. 4790 Se creó un grupo de consulta LDAP. Subcategoría: Administrar cuenta de equipo 4742 Se modificó una cuenta de equipo. 4743 Se eliminó una cuenta de equipo. 188

La aplicación del reglamento de seguridad en los sistemas Microsoft Subcategoría: Administración de grupo de distribución 4744 Se creó un grupo local con seguridad deshabilitada. 4745 Se cambió un grupo local con seguridad deshabilitada. 4746 Un miembro se agregó a un grupo local con seguridad deshabilitada. 4747 Un miembro se quitó de un grupo local con seguridad deshabilitada. 4748 Se eliminó un grupo local con seguridad deshabilitada. 4749 Se creó un grupo global con seguridad deshabilitada. 4750 Se cambió un grupo global con seguridad deshabilitada. 4751 Un miembro se agregó a un grupo global con seguridad deshabilitada. 4752 Un miembro se quitó de un grupo global con seguridad deshabilitada. 4753 Se eliminó un grupo global con seguridad deshabilitada. 4759 Se creó un grupo universal con seguridad deshabilitada. 4760 Se cambió un grupo universal con seguridad deshabilitada. 4761 Un miembro se agregó a un grupo universal con seguridad deshabilitada. 4762 Un miembro se quitó de un grupo universal con seguridad deshabilitada. Subcategoría: Otros sucesos de administración de cuentas 4739 Se cambió Directiva de dominio. 4782 Se tuvo acceso al hash de contraseña de una cuenta. 4793 Se llamó a la API Comprobar de Directiva de contraseñas. Subcategoría: Administración de grupo de seguridad 4727 Se creó un grupo global con seguridad habilitada. 4728 Un miembro se agregó a un grupo global con seguridad habilitada. 4729 Un miembro se quitó de un grupo global con seguridad habilitada. 4730 Se eliminó un grupo global con seguridad habilitada. 4731 Se creó un grupo local con seguridad habilitada. 4732 Un miembro se agregó a un grupo local con seguridad habilitada. 4733 Un miembro se quitó de un grupo local con seguridad habilitada. 4734 Se eliminó un grupo local con seguridad habilitada. 4735 Se cambió un grupo local con seguridad habilitada. 4737 Se cambió un grupo global con seguridad habilitada. 189

La protección de datos personales: Soluciones en entornos Microsoft 4754 Se creó un grupo universal con seguridad habilitada. 4755 Se cambió un grupo universal con seguridad habilitada. 4756 Un miembro se agregó a un grupo universal con seguridad habilitada. 4757 Un miembro se quitó de un grupo universal con seguridad habilitada. 4758 Se eliminó un grupo universal con seguridad habilitada. 4764 Se cambió un tipo groupÆs. Subcategoría: Administración de cuentas de usuario 4720 Se creó una cuenta de usuario. 4722 Una cuenta de usuario se ha habilitado. 4723 Se intentó cambiar la contraseña de una cuenta. 4724 Se intentó restablecer la contraseña de una cuenta. 4725 Una cuenta de usuario se ha deshabilitado. 4726 Se eliminó una cuenta de usuario. 4738 Se cambió una cuenta de usuario. 4740 Se bloqueó una cuenta de usuario. 4765 Se agregó Historial SID a una cuenta. 4766 Al intentar agregar un Historial SID a una cuenta se produjo un error. 4767 Se desbloqueó una cuenta de usuario. 4780 La ACL se estableció en cuentas que son los miembros de grupo de administradores. 4781 Se cambió el nombre de una cuenta: 4794 Se intentó establecer al Modo de restauración de servicios de directorio. 5376 Se modificaron las credenciales de Administrador de credenciales. 5377 Las credenciales de Administrador de credenciales se restauraron a partir de una copia de seguridad. A través de estos identificadores, procederemos a controlar los cambios en las cuentas (contraseñas, pertenencias a grupos, eliminación de las mismas, etc.). Por otro lado, también sería aconsejable no olvidar los posibles bloqueos de cuenta que pudieran identificar intentos de prueba-fallo sobre las cuentas de dominio, como posibles intentos para hacerse con cuentas de usuario o elevar privilegios administrativos a una cuenta para realizar operaciones, enmascaradas bajo cuentas no privilegiadas. Los usos indebidos de cuenta pueden ser descubiertos bajo procedimientos como los que resultan de habilitar una cuenta deshabilitada, establecer una nueva contraseña para la misma, realizar posteriormente una validación con la misma y finalmente volver a deshabilitar la cuenta. 190

La aplicación del reglamento de seguridad en los sistemas Microsoft Son especialmente importantes en este sentido tanto la Subcategoría: Adminis- trar grupo de seguridad, como la Subcategoría: Administración de cuentas de usuario. La primera es crítica, puesto que muchas empresas basarán la administra- ción para el acceso a objetos relacionados con Datos de Carácter Personal, en un sistema de grupos y membresía. De esta manera podremos controlar si algún usuario es agregado o eliminado de un grupo que disponga de acceso a datos aunque originalmente no era así. En el caso de la administración de cuentas es todavía más obvia, ya que aquí radica el control de las cuentas con privilegios de accesos importantes para una organización. 11.4.3.4. Eventos de acceso a objetos El sistema habilita mediante la auditoría de acceso a objetos la posibilidad de supervisar cuándo se produce un acceso a un objeto del sistema siempre y cuando se tengan habilitadas las Listas de control de acceso al sistema (SACL). Antes de haber habilitado las SACL, se necesita que previamente se hayan habilitado las auditorías sobre los accesos a objetos. Este sistema de control queda encuadrado dentro de las clases del espacio de nombres System.Security.AccessControl que nos van a permitir, mediante programación, establecer las listas de control de acceso discrecionales (DACL), los accesos a recursos mediante permisos, y las SACL, que establecen las auditorías del sistema. Estos controles deben ser considerados como un tema crítico a tratar, ya que nos van a servir para poder controlar los procedimientos de trabajo realizados sobre ficheros, carpetas, impresoras, registro, el servicio de certificados o el directorio activo, pudiendo así poder determinar quién realiza una acción determinada, de tal forma que, cuando un usuario acceda a un objeto que tiene asociada una SACL se genere una auditoría correcta, y si el usuario no logra tener acceso al objeto se genere una auditoría errónea. Auditoría de manipulador de objeto; apertura y acceso. 191

La protección de datos personales: Soluciones en entornos Microsoft En este sentido es muy importante determinar qué tipos de acceso deben ser auditados, puesto que en muchas circunstancias unos llevan implícitos a otros, aunque cada uno de ellos generará sus propios eventos con lo que emitirá demasia- da información, que en la mayor parte de circunstancias será superflua. Observados desde el punto de vista de registro de la información se deberían auditar para el acceso a carpetas y ficheros los siguientes elementos a través de las SACL asociadas:  Recorrer carpeta / Ejecutar archivos.  Crear archivos / Escribir datos.  Eliminar subcarpetas y archivos.  Eliminar.  Cambiar permisos.  Tomar posesión. Los dos últimos elementos de la auditoría no constituyen una exigencia desde el punto de vista del reglamento de seguridad, pero proporcionan una ayuda administrativa importante enfocada a evitar cambios en los planes de seguridad planteados por la organización. El resultado de las diferentes auditorías quedará reflejado en el Visor de sucesos a través de los siguientes identificadores. Auditoría del evento de eliminación de fichero. Estos mecanismos de control van a permitirnos también determinar qué es lo que sucede con los objetos del Directorio Activo. Cada objeto del Directorio Activo lleva también asociada una SACL que puede ser controlada desde las propiedades avanzadas de seguridad de los objetos. Lo único que hay que tener presente es que determinados objetos pueden generar un volumen tal de datos normales de control, que podrían llegar a enmascarar sucesos realmente importantes. 192

La aplicación del reglamento de seguridad en los sistemas Microsoft Subcategoría: Aplicación generada 4665 Se intentó crear un contexto de aplicaciones cliente. 4666 Una aplicación intentó una operación. 4667 Se eliminó un contexto de aplicaciones cliente. 4668 Se inicializó una aplicación. Subcategoría: Servicios de certificación 4868 El administrador de certificados denegó una petición de certificado pendiente. 4869 El Servicio de Certificados recibió una solicitud de certificado reenvia- da. 4870 El Servicio de Certificados revocó un certificado. 4871 El Servicio de Certificados recibió una solicitud para publicar la lista de revocaciones de certificados (CRL). 4872 El Servicio de Certificados publicó la lista de revocaciones de certificados (CRL). 4873 Se cambió una extensión de solicitud de certificado. 4874 Uno o más atributos de solicitud de certificado cambió. 4875 El Servicio de Certificados recibió una solicitud para cerrarse. 4876 Se inició una copia de seguridad del Servicio de Certificados. 4877 Copia de seguridad completada del Servicio de Certificados. 4878 Se inició la restauración del Servicio de Certificados. 4879 Restauración completada del Servicio de Certificados. 4880 Se inició el Servicio de Certificados. 4881 Se detuvo el Servicio de Certificados. 4882 Se cambiaron los permisos de seguridad para el Servicio de Certifica- dos. 4883 El Servicio de Certificados recuperó una clave archivada. 4884 El Servicio de Certificados importó un certificado en su base de datos. 4885 Se cambió el filtro de auditoría para el Servicio de Certificados. 4886 El Servicio de Certificados recibió una solicitud de certificado. 4887 El Servicio de Certificados aprobó una solicitud de certificado y emitió un certificado. 4888 El Servicio de Certificados denegó una petición de certificado. 193

La protección de datos personales: Soluciones en entornos Microsoft 4889 El Servicio de Certificados estableció el estado de una solicitud de certificado a pendiente. 4890 Las configuraciones de administrador de certificados para el Servicio de Certificados cambiaron. 4891 Una entrada de configuración se cambió en el Servicio de Certificados. 4892 Una propiedad en el Servicio de Certificados cambió. 4893 El Servicio de Certificados archivó una clave. 4894 El Servicio de Certificados importó y archivó una clave. 4895 El Servicio de Certificados publicó el certificado de entidad emisora en el Servicio de Dominios de Directorio Activo. 4896 Una o más filas se han eliminado de la base de datos de certificados. 4897 Habilitada la separación de funciones. 4898 El Servicio de Certificados cargó una plantilla. Subcategoría: Compartido de archivos 5140 Se tuvo acceso a un objeto de recurso compartido de red. Subcategoría: Sistema de archivos 4664 Se intentó crear un vínculo fuerte. 4985 El estado de una transacción ha cambiado. 5051 Un archivo fue virtualizado. Subcategoría: Filtrado de conexión 5031 El servicio Servidor de seguridad de Windows bloqueó una aplicación para no aceptar conexiones entrantes en la red. 5154 El Firewall de Windows ha permitido conexiones entrantes a una aplicación o a un servicio. 5155 El Firewall de Windows ha bloqueado a una aplicación o a un servicio. 5156 El Firewall de Windows ha permitido una conexión. 5157 El Firewall de Windows ha bloqueado una conexión. 5158 El Firewall de Windows ha permitido un enlace a un puerto local. 5159 El Firewall de Windows ha bloqueado un enlace a un puerto local. Subcategoría: Filtrado de paquetes 5152 El Firewall de Windows bloqueó un paquete. 5153 Un filtro más restrictivo del Firewall de Windows ha bloqueado un paquete. 194

La aplicación del reglamento de seguridad en los sistemas Microsoft Subcategoría: Manipulación de identificadores 4656 Se solicitó un identificador de un objeto. 4658 Se cerró el identificador de un objeto. 4690 Se realizó un intento que duplica un identificador de un objeto. Subcategoría: Otros eventos de acceso a objetos 4671 Una aplicación intentó obtener acceso a un ordinal bloqueado a través del TBS. 4691 Se solicitó el acceso indirecto a un objeto. 4698 Se creó una tarea programada. 4699 Se eliminó una tarea programada. 4700 Una tarea programada se ha habilitado. 4701 Una tarea programada se ha deshabilitado. 4702 Se actualizó una tarea programada. 5888 Se modificó un objeto en el catálogo COM+. 5889 Se eliminó un objeto del catálogo COM+. 5890 Un objeto se agregó al catálogo COM+. Subcategoría: Registro 4657 Se modificó un valor de Registro. 5039 Una clave de Registro fue virtualizada. Subcategoría: Subcategoría de uso especial múltiple 4659 Se solicitó un identificador de un objeto con intención para eliminar. 4660 Se eliminó un objeto. 4661 Se solicitó un identificador de un objeto. 4663 Se intentó que se tenga el acceso a un objeto. El control de ficheros y carpetas en una organización que pueda manejar datos críticos consignados como de tipo alto reviste de una gran importancia, por lo que para los sucesos que se relacionen con los mismos debe prestarse una gran atención. En este sentido es importante conocer cómo Windows Vista y Windows Server 2008 nos indican a través del Visor de sucesos la información relativa a sucesos con los objetos implicados. Tienen para ello especial significación todos los eventos relacionados con la Subcategoría: Manipulación de identificadores, que indica el inicio de un proceso sobre un fichero o carpeta, así como su finalización. 195

La protección de datos personales: Soluciones en entornos Microsoft Entre ambos procesos se realizan una serie de eventos relacionados con la eliminación, escritura, etc. Aunque significativamente estos últimos eventos son los que revelan las acciones realizadas, nos encontramos con las circunstancias que no revelan el fichero o carpeta sujeta a la acción, sino la aplicación que ha llevado a efecto dicho procedimiento (generalmente la utilidad explorer.exe). Es por eso que será necesario correlacionar a través del mismo identificador el proceso que abre el evento y la acción realizada, así como conocer cuándo se cierra el evento y, por tanto, queda libre el identificador para poder ser utilizado posteriormente para otros procesos. El valor, por tanto, que es necesario controlar a través de estos eventos es el Id. de identificador que correlacionará un mismo proceso. En caso de utilizar una herramienta para la consolidación de logs, será necesario utilizar reglas de correla- ción para un seguimiento correcto de la información. 11.4.3.5. Eventos de uso de privilegios Con el fin de realizar operaciones, los usuarios tienen concedidos una serie de derechos y privilegios para poder interactuar con el sistema. Los siguientes eventos relacionan cuándo se ha utilizado o se ha intentado utilizar un privilegio Subcategoría: Uso de privilegios confidencial. 4672 Los privilegios especificados se agregaron a un token de acceso del usuario. Este suceso se genera cuando un usuario inicia una sesión. 4673 Se ha utilizado un privilegio sobre un objeto. 4674 Un usuario intentó realizar una operación de servicio del sistema con privilegios. 11.4.3.6. Eventos de seguimiento de procesos En ciertas circunstancias, y con objeto de tener control y de utilizarse en depuraciones de aplicaciones, es necesario habilitar la auditoría de seguimiento de procesos con objeto de determinar cuándo se inician o cierran los procesos que puede utilizar una aplicación. Hay que tener cuidado al habilitar esta auditoría, pues genera una gran cantidad de datos que pueden saturar la base de datos. Las auditorías para el seguimiento de procesos deberían habilitarse solamente para depuración de aplicaciones u obtención de información de control sobre procesos. Una vez que se haya establecido el control de los procesos, puede ser recomendable deshabilitarlas nuevamente. Subcategoría: Actividad DPAPI 4692 Se intentó una copia de seguridad de la clave maestra de protección de datos. 4693 Se intentó recuperar la clave maestra de protección de datos. 4694 Se intentó la protección de datos protegidos auditables. 196

La aplicación del reglamento de seguridad en los sistemas Microsoft 4695 Se intentó una protección de datos protegidos auditables. Subcategoría: Creación de proceso 4688 Se ha creado un proceso 4696 Un identificador primario se asignó al procesarlo. Subcategoría: Terminación de proceso 4689 Ha terminado un proceso Subcategoría: Eventos RPC 5712 Se intentó llamar a un procedimiento remoto. 11.4.3.7. Eventos de sucesos del sistema Esta auditoría controla cuándo se inicia o se apaga un equipo o todos aquellos sucesos relacionados con la seguridad del sistema o el propio registro de seguridad. Este último cobra una gran importancia, ya que nos proporciona información relativa a la limpieza del registro de seguridad y qué usuario la ha realizado. Frente a otros tipos de sucesos, se aconseja en este caso que las auditorías, tanto correctas como erróneas para estos eventos, se encuentren siempre habilitadas de cara a las buenas prácticas de la seguridad, aunque no son requeridas desde el punto de vista de la LOPD. Subcategoría: Controlador IPsec 4960 IPsec eliminó un paquete entrante que no superó una comprobación de integridad. 4961 IPsec eliminó un paquete entrante que no superó una comprobación de reproducción. 4962 IPsec eliminó un paquete entrante que no superó una comprobación de reproducción. 4963 IPsec eliminó un paquete de texto sin cifrar entrante que se debería haber asegurado. 4965 IPsec recibió un paquete desde un equipo remoto con un Índice de Parámetro de Seguridad (SPI) incorrecto. 5478 El servicio de IPsec se ha iniciado correctamente. 5479 Se ha cerrado el servicio de IPsec satisfactoriamente. 5480 El servicio de IPsec no puede obtener la lista completa de interfaz de red en el equipo. 5483 El servicio de IPsec no puede inicializar el servidor RPC. 5484 El servicio de IPsec ha experimentado un error crítico y se ha cerrado. 197

La protección de datos personales: Soluciones en entornos Microsoft 5485 El servicio de IPsec no puede procesar algunos filtros IPsec sobre un evento plug-and-play para la interfaz de red. Subcategoría: Otros sucesos de sistema 5024 El servicio Servidor de seguridad de Windows se ha iniciado correctamente. 5025 Se ha detenido el servicio Servidor de seguridad de Windows. 5027 El servicio Servidor de seguridad de Windows no puede recuperar la directiva de seguridad del almacenamiento local. El servicio continua- rá utilizando la directiva actual. 5028 El servicio Servidor de seguridad de Windows no puede analizar la directiva de seguridad nueva. El servicio continuará con la directiva actualmente utilizada. 5029 El servicio Servidor de seguridad de Windows no puede inicializar el controlador. El servicio continuará utilizando la directiva actual. 5030 No se puede iniciar el servicio Servidor de seguridad de Windows. 5032 Firewall de Windows no pudo notificar qué bloqueó una aplicación de conexiones entrantes en la red al usuario. 5033 El Controlador de Windows Firewall se ha iniciado correctamente. 5034 Se ha detenido el Controlador de Windows Firewall. 5035 El Controlador de Windows Firewall no se ha podido iniciar. 5037 El Controlador de Windows Firewall detectó errores de tiempo de ejecución críticos. Se interrumpe. 5058 Operación de archivo de clave. 5059 Operación de migración clave. Subcategoría: Cambio de estado de la seguridad 4608 Se está iniciando Windows. 4609 Se está cerrando Windows. 4616 La hora de sistema se cambió. 4621 El Administrador recuperó un sistema de fallo de auditoría. Se permi- tirá ahora que los usuarios que no son los administradores inicien sesión. No se puede registrar ninguna actividad auditable. Subcategoría: Extensión de sistema de seguridad 4610 Un paquete de autenticación ha sido cargado por la Autoridad de seguridad local. 198

La aplicación del reglamento de seguridad en los sistemas Microsoft 4611 Un proceso de inicio de sesión de confianza se ha registrado en la Autoridad de seguridad local. 4614 Un paquete de notificación ha sido cargado por el Administrador de cuentas de seguridad. 4622 Un paquete de seguridad ha sido cargado por la Autoridad de seguridad local. 4697 Un servicio se ha instalado en el sistema. Subcategoría: Integridad de sistema 4612 Los recursos internos asignados para la cola de mensajes de auditoría se han saturado resultando la pérdida de algunas auditorías. 4615 Uso no válido de puerto LPC. 4618 Se ha producido un patrón de eventos de seguridad supervisada. 4816 RPC detectó una infracción de integridad en un mensaje entrante. 5038 La integridad de código determinó que el hash de imagen de un archivo no es válido 5056 Se realizó una prueba criptográfica. 5057 En una operación de primitiva criptográfica se produjo un error. 5060 En una operación de comprobación se produjo un error. 5061 Operación criptográfica. 5062 Se realizó una prueba del modo de núcleo criptográfico. Son especialmente útiles en seguridad todos los eventos relativos al módulo de firewall, que permiten reportar intentos de ataque o accesos de aplicaciones no permitidos. A destacar también las operaciones reportadas por los diferentes eventos de la subcategoría de cambio de estado de la seguridad, que reflejan los inicios y cierres de Windows y cuándo el administrador ha permitido que se inicie sesión de los usuarios, aunque no puedan realizarse auditorías por hallarse llenos los ficheros de eventos, ya que no se permite sobreescribirlos. 11.4.3.8. Eventos de cambios de directivas Para establecer un control más exhaustivo sobre los derechos otorgados a los usuarios del sistema es importante tener controlados los cambios en las directivas de asignación de derechos de usuario, de auditoría o de confianza que se puedan realizar. Esto nos va a reportar información de cuándo se ha podido producir un incidente que puede estar enmascarado mediante algún cambio en las directivas, bien a nivel de dominio o en la máquina local. Los procedimientos de control de directivas son un núcleo principal de la seguridad de una organización. Muchos de los controles establecidos se refieren a 199

La protección de datos personales: Soluciones en entornos Microsoft directivas, y en especial a las directivas de auditoría. Un buen sistema de auditoría podría quedar muy mermado si alguien pudiera deshabilitarlo y habilitarlo, sin que se hubiese generado ninguna acción que reportara dicho proceso. Subcategoría: Cambio de directiva de auditoría 4715 Se cambió la directiva de auditoría (SACL) en un objeto. 4719 Se cambió directiva de auditoría de sistema. 4902 Se creó la tabla de usuario de directiva de auditoría. 4904 Se realizó un intento que registra un origen de evento de seguridad. 4905 Se realizó un intento que anula el registro de un origen de eventos de seguridad. 4906 El valor de CrashOnAuditFail ha cambiado. 4907 Se cambiaron las configuraciones de auditoría en objeto. 4908 Tabla modificada especial de Inicio de sesión de Grupos. 4912 Se cambió la Directiva de auditoría por usuario. Subcategoría: Cambio de directiva de autenticación 4706 Una confianza nueva se creó en un dominio. 4707 Se quitó una confianza a un dominio. 4713 Se cambió la directiva Kerberos. 4716 Se modificó la información de dominio de confianza. 4717 El acceso de seguridad a sistema se concedió a una cuenta. 4718 Se eliminó acceso de seguridad a sistema de una cuenta. 4864 Se detectó una colisión de espacio de nombres. 4865 Se agregó una entrada de información de bosque de confianza. 4866 Se quitó una entrada de información de bosque de confianza. 4867 Se modificó una entrada de información de bosque de confianza. Subcategoría: Cambio de directiva de autorización 4704 Se asignó un derecho de usuario. 4705 Se quitó un derecho a un usuario. 4714 Se cambió la directiva de recuperación de datos cifrados. Subcategoría: Filtrar cambio de directiva de plataforma 4709 Se iniciaron los Servicios de IPsec. 4710 Se deshabilitaron los Servicios de IPsec. 200

La aplicación del reglamento de seguridad en los sistemas Microsoft 4711 Puede contener cualquiera de los siguientes:  Motor PAStore almacenó una copia de almacenamiento de la directiva IPsec del Directorio Activo en la caché del equipo.  Motor PAStore aplicó un almacenamiento de la directiva IPsec del Directorio Activo en el equipo.  Motor PAStore almacenó en el Registro local la directiva de IPsec en el equipo.  Motor PAStore no puede copiar la directiva IPsec de Directorio Activo en la caché del equipo local.  Motor PAStore no almacenó en el Registro local la directiva de IPsec en el equipo.  Motor PAStore no aplicó un almacenamiento de la directiva IPsec del Directorio Activo en el equipo.  Motor PAStore no puede aplicar algunas reglas de la directiva IPsec activa en el equipo.  Motor PAStore no puede cargar el directorio de directivas IPsec en el equipo.  Motor PAStore cargó el directorio de directivas IPsec en el equipo.  Motor PAStore no puede cargar el almacenamiento local de directivas IPsec en el equipo.  Motor PAStore cargó el almacenamiento local de directivas IPsec en el equipo.  Motor PAStore realizó un sondeo de cambios de la directiva IPsec activa y no detectó ningún cambio. 4712 El servicio de IPsec encontró un error potencialmente grave. 5040 Se ha hecho un cambio en la configuración IPsec. Se agregó una Auten- ticación. 5041 Se ha hecho un cambio en la configuración IPsec. Se modificó una Autenticación. 5042 Se ha hecho un cambio en la configuración IPsec. Se eliminó una Autenticación. 5043 Se ha hecho un cambio en la configuración IPsec. Se agregó una Regla de Seguridad de Conexión. 5044 Se ha hecho un cambio en la configuración IPsec. Se modificó una Regla de Seguridad de Conexión. 5045 Se ha hecho un cambio en la configuración IPsec. Se eliminó una Regla de Seguridad de Conexión. 201

La protección de datos personales: Soluciones en entornos Microsoft 5046 Se ha hecho un cambio en la configuración IPsec. Se agregó una entrada Criptográfica. 5047 Se ha hecho un cambio en la configuración IPsec. Se modificó una entrada Criptográfica. 5048 Se ha hecho un cambio en la configuración IPsec. Se eliminó una entrada Criptográfica. 5440 La llamada siguiente estuvo presente cuando se inició el Motor de Firewall de Windows. 5441 El filtro siguiente estuvo presente cuando se inició el Motor de Firewall de Windows. 5442 El proveedor siguiente estuvo presente cuando se inició el Motor de Firewall de Windows. 5443 El contexto siguiente de proveedor estuvo presente cuando se inició el Motor de Firewall de Windows. 5444 La sub-capa siguiente estuvo presente cuando se inició el Motor de Firewall de Windows. 5446 Se ha cambiado una llamada al Proveedor de filtrado de Windows. 5448 Se ha cambiado el Proveedor de filtrados de Windows. 5449 Se ha cambiado un contexto del Proveedor de filtrado de Windows. 5450 Se ha cambiado una sub-capa del Proveedor de Filtrado de Windows. 5456 El motor PAStore aplicó un almacenamiento de la directiva IPsec del Directorio Activo en el equipo. 5457 El motor PAStore no aplicó un almacenamiento de la directiva IPsec del Directorio Activo en el equipo. 5458 El motor PAStore almacenó localmente una copia de almacenamiento de la directiva IPsec del Directorio Activo en la caché del equipo. 5459 El motor PAStore no pudo almacenar una copia de almacenamiento de la directiva IPsec del Directorio Activo en la caché del equipo. 5460 El motor PAStore almacenó en el Registro local la directiva IPsec del equipo. 5461 El motor PAStore no almacenó en el Registro local la directiva IPsec del equipo. 5462 El motor PAStore no pudo aplicar algunas reglas de la directiva IPsec activa en el equipo. 5463 El motor PAStore realizó un sondeo de cambios de la directiva IPsec activa y no detectó ningún cambio. 202

La aplicación del reglamento de seguridad en los sistemas Microsoft 5464 El motor PAStore realizó un sondeo de cambios de la directiva IPsec activa, detectó cambios y los aplicó al Servicio de IPsec. 5465 El motor PAStore recibió un control para volver a cargar la directiva IPsec y procesó el control correctamente. 5466 El motor PAStore realizó un sondeo de cambios de la directiva y determinó que no se puede alcanzar el Directorio Activo y que en su lugar utilizará la copia almacenada en la caché de la directiva IPsec del Directorio Activo. 5467 El motor PAStore realizó un sondeo de cambios de la directiva y determinó que no se puede alcanzar el Directorio Activo y no se puede utilizar la copia almacenada en la caché de la directiva IPsec del Directorio Activo. 5468 El motor PAStore realizó un sondeo de cambios de la directiva IPsec, determinó que se puede alcanzar el Directorio Activo, que encontró cambios de la directiva y que aplicó aquellos cambios. Ya no se utiliza la copia almacenada en caché de la directiva IPsec del Directorio Activo. 5471 El motor PAStore cargó el almacenamiento local de directivas IPsec en el equipo. 5472 El motor PAStore no puede cargar el almacenamiento local de directivas IPsec en el equipo. 5473 El motor PAStore cargó el almacenamiento de directorio de directivas IPsec en el equipo. 5474 El motor PAStore no pudo cargar el almacenamiento de directorio de directivas IPsec en el equipo. 5477 Motor PAStore no pudo agregar un filtro de modo rápido. Subcategoría: Cambio de directiva a nivel de regla MPSSVC 4944 La directiva siguiente estuvo activa cuando se inició el Firewall de Windows. 4945 Una regla se mostró cuando se inició el Firewall de Windows. 4946 Un cambio se ha realizado en la lista de excepciones del Firewall de Windows. Se agregó una regla. 4947 Un cambio se ha realizado en la lista de excepciones del Firewall de Windows. Se modificó una regla. 4948 Un cambio se ha realizado en la lista de excepciones del Firewall de Windows. Se eliminó una regla. 4949 Las configuraciones del Firewall de Windows se han restaurado a los valores predeterminados. 203

La protección de datos personales: Soluciones en entornos Microsoft 4950 Se ha cambiado una configuración del Firewall de Windows. 4951 Una regla se ha omitido porque su número de versión principal no fue reconocido por el Firewall de Windows. 4952 Las partes de una regla se han omitido porque su número de versión secundaria no fue reconocido por el Firewall de Windows. Se exigirán las otras partes de la regla. 4953 Una regla ha sido omitida por el Firewall de Windows porque no podía analizar la regla. 4954 Las configuraciones de Directiva de grupo de Firewall de Windows han cambiado. Se han aplicado las nuevas configuraciones. 4956 El Firewall de Windows ha cambiado el perfil activo. 4957 El Firewall de Windows no aplicó la regla siguiente: 4958 El Firewall de Windows no aplicó la regla siguiente porque la regla hizo referencia a elementos no configurados en este equipo. Subcategoría: Otros eventos de cambio de directiva 4909 Se cambiaron las configuraciones de directiva local para el TBS. 4910 Se cambiaron las configuraciones de directiva de grupo para el TBS. 5063 Se intentó una operación del proveedor de cifrado. 5064 Se intentó una operación de contexto de cifrado. 5065 Se intentó una modificación de contexto de cifrado. 5066 Se intentó una operación de función criptográfica. 5067 Se intentó una modificación de función criptográfica. 5068 Se intentó una operación de proveedor de función criptográfica. 5069 Se intentó una operación de propiedad de función criptográfica. 5070 Se intentó una modificación de propiedad de función criptográfica. 5447 Se ha cambiado un filtro del la Plataforma de filtrado de Windows. 6144 La directiva de seguridad en los objeto de directiva de grupo se ha aplicado correctamente. 6145 Se encontró uno o más errores mientras se procesaban las directivas de seguridad en los objetos de directiva de grupo. Subcategoría: Subcategoría de uso special Nota. El suceso siguiente puede ser generado por cualquier administrador de recursos cuando su subcategoría está habilitada. Por ejemplo, el suceso siguiente puede ser generado por el administrador de recur- 204

La aplicación del reglamento de seguridad en los sistemas Microsoft sos de Registro o por el administrador de recursos del sistema de archivos. 4670 Se cambiaron los permisos de un objeto. 11.4.3.9. Protección de los registros Como hemos visto, las auditorías presentan una valiosa información de cara a descubrir posibles incidencias relacionadas con la seguridad. Con objeto de impedir problemas con los datos y que alguien los pudiera borrar, el sistema aplica unos permisos predeterminados sobre el fichero de registro SecEvent.Evt, fichero donde queda almacenada dicha información. Estos permisos pueden ajustarse según las necesidades de la empresa. Sobre este fichero se va a poder efectuar también un registro de auditoría con objeto de determinar accesos y modificaciones. Otro aspecto a tener en cuenta también, es el relacionado con su tamaño y la cantidad de sucesos que puede almacenar. Este fichero, al igual que todos los de registro, tiene un tamaño específi- co que se puede modificar. Si se alcanza el tamaño máximo para dicho fichero, el sistema no permite:  Sobrescribir los sucesos cuando sean necesarios. Se irían eliminando los sucesos según su antigüedad.  Sobrescribir los sucesos que tengan más de un número de días. Sólo se eliminarán sucesos si es necesario que hayan superado el número de días especificados.  No sobrescribir sucesos. Los sucesos no se eliminarán automáticamente, sino que se requiere la intervención manual del administrador. En caso que se hubiera alcanzado el tamaño máximo del fichero y no se pudieran sobrescribir sucesos, el sistema impediría el acceso local a usuarios que no sean administradores, con objeto de impedir que un problema de seguridad queda- ra enmascarado por no sobrescribir los sucesos que los relaciona. Para proceder a la realización de cambios en estas configuraciones, tendremos que recurrir a las propiedades del registro de seguridad en el visor de sucesos. De cara a mejorar la administración y mediante la configuración de políticas de grupo en el Directorio Activo, se puede gestionar toda la configuración del fichero de registro mediante directivas de grupo. Al objeto de asegurar la información que genera la auditoría, se determina que la responsabilidad queda depositada en el administrador para evitar incidentes sobre los datos de auditoría. En el caso de los sistemas operativos Windows Vista y Windows Server 2008, el sistema protege por defecto el fichero secevent.evt donde se depositan las auditorías del sistema, permitiendo que sólo los administradores y la cuenta de sistema tengan acceso a dicho fichero. En el caso de que alguna persona más tuviera que tener acceso a este fichero, habría que concederle permisos explícitos. 205

La protección de datos personales: Soluciones en entornos Microsoft Auditoría: propiedades del registro. Otro problema que se puede plantear es qué pasaría si el registro de seguridad se llena. Evidentemente, este hecho podría ocasionar que no se registraran eventos importantes, o bien que se acabaran eliminando otros. Para evitar estas posibles circunstancias, el sistema prevé que se pueda apagar el sistema en caso de que se llene el registro de seguridad; esta capacidad puede ser habilitada desde las directivas de seguridad en las opciones de seguridad en auditoría: apagar el sistema de inmediato si no puede registrar auditorías de seguridad. De todas formas, con el fin de evitar este procedimiento en sistemas que necesiten una alta disponibilidad, se debería establecer la necesidad de ampliar el tamaño para el almacenamiento de registros y plantear una estrategia para realizar una copia de seguridad de los datos contenidos en el fichero (estableciendo protec- ción sobre el mismo), y vaciando posteriormente el contenido del mismo. 11.4.3.10. Consolidación de Logs Aunque los datos recogidos evidentemente reflejan una importante informa- ción, nos podemos encontrar que ésta puede ser tan ingente que puede ser difícil distinguir los datos realmente relevantes de aquellos que puedan resultar super- fluos. Por tanto, debería adoptarse algún tipo de metodología para la gestión de dichos logs y la información que queda reflejada en ellos. Diferentes empresas han implementado herramientas que en este sentido permiten la recopilación de logs de los diferentes tipos de registros y, por tanto, hacer un seguimiento más exacto de la información y permitir la generación de informes de acuerdo a las incidencias detectadas. La solución Microsoft, Ms. System Center Operation Manager 2007, cumple de forma óptima la funcionalidad para la consolidación de logs y generación de informes con los datos recopilados. ACS Collector (Audit Collection Service), 206

La aplicación del reglamento de seguridad en los sistemas Microsoft constituye el Rol, encargado de la recogida de la información procedente de los agentes correspondientes (ACS Forwarder) y de almacenar la información en el servicio de Base de Datos correspondiente (ACS Database). Además de la gestión de la información, el servicio presenta una serie de informes pregenerados, proporcionando algunos de los datos más importantes relacionados con la seguridad general de los sistemas de información de una empresa:  Gestión de cuentas.  Accesos no autorizados.  Cambios en la política.  Integridad del sistema. No obstante, el servicio permite la generación de nuevos informes que pueden ajustarse a las necesidades de informes mensuales estipulados por el Reglamento de Seguridad que debe elaborar el responsable de seguridad. 11.4.3.11. Auditoría en Exchange 2007 Hoy en día, la auditoría de sistemas Exchange se considera una tarea crucial dentro de las labores de administración y gestión diarias, y como tal no sólo es aplicable en escenarios donde sea de aplicación la normativa LOPD. La auditoría nos permite conocer cómo se están comportando nuestros servidores y detectar posibles problemas o fallos de seguridad. Además, las organizaciones requieren que sus sistemas sean auditables, con el fin de cumplir con la legislación vigente o normativas internas de la propia organización. Aunque existen diversos programas de terceros en el mercado para realizar auditorías tanto de sistema operativo como de Exchange Server, en este apartado se exponen las herramientas que el propio Exchange Server 2007 proporciona para realizar una auditoría de su organización. Exchange Server 2007 incluye importantes mejoras en el ámbito de la recolección de datos y auditoría .Podemos dividir las áreas de auditoría en las siguientes:  Eventos de aplicación.  Auditoría de cambios de configuración.  Registro de Diario.  Logs de transporte.  Seguimiento de mensajes.  Acceso a buzones e inicios de sesión. Eventos de aplicación Exchange Server 2007 registra de forma predeterminada los eventos básicos como aquellos que son críticos para el sistema o alertas de funcionamiento. Si se 207

La protección de datos personales: Soluciones en entornos Microsoft requiere elevar el nivel de registro para realizar un seguimiento detallado, auditar el adecuado funcionamiento o comprobar fallos del sistema, se puede realizar mediante el cmdlet de Powershell Set-EventLogLevel. Elevar el nivel de registro puede ayudar a resolver un problema o auditar el uso que los usuarios realizan de la mensajería. Se pueden establecer los niveles 0 (inferior), 1 (bajo), 3 (medio), 5 (alto) y 7 (experto). El nivel de registro predeterminado es 0 (inferior). Prácticamente todos los procesos de Exchange se pueden configurar con otros niveles de registro diferentes al predeterminado. La lista completa de procesos se puede consultar en la siguiente dirección: http://technet.microsoft.com/es-es/ library/bb201661(EXCHG.80).aspx Auditoría de cambios de configuración Es importante controlar los cambios que re realizan en la configuración de la organización Exchange, quién los ha realizado y en qué momento. Para ello debemos apoyarnos en las capacidades de auditoría de Windows Server mediante la funcionalidad de auditoría de los cambios en los objetos del Directorio Activo, debido a que la mayor parte de la configuración de Exchange se almacena en la parti- ción de configuración del Directorio Activo. Por tanto, se replica en todos los controladores de dominio y se puede cambiar en cualquier Controlador de Dominio. Mediante una GPO, se debe habilitar la directiva de auditoría denominada Auditoría del acceso al servicio de Directorio en los Controladores de Dominio. Para obtener toda la información de acceso, se debe habilitar tanto el error como el éxito. Una vez hecho esto, se registrarán en el visor de eventos de seguridad de los Controladores de Dominio los cambios y accesos realizados a los objetos de Directo- rio Activo, entre los que se encuentran los de Exchange Server. Registro de diario El registro en diario facilita que las organizaciones cumplan con la legislación y normas de control de la información. Además, Exchange Server 2007 ayuda a proteger la información que contienen los informes de registro en diario del acceso no autorizado. El registro en diario es la capacidad de registrar todas las comunicaciones, incluyendo las de correo electrónico. Debido a las nuevas normativas, muchas organizaciones se ven obligadas a mantener los registros de la comunicación entre los empleados cuando realizan las tareas de administración diarias. Entre estas normativas se encuentran la Directiva de protección de datos de la Unión Europea (EUDPD) o la propia Ley Orgánica de Protección de Datos que estamos tratando. Exchange cuenta con un agente de transporte denominado agente de registro en diario, el cual se encarga de cumplir con las reglas configuradas de registro cuando el mensaje cumple con las condiciones establecidas. Exchange 2007 proporciona dos opciones de registro en diario para satisfacer los requisitos de la organización: 208

La aplicación del reglamento de seguridad en los sistemas Microsoft  Diario estándar. Se configura a nivel de base de datos y hace que el agente registre en el diario todos los mensajes enviados y procedentes de los destinatarios y remitentes ubicados en una base de datos de buzones específica.  Registro en diario Premium. Se configura con reglas de diario y permite que se especifique el destinatario o grupo del cual se registrarán los mensajes enviados o recibidos. Para utilizar esta característica se requiere una licencia CAL. Los buzones de registro en diario contienen información muy confidencial; por ello, se deben proteger los buzones de registro en diario porque reúnen mensajes que se envían hacia y desde destinatarios de su organización, y porque estos mensajes pueden formar parte de procedimientos legales o estar sujetos a requisitos normativos. Hay varias leyes que requieren que los mensajes permanezcan sin manipulación antes de que se envíen a una autoridad de investigación. Un informe de diario es el mensaje que genera Microsoft Exchange cuando un mensaje coincide con una regla de diario y debe enviarse al buzón de registro en diario. Exchange 2007 admite sólo el registro en diario de sobres. Mediante el registro en diario de sobres, el mensaje original que coincide con la regla de diario se incluye sin modificaciones como dato adjunto al informe de diario. El cuerpo de un informe de diario contiene la dirección de correo electrónico del remitente, el asunto, el Id. de mensaje y las direcciones de correo electrónico de los destinatarios contenidos en el mensaje original. Cuando el agente de registro en diario registra un mensaje, dicho agente intenta capturar todos los detalles posibles sobre el mensaje original. Esta informa- ción es muy importante a la hora de determinar la intención del mensaje, sus destinatarios y sus remitentes. Logs de transporte Los registros de transporte están disponibles en los servidores con la función de transporte perimetral o concentrador de transporte. Se pueden dividir en las siguientes categorías:  Registro de conectividad. Registro de la actividad de conexión SMTP de las colas de entrega de mensajes salientes al servidor de buzones, host inteligente o dominio de destino. De forma predeterminada, el registro de conectividad está deshabilitado.  Registro de protocolo. Registro de la actividad de los conectores de envío SMTP entre servidores de mensajería. De forma predeterminada, el registro de protocolo está deshabilitado.  Registro de seguimiento de mensajes. Registro detallado de la actividad de transporte de mensajes durante la transferencia de un equipo Exchange a otro. Por defecto, el seguimiento de mensajes está habilitado. 209

La protección de datos personales: Soluciones en entornos Microsoft  Registro de agente. Registro de las acciones que los agentes antivirus y contra correo electrónico no deseado de Exchange 2007 realizan en un mensaje. De forma predeterminada, el registro de agente está habilitado.  Registro de tabla de enrutamiento. Registro de las tablas de enrutamiento que los servidores de transporte utilizan para entregar mensajes. De forma predeterminada, el registro de tabla de enrutamiento está habilitado. Seguimiento de mensajes La herramienta de seguimiento de mensajes que incorpora Exchange Server 2007 ha sido mejorada para permitir búsquedas con criterios de filtrado más flexi- bles y potentes. El seguimiento de mensajes es fundamental para realizar auditorías de transporte de mensajes o resolver incidencias de usuarios en el envío o recepción de mensajes. El seguimiento de mensajes está habilitado por defecto en los servidores de transporte y de buzones de la organización Exchange, por lo que pueden realizarse consultas en cualquiera de estos roles de servidor. La convención de nomenclatura de los archivos de registro del directorio de registro de seguimiento de mensajes depende de la función del servidor que esté instalada. En un servidor de transporte de concentradores o en un servidor de transporte perimetral, los archivos de registro se denominan MSGTRKyyyymmdd- nnnn.log. En un servidor Buzón de correo, los archivos de registro se denominan MSGTRKMyyyymmdd-nnnn.log. De forma predeterminada, los archivos de registro de seguimiento de mensajes se encuentran en C:Archivos de programaMicrosoftExchange ServerTransportRolesLogsMessageTracking. La herramienta de seguimiento de mensajes se encuentra en la sección del centro de herramientas de la consola de Administración Exchange, aunque también se pueden ejecutar utilizando el Shell de Administración con el cmdlet Get- MessageTrackingLog. El seguimiento de mensajes depende del servicio de búsqueda de registros de transporte de Microsoft Exchange, por lo que si éste se deshabilita, no se registrarán los eventos de transporte de los mensajes. Con la herramienta de seguimiento, se pueden consultar los siguientes eventos de transporte: BADMAIL Se ha enviado un mensaje mediante el directorio de recogida o el directorio de repetición que no se puede entregar o devolver. DELIVER Se ha entregado un mensaje a un buzón. DEFER Se ha retrasado la entrega del mensaje. DSN Se ha generado una notificación de estado de entrega (DSN). EXPAND Se ha ampliado un grupo de distribución. FAIL Error al entregar el mensaje. 210

La aplicación del reglamento de seguridad en los sistemas Microsoft POISONMESSAGE Se ha incluido o quitado un mensaje de la cola de mensajes dudosos. RECEIVE Se ha recibido un mensaje y se ha confirmado para la base de datos. REDIRECT Se ha redirigido un mensaje a un destinatario alternativo tras una búsqueda en el servicio de directorio de Directorio Activo. RESOLVE Los destinatarios de un mensaje se han resuelto para una direc- ción de correo electrónico distinta tras una búsqueda en Directo- rio Activo. SEND Se ha enviado un mensaje mediante el Protocolo simple de transferencia de correo (SMTP) a otro servidor. SUBMIT Se ha enviado un mensaje mediante un equipo de Exchange 2007 que tiene instalada la función del servidor Buzón de correo a un equipo Exchange 2007 con la función del servidor Transpor- te de concentradores o la función del servidor Transporte perimetral. Los registros de seguimiento de mensajes que se generan con la función del servidor Buzón de correo sólo contienen eventos de ENVÍO. TRANSFER Los destinatarios se han movido a un mensaje bifurcado debido a la conversión del contenido, los límites de destinatarios de mensajes o los agentes. Asimismo, los filtros de consultas más comunes son:  Recipients: campo de dirección del destinatario.  Sender: campo de remitente.  Server: servidor Exchange 2007 que contiene los registros de seguimiento de mensajes que se van a buscar.  EventID: Id. de evento, especificado en la tabla anterior.  MessageID: Id. de mensaje que se especifica en el encabezado Message- ID.  InternalMessageID: Id. de mensaje interno. Es un número entero identificador de mensaje que asigna el servidor de Exchange 2007 que está procesando el mensaje.  Subject: Asunto del mensaje.  Reference: (referencia) contiene información adicional para tipos de eventos específicos. Para un evento DSN, el campo de referencia contiene el MessageID: del mensaje que provocó el DSN. Para un evento SEND, el campo de referencia contiene el MessageID: de cualquier mensaje DSN. 211

La protección de datos personales: Soluciones en entornos Microsoft Para un evento TRANSFER, el campo de referencia contiene el MessageID: del mensaje que se transfiere.  Inicio y Fin: intervalo de fecha y hora para buscar entradas de seguimien- to. De forma predeterminada, no se almacena ningún contenido de mensaje en el registro de seguimiento de mensajes; sin embargo, sí se almacena el asunto del mensaje. Es posible deshabilitar este registro si la organización lo requiere mediante el cmdlet de PowerShell Set-MailboxServer. Acceso a buzones e inicios de sesión Otra de las áreas de auditoría que se debe tener en cuenta es el acceso a los buzones que realizan los usuarios y los procesos de inicio de sesión, en los que se incluyen los inicios de sesión MAPI, POP e IMAP. Mediante el cmdlet de PowerShell get-mailboxstatistics se puede extraer informa- ción valiosa como el tamaño del buzón, el número de mensajes que contiene y la última vez que se inició sesión en él. Si se requiere tener una visualización en tiempo real de la actividad de los usuarios que se conectan vía MAPI a sus buzones, se pude descargar la herramienta Microsoft Exchange Server User Monitor desde http://www.microsoft.com/downloads/ details.aspx?FamilyID=9a49c22e-e0c7-4b7c-acef-729d48af7bc9&DisplayLang=en . Exchange: Exchange User Monitor. ExMon recopila de forma predeterminada información a intervalos de un minuto y se almacena en trazas de actividad en formato ETL (Event Trace Log) en el directorio de instalación de ExMon. Posteriormente se puede exportar la información contenida en la Traza de auditoría a un archivo de texto separado por comas (CSV) mediante línea de comandos con la propia utilidad Exmon.exe –SU. 212

La aplicación del reglamento de seguridad en los sistemas Microsoft Pero ExMon sólo registra los accesos realizados mediante clientes MAPI. Para otro tipo de accesos como POP o IMAP, Exchange dispone de registros internos que se pueden habilitar. Por defecto, el registro de conexiones POP e IMAP está deshabilitado. Mientras que los accesos MAPI se realizan y se registran directamente en los servidores de buzones, los accesos POP e IMAP se realizan y se registran en los servidores de Acceso de Cliente (CAS). Para ello se deben modificar los siguientes archivos:  Microsoft.Exchange.Pop3.exe.config.  IMAP4 Microsoft.Exchange.Imap4.exe.config. Los dos archivos se encuentran en C:Archivos de programaMicrosoft Exchange ServerClientAccessPopImap. Se trata de dos archivos en formato XML que definen el comportamiento de cada uno de los protocolos a los que hacen referencia. Para habilitar el registro del protocolo se debe cambiar el valor de la entrada ProtocoLog de False a True. La información que se registra de los protocolos POP3 e IMAP4 se divide en campos separados por comas, e incluye los siguientes campos: Date-time La fecha y hora del evento del protocolo. El valor tiene la forma aaaa-mm-ddhh:mm:ss.fffZ, donde aaaa = año, mm = mes, dd = día, hh = hora, mm = minuto, ss = segundo, fff = fracciones de segundo, y Z indica Zulú. Zulú es otra forma de indicar la Hora universal coordina- da (UTC). Connector-id Este campo no se usa en el registro de los protocolos POP3 e IMAP4. Session-id Un GUID que es exclusivo para cada sesión de SMTP, pero que es el mismo para cada evento que está asociado a la sesión de SMTP. Sequence-number Contador que se inicia en 0 y que aumenta para cada evento dentro de la misma sesión. Local-endpoint El extremo local de una sesión de POP3 o IMAP4. Se compone de una dirección IP y un número de puerto TCP que está formateado como <Dirección IP>:<puerto>. Remote-endpoint El extremo remoto de una sesión de POP3 o IMAP4. Se compone de una dirección IP y un número de puerto TCP que está formateado como <Dirección IP>:<puerto>. Evento Un único carácter que representa el evento del protocolo. Los valores posibles para el evento son los siguientes:  + Conectar.  - Desconectar.  > Enviar. 213

La protección de datos personales: Soluciones en entornos Microsoft  < Recibir.  * Información. Datos Información de texto asociada al evento de POP3 o IMAP4. Contexto No se usa en el registro de los protocolos POP3 e IMAP4. Otra posibilidad de registro de protocolo está disponible en los conectores de envío y recepción del protocolo SMTP. Por defecto, el registro del protocolo en dichos conectores está deshabilitado. El registro de protocolo graba las conversacio- nes del Protocolo simple de transferencia de correo (SMTP) que se producen entre servidores de correo electrónico como parte de la entrega de mensajes y se produce en los servidores de transporte de la organización. Tanto los clientes POP3/IMAP, los cuales envían sus mensajes a través de SMTP, como el transporte entre servidores, se registran habilitando el logging de los conectores. Los archivos del registro de protocolo se encuentran en las siguientes ubicaciones:  Archivos del registro de protocolo del conector de recepción: C:Archivos de programaMicrosoftExchange ServerTransportRolesLogsProtocolLogSmtpReceive.  Archivos del registro de protocolo del conector de envío: C:Archivos de programaMicrosoftExchange ServerTransportRolesLogsProtocolLogSmtpSend. Los archivos de registro de protocolos, tanto SMTP como POP3 e IMAP, son archivos de texto que contienen datos en el formato de valores separados por comas (CSV). Además, en cada servidor con la función de concentrador de transporte existe un conector de envío especial denominado conector de envío dentro de la organiza- ción. Este conector se crea implícitamente, es invisible y no necesita administración. El conector de envío dentro la organización se usa para retransmitir mensajes a los siguientes destinos:  A los demás servidores de transporte de concentradores de la organiza- ción de Exchange.  A servidores Exchange Server 2003 de la organización de Exchange.  A servidores de transporte perimetral de la organización de Exchange. De forma predeterminada, el registro de protocolo del conector de envío dentro de la organización también está deshabilitado. Con el cmdlet Set- TransportServer y el parámetro IntraOrgConnectorProtocolLoggingLevel, se habilita el registro de este conector de envío. El registro tendrá lugar en los registros de protocolo del conector de envío que estén configurados en el servidor transporte de concentradores. 214

La aplicación del reglamento de seguridad en los sistemas Microsoft 11.4.4. Artículo 104. Telecomunicaciones Cuando, conforme al artículo 81.3 deban implantarse las medidas de seguridad de nivel alto, la transmisión de datos de carácter personal a través de redes públicas o redes inalámbricas de comunicaciones electrónicas se realizará cifrando dichos datos o bien utilizando cualquier otro mecanismo que garantice que la información no sea inteligible ni manipulada por terceros. Los planteamientos de seguridad, cuando se realiza una transmisión de datos, deben quedar también reflejados cuando se establecen los envíos de datos. Evitar que se puedan robar los datos en tránsito es algo complejo, pero sí se pueden disponer para que los datos queden cifrados y para cualquiera que pudiera robar- los, resulten totalmente ininteligibles. Windows Vista y Windows Server 2008 implementan una serie de mecanismos que va a hacer posible esos mecanismos de cifrado, pudiendo realizarse a diferentes niveles y en función de los elementos empleados. IPSEC, directiva de cifrado. En caso de cualquier tipo de comunicación, tanto a nivel local como en conexiones a través de Internet, los mecanismos de Seguridad IP (IPSEC) garantizan la integridad, la confidencialidad y la autentificación para los datos transmitidos. Enrutado como tráfico IP quedan establecidos los mecanismos de funcionamiento del sistema de seguridad mediante unas series de reglas y de filtros que son aplicadas mediante las directivas de seguridad, bien a nivel local o a través del dominio. Windows Vista y Windows Server 2008 utiliza 3DES como algoritmo de cifrado de datos. IPSEC implementa dos posibles mecanismos de seguridad: cabecera de auten- tificación (AH) y cabecera ESP (Encapsulation Security Payload). AH permite garantizar la integridad de los datos y la autentificación, aunque no va a garantizar que no se pueda ver el contenido de la transmisión. De cara a la 215

La protección de datos personales: Soluciones en entornos Microsoft integridad de datos, el ICV (Integrity Check Value) se calcula mediante algoritmos SHA-1 y MD5. Los mecanismos de autentificación admiten el uso de Kerberos, mecanismos de PKI o claves compartidos. ESP garantiza la confidencialidad de los datos mediante algoritmos 3DES, aunque admite DES por compatibilidad. ESP puede combinarse con AH para establecer niveles más altos de seguridad, garantizando así el envío de datos al sistema correcto e impidiendo que si estos son modificados en tránsito sean admiti- dos como válidos. La funcionalidad de IPSEC entre dos máquinas quedará determinada por el proceso de negociación (ISAKMP) entre ambos sistemas, donde se establecen en función de las directivas, los mecanismos de autentificación, de firmado y de cifrado. IPSEC: captura de conversación sin IPsec. IPSEC: captura de conversación con IPsec. 216

La aplicación del reglamento de seguridad en los sistemas Microsoft Este sistema de implementación es admitido entre sistemas independientemente de si pertenecen o no a un dominio, puesto que los mecanismos de autentifi- cación basados en secreto compartido o los de certificados permiten esa compatibilidad. IPsec proporciona además mecanismos para el envío de datos en modo túnel que permiten el envío de datos cifrados entre redes a través de Internet, cifrando los datos únicamente en la parte pública de la comunicación. Aunque para los procedimientos de configuración de IPSec pueden utilizarse los mecanismos tradicionales de configuración, en las nuevas versiones de los sistemas operativos, esta funcionalidad queda integrada en el módulo de Firewall, con lo cual pueden combinarse ambas características para dar una mayor consisten- cia general en la seguridad. Por consiguiente, IPsec puede ganar las funcionalidades aportadas por el Firewall en las características avanzadas, como por ejemplo, determinar el comportamiento para el cifrado en base al tipo de red en el que pueda encontrarse la máquina: pública, privada o dominio. Además de los mecanismos de comunicación basados en IPsec, Windows Server 2008 soporta la funcionalidad de servidor VPN para establecer comunicaciones remotas a través de túneles de encapsulamiento en la capa 2 a través del Servi- cio NAS (Network Access Service) o bien la implementación con ISA Server 2006 de clientes VPN y conexiones entre sitios. Windows Server 2008 e ISA Server 2006 permiten implementar túneles de VPN mediante PPTP y L2TP. En el caso de L2TP, se utilizan las implementaciones de IPSEC para establecer un sistema de túneles mejorados, estableciendo de esta forma los túneles L2TP/IPSEC donde se utilizan los mecanismos de ESP como medida de seguridad. Windows Vista funciona como cliente VPN dentro de la arquitectura. VPN: propiedades de conexión. Un mecanismo adicional y complementario, sólo disponible en Windows Server 2008, permite garantizar el estado de salud de las máquinas, previniendo una posible intrusión de máquinas que no se encuentren dentro de unos criterios de 217

La protección de datos personales: Soluciones en entornos Microsoft seguridad que haya establecido la organización. Este servicio, denominado NAP (Network Access Protection), implica una arquitectura cliente (Windows Vista, Windows XP SP3) y servidor (Windows Server 2008), donde basándose en unos diferentes patrones de control, se establece a través de diferentes servicios, entre los que figuran los Servicios NAS y de autenticación Wireless, si una máquina se incorpora a una red de cuarentena cuando no ha cumplido los criterios previamente establecidos. Las comunicaciones inalámbricas que cada vez están cobrando una importancia mayor, también permiten mecanismos de seguridad que permiten tanto el cifrado de los datos como garantizar los mecanismos de autentificación. Además de la adopción de mecanismos tipo WEP o WPA, Microsoft presenta dos soluciones de seguridad para estos tipos de redes:  Solución EAP-TLS donde se utilizan los mecanismos de certificados de clientes para autenticar clientes inalámbricos.  Solución PEAP donde se utilizan contraseñas y el protocolo de autentica- ción extensible protegido (PEAP) para autenticar clientes inalámbricos. Microsoft proporciona una guía para la implantación de sistemas de comunicaciones seguros a través de redes inalámbricas. Dicha guía puede obtenerse en la siguiente URL: http://www.microsoft.com/spain/technet/security/guidance/cryptographyetc/ peap_1.mspx. 11.4.5. Confidencialidad en Exchange 2007 Cuando hablamos de confidencialidad en un sistema de mensajería, no sólo nos referimos a las conexiones, sino también al contenido de la transmisión y los propios mensajes. Bajo tal perspectiva, podemos definir confidencialidad como la característica que tiene un mensaje para que solamente sea leído por las personas o servicios autorizados. Si dicho mensaje pudiera ser leído o accedido en algún momento del transporte, depósito o con posterioridad, se estaría vulnerando su confidencialidad. Exchange Server 2007 proporciona tecnologías para mantener la confidencialidad de la información, las cuales van desde el establecimiento de conexiones seguras con TLS/SSL, hasta el soporte para formato S/MIME y gestión de derechos de información (WRM). Los permisos de acceso a los buzones en un organización Exchange Server 2007 preservan el derecho a la confidencialidad. Por defecto, sólo los propios usuarios pueden acceder a su buzón en donde se encuentran sus mensajes de correo electrónico. Ni siquiera el administrador del sistema tiene permisos establecidos para visualizar el contenido de los buzones de los usuarios. Si bien es cierto que dichos permisos se pueden modificar para ajustarse a las necesidades de cada organización, por ejemplo, la relación entre un director y su secretaria, este proceso para otorgar acceso a un buzón de otro usuario debe ser 218

La aplicación del reglamento de seguridad en los sistemas Microsoft previamente solicitado y autorizado mediante un procedimiento oficial de la propia organización. A pesar de ello, la información como tal, por defecto no se almacena cifrada en las bases de datos de mensajes de los servidores Exchange. Resultaría una carga de trabajo adicional para los servidores si tuvieran que estar cifrando y descifrando continuamente el contenido de cientos o miles de usuarios de una organización. Es posible que no todos los usuarios requieran los mismos criterios de seguridad y confidencialidad. Para aquellos buzones sensibles, los cuales requieren medidas adicionales para preservar la confidencialidad, se puede implantar el formato S/MIME para cifrar los mensajes que se envían o reciben. Cuando un usuario envía un mensaje a otro destinatario en Internet, no puede controlar de qué forma se va a transmitir, ni si los canales de comunicación están cifrados o no. Ya sabemos que el transporte entre servidores Exchange dentro de la misma organización sí está cifrado por defecto; sin embargo, una vez que el mensaje sale del servidor perimetral, no es posible saber de antemano cómo se transmitirá dicho mensaje. Por ello, el usuario que necesite un nivel de confidencialidad más alto, puede configurar su cliente de correo para que cifre el mensaje y se transmita cifrado independientemente del medio de transmisión. Para ello se requiere un certificado de cliente, emitido por una Entidad Certifi- cadora de confianza. El certificado se utilizará para firmar el mensaje con la clave privada del usuario y para descifrar los mensajes que le lleguen al usuario, los cuales deben haber sido cifrados con su clave pública por el remitente del mensaje. Tanto la firma digital como el cifrado de mensajes de correo electrónico mejoran la seguridad y la confidencialidad, ya que permite garantizar que el mensaje procede de quien dice ser (validación de firma) y que sólo lo podrá leer el destinatario del mensaje (cifrado). Respecto a este último punto, cabe señalar que el mensaje se guarda cifrado en la base de datos de buzones de Exchange y que sólo el usuario que posea el certificado correspondiente con la clave privada podrá acceder a dicho mensaje. El proceso de cifrado y firma digital es el siguiente: Cifrado y firma digital de un mensaje de correo. 219

La protección de datos personales: Soluciones en entornos Microsoft El proceso de descifrado y validación de la firma digital es el siguiente: Descifrado y comprobación de la firma digital. Una de las mejoras de S/MIME versión 3 que merece la pena destacar es el “triple envoltorio”. Un mensaje S/MIME con triple envoltorio es aquel que se firma, se cifra y se firma de nuevo. Este nivel adicional de cifrado proporciona un nivel adicional de seguridad. Cuando los usuarios firman y cifran mensajes con Outlook Web Access con el control S/MIME, el mensaje tiene triple envoltorio automáticamente. Outlook y Outlook Express no aplican triple envoltorio a los mensajes, pero pueden leer este tipo de mensajes. S/MIME es una tecnología estándar implantada en numerosos productos de mensajería; sin embargo, su principal debilidad es que la configuración de la seguridad recae en el usuario final. En muchas organizaciones, los usuarios no disponen de los conocimientos necesarios para identificar mensajes firmados de aquellos no firmados, para realizar una solicitud de certificado de usuario, o simplemente para hacer una gestión adecuada de los certificados digitales de sus contactos. Además, una desventaja clara de los mensajes cifrados desde el cliente es Correo cifrado mediante S-MIME. 220

La aplicación del reglamento de seguridad en los sistemas Microsoft que no se pueden escanear para detectar virus o filtrar según el contenido del mensaje, y tal y como están las cosas con el SPAM hoy en día, esto puede ser un problema para algunas organizaciones. Es por ello que Exchange Server 2007 implanta un modelo nuevo de confidencialidad cuya responsabilidad recae en los servidores perimetrales y no en el usuario final. Dicho modelo se denomina Message Layer Security (Seguridad a nivel de mensajes), donde el servidor perimetral es el que se encarga de cifrar y firmar el mensaje antes de ser enviado al destinatario. Esta tecnología se apoya en claves públicas y privadas. Las claves públicas se publican en los servidores DNS, desde donde se consultan por parte de los servidores destinatarios. El modelo es muy similar a S/MIME, con la diferencia que todo el trabajo se realiza en el perímetro. Debido a que el remitente debe autenticarse para poder enviar el mensaje hacia Internet, el servidor perimetral es capaz de garantizar la autenticidad del remitente. Cuando el destinatario abra el mensaje, desde OWA u Outlook 2007, se mostrará un mensaje indicando que se ha transmitido de forma segura entre organizaciones Exchange Server 2007 y que la autenticidad ha sido comprobada. Proceso de transporte con MLS. Además, aquellas organizaciones con versiones anteriores de Exchange o incluso aplicaciones de mensajería diferentes, si tienen el soporte para TLS habilitado, ahora los servidores perimetrales de Exchange Server 2007 van a iniciar una conexión TLS predeterminada para la transmisión de los mensajes de correo. Esta mejora se denomina Oportunistic TLS (TLS Oportunista). Por tanto, se garantiza la confidencialidad del mensaje mientras viaja por Internet, incluso entre organizaciones que no tienen ningún tipo de relación, asegurando de esta forma que el intercambio externo de correo con datos de carácter personal conserve ese nivel de seguridad exigido por el Reglamento de Medidas de Seguridad que desarrolla la LOPD. 221

12 La aplicación del reglamento de seguridad en SQL Server 12.1. Artículo 91. Control de acceso En el caso de SQL Server, podemos especificar la seguridad de control de acceso a nivel de cada uno de los objetos dentro de una base datos, llegando incluso a nivel de detalle de columna. El proceso de control de acceso en SQL Server se divide en dos pasos: 1. En primer lugar, el usuario inicia una sesión en la instancia de SQL Server, para lo cual debe disponer de un inicio de sesión asignado, como veremos en la sección de autenticación. Una vez conectado a la instancia, el usuario accederá a una determinada base de datos dentro de esa instancia, para lo cual, su inicio de sesión tendrá que tener asociado un usuario en esa base de datos. En el caso de que el inicio de sesión no tenga un usuario de base de datos asociado, SQL Server buscará si existe el usuario guest, que es el usuario invitado de SQL Server. SQL Server no crea el usuario guest de forma predeterminada, y no se considera buena práctica su utilización. A través de este funcionamiento, ya nos aseguramos de que los usuarios tan solo podrán acceder a aquellas bases de datos a las que específicamente les proporcionemos acceso. 2. Una vez que el usuario tiene acceso a una determinada base de datos, cada vez que ejecute una sentencia en esa base de datos se comprobarán los permisos de que dispone el usuario para asegurarse de que dispone de los permisos necesarios para su ejecución. Como se puede apreciar en la figura, podemos asignar permisos a los usuarios desde las propiedades 223

La protección de datos personales: Soluciones en entornos Microsoft del objeto en cuestión o desde las propiedades del usuario, para cada una de las operaciones, o bien podemos denegar ese permiso. Al mismo tiempo, podemos ver no solo los permisos específicos asignados a ese usuario, sino también los permisos efectivos por pertenencia a grupos (funciones o roles en la terminología de SQL Server). Control de acceso a bases de datos. Todas estas operaciones pueden realizarse también utilizando sentencias Transact-SQL, de modo que podamos generar scripts para asignación de permisos que sean fáciles de reutilizar. Asignación de permisos a usuarios de bases de datos. 224

La aplicación del reglamento de seguridad en SQL Server Como hemos comentado anteriormente, desde las propiedades de un objeto o usuario podemos obtener información acerca de los permisos específicos de esos usuarios sobre los objetos, y del mismo modo, desde las propiedades de un usuario podemos obtener información sobre los permisos específicos de dicho usuario sobre un determinado objeto. A través de la pertenencia a determinados roles de servidor, concretamente sysadmin y securityadmin, podemos controlar qué inicios de sesión pueden cambiar las configuraciones de seguridad y otorgar o denegar acceso a determinadas bases de datos. A nivel ya de base de datos, disponemos de las funciones db_accessadmin, db_securityadmin y db_owner, que nos permiten controlar qué usuarios tienen privilegios para cambiar los permisos de los objetos de cada base de datos. Del mismo modo, cuando se asigna un permiso a un determinado usuario, disponemos de la opción WITH GRANT, a través de la cual, no sólo otorga- mos el permiso al usuario, sino que le proporcionamos también la posibilidad de otorgar esos permisos a otros usuarios. 12.2. Artículo 93. Identificación y autenticación Para gestionar la autenticación de usuarios a las instancias de SQL Server, podemos utilizar dos mecanismos de autenticación: 1. Autenticación de Windows. En este caso, tan solo se permite acceso a la instancia de SQL Server a usuarios previamente autenticados a nivel del sistema operativo. SQL Server no se encarga de validar la contraseña del usuario, tan solo revisa en la tabla de inicios de sesión si le hemos otorgado acceso a dicho usuario Windows a la instancia de SQL Server. Es el mecanismo recomendado, puesto que no viajan contraseñas, ni se almacenan en SQL Server, y podemos reutilizar todos los mecanismos comenta- dos sobre la autenticación y gestión de usuarios a nivel del sistema operativo Windows. 2. Autenticación mixta. En algunos escenarios, por ejemplo cuando tenga- mos clientes que no sean Windows o no formen parte de nuestro dominio, debemos emplear la autenticación mixta. En esta configuración, además de usuarios del sistema operativo, podemos crear inicios de sesión especí- ficos de SQL Server, a los que deberemos asignarles una contraseña. El mecanismo de autenticación predeterminado en la instalación, y recomendado, es la Autenticación Windows. De este modo, podemos reutilizar todas las funcionalidades de seguridad que el sistema operativo Windows proporciona a sus cuentas, y SQL Server no necesita almacenar dichas cuentas ni sus contraseñas. En aquellos escenarios de autenticación mixta, en los que creemos inicios de sesión de SQL Server, disponemos de mecanismos para hacer que el usuario modifique la contraseña en su primer inicio de sesión. Lo que SQL Server almacena de estas contraseñas es su Hash, no se almacenan en texto plano, de modo que disponemos de mecanismos para asegurar su confidencialidad e integridad, puesto que SQL Server cifra los inicios de sesión de estos usuarios, por lo que también viajan protegidos por la red. 225

La protección de datos personales: Soluciones en entornos Microsoft Selección del mecanismo de autenticación. Tal y como acabamos de comentar en el apartado anterior, SQL Server almacena el Hash de las contraseñas, por lo que éstas son ininteligibles. Del mismo modo, cuando creamos inicios de sesión de SQL Server, en una configuración de autentica- ción mixta, podemos configurar sobre estos inicios de sesión las siguientes opciones: 1. Forzar la política de contraseña. Seleccionando esta opción, nos aseguramos de que SQL Server aplicará la misma configuración de política de contraseña que la configurada a nivel del sistema operativo. 2. Forzar caducidad de contraseña. Al igual que en el apartado anterior, seleccionando esta opción, SQL Server aplicará la política de caducidad de contraseña configurada a nivel del sistema operativo del servidor en el que esté instalado SQL Server. A través de estas dos opciones, disponibles desde SQL Server 2005, podemos aplicar un mayor nivel de seguridad que nos permita controlar los inicios de sesión de SQL Server. 12.3. Artículo 94. Copias de respaldo y recuperación SQL Server dispone de mecanismos de control que permiten proteger la información almacenada en sus bases de datos, además de capacidades de copia de seguridad y restauración. El primero de estos mecanismos es el denominado Mode- lo de recuperación. SQL Server mantiene un registro de transacciones por cada una de las bases de datos, en el que se registran las operaciones realizadas con los datos de esa base de datos. EL Modelo de recuperación especifica las operaciones que se registran en dicho log de transacciones y cómo se registran. Disponemos de tres opciones de configuración: 226

La aplicación del reglamento de seguridad en SQL Server Configuración de las opciones de política de cuenta y contraseña. 1. Simple. En el modo de recuperación simple, SQL Server registra mínimamente determinadas operaciones, y trunca el registro de transacciones después de cada Checkpoint. Esta configuración está recomendada, en principio, sólo para escenarios de pruebas o desarrollo, puesto que en esta configuración no podremos realizar copias de seguridad del registro de transacciones. 2. Carga masiva. Es un modelo de recuperación que se considera temporal, y está pensado para aquellos escenarios en los que, teniendo configurado un modelo de recuperación completo, queremos optimizar un proceso de carga masiva de registros, registrando mínimamente esa operación. 3. Completo. Es el modelo predeterminado y el recomendado para las bases de datos en producción. En este modelo de recuperación, todas las transacciones se registran completamente en el log de transacciones, y el log no se trunca en ningún momento. Este modelo nos añade una tarea adicional de mantenimiento para el registro de transacciones, puesto que debemos asegurarnos de que se trunca en algún momento, idealmente, cuando realicemos copia de seguridad del mismo, tal y como comentaremos a continuación. Los cambios de un modelo de recuperación a otro, pueden realizarse en caliente en cualquier momento, desde las propiedades de la base de datos o mediante el comando ALTER DATABASE. Sin embargo, se aconseja realizar una copia de seguridad, antes y después de realizado el cambio, para asegurarnos de no romper la secuencia de copias de seguridad. Por lo que respecta a los tipos de copias de seguridad, SQL Server proporciona los siguientes tipos: 227

La protección de datos personales: Soluciones en entornos Microsoft Modelo de recuperación de base de datos. 1. Completa. En una copia de seguridad completa, SQL Server realiza copia de seguridad de todo el contenido de la base de datos, incluido el registro de transacciones. Además, como la copia de seguridad es una operación que puede realizarse en línea, mientras otros usuarios están trabajando con los datos, SQL Server realiza copia de la parte activa del registro de transacciones, por lo que la copia de seguridad contendrá las operaciones realizadas durante la copia de seguridad. 2. Diferencial. Tomando como base una copia completa, SQL Server recorre las cabeceras de los ficheros en busca del mapa de páginas que marca las extensiones que se han modificado desde la copia completa. Asimismo, como ocurría con la copia completa, se copia la parte activa del registro de transacciones, que contendrá las operaciones realizadas durante el proceso de copia de seguridad diferencial. 3. Registro de transacciones. Realiza copia de seguridad del registro de transacciones, desde una copia completa o desde la anterior copia del registro de transacciones. 4. Copia de seguridad de ficheros o grupos de ficheros. Nos proporciona la posibilidad de realizar copias de seguridad sólo de determinados ficheros o grupos de ficheros de la base de datos. Estos diferentes tipos de copias de seguridad nos proporcionan la flexibilidad suficiente como para crear un plan de copias de seguridad que cumpla con los requisitos tanto funcionales como legales, por muy complicado que sea el entorno de trabajo. 228

La aplicación del reglamento de seguridad en SQL Server A la hora de realizar la restauración de estas copias de seguridad, debemos tener en cuenta que: 1. Las copias de seguridad completas, diferenciales y del registro de transacciones nos permiten realizar una restauración a un punto determinado del tiempo. Esta característica es útil en aquellos escenarios en los que se ha detectado una operación no deseada que no queremos que se restaure. En estos casos, podemos incluso realizar la copia de seguridad después de realizada la operación y detener la restauración en el momento anterior a dicha operación. 2. En la versión empresarial de SQL Server, también las restauraciones pueden ser parciales. Para que una base de datos SQL Server pueda ser abierta, la instancia de SQL Server debe tener acceso al fichero .mdf y al registro de transacciones. En aquellos escenarios en los que disponemos de varios grupos de ficheros para organizar los archivos de datos, podemos ir restaurando parcialmente dichos grupos de ficheros, de modo que vayamos poniendo a disposición de las aplicaciones y usuarios aquellas partes más críticas. Esta característica permite reducir el tiempo de parada en escenarios de bases de datos de gran tamaño. Restauración de la base de datos. 12.4. Artículo 98. Identificación y autenticación Tal y como hemos mencionado, disponemos de la opción, a nivel de inicio de sesión, de hacer que SQL Server aplique las políticas de cuentas de Windows a los inicios de sesión de SQL Server. 229

La protección de datos personales: Soluciones en entornos Microsoft 12.5. Artículo 101. Gestión y distribución de soportes Existen diferentes mecanismos que nos permiten distribuir la información de bases de datos, tales como copia de seguridad y restauración, o la des-asociación y asociación de bases de datos entre instancias. En SQL Server 2008 disponemos de una nueva funcionalidad, denominada Cifrado Transparente de Datos (TDE según sus iniciales en inglés), que nos permite cifrar todos los ficheros de una base de datos. Cuando tenemos habilitada esta opción, SQL Server no sólo cifra los ficheros de base de datos, sino que si realizamos una copia de seguridad, esta última tam- bién se cifra, quedando protegida. Del mismo modo, al realizarse el cifrado a nivel de entrada/salida a disco, si desasociamos la base de datos, esos ficheros permane- cerán cifrados, por lo que si distribuimos esa base de datos en algún soporte, esos datos irán cifrados. Activación del cifrado a nivel de base de datos. A la hora de configurar este cifrado transparente deberemos especificar lo siguiente: 1. El algoritmo de cifrado que deseamos utilizar. Disponemos de las siguientes opciones:  AES 128.  AES 192.  AES 256.  TRIPLE DES. 2. Mecanismo que deseamos utilizar para dicho cifrado. Podemos utilizar bien un certificado de servidor o bien una clave asimétrica. En ambos 230

La aplicación del reglamento de seguridad en SQL Server casos, debemos crear esos objetos en nuestra instancia SQL Server antes de configurar el cifrado. A partir del momento en el que configuremos el cifrado, SQL cifrará y desci- frará el contenido de los ficheros de base de datos (tanto de datos, como de registro de transacciones) en cada operación de lectura y escritura. 12.6. Artículo 103. Registro de accesos A la hora de disponer de un registro de los accesos a una base de datos de SQL Server 2008, disponemos de diferentes mecanismos para obtener dicha información: 1. Utilizando trazas de SQL Server Profiler. Es la más antigua de las opciones, puesto que existe desde las primeras versiones de SQL Server, y nos proporciona la posibilidad de capturar cualquier sentencia que se envíe a una instancia de SQL Server. 2. Captura de datos modificados. La Captura de datos modificados (Change Data Capture) es una de las novedades introducidas por SQL Server 2008, y nos permite llevar un control de todos los cambios realizados en aquellas tablas que configuremos. La principal restricción de esta opción es que sólo podemos controlar las transacciones ejecutadas, no las consultas a los datos. 3. Auditoría. Probablemente es una de las características más demandadas por los profesionales de bases de datos y que aparece en SQL Server 2008 para permitirnos la auditoría en instancias de SQL Server 2008 y que analizaremos a continuación. 12.6.1. Auditoría en SQL Server 2008 Para configurar la auditoría, en primer lugar debemos crear un objeto Auditoría, tal y como muestra la Figura 8. Básicamente definiremos el destino de la auditoría (Fichero, Registro de seguridad o Registro de aplicación) y cómo SQL Server gestionará los tamaños de la auditoría. Deberemos de asegurarnos de habilitar el objeto Auditoría, antes de poder utilizarlo, puesto que por defecto, estos objetos se crean deshabilitados. Una vez definida la auditoría, deberemos crear la Especificación de la auditoría, en la que básicamente configuraremos cuáles son los eventos que deseamos auditar. Llegados a este punto, podemos crear especificaciones a nivel de instancia de SQL Server, para aquellos eventos que se generen a ese nivel, tales como inicios de sesión, por ejemplo; o a nivel de base de datos, para los eventos que ocurren dentro de cada base de datos, tales como los accesos a los datos. Estas especificaciones, a nivel de base de datos, son las que nos interesan en este caso. Para crear dicha especificación, deberemos acceder a la carpeta Especificaciones de auditoría de base de datos, dentro de la carpeta Seguridad de la base de datos, tal y 231

La protección de datos personales: Soluciones en entornos Microsoft Creación de un objeto Auditoría. como podemos apreciar en la primera figura de la siguiente página. En esta especi- ficación debemos configurar lo siguiente: 1. La auditoría en la que almacenaremos el resultado de la especificación. 2. El tipo de acción a auditar, tal como SELECT, UPDATE o DELETE. 3. El objeto, esquema o base de datos, sobre el que queremos aplicar la especificación. 4. La entidad (usuario o rol) que deseamos auditar. Al igual que ocurría con las auditorías, debemos habilitar la especificación para que entre en funcionamiento. A partir de ese momento, se irán registrando las acciones auditadas en el destino seleccionado en la auditoría. Si hemos configurado que la auditoría almacene los datos en fichero, podremos acceder al contenido del mismo a través de la función sys.fn_get_audit_file(), por ejemplo: SELECT * FROM sys.fn_get_audit_file (‘C:TempAudit_Test_E5CF6565-8052-46C3-A8D4- 51D26698F5B5_0_128640862326190000.sqlaudit’,DEFAULT,DEFAULT) 12.7. Artículo 104. Telecomunicaciones En el caso de que realicemos el acceso a datos de carácter personal de nivel alto y almacenados en SQL Server a través de una red pública, deberemos configurar el cifrado de dichas comunicaciones, puesto que de forma predeterminada SQL Server tan sólo cifra los inicios de sesión de los usuarios, pero no las comunicacio- 232

La aplicación del reglamento de seguridad en SQL Server Especificación de la auditoría de base de datos. nes cliente/servidor posteriores. Para ello, deberemos disponer de un certificado a nivel de sistema operativo que nos permita forzar el cifrado de las comunicaciones. Dicho certificado debe cumplir con los siguientes requisitos: 1. La propiedad Subject del certificado debe ser igual al nombre FQDN de la instancia de SQL Server. Como alternativa, podemos configurar, a través del registro de Windows, el nombre del certificado a utilizar. El valor del registro se denomina Certificate y se encuentra en la clave del registro HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSSQL10.xxMSSQLServerSuperSocketNetLib, donde xx hace referencia al nombre de la instancia de SQL Server 2008. Cómo habilitar el cifrado en las comunicaciones de SQL Server. 233

La protección de datos personales: Soluciones en entornos Microsoft 2. El certificado debe contener, como uno de sus usos, la autenticación de servidor. 3. El certificado debe estar instalado para la cuenta de usuario que inicia el servicio de SQL Server. Para que los cambios surtan efecto, debemos reiniciar la instancia de SQL Server. De este modo nos aseguramos de que todas las comunicaciones con esa instancia de SQL Server se cifren. 234

13 Implementación de la LOPD sobre SQL Server SQL Server 2005-2008 13.1. Introducción Actualmente, los sistemas de información de empresas y profesionales almacenan y manejan datos de carácter personal en el desarrollo de su actividad. La ley Orgánica de Protección de Datos de carácter personal del año 1999 genera un conjunto de obligaciones relacionadas con la recogida de datos, acceso, auditoria, consentimiento, uso, almacenamiento, comunicación, cesión de datos, copia de la información, rectificación y acceso. El presente documento muestra las posibilidades que SQL Server tanto en su versión de 2005 como de 2008 ofrece (la filosofía de implementación es aplicable a ambas versiones) para desarrollar los casos de Registro de Accesos que el Real Decreto 994/1999 de 11 de Junio (Reglamento de Medidas de Seguridad de los ficheros automatizados que contengan datos de carácter personal) contempla. Para ello se incluyen en este documento los apartados de requisitos necesarios, modo de implementación y recomendaciones para llevar a cabo este propósito. 13.2. Objetivos del documento Con este documento, se pretende:  Presentar el método para llevar el control de acceso a la información.  Requisitos para la implementación. 235

La protección de datos personales: Soluciones en entornos Microsoft  Acuse de rendimiento debido a la actuación del proceso de acceso a la información.  Recomendaciones. 13.3. Ejemplo teórico Se propone un caso teórico para establecer la base sobre la cual se desarrollará el siguiente apartado, el ejemplo práctico: Partiendo de la premisa que según indica el Real Decreto 994/1999 de 11 de Junio en su capítulo IV (MEDIDAS DE SEGURIDAD DE NIVEL ALTO), en el Artículo 24 (Registro de Accesos) en los puntos 1 y 2: 1. “De cada acceso se guardarán, como mínimo, la identificación del usuario, la fecha y hora en que se realizó, el fichero accedido, el tipo de acceso y si ha sido autorizado o denegado.” 2. “En el caso de que haya sido autorizado, será preciso guardar la información que permita identificar el registro accedido.” Se plantea el caso que se detalla a continuación. Para un conjunto de datos que contienen información de carácter personal y que residen almacenados sobre SQL Server 2005, se necesita registrar el lugar en el tiempo, los accesos a los mismos por usuarios que explotan los datos y posteriormente, si fuera necesario, en caso que el acceso haya sido positivo, recuperar la información a la cual estos usuarios accedieron en el momento deseado. El caso real consistiría en almacenar la información correspondiente a los accesos (identificación del usuario, fecha y hora, consulta realizada y permisividad en el acceso), realizados sobre tablas o vistas específicas, por usuarios que tengan posibilidad mediante aplicaciones o herramientas a los datos que las contienen. Esto será posible mediante la ejecución de trazas específicas y dedicadas (las trazas contendrán los filtros necesarios para no penalizar en rendimiento la actividad diaria de la aplicación) en el servidor de datos SQL Server que registrarán la información anteriormente citada en ficheros de traza. De tal modo que es posible reproducir el comportamiento del tratamiento de información que el usuario realizó recuperando las sentencias ejecutadas en el motor de datos junto con la copia de los datos sobre los cuales el usuario interactuó con ellos. Anotar que en la información que contiene la traza existe información suficiente para verificar si el usuario tuvo acceso permitido o no en la ejecución. Para obtener el conjunto de datos sobre los cuales el usuario interactuó con ellos, el método consiste, en primera fase, en generar una copia de seguridad de los datos y otra de la información residente en el fichero de Log de manera periódica. En segunda fase, para la recuperación de la información en un momento puntual en el tiempo, se procederá con la restauración de los datos desde el backup 236

Implementación LOPD sobre SQL Server completo y posteriormente la restauración de los backups de Log hasta el instante que se requiera, pues existen cláusulas específicas en las sentencias de restauración incluidas en SQL Server 2005 que permiten llevar a cabo este propósito. Una vez que se ha obtenido la consulta a reproducir y se ha recuperado la información hasta el momento pedido, basta con ejecutar la sentencia y recoger la información resultante de ella. 13.4. Requisitos En el siguiente apartado se presentan los requisitos para poder llevar a cabo la implementación propuesta:  Modo de recuperación de la Base de Datos. Para llevar a cabo la recupe- ración de la información de los datos en un instante específico, el modo de recuperación de la BDD ha de estar configurada en modo completo, pues es el modo que permite la generación de copias de seguridad tanto de los ficheros de datos como del fichero de log.  Permisos de seguridad para la creación y manipulación de componentes. Definir roles distintos para el acceso a información resultante del proceso de Registro de Accesos y para la creación de componentes (procedimientos almacenados y permisos para la modificación de los ficheros de traza generados), de tal modo que se distingan las capacidades de crea- ción y manipulación de registros de accesos, de las capacidades de explo- tación de la información resultante.  Almacenamiento de la información en tablas contenidas dentro de SQL Server 2005. Para poder realizar la captura de las sentencias y posterior reproducción de la explotación de la información, los datos deberán estar persistidos en tablas de SQL Server.  Enumeración de las tablas y vistas a filtrar. Para evitar que las trazas recuperen y almacenen más información de la necesaria, se ha de conocer el conjunto de tablas y vistas sobre las cuales se requieren los procesos de seguimiento de acceso a la información, minimizándose tanto el posible impacto de crecimiento de los ficheros de trazas, como la pérdida de rendimiento originada por un alto consumo en las necesidades de almacenamiento de información durante el proceso de Registro de Accesos.  Definición de seguridad. Para poder definir quién accedió a qué informa- ción, el modo de acceso al motor ha de estar definido de tal modo que se pueda identificar al usuario que realizó la consulta-actualización contra el motor. Así pues, por ejemplo, no será válida la posibilidad de identificar los accesos, en los casos que se trate de aplicaciones, componentes que impersonen credenciales de acceso para consultar al motor de datos. 237

La protección de datos personales: Soluciones en entornos Microsoft 13.5. Implementación Las bases sobre las cuales se sustenta el proceso para el control del Registro de Accesos son:  Trazas de SQL Server. Mediante la configuración, ejecución y control de trazas sobre SQL Server 2005, se permite la trazabilidad de sentencias ejecutadas contra el motor de datos, base principal para el control del Registro de Accesos.  Procedimientos almacenados. Para la automatización del proceso de Registro de Accesos, será necesario crear procedimientos que aglutinen las sentencias necesarias para la creación, inicio, y parada de trazas definidas.  Política de copia de seguridad y restauración. Para las situaciones en que se requiera recuperar la información a la cual accedió un usuario específi- co en un momento dado, se habrá de haber realizado copia de seguridad tanto del fichero de datos como de los correspondientes ficheros de log (mediante sentencias específicas de SQL Server que permiten llevar a cabo este propósito). Una vez realizada esta operativa con la periodicidad que marque el uso de la aplicación, se podrá restaurar la información hasta el momento deseado, utilizando las sentencias específicas que SQL Server provee. 13.5.1. Implementación del proceso de Registro de Accesos Indicar que el código que aquí se presenta es un mero ejemplo de la posibilidad de crear trazas de modo programático y cómo se pueden iniciar de modo automático o manual para llevar a cabo los propósitos del Registro de Accesos. Por tanto, la codificación dependerá de los entornos y las necesidades de cada situación.  Creación del modelo de tablas sobre el cual se efectuará el seguimiento de Registro de Accesos. Se plantea el siguiente conjunto de tablas para realizar los ejemplos prácticos del proceso de Registro de Accesos. Tanto la tabla tbPersonas como la tabla tbCcBancarias son candidatas para el proceso de Registro de Accesos. CREATE TABLE dbo.tbPersonas ( ID INT NOT NULL, Nombre NVARCHAR(50), Apellido1 NVARCHAR(50), Apellido2 NVARCHAR(50), Direccion NVARCHAR(100), Sexo BIT, 238

Implementación LOPD sobre SQL Server Fx_Insercion DATETIME DEFAULT GETDATE() ) go CREATE TABLE dbo.tbCcBancarias ( ID INT NOT NULL, FK_tbPersonas_ID INT NOT NULL, FK_tbBancos_ID INT NOT NULL, CCuentaB NVARCHAR(50), Fx_Insercion DATETIME DEFAULT GETDATE() ) go CREATE table dbo.tbBancos ( ID INT NOT NULL, Nombre_Corto NVARCHAR(15), Nombre_Largo NVARCHAR(50) NOT NULL, Fx_Insercion DATETIME DEFAULT GETDATE() ) Go  Creación de la tabla sobre la cual se reflejará el estado actual de ejecu- ción de la traza encargada del Registro de Accesos. A modo de implementar un registro de actividad del estado de la traza en ejecución, y de modo que la información persista de modo que sea consultable, se plantea una tabla tbSeguimientoTraza, sobre la cual se almacenará la infor- mación de identificador de traza, fichero sobre el cual se almacenará la información, fecha de inicio y estado de la misma. CREATE TABLE dbo.tbSeguimientoTraza ( Idtraza INT NOT NULL, Fichero NVARCHAR(128) NULL, Inicio DATETIME NULL DEFAULT (getdate()), Detencion DATETIME NULL, ElemTraza NVARCHAR(128) NULL, ID INT IDENTITY(1,1) NOT NULL ) GO  Procedimiento almacenado encargado de la creación y el lanzamiento de la traza de Registro de Accesos. El procedimiento que a continuación se propone, Crea_Traza_LOPD, presenta la creación de una traza con los eventos de SQL:BatchCompleted, SQL:StmtCompleted y SP:StmtCompleted, junto con los filtros de nombre de tabla y/o vista a tratar (los filtros de los objetos a trazar se envían en formato XML). Además de esto, el procedimiento almacenado se encargará de iniciar la traza definida. 239

La protección de datos personales: Soluciones en entornos Microsoft Para más información consultar los BOL de SQL Server 2005. create PROCEDURE [dbo].[Crea_Traza_LOPD] @EspacioMaximo bigint, --- Espacio máx. del fichero de traza en MB @FicheroTraza nvarchar(128), --- Unidad y ruta del fichero de --- traza; el nombre del fichero será LOPD --- concatenado con la fecha y hora @XML_Objetos xml, --- Identificadores de los objetos a auditar --- en formato XML -- <IDENTIFICADORES><ID>tbpersonas</ID> .. .. .. <ID>tbccbancarias</ID></IDENTIFICADORES> @DB_ID int --- Identificador de la base de datos sobre la --- cual se audita as declare @Traza int declare @IdTraza int select @FicheroTraza=@FicheroTraza+REPLACE(REPLACE(‘LOPD’+convert (nchar(24),getdate(),113),’:’,’’),’ ‘,’’) select @FicheroTraza exec @Traza = sp_trace_create @IdTraza output, 2, @FicheroTraza, @EspacioMaximo, NULL if (@Traza != 0) goto error -- Eventos declare @on bit set @on = 1 -- SQL:BatchCompleted -- SQL:StmtCompleted(41) -- SP:StmtCompleted(45) exec sp_trace_setevent @IdTraza, 12, 1, @on exec sp_trace_setevent @IdTraza, 12, 3, @on exec sp_trace_setevent @IdTraza, 12, 6, @on exec sp_trace_setevent @IdTraza, 12, 7, @on exec sp_trace_setevent @IdTraza, 12, 8, @on exec sp_trace_setevent @IdTraza, 12, 10, @on exec sp_trace_setevent @IdTraza, 12, 11, @on exec sp_trace_setevent @IdTraza, 12, 12, @on exec sp_trace_setevent @IdTraza, 12, 14, @on exec sp_trace_setevent @IdTraza, 12, 15, @on 240

Implementación LOPD sobre SQL Server exec sp_trace_setevent @IdTraza, 12, 22, @on exec sp_trace_setevent @IdTraza, 12, 23, @on exec sp_trace_setevent @IdTraza, 12, 31, @on exec sp_trace_setevent @IdTraza, 12, 34, @on exec sp_trace_setevent @IdTraza, 12, 48, @on exec sp_trace_setevent @IdTraza, 12, 64, @on exec sp_trace_setevent @IdTraza, 41, 1, @on exec sp_trace_setevent @IdTraza, 41, 3, @on exec sp_trace_setevent @IdTraza, 41, 6, @on exec sp_trace_setevent @IdTraza, 41, 7, @on exec sp_trace_setevent @IdTraza, 41, 8, @on exec sp_trace_setevent @IdTraza, 41, 10, @on exec sp_trace_setevent @IdTraza, 41, 11, @on exec sp_trace_setevent @IdTraza, 41, 12, @on exec sp_trace_setevent @IdTraza, 41, 14, @on exec sp_trace_setevent @IdTraza, 41, 15, @on exec sp_trace_setevent @IdTraza, 41, 22, @on exec sp_trace_setevent @IdTraza, 41, 23, @on exec sp_trace_setevent @IdTraza, 41, 31, @on exec sp_trace_setevent @IdTraza, 41, 34, @on exec sp_trace_setevent @IdTraza, 41, 48, @on exec sp_trace_setevent @IdTraza, 41, 64, @on exec sp_trace_setevent @IdTraza, 45, 1, @on exec sp_trace_setevent @IdTraza, 45, 3, @on exec sp_trace_setevent @IdTraza, 45, 6, @on exec sp_trace_setevent @IdTraza, 45, 7, @on exec sp_trace_setevent @IdTraza, 45, 8, @on exec sp_trace_setevent @IdTraza, 45, 10, @on exec sp_trace_setevent @IdTraza, 45, 11, @on exec sp_trace_setevent @IdTraza, 45, 12, @on exec sp_trace_setevent @IdTraza, 45, 14, @on exec sp_trace_setevent @IdTraza, 45, 15, @on exec sp_trace_setevent @IdTraza, 45, 22, @on exec sp_trace_setevent @IdTraza, 45, 23, @on exec sp_trace_setevent @IdTraza, 45, 31, @on exec sp_trace_setevent @IdTraza, 45, 34, @on exec sp_trace_setevent @IdTraza, 45, 48, @on exec sp_trace_setevent @IdTraza, 45, 64, @on -- Filtros declare @salida as bit declare @conta as int declare @XML_Nodo as xml declare @cadena as nvarchar(256) 241

La protección de datos personales: Soluciones en entornos Microsoft select @conta= 1 select @salida=0 while (@salida =0) begin set @XML_Nodo = @XML_Objetos.query(‘ for $DE in /IDENTIFICADORES[1]/ID[sql:variable(“@conta”)], $ELEM in $DE return $ELEM’) if (@XML_Nodo.exist(‘(ID[1])’)=1) begin select @cadena = ‘%’ + @XML_Nodo.value(‘ID[1]’,’varchar(12)’) + ‘%’ exec sp_trace_setfilter @IdTraza, 1, 1, 6, @cadena set @conta= @conta+1 end else select @salida=1 end exec sp_trace_setfilter @IdTraza, 3, 0, 0, @DB_ID exec sp_trace_setfilter @IdTraza, 10, 0, 7, N’SQL Profiler’ -- Set the trace status to start exec sp_trace_setstatus @IdTraza, 1 select TraceID=@IdTraza declare @dat_param as varchar(max) SELECT @dat_param= cast(T.c.query(‘.’) as varchar(max)) FROM @xml_objetos.nodes(‘/IDENTIFICADORES’) T(c) exec (‘insert into LOPD.dbo.tbSeguimientoTraza (Idtraza, fichero, ElemTraza) values (‘+ @IdTraza+’,’’’+ @FicheroTraza+’’’’+’,’’’+ @dat_param + ‘’’)’) goto finish error: select ErrorCode=@Traza finish: GO  Procedimiento almacenado para la parada de ejecución de la traza iniciada con el procedimiento anterior. El procedimiento almacenado que se presenta a continuación, procede a la parada y eliminación del proceso de traza (no se elimina la información recopilada). CREATE Procedure [dbo].[Para_Traza_Espec_LOPD] @ID_Traza_STOP int, @out int output as 242

Implementación LOPD sobre SQL Server declare @IdTrazaTabla int select @idTrazaTabla=t.id from tbSeguimientoTraza t WHERE (t.IdTraza = @ID_TRAZA_STOP) and t.detencion is null BEGIN TRY exec sp_trace_setstatus @ID_Traza_STOP, 0 -- Detiene la traza exec sp_trace_setstatus @ID_Traza_STOP, 2 -- Elimina la traza update tbSeguimientoTraza set detencion = getdate() where id = @idtrazaTabla select @out =0 END TRY BEGIN CATCH — Execute error retrieval routine. SELECT ERROR_NUMBER() AS Error, ERROR_PROCEDURE() as Procedimiento, ERROR_MESSAGE() as Mensaje; select @out=1 END CATCH; GO  Sentencias para la ejecución de modo manual de la traza de Registro de Accesos. Para la ejecución manual del proceso de inicio de trazas se deberá ejecutar la siguiente instrucción. exec dbo.Crea_Traza_LOPD_ 1, ‘C:TrabajoLOPD’, ‘<IDENTIFICADORES> <ID>tbpersonas</ID> <ID>tbccbancarias</ID> </IDENTIFICADORES>’, 29 exec BDD.SCHEMA.Crea_Traza_LOPD 1, ‘C:TrabajoLOPD’, ‘LOPD_0’, ‘%tbPersonas%’,’’ Los parámetros a utilizar corresponden por orden a lo siguiente:  1: tamaño en Mb del fichero de traza a generar.  C:TrabajoLOPD: directorio sobre el cual se generarán los correspondientes ficheros de trazas.  <IDENTIFICADORES><ID>tbpersonas</ID><ID>tbccbancarias</ID></ IDENTIFICADORES>: XML que contiene los objetos a trazar.  29: identificador de la base de datos sobre la cual se procederá a coleccionar información, basada en los filtros de objetos del parámetro anterior. 243

La protección de datos personales: Soluciones en entornos Microsoft  Sentencias para la ejecución de modo automático al inicio de la instancia de SQL Server 2005. Para el inicio del proceso de Registro de Accesos desde el arranque del motor de modo automatizado, se plantean las siguientes instrucciones. CREATE PROCEDURE InicioLOPD as exec LOPD.dbo.Crea_Traza_LOPD 1, ‘C:TrabajoLOPD’, ‘<IDENTIFICADORES><ID>tbpersonas</ID><ID>tbccbancarias</ID></ IDENTIFICADORES>’,29 go — Alta del procedimiento en arranque del motor sp_procoption ‘InicioLOPD’, ‘startup’, ‘true’ go Con la creación de los objetos anteriormente citados obtendríamos el resultado de ficheros de trazas que contienen la información filtrada de los datos referentes a los accesos, junto con información suficiente para poder determinar el usuario, la sentencia que se produjo y el momento de ejecución que generó el acceso sobre el modelo de información.  Procedimiento para la parada de ejecuciones del proceso de Registro de Accesos. Para el proceso de parada de Registro de Accesos, se han definido dos modos diferentes: 1. Ejecución del procedimiento almacenado Para_Traza_Espec_LOPD desde el arranque del motor de modo automatizado; se plantean las siguientes instrucciones: CREATE PROCEDURE [dbo].[Para_Traza_Espec_LOPD] @ID_Traza_STOP INT, @out INT OUTPUT AS DECLARE @IdTrazaTabla INT SELECT @idTrazaTabla=t.id FROM tbSeguimientoTraza t WHERE (t.IdTraza = @ID_TRAZA_STOP) and t.detencion is null BEGIN TRY EXEC sp_trace_setstatus @ID_Traza_STOP, 0 -- Detiene la traza EXEC sp_trace_setstatus @ID_Traza_STOP, 2 -- Elimina la traza UPDATE tbSeguimientoTraza SET detencion = GETDATE() WHERE id = @idtrazaTabla SELECT @out =0 END TRY BEGIN CATCH -- Retorno de error ocurrido. SELECT ERROR_NUMBER() AS Error, ERROR_PROCEDURE() AS Procedimiento, 244

Implementación LOPD sobre SQL Server ERROR_MESSAGE() AS Mensaje; SELECT @out=1 END CATCH; GO 2. O bien, desde un conjunto de informes, ejecutables desde la consola de SQL Server Management Studio: 13.5.2. Acceso a la información de Registro de Accesos Una vez llevadas a cabo las tareas de creación y ejecución anteriormente citadas, se plantea la necesidad de poder replicar el comportamiento que se produjo, de modo que se pueda recuperar la información tratada por un usuario específi- co en un momento dado, con los datos que estaban en vigor en ese instante. Así pues, los pasos necesarios serán:  Recuperación de la consulta realizada en el momento pedido. Se plantean dos modos de acción para recuperar la información almacenada en los ficheros de traza: 1. Apertura de la traza mediante la aplicación “SQL Server Profiler” (véase la primera figura de la siguiente página). 2. Recuperación de la información de traza mediante comandos SQL: SELECT LoginName, NtUsername, Textdata, StartTime, EndTime, EventClass, Error INTO tabla_traza_LOPD FROM ::fn_trace_gettable (‘C:TrabajoLOPDLOPD31_May_2007_09_12_13_217.trc’, DEFAULT) WHERE textdata IS NOT NULL 245

La protección de datos personales: Soluciones en entornos Microsoft Esta sentencia T-SQL se encarga de leer el fichero de traza especificado por parámetro en la función ::fn_trace_gettable y volcar la informa- ción contenida en él, a la tabla tabla_traza_LOPD, la cual no será necesaria haberla creado con antelación pues de ese propósito se encarga la propia sentencia SELECT … INTO. Una vez insertada la información, podremos consultar la tabla tabla_traza_LOPD consiguiendo la operación a replicar.  Recuperación del estado de la información hasta el momento pedido. Es el momento de recuperar la información mediante RESTORE . Para poder realizar esta tarea, el modo de recuperación de la base de datos se ha de encontrar en modo FULL , el cual permite la restauración de la información del Log de transacciones hasta un momento específico. (Véase la primera figura de la siguiente página.) Para llevar a cabo la restauración en un momento específico se deberá ejecutar el siguiente conjunto de instrucciones: Use MASTER RESTORE DATABASE [LOPD_1] FROM DISK = N’C:TrabajoLOPDBCK_LOPD_FULL.bak’ 246

Implementación LOPD sobre SQL Server WITH FILE = 1, MOVE N’0_LOPD’ TO N’C:trabajolopd0_LOPD.mdf’, MOVE N’0_LOPD_log’ TO N’C:trabajolopd0_LOPD_log.ldf’, NORECOVERY GO RESTORE LOG [LOPD_1] FROM DISK = N’C:TrabajoLOPDBCK_LOPD_LOG.trn’ WITH FILE = 1, STOPAT=’Jun 01, 2007 15:22:00 PM’, RECOVERY GO En este caso ejecutaremos la recuperación de la información, hasta el día y hora indicada en la cláusula STOPAT (01-06-2007 a las 15:22:00). La recuperación la realizaremos sobre una nueva base de datos ( LOPD_1 ).  Recuperación de los datos sobre la consulta y la información restaurada. Una vez restaurada la información, y con la sentencia a tratar, ejecutamos ésta en el sistema restaurado recuperando la información deseada. 247

La protección de datos personales: Soluciones en entornos Microsoft Datos en la BDD original LOPD_0. Datos en la BDD restaurada LOPD_1. 13.5.3. Recomendaciones en casos especiales  No es necesaria la restauración en un entorno espejo al de producción para el proceso de restauración, pues los requerimientos de aplicación (carga de usuarios, concurrencia) no estarán presentes.  Para la recuperación de tablas con un gran volumen de información y que se encuentren definidas en “files”, existe la posibilidad de recuperarlas desde copias de seguridad mediante la instrucción RESTORE DATABASE <nombre_basedatos> <fichero_o_grupoficheros> [n] ... WITH NORECOVERY .... 13.6. Rendimiento Para evitar que el rendimiento del proceso de traza penalice en rendimiento a la operativa diaria de la aplicación, es recomendable almacenar los ficheros resultantes de la traza en unidades de disco que no interfieran en el proceso de los ficheros. 13.6.1. Sobrecarga del proceso de traza Para probar la carga efectiva del proceso de Registro de accesos, se ha planteado el siguiente marco de pruebas: Sobre el conjunto de tablas definidas en este documento con anterioridad, se ha procedido a realizar las siguientes ejecuciones de modo que se pueda simular la carga de ejecución sobre una aplicación tipo que consulta datos en un 75% de los casos y actualiza e inserta en el 25% restante: 248

Implementación LOPD sobre SQL Server  Consulta Simple. Acceso mediante join a la tabla de personas y cuentas bancarias, devolviendo 1000 filas por cada ejecución.  Consulta Media. Acceso mediante join a las tablas de personas, cuentas bancarias y bancos con ordenación específica, devolviendo 500 filas por ejecución.  Consulta Compleja. Acceso dentro de la misma ejecución a las dos consultas anteriormente citadas.  Actualizaciones e inserciones. Proceso que realiza 10 inserciones sobre la tabla Bancos, 5 inserciones sobre la tabla Personas y 10 inserciones sobre la tabla tbCcBancarias. Después de realizar las mediciones referentes a consumo de CPU, se muestra que el consumo medio extra se refiere en torno a un 2%, la diferencia entre las dos mediciones realizadas, consumo medio de CPU en caso únicamente de proceso de carga 62,357 y consumo medio de CPU en el caso de proceso de carga y trazas activas 64,185. Ejecución de proceso de carga. Ejecución de proceso de carga más trazas activadas. Anotar que para el proceso de Registro de Accesos sólo se han registrado las consultas que realizaban llamadas a la tabla tbPersonas y tbccBancarias. 249

La protección de datos personales: Soluciones en entornos Microsoft 13.6.2. Almacenamiento físico de los ficheros de traza Otro parámetro a tener en cuenta es el almacenamiento físico de las trazas, pues la información que éstas arrojan es almacenada físicamente en ficheros con extensión “.trz”. A continuación se muestra una tabla con información de espacio resultante de procesos de pruebas de registro de actividad: Número de Tiempo sentencias Sentencias Espacio de ejecución recogidas por segundo requerido 10 minutos 6.168 10,3 2.304 Kb 10 minutos 10.387 17,3 3.712 Kb 10 minutos 88.548 147,6 27.520 Kb Para los datos mostrados se ha utilizado el modelo de datos citado en anteriores apartados con las consultas utilizadas durante la prueba de “Sobrecarga de proceso” y recogiendo información de las consultas accedidas sobre las tablas tbPersonas y tbBancos. El número de ficheros de traza generados fue de cuatro, ya que el tamaño definido para el “rollover” de ficheros de traza automática se situó en 1Mb, correspondiendo a dos ficheros de 1024 Kb para el caso de la traza sobre la tabla tbPersonas y otros dos ficheros más, con tamaños 1024 Kb y 640 Kb respectivamente, para el proceso de traza sobre la tabla tbBancos. Debido al espacio físico que pueden llegar a acumular las trazas durante el proceso de Registro de Accesos (una gran cantidad de objetos a trazar, aumentará el contenido del fichero “.trz” correspondiente) es recomendable:  Establecer una política de almacenamiento y RollOver de ficheros:  Durante la creación de los ficheros de traza mediante la instrucción sp_create_trace, se permite definir tanto el tamaño de fichero como el comportamiento en caso que éste llegue al máximo de la capacidad definida, en el caso de activación/creación de la traza mediante el parámetro RollOver. La propia instrucción se encargará de generar ficheros de traza con una numeración consecutiva.  Si la característica RollOver se encuentra activada, establecer un tamaño máximo de fichero de traza, por ejemplo de 100 Mb, de tal modo que sean manejables y fácilmente accesibles para la búsqueda de información sobre ellos.  Establecer un sistema cíclico de volcado de información a histórico, como por ejemplo de carácter semanal. 250

Implementación LOPD sobre SQL Server  Tratar la información resultante comprimiéndola:  Debido a la naturaleza de la información contenida por los ficheros de traza, ésta es transformada en una relación aproximadamente de 1/30 después de realizar procesos de compresión sobre ella. Esto permite reducir el almacenamiento de un modo bastante considerable. Tamaño Tamaño de traza comprimido 2.304 Kb 67 kB 3.712 kB 94 kB 27.520 kB 739 kB 13.7. Nuevas características en SQL Server 2008 El proceso anteriormente descrito es posible llevarlo a cabo sobre la versión SQL Server 2008. No obstante, hay que tener en cuenta que esta última versión goza de mejoras orientadas al control de registro de accesos al motor de datos mediante las opciones Enable Common Criteria compliance y Enable C2 audit tracing, así como el conjunto de auditoría de acceso. 251

La protección de datos personales: Soluciones en entornos Microsoft Otro de los puntos de interés que trae consigo SQL Server 2008 es Change Data Capture, que permite el registro de cambios de datos en tablas sin necesidad de utilizar triggers u otros mecanismos de intercepción de los cambios. Para información más detallada de todas las mejoras de esta última versión, remitirse a BOL o http://msdn.microsoft.com/es-es/library/cc280526.aspx. 13.8. Apéndices 13.8.1. Implementación de trazas sobre SQL Server 2005  Introducción a las trazas de SQL http://msdn2.microsoft.com/es-es/library/ms191006.aspx  Visualización y análisis de trazas con el Analizador de SQL Server http://msdn2.microsoft.com/es-ES/library/ms175848.aspx  Reproducción de trazas http://msdn2.microsoft.com/es-es/library/ms190995.aspx 252

Implementación LOPD sobre SQL Server 13.8.2. Posibilidades de Backup y Restore en SQL Server 2005  RESTORE Statements for Restoring, Recovering, and Managing Backups http://msdn2.microsoft.com/en-us/library/ms190372.aspx  BACKUP (Transact-SQL) http://msdn2.microsoft.com/en-us/library/ms186865.aspx  Working with Transaction Log Backups http://msdn2.microsoft.com/en-us/library/ms190440.aspx 13.8.3. Seguridad en SQL Server 2005  Consideraciones de seguridad para SQL Server http://msdn2.microsoft.com/es-es/library/ms161948.aspx  Permisos necesarios para ejecutar el Analizador de SQL Server http://msdn2.microsoft.com/es-es/library/ms187611.aspx 13.8.4. Seguridad en SQL Server 2008  Seguridad y protección (motor de base de datos) http://technet.microsoft.com/es-es/library/bb510589.aspx  Mejoras de seguridad (motor de base de datos) http://msdn.microsoft.com/es-es/library/cc645578.aspx 253

14 Política de seguridad 14.1. Introducción La necesidad de definir una política de seguridad es algo absolutamente indiscutible. Las actuaciones voluntaristas de un departamento de TI en materia de seguridad siempre estarán lejos de conseguir muchos de los objetivos que nos marcamos en esa visión multidimensional del problema. Ni la tecnología es el único problema, ni evidentemente es la única solución. El cumplimiento de la LOPD representa un indiscutible impulsor del sector de la seguridad en España. Aprovechar la necesidad legal de su cumplimiento para extender el alcance de las iniciativas tomadas hacia una política de seguridad general mas allá del estricto dato personal, es una decisión tomada por numerosas empresas. Resultará interesante hablar de qué pasos podemos dar para conseguir una política de seguridad correcta. Existen numerosos procedimientos que determinan la calidad de un sistema en este aspecto, BS, ISO, AENOR, etc., cuyos aspectos están fuera del alcance de este capítulo. Sin embargo, todos aquellos responsables de poner en marcha una política de seguridad saben de la dificultad innata a la tarea de ajustar una iniciativa como ésta a la idiosincrasia de la empresa. Desde el momento en el que una política de seguridad afecta a toda la compañía, a todos y cada uno de sus departamentos, ya sabemos que nos enfrentamos a una tarea compleja cuyo éxito depende en gran medida del compromiso de los implicados en su definición fundamentalmente, pero de toda la compañía en general. 14.2. Fases fundamentales Sin pretender dar un recetario, exponemos unos puntos de reflexión extraídos de experiencias de profesionales de la seguridad, y que recogen algunas de las 255

La protección de datos personales: Soluciones en entornos Microsoft dificultades y métodos para la definición inicial de una política de seguridad y acercarnos a ese compromiso deseado de la compañía. Son puntos muy prácticos que arrojan algo de luz sobre los pasos previos necesarios a dar en su definición. Establecemos cinco fases fundamentales con objetivos muy definidos, aunque sólo comentaremos las tres primeras por ser las más orientadas a dar esos primeros pasos organizativos:  Fase 1. Organización y análisis.  Fase 2. Desarrollo de un estudio sobre las necesidades de privacidad.  Fase 3. Evaluación de las necesidades tecnológicas para la protección de la privacidad.  Fase 4. Desarrollo de la política y planes.  Fase 5. Implementación del plan. 14.2.1. Fase 1. Organización y análisis Esta fase supone la puesta en marcha de la iniciativa y requiere una toma de datos básica, así como estructurar un grupo de trabajo capaz de ponerla en marcha. Podemos definir ocho puntos a tener en cuenta en esta fase:  Desarrollo de una filosofía general de privacidad. Es decir, establecer un equilibrio de consenso entre las perspectivas de bajo y alto riesgo. Una perspectiva de bajo riesgo es aquella en la que una política de seguridad está en marcha, la diseminación de información está fuertemente controlada, las políticas se establecen por tipo de dato, todas las salidas de infor- mación fuera de la empresa necesitan ser previamente aprobadas, etc. Por el contrario, una perspectiva de alto riesgo es aquella en la que políticas no severas están en marcha, la información se controla débilmente, existen políticas globales poco específicas y se permite a las unidades de negocio y departamentos el tomar sus propias decisiones sobre el uso de la infor- mación. Ambos extremos delimitan una filosofía de privacidad llena de grises. Definir a priori la filosofía más cercana a nuestras necesidades es muy conveniente y complicado pues, dentro de la misma compañía, existirán departamentos más decididos por una política de bajo riesgo, mientras otros abogarán por una de alto riesgo.  Responsable de privacidad. Los más elevados niveles de la dirección deben apoyar los planes de privacidad ante toda la compañía. Es un indicador de la importancia que este asunto tiene para la compañía. Aunque el apoyo es fundamental, no es lo más recomendable que este nivel esté involucrado en el día a día del desarrollo del plan de seguridad. Simplemente por no ser lo más efectivo. Un director de nivel medio es más adecuado para coordinar la tarea. La persona encargada deberá 256

Política de seguridad dedicar gran parte de su tiempo a esta tarea que, en ocasiones, requerirá una dedicación total. Debe mantener una buena relación con todos los departamentos de la empresa y con los recursos externos.  Creación del Grupo de trabajo de privacidad (Privacity Task Force). Es necesario crear un grupo de trabajo interdepartamental liderado por el responsable de privacidad y con representación de todos los departamentos de la compañía (dos por departamento, uno principal y otro suplente). El mejor rol posible del CEO sería asegurarse de que el grupo de trabajo de seguridad obtiene los recursos, la participación y la cooperación necesarios para este desempeño. La función del CEO en este sentido es la de dejar constancia de la importancia del grupo en todos sus reportes directos, así como dar el apoyo necesario para situar la importancia de la tarea asignada al grupo creado.  Organización a nivel departamental .Cada departamento deberá tener su propio equipo de privacidad que desarrolle los trabajos de investigación, evaluación o implementación, liderados por su representante en el Grupo de trabajo. Debería constituirse con niveles de supervisión y técnicos.  Evaluación de la capacidad del Grupo de trabajo. Es necesario evaluar las capacidades y conocimientos del grupo de trabajo, formación, experiencia en asuntos relacionados con la privacidad, etc. Igualmente, es una tarea a desarrollar por cada miembro del grupo de trabajo en su grupo departamental. Identificar correctamente esto permitirá identificar necesidades de formación y/o contratación de ayuda externa (legal, consultoría, etc.). El objetivo es cubrir las carencias detectadas en el apartado anterior.  Establecer el calendario de trabajo. Será imprescindible desarrollar una agenda de reuniones periódicas desde el primer momento, con objetivos concretos. Una reunión de frecuencia fija será necesaria, además de las que el proceder vaya marcando. Serán necesarias para formar subcomités, identificar responsabilidades, asignar tareas interdepartamentales, etc. Los grupos departamentales deberán reunirse con la frecuencia necesaria para respetar las agendas y compromisos del Grupo de trabajo global.  Campaña de concienciación. La iniciativa necesita ser apoyada y conoci- da por toda la compañía. Los distintos grupos de trabajo tendrán escaso éxito sin el apoyo y conocimiento de todos los empleados. Se deben utilizar todos los medios de comunicación interna: newsletters, intranets, reuniones, marketing interno, etc.; así como plantear planes de formación al respecto para las nuevas incorporaciones y para los empleados.  Establecer el escenario para el inicio del estudio de necesidades de privacidad. Notificar a los empleados el tipo de información que será necesaria recoger en el inicio del estudio (a acometer en la siguiente fase). 257

La protección de datos personales: Soluciones en entornos Microsoft 14.2.2. Fase 2. Desarrollo de un estudio sobre las necesidades de privacidad La compañía debe comenzar a conocer los diferentes tipos de datos e informa- ción que almacena y utiliza. Esta fase ayuda a la compañía a identificar esos datos, determinar su origen, establecer cómo deben ser utilizados, identificar de qué forma y cómo se diseminan. Además, este proceso ha de identificar aquellas leyes y regulaciones gubernamentales y requerimientos internos que pueden gobernar la forma en la que se recogen y difunden esos datos. 14.2.2.1. Establecer un sistema de inventario de datos Apoyarse en una base de datos es una herramienta útil para almacenar la información recogida. Probablemente, los campos indicados constituyan una buena base de partida para la construcción de dicha base. El inventario ha de ser lo más profundo posible. Ninguna compañía debería tener una falsa percepción de seguridad como fruto de un inventario de datos incompleto. Es muy común leer en el periódico un caso concreto sobre problemas de privacidad de un determinado tipo de datos y prematuramente concluir con que no somos vulnerables. Los campos de esta base de datos bien podrían ser: descripción del dato, departamento responsable, fuente, sistema donde reside, dónde residen copias en papel, cómo y dónde se utilizan internamente, cómo y dónde se distribuyen, política existente sobre el uso de datos, leyes al respecto del uso de esos datos, incidentes previos respecto a su uso, notas del grupo de seguridad sobre esos datos, etc. 14.2.2.2. Puesta en marca del proceso de inventario Son muchas las fuentes de datos que hay que considerar. Cada departamento debe determinar qué tipo de datos recoge, crea o utiliza. El grupo departamental debe proporcionar esta información al grupo de seguridad. Las compañías no deben presuponer que el departamento de TI conoce todos los datos utilizados por los demás departamentos o unidades de negocio. Los almacenes de datos surgen “como setas” en las compañías. Por ejemplo, ficheros de los usuarios, ficheros de los proveedores, del canal de partners, registros desde el web site, registros de empleados, ficheros de I+D, ficheros de suscripción para newsletters corporativas, etc. En cualquier caso, las compañías deben ser muy realistas en este aspecto, ya que todos los departamentos y unidades de negocio se sienten como propietarios absolutos de esos datos. Hay una barrera cultural al cambio. Existe una tendencia observada en el tiempo a no cooperar totalmente con las iniciativas de ámbito global. La mejor herramienta para conseguir esa profundidad en el análisis de los datos puede que no sea enviar un formulario enorme a cada supervisor para que sea completado, sino una aproximación más de concienciación en la que tanto supervisores clave como expertos técnicos son encuestados sobre cómo son manejados los datos. Tres puntos de la estrategia global puesta en marcha pueden ayudar a vencer resistencias: 258

Política de seguridad 1. Campaña de información interna sobre la importancia de la privacidad, realizada en la fase anterior, proporcionando al empleado una forma de proporcionar feedback sobre vulnerabilidades potenciales de la privacidad. 2. Comenzar el proceso formal de inventario de datos. 3. Crear y distribuir una encuesta a los empleados clave para recoger sus inputs sobre la vulneración de la privacidad. La compañía puede triangular estas tres fuentes de información y obtener valiosa información mientras construye el inventario de datos. 14.2.2.3. Existencia de políticas previas ¿Existe ya alguna política previa asociada a determinado tipo de dato? ¿Inclu- so cuando no se haya identificado como política? Si existe, es el momento de reco- gerla, ya esté escrita o no, para su posterior análisis por el grupo de seguridad. Este proceso debe examinar si las políticas existentes no contradicen las nuevas. No se deben cambiar las existentes si se adaptan bien a las nuevas. 14.2.2.4. Leyes actuales. LOPD ¿Existe una normativa especial que gobierne el manejo de los datos que manipulamos? La asesoría legal es un aspecto muy importante para evitar posibles malas interpretaciones o acciones incorrectas en lo que respecta a la normativa existente. 14.2.2.5. Asesoría y cobertura de seguros Se deben estudiar las ofertas de compañías de seguros en materia de coberturas por interrupción de actividad y/o violación de privacidad. Las grandes compa- ñías suelen tener un departamento de análisis de riesgos, bajo cuyo paraguas caería la responsabilidad de evaluar los riesgos y las coberturas de los seguros asociados. 14.2.2.6. Identificar problemas de privacidad pasados y presentes Desafortunadamente, muchas compañías no comienzan a tomarse en serio la seguridad hasta que existe algún incidente. El grupo de trabajo debe ser informado sobre cómo se actuó en este sentido. El mayor obstáculo se presenta cuando se recurre a la “memoria institucional” y vemos que los implicados en el problema ya no están en la compañía o que la memoria tiende a ser muy selectiva. 14.2.2.7. Revisar políticas de seguridad y problemas de los partners de negocio ¿ Podríamos ser vulnerables por las prácticas de nuestros proveedores, canal, etc.? Estos partners de negocio deben ser informados de la puesta en marcha del plan. El mayor obstáculo es conseguir su cooperación, la que dependerá en gran medida del número de partners y la capacidad de influencia en sus procesos. 259

La protección de datos personales: Soluciones en entornos Microsoft 14.2.2.8. Chequear la reputación entre organismos jurídicos especializados Las compañías deberían contactar directamente con organizaciones jurídicas o no jurídicas, pero con algún interés existente en indagar en la privacidad con la que tratamos nuestros datos, y chequear si han encontrado algún problema. De paso, aprovechar para informar sobre el desarrollo de un nuevo plan de privacidad. 14.2.2.9. Consolidación de resultados y clasificación de datos Una vez recogida toda la información, es la hora de consolidar en informes todo lo correspondiente a esta fase, con especial atención a la clasificación de los datos recogidos en base a criterios de sensibilidad e importancia de su privacidad. A partir de esto, puede comenzarse a adelantar un borrador sobre la política de seguridad y procedimiento en el manejo de ese tipo de datos. Como resultado de esta fase, deberíamos tener muy claro el inventariado de datos y su clasificación según su sensibilidad e importancia, así como toda la normativa legal que les afecta. En este apartado, un subcomité del grupo de seguridad debería iniciar la siguiente fase, en estrecha colaboración con el departamento de TI o un consultor externo de tecnologías de la información, para llevar a cabo una evaluación de la tecnología que puede ayudar a mantener el nivel de privacidad deseado. 14.2.3. Fase 3. Evaluación de las necesidades tecnológicas para la protección de la privacidad Es necesario evaluar las capacidades existentes en la empresa para operar e implantar la tecnología necesaria para asegurar la privacidad de la información corporativa. Esta evaluación requiere un detenido análisis de tecnologías, personal de seguridad, fondos para seguridad y planes de seguridad. Este estudio debería ser llevado a cabo por un subcomité de la Task Force, en trabajo conjunto con el departamento IT y, si fuera necesario, contar con una consultoría externa. Las funciones de este subcomité irían orientadas a:  Asesorar al Grupo de trabajo sobre aspectos tecnológicos.  Preparar reuniones sobre problemas tecnológicos específicos.  Educar al Grupo de trabajo sobre el potencial y limitaciones de la tecnología.  Examinar las capacidades en materia de seguridad en las tecnologías de la información.  Revisar problemas tecnológicos derivados de las necesidades de privacidad detectadas en la fase anterior.  Revisar los procedimientos y planes de seguridad de la información existentes.  Testear la seguridad de la tecnología de la información. 260

Política de seguridad  Ayudar en las pruebas sobre las debilidades existentes en los procedimientos en torno a la privacidad. Las tecnologías sobre las que tenemos que reflexionar en cada uno de los aspectos necesarios se pueden clasificar perfectamente en: 1. Tecnologías para la protección de la información almacenada en sistemas. 2. Tecnología para la protección de los datos en tránsito. 3. Tecnología para la protección de las comunicaciones de voz. 4. Tecnologías para la protección física de las copias de información. 5. Tecnología para el cumplimiento de las especificaciones de “Puerto Seguro” (Safe Harbor). En este punto resulta fundamental conocer lo que la tecnología nos ofrece y seleccionar los elementos que nos permitan afrontar cada uno de estos aspectos. Microsoft es el fabricante de software que más soluciones de seguridad aporta a sus productos. El objetivo es la “democratización” del acceso a la seguridad, que la seguridad no se convierta en algo inalcanzable . En cualquier caso, es IMPRESCINDIBLE que el subcomité tecnológico del Grupo de trabajo revise las capacidades, conocimientos y certificaciones de todo el staff responsable de la gestión de la red y control de los productos de software, y recomendar formación adicional si fuera necesario. En términos tecnológicos, los sistemas se constituyen tan seguros como los conocimientos de las personas que los operan. No caigamos en el repetido error de dar la operación de determinados sistemas a personas inexpertas o sin la debida formación. Todos los sistemas requieren ser operados por personal cualificado y certificado. No descuidemos este aspecto que la experiencia nos enseña, ya que puede ser fuente de posteriores problemas o vulnerabilidades en la integridad del sistema. 261

Parte III Anexos Anexo A. Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal 265 Anexo B. Real decreto por el que se aprueba el reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal 295 Glosario de términos 383

A Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal (Cambio denominación por artículo 79 Ley 62/2003, de 30 de noviembre: Las referencias a la Agencia de Protección de Datos deberán entenderse realizadas a la Agencia Española de Protección de Datos.) TÍTULO I. Disposiciones generales Artículo 1. Objeto 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. Artículo 2. Ámbito de aplicación 1. 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úbli- co y privado. Se regirá por la presente Ley Orgánica todo tratamiento de datos de carácter personal: a) Cuando el tratamiento sea efectuado en territorio español en el marco de las actividades de un establecimiento del responsable del tratamiento. 265

La protección de datos personales: Soluciones en entornos Microsoft b) Cuando al responsable del tratamiento no establecido en territorio español, le sea de aplicación la legislación española en aplicación de normas de Derecho Internacional público. c) Cuando el responsable del tratamiento no esté establecido en territorio de la Unión Europea y utilice en el tratamiento de datos medios situados en territorio español, salvo que tales medios se utilicen únicamente con fines de tránsito. 2. El régimen de protección de los datos de carácter personal que se establece en la presente Ley Orgánica no será de aplicación: a) A los ficheros mantenidos por personas físicas en el ejercicio de actividades exclusivamente personales o domésticas. b) A los ficheros sometidos a la normativa sobre protección de materias clasificadas. c) A los ficheros establecidos para la investigación del terrorismo y de formas graves de delincuencia organizada. No obstante, en estos supuestos el responsable del fichero comunicará previamente la existencia del mismo, sus características generales y su finalidad a la Agencia de Protección de Datos. 3. Se regirán por sus disposiciones específicas, y por lo especialmente previs- to, en su caso, por esta Ley Orgánica los siguientes tratamientos de datos personales: a) Los ficheros regulados por la legislación de régimen electoral. b) Los que sirvan a fines exclusivamente estadísticos, y estén amparados por la legislación estatal o autonómica sobre la fun ción estadí stica públi ca. c) Los que tengan por objeto el almacenamiento de los datos contenidos en los informes personales de calificación a que se refiere la legisla- ción del Régimen del personal de las Fuerzas Armadas. d) Los derivados del Registro Civil y del Registro Central de penados y rebeldes. e) Los procedentes de imágenes y sonidos obtenidos mediante la utiliza- ción de videocámaras por las Fuerzas y Cuerpos de Seguridad, de conformidad con la legislación sobre la materia. Artículo 3. Definiciones A los efectos de la presente Ley Orgánica se entenderá por: a) Datos de carácter personal: Cualquier información concerniente a personas físicas identificadas o identificables. b) Fichero: Todo conjunto organizado de datos de carácter personal, cualquiera que fuere la forma o modalidad de su creación, almacenamiento, organización y acceso. 266

Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal c) Tratamiento de datos: Operaciones y procedimientos técnicos de carácter automatizado o no, que permitan la recogida, grabación, conservación, elabo- ración, modificación, bloqueo y cancelación, así como las cesiones de datos que resulten de comunicaciones, consultas, interconexiones y transferencias. d) Responsable del fichero o tratamiento: Persona física o jurídica, de naturaleza pública o privada, u órgano administrativo, que decida sobre la finalidad, contenido y uso del tratamiento. e) Afectado o interesado: Persona física titular de los datos que sean objeto del tratamiento a que se refiere el apartado c) del presente artículo. f) Procedimiento de disociación: Todo tratamiento de datos personales de modo que la información que se obtenga no pueda asociarse a persona identificada o identificable. g) Encargado del tratamiento: La persona física o jurídica, autoridad pública, servicio o cualquier otro organismo que, solo o conjuntamente con otros, trate datos personales por cuenta del responsable del tratamiento. h) Consentimiento del interesado: Toda manifestación de voluntad, libre, inequívoca, específica e informada, mediante la que el interesado consienta el tratamiento de datos personales que le conciernen. i) Cesión o comunicación de datos: Toda revelación de datos realizada a una persona distinta del interesado. j) Fuentes accesibles al público: Aquellos ficheros cuya consulta puede ser realizada por cualquier persona, no impedida por una norma limitativa, o sin más exigencia que, en su caso, el abono de una contraprestación. Tienen la consideración de fuentes de acceso público, exclusivamente, el censo promocional, los repertorios telefónicos en los términos previstos por su normativa específica y las listas de personas pertenecientes a grupos de profesionales que contengan únicamente los datos de nombre, título, profesión, actividad, grado académico, dirección e indicación de su pertenencia al grupo. Asimismo, tienen el carácter de fuentes de acceso público, los Diarios y Boletines oficiales y los medios de comunicación. TÍTULO II. Principios de la protección de datos Artículo 4. Calidad de los datos 1. Los datos de carácter personal sólo se podrán recoger para su tratamiento, así como someterlos a dicho tratamiento, cuando sean adecuados, pertinentes y no excesivos en relación con el ámbito y las finalidades determinadas, explícitas y legítimas para las que se hayan obtenido. 2. Los datos de carácter personal objeto de tratamiento no podrán usarse para finalidades incompatibles con aquellas para las que los datos hubieran sido recogidos. No se considerará incompatible el tratamiento posterior de éstos con fines históricos, estadísticos o científicos. 267

La protección de datos personales: Soluciones en entornos Microsoft 3. Los datos de carácter personal serán exactos y puestos al día de forma que respondan con veracidad a la situación actual del afectado. 4. Si los datos de carácter personal registrados resultaran ser inexactos, en todo o en parte, o incompletos, serán cancelados y sustituidos de oficio por los correspondientes datos rectificados o completados, sin perjuicio de las facultades que a los afectados reconoce el artículo 16. 5. Los datos de carácter personal serán cancelados cuando hayan dejado de ser necesarios o pertinentes para la finalidad para la cual hubieran sido recabados o registrados. No serán conservados en forma que permita la identificación del interesado durante un período superior al necesario para los fines en base a los cuales hubieran sido recabados o registrados. Reglamentariamente se determinará el procedimiento por el que, por excepción, atendidos los valores históricos, estadísticos o científicos de acuerdo con la legislación específica, se decida el mantenimiento íntegro de determinados datos. 6. Los datos de carácter personal serán almacenados de forma que permitan el ejercicio del derecho de acceso, salvo que sean legalmente cancelados. 7. Se prohibe la recogida de datos por medios fraudulentos, desleales o ilícitos. Artículo 5 . Derecho de información en la recogida de datos. 1. Los interesados a los que se soliciten datos personales deberán ser previamente informados de modo expreso, preciso e inequívoco: a) De la existencia de un fichero o tratamiento de datos de carácter personal, de la finalidad de la recogida de éstos y de los destinatarios de la información. b) Del carácter obligatorio o facultativo de su respuesta a las preguntas que les sean planteadas. c) De las consecuencias de la obtención de los datos o de la negativa a suministrarlos. d) De la posibilidad de ejercitar los derechos de acceso, rectificación, cancelación y oposición. e) De la identidad y dirección del responsable del tratamiento o, en su caso, de su representante. Cuando el responsable del tratamiento no esté establecido en el territorio de la Unión Europea y utilice en el tratamiento de datos medios situados en territorio español, deberá designar, salvo que tales medios se utilicen con fines de tránsito, un representante en España, sin perjuicio de las acciones que pudieran emprenderse contra el propio responsable del tratamiento. 268

Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal 2. Cuando se utilicen cuestionarios u otros impresos para la recogida, figura- rán en los mismos, en forma claramente legible, las advertencias a que se refiere el apartado anterior. 3. No será necesaria la información a que se refieren las letras b), c) y d) del apartado 1 si el contenido de ella se deduce claramente de la naturaleza de los datos personales que se solicitan o de las circunstancias en que se recaban. 4. Cuando los datos de carácter personal no hayan sido recabados del interesado, éste deberá ser informado de forma expresa, precisa e inequí- voca, por el responsable del fichero o su representante, dentro de los tres meses siguientes al momento del registro de los datos, salvo que ya hubiera sido informado con anterioridad, del contenido del tratamiento, de la procedencia de los datos, así como de lo previsto en las letras a), d) y e) del apartado 1 del presente artículo. 5. No será de aplicación lo dispuesto en el apartado anterior cuando expresamente una Ley lo prevea, cuando el tratamiento tenga fines históricos, estadísticos o científicos, o cuando la información al interesado resulte imposible o exija esfuerzos desproporcionados, a criterio de la Agencia de Protección de Datos o del organismo autonómico equivalente, en conside- ración al número de interesados, a la antigüedad de los datos y a las posibles medidas compensatorias. Asimismo, tampoco regirá lo dispuesto en el apartado anterior cuando los datos procedan de fuentes accesibles al público y se destinen a la actividad de publicidad o prospección comercial, en cuyo caso, en cada comuni- cación que se dirija al interesado se le informará del origen de los datos y de la identidad del responsable del tratamiento así como de los derechos que le asisten. Artículo 6. Consentimiento del afectado 1. El tratamiento de los datos de carácter personal requerirá el consentimien- to inequívoco del afectado, salvo que la Ley disponga otra cosa. 2. No será preciso el consentimiento cuando los datos de carácter personal se recojan para el ejercicio de las funciones propias de las Administraciones Públicas en el ámbito de sus competencias; cuando se refieran a las partes de un contrato o precontrato de una relación negocial, laboral o administrativa y sean necesarios para su mantenimiento o cumplimiento; cuando el tratamiento de los datos tenga por finalidad proteger un interés vital del interesado en los términos del artículo 7 apartado 6 de la presente Ley, o cuando los datos figuren en fuentes accesibles al público y su tratamiento sea necesario para la satisfacción del interés legítimo perseguido por el responsable del fichero o por el del tercero a quien se comuniquen los datos, siempre que no se vulneren los derechos y libertades fundamentales del interesado. 269

La protección de datos personales: Soluciones en entornos Microsoft 3. El consentimiento a que se refiere el artículo podrá ser revocado cuando exista causa justificada para ello y no se le atribuyan efectos retroactivos. 4. En los casos en los que no sea necesario el consentimiento del afectado para el tratamiento de los datos de carácter personal, y siempre que una Ley no disponga lo contrario, éste podrá oponerse a su tratamiento cuando existan motivos fundados y legítimos relativos a una concreta situación personal. En tal supuesto, el responsable del fichero excluirá del tratamiento los datos relativos al afectado. Artículo 7. Datos especialmente protegidos 1. De acuerdo con lo establecido en el apartado 2 del artículo 16 de la Consti- tución, nadie podrá ser obligado a declarar sobre su ideología, religión o creencias. Cuando en relación con estos datos se proceda a recabar el consentimiento a que se refiere el apartado siguiente, se advertirá al interesado acerca de su derecho a no prestarlo. 2. Sólo con el consentimiento expreso y por escrito del afectado podrán ser objeto de tratamiento los datos de carácter personal que revelen la ideolo- gía, afiliación sindical, religión y creencias. Se exceptúan los ficheros mantenidos por los partidos políticos, sindicatos, iglesias, confesiones o comunidades religiosas y asociaciones, fundaciones y otras entidades sin ánimo de lucro, cuya finalidad sea política, filosófica, religiosa o sindical, en cuanto a los datos relativos a sus asociados o miembros, sin perjuicio de que la cesión de dichos datos precisará siempre el previo consentimien- to del afectado. 3. Los datos de carácter personal que hagan referencia al origen racial, a la salud y a la vida sexual sólo podrán ser recabados, tratados y cedidos cuando, por razones de interés general, así lo disponga una Ley o el afectado consienta expresamente. 4. Quedan prohibidos los ficheros creados con la finalidad exclusiva de almacenar datos de carácter personal que revelen la ideología, afiliación sindical, religión, creencias, origen racial o étnico, o vida sexual. 5. Los datos de carácter personal relativos a la comisión de infracciones penales o administrativas sólo podrán ser incluidos en ficheros de las Administraciones Públicas competentes en los supuestos previstos en las respectivas normas reguladoras. 6. No obstante lo dispuesto en los apartados anteriores podrán ser objeto de tratamiento los datos de carácter personal a que se refieren los apartados 2 y 3 de este artículo, cuando dicho tratamiento resulte necesario para la prevención o para el diagnóstico médicos, la prestación de asistencia sanitaria o tratamientos médicos o la gestión de servicios sanitarios, siempre que dicho tratamiento de datos se realice por un profesional sanitario sujeto al secreto profesional o por otra persona sujeta asimismo a una obligación equivalente de secreto. 270

Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal También podrán ser objeto de tratamiento los datos a que se refiere el pá- rrafo anterior cuando el tratamiento sea necesario para salvaguardar el interés vital del afectado o de otra persona, en el supuesto de que el afectado esté física o jurídicamente incapacitado para dar su consentimiento. Artículo 8. Datos relativos a la salud Sin perjuicio de lo que se dispone en el artículo 11 respecto de la cesión, las instituciones y los centros sanitarios públicos y privados y los profesionales correspondientes podrán proceder al tratamiento de los datos de carácter personal relativos a la salud de las personas que a ellos acudan o hayan de ser tratados en los mismos, de acuerdo con lo dispuesto en la legislación estatal o autonómica sobre sanidad. Artículo 9. Seguridad de los datos 1. El responsable del fichero, y, en su caso, el encargado del tratamiento, debe- rá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. Artículo 10. Deber de secreto 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. Artículo 11. Comunicación de datos 1. Los datos de carácter personal objeto del tratamiento sólo podrán ser comunicados a un tercero para el cumplimiento de fines directamente relacionados con las funciones legítimas del cedente y del cesionario con el previo consentimiento del interesado. 2. El consentimiento exigido en el apartado anterior no será preciso: a) Cuando la cesión está autorizada en una Ley. 271

La protección de datos personales: Soluciones en entornos Microsoft b) Cuando se trate de datos recogidos de fuentes accesibles al público. c) Cuando el tratamiento responda a la libre y legítima aceptación de una relación jurídica cuyo desarrollo, cumplimiento y control implique necesariamente la conexión de dicho tratamiento con ficheros de terceros. En este caso la comunicación sólo será legítima en cuanto se limite a la finalidad que la justifique. d) Cuando la comunicación que deba efectuarse tenga por destinatario al Defensor del Pueblo, el Ministerio Fiscal o los Jueces o Tribunales o el Tribunal de Cuentas, en el ejercicio de las funciones que tiene atribuidas. Tampoco será preciso el consentimiento cuando la comu- nicación tenga como destinatario a instituciones autonómicas con funciones análogas al Defensor del Pueblo o al Tribunal de Cuentas. e) Cuando la cesión se produzca entre Administraciones Públicas y tenga por objeto el tratamiento posterior de los datos con fines históri- cos, estadísticos o científicos. f) Cuando la cesión de datos de carácter personal relativos a la salud sea necesaria para solucionar una urgencia que requiera acceder a un fichero o para realizar los estudios epidemiológicos en los términos establecidos en la legislación sobre sanidad estatal o autonómica. 3. Será nulo el consentimiento para la comunicación de los datos de carácter personal a un tercero cuando la información que se facilite al interesado no le permita conocer la finalidad a que destinarán los datos cuya comunicación se autoriza o el tipo de actividad de aquél a quien se pretenden comunicar. 4. El consentimiento para la comunicación de los datos de carácter personal tiene también un carácter de revocable. 5. Aquél a quien se comuniquen los datos de carácter personal se obliga, por el solo hecho de la comunicación, a la observancia de las disposiciones de la presente Ley. 6. Si la comunicación se efectúa previo procedimiento de disociación, no será aplicable lo establecido en los apartados anteriores. Artículo 12. Acceso a los datos por cuenta de terceros 1. No se considerará comunicación de datos el acceso de un tercero a los datos cuando dicho acceso sea necesario para la prestación de un servicio al responsable del tratamiento. 2. La realización de tratamientos por cuenta de terceros deberá estar regula- da en un contrato que deberá constar por escrito o en alguna otra forma que permita acreditar su celebración y contenido, estableciéndose expresamente que el encargado del tratamiento únicamente tratará los datos conforme a las instrucciones del responsable del tratamiento, que no los aplicará o utilizará con fin distinto al que figure en dicho contrato, ni los comunicará, ni siquiera para su conservación, a otras personas. 272

Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal En el contrato se estipularán, asimismo, las medidas de seguridad a que se refiere el artículo 9 de esta Ley que el encargado del tratamiento está obligado a implementar. 3. Una vez cumplida la prestación contractual, los datos de carácter personal deberán ser destruidos o devueltos al responsable del tratamiento, al igual que cualquier soporte o documentos en que conste algún dato de carácter personal objeto del tratamiento. 4. En el caso de que el encargado del tratamiento destine los datos a otra finalidad, los comunique o los utilice incumpliendo las estipulaciones del contrato, será considerado, también, responsable del tratamiento, respondiendo de las infracciones en que hubiera incurrido personalmente. TÍTULO III. Derechos de las personas Artículo 13. Impugnación de valoraciones 1. Los ciudadanos tienen derecho a no verse sometidos a una decisión con efectos jurídicos, sobre ellos o que les afecte de manera significativa, que se base únicamente en un tratamiento de datos destinados a evaluar determinados aspectos de su personalidad. 2. El afectado podrá impugnar los actos administrativos o decisiones privadas que impliquen una valoración de su comportamiento, cuyo único fundamento sea un tratamiento de datos de carácter personal que ofrezca una definición de sus características o personalidad. 3. En este caso, el afectado tendrá derecho a obtener información del responsable del fichero sobre los criterios de valoración y el programa utilizados en el tratamiento que sirvió para adoptar la decisión en que consistió el acto. 4. La valoración sobre el comportamiento de los ciudadanos basada en un tratamiento de datos, únicamente podrá tener valor probatorio a petición del afectado. Artículo 14. Derecho de Consulta al Registro General de Protección de Datos Cualquier persona podrá conocer, recabando a tal fin la información oportuna del Registro General de Protección de Datos, la existencia de tratamientos de datos de carácter personal, sus finalidades y la identidad del responsable del tratamiento. El Registro General será de consulta pública y gratuita. Artículo 15. Derecho de acceso 1. El interesado tendrá derecho a solicitar y obtener gratuitamente informa- ción de sus datos de carácter personal sometidos a tratamiento, el origen de dichos datos así como las comunicaciones realizadas o que se prevén hacer de los mismos. 273

La protección de datos personales: Soluciones en entornos Microsoft 2. La información podrá obtenerse mediante la mera consulta de los datos por medio de su visualización, o la indicación de los datos que son objeto de tratamiento mediante escrito, copia, telecopia o fotocopia, certificada o no, en forma legible e inteligible, sin utilizar claves o códigos que requieran el uso de dispositivos mecánicos específicos. 3. El derecho de acceso a que se refiere este artículo sólo podrá ser ejercitado a intervalos no inferiores a doce meses, salvo que el interesado acredite un interés legítimo al efecto, en cuyo caso podrá ejercitarlo antes. Artículo 16. Derecho de rectificación y cancelación 1. El responsable del tratamiento tendrá la obligación de hacer efectivo el derecho de rectificación o cancelación del interesado en el plazo de diez días. 2. Serán rectificados o cancelados, en su caso, los datos de carácter personal cuyo tratamiento no se ajuste a lo dispuesto en la presente Ley y, en particular, cuando tales datos resulten inexactos o incompletos. 3. La cancelación dará lugar al bloqueo de los datos, conservándose única- mente a disposición de las Administraciones Públicas, Jueces y Tribunales, para la atención de las posibles responsabilidades nacidas del tratamiento, durante el plazo de prescripción de éstas. Cumplido el citado plazo deberá procederse a la supresión. 4. Si los datos rectificados o cancelados hubieran sido comunicados previamente, el responsable del tratamiento deberá notificar la rectificación o cancelación efectuada a quien se hayan comunicado, en el caso de que se mantenga el tratamiento por este último, que deberá también proceder a la cancelación . 5. Los datos de carácter personal deberán ser conservados durante los plazos previstos en las disposiciones aplicables o, en su caso, en las relaciones contractuales entre la persona o entidad responsable del tratamiento y el interesado. Artículo 17. Procedimiento de oposición, acceso, rectificación o cancelación 1. Los procedimientos para ejercitar el derecho de oposición, acceso, así como los de rectificación y cancelación serán establecidos reglamentariamente. 2. No se exigirá contraprestación alguna por el ejercicio de los derechos de oposición, acceso, rectificación o cancelación. Artículo 18. Tutela de los derechos 1. Las actuaciones contrarias a lo dispuesto en la presente Ley pueden ser objeto de reclamación por los interesados ante la Agencia de Protección de Datos, en la forma que reglamentariamente se determine. 274

Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal 2. El interesado al que se deniegue, total o parcialmente, el ejercicio de los derechos de oposición, acceso, rectificación o cancelación, podrá ponerlo en conocimiento de la Agencia de Protección de Datos o, en su caso, del Organismo competente de cada Comunidad Autónoma, que deberá asegurarse de la procedencia o improcedencia de la denegación. 3. El plazo máximo en que debe dictarse la resolución expresa de tutela de derechos será de seis meses. 4. Contra las resoluciones de la Agencia de Protección de Datos procederá recurso contencioso-administrativo. Artículo 19. Derecho a indemnización 1. Los interesados que, como consecuencia del incumplimiento de lo dispuesto en la presente Ley por el responsable o el encargado del tratamien- to, sufran daño o lesión en sus bienes o derechos tendrán derecho a ser indemnizados. 2. Cuando se trate de ficheros de titularidad pública, la responsabilidad se exigirá de acuerdo con la legislación reguladora del régimen de responsabilidad de las Administraciones Públicas. 3. En el caso de los ficheros de titularidad privada, la acción se ejercitará ante los órganos de la jurisdicción ordinaria. TÍTULO IV. Disposiciones sectoriales Capítulo Primero. Fichero de titularidad pública Artículo 20. Creación, modificación o supresión 1. La creación, modificación o supresión de los ficheros de las Administracio- nes Públicas sólo podrán hacerse por medio de disposición general publicada en el “Boletín Oficial del Estado” o diario oficial correspondiente. 2. Las disposiciones de creación o de modificación de ficheros deberán indicar: a) La finalidad del fichero y los usos previstos para el mismo. b) Las personas o colectivos sobre los que se pretenda obtener datos de carácter personal o que resulten obligados a suministrarlos. c) El procedimiento de recogida de los datos de carácter personal. d) La estructura básica del fichero y la descripción de los tipos de datos de carácter personal incluidos en el mismo. e) Las cesiones de datos de carácter personal y, en su caso, las transferencias de datos que se prevean a países terceros. f) Los órganos de las Administraciones responsables del fichero. g) Los servicios o unidades ante los que pudiesen ejercitarse los derechos de acceso, rectificación, cancelación y oposición. 275

La protección de datos personales: Soluciones en entornos Microsoft h) Las medidas de seguridad con indicación del nivel básico, medio o alto exigible. 3. En las disposiciones que se dicten para la supresión de los ficheros se establecerá el destino de los mismos o, en su caso, las previsiones que se adopten para su destrucción. Artículo 21. Comunicación de datos entre Administraciones Públicas 1. Los datos de carácter personal recogidos o elaborados por las Administra- ciones Públicas para el desempeño de sus atribuciones no serán comunicados a otras Administraciones Públicas para el ejercicio de competencias diferentes o de competencias que versen sobre materias distintas, salvo cuando la comunicación tenga por objeto el tratamiento posterior de los datos con fines históricos, estadísticos o científicos. (Resultado STC 292/ 2000, de 30 de noviembre.) 2. Podrán, en todo caso, ser objeto de comunicación los datos de carácter personal que una Administración Pública obtenga o elabore con destino a otra. 3. No obstante lo establecido en el artículo 11.2 b), la comunicación de datos recogidos de fuentes accesibles al público no podrá efectuarse a ficheros de titularidad privada, sino con el consentimiento del interesado o cuando una Ley prevea otra cosa. 4. En los supuestos previstos en los apartados 1 y 2 del presente artículo no será necesario el consentimiento del afectado a que se refiere el artículo 11 de la presente Ley. Artículo 22. Ficheros de las Fuerzas y Cuerpos de Seguridad 1. Los ficheros creados por las Fuerzas y Cuerpos de Seguridad que contengan datos de carácter personal que, por haberse recogido para fines administrativos, deban ser objeto de registro permanente, estarán sujetos al régimen general de la presente Ley. 2. La recogida y tratamiento para fines policiales de datos de carácter personal por las Fuerzas y Cuerpos de Seguridad sin consentimiento de las personas afectadas están limitados a aquellos supuestos y categorías de datos que resulten necesarios para la prevención de un peligro real para la seguridad pública o para la represión de infracciones penales, debiendo ser almacenados en ficheros específicos establecidos al efecto, que deberán clasificarse por categorías en función de su grado de fiabilidad. 3. La recogida y tratamiento por las Fuerzas y Cuerpos de Seguridad de los datos a que hacen referencia los apartados 2 y 3 del artículo 7, podrán realizarse exclusivamente en los supuestos en que sea absolutamente necesario para los fines de una investigación concreta, sin perjuicio del control de legalidad de la actuación administrativa o de la obligación de resolver las pretensiones formuladas en su caso por los interesados que corresponden a los órganos jurisdiccionales. 276

Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal 4. Los datos personales registrados con fines policiales se cancelarán cuando no sean necesarios para las averiguaciones que motivaron su almacenamiento. A estos efectos, se considerará especialmente la edad del afectado y el carácter de los datos almacenados, la necesidad de mantener los datos hasta la conclusión de una investigación o procedimiento concreto, la resolución judicial firme, en especial la absolutoria, el indulto, la rehabili- tación y la prescripción de responsabilidad. Artículo 23. Excepciones a los derechos de acceso, rectificación y cancelación 1. Los responsables de los ficheros que contengan los datos a que se refieren los apartados 2, 3 y 4 del artículo anterior podrán denegar el acceso, la rectificación o cancelación en función de los peligros que pudieran derivarse para la defensa del Estado o la seguridad pública, la protección de los derechos y libertades de terceros o las necesidades de las investigacio- nes que se estén realizando. 2. Los responsables de los ficheros de la Hacienda Pública podrán, igualmente, denegar el ejercicio de los derechos a que se refiere el apartado anterior cuando el mismo obstaculice las actuaciones administrativas ten- dentes a asegurar el cumplimiento de las obligaciones tributarias y, en todo caso, cuando el afectado esté siendo objeto de actuaciones inspectoras. 3. El afectado al que se deniegue, total o parcialmente, el ejercicio de los derechos mencionados en los apartados anteriores podrá ponerlo en conocimiento del Director de la Agencia de Protección de Datos o del Organismo competente de cada Comunidad Autónoma en el caso de ficheros mantenidos por Cuerpos de Policía propios de éstas, o por las Administraciones Tributarias Autonómicas, quienes deberán asegurarse de la procedencia o improcedencia de la denegación. Artículo 24. Otras excepciones a los derechos de los afectados 1. Lo dispuesto en los apartados 1 y 2 del artículo 5 no será aplicable a la recogida de datos cuando la información al afectado impida o dificulte gravemente el cumplimiento de las funciones de control y verificación de las Administraciones Públicas o cuando afecte a la Defensa Nacional, a la seguridad pública o a la persecución de infracciones penales. (Resultado STC 292/2000, de 30 de noviembre.) CAPÍTULO II. Ficheros de titularidad privada Artículo 25. Creación Podrán crearse ficheros de titularidad privada que contengan datos de carácter personal cuando resulte necesario para el logro de la actividad u objeto legítimos de la persona, empresa o entidad titular y se respeten las garantías que esta Ley establece para la protección de las personas. 277

La protección de datos personales: Soluciones en entornos Microsoft Artículo 26. Notificación e inscripción registral 1. Toda persona o entidad que proceda a la creación de ficheros de datos de carácter personal lo notificará previamente a la Agencia de Protección de Datos. 2. Por vía reglamentaria se procederá a la regulación detallada de los distintos extremos que debe contener la notificación, entre los cuales figurarán necesariamente el responsable del fichero, la finalidad del mismo, su ubicación, el tipo de datos de carácter personal que contiene, las medidas de seguridad, con indicación del nivel básico, medio o alto exigible y las cesiones de datos de carácter personal que se prevean realizar y, en su caso, las transferencias de datos que se prevean a países terceros. 3. Deberán comunicarse a la Agencia de Protección de Datos los cambios que se produzcan en la finalidad del fichero automatizado, en su responsable y en la dirección de su ubicación. 4. El Registro General de Protección de Datos inscribirá el fichero si la notificación se ajusta a los requisitos exigibles. En caso contrario podrá pedir que se completen los datos que falten o se proceda a su subsanación. 5. Transcurrido un mes desde la presentación de la solicitud de inscripción sin que la Agencia de Protección de Datos hubiera resuelto sobre la misma, se entenderá inscrito el fichero automatizado a todos los efectos. Artículo 27. Comunicación de la cesión de datos 1. El responsable del fichero, en el momento en que se efectúe la primera cesión de datos, deberá informar de ello a los afectados, indicando, asimismo, la finalidad del fichero, la naturaleza de los datos que han sido cedidos y el nombre y dirección del cesionario. 2. La obligación establecida en el apartado anterior no existirá en el supuesto previsto en los apartados 2, letras c), d), e) y 6 del artículo 11, ni cuando la cesión venga impuesta por Ley. Artículo 28. Datos incluidos en las fuentes de acceso público 1. Los datos personales que figuren en el censo promocional o las listas de personas pertenecientes a grupos de profesionales a que se refiere el artículo 3 j) de esta Ley deberán limitarse a los que sean estrictamente necesarios para cumplir la finalidad a que se destina cada listado. La inclusión de datos adicionales por las entidades responsables del mantenimiento de dichas fuentes requerirá el consentimiento del interesado, que podrá ser revocado en cualquier momento. 2. Los interesados tendrán derecho a que la entidad responsable del mantenimiento de los listados de los Colegios profesionales indique gratuitamente que sus datos personales no pueden utilizarse para fines de publici- 278

Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal dad o prospección comercial. Los interesados tendrán derecho a exigir gratuitamente la exclusión de la totalidad de sus datos personales que consten en el censo promocional por las entidades encargadas del mantenimiento de dichas fuentes. La atención a la solicitud de exclusión de la información innecesaria o de inclusión de la objeción al uso de los datos para fines de publicidad o venta a distancia deberá realizarse en el plazo de diez días respecto de las informaciones que se realicen mediante consulta o comunicación telemática y en la siguiente edición del listado cualquiera que sea el soporte en que se edite. 3. Las fuentes de acceso público que se editen en forma de libro o algún otro soporte físico, perderán el carácter de fuente accesible con la nueva edición que se publique. En el caso de que se obtenga telemáticamente una copia de la lista en formato electrónico, ésta perderá el carácter de fuente de acceso público en el plazo de un año, contado desde el momento de su obtención. 4. Los datos que figuren en las guías de servicios de telecomunicaciones disponibles al público se regirán por su normativa específica. Artículo 29. Prestación de servicios de información sobre solvencia patrimonial y crédito 1. Quienes se dediquen a la prestación de servicios de información sobre la solvencia patrimonial y el crédito sólo podrán tratar datos de carácter personal obtenidos de los registros y las fuentes accesibles al público establecidos al efecto o procedentes de informaciones facilitadas por el interesado o con su consentimiento. 2. Podrán tratarse también datos de carácter personal relativos al cumplimiento o incumplimiento de obligaciones dinerarias facilitados por el creedor o por quien actúe por su cuenta o interés. En estos casos se notifi- cará a los interesados respecto de los que hayan registrado datos de carácter personal en ficheros, en el plazo de treinta días desde dicho registro, una referencia de los que hubiesen sido incluidos y se les infor- mará de su derecho a recabar información de la totalidad de ellos, en los términos establecidos por la presente Ley. 3. En los supuestos a que se refieren los dos apartados anteriores cuando el interesado lo solicite, el responsable del tratamiento le comunicará los datos, así como las evaluaciones y apreciaciones que sobre el mismo hayan sido comunicadas durante los últimos seis meses y el nombre y dirección de la persona o entidad a quien se hayan revelado los datos. 4. Sólo se podrán registrar y ceder los datos de carácter personal que sean determinantes para enjuiciar la solvencia económica de los interesados y que no se refieran, cuando sean adversos, a más de seis años, siempre que respondan con veracidad a la situación actual de aquellos. 279

La protección de datos personales: Soluciones en entornos Microsoft Artículo 30. Tratamientos con fines de publicidad y prospección comercial 1. Quienes se dediquen a la recopilación de direcciones, reparto de documentos, publicidad, venta a distancia, prospección comercial y otras actividades análogas, utilizarán nombres y direcciones u otros datos de carácter personal cuando los mismos figuren en fuentes accesibles al público o cuando hayan sido facilitados por los propios interesados u obtenidos con su consentimiento. 2. Cuando los datos procedan de fuentes accesibles al público, de conformidad con lo establecido en el párrafo segundo del artículo 5.5 de esta Ley, en cada comunicación que se dirija al interesado se informará del origen de los datos y de la identidad del responsable del tratamiento, así como de los derechos que le asisten. 3. En el ejercicio del derecho de acceso los interesados tendrán derecho a conocer el origen de sus datos de carácter personal, así como del resto de información a que se refiere el artículo 15. 4. Los interesados tendrán derecho a oponerse, previa petición y sin gastos, al tratamiento de los datos que les conciernan, en cuyo caso serán dados de baja del tratamiento, cancelándose las informaciones que sobre ellos figuren en aquél, a su simple solicitud. Artículo 31. Censo promocional 1. Quienes pretendan realizar permanente o esporádicamente la actividad de recopilación de direcciones, reparto de documentos, publicidad, venta a distancia, prospección comercial u otras actividades análogas, podrán solicitar del Instituto Nacional de Estadística o de los órganos equivalentes de las Comunidades Autónomas una copia del censo promocional, formado con los datos de nombre, apellidos y domicilio que constan en el censo electoral. 2. El uso de cada lista de censo promocional tendrá un plazo de vigencia de un año. Transcurrido el plazo citado, la lista perderá su carácter de fuente de acceso público. 3. Los procedimientos mediante los que los interesados podrán solicitar no aparecer en el censo promocional se regularán reglamentariamente. Entre estos procedimientos, que serán gratuitos para los interesados, se incluirá el documento de empadronamiento. Trimestralmente se editará una lista actualizada del censo promocional, excluyendo los nombres y domicilios de los que así lo hayan solicitado. 4. Se podrá exigir una contraprestación por la facilitación de la citada lista en soporte informático. Artículo 32. Códigos tipo 1. Mediante acuerdos sectoriales, convenios administrativos o decisiones de empresa, los responsables de tratamientos de titularidad pública y priva- 280

Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal da así como las organizaciones en que se agrupen, podrán formular códi- gos tipo que establezcan las condiciones de organización, régimen de funcionamiento, procedimientos aplicables, normas de seguridad del entorno, programas o equipos, obligaciones de los implicados en el tratamiento y uso de la información personal, así como las garantías, en su ámbito, para el ejercicio de los derechos de las personas con pleno respeto a los principios y disposiciones de la presente Ley y sus normas de desarrollo. 2. Los citados códigos podrán contener o no reglas operacionales detalladas de cada sistema particular y estándares técnicos de aplicación. En el supuesto de que tales reglas o estándares no se incorporen directamente al código, las instrucciones u órdenes que los establecieran deberán respetar los principios fijados en aquél. 3. Los códigos tipo tendrán el carácter de códigos deontológicos o de buena práctica profesional, debiendo ser depositados o inscritos en el Registro General de Protección de Datos y, cuando corresponda, en los creados a estos efectos por las Comunidades Autónomas, de acuerdo con el artículo 41. El Registro General de Protección de Datos podrá denegar la inscrip- ción cuando considere que no se ajusta a las disposiciones legales y reglamentarias sobre la materia, debiendo, en este caso, el Director de la Agencia de Protección de Datos requerir a los solicitantes para que efec- túen las correcciones oportunas. TÍTULO V. Movimiento internacional de datos Artículo 33. Norma general 1. No podrán realizarse transferencias temporales ni definitivas de datos de carácter personal que hayan sido objeto de tratamiento o hayan sido recogidos para someterlos a dicho tratamiento con destino a países que no proporcionen un nivel de protección equiparable al que presta la presente Ley, salvo que, además de haberse observado lo dispuesto en ésta, se obtenga autorización previa del Director de la Agencia de Protección de Datos, que sólo podrá otorgarla si se obtienen garantías adecuadas. 2. El carácter adecuado del nivel de protección que ofrece el país de destino se evaluará por la Agencia de Protección de Datos atendiendo a todas las circunstancias que concurran en la transferencia o categoría de transferencia de datos. En particular, se tomará en consideración la naturaleza de los datos de finalidad y la duración del tratamiento o de los tratamientos previstos, el país de origen y el país de destino final, las normas de Dere- cho, generales o sectoriales, vigentes en el país tercero de que se trate, el contenido de los informes de la Comisión de la Unión Europea, así como las normas profesionales y las medidas de seguridad en vigor en dichos países. 281

La protección de datos personales: Soluciones en entornos Microsoft Artículo 34. Excepciones Lo dispuesto en el artículo anterior no será de aplicación: a) Cuando la transferencia internacional de datos de carácter personal resulte de la aplicación de tratados o convenios en los que sea parte España. b) Cuando la transferencia se haga a efectos de prestar o solicitar auxilio judicial internacional. c) Cuando la transferencia sea necesaria para la prevención o para el diag- nóstico médicos, la prestación de asistencia sanitaria o tratamiento médi- cos o la gestión de servicios sanitarios. d) Cuando se refiera a transferencias dinerarias conforme a su legislación específica. e) Cuando el afectado haya dado su consentimiento inequívoco a la transferencia prevista. f) Cuando la transferencia sea necesaria para la ejecución de un contrato entre el afectado y el responsable del fichero o para la adopción de medidas precontractuales adoptadas a petición del afectado. g) Cuando la transferencia sea necesaria para la celebración o ejecución de un contrato celebrado o por celebrar, en interés del afectado, por el responsable del fichero y un tercero. h) Cuando la transferencia sea necesaria o legalmente exigida para la salvaguarda de un interés público. Tendrá esta consideración la transferencia solicitada por una Administración fiscal o aduanera para el cumplimiento de sus competencias. i) Cuando la transferencia sea precisa para el reconocimiento, ejercicio o defensa de un derecho en un proceso judicial. j) Cuando la transferencia se efectúe, a petición de persona con interés legítimo, desde un Registro Público y aquélla sea acorde con la finalidad del mismo. k) Cuando la transferencia tenga como destino un Estado miembro de la Unión Europea, o un Estado respecto del cual la Comisión de las Comuni- dades Europeas, en el ejercicio de sus competencias, haya declarado que garantiza un nivel de protección adecuado. TÍTULO VI. Agencia de Protección de Datos Artículo 35. Naturaleza y régimen jurídico 1. La Agencia de Protección de Datos es un Ente de Derecho público, con personalidad jurídica propia y plena capacidad pública y privada, que actúa con plena independencia de las Administraciones Públicas en el ejercicio de sus funciones. Se regirá por lo dispuesto en la presente Ley y en un Estatuto propio, que será aprobado por el Gobierno. 282

Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal 2. En el ejercicio de sus funciones públicas, y en defecto de lo que disponga la presente Ley y sus disposiciones de desarrollo, la Agencia de Protección de Datos actuará de conformidad con la Ley 30/1992, de 26 de noviembre, de Régimen Jurídico de las Administraciones Públicas y del Procedimien- to Administrativo Común. En sus adquisiciones patrimoniales y contrata- ción estará sujeta al Derecho privado. 3. Los puestos de trabajo de los órganos y servicios que integren la Agencia de Protección de Datos serán desempeñados por funcionarios de las Administraciones Públicas y por personal contratado al efecto, según la naturaleza de las funciones asignadas a cada puesto de trabajo. Este personal está obligado a guardar secreto de los datos de carácter personal de que conozca en el desarrollo de su función. 4. La Agencia de Protección de Datos contará, para el cumplimiento de sus fines, con los siguientes bienes y medios económicos: a) Las asignaciones que se establezcan anualmente con cargo a los Presupuestos Generales del Estado. b) Los bienes y valores que constituyan su patrimonio, así como los productos y rentas del mismo. c) Cualesquiera otros que legalmente puedan serle atribuidos. 5. La Agencia de Protección de Datos elaborará y aprobará con carácter anual el correspondiente anteproyecto de presupuesto y lo remitirá al Gobierno para que sea integrado, con la debida independencia, en los Presupuestos Generales del Estado. Artículo 36. El Director 1. El Director de la Agencia de Protección de Datos dirige la Agencia y osten- ta su representación. Será nombrado, de entre quienes componen el Con- sejo Consultivo, mediante Real Decreto, por un período de cuatro años. 2. Ejercerá sus funciones con plena independencia y objetividad, y no estará sujeto a instrucción alguna en el desempeño de aquéllas. En todo caso, el Director deberá oír al Consejo Consultivo en aquéllas propuestas que éste le realice en el ejercicio de sus funciones. 3. El Director de la Agencia de Protección de Datos sólo cesará antes de la expiración del período a que se refiere el apartado 1 a petición propia o por separación acordada por el Gobierno, previa instrucción de expediente, en el que necesariamente serán oídos los restantes miembros del Consejo Consultivo, por incumplimiento grave de sus obligaciones, incapacidad sobrevenida para el ejercicio de su función, incompatibilidad o condena por delito doloso. 4. El Director de la Agencia de Protección de Datos tendrá la consideración de alto cargo y quedará en la situación de servicios especiales si con ante- 283

La protección de datos personales: Soluciones en entornos Microsoft rioridad estuviera desempeñando una función pública. En el supuesto de que sea nombrado para el cargo algún miembro de la carrera judicial o fiscal, pasará asimismo a la situación administrativa de servicios especiales. Artículo 37. Funciones 1. Son funciones de la Agencia de Protección de Datos: a) Velar por el cumplimiento de la legislación sobre protección de datos y controlar su aplicación, en especial en lo relativo a los derechos de información, acceso, rectificación, oposición y cancelación de datos. b) Emitir las autorizaciones previstas en la Ley o en sus disposiciones reglamentarias. c) Dictar, en su caso y sin perjuicio de las competencias de otros órga- nos, las instrucciones precisas para adecuar los tratamientos a los principios de la presente Ley. d) Atender las peticiones y reclamaciones formuladas por las personas afectadas. e) Proporcionar información a las personas acerca de sus derechos en materia de tratamiento de los datos de carácter personal. f) Requerir a los responsables y los encargados de los tratamientos, previa audiencia de éstos, la adopción de las medidas necesarias para la adecuación del tratamiento de datos a las disposiciones de esta Ley y, en su caso, ordenar la cesación de los tratamientos y la cancelación de los ficheros, cuando no se ajuste a sus disposiciones. g) Ejercer la potestad sancionadora en los términos previstos por el Título VII de la presente Ley. h) Informar, con carácter preceptivo, los proyectos de disposiciones generales que desarrollen esta Ley. i) Recabar de los responsables de los ficheros cuanta ayuda e informa- ción estime necesaria para el desempeño de sus funciones. j) Velar por la publicidad de la existencia de los ficheros de datos con carácter personal, a cuyo efecto publicará periódicamente una rela- ción de dichos ficheros con la información adicional que el Director de la Agencia determine. k) Redactar una memoria anual y remitirla al Ministerio de Justicia. l) Ejercer el control y adoptar las autorizaciones que procedan en relación con los movimientos internacionales de datos, así como desempeñar las funciones de cooperación internacional en materia de protección de datos personales. m ) Velar por el cumplimiento de las disposiciones que la Ley de la Función Estadística Pública establece respecto a la recogida de datos estadísticos y al secreto estadístico, así como dictar las instrucciones 284

Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal precisas, dictaminar sobre las condiciones de seguridad de los ficheros constituidos con fines exclusivamente estadísticos y ejercer la potestad a la que se refiere el artículo 46. n) Cuantas otras le sean atribuidas por normas legales o reglamentarias. 2. Las resoluciones de la Agencia de Protección de Datos se harán públicas, una vez hayan sido notificadas a los interesados. La publicación se realiza- rá preferentemente a través de medios informáticos o telemáticos. Reglamentariamente podrán establecerse los términos en que se lleve a cabo la publicidad de las citadas resoluciones. Lo establecido en los párrafos anteriores no será aplicable a las resoluciones referentes a la inscripción de un fichero o tratamien- to en el Registro General de Protección de Datos ni a aquéllas por las que se resuelva la inscripción en el mismo de los Códigos tipo, regulados por el artículo 32 de esta Ley Orgánica. (Artículo 82.1 Ley 62/2003, de 30 de diciembre.) Artículo 38. Consejo Consultivo El Director de la Agencia de Protección de Datos estará asesorado por un Consejo Consultivo compuesto por los siguientes miembros:  Un Diputado, propuesto por el Congreso de los Diputados.  Un Senador, propuesto por el Senado.  Un representante de la Administración Central, designado por el Gobierno.  Un representante de la Administración Local, propuesto por la Federación Española de Municipios y Provincias.  Un miembro de la Real Academia de la Historia, propuesto por la misma.  Un experto en la materia, propuesto por el Consejo Superior de Universidades.  Un representante de los usuarios y consumidores, seleccionado del modo que se prevea reglamentariamente.  Un representante de cada Comunidad Autónoma que haya creado una Agencia de Protección de Datos en su ámbito territorial, propuesto de acuerdo con el procedimiento que establezca la respectiva Comunidad Autónoma.  Un representante del sector de ficheros privados, para cuya propuesta se seguirá el procedimiento que se regule reglamentariamente. El funcionamiento del Consejo Consultivo se regirá por las normas reglamentarias que al efecto se establezcan. Artículo 39. El Registro General de Protección de Datos 1. El Registro General de Protección de Datos es un órgano integrado en la Agencia de Protección de Datos. 285

La protección de datos personales: Soluciones en entornos Microsoft 2. Serán objeto de inscripción en el Registro General de Protección de Datos a) Los ficheros de que sean titulares las Administraciones Públicas. b) Los ficheros de titularidad privada. c) Las autorizaciones a que se refiere la presente Ley. d) Los códigos tipo a que se refiere el artículo 32 de la presente Ley. e) Los datos relativos a los ficheros que sean necesarios para el ejercicio de los derechos de información, acceso, rectificación, cancelación y oposición. 3. Por vía reglamentaria se regulará el procedimiento de inscripción de los ficheros, tanto de titularidad pública como de titularidad privada, en el Registro General de Protección de Datos, el contenido de la inscripción , su modificación, cancelación, reclamaciones y recursos contra las resoluciones correspondientes y demás extremos pertinentes. Artículo 40. Potestad de inspección 1. Las autoridades de control podrán inspeccionar los ficheros a que hace referencia la presente Ley, recabando cuantas informaciones precisen para el cumplimiento de sus cometidos. A tal efecto, podrán solicitar la exhibi- ción o el envío de documentos y datos y examinarlos en el lugar en que se encuentren depositados, así como inspeccionar los equipos físicos y lógicos utilizados para el tratamiento de los datos, accediendo a los locales donde se hallen instalados. 2. Los funcionarios que ejerzan la inspección a que se refiere el apartado anterior tendrán la consideración de autoridad pública en el desempeño de sus cometidos. Estarán obligados a guardar secreto sobre las informaciones que conozcan en el ejercicio de las mencionadas funciones, incluso después de haber cesado en las mismas. Artículo 41. Órganos correspondientes de las Comunidades Autónomas 1. Las funciones de la Agencia de Protección de Datos reguladas en el artículo 37, a excepción de las mencionadas en los apartados j), k) y l), y en los apartados f) y g) en lo que se refiere a las transferencias internacionales de datos, así como en los artículos 46 y 49, en relación con sus específicas competencias serán ejercidas, cuando afecten a ficheros de datos de carácter personal creados o gestionados por las Comunidades Autónomas y por la Administración local de su ámbito territorial, por los órganos correspondientes de cada Comunidad, que tendrán la consideración de autoridades de control, a los que garantizarán plena independencia y objetividad en el ejercicio de su cometido. 2. Las Comunidades Autónomas podrán crear y mantener sus propios registros de ficheros para el ejercicio de las competencias que se les reconoce sobre los mismos. 286

Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal 3. El Director de la Agencia de Protección de Datos podrá convocar regular- mente a los órganos correspondientes de las Comunidades Autónomas a efectos de cooperación institucional y coordinación de criterios o procedimientos de actuación. El Director de la Agencia de Protección de Datos y los órganos correspondientes de las Comunidades Autónomas podrán solicitarse mutuamente la información necesaria para el cumplimiento de sus funciones. Artículo 42. Ficheros de las Comunidades Autónomas en materia de su exclusiva competencia 1. Cuando el Director de la Agencia de Protección de Datos constate que el mantenimiento o uso de un determinado fichero de las Comunidades Autónomas contraviene algún precepto de esta Ley en materia de su exclusiva competencia podrá requerir a la Administración correspondiente que se adopten las medidas correctoras que determine en el plazo que expresamente se fije en el requerimiento. 2. Si la Administración Pública correspondiente no cumpliera el requerimiento formulado, el Director de la Agencia de Protección de Datos podrá impugnar la resolución adoptada por aquella Administración. TÍTULO VII. Infracciones y sanciones Artículo 43. Responsables 1. Los responsables de los ficheros y los encargados de los tratamientos estarán sujetos al régimen sancionador establecido en la presente Ley. 2. Cuando se trate de ficheros de los que sean responsables las Administra- ciones Públicas se estará, en cuanto al procedimiento y a las sanciones, a lo dispuesto en el artículo 46, apartado 2. Artículo 44. Tipos de infracciones 1. Las infracciones se calificarán como leves, graves o muy graves. 2. Son infracciones leves: a) No atender, por motivos formales, la solicitud del interesado de rectificación o cancelación de los datos personales objeto de tratamiento cuando legalmente proceda. b) No proporcionar la información que solicite la Agencia de Protección de Datos en el ejercicio de las competencias que tiene legalmente atribuidas, en relación con aspectos no sustantivos de la protección de datos. c) No solicitar la inscripción del fichero de datos de carácter personal en el Registro General de Protección de Datos, cuando no sea constitutivo de infracción grave. 287

La protección de datos personales: Soluciones en entornos Microsoft d) Proceder a la recogida de datos de carácter personal de los propios afectados sin proporcionarles la información que señala el artículo 5 de la presente Ley. e) Incumplir el deber de secreto establecido en el artículo 10 de esta Ley, salvo que constituya infracción grave. 3. Son infracciones graves: a) Proceder a la creación de ficheros de titularidad pública o iniciar la recogida de datos de carácter personal para los mismos, sin autoriza- ción de disposición general, publicada en el “Boletín Oficial del Estado” o diario oficial correspondiente. b) Proceder a la creación de ficheros de titularidad privada o iniciar la recogida de datos de carácter personal para los mismos con finalidades distintas de las que constituyen el objeto legítimo de la empresa o entidad. c) Proceder a la recogida de datos de carácter personal sin recabar el consentimiento expreso de las personas afectadas, en los casos en que éste sea exigible. d) Tratar los datos de carácter personal o usarlos posteriormente con conculcación de los principios y garantías establecidos en la presente Ley o con incumplimiento de los preceptos de protección que impongan las disposiciones reglamentarias de desarrollo, cuando no constituya infracción muy grave. e) El impedimento o la obstaculización del ejercicio de los derechos de acceso y oposición y la negativa a facilitar la información que sea solicitada. f) Mantener datos de carácter personal inexactos o no efectuar las rectificaciones o cancelaciones de los mismos que legalmente procedan cuando resulten afectados los derechos de las personas que la presente Ley ampara. g) La vulneración del deber de guardar secreto sobre los datos de carácter personal incorporados a ficheros que contengan datos relativos a la comisión de infracciones administrativas o penales, Hacienda Pública, servicios financieros, prestación de servicios de solvencia patrimonial y crédito, así como aquellos otros ficheros que contengan un conjunto de datos de carácter personal suficientes para obtener una evaluación de la personalidad del individuo. h) 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. i) No remitir a la Agencia de Protección de Datos las notificaciones previstas en esta Ley o en sus disposiciones de desarrollo, así como no proporcionar en plazo a la misma cuantos documentos e informaciones deba recibir o sean requeridos por aquél a tales efectos. 288

Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal j) La obstrucción al ejercicio de la función inspectora. k) No inscribir el fichero de datos de carácter personal en el Registro General de Protección de Datos, cuando haya sido requerido para ello por el Director de la Agencia de Protección de Datos. l) Incumplir el deber de información que se establece en los artículos 5, 28 y 29 de esta Ley, cuando los datos hayan sido recabados de persona distinta del afectado. 4. Son infracciones muy graves: a) La recogida de datos en forma engañosa y fraudulenta. b) La comunicación o cesión de los datos de carácter personal, fuera de los casos en que estén permitidas. c) Recabar y tratar los datos de carácter personal a los que se refiere el apartado 2 del artículo 7 cuando no medie el consentimiento expreso del afectado; recabar y tratar los datos referidos en el apartado 3 del artículo 7 cuando no lo disponga una Ley o el afectado no haya consentido expresamente, o violentar la prohibición contenida en el apartado 4 del artículo 7. d) No cesar en el uso ilegítimo de los tratamientos de datos de carácter personal cuando sea requerido para ello por el Director de la Agencia de Protección de Datos o por las personas titulares del derecho de acceso. e) La transferencia temporal o definitiva de datos de carácter personal que hayan sido objeto de tratamiento o hayan sido recogidos para someterlos a dicho tratamiento, con destino a países que no proporcionen un nivel de protección equiparable sin autorización del Direc- tor de la Agencia de Protección de Datos. f) Tratar los datos de carácter personal de forma ilegítima o con menosprecio de los principios y garantías que les sean de aplicación, cuando con ello se impida o se atente contra el ejercicio de los derechos fundamentales. g) La vulneración del deber de guardar secreto sobre los datos de carácter personal a que hacen referencia los apartados 2 y 3 del artículo 7, así como los que hayan sido recabados para fines policiales sin consentimiento de las personas afectadas. h) No atender, u obstaculizar de forma sistemática el ejercicio de los derechos de acceso, rectificación, cancelación u oposición. i) No atender de forma sistemática el deber legal de notificación de la inclusión de datos de carácter personal en un fichero. Artículo 45. Tipo de sanciones 1. Las infracciones leves serán sancionadas con multa de 100.000 a 10.000.000 de pesetas. 289

La protección de datos personales: Soluciones en entornos Microsoft 2. Las infracciones graves serán sancionadas con multa de 10.000.000 a 50.000.000 de pesetas. 3. Las infracciones muy graves serán sancionadas con multa de 50.000.000 a 100.000.000 de pesetas. 4. La cuantía de las sanciones se graduará atendiendo a la naturaleza de los derechos personales afectados, al volumen de los tratamientos efectuados, a los beneficios obtenidos, al grado de intencionalidad, a la reincidencia, a los daños y perjuicios causados a las personas interesadas y a terceras personas, y a cualquier otra circunstancia que sea relevante para determinar el grado de antijuridicidad y de culpabilidad presentes en la concreta actuación infractora. 5. Si, en razón de las circunstancias concurrentes, se apreciara una cualificada disminución de la culpabilidad del imputado o de la antijuridicidad del hecho, el órgano sancionador establecerá la cuantía de la sanción aplicando la escala relativa a la clase de infracciones que preceda inmediantamente en gravedad a aquella en que se integra la considerada en el caso de que se trate. 6. En ningún caso podrá imponerse una sanción más grave que la fijada en la Ley para la clase de infracción en la que se integre la que se pretenda sancionar. 7. El Gobierno actualizará periódicamente la cuantía de las sanciones de acuerdo con las variaciones que experimenten los índices de precios. Artículo 46. Infracciones de las Administraciones Públicas 1. Cuando las infracciones a que se refiere el artículo 44 fuesen cometidas en ficheros de los que sean responsables las Administraciones Públicas, el Director de la Agencia de Protección de Datos 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 Director de la Agencia 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 a la Agencia las resoluciones que recaigan en relación con las medidas y actuaciones a que se refieren los apartados anteriores. 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. 290

Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal Artículo 47. Prescripción 1. Las infracciones muy graves prescribirán a los tres años, las graves a los dos años y las leves al año. 2. El plazo de prescripción comenzará a contarse desde el día en que la infracción se hubiera cometido. 3. Interrumpirá la prescripción la iniciación, con conocimiento del interesado, del procedimiento sancionador, reanudándose el plazo de prescripción si el expediente sancionador estuviere paralizado durante más de seis meses por causas no imputables al presunto infractor. 4. Las sanciones impuestas por faltas muy graves prescribirán a los tres años, las impuestas por faltas graves a los dos años y las impuestas por faltas leves al año. 5. El plazo de prescripción de las sanciones comenzará a contarse desde el día siguiente a aquel en que adquiera firmeza la resolución por la que se impone la sanción. 6. La prescripción se interrumpirá por la iniciación, con conocimiento del interesado, del procedimiento de ejecución, volviendo a transcurrir el plazo si el mismo está paralizado durante más de seis meses por causa no imputable al infractor. Artículo 48. Procedimiento sancionador 1. Por vía reglamentaria se establecerá el procedimiento a seguir para la determinación de las infracciones y la imposición de las sanciones a que hace referencia el presente Título. 2. Las resoluciones de la Agencia de Protección de Datos u órgano correspondiente de la Comunidad Autónoma agotan la vía administrativa. 3. Los procedimientos sancionadores tramitados por la Agencia de Protec- ción de Datos, en ejercicio de las potestades que a la misma atribuyan esta u otras Leyes, salvo los referidos a infracciones de la Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones, tendrán una duración máxi- ma de seis meses. (Artículo 82.2 Ley 62/2003, de 30 de diciembre.) Artículo 49. Potestad de inmovilización de ficheros En los supuestos, constitutivos de infracción muy grave, de utilización o cesión ilícita de los datos de carácter personal en que se impida gravemente o se atente de igual modo contra el ejercicio de los derechos de los ciudadanos y el libre desarrollo de la personalidad que la Constitución y las leyes garantizan, el Director de la Agencia de Protección de Datos podrá, además de ejercer la potestad sancionadora, requerir a los responsables de ficheros de datos de carácter personal, tanto de titularidad pública como privada, la cesación en la utilización o cesión ilícita de los datos. Si el requerimiento fuera desatendido, la Agencia de Protección de Datos 291

La protección de datos personales: Soluciones en entornos Microsoft podrá, mediante resolución motivada, inmovilizar tales ficheros a los solos efectos de restaurar los derechos de las personas afectadas. Disposiciones adicionales Primera. Ficheros preexistentes Los ficheros y tratamientos automatizados, inscritos o no en el Registro Gene- ral de Protección de Datos deberán adecuarse a la presente Ley Orgánica dentro del plazo de tres años, a contar desde su entrada en vigor. En dicho plazo, los ficheros de titularidad privada deberán ser comunicados a la Agencia de Protección de Datos y las Administraciones Públicas, responsables de ficheros de titularidad pública, deberán aprobar la pertinente disposición de regulación del fichero o adaptar la existente. En el supuesto de ficheros y tratamientos no automatizados, su adecuación a la presente Ley Orgánica y la obligación prevista en el párrafo anterior deberá cumplimentarse en el plazo de doce años a contar desde el 24 de octubre de 1995, sin perjuicio del ejercicio de los derechos de acceso, rectificación y cancelación por parte de los afectados. Segunda. Ficheros y Registro de Población de las Administraciones Públicas. 1. La Administración General del Estado y las Administraciones de las Co- munidades Autónomas podrán solicitar al Instituto Nacional de Estadísti- ca, sin consentimiento del interesado, una copia actualizada del fichero formado con los datos del nombre, apellidos, domicilio, sexo y fecha de nacimiento que constan en los padrones municipales de habitantes y en el censo electoral correspondientes a los territorios donde ejerzan sus competencias, para la creación de ficheros o registros de población. 2. Los ficheros o registros de población tendrán como finalidad la comunica- ción de los distintos órganos de cada administración pública con los interesados residentes en los respectivos territorios, respecto a las relaciones jurídico administrativas derivadas de las competencias respectivas de las Administraciones Públicas. Tercera. Tratamiento de los expedientes de las derogadas Leyes de Vagos y Maleantes y de Peligrosidad y Rehabilitación Social. Los expedientes específicamente instruidos al amparo de las derogadas Leyes de Vagos y Maleantes, y de Peligrosidad y Rehabilitación Social, que contengan datos de cualquier índole susceptibles de afectar a la seguridad, al honor, a la intimidad o a la imagen de las personas, no podrán ser consultados sin que medie consentimiento expreso de los afectados, o hayan transcurrido 50 años desde la fecha de aquéllos. En este último supuesto, la Administración General del Estado, salvo que haya constancia expresa del fallecimiento de los afectados, pondrá a disposición del solicitante la documentación, suprimiendo de la misma los datos 292

Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal aludidos en el párrafo anterior, mediante la utilización de los procedimientos técnicos pertinentes en cada caso. Cuarta. Modificación del artículo 112.4 de la Ley General Tributaria. El apartado cuarto del artículo 112 de la Ley General Tributaria pasa a tener la siguiente redacción: 4. La cesión de aquellos datos de carácter personal, objeto de tratamiento que se debe efectuar a la Administración tributaria conforme a lo dispues- to en el artículo 111, en los apartados anteriores de este artículo o en otra norma de rango legal, no requerirá el consentimiento del afectado. En este ámbito tampoco será de aplicación lo que respecto a las Administraciones Públicas establece el apartado 1 del artículo 21 de la Ley Orgánica de Protección de Datos de carácter personal. Quinta . Competencias del Defensor del Pueblo y órganos autonómicos semejantes. Lo dispuesto en la presente Ley Orgánica se entiende sin perjuicio de las competencias del Defensor del Pueblo y de los órganos análogos de las Comunida- des Autónomas. Sexta. Modificación del artículo 24.3 de la Ley de Ordenación y Supervisión de los Seguros Privados. Se modifica el artículo 24.3, párrafo 2º de la Ley 30/1995, de 8 de noviembre, de Ordenación y Supervisión de los Seguros Privados con la siguiente redacción: “Las entidades aseguradoras podrán establecer ficheros comunes que contengan datos de carácter personal para la liquidación de siniestros y la colaboración estadístico actuarial con la finalidad de permitir la tarificación y selección de riesgos y la elabora- ción de estudios de técnica aseguradora. La cesión de datos a los citados ficheros no requerirá el consentimiento previo del afectado, pero sí la comunicación al mismo de la posible cesión de sus datos personales a ficheros comunes para los fines señalados con expresa indicación del responsable para que se puedan ejercitar los derechos de acceso, rectificación y cancelación previstos en la Ley. También podrán establecerse ficheros comunes cuya finalidad sea prevenir el fraude en el seguro sin que sea necesario el consentimiento del afectado. No obstante, será necesaria en estos casos la comunica- ción al afectado, en la primera introducción de sus datos, de quién sea el responsable del fichero y de las formas de ejercicio de los derechos de acceso, rectificación y cancela- ción. En todo caso, los datos relativos a la salud sólo podrán ser objeto de tratamiento con el consentimiento expreso del afectado”. Disposiciones transitorias Primera. Tratamientos creados por Convenios Internacionales. La Agencia de Protección de Datos será el organismo competente para la protección de las personas físicas en lo que respecta al tratamiento de datos de 293

La protección de datos personales: Soluciones en entornos Microsoft carácter personal respecto de los tratamientos establecidos en cualquier Convenio Internacional del que sea parte España que atribuya a una autoridad nacional de control esta competencia, mientras no se cree una autoridad diferente para este cometido en desarrollo del Convenio. Segunda. Utilización del Censo Promocional. Reglamentariamente se desarrollarán los procedimientos de formación del Censo Promocional, de oposición a aparecer en el mismo, de puesta a disposición de sus solicitantes, y de control de las listas difundidas. El Reglamento establecerá los plazos para la puesta en operación del Censo Promocional. Tercera. Subsistencia de normas preexistentes. Hasta tanto se lleven a efecto las previsiones de la Disposición Final Primera de esta Ley, continuarán en vigor, con su propio rango, las normas reglamentarias existentes y, en especial, los Reales Decretos 428/1993, de 26 de marzo, 1332/1994, de 20 de junio y 994/1999, de 11 de junio, en cuanto no se opongan a la presente Ley. Disposición derogatoria Única Queda derogada la Ley Orgánica 5/1992, de 29 de octubre, de regulación del tratamiento automatizado de los datos de carácter personal. Disposiciones finales Primera. Habilitación para el desarrollo reglamentario. El Gobierno aprobará, o modificará, las disposiciones reglamentarias necesarias para la aplicación y desarrollo de la presente Ley. Segunda. Preceptos con carácter de Ley Ordinaria. Los títulos IV, VI excepto el último inciso del párrafo 4 del artículo 36 y VII de la presente Ley, la Disposición Adicional Cuarta, la Disposición Transitoria Primera y la Final Primera, tienen el carácter de Ley Ordinaria. Tercera. Entrada en vigor. La presente Ley entrará en vigor en el plazo de un mes, contado desde su publicación en el Boletín Oficial del Estado. Palacio del Congreso de los Diputados, a 25 de noviembre de 1999. Federico Trillo-Figueroa Martínez-Conde PRESIDENTE DEL CONGRESO DE LOS DIPUTADOS 294

B Real decreto por el que se aprueba el reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal B.O.E. número 17 19 de enero de 2008 CAPÍTULO VI. Publicidad del registro Artículo 53. Publicidad formal. 1. El Registro es público. 2. La publicidad se hará efectiva por certificación del contenido de los asientos expedida por el Encargado del Registro, por nota simple informativa o por copia de los asientos y de los documentos depositados en el Registro preferentemente por medios telemáticos. En todo caso, la publicidad formal se ajustará a los requisitos establecidos en la normativa vigente en materia de protección de datos de carácter personal y en la específica sobre acceso a registros administrativos. 3. La información obtenida del Registro no podrá tratarse para fines que resulten incompatibles con el principio de publicidad formal que justificó 295

La protección de datos personales: Soluciones en entornos Microsoft su obtención. El Encargado del Registro velará por el cumplimiento de las normas vigentes en las solicitudes de publicidad en masa o que afecten a los datos personales reseñados en los asientos. Artículo 54. Certificaciones. 1. Corresponderá exclusivamente al Encargado del Registro la facultad de certificar los asientos del Registro y de los documentos archivados o depositados en el mismo. 2. Las certificaciones constituyen el único medio de acreditar fehacientemente el contenido de los asientos del Registro. En ningún caso podrán expedirse certificaciones sobre datos de fundaciones inscritas en otros registros de fundaciones. 3. Las certificaciones podrán solicitarse por cualquier medio que permita la constancia de la solicitud realizada y la identidad del solicitante. 4. Las certificaciones, debidamente firmadas por el Encargado del Registro, se expedirán en el plazo de cinco días contados desde la fecha en que se presente su solicitud. Artículo 55. Clases de certificación y de nota. Tanto la certificación como la nota podrán ser literales o en extracto, y referirse a todos los asientos relativos a una fundación o sólo a alguno o algunos de ellos. Podrán expedirse en formato electrónico. Las notas se expedirán en el plazo de tres días desde su solicitud. CAPÍTULO VII. Principio de colaboración Artículo 56. Colaboración entre el Registro y los registros autonómicos. 1. Las relaciones entre el Registro y los registros de fundaciones de las comunidades autónomas se regirán por el principio de lealtad institucional. En consecuencia, ambos registros deberán: a) Facilitar a los otros registros de fundaciones cuantos datos, documentos o medios probatorios se hallen a su disposición y se precisen para el ejercicio de sus propias competencias. b) Prestar la cooperación y asistencia activas que los otros registros pudieran recabar para el eficaz ejercicio de sus competencias. 2. Los intercambios de documentación y datos entre los registros de fundaciones deberán realizarse por medios telemáticos. A estos efectos, la Comisión de Cooperación e Información Registral establecerá las condiciones generales, requisitos y características técnicas de las comunicaciones y de los distintos documentos. 296

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal Artículo 57. Flujos de información entre registros en materia de denominaciones. A efectos de dar cumplimiento a lo dispuesto en el capítulo V de este Regla- mento, se asegurará el flujo de información entre los registros de las comunidades autónomas y el Registro y entre éste y aquéllos, en relación con denominaciones utilizadas o meramente reservadas por las fundaciones inscritas en dichos registros. Artículo 58. Colaboración con los Protectorados. 1. El Registro comunicará de oficio al Protectorado todas las inscripciones de cada fundación, cuando se trate de actos que requieran la previa interven- ción de aquél. 2. Siempre que sea conveniente, el Registro podrá solicitar información a los protectorados ministeriales y a los protectorados de las comunidades autónomas. 3. Se establecerán los procedimientos por los que los Protectorados puedan tener acceso a la publicidad del Registro. Articulo 59. Colaboración con el Consejo Superior de Fundaciones. 1. El Registro y los departamentos que ejerzan los protectorados de las fundaciones facilitarán al Consejo Superior de Fundaciones cuanta docu- mentación e información relativa a éstas sea necesaria para el debido ejercicio de sus funciones. 2. El Registro podrá solicitar informe al Consejo Superior de Fundaciones. La consulta versará sobre aquellos aspectos relacionados con las funciones que el Registro tiene normativamente atribuidas. 979 REAL DECRETO 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal. La actual Ley Orgánica 15/1999, de 13 de diciembre de Protección de datos de carácter personal adaptó nuestro ordenamiento a lo dispuesto por la Directiva 95/ 46/CE del Parlamento Europeo y del Consejo de 24 de octubre de 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, derogando a su vez la hasta entonces vigente Ley Orgánica 5/1992, de 29 de octubre, de Regulación del tratamiento automatizado de datos de carácter personal. La nueva ley, que ha nacido con una amplia vocación de generalidad, prevé en su artículo 1 que «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». Comprende por tanto el tratamiento automatizado y el no automatizado de los datos de carácter personal. 297

La protección de datos personales: Soluciones en entornos Microsoft A fin de garantizar la necesaria seguridad jurídica en un ámbito tan sensible para los derechos fundamentales como el de la protección de datos, el legislador declaró subsistentes las normas reglamentarias existentes y, en especial, los reales decretos 428/1993, de 26 de marzo, por el que se aprueba el Estatuto de la Agencia de Protección de Datos, 1332/1994, de 20 de junio, por el que se desarrollan determinados aspectos de la Ley Orgánica 5/1992, de 29 de octubre de Regulación del tratamiento automatizado de los datos de carácter personal y 994/1999, de 11 de junio, por el que se aprueba el Reglamento de Medidas de seguridad de los ficheros automatizados que contengan datos de carácter personal, a la vez que habilitó al Gobierno para la aprobación o modificación de las disposiciones reglamentarias necesarias para la aplicación y desarrollo de la Ley Orgánica 15/1999. Por otra parte, la Ley 34/2002, de 11 de julio, de Servicios de la sociedad de la información y de comercio electrónico y la Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones atribuyen competencias en materia sancionadora a la Agencia Española de Protección de Datos. Éstas requieren de desarrollo reglamentario con la peculiaridad de que ambas normas se ordenan a la tutela no sólo de los derechos de las personas físicas, sino también de las jurídicas. II Este Reglamento comparte con la Ley Orgánica la finalidad de hacer frente a los riesgos que para los derechos de la personalidad pueden suponer el acopio y tratamiento de datos personales. Por ello, ha de destacarse que esta norma reglamentaria nace con la vocación de no reiterar los contenidos de la norma superior y de desarrollar, no sólo los mandatos contenidos en la Ley Orgánica de acuerdo con los principios que emanan de la Directiva, sino también aquellos que en estos años de vigencia de la Ley se ha demostrado que precisan de un mayor desarrollo normativo. Por tanto, se aprueba este Reglamento partiendo de la necesidad de dotar de coherencia a la regulación reglamentaria en todo lo relacionado con la transposición de la Directiva y de desarrollar los aspectos novedosos de la Ley Orgánica 15/1999, junto con aquellos en los que la experiencia ha aconsejado un cierto de grado de precisión que dote de seguridad jurídica al sistema. III El reglamento viene a abarcar el ámbito tutelado anteriormente por los reales decretos 1332/1994, de 20 de junio, y 994/1999, de 11 de junio, teniendo en cuenta la necesidad de fijar criterios aplicables a los ficheros y tratamientos de datos personales no automatizados. Por otra parte, la atribución de funciones a la Agencia Española de Protección de Datos por la Ley 34/2002, de 11 de julio, de Servicios de la sociedad de la información y de comercio electrónico y la Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones obliga a desarrollar también los procedimientos para el ejercicio de la potestad sancionadora por la Agencia. El reglamento se estructura en nueve títulos cuyo contenido desarrolla los aspectos esenciales en esta materia. 298

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal El título I contempla el objeto y ámbito de aplicación del reglamento. A lo largo de la vigencia de la Ley Orgánica 15/1999, se ha advertido la conveniencia de desarrollar el apartado 2 de su artículo 2 para aclarar qué se entiende por ficheros y tratamientos relacionados con actividades personales o domésticas, aspecto muy relevante dado que están excluidos de la normativa sobre protección de datos de carácter personal. Por otra parte, el presente reglamento no contiene previsiones para los tratamientos de datos personales a los que se refiere el apartado 3 del artículo 2 de la ley orgánica, dado que se rigen por sus disposiciones específicas y por lo especialmente previsto, en su caso, por la propia Ley Orgánica 15/1999. En consecuencia, se mantiene el régimen jurídico propio de estos tratamientos y ficheros. Además, en este título se aporta un conjunto de definiciones que ayudan al correcto entendimiento de la norma, lo que resulta particularmente necesario en un ámbito tan tecnificado como el de la protección de datos personales. Por otra parte, fija el criterio a seguir en materia de cómputo de plazos con el fin de homogeneizar esta cuestión evitando distinciones que suponen diferencias de trato de los ficheros públicos respecto de los privados. El título II, se refiere a los principios de la protección de datos. Reviste particular importancia la regulación del modo de captación del consentimiento atendiendo a aspectos muy específicos como el caso de los servicios de comunicaciones electró- nicas y, muy particularmente, la captación de datos de los menores. Asimismo, se ofrece lo que no puede definirse sino como un estatuto del encargado del tratamien- to, que sin duda contribuirá a clarificar todo lo relacionado con esta figura. Las previsiones en este ámbito se completan con lo dispuesto en el título VIII en materia de seguridad dotando de un marco coherente a la actuación del encargado. El título III se ocupa de una cuestión tan esencial como los derechos de las personas en este ámbito. Estos derechos de acceso, rectificación, cancelación y oposición al tratamiento, según ha afirmado el Tribunal Constitucional en su sentencia número 292/2000, constituyen el haz de facultades que emanan del derecho fundamental a la protección de datos y “sirven a la capital función que desempeña este derecho fundamental: garantizar a la persona un poder de control sobre sus datos personales, lo que sólo es posible y efectivo imponiendo a terceros los mencionados deberes de hacer”. A continuación, los títulos IV a VII permiten clarificar aspectos importantes para el tráfico ordinario, como la aplicación de criterios específicos a determinado tipo de ficheros de titularidad privada que por su trascendencia lo requerían –los relativos a la solvencia patrimonial y crédito y los utilizados en actividades de publicidad y prospección comercial–, el conjunto de obligaciones materiales y formales que deben conducir a los responsables a la creación e inscripción de los ficheros, los criterios y procedimientos para la realización de las transferencias internacionales de datos, y, finalmente, la regulación de un instrumento, el código tipo, llamado a jugar cada vez un papel más relevante como elemento dinamizador del derecho fundamental a la protección de datos. 299

La protección de datos personales: Soluciones en entornos Microsoft El título VIII regula un aspecto esencial para la tutela del derecho fundamental a la protección de datos, la seguridad, que repercute sobre múltiples aspectos organizativos, de gestión y aún de inversión, en todas las organizaciones que traten datos personales. La repercusión del deber de seguridad obligaba a un particular rigor ya que en esta materia han confluido distintos elementos muy relevantes. Por una parte, la experiencia dimanante de la aplicación del Real Decreto 994/1999 permitía conocer las dificultades que habían enfrentado los responsables e identificar los puntos débiles y fuertes de la regulación. Por otra, se reclamaba la adapta- ción de la regulación en distintos aspectos. En este sentido, el reglamento trata de ser particularmente riguroso en la atribución de los niveles de seguridad, en la fijación de las medidas que corresponda adoptar en cada caso y en la revisión de las mismas cuando ello resulte necesario. Por otra parte, ordena con mayor precisión el contenido y las obligaciones vinculadas al mantenimiento del documento de seguridad. Además, se ha pretendido regular la materia de modo que contemple las múltiples formas de organización material y personal de la seguridad que se dan en la práctica. Por último, se regula un conjunto de medidas destinadas a los ficheros y tratamientos estructurados y no automatizados que ofrezca a los responsables un marco claro de actuación. Finalmente en el título IX, dedicado a los procedimientos tramitados por la Agencia Española de Protección de Datos, se ha optado por normar exclusivamente aquellas especialidades que diferencian a los distintos procedimientos tramitados por la Agencia de las normas generales previstas para los procedimientos en la Ley 30/1992, de 26 de noviembre, de Régimen Jurídico de las Administraciones Públi- cas y del Procedimiento Administrativo Común, cuya aplicación se declara supletoria al presente reglamento. En su virtud, a propuesta del Ministro de Justicia, con la aprobación previa de la Ministra de Administraciones Públicas, de acuerdo con el Consejo de Estado y previa deliberación del Consejo de Ministros en su reunión del día 21 de diciembre de 2007. DISPONGO: Artículo único. Aprobación del reglamento. Se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de datos de carácter personal, cuyo texto se incluye a continuación. Disposición transitoria primera. Adaptación de los códigos tipo inscritos en el Registro General de Protección de Datos. En el plazo de un año desde la entrada en vigor del presente real decreto deberán notificarse a la Agencia Española de Protección de Datos las modificaciones que resulten necesarias en los códigos tipo inscritos en el Registro General de Protección de Datos para adaptar su contenido a lo dispuesto en el título VII del mismo. 300

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal Disposición transitoria segunda. Plazos de implantación de las medidas de seguridad. La implantación de las medidas de seguridad previstas en el presente real decreto deberá producirse con arreglo a las siguientes reglas: 1.ª Respecto de los ficheros automatizados que existieran en la fecha de entrada en vigor del presente real decreto: a) En el plazo de un año desde su entrada en vigor, deberán implantarse las medidas de seguridad de nivel medio exigibles a los siguientes ficheros: 1.º Aquéllos de los que sean responsables las Entidades Gestoras y Servicios Comunes de la Seguridad Social y se relacionen con el ejercicio de sus competencias. 2.º Aquéllos de los que sean responsables las mutuas de accidentes de trabajo y enfermedades profesionales de la Seguridad Social. 3.º Aquéllos que contengan un conjunto de datos de carácter personal que ofrezcan una definición de las características o de la personalidad de los ciudadanos y que permitan evaluar determinados aspectos de la personalidad o del comportamiento de los mismos, respecto de las medidas de este nivel que no fueran exigibles conforme a lo previsto en el artículo 4.4 del Reglamento de Medi- das de seguridad de los ficheros automatizados de datos de carác- ter personal, aprobado por Real Decreto 994/1999, de 11 de junio. b) En el plazo de un año desde su entrada en vigor deberán implantarse las medidas de seguridad de nivel medio y en el de dieciocho meses desde aquella fecha, las de nivel alto exigibles a los siguientes ficheros: 1.º Aquéllos que contengan datos derivados de actos de violencia de género. 2.º Aquéllos de los que sean responsables los operadores que presten servicios de comunicaciones electrónicas disponibles al público o exploten redes públicas de comunicaciones electrónicas respecto a los datos de tráfico y a los datos de localización. c) En los demás supuestos, cuando el presente reglamento exija la implantación de una medida adicional, no prevista en el Reglamento de Medidas de seguridad de los ficheros automatizados de datos de carácter personal, aprobado por Real Decreto 994/1999, de 11 de junio, dicha medida deberá implantarse en el plazo de un año desde la entrada en vigor del presente real decreto. 2.ª Respecto de los ficheros no automatizados que existieran en la fecha de entrada en vigor del presente real decreto: a) Las medidas de seguridad de nivel básico deberán implantarse en el plazo de un año desde su entrada en vigor. 301

La protección de datos personales: Soluciones en entornos Microsoft b) Las medidas de seguridad de nivel medio deberán implantarse en el plazo de dieciocho meses desde su entrada en vigor. c) Las medidas de seguridad de nivel alto deberán implantarse en el plazo de dos años desde su entrada en vigor. 3.ª Los ficheros, tanto automatizados como no automatizados, creados con posterioridad a la fecha de entrada en vigor del presente real decreto deberán tener implantadas, desde el momento de su creación la totalidad de las medidas de seguridad reguladas en el mismo. Disposición transitoria tercera. Régimen transitorio de las solicitudes para el ejercicio de los derechos de las personas. A las solicitudes para el ejercicio de los derechos de acceso, oposición, rectifica- ción y cancelación que hayan sido efectuadas antes de la entrada en vigor del presente real decreto, no les será de aplicación el mismo, rigiéndose por la normativa anterior. Disposición transitoria cuarta. Régimen transitorio de los procedimientos. A los procedimientos ya iniciados antes de la entrada en vigor del presente real decreto, no les será de aplicación el mismo, rigiéndose por la normativa anterior. Disposición transitoria quinta. Régimen transitorio de las actuaciones previas. A las actuaciones previas iniciadas con anterioridad a la entrada en vigor del presente real decreto, no les será de aplicación el mismo, rigiéndose por la normativa anterior. El presente real decreto se aplicará a las actuaciones previas que se inicien después de su entrada en vigor. Disposición derogatoria única. Derogación normativa. Quedan derogados el Real Decreto 1332/1994, de 20 de junio, por el que se desarrollan determinados aspectos de la Ley Orgánica 5/1992, de 29 de octubre, de Regulación del tratamiento automatizado de los datos de carácter personal, el Real Decreto 994/1999, de 11 de junio, por el que se aprueba el Reglamento de Medidas de seguridad de los ficheros automatizados que contengan datos de carácter personal y todas las normas de igual o inferior rango que contradigan o se opongan a lo dispuesto en el presente real decreto. Disposición final primera. Título competencial. El título I, con excepción del apartado c) del artículo 4, los títulos II, III, VII y VIII, así como los artículos 52, 53.3, 53.4, 54, 55.1, 55.3, 56, 57, 58 y 63.3 del reglamento se dictan al amparo de lo dispuesto en el artículo 149.1.1.ª de la Constitución, que atribuye al Estado la competencia exclusiva para la regulación de las condiciones básicas que garanticen la igualdad de todos los españoles en el ejercicio de los derechos y en el cumplimiento de los deberes constitucionales. 302

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal Disposición final segunda. Entrada en vigor. El presente real decreto entrará en vigor a los tres meses de su íntegra publica- ción en el «Boletín Oficial del Estado». Dado en Madrid, el 21 de diciembre de 2007. JUAN CARLOS R. El Ministro de Justicia, MARIANO FERNÁNDEZ BERMEJO REGLAMENTO DE DESARROLLO DE LA LEY ORGÁNICA 15/1999, DE 13 DE DICIEMBRE, DE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL Título I. Disposiciones generales. Artículo 1. Objeto. Artículo 2. Ámbito objetivo de aplicación. Artículo 3. Ámbito territorial de aplicación. Artículo 4. Ficheros o tratamientos excluidos. Artículo 5. Definiciones. Artículo 6. Cómputo de plazos. Artículo 7. Fuentes accesibles al público. Título II. Principios de protección de datos. Capítulo I. Calidad de los datos. Artículo 8. Principios de calidad de los datos. Artículo 9. Tratamiento con fines estadísticos, históricos o científicos. Artículo 10. Supuestos que legitiman el tratamiento o cesión de los datos. Artículo 11. Verificación de datos en solicitudes formuladas a las Adminis- traciones Públicas. Capítulo II. Consentimiento para el tratamiento de los datos y deber de infor- mación. Sección Primera. Obtención del consentimiento del afectado. Artículo 12. Principios generales. Artículo 13. Consentimiento para el tratamiento de datos de menores de edad. Artículo 14. Forma de recabar el consentimiento. Artículo 15. Solicitud del consentimiento en el marco de una relación contractual para fines no relacionados directamente con la misma. Artículo 16. Tratamiento de datos de facturación y tráfico en servicios de comunicaciones electrónicas. 303

La protección de datos personales: Soluciones en entornos Microsoft Artículo 17. Revocación del consentimiento. Sección Segunda. Deber de información al interesado. Artículo 18. Acreditación del cumplimiento del deber de información. Artículo 19. Supuestos especiales. Capítulo III. Encargado del tratamiento. Artículo 20. Relaciones entre el responsable y el encargado del tratamiento. Artículo 21. Posibilidad de subcontratación de los servicios. Artículo 22. Conservación de los datos por el encargado del tratamiento. Título III. Derechos de acceso, rectificación, cancelación y oposición. Capítulo I. Disposiciones generales. Artículo 23. Carácter personalísimo. Artículo 24. Condiciones generales para el ejercicio de los derechos de acceso, rectificación, cancelación y oposición. Artículo 25. Procedimiento. Artículo 26. Ejercicio de los derechos ante un encargado del tratamiento. Capítulo II. Derecho de acceso. Artículo 27. Derecho de acceso. Artículo 28. Ejercicio del derecho de acceso. Artículo 29. Otorgamiento del acceso. Artículo 30. Denegación del acceso. Capítulo III. Derechos de rectificación y cancelación. Artículo 31. Derechos de rectificación y cancelación. Artículo 32. Ejercicio de los derechos de rectificación y cancelación. Artículo 33. Denegación de los derechos de rectificación y cancelación. Capítulo IV. Derecho de oposición. Artículo 34. Derecho de oposición. Artículo 35. Ejercicio del derecho de oposición. Artículo 36. Derecho de oposición a las decisiones basadas únicamente en un tratamiento automatizado de datos. Título IV. Disposiciones aplicables a determinados ficheros de titularidad privada. Capítulo I. Ficheros de información sobre solvencia patrimonial y crédito. Sección Primera. Disposiciones generales. Artículo 37. Régimen aplicable. Sección Segunda. Tratamiento de datos relativos al cumplimiento o incumplimiento de obligaciones dinerarias facilitados por el acreedor o por quien actúe por su cuenta o interés. 304

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal Artículo 38. Requisitos para la inclusión de los datos. Artículo 39. Información previa a la inclusión. Artículo 40. Notificación de inclusión. Artículo 41. Conservación de los datos. Artículo 42. Acceso a la información contenida en el fichero. Artículo 43. Responsabilidad. Artículo 44. Ejercicio de los derechos de acceso, rectificación, cancelación y oposición. Capítulo II. Tratamientos para actividades de publicidad y prospección comercial. Artículo 45. Datos susceptibles de tratamiento e información al interesado. Artículo 46. Tratamiento de datos en campañas publicitarias. Artículo 47. Depuración de datos personales. Artículo 48. Ficheros de exclusión del envío de comunicaciones comerciales. Artículo 49. Ficheros comunes de exclusión del envío de comunicaciones comerciales. Artículo 50. Derechos de acceso, rectificación y cancelación. Artículo 51. Derecho de oposición. Título V. Obligaciones previas al tratamiento de los datos. Capítulo I. Creación, modificación o supresión de ficheros de titularidad pública. Artículo 52. Disposición o Acuerdo de creación, modificación o supresión del fichero. Artículo 53. Forma de la disposición o acuerdo. Artículo 54. Contenido de la disposición o acuerdo. Capítulo II. Notificación e inscripción de los ficheros de titularidad pública o privada. Artículo 55. Notificación de ficheros. Artículo 56. Tratamiento de datos en distintos soportes. Artículo 57. Ficheros en los que exista más de un responsable. Artículo 58. Notificación de la modificación o supresión de ficheros. Artículo 59. Modelos y soportes para la notificación. Artículo 60. Inscripción de los ficheros. Artículo 61. Cancelación de la inscripción. Artículo 62. Rectificación de errores. Artículo 63. Inscripción de oficio de ficheros de titularidad pública. Artículo 64. Colaboración con las Autoridades de Control de las Comuni- dades Autónomas. Título VI. Transferencias internacionales de datos. 305

La protección de datos personales: Soluciones en entornos Microsoft Capítulo I. Disposiciones generales. Artículo 65. Cumplimiento de las disposiciones de la Ley Orgánica 15/ 1999, de 13 de diciembre. Artículo 66. Autorización y notificación. Capítulo II. Transferencias a estados que proporcionen un nivel adecuado de protección. Artículo 67. Nivel adecuado de protección acordado por la Agencia Española de Protección de Datos. Artículo 68. Nivel adecuado de protección declarado por Decisión de la Comisión Europea. Artículo 69. Suspensión temporal de las transferencias. Capítulo III. Transferencias a estados que no proporcionen un nivel adecuado de protección. Artículo 70. Transferencias sujetas a autorización del Director de la Agen- cia Española de Protección de Datos. Título VII. Códigos tipo. Artículo 71. Objeto y naturaleza. Artículo 72. Iniciativa y ámbito de aplicación. Artículo 73. Contenido. Artículo 74. Compromisos adicionales Artículo 75. Garantías del cumplimiento de los códigos tipo. Artículo 76. Relación de adheridos. Artículo 77. Depósito y publicidad de los códigos tipo. Artículo 78. Obligaciones posteriores a la inscripción del código tipo. Título VIII. De las medidas de seguridad en el tratamiento de datos de carácter personal. Capítulo I. Disposiciones generales. Artículo 79. Alcance. Artículo 80. Niveles de seguridad. Artículo 81. Aplicación de los niveles de seguridad. Artículo 82. Encargado del tratamiento. Artículo 83. Prestaciones de servicios sin acceso a datos personales. Artículo 84. Delegación de autorizaciones. Artículo 85. Acceso a datos a través de redes de comunicaciones. Artículo 86. Régimen de trabajo fuera de los locales del responsable del fichero o encargado del tratamiento. Artículo 87. Ficheros temporales o copias de trabajo de documentos. Capítulo II. Del documento de seguridad. 306

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal Artículo 88. El documento de seguridad. Capítulo III. Medidas de seguridad aplicables a ficheros y tratamientos automatizados. Sección Primera. Medidas de seguridad de nivel básico. Artículo 89. Funciones y obligaciones del personal. Artículo 90. Registro de incidencias. Artículo 91. Control de acceso. Artículo 92. Gestión de soportes. Artículo 93. Identificación y autenticación. Artículo 94. Copias de respaldo y recuperación. Sección Segunda. Medidas de seguridad de nivel medio. Artículo 95. Responsable de seguridad. Artículo 96. Auditoría. Artículo 97. Gestión de soportes. Artículo 98. Identificación y autenticación. Artículo 99. Control de acceso físico. Artículo 100. Registro de incidencias. Sección Tercera. Medidas de seguridad de nivel alto. Artículo 101. Gestión y distribución de soportes. Artículo 102. Copias de respaldo y recuperación. Artículo 103. Registro de accesos. Artículo 104. Telecomunicaciones. Capítulo IV. Medidas de seguridad aplicables a los ficheros y tratamientos no automatizados. Sección Primera. Medidas de seguridad de nivel básico. Artículo 105. Obligaciones comunes. Artículo 106. Criterios de archivo. Artículo 107. Dispositivos de almacenamiento. Artículo 108. Custodia de los soportes. Sección Segunda. Medidas de seguridad de nivel medio. Artículo 109. Responsabilidad de seguridad. Artículo 110. Auditoría. Sección Tercera. Medidas de seguridad de nivel alto. Artículo 111. Almacenamiento de la información. Artículo 112. Copia o reproducción. Artículo 113. Acceso a la documentación. Artículo 114. Traslado de documentación. 307

La protección de datos personales: Soluciones en entornos Microsoft Título IX. Procedimientos tramitados por la Agencia Española de Protección de Datos. Capítulo I. Disposiciones generales. Artículo 115. Régimen aplicable. Artículo 116. Publicidad de las resoluciones Capítulo II. Procedimiento de tutela de los derechos de acceso, rectificación, cancelación y oposición. Artículo 117. Instrucción del procedimiento. Artículo 118. Duración del procedimiento y efectos de la falta de resolu- ción expresa. Artículo 119. Ejecución de la resolución. Capítulo III. Procedimientos relativos al ejercicio de la potestad sancionadora. Sección Primera. Disposiciones Generales. Artículo 120. Ámbito de aplicación. Artículo 121. Inmovilización de ficheros. Sección Segunda. Actuaciones previas. Artículo 122. Iniciación. Artículo 123. Personal competente para la realización de las actuaciones previas. Artículo 124. Obtención de información. Artículo 125. Actuaciones presenciales. Artículo 126. Resultado de las actuaciones previas. Sección Tercera Procedimiento Sancionador. Artículo 127. Iniciación del procedimiento. Artículo 128. Plazo máximo para resolver. Sección Cuarta. Procedimiento de declaración de infracción de la Ley Orgánica 15/1999, de 13 de diciembre, por las Administraciones Públicas. Artículo 129. Disposición general. Capítulo IV. Procedimientos relacionados con la inscripción o cancelación de ficheros. Sección Primera. Procedimiento de inscripción de la creación, modificación o supresión de ficheros. Artículo 130. Iniciación del procedimiento. Artículo 131. Especialidades en la notificación de ficheros de titularidad pública. Artículo 132. Acuerdo de inscripción o cancelación. Artículo 133. Improcedencia o denegación de la inscripción. Artículo 134. Duración del procedimiento y efectos de la falta de resolu- ción expresa. 308

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal Sección Segunda. Procedimiento de cancelación de oficio de ficheros inscritos. Artículo 135. Iniciación del procedimiento. Artículo 136. Terminación del expediente. Capítulo V. Procedimientos relacionados con las transferencias internacionales de datos. Sección Primera. Procedimiento de autorización de transferencias internacionales de datos. Artículo 137. Iniciación del procedimiento. Artículo 138. Instrucción del procedimiento. Artículo 139. Actos posteriores a la resolución. Artículo 140. Duración del procedimiento y efectos de la falta de resolu- ción expresa. Sección Segunda. Procedimiento de suspensión temporal de transferencias internacionales de datos. Artículo 141. Iniciación. Artículo 142. Instrucción y resolución. Artículo 143. Actos posteriores a la resolución. Artículo 144. Levantamiento de la suspensión temporal. Capítulo VI. Procedimiento de inscripción de códigos tipo. Artículo 145. Iniciación del procedimiento. Artículo 146. Análisis de los aspectos sustantivos del código tipo. Artículo 147. Información pública. Artículo 148. Mejora del código tipo. Artículo 149. Trámite de audiencia. Artículo 150. Resolución. Artículo 151. Duración del procedimiento y efectos de la falta de resolu- ción expresa. Artículo 152. Publicación de los códigos tipo por la Agencia Española de Protección de Datos. Capítulo VII. Otros procedimientos tramitados por la Agencia Española de Protección de Datos. Sección Primera. Procedimiento de exención del deber de información al interesado Artículo 153. Iniciación del procedimiento. Artículo 154. Propuesta de nuevas medidas compensatorias Artículo 155. Terminación del procedimiento. Artículo 156. Duración del procedimiento y efectos de la falta de resolu- ción expresa. 309

La protección de datos personales: Soluciones en entornos Microsoft Sección Segunda. Procedimiento para la autorización de conservación de datos para fines históricos, estadísticos o científicos. Artículo 157. Iniciación del procedimiento. Artículo 158. Duración del procedimiento y efectos de la falta de resolu- ción expresa. Disposición adicional única. Productos de software. Disposición final única. Aplicación supletoria. TÍTULO I. Disposiciones generales Artículo 1. Objeto. 1. El presente reglamento tiene por objeto el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de datos de carácter personal. 2. Asimismo, el capítulo III del título IX de este reglamento desarrolla las disposiciones relativas al ejercicio por la Agencia Española de Protección de Datos de la potestad sancionadora, en aplicación de lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, en el título VII de la Ley 34/ 2002, de 11 de julio, de Servicios de la sociedad de la información y de comercio electrónico, y en el título VIII de la Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones. Artículo 2. Ámbito objetivo de aplicación. 1. El presente reglamento 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. 2. Este reglamento no será aplicable a los tratamientos de datos referidos a personas jurídicas, ni a los ficheros que se limiten a incorporar los datos de las personas físicas que presten sus servicios en aquéllas, consistentes únicamente en su nombre y apellidos, las funciones o puestos desempeña- dos, así como la dirección postal o electrónica, teléfono y número de fax profesionales. 3. Asimismo, los datos relativos a empresarios individuales, cuando hagan referencia a ellos en su calidad de comerciantes, industriales o navieros, también se entenderán excluidos del régimen de aplicación de la protec- ción de datos de carácter personal. 4. Este reglamento no será de aplicación a los datos referidos a personas fallecidas. No obstante, las personas vinculadas al fallecido, por razones familiares o análogas, podrán dirigirse a los responsables de los ficheros o tratamientos que contengan datos de éste con la finalidad de notificar el óbito, aportando acreditación suficiente del mismo, y solicitar, cuando hubiere lugar a ello, la cancelación de los datos. 310

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal Artículo 3. Ámbito territorial de aplicación. 1. Se regirá por el presente reglamento todo tratamiento de datos de carácter personal: a) Cuando el tratamiento sea efectuado en el marco de las actividades de un establecimiento del responsable del tratamiento, siempre que dicho establecimiento se encuentre ubicado en territorio español. Cuando no resulte de aplicación lo dispuesto en el párrafo anterior, pero exista un encargado del tratamiento ubicado en España, serán de aplicación al mismo las normas contenidas en el título VIII del presente reglamento. b) Cuando al responsable del tratamiento no establecido en territorio español, le sea de aplicación la legislación española, según las normas de Derecho internacional público. c) Cuando el responsable del tratamiento no esté establecido en territorio de la Unión Europea y utilice en el tratamiento de datos medios situados en territorio español, salvo que tales medios se utilicen únicamente con fines de tránsito. En este supuesto, el responsable del tratamiento deberá designar un representante establecido en territorio español. 2. A los efectos previstos en los apartados anteriores, se entenderá por establecimiento, con independencia de su forma jurídica, cualquier instalación estable que permita el ejercicio efectivo y real de una actividad. Artículo 4. Ficheros o tratamientos excluidos. El régimen de protección de los datos de carácter personal que se establece en el presente reglamento no será de aplicación a los siguientes ficheros y tratamientos: a) A los realizados o mantenidos por personas físicas en el ejercicio de actividades exclusivamente personales o domésticas. Sólo se considerarán relacionados con actividades personales o domésticas los tratamientos relativos a las actividades que se inscriben en el marco de la vida privada o familiar de los particulares. b) A los sometidos a la normativa sobre protección de materias clasificadas. c) A los establecidos para la investigación del terrorismo y de formas graves de delincuencia organizada. No obstante el responsable del fichero comu- nicará previamente la existencia del mismo, sus características generales y su finalidad a la Agencia Española de Protección de Datos. Artículo 5. Definiciones. 1. A los efectos previstos en este reglamento, se entenderá por: 311

La protección de datos personales: Soluciones en entornos Microsoft a) Afectado o interesado: Persona física titular de los datos que sean objeto del tratamiento. b) Cancelación: Procedimiento en virtud del cual el responsable cesa en el uso de los datos. La cancelación implicará el bloqueo de los datos, consistente en la identificación y reserva de los mismos con el fin de impedir su tratamiento excepto para su puesta a disposición de las Administraciones públicas, Jueces y Tribunales, para la atención de las posibles responsabilidades nacidas del tratamiento y sólo durante el plazo de prescripción de dichas responsabilidades. Transcurrido ese plazo deberá procederse a la supresión de los datos. c) Cesión o comunicación de datos: Tratamiento de datos que supone su revelación a una persona distinta del interesado. d) Consentimiento del interesado: Toda manifestación de voluntad, libre, inequívoca, específica e informada, mediante la que el interesado consienta el tratamiento de datos personales que le conciernen. e) Dato disociado: aquél que no permite la identificación de un afectado o interesado. f) Datos de carácter personal: Cualquier información numérica, alfabética, gráfica, fotográfica, acústica o de cualquier otro tipo concerniente a personas físicas identificadas o identificables. g) Datos de carácter personal relacionados con la salud: las informaciones concernientes a la salud pasada, presente y futura, física o mental, de un individuo. En particular, se consideran datos relacionados con la salud de las personas los referidos a su porcentaje de discapacidad y a su información genética. h) Destinatario o cesionario: la persona física o jurídica, pública o privada u órgano administrativo, al que se revelen los datos. Podrán ser también destinatarios los entes sin personalidad jurídica que actúen en el tráfico como sujetos diferenciados. i) Encargado del tratamiento: La persona física o jurídica, pública o privada, u órgano administrativo que, solo o conjuntamente con otros, trate datos personales por cuenta del responsable del tratamiento o del responsable del fichero, como consecuencia de la existencia de una relación jurídica que le vincula con el mismo y delimita el ámbito de su actuación para la prestación de un servicio. Podrán ser también encargados del tratamiento los entes sin personalidad jurídica que actúen en el tráfico como sujetos diferenciados. j) Exportador de datos personales: la persona física o jurídica, pública o privada, u órgano administrativo situado en territorio español que realice, conforme a lo dispuesto en el presente Reglamento, una transferencia de datos de carácter personal a un país tercero. k) Fichero: Todo conjunto organizado de datos de carácter personal, que permita el acceso a los datos con arreglo a criterios determinados, 312

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal cualquiera que fuere la forma o modalidad de su creación, almacenamiento, organización y acceso. l) Ficheros de titularidad privada: los ficheros de los que sean responsables las personas, empresas o entidades de derecho privado, con independencia de quien ostente la titularidad de su capital o de la procedencia de sus recursos económicos, así como los ficheros de los que sean responsables las corporaciones de derecho público, en cuanto dichos ficheros no se encuentren estrictamente vinculados al ejercicio de potestades de derecho público que a las mismas atribuye su normativa específica. m ) Ficheros de titularidad pública: los ficheros de los que sean responsables los órganos constitucionales o con relevancia constitucional del Estado o las instituciones autonómicas con funciones análogas a los mismos, las Administraciones públicas territoriales, así como las entidades u organismos vinculados o dependientes de las mismas y las Corporaciones de derecho público siempre que su finalidad sea el ejercicio de potestades de derecho público. n) Fichero no automatizado: todo conjunto de datos de carácter personal organizado de forma no automatizada y estructurado conforme a criterios específicos relativos a personas físicas, que permitan acceder sin esfuerzos desproporcionados a sus datos personales, ya sea aquél centralizado, descentralizado o repartido de forma funcional o geográfica. ñ) Importador de datos personales: la persona física o jurídica, pública o privada, u órgano administrativo receptor de los datos en caso de transferencia internacional de los mismos a un tercer país, ya sea responsable del tratamiento, encargada del tratamiento o tercero. o) Persona identificable: toda persona cuya identidad pueda determinarse, directa o indirectamente, mediante cualquier información referida a su identidad física, fisiológica, psíquica, económica, cultural o social. Una persona física no se considerará identificable si dicha identificación requiere plazos o actividades desproporcionados. p) Procedimiento de disociación: Todo tratamiento de datos personales que permita la obtención de datos disociados. q) Responsable del fichero o del tratamiento: Persona física o jurídica, de naturaleza pública o privada, u órgano administrativo, que sólo o conjuntamente con otros decida sobre la finalidad, contenido y uso del tratamiento, aunque no lo realizase materialmente. Podrán ser también responsables del fichero o del tratamiento los entes sin personalidad jurídica que actúen en el tráfico como sujetos diferenciados. r) Tercero: la persona física o jurídica, pública o privada u órgano administrativo distinta del afectado o interesado, del responsable del trata- 313

La protección de datos personales: Soluciones en entornos Microsoft miento, del responsable del fichero, del encargado del tratamiento y de las personas autorizadas para tratar los datos bajo la autoridad directa del responsable del tratamiento o del encargado del tratamiento. Podrán ser también terceros los entes sin personalidad jurídica que actúen en el tráfico como sujetos diferenciados. s) Transferencia internacional de datos: Tratamiento de datos que supone una transmisión de los mismos fuera del territorio del Espacio Eco- nómico Europeo, bien constituya una cesión o comunicación de datos, bien tenga por objeto la realización de un tratamiento de datos por cuenta del responsable del fichero establecido en territorio español. t) Tratamiento de datos: cualquier operación o procedimiento técnico, sea o no automatizado, que permita la recogida, grabación, conservación, elaboración, modificación, consulta, utilización, modificación, cancela- ción, bloqueo o supresión, así como las cesiones de datos que resulten de comunicaciones, consultas, interconexiones y transferencias. 2. En particular, en relación con lo dispuesto en el título VIII de este reglamento se entenderá por: a) Accesos autorizados: autorizaciones concedidas a un usuario para la utilización de los diversos recursos. En su caso, incluirán las autorizaciones o funciones que tenga atribuidas un usuario por delegación del responsable del fichero o tratamiento o del responsable de seguridad. b) Autenticación: procedimiento de comprobación de la identidad de un usuario. c) Contraseña: información confidencial, frecuentemente constituida por una cadena de caracteres, que puede ser usada en la autenticación de un usuario o en el acceso a un recurso. d) Control de acceso: mecanismo que en función de la identificación ya autenticada permite acceder a datos o recursos. e) Copia de respaldo: copia de los datos de un fichero automatizado en un soporte que posibilite su recuperación. f) Documento: todo escrito, gráfico, sonido, imagen o cualquier otra clase de información que puede ser tratada en un sistema de informa- ción como una unidad diferenciada. g) Ficheros temporales: ficheros de trabajo creados por usuarios o procesos que son necesarios para un tratamiento ocasional o como paso intermedio durante la realización de un tratamiento. h) Identificación: procedimiento de reconocimiento de la identidad de un usuario. i) Incidencia: cualquier anomalía que afecte o pudiera afectar a la seguridad de los datos. j) Perfil de usuario: accesos autorizados a un grupo de usuarios. 314

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal k) Recurso: cualquier parte componente de un sistema de información. l) Responsable de seguridad: persona o personas a las que el responsable del fichero ha asignado formalmente la función de coordinar y controlar las medidas de seguridad aplicables. m ) Sistema de información: conjunto de ficheros, tratamientos, programas, soportes y en su caso, equipos empleados para el tratamiento de datos de carácter personal. n) Sistema de tratamiento: modo en que se organiza o utiliza un sistema de información. Atendiendo al sistema de tratamiento, los sistemas de información podrán ser automatizados, no automatizados o parcialmente automatizados. ñ) Soporte: objeto físico que almacena o contiene datos o documentos, u objeto susceptible de ser tratado en un sistema de información y sobre el cual se pueden grabar y recuperar datos. o) Transmisión de documentos: cualquier traslado, comunicación, envío, entrega o divulgación de la información contenida en el mismo. p) Usuario: sujeto o proceso autorizado para acceder a datos o recursos. Tendrán la consideración de usuarios los procesos que permitan acceder a datos o recursos sin identificación de un usuario físico. Artículo 6. Cómputo de plazos. En los supuestos en que este reglamento señale un plazo por días se computa- rán únicamente los hábiles. Cuando el plazo sea por meses, se computarán de fecha a fecha. Artículo 7. Fuentes accesibles al público. 1. A efectos del artículo 3, párrafo j) de la Ley Orgánica 15/1999, se entende- rá que sólo tendrán el carácter de fuentes accesibles al público: a) El censo promocional, regulado conforme a lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre. b) Las guías de servicios de comunicaciones electrónicas, en los términos previstos por su normativa específica. c) Las listas de personas pertenecientes a grupos de profesionales que contengan únicamente los datos de nombre, título, profesión, actividad, grado académico, dirección profesional e indicación de su pertenencia al grupo. La dirección profesional podrá incluir los datos del domicilio postal completo, número telefónico, número de fax y dirección electrónica. En el caso de Colegios profesionales, podrán indicarse como datos de pertenencia al grupo los de número de colegiado, fecha de incorporación y situación de ejercicio profesional. d) Los diarios y boletines oficiales. 315

La protección de datos personales: Soluciones en entornos Microsoft e) Los medios de comunicación social. 2. En todo caso, para que los supuestos enumerados en el apartado anterior puedan ser considerados fuentes accesibles al público, será preciso que su consulta pueda ser realizada por cualquier persona, no impedida por una norma limitativa, o sin más exigencia que, en su caso, el abono de una contraprestación. TÍTULO II. Principios de protección de datos CAPÍTULO I. Calidad de los datos Artículo 8. Principios relativos a la calidad de los datos. 1. Los datos de carácter personal deberán ser tratados de forma leal y lícita. Se prohíbe la recogida de datos por medios fraudulentos, desleales o ilícitos. 2. Los datos de carácter personal sólo podrán ser recogidos para el cumplimiento de finalidades determinadas, explícitas y legítimas del responsable del tratamiento. 3. Los datos de carácter personal objeto de tratamiento no podrán usarse para finalidades incompatibles con aquellas para las que los datos hubieran sido recogidos. 4. Sólo podrán ser objeto de tratamiento los datos que sean adecuados, pertinentes y no excesivos en relación con las finalidades determinadas, explícitas y legítimas para las que se hayan obtenido. 5. Los datos de carácter personal serán exactos y puestos al día de forma que respondan con veracidad a la situación actual del afectado. Si los datos fueran recogidos directamente del afectado, se considerarán exactos los facilitados por éste. Si los datos de carácter personal sometidos a tratamiento resultaran ser inexactos, en todo o en parte, o incompletos, serán cancelados y sustituidos de oficio por los correspondientes datos rectificados o completados en el plazo de diez días desde que se tuviese conocimiento de la inexactitud, salvo que la legislación aplicable al fichero establezca un procedimiento o un plazo específico para ello. Cuando los datos hubieran sido comunicados previamente, el responsable del fichero o tratamiento deberá notificar al cesionario, en el plazo de diez días, la rectificación o cancelación efectuada, siempre que el cesionario sea conocido. En el plazo de diez días desde la recepción de la notificación, el cesionario que mantuviera el tratamiento de los datos, deberá proceder a la rectifica- ción y cancelación notificada. Esta actualización de los datos de carácter personal no requerirá comuni- cación alguna al interesado, sin perjuicio del ejercicio de los derechos por 316

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal parte de los interesados reconocidos en la Ley Orgánica 15/1999, de 13 de diciembre. Lo dispuesto en este apartado se entiende sin perjuicio de las facultades que a los afectados reconoce el título III de este reglamento. 6. Los datos de carácter personal serán cancelados cuando hayan dejado de ser necesarios o pertinentes para la finalidad para la cual hubieran sido recabados o registrados. No obstante, podrán conservarse durante el tiempo en que pueda exigirse algún tipo de responsabilidad derivada de una relación u obligación jurídica o de la ejecución de un contrato o de la aplicación de medidas precontractuales solicitadas por el interesado. Una vez cumplido el período al que se refieren los párrafos anteriores, los datos sólo podrán ser conservados previa disociación de los mismos, sin perjuicio de la obligación de bloqueo prevista en la Ley Orgánica 15/1999, de 13 de diciembre, y en el presente reglamento. 7. Los datos de carácter personal serán tratados de forma que permitan el ejercicio del derecho de acceso, en tanto no proceda su cancelación. Artículo 9. Tratamiento con fines estadísticos, históricos o científicos. 1. No se considerará incompatible, a los efectos previstos en el apartado 3 del artículo anterior, el tratamiento de los datos de carácter personal con fines históricos, estadísticos o científicos. Para la determinación de los fines a los que se refiere el párrafo anterior se estará a la legislación que en cada caso resulte aplicable y, en particular, a lo dispuesto en la Ley 12/1989, de 9 de mayo, Reguladora de la función estadística pública, la Ley 16/1985, de 25 junio, del Patrimonio histórico español y la Ley 13/1986, de 14 de abril de Fomento y coordinación general de la investigación científica y técnica, y sus respectivas disposiciones de desarrollo, así como a la normativa autonómica en estas materias. 2. Por vía de excepción a lo dispuesto en el apartado 6 del artículo anterior, la Agencia Española de Protección de Datos o, en su caso, las autoridades de control de las comunidades autónomas podrán, previa solicitud del responsable del tratamiento y conforme al procedimiento establecido en la sección segunda del capítulo VII del título IX del presente reglamento, acordar el mantenimiento íntegro de determinados datos, atendidos sus valores históricos, estadísticos o científicos de acuerdo con las normas a las que se refiere el apartado anterior. Artículo 10. Supuestos que legitiman el tratamiento o cesión de los datos. 1. Los datos de carácter personal únicamente podrán ser objeto de tratamiento o cesión si el interesado hubiera prestado previamente su consentimiento para ello. 317

La protección de datos personales: Soluciones en entornos Microsoft 2. No obstante, será posible el tratamiento o la cesión de los datos de carác- ter personal sin necesidad del consentimiento del interesado cuando: a) Lo autorice una norma con rango de ley o una norma de derecho comunitario y, en particular, cuando concurra uno de los supuestos siguientes: El tratamiento o la cesión tengan por objeto la satisfacción de un interés legítimo del responsable del tratamiento o del cesionario amparado por dichas normas, siempre que no prevalezca el interés o los derechos y libertades fundamentales de los interesados previstos en el artículo 1 de la Ley Orgánica 15/1999, de 13 de diciembre. El tratamiento o la cesión de los datos sean necesarios para que el responsable del tratamiento cumpla un deber que le imponga una de dichas normas. b) Los datos objeto de tratamiento o de cesión figuren en fuentes accesibles al público y el responsable del fichero, o el tercero a quien se comuniquen los datos, tenga un interés legítimo para su tratamiento o conocimiento, siempre que no se vulneren los derechos y libertades fundamentales del interesado. No obstante, las Administraciones públicas sólo podrán comunicar al amparo de este apartado los datos recogidos de fuentes accesibles al público a responsables de ficheros de titularidad privada cuando se encuentren autorizadas para ello por una norma con rango de ley. 3. Los datos de carácter personal podrán tratarse sin necesidad del consentimiento del interesado cuando: a) Se recojan para el ejercicio de las funciones propias de las Administra- ciones públicas en el ámbito de las competencias que les atribuya una norma con rango de ley o una norma de derecho comunitario. b) Se recaben por el responsable del tratamiento con ocasión de la celebración de un contrato o precontrato o de la existencia de una relación negocial, laboral o administrativa de la que sea parte el afectado y sean necesarios para su mantenimiento o cumplimiento. c) El tratamiento de los datos tenga por finalidad proteger un interés vital del interesado en los términos del apartado 6 del artículo 7 de la Ley Orgánica 15/1999, de 13 de diciembre. 4. Será posible la cesión de los datos de carácter personal sin contar con el consentimiento del interesado cuando: a) La cesión responda a la libre y legítima aceptación de una relación jurídica cuyo desarrollo, cumplimiento y control comporte la comuni- cación de los datos. En este caso la comunicación sólo será legítima en cuanto se limite a la finalidad que la justifique. b) La comunicación que deba efectuarse tenga por destinatario al Defensor del Pueblo, el Ministerio Fiscal o los Jueces o Tribunales o el 318

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal Tribunal de Cuentas o a las instituciones autonómicas con funciones análogas al Defensor del Pueblo o al Tribunal de Cuentas y se realice en el ámbito de las funciones que la ley les atribuya expresamente. c) La cesión entre Administraciones públicas cuando concurra uno de los siguientes supuestos: Tenga por objeto el tratamiento de los datos con fines históricos, estadísticos o científicos. Los datos de carácter personal hayan sido recogidos o elaborados por una Administración pública con destino a otra. La comunicación se realice para el ejercicio de competencias idénticas o que versen sobre las mismas materias. 5. Los datos especialmente protegidos podrán tratarse y cederse en los términos previstos en los artículos 7 y 8 de la Ley Orgánica 15/1999, de 13 de diciembre. En particular, no será necesario el consentimiento del interesado para la comunicación de datos personales sobre la salud, incluso a través de medios electrónicos, entre organismos, centros y servicios del Sistema Nacional de Salud cuando se realice para la atención sanitaria de las personas, conforme a lo dispuesto en el Capítulo V de la Ley 16/2003, de 28 de mayo, de cohesión y calidad del Sistema Nacional de Salud. Artículo 11. Verificación de datos en solicitudes formuladas a las Administraciones públicas. Cuando se formulen solicitudes por medios electrónicos en las que el interesado declare datos personales que obren en poder de las Administraciones públicas, el órgano destinatario de la solicitud podrá efectuar en el ejercicio de sus competencias las verificaciones necesarias para comprobar la autenticidad de los datos. CAPÍTULO II. Consentimiento para el tratamiento de los datos y deber de información SECCIÓN 1.ª OBTENCIÓN DEL CONSENTIMIENTO DEL AFECTADO Artículo 12. Principios generales. 1. El responsable del tratamiento deberá obtener el consentimiento del interesado para el tratamiento de sus datos de carácter personal salvo en aquellos supuestos en que el mismo no sea exigible con arreglo a lo dispuesto en las leyes. La solicitud del consentimiento deberá ir referida a un tratamiento o serie de tratamientos concretos, con delimitación de la finalidad para los que se 319

La protección de datos personales: Soluciones en entornos Microsoft recaba, así como de las restantes condiciones que concurran en el tratamiento o serie de tratamientos. 2. Cuando se solicite el consentimiento del afectado para la cesión de sus datos, éste deberá ser informado de forma que conozca inequívocamente la finalidad a la que se destinarán los datos respecto de cuya comunica- ción se solicita el consentimiento y el tipo de actividad desarrollada por el cesionario. En caso contrario, el consentimiento será nulo. 3. Corresponderá al responsable del tratamiento la prueba de la existencia del consentimiento del afectado por cualquier medio de prueba admisible en derecho. Artículo 13. Consentimiento para el tratamiento de datos de menores de edad. 1. Podrá procederse al tratamiento de los datos de los mayores de catorce años con su consentimiento, salvo en aquellos casos en los que la Ley exija para su prestación la asistencia de los titulares de la patria potestad o tutela. En el caso de los menores de catorce años se requerirá el consentimiento de los padres o tutores. 2. En ningún caso podrán recabarse del menor datos que permitan obtener información sobre los demás miembros del grupo familiar, o sobre las características del mismo, como los datos relativos a la actividad profesional de los progenitores, información económica, datos sociológicos o cualesquiera otros, sin el consentimiento de los titulares de tales datos. No obstante, podrán recabarse los datos de identidad y dirección del padre, madre o tutor con la única finalidad de recabar la autorización prevista en el apartado anterior. 3. Cuando el tratamiento se refiera a datos de menores de edad, la informa- ción dirigida a los mismos deberá expresarse en un lenguaje que sea fácilmente comprensible por aquéllos, con expresa indicación de lo dispuesto en este artículo. 4. Corresponderá al responsable del fichero o tratamiento articular los procedimientos que garanticen que se ha comprobado de modo efectivo la edad del menor y la autenticidad del consentimiento prestado en su caso, por los padres, tutores o representantes legales. Artículo 14. Forma de recabar el consentimiento. 1. El responsable del tratamiento podrá solicitar el consentimiento del interesado a través del procedimiento establecido en este artículo, salvo cuando la Ley exija al mismo la obtención del consentimiento expreso para el tratamiento de los datos. 320

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal 2. El responsable podrá dirigirse al afectado, informándole en los términos previstos en los artículos 5 de la Ley Orgánica 15/1999, de 13 de diciembre y 12.2 de este reglamento y deberá concederle un plazo de treinta días para manifestar su negativa al tratamiento, advirtiéndole de que en caso de no pronunciarse a tal efecto se entenderá que consiente el tratamiento de sus datos de carácter personal. En particular, cuando se trate de responsables que presten al afectado un servicio que genere información periódica o reiterada, o facturación periódica, la comunicación podrá llevarse a cabo de forma conjunta a esta información o a la facturación del servicio prestado, siempre que se realice de forma claramente visible. 3. En todo caso, será necesario que el responsable del tratamiento pueda conocer si la comunicación ha sido objeto de devolución por cualquier causa, en cuyo caso no podrá proceder al tratamiento de los datos referidos a ese interesado. 4. Deberá facilitarse al interesado un medio sencillo y gratuito para manifestar su negativa al tratamiento de los datos. En particular, se considerará ajustado al presente reglamento los procedimientos en el que tal negativa pueda efectuarse, entre otros, mediante un envío prefranqueado al responsable del tratamiento, la llamada a un número telefónico gratuito o a los servicios de atención al público que el mismo hubiera establecido. 5. Cuando se solicite el consentimiento del interesado a través del procedimiento establecido en este artículo, no será posible solicitarlo nuevamente respecto de los mismos tratamientos y para las mismas finalidades en el plazo de un año a contar de la fecha de la anterior solicitud. Artículo 15. Solicitud del consentimiento en el marco de una relación contractual para fines no relacionados directamente con la misma. Si el responsable del tratamiento solicitase el consentimiento del afectado durante el proceso de formación de un contrato para finalidades que no guarden relación directa con el mantenimiento, desarrollo o control de la relación contractual, deberá permitir al afectado que manifieste expresamente su negativa al tratamiento o comunicación de datos. En particular, se entenderá cumplido tal deber cuando se permita al afectado la marcación de una casilla claramente visible y que no se encuentre ya marcada en el documento que se le entregue para la celebración del contrato o se establezca un procedimiento equivalente que le permita manifestar su negativa al tratamiento. Artículo 16. Tratamiento de datos de facturación y tráfico en servicios de comunicaciones electrónicas. La solicitud del consentimiento para el tratamiento o cesión de los datos de tráfico, facturación y localización por parte de los sujetos obligados, o en su caso la 321

La protección de datos personales: Soluciones en entornos Microsoft revocación de aquél, según la legislación reguladora de las telecomunicaciones se someterá a lo establecido en su normativa específica y, en lo que no resulte contrario a la misma, a lo establecido en la presente sección. Artículo 17. Revocación del consentimiento. 1. El afectado podrá revocar su consentimiento a través de un medio sencillo, gratuito y que no implique ingreso alguno para el responsable del fichero o tratamiento. En particular, se considerará ajustado al presente reglamento el procedimiento en el que tal negativa pueda efectuarse, entre otros, mediante un envío prefranqueado al responsable del tratamiento o la llamada a un número telefónico gratuito o a los servicios de atención al público que el mismo hubiera establecido. No se considerarán conformes a lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, los supuestos en que el responsable establezca como medio para que el interesado pueda manifestar su negativa al tratamiento el envío de cartas certificadas o envíos semejantes, la utilización de servicios de telecomunicaciones que implique una tarificación adicional al afectado o cualesquiera otros medios que impliquen un coste adicional al interesado. 2. El responsable cesará en el tratamiento de los datos en el plazo máximo de diez días a contar desde el de la recepción de la revocación del consentimien- to, sin perjuicio de su obligación de bloquear los datos conforme a lo dispuesto en el artículo 16.3 de la Ley Orgánica 15/1999, de 13 de diciembre. 3. Cuando el interesado hubiera solicitado del responsable del tratamiento la confirmación del cese en el tratamiento de sus datos, éste deberá responder expresamente a la solicitud. 4. Si los datos hubieran sido cedidos previamente, el responsable del tratamiento, una vez revocado el consentimiento, deberá comunicarlo a los cesionarios, en el plazo previsto en el apartado 2, para que éstos, cesen en el tratamiento de los datos en caso de que aún lo mantuvieran, conforme al artículo 16.4 de la Ley Orgánica 15/1999, de 13 de diciembre. SECCIÓN 2.ª DEBER DE INFORMACIÓN AL INTERESADO Artículo 18. Acreditación del cumplimiento del deber de información. 1. El deber de información al que se refiere el artículo 5 de la Ley Orgánica 15/1999, de 13 de diciembre, deberá llevarse a cabo a través de un medio que permita acreditar su cumplimiento, debiendo conservarse mientras persista el tratamiento de los datos del afectado. 2. El responsable del fichero o tratamiento deberá conservar el soporte en el que conste el cumplimiento del deber de informar. Para el almacenamien- to de los soportes, el responsable del fichero o tratamiento podrá utilizar 322

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal medios informáticos o telemáticos. En particular podrá proceder al escaneado de la documentación en soporte papel, siempre y cuando se garantice que en dicha automatización no ha mediado alteración alguna de los soportes originales. Artículo 19. Supuestos especiales. En los supuestos en que se produzca una modificación del responsable del fichero como consecuencia de una operación de fusión, escisión, cesión global de activos y pasivos, aportación o transmisión de negocio o rama de actividad empresarial, o cualquier operación de reestructuración societaria de análoga naturaleza, contemplada por la normativa mercantil, no se producirá cesión de datos, sin perjuicio del cumplimiento por el responsable de lo dispuesto en el artículo 5 de la Ley Orgánica 15/1999, de 13 de diciembre. CAPÍTULO III. Encargado del tratamiento Artículo 20. Relaciones entre el responsable y el encargado del tratamiento. 1. El acceso a los datos por parte de un encargado del tratamiento que resulte necesario para la prestación de un servicio al responsable no se considerará comunicación de datos, siempre y cuando se cumpla lo establecido en la Ley Orgánica 15/1999, de 13 de diciembre y en el presente capítulo. El servicio prestado por el encargado del tratamiento podrá tener o no carácter remunerado y ser temporal o indefinido. No obstante, se considerará que existe comunicación de datos cuando el acceso tenga por objeto el establecimiento de un nuevo vínculo entre quien accede a los datos y el afectado. 2. Cuando el responsable del tratamiento contrate la prestación de un servicio que comporte un tratamiento de datos personales sometido a lo dispuesto en este capítulo deberá velar por que el encargado del tratamiento reúna las garantías para el cumplimiento de lo dispuesto en este Reglamento. 3. En el caso de que el encargado del tratamiento destine los datos a otra finalidad, los comunique o los utilice incumpliendo las estipulaciones del contrato al que se refiere el apartado 2 del artículo 12 de la Ley Orgánica 15/1999, de 13 de diciembre, será considerado, también, responsable del tratamiento, respondiendo de las infracciones en que hubiera incurrido personalmente. No obstante, el encargado del tratamiento no incurrirá en responsabilidad cuando, previa indicación expresa del responsable, comunique los datos a un tercero designado por aquél, al que hubiera encomendado la presta- ción de un servicio conforme a lo previsto en el presente capítulo. 323

La protección de datos personales: Soluciones en entornos Microsoft Artículo 21. Posibilidad de subcontratación de los servicios. 1. El encargado del tratamiento no podrá subcontratar con un tercero la realización de ningún tratamiento que le hubiera encomendado el responsable del tratamiento, salvo que hubiera obtenido de éste autorización para ello. En este caso, la contratación se efectuará siempre en nombre y por cuenta del responsable del tratamiento. 2. No obstante lo dispuesto en el apartado anterior, será posible la subcontratación sin necesidad de autorización siempre y cuando se cumplan los siguientes requisitos: a) Que se especifiquen en el contrato los servicios que puedan ser objeto de subcontratación y, si ello fuera posible, la empresa con la que se vaya a subcontratar. Cuando no se identificase en el contrato la empresa con la que se vaya a subcontratar, será preciso que el encargado del tratamiento comunique al responsable los datos que la identifiquen antes de proceder a la subcontratación. b) Que el tratamiento de datos de carácter personal por parte del subcontratista se ajuste a las instrucciones del responsable del fichero. c) Que el encargado del tratamiento y la empresa subcontratista formalicen el contrato, en los términos previstos en el artículo anterior. En este caso, el subcontratista será considerado encargado del tratamiento, siéndole de aplicación lo previsto en el artículo 20.3 de este reglamento. 3. Si durante la prestación del servicio resultase necesario subcontratar una parte del mismo y dicha circunstancia no hubiera sido prevista en el contrato, deberán someterse al responsable del tratamiento los extremos señalados en el apartado anterior. Artículo 22. Conservación de los datos por el encargado del tratamiento. 1. Una vez cumplida la prestación contractual, los datos de carácter personal deberán ser destruidos o devueltos al responsable del tratamiento o al encargado que éste hubiese designado, al igual que cualquier soporte o documentos en que conste algún dato de carácter personal objeto del tratamiento. No procederá la destrucción de los datos cuando exista una previsión legal que exija su conservación, en cuyo caso deberá procederse a la devolución de los mismos garantizando el responsable del fichero dicha conservación. 2. El encargado del tratamiento conservará, debidamente bloqueados, los datos en tanto pudieran derivarse responsabilidades de su relación con el responsable del tratamiento. 324

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal TÍTULO III. Derechos de acceso, rectificación, cancelación y oposición CAPÍTULO I. Disposiciones generales Artículo 23. Carácter personalísimo. 1. Los derechos de acceso, rectificación, cancelación y oposición son personalísimos y serán ejercidos por el afectado. 2. Tales derechos se ejercitarán: a) Por el afectado, acreditando su identidad, del modo previsto en el artículo siguiente. b) Cuando el afectado se encuentre en situación de incapacidad o minoría de edad que le imposibilite el ejercicio personal de estos derechos, podrán ejercitarse por su representante legal, en cuyo caso será necesario que acredite tal condición. c) Los derechos también podrán ejercitarse a través de representante voluntario, expresamente designado para el ejercicio del derecho. En ese caso, deberá constar claramente acreditada la identidad del representado, mediante la aportación de copia de su Documento Nacional de Identidad o documento equivalente, y la representación conferida por aquél. Cuando el responsable del fichero sea un órgano de las Administra- ciones públicas o de la Administración de Justicia, podrá acreditarse la representación por cualquier medio válido en derecho que deje constancia fidedigna, o mediante declaración en comparecencia personal del interesado. 3. Los derechos serán denegados cuando la solicitud sea formulada por persona distinta del afectado y no se acreditase que la misma actúa en representación de aquél. Artículo 24. Condiciones generales para el ejercicio de los derechos de acceso, rectificación, cancelación y oposición. 1. Los derechos de acceso, rectificación, cancelación y oposición son derechos independientes, de tal forma que no puede entenderse que el ejercicio de ninguno de ellos sea requisito previo para el ejercicio de otro. 2. Deberá concederse al interesado un medio sencillo y gratuito para el ejercicio de los derechos de acceso, rectificación, cancelación y oposición. 3. El ejercicio por el afectado de sus derechos de acceso, rectificación, cance- lación y oposición será gratuito y en ningún caso podrá suponer un ingreso adicional para el responsable del tratamiento ante el que se ejercitan. 325

La protección de datos personales: Soluciones en entornos Microsoft No se considerarán conformes a lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, y en el presente Reglamento los supuestos en que el responsable del tratamiento establezca como medio para que el interesado pueda ejercitar sus derechos el envío de cartas certificadas o semejantes, la utilización de servicios de telecomunicaciones que implique una tarificación adicional al afectado o cualesquiera otros medios que impliquen un coste excesivo para el interesado. 4. Cuando el responsable del fichero o tratamiento disponga de servicios de cualquier índole para la atención a su público o el ejercicio de reclamaciones relacionadas con el servicio prestado o los productos ofertados al mismo, podrá concederse la posibilidad al afectado de ejercer sus derechos de acceso, rectificación, cancelación y oposición a través de dichos servicios. En tal caso, la identidad del interesado se considerará acreditada por los medios establecidos para la identificación de los clientes del responsable en la prestación de sus servicios o contratación de sus productos. 5. El responsable del fichero o tratamiento deberá atender la solicitud de acceso, rectificación, cancelación u oposición ejercida por el afectado aún cuando el mismo no hubiese utilizado el procedimiento establecido específicamente al efecto por aquél, siempre que el interesado haya utilizado un medio que permita acreditar el envío y la recepción de la solicitud, y que ésta contenga los elementos referidos en el párrafo 1 del artículo siguiente. Artículo 25. Procedimiento. 1. Salvo en el supuesto referido en el párrafo 4 del artículo anterior, el ejercicio de los derechos deberá llevarse a cabo mediante comunicación dirigida al responsable del fichero, que contendrá: a) Nombre y apellidos del interesado; fotocopia de su documento nacional de identidad, o de su pasaporte u otro documento válido que lo identifique y, en su caso, de la persona que lo represente, o instrumentos electrónicos equivalentes; así como el documento o instrumento electrónico acreditativo de tal representación. La utiliza- ción de firma electrónica identificativa del afectado eximirá de la presentación de las fotocopias del DNI o documento equivalente. El párrafo anterior se entenderá sin perjuicio de la normativa específi- ca aplicable a la comprobación de datos de identidad por las Admi- nistraciones Públicas en los procedimientos administrativos. b) Petición en que se concreta la solicitud. c) Dirección a efectos de notificaciones, fecha y firma del solicitante. d) Documentos acreditativos de la petición que formula, en su caso. 2. El responsable del tratamiento deberá contestar la solicitud que se le dirija en todo caso, con independencia de que figuren o no datos personales del afectado en sus ficheros. 326

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal 3. En el caso de que la solicitud no reúna los requisitos especificados en el apartado primero, el responsable del fichero deberá solicitar la subsanación de los mismos. 4. La respuesta deberá ser conforme con los requisitos previstos para cada caso en el presente título. 5. Corresponderá al responsable del tratamiento la prueba del cumplimiento del deber de respuesta al que se refiere el apartado 2, debiendo conservar la acreditación del cumplimiento del mencionado deber. 6. El responsable del fichero deberá adoptar las medidas oportunas para garantizar que las personas de su organización que tienen acceso a datos de carácter personal puedan informar del procedimiento a seguir por el afectado para el ejercicio de sus derechos. 7. El ejercicio de los derechos de acceso, rectificación, cancelación y oposición podrá modularse por razones de seguridad pública en los casos y con el alcance previsto en las Leyes. 8. Cuando las leyes aplicables a determinados ficheros concretos establezcan un procedimiento especial para la rectificación o cancelación de los datos contenidos en los mismos, se estará a lo dispuesto en aquéllas. Artículo 26. Ejercicio de los derechos ante un encargado del tratamiento. Cuando los afectados ejercitasen sus derechos ante un encargado del tratamiento y solicitasen el ejercicio de su derecho ante el mismo, el encargado deberá dar traslado de la solicitud al responsable, a fin de que por el mismo se resuelva, a menos que en la relación existente con el responsable del tratamiento se prevea precisamente que el encargado atenderá, por cuenta del responsable, las solicitudes de ejercicio por los afectados de sus derechos de acceso, rectificación, cancelación u oposición. CAPÍTULO II. Derecho de acceso Artículo 27. Derecho de acceso. 1. El derecho de acceso es el derecho del afectado a obtener información sobre si sus propios datos de carácter personal están siendo objeto de tratamiento, la finalidad del tratamiento que, en su caso, se esté realizando, así como la información disponible sobre el origen de dichos datos y las comunicaciones realizadas o previstas de los mismos. 2. En virtud del derecho de acceso el afectado podrá obtener del responsable del tratamiento información relativa a datos concretos, a datos incluidos en un determinado fichero, o a la totalidad de sus datos sometidos a tratamiento. No obstante, cuando razones de especial complejidad lo justifiquen, el responsable del fichero podrá solicitar del afectado la 327

La protección de datos personales: Soluciones en entornos Microsoft especificación de los ficheros respecto de los cuales quiera ejercitar el derecho de acceso, a cuyo efecto deberá facilitarle una relación de todos ellos. 3. El derecho de acceso es independiente del que otorgan a los afectados las leyes especiales y en particular la Ley 30/1992, de 26 de noviembre, de Régimen Jurídico de las Administraciones Públicas y del Procedimiento Administrativo Común. Artículo 28. Ejercicio del derecho de acceso. 1. Al ejercitar el derecho de acceso, el afectado podrá optar por recibir la información a través de uno o varios de los siguientes sistemas de consulta del fichero: a) Visualización en pantalla. b) Escrito, copia o fotocopia remitida por correo, certificado o no. c) Telecopia. d) Correo electrónico u otros sistemas de comunicaciones electrónicas. e) Cualquier otro sistema que sea adecuado a la configuración o implan- tación material del fichero o a la naturaleza del tratamiento, ofrecido por el responsable. 2. Los sistemas de consulta del fichero previstos en el apartado anterior podrán restringirse en función de la configuración o implantación material del fichero o de la naturaleza del tratamiento, siempre que el que se ofrezca al afectado sea gratuito y asegure la comunicación escrita si éste así lo exige. 3. El responsable del fichero deberá cumplir al facilitar el acceso lo establecido en el Título VIII de este Reglamento. Si tal responsable ofreciera un determinado sistema para hacer efectivo el derecho de acceso y el afectado lo rechazase, aquél no responderá por los posibles riesgos que para la seguridad de la información pudieran derivarse de la elección. Del mismo modo, si el responsable ofreciera un procedimiento para hacer efectivo el derecho de acceso y el afectado exigiese que el mismo se materializase a través de un procedimiento que implique un coste desproporcionado, surtiendo el mismo efecto y garantizando la misma seguridad el procedimiento ofrecido por el responsable, serán de cuenta del afectado los gastos derivados de su elección. Artículo 29. Otorgamiento del acceso. 1. El responsable del fichero resolverá sobre la solicitud de acceso en el plazo máximo de un mes a contar desde la recepción de la solicitud. Transcurri- do el plazo sin que de forma expresa se responda a la petición de acceso, el interesado podrá interponer la reclamación prevista en el artículo 18 de la Ley Orgánica 15/1999, de 13 de diciembre. 328

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal En el caso de que no disponga de datos de carácter personal de los afectados deberá igualmente comunicárselo en el mismo plazo. 2. Si la solicitud fuera estimada y el responsable no acompañase a su comu- nicación la información a la que se refiere el artículo 27.1, el acceso se hará efectivo durante los diez días siguientes a dicha comunicación. 3. La información que se proporcione, cualquiera que sea el soporte en que fuere facilitada, se dará en forma legible e inteligible, sin utilizar claves o códigos que requieran el uso de dispositivos mecánicos específicos. Dicha información comprenderá todos los datos de base del afectado, los resultantes de cualquier elaboración o proceso informático, así como la información disponible sobre el origen de los datos, los cesionarios de los mismos y la especificación de los concretos usos y finalidades para los que se almacenaron los datos. Artículo 30. Denegación del acceso. 1. El responsable del fichero o tratamiento podrá denegar el acceso a los datos de carácter personal cuando el derecho ya se haya ejercitado en los doce meses anteriores a la solicitud, salvo que se acredite un interés legítimo al efecto. 2. Podrá también denegarse el acceso en los supuestos en que así lo prevea una Ley o una norma de derecho comunitario de aplicación directa o cuando éstas impidan al responsable del tratamiento revelar a los afectados el tratamiento de los datos a los que se refiera el acceso. 3. En todo caso, el responsable del fichero informará al afectado de su derecho a recabar la tutela de la Agencia Española de Protección de Datos o, en su caso, de las autoridades de control de las comunidades autóno- mas, conforme a lo dispuesto en el artículo 18 de la Ley Orgánica 15/1999, de 13 de diciembre. CAPÍTULO III. Derechos de rectificación y cancelación Artículo 31. Derechos de rectificación y cancelación. 1. El derecho de rectificación es el derecho del afectado a que se modifiquen los datos que resulten ser inexactos o incompletos. 2. El ejercicio del derecho de cancelación dará lugar a que se supriman los datos que resulten ser inadecuados o excesivos, sin perjuicio del deber de bloqueo conforme a este reglamento. En los supuestos en que el interesado invoque el ejercicio del derecho de cancelación para revocar el consentimiento previamente prestado, se estará a lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre y en el presente reglamento. 329

La protección de datos personales: Soluciones en entornos Microsoft Artículo 32. Ejercicio de los derechos de rectificación y cancelación. 1. La solicitud de rectificación deberá indicar a qué datos se refiere y la corrección que haya de realizarse y deberá ir acompañada de la documen- tación justificativa de lo solicitado. En la solicitud de cancelación, el interesado deberá indicar a qué datos se refiere, aportando al efecto la documentación que lo justifique, en su caso. 2. El responsable del fichero resolverá sobre la solicitud de rectificación o cancelación en el plazo máximo de diez días a contar desde la recepción de la solicitud. Transcurrido el plazo sin que de forma expresa se responda a la petición, el interesado podrá interponer la reclamación prevista en el artículo 18 de la Ley Orgánica 15/1999, de 13 de diciembre. En el caso de que no disponga de datos de carácter personal del afectado deberá igualmente comunicárselo en el mismo plazo. 3. Si los datos rectificados o cancelados hubieran sido cedidos previamente, el responsable del fichero deberá comunicar la rectificación o cancelación efectuada al cesionario, en idéntico plazo, para que éste, también en el plazo de diez días contados desde la recepción de dicha comunicación, proceda, asimismo, a rectificar o cancelar los datos. La rectificación o cancelación efectuada por el cesionario no requerirá comunicación alguna al interesado, sin perjuicio del ejercicio de los derechos por parte de los interesados reconocidos en la Ley Orgánica 15/1999, de 13 de diciembre. Artículo 33. Denegación de los derechos de rectificación y cancelación. 1. La cancelación no procederá cuando los datos de carácter personal deban ser conservados durante los plazos previstos en las disposiciones aplicables o, en su caso, en las relaciones contractuales entre la persona o entidad responsable del tratamiento y el interesado que justificaron el tratamiento de los datos. 2. Podrá también denegarse los derechos de rectificación o cancelación en los supuestos en que así lo prevea una ley o una norma de derecho comunitario de aplicación directa o cuando éstas impidan al responsable del tratamiento revelar a los afectados el tratamiento de los datos a los que se refiera el acceso. 3. En todo caso, el responsable del fichero informará al afectado de su derecho a recabar la tutela de la Agencia Española de Protección de Datos o, en su caso, de las autoridades de control de las Comunidades Autóno- mas, conforme a lo dispuesto en el artículo 18 de la Ley Orgánica 15/1999, de 13 de diciembre. CAPÍTULO IV. Derecho de oposición Artículo 34. Derecho de oposición. El derecho de oposición es el derecho del afectado a que no se lleve a cabo el tratamiento de sus datos de carácter personal o se cese en el mismo en estos supuestos: 330

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal a) Cuando no sea necesario su consentimiento para el tratamiento, como consecuencia de la concurrencia de un motivo legítimo y fundado, referido a su concreta situación personal, que lo justifique, siempre que una Ley no disponga lo contrario. b) Cuando se trate de ficheros que tengan por finalidad la realización de actividades de publicidad y prospección comercial, en los términos previstos en el artículo 51 de este reglamento, cualquiera que sea la empresa responsable de su creación. c) Cuando el tratamiento tenga por finalidad la adopción de una decisión referida al afectado y basada únicamente en un tratamiento automatizado de sus datos de carácter personal, en los términos previstos en el artículo 36 de este reglamento. Artículo 35. Ejercicio del derecho de oposición. 1. El derecho de oposición se ejercitará mediante solicitud dirigida al responsable del tratamiento. Cuando la oposición se realice con base en la letra a) del artículo anterior, en la solicitud deberán hacerse constar los motivos fundados y legítimos, relativos a una concreta situación personal del afectado, que justifican el ejercicio de este derecho. 2. El responsable del fichero resolverá sobre la solicitud de oposición en el plazo máximo de diez días a contar desde la recepción de la solicitud. Transcurrido el plazo sin que de forma expresa se responda a la petición, el interesado podrá interponer la reclamación prevista en el artículo 18 de la Ley Orgánica 15/1999, de 13 de diciembre. En el caso de que no disponga de datos de carácter personal de los afectados deberá igualmente comunicárselo en el mismo plazo. 3. El responsable del fichero o tratamiento deberá excluir del tratamiento los datos relativos al afectado que ejercite su derecho de oposición o denegar motivadamente la solicitud del interesado en el plazo previsto en el apartado 2 de este artículo. Artículo 36. Derecho de oposición a las decisiones basadas únicamente en un tratamiento automatizado de datos. 1. Los interesados tienen derecho a no verse sometidos a una decisión con efectos jurídicos sobre ellos o que les afecte de manera significativa, que se base únicamente en un tratamiento automatizado de datos destinado a evaluar determinados aspectos de su personalidad, tales como su rendimiento laboral, crédito, fiabilidad o conducta. 2. No obstante, los afectados podrán verse sometidos a una de las decisiones contempladas en el apartado 1 cuando dicha decisión: 331

La protección de datos personales: Soluciones en entornos Microsoft a) Se haya adoptado en el marco de la celebración o ejecución de un contrato a petición del interesado, siempre que se le otorgue la posibilidad de alegar lo que estimara pertinente, a fin de defender su derecho o interés. En todo caso, el responsable del fichero deberá informar previamente al afectado, de forma clara y precisa, de que se adoptarán decisiones con las características señaladas en el apartado 1 y cancelará los datos en caso de que no llegue a celebrarse finalmente el contrato. b) Esté autorizada por una norma con rango de Ley que establezca medidas que garanticen el interés legítimo del interesado. TÍTULO IV. Disposiciones aplicables a determinados ficheros de titularidad privada CAPÍTULO I. Ficheros de información sobre solvencia patrimonial y crédito SECCIÓN 1.ª DISPOSICIONES GENERALES Artículo 37. Régimen aplicable. 1. El tratamiento de datos de carácter personal sobre solvencia patrimonial y crédito, previsto en el apartado 1 del artículo 29 de la Ley Orgánica 15/ 1999, de 13 de diciembre, se someterá a lo establecido, con carácter general, en dicha ley orgánica y en el presente reglamento. 2. El ejercicio de los derechos de acceso, rectificación, cancelación y oposi- ción en el caso de los ficheros a que se refiere el apartado anterior, se rige por lo dispuesto en los capítulos I a IV del título III del presente reglamen- to, con los siguientes criterios: a) Cuando la petición de ejercicio de los derechos se dirigiera al responsable del fichero, éste estará obligado a satisfacer, en cualquier caso, dichos derechos. b) Si la petición se dirigiera a las personas y entidades a las que se presta el servicio, éstas únicamente deberán comunicar al afectado aquellos datos relativos al mismo que les hayan sido comunicados y a facilitar la identidad del responsable para que, en su caso, puedan ejercitar sus derechos ante el mismo. 3. De conformidad con el apartado 2 del artículo 29 de la Ley Orgánica 15/ 1999, de 13 de diciembre, también podrán tratarse los datos de carácter personal relativos al cumplimiento o incumplimiento de obligaciones dinerarias facilitados por el acreedor o por quien actúe por su cuenta o interés. Estos datos deberán conservarse en ficheros creados con la exclusiva finalidad de facilitar información crediticia del afectado y su tratamiento se regirá por lo dispuesto en el presente reglamento y, en particular, por las previsiones contenidas en la sección segunda de este capítulo. 332

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal SECCIÓN 2.ª TRATAMIENTO DE DATOS RELATIVOS AL CUMPLIMIENTO O INCUMPLIMIENTO DE OBLIGACIONES DINERARIAS FACILITADOS POR EL ACREEDOR O POR QUIEN ACTÚE POR SU CUENTA O INTERÉS Artículo 38. Requisitos para la inclusión de los datos. 1. Sólo será posible la inclusión en estos ficheros de datos de carácter personal que sean determinantes para enjuiciar la solvencia económica del afectado, siempre que concurran los siguientes requisitos: a) Existencia previa de una deuda cierta, vencida, exigible, que haya resultado impagada y respecto de la cual no se haya entablado reclamación judicial, arbitral o administrativa, o tratándose de servicios financieros, no se haya planteado una reclamación en los térmi- nos previstos en el Reglamento de los Comisionados para la defensa del cliente de servicios financieros, aprobado por Real Decreto 303/ 2004, de 20 de febrero. b) Que no hayan transcurrido seis años desde la fecha en que hubo de procederse al pago de la deuda o del vencimiento de la obligación o del plazo concreto si aquélla fuera de vencimiento periódico. c) Requerimiento previo de pago a quien corresponda el cumplimiento de la obligación. 2. No podrán incluirse en los ficheros de esta naturaleza datos personales sobre los que exista un principio de prueba que de forma indiciaria contradiga alguno de los requisitos anteriores. Tal circunstancia determinará asimismo la cancelación cautelar del dato personal desfavorable en los supuestos en que ya se hubiera efectuado su inclusión en el fichero. 3. El acreedor o quien actúe por su cuenta o interés estará obligado a conservar a disposición del responsable del fichero común y de la Agencia Española de Protección de Datos documentación suficiente que acredite el cumplimiento de los requisitos establecidos en este artículo y del requerimiento previo al que se refiere el artículo siguiente. Artículo 39. Información previa a la inclusión. El acreedor deberá informar al deudor, en el momento en que se celebre el contrato y, en todo caso, al tiempo de efectuar el requerimiento al que se refiere la letra c) del apartado 1 del artículo anterior, que en caso de no producirse el pago en el término previsto para ello y cumplirse los requisitos previstos en el citado artícu- lo, los datos relativos al impago podrán ser comunicados a ficheros relativos al cumplimiento o incumplimiento de obligaciones dinerarias. 333

La protección de datos personales: Soluciones en entornos Microsoft Artículo 40. Notificación de inclusión. 1. El responsable del fichero común deberá notificar a los interesados respec- to de los que hayan registrado datos de carácter personal, en el plazo de treinta días desde dicho registro, una referencia de los que hubiesen sido incluidos, informándole asimismo de la posibilidad de ejercitar sus derechos de acceso, rectificación, cancelación y oposición, en los términos establecidos por la Ley Orgánica 15/1999, de 13 de diciembre. 2. Se efectuará una notificación por cada deuda concreta y determinada con independencia de que ésta se tenga con el mismo o con distintos acreedores. 3. La notificación deberá efectuarse a través de un medio fiable, auditable e independiente de la entidad notificante, que la permita acreditar la efectiva realización de los envíos. 4. En todo caso, será necesario que el responsable del fichero pueda conocer si la notificación ha sido objeto de devolución por cualquier causa, en cuyo caso no podrá proceder al tratamiento de los datos referidos a ese interesado. No se entenderán suficientes para que no se pueda proceder al tratamien- to de los datos referidos a un interesado las devoluciones en las que el destinatario haya rehusado recibir el envío. 5. Si la notificación de inclusión fuera devuelta, el responsable del fichero común comprobará con la entidad acreedora que la dirección utilizada para efectuar esta notificación se corresponde con la contractualmente pactada con el cliente a efectos de comunicaciones y no procederá al tratamiento de los datos si la mencionada entidad no confirma la exactitud de este dato. Artículo 41. Conservación de los datos. 1. Sólo podrán ser objeto de tratamiento los datos que respondan con veracidad a la situación de la deuda en cada momento concreto. El pago o cumplimiento de la deuda determinará la cancelación inmediata de todo dato relativo a la misma. 2. En los restantes supuestos, los datos deberán ser cancelados cuando se hubieran cumplido seis años contados a partir del vencimiento de la obligación o del plazo concreto si aquélla fuera de vencimiento periódico. Artículo 42. Acceso a la información contenida en el fichero. 1. Los datos contenidos en el fichero común sólo podrán ser consultados por terceros cuando precisen enjuiciar la solvencia económica del afectado. En particular, se considerará que concurre dicha circunstancia en los siguientes supuestos: 334

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal a) Que el afectado mantenga con el tercero algún tipo de relación contractual que aún no se encuentre vencida. b) Que el afectado pretenda celebrar con el tercero un contrato que implique el pago aplazado del precio. c) Que el afectado pretenda contratar con el tercero la prestación de un servicio de facturación periódica. 2. Los terceros deberán informar por escrito a las personas en las que concurran los supuestos contemplados en las letras b) y c) precedentes de su derecho a consultar el fichero. En los supuestos de contratación telefónica de los productos o servicios a los que se refiere el párrafo anterior, la información podrá realizarse de forma no escrita, correspondiendo al tercero la prueba del cumplimiento del deber de informar. Artículo 43. Responsabilidad. 1. El acreedor o quien actúe por su cuenta o interés deberá asegurarse que concurren todos los requisitos exigidos en los artículos 38 y 39 en el momento de notificar los datos adversos al responsable del fichero común. 2. El acreedor o quien actúe por su cuenta o interés será responsable de la inexistencia o inexactitud de los datos que hubiera facilitado para su inclusión en el fichero, en los términos previstos en la Ley Orgánica 15/ 1999, de 13 de diciembre. Artículo 44. Ejercicio de los derechos de acceso, rectificación, cancelación y oposición. 1. El ejercicio de los derechos de acceso, rectificación, cancelación y oposición se rige por lo dispuesto en los capítulos I a IV del título III de este reglamento, sin perjuicio de lo señalado en el presente artículo. 2. Cuando el interesado ejercite su derecho de acceso en relación con la inclu- sión de sus datos en un fichero regulado por el artículo 29.2 de la Ley Orgá- nica 15/1999, de 13 de diciembre, se tendrán en cuenta las siguientes reglas: 1.ª Si la solicitud se dirigiera al titular del fichero común, éste deberá comunicar al afectado todos los datos relativos al mismo que obren en el fichero. En este caso, el titular del fichero común deberá, además de dar cumplimiento a lo establecido en el presente reglamento, facilitar las evaluaciones y apreciaciones que sobre el afectado se hayan comunicado en los últimos seis meses y el nombre y dirección de los cesionarios. 2.ª Si la solicitud se dirigiera a cualquier otra entidad participante en el sistema, deberá comunicar al afectado todos los datos relativos al mismo a los que ella pueda acceder, así como la identidad y dirección 335

La protección de datos personales: Soluciones en entornos Microsoft del titular del fichero común para que pueda completar el ejercicio de su derecho de acceso. 3. Cuando el interesado ejercite sus derechos de rectificación o cancelación en relación con la inclusión de sus datos en un fichero regulado por el artículo 29.2 de la Ley Orgánica 15/1999, de 13 de diciembre, se tendrán en cuenta las siguientes reglas: 1.ª Si la solicitud se dirige al titular del fichero común, éste tomará las medidas oportunas para trasladar dicha solicitud a la entidad que haya facilitado los datos, para que ésta la resuelva. En el caso de que el responsable del fichero común no haya recibido contestación por parte de la entidad en el plazo de siete días, procederá a la rectifica- ción o cancelación cautelar de los mismos. 2.ª Si la solicitud se dirige a quien haya facilitado los datos al fichero común procederá a la rectificación o cancelación de los mismos en sus ficheros y a notificarlo al titular del fichero común en el plazo de diez días, dando asimismo respuesta al interesado en los términos previstos en el artículo 33 de este reglamento. 3.ª Si la solicitud se dirige a otra entidad participante en el sistema, que no hubiera facilitado al fichero común los datos, dicha entidad informará al afectado sobre este hecho en el plazo máximo de diez días, proporcionándole, además, la identidad y dirección del titular del fichero común para, que en su caso, puedan ejercitar sus derechos ante el mismo. CAPÍTULO II. Tratamientos para actividades de publicidad y prospección comercial Artículo 45. Datos susceptibles de tratamiento e información al interesado. 1. Quienes se dediquen a la recopilación de direcciones, reparto de documentos, publicidad, venta a distancia, prospección comercial y otras actividades análogas, así como quienes realicen estas actividades con el fin de comercializar sus propios productos o servicios o los de terceros, sólo podrán utilizar nombres y direcciones u otros datos de carácter personal cuando los mismos se encuentren en uno de los siguientes casos: a) Figuren en alguna de las fuentes accesibles al público a las que se refiere la letra j) del artículo 3 de la Ley Orgánica 15/1999, de 13 de diciembre y el artículo 7 de este reglamento y el interesado no haya manifestado su negativa u oposición a que sus datos sean objeto de tratamiento para las actividades descritas en este apartado. b) Hayan sido facilitados por los propios interesados u obtenidos con su consentimiento para finalidades determinadas, explícitas y legítimas relacionadas con la actividad de publicidad o prospección comercial, habiéndose informado a los interesados sobre los sectores específicos 336

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal y concretos de actividad respecto de los que podrá recibir informa- ción o publicidad. 2. Cuando los datos procedan de fuentes accesibles al público y se destinen a la actividad de publicidad o prospección comercial, deberá informarse al interesado en cada comunicación que se le dirija del origen de los datos y de la identidad del responsable del tratamiento así como de los derechos que le asisten, con indicación de ante quién podrán ejercitarse. A tal efecto, el interesado deberá ser informado de que sus datos han sido obtenidos de fuentes accesibles al público y de la entidad de la que hubieran sido obtenidos. Artículo 46. Tratamiento de datos en campañas publicitarias. 1. Para que una entidad pueda realizar por sí misma una actividad publicitaria de sus productos o servicios entre sus clientes será preciso que el tratamiento se ampare en alguno de los supuestos contemplados en el artículo 6 de la Ley Orgánica 15/1999, de 13 de diciembre. 2. En caso de que una entidad contrate o encomiende a terceros la realiza- ción de una determinada campaña publicitaria de sus productos o servicios, encomendándole el tratamiento de determinados datos, se aplicarán las siguientes normas: a) Cuando los parámetros identificativos de los destinatarios de la campaña sean fijados por la entidad que contrate la campaña, ésta será responsable del tratamiento de los datos. b) Cuando los parámetros fueran determinados únicamente por la entidad o entidades contratadas, dichas entidades serán las responsable del tratamiento. c) Cuando en la determinación de los parámetros intervengan ambas entidades, serán ambas responsables del tratamiento. 3. En el supuesto contemplado en el apartado anterior, la entidad que encargue la realización de la campaña publicitaria deberá adoptar las medidas necesarias para asegurarse de que la entidad contratada ha recabado los datos cumpliendo las exigencias establecidas en la Ley Orgánica 15/1999, de 13 de diciembre, y en el presente reglamento. 4. A los efectos previstos en este artículo, se consideran parámetros identificativos de los destinatarios las variables utilizadas para identificar el público objetivo o destinatario de una campaña o promoción comercial de productos o servicios que permitan acotar los destinatarios individuales de la misma. Artículo 47. Depuración de datos personales. Cuando dos o más responsables por sí mismos o mediante encargo a terceros pretendieran constatar sin consentimiento de los afectados, con fines de promoción o 337

La protección de datos personales: Soluciones en entornos Microsoft comercialización de sus productos o servicios y mediante un tratamiento cruzado de sus ficheros quiénes ostentan la condición de clientes de una u otra o de varios de ellos, el tratamiento así realizado constituirá una cesión o comunicación de datos. Artículo 48. Ficheros de exclusión del envío de comunicaciones comerciales. Los responsables a los que el afectado haya manifestado su negativa a recibir publicidad podrán conservar los mínimos datos imprescindibles para identificarlo y adoptar las medidas necesarias que eviten el envío de publicidad. Artículo 49. Ficheros comunes de exclusión del envío de comunicaciones comerciales. 1. Será posible la creación de ficheros comunes, de carácter general o sectorial, en los que sean objeto de tratamiento los datos de carácter personal que resulten necesarios para evitar el envío de comunicaciones comerciales a los interesados que manifiesten su negativa u oposición a recibir publicidad. A tal efecto, los citados ficheros podrán contener los mínimos datos imprescindibles para identificar al afectado. 2. Cuando el afectado manifieste ante un concreto responsable su negativa u oposición a que sus datos sean tratados con fines de publicidad o prospec- ción comercial, aquél deberá ser informado de la existencia de los ficheros comunes de exclusión generales o sectoriales, así como de la identidad de su responsable, su domicilio y la finalidad del tratamiento. El afectado podrá solicitar su exclusión respecto de un fichero o tratamien- to concreto o su inclusión en ficheros comunes de excluidos de carácter general o sectorial. 3. La entidad responsable del fichero común podrá tratar los datos de los interesados que hubieran manifestado su negativa u oposición al tratamiento de sus datos con fines de publicidad o prospección comercial, cumpliendo las restantes obligaciones establecidas en la Ley Orgánica 15/ 1999, de 13 de diciembre, y en el presente Reglamento. 4. Quienes pretendan efectuar un tratamiento relacionado con actividades de publicidad o prospección comercial deberán previamente consultar los ficheros comunes que pudieran afectar a su actuación, a fin de evitar que sean objeto de tratamiento los datos de los afectados que hubieran manifestado su oposición o negativa a ese tratamiento. Artículo 50. Derechos de acceso, rectificación y cancelación. 1. El ejercicio de los derechos de acceso, rectificación y cancelación en rela- ción con los tratamientos vinculados a actividades de publicidad y pros- pección comercial se someterá a lo previsto en los capítulos I a IV del título III de este reglamento. 338

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal 2. Si el derecho se ejercitase ante una entidad que hubiese encargado a un tercero la realización de una campaña publicitaria, aquélla estará obligada, en el plazo de diez días, desde la recepción de la comunicación de la solicitud de ejercicio de derechos del afectado, a comunicar la solicitud al responsable del fichero a fin de que el mismo otorgue al afectado su derecho en el plazo de diez días desde la recepción de la comunicación, dando cuenta de ello al afectado. Lo dispuesto en el párrafo anterior se entenderá sin perjuicio del deber impuesto a la entidad mencionada en el apartado anterior, en todo caso, por el párrafo segundo del artículo 5.5 de la Ley Orgánica 15/1999, de 13 de diciembre. Artículo 51. Derecho de oposición. 1. Los interesados tendrán derecho a oponerse, previa petición y sin gastos, al tratamiento de los datos que les conciernan, en cuyo caso serán dados de baja del tratamiento, cancelándose las informaciones que sobre ellos figuren en aquél, a su simple solicitud. La oposición a la que se refiere el párrafo anterior deberá entenderse sin perjuicio del derecho del interesado a revocar cuando lo estimase oportuno el consentimiento que hubiera otorgado, en su caso, para el tratamiento de los datos. 2. A tal efecto, deberá concederse al interesado un medio sencillo y gratuito para oponerse al tratamiento. En particular, se considerará cumplido lo dispuesto en este precepto cuando los derechos puedan ejercitarse mediante la llamada a un número telefónico gratuito o la remisión de un correo electrónico. 3. Cuando el responsable del fichero o tratamiento disponga de servicios de cualquier índole para la atención a sus clientes o el ejercicio de reclamaciones relacionadas con el servicio prestado o los productos ofertados al mismo, deberá concederse la posibilidad al afectado de ejercer su oposi- ción a través de dichos servicios. No se considerarán conformes a lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, los supuestos en que el responsable del tratamiento establezca como medio para que el interesado pueda ejercitar su oposición el envío de cartas certificadas o envíos semejantes, la utilización de servicios de telecomunicaciones que implique una tarificación adicional al afectado o cualesquiera otros medios que impliquen un coste excesivo para el interesado. En todo caso, el ejercicio por el afectado de sus derechos no podrá suponer un ingreso adicional para el responsable del tratamiento ante el que se ejercitan. 339

La protección de datos personales: Soluciones en entornos Microsoft 4. Si el derecho de oposición se ejercitase ante una entidad que hubiera encomendado a un tercero la realización de una campaña publicitaria, aquélla estará obligada, en el plazo de diez días, desde la recepción de la comunicación de la solicitud de ejercicio de derechos del afectado, a comunicar la solicitud al responsable del fichero a fin de que el mismo atienda el derecho del afectado en el plazo de diez días desde la recepción de la comunicación, dando cuenta de ello al afectado. Lo dispuesto en el párrafo anterior se entenderá sin perjuicio del deber impuesto a la entidad mencionada en el apartado anterior, en todo caso, por el párrafo segundo del artículo 5.5 de la Ley Orgánica 15/1999, de 13 de diciembre. TÍTULO V. Obligaciones previas al tratamiento de los datos CAPÍTULO I. Creación, modificación o supresión de ficheros de titularidad pública Artículo 52. Disposición o Acuerdo de creación, modificación o supresión del fichero. 1. La creación, modificación o supresión de los ficheros de titularidad públi- ca sólo podrá hacerse por medio de disposición general o acuerdo publicados en el «Boletín Oficial del Estado» o diario oficial correspondiente. 2. En todo caso, la disposición o acuerdo deberá dictarse y publicarse con carácter previo a la creación, modificación o supresión del fichero. Artículo 53. Forma de la disposición o acuerdo. 1. Cuando la disposición se refiera a los órganos de la Administración General del Estado o a las entidades u organismos vinculados o dependientes de la misma, deberá revestir la forma de orden ministerial o resolución del titular de la entidad u organismo correspondiente. 2. En el caso de los órganos constitucionales del Estado, se estará a lo que establezcan sus normas reguladoras. 3. En relación con los ficheros de los que sean responsables las comunidades autónomas, entidades locales y las entidades u organismos vinculados o dependientes de las mismas, las universidades públicas, así como los órganos de las comunidades autónomas con funciones análogas a los órganos constitucionales del Estado, se estará a su legislación específica. 4. La creación, modificación o supresión de los ficheros de los que sean responsables las corporaciones de derecho público y que se encuentren relacionados con el ejercicio por aquéllas de potestades de derecho público deberá efectuarse a través de acuerdo de sus órganos de gobierno, en los términos que establezcan sus respectivos Estatutos, debiendo ser igual- 340

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal mente objeto de publicación en el «Boletín Oficial del Estado» o diario oficial correspondiente. Artículo 54. Contenido de la disposición o acuerdo. 1. La disposición o acuerdo de creación del fichero deberá contener los siguientes extremos: a) La identificación del fichero o tratamiento, indicando su denomina- ción, así como la descripción de su finalidad y usos previstos. b) El origen de los datos, indicando el colectivo de personas sobre los que se pretende obtener datos de carácter personal o que resulten obligados a suministrarlos, el procedimiento de recogida de los datos y su procedencia. c) La estructura básica del fichero mediante la descripción detallada de los datos identificativos, y en su caso, de los datos especialmente protegidos, así como de las restantes categorías de datos de carácter personal incluidas en el mismo y el sistema de tratamiento utilizado en su organización. d) Las comunicaciones de datos previstas, indicando en su caso, los destinatarios o categorías de destinatarios. e) Las transferencias internacionales de datos previstas a terceros países, con indicación, en su caso, de los países de destino de los datos. f) Los órganos responsables del fichero. g) Los servicios o unidades ante los que pudiesen ejercitarse los derechos de acceso, rectificación, cancelación y oposición. h) El nivel básico, medio o alto de seguridad que resulte exigible, de acuerdo con lo establecido en el título VIII del presente reglamento. 2. La disposición o acuerdo de modificación del fichero deberá indicar las modificaciones producidas en cualquiera de los extremos a los que se refiere el apartado anterior. 3. En las disposiciones o acuerdos que se dicten para la supresión de los ficheros se establecerá el destino que vaya a darse a los datos o, en su caso, las previsiones que se adopten para su destrucción. CAPÍTULO II. Notificación e inscripción de los ficheros de titularidad pública o privada Artículo 55. Notificación de ficheros. 1. Todo fichero de datos de carácter personal de titularidad pública será notificado a la Agencia Española de Protección de Datos por el órgano competente de la Administración responsable del fichero para su inscripción en 341

La protección de datos personales: Soluciones en entornos Microsoft el Registro General de Protección de Datos, en el plazo de treinta días desde la publicación de su norma o acuerdo de creación en el diario oficial correspondiente. 2. Los ficheros de datos de carácter personal de titularidad privada serán notificados a la Agencia Española de Protección de Datos por la persona o entidad privada que pretenda crearlos, con carácter previo a su creación. La notificación deberá indicar la identificación del responsable del fichero, la identificación del fichero, sus finalidades y los usos previstos, el sistema de tratamiento empleado en su organización, el colectivo de personas sobre el que se obtienen los datos, el procedimiento y procedencia de los datos, las categorías de datos, el servicio o unidad de acceso, la indicación del nivel de medidas de seguridad básico, medio o alto exigible, y en su caso, la identificación del encargado del tratamiento en donde se encuentre ubicado el fichero y los destinatarios de cesiones y transferencias internacionales de datos. 3. Cuando la obligación de notificar afecte a ficheros sujetos a la competencia de la autoridad de control de una comunidad autónoma que haya creado su propio registro de ficheros, la notificación se realizará a la autoridad autonómica competente, que dará traslado de la inscripción al Registro General de Protección de Datos. El Registro General de Protección de Datos podrá solicitar de las autoridades de control de las comunidades autónomas el traslado al que se refiere el párrafo anterior, procediendo, en su defecto, a la inclusión de oficio del fichero en el Registro. 4. La notificación se realizará conforme al procedimiento establecido en la sección primera del capítulo IV del título IX del presente reglamento. Artículo 56. Tratamiento de datos en distintos soportes. 1. La notificación de un fichero de datos de carácter personal es independiente del sistema de tratamiento empleado en su organización y del soporte o soportes empleados para el tratamiento de los datos. 2. Cuando los datos de carácter personal objeto de un tratamiento estén almacenados en diferentes soportes, automatizados y no automatizados o exista una copia en soporte no automatizado de un fichero automatizado sólo será precisa una sola notificación, referida a dicho fichero. Artículo 57. Ficheros en los que exista más de un responsable. Cuando se tenga previsto crear un fichero del que resulten responsables varias personas o entidades simultáneamente, cada una de ellas deberá notificar, a fin de proceder a su inscripción en el Registro General de Protección de Datos y, en su caso, en los Registros de Ficheros creados por las autoridades de control de las comunidades autónomas, la creación del correspondiente fichero. 342

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal Artículo 58. Notificación de la modificación o supresión de ficheros. 1. La inscripción del fichero deberá encontrarse actualizada en todo momen- to. Cualquier modificación que afecte al contenido de la inscripción de un fichero deberá ser previamente notificada a la Agencia Española de Protección de Datos o a las autoridades de control autonómicas competentes, a fin de proceder a su inscripción en el registro correspondiente, conforme a lo dispuesto en el artículo 55. 2. Cuando el responsable del fichero decida su supresión, deberá notificarla a efectos de que se proceda a la cancelación de la inscripción en el registro correspondiente. 3. Tratándose de ficheros de titularidad pública, cuando se pretenda la modificación que afecte a alguno de los requisitos previstos en el artículo 55 o la supresión del fichero deberá haberse adoptado, con carácter previo a la notificación la correspondiente norma o acuerdo en los términos previstos en el capítulo I de este título. Artículo 59. Modelos y soportes para la notificación. 1. La Agencia Española de Protección de Datos publicará mediante la correspondiente Resolución del Director los modelos o formularios electrónicos de notificación de creación, modificación o supresión de ficheros, que permitan su presentación a través de medios telemáticos o en soporte papel, así como, previa consulta de las autoridades de protección de datos de las comunidades autónomas, los formatos para la comunicación telemática de ficheros públicos por las autoridades de control autonómi- cas, de conformidad con lo establecido en los artículos 55 y 58 del presente reglamento. 2. Los modelos o formularios electrónicos de notificación se podrán obtener gratuitamente en la página web de la Agencia Española de Protección de Datos. 3. El Director de la Agencia Española de Protección de Datos podrá establecer procedimientos simplificados de notificación en atención a las circunstancias que concurran en el tratamiento o el tipo de fichero al que se refiera la notificación. Artículo 60. Inscripción de los ficheros. 1. El Director de la Agencia Española de Protección de Datos, a propuesta del Registro General de Protección de Datos, dictará resolución acordando, en su caso, la inscripción, una vez tramitado el procedimiento previsto en el capítulo IV del título IX. 2. La inscripción contendrá el código asignado por el Registro, la identifica- ción del responsable del fichero, la identificación del fichero o tratamiento, la descripción de su finalidad y usos previstos, el sistema de tratamiento 343

La protección de datos personales: Soluciones en entornos Microsoft empleado en su organización, en su caso, el colectivo de personas sobre el que se obtienen los datos, el procedimiento y procedencia de los datos, las categorías de datos, el servicio o unidad de acceso, y la indicación del nivel de medidas de seguridad exigible conforme a lo dispuesto en el artículo 81. Asimismo, se incluirán, en su caso, la identificación del encargado del tratamiento en donde se encuentre ubicado el fichero y los destinatarios de cesiones y transferencias internacionales. En el caso de ficheros de titularidad pública también se hará constar la referencia de la disposición general por la que ha sido creado, y en su caso, modificado. 3. La inscripción de un fichero en el Registro General de Protección de Datos, no exime al responsable del cumplimiento del resto de las obligaciones previstas en la Ley Orgánica 15/1999, de 13 de diciembre, y demás disposiciones reglamentarias. Artículo 61. Cancelación de la inscripción. 1. Cuando el responsable del tratamiento comunicase, en virtud de lo dispuesto en el artículo 58 de este reglamento, la supresión del fichero, el Director de la Agencia Española de Protección de Datos, previa la tramita- ción del procedimiento establecido en la sección primera del capítulo IV del título IX, dictará resolución acordando la cancelación de la inscripción correspondiente al fichero. 2. El Director de la Agencia Española de Protección de Datos podrá, en ejercicio de sus competencias, acordar de oficio la cancelación de la inscripción de un fichero cuando concurran circunstancias que acrediten la imposibilidad de su existencia, previa la tramitación del procedimiento establecido en la sección segunda del capítulo IV del título IX de este reglamento. Artículo 62. Rectificación de errores. El Registro General de Protección de Datos podrá rectificar en cualquier momento, de oficio o a instancia de los interesados, los errores materiales, de hecho o aritméticos que pudieran existir en las inscripciones, de conformidad con lo dispuesto en el artículo 105 de la Ley 30/1992, de 26 de noviembre. Artículo 63. Inscripción de oficio de ficheros de titularidad pública. 1. En supuestos excepcionales con el fin de garantizar el derecho a la protec- ción de datos de los afectados, y sin perjuicio de la obligación de notifica- ción, se podrá proceder a la inscripción de oficio de un determinado fichero en el Registro General de Protección de Datos. 344

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal 2. Para que lo dispuesto en el apartado anterior resulte de aplicación, será requisito indispensable que la correspondiente norma o acuerdo regulador de los ficheros que contengan datos de carácter personal haya sido publicado en el correspondiente diario oficial y cumpla los requisitos establecidos en la Ley Orgánica 15/1999, de 13 de diciembre, y el presente reglamento. 3. El Director de la Agencia Española de Protección de Datos podrá, a propuesta del Registro General de Protección de Datos, acordar la inscrip- ción del fichero de titularidad pública en el Registro, notificándose dicho acuerdo al órgano responsable del fichero. Cuando la inscripción se refiera a ficheros sujetos a la competencia de la autoridad de control de una comunidad autónoma que haya creado su propio registro de ficheros, se comunicará a la referida autoridad de control autonómica para que proceda, en su caso, a la inscripción de oficio. Artículo 64. Colaboración con las autoridades de control de las comunidades autónomas. El Director de la Agencia Española de Protección de Datos podrá celebrar con los directores de las autoridades de control de las comunidades autónomas los convenios de colaboración o acuerdos que estime pertinentes, a fin de garantizar la inscripción en el Registro General de Protección de Datos de los ficheros sometidos a la competencia de dichas autoridades autonómicas. TÍTULO VI. Transferencias internacionales de datos CAPÍTULO I. Disposiciones generales Artículo 65. Cumplimiento de las disposiciones de la Ley Orgánica 15/ 1999, de 13 de diciembre. La transferencia internacional de datos no excluye en ningún caso la aplicación de las disposiciones contenidas en la Ley Orgánica 15/1999, de 13 de diciembre, y en el presente reglamento. Artículo 66. Autorización y notificación. 1. Para que la transferencia internacional de datos pueda considerarse conforme a lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, y en el presente Reglamento será necesaria la autorización del Director de la Agencia Española de Protección de Datos, que se otorgará en caso de que el exportador aporte las garantías a las que se refiere el artículo 70 del presente reglamento. La autorización se otorgará conforme al procedimiento establecido en la sección primera del capítulo V del título IX de este reglamento. 345

La protección de datos personales: Soluciones en entornos Microsoft 2. La autorización no será necesaria: a) Cuando el Estado en el que se encontrase el importador ofrezca un nivel adecuado de protección conforme a lo previsto en el capítulo II de este título. b) Cuando la transferencia se encuentre en uno de los supuestos contemplados en los apartados a) a j) del artículo 34 de la Ley Orgánica 15/ 1999, de 13 de diciembre. 3. En todo caso, la transferencia internacional de datos deberá ser notificada a fin de proceder a su inscripción en el Registro General de Protección de Datos, conforme al procedimiento establecido en la sección primera del capítulo IV del título IX del presente reglamento. CAPÍTULO II. Transferencias a estados que proporcionen un nivel adecuado de protección Artículo 67. Nivel adecuado de protección acordado por la Agencia Española de Protección de Datos. 1. No será precisa autorización del Director de la Agencia Española de Protección de Datos a una transferencia internacional de datos cuando las normas aplicables al Estado en que se encontrase el importador ofrezcan dicho nivel adecuado de protección a juicio del Director de la Agencia Española de Protección de Datos. El carácter adecuado del nivel de protección que ofrece el país de destino se evaluará atendiendo a todas las circunstancias que concurran en la transferencia o categoría de transferencia de datos. En particular, se tomará en consideración la naturaleza de los datos, la finalidad y la duración del tratamiento o de los tratamientos previstos, el país de origen y el país de destino final, las normas de Derecho, generales o sectoriales, vigentes en el país tercero de que se trate, el contenido de los informes de la Comisión de la Unión Europea, así como las normas profesionales y las medidas de seguridad en vigor en dichos países. Las resoluciones del Director de la Agencia Española de Protección de Datos por las que se acordase que un determinado país proporciona un nivel adecuado de protección de datos serán publicadas en el «Boletín Oficial del Estado». 2. El Director de la Agencia Española de Protección de Datos acordará la publicación de la relación de países cuyo nivel de protección haya sido considerado equiparable conforme a lo dispuesto en el apartado anterior. Esta lista se publicará y mantendrá actualizada asimismo a través de medios informáticos o telemáticos. 346

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal Artículo 68. Nivel adecuado de protección declarado por Decisión de la Comisión Europea. No será necesaria la autorización del Director de la Agencia Española de Protección de Datos para la realización de una transferencia internacional de datos que tuvieran por importador una persona o entidad, pública o privada, situada en el territorio de un Estado respecto del que se haya declarado por la Comisión Europea la existencia de un nivel adecuado de protección. Artículo 69. Suspensión temporal de las transferencias. 1. En los supuestos previstos en los artículos precedentes, el Director de la Agencia Española de Protección de Datos, en uso de la potestad que le otorga el artículo 37.1 f) de la Ley Orgánica 15/1999, de 13 de diciembre, podrá acordar, previa audiencia del exportador, la suspensión temporal de la transferencia de datos hacia un importador ubicado en un tercer Estado del que se haya declarado la existencia de un nivel adecuado de protec- ción, cuando concurra alguna de las circunstancias siguientes: a) Que las autoridades de Protección de Datos del Estado importador o cualquier otra competente, en caso de no existir las primeras, resuel- van que el importador ha vulnerado las normas de protección de datos establecidas en su derecho interno. b) Que existan indicios racionales de que se estén vulnerando las normas o, en su caso, los principios de protección de datos por la entidad importadora de la transferencia y que las autoridades competentes en el Estado en que se encuentre el importador no han adoptado o no van a adoptar en el futuro las medidas oportunas para resolver el caso en cuestión, habiendo sido advertidas de la situación por la Agencia Española de Protección de Datos. En este caso se podrá suspender la transferencia cuando su continuación pudiera generar un riesgo inminente de grave perjuicio a los afectados. 2. La suspensión se acordará previa la tramitación del procedimiento establecido en la sección segunda del capítulo V del título IX del presente reglamento. En estos casos, la decisión del Director de la Agencia Española de Protec- ción de Datos será notificada a la Comisión Europea. CAPÍTULO III. Transferencias a Estados que no proporcionen un nivel adecuado de protección Artículo 70. Transferencias sujetas a autorización del Director de la Agen- cia Española de Protección de Datos. 1. Cuando la transferencia tenga por destino un Estado respecto del que no se haya declarado por la Comisión Europea o no se haya considerado por 347

La protección de datos personales: Soluciones en entornos Microsoft el Director de la Agencia Española de Protección de Datos que existe un nivel adecuado de protección, será necesario recabar la autorización del Director de la Agencia Española de Protección de Datos. La autorización de la transferencia se tramitará conforme al procedimien- to establecido en la sección primera del capítulo V del título IX del presente reglamento. 2. La autorización podrá ser otorgada en caso de que el responsable del fichero o tratamiento aporte un contrato escrito, celebrado entre el exportador y el importador, en el que consten las necesarias garantías de respeto a la protección de la vida privada de los afectados y a sus derechos y libertades fundamentales y se garantice el ejercicio de sus respectivos derechos. A tal efecto, se considerará que establecen las adecuadas garantías los contratos que se celebren de acuerdo con lo previsto en las Decisiones de la Comisión Europea 2001/497/CE, de 15 de Junio de 2001, 2002/16/CE, de 27 de diciembre de 2001, y 2004/915/CE, de 27 de diciembre de 2004 o de lo que dispongan las Decisiones de la Comisión que den cumplimiento a lo establecido en el artículo 26.4 de la Directiva 95/46/CE. 3. En el supuesto contemplado en el apartado anterior, el Director de la Agencia Española de Protección de Datos podrá denegar o, en uso de la potestad que le otorga el artículo 37.1 f) de la Ley Orgánica 15/1999, de 13 de diciembre, suspender temporalmente, previa audiencia del exportador, la transferencia, cuando concurra alguna de las circunstancias siguientes: a) Que la situación de protección de los derechos fundamentales y libertades públicas en el país de destino o su legislación impidan garantizar el íntegro cumplimiento del contrato y el ejercicio por los afectados de los derechos que el contrato garantiza. b) Que la entidad destinataria haya incumplido previamente las garan- tías establecidas en cláusulas contractuales de este tipo. c) Que existan indicios racionales de que las garantías ofrecidas por el contrato no están siendo o no serán respetadas por el importador. d) Que existan indicios racionales de que los mecanismos de aplicación del contrato no son o no serán efectivos. e) Que la transferencia, o su continuación, en caso de haberse iniciado, pudiera crear una situación de riesgo de daño efectivo a los afectados. La suspensión se acordará previa la tramitación del procedimiento establecido en la sección segunda del capítulo V del título IX del presente reglamento. Las resoluciones del Director de la Agencia Española de Protección de Datos por las que se deniegue o suspenda una transferencia internacional de datos en virtud de las causas a las que se refiere este aparta- 348

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal do serán notificadas a la Comisión de las Comunidades Europeas cuando así sea exigible. 4. También podrá otorgarse la autorización para la transferencia internacional de datos en el seno de grupos multinacionales de empresas cuando hubiesen sido adoptados por los mismos normas o reglas internas en que consten las necesarias garantías de respeto a la protección de la vida privada y el derecho fundamental a la protección de datos de los afectados y se garantice asimismo el cumplimiento de los principios y el ejercicio de los derechos reconocidos en la Ley Orgánica 15/1999, de 13 de diciembre, y el presente reglamento. En este caso, para que proceda la autorización del Director de la Agencia Española de Protección de Datos será preciso que las normas o reglas resulten vinculantes para las empresas del Grupo y exigibles conforme al ordenamiento jurídico español. En todo caso, la autorización del Director de la Agencia Española de Protección de Datos implicará la exigibilidad de lo previsto en las normas o reglas internas tanto por la Agencia como por los afectados cuyos datos hubieran sido objeto de tratamiento. TÍTULO VII. Códigos tipo Artículo 71. Objeto y naturaleza. 1. Los códigos tipo a los que se refiere el artículo 32 de la Ley Orgánica 15/ 1999, de 13 de diciembre, tienen por objeto adecuar lo establecido en la citada Ley Orgánica y en el presente reglamento a las peculiaridades de los tratamientos efectuados por quienes se adhieren a los mismos. A tal efecto, contendrán reglas o estándares específicos que permitan armonizar los tratamientos de datos efectuados por los adheridos, facilitar el ejercicio de los derechos de los afectados y favorecer el cumplimiento de lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, y el presente reglamento. 2. Los códigos tipo tendrán el carácter de códigos deontológicos o de buena práctica profesional y serán vinculantes para quienes se adhieran a los mismos. Artículo 72. Iniciativa y ámbito de aplicación. 1. Los códigos tipo tendrán carácter voluntario. 2. Los códigos tipo de carácter sectorial podrán referirse a la totalidad o a parte de los tratamientos llevados a cabo por entidades pertenecientes a un mismo sector, debiendo ser formulados por organizaciones representa- tivas de dicho sector, al menos en su ámbito territorial de aplicación, y sin 349

La protección de datos personales: Soluciones en entornos Microsoft perjuicio de la potestad de dichas entidades de ajustar el código tipo a sus peculiaridades. 3. Los códigos tipo promovidos por una empresa deberán referirse a la totalidad de los tratamientos llevados a cabo por la misma. 4. Las Administraciones públicas y las corporaciones de Derecho Público podrán adoptar códigos tipo de acuerdo con lo establecido en las normas que les sean aplicables. Artículo 73. Contenido. 1. Los códigos tipo deberán estar redactados en términos claros y accesibles. 2. Los códigos tipo deben respetar la normativa vigente e incluir, como mínimo, con suficiente grado de precisión: a) La delimitación clara y precisa de su ámbito de aplicación, las actividades a que el código se refiere y los tratamientos sometidos al mismo. b) Las previsiones específicas para la aplicación de los principios de protección de datos. c) El establecimiento de estándares homogéneos para el cumplimiento por los adheridos al código de las obligaciones establecidas en la Ley Orgánica 15/1999, de 13 de diciembre. d) El establecimiento de procedimientos que faciliten el ejercicio por los afectados de sus derechos de acceso, rectificación, cancelación y oposición. e) La determinación de las cesiones y transferencias internacionales de datos que, en su caso, se prevean, con indicación de las garantías que deban adoptarse. f) Las acciones formativas en materia de protección de datos dirigidas a quienes los traten, especialmente en cuanto a su relación con los afectados. g) Los mecanismos de supervisión a través de los cuales se garantice el cumplimiento por los adheridos de lo establecido en el código tipo, en los términos previstos en el artículo 74 de este reglamento. 3. En particular, deberán contenerse en el código: a) Cláusulas tipo para la obtención del consentimiento de los afectados al tratamiento o cesión de sus datos. b) Cláusulas tipo para informar a los afectados del tratamiento, cuando los datos no sean obtenidos de los mismos. c) Modelos para el ejercicio por los afectados de sus derechos de acceso, rectificación, cancelación y oposición. 350

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal d) Modelos de cláusulas para el cumplimiento de los requisitos formales exigibles para la contratación de un encargado del tratamiento, en su caso. Artículo 74. Compromisos adicionales. 1. Los códigos tipo podrán incluir cualquier otro compromiso adicional que asuman los adheridos para un mejor cumplimiento de la legislación vigente en materia de protección de datos. 2. Además podrán contener cualquier otro compromiso que puedan establecer las entidades promotoras y, en particular, sobre: a) La adopción de medidas de seguridad adicionales a las exigidas por la Ley Orgánica 15/1999, de 13 de diciembre, y el presente Reglamento. b) La identificación de las categorías de cesionarios o importadores de los datos. c) Las medidas concretas adoptadas en materia de protección de los menores o de determinados colectivos de afectados. d) El establecimiento de un sello de calidad que identifique a los adheridos al código. Artículo 75. Garantías del cumplimiento de los códigos tipo. 1. Los códigos tipo deberán incluir procedimientos de supervisión independientes para garantizar el cumplimiento de las obligaciones asumidas por los adheridos, y establecer un régimen sancionador adecuado, eficaz y disuasorio. 2. El procedimiento que se prevea deberá garantizar: a) La independencia e imparcialidad del órgano responsable de la supervisión. b) La sencillez, accesibilidad, celeridad y gratuidad para la presentación de quejas y reclamaciones ante dicho órgano por los eventuales incumplimientos del código tipo. c) El principio de contradicción. d) Una graduación de sanciones que permita ajustarlas a la gravedad del incumplimiento. Esas sanciones deberán ser disuasorias y podrán implicar la suspensión de la adhesión al código o la expulsión de la entidad adherida. Asimismo, podrá establecerse, en su caso, su publicidad. e) La notificación al afectado de la decisión adoptada. 3. Asimismo, y sin perjuicio de lo dispuesto en el artículo 19 de la Ley Orgánica 15/1999, de 13 de diciembre, los códigos tipo podrán contemplar procedimientos para la determinación de medidas reparadoras en 351

La protección de datos personales: Soluciones en entornos Microsoft caso de haberse causado un perjuicio a los afectados como consecuencia del incumplimiento del código tipo. 4. Lo dispuesto en este artículo se aplicará sin perjuicio de las competencias de la Agencia Española de Protección de Datos y, en su caso, de las autoridades de control de las comunidades autónomas. Artículo 76. Relación de adheridos. El código tipo deberá incorporar como anexo una relación de adheridos, que deberá mantenerse actualizada, a disposición de la Agencia Española de Protección de Datos. Artículo 77. Depósito y publicidad de los códigos tipo. 1. Para que los códigos tipo puedan ser considerados como tales a los efectos previstos en el artículo 32 de la Ley Orgánica 15/1999, de 13 de diciembre, y el presente reglamento, deberán ser depositados e inscritos en el Regis- tro General de Protección de Datos de la Agencia Española de Protección de Datos o, cuando corresponda, en el registro que fuera creado por las comunidades autónomas, que darán traslado para su inclusión al Registro General de Protección de Datos. 2. A tal efecto, los códigos tipo deberán ser presentados ante la correspondiente autoridad de control, tramitándose su inscripción, en caso de estar sometidos a la decisión de la Agencia Española de Protección de Datos, conforme al procedimiento establecido en el capítulo VI del título IX de este reglamento. 3. En todo caso, la Agencia Española de Protección de Datos dará publicidad a los códigos tipo inscritos, preferentemente a través de medios informáticos o telemáticos. Artículo 78. Obligaciones posteriores a la inscripción del código tipo. Las entidades promotoras o los órganos, personas o entidades que al efecto se designen en el propio código tipo tendrán, una vez el mismo haya sido publicado, las siguientes obligaciones: a) Mantener accesible al público la información actualizada sobre las entidades promotoras, el contenido del código tipo, los procedimientos de adhesión y de garantía de su cumplimiento y la relación de adheridos a la que se refiere el artículo anterior. Esta información deberá presentarse de forma concisa y clara y estar permanentemente accesible por medios electrónicos. b) Remitir a la Agencia Española de Protección de Datos una memoria anual sobre las actividades realizadas para difundir el código tipo y promover la adhesión a éste, las actuaciones de verificación del cumplimiento del 352

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal código y sus resultados, las quejas y reclamaciones tramitadas y el curso que se les hubiera dado y cualquier otro aspecto que las entidades promotoras consideren adecuado destacar. Cuando se trate de códigos tipo inscritos en el registro de una autoridad de control de una comunidad autónoma, la remisión se realizará a dicha autoridad, que dará traslado al registro General de Protección de Datos. c) Evaluar periódicamente la eficacia del código tipo, midiendo el grado de satisfacción de los afectados y, en su caso, actualizar su contenido para adaptarlo a la normativa general o sectorial de protección de datos existente en cada momento. Esta evaluación deberá tener lugar, al menos, cada cuatro años, salvo que sea precisa la adaptación de los compromisos del código a la modificación de la normativa aplicable en un plazo menor. d) Favorecer la accesibilidad de todas las personas, con especial atención a las que tengan alguna discapacidad o de edad avanzada a toda la infor- mación disponible sobre el código tipo. TÍTULO VIII. De las medidas de seguridad en el tratamiento de datos de carácter personal CAPÍTULO I. Disposiciones generales Artículo 79. Alcance. Los responsables de los tratamientos o los ficheros y los encargados del tratamiento deberán implantar las medidas de seguridad con arreglo a lo dispuesto en este Título, con independencia de cual sea su sistema de tratamiento. Artículo 80. Niveles de seguridad. Las medidas de seguridad exigibles a los ficheros y tratamientos se clasifican en tres niveles: básico, medio y alto. Artículo 81. Aplicación de los niveles de seguridad. 1. Todos los ficheros o tratamientos de datos de carácter personal deberán adoptar las medidas de seguridad calificadas de nivel básico. 2. Deberán implantarse, además de las medidas de seguridad de nivel básico, las medidas de nivel medio, en los siguientes ficheros o tratamientos de datos de carácter personal: a) Los relativos a la comisión de infracciones administrativas o penales. b) Aquellos cuyo funcionamiento se rija por el artículo 29 de la Ley Orgánica 15/1999, de 13 de diciembre. 353

La protección de datos personales: Soluciones en entornos Microsoft c) Aquellos de los que sean responsables Administraciones tributarias y se relacionen con el ejercicio de sus potestades tributarias. d) Aquéllos de los que sean responsables las entidades financieras para finalidades relacionadas con la prestación de servicios financieros. e) Aquéllos de los que sean responsables las Entidades Gestoras y Servicios Comunes de la Seguridad Social y se relacionen con el ejercicio de sus competencias. De igual modo, aquellos de los que sean responsables las mutuas de accidentes de trabajo y enfermedades profesionales de la Seguridad Social. f) Aquéllos que contengan un conjunto de datos de carácter personal que ofrezcan una definición de las características o de la personalidad de los ciudadanos y que permitan evaluar determinados aspectos de la personalidad o del comportamiento de los mismos. 3. Además de las medidas de nivel básico y medio, las medidas de nivel alto se aplicarán en los siguientes ficheros o tratamientos de datos de carácter personal: a) Los que se refieran a datos de ideología, afiliación sindical, religión, creencias, origen racial, salud o vida sexual. b) Los que contengan o se refieran a datos recabados para fines policiales sin consentimiento de las personas afectadas. c) Aquéllos que contengan datos derivados de actos de violencia de género. 4. A los ficheros de los que sean responsables los operadores que presten servicios de comunicaciones electrónicas disponibles al público o exploten redes públicas de comunicaciones electrónicas respecto a los datos de tráfico y a los datos de localización, se aplicarán, además de las medidas de seguridad de nivel básico y medio, la medida de seguridad de nivel alto contenida en el artículo 103 de este reglamento. 5. En caso de ficheros o tratamientos de datos de ideología, afiliación sindical, religión, creencias, origen racial, salud o vida sexual bastará la implan- tación de las medidas de seguridad de nivel básico cuando: a) Los datos se utilicen con la única finalidad de realizar una transferencia dineraria a las entidades de las que los afectados sean asociados o miembros. b) Se trate de ficheros o tratamientos no automatizados en los que de forma incidental o accesoria se contengan aquellos datos sin guardar relación con su finalidad. 6. También podrán implantarse las medidas de seguridad de nivel básico en los ficheros o tratamientos que contengan datos relativos a la salud, referentes exclusivamente al grado de discapacidad o la simple declara- ción de la condición de discapacidad o invalidez del afectado, con motivo del cumplimiento de deberes públicos. 354

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal 7. Las medidas incluidas en cada uno de los niveles descritos anteriormente tienen la condición de mínimos exigibles, sin perjuicio de las disposiciones legales o reglamentarias específicas vigentes que pudieran resultar de aplicación en cada caso o las que por propia iniciativa adoptase el responsable del fichero. 8. A los efectos de facilitar el cumplimiento de lo dispuesto en este título, cuando en un sistema de información existan ficheros o tratamientos que en función de su finalidad o uso concreto, o de la naturaleza de los datos que contengan, requieran la aplicación de un nivel de medidas de seguridad diferente al del sistema principal, podrán segregarse de este último, siendo de aplicación en cada caso el nivel de medidas de seguridad correspondiente y siempre que puedan delimitarse los datos afectados y los usuarios con acceso a los mismos, y que esto se haga constar en el documento de seguridad. Artículo 82. Encargado del tratamiento. 1. Cuando el responsable del fichero o tratamiento facilite el acceso a los datos, a los soportes que los contengan o a los recursos del sistema de información que los trate, a un encargado de tratamiento que preste sus servicios en los locales del primero deberá hacerse constar esta circunstancia en el documento de seguridad de dicho responsable, comprometiéndo- se el personal del encargado al cumplimiento de las medidas de seguridad previstas en el citado documento. Cuando dicho acceso sea remoto habiéndose prohibido al encargado incorporar tales datos a sistemas o soportes distintos de los del responsable, este último deberá hacer constar esta circunstancia en el documento de seguridad del responsable, comprometiéndose el personal del encargado al cumplimiento de las medidas de seguridad previstas en el citado documento. 2. Si el servicio fuera prestado por el encargado del tratamiento en sus propios locales, ajenos a los del responsable del fichero, deberá elaborar un documento de seguridad en los términos exigidos por el artículo 88 de este reglamento o completar el que ya hubiera elaborado, en su caso, identificando el fichero o tratamiento y el responsable del mismo e incorporando las medidas de seguridad a implantar en relación con dicho tratamiento. 3. En todo caso, el acceso a los datos por el encargado del tratamiento estará sometido a las medidas de seguridad contempladas en este reglamento. Artículo 83. Prestaciones de servicios sin acceso a datos personales. El responsable del fichero o tratamiento adoptará las medidas adecuadas para limitar el acceso del personal a datos personales, a los soportes que los contengan o a los recursos del sistema de información, para la realización de trabajos que no impliquen el tratamiento de datos personales. 355

La protección de datos personales: Soluciones en entornos Microsoft Cuando se trate de personal ajeno, el contrato de prestación de servicios recogerá expresamente la prohibición de acceder a los datos personales y la obliga- ción de secreto respecto a los datos que el personal hubiera podido conocer con motivo de la prestación del servicio. Artículo 84. Delegación de autorizaciones. Las autorizaciones que en este título se atribuyen al responsable del fichero o tratamiento podrán ser delegadas en las personas designadas al efecto. En el documento de seguridad deberán constar las personas habilitadas para otorgar estas autorizaciones así como aquellas en las que recae dicha delegación. En ningún caso esta designación supone una delegación de la responsabilidad que corresponde al responsable del fichero. Artículo 85. Acceso a datos a través de redes de comunicaciones. Las medidas de seguridad exigibles a los accesos a datos de carácter personal a través de redes de comunicaciones, sean o no públicas, deberán garantizar un nivel de seguridad equivalente al correspondiente a los accesos en modo local, conforme a los criterios establecidos en el artículo 80. Artículo 86. Régimen de trabajo fuera de los locales del responsable del fichero o encargado del tratamiento. 1. Cuando los datos personales se almacenen en dispositivos portátiles o se traten fuera de los locales del responsable de fichero o tratamiento, o del encargado del tratamiento será preciso que exista una autorización previa del responsable del fichero o tratamiento, y en todo caso deberá garanti- zarse el nivel de seguridad correspondiente al tipo de fichero tratado. 2. La autorización a la que se refiere el párrafo anterior tendrá que constar en el documento de seguridad y podrá establecerse para un usuario o para un perfil de usuarios y determinando un periodo de validez para las mismas. Artículo 87. Ficheros temporales o copias de trabajo de documentos. 1. Aquellos ficheros temporales o copias de documentos que se hubiesen creado exclusivamente para la realización de trabajos temporales o auxi- liares deberán cumplir el nivel de seguridad que les corresponda conforme a los criterios establecidos en el artículo 81. 2. Todo fichero temporal o copia de trabajo así creado será borrado o destrui- do una vez que haya dejado de ser necesario para los fines que motivaron su creación. CAPÍTULO II. Del documento de seguridad Artículo 88. El documento de seguridad. 1. El responsable del fichero o tratamiento elaborará un documento de seguridad que recogerá las medidas de índole técnica y organizativa 356

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal acordes a la normativa de seguridad vigente que será de obligado cumplimiento para el personal con acceso a los sistemas de información. 2. El documento de seguridad podrá ser único y comprensivo de todos los ficheros o tratamientos, o bien individualizado para cada fichero o tratamiento. También podrán elaborarse distintos documentos de seguridad agrupando ficheros o tratamientos según el sistema de tratamiento utilizado para su organización, o bien atendiendo a criterios organizativos del responsable. En todo caso, tendrá el carácter de documento interno de la organización. 3. El documento deberá contener, como mínimo, los siguientes aspectos: a) Ámbito de aplicación del documento con especificación detallada de los recursos protegidos. b) Medidas, normas, procedimientos de actuación, reglas y estándares encaminados a garantizar el nivel de seguridad exigido en este reglamento. c) Funciones y obligaciones del personal en relación con el tratamiento de los datos de carácter personal incluidos en los ficheros. d) Estructura de los ficheros con datos de carácter personal y descripción de los sistemas de información que los tratan. e) Procedimiento de notificación, gestión y respuesta ante las incidencias. f) Los procedimientos de realización de copias de respaldo y de recupe- ración de los datos en los ficheros o tratamientos automatizados. g) Las medidas que sea necesario adoptar para el transporte de soportes y documentos, así como para la destrucción de los documentos y soportes, o en su caso, la reutilización de estos últimos. 4. En caso de que fueran de aplicación a los ficheros las medidas de seguridad de nivel medio o las medidas de seguridad de nivel alto, previstas en este título, el documento de seguridad deberá contener además: a) La identificación del responsable o responsables de seguridad. b) Los controles periódicos que se deban realizar para verificar el cumplimiento de lo dispuesto en el propio documento. 5. Cuando exista un tratamiento de datos por cuenta de terceros, el documento de seguridad deberá contener la identificación de los ficheros o tratamientos que se traten en concepto de encargado con referencia expresa al contrato o documento que regule las condiciones del encargo, así como de la identificación del responsable y del período de vigencia del encargo. 6. En aquellos casos en los que datos personales de un fichero o tratamiento se incorporen y traten de modo exclusivo en los sistemas del encargado, el 357

La protección de datos personales: Soluciones en entornos Microsoft responsable deberá anotarlo en su documento de seguridad. Cuando tal circunstancia afectase a parte o a la totalidad de los ficheros o tratamientos del responsable, podrá delegarse en el encargado la llevanza del documento de seguridad, salvo en lo relativo a aquellos datos contenidos en recursos propios. Este hecho se indicará de modo expreso en el contrato celebrado al amparo del artículo 12 de la Ley Orgánica 15/1999, de 13 de diciembre, con especificación de los ficheros o tratamientos afectados. En tal caso, se atenderá al documento de seguridad del encargado al efecto del cumplimiento de lo dispuesto por este reglamento. 7. El documento de seguridad deberá mantenerse en todo momento actualiza- do y será revisado siempre que se produzcan cambios relevantes en el sistema de información, en el sistema de tratamiento empleado, en su organiza- ción, en el contenido de la información incluida en los ficheros o tratamientos o, en su caso, como consecuencia de los controles periódicos realizados. En todo caso, se entenderá que un cambio es relevante cuando pueda repercutir en el cumplimiento de las medidas de seguridad implantadas. 8. El contenido del documento de seguridad deberá adecuarse, en todo momento, a las disposiciones vigentes en materia de seguridad de los datos de carácter personal. CAPÍTULO III. Medidas de seguridad aplicables a ficheros y tratamientos automatizados SECCIÓN 1.ª MEDIDAS DE SEGURIDAD DE NIVEL BÁSICO Artículo 89. Funciones y obligaciones del personal. 1. Las funciones y obligaciones de cada uno de los usuarios o perfiles de usuarios con acceso a los datos de carácter personal y a los sistemas de información estarán claramente definidas y documentadas en el documento de seguridad. También se definirán las funciones de control o autorizaciones delegadas por el responsable del fichero o tratamiento. 2. El responsable del fichero o tratamiento adoptará las medidas necesarias para que el personal conozca de una forma comprensible las normas de seguridad que afecten al desarrollo de sus funciones así como las consecuencias en que pudiera incurrir en caso de incumplimiento. Artículo 90. Registro de incidencias. Deberá existir un procedimiento de notificación y gestión de las incidencias que afecten a los datos de carácter personal y establecer un registro en el que se haga constar el tipo de incidencia, el momento en que se ha producido, o en su caso, 358

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal detectado, la persona que realiza la notificación, a quién se le comunica, los efectos que se hubieran derivado de la misma y las medidas correctoras aplicadas. 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. Artículo 92. Gestión de soportes y documentos. 1. Los soportes y documentos que contengan datos de carácter personal deberán permitir identificar el tipo de información que contienen, ser inventariados y solo deberán ser accesibles por el personal autorizado para ello en el documento de seguridad. Se exceptúan estas obligaciones cuando las características físicas del soporte imposibiliten su cumplimiento, quedando constancia motivada de ello en el documento de seguridad. 2. La salida de soportes y documentos que contengan datos de carácter personal, incluidos los comprendidos y/o anejos a un correo electrónico, fuera de los locales bajo el control del responsable del fichero o tratamien- to deberá ser autorizada por el responsable del fichero o encontrarse debidamente autorizada en el documento de seguridad. 3. En el traslado de la documentación se adoptarán las medidas dirigidas a evitar la sustracción, pérdida o acceso indebido a la información durante su transporte. 4. Siempre que vaya a desecharse cualquier documento o soporte que contenga datos de carácter personal deberá procederse a su destrucción o borrado, mediante la adopción de medidas dirigidas a evitar el acceso a la información contenida en el mismo o su recuperación posterior. 5. La identificación de los soportes que contengan datos de carácter personal que la organización considerase especialmente sensibles se podrá realizar 359

La protección de datos personales: Soluciones en entornos Microsoft utilizando sistemas de etiquetado comprensibles y con significado que permitan a los usuarios con acceso autorizado a los citados soportes y documentos identificar su contenido, y que dificulten la identificación para el resto de personas. 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 verifica- ción de que está autorizado. 3. Cuando el mecanismo de autenticación se base en la existencia de contra- señ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. Artículo 94. Copias de respaldo y recuperación. 1. Deberán establecerse procedimientos de actuación para la realización como mínimo semanal de copias de respaldo, salvo que en dicho período no se hubiera producido ninguna actualización de los datos. 2. Asimismo, se establecerán procedimientos para la recuperación de los datos que garanticen en todo momento su reconstrucción en el estado en que se encontraban al tiempo de producirse la pérdida o destrucción. Únicamente, en el caso de que la pérdida o destrucción afectase a ficheros o tratamientos parcialmente automatizados, y siempre que la existencia de documentación permita alcanzar el objetivo al que se refiere el párrafo anterior, se deberá proceder a grabar manualmente los datos quedando constancia motivada de este hecho en el documento de seguridad. 3. El responsable del fichero se encargará de verificar cada seis meses la correcta definición, funcionamiento y aplicación de los procedimientos de realización de copias de respaldo y de recuperación de los datos. 4. Las pruebas anteriores a la implantación o modificación de los sistemas de información que traten ficheros con datos de carácter personal no se realizarán con datos reales, salvo que se asegure el nivel de seguridad correspondiente al tratamiento realizado y se anote su realización en el documento de seguridad. 360

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal Si está previsto realizar pruebas con datos reales, previamente deberá haberse realizado una copia de seguridad. SECCIÓN 2.ª MEDIDAS DE SEGURIDAD DE NIVEL MEDIO Artículo 95. Responsable de seguridad. En el documento de seguridad deberán designarse uno o varios responsables de seguridad encargados de coordinar y controlar las medidas definidas en el mismo. Esta designación puede ser única para todos los ficheros o tratamientos de datos de carácter personal o diferenciada según los sistemas de tratamiento utilizados, circunstancia que deberá hacerse constar claramente en el documento de seguridad. En ningún caso esta designación supone una exoneración de la responsabilidad que corresponde al responsable del fichero o al encargado del tratamiento de acuerdo con este reglamento. Artículo 96. Auditoría. 1. A partir del nivel medio los sistemas de información e instalaciones de tratamiento y almacenamiento de datos se someterán, al menos cada dos años, a una auditoría interna o externa que verifique el cumplimiento del presente título. Con carácter extraordinario deberá realizarse dicha auditoría siempre que se realicen modificaciones sustanciales en el sistema de información que puedan repercutir en el cumplimiento de las medidas de seguridad implantadas con el objeto de verificar la adaptación, adecuación y eficacia de las mismas. Esta auditoría inicia el cómputo de dos años señalado en el párrafo anterior. 2. El informe de auditoría deberá dictaminar sobre la adecuación de las medidas y controles a la Ley y su desarrollo reglamentario, identificar sus deficiencias y proponer las medidas correctoras o complementarias necesarias. Deberá, igualmente, incluir los datos, hechos y observaciones en que se basen los dictámenes alcanzados y las recomendaciones propuestas. 3. Los informes de auditoría serán analizados por el responsable de seguridad competente, que elevará las conclusiones al responsable del fichero o tratamiento para que adopte las medidas correctoras adecuadas y queda- rán a disposición de la Agencia Española de Protección de Datos o, en su caso, de las autoridades de control de las comunidades autónomas. Artículo 97. Gestión de soportes y documentos. 1. Deberá establecerse un sistema de registro de entrada de soportes que permita, directa o indirectamente, conocer el tipo de documento o soporte, 361

La protección de datos personales: Soluciones en entornos Microsoft la fecha y hora, el emisor, el número de documentos o soportes incluidos en el envío, el tipo de información que contienen, la forma de envío y la persona responsable de la recepción que deberá estar debidamente autorizada. 2. Igualmente, se dispondrá de un sistema de registro de salida de soportes que permita, directa o indirectamente, conocer el tipo de documento o soporte, la fecha y hora, el destinatario, el número de documentos o soportes incluidos en el envío, el tipo de información que contienen, la forma de envío y la persona responsable de la entrega que deberá estar debidamente autorizada. Artículo 98. Identificación y autenticación. El responsable del fichero o tratamiento establecerá un mecanismo que limite la posibilidad de intentar reiteradamente el acceso no autorizado al sistema de información. Artículo 99. Control de acceso físico. Exclusivamente el personal autorizado en el documento de seguridad podrá tener acceso a los lugares donde se hallen instalados los equipos físicos que den soporte a los sistemas de información. Artículo 100. Registro de incidencias. 1. En el registro regulado en el artículo 90 deberán consignarse, además, los procedimientos realizados de recuperación de los datos, indicando la persona que ejecutó el proceso, los datos restaurados y, en su caso, qué datos ha sido necesario grabar manualmente en el proceso de recuperación. 2. Será necesaria la autorización del responsable del fichero para la ejecución de los procedimientos de recuperación de los datos. SECCIÓN 3.ª MEDIDAS DE SEGURIDAD DE NIVEL ALTO Artículo 101. Gestión y distribución de soportes. 1. La identificación de los soportes se deberá realizar utilizando sistemas de etiquetado comprensibles y con significado que permitan a los usuarios con acceso autorizado a los citados soportes y documentos identificar su contenido, y que dificulten la identificación para el resto de personas. 2. La distribución de los soportes que contengan datos de carácter personal se realizará cifrando dichos datos o bien utilizando otro mecanismo que garantice que dicha información no sea accesible o manipulada durante su transporte. Asimismo, se cifrarán los datos que contengan los dispositivos portátiles cuando éstos se encuentren fuera de las instalaciones que están bajo el control del responsable del fichero. 362

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal 3. Deberá evitarse el tratamiento de datos de carácter personal en dispositivos portátiles que no permitan su cifrado. En caso de que sea estrictamente necesario se hará constar motivadamente en el documento de seguridad y se adoptarán medidas que tengan en cuenta los riesgos de realizar tratamientos en entornos desprotegidos. Artículo 102. Copias de respaldo y recuperación. Deberá conservarse una copia de respaldo de los datos y de los procedimientos de recuperación de los mismos en un lugar diferente de aquel en que se encuentren los equipos informáticos que los tratan, que deberá cumplir en todo caso las medidas de seguridad exigidas en este título, o utilizando elementos que garanticen la integridad y recuperación de la información, de forma que sea posible su recuperación. Artículo 103. Registro de accesos. 1. De cada intento de acceso se guardarán, como mínimo, la identificación del usuario, la fecha y hora en que se realizó, el fichero accedido, el tipo de acceso y si ha sido autorizado o denegado. 2. En el caso de que el acceso haya sido autorizado, será preciso guardar la información que permita identificar el registro accedido. 3. Los mecanismos que permiten el registro de accesos estarán bajo el control directo del responsable de seguridad competente sin que deban permitir la desactivación ni la manipulación de los mismos. 4. El período mínimo de conservación de los datos registrados será de dos años. 5. El responsable de seguridad se encargará de revisar al menos una vez al mes la información de control registrada y elaborará un informe de las revisiones realizadas y los problemas detectados. 6. No será necesario el registro de accesos definido en este artículo en caso de que concurran las siguientes circunstancias: a) Que el responsable del fichero o del tratamiento sea una persona física. b) Que el responsable del fichero o del tratamiento garantice que única- mente él tiene acceso y trata los datos personales. La concurrencia de las dos circunstancias a las que se refiere el apartado anterior deberá hacerse constar expresamente en el documento de seguridad. Artículo 104. Telecomunicaciones. Cuando, conforme al artículo 81.3 deban implantarse las medidas de seguridad de nivel alto, la transmisión de datos de carácter personal a través de redes públicas o redes inalámbricas de comunicaciones electrónicas se realizará cifrando dichos datos o bien utilizando cualquier otro mecanismo que garantice que la información no sea inteligible ni manipulada por terceros. 363

La protección de datos personales: Soluciones en entornos Microsoft CAPÍTULO IV. Medidas de seguridad aplicables a los ficheros y tratamientos no automatizados SECCIÓN 1.ª MEDIDAS DE SEGURIDAD DE NIVEL BÁSICO Artículo 105. Obligaciones comunes. 1. Además de lo dispuesto en el presente capítulo, a los ficheros no automatizados les será de aplicación lo dispuesto en los capítulos I y II del presente título en lo relativo a: a) Alcance. b) Niveles de seguridad. c) Encargado del tratamiento. d) Prestaciones de servicios sin acceso a datos personales. e) Delegación de autorizaciones. f) Régimen de trabajo fuera de los locales del responsable del fichero o encargado del tratamiento. g) Copias de trabajo de documentos. h) Documento de seguridad. 2. Asimismo se les aplicará lo establecido por la sección primera del capítulo III del presente título en lo relativo a: a) Funciones y obligaciones del personal. b) Registro de incidencias. c) Control de acceso. d) Gestión de soportes. Artículo 106. Criterios de archivo. El archivo de los soportes o documentos se realizará de acuerdo con los criterios previstos en su respectiva legislación. Estos criterios deberán garantizar la correcta conservación de los documentos, la localización y consulta de la informa- ción y posibilitar el ejercicio de los derechos de oposición al tratamiento, acceso, rectificación y cancelación. En aquellos casos en los que no exista norma aplicable, el responsable del fichero deberá establecer los criterios y procedimientos de actua- ción que deban seguirse para el archivo. Artículo 107. Dispositivos de almacenamiento. Los dispositivos de almacenamiento de los documentos que contengan datos de carácter personal deberán disponer de mecanismos que obstaculicen su apertura. Cuando las características físicas de aquéllos no permitan adoptar esta medida, el responsable del fichero o tratamiento adoptará medidas que impidan el acceso de personas no autorizadas. 364

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal Artículo 108. Custodia de los soportes. Mientras la documentación con datos de carácter personal no se encuentre archivada en los dispositivos de almacenamiento establecidos en el artículo anterior, por estar en proceso de revisión o tramitación, ya sea previo o posterior a su archivo, la persona que se encuentre al cargo de la misma deberá custodiarla e impedir en todo momento que pueda ser accedida por persona no autorizada. SECCIÓN 2.ª MEDIDAS DE SEGURIDAD DE NIVEL MEDIO Artículo 109. Responsable de seguridad. Se designará uno o varios responsables de seguridad en los términos y con las funciones previstas en el artículo 95 de este reglamento. Artículo 110. Auditoría. Los ficheros comprendidos en la presente sección se someterán, al menos cada dos años, a una auditoría interna o externa que verifique el cumplimiento del presente título. SECCIÓN 3.ª MEDIDAS DE SEGURIDAD DE NIVEL ALTO Artículo 111. Almacenamiento de la información. 1. Los armarios, archivadores u otros elementos en los que se almacenen los ficheros no automatizados con datos de carácter personal deberán encontrarse en áreas en las que el acceso esté protegido con puertas de acceso dotadas de sistemas de apertura mediante llave u otro dispositivo equivalente. Dichas áreas deberán permanecer cerradas cuando no sea preciso el acceso a los documentos incluidos en el fichero. 2. Si, atendidas las características de los locales de que dispusiera el responsable del fichero o tratamiento, no fuera posible cumplir lo establecido en el apartado anterior, el responsable adoptará medidas alternativas que, debidamente motivadas, se incluirán en el documento de seguridad. Artículo 112. Copia o reproducción. 1. La generación de copias o la reproducción de los documentos únicamente podrá ser realizada bajo el control del personal autorizado en el documen- to de seguridad. 2. Deberá procederse a la destrucción de las copias o reproducciones desechadas de forma que se evite el acceso a la información contenida en las mismas o su recuperación posterior. Artículo 113. Acceso a la documentación. 1. El acceso a la documentación se limitará exclusivamente al personal autorizado. 365

La protección de datos personales: Soluciones en entornos Microsoft 2. Se establecerán mecanismos que permitan identificar los accesos realizados en el caso de documentos que puedan ser utilizados por múltiples usuarios. 3. El acceso de personas no incluidas en el párrafo anterior deberá quedar adecuadamente registrado de acuerdo con el procedimiento establecido al efecto en el documento de seguridad. Artículo 114. Traslado de documentación. Siempre que se proceda al traslado físico de la documentación contenida en un fichero, deberán adoptarse medidas dirigidas a impedir el acceso o manipulación de la información objeto de traslado. TÍTULO IX. Procedimientos tramitados por la Agencia Española de Protección de Datos CAPÍTULO I. Disposiciones generales Artículo 115. Régimen aplicable. 1. Los procedimientos tramitados por la Agencia Española de Protección de Datos se regirán por lo dispuesto en el presente título, y supletoriamente, por la Ley 30/1992, de 26 de noviembre, de Régimen Jurídico de las Administraciones Públicas y del Procedimiento Administrativo Común. 2. Específicamente serán de aplicación las normas reguladoras del procedimiento administrativo común al régimen de representación en los citados procedimientos. Artículo 116. Publicidad de las resoluciones. 1. La Agencia Española de Protección de Datos hará públicas sus resoluciones, con excepción de las correspondientes a la inscripción de un fichero o tratamiento en el Registro General de Protección de Datos y de aquéllas por las que se resuelva la inscripción en el mismo de los códigos tipo, siempre que se refieran a procedimientos que se hubieran iniciado con posterioridad al 1 de enero de 2004, o correspondan al archivo de actuaciones inspectoras incoadas a partir de dicha fecha. 2. La publicación de estas resoluciones se realizará preferentemente mediante su inserción en el sitio web de la Agencia Española de Protección de Datos, dentro del plazo de un mes a contar desde la fecha de su notifica- ción a los interesados. 3. En la notificación de las resoluciones se informará expresamente a los interesados de la publicidad prevista en el artículo 37.2 de la Ley Orgánica 15/1999, de 13 de diciembre. 4. La publicación se realizará aplicando los criterios de disociación de los datos de carácter personal que a tal efecto se establezcan mediante Resolu- ción del Director de la Agencia. 366

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal CAPÍTULO II. Procedimiento de tutela de los derechos de acceso, rectificación, cancelación y oposición Artículo 117. Instrucción del procedimiento. 1. El procedimiento se iniciará a instancia del afectado o afectados, expresan- do con claridad el contenido de su reclamación y de los preceptos de la Ley Orgánica 15/1999, de 13 de diciembre, que se consideran vulnerados. 2. Recibida la reclamación en la Agencia Española de Protección de Datos, se dará traslado de la misma al responsable del fichero, para que, en el plazo de quince días, formule las alegaciones que estime pertinentes. 3. Recibidas las alegaciones o transcurrido el plazo previsto en el apartado anterior, la Agencia Española de Protección de Datos, previos los informes, pruebas y otros actos de instrucción pertinentes, incluida la audiencia del afectado y nuevamente del responsable del fichero, resolverá sobre la reclamación formulada. Artículo 118. Duración del procedimiento y efectos de la falta de resolución expresa. 1. El plazo máximo para dictar y notificar resolución en el procedimiento de tutela de derechos será de seis meses, a contar desde la fecha de entrada en la Agencia Española de Protección de Datos de la reclamación del afectado o afectados. 2. Si en dicho plazo no se hubiese dictado y notificado resolución expresa, el afectado podrá considerar estimada su reclamación por silencio administrativo positivo. Artículo 119. Ejecución de la resolución. Si la resolución de tutela fuese estimatoria, se requerirá al responsable del fichero para que, en el plazo de diez días siguientes a la notificación, haga efectivo el ejercicio de los derechos objeto de la tutela, debiendo dar cuenta por escrito de dicho cumplimiento a la Agencia Española de Protección de Datos en idéntico plazo. CAPÍTULO III. Procedimientos relativos al ejercicio de la potestad sancionadora SECCIÓN 1.ª DISPOSICIONES GENERALES Artículo 120. Ámbito de aplicación. 1. Las disposiciones contenidas en el presente capítulo serán de aplicación a los procedimientos relativos al ejercicio por la Agencia Española de Protección de Datos de la potestad sancionadora que le viene atribuida por la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de datos 367

La protección de datos personales: Soluciones en entornos Microsoft de carácter personal, en la Ley 34/2002, de 11 de julio, de Servicios de la sociedad de la información y de comercio electrónico, y en la Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones. 2. No obstante, las disposiciones previstas en el artículo 121 y en la sección cuarta de este capítulo únicamente serán aplicables a los procedimientos referidos al ejercicio de la potestad sancionadora prevista en la Ley Orgá- nica 15/1999, de 13 de diciembre. Artículo 121. Inmovilización de ficheros. 1. En el supuesto previsto como infracción muy grave en la Ley Orgánica 15/1999, de 13 de diciembre, consistente en la utilización o cesión ilícita de los datos de carácter personal en la que se impida gravemente o se atente de igual modo contra el ejercicio de los derechos de los ciudadanos y el libre desarrollo de la personalidad que la Constitución y las leyes garantizan, el Director de la Agencia Española de Protección de Datos podrá, en cualquier momento del procedimiento, requerir a los responsables de ficheros o tratamientos de datos de carácter personal, tanto de titularidad pública como privada, la cesación en la utilización o cesión ilícita de los datos. 2. El requerimiento deberá ser atendido en el plazo improrrogable de tres días, durante el cual el responsable del fichero podrá formular las alegaciones que tenga por convenientes en orden al levantamiento de la medida. 3. Si el requerimiento fuera desatendido, el Director de la Agencia Española de Protección de Datos podrá, mediante resolución motivada, acordar la inmovilización de tales ficheros o tratamientos, a los solos efectos de restaurar los derechos de las personas afectadas. SECCIÓN 2.ª ACTUACIONES PREVIAS Artículo 122. Iniciación. 1. Con anterioridad a la iniciación del procedimiento sancionador, se podrán realizar actuaciones previas con objeto de determinar si concurren circunstancias que justifiquen tal iniciación. En especial, estas actuaciones se orientarán a determinar, con la mayor precisión posible, los hechos que pudieran justificar la incoación del procedimiento, identificar la persona u órgano que pudiera resultar responsable y fijar las circunstancias relevantes que pudieran concurrir en el caso. 2. Las actuaciones previas se llevarán a cabo de oficio por la Agencia Española de Protección de Datos, bien por iniciativa propia o como consecuencia de la existencia de una denuncia o una petición razonada de otro órgano. 3. Cuando las actuaciones se lleven a cabo como consecuencia de la existencia de una denuncia o de una petición razonada de otro órgano, la Agencia 368

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal Española de Protección de Datos acusará recibo de la denuncia o petición, pudiendo solicitar cuanta documentación se estime oportuna para poder comprobar los hechos susceptibles de motivar la incoación del procedimiento sancionador. 4. Estas actuaciones previas tendrán una duración máxima de doce meses a contar desde la fecha en la que la denuncia o petición razonada a las que se refiere el apartado 2 hubieran tenido entrada en la Agencia Española de Protección de Datos o, en caso de no existir aquéllas, desde que el Director de la Agencia acordase la realización de dichas actuaciones. El vencimiento del plazo sin que haya sido dictado y notificado acuerdo de inicio de procedimiento sancionador producirá la caducidad de las actuaciones previas. Artículo 123. Personal competente para la realización de las actuaciones previas. 1. Las actuaciones previas serán llevadas a cabo por el personal del área de la Inspección de Datos habilitado para el ejercicio de funciones inspectoras. 2. En supuestos excepcionales, el Director de la Agencia Española de Protec- ción de Datos podrá designar para la realización de actuaciones específi- cas a funcionarios de la propia Agencia no habilitados con carácter general para el ejercicio de funciones inspectoras o a funcionarios que no presten sus funciones en la Agencia, siempre que reúnan las condiciones de idoneidad y especialización necesarias para la realización de tales actuaciones. En estos casos, la autorización indicará expresamente la identifica- ción del funcionario y las concretas actuaciones previas de inspección a realizar. 3. Los funcionarios que ejerzan la inspección a los que se refieren los dos apartados anteriores tendrán la consideración de autoridad pública en el desempeño de sus cometidos. Estarán obligados a guardar secreto sobre las informaciones que conozcan en el ejercicio de las mencionadas funciones, incluso después de haber cesado en las mismas. Artículo 124. Obtención de información. Los inspectores podrán recabar cuantas informaciones precisen para el cumplimiento de sus cometidos. A tal fin podrán requerir la exhibición o el envío de los documentos y datos y examinarlos en el lugar en que se encuentren depositados, como obtener copia de los mismos, inspeccionar los equipos físicos y lógicos, así como requerir la ejecución de tratamientos y programas o procedimientos de gestión y soporte del fichero o ficheros sujetos a investigación, accediendo a los lugares donde se hallen instalados. 369

La protección de datos personales: Soluciones en entornos Microsoft Artículo 125. Actuaciones presenciales. 1. En el desarrollo de las actuaciones previas se podrán realizar visitas de inspección por parte de los inspectores designados, en los locales o sede del inspeccionado, o donde se encuentren ubicados los ficheros, en su caso. A tal efecto, los inspectores habrán sido previamente autorizados por el Director de la Agencia Española de Protección de Datos. Las inspecciones podrán realizarse en el domicilio del inspeccionado, en la sede o local concreto relacionado con el mismo o en cualquiera de sus locales, incluyendo aquéllos en que el tratamiento sea llevado a cabo por un encargado. La autorización se limitará a indicar la habilitación del inspector autorizado y la identificación de la persona u órgano inspeccionado. 2. En el supuesto contemplado en el apartado anterior, las inspecciones concluirán con el levantamiento de la correspondiente acta, en la que quedará constancia de las actuaciones practicadas durante la visita o visitas de inspección. 3. El acta, que se emitirá por duplicado, será firmada por los inspectores actuantes y por el inspeccionado, que podrá hacer constar en la misma las alegaciones o manifestaciones que tenga por conveniente. En caso de negativa del inspeccionado a la firma del acta, se hará constar expresamente esta circunstancia en la misma. En todo caso, la firma por el inspeccionado del acta no supondrá su conformidad, sino tan sólo la recepción de la misma. Se entregará al inspeccionado uno de los originales del acta de inspección, incorporándose el otro a las actuaciones. Artículo 126. Resultado de las actuaciones previas. 1. Finalizadas las actuaciones previas, éstas se someterán a la decisión del Director de la Agencia Española de Protección de Datos. Si de las actuaciones no se derivasen hechos susceptibles de motivar la imputación de infracción alguna, el Director de la Agencia Española de Protección de Datos dictará resolución de archivo que se notificará al investigado y al denunciante, en su caso. 2. En caso de apreciarse la existencia de indicios susceptibles de motivar la imputación de una infracción, el Director de la Agencia Española de Protección de Datos dictará acuerdo de inicio de procedimiento sancionador o de infracción de las Administraciones públicas, que se tramitarán conforme a lo dispuesto, respectivamente, en las secciones tercera y cuarta del presente capítulo. 370

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal SECCIÓN 3.ª PROCEDIMIENTO SANCIONADOR Artículo 127. Iniciación del procedimiento. Con carácter específico el acuerdo de inicio del procedimiento sancionador deberá contener: a) Identificación de la persona o personas presuntamente responsables. b) Descripción sucinta de los hechos imputados, su posible calificación y las sanciones que pudieran corresponder, sin perjuicio de lo que resulte de la instrucción. c) Indicación de que el órgano competente para resolver el procedimiento es el Director de la Agencia Española de Protección de Datos. d) Indicación al presunto responsable de que puede reconocer voluntariamente su responsabilidad, en cuyo caso se dictará directamente resolu- ción. e) Designación de instructor y, en su caso, secretario, con expresa indicación del régimen de recusación de los mismos. f) Indicación expresa del derecho del responsable a formular alegaciones, a la audiencia en el procedimiento y a proponer las pruebas que estime procedentes. g) Medidas de carácter provisional que pudieran acordarse, en su caso, conforme a lo establecido en la sección primera del presente capítulo. Artículo 128. Plazo máximo para resolver. 1. El plazo para dictar resolución será el que determinen las normas aplicables a cada procedimiento sancionador y se computará desde la fecha en que se dicte el acuerdo de inicio hasta que se produzca la notificación de la resolu- ción sancionadora, o se acredite debidamente el intento de notificación. 2. El vencimiento del citado plazo máximo, sin que se haya dictada y notificada resolución expresa, producirá la caducidad del procedimiento y el archivo de las actuaciones. SECCIÓN 4.ª PROCEDIMIENTO DE DECLARACIÓN DE INFRACCIÓN DE LA LEY ORGÁNICA 15/1999, DE 13 DE DICIEMBRE, POR LAS ADMINISTRACIONES PÚBLICAS Artículo 129. Disposición general. El procedimiento por el que se declare la existencia de una infracción de la Ley Orgánica 15/1999, de 13 de diciembre, cometida por las Administraciones públicas será el establecido en la sección tercera de este capítulo. 371

La protección de datos personales: Soluciones en entornos Microsoft CAPÍTULO IV. Procedimientos relacionados con la inscripción o cancelación de ficheros SECCIÓN 1.ª PROCEDIMIENTO DE INSCRIPCIÓN DE LA CREACIÓN, MODIFICACIÓN O SUPRESIÓN DE FICHEROS Artículo 130. Iniciación del procedimiento. 1. El procedimiento se iniciará como consecuencia de la notificación de la creación, modificación o supresión del fichero por el interesado o, en su caso, de la comunicación efectuada por las autoridades de control de las comunidades autónomas, a la que se refiere el presente reglamento. 2. La notificación se deberá efectuar cumplimentando los modelos o formularios electrónicos publicados al efecto por la Agencia Española de Protec- ción de Datos, en virtud de lo dispuesto en el apartado 1 del artículo 59 de este reglamento. Tratándose de la notificación de la modificación o supresión de un fichero, deberá indicarse en la misma el código de inscripción del fichero en el Registro General de Protección de Datos. 3. La notificación se efectuará en soporte electrónico, ya mediante comunica- ción electrónica a través de Internet mediante firma electrónica o en soporte informático, utilizando al efecto el programa de ayuda para la generación de notificaciones que la Agencia pondrá a disposición de los interesados de forma gratuita. Será igualmente válida la notificación efectuada en soporte papel cuando para su cumplimentación hayan sido utilizados los modelos o formularios publicados por la Agencia. 4. En la notificación, el responsable del fichero deberá declarar un domicilio a efectos de notificaciones en el procedimiento. Artículo 131. Especialidades en la notificación de ficheros de titularidad pública. 1. Cuando se trate de la notificación de ficheros de titularidad pública, deberá acompañarse a la notificación una copia de la norma o acuerdo de creación, modificación o supresión del fichero a que hace referencia el artículo 52 del presente reglamento. Cuando el diario oficial en el que se encuentre publicada la citada norma o acuerdo sea accesible a través de Internet, bastará con indicar en la notifi- cación la dirección electrónica que permita su concreta localización. 2. Recibida la notificación, si la misma no contuviera la información preceptiva o se advirtieran defectos formales, el Registro General de Protección 372

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal de Datos requerirá al responsable del fichero para que complete o subsane la notificación. El plazo para la subsanación o mejora de la solicitud será de tres meses, en el caso de que se precise la modificación de la norma o acuerdo de creación del fichero. Artículo 132. Acuerdo de inscripción o cancelación. Si la notificación referida a la creación, modificación o supresión del fichero contuviera la información preceptiva y se cumplieran las restantes exigencias legales, el Director de la Agencia Española de Protección de Datos, a propuesta del Re- gistro General de Protección de Datos, acordará, respectivamente, la inscripción del fichero, asignando al mismo el correspondiente código de inscripción, la modifica- ción de la inscripción del fichero o la cancelación de la inscripción correspondiente. Artículo 133. Improcedencia o denegación de la inscripción. El Director de la Agencia Española de Protección de Datos, a propuesta del Registro General de Protección de Datos, dictará resolución denegando la inscrip- ción, modificación o cancelación cuando de los documentos aportados por el responsable del fichero se desprenda que la notificación no resulta conforme a lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre. La resolución será debidamente motivada, con indicación expresa de las causas que impiden la inscripción, modificación o cancelación. Artículo 134. Duración del procedimiento y efectos de la falta de resolución expresa. 1. El plazo máximo para dictar y notificar resolución acerca de la inscripción, modificación o cancelación será de un mes. 2. Si en dicho plazo no se hubiese dictado y notificado resolución expresa, se entenderá inscrito, modificado o cancelado el fichero a todos los efectos. SECCIÓN 2.ª PROCEDIMIENTO DE CANCELACIÓN DE OFICIO DE FICHEROS INSCRITOS Artículo 135. Iniciación del procedimiento. El procedimiento de cancelación de oficio de los ficheros inscritos en el Regis- tro General de Protección de Datos se iniciará siempre de oficio, bien por propia iniciativa o en virtud de denuncia, por acuerdo del Director de la Agencia Española de Protección de Datos. Artículo 136. Terminación del expediente. La resolución, previa audiencia del interesado, acordará haber lugar o no a la cancelación del fichero. 373

La protección de datos personales: Soluciones en entornos Microsoft Si la resolución acordase la cancelación del fichero, se dará traslado de la misma al Registro General de Protección de Datos, para que proceda a la cancelación. CAPÍTULO V. Procedimientos relacionados con las transferencias internacionales de datos SECCIÓN 1.ª PROCEDIMIENTO DE AUTORIZACIÓN DE TRANSFERENCIAS INTERNACIONALES DE DATOS Artículo 137. Iniciación del procedimiento. 1. El procedimiento para la obtención de la autorización para las transferencias internacionales de datos a países terceros a las que se refiere el artícu- lo 33 de la Ley Orgánica 15/1999, de 13 de diciembre, y el artículo 70 de este reglamento se iniciará siempre a solicitud del exportador que pretenda llevar a cabo la transferencia. 2. En su solicitud, además de los requisitos legalmente exigidos, el exportador deberá consignar, en todo caso: a) La identificación del fichero o ficheros a cuyos datos se refiera la transferencia internacional, con indicación de su denominación y código de inscripción del fichero en el Registro General de Protección de Datos. b) La transferencia o transferencias respecto de las que se solicita la autorización, con indicación de la finalidad que la justifica. c) La documentación que incorpore las garantías exigibles para la ob- tención de la autorización así como el cumplimiento de los requisitos legales necesarios para la realización de la transferencia, en su caso. Cuando la autorización se fundamente en la existencia de un contrato entre el exportador y el importador de los datos, deberá aportarse copia del mismo, acreditándose asimismo la concurrencia de poder suficiente en sus otorgantes. Si la autorización se pretendiera fundar en lo dispuesto en el apartado 4 del artículo 70, deberán aportarse las normas o reglas adoptadas en relación con el tratamiento de los datos en el seno del grupo, así como la documentación que acredite su carácter vinculante y su eficacia dentro del grupo. Igualmente deberá aportarse la documentación que acredite la posibilidad de que el afectado o la Agencia Española de Protección de Datos puedan exigir la responsabilidad que corresponda en caso de perjuicio del afectado o vulneración de las normas de protección de datos por parte de cualquier empresa importadora. Artículo 138. Instrucción del procedimiento. 1. Cuando el Director de la Agencia Española de Protección de Datos acuerde, conforme a lo dispuesto en el artículo 86.1 de la Ley 30/1992, de 26 de noviembre, la apertura de un período de información pública, el plazo para 374

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal la formulación de alegaciones será de diez días a contar desde la publicación en el «Boletín Oficial del Estado» del anuncio previsto en dicha Ley. 2. No será posible el acceso a la información del expediente en que concurran las circunstancias establecidas en el artículo 37.5 de la Ley 30/1992, de 26 de noviembre. 3. Transcurrido el plazo previsto en el apartado 1, en caso de que se hubieran formulado alegaciones, se dará traslado de las mismas al solicitante de la autorización, a fin de que en el plazo de diez días alegue lo que estime procedente. Artículo 139. Actos posteriores a la resolución. 1. Cuando el Director de la Agencia Española de Protección de Datos resuelva autorizar la transferencia internacional de datos, se dará traslado de la resolución de autorización al Registro General de Protección de Datos, a fin de proceder a su inscripción. El Registro General de Protección de Datos inscribirá de oficio la autoriza- ción de transferencia internacional. 2. En todo caso, se dará traslado de la resolución de autorización o denega- ción de la autorización de la transferencia internacional de datos al Minis- terio de Justicia, al efecto de que se proceda a su notificación a la Comi- sión Europea y a los demás Estados miembros de la Unión Europea de acuerdo a lo previsto en el artículo 26.3 de la Directiva 95/46/CE. Artículo 140. Duración del procedimiento y efectos de la falta de resolu- ción expresa. 1. El plazo máximo para dictar y notificar resolución será de tres meses, a contar desde la fecha de entrada en la Agencia Española de Protección de Datos de la solicitud. 2. Si en dicho plazo no se hubiese dictado y notificado resolución expresa, se entenderá autorizada la transferencia internacional de datos. SECCIÓN 2.ª PROCEDIMIENTO DE SUSPENSIÓN TEMPORAL DE TRANSFERENCIAS INTERNACIONALES DE DATOS Artículo 141. Iniciación. 1. En los supuestos contemplados en el artículo 69 y en el apartado 3 del artículo 70, el Director de la Agencia Española de Protección de Datos podrá acordar la suspensión temporal de una transferencia internacional de datos. 2. En tales supuestos, el Director dictará acuerdo de inicio referido a la suspensión temporal de la transferencia. El acuerdo deberá ser motivado y fundarse en los supuestos previstos en este reglamento. 375

La protección de datos personales: Soluciones en entornos Microsoft Artículo 142. Instrucción y resolución. 1. Se dará traslado del acuerdo al exportador, a fin de que en el plazo de quince días formule lo que a su derecho convenga. 2. Recibidas las alegaciones o cumplido el plazo señalado, el Director dictará resolución acordando, en su caso, la suspensión temporal de la transferencia internacional de datos. Artículo 143. Actos posteriores a la resolución. 1. El Director de la Agencia Española de Protección de Datos dará traslado de la reso ro General de Protección de Datos inscribirá de oficio la suspen- sión temporal de la transferencia internacional. 2. En todo caso, se dará traslado de la resolución al Ministerio de Justicia, al efecto de que se proceda a su notificación a la Comisión Europea y a los demás Estados miembros de la Unión Europea de acuerdo a lo previsto en el artículo 26.3 de la Directiva 95/46/CE. Artículo 144. Levantamiento de la suspensión temporal. 1. La suspensión se levantará tan pronto como cesen las causas que la hubieran justificado, mediante resolución del Director de la Agencia Española de Protección de Datos, del que se dará traslado al exportador. 2. El Director de la Agencia Española de Protección de Datos dará traslado de la resolución al Registro General de Protección de Datos, a fin de que la misma se haga constar en el Registro. El Registro General de Protección de Datos hará constar de oficio el levantamiento de la suspensión temporal de la transferencia internacional. 3. El acuerdo será notificado al exportador y al Ministerio de Justicia, al efecto de que se proceda a su notificación a la Comisión Europea y a los demás Estados miembros de la Unión Europea de acuerdo a lo previsto en el artículo 26. 3 de la Directiva 95/46/CE. CAPÍTULO VI. Procedimiento de inscripción de códigos tipo Artículo 145. Iniciación del procedimiento. 1. El procedimiento para la inscripción en el Registro General de Protección de Datos de los códigos tipo se iniciará siempre a solicitud de la entidad, órgano o asociación promotora del código tipo. 2. La solicitud, que deberá reunir los requisitos legalmente establecidos, habrá de acompañarse de los siguientes documentos: a) Acreditación de la representación que concurra en la persona que presente la solicitud. b) Contenido del acuerdo, convenio o decisión por la que se aprueba, en el ámbito correspondiente el contenido del código tipo presentado. 376

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal c) En caso de que el código tipo proceda de un acuerdo sectorial o una decisión de empresa certificación referida a la adopción del acuerdo y legitimación del órgano que lo adoptó. d) En el supuesto contemplado en la letra anterior, copia de los estatutos de la asociación, organización sectorial o entidad en cuyo marco haya sido aprobado el código. e) En caso de códigos tipo presentados por asociaciones u organizaciones de carácter sectorial, documentación relativa a su representatividad en el sector. f) En caso de códigos tipo basados en decisiones de empresa, descrip- ción de los tratamientos a los que se refiere el código tipo. g) Código tipo sometido a la Agencia Española de Protección de Datos. Artículo 146. Análisis de los aspectos sustantivos del código tipo. 1. Durante los treinta días siguientes a la notificación o subsanación de los defectos el Registro General de Protección de Datos podrá convocar a los solicitantes, a fin de obtener aclaraciones o precisiones relativas al contenido sustantivo del código tipo. 2. Transcurrido el plazo señalado en el apartado anterior, el Registro General de Protección de Datos elaborará un informe sobre las características del proyecto de código tipo. 3. La documentación presentada y el informe del Registro serán remitidos al Gabinete Jurídico, a fin de que por el mismo se informe acerca del cumplimiento de los requisitos establecidos en el Título VII de este Reglamento. Artículo 147. Información pública. 1. Cuando el Director de la Agencia Española de Protección de Datos acuerde, conforme a lo dispuesto en el artículo 86.1 de la Ley 30/1992, de 26 de noviembre, la apertura de un período de información pública, el plazo para la formulación de alegaciones será de diez días a contar desde la publi- cación en el «Boletín Oficial del Estado» del anuncio previsto en dicha ley. 2. No será posible el acceso a la información del expediente en que concurran las circunstancias establecidas en el artículo 37.5 de la Ley 30/1992, de 26 de noviembre. Artículo 148. Mejora del código tipo. Si durante la tramitación del procedimiento resultase necesaria la aportación de nuevos documentos o la modificación del código tipo presentado, la Agencia Española de Protección de Datos podrá requerir al solicitante, a fin de que en el plazo de treinta días introduzca las modificaciones que sean precisas, remitiendo el texto resultante a la Agencia Española de Protección de Datos. Se declarará la suspensión del procedimien- to en tanto el solicitante no dé cumplimiento al requerimiento. 377

La protección de datos personales: Soluciones en entornos Microsoft Artículo 149. Trámite de audiencia. En caso de que durante el trámite previsto en el artículo 148 se hubieran formulado alegaciones, se dará traslado de las mismas al solicitante de la autoriza- ción, a fin de que en el plazo de diez días alegue lo que estime procedente. Artículo 150. Resolución. 1. Cumplidos los términos establecidos en los artículos precedentes, el Direc- tor de la Agencia resolverá sobre la procedencia o improcedencia de la inscripción del código tipo en el Registro General de Protección de Datos. 2. Cuando el Director de la Agencia Española de Protección de Datos resuelva autorizar la inscripción del código tipo, se dará traslado de la resolución al Registro General de Protección de Datos, a fin de proceder a su inscripción. Artículo 151. Duración del procedimiento y efectos de la falta de resolución expresa. 1. El plazo máximo para dictar y notificar resolución será de seis meses, a contar desde la fecha de entrada de la solicitud en la Agencia Española de Protección de Datos. 2. Si en dicho plazo no se hubiese dictado y notificado resolución expresa, el solicitante podrá considerar estimada su solicitud. Artículo 152. Publicación de los códigos tipo por la Agencia Española de Protección de Datos. La Agencia Española de Protección de Datos dará publicidad al contenido de los códigos tipo inscritos en el Registro General de Protección de Datos, utilizando para ello, con carácter preferente, medios electrónicos o telemáticos. CAPÍTULO VII. Otros procedimientos tramitados por la agencia española de protección de datos SECCIÓN 1.ª PROCEDIMIENTO DE EXENCIÓN DEL DEBER DE INFORMACIÓN AL INTERESADO Artículo 153. Iniciación del procedimiento. 1. El procedimiento para obtener de la Agencia Española de Protección de Datos la exención del deber de informar al interesado acerca del tratamiento de sus datos de carácter personal cuando resulte imposible o exija esfuerzos desproporcionados, prevista en el apartado 5 del artículo 5 de la Ley Orgánica 15/1999, de 13 de diciembre, se iniciará siempre a petición del responsable que pretenda obtener la aplicación de la exención. 2. En el escrito de solicitud, además de los requisitos recogidos en el art. 70 de la Ley 30/1992, de 26 de noviembre, el responsable deberá: 378

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal a) Identificar claramente el tratamiento de datos al que pretende aplicarse la exención del deber de informar. b) Motivar expresamente las causas en que fundamenta la imposibilidad o el carácter desproporcionado del esfuerzo que implicaría el cumplimiento del deber de informar. c) Exponer detalladamente las medidas compensatorias que propone realizar en caso de exoneración del cumplimiento del deber de informar. d) Aportar una cláusula informativa que, mediante su difusión, en los términos que se indiquen en la solicitud, permita compensar la exención del deber de informar. Artículo 154. Propuesta de nuevas medidas compensatorias. 1. Si la Agencia Española de Protección de Datos considerase insuficientes las medidas compensatorias propuestas por el solicitante, podrá acordar la adopción de medidas complementarias o sustitutivas a las propuestas por aquél en su solicitud. 2. Del acuerdo se dará traslado al solicitante, a fin de que exponga lo que a su derecho convenga en el plazo de quince días. Artículo 155. Terminación del procedimiento. Concluidos los trámites previstos en los artículos precedentes, el Director de la Agencia dictará resolución, concediendo o denegando la exención del deber de informar. La resolución podrá imponer la adopción de las medidas complementarias a las que se refiere el artículo anterior. Artículo 156. Duración del procedimiento y efectos de la falta de resolución expresa. 1. El plazo máximo para dictar y notificar resolución en el procedimiento será de seis meses, a contar desde la fecha de entrada en la Agencia Espa- ñola de Protección de Datos de la solicitud del responsable del fichero. 2. Si en dicho plazo no se hubiese dictado y notificado resolución expresa, el afectado podrá considerar estimada su solicitud por silencio administrativo positivo. SECCIÓN 2.ª PROCEDIMIENTO PARA LA AUTORIZACIÓN DE CONSERVACIÓN DE DATOS PARA FINES HISTÓRICOS, ESTADÍSTICOS O CIENTÍFICOS Artículo 157. Iniciación del procedimiento. 1. El procedimiento para obtener de la Agencia Española de Protección de Datos la declaración de la concurrencia en un determinado tratamiento de 379

La protección de datos personales: Soluciones en entornos Microsoft datos de valores históricos, científicos o estadísticos, a los efectos previstos en la Ley Orgánica 15/1999, de 13 de diciembre, y en el presente Regla- mento, se iniciará siempre a petición del responsable que pretenda obtener la declaración. 2. En el escrito de solicitud, el responsable deberá: a) Identificar claramente el tratamiento de datos al que pretende aplicarse la excepción. b) Motivar expresamente las causas que justificarían la declaración. c) Exponer detalladamente las medidas que el responsable del fichero se propone implantar para garantizar el derecho de los ciudadanos. 3. La solicitud deberá acompañarse de cuantos documentos o pruebas sean necesarios para justificar la existencia de los valores históricos, científicos o estadísticos que fundamentarían la declaración de la Agencia. Artículo 158. Duración del procedimiento y efectos de la falta de resolución expresa. 1. El plazo máximo para dictar y notificar resolución en el procedimiento será de tres meses, a contar desde la fecha de entrada en la Agencia Espa- ñola de Protección de Datos de la solicitud del responsable del fichero. 2. Si en dicho plazo no se hubiese dictado y notificado resolución expresa, el afectado podrá considerar estimada su solicitud. Disposición adicional única. Productos de software. Los productos de software destinados al tratamiento automatizado de datos personales deberán incluir en su descripción técnica el nivel de seguridad, básico, medio o alto, que permitan alcanzar de acuerdo con lo establecido en el título VIII de este reglamento. Disposición final única. Aplicación supletoria. En lo no establecido en el capítulo III del título IX serán de aplicación a los procedimientos sancionadores tramitados por la Agencia Española de Protección de Datos las disposiciones contenidas en el Reglamento del Procedimiento para el ejercicio de la potestad sancionadora, aprobado por Real Decreto 1398/1993, de 4 de agosto. MINISTERIO DE FOMENTO 980 REAL DECRETO 1762/2007, de 28 de diciembre, por el que se determinan los requisitos relativos a la lista maestra de equipo mínimo y la lista de equipo mínimo, exigidos a las aeronaves civiles dedicadas al transporte aéreo comercial y a los trabajos aéreos. 380

Real decreto por el que se aprueba el desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal Las Autoridades Aeronáuticas Conjuntas (JAA), organismo asociado a la Conferencia Europea de Aviación Civil (CEAC), e integrado por las Autoridades nacionales de aviación civil de los Estados europeos firmantes de los Acuerdos sobre la elaboración, aceptación y puesta en práctica de los requisitos conjuntos de aviación (Chipre 1990), acordaron el 1 de junio de 2000 los requisitos conjuntos de aviación (JAR) relativos a la lista maestra de equipo mínimo (Master Minimum Equipment List o MMEL), y la lista de equipo mínimo (Minimum Equipment List o MEL) denominados JAR MMEL/MEL. Estos requisitos conjuntos de listas maestras y listas de equipos mínimos (JAR- MMEL/MEL) fueron incorporados al ordenamiento jurídico español mediante la Orden FOM/3538/2003, de 9 de diciembre, para su aplicación a los aviones civiles de transporte aéreo comercial, en desarrollo del Real Decreto 220/2001, de 2 de marzo, por el que se determinan los requisitos exigibles para la realización de las operaciones de transporte aéreo comercial por aviones civiles. La utilización de estas listas de equipo aporta cierta flexibilidad para operar aeronaves que de otro modo quedarían forzosamente inoperantes, en ausencia del personal certificador que pueda analizar en que grado se ve afectada la seguridad del vuelo con dicho defecto. El Reglamento (CE) n.º 2042/2003 de la Comisión, de 20 de noviembre de 2003, sobre el mantenimiento de la aeronavegabilidad de las aeronaves y productos aeronáuticos, componentes y equipos y sobre la aprobación de las organizaciones y personal que participan en dichas tareas, cuyo ámbito de aplicación abarca a casi todas las aeronaves civiles, salvo algunas excepciones expresamente determinadas en el mismo, prevé la posibilidad de que el piloto al mando de la aeronave o el personal certificador autorizado pueda utilizar la lista de equipo mínimo aprobada y exigida por la autoridad competente, en caso de que surjan defectos en la aeronave. Por lo expuesto, y tras la reciente aprobación del Real Decreto 279/2007, de 23 de febrero, por el que se determinan los requisitos exigibles para la realización de las operaciones de transporte aéreo comercial por helicópteros, así como, el gran desarrollo alcanzado en el campo de los trabajos aéreos, este real decreto tiene por finalidad de establecer los requisitos exigidos para la utilización de la lista maestra de equipo mínimo y la lista de equipo mínimo, por todas las aeronaves que realizan transporte aéreo comercial o trabajos aéreos, en aplicación de lo dispuesto en el artículo 20.4 de la Ley 48/1960, de 21 de julio, de Navegación Aérea, y al amparo de la habilitación prevista en la disposición final cuarta de la misma Ley. Asimismo, se establece el procedimiento para la aprobación o, en su caso, aceptación, de las mencionadas listas (lista maestra de equipo mínimo MMEL y lista de equipo mínimo MEL), y se incorpora la enmienda 1 adoptada por las Autorida- des Aeronáuticas Conjuntas (JAA) el 1 de agosto de 2005, en relación con los requisitos conjuntos de aviación antes mencionados (JAR-MMEL/MEL). En su virtud, a propuesta de la Ministra de Fomento, con la previa aprobación del Ministro de Administraciones Públicas, de acuerdo con el Consejo de Estado y 381

La protección de datos personales: Soluciones en entornos Microsoft previa deliberación del Consejo de Ministros en su reunión del día 28 de diciembre de 2007, DISPONGO: Artículo 1. Objeto y ámbito de aplicación. Este real decreto tiene por objeto la determinación de los requisitos exigibles para la utilización, aprobación o, en su caso, aceptación de los documentos denominados lista maestra de equipo mínimo (MMEL), y lista de equipo mínimo (MEL), de las aeronaves civiles dedicadas al transporte aéreo comercial y a los trabajos aéreos que operen en España. Artículo 2. Definiciones. A los efectos de este real decreto se entenderá por: a) Extensión del intervalo de corrección: consiste en la ampliación de la duración del Intervalo de Corrección sujeto a los condicionantes recogidos en este real decreto. b) Intervalo de corrección: significa una limitación en la duración de operaciones con equipos inoperantes. c) Lista maestra de equipo mínimo (MMEL): lista maestra establecida para un tipo de aeronave, que determina los instrumentos, elementos del equipo o funciones que pueden no estar en funcionamiento temporalmente manteniendo el nivel de seguridad pretendido por las correspondientes especificaciones de la certificación de aeronavegabilidad, debido a la redundancia del diseño de la aeronave o a procedimientos, condiciones o limitaciones específicas de carácter operacional o de mantenimiento, y de conformidad con los procedimientos aplicables para el mantenimiento de la aeronavegabilidad. 382

Glosario de términos Afectado o interesado. Persona física titular de los datos que sean objeto del tratamiento. Ejemplo. En esta definición entraríamos todos los individuos de los que se pueden obtener datos. Debemos tener claro, que el titular de los datos no es quien los posee en un fichero, sino el propio individuo al que corresponden esos datos. Cancelación. Procedimiento en virtud del cual el responsable cesa en el uso de los datos. La cancelación implicará el bloqueo de los datos, consistente en la identifi- cación y reserva de los mismos con el fin de impedir su tratamiento excepto para su puesta a disposición de las Administraciones públicas, Jueces y Tribunales, para la atención de las posibles responsabilidades nacidas del tratamiento y sólo durante el plazo de prescripción de dichas responsabilidades. Transcurrido ese plazo deberá procederse a la supresión de los datos. Ejemplo. El ejercicio del derecho de cancelación dará lugar a que se supriman los datos que resulten ser inadecuados o excesivos, sin perjuicio del deber de bloqueo conforme a este reglamento. Los datos de carácter personal deberán ser conservados durante los plazos previstos en las disposiciones aplicables o, en su caso, en las relaciones contractuales entre la persona o entidad responsable del tratamiento y el interesado. Cesión o Comunicación de Datos. Tratamiento de datos que supone su revelación a una persona distinta del interesado. Ejemplo. Se considera cesión de datos la simple comunicación, visualización o consulta que un tercero realice, aunque sea a distancia y sin creación de un nuevo fichero o tratamiento nuevo. Consentimiento del Interesado. Toda manifestación de voluntad, libre, inequívo- ca, específica e informada, por la que el interesado consienta el tratamiento de datos personales que le conciernen. Ejemplo. Supone que el titular autoriza el tratamiento de sus datos. Como regla general, no se podrán tratar datos de carácter personal sin el consentimiento de su titular. Además, en algunos casos concretos, la Ley exige una determinada forma de consentimiento; por ejemplo, por escrito. Dato Disociado. Aquél que no permite la identificación de un afectado o interesado. Ejemplo. Dato que no permite identificar a nadie. Por ejemplo, los datos estadís- ticos, que no permiten identificar a las personas. Datos de Carácter Personal. Cualquier información numérica, alfabética, gráfica, fotográfica, acústica o de cualquier otro tipo concerniente a personas físicas identificadas o identificables. Ejemplo. Nombre, DNI, dirección, profesión, dirección de correo electrónico, datos bancarios y cualquier otro tipo de información que esté vinculada a una 383

La protección de datos personales: Soluciones en entornos Microsoft persona física. La Ley sólo protege a las personas físicas. Las personas jurídicas no están bajo su amparo. Datos de Carácter Personal Relacionados con la Salud. Las informaciones concernientes a la salud pasada, presente y futura, física o mental, de un individuo. En particular, se consideran datos relacionados con la salud de las personas los referidos a su porcentaje de discapacidad y a su información genética. Ejemplo. Los integrantes de la Historia Clínica, datos de minusvalía, prácticas sexuales, etc. Destinatario o Cesionario. La persona física o jurídica, pública o privada u órgano administrativo, al que se revelen los datos. Podrán ser también destinatarios los entes sin personalidad jurídica que actúen en el tráfico como sujetos diferenciados. Ejemplo. La Agencia Tributaria es destinatario de los datos referentes a los salarios y retenciones efectuadas por una empresa a sus empleados. Encargado del Tratamiento. La persona física o jurídica, pública o privada, u órgano administrativo que, solo o conjuntamente con otros, trate datos personales por cuenta del responsable del tratamiento o del responsable del fichero, como consecuencia de la existencia de una relación jurídica que le vincula con el mismo y delimita el ámbito de su actuación para la prestación de un servicio. Podrán ser también encargados del tratamiento los entes sin personalidad jurídica que actúen en el tráfico como sujetos diferenciados. Ejemplo. En ocasiones, la persona que efectúa el tratamiento de los datos no es el propio responsable del fichero, sino un tercero al que éste contrata para que realice una tarea en su nombre. Este tercero no decide sobre la finalidad, el objeto y el tratamiento de los datos, sino que recibe instrucciones del responsable del fichero para tratarlos. El ejemplo típico es la elaboración de las nóminas por una gestoría. Exportador de Datos Personales. La persona física o jurídica, pública o privada, u órgano administrativo situado en territorio español que realice, conforme a lo dispuesto en el presente Reglamento, una transferencia de datos de carácter personal a un país tercero. Ejemplo. Las empresas que tienen una autorización para efectuar transferencia internacional de datos. Fichero. Todo conjunto organizado de datos de carácter personal, que permita el acceso a los datos con arreglo a criterios determinados, cualquiera que fuere la forma o modalidad de su creación, almacenamiento, organización y acceso. Ejemplo. Un fichero es tanto el conjunto de fichas en papel de los pacientes que un dentista guarda por orden alfabético, como la más sofisticada base de datos de clientes de una multinacional en forma automatizada. Ficheros de Titularidad Privada. Los ficheros de los que sean responsables las personas, empresas o entidades de derecho privado, con independencia de quien ostente la titularidad de su capital o de la procedencia de sus recursos económi- cos, así como los ficheros de los que sean responsables las corporaciones de derecho público, en cuanto dichos ficheros no se encuentren estrictamente 384

Glosario de términos vinculados al ejercicio de potestades de derecho público que a las mismas atribuye su normativa específica. Ejemplo. Todos los ficheros de empresas privadas o públicas, comunidades de vecinos, profesionales independientes, etc. También aquellos ficheros de entidades públicas cuya finalidad no sea estrictamente pública (por ejemplo, el fichero de Formación de un Colegio Profesional). Ficheros de Titularidad Pública. Los ficheros de los que sean responsables los órganos constitucionales o con relevancia constitucional del Estado o las instituciones autonómicas con funciones análogas a los mismos, las Administraciones públicas territoriales, así como las entidades u organismos vinculados o dependientes de las mismas y las Corporaciones de derecho público siempre que su finalidad sea el ejercicio de potestades de derecho público. Ejemplo. Los ficheros de instituciones y organismos públicos, colegios profesionales, salvo que por su actividad sean considerados privados. Por ejemplo, el censo de habitantes de un municipio. Fichero no automatizado. Todo conjunto de datos de carácter personal organizado de forma no automatizada y estructurado conforme a criterios específicos relativos a personas físicas, que permitan acceder sin esfuerzos desproporcionados a sus datos personales, ya sea aquél centralizado, descentralizado o repartido de forma funcional o geográfica. Ejemplo. El archivo físico de historias clínicas de un hospital o el archivo de nóminas en formato papel de una empresa. Importador de Datos Personales. La persona física o jurídica, pública o privada, u órgano administrativo receptor de los datos en caso de transferencia internacional de los mismos a un tercer país, ya sea responsable del tratamiento, encargada del tratamiento o tercero. Ejemplo. Un call-center que realiza tratamiento de datos de un fichero de clientes de una empresa de un tercer país. Persona Identificable. Toda persona cuya identidad pueda determinarse, directa o indirectamente, mediante cualquier información referida a su identidad física, fisiológica, psíquica, económica, cultural o social. Una persona física no se considerará identificable si dicha identificación requiere plazos o actividades desproporcionados. Ejemplo. Aquella que puede ser identificada por los datos que poseemos en nuestros ficheros. Por ejemplo, número de historia clínica, fecha de nacimiento... Procedimiento de Disociación. Todo tratamiento de datos personales que permita la obtención de datos disociados. Ejemplo. Supone la utilización de datos sin que permita identificar a nadie. Por ejemplo, la realización de estadísticas no permite identificar a las personas. Responsable del Fichero o del Tratamiento. Persona física o jurídica, de naturaleza pública o privada, u órgano administrativo, que sólo o conjuntamente con otros decida sobre la finalidad, contenido y uso del tratamiento, aunque no lo 385

La protección de datos personales: Soluciones en entornos Microsoft realizase materialmente. Podrán ser también responsables del fichero o del tratamiento los entes sin personalidad jurídica que actúen en el tráfico como sujetos diferenciados. Ejemplo. El responsable de los ficheros es la empresa. La palabra clave en esta definición es “decida”, que nos permitirá distinguirlo de la figura del “encargado del tratamiento”. Existen dos tipos de ficheros en función de su responsable: ficheros de titularidad pública (por ejemplo, el padrón municipal) y ficheros de titularidad privada (los mantenidos por cualquier empresa privada, por ejemplo, fichero de personal). Tercero. La persona física o jurídica, pública o privada u órgano administrativo distinta del afectado o interesado, del responsable del tratamiento, del responsable del fichero, del encargado del tratamiento y de las personas autorizadas para tratar los datos bajo la autoridad directa del responsable del trata-miento o del encargado del tratamiento. Podrán ser también terceros los entes sin personalidad jurídica que actúen en el tráfico como sujetos diferenciados. Ejemplo. Cualquiera que sin autorización acceda a la información. Transferencia Internacional de Datos. Tratamiento de datos que supone una transmisión de los mismos fuera del territorio del Espacio Económico Europeo, bien constituya una cesión o comunicación de datos, bien tenga por objeto la realización de un tratamiento de datos por cuenta del responsable del fichero establecido en territorio español. Ejemplo. El envío de un fichero de clientes de una organización a un país fuera del espacio económico europeo. Tratamiento de Datos. Cualquier operación o procedimiento técnico, sea o no automatizado, que permita la recogida, grabación, conservación, elaboración, modificación, consulta, utilización, modificación, cancelación, bloqueo o supre- sión, así como las cesiones de datos que resulten de comunicaciones, consultas, interconexiones y transferencias. Ejemplo. Encontraría cabida aquí cualquier tipo de operación con datos personales: confección de nóminas, elaboración de listas de alumnos o asistentes a un congreso, envío de mailing, etc. Accesos Autorizados. Autorizaciones concedidas a un usuario para la utilización de los diversos recursos. En su caso, incluirán las autorizaciones o funciones que tenga atribuidas un usuario por delegación del responsable del fichero o tratamiento o del responsable de seguridad. Ejemplo. El acceso que realiza la empresa de mantenimiento informático. Autenticación . Procedimiento de comprobación de la identidad de un usuario. Ejemplo. Cualquier mecanismo o programa que permita identificar la contrase- ña de acceso, la huella dactilar, la firma electrónica, etc. Contraseña. Información confidencial, frecuentemente constituida por una cadena de caracteres, que puede ser usada en la autenticación de un usuario o en el acceso a un recurso. 386

Glosario de términos Ejemplo. Se ha impuesto el anglicismo “password”, pero también se pueden considerar contraseñas grabaciones para reconocimiento de voz, etc. Control de Acceso. Mecanismo que en función de la identificación ya autenticada permite acceder a datos o recursos. Ejemplo. En los ficheros de nivel alto, este control de accesos debe generar un fichero lógico de control de accesos y de denegación de accesos. Copia de Respaldo. Copia de los datos de un fichero automatizado en un soporte que posibilite su recuperación. Ejemplo. Comúnmente llamada copia de seguridad. Documento. Todo escrito, gráfico, sonido, imagen o cualquier otra clase de infor- mación que puede ser tratada en un sistema de información como una unidad diferenciada. Ejemplo. Historia clínica, una carta, una grabación de videovigilancia, etc. Ficheros Temporales. Ficheros de trabajo creados por usuarios o procesos que son necesarios para un tratamiento ocasional o como paso intermedio durante la realización de un tratamiento. Ejemplo. Un fichero temporal extraído de un fichero de personal para el análisis de las remuneraciones salariales del próximo ejercicio. Identificación. Procedimiento de reconocimiento de la identidad de un usuario. Incidencia. Cualquier anomalía que afecte o pudiera afectar a la seguridad de los datos. Ejemplo. La pérdida de información tanto por rotura de equipos informáticos como el extravío de documentación en formato papel. Perfil de Usuario. Accesos autorizados a un grupo de usuarios. Ejemplo. Es el conjunto de permisos de acceso a la información contenida en un fichero que se otorgan a un usuario. Recurso. Cualquier parte componente de un sistema de información. Desde una aplicación informática a una conexión remota. Responsable de Seguridad. La persona o personas a las que el responsable del fichero ha asignado formalmente la función de coordinar y controlar las medidas de seguridad aplicables. Ejemplo. Es la persona interna de la compañía, designada por el responsable del fichero, encargada de controlar y coordinar las medidas de seguridad que se hayan implementado en la compañía. No tiene responsabilidad de cara al exterior. Sistema de Información. Conjunto de ficheros, tratamientos, programas, soportes y en su caso, equipos empleados para el tratamiento de datos de carácter personal. Ejemplo. Es el conjunto de recursos que una organización utiliza para el tratamiento de los ficheros de información. Sistema de Tratamiento. Modo en que se organiza o utiliza un sistema de informa- ción. Atendiendo al sistema de tratamiento, los sistemas de información podrán ser automatizados, no automatizados o parcialmente automatizados. 387

La protección de datos personales: Soluciones en entornos Microsoft Ejemplo. Sistemas informáticos, sistemas de grabación de videovigilancia, archivos, etc. Soporte. Objeto físico que almacena o contiene datos o documentos, u objeto susceptible de ser tratado en un sistema de información y sobre el cual se pueden grabar y recuperar datos. Ejemplo. CD, DVD, Pen-Drive, disquetes, papel, etc. Transmisión de documentos: Cualquier traslado, comunicación, envío, entrega o divulgación de la información contenida en el mismo. Ejemplo. Correo electrónico, correo postal, página web, etc. Usuario. Sujeto o proceso autorizado para acceder a datos o recursos. Tendrán la consideración de usuarios los procesos que permitan acceder a datos o recursos sin identificación de un usuario físico. Ejemplo. No confundir usuario con empleado. Usuario es cualquiera que esté autorizado al acceso a la información, aunque la vinculación con la organización no sea laboral. Fuentes Accesibles al Público. Son aquellos ficheros cuya consulta puede ser realizada por cualquier persona, no impedida por una norma limitativa o sin más exigencia que, en su caso, el abono de una contraprestación. Ejemplo. Exclusivamente son el censo promocional, las guías de servicios de comunicaciones electrónicas (guías de teléfonos), listas de colegios profesionales, diarios y boletines oficiales y los medios de comunicación social. Derechos ARCO. Son los derechos de acceso, rectificación, cancelación y oposición. ACRÓNIMOS AEPD. Agencia Española de Protección de Datos: www.agpd.es. APDCAT. Agencia Catalana de Protección de Datos (Agéncia Catalana de Protecció de Dades): www.apdcat.net. APDCM. Agencia de Protección de Datos de la Comunidad de Madrid: www.madrid.org. AVPD. Agencia Vasca de Protección de Datos (Datuak Babesteko Euskal Bulegoa): www.avpd.euskadi.net. LOPD. Ley 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal. LORTAD. Ley Orgánica 5/1992, de 29 de octubre, de Regulación del Tratamiento Automatizado de los Datos de Carácter Personal. NOTA. Programa de notificación de ficheros al RGPD: Notificaciones Telemáticas a la Agencia. RGPD. Registro General de Protección de Datos. RLOPD. Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal. 388

Libro Lopd V2 Alta

by losalamos on Aug 21, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

Libro Lopd V2 Alta — Document Transcript