Riesgos de integrar sistemas y aplicaciones en una empresa
Los riesgos de integrar sistemas suelen pasar desapercibidos porque las integraciones funcionan de forma silenciosa. Una empresa decide automatizar un proceso aparentemente sencillo.
La empresa decide automatizar un proceso aparentemente sencillo.
Un cliente completa un formulario desde la página web.
Automáticamente, la información llega al CRM.
Por otro lado, la herramienta de inteligencia artificial resume la solicitud.
El resumen se incorpora al expediente.
El documento se almacena en la nube.
El responsable comercial recibe una notificación.
Después, el ERP utiliza parte de esos datos para preparar el presupuesto.
Todo sucede en apenas unos segundos.
Desde fuera parece un único proceso.
En realidad, han intervenido varios sistemas, distintos proveedores, diferentes credenciales y múltiples intercambios de información.
La automatización funciona porque todas esas aplicaciones confían unas en otras.
Sin embargo, pocas organizaciones se detienen a analizar qué implica realmente esa confianza.
Porque cada integración decide qué información puede circular, qué acciones puede ejecutar cada sistema, qué permisos necesita y qué dependencia crea respecto a terceros.
Por ese motivo, los riesgos de integrar sistemas no empiezan cuando aparece una vulnerabilidad técnica.
Empiezan mucho antes.
Empiezan en el momento en que una organización decide conectar aplicaciones sin preguntarse qué capacidad de actuación está entregando a cada una de ellas.
Modernizar una empresa no consiste únicamente en incorporar nuevas herramientas.
Precisamente por eso, antes de integrar nuevos sistemas conviene definir cómo automatizar procesos sin perder el control sobre ellos.
Como explicamos en nuestro artículo sobre cómo automatizar procesos sin perder el control, la automatización solo aporta valor cuando existe un modelo de gobierno que permita supervisarla.
También implica comprender cómo interactúan entre sí, qué responsabilidades genera cada conexión y cómo mantener el control cuando el ecosistema tecnológico deja de estar formado por aplicaciones independientes para convertirse en una red de decisiones automatizadas.
Precisamente ahí aparece una cuestión que suele pasar desapercibida.
La empresa no solo amplía su infraestructura tecnológica.
También amplía su superficie de confianza.
Implementar una nueva integración incorpora un sistema adicional capaz de acceder a información, ejecutar acciones, activar procesos o depender de otro proveedor para que el negocio continúe funcionando.
La pregunta ya no debería ser únicamente:
¿Qué información comparten nuestros sistemas?
La verdadera pregunta es mucho más estratégica:
¿Sabemos qué puede hacer cada sistema dentro de los demás?
Riesgos de integrar sistemas: qué cambia al conectar dos aplicaciones
Muchas organizaciones consideran una integración como una simple conexión técnica.
- Una API.
- Un conector.
- Un flujo automatizado.
- Un servicio de sincronización.
Sin embargo, desde una perspectiva de gobierno tecnológico, integrar dos aplicaciones significa mucho más que intercambiar información. Porque cada integración incorpora nuevas capacidades que antes no existían.
Aunque el usuario apenas perciba cambios, la organización acaba creando una nueva relación de confianza entre sistemas que puede mantenerse durante años.
Por ese motivo, conviene analizar cada integración como una decisión organizativa y no únicamente como una configuración informática.
Una integración crea un nuevo flujo de información
La primera consecuencia resulta evidente.
Los datos empiezan a desplazarse entre aplicaciones.
Sin embargo, rara vez permanecen donde el usuario cree.
Un dato puede viajar desde un formulario web hasta el CRM, pasar por una plataforma de automatización, enviarse a un servicio de inteligencia artificial, almacenarse en un gestor documental y terminar formando parte de un ERP.
Cuando alguno de esos sistemas incorpora inteligencia artificial, también resulta necesario conocer qué información se comparte y con qué finalidad. Es un aspecto que desarrollamos en ¿Controlas la información compartida con IA?
Por eso, cada uno de esos movimientos debería responder, al menos, a tres preguntas:
¿Qué información se intercambia?
¿Con qué finalidad?
¿Era realmente necesario compartir todos esos datos?
Este análisis conecta directamente con el principio de minimización de datos previsto en el artículo 5.1.c del RGPD, que exige tratar únicamente la información adecuada, pertinente y limitada a lo necesario para cada finalidad.
Una integración también crea nuevos permisos
Para intercambiar información, los sistemas necesitan identificarse.
Utilizan usuarios de servicio, claves, certificados, tokens o credenciales permanentes.
Esas credenciales no solo permiten consultar datos.
Con frecuencia también autorizan acciones.
Modificar registros.
Crear documentos.
Eliminar información.
Enviar comunicaciones.
Actualizar expedientes.
Conceder permisos.
Por tanto, cuando una empresa conecta dos aplicaciones, no solo comparte información.
También distribuye capacidad de actuación.
Y esa capacidad debe responder al principio de protección de datos desde el diseño y por defecto previsto en el artículo 25 del RGPD.
No basta con que la integración funcione.
Debe disponer únicamente de los permisos imprescindibles para cumplir su finalidad.
También aparece una nueva dependencia
Las automatizaciones que realizas en tus sistemas dependen de que todos los elementos implicados continúen funcionando.
- Si un proveedor cambia su API.
- Si una credencial caduca.
- Si una plataforma deja de responder.
- Si una automatización queda deshabilitada.
Todo el proceso puede detenerse o empezar a generar resultados incorrectos.
La empresa no depende únicamente de sus propios sistemas.
Empieza a depender del funcionamiento coordinado de múltiples proveedores externos.
Las integraciones también ejecutan acciones
Con frecuencia se piensa que una integración únicamente mueve datos.
No siempre es así.
Muchas conexiones pueden:
- crear usuarios;
- modificar permisos;
- enviar comunicaciones;
- generar facturas;
- bloquear cuentas;
- aprobar procesos;
- activar automatizaciones posteriores;
- iniciar nuevas decisiones.
Del mismo modo que no todas las decisiones deberían delegarse en una IA, tampoco todas las acciones deberían ejecutarse automáticamente sin supervisión. Ya analizamos este aspecto en Las decisiones que ninguna IA debería tomar por ti.
La organización necesita conocer exactamente qué capacidad de actuación posee cada conexión.
No basta con saber que existe.
Debe comprender qué puede hacer.
Finalmente, una integración exige evidencia
Cuando intervienen varios sistemas, también aumenta la dificultad para reconstruir lo sucedido.
Si aparece un error, una reclamación o un incidente, la empresa debería poder responder preguntas como estas:
- ¿Qué aplicación inició el proceso?
- ¿Qué sistema ejecutó cada acción?
- ¿Qué información se transmitió?
- ¿Qué credenciales se utilizaron?
- ¿Qué registros quedaron disponibles?
Sin esa información, la organización puede comprobar que el proceso ha funcionado.
Pero difícilmente podrá demostrar cómo lo hizo.
Y esa diferencia resulta esencial cuando hablamos de responsabilidad proactiva, diseño seguro y medidas técnicas y organizativas adecuadas conforme a los artículos 24 y 32 del RGPD.
Los riesgos de integrar sistemas no terminan en una brecha de seguridad
Cuando se habla de integraciones, muchas organizaciones piensan inmediatamente en ciberataques.
Es una preocupación razonable.
Sin embargo, reducir el análisis únicamente a las vulnerabilidades técnicas deja fuera la mayor parte del problema.
Los riesgos de integrar sistemas aparecen mucho antes de que exista una brecha de seguridad.
Surgen cuando la organización pierde visibilidad sobre cómo circula la información, quién puede actuar sobre ella y qué dependencias está incorporando a su funcionamiento diario.
Por ese motivo, conviene analizar las integraciones desde una perspectiva mucho más amplia que la puramente tecnológica.
Exposición progresiva de la información
Las nuevas conexiones pueden hacer que un mismo dato aparezca en más aplicaciones de las previstas inicialmente.
Un documento puede almacenarse simultáneamente en varias plataformas, un cliente puede quedar registrado en distintos sistemas y una misma información puede copiarse automáticamente en múltiples bases de datos.
Cuanto mayor sea el número de destinos, más difícil resulta conocer dónde permanece realmente la información y quién puede acceder a ella.
Exceso de permisos
Muchas integraciones solicitan permisos muy superiores a los estrictamente necesarios.
En ocasiones pueden consultar todos los contactos cuando únicamente necesitan acceder a uno.
O modificar registros completos cuando solo deberían leer determinada información.
En consecuencia, cualquier permiso innecesario amplía la superficie de confianza que la empresa deposita en esa integración.
Y esa confianza debería justificarse, limitarse y revisarse periódicamente.
Los riesgos de integrar sistemas no se limitan a posibles brechas de seguridad. Cada integración crea nuevos flujos de información, permisos técnicos, dependencias entre aplicaciones y responsabilidades que la empresa debe comprender, supervisar y poder revocar.
La exposición no siempre termina en una filtración
Cuando una integración distribuye la información entre varias aplicaciones, también aumenta la dificultad para mantener el control sobre todo su recorrido.
No porque cada proveedor sea inseguro.
Sino porque cada sistema incorpora nuevas reglas de funcionamiento, nuevos permisos y nuevas formas de tratar los datos.
Una integración puede funcionar correctamente durante años y, aun así, hacer que la empresa pierda visibilidad sobre dónde está realmente determinada información o qué aplicaciones continúan utilizándola.
Por eso, gobernar una integración también significa comprender todo el ciclo de vida del dato, desde que entra en la organización hasta que deja de ser necesario.
Acciones encadenadas
Uno de los aspectos menos visibles de una integración es su capacidad para desencadenar otras actuaciones.
Una única acción puede iniciar una cadena completa de procesos automáticos.
Por ejemplo:
un cliente actualiza sus datos;
el CRM modifica la ficha;
el ERP actualiza la información de facturación;
el sistema documental genera una nueva versión del expediente;
una plataforma de correo envía una notificación;
una herramienta de IA vuelve a analizar el caso.
Es una cadena en la que cada eslabón depende del anterior.
Si uno falla, el resto puede seguir ejecutándose con información incompleta, desactualizada o incorrecta.
En ocasiones, el problema no consiste en que falle un sistema.
Consiste en que el resto continúa funcionando como si nada hubiera ocurrido.
Por ese motivo, una integración también debe contemplar qué sucede cuando una parte del proceso deja de responder.
Credenciales persistentes
Muchas conexiones utilizan cuentas técnicas, claves API o tokens que permanecen activos durante largos periodos.
Estas credenciales suelen pasar desapercibidas porque ningún usuario trabaja directamente con ellas.
Sin embargo, representan uno de los elementos más importantes de cualquier integración.
Si continúan activas cuando ya no son necesarias, mantienen abierta una capacidad de acceso que la organización puede haber olvidado completamente.
La revisión periódica de estas credenciales forma parte de un modelo de gobierno mucho más amplio que la simple administración de usuarios.
También implica preguntarse:
¿Quién autorizó esta conexión?
¿Sigue siendo necesaria?
¿Conserva más permisos de los imprescindibles?
¿Podría revocarse hoy sin afectar al negocio?
Integraciones olvidadas
Es habitual que una empresa conecte aplicaciones para resolver una necesidad concreta.
- Un proyecto temporal.
- Un proveedor específico.
- Un empleado.
- Una campaña.
Con el paso del tiempo, aquella necesidad desaparece.
La integración permanece.
Nadie recuerda exactamente por qué sigue activa.
Ni qué información continúa intercambiando.
Ni si todavía interviene en algún proceso crítico.
Estas conexiones «heredadas» suelen convertirse en uno de los mayores puntos ciegos de una organización.
No porque funcionen mal.
Sino porque nadie las supervisa.
Dependencia de terceros
Con cada integración surge una nueva relación de dependencia.
Aunque el proceso parezca interno, es posible que intervengan plataformas de automatización, servicios cloud, proveedores de inteligencia artificial o aplicaciones especializadas.
La empresa no controla directamente su disponibilidad, sus cambios de funcionamiento ni su evolución técnica.
Sin embargo, continúa siendo responsable del proceso empresarial que depende de ellas.
Por eso, conectar un nuevo proveedor nunca debería entenderse únicamente como una decisión tecnológica.
También es una decisión organizativa sobre continuidad, supervisión y responsabilidad.
Falta de trazabilidad
Cuando varias aplicaciones participan en un mismo proceso, reconstruir posteriormente qué ocurrió puede resultar mucho más complejo de lo esperado.
Especialmente cuando cada plataforma conserva registros diferentes o durante periodos distintos.
Una organización debería poder responder preguntas como estas:
- ¿Qué sistema ejecutó esta acción?
- ¿Qué información utilizó?
- ¿Cuándo ocurrió?
- ¿Qué aplicación inició el proceso?
- ¿Quién autorizó la integración?
- ¿Qué proveedor intervino?
Sin esa capacidad de reconstrucción resulta difícil analizar errores, atender incidencias o demostrar cómo se desarrolló realmente el proceso.
Dificultad para desconectar una integración
Existe un riesgo del que apenas se habla durante los proyectos de automatización.
Todo el mundo planifica cómo conectar aplicaciones.
Muy pocos planifican cómo dejarán de estar conectadas.
Y, sin embargo, tarde o temprano cualquier organización cambia de proveedor, sustituye herramientas o modifica sus procesos.
Cuando ese momento llega, muchas empresas descubren que nadie sabe exactamente qué consecuencias tendrá eliminar una determinada conexión.
Ese es uno de los principales indicadores de una integración que nunca llegó a gobernarse realmente.
Riesgos de integrar sistemas: la pregunta que casi nadie se hace
Cuando una organización decide conectar dos aplicaciones, suele dedicar mucho tiempo a definir cómo funcionará el proceso.
Qué información circulará.
Qué automatizaciones se ejecutarán.
Qué resultados esperan obtener.
Sin embargo, existe una pregunta que rara vez aparece durante la fase de diseño.
¿Cómo se deshace esta integración?
La mayoría de los proyectos nacen pensando en el funcionamiento.
Muy pocos piensan en la salida.
Y esa ausencia puede convertirse en un problema cuando cambian las necesidades del negocio, se sustituye un proveedor o simplemente deja de tener sentido mantener una determinada conexión.
Diseñar una integración también implica diseñar su reversibilidad.
No basta con saber cómo crearla.
La organización debería poder retirarla sin perder el control sobre el proceso.
La reversibilidad también forma parte del gobierno tecnológico
Una integración madura no solo automatiza correctamente.
También puede desactivarse de forma controlada.
Eso exige responder, al menos, a varias cuestiones antes de ponerla en funcionamiento.
- ¿Qué ocurre con las credenciales cuando deja de utilizarse?
- ¿Cómo se revocan los permisos concedidos?
- ¿Qué sucede con la información ya compartida?
- ¿Existen copias adicionales?
- ¿Qué procesos dejarán de funcionar?
- ¿Quién comprobará que la desconexión ha sido efectiva?
- ¿Cómo se garantizará la continuidad del negocio?
Estas preguntas no pretenden frenar la modernización.
Al contrario.
Permiten modernizar con mayor control y reducir la dependencia tecnológica futura.
Una integración también necesita un plan de salida
Muchas organizaciones elaboran procedimientos para implantar nuevas herramientas.
Muy pocas documentan cómo abandonarlas.
Sin embargo, cambiar de proveedor forma parte del ciclo de vida normal de cualquier sistema.
La organización debería conocer:
- cómo recuperar la información;
- cómo eliminar las conexiones existentes;
- cómo revocar las credenciales técnicas;
- cómo sustituir la automatización sin interrumpir el servicio;
- y cómo verificar que ningún flujo continúa operativo una vez finalizado el proceso.
Planificar esta salida no supone desconfiar de la tecnología.
Supone conservar la capacidad de decidir cuándo una integración deja de formar parte del negocio.
En otras palabras, una integración bien gobernada no es únicamente la que funciona.
Es aquella que la empresa puede comprender, supervisar… y retirar cuando resulte necesario.
Qué debe conocer la dirección sobre los riesgos de integrar sistemas
No todas las organizaciones necesitan comprender el funcionamiento técnico de una API.
Pero sí necesitan conocer las implicaciones que genera cada conexión para el negocio.
La dirección no debería limitarse a saber que dos aplicaciones están conectadas.
Debería poder respoPorque aceptar una integración también implica aceptar un determinado nivel de riesgo. Y esa decisión siempre debe formar parte del gobierno de la organización, tal y como explicábamos en Quién ha decidido cuánto riesgo puede asumir tu empresa.
nder un conjunto mínimo de preguntas que permitan demostrar que esa integración continúa bajo control.
En YWEN proponemos un marco práctico de revisión basado en ocho preguntas.
Antes de mantener o implantar una integración, la organización debería ser capaz de responderlas con claridad.
¿Qué sistemas conecta?
Identificar las aplicaciones implicadas es el primer paso para comprender el alcance real del proceso.
¿Qué información intercambia?
No basta con afirmar que comparte datos.
Debe conocerse exactamente qué categorías de información circulan entre los sistemas y con qué finalidad.
¿Qué acciones puede ejecutar?
Una integración puede limitarse a consultar información.
O puede modificar registros, crear documentos, conceder permisos, enviar comunicaciones o iniciar nuevos procesos.
La diferencia resulta esencial desde el punto de vista del gobierno tecnológico.
¿Con qué identidad o credencial actúa?
Cada integración utiliza algún mecanismo de autenticación.
La organización debería conocer qué cuenta utiliza, qué permisos posee y quién es responsable de revisarlos.
¿Qué proveedor participa?
Muchas automatizaciones incorporan plataformas de terceros.
La empresa necesita identificar qué papel desempeña cada proveedor y qué responsabilidades asume dentro del proceso.
¿Qué evidencia genera?
Para que una integración gobernada deje trazabilidad, debe existir información suficiente para reconstruir qué ocurrió cuando resulte necesario.
¿Qué sucede si falla?
Todo proceso necesita contemplar escenarios de error.
¿Qué ocurre si uno de los sistemas deja de responder?
¿Existe continuidad?
¿Se genera una alerta?
¿Puede recuperarse el proceso?
¿Cómo puede revocarse o sustituirse?
Finalmente, la organización debería poder retirar esa integración sin perder el control del proceso ni dejar conexiones activas que ya no respondan a una necesidad real.
Este conjunto de preguntas no pretende convertir a la dirección en especialista técnico.
Su objetivo es mucho más sencillo.
Asegurar que cada integración continúa siendo una decisión consciente y supervisada, y no una configuración heredada que nadie recuerda cómo funciona.
Integrar también implica supervisar al proveedor
Cuando una empresa conecta una nueva aplicación suele pensar en las funcionalidades que incorpora.
Automatizar tareas.
Ahorrar tiempo.
Eliminar trabajos repetitivos.
Mejorar la coordinación entre departamentos.
Sin embargo, cada integración también puede incorporar un nuevo proveedor dentro del proceso.
Y con él aparecen nuevas responsabilidades que no siempre resultan evidentes.
La organización puede seguir siendo la misma.
Los datos también.
Pero la forma en que esos datos se utilizan, circulan o permanecen disponibles puede cambiar de manera significativa.
Por ese motivo, una integración nunca debería analizarse únicamente desde la perspectiva tecnológica.
También debe evaluarse desde el punto de vista del cumplimiento, la responsabilidad y el gobierno de los proveedores implicados.
No todos los proveedores desempeñan el mismo papel
Algunas aplicaciones únicamente facilitan una comunicación entre sistemas, otras almacenan información, algunas procesan datos por cuenta de la organización y otras incorporan sus propios subproveedores para prestar el servicio,
Pero cada situación requiere un análisis diferente.
No toda integración implica necesariamente un nuevo encargado del tratamiento ni una transferencia internacional de datos.
Debe estudiarse caso por caso.
Lo importante es que la empresa conozca quién interviene realmente en el proceso y qué responsabilidades asume cada participante.
Esta necesidad conecta con el principio de responsabilidad proactiva previsto en el artículo 24 del RGPD y, cuando exista un tratamiento por cuenta de terceros, con las garantías exigidas por el artículo 28.
La integración también modifica el ecosistema de confianza
Un nuevo proveedor puede incorporar elementos que la organización necesita conocer.
Por ejemplo:
- nuevas ubicaciones desde las que se presta el servicio;
- subencargados que participan en la prestación;
- condiciones de conservación de la información;
- mecanismos de eliminación de datos;
- medidas técnicas y organizativas aplicadas;
- procedimientos de notificación ante incidentes;
- cambios en las condiciones del servicio.
No se trata de desconfiar sistemáticamente del proveedor.
Se trata de comprender cómo afecta esa integración al funcionamiento global de la empresa.
Porque, aunque determinadas tareas se deleguen técnicamente, la responsabilidad de gobernarlas continúa perteneciendo a la organización.
Configurar una integración no significa gobernarla
Es habitual que la empresa considere que el trabajo termina cuando el proveedor deja funcionando la automatización.
Sin embargo, la configuración técnica solo representa el comienzo.
A partir de ese momento la organización debería poder responder preguntas como estas:
- ¿La integración sigue siendo necesaria?
- ¿Continúa utilizando únicamente los permisos imprescindibles?
- ¿Ha cambiado el proveedor sus condiciones?
- ¿Se han incorporado nuevos servicios o subprocesadores?
- ¿Sigue existiendo un responsable interno que supervise esta conexión?
Gobernar una integración significa revisar periódicamente que las condiciones bajo las que fue aprobada continúan siendo válidas.
No basta con que siga funcionando.
Debe seguir siendo adecuada para el riesgo que la organización está dispuesta a asumir.
Evidencias mínimas de una integración gobernada
Muchas organizaciones disponen de decenas de conexiones entre aplicaciones.
Sin embargo, cuando necesitan revisarlas, descubren que apenas existe documentación sobre ellas.
La integración funciona.
Pero nadie puede explicar con precisión cómo se aprobó, qué permisos utiliza o quién continúa supervisándola.
Una integración gobernada debería dejar evidencia suficiente para demostrar que la organización mantiene el control sobre ella.
No hace falta generar documentación innecesaria.
Sí conviene conservar la información que permita comprender, revisar y justificar cada conexión.
Información mínima que debería documentarse
Como mínimo, resulta recomendable disponer de un inventario que incluya:
- sistemas que participan en la integración;
- finalidad de la conexión;
- responsable interno del proceso;
- categorías de datos que se intercambian;
- acciones que la integración puede ejecutar;
- permisos y credenciales utilizadas;
- proveedor o proveedores implicados;
- acuerdos o contratos aplicables, cuando procedan;
- fecha de implantación y de la última revisión;
- registros disponibles para reconstruir la actividad;
- procedimiento para revocar la integración;
- comprobación de que la desconexión puede realizarse correctamente;
- impacto sobre la continuidad operativa en caso de fallo.
Este inventario no pretende convertirse en un ejercicio administrativo.
Su objetivo es mucho más práctico.
Permitir que la organización comprenda qué conexiones existen, por qué siguen siendo necesarias y qué ocurriría si alguna dejara de funcionar.
Solo así puede mantenerse un control real sobre un ecosistema tecnológico que evoluciona constantemente.
Gobernar las integraciones es mantener el control
Las integraciones forman parte de cualquier proceso de modernización.
Permiten automatizar tareas, conectar aplicaciones y reducir trabajos repetitivos.
Pero también amplían el número de sistemas que participan en las decisiones de la empresa, aumentan las dependencias entre proveedores y multiplican los puntos desde los que puede iniciarse una acción.
Por eso, los riesgos de integrar sistemas no deberían analizarse únicamente desde la perspectiva de la ciberseguridad.
También afectan al gobierno tecnológico, a la supervisión, a la continuidad operativa y a la capacidad de demostrar que la organización mantiene el control sobre sus procesos.
Una integración segura no es la que simplemente funciona.
Es aquella que la empresa comprende, documenta, supervisa y puede modificar o retirar cuando resulte necesario.
Conectar aplicaciones puede mejorar la eficiencia.
Gobernar esas conexiones es lo que permite modernizar sin perder el control.
Además de implantar medidas de gobierno, conviene consultar las recomendaciones prácticas publicadas por INCIBE para fortalecer la seguridad y la resiliencia de las organizaciones.
¿Dispones de un mapa actualizado de todos los sistemas conectados en tu empresa, los datos que intercambian, los permisos que utilizan y las acciones que pueden ejecutar?
Responder a esa pregunta suele ser el primer paso para descubrir si las integraciones forman parte de una estrategia de modernización… o simplemente han ido creciendo con el tiempo.
Los principales riesgos de integrar sistemas incluyen la pérdida de visibilidad sobre los flujos de información, el exceso de permisos, las dependencias entre aplicaciones, la falta de trazabilidad, las credenciales persistentes y la dificultad para retirar una integración sin afectar a la continuidad del negocio.
No. Integrar sistemas no supone por sí mismo un incumplimiento del RGPD. Lo importante es analizar cada integración para garantizar que el tratamiento de los datos sea adecuado, que existan medidas de seguridad proporcionales al riesgo y que se cumplan las obligaciones aplicables en cada caso.
Porque las aplicaciones evolucionan, cambian sus permisos, incorporan nuevas funcionalidades o modifican las condiciones del servicio. Una integración que era adecuada cuando se implantó puede dejar de serlo si nadie revisa cómo continúa funcionando.
Como mínimo, conviene mantener un inventario que identifique los sistemas conectados, la finalidad de la integración, los datos intercambiados, los permisos utilizados, los proveedores implicados, el responsable interno, los registros disponibles y el procedimiento para revocar la conexión.
