We hebben ons volledige Vendor Assurance Pack gepubliceerd — inclusief wat we nog niet hebben

Zo verloopt softwareaanschaf in de praktijk binnen een gereguleerd bedrijf. Operations kiest de tool in week twee. Kwaliteit en IT-beveiliging beginnen hun beoordeling in week vier. De vragenlijst bereikt de leverancier in week zes — veertig tabbladen, en een verzoek om een GAMP-categorisering die de leverancier nooit op papier heeft gezet. Ergens rond week veertien is iedereen het eens, en het was nooit het product dat het vertraagde.

We hebben dit vaak genoeg van de ontvangende kant meegemaakt om te concluderen dat de volgorde verkeerd is. Daarom hebben we de antwoorden vooraf gepubliceerd.

Wat erin staat

Achttien secties, georganiseerd zodat een beoordelaar direct naar zijn of haar eigen onderdeel kan gaan. Een kwaliteitsbeoordelaar heeft de QMS-index, de GAMP 5-categorisering en de Annex 11- en Part 11-koppelingen nodig. IT-beveiliging heeft de hostingtopologie, de beveiligingsarchitectuur en de CAIQ-Lite nodig. Een DPO heeft de verwerkingsverantwoordelijke-verwerkersverdeling, het sub-verwerkerregister en de AI-governancesectie nodig. Inkoop heeft de certificeringsstatus, de continuïteitspositie en de verantwoordelijkheidsverdeling nodig. Het pack opent met een tabel die elk van hen vertelt welke secties ze moeten lezen.

De clausulekoppelingen vormen de kern ervan. Elke clausule van Annex 11 — alle zeventien — met wat wij daaraan doen en waar het bewijsmateriaal zich bevindt. Vervolgens 21 CFR Part 11: de §11.10-maatregelen, de handtekeningbepalingen van §11.50 en §11.70, en de vereisten voor elektronische handtekeningen van §11.100, §11.200 en §11.300. Twee van die rijen zijn gemarkeerd als *uw* verplichting in plaats van de onze, omdat ze niet door een leverancier kunnen worden nagekomen, en het anders voorstellen zou een leemte achterlaten die pas tijdens een inspectie aan het licht komt.

En wat er niet in staat

Dit is het onderdeel dat het document de moeite waard maakte om te schrijven. §13 is een tabel met certificeringsstatus en §17 is een volledige lijst van openstaande punten, en samen zeggen ze duidelijk:

• Wij beschikken niet over SOC 2 Type II. Een gecombineerd programma met ISO 27001 is gepland, met realistische doelmaanden — geen bewering dat er al een audit loopt.
• Wij beschikken niet over ISO 27001.
• Onze web application firewall heeft geen regelset gekoppeld. Het beleid staat in Prevention-modus, wat geruststellend klinkt, maar zonder regels wordt er niets gefilterd op laag 7. Dit hebben we ontdekt tijdens de verificatie van claims voor dit document, en we publiceren het liever dan dat een beoordelaar het vindt.
• Hoge beschikbaarheid is niet ingeschakeld op de database, geo-redundante back-up is uitgeschakeld, en onze RTO en RPO zijn interne doelstellingen in plaats van contractuele verplichtingen.
• Onze penetratietest is niet uitgevoerd door een CREST-geaccrediteerde derde partij. De test van april 2026 leverde nul bevindingen op in tien OWASP-categorieën; het was geen geaccrediteerde onafhankelijke test, en dat vermelden we daar waar een beoordelaar kijkt.

Over het verschil tussen compliant en gecertificeerd

Eén onderscheid waaraan het pakket een alinea besteedt, omdat het in deze markt routinematig wordt vervaagd. Annex 11 en 21 CFR Part 11 zijn regulatoire verwachtingen, geen certificeringsschema's. Geen enkele instantie geeft een 'Annex 11-certificaat' af, en een leverancier die er een aanbiedt verkoopt iets dat niet bestaat. Wat wel aantoonbaar is, is een implementatie die clausule voor clausule is uitgewerkt met bewijsmateriaal achter elke rij — en dat is wat het pakket bevat.

SOC 2 en ISO 27001 *zijn* certificeringsschema's. Wij beschikken hier niet over. Daarom beschrijven wij onszelf niet als gecertificeerd, en de certificeringen van onze infrastructuurprovider worden als die van hen vermeld — niet stilzwijgend als de onze gepresenteerd.

Alles is geverifieerd, niet gekopieerd

Compliancedocumenten verouderen. Een hostingregio verandert, een tekortkoming wordt opgelost, een maatregel krijgt een nieuwe naam — en het document blijft de architectuur van vorig jaar beschrijven met het vertrouwen van dit jaar. Bij ons was dat al aan het gebeuren: een intern QMS-document beschreef nog een hostingprovider waarvandaan we waren gemigreerd, en een pagina op onze eigen site vermeldde de verkeerde Azure-regio's.

Elke status in het pakket is daarom op de dag van publicatie gecontroleerd aan de hand van live productie-infrastructuur en live broncode — regio's uitgelezen vanuit het abonnement, het gegevensresidentiebeleid uitgelezen vanuit de toewijzing, de edge-configuratie uitgelezen vanuit live response headers, en het gedrag van audittrail en handtekeningen uitgelezen vanuit de code die ze implementeert. Waar de verificatie in strijd was met een bestaand document, heeft de verificatie gewonnen. Zo hebben we ook de firewall-regelset gevonden.

Het pakket is gedateerd en bevat een reviewverplichting: minimaal elke zes maanden, en opnieuw uitgegeven wanneer een status in de certificeringstabel of de lijst van openstaande punten wijzigt.

Als u degene bent die de beoordeling moet uitvoeren

Er is een aanvullend document bij dit pakket. De Yard Operations GMP Audit Readiness Checklist is een zelfinspectie met 101 controlepunten langs de grens van het terrein — en het laatste domein betreft de leveranciersbeoordeling van uw yard-systeemverkoper. Dit pakket is geschreven om dat domein te beantwoorden, ongeacht of de leverancier die u beoordeelt wij zijn.

Als u iets nodig heeft dat het pakket niet bevat — de volledige QMS-set onder NDA, uitgevoerd testmateriaal, een software bill of materials voor een aangewezen release, of een CAIQ ingevuld in uw eigen sjabloon — neem dan contact op via admin@yardtwin.com. De lijst van wat op aanvraag beschikbaar is, staat in §18.