Calificacion-de-software-y-registros-electronicos

Vista previa del material en texto

1 
 
 
 
 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
FACULTAD DE QUÍMICA 
 
CALIFICACIÓN DE SOFTWARE Y REGISTROS ELECTRÓNICOS 
 
 
 
TESIS PARA OBTENER EL TÍTULO DE 
 
QUÍMICO FARMACÉUTICO BIÓLOGO 
 
 
 
PRESENTA 
VÍCTOR MANUEL MIRANDA VILLAGÓMEZ 
 
 
 
 
 
 
 
 
 
 
 
 
 MÉXICO, D.F. AÑO 2014 
 
 
 
 
 
 
 
 
 
UNAM – Dirección General de Bibliotecas 
Tesis Digitales 
Restricciones de uso 
 
DERECHOS RESERVADOS © 
PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL 
 
Todo el material contenido en esta tesis esta protegido por la Ley Federal 
del Derecho de Autor (LFDA) de los Estados Unidos Mexicanos (México). 
El uso de imágenes, fragmentos de videos, y demás material que sea 
objeto de protección de los derechos de autor, será exclusivamente para 
fines educativos e informativos y deberá citar la fuente donde la obtuvo 
mencionando el autor o autores. Cualquier uso distinto como el lucro, 
reproducción, edición o modificación, será perseguido y sancionado por el 
respectivo titular de los Derechos de Autor. 
 
 
 
2 
 
 
 
JURADO ASIGNADO: 
 
PRESIDENTE: Profesor: Socorro Alpizar Ramos 
VOCAL: Profesor: Tania Campos González 
SECRETARIO: Profesor: Maria Eugenia Ivette Gómez Sánchez 
1er. SUPLENTE: Profesor: Raúl Lugo Villegas 
2° SUPLENTE: Profesor: Ivan Alejandro Franco Morales 
 
 
SITIO DONDE SE DESARROLLÓ EL TEMA: 
 
 
ASESOR DEL TEMA: SOCORRO ALPIZAR RAMOS 
(nombre y firma) 
SUPERVISOR TÉCNICO (Si lo hay): N/A 
(nombre y firma) 
SUSTENTANTE (S): VÍCTOR MANUEL MIRANDA VILLAGÓMEZ 
(nombre (s) y firma (s) ) 
 
 
 
 
 
 
 
 
 
 
 
 
3 
 
 
 
 
 
 
Esta Tesis es dedicada a mis padres, mi esposa e hijos por 
apoyarme en todo momento y un agradecimiento especial a mi 
asesora de este trabajo y demás profesores de los que siempre 
aprendí y que siempre obtuve apoyo en todo momento. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4 
 
CaLIFICACIÓN DE SOFTWARE Y REGISTROS ELECTRÓNICOS 
 
 
 
INDICE 
 
1. OBJETIVO, INTRODUCCIÓN Y CONCEPTOS…………………….……7 
 1.1 OBJETIVO GENERAL…………………….………………………….….8 
 1.2 OBJETIVOS ESPECIFICOS………..……………………...…………..8 
 1.3 INTRODUCCIÓN……..……………………………………….…….......8 
 1.4 CONCEPTOS…………………………..…………………………..…….8 
 
2. CALIFICACIÓN DE SOFTWARE Y REGISTROS ELECTRÓNICOS…12 
2.1 CALIFICACIÓN DE DISEÑO……………………...…….……….…..…14 
2.2 CALIFICACIÓN DE INSTALACIÓN…………………………………….15 
2.3 CALIFICACIÓN DE OPERACIÓN…………………………....……..…18 
2.4 CALIFICACIÓN DE DESEMPEÑO…………………………………….21 
 
3. CONTROL DE CAMBIOS....................................................................23 
 3.1 TIPOS DE CAMBIO………………………………………..……………24 
 
4. PLAN MAESTRO DE VALIDACIÓN…………………………………...…29. 
4.1 OBJETIVO……………………………….....……….………………...….31 
4.2 ALCANCE……………………………….……………………………..…31 
4.3 ESTRUCTURA ORGANIZACIONAL…………………….……….……32 
4.4 ESTRATEGIA DE VALIDACIÓN…………..……………………….…..33 
4.5 ESTRATEGIA DE PRIORITIZACIÓN…………….………..….…..…..37 
 
 
 
 
PÁGINA 
 
 
 
5 
 
5. EJEMPLO DE CALIFICACIÓN E INSTALACIÓN DE SISTEMAS DE CÓMPUTO…46 
5.1 INTRODUCCIÓN…………….……………………………..……………47 
5.2 CALIFICACIÓN DE INSTALACIÓN……………..…………...……….139 
5.3 CALIFICACIÓN DE OPERACIÓN……………………………....……197 
5.4 CALIFICACIÓN DE DESEMPEÑO...……….…………………..….…283 
 
6. REFERENCIAS………………………………...……………………..……293 
 
7. CONCLUSIONES……..……………………………..………..……..……..293 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
6 
 
 
PROPÓSITO DE LA PRESENTE TÉSIS 
 
El propósito de este documento es transmitir un enfoque de validación de software el cual 
permita entender los requerimientos normativos nacionales (NOM059-SSA1-2013) e 
internacionales por ejemplo CFR21 parte 11 el cual permita asegurar el buen 
funcionamiento de los sistemas de cómputo. Además lograr identificar las diferencias sobre 
aquellos que no tengan impacto regulatorio o BPF Buenas Prácticas de Fabricación, no 
están limitados a que se verifiquen estos tipos de sistemas los cuales aunque no impacten 
directa o indirectamente al producto, si pueda tener impacto en el negocio o en la seguridad, 
en la planeación de proyectos etc. 
 
A manera de ejemplo, se incluye la calificación de software de un medidor de TOC (Carbono 
Orgánico Total) en el cual se verifica: Calificación de Instalación de software en el cual se 
verifica de que el software instalado sea de acuerdo a lo especificado por él fabricante y 
Calificación de Operación de Software en el cual se verifica la operación del sistema de 
acuerdo a sus funciones, su control de acceso, su seguridad etc. 
 
Las áreas con las que validación de sistemas de software que pueden estar directamente 
relacionadas son las siguientes: Gerencia, Unidad de Calidad, Investigación, Desarrollo, 
Transferencias de tecnología, Manufactura, Ingeniería, Tecnología de la información y Otras 
áreas de soporte 
 
 
 
 
 
 
 
 
 
7 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 CAPITULO 1 OBJETIVO, INTRODUCCIÓN Y CONCEPTOS 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
8 
 
 
1.1 OBJETIVO GENERAL 
 
Revisar los requerimientos, nacionales (NOM059-SSA1-2013) e internacionales (CFR21 
parte 11, Internacional Conferencia de Armonización por sus siglas en inglés [ICH Q7], guía 
ISPE GAMP 5 en base a riesgo para el cumplimiento de Software) para la calificación de 
software y registros electrónicos. 
 
1.2 OBJETIVOS ESPECÍFICOS 
 
Proponer una metodología para la calificación de software y validación de registros 
electrónicos aplicando esta metodología de calificación a un equipo controlado por software 
dentro de la industria farmacéutica en base a la regulación NOM-059-SSA1-2013, a las guías 
ISPE y CFR 21 parte 11. 
Indicar que debe de ser incluido dentro de la estructura de un plan maestro de validación, la 
calificación de software y registros electrónicos con impacto a BPX´s 
 
1.3 INTRODUCCIÓN 
 
La industria farmacéutica está respondiendo actualmente a cambios de significante mejora 
para el desarrollo y manufactura. 
 
Nuevos conceptos están siendo desarrollados y aplicados en el manejo del riesgo enfocado 
esencialmente en el entendimiento del proceso/producto desde el punto de vista científico, la 
aplicación de conceptos basados en diseño, “seguridad del paciente, potencia, calidad del 
producto e integridad” cobra cada vez más relevancia en: 
 
Sistemas de software. 
 
Hardware 
 
9 
 
Hojas de cálculo 
 
Niveles de acceso 
 
El objetivo principal de la Validación es identificar los parámetros críticos y establecer rangos 
de operación aceptables, para identificar y minimizar las fuentes de variación, en un área, 
equipo, sistema crítico, sistema computarizado /automatizado o proceso. Al minimizar la 
variabilidad se proporciona un alto grado de seguridad de que un producto cumpla sus 
especificaciones de Calidad de forma consistente y reproducible para lo cual fue diseñado. 
 
A continuación se da la definición de conceptos generales sobre las frases de calificación que 
aplican de igual forma a calificación de software: 
 
 
1.4 CONCEPTOS 
Tabla 1 
Buenas Prácticas 
de Fabricación BPF 
(1) 
Al conjunto de lineamientos y actividades relacionadas entre sí, 
destinadas a asegurar que los medicamentos elaborados tengan y 
mantengan las características de identidad, pureza, seguridad, 
eficacia y calidad requeridas para su uso. 
BPX´s 
Buenas prácticas en conjunto que incluyen: Buenas prácticas de 
documentación, buenas prácticas de laboratorio, buenas prácticas de 
ingeniería, buenas prácticas de almacén entre otras. 
Calificación del 
Diseño (2). 
Revisión estructurada durante los proyectos de ingeniería; del diseño 
de las instalaciones, sistemas críticos y equipos acorde a los 
requerimientos y especificaciones de usuario y de las Buenas 
Prácticas de FabricaciónBPF’s. Con la finalidad de revelar problemas 
de diseño ó de especificación en las primeras etapas de los proyectos 
y anticiparse a potenciales atrasos y gastos durante las etapas de 
10 
 
