Політика електронного підпису INBULK

1. Статус і пріоритет

1.1. Політика деталізує порядок Підписання на Платформі. У разі суперечності перевагу має Договір приєднання, а для конкретного документа — його ідентифіковані умови та застосовне право.

1.2. Назва способу в інтерфейсі повинна відповідати його фактичній юридичній і технічній природі. OTP, пароль або click-to-confirm не називаються КЕП/QES, якщо вони не відповідають вимогам такого підпису.

2. Ролі

2.1. У Підписанні беруть участь:

2.2. Технічна інтеграція не робить Оператора QTSP/TSP, CA, RA, TSA або кваліфікованим validation service без підтвердженого статусу.

3. Підтвердження особи і повноважень

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

3.2. Ідентифікація фізичної особи, Автентифікація Облікового запису, перевірка сертифіката та корпоративне повноваження є різними перевірками.

3.3. Чинний підпис або сертифікат сам по собі не підтверджує посаду, внутрішнє схвалення, відсутність ліміту, право розпоряджатися товаром чи коштами або належність IBAN.

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

4. Рівні підпису та підтвердження

4.1. На Платформі можуть застосовуватися такі способи підпису та підтвердження:

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

5. Обов’язкові сценарії

5.1. Заява про приєднання українського Користувача-компанії підписується КЕП відповідно до Договору.

5.2. Для зміни банківських реквізитів, надання критичних Прав, розпорядження товаророзпорядчими документами, високовартісних операцій або інших ризикових дій Платформа може вимагати КЕП, посилену Автентифікацію та/або second approval.

5.3. Обов’язковий рівень залежить від юрисдикції, у якій зареєстрований Користувач-компанія:

5.4. Юрисдикція вноситься до таблиці п. 5.3 новою редакцією цієї Політики після запуску country module для відповідної країни. Country module — набір налаштувань Платформи для окремої юрисдикції, що визначає тип підпису, строк, провайдера, склад доказів і мову (п. 12.3).

5.5. Доки юрисдикцію не внесено до таблиці, жоден спосіб підпису не позначається на Платформі як юридично достатній для всіх документів відповідної країни. Конкретний спосіб для окремого документа визначається за розділом 4 і показується до фінальної дії.

6. Signing ceremony

6.1. Процедура Підписання забезпечує:

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

7. Версія та цілісність

7.1. До Підписання формується незмінювана редакція з унікальним ідентифікатором і криптографічним відбитком, якщо це підтримується.

7.2. Зміна підписаного документа повинна бути виявною. Нова редакція не замінює й не видаляє попередній підписаний файл та evidence.

7.3. Підписання додатків і вкладень має дозволяти встановити, які саме файли входили до пакета.

8. Перевірка підпису

8.1. Результат перевірки може бути успішним, негативним, невизначеним або незавершеним. Лише успішно завершена перевірка може відображатися як «перевірено».

8.2. Перевірка, залежно від способу, може враховувати цілісність, сертифікат, ланцюг довіри, статус відкликання, timestamp, trusted list, відповідність особи профілю та інші доступні дані.

8.3. Недоступність OCSP/CRL, trusted list або validation service не перетворюється автоматично на успішний результат.

8.4. Повторна перевірка не створює повторного підпису, Акцепту або правочину.

9. Доказова база і Запис про підписання

9.1. Щодо кожного Підписання Платформа формує та зберігає доступні елементи:

• ідентифікатор документа, редакція, назва й хеш;
• Підписант і представлена компанія;
• спосіб ідентифікації та Автентифікації;
• відображене Право або authority snapshot, якщо функціонал доступний;
• текст підтвердження наміру;
• тип підпису, провайдер, сертифікат чи ідентифікатор і результат перевірки;
• дата й час системних подій у UTC та, за потреби, локальний час;
• IP, device/browser information у пропорційному обсязі;
• timestamp і validation evidence, якщо застосовані;
• event ID, idempotency key і second approval;
• факт відмови, помилки, скасування або недоступності сервісу.

9.2. Склад конкретного Запису залежить від доступного способу. Відсутній елемент не повинен подаватися як такий, що був перевірений.

10. Зберігання, експорт і legal hold

10.1. Підписані документи й докази зберігаються відповідно до Політики електронних доказів, Політики конфіденційності, строку документа, спору та закону.

10.2. Користувач може завантажити доступний підписаний документ і Запис про підписання. Export не повинен змінювати оригінальний файл.

10.3. Видалення призупиняється на час спору, розслідування або законної вимоги.

11. Інциденти

11.1. При компрометації ключа, сертифіката, Облікового запису або засобу Автентифікації нові Підписання можуть бути призупинені, докази збережені, а статус документів — перевірений.

11.2. Компрометація після Підписання не скасовує документ автоматично; наслідки визначаються фактичними обставинами, моментом компрометації, правом і рішенням сторін або компетентного органу.

11.3. Користувач негайно повідомляє Оператора Платформи й провайдера та ініціює блокування чи відкликання, коли це застосовується.

12. Провайдери і country modules

12.1. Актуальні провайдери, їх юридичні особи, країни, статуси, supported signature types і privacy roles зазначаються в реєстрі або на екрані підписання.

12.2. Зміна провайдера не потребує нової редакції Договору, якщо не змінює юридичний наслідок, істотні privacy-умови або обов’язки Користувача; такі зміни повідомляються.

12.3. Особливості окремої юрисдикції встановлюються country module, що може визначати інший тип підпису, строк, провайдера, evidence і мову.

13. Зміни

13.1. Матеріальні зміни Політики застосовуються перспективно. Для підписання використовується редакція, показана й зафіксована до дії.

14. Контакти

14.1. Питання щодо цієї Політики — [email protected].

Джерела та нормативна база

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

• Договір приєднання, до якого приєднався Користувач.
• Закон України «Про електронні документи та електронний документообіг» № 851-IV.
• Закон України «Про електронну ідентифікацію та електронні довірчі послуги» № 2155-VIII.
• Regulation (EU) No 910/2014 (eIDAS) у випадках, коли він застосовується.

Історія редакцій