Перелік забороненого ПЗ оновлено: що робити бізнесу з 1С, BAS та обліковими системами

Коротко

Перелік забороненого / ризикового ПЗ Держспецзв'язку у 2026 році оновлювався кілька разів і розширився з 215 до 1079 позицій (травень–липень).
До переліку входять численні конфігурації 1С та BAS — це підтверджено профільними джерелами.
Формально обов'язок не використовувати таке ПЗ поширюється на держсектор, критичну інфраструктуру, органи влади та військові формування — не на приватний бізнес автоматично.
Для приватного бізнесу це не пряма юридична заборона, але сильний комплаєнс- і кіберризик, який ігнорувати нерозумно.
Використання 1С/BAS може створювати питання з боку банків, інвесторів, тендерних комітетів, аудиторів і міжнародних материнських компаній — незалежно від прямої заборони.
Перехід з 1С/BAS варто планувати як керований ERP-проєкт, а не як аварійну заміну програми в останній момент.
Перед міграцією потрібно інвентаризувати конфігурації, інтеграції, звіти й історичні дані — а не просто «поставити нову програму».
Вимога SAF-T робить структуру й якість облікових даних ще важливішою — це гарний момент поєднати відмову від ризикового ПЗ з підготовкою до SAF-T.

Що саме оновили у переліку забороненого ПЗ

Перелік веде Держспецзв'язку (Державна служба спеціального зв'язку та захисту інформації України) — офіційна назва документа: «Перелік забороненого до використання програмного забезпечення та комунікаційного (мережевого) обладнання». Він публікується та оновлюється на офіційному сайті відомства.

Протягом весни–літа 2026 року перелік розширювався кілька разів поспіль: 28 травня — до 215 позицій, 15 червня — до 416, 22 червня — до 619, 29 червня — до 880, 6 липня — до 1079 позицій. У травневому оновленні додано 175 нових позицій, серед яких — численні варіації 1С та BAS, включно з галузевими конфігураціями («1С:Підприємство 8. Управління аптечною мережею», BAS Бухгалтерія, BAS Базова, BAS ПРОФ). Крім облікових систем, до переліку потрапляють й інші категорії ПЗ — антивірусні продукти (Dr.Web, Kaspersky), сервіси Яндекс, криптографічні та мережеві рішення (ViPNet, КриптоПро).

Це офіційно підтверджені дані з профільних джерел (i.factor.ua, news.dtkt.ua), які узгоджуються між собою. Оскільки перелік регулярно оновлюється, перед прийняттям рішення потрібно звіряти не лише назву програми, а й конкретну версію, конфігурацію, виробника та пов'язаних юридичних осіб з актуальною редакцією офіційного переліку.

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

Чи означає це, що 1С або BAS заборонені всім

Ні — і це найважливіший юридично точний момент цієї теми.

Обов'язок не використовувати ПЗ з переліку прямо поширюється на органи державної влади, державні органи та підприємства, органи місцевого самоврядування, військові формування, системи, що працюють із чутливими даними, та об'єкти критичної інформаційної інфраструктури. Для цих категорій наслідки конкретні: неможливість пройти авторизацію безпеки чи отримати сертифікат відповідності, скасування вже виданої авторизації, обов'язок замінити заборонене ПЗ за приписом контролюючого органу, і адміністративна відповідальність за ст. 188-31 КУпАП за невиконання такого припису.

Для приватного бізнесу пряма норма про заборону чи відповідальність на сьогодні відсутня — сам Держспецзв'язку у своїх роз'ясненнях прямо вказує, що «до приватного сектору поки що відношення не має». Це означає, що твердження на кшталт «BAS заборонено всім компаніям в Україні» чи «за використання 1С автоматично буде штраф» не відповідають чинним нормам для звичайного приватного бізнесу — і ми свідомо їх тут не робимо.

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

Практична формула

Не панікувати, але й не ігнорувати — перевірити статус компанії, конкретне ПЗ, інтеграції, договори, вимоги клієнтів і мати план переходу, навіть якщо не терміновий.

Які ризики створює використання ворожого або санкційного ПЗ

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