Calificación (Instalación, Operación y Desempeño).Verificación 
documentada de que el diseño propuesto de las instalaciones, 
sistemas y equipo es conveniente para el propósito proyectado 
 
Calificación del 
Desempeño(2) 
Evidencia documentada que provee un alto grado de seguridad de 
que todos los aspectos de un equipo, sistema o área que puede 
afectar la calidad del producto se desempeñan como se espera 
cumpliendo con el criterio de aceptación establecido. 
 
Calificación de 
Instalación(2) 
 
Evidencia documentada que provee un alto grado de seguridad de 
que todos los aspectos de un equipo, sistema, instalación o área que 
puede afectar la calidad del producto, está correctamente instalado y 
se apegan a las especificaciones aprobadas del fabricante y 
requisitos internos de la planta. 
Etapa de 
Comisionamiento(2) 
Metodología bien planeada, documentada y administrada por 
Ingeniería, por mantenimiento, por producción y otras áreas para el 
arranque y entrega de instalaciones, sistemas y equipos al Usuario 
Final, resultando en una entrega segura y funcional que cumpla con 
los requerimientos de diseño establecidos y las expectativas de los 
usuarios; sin embargo, se puede llevar y administrar por otras áreas 
como producción, mantenimiento, planeación etc . 
Definición de Sistemas de Impacto hacia la calidad del producto 
como; Directo, Indirecto, y No Impacto. 
 
Calificación de la 
Operación(2) 
Evidencia documentada que provee un alto grado de seguridad de 
que todos los aspectos de un equipo, sistema, instalación o área que 
pueden afectar la calidad del producto operan como se espera dentro 
de los rangos anticipados y previamente determinados. 
Firma electrónica 
(1) 
A la compilación de datos computacionales o cualquier símbolo o 
serie de símbolos, ejecutados, adoptados, o autorizados por un 
11 
 
individuo para ser legalmente adjuntados y equivalentes a la firma 
manuscrita del individuo. 
 
Validación (1) Es definida como la acción de proveer evidencia documentada de 
acuerdo con los principios de Buenas Prácticas de Manufactura que 
conduzca a los resultados esperados para cualquier procedimiento, 
proceso, equipo, material, actividad o sistema. 
 
Registros 
electrónicos (1) 
Al conjunto de información que incluye datos electrónicos (texto, 
numérico, gráfico) que es creado, modificado, mantenido, archivado, 
restaurado o transmitido a través de un sistema computarizado 
 
 
(1) NOM059-SSA-1-2013 Buenas prácticas de fabricación para establecimientos de la 
industria químico farmacéutica dedicados a la fabricación de medicamentos 
(2) -Guias ISPE GAMP 5 A Risk- Based Approach to compliant GxP Computarized Systems 
2008 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
12 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
CAPITULO 2 CALIFICACIÓN DE SOFTWARE Y REGISTROS ELECTRÓNICOS 
 
 
 
 
 
 
 
 
 
 
 
 
 
13 
 
 
 
CALIFICACIÓN DE SOFTWARE Y REGISTROS ELECTRÓNICOS 
 
 
El comisionamiento “comissioning” (inglés) de pruebas de calificación tiene base en las BPI 
(Buenas Prácticas de Ingeniería), donde parte de los entregables son pruebas hechas por el 
proveedor o cualquier otra área de soporte como mantenimiento, proyectos, TI, etc. Las 
pruebas pueden ser de arranque, pruebas FAT, pruebas SAT, pruebas de instalación, de 
operación, de desempeño o de cualquier otro tipo, por medio de las cuales se asegura el 
correcto funcionamiento del equipo. Muchas de estas pruebas se repiten en la calificación del 
equipo, lo cual implica una mayor inversión de tiempo y recursos sin embargo son necesarias 
para el aseguramiento de la puesta en marcha sin contratiempos y cumplimiento. 
 
Para lograr lo anterior es necesario que se documenten las pruebas comisionadas, 
generando evidencia documental de las actividades realizadas y los resultados obtenidos, las 
cuales deben ser aprobadas por el dueño del equipo, validación y aseguramiento de la 
calidad, dándoles un carácter BPF. 
La ejecución de las pruebas comisionadas debe anexarse a los protocolos de calificación 
correspondientes, así mismo en los protocolos debe hacerse referencia a las pruebas 
comisionadas conservando la trazabilidad entre pruebas y documentos. 
 
En el siguiente diagrama se ilustra como las pruebas de comisionamiento pueden formar 
parte de la calificación de los equipos. 
14 
 
 
 
Un sistema computarizado, consiste de hardware y/o software; los cuales pueden ser 
administrados en cuanto al cumplimiento de BPF ayudados de algunos sistemas de calidad 
de la empresa como controles de cambio, sistema de administración de desviaciones etc. 
 
 2.1 CALIFICACIÓN DE DISEÑO (“Performance Qualification” por sus siglas en inglés) 
 
Un adecuado manejo del proceso de la configuración debe ser claramente establecida como 
es: el sistema computarizado y todos los componentes deben ser identificados y definidos en 
este punto. 
 
El procedimiento de manejo del cambio debe ser establecido. Un apropiado manejo del 
cambio en conjunto con un sistema robusto de proyecto con sus respectivas fases de 
implantación del cambio. 
Requerimientos 
de Usuario 
(Qué se requiere) 
 
Especificación Funcional 
(Funcionamiento requerido) 
 
Especificación de 
Diseño 
(Cómo se hará) 
 
Calificación de Instalación 
Calificación de Operación 
 
Calificación de Desempeño 
 
 
Implementación o Instalación 
Pruebas de desempeño 
de proveedor 
 
Puesta en marcha y pruebas 
de ajuste, FAT, SAT, 
Pruebas de operación de 
Proveedor 
 
Inspección física preliminar, 
Pruebas de instalación de 
Proveedor, P&DI 
 
OQ 
IQ 
 
 
 
Análisis de 
Riesgo de 
Funciones 
(Identificació
n de riesgos) 
 
15 
 
 
Antes de ser establecido el desarrollo del protocolo de Diseño, se debe tener una VOC (Voz 
del Cliente) a raíz de la cual se establecen los Requerimientos de Usuario y posteriormente 
Especificaciones Funcionales. Una vez obtenido lo anterior se procede con el Diseño y su 
respectiva Calificación. 
 
 
 2.2 CALIFICACIÓN DE INSTALACIÓN (Instalation Qualification) 
 
El Protocolo de Calificación de Instalación verifica la instalación del hardware, software de 
aplicación y de sistema, y el equipo asociado (como impresoras, lectores de código de 
barras, etc.) de acuerdo a especificaciones. La Calificación de Instalación ejecuta pruebas 
relacionadas con los riesgos identificados en el Análisis de Riesgo. 
 
La Calificación de Instalación confirma que: 
El sistema cuente con documentación de soporte. 
El equipo o sistema es identificado para su reconocimiento. 
Los componentes específicos de hardware han sido ensamblados e instalados de acuerdo a 
las especificaciones del proveedor. 
El software ha sido instalado correctamente. 
El medio ambiente en que opera el sistema es el adecuado de acuerdo a especificaciones 
del equipo o sistema. 
Los instrumentos de control y monitoreo están calibrados e instalados correctamente. 
 
Enseguida se listan una serie de pruebas (Tabla 2) sugeridas para la calificación de 
instalación (IQ) sin embargo la calificación no está restringida ni limitada a las aquí 
mencionadas. Las pruebas dependerán de la categoría, complejidad y naturaleza del 
sistema. 
 
 
 
16 
 
Tabla 2 
Pruebas Detalle 
Identificación del sistema y 
Documentación 
Que el software cuente con licencias de uso 
Manuales, diagramas, esquemas, etc. del sistema, cada 
uno de ellos debe contar con un número de identificación 
y se deben encontrar en un lugar definido 
Ficha técnica 
Mantenimiento preventivo 
Respaldo de información. 
 
Depuración de información. 
 
Cambio de horario de verano de forma manual (si aplica) 
 
Código de identificación interno 
Modelo,número de serie, datos de placa de 
identificación, 
 
Verificación de condiciones 
ambientales y servicios 
auxiliares 
 
Temperatura ambiental esté de acuerdo a la 
especificación del fabricante 
Humedad relativa ambiental esté de acuerdo a la 
especificación del fabricante 
Voltaje eléctrico esté de acuerdo con la especificación del 
fabricante 
Frecuencia eléctrica del sistema 
Sistema de control cuente con una conexión a un sistema 
de alimentación eléctrica in interrumpible (UPS) 
Conexión a tierra física. 
Identificación de cableado de red (si aplica). 
 
 Memoria RAM, Disco duro, tarjetas de interfaz, medios de 
17 
 
Verificación de Hardware 
 
