Електронні підписи

Ця тема є частиною SG Systems Global глосарій нормативних та операційних термінів.

Оновлено у грудні 2025 р. • Частина 11 / Додаток 11 Контроль, затвердження та атрибуція • Забезпечення якості, відповідність вимогам, ІТ, операції

Електронні підписи – це юридично значущі затвердження та підписання, що виконуються в електронній системі, де подія підпису однозначно пов’язана з конкретною особою та пов’язана з певним записом і значенням (наприклад, «переглянуто», «затверджено», «виконано», «випущено»). У регульованих системах виробництва та якості електронний підпис – це не просто прапорець або надруковане ім’я. Це контрольована подія, яка має підтвердити особу , намір та зв’язок запису , щоб підписаний запис був надійним та захищеним під час аудитів та розслідувань. Саме тому електронні підписи тісно пов’язані з 21 CFR Part 11 , EU Annex 11 , цілісністю даних та відповідністю аудиторського журналу , який фіксує, хто підписав, що вони підписали, коли вони підписали та що означав підпис.

Електронні підписи важливі, оскільки вони перетворюють електронні записи на докази відповідності. Якщо підписи слабкі — спільні облікові записи, неоднозначне значення, відсутнє посилання на авторство або записи, які можна редагувати після підписання — тоді систему важко захистити, навіть якщо базовий процес хороший. Надійні електронні підписи дозволяють вести безпаперові операції, швидші цикли випуску, контрольовані робочі процеси та надійну підзвітність під час пакетного виконання ( eBMR ), відхилень, CAPA, контролю документів, навчання та рішень щодо постачальників/якості. Мета проста: електронний запис повинен мати таку ж надійність, як і підписаний паперовий запис — часто навіть кращу — оскільки докази мають позначку часу та простежуються.

«Електронний підпис цінний лише тоді, коли він підтверджує особу, намір та нерозривний зв’язок із точним записом, який було підписано».

1) Що насправді доводить електронний підпис

Відповідний електронний підпис повинен підтверджувати три речі:

• Ідентичність: підписант однозначно ідентифікований (спільні облікові дані відсутні) та автентифікований.
• Намір: підписант мав намір підписати та зрозумів значення підпису (перевірено/затверджено/виконано/опубліковано).
• Прив'язка запису: Підпис пов'язаний з конкретним записом у момент підписання та не може бути відокремлений або неправильно накладений.

Коли ці елементи присутні, електронний підпис стає сильнішим за власноручний, оскільки він має позначку часу, атрибутивний та пов’язаний із системним контекстом (роллю, кроком робочого процесу, версією запису). Коли ці елементи відсутні, «електронний підпис» стає лише артефактом інтерфейсу користувача зі слабкою доказовою цінністю.

2) Електронні підписи проти електронних записів

Електронний запис – це самі дані: запис партії, відхилення, CAPA, результат тесту, контрольований документ, завершення навчання. Електронний підпис – це дія затвердження або атестації, що застосовується до цього запису. Ці два елементи повинні працювати разом. Запис без контрольованого підпису може бути неповним для випуску. Підпис без контрольованого запису не має значення.

Ось чому Частину 11 часто називають «електронними записами та електронними підписами». Ви повинні контролювати запис (цілісність, зберігання, журнали аудиту) та підпис (ідентичність, намір, зв'язування). Якщо одна сторона слабка, система дотримання вимог руйнується.

3) Чому електронні підписи існують у регульованих операціях

Електронні підписи існують тому, що регульоване виробництво побудовано на задокументованих рішеннях. Схвалення визначають, що дозволено: які кроки партії були виконані, які відхилення прийняті, які CAPA закриті, які специфікації є чинними, які партії випущені. Без підписів рішення неоднозначні. З підписами рішення стають такими, що можуть бути пов'язані між собою, та такими, що можуть бути захищені.

Електронні підписи також дозволяють вести безпаперові операції та зменшують тертя в процесі. Замість друку та сканування форм, організація може фіксувати підписи в момент дії, з негайним посиланням на запис та журнал аудиту. Якщо все зробити правильно, це покращує як дотримання вимог, так і ефективність, оскільки зменшує помилки транскрипції та скорочує часовий проміжок між дією та документуванням.

4) Значення підпису: «Переглянуто» не те саме, що «Схвалено»

Значення підпису – одна з найбільш недооцінених вимог. Підпис повинен мати чітко визначений намір. Найпоширеніші наміри підпису включають:

• Виконано: «Я виконав цей крок/дію».
• Підтверджено: «Я підтвердив, що цей результат/крок відповідає вимогам».
• Переглянуто: «Я переглянув запис і вважаю його прийнятним».
• Схвалено: «Я схвалюю використання цього запису/рішення».
• Випущено: «Я передаю цю партію/партію/документ наступному штату».

