Sie sind auf Seite 1von 47

ENSAYO DE INVESTIGACIÓN

UNA METODOLOGÍA SISTEMÁTICA DE IMPACTO SOBRE LA


PRIVACIDAD EVALUACIONES: UN ENFOQUE DE CIENCIA DEL DISEÑO

Resumen
Para las empresas que desarrollan y operan aplicaciones que procesan los datos
personales de los clientes y empleados, un problema importante es la protección de
éstos los datos y la prevención de violaciones a la privacidad. Si no se abordan
adecuadamente este problema puede resultar en un daño considerable a la reputación de
la empresa y finanzas, así como los efectos negativos para los clientes o empleados (de
los interesados).
Para abordar este problema, proponemos una metodología que sistemáticamente
considera la privacidad mediante el uso de una evaluación de impacto sobre la
privacidad paso a paso-(PIA). Enfoques PIA existentes no pueden aplicarse fácilmente
porque son inadecuadamente estructurado o imprecisa y largo. Sostenemos que las
empresas que emplear nuestro PIA puede lograr "intimidad mediante el diseño», que es
ampliamente anunciado por las autoridades de protección de datos. De hecho, la Oficina
Federal Alemana para la Información Seguridad (BSI) ratificó el enfoque que
presentamos en este artículo para la técnica campo de la RFID y lo publicó como una
guía en noviembre de 2011. La contribución de los artefactos que hemos creado es
doble: en primer lugar, ofrecemos un problema formal estructura de representación para
el análisis de los requisitos de privacidad. En segundo lugar, reducir la complejidad del
paisaje regulación de la privacidad para los profesionales que necesitan para tomar
decisiones de gestión de la privacidad para sus aplicaciones de TI.
Revista Europea de Sistemas de Información (2014) 23, 126-150. doi: 10.1057 /
ejis.2013.18; publicado en línea el 23 de julio 2013
Palabras clave: evaluación de impacto sobre la privacidad; intimidad mediante el
diseño; evaluación de los riesgos de seguridad; diseño ciencia.