Кіберризики — потенційний доступ виробника (чи пов'язаних із ним осіб) до логіки оновлень, а через них — теоретичний вектор ризику для даних, інтеграцій, серверів і резервних копій, залежно від архітектури конкретного впровадження.
Комплаєнс-ризики — невідповідність внутрішнім політикам материнської компанії, вимогам банків при кредитуванні, умовам донорського фінансування чи вимогам міжнародних контрагентів під час due diligence.
Операційні ризики — залежність від застарілої або обмежено підтримуваної системи, складність підтримки, дефіцит кваліфікованих фахівців, нагромаджені кастомізації без документації.
Податкові ризики — помилки в звітності через застарілу логіку системи, складність підтвердження історичних даних під час перевірки.
Аудиторські ризики — проблеми з доступом до логів, історії змін, повноти і цілісності облікових даних під час аудиту фінансової звітності.
Репутаційні ризики — питання від партнерів, материнської компанії, інвесторів чи клієнтів, які бачать у вашому стеку систему із санкційного переліку.

Ризик	Як проявляється	Що перевірити	Як зменшити
Кіберризик	Потенційна вразливість через оновлення, підтримку чи інтеграції постачальника	Хто технічно адмініструє систему, звідки приходять оновлення, де фізично розміщені сервери й бекапи	Обмежити доступ, перевірити канали оновлень, розглянути ізоляцію критичних даних
Комплаєнс-ризик	Невідповідність політикам групи, банку, донора, тендерній документації	Чи є у ваших договорах, кредитних угодах чи корпоративних політиках вимоги щодо переліку ПЗ	Звірити внутрішні політики та договірні зобов'язання з поточним стеком ПЗ
Операційний ризик	Складність підтримки, дефіцит фахівців, недокументовані кастомізації	Скільки людей знають логіку поточних кастомізацій, чи є документація	Задокументувати поточні процеси до початку будь-якої зміни
Податковий ризик	Помилки звітності, складність відновлення історичних даних	Чи система коректно формує дані для податкової звітності й SAF-T	Перевірити повноту й структурованість облікових даних заздалегідь
Аудиторський ризик	Неповнота історії змін, обмежений доступ до логів	Чи є незмінна історія операцій і трасування змін	Забезпечити збереження історичних даних до будь-якої міграції
Репутаційний ризик	Питання від партнерів, інвесторів, материнської компанії	Чи запитували контрагенти про ваш стек ПЗ	Мати готову, чесну відповідь і за потреби — план переходу

Що бізнесу зробити зараз: практичний чеклист

Визначити, які облікові, ERP, кадрові, складські, payroll і звітні системи використовуються в компанії.
Перевірити, чи є серед них 1С/BAS або інше ПЗ з офіційного переліку Держспецзв'язку.
Встановити, чи компанія належить до держсектору, критичної інфраструктури, регульованих суб'єктів, або має спеціальні вимоги від клієнтів/банків/донорів.
Перевірити, де фізично розміщені бази даних і резервні копії.
Перевірити, хто має доступ до підтримки, оновлень і адміністрування системи.
Перевірити інтеграції: банк-клієнт, M.E.Doc, CRM, склад, виробництво, зарплата, BI, SAF-T.
Оцінити, які бізнес-процеси критично залежать від старої системи.
Визначити цільову систему або короткий список альтернатив для порівняння.
Підготувати план міграції даних.
Окремо спланувати збереження історичних даних для податкових перевірок, аудиту та SAF-T.
Узгодити перехід із бухгалтерією, IT, фінансовим директором і власниками бізнес-процесів.
Не вимикати стару систему до повної перевірки коректності міграції та звітності.

Як правильно планувати перехід з 1С/BAS на нову ERP

Міграція — це не «встановити нову програму й перенести файл». Це проєкт, який вимагає опису процесів, а не лише технічного перенесення даних.

Перед стартом варто чітко визначити: що саме переноситься (довідники, залишки, обороти, первинні документи, повна історія чи лише певний період), яка дата переходу, як буде протестована податкова й фінансова звітність у новій системі, як забезпечується доступ до історичних даних після відключення старої системи, чи потрібен паралельний період одночасної роботи двох систем, і хто відповідає за навчання бухгалтерії та інших користувачів. Окремо потрібно задокументувати мапінг — відповідність старих і нових рахунків, довідників та аналітик, — інакше історичні звіти й порівняльні дані втратять сенс.

Етап	Що зробити	Типова помилка	Як уникнути
Інвентаризація	Скласти повний перелік систем, інтеграцій, звітів, користувачів	Врахувати лише «головну» систему, забути про суміжні модулі	Залучити всі відділи, які працюють з обліковими даними, а не лише бухгалтерію
Опис процесів	Задокументувати поточні бізнес-процеси й облікові операції	Описувати «як має бути», а не «як є насправді»	Спостерігати за реальною роботою користувачів, а не лише за інструкціями
Вибір цільової системи	Оцінити альтернативи за критеріями бізнесу	Обирати систему «схожу на стару» без аналізу реальних потреб	Формалізувати критерії вибору до порівняння варіантів
Підготовка даних	Очистити довідники, консолідувати дублікати	Переносити історичний хаос «як є»	Провести очищення даних до, а не під час міграції
Мапінг довідників	Зіставити старі й нові рахунки, аналітики, довідники	Мапінг існує лише «в голові» відповідального	Задокументувати мапінг у окремому файлі, доступному команді
Тестова міграція	Перенести дані на тестовий контур і перевірити результат	Тестувати лише на невеликій вибірці «зручних» даних	Тестувати на реальних, включно з нетиповими, операціями
Паралельний облік	Вести облік в обох системах певний період	Скорочувати паралельний період через тиск строків	Закласти паралельний період у план з запасом, включно із закриттям місяця
Запуск	Перейти на нову систему як основну	Запускати без фінального узгодження з бухгалтерією	Формальний sign-off від фінансового директора й бухгалтерії перед запуском
Архів старої системи	Зберегти доступ до архіву старої системи	Видаляти чи вимикати стару систему одразу після запуску	Утримувати архівний доступ до завершення можливих перевірок за старі періоди
Постміграційна перевірка	Звірити звітність, залишки, історичні дані в новій системі	Вважати проєкт завершеним одразу після технічного запуску	Провести контрольне закриття щонайменше одного повного звітного періоду в новій системі

SAF-T і заборонене ПЗ: чому це пов'язано

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

Якщо перехід на нову систему робиться хаотично, без опису процесів і мапінгу, зібрати повну й коректну історію операцій для SAF-T після такої міграції буде значно складніше. Тому відмова від ризикового ПЗ — це не лише реакція на комплаєнс-сигнал, а й практична нагода одразу привести структуру облікових даних у стан, готовий до SAF-T, замість того щоб робити це окремим проєктом пізніше.

LUCAS SAF-T Connector може працювати з даними з різних джерел, включно з різними ERP та обліковими системами, — але якість вихідних даних і коректність мапінгу залишаються критично важливими незалежно від того, який конектор чи інструмент використовується. Хороша міграція вирішує обидва завдання одночасно: і зниження комплаєнс-ризику, і готовність до SAF-T.

Яку систему обрати замість 1С/BAS

Універсальної відповіді немає, і рейтинг «топ-10 ERP» без аналізу конкретного бізнесу був би непрофесійним. Вибір цільової системи залежить від конкретних критеріїв компанії:

масштаб бізнесу і кількість користувачів;
галузь — виробництво, торгівля чи послуги мають різні вимоги до функціоналу;
кількість юридичних осіб і потреба в консолідованій звітності;
стандарт звітності — МСФЗ чи НП(С)БО;
вимоги до кадрового обліку й розрахунку зарплати;
потреби складського обліку, виробництва чи роздрібної торгівлі;
необхідні інтеграції та наявність зручного API;
рівень локалізації під українське законодавство і практику;
готовність системи до податкової звітності й SAF-T;
вартість впровадження і подальшої підтримки;
наявність кваліфікованих партнерів з впровадження на ринку;
рівень безпеки та можливості контролю доступу.

На ринку представлені різні типи рішень — українські бухгалтерські системи, міжнародні ERP, хмарні платформи, кастомні рішення під конкретний бізнес, а також гібридні моделі, коли частина процесів залишається в одній системі, а частина переноситься в іншу. Правильний вибір — результат аналізу потреб конкретної компанії, а не слідування загальному тренду.

Типові помилки при відмові від старої облікової системи

чекати, поки обмеження стане прямим і невідкладним, замість того щоб почати планування заздалегідь;
обирати нову систему лише тому, що вона «схожа на 1С/BAS», без аналізу реальних потреб;
переносити весь історичний хаос у нову ERP без очищення даних;
не документувати мапінг рахунків, довідників і аналітик;
не залучати бухгалтерію до проєкту міграції як повноцінного учасника, а не лише виконавця;
не тестувати закриття місяця в новій системі перед повним переходом;
не перевіряти коректність податкової звітності до відключення старої системи;
не планувати збереження доступу до історичних даних;
забувати про суміжні інтеграції — банк-клієнт, CRM, склад, зарплатні сервіси;
не враховувати вимоги SAF-T при проєктуванні нової структури обліку;
робити перехід без чіткого власника проєкту, відповідального за результат.

Як LUCAS допомагає з переходом від ризикового ПЗ

LUCAS може провести аудит поточних облікових систем компанії та визначити, які саме дані й процеси залежать від 1С/BAS чи іншого ризикового ПЗ. Ми допомагаємо сформулювати вимоги до нової системи, виходячи з реальних потреб бізнесу, а не з готового шаблону, і берем участь у виборі ERP чи облікової системи разом із командою клієнта.

Окремо ми плануємо міграцію даних, перевіряємо мапінг рахунків, довідників і аналітик, і готуємо обліковий процес до вимог SAF-T — щоб перехід вирішував одразу і питання комплаєнсу, і питання готовності до податкового контролю. Ми також допомагаємо побудувати комунікацію між бухгалтерією, IT-командою та впроваджувачем ERP, і перевіряємо, чи зберігається після міграції якість даних, потрібна для аудиту, податкової та управлінської звітності.

Детальніше про перехід з 1С на Odoo — у статті «Міграція з 1С на Odoo: складнощі, ризики і як їх уникнути», а про підготовку до SAF-T — у матеріалі «Як підготувати компанію до SAF-T UA».

Часті запитання

Що таке перелік забороненого програмного забезпечення?

Це офіційний перелік Держспецзв'язку — «Перелік забороненого до використання програмного забезпечення та комунікаційного (мережевого) обладнання», який визначає ПЗ і обладнання, пов'язані з особами під санкціями, недопустиме для використання у визначених законом категоріях суб'єктів.

Хто веде перелік забороненого ПЗ?

Державна служба спеціального зв'язку та захисту інформації України (Держспецзв'язку), на підставі Постанови КМУ від 22.10.2025 №1335 та санкційного законодавства.