Система повинна робити значення чітким та послідовним. Якщо все просто «підписано», підпис є слабким, оскільки незрозуміло, що засвідчив підписувач. Сильні системи фіксують значення підпису як метадані та чітко відображають його в записі та журналах аудиту.

5) Контроль автентифікації: забезпечення захисту ідентичності

Ідентичність є основоположною. Найсильніша програма підпису руйнується, якщо автентифікація слабка. Як мінімум, захищена програма вимагає:

• Унікальні облікові записи користувачів: жодних спільних логінів, жодних загальних облікових записів «операторів».
• Сильна автентифікація: стандарти паролів, багатофакторна автентифікація (MFA), де це доречно, та засоби контролю для скидання налаштувань.
• Контрольоване виділення ресурсів: управляється забезпечення доступу та деініціалізацію.
• Дозволи на основі ролей: підписувати можуть лише авторизовані ролі та лише для дозволених дій (RBAC).

Багато систем також вимагають «повторної автентифікації під час підпису» (наприклад, повторного введення пароля або підтвердження особи) для підписів з високим рівнем впливу, таких як випуск партії або затвердження відхилень. Мета полягає в тому, щоб намір та ідентифікація були чітко визначені в момент підписання, а не лише під час входу в систему.

6) Зв'язування записів та контроль змін після підпису

Підпис має бути пов’язаний зі станом запису на момент підписання. Основна проблема полягає в «редагуванні після підписання». Якщо запис можна змінити після затвердження без можливості відстеження, затвердження втрачає сенс. Захистний підхід зазвичай включає:

• Блокування: Після підписання критичні поля запису блокуються або стають доступними для керування версіями.
• Контроль версій: зміни після підписання вимагають створення нової редакції з новими затвердженнями (зв'язки з контроль документів та контроль змін).
• Видимість журналу аудиту: Будь-які зміни після підписання реєструються та видимі, включаючи того, хто що змінив і чому.
• Логіка анулювання підпису: певні зміни автоматично анулюють попередні підписи та вимагають повторного підписання.

Прив’язка також включає керування вкладеннями. Якщо запис посилається на вкладення (звіти, PDF-файли, зображення), підпис має застосовуватися до пакета записів, а не лише до одного поля.

7) Де використовуються електронні підписи (типові випадки використання)

Електронні підписи використовуються скрізь, де рішення мають бути пов'язані між собою та обґрунтованими. Загальні випадки використання включають:

• Пакетне виконання: завершення кроку, перевірки в процесі, підтвердження проходження лінії та остаточне підписання партії в еБМР.
• Утримувати/відпускати: розміщення та випускання карантин/тримати статус лотів та партій.
• Відхилення та розслідування: затвердження відхилень, висновки розслідування та перевірки ефективності.
• КАПА: Схвалення CAPA, підписання завершення дії та закриття.
• Контроль змін: затвердження запиту на зміни, затвердження впровадження та перевірка після впровадження.
• Контроль документів: Затвердження стандартних операційних процедур (СОП), авторизація дати набрання чинності, затвердження застарілих матеріалів.
• Навчання: підтвердження проходження навчання та компетентності.
• Рішення щодо постачальників та якості: Розпорядження MRB та затвердження коригувальних дій постачальниками.

У кожному випадку підпис має відображати правильне значення та бути обмеженим ролями, щоб неавторизовані користувачі не могли підписувати рішення з високим рівнем ризику.

8) Очікування щодо журналу аудиту для ключових подій

Події підпису повинні бути відстежуваними. Захищений журнал аудиту для електронних підписів зазвичай фіксує:

• Ідентифікація підписанта: ідентифікатор користувача та, де це доречно, друковане ім'я.
• Позначка часу: дата/час підписання (включаючи узгодженість часового поясу).
• Значення: переглянуто/затверджено/виконано/опубліковано.
• Посилання на запис: який запис і яка версія/редакція була підписана.
• Метод автентифікації: чи відбулася повторна автентифікація під час підписання для важливих кроків.

Аудиторів також турбують збої підписів та їх перевизначення: невдалі спроби входу, скасування підписів, скидання паролів та будь-які дії адміністратора, які можуть поставити під загрозу атрибуцію. Саме тому системи підписів повинні бути пов'язані з контрольованим доступом та контролюватися на наявність незвичайних моделей.

9) Поширені режими збоїв (Як електронні підписи стають слабкими)

Програми електронного підпису, як правило, дають збої передбачуваним чином:

