План управління системою – як створити реєстр ІТ-систем, розподілити обов'язки та річний графік робіт

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

Що має містити план управління системою?

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

Хто такий власник системи — і в чому різниця з адміністратором системи?

Власник системи — це зазвичай роль, яку бізнес призначає для прийняття рішень щодо цілей, пріоритетів і ресурсів для системи. Адміністратор системи (systemförvaltare) зазвичай координує практичну роботу, документацію та моніторинг. ІТ-підрозділ виконує технічні завдання відповідно до розподілу відповідальності, що діє в організації або у постачальника.

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

Створення реєстру ІТ-систем крок за кроком

1. Інвентаризація фактично використовуваних систем

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

2. Документування базової інформації

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

3. Ідентифікація інформації та залежностей

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

4. Розподіл відповідальності за допомогою простої матриці RACI

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

5. Пріоритезація ризиків та покращень

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

6. Створення річного плану

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

7. Перегляд життєвого циклу та виведення з експлуатації

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

Приклад: три системи в невеликій компанії

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

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

Чи є реєстр ІТ-систем тим самим, що й реєстр обробки даних згідно з GDPR?

Ні. Реєстр ІТ-систем описує системи та технічні чи організаційні ресурси. Правила статті 30 GDPR натомість стосуються реєстру операцій з обробки персональних даних і вимагають специфічних відомостей, зокрема цілі обробки, категорії суб'єктів даних та отримувачів, де це застосовно. Одна ІТ-система може підтримувати кілька процесів обробки персональних даних, а один процес обробки може охоплювати кілька систем. Тому реєстр операцій з обробки даних має оцінюватися окремо.

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

Контрольний список для управління системою

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

Типові помилки, яких слід уникати

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

Поширені запитання про план управління системою

Чи повинна кожна компанія мати план управління системою?

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

Яка різниця між реєстром ІТ-систем та реєстром ліцензій?

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

Як часто слід оновлювати план управління системою?

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

Чи може одна й та сама особа бути власником системи та адміністратором системи?

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

Пов'язані посібники та шаблони

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

Джерела та додаткова література

• IMY: Ведення реєстру обробки персональних даних
• IMY: Обробка персональних даних компаніями
• Informationssäkerhet.se: Методична підтримка для систематичної роботи з інформаційної безпеки

Остання перевірка фактів: 13 жовтня 2026 року. Стаття надає загальні бізнес-рекомендації і не є юридичною консультацією. Перевірте, чи підпадає ваша діяльність під специфічні галузеві вимоги, договори або нормативні акти.