21 septiembre 2018

Contención en las secuencias en entornos Oracle RAC

Recientemente me encontré con un caso en el que seleccionar el siguiente valor de una secuencia causó problemas de contención en Oracle RAC. Mira esta captura de pantalla:

Los eventos de espera tendrán el mismo aspecto si se muestran en las pantallas de rendimiento de Enterprise Manager, que sí requieren una licencia para el Paquete de diagnóstico opcional.
Podemos ver altas esperas en el evento de espera de bloque de caché de fila, así como múltiples eventos de espera de caché global (todos comienzan con "gc").
El problema fue que la secuencia se creó con CACHE establecido en cero. Las secuencias en Oracle RAC con una configuración de caché demasiado baja verán eventos de espera como este. La solución es simple, aumente el tamaño de CACHE.



09 julio 2018

Cómo corregir las tablas fragmentadas de una base de datos Oracle 11g


¿Qué es la fragmentación de datos?

Si a una tabla únicamente se somete a inserciones, no habrá ninguna fragmentación. La fragmentación viene solo cuando hacemos borrados/actualizaciones a la tabla.
El espacio que se libera durante las operaciones “no-inserts” no son usadas inmediatamente (algunas veces jamás se usaran). Esto deja huecos en la tabla que resultan en fragmentación.
la fragmentación de las tablas es diferente a la fragmentación de archivos, cuando se realizan muchas operaciones DML (Data manipulation language) en una tabla, la tabla se fragmenta, debido a que las DML no liberan el espacio de la tabla debajo de la High Water Mark ( HWM=  es la última parte de una tabla que le indica al cursor que hasta allí llego la tabla y contiene la cantidad de registros)
Cada vez que la información crece, elimina el bloque donde está el HWM y recreando otro HWM cuando termina de incrementar el espacio, estos bloques donde estaban los HWM’s no ocupan casi nada de espacio, pero después de muchísimo uso y mucho tiempo ya pueden ser significativos en el tiempo de lectura.

¿Cuáles son las razones de reorganizar la tabla?


·         bajo tiempo de respuesta (de esa tabla en especial)
·         Alto número de campos encadenados (o migrados)
·         La tabla ha crecido muchos bloques y el espacio antiguo no ha sido reutilizado

Nota: Los consultas basados en índices no se beneficiaran mucho por la reorganización comparado con las consultas que hacen un “full table scan”
 ¿Cómo encontrar la fragmentación de las tablas?
En los esquemas de Oracle en donde se encuentran una gran diferencia entre el tamaño actual (se encuentra en la vista user_segments) y el tamaño esperado de user_tables (Num_rows*avg_row_length (in bytes)). Toda esta diferencia se debe a la fragmentación de la tabla o la columna de stats no está actualizada en dba_tables.
Pasos para revisar y remover la fragmentación de las tablas:
Obtener las estadísticas de las tablas:
Para tener la diferencia exacta del tamaño actual (dba_segments) y el tamaño de las stats (dba_tables). La diferencia entre estos valores reportara la verdadera fragmentación al DBA. Así que para tener actualizadas las stats en dba_tables. Revisa el valor de LAST_ANALYZED de la tabla en dba_tables. Si este valor es reciente, puedes brincarte este paso, además yo sugeriría obtener las estadísticas de las tablas para actualizar este valor.
exec dbms_stats.gather_table_stats(‘&schema_name’,’&table_name’);

Revisa el tamaño de la tabla:
De nuevo revisa el tamaño de la tabla y fíjate si se redujo. Recuerda que el dato esta en bytes, lo transformas a kb dividiéndolo en 1024 y a megabytes otra vez dividiendo en 1024
select table_name,bytes/(1024*1024*1024) from dba_table where table_name=’&table_name’;
 Revisa la fragmentación de la tabla:
