Vi Publicerade Hela Vår Vendor Assurance Pack — Inklusive Det Vi Inte Har
Så här fungerar mjukvaruupphandling i verkligheten inom en reglerad verksamhet. Driften väljer verktyget i vecka två. Kvalitet och IT-säkerhet inleder sin granskning i vecka fyra. Frågeformuläret når leverantören i vecka sex — fyrtio flikar, och en begäran om en GAMP-kategorisering som leverantören aldrig skrivit ned. Någonstans kring vecka fjorton är alla överens, och det som försenade processen var aldrig produkten.
Vi har befunnit oss i den situationen tillräckligt många gånger för att dra slutsatsen att ordningsföljden är fel. Därför publicerar vi svaren i förväg.
- QMS-dokumentregister, GAMP 5-kategorisering och valideringsmetodik
- EU GMP Annex 11 och 21 CFR Part 11 mappade klausul för klausul, med bevis
- ALCOA+-utlåtande, lagringsschema, GDPR och register över underbiträden
- Säkerhetsarkitektur, bevis för säker utveckling och en ifylld CAIQ-Lite
- En fullständig lista över öppna punkter — allt vi ännu inte har gjort, med våra egna allvarlighetsgraderingar
Vad som ingår
Arton avsnitt, organiserade så att en granskare kan gå direkt till sin del. En kvalitetsgranskare behöver QMS-registret, GAMP 5-kategoriseringen samt Annex 11- och Part 11-mappningarna. IT-säkerhet behöver värdtopologin, säkerhetsarkitekturen och CAIQ-Lite. En DPO behöver uppdelningen mellan personuppgiftsansvarig och biträde, registret över underbiträden och avsnittet om AI-styrning. Inköp behöver certifieringsstatus, kontinuitetsställning och ansvarsfördelning. Paketet inleds med en tabell som anger vilka avsnitt respektive granskare ska läsa.
Klausulmappningarna är kärnan. Varje klausul i Annex 11 — alla sjutton — med vad vi gör avseende den och var bevisningen finns. Sedan 21 CFR Part 11: §11.10-kontrollerna, signaturbestämmelserna i §11.50 och §11.70, samt kraven på elektroniska signaturer i §11.100, §11.200 och §11.300. Två av dessa rader är markerade som *ditt* ansvar snarare än vårt, eftersom de inte kan uppfyllas av en leverantör, och att låtsas något annat skulle lämna en lucka som bara uppdagas vid en inspektion.
Och vad som inte ingår
Det här är den del som gjorde dokumentet värt att skriva. §13 är en tabell över certifieringsstatus och §17 är en komplett lista över öppna punkter, och tillsammans säger de tydligt:
- Vi innehar inte SOC 2 Type II. Ett kombinerat program med ISO 27001 är planerat, med realistiska målmånader – inte ett påstående om att en revision pågår.
- Vi innehar inte ISO 27001.
- Vår brandvägg för webbapplikationer saknar kopplad regeluppsättning. Policyn är inställd på Prevention-läge, vilket låter betryggande men filtrerar utan regler ingenting på lager 7. Vi upptäckte detta när vi verifierade uppgifterna inför detta dokument, och vi väljer att publicera det snarare än att låta en granskare hitta det.
- Hög tillgänglighet är inte aktiverat på databasen, geo-redundant säkerhetskopiering är inaktiverat, och våra RTO- och RPO-värden är interna mål snarare än avtalsenliga åtaganden.
- Vår penetrationstestning utfördes inte av en CREST-ackrediterad tredje part. Testet i april 2026 visade noll fynd inom tio OWASP-kategorier; det var inte ett ackrediterat oberoende test, och det framgår tydligt där en granskare tittar.
Om skillnaden mellan regelefterlevnad och certifiering
En distinktion som paketet ägnar ett stycke åt, eftersom den rutinmässigt suddas ut på denna marknad. Annex 11 och 21 CFR Part 11 är regulatoriska förväntningar, inte certifieringssystem. Inget organ utfärdar ett "Annex 11-certifikat", och en leverantör som erbjuder ett säljer något som inte existerar. Det som verkligen kan styrkas är en implementation kartlagd klausul för klausul med underlag bakom varje rad – vilket är vad paketet innehåller.
SOC 2 och ISO 27001 *är* certifieringssystem. Vi innehar dem inte. Vi beskriver oss därför inte som certifierade, och vår infrastrukturleverantörs certifieringar redovisas som deras egna snarare än att tyst presenteras som våra.
Allt i det verifierades, kopierades inte
Efterlevnadsdokument åldras dåligt. En värdregion ändras, en brist åtgärdas, en kontroll byter namn, och dokumentet fortsätter att hävda förra årets arkitektur med årets tillförsikt. Vårt hade börjat göra det: ett internt QMS-dokument beskrev fortfarande en värdleverantör vi migrerat bort ifrån, och en sida på vår egen webbplats angav fel Azure-regioner.
Därför kontrollerades varje status i paketet mot live-produktionsinfrastruktur och levande källkod på publiceringsdagen – regioner avlästa från prenumerationen, residenspolicyn avläst från sin tilldelning, edge-konfigurationen avläst från live-svarshuvuden, granskningsspårets och signaturernas beteende avläst från koden som implementerar dem. Där verifieringen motsade ett befintligt dokument vann verifieringen. Det är också hur vi hittade brandväggens regeluppsättning.
Paketet är daterat och innehåller ett granskningsåtagande: minst var sjätte månad, och återutgivet när en status i certifieringstabellen eller listan över öppna punkter ändras.
Om du är den som ska utföra bedömningen
Det finns ett kompletterande dokument till detta. Yard Operations GMP Audit Readiness Checklist är en självinspektion med 101 kontroller längs gårdens gräns – och dess sista domän är leverantörskvalificering av er gårdshanteringsleverantör. Det här paketet är skrivet för att besvara den domänen, oavsett om leverantören ni bedömer är vi eller inte.
Om ni behöver något som paketet inte innehåller – fullständig QMS-dokumentation under NDA, utfört testunderlag, en mjukvaruförteckning för en specificerad release, eller en CAIQ ifylld i er egen mall – kontakta oss på admin@yardtwin.com. Listan över vad som finns tillgängligt på begäran finns i §18.
Utvärderar du gårdshanteringsplattformar för en reglerad anläggning? Starta en kostnadsfri 30-dagars provperiod och underkasta produkten samma granskning som dokumentationen.