Introducción
Mantenimiento y control de privacidad es un valor social profundamente arraigado en
nuestra la sociedad. Una encuesta mundial reveló que el 88% de la gente está
preocupada acerca de quién tiene el acceso a sus datos; más del 80% espera que los
gobiernos para regular la privacidad e imponer sanciones a las empresas que no utilizan
los datos de forma responsable (Fujitsu, 2010). Al mismo tiempo, somos testigos de un
mayor número de violaciones de la intimidad, incluyendo la fuga masiva de datos
personales a terceros no autorizados. En un rápido ritmo, sistemas técnicos están
evolucionando para permitir niveles sin precedentes de vigilancia. Estos desarrollos
exigen nuevos enfoques de privacidad protección.
Uno de estos enfoques es exigir a las empresas para llevar a cabo la privacidad
evaluaciones de impacto (PIA). Al igual que las evaluaciones de riesgos de seguridad
(NIST, 2002; ISO, 2008), PIA requieren las empresas para llevar a cabo una evaluación
del riesgo sistemático que escudriña las implicaciones de privacidad de sus operaciones
y los datos personales prácticas de manejo. PIA proponen identificar privacidad técnica
y organizativa amenazas y eligen controles que mitiguen esas amenazas. Típicamente,
la las evaluaciones se han completado temprano en el desarrollo de una aplicación
informática.
Siguiendo el principio de «intimidad mediante el diseño» (IPCO, 2011), estas
evaluación tos tienen como objetivo detectar problemas de privacidad durante el
desarrollo del producto y proactivamente construir técnicas de privacidad de mejora y
medidas en los sistemas. Idealmente, al menos algunos resultados de PIA sean
publicitados en los sitios web de las empresas o de los gobiernos de manera que las
instituciones pueden demostrar su responsabilidad. Y las autoridades de protección de
datos pueden utilizar PIA reporta a entender las prácticas de manipulación de los datos
de las empresas, sus esfuerzos de privacidad y cumplimiento legal. El Madrid
Resolución, que fue firmado por 50 protección de datos global funcionarios y
autoridades ción, alienta a las organizaciones a aplicar PIA (SDPA, 2009). La Comisión
Europea ha integrado el concepto de PIA en la nueva regulación propuesta de
protección de datos jurídica (CE, 2012). Y la Artículo 29 Grupo de Trabajo de
Protección de Datos Europea recientemente aprobado un Marco PIA para RFID
(INFSO, 2011). En el de la Comisión Federal de Comercio de Estados Unidos ha
requerido tanto Google y Facebook para llevar a cabo con regularidad para el PIA
próximos 20 años. A pesar del fuerte movimiento político para establecer PIA prácticas,
la adopción de PIA es todavía escasa, sobre todo en Europa. Mientras que los gobiernos
de Canadá, Australia y los EEUU utilizamos PIA en áreas sensibles como la biometría,
la salud o la seguridad nacional, el sector privado no ha adoptado el concepto (Bennett
& Bayley, 2007). Esta falta de acción puede ser se explica por el hecho de que, hasta
ahora, la mayoría de los PIA no tienen sido obligatoria (Wright, 2011). Pero incluso si
se vuelven PIA obligatorio, no existen normas sobre cómo llevar a cabo los PIA; en
además, los enfoques actuales carecen de una metodología clara y fácil aplicabilidad.
Como mostraremos, ninguno de los enfoques describir un proceso paso a paso que una
empresa podría fácilmente implementar e integrar en su pro- gestión de riesgos procesos
(Wright et al, 2011). Para hacer frente a la falta de integridad conceptual y metodología
rigurosa para PIA existentes, se propone un conjunto de nuevas construcciones y un
modelo de referencia nuevo procedimiento para la realización sistemática PIA.
Extendemos trabajo previo en esta área de investigación por las experiencias de
transferencia y conceptos de las evaluaciones de riesgos de seguridad al dominio de
privacidad. Los objetivo de esta metodología PIA es complementar existente técnicas de
gestión de riesgo y tratamiento de datos proporcionen con una técnica formal para el
análisis específico del sistema los requisitos de privacidad. Para lograr este objetivo,
adoptamos la enfoque de investigación de la ciencia del diseño (Hevner et al, 2004;
Gregor, 2006; Hevner, 2007). Basado en un theore- existente base de conocimientos
tica, la investigación en ciencias de diseño típicamente consiste en la construcción y
evaluación de nuevos artefactos de TI, construcciones, modelos, métodos o instancias
para abordar problemas de TI de la organización. En este artículo, desarrollamos
construye para la representación y evaluación de privacidad requisito mentos, así como
una nueva metodología para la sistemática la ejecución de un PIA.
La siguiente sección de este artículo se revisan los conocimientos base para los PIA y
reflexiona sobre la relevancia ejecutado y ciclos de rigor (Hevner, 2007) que
proporcionan un contexto entorno de investigación. Por la presente, recordamos rencias
de Iivari gestion de usar no sólo la investigación previa, pero también práctico
problemas y artefactos existentes (Iivari, 2007) para lograr un método de investigación
constructiva riguroso. Analizamos conceptos actuales de la privacidad y protección de
datos, oportuna procedimientos de evaluación de la privacidad y metodologías
relacionadas para la evaluación de impacto de la seguridad. La tercera y cuarta
secciones documentan el ciclo de diseño ejecutado (Hevner, 2007) y sus iteraciones de
la construcción de artefactos y evaluación. La tercera sección describe una nueva
metodología que PIA desarrollado y probado. Aquí definimos construcciones,
incluyendo ción de la representación de los requisitos de privacidad en forma de los
objetivos de privacidad, y proponer la evaluación cualitativa técnicas para dar prioridad
a ellos con la ayuda de la protección categorías de demanda. La cuarta sección se
incluye la evaluación ción de nuestra metodología propuesta y construcciones en
términos de la utilidad absoluta mediante la investigación-acción. En particular, se
aplicar nuestro modelo de proceso de PIA al campo de la tecno- RFID gía, donde
probamos el modelo y establecimos a través la Oficina Federal Alemana para la
Seguridad de la Información (BSI) como una guía para el desarrollo de RFID con la
privacidad aplicaciones. Luego discutiremos las limitaciones del PIA, limitaciones de
nuestro enfoque y necesidades para el trabajo futuro. Cerramos con un resumen de
nuestro trabajo, reflexionando sobre sus contribuciones de una perspectiva ciencia del
diseño.
Abordar los problemas de privacidad: una revisión de la actual base de
conocimientos:
La metodología PIA se presenta se basa en una crítica revisión de construcciones y
procedimientos existentes. Reflexionamos sobre los elementos que informaron nuestra
metodología PIA: existentes procedimientos de cumplimiento de privacidad, los
principios de privacidad, regulación ciones y procedimientos de evaluación como el
impacto de seguridad evaluaciones.
Procedimientos de cumplimiento y privacidad existentes intimidad mediante el
diseño:
Legales verificaciones de cumplimiento son los más comúnmente utilizados
procedimientos de evaluación de la privacidad en la mayoría de los países hoy en día.
Estas comprobaciones de cumplimiento se basan en leyes que aborden cuestiones de
protección de datos; los controles se llevan a cabo por com- , los datos nacionales
empresas 'oficiales internos de protección de datos las autoridades de protección o
negocios privadas de auditoría. Algunas instituciones de cumplimiento de la privacidad
también emiten un sello de privacidad para empresas; este sello informa a los
consumidores acerca de la privacidad los esfuerzos de esa empresa (es decir,
BBBOnLine, 2011; EuroPriSe, 2011; TRUSTe, 2011). A pesar de su valor,
cumplimiento actual procedimientos ANCE enfrentan algunos retos: En primer lugar,
que en su mayoría llevará a cabo al final de un ciclo de desarrollo del sistema o incluso
más tarde, cuando el sistema ya está en marcha y funcionando. Por lo tanto, los
procedimientos de revisión de diseños de sistemas existentes (Shroff, 2007), que sólo se
puede fijar en un atornillado de mano y la moda a menudo costoso. En segundo lugar,
los procedimientos no se hacen por los ingenieros que diseñan el sistema, pero por los
auditores, abogados o funcionarios de protección de datos, que sólo se ejecutan a través
una lista de comprobación para determinar el cumplimiento legal. Estos procedimientos
son incapaces de influir más "código de base 'y riguroso controles de privacidad.
Controles de cumplimiento actuales carecen de Terceros un procedimiento estándar, en
parte porque pro- datos nacionales leyes de protección y procedimientos de sellado
privacidad varían. Adicionalmente, mayoría de las empresas no incorporan la gestión de
la privacidad en los controles de calidad que se garantiza mediante estandarizados
procedimientos de riesgos. Con la creciente presión pública para la protección de la
privacidad, PIA se consideran ahora como complementos o sustitución mentos para
estos procedimientos actuales (CE, 2009). PIA surgido a mediados de la década de 1990
en Australia, Canadá, Hong Kong, Nueva Zelanda y los EE.UU. (Wright et al, 2011).
Los PIA primer europeo fue iniciada por el Reino Unido en 2007 (ICO, 2009). Stewart
(1996) describe un PIA de la siguiente manera: "En gran medida, PIA están dirigidas no
sólo hacia los temas del cumplimiento legal, pero las opciones políticas que participan
en responder a las preguntas "debemos hacer esto" 'Bennett & Bayley (2007) identificó
cuatro requisitos PIA comunes: (1) 'llevar a cabo una identificación prospectiva de los
problemas de privacidad o riesgos antes de los sistemas y programas se ponen en
marcha, o modificado ", (2)" evaluar los impactos en términos más amplios que los de
cumplimiento legal ", (3) 'ser el proceso más que salida orientada ', y (4)' sea sistemática
". En este fondo, definimos un PIA como una evaluación de riesgos metodología
utilizada de forma proactiva en el diseño o la fase de actualización de TI sistema para
hacer que el sistema de privacidad amable y cumple con la legislación de protección de
datos. Un PIA tiene la intención de superar las deficiencias de legal controles de
cumplimiento de varias maneras: En primer lugar, un PIA acom-Nies todas las etapas
de un proyecto de desarrollo del sistema, a partir lo antes posible y que influyen en el
sistema las decisiones de diseño en todo el desarrollo del sistema ciclo de vida (Bennett
& Bayley, 2007; Clarke, 2009; Wright et al, 2011). Por lo tanto, no es un control de
conformidad de una sola vez al final de un proyecto, pero un REQUISITOS curso el
ejercicio de la ingeniería. En segundo lugar, un PIA implica normalmente técnicos y
legales y otros grupos de interés relevantes titulares, que pueden ofrecer perspectivas
sobre un sistema de TI más allá del cumplimiento legal (Jeselon y Fineberg, 2011). En
tercer lugar, porque ofrece un enfoque de gestión de riesgos que incluye procedimientos
estandarizados para la forma de evaluar y mitigar los riesgos (por ejemplo, NIST, 2002;
Seibild, 2006; ISO, 2008; BSI, 2008), un PIA debe conducir a mejo- técnica concreta
vimientos o cambios de diseño en un sistema. Como resultado, PIA superar el enfoque
en gran medida cualitativa de la legal dominio cumplimiento. PIA son un medio
fundamental para hacer frente a uno de los núcleos preocupaciones de privacidad
comunidad de hoy en día, que es el establecimiento de la privacidad por diseño (Jeselon
y Fineberg, 2011). 'Privacy by Design es una empresa de ingeniería y estratégico
enfoque de gestión que se compromete en forma selectiva y minimizar sostenible
privacidad de sistemas de información ' riesgos a través de con- técnica y la gobernanza
proactiva controles '(Spiekermann, 2012). 'Privacy by Design' El término fue acuñado
por Ann Cavoukian, la información y Comisionado de Privacidad de Ontario, en la
década de 1990 (Cavoukian, 2009a). En su descripción de cómo acom-Plish privacidad
desde el diseño, ella nombra siete cipio rector ples: proactiva, por defecto, incrustado,
suma positiva, la protección del ciclo de vida, la visibilidad / transparencia, el respeto a
usuarios (Cavoukian, 2009b). Estos principios fueron más tarde ampliamente adoptada
como una resolución por otra de políticas prominentes fabricantes y PIA se esfuerzan
por seguir estos siete principios.
Privacidad por diseño se ha impulsado aún más por la creciente ing reconocimiento de
que el respeto a la privacidad de los usuarios no puede ser realizado a través de medidas
atornilladas-en que se agregan a un sistema después de que se despliega. Debido al
rápido cambio en la tecnología y la incapacidad resultante de prever todo las cuestiones
de privacidad, medidas de privacidad deben integrarse en las bases de un sistema, y PIA
son una clave significa hacerlo.
Metodologías de evaluación de riesgos que abordan la seguridad y problemas de
privacidad
En el núcleo de un PIA es una evaluación de riesgos. Evaluaciones de riesgo suelen
seguir un proceso claro de ambos identificación de riesgos y mitigación de riesgos.
Aunque se espera que los PIA de seguir la misma filosofía, PIA existentes caen en gran
medida a corto esto. Como muestra la Figura 1 demuestra, incluso el manual Reino
Unido PIA (ICO, 2009), que se considera una "mejor práctica mundial publicación
'sobre la forma de llevar a cabo un PIA (Clarke, 2011; Wright et al, 2011), es
metodológicamente no es adecuado para ser un modelo de referencia de proceso. No
hay factores de insumo-producto son descrito. Pasos del proceso son genéricos
("información recolectores ing "," análisis interno '). Y, lo más importante, individuales
riesgos no se corresponden con los controles respectivos. Como resultado, las personas
que llevan a cabo un PIA de acuerdo con el Reino Unido PIA Handbook libro son mal
informados sobre qué hacer cuando no son llevado a coincidir sistemáticamente
controles con riesgos. Tal PIA deficiencias son sintomáticos. Como es, no hay pautas
adecuadas o herramientas conceptuales suficientemente apoyan riesgo para la
privacidad evaluaciones. A nuestro entender, la única directriz PIA con un válido
modelo de proceso es el Marco PIA para RFID, que era aprobado por el Grupo de
Trabajo del artículo 29 y firmado por la Comisión Europea el 6 de abril de 2011
(INFSO, 2011).

Figura 1 Estado del arte en la metodología PIA: proceso de Reino Unido PIA (ICO,
2009).
Este marco alienta aplicación RFID Europea operadores para ejecutar a través de un
proceso de PIA de cuatro pasos: (1) describir su infraestructura de sistemas, (2)
identificar los riesgos de privacidad, (3) mitigar esos riesgos mediante controles
adecuados, y (4) el documento de análisis y riesgos residuales en un PIA informe. Esta
metodología de cuatro pasos ha sido llamado un 'hito para la privacidad por diseño "por
protección de datos de Ontario autoridades ción, que inventaron el concepto de
intimidad por caso diseño. Sin embargo, en comparación con un riesgo de seguridad
equivalente evaluación (ver Figura 2), el Marco de PIA para la RFID es
metodológicamente débiles. Por lo tanto, revisamos existente procesos de riesgo de
seguridad para informar a la creación de un nuevo PIA metodología.

Las normas y pautas para la dirección de seguridad de información en la organización


han estado disponibles para algún tiempo. Los más prominentes son los ISO/IEC 27000
serie y NIST las Publicaciones Especiales 800 serie. En Alemania, La Oficina federal
para la Seguridad de Información (BSI) proporciona la industria con un ÉL el Catálogo
de Protección Básica (‘BSI ITGrundschutz ') (BSI, 2011a). Similar al ejemplo de NIST
pintado en Figura 2, estas normas incluyen enclavado pasos que construyen en nosotros;
para controlar para todo pertinente los riesgos, las normas emparejan cada amenaza del
sistema con un mando respectivo. El más pretenciosamente, todos que estas normas
ofrecen a las pautas eso puede integrarse en la dirección de riesgo de un organización
los procesos (vea: NIST, 2002,; BSI, 2008,; ISO, 2008). El
Los pasos detallados y los artefactos de una valoración de seguridad permitan a una
compañía evaluar el riesgo coherentemente. Además, los procedimientos de riesgo de
seguridad regularizados describen cuando cada paso debe ocurrir en el desarrollo del
sistema el lifecycle. Los problemas de seguridad son considerados tempranos en el
desarrollo y aplicación de ÉL las aplicaciones. El las disminuciones del acercamiento
echar el cerrojo a-adelante la funcionalidad de seguridad y promueve el seguridad-por-
plan. No obstante, investigadores describen problemas que son inherente en las
valoraciones de riesgo de seguridad existentes que nosotros por consiguiente necesite
considerar para nuestra metodología propuesta: un enfoque en el proceso y no en el
volumen y su la calidad (Siponen, 2006), enfoque en los requisitos de seguridad
genéricos al gasto de requisitos compañía-específicos (Siponen & Willison, 2009), y la
aprobación basó adelante la práctica común y no en los métodos de la investigación
profundos (Siponen & Willison, 2009).Como el retiro y valoraciones de seguridad es
complementario, no es sorprendente que ISO/IEC 27002 y BSI.
Él-Grundschutz incluya protección del retiro. Sin embargo, analizando estas normas que
el retiro de ' detalla, la norma de ISO, las políticas de retiro de hojas y medidas no
especificado. Aunque el BSI Él-Grundschutz aplica el análisis de riesgo de seguridad a
los principios del retiro, reduce protección del retiro al los conceptos de anonimidad, el
pseudonymity, el unobservability, y unlinkability (BSI, 2008). Como resultado, la
norma no abraza el espectro más ancho de protección de los datos los principios
inherente en la Protección de los Datos europea Director o las OCDE retiro pautas.

LOS PRINCIPIOS DEL RETIRO Y LA REGULACIÓN DE


PROTECCIÓN DE LOS DATOS

Para diseñar un análisis del retiro o PIA, uno debe determinar primero qué necesita ser
protegido (Rost, 2011). Desgraciadamente, El Retiro de ‘es un camaleón-como la
palabra, el denotatively usado a designe una gama amplia de intereses extremamente
dispares–de la confidencialidad de información personal a reproductor la autonomía–y
connotatively para generar el buena voluntad adelante el nombre de interés cualquier
está afirmándose en su nombre '(Lillian Bevier citó en Solove, 2006). Solove (2002)
conceptuó el retiro a lo largo de las dimensiones múltiples: limitado el acceso al ego
(construyendo en Warren & Brandeis ' (1890) el concepto del ‘' derecho-a-ser-permitir-
solo), secreto (la ocultación de ciertas materias de otros), controle encima de personal
la información (en la línea con Westin (1967) el énfasis en el retiro de información),
protección del personhood de uno (por lo que se refiere a protección de la personalidad
de uno, individualidad y dignidad ante la vigilancia) e interpersonal la intimidad. El
REINO UNIDO PIA Manual (ICO, 2009) es más resume, mientras declarando que un
PIA no sólo debe considerar el retiro de información personal, pero también el retiro de
la persona, behaviour personales y comunicaciones personales. Porque el retiro es una
estructura multidimensional, muchos, los estudiosos del retiro defienden ese retiro se
extiende más allá del la noción de protección de los datos que el ambiente legal actual
los enfoques en (es decir, Raab & Wright, 2012). Los Estudiosos la nota que las OCDE
retiro pautas (OCDE, 1980) y las regulaciones europeas se agrupan a menudo las
políticas de protecciones de los datos con el término el retiro de ‘' pero caída corto de
abrazar el retiro como un concepto más ancho. Por ejemplo, los estudiosos critican el
Artículo 33 de la propuesta para la regulación de una nueva EU datos protección.
El artículo sólo se refiere a las valoraciones de impacto de ‘datos protecciones ' (CEE,
2012), pero debe asignar el impacto del retiro las valoraciones; como resultado, el
artículo no puede aplicar a algunos áreas dónde el retiro está en la estaca.
Nosotros apuntamos para resolverse esta batalla de condiciones preguntando si las
reglas de las protecciones de los datos perfilaron en los datos europeos protección
director (y su regulación del sucesor), OCDE las pautas y los Principios de Práctica de
Información Justos (FTC, 1998) suficientemente la dirección el espectro lleno de retiro
amenazas que pueden causarse por ÉL los sistemas. Si protección de los datos las reglas
pueden dirigirse suficientemente o pueden mitigar todas las amenazas del retiro
conocido para ser causado por ÉL los sistemas, nosotros podemos decir que–en el
contexto de ÉL–las reglas de protecciones de los datos y reglas del retiro son
eficazmente el mismo.
Para fechar, Solove (2006) probablemente ha producido el más lista completa de
amenazas del retiro. Esta lista incluye las amenazas del retiro observaron durante un
siglo de EE.UU. legal la historia. Las amenazas incluyen: los casos de vigilancia y falso
la interrogación, los casos de información abundante e ilegal, procesando en la forma de
agregación de los datos, personal, la identificación, los datos indefensos, los datos
secundarios no deseados, usos o la exclusión individual, casos dónde la información la
primacía de la diseminación para abrir brecha de confidencialidad, no deseado, los
descubrimientos, la exposición personal, la accesibilidad aumentada para las
instituciones privadas y gubernamentales, chantaje o apropiaciones y distorsiones, y
casos de invasión en la forma de intrusión física o virtual e interferencia de decisión.
Nosotros creemos que más estudiosos del retiro habría acepte esta lista de problemas
como un cuadro relativamente completo de la estructura del retiro.
A extenso explore las similitudes y diferencias entre las reglas de protecciones de los
datos y el retiro gobierna, nosotros combinamos. La lista de Solove de amenazas del
retiro con protección de los datos la regulación. Nosotros investigamos entonces si
rigurosamente siguiendo la regulación de la protección de los datos actual habría
suficientemente diríjase todas las amenazas del retiro conocidas. Si los datos la
regulación de protección es suficiente, un retiro electrónico, el esfuerzo podría tener
éxito siguiendo la legislación de protección de los datos. El apéndice UN resume todos
los elementos de la corriente y propuso la regulación de EU datos protección (CEE,
1995,; CEE, 2012) y de los principios de todo las protecciones de los datos incluido en
las OCDE retiro pautas (OCDE, 1980) y los Principios de Práctica de Información
Justos (FTC, 1998). La mesa lleva a dos conclusiones: Primero, si las compañías toman
los datos la regulación de protección en serio, particularmente introduciendo la calidad
de los datos alta y normas de seguridad, entonces todos, amenazas del retiro
identificadas por Solove (2006) se dirige. Segundo, la regulación de protección de los
datos proporciona a las personas con la libre determinación adicional corrige para la
información que vaya más allá del dominio del retiro. Para nuestros propósitos, el
primero la conclusión es la más importante. La mesa muestra las reglas de esa
protección de los datos apoyan la mitigación de todos las amenazas del retiro
potenciales. Por ejemplo, Solove describe cómo el retiro se daña por agregación de los
datos que es la creación de un revelar favorablemente y relativamente completo el perfil
de un individuo de las fuentes de los datos múltiples. Si los datos las reglas de
protecciones se siguen en el sentido que directores de los datos evite los datos
colectivos (P1.5), adhiera al minimisation de los datos (P1.6), y restringe el proceso a
pre-convenido los propósitos legítimos (P2.1 y P2.2), será difícil para directores de los
datos para crear el tipo de agregados de los datos legalmente ese gentes de daño el retiro
de’. Porque pueden dirigirse las amenazas del retiro a través de existir las regulaciones
de protecciones de los datos, nosotros defendemos que el PIA metodología que nosotros
presentamos es de hecho una valoración de impacto de retiro y no sólo la valoración de
una protección del datos manejada por una necesidad para la complacencia.

LA METODOLOGÍA DE PIA Y ESTRUCTURAS

Contra el fondo de la base de conocimiento descrita (Las metas de PIA, las referencias
de valoración de riesgo, el retiro construye), nosotros hemos desarrollado un siete-paso
la metodología de PIA (Figura 3) eso es basado en el riesgo de BSI ampliamente
adoptado el método (BSI, 2008). UN PIA se activa cuando un nuevo sistema se planea o
un existiendo uno se actualiza. Así, aunque los extremos de la metodología presentados
con el séptimo paso y no se pinta como cíclico, es un proceso continuado que ocurre en
paralelo con el proceso de desarrollo de sistema. Siempre que un sistema cambie, un
PIA se activa, los siete se dirigen los pasos y la documentación existente y deben
ponerse al día las resoluciones y deben verificarse para su validez.
El PIA puede referirse a una aplicación autosuficiente o un programa eso es incluido en
un backend conectados una red de computadoras más anchos la infraestructura. Las
valoraciones de riesgo de retiro no son necesarias en todas las situaciones. Ellos sólo
son aconsejables si un sistema usará o genere los datos personales o cuando puede
ayudar enriquecer bancos de datos adyacentes que contienen los perfiles personales.
Para esto razone, el primer paso de un PIA requiere una consideración completa del
sistema bajo el escrutinio y su adyacente la infraestructura. En la línea con los líderes
del pensamiento en el retiro diseñe el dominio (Rost & Pfitzmann, 2009), nosotros
hacemos pensar en eso un PIA debe incluir una reflexión de principios del retiro eso
podría minarse por el sistema (Paso 2). O, en las condiciones diseñando, la valoración
debe incluir un la identificación de blancos del retiro que necesitan ser alcanzado a
través del plan del sistema. Todavía como en todo el desarrollo del sistema los
proyectos, no todos los blancos de plan de sistema son igualmente importantes.
Algunos blancos del retiro pueden ser cruciales porque ignorando ellos podrían dañar
un asunto del datos en serio. Pero otro los blancos del retiro pueden tener menos
prioridad, como su abandono, afecte asuntos de los datos o compañías apenas. Para esto
razone, Camine 3 de nuestro PIA propuesto procesan requiere el retiro los blancos de
desarrollo ser pesado y asignó a protección exija categorías que reflejan su importancia.
Entonces, las amenazas a cada uno de los blancos del retiro establecidos son
identificado (Paso 4). Cuando nosotros hemos visto en el riesgo de seguridad el
contexto, la identificación de amenazas es central al riesgo la valoración porque cada
amenaza necesita ser mitigada por uno o varios mandos. Si un explícito y detalló la
inscripción de todas las amenazas del retiro está extrañando, los mandos no pueden ser
individualmente asignado para oponerse a esas amenazas. Los mandos poniendo
oponerse a cada amenaza del retiro uno por uno es el más más el aspecto importante de
retiro-por-plan (Paso 5). Este ejercicio debe documentarse bien en un informe de PIA
(Paso 7) porque directores de los datos y procesadores pueden usarlo para demostrar
que ellos han trabajado para proteger los aspectos todo pertinentes de el retiro de un
asunto del datos. Directores de los datos también pueden usar esto ejerza para identificar
las amenazas que permanecen desenfrenadas; estas amenazas constituyen los riesgos
residuales (Paso 6). El las secciones siguientes explican cada paso de la metodología de
PIA nosotros proponemos.

ANDE 1–EL CARACTERIZACIÓN DEL SISTEMA

El primer paso de un PIA apunta para describir un sistema en tal un comprensivo y


detalló la manera que el retiro potencial pueden descubrirse los problemas. Para
minimizar el riesgo que la información pertinente va inadvertida, facilitar el retiro, las
auditorías y para construir en el caracterización del sistema los acercamientos de otros
procedimientos de valoración de riesgo (NIST,2002; ISO, 2002,; BSI, 2008,; ISO,
2008), nosotros recomendamos documentando un sistema basado en cuatro vistas:
1. la vista del sistema: la aplicación y componentes del sistema, el hardware, el
software, la interfaz interior y externas, la red, el topología;
2. la vista funcional: los procesos de negocio genéricos, el uso detallado, los casos,
los papeles y usuarios, los mandos técnicos,
3. Los datos ven: las categorías de datos procesados, los datos fluyen los diagramas
de datos interiores y externos fluye, mientras incluyendo actores y tipos de los datos;
4. la vista de ambiente física: la seguridad física y operacional los mandos como el
apoyo y contingencia. Para estar completos, los caracterización de un sistema deben
incorpore estas cuatro vistas y considere todo el sistema los componentes e interfaz que
están envuelto en el almacenamiento, procesando y transfiere de datos personales. Cada
interfaz debe verificarse para si permite los datos personales para ser transmitido a otro
componente; el datos fluye deba contener a actores todo pertinentes que están envuelto
en los datos la transmisión. A menudo, la tal documentación ya está disponible si se
diseñan bien los sistemas, está en un requerimiento en ingeniería fase o necesita sufrir el
análisis de seguridad.
Para un PIA, esta documentación podría necesitar ser modificada ligeramente para
asegurar que acentúa existiendo y potencial el dato fluye y el dato teclea más de la
funcionalidad del sistema. Este énfasis en los datos fluye modelos también se ha
perfilado por el ISO PIAS en la industria financiera (ISO, 2002). El desafío del centro
en esta fase de la documentación de un PIA es determinar los límites del sistema
correctos y así los recursos que necesitarán ser cubierto en la valoración. Por ejemplo, si
un minorista investiga un RFID-habilitó el sistema del inventario para las implicaciones
del retiro, el minorista deba determinar si para incluir el programa de lealtad los bancos
de datos en el análisis. Con el propósito del retiro el análisis, nosotros defendemos que
un límite del sistema se alcanza cuando el datos fluye el extremo o ninguno del
internamente o externamente los sistemas adyacentes son pertinentes para el retiro.
Porque el RFID inventa que la aplicación del sistema puede unirse fácilmente a una
base de lealtad de cliente, los datos de RFID podrían ser personalmente identificados
con el esfuerzo razonable. De un minorista habría se aconseje bien para incluir su
programa de lealtad en el análisis del retiro del sistema del inventario.

ANDE 2–LA DEFINICIÓN DE BLANCOS DEL RETIRO

Una valoración de riesgo apunta para entender lo que está al riesgo. Las valoraciones de
riesgo de seguridad existentes ven el idéntico de los recursos - el fied en el
caracterización del sistema de Paso 1 como la seguridad blancos que deben protegerse
(por ejemplo ISO, 2008). Aunque las valoraciones ofrecen las bibliotecas de blancos de
seguridad, éstos, las bibliotecas han empezado a ser elaboradas para el retiro
simplemente el dominio y no se regulariza todavía. En cambio, los catálogos legales y
las pautas en los principios del retiro dominan la escena (es decir FIPPs (FTC, 1998)).
Estos principios legales no son limitó a los problemas de protecciones de los datos,
cuando ellos abrazan el lleno el concepto de retiro (vea el Apéndice UN). en contraste
con el las bibliotecas de blancos de seguridad, los principios del retiro legales son
difícil para usar por evaluar la funcionalidad del sistema concreta o describiendo el plan
de sistemas. Los principios del retiro son difíciles usar porque ellos son semánticamente
diferentes y a menudo más genéricos que las funciones del sistema concretas que
ingenieros pueden construir o eso puede escrutarse en un PIA. Considere el principio
legal de calidad de los datos requerido por Sección 1 de la Protección de los Datos del
EU Director (CEE, 1995). Ingenieros piensan en calidad de los datos en mucho más
concreto las condiciones que eso que los contornos de la ley; las condiciones concretas
incluyen la integridad de los datos, precisión, integridad, timeliness o consistencia (El
Scannapieco et al, 2005). como resultado, retiro, la seguridad y los estudiosos legales
reconocen ese retiro legal deben traducirse los principios en el hormigón, auditable y
los blancos del retiro funcionalmente ejecutables y subsecuente el sistema funciona
(Rost & Pfitzmann, 2009,; Rost, 2011,; ENDOSE, 2011). Por esta razón, nuestra
metodología de PIA abraza el retiro de ‘ los blancos ' en lugar de los ‘retiro principios '.
PIAs debe enfocar en los objetos de hormigón de análisis (es decir las características del
sistema) y debe ayudar a ingenieros a identificar las metas del plan específicas. El
término los ‘retiro blancos ' apoya este esfuerzo y está en la línea con la redacción de
valoraciones de seguridad que son un complemento de y precursor para PIAs. Nosotros
reconocemos eso ambos el EU Datos Protección Director (CEE, 1995) y el La Norma
de ISO para la Arquitectura del Retiro (ISO, 2011) refiérase a los principios de ‘' dónde
nosotros usamos el término ‘' designado. Pero como la Mesa 1 muestras, nosotros
también hacemos pensar en formulando los blancos del retiro como los artículos de
acción, similar a las técnicas del modelado ampliamente aceptadas guste UML (se
Unificó el Idioma del Modelado) y ARIS (La arquitectura de Sistemas de Información
Integrados). Formulando los blancos de esta manera promueven la acción futura. Por
pensando por lo que se refiere a acciones que logran el desarrollo los blancos, nosotros
partimos claramente de pensar por lo que se refiere a los principios cuando viene a
dirigir un PIA. Eso dijo, nuestros blancos del retiro se derivan directamente de los
principios del retiro establecidos formularon en el EU Protección de los datos Director
(CEE, 1995) y la propuesta del EU para la regulación de nueva protección de los datos
(CEE, 2012). Esto el acercamiento está en la línea con dos normas de PIA oficiales
nosotros co-authored, a saber el Armazón de PIA para RFID (INFSO, 2011) y la BSI
PIA Pauta para las Aplicaciones de RFID (BSI, 2011b). se derivan los blancos del
Retiro de las leyes para varias razones: Primero, derivando los blancos del retiro de las
leyes implica ese compañías del europeo que atraviesan todos los blancos del retiro
asegurarán que ellos obedecen los datos las regulaciones de protecciones. Segundo,
porque los datos europeos la ley de protección es más exhaustiva que muchas otras
pautas en esta materia (como FIPPs (FTC, 1998)), derivando los blancos de plan de
retiro de él producen un muy exhaustivo la lista de blancos. Las leyes también reflejan
las normas aceptadas de moralidad que la sociedad ha escogido aceptar. Como
resultado, ellos constituyen una fundación a largo plazo más válida y fiable para el plan
del sistema que blancos del retiro que vienen fuera de un proceso del stakeholder ad
hoc.
Muchos estudiosos del retiro todavía apuntan a la importancia de el envolvimiento del
stakeholder en PIAs cuando viene al la identificación de blancos del retiro (Wright &
De Hert, 2012). Esos crítico de la nota de la ley que se retrasa tecnológico detrás
desarrollos o no cubre todo pertinente ético los aspectos de una tecnología específica
(Van Gorp & de Poel, 2008). aplicando costumbres establecidas, leyes, y normas, un
PIA ejecuta el riesgo de crear un ‘que derrota las ética ' que se cae corto de dirigirse los
desafíos éticos de un particular tecnología o aplicación (el moro, 1998). Nosotros por
consiguiente recomiende que los interesados desafían si los blancos derivado
adecuadamente de las leyes de protecciones de los datos la dirección el

Tabla 1 principios de privacidad y las metas de privacidad

P1 - Calidad de los datos


P1.1 Asegurar tratamiento justo y legítimo a través de la transparencia
P1.2 Asegurar el procesamiento únicamente para fines legítimos
P1.3 Proporcionar especificación propósito
P1.4 Asegurar procesamiento limitada para el propósito específico
P1.5 que garanticen la prevención de datos
P1.6 Asegurar minimización de los datos
P1.7 Asegurar calidad de los datos, la precisión y la integridad
P1.8 Asegurar almacenamiento limitado

P2 - legitimidad Procesamiento
P2.1 Garantizar la legitimidad del tratamiento de datos personales
P2.2 Garantizar la legitimidad del tratamiento de datos personales sensibles
P3 - Información correcta de las informaciones amparadas
P3.1 Proporcionar información adecuada en los casos de cobro directo
de los datos del titular de los datos
P3.2 Proporcionar información adecuada cuando los datos no ha sido obtenida
directamente del titular de los datos (por ejemplo, a partir de tercero fiestas)
P4 - derecho de acceso de las informaciones amparadas
P4.1 Facilitar el suministro de información sobre procesado datos y el propósito
P4.2 Facilitar la rectificación, supresión o bloqueo de los datos
P4.3 facilitar la portabilidad de los datos
P4.4 Facilitar la notificación a terceros sobre rectificación, supresión y bloqueo de los
datos
P5 - derecho del interesado a oponerse
P5.1 Facilitar la oposición al tratamiento de los datos personales
P5.2 Facilitar la objeción de dirigir las actividades de marketing
P5.3 Facilitar la objeción a la divulgación de datos a terceros fiestas
P5.4 Facilitar la objeción a las decisiones que se basa únicamente en un tratamiento
automatizado de los datos
P5.5 Facilitar derecho del interesado a disputar la corrección de las conclusiones de la
máquina.

P6 - Seguridad de los datos


P6.1 Garantizar la confidencialidad, integridad y disponibilidad de almacenamiento de
datos personales, el tratamiento y la transmisión
P6.2 Garantizar la detección de fugas de datos personales y su la comunicación a los
interesados
P7 - Rendición de cuentas
P7.1 Garantizar la rendición de cuentas de almacenamiento de datos de carácter
personal, procesamiento y transmisión

Problemas de privacidad inherentes a una nueva tecnología. Un ejemplo es un proceso


de partes interesadas que llevó a cabo en la tecnología RFID. Hemos encontrado que,
además de la privacidad RFID corre el riesgo de que están cubiertos por la ley, tales
como la recopilación de datos abundantes, los consumidores también tienen miedo de
ser constreñida por las capacidades de automatización de la tecnología. En su vida
privada casas, la gente considera las formas en que se ocupan de la objetos de su
propiedad para ser privado. La lista de objetivos para la privacidad Por lo tanto, los
bienes de consumo RFID deben incluir una apuntar como, 'que permite el control final
sobre automática reacciones del sistema '(Spiekermann, 2008). La lista de objetivos en
la Tabla 1 no incluye tecnología específica objetivos privacidad. Sin embargo, se
complementa con dos objetivos privacidad identificados por (Rost y Bock, 2011): En
primer lugar, los seres humanos se les debe permitir a disputar conclusiones de la
máquina (P5.5); segundo, en sus comunicaciones con los usuarios, las empresas debe
desacoplar las formas distintas que los datos son procesado (P1.3). Dado que estos
objetivos de privacidad no son incrustados en la mayoría de los marcos legales, sin
embargo, les añadimos a la lista. Para abordar el segundo problema con la seguridad
existente evaluaciones de riesgos, en el principio de esta segunda etapa, cada uno
objetivo privacidad debe ser descrito en el contexto de la industria o compañía contexto
respectivo. Los - privacidad lista de objetivos en la Tabla 1 es un buen punto de
referencia para la evaluación los impactos de privacidad de un sistema. Pero debido a la
privacidad concepto abarca un amplio espectro conceptual y se dirige por una variedad
de leyes nacionales o regulaciones específicas de la industria, pueden y deben añadir
más objetivos. Dónde posible, un proceso de partes interesadas debe cuestionar y
discutir la aplicabilidad, el significado y la exhaustividad de la objetivos en un contexto
específico.

PASO 3 - EVALUACIÓN DEL GRADO DE DEMANDA DE PROTECCIÓN


PARA CADA OBJETIVO PRIVACIDAD

No todos los objetivos de privacidad resumidos en la Tabla 1 son aplicables a todos los
sistemas. Por ejemplo, para algunos sistemas que recogen los datos, tales como los
sitios de sexo o bases de datos de salud, la gente puede ser muy sensible acerca de la
divulgación de sus datos a terceros (P5.3). Si limitación de la divulgación no estaba
asegurada y la información personal se filtró al público, la reputación tanto de la
persona cuya la información fue publicitado y la empresa que se filtró los datos podrían
ser seriamente dañados. En otras situaciones, objetivos de privacidad pueden ser
obligados por ley, pero no es una prioridad para los clientes. Por ejemplo, un operador
de telecomunicaciones debe facilitar la rectificación y supresión de los datos de llamada
registros (P1.8); si el operador no lo hizo, el daño a las finanzas y la reputación de la
persona haría probablemente ser menos grave que en el ejemplo anterior.
Debido a la importancia de los objetivos de privacidad depende contexto, las empresas
que se ejecutan a través de PIA deben clasificar metas e identificar las prioridades para
sus arquitecturas de privacidad. Para determinar el nivel adecuado de protección de la
demanda, las empresas pueden preguntar "¿Qué pasaría si...?". Como se muestra en la
Tabla 2, se propone que las empresas utilizan escenarios de daños Para responder a esta
pregunta. Tanto el operador del sistema y su clientes incurren en daño si no se cumplen
los objetivos de privacidad. Los operadores del sistema pueden sufrir financieramente o
dañar su marca de la empresa si no se cumplen los objetivos de privacidad. Datos los
sujetos pueden incurrir en daños a su reputación, las libertades o las finanzas

Tabla 2 categorías de demanda de protección y perspectivas


Protección demanda requerido para objetivo privacidad
¿Qué podría ser afectado si el objetivo no era la privacidad reunió...? operador del
sistema perspectiva
Información sujeta perspectiva reputación o marca valor financiero situación social de
pie, reputación financiero situación personal libertad
Baja - 1 El impacto de cualquier pérdida o daño es limitado y calculable.
Medium - 2 El impacto de cualquier pérdida o daño es considerable.
Alto - 3 El impacto de cualquier pérdida o daño es devastador
La evaluación de los objetivos de privacidad proponemos difiere Del, evaluación más
cuantitativa de destino activo impulsado de algunas evaluaciones de seguridad (véase,
por ejemplo, (ISO, 2008)). Nuestro enfoque difiere debido a las consecuencias de la
privacidad infracciones son a menudo de carácter "más suave" de violaciones de la
seguridad; violaciones a la privacidad a menudo se refieren a herir los sentimientos en
lugar de algo así como el compromiso de un sistema informático, que tiene un cierto
valor monetario. Por ejemplo, ¿cómo a evaluar cuantitativamente las consecuencias de
una fuga tomografía del cuerpo? Debido a que es difícil cuantificar el personal
consecuencia de violaciones a la privacidad, distinguimos entre consecuencias
limitadas, considerables y devastadoras para cada uno de los cinco escenarios de daños.
Dependiendo de la más alta nivel de consecuencia identificamos para un escenario,
entonces llamar a un grado correspondiente de la demanda de protección, que puede ser
bajo, medio o alto. En un estado posterior de la evaluación (Paso 5), las empresas
utilizan esta evaluación elegir controles de privacidad que están alineados en fuerza y
vigor. Este enfoque es similar a la evaluación de la seguridad procedimientos
establecidos por la Oficina Federal Alemana para la Seguridad de la Información (BSI,
2008). Estos procedimientos son demostrado que funciona bien en la práctica porque
tres consecuencias niveles son cognitivamente más manejable y discutible que escalas
más complejas.

PASO 4 - IDENTIFICACIÓN DE AMENAZAS PARA CADA OBJETIVO


PRIVACIDAD

En el corazón de las metodologías de evaluación de riesgos reconocidos, uno encuentra


normalmente una lista de amenazas concretas para orientar activos y la probabilidad de
que estas amenazas se materialicen. Los activos bajo potencial de ataque - en nuestro
caso, la objetiva privacidad - se analizan para determinar por qué son vulnerables. Las
causas de la vulnerabilidad y las amenazas son combinado con la probabilidad de que se
produzcan las amenazas. El resultado es una medida del riesgo inherente a un sistema.
Por más detalles sobre las metodologías de evaluación de riesgos, consulte NIST (2002)
e ISO (2008). Nuestra metodología PIA sigue un enfoque similar. Por cada objetivo
privacidad, identificar sistemáticamente las amenazas que podría impedirnos llegar a
ellos. Por ejemplo, P3.1 objetivo privacidad establece que la información adecuada debe
darse a los interesados cuando los datos se recogen directamente de ellos. Este objetivo
podría verse amenazada en múltiples maneras: Las empresas no pueden dar a los
clientes una privacidad declaración y por lo tanto fracasan por completo para
informarles. Pero las empresas también pueden dejar de incluir la información correcta
en una declaración de privacidad, como por ejemplo que el responsable del tratamiento
es, ¿por qué el controlador de datos recoge los datos, ya sea los datos son compartidos,
que los datos se comparten con, que a en contacto en caso de reparación, y así
sucesivamente. En un PIA, las amenazas son principalmente el incumplimiento de las
leyes o sector de privacidad normas, que se exponen en los objetivos de privacidad. En
Además, las fallas pueden ocurrir cuando los interesados son ignorante de las prácticas
que se han identificado como relevantes en la lista de objetivos de privacidad. Las
amenazas pueden materializarse cuando tecnologías no tienen funcionalidad privacidad
adecuada o cuando los procesos y prácticas de gobierno no protegen privacidad.
Para un análisis de la amenaza de ser completa y justificable, las amenazas en el análisis
deben coincidir con la identificada objetiva privacidad. Amenazas que no corresponden
a una privacidad objetivo no se justifican. Si cualquier blanco de privacidad no tienen
amenazas correspondiente, ya sea los objetivos no son relevantes o el análisis de la
amenaza puede ser incompleta. Para garantizar un alto nivel de control metodológico en
un PIA, metas privacidad y amenazas a la privacidad pueden ser emparejados con una
numeración esquema (véase la Figura 4 para la ilustración). Por último, no todas las
amenazas potenciales es probable que ocurran. Los probabilidad de que se convierten en
relevantes depende de la tecnología, la arquitectura de TI, la gente involucrada, el
gobierno de la información de la empresa, el atractivo y la sensibilidad de los datos de
carácter personal involucrado, la educación privacidad de los empleados y muchos otros
potenciales factores. Debido a que muchas variables pueden influir en el incidencia de
una amenaza, las evaluaciones de riesgos de seguridad determinan probabilidades de
amenaza. Las personas que utilizan la evaluación de riesgos de seguridad determinar
qué riesgos para abordar basada primero en éstos probabilidades y el valor del ser activo
subyacente amenazado.
En el ámbito de la privacidad, sostenemos que una determinación gradual de
probabilidad de amenaza como se hace en las evaluaciones de seguridad no es
recomendable: si un derecho humano como es la privacidad amenazada, debe ser
tratada. No podemos considerar la probabilidad de que una amenaza, sino más bien si es
que existe. Si la amenaza es probable que exista un control debe ser determinado a
mitigarlo.

PASO 5 - IDENTIFICACIÓN Y RECOMENDACIÓN DE LOS CONTROLES


ADECUADO PARA PROTEGER CONTRA AMENAZAS

El paso crucial en un PIA es identificar los controles que pueden minimizar, mitigar o
eliminar las amenazas identificadas. Los controles pueden ser de carácter técnico o no
técnico. Técnico los controles se incorporan directamente en un sistema, mientras
controles no técnicos son la gestión y administrativa controles, así como las medidas de
rendición de cuentas. Ejemplar controles para cada objetivo privacidad se resumen en la
Tabla 3. Los controles pueden ser categorizados como preventivo o de detectives
(NIST, 2002). Los controles preventivos inhiben violación intentos, mientras que los
controles policiales advierten operadores sobre violaciónes o intentos de violaciónes.
Debido PIA están destinadas a fomentar la intimidad mediante el diseño, los
responsables del tratamiento deberían centrarse en la identificación y la recomendación
de los controles preventivos. Los controles que son más rigurosos y extensos son
también probable que sea más costoso y difícil de realizar en la práctica. Por esta razón,
le recomendamos tres niveles de rigor para controles: (1) satisfactorio, (2) fuerte y (3)
muy fuerte; para cada objetivo privacidad, el nivel de rigor que se requiere depende del
grado de protección que la demanda se determinó en el paso 3 de la PIA. Por ejemplo,
de alta
(3) las demandas de protección combinados con probables amenazas debe ser mitigado
con (3) controles muy fuertes, mientras que objetivos privacidad con baja (1) el impacto
puede ser contrarrestado con un satisfactorio (1) control. Como muestra la figura 4, un
control También puede abordar y mitigar amenazas múltiples.

PASO 6 - EVALUACIÓN Y DOCUMENTACIÓN DE LOS RIESGOS


RESIDUALES

Después de la lista de controles está escrito, los controles deben ser evaluado para la
viabilidad y eficacia. Organizaciones puede realizar un análisis de costo-beneficio e
invitar a las partes interesadas para discutir la aceptación de controles alternativos. Por
ejemplo, supongamos que un minorista quiere introducir RFID las etiquetas de los
productos y tiene las alternativas de control de matar etiquetas en las tiendas salidas o
les desactivar con una contraseña esquema de protección. En este caso, el minorista
puede discutir opciones de control con los clientes para determinar qué enfoque es más
aceptable para el mercado. Los responsables del tratamiento Cuando se evalúan posibles
controles puede producir un plan de implementación de control que claramente
identifica cómo cada amenaza se mitiga y donde las amenazas permanecerá sin
resolverse. Amenazas que permanecen sin resolverse constituyen el riesgo residual. Un
riesgo residual también existe si un
TABLA 3 OBJETIVOS Y CONTROLES DE PRIVACIDAD
EJEMPLARES

Privacidad dirige Controles


Técnica Administrativa / Gerencial

P1 - Calidad de los datos

P1.1 Asegurar tratamiento justo y legítimo a través de la transparencia


Proporcionar información precisa y actualizada, Hacer accesible la información,
Proporcionar una declaración de privacidad

Procesamiento Asegurar P1.2 sólo para fines legítimos Asegurar la legitimidad


del propósito

P1.3 Proporcionar especificación finalidad proporcionar una especificación


precisa y actualizada propósito

P1.4 Asegurar procesamiento limitada para la autenticación propósito


especificado,
Autorización,
Inicio de sesión
Garantizar la elaboración conexa propósito a través de políticas y auditorías
regulares

P1.5 que garanticen la prevención datos de granularidad mínima que garanticen


la prevención de datos a través de políticas y auditorías periódicas

P1.6 Garantizar seudonimización minimización de los datos,


Anonimizarían,
La ofuscación,
Eliminación automatizada rutinas
Garantizar la minimización de los datos a través de políticas y auditorías
regulares,
Proporcionar y hacer cumplir las normas de eliminación

P1.7 Garantizar la calidad de los datos, la precisión y la validación de datos de


integridad

P1.8 Asegurar la eliminación de almacenamiento limitada automatizada


rutinas
Proporcionar y hacer cumplir las normas de eliminación

P2 - legitimidad Procesamiento

P2.1 Garantizar la legitimidad del tratamiento de datos personales Asegurar


obtención del consentimiento,
Comprobación de validez del consentimiento

P2.2 Garantizar la legitimidad del tratamiento de datos personales sensibles

P3 - Información correcta de las informaciones amparadas

P3.1 Proporcionar información adecuada en los casos de recogida directa de


datos
del interesado
Proporcionar información precisa y actualizada en relación con (a) la identidad
de los datos
controlador, (b) la finalidad del tratamiento, (c) los destinatarios de los datos, (d)
de datos opcional

P3.2 Proporcionar información adecuada en los que no se han obtenido los datos
directamente del titular de los datos (por ejemplo, por parte de terceros)

P4 - derecho de acceso de las informaciones amparadas


P4.1 Facilitar el suministro de información sobre los datos procesados y
propósito
Proporcionar una interfaz que permite a los interesados a enviar una solicitud de
información,
Asegurar el procesamiento oportuno de la solicitud de los interesados para
obtener información,
Proporcionar información precisa y actualizada en relación con (a) la
confirmación de la
si o no los datos relativos al titular de los datos se están procesando, (b) la
finalidad de
el procesamiento, (c) las categorías de datos en cuestión, (d) los destinatarios o
categorías de
destinatarios a los que se comuniquen los datos, (e) el procesamiento de datos
sometidos y cualquier
información en cuanto a la fuente de los datos, (f) la lógica utilizada en los
tratamientos automatizados de
los datos y las decisiones automatizadas.

P4.2 Facilitar la rectificación, supresión o bloqueo de los datos de autenticación,


Autorización,
Inicio de sesión

P4.3 facilitar la portabilidad de la funcionalidad de exportación de datos

P4.4 Facilitar la notificación a terceros sobre rectificación, cancelación y el


bloqueo de los datos
Proporcionar información adecuada y oportuna acerca de rectificación, supresión
y bloqueo de datos a terceras partes relevantes.
Control implementado reduce el impacto de una amenaza, sino no elimina por
completo. Ya sea un riesgo residual es aceptable o una opción de control se pospone a
una etapa posterior de la implementación del sistema depende de los estándares de
riesgo y las normas de un equipo de diseño o compañía entera (Naoe, 2008). En todo
caso, los riesgos residuales debe estar bien documentado en un informe PIA; la alta
dirección, la gestión del riesgo empresarial y personal de TI se llevarán a cabo
responsable si se producen violaciones a la privacidad.

PASO 7 - DOCUMENTACIÓN DEL PROCESO DE PIA

Hasta la fecha, no existen normas para la buena presentación de informes PIA. El


EUPIAF proyecto recientemente comparó informar de la principal PIA prácticas que
existen (Wright et al, 2011). Extendiendo su conclusiones de lo que normalmente se
incluye en los informes de PIA, que argumentan que el contenido de los informes de
PIA debe principalmente expectativas cumplir el objetivo audiencias. Públicos objetivos
múltiples para PIA existen informes. Internamente, la empresa 'a empresas la gestión
del riesgo, personal de marketing, la alta dirección y la gestión de TI debe ser
consciente de los riesgos de privacidad. Estos grupos deben entender los riesgos de
privacidad, no sólo porque violaciones a la privacidad pueden dar lugar a pasivos
financieros, sino también debido a violaciones a la privacidad pueden dañar la marca 'a
empresas y la fuerza de la alta dirección para dejar de fumar. Al mismo tiempo,
El personal de TI probablemente se hace responsable de los incidentes que se producen.
Por lo tanto, las empresas deben tener un fuerte interés en documentar exhaustivamente
su privacidad objetivos, amenazas, controles y riesgos residuales; Ellos deberían
También comprobar regularmente el cumplimiento de las leyes pertinentes. El personal
de TI tendrá que tener la misma información, sino también debe ser capaz de detectar
rápidamente las debilidades de un sistema cuando una violación ocurre. Para ellos, la
documentación de la calidad de la sus flujos de datos del sistema y es esencial.
Externamente, las autoridades de protección de datos en muchos países tener el derecho
legal de revisar los informes de PIA. Autoridades puede ser necesario para comprender
el sistema bajo la lupa y juzgar si los límites del sistema, los objetivos de privacidad y
las amenazas han sido debidamente identificados y mitigados. Las autoridades también
necesitan entender los riesgos residuales
Por último, los clientes y los medios de comunicación podrían estar interesados en
Informes de PIA. Estos grupos quieren entender el sistema y sus efectos, las opciones
de control del cliente y el núcleo conclusiones sobre las amenazas y controles. Tanto
para la protección las autoridades y los medios de comunicación, algunas señales de
calidad PIA podría conducir a la aceptación de que el trabajo de privacidad se ha hecho.
Estas señales incluyen la notificación de participación de los interesados y la
presentación de informes de que un proceso de PIA es parte del desarrollo del sistema.
Por último, cuando las cosas van mal, todo el mundo quiere saber quién es responsable
y por qué un PIA no pudo evitar una violación. Los principales expertos de privacidad
han llamado regularmente por la rendición de cuentas por las violaciones de privacidad
(Alhadeff et al, 2012).
En consecuencia, la gente quiere saber cuándo el PIA era llevado a cabo, el tiempo que
la evaluación se llevó, que llevó a cabo y quién es el responsable último de cualquier
infracción que ocurrir.
Debido PIA informa tener tales variadas audiencias, P5 quienes a su vez tienen
expectativas variadas, un informe PIA debe idealmente contener los elementos descritos
en la Tabla 4. Como se muestra en la tabla, es aconsejable para producir dos versiones
de un informe de PIA. El uno para fines internos y auditoría proporciona mucho más
contenido, algunas de las cuales podrían ser confidenciales; la versión para el público
puede tener menos detalle pero debe ser fácil de entender. Además, legible por máquina
Estándares informe PIA deben desarrollarse de manera que ambas solicitudes auditorías
y de consumo pueden ser administrativamente facilitado. El estándar P3P desarrollado
para la privacidad políticas pueden ser un buen punto de partida para este ejercicio
(Cranor et al, 2006).
La mayoría de los pasos en nuestro PIA, así como su secuencia, son similares a los
procesos de evaluación de riesgos existentes (Por ejemplo, BSI, 2008; ISO 2002; ISO
2008; NIST, 2002; Seibild, 2006); cuando sea necesario, hemos mejorado los pasos con
requisitos de privacidad específica. Estas mejoras son especialmente observables en los
pasos 1 y 3. En el paso 1, en contraste correr el riesgo de los procesos de evaluación que
requieren sólo una descripción de los activos del sistema, proporcionamos información
sobre los aspectos de un sistema que necesita ser caracterizado y enfatizar la descripción
de categorías de datos y los flujos de datos. En el paso 3, consideramos dos perspectivas
- operador del sistema y datos tema - para evaluar el grado de la demanda de protección.
Los procesos de evaluación de riesgos existentes no reflejan las diferentes perspectivas,
centrándose de manera implícita en el sistema de operador de perspectiva. Se introduce
la noción de perspectivas, especialmente la consideración de la perspectiva del
interesado, para fomentar una evaluación integral de la concepto amplio de privacidad y
para resaltar los datos afectada asignaturas. Sólo los pasos 2 y 7 se definieron a partir de
cero; que no se pueden encontrar en los procesos de evaluación de riesgos existentes. Al
igual que en las mejoras de la intimidad específica mencionada en los otros pasos, se
introdujeron estos dos pasos para responder a las preocupaciones específicas del
concepto privacidad y enmarcar los problemas de privacidad de una manera que alienta
privacyby-diseño. En el paso 2, donde las organizaciones definen relevante objetivos de
privacidad, las organizaciones no sólo comprender y abrazar a los amplios aspectos del
concepto de privacidad, sino también especificar los requisitos de privacidad de una
manera que les permite abordar técnicamente, lo que lleva a la privacidad por diseño.
Paso 7 describe los requisitos PIA-específicas para crear y publicará un informe que
cumpla las expectativas de los diferentes las partes interesadas en relación con la
documentación de la PIA
Los siete pasos se deben seguir en la secuencia porque cada una de ellas se basa en el
anterior. Una excepción es Pasos 1 y 2, que puede ser ejecutado en paralelo; Sin
embargo, en algunos de los casos, podrían ser necesarios detalles de caracterización del
sistema identificar y definir los objetivos concretos de privacidad. la naturaleza de la
Etapa 7 también permite que ocurra en paralelo con la otra pasos. En contraste, Paso 3
se basa en gran medida de los resultados de los pasos anteriores; las organizaciones no
pueden ejecutar una evaluación informada de la demanda de protección si el sistema
objetivo de caracterización y la privacidad no están definidos en detalle. Los resultados
de la Etapa 3 son esenciales para los siguientes pasos, ya que informen a la
identificación de las amenazas y controles en el paso 4 y 5; Además, son el base para
recomendar los controles adecuados en Paso 5 y evaluación de riesgos residuales en el
Paso 6. Controles posible

Tabla 4 PIA informes y presentación de informes de los públicos objetivo '

Expectativas protección de Datos autoridades empresa personal


clientes de Medios
Información general del sistema
Vista general del sistema x x
Límites del sistema x x
Los propósitos del sistema x x x x
información de Evaluación
privacidad relevantes
objetivos identificados
x x xx
privacidad relevantes
amenazas dirigidas
xx
elegido privacidad
controles
x x xx
riesgos residuales
encontrado
x x (x) (x)
Señales de calidad de PIA
Las partes interesadas que participan x x
cumplimiento legal
comprobado
x x xx
PIA fecha de inicio /
Fecha de inicio del sistema
xx
responsabilidad
Persona (s) que participan en
el PIA
xx
Organización que
realizado el PIA
x x xx
Persona que aprobó
el PIA
xx
Privacidad responsable
empresa
x x xx
Fecha de PIA
Terminación
x x xx
Plazo de PIA
Validez

Solamente ser identificado en el paso 5 si una lista de amenazas ha sido compilada en el


paso 4, y los riesgos residuales sólo puede ser evaluado en el paso 6 si una lista de
controles recomendados está disponible. Finalmente, aunque la secuencia de los pasos
es fijo, el proceso en sí es iterativo. Le recomendamos ejecutar la propuesta de PIA más
de una vez durante el desarrollo de un sistema. Requisitos y adiciones funcionales o
cambios en el sistema, discusiones con los interesados o la evolución ulterior del
concepto de privacidad en sí podría conducir a nuevas dianas de privacidad, una re-
evaluación de la protección demanda o las nuevas amenazas y los controles.

EVALUACIÓN UTILIDAD DE LOS OBJETOS PROPUESTOS

Como parte de la investigación en ciencias de diseño, debemos evaluar los artefactos


propuestos. Se utilizó la evaluación estratégica marco de Pries-Heje et al (2008) para
elegir la evaluación métodos, en última instancia, que evalúan el proceso de diseño
(Paredes et al, 1992) por la búsqueda de opiniones de los usuarios de proceso(Pries-
Heje et al, 2008). Se evalúa el proceso de diseño durante las iteraciones del ciclo de
diseño por lo que el principal iteración es ex post y las iteraciones anteriores son ex
ante. A demostrar la utilidad de nuestros artefactos, se optó por un naturalista método de
evaluación (Venable, 2006). Para el naturalista evaluación, se utilizó la investigación de
acción propuesto por Venable (2006) en forma de talleres con la industria de TI
expertos. Mediante el uso de este método de evaluación, también abordamos los
problemas antes mencionados de riesgo de seguridad existentes evaluaciones que se
centran sobre todo en el proceso y no en contenidos de calidad (Siponen, 2006).
Evitamos un enfoque en requisitos de seguridad genéricos que companyspecific
desprecio requisitos (Siponen y Willison, 2009). Y validamos nuestro enfoque basado
en los negocios comunes práctica. Utilizamos métodos de investigación profundos para
evaluar el contenido y la calidad de nuestros artefactos propuestos. Los investigadores
han desarrollado sistemas de información y enfoques de investigación-acción diferente
adoptadas (Baskerville & Wood-Harper, 1996; Avison et al, 1999).
Seguimos Baskerville (1999) y el uso de uno de los más conocidos enfoques, a saber
Susman y Evered (1978) ciclo de investigación-acción. Este ciclo consiste en el
diagnóstico, planificación de la acción, la toma de acción, evaluar y especificar el
aprendizaje. El proceso de investigación era de colaboración y iterativo.
El enfoque requiere en primer lugar se establece la investigación medio ambiente:
reclutamos especialistas con diferentes áreas de experiencia en la industria (incluyendo
venta al por menor, el transporte público y automotriz) y les pidió llevar a cabo y el
desafío nuestra metodología PIA propuesto. Se trabajó con seis industria expertos que
sostienen diferentes roles organizativos pertinentes para PIA: un CIO, un gestor de
riesgos en general, una tecnología gerente de innovaciones con una sólida formación en
técnica gestión de la seguridad y de tres miembros de un gobierno institución enfocada
en seguridad de la información, cada una de los cuales tienen una gran experiencia en la
gestión del riesgo teórico. Establecimos un acuerdo investigador-cliente informales
(Susman y Evered, 1978; Davison et al, 2004) que especifique el enfoque colaborativo y
la siguiente objetivos: (1) la aplicación de forma experimental y por lo tanto un reto la
metodología PIA se propone en forma de talleres, (2) completando PIA para tres
escenarios de la vida real y (3) la integración de forma experimental los siete pasos de
PIA en un proceso de desarrollo del sistema.
DIAGNÓSTICO - INICIO DE LA ESTRATEGIA DE COLABORACIÓN

Organizaciones Expertos estaban muy interesadas en la aplicación de estrategias a tener


en cuenta de manera sistemática los requisitos de privacidad y cuestiones. Sin embargo,
los expertos informaron de una falta de conocimiento sobre los requisitos de privacidad
pertinentes y la falta el personal de experiencia. Como resultado, hemos identificado
una necesidad para una guía PIA orientado al proceso, uno que contenía requisitos de
privacidad detalladas y podría ser implementado por personal existentes. A través de
entrevistas, identificamos los sistemas reales y escenarios de negocio que la
metodología PIA haría y aplicar a los requisitos relacionados que necesitaría Satisfacer.
Basado en estas entrevistas, delineamos tres escenarios: (a) un escenario que implica un
menor habilitadas RFID- tarjeta de fidelidad y los productos etiquetados, (b) un
transporte público escenario utilizando entradas con RFID y de pago por uso modelos, y
(c) un escenario que implica un automóvil Montaje RFID controlado y un empleado
RFID tarjeta de acceso. Este paso se llevó a cabo el diagnóstico de solamente
inicialmente, mientras que las siguientes etapas del ciclo de investigación-acción se
completaron durante iteraciones posteriores.

PLANIFICACIÓN DE ACCIONES

Debido a la Etapa 1 se completó en la fase de diagnóstico, llevamos a cabo los pasos 2-


6 de nuestra metodología propuesta en la forma de talleres y varias entrevistas en
profundidad con las partes interesadas pertinentes. Para asegurar que el taller los
participantes tendrán la información que necesitaban a participar en el PIA, hemos
preparado una descripción de nuestra metodología propuesta y una descripción de los
sistemas de y los escenarios desde el paso 1. La metodología, las descripciones de
escenarios, y PIA relacionados documentación se actualiza al final de cada acción
investigación-iteración como resultado de la evaluación y especificando pasos de
aprendizaje.

PASAR A LA ACCIÓN

Durante cada taller, explicamos nuestra metodología PIA y construcciones a través de


una presentación de todos los siete pasos y llevó a cabo una sesión de preguntas y
respuestas para asegurar que todos los participantes entienden los pasos y el objetivo
general. En segundo lugar, se realizó un PIA y completado los pasos 2-6 con tanto en el
contexto de la organización de los expertos internos operaciones y uno de los escenarios
en mente. Cada una de los participantes tenían una plantilla de papel a mano que
representa cada uno de los pasos y puedan ser cubiertas con los resultados de la
discusión. En tercer lugar, pedimos a los participantes que sugieran posibles mejoras en
nuestros artefactos propuestos. Más de los talleres tuvo 6 a 8 h. La información fue
capturada en forma de protocolos de Resultados y completado plantillas de papel.
Elegimos esta configuración para los talleres para llegar a nuestra primera dos objetivos
del proceso de colaboración, a saber, de aplicación y desafiando la metodología
propuesta y completando PIA para tres escenarios de la vida real. En una acción
posterior investigación iteración, también intentamos integrar los siete pasos de PIA en
las fases del proyecto de un proceso de desarrollo del sistema. Hemos elegido utilizar la
menor caso, la integración de los siete pasos en el sistema actual proceso de desarrollo
de una de las organizaciones minoristas que participaron (Figura 5). Hemos llevado a
cabo la integración basado en el proceso actual de proyectos de desarrollo de sistemas
debido a grandes cambios en el flujo de proyectos de TI actual habría sido no deseado.
La Figura 5 representa el proyecto etapas, partes interesadas y cuándo y por quién los
pasos de nuestra metodología PIA propuesto podría llevarse a cabo.
La figura muestra que los pasos 1 y 2 pueden llevarse a cabo desde el inicio de un
proyecto y debe ser completado en la fase de caracterización proyecto, que determina
las características que se implementarán. Todos los grupos de interés internos están
involucrados en los pasos 1 y 2; incluso la dirección comité podría influir en los
objetivos de privacidad durante el fase de aprobación. Paso 3 se ejecuta en el requisito
fase de especificación y por lo tanto es impulsado principalmente por la unidad de
negocio responsable, que en consecuencia decide la cantidad de protección que se
requiere. Los pasos 4 y 5 mosto ser completado en la fase de especificación de destino.
Por lo tanto, personal orientado a los negocios de la unidad de negocio y personal
técnico de la unidad de TI, tanto a identificar amenazas y recomendar los controles.
Paso 5 debe completarse en este tiempo porque la planificación del presupuesto debe
basarse en la aplicación prevista de los controles recomendados. Paso 6 se produce
durante el desarrollo del sistema y la definición de la prueba, donde los riesgos
residuales se pueden documentar y rutinas de prueba para validar los controles se
pueden definir. Como un informe PIA (Paso 7) debe estar disponible en el momento de
la liberación del sistema, esta es la fase donde el personal de las unidades de negocio y
el personal de TI completa Documentación relacionada con el PIA y escribir un informe
PIA. En el mejor de los casos de un desarrollo del sistema proceso del proyecto se
muestra en la Figura 5, la integración de la siete pasos PIA parece ser transparente y
más bien secuencial. Pero ciclos correccionales son típicos en este tipo de proyectos, y
por lo tanto los procesos de solicitud de cambio deben ser considerados también. En el
caso de venta, solicitudes de cambio puede ocurrir en cualquier momento después la
fase de aprobación y antes de la fase de liberación del sistema. En ese caso, Pasos 3-7 se
debe ejecutar de nuevo y relacionados documentación debe ser actualizada.

EVALUACIÓN Y ESPECIFICANDO EL APRENDIZAJE

Cada una de las acciones de investigación-iteraciones se cerró con un investigador de un


paso de sólo evaluar así la colaboración y como un paso de aprendizaje especificando.
Todos los participantes confirmaron que la documentación completa de un sistema,
como se requiere en el Paso 1, era necesario para completar un PIA fiable. Pero los
participantes fueron preocupados por la cantidad de tiempo y mano de obra necesaria
para crear una caracterización detallada del sistema. Los participantes señaló que dicha
documentación no es completa fácilmente disponibles en una empresa típica, donde la
principal interés radica en la producción de una aplicación que se ejecuta en lugar que
uno bien documentado. Fue especialmente difícil para los participantes se pongan de
acuerdo sobre los límites del sistema de documentación y análisis. La mejor solución a
este dilema que los participantes sugirieron era centrarse en el flujo de Datos personales.
En este enfoque, la documentación haría describir los componentes del sistema y las
interfaces que son parte del flujo de datos de carácter personal, pero dejar de
documentar componentes en el punto donde los datos de personal trata de un descanso.
En el paso 2, todos los participantes altamente valorado la privacidad objetivos (ver
Tabla 1). Los objetivos de privacidad sistemáticamente estructurar el paisaje confuso y
extenso de privacidad requisitos en una manera que sea practicantes se sienten seguros
trabajando con. Lo más importante, ya que la mayoría de ellos inicialmente cubrir la
ley, el cumplimiento legal se garantiza mediante nuestra metodología PIA. Esto es
importante para la industria desde PIA son costosos y por lo menos deben garantizar el
cumplimiento legal. Cuando los participantes discuten cada uno de los objetivos de la
privacidad en detalle (en el contexto de sus operaciones personales, así como los
escenarios en discusión), su confianza aumentó y ellos vieron los objetivos como menos
complejos. Sin embargo, la interpretación "correcta" de algunos de los objetivos se
mantuvo un problema. En particular, P1.1 objetivo "Asegurar justo y tratamiento legal a
través de la transparencia 'dio lugar a discusiones sobre cómo interpretar la
«transparencia» y cómo transparencia puede garantizarse. Este problema de la
"correcta" interpretación no fue considerado como insuperable; discusiones siempre
condujeron a alguna interpretación satisfactoria. Todos los participantes admitieron que
no estaban al tanto de la mayoría de los requisitos legales que entran en la discusión.
Los participantes reconocieron que iban a necesitar para invertir en formación y
personal adicional para fomentar el entendimiento de los problemas de privacidad en
sus organizaciones.
En el paso 3, cuando la evaluación requiere del tratamiento de datos para evaluar cuánta
protección cada objetivo privacidad requiere, los participantes coincidieron en que un
enfoque cualitativo es la más factible. Como se señaló anteriormente, la evaluación del
impacto de una violación de la privacidad es diferente de evaluar el impacto de brechas
de seguridad; por ejemplo, una garantía incumplan tales como pérdida de disponibilidad
podría cuantificarse en términos de negocio pérdidas. Los dos puntos de vista que
proponemos (operador y datos tema; véase la Tabla 2) se considera que es muy útil para
la evaluación de los factores "blandos" que por lo general se ven afectados por
violaciones a la privacidad. Sin embargo, los participantes con técnica fondo, que se
utiliza para la evaluación de los fallos del sistema cuantitativamente, tenían más
dificultades para trabajar a través de este paso de las partes interesadas con un fondo de
gestión de riesgos. Estos últimos grupos de interés consideran principalmente la
perspectiva del operador, centrándose en amenazas como el daño a imagen de una
empresa; actores técnicos, por su parte, se centró en cuestiones técnicas y omitido
administrativa cuestiones. Para ambos grupos de partes interesadas, esfuerzo
significativo fue necesaria para tomar la perspectiva de los datos sujetos y
correctamente evaluar el grado de demanda de protección necesaria; este hallazgo
enfatiza lo importante que es que los interesados adoptar explícitamente la perspectiva
del usuario final. Después de discutir algunos de los objetivos de la privacidad, los
interesados se acostumbraron a la forma alternativa de pensar y razonar acerca de
problemas de privacidad, y asignan los tres niveles de protección más fácilmente. Para
la evaluación de la probabilidad de amenazas en el Paso 4, los talleres nos llevó a
adoptar un enfoque más cualitativo. Aunque los participantes consideraron la asignación
de una cuantitativa probabilidad a cada amenaza, la naturaleza de la mayoría de las
amenazas no hacer de este enfoque viable. Por lo tanto, nos acomodamos en una
diferenciación sencilla en la que se marcó cada amenaza 'Probable' o 'poco probable'
La mayoría de los participantes consideraron que la identificación de los mandos en el
paso 5 como sencillo. A pesar de que no estaban familiarizados con el concepto de la
intimidad mediante el diseño, acordaron que controles de privacidad deben ser
identificados lo más pronto posible en el proceso de desarrollo del sistema. Los
participantes carecían conocimiento sobre las opciones de control de privacidad de
mejora y las medidas que pueden ayudar a realizar una privacidad por diseño enfoque.
Por ejemplo, los participantes no sabían que podrían cumplir con el requisito
minimización de los datos por la aplicación de medidas apócrifos o anonimizarían (Ver
Tabla 3). Por otra parte, los entrevistados de las empresas’ Los departamentos
reconocido que los expertos tenían privacidad nunca ha sido parte de sus equipos de
proyecto; estos expertos podría han traído conocimiento y la perspectiva significativa a
la ciclo de vida de desarrollo del sistema. Los participantes estaban seguros de que
podían documentar riesgos residuales y establecer un plan de ejecución para los
controles en el Paso 6; estas acciones se asemejan a los riesgos existentes los procesos
de gestión, y no implican ningún procedimiento de privacidad específica. Por el
contrario, algunos de los participantes estaban fuertemente preocupados por la
publicación de un PIA informar cómo se requiere en el Paso 7. A pesar de que estaban
preocupados acerca de revelar información detallada y confidencial al público, se
acordó que los resultados de un PIA deberían ser publicada. Además, acordaron que las
partes externas al igual que las autoridades de protección de datos y los clientes deben
ser informados sobre el razonamiento que llevó a los resultados. Basado en los talleres,
llegamos a la conclusión de que dos versiones de un PIA informe debe ser escrito: un
informe detallado para uso interno y las auditorías de las autoridades de protección de
datos y un informe que resume claramente los resultados para los clientes y el medios
de comunicación (ver Tabla 4).

RESULTADOS Y CONCLUSIONES CLAVE

Después de completar la última iteración de la investigación-acción ciclo, hemos creado


PIA informa para los tres escenarios como requerido en el Paso 7. Como una
descripción completa de los escenarios y su respectiva PIA no está en el alcance de este
documento, nos referimos al lector a la directriz de la PIA BSI (BSI, 2011b).
En la siguiente sección, se describen brevemente algunas claves conclusiones del PIA
ejemplar para el escenario minorista. Estas principales conclusiones tienen
consecuencias para el diseño de RFID aplicaciones en el sector minorista y de negocios
relacionados procesos. Por lo tanto, conducen a adaptaciones de la vida privada-
ByDesign en las áreas de diseño del sistema, la función y proceso. En resumen, el
escenario minorista se compone de un RFIDenabled tarjetas de fidelidad, los productos
etiquetados, servicios de valor añadido y aplicaciones de taller RFID como inteligente
carretillas, estanterías inteligentes y sistemas de autoservicio. Después de que nosotros
objetivos privacidad considerado, que generaron la siguiente recomendaciones para el
control de la privacidad: informar ampliamente los clientes acerca de la tecnología
RFID, los datos del cliente que se recogen y cómo se procesan estos datos para que los
clientes saben que pueden 'escaneados' por RFID lectores (P1.1); permiten a los clientes
elegir si quieren participar en los servicios basados en RFID; logístico separada datos de
los datos del cliente (P1.2 y P1.3); implementar de grano fino derechos de acceso y
actualizar regularmente asignado derechos de acceso (P1.2 y P7.1); aplicar reglas de
supresión que los datos eliminar o anonimizarían cliente que ya no es necesaria para los
fines especificados (P1.5 y P1.3); oferta tarjetas de fidelidad personalizados y
pseudonymised a clientes (P1.3); matar o desactivar todas las etiquetas de productos
durante la salida, pero no matan a una etiqueta del producto si un cliente pide
explícitamente la capacidad de utilizar el producto en conjunto con valor añadido
servicios (P1.2 y P7.1). Después de evaluar nuestra metodología y construcciones
propuestas en términos de utilidad absoluta (mediante la investigación-acción), también
se evaluó en términos de utilidad relativa comparándolo con otros métodos de
evaluación de riesgo y describir el correspondientes análisis en el Apéndice B.

LIMITACIONES DE NUESTRA METODOLOGÍA PIA

La evaluación utilidad de nuestros artefactos sugiere algunas limitaciones de nuestra


metodología. En primer lugar, se utiliza un cualitativa enfoque de evaluación que consta
de tres niveles (bajo, medio y alto) para evaluar el nivel de demanda de protección.
Como En consecuencia, se considera sólo la magnitud del riesgo, no la probabilidad.
Por ello, recomendamos que externa y grupos de interés internos involucrados en cada
paso del proceso; los interesados pueden contextualizar y definir la privacidad objetivos,
evaluar la demanda de protección e identificar y evaluar las amenazas. Esta
participación de los interesados podría ser con el apoyo de la introducción de juicios de
expertos de la técnica 'Delphi' (Linstone y Turoff, 1975), que se utiliza a menudo en
evaluaciones de riesgos cualitativas. Sin embargo, las pequeñas y medianas las
empresas que carecen de los recursos para llevar a cabo análisis exhaustivos de riesgo
Delphi podrían utilizar nuestro actual enfoque.
En segundo lugar, no ofrecemos ningún medio o instrumentos a medir y analizar qué
tan bien se ha ejecutado un paso y si el artefacto resultante es completo. Al igual que los
riesgos de seguridad normas de evaluación, nos dejan el juicio relativo a la integridad y
calidad de la evaluación ejecutado para los evaluadores; le recomendamos auditorías
periódicas que pueden desenterrar temas restantes e iniciar mejoras tanto en el proceso
de evaluación aplicado y la aplicación. Sin embargo, las herramientas de software
pueden ayudar a garantizar que las medidas de evaluación y sus artefactos resultantes
son completos. Para proporcionar herramientas útiles para los profesionales, que ya
implementado una instancia de nuestros artefactos en la forma de una aplicación web
llamada "intelligentPIA '(IPIA, 2011). También tenemos previsto hacer estudios de
casos para evaluar más a fondo la utilidad de nuestros artefactos propuestos. En tercer
lugar, en esta investigación nos hemos centrado en el desarrollo de una metodología
PIA. No consideramos como nuestra stepby a paso metodología puede integrarse
formalmente en desarrollo de la gestión de riesgos y el sistema existente de una
compañía proceso. Aunque nos basamos nuestra metodología en las evaluaciones de
riesgos de seguridad existentes para facilitar fisuras la integración, hemos examinado si
y cómo dicha integración se puede realizar sobre la base de sólo un caso al por menor.
Cuando las organizaciones a integrar los procesos, también pueden considerar que es
responsable de la ejecución de un PIA como un todo y para cada uno de sus pasos.
Roles que son necesarios para llevar a cabo una PIA debe ser incorporado en la
seguridad existente y sistemas de gestión de la protección de datos. Los ingenieros de
sistemas con un conocimiento profundo de privacidad están obligados a realizar PIA
orientados al diseño de éxito. Así, los investigadores debe examinar si las funciones
existentes de seguridad y sistemas de gestión de protección de datos, que son
actualmente definido como la tecnología centrada (seguridad) o legalcentric (Protección
de datos), son suficientes para cumplir la presente requisito. Este examen sería un
importante tema para el trabajo futuro.

CONCLUSIÓN

Siguiendo el paradigma de investigación en ciencias de diseño, el principal contribución


de esta investigación es el desarrollo de un nuevo conjunto de artefactos. Estos
artefactos ayudan a los profesionales y los investigadores a comprender la regulación de
la privacidad relevante paisaje y analizar y evaluar los problemas de privacidad
mediante el uso de un proceso sistemático paso a paso. La metodología PIA ayuda a los
médicos se dan cuenta el concepto de intimidad mediante el diseño en su ciclo de vida
de desarrollo del sistema. Específicamente, la artefactos proporcionan apoyo sistemático
para la representación de privacidad requisitos en forma de objetivos de privacidad, la
evaluación cuánta protección de estos objetivos requieren y la identificación sistemática
de amenazas y controles adecuados. Los objetivos propuestos han sido privacidad
sistemáticamente derivado de los requisitos de protección de datos legales y privacidad
principios. Nuestra metodología PIA se basa en riesgo antes experiencias de evaluación
y la investigación, especialmente en el riesgo para la seguridad área de evaluación. La
metodología puede ser verificado porque cada paso del proceso de PIA produce una
artefacto. Aunque la metodología se describe en un nivel de detalle que permite a los
profesionales para reproducir y transferirlo a su entorno operativo, la metodología se ha
probado sólo en un contexto teórico. Debido a que esta metodología se aplicará en
variada contextos, esperamos que los artefactos que también varían. Hacemos no
anticipar los cambios en el diseño metodológico en sí, pero sí esperamos la metodología
a aplicar en diferentes caminos. En particular, la lista propuesta de privacidad objetivos
pueden y deben adaptarse a nacional o regional la legislación y la tecnología o la
regulación específica de la industria. El contexto término no sólo se refiere a las
diferentes industrias o la legislación, sino también implica que la metodología puede
aplicar en diferentes contextos organizativos: nuevas empresas pequeñas, empresas o
grandes empresas de tamaño mediano. Para PIA de aplicar en estos muy diferentes
ajustes, el PIA Reino Unido ya introduce la noción de PIA-pequeña y gran escala (ICO,
2009). La noción de escala se refiere a la asignación de recursos para llevar a cabo un
PIA y el compromiso de la dirección para liberar estos recursos. En particular, la parte
interesada procesos que se pedían en los Pasos 2-4 podrían ser muy caro y por lo tanto
se aplican sólo a las grandes empresas. Para una pequeña empresa, puede ser que sea
posible llevar a cabo una pequeña PIA escala con un solo empleado. Sin embargo, el
secuencia de los siete pasos no cambia; Solo el inversión de tiempo y grado de detalle
difiere entre PIA-pequeña y gran escala. La escala de un PIA y por tanto la cantidad de
recursos invertidos no depende sólo de restricciones presupuestarias, sino también en la
sensibilidad de la datos procesados, la importancia o la visibilidad externa de un sistema
o proyecto, la cultura corporativa y la sostenibilidad de una marca; por ejemplo, las
marcas que se centran en ética preocupaciones podrían invertir más recursos que otros.
Hemos probado nuestra metodología y artefactos propuesta con la ayuda de expertos de
la industria y tres integral escenarios. Los participantes de nuestros talleres desafiaron la
utilidad de nuestra metodología y ayudó a mejorar la misma. A asegurarse de que
nuestra metodología podría ser reproducido por profesionales, que trabajaron con los
participantes para dar cuerpo a nuestra Descripción de la metodología y sus artefactos
de apoyo. Mediante la realización de tres PIA ejemplares para los escenarios y creando
así una instancia expositiva, nos fueron capaces de probar la integridad de la
metodología y viabilidad. El enfoque de escenarios también demostró que los datos
controladores pueden utilizar nuestra metodología para descubrir privacidad cuestiones
y controles apropiados primeros en la fase de diseño del desarrollo del sistema, lo que
se consigue el objetivo de intimidad mediante el diseño.

AGRADECIMIENTOS

Nos gustaría dar las gracias a los revisores de un ECIS anterior conferencia de la
versión del artículo, así como Dariusz Kloza y Gabriela Bodea útil para los comentarios
sobre este proyecto de artículo, el Instituto Federal Alemán de Seguridad e Información
de la Autoridades de Protección de Datos de Alemania por su voluntad de verificar,
analizar y publicar la metodología presentada en este artículo, Christian von Grone
(CIO del Gerry Weber) y Pierre Blanc (innovaciones de TI de gestión en Carrefour)
para ayudar a mejorar nuestras construcciones y las aplicamos a la venta al por menor
industria, Markus Sprafke para desafiar nuestra metodología para la industria
automotriz RFID, Wolf Rüdiger Hansen por la integración de nuestra metodología en
PIA talleres para la RFID industria y finalmente Julian Cantella para la edición del
Inglés versión de este documento

ACERCA DE LOS AUTORES

Marie Caroline Oetzel es un ex Ph.D. estudiante de la Instituto de Sistemas de


Información Gerencial en Viena Universidad de Ciencias Económicas y Empresariales
(2009-2013). Sarah Spiekermann es profesor de Sistemas de Información desde 2009 y
preside el Instituto de Gestión de la Información Sistemas de la Universidad de Viena
de Economía y Empresa (WU Wien). Antes tenured en Viena, fue profesor asistente en
el Instituto de Sistemas de Información en la Universidad Humboldt de Berlín
(Alemania) y ha mantenido un Posiciones profesor adjunto con el Colegio Público de
Heinz Política. Sarah es mejor conocido por su trabajo en electrónica privacidad y
marketing electrónico. El objetivo clave de su trabajo es investigar la importancia de las
construcciones de comportamiento y los valores sociales de TI diseñar y refinar el
concepto de computación ética en una e-sociedad.

REFERENCIAS

ALHADEFF J, VAN ALSENOY B y DUMORTIER J (2012) La rendición de cuentas


principio en la regulación de la protección de datos: origen, desarrollo y futuro
direcciones. En Gestión de Rendición de Cuentas a través de Privacidad, pp 49-82,
Palgrave Macmillan, Nueva York.
AVISON D, F LAU, MYERS MD y NIELSEN PA investigación (1999) Acción.
Comunicaciones de la ACM 42 (1), 28-45.
BASKERVILLE sistemas de información Investigación de acción con R (1999)
investigación. Comunicaciones de la AIS 2 (3), 1-32.
BASKERVILLE RL y MADERA EN HARPER (1996) Una perspectiva crítica sobre la
acción
investigación como un método para la investigación sistema de información. Diario de
Tecnología de la Información 11 (3), 235-246.
BBBOnLine. (2011) BBBOnLine - BBB Accredited Business Seal.
[Documento WWW] http://www.bbb.org/online/ (visitada 05 de diciembre
2011).
BENNETT C y BAYLEY R (2007) Estudio de los impactos de Privacidad:
Internacional
Estudio de su aplicación y efectos de la Universidad de Loughborough, Reino Unido.
Metodología sistemática para el impacto privacidad evaluaciones de Marie Caroline
Oetzel y Sarah Spiekermann 143
Revista Europea de Sistemas de Información
BSI (Bundesamt für Sicherheit in der Informationstechnik). (2008) Riesgo
análisis sobre la base de IT-Grundschutz, BSI Standard 100-3. [WWW
documento] https://www.bsi.bund.de/ContentBSI/Publikationen/BSI_
Estándar / it_grundschutzstandards.html # doc471418bodyText3
(Consultado el 20 de marzo de 2012).
BSI (Bundesamt für Sicherheit in der Informationstechnik). (2011a) ITGrundschutz-
Kataloge.
[Documento WWW] https://www.bsi.bund.de/
DE / Themen / ITGrundschutz / StartseiteITGrundschutz /
startseiteitgrundschutz_node.html
(Consultado el 29 de febrero de 2012).
BSI (Bundesamt für Sicherheit in der Informationstechnik). (2011b)
Guía de evaluación de impacto de privacidad para aplicaciones RFID. [WWW
documento] https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/
ElekAusweise / PIA / Privacy_Impact_Assessment_Guideline_Langfassung.
pdf; jsessionid = 4BE04C3871C6AEB0CD78E76F22F0153A.2_cid244?
__blob = publicationFile (consultado el 07 de marzo 2012).
Cavoukian A (2009a) de privacidad por diseño ... Tome el desafío. Información
y Comisionado de Privacidad de Ontario (Canadá). [Documento WWW]
http://www.ipc.on.ca/images/Resources/PrivacybyDesignBook.pdf
(Acceso el 10 de octubre de 2012).
Cavoukian A (2009b) de privacidad por diseño: los 7 principios fundamentales.
Información y Comisionado de Privacidad de Ontario (Canadá). [WWW
documento] http://privacybydesign.ca/about/principles/ (visitada
10 de octubre 2012).
CLARKE R (2009) Privacidad evaluación de impacto: sus orígenes y desarrollo.
Derecho Informático y de Seguridad 25 (2), 123-135.
CLARKE R (2011) Una evaluación de la guía de evaluación de impacto privacidad
documentos. Derecho Internacional de privacidad de datos 1 (2), 111-120.
Cranor LF et al (2006) La plataforma para preferencias de privacidad 1,1 (P3P1.1)
Especificación - Grupo de Trabajo del W3C nota 13 de noviembre de 2006. [WWW
documento] http://www.w3.org/TR/P3P11/ (el 1 de marzo de 2012).
DAVISON RM, Martinsons MG y KOCK N (2004) Principios de la canónica
investigación para la Acción. Sistemas de Información de Diario 14 (1), 65-89.
De Hert P, Kloza D y D WRIGHT (2012) Una evaluación de impacto sobre la
privacidad
marco de los derechos de protección de datos y privacidad. Entregable D3 de la
Proyecto PIAF UE - Recomendaciones para una evaluación de impacto sobre la
privacidad
marco de la Unión Europea. Bruselas.
Director de la Agencia Española de Protección de Datos (AEPD). (2009) Normas
sobre la Protección de Datos Personales y Privacidad - La Resolución de Madrid.
05 de noviembre 2009, Madrid ..
RESPALDAN. (2011) aprobar proyectos. [Documento WWW] http://ictendorse.eu/
(1 de marzo de 2012).
CE (Parlamento Europeo y Consejo de la Unión Europea). (1995)
Directiva 95/46 / CE relativa a la protección de las personas con respecto a la
tratamiento de datos personales ya la libre circulación de estos datos.
Diario Oficial de las Comunidades Europeas L 281/31: 31-50.
CE (Comisión de las Comunidades Europeas). (2009) de la Comisión
Recomendación sobre la aplicación de Privacidad y Protección de Datos
Principios en aplicaciones soportadas por Radio-Frequency Identification, EC
(Comisión de las Comunidades Europeas), Bruselas.
CE (Comisión Europea). (2012) Propuesta de Reglamento del
Parlamento Europeo y del Consejo relativa a la protección de las personas
en lo que respecta al tratamiento de datos personales ya la libre circulación
de estos datos (Reglamento general de protección de datos), COM (2012)
11 final. 25 de enero de Bruselas.
EuroPriSe. (2011) EuroPriSe - sello de privacidad Europea. [Documento WWW]
https://www.european-privacy-seal.eu/ (consultado el 5 de diciembre de 2011).
FTC (Comisión Federal de Comercio). (1998) Feria Información Práctica
Principios.
FUJITSU (2010) Los datos personales en la nube: una encuesta global de los
consumidores
actitudes. [Documento WWW] http://www.fujitsu.com/global/news/
publicaciones / dataprivacy.html (consultado el 20 de marzo de 2012).
GREGOR S (2006) La naturaleza de la teoría de los sistemas de información. MIS
Trimestral 30 (3), 611-642.
Hevner AR (2007) Una vista de tres ciclos de investigación en ciencias de diseño.
Escandinavo
Diario de Sistemas de Información 19 (2), 87-92.
Hevner AR, MARZO ST, PARQUE J y la RAM S (2004) la ciencia en Diseño
la investigación de sistemas de información. MIS Quarterly 28 (1), 75-105.
IIVARI J (2007) Un análisis paradigmático de los sistemas de información como un
diseño
ciencia. Scandinavian Journal of Information Systems 19 (2), 39-64.
Información y Comisionado de Privacidad de Ontario (IPCO). (2011) de Privacidad
por diseño. [Documento WWW] http://privacybydesign.ca (visitada
07 de febrero 2011).
intelligentPIA (IPIA). (2011) intelligentPIA - una evaluación de impacto sobre la
privacidad
herramienta. [Documento WWW] http://www.wu.ac.at/ec/research/ipia
(1 de marzo de 2012).
INFSO (Comisión Europea, Sociedad de la Información y Medios de Comunicación
Dirección General).
(2011) de privacidad y los datos de evaluación de impacto protección
marco para las aplicaciones RFID, 12 de enero de 2011, Bruselas.
ISO (Organización Internacional de Normalización). (2002) ISO FDIS
22307 Servicios Financieros - evaluación de impacto sobre la privacidad.
ISO (Organización Internacional de Normalización). (2008) ISO / IEC
27005 Tecnología de la información - Técnicas de seguridad - Información
la gestión de riesgos de seguridad.
ISO (Organización Internacional de Normalización). (2009) ISO / IEC 31000
la gestión del riesgo - principios y directrices sobre la aplicación.
ISO (Organización Internacional de Normalización). (2011) ISO IEC CD /
29.101,4 Tecnología de la información - Técnicas de seguridad - Arquitectura
privacidad
marco.
JESELON P y Fineberg A (2011) Un marco fundacional para una PdD-PIA,
Información y Privacidad Comisión Canadá, Toronto, ON.
Linstone, HA y Turoff, H, Eds (1975) El Método Delphi: Técnicas
y Aplicación, Addison Wesley, Londres.
MOOR JH (1998) Razón, la relatividad, la ética y la responsabilidad en la computadora.
Computadoras y Sociedad 28 (1), 14-21.
NAOE K cultura (2008) Diseño y riesgo aceptable. En Filosofía
y Diseño - Desde Ingeniería de Arquitectura (Vermaas PE, KROES P,
LUZ A y MOORE SA, Eds) pp 119-130, Springer, Amsterdam.
NIST (Instituto Nacional de Estándares y Tecnología). (2002) Riesgo
guía de gestión para los sistemas de tecnología de la información, el NIST Especial
Publicación 800-30.
OCDE (Organización para la Cooperación y el Desarrollo Económico).
(1980) Directrices sobre la protección de la privacidad y los flujos transfronterizos
de los datos personales.
PRIES-Heje J, R y BASKERVILLE VENABLE JR (2008) Estrategias para el diseño
evaluación de la investigación científica. ECIS 2008 Actas, papel 87.
Raab C y D WRIGHT (2012) Vigilancia: la ampliación de los límites de la privacidad
evaluaciones de impacto. En privacidad de Evaluación de Impacto (WRIGHT D y
De Hert P, Eds) pp 363-383, Springer, Dordrecht.
ROST M (2011) Datenschutz en 3D. Datenschutz und Datensicherheit - DUD
5 (35), 351-354.
ROST M y BOCK K (2011) de privacidad por diseño und die Neuen Schutzziele.
Datenschutz und Datensicherheit - Dud 35 (1), 30-35.
ROST M y Pfitzmann A (2009) Datenschutz-Schutzziele - revisited.
Datenschutz und Datensicherheit - Dud 33 (6), 353-358.
SCANNAPIECO M, P y Missier Batini C (2005) Calidad de los datos de un vistazo.
Datenbank-Spektrum 14/2005.
SEIBILD H (2006) IT-Risikomanagement, Oldenbourg Verlag, München, Wien.
Shroff M (2007) Manual para la Evaluación de Impacto de privacidad, Informe de la
Oficina de
el Comisionado de Privacidad, Auckland, Nueva Zelanda.
Siponen M (2006) los estándares de seguridad de la información - se centran en la
existencia de proceso, no su contenido. Comunicaciones de la ACM
49 (8), 97-100.
Gestión de la seguridad (2009) Información Siponen M y R Willison
normas: problemas y soluciones. Información y Gestión 46 (5),
267-270.
Solove DJ (2002) Conceptualización de privacidad. California Law Review 90 (4),
1087-1156.
Solove DJ (2006) Una taxonomía de privacidad. Universidad de Pennsylvania Law
Revisión 154 (3), 477-560.
Spiekermann S (2008) Control de Usuario en Computación Ubicua: Diseño Alternativas
y aceptación del usuario, Shaker Verlag, de Aquisgrán.
Spiekermann S (2012) Los retos de la privacidad por diseño. Comunicaciones
de la ACM 55 (7), 38-40.
STEWART B evaluaciones de impacto (1996) Privacidad. Derecho y Política de
Privacidad
Reportero 3 (4), 61-64.
SUSMAN GI y Evered RD (1978) Una evaluación de los méritos científicos de
investigación para la Acción. Ciencia Administrativa Trimestral 23 (4), 582-603.
TRUSTe. Sello de privacidad (2011) TRUSTe. [Documento WWW] http: // www
.truste.com / (consultado el 5 de diciembre de 2011).
Información del Reino Unido Oficina de Comisionados (ICO). Evaluación del Impacto
(2009) Privacidad
Manual (versión 2.0), la Oficina de Información del Reino Unido Comisionados
(ICO), Londres.
VAN GORP A y de Poel IV (2008) Decidir sobre las cuestiones éticas en la ingeniería
diseño. En Filosofía y Diseño - Desde Ingeniería de Arquitectura
144 metodología sistemática para el impacto privacidad evaluaciones de Marie Caroline
Oetzel y Sarah Spiekermann
Revista Europea de Sistemas de Información
(Vermaas PE, KROES P, LUZ A y MOORE SA, Eds) pp 77-89, Springer,
Amsterdam.
VENABLE J (2006) Un marco para las actividades de investigación en ciencias de
diseño. En
Actas de la Conferencia de la Asociación de Gestión de Recursos de la Información,
Washington, DC, EE.UU., 21-24 de mayo.
PAREDES JG, Widmeyer GR y El Sawy OA (1992) La construcción de un sistema de
información
la teoría del diseño de vigilantes EIS. Sistemas de Información de Investigación 3 (1),
36-59.
WARREN SD y BRANDEIS LD (1890) El derecho a la privacidad. Derecho de
Harvard
4 (5), 193-220.
WESTIN AF (1967) Privacidad y Libertad, Ateneo, Nueva York.
WRIGHT D (2011) En caso de que las evaluaciones de impacto de privacidad
obligatoria?
Comunicaciones del ACM 54 (8), 121-131.
WRIGHT D y DE HERT P Evaluación del Impacto (2012) Privacidad, Springer,
Dordrecht.
WRIGHT D, K Wadhwa, DE HERT P y Kloza D (2011) Impacto de Privacidad
Marco de Evaluación de los derechos de protección de datos y privacidad. Entregable
D1 del Proyecto PIAF UE - Preparado para la Comisión Europea
Dirección General de Justicia. Bruselas.
APÉNDICE A