El siguiente query te mostrara el tamaño total de la fragmentación esperada y cuanto porcentaje del tamaño se puede reclamar después de remover la fragmentación, el administrador de la base de datos te tiene que proveer el table_name y el schema_name, eso te lo pedirá este query.
set pages 50000 lines 32767
select owner,table_name,round((blocks*8),2)||’kb’ “Tamanio fragmentado”, round((num_rows*avg_row_len/1024),2)||’kb’ “Tamanio Actual”, round((blocks*8),2)-round((num_rows*avg_row_len/1024),2)||’kb’,
((round((blocks*8),2)-round((num_rows*avg_row_len/1024),2))/round((blocks*8),2))*100 -10 “espacio reclamable % ” from dba_tables where table_name =’&table_Name’ AND OWNER LIKE ‘&schema_name’
/
Esta consulta obtiene datos de dba_tables, así que la precisión del resultado depende de los stats del dba_table. Si tú encuentras espacio reclamable mayor al 20%, entonces podemos esperar que exista fragmentación es en esta tabla, suponiendo que el dba encuentra el 50% reclamable de la consulta anterior, puede proceder a remover la fragmentación.
¿cómo reiniciar los HWM /remover fragmentación?
Tenemos cuatro opciones diferentes para reorganizar las tablas fragmentadas
  • Alter table move (mover la tabla a otro tablespace o dentro del mismo tablespace) y reconstruir índices.
  • Exportar e importar la tabla. (Muy difícil de implementar en un ambiente productivo)
  • Comando Shrink (de Oracle 10g para arriba) (el comando shrink solo es aplicable a las tablas que tengan activado “auto segment space management)
  • Alter table move (mover la tabla a otro tablespace o dentro del mismo tablespace) y reconstruir índices.

Recolecta el estatus de todos los índices de la tabla:
Recolectaremos todos los estatus de los índices en un solo lugar.
select index_name,status from dba_indexes where table_name like ‘&table_name’;
Mueve la tabla al mismo tablespace o a uno diferente:
En este paso moveremos la tabla fragmentada a otro espacio (o al mismo) para recuperar el espacio fragmentado, encuentra el tamaño actual de tu table de los segmentos de dba_segments y revisa si continua con el mismo espacio libre.
alter table <table_name> move; <—mueve la tabla al mismo tablespace
O
alter table <table_name> enable row movement;
alter table <table_name> move tablespace <nuevo_tablespace>;
Luego tienes que regresarlo al tablespace antiguo usando el siguiente comando:
alter table table_name move tablespace tablespace_viejo;

Ahora reconstruye los índices
Necesitamos reconstruir todos los índices de la tabla porque con el comando move todos los índices viejos se vuelven inservibles

SQL> select status,index_name from dba_indexes where table_name = ‘&table_name’;
STATUS INDEX_NAME
——– ——————————
UNUSABLE INDEX_NAME ——-> El valor que te diga aquí te dice si el índice sirve o no sirve
SQL> alter index <INDEX_NAME> rebuild online; ——-> Usa este comando para cada índice
Index altered.
SQL> select status,index_name from dba_indexes where table_name = ‘&table_name’;
STATUS INDEX_NAME
——– ——————————
VALID INDEX_NAME ——-> después de ejecutar el comando anterior, aquí te debe de decir VALID
Obtener estadísticas de la tabla
——————
SQL> exec dbms_stats.gather_table_stats(‘&owner_name’,’&table_name’);
PL/SQL procedure successfully completed.

Revisa el tamaño de la tabla:
—————–
De nuevo revisa el tamaño de la tabla y verifica si ya bajo de tamaño
select table_name,bytes/(1024*1024*1024) from dba_table where table_name=’&table_name’;

Revisa la fragmentación de la tabla:
——————————–
set pages 50000 lines 32767
select owner,table_name,round((blocks*8),2)||’kb’ “Fragmented size”, round((num_rows*avg_row_len/1024),2)||’kb’ “Actual size”, round((blocks*8),2)-round((num_rows*avg_row_len/1024),2)||’kb’,
((round((blocks*8),2)-round((num_rows*avg_row_len/1024),2))/round((blocks*8),2))*100 -10 “reclaimable space % ” from dba_tables where table_name =’&table_Name’ AND OWNER LIKE ‘&schema_name’
/
 Usa el comando shrink (para Oracle 10g)
Comando shrink:
Entre las nuevas características de 10g para reorganizar (shrink) las tablas “casi” en línea, puede ser usada junto al ASS (automatic segment space management)
Este comando solo es aplicable para tablas que el tablespace tenga ASS

Antes de usar este comando, tú debes de activar el “row movement”
SQL> alter table <table_name> enable row movement;
Table altered.