respaldo, puertos de comunicación que ocupa el sistema, 
modelo de PLC 
Características de los servidores, PC’s, PLC, 
Controladores, que cumplan con los requerimientos 
mínimos del software como son: procesador 
Teclado, mouse, lápiz óptico, etc. (según el sistema) 
Con impresoras y otras interfaz de acuerdo al sistema 
PC’s clientes cumplan con las características mínimas 
requeridas para realizar sus funciones. (sistemas en 
RED). 
Verificación de los 
componentes principales 
 
Componentes que complementan al sistema de control 
para desempeñar sus funciones, como son sensores, 
actuadores, lectores, etc. 
Programa de PLC 
Sistema operativo 
Software de aplicación 
Módulos requeridos 
Tablas de datos 
Software auxiliar 
Verificación de parámetros de 
servidor 
Documenta los parámetros generales de servidor como 
son: nombre, dirección IP, Base de datos 
Verificación de respaldos 
 
La existencia de discos de instalación (sistema operativo, 
aplicaciones, software auxiliar, software de base de datos, 
etc.) 
Archivos de respaldo 
Existencia de información. 
Bitácora de respaldos de información 
Calibración e instrumentación 
del sistema 
Instrumentos del sistema se encuentren calibrados, 
cuenten con el certificado correspondiente y con una 
etiqueta de vigencia de calibración. 
18 
 
 
2.3 CALIFICACIÓN DE OPERACIÓN (Operation Qualification “OQ”) 
 
La calificación de operación es ejecutada después de la calificación de instalación, por lo que 
antes de ejecutar la Calificación de Operación, asegúrese de que existe el Dictamen 
satisfactorio de la Calificación de Instalación del sistema, de lo contrario no se puede ejecutar 
el OQ. Se realiza la Calificación de Operación para asegurar que todos los componentes del 
sistema (o del subsistema) se comportan de acuerdo a sus especificaciones respectivas en 
base al análisis de riesgo. 
 
El OQ confirma que: 
Existen procedimientos de operación (el cual puede desarrollarse desde él comisionamiento) 
y administración del sistema 
El hardware y componentes de control realizan sus funciones de acuerdo a especificaciones. 
Las funciones del software realizan las tareas para las que fueron diseñadas. 
El sistema cumple con los requerimientos regulatorios referentes a firmas y registros 
electrónicos (para los sistemas que así lo requieran) 
Las alarmas son desplegadas en situaciones que especifica el fabricante. 
El sistema está preparado para contingencias que impactan en la operativa (cortes de 
energía eléctrica, interferencia de radio frecuencia, perdida de sistema, etc.) 
 
En ésta etapa de la calificación se verifica de manera independiente función por función 
confirmando que el resultado es satisfactorio, funciones que no sean usadas en su etapa de 
uso productivo serán evaluadas acorde al Análisis de Riesgo de Funciones para determinar si 
deben ser incluidas en la calificación. 
 
Enseguida se lista (Tabla 3) una serie de pruebas sugeridas para la calificación de operación 
(OQ) sin embargo la calificación no está restringida ni limitada a las aquí mencionadas. Las 
pruebas dependerán de la categoría, complejidad y naturaleza del sistema. 
19 
 
 
Tabla 3 
Pruebas Detalles 
Procedimientos 
normalizados de 
operación e instructivos 
de trabajo 
Procedimiento(s) del sistema, se encuentren aprobados, así 
como que contengan los temas que solicita el procedimiento 
de uso productivo de sistemas computarizados. 
Funcionalidad del sistema 
 
En base al árbol de funciones del sistema y al análisis de 
riesgo, reta que éstas diferentes funciones con que cuenta el 
sistema realicen la acción para la que fueron diseñadas. 
 
Reta las funciones de administración de recetas como altas, 
bajas y modificaciones (si aplica) 
 
Cálculos realizados por el sistema 
Emisión e impresión de 
reportes 
 
Reportes cuenten con toda la información requerida 
Imprimen de manera correcta. 
Funciones de 
administración 
Reta las funciones de administración (alta de usuarios, baja 
de usuarios, cambios de contraseña, etc.) 
 
Seguridad lógica Reta que todas las medidas de seguridad con que cuenta el 
sistema realmente funcionen. 
 
Documenta los parámetros de seguridad (tiempo de 
inactividad, número mínimo de caracteres en contraseña, 
periodo establecido para cambio de contraseña, número de 
intentos fallidos, etc.) 
Niveles de acceso Niveles de acceso en el sistema corresponden a los 
documentados 
20 
 
Reta por lo menos 10 funciones incluyendo permitidas y no 
permitidas para cada nivel de acceso verificando que los 
permisos sean respetados. 
 
Reta el cambio de nivel de acceso a los usuarios. 
 
Reta la creación, edición y borrado de niveles de acceso. 
 
 
Verificación de hora y 
fecha del sistema 
Formato de hora y fecha 
Sistema se encuentre a la hora y fecha correctos 
Horario de verano (si aplica) 
El sistema tome la hora y fecha del servidor no del cliente 
(sistemas en RED) 
Verificación de Audit Trail 
(auditoria de rastreo) 
Se registre hora, fecha, usuario y acción realizada 
Si un valor cambió debe registrarse el valor actual y el valor 
anterior 
Login de usuarios tanto exitosos como fallidos 
registrar todas y cada una de las corridas en el sistema 
Alarmas ocurridas durante el proceso deben quedar 
registradas 
 
Los reportes de “Audit Trail (auditoria de rastreo)” no deben 
poder ser modificados 
 
Mensajes y alarmas 
 
Simula los estados de alarmas y verifica que son detectados 
y desplegados por el sistema. 
 
Pruebas de radio Para los sistemas que funcionan con radio frecuencia, micro 
21 
 
frecuencia ondas, campos magnéticos, etc. Verifica si sus funciones se 
ven afectadas por radios de comunicación o celulares y a 
qué distancia se presenta la afección. 
 
Integridad de datos Verificar que los datos respaldados y posteriormente 
recuperados no sufren cambios asegurando su integridad y 
confiabilidad. 
 
Respaldo de réplica 
exacta 
Exista un respaldo de réplica exacta, como puede ser: 
imagen de disco duro, disco duro clon, configuración RAID, 
respaldo de memoria EPROM para PLC, etc. 
Falla de energía eléctrica Simula una falla de energía eléctrica y verifica que el sistema 
responda de acuerdo a lo esperado. 
 
 
 2.4 CALIFICACIÓN DE DESEMPEÑO (Performance Qualification “PQ”) 
La calificación de desempeño es ejecutada después de la calificación de operación, por lo 
que antes de ejecutar la Calificación de Desempeño, asegúrese de que existe el Dictamen 
satisfactorio de la Calificación de Instalación y Operación del sistema, de lo contrario no se 
puede ejecutar el PQ. Se realiza la calificación de desempeño para asegurar que el sistema 
funciona de acuerdo a los requerimientos de usuario, conforme a su uso esperado flujo de 
trabajo establecido y la secuencia de proceso requerida, mientras opera en un medio 
ambiente productivo específico. 
 
El PQ confirma que: 
El personal que tiene acceso al sistema está capacitado. 
El sistema cuente con todo lo necesario para operar en su ambiente productivo. 
El sistema funciona correctamente de manera integral como lo hará en su etapa de uso 
productivo 
El sistema es capaz de operar en sus límites de desempeño. 
22 
 
En esta etapa dela calificación se verifica que el sistema es capaz de operar de manera 
integral y se prueban secuencias de operación completas de inicio a fin confirmando que es 
capaz de desempeñar sus tareas como lo hará en su etapa de uso productivo. 
 
Enseguida se lista (Tabla 4) una serie de pruebas sugeridas para la calificación de 
desempeño (PQ) sin embargo la calificación no está restringida ni limitada a las aquí 
mencionadas. Las pruebas dependerán de la categoría, complejidad y naturaleza del 
sistema. 
Tabla 4 
Pruebas Detalles 
Verificación de matriz 
de usuarios 
Esté documentada el alta de los usuarios activos en el sistema. 
 
Capacitación de 
usuarios 
Los usuarios activos en el sistema cuenten con capacitación 
Que el/los administradores estén capacitados en el 
procedimiento de uso productivo del sistema. 
Verificación de recetas 
del sistema 
Que las recetas que están activas en el sistema coinciden con la 
documentación de altas, baja y modificación de recetas. 
Prueba de 
funcionamiento 
 
Corre un ciclo completo lo más apegado a la realidad y verifica 
que cada uno de los pasos se lleve a cabo conforme lo esperado. 
 
Conciliación de lo real contra lo reportado por el sistema 
Verifica que la corrida quedo registrada en el audit trail (auditoria 
de rastreo) 
Prueba de estrés Reta que el sistema es capaz de desempeñar correctamente sus 
funciones llevándolo al límite de su capacidad de operación sin 
sobre pasarlo. 
Verificación de sobre 
con administrador 
virtual 
Verifica la existencia de un sobre que contenga un usuario 
administrador y su respectiva clave de acceso. 
 
 
23 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 CAPITULO 3 MANTENIMIENTO AL ESTADO VALIDADO 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
24 
 
MANTENIMIENTO AL ESTADO VALIDADO 
 