Objetivos Privacidad y cómo hacer frente a las actividades que pueden crear daños
Para crear una visión global de los objetivos de privacidad, incorporan todos los marcos
regulatorios pertinentes, por lo menos desde un punto de vista europeo. La lista
resultante de la privacidad objetivos como se presentan en la Tabla A1 se basan en:

● todos los elementos de los datos actuales y la propuesta de la UE regulación de la


protección (CE, 1995; CE, 2012);
● todos los principios de protección de los datos incluidos en la OCDE directrices de
privacidad (OCDE, 1980) y Feria de Información Principios de Práctica (FTC, 1998);
● todos los elementos del Marco de Arquitectura de Privacidad ISO / IEC (ISO, 2011);
● objetivos de protección de datos propuesto por Rost & Bock (2011) que destacar los
individuos autodeterminación informativa los derechos.

Estos privacidad "objetivos" legales mayoría europeos son entonces evaluadas con
respecto a su impacto sobre "actividades que perjudican ' como se identifica en el
sistema legal estadounidense. Nos preguntamos si daño privacidad es probable que
ocurra si los objetivos son de privacidad efectivamente abordado. Las actividades
nocivas en la mesa proceder de la taxonomía de Solove de privacidad (Solove, 2006),
que ofrece la más completa y estructurada ver en este asunto. Los conceptos que las
actividades en la tabla se basan en se limitan al contexto de la privacidad de la
información. Por ejemplo, la interferencia decisional (P5.4) se limita a la consideración
de las decisiones que se derivan de los datos recogidos. En contraste, gubernamental
interferencia, que normalmente incorpora corporal y privacidad territorial, se excluye de
esta tabla. Tres expertos en privacidad independientes juzgaron la relación entre los
objetivos de privacidad y las actividades perjudiciales. Dónde se da una relación tal, la
intersección está marcada. PIA evaluadores pueden utilizar las sentencias de la tabla
para determinar si se debe considerar un objetivo privacidad en su contexto. Debido
P4.3 es funcionalmente solamente una extensión de P4.1 y P4.2, que es el único
objetivo que no está asignado explícitamente a cualquiera de las actividades. Al llevar a
cabo una PIA, podría ser útil para elegir las actividades que son relevantes para el
sistema o negocio así, identificar los objetivos de privacidad a considerar.
APÉNDICE B