Existen dos maneras de usar este comando.
1. Reorganiza los campos y resetea el HWM
Parte 1: reorganiza (todas las DML pueden ocurrir mientras haces esto)
 SQL> alter table <table_name> shrink space compact;
Table altered.
 Parte 2: resetea el HWM (mientras haces esto no debes de ejecutar DMS. pero es muy rápido, casi imperceptible)
SQL> alter table <table_name> shrink space;
Table altered.
2. Directamente resetea el HWM:
SQL> alter table <table_name> shrink space; (con este comando se resetea y se reorganiza a la vez)
Table altered.





21 febrero 2018

Oracle E-Business Suite: registro y auditoría (seguimiento de acceso a la página)

La auditoria de inicio de sesión solo registra la actividad de formularios profesionales; no registra la actividad del usuario de Oracle Applications Framework (OAF). El seguimiento de acceso a la página es necesario para registrar la actividad OAF. Una vez habilitado, el nivel de registro debe establecerse, así como marcar las aplicaciones para que se registren y tiene una sobrecarga insignificante.

Para configurar el seguimiento de acceso a la página, use la siguiente navegación: System Administration -> Oracle Applications Manager -> Site Map > Monitoring > Applications Usage Reports > Page Access Tracking..

Una vez habilitado, el seguimiento de acceso a la página requiere la ejecución de dos programas simultáneos. La migración de datos de seguimiento de acceso de página del programa se debe ejecutar para mover los datos de las tablas intermedias a las tablas de informes. Esto generalmente se hace a diario. Para purgar los datos de forma periódica, ejecute el programa de datos de depuración de seguimiento de acceso de página.

Los niveles de registro son:

  • Información de la sesión
  • Información de sesión y cookies
  • Información de sesión, cookies y parámetros de URL
  • Información de sesión, cookies y todos los parámetros

Una vez configurados, los informes se pueden ejecutar para los siguientes tipos de actividad:

  • Sesión
  • Fecha
  • Formar
  • Usuario
  • Solicitud

¿Cómo saber si el seguimiento de página de acceso está activado?


  • Compruebe la opción de perfil del sistema JTF_PF_MASTER_ENABLED y si se establece en TRUE para supervisar el acceso web
  • Verifique la opción de perfil del sistema JTF_PF_LEVEL. Esto se establecerá para cada aplicación. Además, se puede establecer para Responsabilidades y usuarios:

JTF_PF_LEVEL
Descripción
22
Session info
118
Session Info and Cookies
254
Session Info, Cookies and URL Parameters
126
Session Info, Cookies and All Parameters

¿Qué tablas almacenan el registro del acceso a cada pagina de la E-Business Suite?

La siguiente tabla identificó las tablas utilizadas para almacenar los datos de seguimiento de acceso a la página. Recuerde que los programas concurrentes de Page Access Tracking Data Migration y Page Access Tracking Purge Data, respectivamente, insertan datos y eliminan datos de estas tablas.

Tablas de seguimiento de acceso a páginas

  • JTF.JTF_PF_SES_ACTIVITY
  • JTF.JTF_PF_ANON_ACTIVITY
  • JTF.JTF_PF_APP_SUMM
  • JTF.JTF_PF_HOST_SUMM
  • JTF.JTF_PF_PAGE_SUMM
  • JTF.JTF_PF_USER_SUMM

Pantallas de configuración de Page Access Tracking







Oracle E-Business Suite: Consejos sobre seguridad cuando actualizas la base de datos

Al actualizar la base de datos de Oracle E-Business Suite a Oracle Database 12c (12.1), hay una serie de consideraciones y pasos de seguridad que deberían incluirse en el procedimiento de actualización:
  • Nota de soporte de Oracle ID 1524398.1 : Notas de interoperabilidad: Oracle E-Business Suite versión 12.0 o 12.1 con Oracle Database 12c versión 1 (12.1.0)


Aquí, documentaremos los pasos que se deben incluir o modificar para mejorar la seguridad de la base de datos. 

Consejo 1:

"Si bien no es obligatorio para la interoperabilidad de Oracle E-Business Suite con Oracle Database, los clientes pueden optar por aplicar Actualizaciones de conjunto de parches de base de datos (PSU) en su Oracle E-Business Suite Database ...".

