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.

*Atualizado em 12 de outubro de 2026: o pack é reeditado como v1.2 após cada estado ter sido reverificado em relação ao código-fonte em execução em produção, à configuração Azure em vigor e às nossas páginas públicas. A Versão 1.1 (23 de agosto de 2026) e a sua edição de redação apenas 1.1.1 exageraram vários controlos; a v1.2 corrige-os e lista cada correção. Onde algo não pôde ser verificado, o pack assinala-o e apresenta-o na sua forma mais conservadora.*

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 detemos SOC 2. Uma certificação SOC 2 pode ser considerada mediante pedido do cliente após a obtenção da ISO 27001 — para uma base de clientes europeia, a ISO 27001 é o certificado que as revisões de fornecedores solicitam em primeiro lugar.
• Ainda não detemos a ISO 27001. O ISMS foi aberto em agosto de 2026; a auditoria de certificação de Fase 2 está prevista para fevereiro de 2027 e o certificado tem como objetivo o primeiro trimestre de 2027. Até que o certificado exista, o pack indica *não detida*.
• A nossa firewall de aplicação web executa cinco regras personalizadas de limitação de taxa, mas nenhum conjunto de regras OWASP gerido. O nível Standard do Front Door não permite associar um — isso requer o nível Premium, previsto para a reformulação da produção.
• A alta disponibilidade não está ativada na base de dados, e os nossos RTO e RPO são objetivos internos e não compromissos contratuais; a disponibilidade mensal de 99,5% nos planos pagos é contratual. O exercício de restauro é executado e evidenciado (um restauro completo de produção medido em menos de 7 minutos), e as cópias de segurança mensais encriptadas são mantidas até 7 anos ao abrigo de uma política de imutabilidade temporal que bloqueia a eliminação e substituição (política ainda não bloqueada).
• Ainda não foi realizado nenhum teste de penetração independente. Está planeado um, com reteste, e o seu âmbito está preparado. A nossa auditoria interna de código white-box em outubro de 2026 identificou vulnerabilidades, incluindo duas Críticas; ambas as descobertas Críticas estão corrigidas em produção. O trabalho de abril de 2026 foi um teste de segurança funcional interno, não um teste de penetração.

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 do pacote foi verificado no dia da publicação em relação ao código-fonte em execução em produção, à configuração Azure ativa e às nossas páginas públicas — 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 dos cabeçalhos de resposta em direto, o comportamento do registo de auditoria e de assinatura lido a partir do código que os implementa. Sempre que a verificação contradisse um documento existente, a verificação prevaleceu. Foi assim que surgiu a v1.2: a revisão da v1.1 revelou afirmações que nunca tinham sido verdadeiras, e esta edição corrige-as.

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.