Abbiamo Pubblicato il Nostro Intero Vendor Assurance Pack — Incluso Ciò Che Non Abbiamo

Ecco come funziona concretamente l'approvvigionamento software in un'azienda regolamentata. Le Operations scelgono lo strumento nella seconda settimana. Qualità e IT Security avviano la loro revisione nella quarta settimana. Il questionario arriva al fornitore nella sesta settimana — quaranta schede e una richiesta di categorizzazione GAMP che il fornitore non ha mai messo per iscritto. Intorno alla quattordicesima settimana tutti trovano un accordo, e ciò che ha causato i ritardi non è mai stato il prodotto.

Siamo stati abbastanza spesso dall'altra parte per concludere che la sequenza è sbagliata. Perciò abbiamo pubblicato le risposte in anticipo.

Cosa contiene

Diciotto sezioni, organizzate in modo che un revisore possa andare direttamente alla propria parte. Un revisore della qualità ha bisogno dell'indice del QMS, della categorizzazione GAMP 5 e delle mappature di Annex 11 e Part 11. L'IT Security ha bisogno della topologia di hosting, dell'architettura di sicurezza e del CAIQ-Lite. Un DPO ha bisogno della suddivisione controller-processor, del registro dei sub-responsabili del trattamento e della sezione sulla governance dell'intelligenza artificiale. Il procurement ha bisogno dello stato delle certificazioni, della postura di continuità operativa e della suddivisione delle responsabilità. Il documento si apre con una tabella che indica a ciascuno quali sezioni leggere.

Le mappature delle clausole ne sono il nucleo. Ogni clausola di Annex 11 — tutte e diciassette — con le nostre azioni corrispondenti e il riferimento alle evidenze. Poi 21 CFR Part 11: i controlli §11.10, le disposizioni sulle firme di §11.50 e §11.70, e i requisiti per le firme elettroniche di §11.100, §11.200 e §11.300. Due di quelle righe sono contrassegnate come obbligo *vostro* anziché nostro, perché non possono essere adempiute da un fornitore, e fingere il contrario lascerebbe una lacuna che emerge solo durante un'ispezione.

E cosa non contiene

Questa è la parte che ha reso il documento degno di essere scritto. Il §13 è una tabella dello stato delle certificazioni e il §17 è un elenco completo delle questioni aperte; tra i due, affermano chiaramente:

• Non siamo in possesso della SOC 2 Type II. È previsto un programma combinato con ISO 27001, con mesi obiettivo realistici, non l'affermazione che un audit sia in corso.
• Non siamo in possesso della ISO 27001.
• Il nostro web application firewall non ha alcun set di regole associato. La policy è in modalità Prevention, il che sembra rassicurante ma, senza regole, non filtra nulla al livello 7. Lo abbiamo scoperto durante la verifica delle dichiarazioni per questo documento e preferiamo pubblicarlo piuttosto che lasciare che lo trovi un revisore.
• L'alta disponibilità non è abilitata sul database, il backup georidondante è disattivato e i nostri RTO e RPO sono obiettivi interni piuttosto che impegni contrattuali.
• Il nostro penetration testing non è stato eseguito da una terza parte accreditata CREST. Il test di aprile 2026 non ha rilevato alcuna anomalia nelle dieci categorie OWASP; non si trattava di un test indipendente accreditato, e lo diciamo esplicitamente dove un revisore cerca queste informazioni.

Sulla differenza tra conforme e certificato

Il pacchetto dedica un paragrafo a questa distinzione, perché viene abitualmente confusa in questo mercato. Annex 11 e 21 CFR Part 11 sono requisiti normativi, non schemi di certificazione. Nessun ente rilascia un "certificato Annex 11", e un fornitore che ne offra uno sta vendendo qualcosa che non esiste. Ciò che può essere genuinamente dimostrato è un'implementazione mappata clausola per clausola con artefatti a supporto di ogni riga — che è esattamente ciò che il pacchetto contiene.

SOC 2 e ISO 27001 *sono* schemi di certificazione. Non li possediamo. Pertanto non ci descriviamo come certificati, e le certificazioni del nostro provider infrastrutturale sono elencate come tali, senza essere presentate tacitamente come nostre.

Tutto ciò che contiene è stato verificato, non copiato

I documenti di conformità invecchiano male. Una regione di hosting cambia, una lacuna viene colmata, un controllo viene rinominato, e il documento continua ad affermare l'architettura dell'anno scorso con la sicurezza di quest'anno. Il nostro aveva iniziato a farlo: un documento interno del QMS descriveva ancora un provider di hosting da cui avevamo migrato, e una pagina del nostro stesso sito indicava le regioni Azure errate.

Pertanto ogni stato riportato nel pacchetto è stato verificato rispetto all'infrastruttura di produzione live e al codice sorgente live nel giorno della pubblicazione — le regioni lette dalla sottoscrizione, la policy di residenza letta dalla sua assegnazione, la configurazione edge letta dagli header di risposta live, il comportamento della audit trail e delle firme letto dal codice che le implementa. Dove la verifica contraddiceva un documento esistente, ha prevalso la verifica. È anche così che abbiamo scoperto il set di regole del firewall.

Il pacchetto è datato e include un impegno di revisione: almeno ogni sei mesi, e viene riemesso ogni volta che uno stato nella tabella delle certificazioni o nell'elenco delle questioni aperte cambia.

Se sei tu quello che deve eseguire la valutazione

Esiste un documento complementare a questo. La Yard Operations GMP Audit Readiness Checklist è un'ispezione autonoma in 101 punti del perimetro del yard — e il suo dominio finale riguarda la qualifica dei fornitori del vostro sistema di yard management. Questo pacchetto è scritto per rispondere a quel dominio, indipendentemente dal fatto che il fornitore che state valutando sia noi o meno.

Se avete bisogno di qualcosa che il pacchetto non contiene — il set completo del QMS sotto NDA, evidenze di test eseguiti, un software bill of materials per una release nominata, o un CAIQ compilato nel vostro template — contattateci all'indirizzo admin@yardtwin.com. L'elenco di ciò che è disponibile su richiesta si trova al §18.