Después de cualquier actualización de la base de datos, siempre se debe aplicar el último parche de CPU (ya sea PSU o SPU). La actualización de la base de datos solo tiene el último parche de CPU disponible en el momento del lanzamiento del parche de actualización de la base de datos. En el caso de 12.1.0.1, la actualización de la base de datos estará vigente a partir de julio de 2013 y faltarán los últimos cinco parches de CPU. Los parches de actualización de la base de datos restablecen el nivel de la CPU, por lo tanto, incluso si hubiera aplicado el parche de la CPU más reciente antes de la actualización, la actualización revertirá el nivel del parche de la CPU a julio de 2013.

Desde una perspectiva de seguridad, el último parche (PSU) debe considerarse obligatorio.

Consejo 2:

Es importante observar desde una perspectiva de seguridad que Database Vault, si está instalado, debe desactivarse durante el proceso de actualización. Todas las protecciones habilitadas en Database Vault destinadas a DBA se desactivarán durante la actualización.

Consejo 3:

El esquema DMSYS ya no se usa con Oracle E-Business Suite y se puede eliminar de forma segura. Recomendamos que elimine el esquema como parte de este paso para reducir la superficie de ataque de la base de datos y eliminar los componentes no utilizados. Use el siguiente SQL para eliminar el usuario DMSYS :

DROP USER DMSYS CASCADE;

Consejo 4:

Como parte de la actualización, es un buen momento para revisar que los parámetros de inicialización relacionados con la seguridad estén configurados correctamente. Verifique que los siguientes parámetros estén establecidos:

o7_dictionary_accessibility = FALSE
audit_trail = <set to a value other than none>
sec_case_sensitive_logon = TRUE (patch 12964564 may have to be applied)

Consejo 5:

Para Oracle E-Business Suite 12.1, sqlnet_ifile.ora debe contener el siguiente parámetro para que se corresponda con el parámetro de inicialización sec_case_sensitive_login = true -

SQLNET.ALLOWED_LOGON_VERSION_SERVER = 10

12 diciembre 2017

¿Hay vida más allá de Oracle? Open banking y PSD2

La Directiva de Servicios de Pago (PSD) adoptada en 2007 tenía por objeto crear un mercado único de pagos en la Unión Europea. Sin embargo, las limitaciones, como que cada país tenga diferentes regulaciones sobre el acceso de terceros a cuentas de clientes, llevaron a que los servicios se localizaran por país. Además, los bancos no estaban obligados a otorgar a proveedores externos acceso a las cuentas de sus clientes

A la luz de estas limitaciones, la Comisión revisó la Directiva revisada de servicios de pago (PSD2 - Directiva UE 2015/2366) en 2013. El objetivo de PSD2 es crear una mayor comodidad y elección para los clientes de la Unión Europea, integrar y mejorar el proceso de pago, crear igualdad de condiciones para los proveedores de servicios de pago, fomentar la innovación y la competencia.

 ¿Qué propone PSD2?

  • Derecho incondicional de devolución para los adeudos domiciliados en el marco del SEPA CORE.
  • Sistema de autenticación de clientes mucho más fuerte.
  • Prohibición de recargos por pagos con tarjeta.
  • Protección mejorada del cliente para pagos realizados fuera de la UE o en monedas no pertenecientes a la UE.
  • Introducción de proveedores de servicios de pago de terceros (TPP) al panorama financiero de la UE:
    • Proveedores de servicios de iniciación de pagos: (PISP) con acceso a la información de la cuenta del cliente del banco.
    • Proveedores de servicios de información de cuenta: (AISP) que puede iniciar un pago en nombre del cliente.
  • También habrá proveedores de servicios de pago de servicios a la cuenta: ASPSP que no son más que bancos que deben proporcionar acceso a la información del cliente a los TPP que utilizan APIs.

 

 ¿Cómo cambia el PSD2 el panorama financiero de la Unión Europea?


 Según una estrategia y estudio de PwC sobre PSD2 en 2016, el 88% de los consumidores utilizan proveedores externos para pagos en línea, lo que indica una gran base de clientes listos para otros servicios de banca digital como pagos, planificación financiera, etc. 2018 es cuando el PSD2 se supone que se pondrá en marcha y, según los expertos de la industria, terminará el monopolio de los bancos sobre la información de sus clientes. Bajo PSD2 los bancos estarán obligados a compartir su información de clientes con terceros a través de API abiertas. Estos terceros proveedores pueden construir sus servicios utilizando los datos del banco. Los bancos también tendrán que soportar mayores costos de proporcionar la infraestructura de seguridad alrededor de las API que expondrán. 