El ciclo de vida del sistema computarizado, comprende todas las actividades desde el inicio 
del proyecto hasta el retiro sin embargo durante el ciclo de vida de la validación existen 
diversos cambios los cuales deben manejarse a través del sistema de control de cambios 
 
Este sistema tiene como objetivo administrar y controlar los cambios(1) que se realizan a los 
sistemas computarizados regulados por las buenas prácticas de fabricación con la finalidad 
de mantenerlos en estado validado, asegurando el correcto desempeño del sistema, así 
como la integridad de los registros generados. Identificando para ello: 
- El impacto del cambio, criticidad, actividades, tiempos y áreas responsables que 
intervengan en la planeación, 
 
Seguimiento e implementación del cambio. 
 
El área responsable de administrar el proceso de control de cambios de sistemas 
computarizados, de acuerdo a este documento debe ser el área de validaciones; esta área 
debe formar parte de los evaluadores, con la finalidad de determinar las acciones necesarias 
para mantener el estado validado del sistema. En conjunto con Aseguramiento de Calidad 
determina si el cambio tiene impacto regulatorio y en conjunto con las demás áreas, 
determina si el cambio es aprobado o rechazado y propone acciones de seguimiento 
 
3.1 Tipos de Cambios: 
 
a) Igual por igual 
Los cambios igual por igual, están definidos como cambios al software y/o hardware de un 
sistema computarizado, donde las características o especificaciones del elemento que será 
sustituido por uno nuevo son iguales, de tal forma que no se ve alterado el funcionamiento 
del sistema por el cambio realizado. Los cambios igual por igual no tienen efecto sobre la 
integridad, calidad o consistencia de los datos o información generada por el sistema 
(incluyendo registros o firmas electrónicas); ni consecuencias en el funcionamiento o 
25 
 
estabilidad del sistema, de tal forma que no se ve afectada la validación del sistema. 
 
Los siguientes son algunos casos que son considerados como cambios igual por igual. 
 
Cambios en hardware del sistema donde el elemento sustituido y el elemento sustituto 
cuentan con las mismas especificaciones, aunque sean de diferentes marcas, como pueden 
ser: Cambios de fuentes de energía, baterías, CD-ROM, Floppy disk, impresoras y elementos 
que no afecten el desempeño del software de aplicación. 
 
Servicios de mantenimiento realizados por el área de soporte técnico correspondiente o 
proveedor del equipo, donde solo son reemplazados consumibles de rutina sin embargo se 
debe hacer una verificación de su correcta instalación y operación. 
 
Estos cambios no requieren del seguimiento a través del proceso de Control de Cambios y la 
responsabilidad de estos cambios es del área que lo ejecuta. 
 
b) Cambios críticos que requieren ser sometidos a través de Control de Cambios , son 
aquellos que pueden alterar el funcionamiento del sistema y que requieren ser probados 
antes de usarlos en ambiente productivo, verificando un correcto desempeño del sistema y la 
integridad de la información que este contiene. Un cambio debe ser planeado, evaluado y 
aprobado, conociendo y considerando todos los aspectos que afecten el estado de validación 
del sistema. 
 
Los siguientes son algunos ejemplos que son categorizados como cambios que deben ser 
sometidos a través del sistema de control de cambios: 
Reparación de errores identificados. 
Instalación de parches. 
Instalación de software y hardware adicional. 
Actualización de versión de software. 
Adición de módulos o funciones del sistema. 
Cualquier cambio que pueda alterar el funcionamiento del sistema. 
26 
 
 
La etapa de evaluación del cambio, se lleva a cabo en base a la descripción y detalles del 
cambio documentada por el solicitante, los evaluadores (Aseguramiento de la Calidad, 
Validaciones y áreas a las que les impacta el cambio) valoran la solicitud de cambio para 
determinar si el cambio es aprobado o rechazado. 
 
En caso de que la información solicitud proporcionada por el solicitante del cambio no sea 
suficiente para la evaluación, los evaluadores indican cual es la información que requieren. 
En base al soporte documental y a la descripción del cambio por parte del solicitante, los 
evaluadores responden las siguientes preguntas marcando las casillas correspondientes: 
 
El cambio impacta la información o registros que forman parte del paquete técnico, 
información de aprobación o rechazo de lote, información de control en proceso u otra 
documentación solicitada en algún requerimiento presentación o sometimiento ante alguna 
entidad regulatoria? Si ó No. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
27 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 SI 
 
 No 
 
 
 
 
 
Los pasos del diagrama anterior, se puede utilizar para establecer en un procedimiento 
formar para determinar si un sistema de software o hardware es BPX´s y cumple para deber 
ser calificado. 
 
 
 
 
Inicio 
¿Alguna o varias de las 
preguntas anteriores fue 
confirmada? 
 
¿El cambio tiene impacto sobre mensajes o alarmas que influyen en la calidad del 
producto? 
 
¿ El cambio influye sobre el control de elementos o parámetros críticos de proceso 
(CPP)? 
 
¿ El cambio influye sobre atributos críticos de la calidad del producto (CQA)? 
 
¿El cambio impacta en la rastreabilidad del producto? 
 
¿Si el cambio falla se tendrá un efecto directo sobre la calidad del producto? 
 
Aplica 
Calificación 
de software 
(Es BPX´s) 
Comisionamiento o 
verificación (No es 
GxP) 
 Fin 
28 
 
Debe de quedar claro que en el diseño, se forjan las bases para el éxito de un proyecto. Se 
debe entender que el proceso para el cual va a ser usado el software, que es lo que 
requerimos como usuarios de tal forma que entendamos las especificaciones funcionales y 
los puntos críticos de calidad a evaluar en el software y de este modo, tendremos en futuro 
productivo menor posibilidad de cambios necesariosa los sistemas. 
 
No debemos perder de vista que ocasionalmente un sistema computarizado comanda o 
controla un sistema o equipo, como por ejemplo: 
 
En fabricación; Parámetros críticos de un lecho luido, niveles de acceso, passwords, recetas 
de limpieza en sitio etc. 
 
Sistema de unidad manejadora de aire acondicionado: Niveles de acceso, passwords, 
recetas de control de temperatura, de humedad, de flujo de aire. 
 
Los requerimientos de usuario son necesarios para cumplir con las necesidades del producto 
o productos implicados para corroborar que estos requerimientos de usuario están siendo 
considerando en el proyecto, se necesitan hacer pruebas de aceptación en fábrica, cuyo 
beneficio trae como resultado ahorro en tiempo y dinero si se necesitara realizar algún ajuste, 
configuración en fábrica. 
 
 
 
 
 
 
 
 
 
 
 
29 
 
 
 
 
 
 
 
 
 
 
 CAPITULO 4 PLAN MAESTRO DE VALIDACIÓN DE SOFTWARE 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
30 
 
Plan Maestro de Validación de software en el plan maestro de validación. 
 
Cada empresa debe establecer que los sistemas relacionados con las Buenas Prácticas de 
Manufactura, deben de ser Calificados / Validados incluidos en un Plan Maestro de Validación 
dentro del cual figuran los sistemas computarizados que por sus funciones estén 
involucrados o afecten directa o indirectamente la calidad de los productos, la seguridad de 
los pacientes o la integridad de la información regulatoria, deben ser validados, para asegurar 
con un alto grado de confiabilidad que el sistema realiza sus funciones de manera 
reproducible y satisfactoria. Para cumplir con este objetivo, se define la estrategia de 
validación que se aplica a través de un proyecto y que debe ser plasmado a través de un 
Plan Maestro de Validación de Sistemas Computarizados alterno al Plan Maestro de 
Validación general, en el cual se define como una metodología y se establecen las fases de 
la validación para cada uno de los tipos de sistemas, acorde a sus características y 
requerimientos, así como se debe de contar con un inventario de los sistemas 
computarizados que requieran ser validados, el cual debe ser resultado de una evaluación de 
todos los sistemas de la planta en el que se analizan los registros electrónicos que estos 
generan, así como los diferentes factores que puedan afectar la calidad de los productos. 
 
Este proyecto es de gran importancia para las empresas ya que es una exigencia regulatoria 
que tiene como único fin buscar el control para la calidad de los productos, reflejando nuevas 
oportunidades de competencia en otros países. 
 
 
 
 
 
 
 
31 
 
 
El Plan Maestro de Validación de Sistemas de cómputo, puede contener pero no se limita a 
los siguientes puntos: 
OBJETIVO 
ALCANCE 
ESTRUCTURA ORGANIZACIONAL 
ROLES Y RESPONSABILIDADES 
ESTRATEGIA DE VALIDACIÓN 
ESTRATEGIA DE PRIORITIZACIÓN 
CRONOGRAMA DE SISTEMAS DE CÓMPUTO A CALIFICAR. 
 
4.1 OBJETIVO 
Debe de indicar el propósito del documento así como la referencia de cumplir con 
requerimientos regulatorios nacionales e internacionales dependiendo de las necesidades del 
negocio referentes a validación de sistemas de cómputo, firmas electrónicas y registros 
electrónicos. 
 
4.2 ALCANCE 
 
Aplicar a cada uno de los sistemas computarizados existentes y los sistemas próximos a ser 
implementados en la planta o plantas farmacéuticas. 
 