Análisis de la utilidad relativa de la PIA propuesto metodología


Después de evaluar la utilidad absoluta de la metodología utilizando investigación-
acción, evaluamos relativa de la metodología utilidad comparándola con otra evaluación
de riesgos enfoques. Aunque PIA están empezando a ser utilizado en la práctica, hay
algunas propuestas sobre cómo llevar a cabo los PIA. Una amplia revisión de las
metodologías propuestas puede ser encontrado en Clarke (2011), así como en la primera
entrega del proyecto PIAF que se realizó para el Europeo Comisión (Wright et al,
2011). Ninguno de los existentes Enfoques PIA se ha convertido en un estándar
reconocido hasta la fecha. Sin embargo, uno de los PIA más anunciados en Europa es el
Reino Unido PIA Manual (ICO, 2009). Por lo tanto, queremos comparar este PIA Reino
Unido para nuestro enfoque. En segundo lugar, queremos comparar nuestra
metodología propuesta con un reconocido estándar. Para este propósito, utilizamos el
riesgo ISO 31000 norma de gestión (ISO 2009), que describe cómo para manejar los
riesgos en general, en las organizaciones. La razón por comparamos nuestra
metodología PIA con esta privacidad-independiente estándar es que la privacidad es
sólo uno de varios riesgos organizacionales. Si una organización se ocupa de regular la
privacidad como un riesgo ético, la privacidad debe convertirse en parte de una los
procesos de gestión de riesgos globales de la organización. PIA y nuestro enfoque, por
tanto, debe encajar en tales procesos. Antes de sumergirse en la comparación detallada
de los diferentes enfoques, debemos discutir las diferencias en perspectiva entre las tres
evaluaciones de riesgos. Tanto el Reino Unido PIA e ISO 31000, al igual que otras
metodologías actuales, considerar un proyecto como su objeto de análisis. Nuestra
metodología, por el contrario, se centra en los sistemas. Conscientemente adoptar una
perspectiva centrada en el sistema, por tres razones: En primer lugar, nuestra
metodología PIA pretende liderar un equipo de proyecto en intimidad mediante el
diseño de un nuevo sistema. Por lo tanto nos concentramos más en los riesgos concretos
de diseño de un sistema y menos en el marco de la organización de un nuevo proyecto.
Nosotros tener una perspectiva de ingeniería que se apoya en los negocios procesos
cuando sea necesario. Debido a que los otros dos enfoques abrazar reflexiones de riesgo
de la organización, que están separados de diseño del sistema. La perspectiva centrada
en proyectos También hace que los evaluadores operan dentro de un proyecto de ámbito
de aplicación. Sin embargo, al hacerlo, pueden pasar por alto el más grande contexto
para los sistemas. Por ejemplo, los flujos de datos de carácter personal puede ir más allá
de los sistemas considerados en lo inmediato alcance del proyecto. Por tanto, los flujos
pueden ser definidos como fuera del alcance del proyecto a pesar de que son muy
relevantes desde una perspectiva de privacidad. Por último, fabricantes de TI desarrollar
sistemas que son inicialmente independientes de la implementación. Desde que deben
utilizar los PIA en su desarrollo del sistema ciclo de vida también tiene sentido
centrarse en un sistema. Para comparar nuestra metodología PIA con el Manual de
Reino Unido PIA y la norma ISO 31000, utilizamos siete calidad PIA criterios que
fueron publicados recientemente por Wright & De Hert (2012):
1. A principios de inicio: Un proceso PIA debe comenzar tan pronto como sea posible
de modo que pueda influir en el diseño de un proyecto.