Esto dará como resultado un aumento dramático en la competencia en el sector financiero con los bancos que ya no compiten con otros bancos, sino también con entidades no bancarias o Fintechs que tendrán un acceso más fácil al mercado. De acuerdo con algunas proyecciones, se prevé que hasta el 9% de los ingresos de pagos minoristas se perderán para los servicios de PISP en 2020, justo dos años después de la puesta en marcha del PSD2.

¿Cómo pueden responder los bancos?

El sector bancario es uno de los mayores consumidores de tecnología. Sin embargo, la mayor parte de este gasto se realiza en actividades de mantenimiento (Transición Cobol --> Java de los noventa, Banca por internet en el inicio de siglo). Lo que ha impedido que los bancos tradicionales sean innovadores no es el costo de adquirir nueva tecnología, sino la indecisión de ceder el control y la inercia de la organización. Este puede ser un enfoque muy arriesgado a la luz de la presión del regulador para nivelar el campo de juego al permitir que nuevos jugadores ingresen al sector bancario y cambien las expectativas de los clientes. 

Los bancos pueden usar el PSD2 como otro requisito de cumplimiento (como PCI DSS o GDPR) o convertirlo en una oportunidad para desarrollar nuevos modelos de negocios al tiempo que brindan servicios que los clientes de la nueva era desean.

El Banco es la plataforma

Los bancos pueden abrir sus API que pueden ser utilizadas por desarrolladores externos para extender la funcionalidad de la plataforma a un nivel tecnológico, mientras que los proveedores externos pueden usar la plataforma para crear valor para los consumidores a nivel comercial. Los bancos actuales deberían liderar la industrialización de sus API y construir sus propios ecosistemas digitales y / o ser parte de un ecosistema externo. Este enfoque ayudará a los bancos a ser más ágiles y crear nuevas oportunidades en la creación y distribución de productos al tiempo que se abren nuevas fuentes de ingresos.
Hay dos enfoques para adoptar esta estrategia:
  • Crear una plataforma de banca digital basada en aplicaciones de aplicaciones de terceros, como:
      • Cuentas corrientes. 
      • Tarjetas de crédito / débito.
      • Préstamos personales instantáneos. 
    • El banco construirá un mercado de aplicaciones como una plataforma de comercio electrónico donde los demás jugadores;  Tanto FinTechs como otros bancos más pequeños pueden listar sus productos o servicios financieros. 
    • Los consumidores luego usarán el mercado bancario para consumir productos y servicios como lo hacen, por ejemplo, desde un Amazon
    • Los ingresos de un banco digital de este tipo no serán los honorarios que pagan los consumidores finales, sino los proveedores de aplicaciones que enumeran sus aplicaciones en la plataforma
    • Los bancos también pueden ampliar sus servicios al habilitar algunos de estos módulos de terceros para sus propias ofertas básicas y encontrar nuevas oportunidades de venta cruzada.
  • En segundo lugar, pueden formar parte de un mercado API de terceros como Open Bank Project (OBP) con sede en Berlín, donde tienen acceso a la comunidad de desarrolladores que pueden crear rápidamente nuevos productos y servicios para ellos. Estos mercados API de terceros también ofrecen aplicaciones etiquetadas en blanco y bancos de pruebas para bancos y otros proveedores de terceros para desarrollar soluciones que ofrezcan una mejor experiencia a sus clientes. Esto reducirá el costo y el tiempo de desarrollo para los bancos, ya que no tienen que invertir en la creación de productos y API desde cero, sino que usarán los servicios de los desarrolladores cuando sea necesario.

Ofrecer servicios PISP: los bancos pueden usar este enfoque para distribuir sus ofertas de banca transaccional y ofrecer soluciones de pago P2P basadas en API de bajo costo y mucho más rápidas. Un buen ejemplo son el banco danés Saxo Bank, o Capital One un banco con sede en el Reino Unido, que ahora permite a los afiliados beneficiarse a través de sus API, en España tenemos un ejemplo que conozco más BBVA:

