Які ризики створює використання 1С/BAS у 2026 році для українського бізнесу?

Рішення продовжувати роботу в 1С чи BAS часто не переглядають, доки система стабільно виконує щоденні завдання. Водночас її працездатність не завжди означає, що бізнес контролює пов’язані з нею юридичні, безпекові та операційні ризики.

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

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

1С/BAS працює, але її правовий статус уже інший 

Перша помилка — оцінювати ризик 1С/BAS лише через наявність або відсутність прямої законодавчої заборони.

У жовтні 2025 року Кабінет Міністрів затвердив порядок формування відкритого переліку забороненого програмного забезпечення та мережевого обладнання. До нього можуть включати продукти, власники, правовласники або виробники яких перебувають під українськими чи визнаними Україною міжнародними санкціями, а також продукти, щодо яких є відповідне рішення суду. Постанова №1335 набула чинності 24 жовтня 2025 року.

На початку 2026 року в переліку було лише кілька десятків позицій. Уже 17 липня 2026 року Держспецзв’язку повідомила про його розширення з 1079 до 1341 програмного продукту та найменування обладнання.

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

Чи заборонено 1С/BAS усім приватним компаніям

Обов’язковість цього переліку поширюється передусім на органи влади, державні підприємства, військові формування та операторів критичної інфраструктури. Для звичайного приватного бізнесу загальна пряма заборона на використання 1С/BAS станом на липень 2026 року не діє.

Законопроєкт №13505 мав запровадити ширше регулювання використання та розповсюдження ворожих програмних продуктів. Проте 30 червня 2026 року Верховна Рада не підтримала його в першому читанні. Законопроєкт отримав статус "відхилено та знято з розгляду".

Важливо зазначити, що цей результат не повертає ринок у стан до 2022 чи навіть до 2017 року. Він лише означає, що конкретна спроба запровадити загальну заборону не стала законом.

Напрям регулювання при цьому залишається незмінним:

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

Для бізнесу небезпечно будувати довгострокове рішення лише на аргументі “сьогодні це ще не заборонено”. Міграція складної облікової системи може тривати місяці, а для великих виробничих або багатокомпанійних структур — значно довше. Після появи обов’язкової вимоги компанія вже не зможе самостійно визначати комфортні строки переходу. 

Радимо до прочитання ERP для MilTech-виробництва: основні терміни та їх значення

Ризики використання 1С/BAS: матриця оцінки 

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

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

Ризик невідповідності системи юридичним вимогам 

Навіть компанія, яка роками працює в BAS, не завжди може точно відповісти, який програмний продукт вона фактично використовує. За стандартною назвою можуть приховуватися:

• базова платформа;
• галузева конфігурація;
• локальні модулі;
• зовнішні обробки;
• неофіційні оновлення;
• інтеграції, створені різними підрядниками;
• окремі компоненти зі своїми правовласниками.

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

Отже, фрази на кшталт “у нас не 1С, а BAS” або “це українська конфігурація” самі по собі нічого не доводять. Потрібно документально встановити:

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

Без такої інвентаризації бізнес не керує юридичним ризиком.

Корисно буде ознайомитися з порівняльним аналізом MASTER:Бухгалтерія чи Oblik-ERP

Неконтрольовані зміни в системі 

Після санкцій 2017 року офіційна модель продажу та підтримки 1С в Україні була порушена. Частину інсталяцій продовжили обслуговувати локальні підрядники, частину — через неофіційні канали, ручні патчі та окремі доопрацювання.

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

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

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

Виникатимуть логічні питання: хто створив файл? Хто перевірив код? Які права він отримує після встановлення? Чи фіксуються зміни? Чи можна повернутися до попередньої версії? Чи є договірна відповідальність постачальника?

Коли відповідей немає, кожне оновлення стає рішенням на довірі до конкретного фахівця. Для системи, що контролює фінансові й операційні процеси, цього недостатньо.

Кібератаки на бухгалтерію та фінансові операції 

Ще одна крайність — автоматично приписувати 1С/BAS усі кібератаки на українські компанії. Публічно підтверджених даних про те, що кожна інсталяція цих продуктів передає інформацію третім особам або містить прихований канал доступу, немає. Так само некоректно використовувати атаку NotPetya 2017 року як доказ компрометації 1С.

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

CERT-UA описувала компанії, у яких зловмисники використовували податкову тематику, шкідливі вкладення та засоби віддаленого доступу. Мета таких атак — отримати контроль над робочим комп’ютером, викрасти автентифікаційні дані або втрутитися в платіжні операції.

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

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

Залежність від одного підрядника 

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

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

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

Дізнайтеся більше про Комплексний облік для виробництва: кейс Brave technics

Ланцюговий збій операцій 

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

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

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

Репутаційні та комплаєнс-обмеження 

Як ми писали вище, для більшості приватних компаній 1С/BAS поки не створює автоматичної юридичної заборони. Проте вже сьогодні походження програмного забезпечення має значення під час:

• участі в державних та корпоративних закупівлях;
• роботи з критичною інфраструктурою;
• залучення міжнародного фінансування;
• партнерства з оборонними компаніями;
• кібербезпекового аудиту;
• due diligence перед інвестицією або M&A.

Наявність 1С/BAS навряд чи сама по собі стане єдиною причиною відмови від угоди. Публічно підтвердженої статистики таких відмов немає. Але в партнера закономірно виникнуть додаткові запитання, наприклад, де зберігаються дані? хто підтримує платформу? чи має компанія план відмови від ворожого програмного забезпечення тощо.

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

Вимушена термінова міграція 

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

Проте вони не змінюють трьох фундаментальних факторів:

1. Регуляторна траєкторія рухається до посилення контролю. Перелік забороненого ПЗ продовжує розширюватися, а питання загальної заборони вже розглядалося парламентом.
2. Архітектурний та технологічний борг накопичується. Кожне нове доопрацювання збільшує кількість логіки, яку доведеться перевірити, перенести або відхилити під час майбутньої міграції.
3. Залежність від людей і підрядників посилюється. Чим довше система працює без документації та плану заміни, тим складніше компанії контролювати вартість і строки переходу.

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

Також варто враховувати навантаженість інтеграторів, яка зможе запропонувати такі послуги. Детальніше про це можна почитати в окремій статті Відхід від забороненого ПЗ: Головні тези дискусії Deloitte про регуляторні виклики, кібербезпеку та цифрову трансформацію.

З чого почати вже сьогодні? 

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

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

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

Також вас зацікавить кейс про те, Як Reface побудували єдину фінансову систему з “Обліком для України” на базі Odoo 

Висновок

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

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

Залиште заявку, щоб оцінити ризики 1С/BAS і спланувати безпечний перехід на українське ERP-рішення.