Publicámos o Nosso Vendor Assurance Pack Completo — Incluindo o Que Ainda Não Temos

Eis como a aquisição de software funciona na prática numa empresa regulada. A operação escolhe a ferramenta na semana dois. A qualidade e a segurança informática iniciam a revisão na semana quatro. O questionário chega ao fornecedor na semana seis — quarenta separadores, e um pedido de categorização GAMP que o fornecedor nunca registou por escrito. Por volta da semana catorze toda a gente chega a acordo, e o que atrasou o processo nunca foi o produto.

Já passámos por isso vezes suficientes para concluir que a sequência está errada. Por isso publicámos as respostas antecipadamente.

O que contém

Dezoito secções, organizadas para que um revisor possa ir diretamente à sua parte. Um revisor de qualidade precisa do índice do QMS, da categorização GAMP 5 e dos mapeamentos do Annex 11 e Part 11. A segurança informática precisa da topologia de alojamento, da arquitetura de segurança e do CAIQ-Lite. Um DPO precisa da divisão responsável-processador, do registo de subprocessadores e da secção de governação de IA. A aquisição precisa do estado de certificação, da postura de continuidade e da divisão de responsabilidades. O documento começa com uma tabela que indica a cada um deles quais as secções a ler.

Os mapeamentos de cláusulas são o seu núcleo. Cada cláusula do Annex 11 — todas as dezassete — com o que fazemos a esse respeito e onde se encontram as evidências. Depois o 21 CFR Part 11: os controlos §11.10, as disposições sobre assinaturas do §11.50 e §11.70, e os requisitos de assinatura eletrónica do §11.100, §11.200 e §11.300. Duas dessas linhas estão marcadas como obrigação *sua* e não nossa, porque não podem ser cumpridas por um fornecedor, e fingir o contrário deixaria uma lacuna que só se deteta durante uma inspeção.

E o que não contém

Esta é a parte que tornou o documento digno de ser escrito. O §13 é uma tabela de estado de certificações e o §17 é uma lista completa de itens em aberto, e entre eles afirmam claramente:

• Não possuímos SOC 2 Type II. Está planeado um programa combinado com ISO 27001, com meses-alvo realistas — não uma afirmação de que uma auditoria está em curso.
• Não possuímos ISO 27001.
• A nossa firewall de aplicação web não tem nenhum conjunto de regras associado. A política está em modo de Prevenção, o que parece tranquilizador mas, sem regras, não filtra nada na camada 7. Descobrimos isto ao verificar as afirmações para este documento, e preferimos publicá-lo a deixar que um revisor o encontre.
• A alta disponibilidade não está ativada na base de dados, a cópia de segurança georredundante está desativada, e os nossos RTO e RPO são objetivos internos e não compromissos contratuais.
• Os nossos testes de penetração não foram realizados por uma entidade terceira acreditada pela CREST. O teste de abril de 2026 não registou quaisquer achados em dez categorias OWASP; não foi um teste independente acreditado, e dizemo-lo onde um revisor procura.

Sobre a diferença entre conforme e certificado

O pacote dedica um parágrafo a uma distinção que é sistematicamente ignorada neste mercado. Annex 11 e 21 CFR Part 11 são requisitos regulatórios, não esquemas de certificação. Nenhum organismo emite um "certificado Annex 11", e um fornecedor que ofereça um está a vender algo que não existe. O que pode genuinamente ser evidenciado é uma implementação mapeada cláusula a cláusula com artefactos por detrás de cada linha — que é precisamente o que o pacote contém.

SOC 2 e ISO 27001 *são* esquemas de certificação. Não os possuímos. Por isso, não nos descrevemos como certificados, e as certificações do nosso fornecedor de infraestrutura são apresentadas como sendo dele e não discretamente como nossas.

Tudo o que contém foi verificado, não copiado

Os documentos de conformidade deterioram-se. Uma região de alojamento muda, uma lacuna é colmatada, um controlo é renomeado, e o documento continua a afirmar a arquitetura do ano passado com a confiança deste ano. O nosso tinha começado a fazê-lo: um documento interno do QMS ainda descrevia um fornecedor de alojamento do qual migrámos, e uma página do nosso próprio site descrevia as regiões Azure erradas.

Assim, cada estado no pacote foi verificado contra a infraestrutura de produção em vigor e o código-fonte em vigor no dia da publicação — regiões lidas a partir da subscrição, a política de residência lida a partir da sua atribuição, a configuração de edge lida a partir de cabeçalhos de resposta em direto, o comportamento da trilha de auditoria e de assinaturas lido a partir do código que os implementa. Onde a verificação contrariou um documento existente, prevaleceu a verificação. Foi assim também que encontrámos o conjunto de regras da firewall.

O pacote tem data e inclui um compromisso de revisão: pelo menos de seis em seis meses, e reeditado sempre que um estado na tabela de certificações ou na lista de itens em aberto se altere.

Se é você quem tem de fazer a avaliação

Existe um documento complementar. A Checklist de Preparação para Auditoria GMP de Operações de Pátio é uma autoinspecção de 101 verificações ao perímetro do pátio — e o seu domínio final é a qualificação de fornecedores do seu sistema de gestão de pátio. Este pacote foi elaborado para responder a esse domínio, independentemente de o fornecedor que está a avaliar ser ou não a nossa empresa.

Se necessitar de algo que o pacote não contenha — o conjunto completo do QMS sob NDA, evidências de testes executados, uma lista de materiais de software para uma versão específica, ou um CAIQ preenchido no seu próprio modelo — contacte-nos em admin@yardtwin.com. A lista do que está disponível mediante pedido encontra-se no §18.