El banco español BBVA es uno de los primeros en dar el salto al Open Bank. Viendo las API como fundamentales para su futuro, BBVA ha creado una Mercado API para desarrolladores externos.


Monetice los datos y las perspectivas de los clientes: los bancos tradicionalmente han recopilado y agregado información de los clientes que es tremendamente valiosa para los nuevos participantes. Los bancos pueden usar análisis avanzados para obtener información de datos transaccionales que ayudarán a los nuevos participantes a orientar mejor a sus clientes. Al utilizar API abiertas, los bancos pueden trabajar como proveedores de estos datos enriquecidos para terceros y así crear nuevas oportunidades de ingresos.

Los bancos también pueden actuar como proveedores de servicios de información de cuentas para sus clientes. Los nuevos participantes de AIS que pretenden proporcionar servicios similares estarían restringidos por la cantidad de clientes que se suscriban a sus servicios, mientras que los bancos ya tienen una gran base de datos de clientes existentes que ofrece una tremenda ventaja como primer usuario.

Pasos a tener en cuenta

Adopta un enfoque de diseño basado en el dominio.

El enfoque para identificar y empaquetar las API debe ser impulsado por el dominio. Para los bancos, esto significa volver al tablero de diseño y analizar todos los procesos comerciales relevantes. Este enfoque requiere que los bancos consideren los procesos desde la perspectiva del cliente (un esfuerzo a tener en cuenta) y los racionalicen para las experiencias digitales. También 
asegura una acumulación progresiva de un repositorio API sin perder 
vista de los controladores clave del programa.

Desde el punto de vista operativo, un enfoque de diseño impulsado por el dominio implica examinar cada uno de los procesos de negocios, internos y externos, y dividirlos en "bloques de LEGO" más pequeños de forma iterativa. Este enfoque es radicalmente diferente de un enfoque de abajo hacia arriba (Top-Down), que analiza las capacidades del panorama actual de la aplicación, lo que resulta en la limitación de las posibilidades de sostener futuras innovaciones.

El enfoque de diseño impulsado por el dominio se ha utilizado en el mundo del desarrollo de software desde hace tiempo y se puede aplicar a otras APIs .

Suscribirse a las API.

Construir cada API única no solo es innecesario sino también tiende a afectar el ritmo y la economía del propio programa. Al fin y al cabo, nadie construye APIs sociales, nos suscribimos a ellas a través de Facebook, Google o Twitter. Hay muchos repositorios de APIs, disponibles hoy para la suscripción desde FinTechs (BBVA España PayStats o BBVA España Payments) a empresas tecnológicas que se centran en cada dominio del negocio. El hecho de que estas organizaciones se enfocan en un solo problema comercial o dominio y muy a menudo trae experiencia global, ayuda a incorporar prácticas recomendadas a nivel mundial en un programa API.

Suscribiéndose a una APIs (y si es necesario ampliarlas, que es muy fácil) ayuda a acelerar no solo el programa API per se, sino también indirectamente empuja a las otras iniciativas de digitalización que están vinculadas.

Un banco puede pensar: "Vale, tenemos un gran producto, pero no podemos desarrollar todas sus vertientes. ¿Qué mejor que aliarse con quien está especializado en dar ese tipo de servicios, para ofrecer el mejor servicio posible a nuestros clientes?

Impulsar el negocio y supervisar la gestión.

Para que un programa API sea exitoso, necesita el compromiso y la cooperación de las partes interesadas comerciales relevantes. Las iniciativas API más exitosas cuentan con el apoyo del propio CEO, por complicada que sea este apoyo.

A largo plazo, la adopción de un enfoque táctico de las API, con el único propósito de ejecutar aceleradores y programas de incubación, puede no producir el mejor ROI.

Cualquier iniciativa API debe centrarse a largo plazo y basarse en modelos comerciales e ingresos innovadores. Esto debería contar con el respaldo adicional de un equipo de gobierno corporativo y un plan progresivo que se desglosa en objetivos a corto plazo.

05 diciembre 2017

¿Hay vida más allá de Oracle? Evaluaciones de impacto de protección de datos bajo la GDPR

