Ми опублікували весь наш Vendor Assurance Pack — включно з тим, чого у нас ще немає

Ось як насправді відбувається закупівля програмного забезпечення у регульованому бізнесі. Операційний відділ обирає інструмент на другому тижні. Відділ якості та IT-безпека розпочинають перевірку на четвертому. Анкета потрапляє до постачальника на шостому тижні — сорок вкладок і запит на категоризацію GAMP, яку постачальник ніколи не фіксував письмово. Десь до чотирнадцятого тижня всі доходять згоди, і затримка ніколи не була пов'язана з самим продуктом.

Ми досить часто опинялися на стороні отримувача таких запитів, щоб дійти висновку: послідовність хибна. Тому ми заздалегідь публікуємо відповіді.

*Оновлено 12 жовтня 2026: пакет перевидано як v1.2 після повторної перевірки кожного статусу відповідно до вихідного коду, що працює у виробництві, поточної конфігурації Azure та наших публічних сторінок. Версія 1.1 (23 серпня 2026) та її редакція лише зі змінами формулювань 1.1.1 перебільшували кілька засобів контролю; v1.2 виправляє їх і наводить кожне виправлення. Там, де перевірку здійснити не вдалося, пакет позначає це та формулює відповідне положення в більш обережній формі.*

Що міститься всередині

Вісімнадцять розділів, організованих так, щоб рецензент міг одразу перейти до свого блоку. Спеціаліст із якості потребує індексу QMS, категоризації GAMP 5 та маппінгів Annex 11 і Part 11. IT-безпека — топології хостингу, архітектури безпеки та CAIQ-Lite. DPO — розподілу відповідальності контролера й процесора, реєстру субпроцесорів і розділу щодо управління ШІ. Закупівля — статусу сертифікації, позиції щодо безперервності діяльності та розподілу відповідальності. Документ відкривається таблицею, яка вказує кожному з них, які розділи читати.

Маппінги положень — це основа документа. Кожне положення 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, який заплановано під час перебудови виробничого середовища.
• Висока доступність не увімкнена для бази даних, а наші RTO та RPO є внутрішніми цілями, а не договірними зобов'язаннями; місячна доступність 99,5% для платних планів є договірною. Відпрацювання відновлення виконано та задокументовано (повне відновлення виробничого середовища займає менше 7 хвилин), а щомісячні зашифровані резервні копії зберігаються до 7 років відповідно до часової політики незмінності, яка блокує видалення та перезапис (політику ще не заблоковано).
• Незалежне тестування на проникнення ще не проводилося. Воно заплановано разом із повторним тестуванням, і його обсяг підготовлено. Наш внутрішній аудит коду методом «білої скриньки» у жовтні 2026 року виявив вразливості, зокрема дві категорії Critical; обидві знайдені проблеми критичного рівня усунено у виробничому середовищі. Роботи у квітні 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.