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

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

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

*Актуализирано на 12 октомври 2026 г.: пакетът е преиздаден като v1.2, след като всеки статус беше повторно потвърден спрямо изходния код, работещ в production, активната конфигурация на Azure и нашите публични страници. Версия 1.1 (23 август 2026 г.) и нейното издание само с промени в текста 1.1.1 са надценили няколко контрола; v1.2 ги коригира и изброява всяка корекция. Където нещо не може да бъде потвърдено, пакетът го отбелязва и го представя в по-слабата му форма.*

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

Осемнадесет раздела, организирани така, че рецензентът да може да отиде директно към своята част. Рецензентът по качество се нуждае от индекса на СУК, 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. Ангажимент за SOC 2 може да бъде разгледан по искане на клиент, след като ISO 27001 е въведен — за европейска клиентска база ISO 27001 е сертификатът, който прегледите на доставчици изискват на първо място.
• Все още не разполагаме с ISO 27001. СУСИ беше открита през август 2026 г.; одитът за сертификация Stage 2 е планиран за февруари 2027 г., а сертификатът се очаква за Q1 2027 г. До издаването на сертификата пакетът отбелязва *не е получен*.
• Нашата уеб приложна защитна стена работи с пет персонализирани правила за ограничаване на честотата, но без управляван набор от правила на OWASP. Нивото Standard на Front Door не позволява прикачване на такъв — за това е необходимо ниво Premium, което е планирано с реконструкцията на production средата.
• Висока наличност не е активирана на базата данни, а нашите RTO и RPO са вътрешни цели, а не договорни ангажименти; месечната наличност от 99,5% при платени планове е договорна. Упражнението за възстановяване се изпълнява и документира (пълно production възстановяване, измерено под 7 минути), а месечните криптирани резервни копия се съхраняват до 7 години съгласно политика за неизменност, основана на времето, която блокира изтриването и презаписването (политиката все още не е заключена).
• Все още не е извършен независим тест за проникване. Такъв е планиран, заедно с повторно тестване, и обхватът му е подготвен. Нашият вътрешен одит на кода (white-box) от октомври 2026 г. откри уязвимости, включително две с ниво Critical; и двете Critical констатации са отстранени в production. Работата от април 2026 г. беше вътрешно функционално тестване на сигурността, а не тест за проникване.

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

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

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

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

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

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

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

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

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

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