Validación de Sistemas SaaS (en la nube) _ Preguntas frecuentes

Las organizaciones están cambiando desde un modo de trabajo en el que, las instalaciones, servidores, datos y softwares están gestionados y CONTROLADOS internamente (On Premise), a una “informática en la nube”, que permite poder alquilar y utilizar recursos virtualizados en la nube contribuyendo a una mayor flexibilidad; permitiendo también descongestionar los esfuerzos necesarios de los departamentos de informática en todos los procesos de instalación y actualización.

Por supuesto que, con la gestión interna de los sistemas, la impresión es que se gana en control de lo que dispones y de cómo está gestionado, y en un sector como el farmacéutico y otros sectores altamente regulados, es una ventaja… creemos estar seguros de todo lo que concierne a nuestro sistema.

Pero la tendencia a los entornos sin papel, con acceso y creación de los datos desde diferentes localizaciones de una misma empresa y la necesidad de actualizar los sistemas sin que el coste sea exorbitante, ha impulsado que, por una parte, se tienda a utilizar sistemas COTS (sin tantas personalizaciones o customizaciones), y se gestionen total o parcialmente, desde la nube.

Que los sistemas estén parcialmente contratados a proveedores externos no nos exime de la responsabilidad sobre la seguridad, veracidad y fiabilidad del sistema como si estuviera instalado localmente. Debe prevalecer el principio de corresponsabilidad según la cual el proveedor y el cliente se ocupan de tareas diferentes y que están previamente definidas en un acuerdo entre ambos.

Para la validación de un sistema SaaS se deben sustituir las pruebas y documentación que se generaría localmente por acuerdos y auditorías a los proveedores del servicio.

Durante la formación Consejos en Validación de Sistemas SaaS (en la nube) realizada el pasado 14 de Mayo, surgieron muchas preguntas y la gran mayoría respecto a 3 temas fundamentales a considerar cuando se planea implementar un sistema SaaS en un entorno GxP:

·     Estrategia de validación

Desde la opción local (On Premise) hasta la opción SaaS, parte de los servicios y herramientas los suministra el proveedor del servicio en la nube. Esto implica que la estrategia de validación variará según el modelo que estemos utilizando.

En un sistema SaaS, desde la instalación hasta los test de funcionalidad los realiza el proveedor, y los test de aceptación del usuario (PQ o UAT) los ejecuta el cliente.

El cliente solamente deberá realizar verificaciones de instalación (IQ) y funcionalidad (OQ) en caso de que se trate de un sistema híbrido donde parte de instalación sea local, o existan funcionalidades específicas para el cliente (ej. Interfases con otros sistemas).

Aunque se trate de un sistema “VALIDADO” por el proveedor, se deben realizar los test de PQ para verificar que cumplen con las URS y son adecuados para los procesos que para los que ha sido requerido.

El proveedor debe suministrar al cliente la documentación de aquellas etapas de validación que haya realizado.

·     Evaluación del proveedor (seguridad y privacidad de los datos)

Una de las áreas clave en la validación en entornos Cloud es la evaluación de los proveedores para poder determinar la capacidad del proveedor para cumplir con los controles necesarios para garantizar la seguridad, la integridad de los datos, el cumplimiento de los procedimientos del cliente y las exigencias reglamentarias.

Esta evaluación, debería hacerse ANTES de contratar los servicios del proveedor, para evitar sorpresas no deseadas.

El nivel de evaluación dependerá del servicio que se contrate y del grado de cumplimiento requerido, según la evaluación del riesgo efectuada.

Se suele realizar en 3 pasos:

  • Revisión de la información del proveedor para conocer si ya trabajan con otros clientes de industrias reguladas y saber si su infraestructura está cualificada para proporcionar un servicio compatible con GxP.
  • Evaluación y auditoría (presencial o enviando un cuestionario): para determinar el grado de cumplimiento del proveedor. Se deben considerar los siguientes puntos:
    • Metodología de Desarrollo del software y su documentación
    • Cualificación y formación del personal
    • Sistema de gestión de calidad: procedimientos, sistema de gestión y aprobación
    • Cualificación de la infraestructura informática
    • Copias de seguridad, planes de contingencia
    • Gestión de cambios, Audit trail e incidencias  
    • Dónde residen físicamente los servidores, seguridad del centro de datos físico, cifrado y administración de claves
    • Cualificación de la infraestructura
    • Seguridad lógica de los sistemas y datos
    • Cumplimiento de 21CFR part 11 o equivalente para registros electrónicos y firma electrónica

Si el proveedor tiene certificaciones reconocidas en vigor (ISO, SOC,…) parte de esta información se puede extraer de los certificados.

  • Generar un acuerdo de servicio (SLA, por sus siglas en inglés): compromiso entre el proveedor del servicio y la empresa, que debe cubrir al menos:
    • Descripción de las responsabilidades del cliente y del proveedor
    • Disponibilidad y rendimiento
    • Gestión e informes de incidencias y gestión de cambios
    • Calidad y garantía del servicio
    • Copias de seguridad y restauración de datos (procedimiento, frecuencia)
    • Cualificación y formación del personal
    • Soporte y mantenimiento

De acuerdo con las responsabilidades definidas en el SLA, el proveedor de servicios es responsable de la administración del entorno de alojamiento, su seguridad y su mantenimiento. Como tal, debe proporcionar al cliente los procedimientos y documentación que rija estas actividades, como:

  • Política de Seguridad
  • Plan de continuidad de negocio
  • Procedimiento de copia de seguridad y restauración
  • Procedimiento de gestión de cambios

De la evaluación del proveedor y posterior contrato, se debe sacar una idea clara del proceso, metodología y servicios ofrecidos por éste, asegurándonos que, cumplen con los requisitos de seguridad y privacidad.

·     Estrategia de actualización

El ritmo de las actualizaciones viene marcado por el proveedor, y no se puede adaptar a las necesidades de cada momento del cliente.

El proveedor proporcionará un calendario de actualizaciones y una vez anunciados los cambios y nuevas funcionalidades disponibles en la nueva versión:

  • El cliente debe preparar el Análisis del Impacto, involucrando a los diferentes roles de la compañía que se verán afectados
  • Solicitar clarificaciones al proveedor si hace falta
  • Construir un plan de acción y ejecutarlo para que en la fecha anunciada se hayan creado/revisado los documentos de validación afectados, procedimientos, formaciones y se hayan realizado las pruebas definidas en el plan
  • Toda la documentación creada/modificada se deberá aprobar antes de la implementación de la actualización del sistema.
QBD Important newsflash

¡INSCRÍBETE PARA RECIBIR NUESTRO BOLETÍN TRIMESTRAL!

Reciba más información sobre los servicios del grupo QbD, nuestros hitos, nuestra ruta pionera en ATMP y productos sanitarios, ¡y mucho más!

¡No te perdas nada y regístrate ahora!

  • Este campo es un campo de validación y debe quedar sin cambios.