Управління безперервністю бізнесу: план на випадок збою

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

Ця стаття — для власника або операційного директора компанії без власного ІТ-відділу: виробництво під замовлення, монтаж, сервіс із виїздом, проєктна робота. Стандарт ISO 22301 і сертифікацію залишимо великим компаніям. Тут — практичний план, який можна зробити самим за кілька вечорів: карта даних, реєстр доступів, щоденна резервна копія з перевіркою відновлення, робота з телефона під час відключень і захист від зниклого підрядника.

Окремо покажемо, як це влаштовано в системах, які робимо ми, і на якому власному уроці ми це правило вивчили.

Коротко:

Почніть із карти, а не з покупок. Спершу запишіть, де живуть дані про замовлення і хто має до них доступ. Генератор і новий сервер допомагають, лише коли відомо, що саме вони захищають.
Кожен критичний доступ — у двох людей компанії. Власником домену, сервера, бота й пошти має бути компанія, а не підрядник чи один працівник.
Копія без перевірки відновлення — лише надія. Резервна копія має робитися щодня автоматично, а відновлення — перевірятися за розкладом на окремому сервері.
Сервер має стояти не в офісі. Тоді відключення світла в офісі зупиняє людей за комп’ютерами, але не систему: з телефона через Telegram працюють і менеджер, і виробництво.
Код і дані мають бути вашими і юридично, і фізично. Право на код без доступу до репозиторію й бази не допоможе, якщо підрядник перестав відповідати.

Управління безперервністю бізнесу без ISO 22301: що це для малої компанії

Що каже стандарт і що з нього взяти

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

Компанії на 20 людей сертифікат зазвичай не потрібен. Їй потрібна логіка стандарту в спрощеному вигляді. Які процеси зупиняють заробіток. Скільки часу без них можна прожити. Скільки даних можна втратити. Хто що робить у перші години збою. Відповіді вміщуються на одну сторінку.

Два числа: скільки можна стояти і скільки можна втратити

У стандартах їх називають RTO і RPO. Простими словами:

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

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

П’ять сценаріїв, від яких будуємо план

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

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

Крок 1. Карта: де живуть дані про замовлення

Як скласти карту за годину

Візьміть один реальний цикл замовлення від заявки до оплати. Пройдіть його і на кожному кроці запишіть, де фіксується інформація. Вийде таблиця на 10–20 рядків.

Що за дані	Де лежать	Хто має доступ	Чи є копія	Що буде, якщо зникнуть
Заявки й листування з клієнтами	Telegram і Viber менеджерів	Кожен менеджер — до свого	Немає	Не знаємо, що обіцяли клієнту
Розрахунки цін	Excel на ноутбуці інженера	Один інженер	Іноді на флешці	Не можемо порахувати нове замовлення
Статуси замовлень	Таблиця Google власника	Власник і менеджери	Історія версій	День хаосу на виробництві
Рахунки й акти	Бухгалтерська програма	Бухгалтер	Залежить від програми	Затримка документів
Креслення і файли клієнтів	Папка на робочому комп’ютері	Конструктор	Немає	Переробка з нуля

Таблиця — приклад, а не опис конкретної компанії. Ваша буде іншою, але стовпці ті самі.

Сховища, про які забувають

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

Якщо одне з цих місць зникне, ви втратите не файл, а шматок процесу.

Як визначити критичність

Для кожного рядка поставте одну з трьох позначок:

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

Усе з позначкою «години» має жити в одному місці з щоденною копією і доступом щонайменше у двох людей. Це головний результат першого кроку.

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

Крок 2. Доступи: хто власник, а хто користувач

Реєстр доступів

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

Що зазвичай потрапляє в реєстр:

Домен сайту і кабінет реєстратора.
Хостинг або сервер, де працюють сайт і система.
Корпоративна пошта й акаунт Google або Microsoft.
Система обліку замовлень та її адміністратор.
Telegram-бот компанії, робочі групи й канали.
Банк-клієнт і ключі електронного підпису директора й бухгалтера.
Кабінети служб доставки, програмного РРО, рекламних сервісів.
Репозиторій з кодом, якщо у вас є власна система.

Для кожного рядка дайте відповідь на одне питання: якщо ця людина завтра недоступна, хто увійде? Якщо відповідь «ніхто», з цього рядка й починайте.

Правило двох ключів

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

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

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

Двоетапна перевірка і Telegram

Держспецзв’язку радить вмикати двофакторну автентифікацію всюди, де це можливо, і серед прикладів називає Telegram, Google і Facebook (LIGA.net). Для Telegram це означає: для входу потрібні і код з SMS, і пароль, а для відновлення пароля можна вказати пошту (Telegram FAQ).

Два налаштування, про які мала компанія зазвичай не думає:

У кожної робочої групи — щонайменше два адміністратори з компанії. Якщо акаунт творця групи видалено, група лишається без власника, хоча адміністратори зберігають свої права (Telegram FAQ).
Бот компанії — на акаунті компанії. Хто створив бота, той ним і керує. Передати бота можна через BotFather, але передача повна і безповоротна: новий власник отримує повний контроль, бачить повідомлення бота і може його видалити (Telegram). Якщо бота створив підрядник на свій особистий акаунт, домовтеся про передачу заздалегідь.

