Hemos publicado nuestro Vendor Assurance Pack completo — incluido lo que aún no tenemos

Así es como funciona realmente la adquisición de software en un negocio regulado. Operaciones elige la herramienta en la semana dos. Calidad y seguridad de TI inician su revisión en la semana cuatro. El cuestionario llega al proveedor en la semana seis — cuarenta pestañas y una solicitud de categorización GAMP que el proveedor nunca ha documentado. Alrededor de la semana catorce todo el mundo llega a un acuerdo, y lo que lo retrasó nunca fue el producto.

Hemos recibido suficientes veces ese proceso para concluir que la secuencia es incorrecta. Por eso hemos publicado las respuestas de antemano.

Qué contiene

Dieciocho secciones, organizadas para que cada revisor pueda ir directamente a su parte. Un revisor de calidad necesita el índice del QMS, la categorización GAMP 5 y los mapeos de Annex 11 y Part 11. Seguridad de TI necesita la topología de alojamiento, la arquitectura de seguridad y el CAIQ-Lite. Un DPO necesita la división responsable-encargado, el registro de subencargados y la sección de gobernanza de IA. Compras necesita el estado de certificación, la postura de continuidad y la distribución de responsabilidades. El documento abre con una tabla que indica a cada perfil qué secciones debe leer.

Los mapeos de cláusulas son el núcleo del documento. Cada cláusula de Annex 11 — las diecisiete — con lo que hacemos al respecto y dónde se encuentra la evidencia. Luego 21 CFR Part 11: los controles del §11.10, las disposiciones sobre firmas del §11.50 y §11.70, y los requisitos de firma electrónica del §11.100, §11.200 y §11.300. Dos de esas filas están marcadas como obligación *suya* y no nuestra, porque no pueden ser asumidas por un proveedor, y fingir lo contrario dejaría una laguna que solo aflora durante una inspección.

Y lo que no contiene

Esta es la parte que justificó escribir el documento. El §13 es una tabla de estado de certificaciones y el §17 es una lista completa de elementos abiertos; entre ambos se afirma con claridad:

• No disponemos de SOC 2 Type II. Se tiene planificado un programa conjunto con ISO 27001, con meses objetivo realistas, no una afirmación de que hay una auditoría en curso.
• No disponemos de ISO 27001.
• Nuestro firewall de aplicaciones web no tiene ningún conjunto de reglas asociado. La política está en modo Prevención, lo que suena tranquilizador pero, sin reglas, no filtra nada en la capa 7. Lo descubrimos al verificar las afirmaciones para este documento y preferimos publicarlo antes de que lo encuentre un revisor.
• La alta disponibilidad no está habilitada en la base de datos, la copia de seguridad con redundancia geográfica está desactivada, y nuestros RTO y RPO son objetivos internos y no compromisos contractuales.
• Nuestra prueba de penetración no fue realizada por un tercero acreditado por CREST. La prueba de abril de 2026 no arrojó ningún hallazgo en diez categorías OWASP; no fue una prueba independiente acreditada, y así lo indicamos donde un revisor pueda buscarlo.

Sobre la diferencia entre cumplir y estar certificado

El pack dedica un párrafo a una distinción que en este mercado se confunde habitualmente. Annex 11 y 21 CFR Part 11 son expectativas regulatorias, no esquemas de certificación. Ningún organismo emite un «certificado Annex 11», y un proveedor que lo ofrezca está vendiendo algo que no existe. Lo que sí puede evidenciarse genuinamente es una implementación mapeada cláusula por cláusula con artefactos que respaldan cada fila, que es precisamente lo que contiene el pack.

SOC 2 e ISO 27001 *sí* son esquemas de certificación. No disponemos de ellos. Por tanto, no nos describimos como certificados, y las certificaciones de nuestro proveedor de infraestructura se presentan como suyas y no como nuestras de forma implícita.

Todo su contenido fue verificado, no copiado

Los documentos de cumplimiento se deterioran. Una región de alojamiento cambia, se cierra una brecha, se renombra un control, y el documento sigue describiendo la arquitectura del año pasado con la confianza del año en curso. El nuestro había empezado a hacerlo: un documento interno del QMS seguía describiendo un proveedor de alojamiento del que ya habíamos migrado, y una página de nuestro propio sitio web mencionaba las regiones de Azure incorrectas.

Por ello, cada estado del pack se comprobó contra la infraestructura de producción activa y el código fuente activo el día de la publicación: las regiones leídas desde la suscripción, la política de residencia leída desde su asignación, la configuración de edge leída desde los encabezados de respuesta activos, y el comportamiento de la pista de auditoría y las firmas leído desde el código que los implementa. Cuando la verificación contradijo un documento existente, prevalecieron los datos verificados. Así fue también como encontramos el conjunto de reglas del firewall.

El pack está fechado e incluye un compromiso de revisión: al menos cada seis meses, y se reemite siempre que cambie algún estado en la tabla de certificaciones o en la lista de elementos abiertos.

Si usted es quien debe realizar la evaluación

Existe un documento complementario a este. La Lista de verificación de preparación para auditorías GMP en operaciones de patio es una autoinspección de 101 puntos del perímetro del patio, cuyo dominio final es la cualificación de proveedores de su sistema de gestión de patio. Este pack está redactado para responder a ese dominio, independientemente de si el proveedor que está evaluando somos nosotros.

Si necesita algo que el pack no contiene —el conjunto completo del QMS bajo NDA, evidencia de pruebas ejecutadas, un listado de materiales de software para una versión específica o un CAIQ completado con su propia plantilla— contáctenos en admin@yardtwin.com. La lista de lo disponible bajo solicitud está en el §18.