Чи заборонені 1С і BAS для всіх українських компаній?

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

Кого прямо стосується заборона або обмеження використання такого ПЗ?

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

Що робити приватному бізнесу, якщо він використовує BAS?

Не панікувати, але й не ігнорувати сигнал: провести інвентаризацію систем, оцінити ризики (кіберризики, комплаєнс, вимоги клієнтів і банків), і сформувати план переходу на альтернативну систему — навіть без жорсткого дедлайну.

Чи потрібно терміново вимикати стару систему?

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

Які ризики використання 1С/BAS у 2026 році?

Кіберризики, комплаєнс-ризики (вимоги банків, інвесторів, материнських компаній), операційні ризики підтримки, податкові ризики звітності, аудиторські ризики повноти даних і репутаційні ризики у взаємодії з партнерами.

Як перевірити, чи наше ПЗ є в переліку?

Звірити конкретні назви й версії використовуваного програмного забезпечення з актуальним переліком на офіційному сайті Держспецзв'язку (cip.gov.ua), оскільки перелік регулярно оновлюється.

Як планувати перехід на нову ERP?

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

Що робити з історичними даними після міграції?

Забезпечити збережений доступ до архіву старої системи до завершення можливих податкових перевірок і аудитів за попередні періоди, а не видаляти чи вимикати стару систему одразу після запуску нової.

Як SAF-T впливає на вибір нової облікової системи?

SAF-T вимагає структурованих, повних облікових даних. При виборі й міграції на нову систему варто одразу враховувати, чи здатна вона коректно формувати довідники, контрагентів, рахунки й первинні документи у форматі, готовому до SAF-T.

Чи може LUCAS допомогти з переходом від 1С/BAS?

Так — LUCAS проводить аудит поточних систем, допомагає з вибором цільової ERP, планує міграцію даних, перевіряє мапінг облікових даних і готує облік до вимог SAF-T.

LUCAS Audit Team

Аудиторсько-методологічна команда

Стаття підготовлена і перевірена аудиторсько-методологічною командою LUCAS — аудиторської та технологічної компанії з понад 15-річним досвідом у фінансовому аудиті, МСФЗ-звітності та цифровій трансформації обліку.