2. Descripción del proyecto: El proyecto se somete a una PIA debe ser adecuadamente
descrito, incluyendo: (1) una descripción general del proyecto, (2) y los flujos de
información (3) requisitos de los instrumentos legales de protección de datos y otros
tipos de privacidad.

3. Consulta de los interesados: Una organización debe identificar los interesados,


informarles sobre el proyecto, buscar sus opiniones y debidamente los toman en cuenta.

4. Riesgos de gestión: El evaluador debe identificar, evaluar y mitigar todos los riesgos
posibles que resultan de un proyecto utilizando (1) evaluación del riesgo y (2) los
enfoques de mitigación de riesgos.

5. Legal comprobación de cumplimiento: El evaluador debe asegurarse de que el


proyecto cumple con las medidas legislativas o de otro tipo los requisitos
reglamentarios.

6. Recomendación e informar: El evaluador debe (1) proporcionar recomendaciones y


un plan de acción, (2) justificar decisiones sobre y aplicación de las recomendaciones y
(3) proporcionar un informe de PIA.

7. Auditoría y revisión: informes PIA deben ser auditados o revisado externamente. Los
tres enfoques metodológicos (UK PIA, ISO 31,000 y nuestro PIA) están de acuerdo en
que una evaluación debe comenzar temprano. El PIA Reino Unido vincula la evaluación
a un ciclo de vida del proyecto y recomienda que la evaluación comienza en el fase de
iniciación de un proyecto; También requiere una cíclico enfoque, lo que significa que
las diferentes fases de la PIA puede ser re-ejecutado en cualquier momento. 31000 ISO
ve riesgo gestión como parte integral de los procesos de organización y pide una
"sistemática, oportuna e iterativo enfoque que es sensible a los cambios '(ISO, 2009).
Como los otros dos enfoques, nuestra metodología PIA está vinculada a un proceso;
nuestra metodología está vinculada a un sistema de proceso de desarrollo, lo que
asegura una sistemática y Por supuesto iterativa de acción. La puntualidad es asegurada
debido nuestra PIA comienza al principio del desarrollo del sistema o cuando se
actualiza un sistema. En cuanto a una descripción del proyecto en general y del sistema,
tanto Reino Unido PIA e ISO 31000 requieren una descripción general del proyecto. El
PIA Manual Reino Unido exige un proyecto esquema y plan del proyecto. ISO 31000
requiere una descripción del contexto de la organización interna, como de organización
objetivos y actitudes hacia el riesgo, así como el contexto para el proceso de gestión de
riesgos. Nuestra propuesta metodología es mucho más específica porque se centra en los
aspectos de un sistema que plantean riesgos de privacidad de hormigón. Nuestra
metodología propuesta exige una más sistemática caracterización del sistema en el paso
1, lo que requiere que el evaluador tomar cuatro puntos de vista diferentes sobre el
sistema y su infraestructura de TI contexto (del sistema, funcionales, datos, física).
Porque es centrado en el sistema, nuestro enfoque proporciona menos información
sobre el proyecto en general y el contexto organizacional. Creemos que las empresas
pueden lograr la intimidad mediante el diseño de una manera más rentable, centrándose
en lo inmediato los riesgos inherentes a un sistema. Sin embargo, debido a la privacidad
ByDesign incluye medidas de gobierno y decisiones estratégicas sobre el manejo de
activos de datos personales, reconocemos que nuestro enfoque PIA debe
complementarse con reflexiones sobre las actitudes de riesgo la privacidad de
organización y de riesgo responsabilidades. Estas reflexiones pueden tener lugar antes
de nuestra PIA proceso comienza y puede informar a los juicios posteriores y informes.
En cuanto a la descripción de los flujos de datos, nuestra systemcentric perspectiva nos
da una ventaja sobre los dos otros enfoques. Se introduce explícitamente una "vista de
datos ' que requiere categorías de datos y diagramas de flujo de datos de flujos de datos
internas y externas, incluyendo actores y datos tipos. Por el contrario, la fase de Reino
Unido PIA 1 contiene un fondo papel que puede describir los flujos de información
personal. ISO
Contexto interno de 31,000 simplemente contiene los flujos de información sin más
detalle. La descripción recomendada de los requisitos de privacidad no se puede
encontrar en la norma ISO 31000 ya que es un riesgo general estándar de la dirección,
no-específica de privacidad. En contraste, el PIA Manual Reino Unido explica
ampliamente la concepto de privacidad y describe cuatro aspectos de la privacidad que
podrían ser considerados en un PIA: privacidad de personal la información, la
privacidad de la persona, a la intimidad de la vida personal el comportamiento, la
privacidad de las comunicaciones personales. Este categorización de la intimidad en
cuatro esferas es muy intuitivo y ayuda a los lectores a comprender la "camaleónica"
privacidad concepto (Solove, 2006). Tomamos un enfoque diferente sin embargo. En
'definición de los objetivos de privacidad' de nuestra metodología, listamos objetivos
privacidad que deben ser utilizados por los ingenieros ya que sus objetivos de diseño de
privacidad. Nuestros objetivos son tanto más concreta y más extenso que el Reino
Unido PIA de cuatro categorías. En contraste con el PIA Reino Unido, también nos
aseguramos de que Requisitos legales europeos están cubiertos. Además, en nuestros
asesores de aproximación deben describir y analizar cada uno objetivo privacidad en el
contexto de sus respectivos contexto. Por estas razones, consideramos que nuestra
metodología para ser más anclado en el concepto de privacidad y más práctico de
aplicar. El tercer criterio de calidad, la consulta de las partes interesadas, es parte de los
tres enfoques de evaluación. El Manual del Reino Unido PIA análisis de las partes
interesadas y establece una consulta grupo durante su fase de preparación. El Manual
también involucra los interesados en su consulta y análisis fase. ISO 31000 contiene una
actividad llamada "comunicación y la consulta 'que involucra la comunicación con
grupos de interés internos y externos y un equipo consultivo enfoque. La entrada precisa
exigió a las partes interesadas no se especifica en estos dos enfoques. Aunque
nuevamente incluir una descripción menos detallada de la organización estructuras, que
no incluyen los interesados en nuestro enfoque y darles un papel concreto. En el paso 3,
por ejemplo, donde la demanda de protección para diferentes privacidad objetivos se
evalúa, se recomienda explícitamente la participación de grupos de interés. Para la
gestión del riesgo, el PIA Manual Reino Unido no lo hace proporcionar ninguna
directriz específica. Su consulta y análisis fase contiene sólo tres señales genéricas:
análisis de riesgos, identificación de problemas y la búsqueda de soluciones. Lo hace no
especifica cómo estas actividades deben ser concretamente perseguido. Evaluación de
riesgos de 31.000 ISO incluye tres actividades que ofrecen recomendaciones detalladas:
la identificación de riesgos, análisis de riesgos y evaluación de riesgos. Las tres
actividades se reflejan en nuestra metodología. En primer lugar, 31000 ISO propone que
una organización se aplica herramientas de identificación de riesgo las técnicas que se
adaptan a sus objetivos y capacidades. En cuanto a las técnicas, se optó por escenarios
de daños y las consideraciones de un operador y datos sujetos perspectiva (Paso 3), así
como una identificación sistemática de las amenazas para cada objetivo que utiliza una
numeración esquema (Paso 4). En segundo lugar, ISO 31000 recomienda que
organizaciones considerar la probabilidad de que las amenazas harán producir y analizar
riesgos cualitativa, semicuantitativa o cuantitativamente. Paso 4 de nuestra metodología
requiere que organizaciones a determinar la probabilidad de que cada amenaza ocurrira.
Por tanto la probabilidad de una amenaza y los datos la demanda de protección, se optó
por un enfoque cualitativo. Nosotros aceptar juicios cualitativos en nuestro enfoque,
porque riesgos de privacidad humanos son a menudo difíciles de describir o cuantificar
que la pérdida de un activo. La mitigación del riesgo se describe en la actividad de la
ISO 31000 "riesgo tratamiento ", que consiste en las opciones de tratamiento del riesgo
de selección, equilibrar los costos contra beneficios y considerando las partes
interesadas. Nuestra metodología trata a este aspecto de la mitigación en los pasos 5
(identificación y recomendación de los controles evaluación adecuado para proteger
contra las amenazas) y 6 (y documentación de los riesgos residuales). En contraste con
la norma ISO 31000, tratamos de mitigación de riesgos más ampliamente. Tenemos así
que no lo hacemos Sólo abordando específicamente los problemas de privacidad, pero
También explicando cómo se aplica la mitigación; en nuestro metodología, las
organizaciones a identificar sistemáticamente controles para todas las posibles
amenazas, utiliza un esquema de numeración, definir tres niveles de rigor, partido rigor
y protección exigir y proporcionar un plan de implementación. Abordamos lo que la
norma ISO 31000 para las llamadas, pero hacerlo de una manera más detallada forma.
Teniendo en cuenta el criterio quinta calidad, no es del todo claro si Wright & De Hert
(2012) y De Hert et al (2012) recomienda un control de cumplimiento de la ley actual,
que se lleva a cabo más tarde y además de un PIA (ICO, 2009), o si recomiendan
asegurar el cumplimiento legal como parte de la evaluación. Los tres enfoques tienen
como objetivo para lograr el cumplimiento de los requisitos legales y reglamentarios. El
PIA Manual Reino Unido y nuestra metodología enfatizan que implicaciones de
privacidad son un movimiento rápido objetivo en el cambiante mundo de la técnica y
que legal objetivos privacidad menudo no pueden abordar todos subsiguientes desafíos.
Los tres enfoques de evaluación requieren que las organizaciones a formular
recomendaciones y justificar su ejecución. En la consulta y análisis de fase el Reino
Unido del PIA, las organizaciones a crear un registro de problemas que enumera la
prevención medidas que se consideraron, explica por qué fueron rechazadas o adoptado,
e identifica las que estén no se aborda. Para la actividad de la ISO 31000 'tratamiento
del riesgo', organizaciones seleccionar las opciones de tratamiento del riesgo de que el
equilibrio costos contra beneficios, reconocen opiniones de los interesados, y preparar y
aplicar un plan de tratamiento de riesgos. Similar a estos enfoques, el Paso 5 de nuestra
metodología requiere que las organizaciones recomiendan controles; Sin embargo, las
organizaciones también debe elegir un nivel justificado de rigor para cada control para
satisfacer el nivel de demanda de protección identificados en el Paso 3. Además,
ofrecemos una extensa lista de controles técnicos y no técnicos ejemplares para cada
potencial riesgo para la privacidad. Una vez más, nuestra metodología proporciona una
mayor especificidad, aplicabilidad práctica y paso a paso guía. Un análisis de costo-
beneficio, un control plan de ejecución y la documentación de los residuales entonces se
requieren riesgos en nuestra Paso 6. Los tres enfoques requerir documentación del
proceso de evaluación. el Reino Unido PIA y nuestra metodología llaman un informe
PIA y recomiendan publicarlo. Nuestra PIA va un paso más allá y ofertas un conjunto
de elementos de contenido concreto de que un informe de PIA puede incluir para
diferentes públicos objetivos (paso 7). Por último, sólo nuestra metodología propuesta
cumple con el último criterio de calidad, que recomienda que un informe de PIA deben
ser auditados y revisados externamente. Facilitar auditoría externa y la revisión del
informe de PIA, se recomienda la creación de un informe de PIA de lectura mecánica.
Tabla B1 muestra que nuestra metodología PIA es el más avanzado de los tres enfoques
con respecto a la propuesta criterios de calidad para un proceso de PIA de mejores
prácticas.

Das könnte Ihnen auch gefallen