Se sugiere no incluir en el alcance del Plan Maestro de Sistemas de Cómputo los que no 
tengan impacto en BPX´s, se recomienda únicamente evaluar a través del sistema de control 
de cambios, su alcance y las actividades de validación que pudieran surgir como resultado de 
su evaluación. 
 
 Validación de Limpieza de Equipo y áreas 
 Validación/Revalidación de Procesos 
 Calificación/ Recalificación de Equipos y Sistema de computo 
 Calificación/Recalificación de Sistemas Críticos 
 
32 
 
4.3 ESTRUCTURA ORGANIZACIONAL. 
Las responsabilidades de la validación de un sistema computarizado será un grupo de trabajo 
asignado para cada sistema, con el fin de realizar actividades a través de todas las fases del 
ciclo de vida de sistemas computarizados, coordinado por el área de validaciones, en general 
en casi todas las organizaciones se cuenta con los siguientes responsables y sus respectivas 
responsabilidades: 
Tabla 5 
Rol Responsabilidad 
Director de planta Tiene la máxima responsabilidad de revisar y aprobar este plan de 
validación de proyecto, asegurarse del cumplimiento e identificar a los 
individuos que serán responsables de ejecutarlo; así como asegurar los 
recursos apropiados para la validación de sistemas en la organización. 
Gerente de 
Control y 
Aseguramiento 
de Calidad 
Asegura que el sistema realiza las funciones adecuadamente en 
conformidad con los requerimientos principalmente regulatorios pero no se 
limitan a los requerimientos corporativos, así como a aprobar la 
documentación de validación de acuerdo a los procedimientos normalizados 
de operación 
Dueño del 
sistema 
El dueño del sistema asume la total responsabilidad de la validación inicial 
del sistema computarizado, el cumplimiento con los requerimientos de las 
agencias regulatorias así como la permanencia del mantenimiento al estado 
validado; es también el responsable de participar y emitir los entregables del 
sistema que estén bajo su responsabilidad. 
Ing. de validación Es responsable de la validación de los sistemas que le son asignados, 
generando el plan de validación individual para cada sistema con los 
entregables aplicables a cada proyecto, coordinar las actividades de 
validación en cumplimiento con los procedimientos locales, mediante la 
correcta utilización de herramientas de ciclo de vida 
Responsable 
Sanitario 
Es la figura que autoriza los protocolos y reportes generados. 
33 
 
 
4.4 ESTRATEGIA DE VALIDACIÓN 
 
Con el fin de incorporar correctamente sistemas computarizados y su cumplimiento con 
registros electrónicos y firmas electrónicas (si aplica) de acuerdo a los requerimientos de las 
agencias regulatorias, el seguimiento y la documentación de las fases (planeación y 
requerimientos, verificación del diseño, calificación, reportes, mantenimiento al estado 
validado y retiro) de los sistemas, tiene que darse de manera secuencial bajo las siguientes 
primicias: 
 
Cada fase de desarrollo del proceso, debe ser controlada y documentada para verificar y/o 
retar que el sistema cumple con las especificaciones de calidad y diseño. 
Por tal motivo la validación de sistemas computarizados, deberá dar evidencia documentada, 
que provea un alto grado de seguridad, de que el sistema desarrollará sus funciones de 
manera consistente confiable y conforme a especificaciones y atributos de calidad 
predeterminadas, de acuerdo a los requerimientos regulatorios vigentes. Todos los sistemas 
relacionados con las BPX´x deben cumplir con registros y firmas electrónicas de acuerdo a lo 
requerido por CFR21 parte 11. 
 
 
 
 
 
 
 
 
 
 
 
 
 
34 
 
DETERMINACIÓN DE CUMPLIMIENTO CON CFR 21 PARTE 11 
 
REGISTROS ELECTRÓNICOS 
Tabla 6 
No. Pregunta SI NO 
1 
 
¿El Sistema Computarizado creará, modificará, guardará, mantendrá, 
archivará, recuperará, o transmitirá registros a medios electrónicos durables? 
Si la respuesta es “no”. El sistema debe ser validado, pero no debe cumplir 
con las regulaciones de CFR 21 parte 11; de lo contrario continúe con punto 
2. 
 
2 
 
¿Estos registros están incluidos o solicitados en algún requerimiento 
regulatorio? 
Como las BPx u otras regulaciones (COFEPRIS, FDA, etc.) o requerimiento 
interno (ejem. PNO). 
Si la respuesta es “no”. El sistema debe ser validado, pero no debe cumplir 
con las regulaciones de 21 CFR parte 11; de lo contrario continúe con punto 
3. 
 
3¿Es el sistema heredado? (sistema heredado es aquel que opera desde antes 
del 20 de agosto de 1997, Guidance for Industry Part 11, Electronic Records; 
Electronic Signatures-Scope and Application, Legacy Systems page 7, líneas 
257 a 274 August 2003.). 
Si la respuesta es “si”. El sistema debe ser validado, pero no debe cumplir 
con las regulaciones de 21 CFR parte 11; de lo contrario continúe con 4. 
 
 Si las preguntas 1 y 2 son “si” y la pregunta 3 es “no”, El sistema debe ser validado y cumplir 
con las regulaciones de registros electrónicos de 21 CFR parte 11 
 
 
 
35 
 
FIRMAS ELECTRÓNICAS 
Tabla 7 
No. Pregunta SI NO 
4 
¿Se usan firmas electrónicas? 
Si la respuesta es “no”, el sistema debe cumplir solo con las regulaciones 
aplicables a registros electrónicos. Si la respuesta es “si”, el sistema debe 
cumplir con las regulaciones de registros electrónicos y a firmas electrónicas. 
 
 
De acuerdo a la NOM 050-SSA-1-2013: 
Para firmas electrónicas: 
Estas deben ser únicas para cada persona e intransferibles. 
Cuando el uso de firmas electrónicas sea adoptado, se debe establecer la fecha a partir de la 
cual las firmas electrónicas son vigentes y equivalentes a las firmas autógrafas. 
Las firmas electrónicas deben contar con al menos dos elementos distintos tales como un 
código de identificación y una contraseña. 
 
Los sistemas computarizados relacionados con Buenas Prácticas de Fabricación, deben ser 
validados, el alcance dependerán de la complejidad de la aplicación computarizada; su 
apropiada calificación de instalación, de operación deben demostrar la adecuabilidad del 
hardware y software para desempeñar tareas asignadas. 
 
Se deberá de dar prioridad de acuerdo al tipo de software o hardware, por ejemplo un 
software comercial que ya cuente con validación vs un software diseñado específicamente el 
cual no ha sido nunca validado, se debe de dar prioridad al software diseñado 
específicamente ya que no se tienen mayores datos de la funcionalidad del sistema. 
 
4.4.1 VALIDACIÓN PROSPECTIVA 
 
En los sistemas computarizados, la validación prospectiva, se realiza siguiendo el ciclo de 
vida de la validación de sistemas de cómputo las cuales deben de asegurar que antes de la 
implementación del sistema en el medio ambiente productivo, este realiza sus actividades de 
36 
 
manera consistente y repetitiva de acuerdo a los requerimientos regulatorios. 
Para sistemas computarizados existentes o heredados que no cuentan con validación, se 
utiliza la misma metodología de ciclo de vida de validación, mediante evidencia documentada 
que los sistemas existentes cumplen con las funciones para las cuales fueron 
implementadas. Considerando así que para los sistemas existentes, la documentación de 
verificación del diseño, e implementación pueden ser omitidas por no estar disponible o 
puede ser documentada con un menor detalle de acuerdo a la información con que se 
cuente, sin embargo, aún cuando operen de manera satisfactoria y confiable no son exentos 
de los requerimientos de validación, para los sistemas que aún no cumplan con un estatus de 
validación aprobado que deban ser alineados a los actuales requerimientos de validación en 
un periodo de tiempo apropiado. 
 
 
4.4.2 REGISTROS ELECTRÓNICOS Y FIRMAS ELECTRÓNICAS 
 
La regulación permite el uso más amplio posible la tecnología electrónica y debe ser aplicada 
a cualquier sistema computarizado que cuente con cualquiera de los requerimientos para 
registros regulatorios. 
 
Para determinar si el sistema debe cumplir con las regulaciones referentes a registros y 
firmas electrónicas, se debe hacer un análisis caso por caso, esto se deberá hacer para 
sistemas nuevos y existentes, donde se definirá si el sistema a validar: 
 
 No debe cumplir con registros ni firmas electrónicas. 
 Sólo debe cumplir con registros electrónicos. 
 Debe cumplir con registros y firmas electrónicas. 
 
La FDA indica que si un sistema está dentro del alcance del 21 CFR parte 11, el 
cumplimiento con todos los atributos de parte 11 son necesarios. 
 
Criticidad y categorías de sistemas computarizados. 
37 
 
 
4.5 ESTRATEGIA DE PRIORITIZACIÓN 
 
De acuerdo a su impacto regulatorio, los sistemas se clasifican de la siguiente manera: 
 
 
Alta criticidad BPX´s 
 
