Beruflich Dokumente
Kultur Dokumente
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.
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.
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.
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
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.
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
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.
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
P2 - legitimidad Procesamiento
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)
PLANIFICACIÓN DE ACCIONES
PASAR A LA ACCIÓN
CONCLUSIÓN
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
REFERENCIAS
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:
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
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.
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.
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.