Що робити в день, коли людина йде

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

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

Крок 3. Резервна копія щодня і перевірка відновлення

Правило 3-2-1 для компанії без ІТ-відділу

Агентство кібербезпеки США CISA радить малому бізнесу правило 3-2-1: три копії важливих файлів, на двох різних типах носіїв, одна копія — поза приміщенням компанії. Там же сказано, що копії мають робитися автоматично й регулярно, відновлення треба перевіряти і повністю, і частково, а дані варто мати змогу відкотити щонайменше на сім днів назад (CISA).

Для компанії на 20 людей це виглядає так:

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

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

Чому копія без перевірки — лише надія

Резервні копії ламаються тихо. Скрипт перестав запускатися після оновлення. Диск переповнився. Копіюється база, але не файли. Пароль від архіву знала людина, яка звільнилася.

Опитування це підтверджують. Серед 300 ІТ-керівників у США, яких опитала Harris Poll на замовлення Backblaze, лише 42% компаній, що втратили дані, змогли відновити їх повністю (Backblaze). В опитуванні 285 малих і середніх компаній Німеччини 72% рідко або ніколи не перевіряють, чи можна відновитися з копії, хоча 77% роблять копії щонайменше щотижня (Silicon).

Як перевірити відновлення: покроково

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

Якщо систему для вас веде підрядник, попросіть його показати таку перевірку на дзвінку. Це 20–30 хвилин. Відмова чи «у нас усе надійно» без демонстрації — привід насторожитися.

Злам і шифрувальник: потрібна копія, яку не видалити

За звітом Verizon за 2025 рік програми-вимагачі присутні в 44% витоків даних, а вхід із чужими обліковими даними — найчастіший спосіб проникнення, 22% випадків (Verizon).

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

Урок Saloy: контроль версій і бекапи з першого дня

Що сталося

Saloy — наша компанія з виробництва на верстатах з ЧПК: меблеві фасади, різьблення, деталі під замовлення. Систему управління для неї ми зробили за три тижні, модуль за модулем. Одного разу оновлення поставили зі старої копії коду. Воно затерло свіжий модуль, і відновлювати його довелося вручну.

Звідси правило, яке ми тепер виконуємо в кожному проєкті: контроль версій і резервні копії — з першого дня, а не «коли система стане великою». Повну історію запуску описано у кейсі власної системи управління.

Контроль версій простими словами

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

Власнику не потрібні технічні деталі. Йому потрібні три факти:

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

Що питати в підрядника

Де зберігається код і хто власник репозиторію?
Як ви ставите оновлення на сервер і як їх відкочуєте?
Як часто робиться копія бази і де вона лежить?
Коли востаннє перевіряли відновлення з копії і скільки воно тривало?
Що я отримаю на руки, якщо ми припинимо співпрацю?

Більше питань для перевірки виконавця — у статті про червоні прапорці ненадійного підрядника.

Коли немає світла: компанія працює з телефона

Що показує досвід українського бізнесу

За опитуванням Європейської бізнес асоціації, оприлюдненим у січні 2026 року, вплив відключень світла відчули 80% компаній-учасниць. Найчастіші наслідки — зростання собівартості (61%), зміна графіків роботи (58%), падіння обсягів (50%) і простої (48%). Альтернативні джерела енергії мають 90% компаній, але повної енергонезалежності досягли лише 23% (Dengi.ua).

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

Сервер — не в офісі

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

Потужний сервер для цього не потрібен. Наш блог із командою ШІ-агентів, Telegram-бот і щотижневий звіт про те, як Google бачить сайт, працюють на найпростішому VPS: 2 ГБ пам’яті, 1 процесор. Система обліку замовлень для невеликої компанії теж не вимагає дорогого заліза в офісі.

Telegram як робоче місце на час відключення

Коли офісні комп’ютери вимкнені, у людей лишаються телефони. Якщо основні дії доступні через Telegram, компанія не зупиняється. У наших системах вхід, сповіщення й задачі йдуть через Telegram. Менеджер отримує сповіщення про нову заявку й відкриває картку замовлення. Виробництво отримує задачу на свій етап. У Saloy майстер запускає таймер операції командою в боті, тож реальний час на операцію видно і без комп’ютера.

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

Чекліст на відключення до восьми годин

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

Ключова людина пішла: знання з голови в систему

Тест двотижневої відпустки

Візьміть кожну ключову людину — менеджера, кошторисника, бухгалтера, начальника виробництва — і поставте питання: що зупиниться, якщо вона завтра на два тижні без зв’язку? Типові відповіді:

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

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

Процес, записаний один раз

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

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

Ролі замість спільного пароля

Якщо всі працюють під одним входом, ви не знаєте, хто що змінив, і не можете забрати доступ в однієї людини. У системі з ролями кожен бачить своє. У Saloy три ролі: власник, менеджер, виробництво, і прибуток бачить лише власник. Людина пішла — її вхід вимкнули, решта працює далі.