Sistema que tiene un impacto directo en la calidad del producto o cumplimiento regulatorio. 
 
 
Mediana criticidad BPX´s 
 
Sistemas que tienen un impacto indirecto en la calidad del producto o cumplimiento 
regulatorio. 
 
Baja criticidad BPX´s 
 
Sistemas que soportan infraestructura de los sistemas regulatorios 
 
Estos niveles de riesgo ayudan al establecimiento de las prioridades de los sistemas 
regulados para la validación, revalidación, corrección o remplazo. 
 
Debido a la gran variedad de sistemas computarizados existentes en el mercado, se define la 
siguiente categorización de De acuerdo a Guías Ispe GAMP 5 A Risk- Based Approach 
to compliant GxP Computarized Systems 2008 
 
 
 
 
 
38 
 
Tabla 8 
Categoría Tipo de sistema 
1 Sistema 
infraestructura 
Elementos de infraestructura interrelacionados para crear un ambiente que 
pueda soportar las aplicaciones, donde las mismas puedan correr y 
desempeñarse de manera confiable. 
Existen dos tipos en esta categoría: 
a. Software de plataforma. 
Las aplicaciones son desarrolladas para correr bajo el control de este tipo de 
software. Ejemplo: sistemas operativos, administradores de bases de datos, 
lenguaje de programación, intérpretes de diagrama escalera, herramientas 
de programación estadística, etc. 
b. Software de infraestructura. 
Esta incluye herramientas como software de monitoreo de redes, software de 
seguridad, anti-virus, herramientas de administración de configuración, etc. 
 
La validación de una aplicación es indirectamente al mismo tiempo una 
validación a los sistemas de infraestructura. Se asume que debido a su gran 
comercialización las fallas serias han sido previamente detectadas y 
eliminadas, por lo que este tipo de software pueden ser considerados como 
productos validados ya que sin un sistema de infraestructura funcional, el 
éxito de la validación de las aplicaciones que correrán en estas plataformas 
no es posible 
 
2 Instrumento Se refiere principalmente a instrumentos de medición, los cuales sólo dan 
mediciones generales de una variable física como puede ser temperatura, 
humedad, voltaje, viscosidad, etc. Una característica de esta categoría es 
que no guardan datos de manera permanente, no procesan datos y tampoco 
toman decisiones. Ejemplo: milímetro, báscula, termo higrómetro, 
manómetro, etc. 
39 
 
3 Firmware Programación en Firmware, es un bloque de instrucciones de programa para 
propósitos específicos, grabado en una memoria tipo ROM, 
EPROM,EEPROM, etc., que establece la lógica de más bajo nivel que 
controla los circuitos electrónicos de un dispositivo de cualquier tipo. Algunas 
características de esa categoría es que, no guarda datos de manera 
permanente. Ejem: PLC, microprocesadores, etc. 
 
Los sistemas firmware no se validan. 
La verificación del sistema de control de este tipo de equipos es retada en la 
calificación de equipo. 
4No 
configurables 
 Son sistemas que no requieren ser configurados para los procesos o 
sistemas que sólo usan la configuración de default, esto incluye a los 
conocidos igualmente como COTS (“comercial-Off- The-Shelf”) estos 
paquetes sólo es necesario ingresar parámetros para que realice sus 
funciones de acuerdo a su medio ambiente productivo, es decir sólo para ser 
instalados y funcionar de acuerdo a las funciones propias del software. 
Estos sistemas sólo requieren ser parametrizadas lo cual se limita a 
establecer parámetros de proceso establecidos específicos del paquete 
ejemplo: tiempos, velocidades, temperaturas, conexiones de red, 
instrumentos o dispositivosperiféricos, etc). 
Los sistemas no configurables si requieren ser validados. 
Se recomienda hacer una validación reducida para este sistema 
5 Paquete de 
software 
configurable 
Los paquetes de software configurables son aquellos que ya existen en el 
mercado pero debido a las múltiples funciones que realiza, este debe ser 
configurado de acuerdo a las necesidades operativas de cada empresa, 
estos ofrecen interfaz y funciones estándar capaces de ser adecuadas 
específicamente para las necesidades de la empresa, esto incluye módulos o 
arreglos, etc, Ejem, Administración de información de laboratorio LIMS, 
sistemas de planeación de recursos ERP, sistemas de administración de la 
documentación electrónica (EDMS), etc. 
40 
 
6 
Personalizado 
Sistemas desarrollados especialmente para cubrir necesidades específicas 
de la empresa (por proveedores internos o externos) que pueden ser, un 
sistema independiente o parte perzonalizada de otro sistema. 
Los sistemas personalizado si requiern ser validados. 
7 Hojas de 
cálculo 
Las hojas de cálculo desarrolladas en paquetes de oficina (ejemplo, Excell, 
Access, etc). Son los archivos que almacenan datos, realizan cálculos y/o 
contienen macros (comandos que se pueden activar como programas) 
desarrollados individualmente para actividades específicas, como registro o 
manipulación de datos e información relacionada con BPX´s. 
Las hojas de cálculo requieren ser validadas. 
 
Cuando se desarrolla una interfaz de un sistema BPX´s que enviara, analizará o mostrará 
información a un sistema No-BPX´s y esta información no será usada con fines regulatorios, 
solo es necesario realizar una calificación de instalación de la interfaz para asegurar que el 
sistema BPX´s no se vio afectado y mantiene su estado validado. 
 
Cualquier sistema desarrollado para control de procesos o aseguramiento de la calidad del 
producto, que sea usado sólo como consulta de información, deberá ser validado antes de 
ser usado. 
 
Todos los sistemas se integran en una sola metodología de validación la cual sigue los 
lineamientos establecidos del ciclo de vida de la validación de sistemas computarizados en 
el cual se utilizan formatos aprobados para cada etapa de validación, esta metodología está 
diseñada para incorporar las actividades de validación dependiendo del tipo y características 
del sistema. 
 
Dentro del plan de validación individual por sistema, será establecida la documentación y 
entregables del ciclo de vida requerida para la validación de cada sistema, así mismo se 
definirán los individuos responsables de la elaboración, revisión y aprobación de cada uno de 
los documentos. No confundir Plan Maestro de Validación con Ciclo de Vida de Validación, ya 
41 
 
que el ciclo de vida se refiere a cada sistema y el Plan Maestro de Validación, se refiere a un 
plan. 
Los documentos del ciclo de vida se dividen en 7 fases* que son: 
a) Fase de prerrequisitos para validación. 
b) Fase de planeación y requerimientos. 
c) Fase de verificación de diseño. 
d) Fase de calificación. 
e) Fase de reportes. 
f) Fase de mantenimiento del estado validado. 
g) Fase de retiro. 
A continuación se describe el listado de documentación y abreviaciones del ciclo de vida que 
deben seguir los sistemas computarizados. 
De acuerdo a Guías Ispe GAMP 5 A Risk- Based Approach to compliant GxP 
Computarized Systems 2008 
 
 
Tabla 9 
Fase Nombre del documento 
Pre requisitos 
para la 
validación 
Plan de Validación de proyecto para sistemas computarizados 
Planeación y 
requerimientos 
Análisis para inclusión al inventario. 
Requerimientos de usuario. 
Plan de validación. 
 
Validación de 
Diseño 
Especificación funcional y de diseño. 
Análisis de riesgo de funciones. 
Calificación Protocolo de calificación de instalación. 
Protocolo de calificación de operación. 
42 
 
Protocolo de calificación de desempeño. 
Matriz de trazabilidad. 
Reportes Reporte de calificación de instalación. 
Reporte de calificación de operación. 
Reporte de calificación de desempeño. 
Mantenimiento 
al estado 
validado 
PNO de uso productivo. 
Revisión periódica y revalidación. 
Control de cambios de sistemas computarizados. 
Retiro Retiro del sistema. 
 
 
Pre requisitos de validación 
 
Plan de Validación de proyecto para sistemas computarizados. 
Es el plan maestro para validación de cómputo, donde se define el alcance del proyecto, la 
estructura organizacional, roles y responsabilidades, la estrategia de validación así como las 
actividades y entregables para dar cumplimiento a la validación de sistemas computarizados, 
visto como un proyecto macro para dar cumplimiento a las regulaciones nacionales e 
internacionales donde se comercializa producto. 
 
Fase de planeación y requerimientos. 
 
En este análisis todos los sistemas serán evaluados caso por caso para determinar si son o 
no son sistemas computarizados, la categoría a la que pertenece, si es un sistema 
relacionado con las BPX´s (Refierase a la estrategia de validación para el proceso que debe 
de seguirse), si debe cumplir con registros electrónicos y / o firmas electrónicas. Este criterio 
es un paso crítico en el proceso de validación, ya que se determina las características de 
cada sistema y ofrece una dirección para establecer los criterios de validación para cada 
sistema. 
 
43 
 
Requerimiento de usuario 
 
Los requerimientos de usuario describen las funciones, operaciones y datos que se desean 
como resultado de la operación del sistema computarizado que se planea adquirir o 
desarrollar, de acuerdo a como se comporta en un medio ambiente productivo. Los 
requerimientos de usuario deben ser escritos tanto para sistemas desarrollados 
internamente como para adquiridos a través de un proveedor 
 
