Публикувахме целия си пакет за гаранция на доставчика — включително това, което все още нямаме

Ето как всъщност протича закупуването на софтуер в регулиран бизнес. Оперативният екип избира инструмента през втората седмица. Отделите по качество и IT сигурност започват прегледа си през четвъртата седмица. Въпросникът достига до доставчика през шестата седмица — четиридесет раздела и заявка за GAMP категоризация, която доставчикът никога не е записвал. Някъде около четиринадесетата седмица всички се договарят, а причината за забавянето никога не е бил самият продукт.

Ние сме преминавали достатъчно пъти през тази ситуация, за да заключим, че последователността е грешна. Затова публикувахме отговорите предварително.

Какво се съдържа в него

Осемнадесет раздела, организирани така, че рецензентът да може да отиде директно към своята част. Рецензентът по качество се нуждае от индекса на СУК, GAMP 5 категоризацията и съответствията с Annex 11 и Part 11. IT сигурността се нуждае от топологията на хостинга, архитектурата на сигурността и CAIQ-Lite. DPO се нуждае от разпределението на ролите администратор-обработващ, регистъра на подизпълнителите и раздела за управление на AI. Отделът по доставки се нуждае от статуса на сертификациите, позицията по непрекъснатост на дейността и разпределението на отговорностите. Пакетът започва с таблица, указваща на всеки от тях кои раздели да прочете.

Съответствията по клаузи са сърцевината на документа. Всяка клауза на Annex 11 — всичките седемнадесет — с описание на нашите действия и местоположението на доказателствата. След това 21 CFR Part 11: контролите по §11.10, разпоредбите за подписи по §11.50 и §11.70, и изискванията за електронен подпис по §11.100, §11.200 и §11.300. Два от тези редове са отбелязани като *ваше* задължение, а не наше, тъй като те не могат да бъдат изпълнени от доставчик — и да се преструваме на противното би оставило пропуск, който се открива едва по време на инспекция.

И какво не се съдържа в него

Това е частта, която направи документа достоен за написване. §13 е таблица с статуси на сертификации, а §17 е пълен списък с отворени точки — и заедно те казват ясно:

• Не притежаваме SOC 2 Type II. Планирана е комбинирана програма с ISO 27001, с реалистични целеви месеци — не твърдение, че одит е в ход.
• Не притежаваме ISO 27001.
• Нашата уеб приложна защитна стена няма прикачен набор от правила. Политиката е в режим на превенция, което звучи успокоително, но без правила не филтрира нищо на ниво 7. Открихме това при проверката на твърденията за настоящия документ и предпочитаме да го публикуваме, вместо рецензент да го открие.
• Висока наличност не е активирана на базата данни, географски резервираното архивиране е изключено, а нашите RTO и RPO са вътрешни цели, а не договорни ангажименти.
• Нашият тест за проникване не е извършен от акредитирана от CREST трета страна. Тестът от април 2026 г. не откри нито един проблем в десет OWASP категории; той не беше акредитиран независим тест и го посочваме там, където рецензентът ще търси.

За разликата между съответствие и сертификация

Разграничение, на което пакетът посвещава отделен параграф, тъй като в този пазар то редовно се размива. Annex 11 и 21 CFR Part 11 са регулаторни изисквания, а не схеми за сертификация. Никой орган не издава "сертификат по Annex 11" и доставчик, който предлага такъв, продава нещо несъществуващо. Това, което наистина може да бъде доказано, е внедряване, съпоставено клауза по клауза с артефакти зад всеки ред — което именно съдържа пакетът.

SOC 2 и ISO 27001 *са* схеми за сертификация. Ние не ги притежаваме. Поради това не се описваме като сертифицирани, а сертификациите на нашия инфраструктурен доставчик са посочени като негови, а не тихомълком представени като наши.

Всичко в него беше проверено, а не копирано

Документите за съответствие остаряват. Регионът на хостинга се сменя, пропуск се отстранява, контрол се преименува — а документът продължава да утвърждава миналогодишната архитектура с тазгодишната увереност. При нас вече се бе стигнало до това: един вътрешен QMS документ все още описваше доставчик на хостинг, от когото бяхме мигрирали, а страница на собствения ни сайт посочваше грешните Azure региони.

Затова всеки статус в пакета беше проверен спрямо живата производствена инфраструктура и живия изходен код в деня на публикуване — регионите бяха прочетени от абонамента, политиката за местоположение на данните — от нейното присвояване, конфигурацията на ръба — от живите заглавки на отговора, поведението на одитния журнал и подписите — от кода, който ги реализира. Там където проверката противоречеше на съществуващ документ, проверката имаше предимство. По този начин открихме и набора от правила за защитната стена.

Пакетът е датиран и съдържа ангажимент за преглед: най-малко на всеки шест месеца, и преиздаван при всяка промяна в таблицата на сертификациите или в списъка с отворени точки.

Ако вие сте този, който трябва да извършва оценката

Към това съществува допълващ материал. Контролният списък за готовност за GMP одит на дворни операции представлява самопроверка от 101 точки на периметъра на двора — като последният му раздел е квалификацията на доставчика на вашата дворна система. Този пакет е създаден, за да отговори на този раздел, независимо дали оценяваният от вас доставчик сме ние.

Ако имате нужда от нещо, което пакетът не съдържа — пълният комплект QMS при NDA, изпълнени тестови доказателства, списък на софтуерните компоненти за конкретна версия или попълнен CAIQ по ваш собствен шаблон — свържете се с нас на admin@yardtwin.com. Списъкът на наличното при заявка е в §18.