Las evaluaciones de impacto de protección de datos (DPIA) ayudan a las organizaciones a identificar, evaluar y mitigar o minimizar los riesgos de privacidad con las actividades de procesamiento de datos. Son particularmente relevantes cuando se introduce un nuevo proceso, sistema o tecnología de procesamiento de datos.

Los DPIA también respaldan el principio de rendición de cuentas, ya que ayudan a las organizaciones a cumplir con los requisitos del Reglamento General de Protección de Datos (GDPR) y demuestran que se han tomado las medidas adecuadas para garantizar el cumplimiento.

El incumplimiento de una DPIA adecuada, en su caso, constituye un incumplimiento del GDPR y podría generar multas de hasta el 2% de la facturación global anual de una organización o 10 millones €, el que sea mayor.

¿Cuándo debería realizarse un DPIA?


La GDPR exige que se lleve a cabo una DPIA donde el procesamiento de datos probablemente genere un alto riesgo para los derechos y las libertades de las personas físicas. Las tres condiciones principales identificadas en el GDPR son:
  • Una evaluación sistemática y exhaustiva de los aspectos personales relacionados con las personas físicas, que se basa en el procesamiento automatizado, incluida la elaboración de perfiles, y en la que se basan las decisiones que producen efectos jurídicos sobre la persona física o afectan de forma similar a la persona física.
  • Procesamiento a gran escala de categorías especiales de datos o de datos personales relacionados con condenas y delitos penales.
  • Monitoreo sistemático de un área de acceso público a gran escala.

Ejemplos de procesamiento de datos personales donde es probable que se requiera un DPIA

  • Compañía proveedora de servicio de telefonía e internet:
    • Retención de datos de llamadas, mensajes y accesos a internet
  • Grandes corporaciones: 
    • Una empresa que supervisa sistemáticamente las actividades de sus empleados, incluidas sus estaciones de trabajo y su actividad en Internet.
  • Bancos e intermediarios financieros: 
    • Una institución que crea una calificación crediticia o base de datos de fraude a nivel nacional.
    • Listas negras, tipo World-check, de verificación KYC ("Know Your Customer").
    • Listas AML (anti-lavado de dinero), como Accuity Global WatchList.
  • Empresas farmacéuticas e instituciones médicas: 
    • El archivo de datos sensibles personales pseudonimizados de proyectos de investigación o ensayos clínicos.
    • Un hospital que procesa los datos genéticos y de salud de sus pacientes en su sistema de información.
  • Compañías de marketing:
    • La recopilación de datos de redes sociales públicas para generar perfiles.

¿Cuándo debería realizarse un DPIA?

Se debe realizar un DPIA lo antes posible dentro de cualquier ciclo de vida del  proyecto de adaptación a GDPR, de modo que sus hallazgos y recomendaciones puedan incorporarse en el diseño de la operación de procesamiento.

Conocido como privacidad por diseño, la incorporación de características de privacidad de datos en el diseño de proyectos puede tener los siguientes beneficios:
  • Abordar los problemas con anticipación a menudo será más simple y menos costoso.
  • Los problemas potenciales se identifican en una etapa temprana.
  • Mayor conciencia de privacidad y protección de datos en toda la organización.
  • Las organizaciones tendrán menos probabilidades de violar el GDPR.
  • Es menos probable que las acciones sean intrusivas para la privacidad y tengan un impacto negativo en las personas.

Elementos clave de un DPIA exitoso

La GDPR no especifica qué proceso debe seguirse, para realizar un DPIA, sino que permite a las organizaciones introducir un marco que complementa sus prácticas de trabajo existentes. 
Un DPIA generalmente constará de los siguientes pasos clave:
  • Identifique la necesidad de un DPIA.
  • Describe el flujo de información.
  • Identificar la protección de datos y los riesgos relacionados.
  • Identificar soluciones de protección de datos para reducir o eliminar los riesgos.
  • Firme los resultados de DPIA.
  • Integra soluciones de protección de datos en el proyecto.

¿Quién debería participar en la realización de un DPIA?

La organización (controlador del dato) es la responsable de garantizar que se lleve a cabo la puesta en marcha de un DPIA. Esta puesta en marcha debe ser impulsada por personas con la experiencia y el conocimiento adecuados del proyecto en cuestión, normalmente el equipo del proyecto. Si su organización no posee suficiente experiencia y experiencia internamente, puede considerar contratar especialistas externos para que asesoren con su experiencia/conocimiento o realicen el mismo DPIA.