Análisis de riesgo de funciones 
 
Un análisis de riesgo debe ser realizado analizando todas las funciones y sus posibles fallas 
que puedan afectar la operación y confiabilidad del sistema computarizado en particular que 
ayude a identificar las los riesgos que representen un impacto en la calidad de los 
productos o información regulatoria, así como la probabilidad de que ocurra y sea detectada. 
El nivel de detalle del análisis de riesgo debe estar relacionado con la complejidad y criticidad 
del sistema. 
 
Fase de calificación 
 
Protocolo de calificación de instalación 
 
La calificación de instalación proporciona evidencia documentada de que los componentes 
del sistema están instalados apropiadamente de acuerdo a especificaciones de fabricante y 
de los requerimientos del cliente previamente establecidas y que la documentación relevante 
está disponible. Los componentes de la calificación de instalación dependerán del alcance 
definido para el sistema como sistemas clientes, sistema operativo, base de datos, etc. 
 
Protocolo de Calificación de operación. 
 
La calificación de operación proporciona evidencia documenta de que el sistema funciona 
como fue requerido en base a especificaciones previamente aprobadas. Las pruebas 
44 
 
asociadas con la calificación de la operación son fundamentalmente pruebas funcionales 
individuales, que confirman que los componentes de hardware y software funcionan de 
manera independiente. 
 
Protocolo de calificación de desempeño 
 
La calificación de desempeño, proporciona evidencia de que el proceso entero e integral, 
bajo condiciones de control de un sistema computarizado, produce consistentemente y de 
manera segura un producto o resultado final que cumple con todos los atributos 
predeterminados de calidad en un ambiente productivo real o lo más parecido a este. Las 
pruebas asociadas a la calificación de desempeño son fundamentalmente pruebas de 
proceso. 
Matriz de trazabilidad 
 
La trazabilidad de requerimientos, será iniciada para el mapeo de los requerimientos de 
usuario, especificaciones, el análisis de riesgoy los casos de prueba, ilustrando así la 
relación entre actividades y documentos. La trazabilidad del sistema debe ser realizada una 
vez que se hayan terminado de aprobar los protocolos. 
 
REPORTES 
 
El proceso de validación de sistemas computarizados termina con un reporte final de 
validación, este reporte debe proporcionar un resumen de las pruebas realizadas y resultados 
relevantes presentados durante la ejecución de la validación, dando el dictamen si el sistema 
se considera calificado o no 
 
MANTENIMIENTO AL ESTADO VALIDADO 
 
En esta fase es cuando el sistema ya es usado para los fines que fué pretendido, de manera 
real y con productos que serán comercializados. En esta etapa son aplicados los PNOs de 
uso productivo, para garantizar procesos estandarizados y mantener el estado de validación 
45 
 
de sistema computarizado. 
 
ANÁLISIS DE RIESGO DE FUNCIONES 
 
A continuación, se mostrará un análisis de funciones en el cual es base para emitir y soportar 
las pruebas de validación/calificación de software. 
 
Hablamos de un caso medidor de carbono orgánico total (TOC) por sus siglas en inglés. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
46 
 
 
 
 
 
 
 
 
 
CAPITULO 5 EJEMPLO DE CALIFICACIÓN DE INSTALACIÓN OPERACIÓN DE 
SOFTWARE 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
47 
 
5.1 INTRODUCCIÓN 
 
El sistema analizador de TOC, es un equipo en el cual se puede analizar residuos de carbono 
orgánico total, el equipo consta de un auto muestreador y analizador automático de muestras, 
los resultados son mandados a una PC la cual cuenta de una impresora y un monitor. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Este TOC tiene su ubicación en el laboratorio de Control de Calidad y tiene como propósito 
analizar muestras de agua purificada del sistema de generación (fuera de línea) así como 
muestras de enjuague de limpieza etc. 
 
Objetivo 
 
Analizar cada una de las especificaciones funcionales del sistema TOC indicadas en el 
documento “X” para identificar los riesgos asociados del sistema y determinar los aspectos 
que deben ser evaluados durante el proceso de calificación del sistema. 
A continuación, se presenta la siguiente matriz de análisis de riesgos en la cual podemos 
observar un número de referencia, título de especificación en el cual se describe la función, 
después de esto tenemos el tipo de impacto si es de Buenas prácticas BPx´s o negocio, 
Usuario 
Impresora 
 
Sistema 
Automuestreador 
Analizador 
de Carbono Orgánico Total 
48 
 
Enseguida tenemos la descripción del riesgo, posteriormente la evaluación del riesgo dividida 
en Impacto, Probabilidad de que ocurra el riesgo, Clasificación del riesgo, Probabilidad de 
detección del riesgo y la prioridad de verificación. 
 
 
I
m
p
a
c
t
o
 d
e
 u
n
 
R
i
e
s
g
o
 
I
d
e
n
t
i
f
i
c
a
d
o
 A 2 1 1 
M 3 2 1 
B 3 3 2 
 B M A 
 
Probabilidad de 
que ocurra 
 
C
la
s
if
ic
a
c
ió
n
 d
e
l 
R
ie
s
g
o
 (
c
la
s
e
) 1 M A A 
2 B M A 
3 B B M 
 A M B 
 
Probabilidad de 
detección del 
Riesgo 
 
 
• 
49 
 
 
5.1.2 TABLA DE ANÁLISIS DE RIESGO DE FUNCIONES 
Tabla 10 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-1 
Cuantificación e 
Identificación 
(TIC / TOC) Carbono 
inorgánico total /Carbono 
orgánico Total 
 