Підрядник зник: що має бути у вас уже сьогодні

Що каже закон про код, написаний на замовлення

Закон «Про авторське право і суміжні права» 2022 року встановлює: майнові права на твір, створений за замовленням, переходять до замовника з моменту створення у повному складі, якщо інше не передбачено договором замовлення (Верховна Рада). Комп’ютерна програма за цим законом теж є твором. Тож спершу перевірте, що саме написано у вашому договорі з розробником. Деякі договори залишають права за виконавцем, а клієнту дають лише дозвіл користуватися. Якщо формулювання незрозумілі, покажіть договір юристу.

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

Готова програма теж може зникнути

Підрядник — це не лише розробник. Хмарний сервіс, у якому ви ведете замовлення, теж підрядник. У квітні 2023 року Україна на десять років запровадила санкції проти 1С і «Парус», і компаніям, які на них працювали, довелося планувати перехід (ДТКТ).

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

Чекліст: що має бути на вашому боці

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

Перевірка проста: попросіть іншого розробника за цими матеріалами підняти копію системи. Якщо він зміг, зникнення підрядника вас не зупинить.

Як це влаштовано в наших системах

Код і дані належать клієнту. Це система компанії, а не підписка на чужу платформу.
Сервер — клієнта або наш, з передачею будь-коли. Якщо ви вирішите перейти на свій сервер чи до іншого виконавця, систему передаємо.
Резервна копія робиться щодня.
Поширені технології: FastAPI, PostgreSQL, React, Telegram-боти. Цей набір знає багато розробників, тому підтримку можна передати іншій команді.
Без оплати за кожного користувача. У кожного працівника свій вхід і своя роль. Не доводиться працювати під одним паролем, щоб заощадити на ліцензіях.

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

План безперервності на одну сторінку

Шаблон

Сценарій	Перший крок	Хто відповідає	Скільки можна стояти	Що потрібно заздалегідь
Немає світла в офісі	Переходимо на телефони і Telegram	Операційний директор	Години	Сервер не в офісі, чекліст відключення
Зламався ноутбук чи сервер	Відновлюємо з копії на новий пристрій або сервер	Підрядник або адміністратор	Доба	Щоденна копія, перевірене відновлення
Пішла ключова людина	Забираємо доступи, передаємо чати й замовлення	Власник	Доба	Реєстр доступів, ролі в системі
Зник підрядник	Передаємо код, базу й інструкцію новому виконавцю	Власник	Система працює, розвиток стоїть	Пакет передачі за чеклістом
Злам акаунта	Блокуємо вхід, міняємо паролі, відновлюємо з копії	Власник і підрядник	Години	Двоетапна перевірка, копія з окремим доступом

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

Розклад перевірок

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

Як порахувати, скільки коштує година простою

Формула: вартість години простою = маржинальний дохід за місяць ÷ робочі години за місяць + погодинна оплата людей, які в цей час чекають.

Умовний приклад. Компанія заробляє 600 тисяч гривень маржинального доходу на місяць і працює 176 годин. Одна година роботи дає близько 3 400 гривень маржі. Якщо при цьому чекають 10 людей із погодинною оплатою 250 гривень, це ще 2 500 гривень. Разом — майже 6 тисяч гривень за годину, без урахування клієнтів, які не дочекалися відповіді. Вісім годин простою обійдуться майже в 48 тисяч гривень.

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

Типові помилки

Купити генератор і вважати план готовим. Генератор захищає від відключення світла, але не від зламаного ноутбука, звільнення бухгалтера чи зниклого підрядника.
Робити копію на той самий сервер. Якщо сервер зламався або акаунт зламали, копія зникає разом з базою.
Ніколи не перевіряти відновлення. Про те, що копія порожня, дізнаються в день аварії.
Тримати всі доступи в одній людині. Навіть якщо це власник: у нього теж бувають відпустка, лікарня й загублений телефон.
Реєструвати домен, бота й сервер на підрядника «для зручності». Через рік ніхто не пам’ятає, на кого вони записані.
Переходити на нову систему за один день. Старий спосіб вимикають, а нова система ще не перевірена на реальних замовленнях. У наших запусках система два тижні працює паралельно зі старим способом.
Написати план і покласти в шухляду. План, який ніхто не перевіряв, — це документ, а не готовність.

Коли такий план не потрібен або його замало

Коли достатньо простішого

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

Коли цього плану замало

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

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

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

Як часто робити резервну копію? Щонайменше раз на добу й автоматично. Частіше — якщо втрата дня замовлень для вас неприйнятна. Відновлення перевіряйте щомісяця на окремому сервері, а не поверх робочого.

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

Якщо у вашій компанії на 5–100 людей замовлення живуть у чатах, таблицях і головах ключових людей, опишіть, як зараз іде одне замовлення і де лежать дані. Покажемо систему на демо за 30 хвилин: замовлення з етапами, вхід через Telegram, ролі й щоденну копію. І чесно скажемо, що з цього вам потрібно, а що зайве. Детальніше — ШІ-система управління бізнесом.