Bajo la GDPR es necesario que cualquier organización con un oficial de protección de datos designado (DPO) busque el consejo de la DPO. Este consejo y las decisiones tomadas deben documentarse como parte del proceso DPIA.

Los elementos clave del mapeo de datos en GDPR

Para mapear efectivamente sus datos, necesita comprender el flujo de información, describirlo e identificar sus elementos clave.

Comprender el flujo de información
Un flujo de información es una transferencia de información de una ubicación a otra, por ejemplo: 
  • Desde dentro hacia fuera de la Unión Europea.
  • Desde proveedores y subproveedores hasta clientes.
Describe el flujo de información
  • Recorra el ciclo de vida de la información para identificar usos de datos imprevistos o involuntarios. Esto también ayuda a minimizar qué datos se recopilan.
  • Asegúrese de consultar a las personas que utilizarán la información sobre las implicaciones prácticas.
  • Considere los posibles usos futuros de la información recopilada, incluso si no es inmediatamente necesaria.
Identificar sus elementos clave
Elementos de datos
  • ¿Qué tipo de información se está procesando (nombre, correo electrónico, dirección, etc.)  
  • En qué categoría pertenece (datos de salud, antecedentes penales, datos de ubicación, etc.)?
Formatos
  • ¿En qué formato almacena los datos (copia impresa, digital, base de datos, trae su propio dispositivo, teléfonos móviles, etc.)?
Método de transferencia
  • ¿Cómo se recopilan datos (publicaciones, teléfonos, redes sociales) y cómo se comparte internamente (dentro de su organización) y externamente (con terceros)?
Ubicación
  • ¿Qué ubicaciones están involucradas en el flujo de datos (oficinas, la nube, terceros, etc.)?
Responsabilidad
  • ¿Quién es responsable de los datos personales? A menudo, esto cambia a medida que los datos se mueven en toda la organización.
Acceso
  • ¿Quién tiene acceso a los datos en cuestión?

Los desafíos clave del mapeo de datos

  • Identificando datos personales: Los datos personales pueden residir en una serie de ubicaciones y almacenarse en varios formatos, como papel, electrónico y audio. Su primer desafío es decidir qué información necesita registrar y en qué formato.
  • Identificar salvaguardias técnicas y organizativas apropiadas: El segundo desafío probablemente sea identificar la tecnología apropiada, y la política y los procedimientos para su uso, para proteger la información y, a la vez, determinar quién controla el acceso a la misma.
  • Comprender las obligaciones legales y regulatorias: Su desafío final es determinar cuáles son las obligaciones legales y reglamentarias de su organización. Además del GDPR, esto puede incluir otros estándares de cumplimiento, como el estándar de seguridad de datos de la industria de tarjetas de pago (PCI DSS) e ISO 27001.
Una vez que haya completado estos tres desafíos, estará en condiciones de avanzar, ganándose la confianza de sus partes interesadas clave.

Otros pasos a tener en cuenta

Implantar, si es necesario, un sistema de gestión de información personal (PIMS)
BS 10012: 2017 es el estándar británico que especifica los requisitos para un sistema de gestión de información personal (PIMS) y está alineado con los requisitos del GDPR.

Proporciona una estructura bien definida para gestionar la protección de datos, y está diseñada para seguir el ciclo planificar-hacer-verificar-actuar (PDCA) para garantizar la mejora continua.

Haber implantado un sistema de gestión de seguridad de la información (ISMS)
La certificación acreditada según ISO 27001 demuestra que su empresa sigue las mejores prácticas de seguridad de la información y ofrece una evaluación independiente y experta de si sus datos están adecuadamente protegidos. Reconocido internacionalmente, es independiente del sector, no favorece ninguna tecnología o solución, y puede ser utilizado por organizaciones de cualquier tamaño.

El enfoque basado en riesgos ISO 27001 para implementar controles de seguridad de la información es un excelente enfoque para cumplir con el requisito de GDPR de que las organizaciones implementen controles técnicos y organizacionales apropiados para garantizar la "confidencialidad, integridad y disponibilidad" de los sistemas y servicios de procesamiento.