BPX´
s 
AR-1 
Las muestras 
pueden ser 
inservibles si el 
equipo no es 
capaz de 
cuantificar ni 
identificar entre 
Carbono TIC y 
TOC 
A M 1 A M 
Verificar en la 
Calificación de 
Instalación (IQ) 
que el sistema es 
capaz de 
identificar y 
cuantificar entre 
TIC y TOC. 
50 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-2 
Límite de Detección. 
El Límite Inferior de 
Detección del Equipo es 
de 0.03 ppb 
BPX´
s 
AR-2 
Las muestras 
pueden ser 
inservibles si el 
sistema no cubre 
con el límite 
mínimo de 
detección de 
análisis. 
A M 1 A M 
Verificar en la 
Calificación de 
Instalación (IQ) 
que el sistema 
cumple con el 
Límite de 
detección 
establecido. (sólo 
hacerlo en caso de 
no haber hecho 
pruebas de 
aceptación en 
fábrica) 
51 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-3 
Rango de lectura 
El rango de operación 
lineal es de : 0.03 ppb a 
50,000 ppb 
BPX´
s 
AR-3 
Las muestras 
pueden ser 
inservibles si el 
sistema no cubre 
con el límite 
mínimo y máximo 
de detección de 
análisis. 
A M 1 A M 
Verificar en la 
Calificación de 
Instalación (IQ) 
que el sistema 
cumple con el 
Rango de Lectura 
establecido. . (sólo 
hacerlo en caso de 
no haber hecho 
pruebas de 
aceptación en 
fábrica) 
52 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-4 
Automuestreador. 
Modelo Automuestreador 
de acuerdo al modelo en 
cuestión. 
Nego
cio 
AR-4 
Sin el 
automuestreador 
los analistas 
prepararían las 
cantidades 
exactas de 
solución 
requeridas por el 
sistema para los 
análisis 
manipulando la 
muestra 
M M 2 M M 
Verificar en la 
Calificación de 
Instalación (IQ) 
que el sistema 
cuente con 
Automuestreador 
integral del modelo 
en cuestión. Si 
llegase a fallar no 
hay impacto a la 
calidad del 
producto ya que 
se puede inyectar 
directamente la 
muestra . 
53 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-5 
Tiempo de Análisis. 
Tiempo de análisis 4 
minutos. 
Nego
cio 
AR-5 
A mayor tiempo de 
análisis, se 
juntarían las 
muestras de otros 
estudios haciendo 
que los resultados 
se entreguen en 
un tiempo mayor a 
lo estipulado 
M M 2 M M 
Verificar en la 
Calificación de 
Instalación (IQ) 
que el sistema 
realiza los análisis 
en un tiempo igual 
o menora los 5 
minutos. . (sólo 
hacerlo en caso de 
no haber hecho 
pruebas de 
aceptación en 
fábrica) 
54 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-6 
Componentes del 
Sistema 
PC e Impresora 
BPX´
s 
AR-6 
Sin todos los 
componentes del 
sistema, no 
podrían realizarse 
los análisis. 
A M 1 M A 
Verificar en la 
Calificación de 
Instalación (IQ) 
que el Sistema 
Sievers Data Pro 
tiene todos sus 
componentes 
correctamente 
instalados y 
conectados. 
55 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-7 
Sistema Ininterrumpido 
de Energía 
UPS 
BPX´
s 
AR-7 
Pérdidas parciales 
de datos, caída 
total del sistema o 
daños en 
hardware. 
A M 1 M A 
Verificar en la 
Calificación de 
Instalación (IQ) 
que el sistema se 
encuentra 
conectado a un 
equipo de energía 
ininterrumpida o 
servicio de energía 
eléctrica de 
emergencia. 
56 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-8 
Calibración Multipunto 
El equipo calcula con un 
coeficiente de correlación 
(no menor de 0.98) 
BPX´
s 
AR-8 
Sin la Calibración 
multipunto no se 
podría verificar la 
linealidad del 
analizador 
imposibilitando su 
ajuste. 
A M 1 M A 
Verificar en la 
Calificación (IQ) 
que el sistema 
realiza Calibración 
Multipunto. 
EF-9 
Límite inferior de 
cuantificación. 
El Límite Inferior de 
Detección del Equipo es 
de 0.03 ppb 
BPX´
s 
AR-9 
Las muestras 
pueden ser 
inservibles si el 
sistema no cubre 
con el límite 
mínimo de 
detección de 
análisis. 
A M 1 A M 
Verificar en la 
Calificación de 
Instalación (IQ) 
que el sistema 
cumple con el 
Límite de 
detección 
establecido. 
57 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-10 
Calificación de 
Software 
El proveedor incluye los 
protocolos y la 
calificación de Software 
del Sistema. 
BPX´
s 
AR-10 
No contar con la 
calificación del 
software 
ocasionaría tener 
incumplimiento 
regulatorio 
M M 2 M M 
Para la 
Calificación del 
Software, se 
elaborarán y 
ejecutarán los 
protocolos IQ/OQ 
del Sistema 
58 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-11 
Calificación/Calibración 
del equipo 
El proveedor incluye los 
protocolos de calificación 
del Analizador TOC y los 
ejecuta, al final entrega el 
reporte de los resultados. 
BPX´
s 
AR-11 
No contar con la 
calibración y 
calificación del 
equipo por parte 
del proveedor 
ocasionaría tener 
resultados no 
confiables. 
M M 2 M M 
No es necesario 
verificar la 
calificación del 
equipo por parte 
del proveedor. Sin 
embargo en la 
Calificación de 
Instalación (IQ) se 
verificará que el 
equipo se 
encuentre 
calibrado. 
59 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-12 
Manuales. 
Manual de operación y 
mantenimiento del 
analizador de carbono 
orgánico total 
BPX´
s 
AR-12 
Sin el manual del 
sistema o la guía 
de usuario, el 
sistema puede ser 
utilizado de forma 
incorrecta. 
A M 1 A M 
Verificar en la 
Calificación de 
Instalación (IQ) 
que exista el 
manual de uso del 
Sistema 
EF-13 
Idioma de Manuales 
Manual de operación y 
mantenimiento esta en 
idioma español 
BPX´
s 
AR-13 
Si los manuales se 
encuentran en 
inglés puede 
existir confusión 
por el idioma. 
A M 1 A M 
Verificar en la 
Calificación de 
Instalación (IQ) 
que los manuales 
se encuentran en 
idioma Español. 
60 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-14 
Registros Inválidos 
El sistema distingue 
registros inválidos (ejem. 
campo inválidos, campos 
dejados en blanco que 
deben contener datos, 
valores fuera de límites, 
etc.) 
BPX´
s 
AR-14 
Los usuarios 
pueden caer en 
confusión al no 
poder nombrar los 
análisis, introducir 
variables o 
cuentas de usuario 
en un formato bien 
definido. 
A M 1 A M 
Verificar en la 
Calificación de 
Operación (OQ) 
que los campos de 
texto del sistema 
están restringidos 
y no acepta 
caracteres que el 
sistema no 
reconoce como 
válidos. 
61 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-15 
Base de Datos 
El analizador almacena el 
historial de datos con las 
mediciones de TOC en la 
memoria RAM. En el 
menú de datos (data), se 
puede configurar la forma 
en que su analizador 
almacena y muestra el 
historial de datos; 
también puede iniciar la 
impresióny exportar los 
datos. 
BPX´
s 
AR-15 
Sin la base de 
datos no hay 
forma de guardar 
ningún tipo de 
análisis ni 
registros 
A M 1 A M 
Verificar en la 
Calificación de 
Operación (OQ) 
que el sistema 
guarda los análisis 
realizados. 
62 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-16 
Eliminación de 
Registros 
El sistema no permite 
eliminar registros de 
forma manual solo 
cancelarlos o inactivarlos. 
BPX´
s 
AR-16 
Si el sistema 
permitiera la 
eliminación de 
registros, se 
perdería toda la 
trazabilidad y las 
actividades 
realizadas en el 
sistema 
A M 1 A M 
Verificar en la 
Calificación de 
Operación (OQ) 
que el sistema no 
permite la 
eliminación de 
registros. 
63 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-17 
Registros electrónicos 
El sistema considera 
como registros 
electrónicos: 
Cada uno de los análisis 
realizados y toda la 
información relacionada a 
los mismos 
BPX´
s 
AR-17 
Sin registros 
electrónicos no 
hay forma de 
conocer las 
acciones 
realizadas en el 
sistema 
A M 1 A M 
Verificar en la 
Calificación de 
Operación (OQ) 
que el sistema 
registra y guarda 
los análisis y 
acciones 
generadas en el 
sistema. 
64 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-18 
Auditoria de rastreo 
El equipo tiene el 
programa Dataguard 
para el cumplimiento con 
el CFR-21 parte 11. 
El sistema cuenta con 
Audit trail (Auditoria de 
rastreo). 
BPX´
s 
AR-18 
Sin el Audit Trail 
(Auditoría de 
Rastreo) no se 
cuenta con el 
registro de las 
acciones más 
importantes 
realizadas en el 
sistema. 
A M 1 A M 
Verificar en la 
Calificación de 
Operación (OQ) 
que el sistema 
cuenta con Audit 
Trail (auditoria de 
rastreo) y que se 
encuentra 
activado. 
65 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-19 
Legibilidad de la 
información 
El sistema presenta la 
información de auditoría 
de rastreo de una 
manera legible y 
susceptible de ser leída y 
bien interpretada. 
BPX´
s 
AR-19 
Si la información 
no es legible y/o 
entendible no es 
posible interpretar 
lo que el Audit Trail 
(auditoria de 
rastreo) contiene 
imposibilitando 
conocer las 
acciones 
efectuadas en el 
sistema. 
A M 1 A M 
Verificar en la 
Calificación de 
Operación (OQ) 
que la información 
del Audit Trail 
(auditoria de 
rastreo) es clara, 
entendible y que 
corresponde con 
las acciones 
efectuadas en el 
sistema. 
66 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-20 
Impresión de Audit Trail 
(auditoria de rastreo) 
El audit trail puede ser 
impreso y leído sin la 
posibilidad de alterar los 
datos que contiene. 
BPX´
s 
AR-20 
Si la información 
impresa por el 
Audit Trail 
(auditoria de 
rastreo) se pudiera 
alterar, los 
registros de 
auditoría no serían 
confiables. 
M M 2 M M 
Verificar en la 
Calificación de 
Operación (OQ) 
que la información 
impresa del Audit 
Trail (auditoria de 
rastreo) no se 
puede modificar. 
67 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-21 
Información de Audit 
trail (auditoria de rastreo) 
El Audit Trail (auditoria de 
rastreo) contiene: 
 Nombre del usuario (User 
Id) 
 Fecha 
 Hora 
 Acción efectuada 
 Datos modificados 
BPX´
s 
AR-21 
No contar con la 
información de las 
acciones 
realizadas en el 
sistema, así como 
tampoco conocer 
quien las efectuó. 
 
A M 1 A M 
Verificar en la 
Calificación de 
Operación (OQ) 
que la información 
del Audit Trail 
(auditoria de 
rastreo) contiene 
la información 
completa para 
rastrear la 
actividad realizada 
en el sistema así 
como el usuario, la 
fecha y la hora en 
que fue ejecutada. 
68 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo 
(A, M, 
B) 
Clasi
ficaci
ón 
del 
Ries
go 
Clas
e 
(1,2,
3) 
Probabilid
ad de 
detección 
del riesgo 
(A, M, B) 
Prior
idad 
(A, 
M, 
B,) 
Medidas 
EF-22 
Registro de acciones de 
Audit Trail (auditoria de 
rastreo) 
La Auditoria de Rastreo 
registra las acciones de 
los usuarios y 
administradores del 
sistema donde los 
registros electrónicos: 
No puede ser alterado ni 
modificado por ningún 
usuario, incluyendo al 
administrador. 
BPX´
s 
AR-22 
Sin el registro de 
acciones en el 
sistema, la 
trazabilidad se 
vuelve incompleta 
al desconocer 
quién genera, 
modifica o elimina 
registros del 
sistema. 
A B 2 M M 
Verificar en la 
Calificación de 
Operación (OQ) 
que el Audit Trail 
(auditoria de 
rastreo) registra 
las acciones de 
todos los usuarios 
del sistema donde 
los registros 
electrónicos 
 Se generan. 
 Se modifican. 
 Se eliminan 
69 
 
No. de 
Referencia 
Titulo de Especificación 
Releva
ncia 
(BPX´s
/Negoc
io) 
No. 
Referen
cia 
Riesgo 
Descripción del Riesgo 
Identificado 
Impacto 
de un 
Riesgo 
Identific
ado 
(A, M, 
B) 
Probab
ilidad 
de que 
ocurra 
el 
Riesgo