• Спільні облікові записи: знищує атрибуцію та робить підписи непридатними для захисту.
• Неоднозначне значення: «підписано» без чітко визначеного наміру.
• Записи, які можна редагувати після підписання: Затвердження втрачають сенс, якщо записи можна змінювати без контрольованого перегляду.
• Надмірно широкі права підписання: занадто багато користувачів можуть схвалювати кроки з високим рівнем впливу, що послаблює розподіл обов'язків.
• Слабке забезпечення: Повзучість ролей та застарілий доступ призводять до можливості несанкціонованого підпису.
• Поганий огляд журналу аудиту: Сигнатурні події існують, але не контролюються; підозрілі закономірності залишаються непоміченими.

Вирішення проблеми полягає в управлінні та дизайні: суворий контроль ідентифікації, чіткий намір підпису, примусові правила блокування/редагування записів та дозволи на основі ролей, узгоджені із системою якості.

10) Практичний план: впровадження захищених електронних підписів

Практичний план впровадження виглядає так:

• 1) Визначте точки підпису: перелічіть, які робочі процеси вимагають підписів (пакетні кроки, випуск, відхилення, CAPA, контроль змін, документи).
• 2) Визначте значення підписів: перевірені/затверджені/виконані/випущені, а також забезпечте їх запис у системі.
• 3) Визначте ролі: зіставити права підпису з ролями та забезпечити розподіл обов'язків.
• 4) Забезпечити контроль ідентифікації: унікальні облікові записи, надійна автентифікація, контрольоване виділення ресурсів.
• 5) Прив’язати підписи до записів: блокувати підписані записи або контролювати їх версії; зберігати вкладення та контекст.
• 6) Зберігати журнали аудиту: події підписів реєструються, переглядаються та зберігаються протягом необхідних періодів.
• 7) Моніторинг та огляд: періодичні перевірки доступу та моніторинг журналу аудиту на наявність аномалій у сигнатурах.

Цей план перетворює електронні підписи на перевагу відповідності, а не на «функцію прапорця». Мета полягає в тому, щоб зробити підписи природними для використання та важкими для неправильного використання.

11) Як це поєднується з V5 від SG Systems Global

Контрольоване виконання та затвердження. На платформі V5 електронні підписи підтримують регульоване виконання в різних модулях: MES покроково підписує в готовому до перевірки eBMR , WMS утримує та випускає об'єкти, а QMS затверджує відхилення, CAPA, MRB та контроль змін. RBAC та контрольоване забезпечення гарантують, що лише авторизовані ролі можуть підписувати певні рішення.

Перевірка. Події підписів фіксуються з атрибуцією, значенням та мітками часу, що зміцнює журнали аудиту та підтримує докази, узгоджені з Частиною 11/Додатком 11. Записи можна блокувати або контролювати на редагування, щоб підписи залишалися прив'язаними до правильного стану запису.

Підсумок: V5 використовує електронні підписи для забезпечення підзвітності та захисту цілісності даних, перетворюючи схвалення на захищені, готові до перевірки докази без паперової обробки.

12) FAQ

Q1. Чи є електронні підписи юридично дійсними?
У багатьох регульованих контекстах так — за умови впровадження належного контролю за ідентифікацією, намірами та зв’язком записів, а також за умови узгодження з чинними правилами та політиками організації.

Q2. Чи вимагають електронні підписи повторного введення пароля?
Часто для підписів з високим рівнем впливу. Деякі системи вимагають повторної автентифікації в момент підписання, щоб чітко визначити намір. Конкретний підхід має відповідати вашій моделі ризиків та регуляторним очікуванням.

Q3. Чи можна змінити підписаний запис пізніше?
Його не повинно бути можна змінити без можливості відстеження. Зазвичай підписані записи блокуються, або зміни вимагають нового перегляду та повторного затвердження, з повним журналом аудиту, який показує, що змінилося і чому.

Q4. Що найшвидше зламує електронні підписи?
Спільні облікові записи, неоднозначне значення підпису, широкі дозволи на підписання без розподілу обов'язків та можливість редагування записів після підписання без контрольованого перегляду.

Q5. Де електронні підписи слід використовувати в першу чергу?
Почніть з контрольних точок високого значення: завершення та випуск етапів партії, схвалення відхилень/CAPA, схвалення контролю змін та схвалення контрольованих документів. Це підписи, на які найбільше покладаються аудитори та розслідування.

Q6. Що має бути зафіксовано в журналі аудиту для підпису?
Хто підписав, коли, який запис/версію було підписано, що означав підпис та (де це можливо) як було виконано автентифікацію. Слід має зберігатися та бути можливим для відновлення.

Пов'язане читання
• Основні вимоги: 21 CFR ч. 11 | Додаток 11 | цілісність даних | Аудиторський слід
• Контроль доступу: Рольовий доступ | Надання доступу | Керування доступом користувачів
• Контекст робочого процесу: еБМР | МНС | V5 СУЯ | Контроль змін