<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Blog de JL Abogadoteleco &#187; privacy by design</title>
	<atom:link href="http://blog.abogadoteleco.es/tag/privacy-by-design/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.abogadoteleco.es</link>
	<description>Un blog jurídico-técnico sobre las TIC</description>
	<lastBuildDate>Tue, 04 Jul 2017 09:40:42 +0000</lastBuildDate>
	<language>es-ES</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>https://wordpress.org/?v=4.1.42</generator>
	<item>
		<title>Orientaciones para la adaptación al RGPD</title>
		<link>http://blog.abogadoteleco.es/orientaciones-para-la-adaptacion-al-rgpd/</link>
		<comments>http://blog.abogadoteleco.es/orientaciones-para-la-adaptacion-al-rgpd/#comments</comments>
		<pubDate>Tue, 04 Jul 2017 09:17:29 +0000</pubDate>
		<dc:creator><![CDATA[jlabogadoteleco]]></dc:creator>
				<category><![CDATA[Protección de Datos]]></category>
		<category><![CDATA[análisis de riesgo]]></category>
		<category><![CDATA[dato personal]]></category>
		<category><![CDATA[DPD]]></category>
		<category><![CDATA[DPO]]></category>
		<category><![CDATA[EIPD]]></category>
		<category><![CDATA[privacidad]]></category>
		<category><![CDATA[privacidad desde el diseño]]></category>
		<category><![CDATA[privacy by design]]></category>
		<category><![CDATA[responsabilidad proactiva]]></category>
		<category><![CDATA[RGPD]]></category>
		<category><![CDATA[transparencia]]></category>

		<guid isPermaLink="false">http://blog.abogadoteleco.es/?p=136</guid>
		<description><![CDATA[Las entidades que actualmente cumplen la normativa relacionada con la protección de datos, en España, la LOPD, Ley Orgánica 15/1999, y el Reglamento que la desarrolla (RLOPD), RD 1720/2007, necesitan adaptar dicho cumplimiento al nuevo Reglamento General de Protección de Datos (RGPD), aprobado por la Unión Europea el 27 de abril de 2016 y que [&#8230;]]]></description>
				<content:encoded><![CDATA[<p style="text-align: justify;">Las entidades que actualmente cumplen la normativa relacionada con la protección de datos, en España, la LOPD, Ley Orgánica 15/1999, y el Reglamento que la desarrolla (RLOPD), RD 1720/2007, necesitan adaptar dicho cumplimiento al nuevo Reglamento General de Protección de Datos (RGPD), aprobado por la Unión Europea el 27 de abril de 2016 y que resulta de inmediata aplicación en toda la Unión sin necesidad de desarrollo ulterior por los Estados miembros. No obstante, y a pesar de haber entrado ya en vigor el 25 de mayo de 2016, el RGPD no será aplicable hasta el 25 de mayo de 2018, habiéndose previsto una vacatio legis de dos años para permitir una adaptación completa en dicho periodo de tiempo por parte de los sujetos obligados a su cumplimiento.</p>
<p style="text-align: justify;">El RGPD supone un cambio significativo en la forma de abordar las actividades necesarias para lograr el cumplimiento normativo en materia de protección de datos. Dicho cambio se puede resumir básicamente en los siguientes puntos de actuación:</p>
<p><span id="more-136"></span></p>
<ul style="text-align: justify;">
<li>Transitar de un modelo de cumplimiento de requisitos, recogidos en las actuales LOPD y RLOPD, a un modelo de <strong>responsabilidad proactiva</strong>, según el cual el responsable del tratamiento deberá ser responsable de tratar los datos personales con arreglo a los principios exigidos en el Reglamento y además será capaz de demostrarlo. Este nuevo modelo supone la necesidad de plantearse desde una perspectiva ex-ante la manera de tratar los datos de forma que se minimicen las posibles vulnerabilidades de los datos personales tratados (quiebras de seguridad).</li>
<li>Modular las medidas de seguridad que se deben adoptar en función del <strong>análisis de riesgo </strong>de los tratamientos de datos realizados, según el tipo de tratamiento, la naturaleza de los datos, su volumen y el número de personas afectadas.</li>
<li>Incrementar la <strong>transparencia</strong> de forma que se comunique a los interesados la información que les afecte de forma concisa, transparente, inteligible y de fácil acceso, con un lenguaje claro y sencillo, además de hacerlo de forma expresa, precisa e inequívoca como requería la LOPD.</li>
<li>Analizar con carácter previo al desarrollo de cualquier proyecto que implique un tratamiento de datos personales, las medidas organizativas y técnicas adecuadas para integrar en dicho tratamiento las garantías que permitan aplicar de forma efectiva los principios del RGPD (<strong>Privacidad desde el diseño</strong>) y adoptar las medidas que garanticen que solo se tratan los datos necesarios (<strong>Privacidad por defecto</strong>).</li>
<li>Nombrar un <strong>Delegado de Protección de Datos</strong> (<strong>DPD</strong>), cuyas funciones principales sean asesorar a la entidad en todo lo relativo al cumplimiento normativo en materia de protección de datos, actuar como punto de contacto con las autoridades de control y con los interesados en todo lo que tenga relación con el tratamiento de sus datos personales. Su existencia será obligatoria tanto cuando el responsable del tratamiento de datos sea un organismo público, como cuando entre las actividades principales del responsable figuren, bien operaciones de tratamiento de datos que requieran una observación habitual y sistemática de interesados a gran escala<a href="#_ftn1" name="_ftnref1">[1]</a> o bien el tratamiento a gran escala de datos sensibles<a href="#_ftn2" name="_ftnref2">[2]</a>.</li>
<li>Llevar a cabo un procedimiento especial de evaluación, denominado <strong>Evaluación de Impacto</strong> (<strong>EIPD</strong>), con carácter previo a la puesta en marcha del tratamiento de datos personales, cuando dicho tratamiento pueda entrañar un alto riesgo para los derechos y libertades de los interesados.</li>
<li>Notificar las <strong>violaciones de seguridad</strong> de los datos que se produzcan a la autoridad competente, en España la Agencia Española de Protección de Datos (AEPD), a menos que sea improbable que la violación suponga un riesgo para los derechos y libertades de los afectados.</li>
</ul>
<p style="text-align: justify;">Para llevar a cabo las actividades de adecuación al nuevo Reglamento que en cada caso concreto se requieran, tanto las asociadas a cada uno de los puntos de actuación antes mencionados como las que resulten necesarias para adaptarse a todas sus precisiones normativas, es aconsejable realizar siempre un análisis preliminar basado en la situación particular de la entidad en materia de tratamiento de datos personales. En función de esa situación, será suficiente una sencilla autoevaluación llevada a cabo por el propio personal de la entidad, analizando por ejemplo la valoración simplificada elaborada por la AEPD<a href="#_ftn3" name="_ftnref3">[3]</a>, si se trata de una empresa que solo realiza tratamientos básicos, sin incorporar datos sensibles, sobre los datos de sus empleados, clientes y proveedores, o, por el contrario, se requerirá un análisis más detallado para el que resultaría aconsejable contar con el asesoramiento profesional de especialistas en protección de datos.</p>
<p style="text-align: justify;"><a href="#_ftnref1" name="_ftn1">[1]</a> La valoración del concepto “a gran escala”, que es un concepto jurídico indeterminado y, por ello, de valoración jurisprudencial, debe realizarse teniendo en cuenta el número de interesados afectados, el volumen y la variedad de los datos tratados, la duración y permanencia del tratamiento, así como su extensión geográfica. A modo de ejemplo y a falta de determinar el umbral entre lo que se considera o no “gran escala”, sí se considera así el tratamiento de datos de pacientes en el desarrollo normal de la actividad de un hospital y no se considera así el tratamiento de datos de pacientes a cargo de un médico.</p>
<p style="text-align: justify;"><a href="#_ftnref2" name="_ftn2">[2]</a> Son datos sensibles los relativos a salud, vida sexual, origen racial, ideología política, creencias religiosas o filosóficas, afiliación sindical, datos genéticos y biométricos e infracciones penales</p>
<p style="text-align: justify;"><a href="#_ftnref3" name="_ftn3">[3]</a> Guía del Reglamento General de Protección de Datos para Responsables del Tratamiento, Capítulo 10: Lista de verificación simplificada</p>
<p><script src="//platform.linkedin.com/in.js" type="text/javascript">// <![CDATA[
lang: en_US
// ]]&gt;</script><br />
<script type="IN/Share" data-url="http://blog.abogadoteleco.es/orientaciones-para-la-adaptacion-al-rgpd/"></script></p>
]]></content:encoded>
			<wfw:commentRss>http://blog.abogadoteleco.es/orientaciones-para-la-adaptacion-al-rgpd/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Protección de Datos desde el diseño en WhatsApp</title>
		<link>http://blog.abogadoteleco.es/proteccion-de-datos-desde-el-diseno-en-whatsapp/</link>
		<comments>http://blog.abogadoteleco.es/proteccion-de-datos-desde-el-diseno-en-whatsapp/#comments</comments>
		<pubDate>Mon, 27 Feb 2017 12:25:00 +0000</pubDate>
		<dc:creator><![CDATA[jlabogadoteleco]]></dc:creator>
				<category><![CDATA[Protección de Datos]]></category>
		<category><![CDATA[Telecomunicaciones]]></category>
		<category><![CDATA[identidad digital]]></category>
		<category><![CDATA[privacidad desde el diseño]]></category>
		<category><![CDATA[privacy by design]]></category>
		<category><![CDATA[verificación en dos pasos]]></category>
		<category><![CDATA[WhatsApp]]></category>

		<guid isPermaLink="false">http://blog.abogadoteleco.es/?p=112</guid>
		<description><![CDATA[La aplicación de los principios de protección de datos desde el diseño y por defecto recogidos en el RGPD debería llevar consigo, en mi opinión, una concienzuda revisión del software que subyace en el funcionamiento de las redes sociales o de las aplicaciones más utilizadas en la actualidad. Habitualmente, la facilidad de uso de una [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>La aplicación de los principios de protección de datos desde el diseño y por defecto recogidos en el RGPD debería llevar consigo, en mi opinión, una concienzuda revisión del software que subyace en el funcionamiento de las redes sociales o de las aplicaciones más utilizadas en la actualidad.</p>
<p>Habitualmente, la facilidad de uso de una aplicación se opone a su seguridad y, en concreto, a la relativa a la privacidad del usuario. Un ejemplo de ello se puede encontrar en la aplicación WhatsApp: ¿Puede WhatsApp basar de forma segura la identificación de usuario exclusivamente en su número telefónico, como ha hecho de forma ineludible hasta fecha muy reciente? <span id="more-112"></span> Sin duda, la respuesta es no, ya que el usuario al que un operador de red asigna un determinado número de teléfono puede dejar de tenerlo asignado y, de hecho, lo deja de tener frecuentemente. Por ejemplo, cuando el usuario se da de baja en el operador sin ejercer su derecho a la portabilidad o cuando una tarjeta SIM de prepago se deja de recargar durante un periodo superior al admitido por el operador.</p>
<p>Al quedar libre por cualquier razón el número asignado al usuario, el operador de red lo asignará de nuevo en un periodo de tiempo probablemente no muy grande, dada la escasez de numeración disponible.</p>
<p>Una de las consecuencias negativas que se derivan de ello, dada la implementación de la aplicación WhatsApp, es que, si el usuario anterior no ha tenido la precaución de darse de baja en dicha aplicación, cuando el nuevo usuario se dé de alta en ella sin activar la verificación opcional de la identidad mediante código de 6 dígitos recientemente introducida (verificación en dos pasos), WhatsApp no tendrá manera de saber que se trata de un nuevo usuario y <span style="text-decoration: underline;">le descargará datos personales del anterior</span>, tales como su foto, sus chats o los contactos participantes en estos chats, con los que el nuevo usuario podría, si quisiese, seguir manteniendo conversaciones sin que aquellos advirtieran que el usuario real ha cambiado<a href="#_ftn1" name="_ftnref1">[1]</a>. Esto, además de ser una cesión no consentida de datos por parte de WhatsApp, de cuya posibilidad desde luego no advierte en su Política de Privacidad, lo que sería sancionable ya con la legislación actual, supone un ejemplo evidente de negación de los principios de protección de datos desde el diseño y por defecto del RGPD, ya que no es admisible semejante agujero de privacidad sin haberlo advertido en un mínimo análisis durante la fase de diseño de la aplicación.</p>
<p>Es evidente que un número telefónico no puede ser un identificador único de usuario, máxime teniendo en cuenta que la aplicación es de uso global y que la asignación de números telefónicos está sometida a las diferentes condiciones existentes en la normativa de cada país. Si se prioriza la protección de datos desde que se comienza el diseño de una aplicación, como es preceptivo según el nuevo RGPD, es necesario establecer un método suficientemente robusto para evitar la suplantación de identidad, incluso inadvertida para el propio “suplantador”. Por ello, la verificación en dos pasos de la identidad debería ser preceptiva, en lugar de ser opcional como lo es actualmente.</p>
<p>Otra consecuencia negativa para el funcionamiento de WhatsApp, también derivada de identificar al usuario únicamente por su número telefónico, consiste en la posibilidad de mantener inadvertidamente conversaciones con alguien desconocido a quien hayan asignado el número telefónico de un contacto nuestro que ha abandonado dicho número sin darse de baja en WhatsApp. Sería de nuevo aplicable la anterior nota a pie de página si se ha habilitado la detección.</p>
<p>Durante el año pasado hemos asistido a una intensa campaña por parte de WhatsApp para ser percibido como un adalid de la privacidad en base a la inclusión del protocolo Signal para el cifrado de mensajes extremo a extremo, manifestando que nadie al margen de los interlocutores de un mensaje, ni siquiera el propio WhatsApp, puede acceder a su contenido. Esto, visto lo anterior, además de tratarse de una pura cuestión de fe mientras su software cliente no sea abierto, ya que ese software presenta el contenido del mensaje en la pantalla del terminal y por tanto existe la posibilidad de que lo cifre también con otra clave, lo transmita donde quiera, o haga lo que le venga en gana sin advertir de todo ello al usuario, es como tener una caja fuerte con otra puerta a la calle sin cerradura.</p>
<p><a href="#_ftnref1" name="_ftn1">[1]</a> Tan sólo podrían percibir que el usuario ha cambiado de terminal, siempre que haya habilitado en la configuración de su app esa opción que no lo está por defecto.</p>
<p><script src="//platform.linkedin.com/in.js" type="text/javascript"> lang: en_US</script><br />
<script type="IN/Share" data-url="http://blog.abogadoteleco.es/proteccion-de-datos-desde-el-diseno-en-whatsapp"></script></p>
]]></content:encoded>
			<wfw:commentRss>http://blog.abogadoteleco.es/proteccion-de-datos-desde-el-diseno-en-whatsapp/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
