Коли ми розробляємо політики чи інструкції, у розділі про ролі й комунікацію зі стейкхолдерами майже завжди зʼявляється класична RACI-матриця. Англійською все чітко: Responsible, Accountable, Consulted, Informed — чотири різні слова, чотири різні ролі.
А тепер спробуйте перекласти перші дві українською. Responsible і Accountable обидва природно тягнуться до одного й того самого слова — “відповідальний”. Google Translate чесно пропонує для Accountable варіант “підзвітний”, але в контексті матриці ролей це звучить дивно і незрозуміло (принаймні мені 😃). І ось тут і починається проблема, яка потім спливає в кожній політиці, посадовій інструкції та розмові з аудитором.
Дві різні відповідальності
В англійській це не синоніми, а два принципово різні поняття:
- Responsible — той, хто виконує роботу. Виконання можна делегувати, можна розділити між кількома людьми, можна перерозподілити, коли хтось пішов у відпустку.
- Accountable — той, хто відповідає за результат перед вищим рівнем: керівництвом, регулятором, клієнтом. Ця відповідальність не делегується. І що важливо — вона завжди належить рівно одній особі чи ролі.
Класична формула, яку варто запамʼятати: responsibility можна делегувати, accountability - ні. Підрядник responsible за те, щоб будинок був збудований якісно й вчасно. Забудовник accountable перед мешканцями — і саме до нього прийдуть, якщо щось піде не так, хоч би скільки підрядників він найняв.
Пастка з двома “А”
Це не абстрактна лінгвістика — вона напряму ламає RACI-матриці. Правило матриці просте: на кожен рядок (кожну задачу чи рішення) має бути рівно одна А. Не нуль, не два.
Коли А з’являється двічі, на практиці це означає, що ніхто насправді не accountable — відповідальність розмивається між двома людьми, і в момент кризи кожен щиро вважає, що останнє слово було за іншим. Коли А немає взагалі, задача так само нічия — виконавці (R) є, а хто саме звітує за результат перед керівництвом — незрозуміло.
Ще одна типова помилка — коли та сама людина в матриці всюди і R, і A. Формально це не заборонено (власник продукту цілком може сам собі й виконавець, і відповідальний), але якщо це відбувається систематично по всій матриці — це ознака або перевантаженої людини, або фіктивно складеної матриці, яку ніхто насправді не використовував для розподілу ролей.
Як це виглядає в GRC
У ризик-менеджменті цей поділ — не теорія, а щоденна практика.
власник ризику — accountable за ризик. Це не означає, що він особисто впроваджує заходи зменшення ризику: технічну реалізацію контролю виконує (responsible) умовний DevOps-інженер чи адміністратор. Але коли ризик реалізується, питання “чому нічого не зробили” йде до власника ризику, а не до виконавця.
Той самий поділ — між власник даних і зберігач даних. Власник даних accountable за те, як дані класифіковані і хто має до них доступ; custodian (умовно, адміністратор бази даних чи хмарної платформи) responsible за технічне зберігання й резервне копіювання.
CISO зазвичай accountable за програму безпеки в цілому — але це не означає, що CISO особисто патчить сервери. Патчі накатують інженери, відповідальні (responsible) за конкретні системи.
ISO/IEC 27001:2022, пункт 5.3 (“Organizational roles, responsibilities and authorities”), прямо вимагає, щоб топ-менеджмент призначив responsibility та authority за відповідність системи управління інформаційною безпекою вимогам стандарту — і зобов’язав звітувати про це саме перед топ-менеджментом. Тобто навіть якщо все технічне впровадження делеговане вниз по організації, кінцева accountability лишається нагорі й нікуди не дівається.
GDPR іде ще далі й робить з accountability окремий принцип — стаття 5(2) вимагає, щоб контролер персональних даних міг довести відповідність усім принципам обробки даних, а не просто задекларувати її. І показово, що офіційний український переклад Регламенту використовує тут слово “підзвітність” — тобто саме той варіант, який Google Translate підказує для RACI, але який у контексті самої матриці ролей звучить незвично. У контексті GDPR “підзвітність” працює природно: контролер підзвітний регулятору. У контексті RACI — гірше, бо там accountable протиставляється не якомусь абстрактному регулятору, а конкретному відповідальному в тому самому рядку.
Ще один практичний наслідок — аутсорсинг і хмара. Коли компанія передає обробку даних хмарному провайдеру чи аутсорс-команді, вона передає відповідальність (responsibility) за виконання. Accountability перед регулятором чи клієнтом лишається на компанії — про це прямо кажуть GDPR (контролер лишається відповідальним, навіть якщо обробку виконує процесор) і практика ISO 27001 щодо постачальників. “Ми віддали це на аутсорс” не знімає accountability, хоч скільки б хотілося.
Які українські відповідники насправді працюють
Особисто я схиляюсь до простого варіанту: Accountable → “Відповідальний”, Responsible → “Виконавець”.
Якщо хочеться зберегти в обох словах корінь “відповідальність” (бо саме так ці ролі й сприймаються менеджментом), працює пара: Accountable → “Відповідальний за результат”, Responsible → “Відповідальний за виконання”. Довше, зате в документі одразу видно логіку без додаткової легенди.
Формальний “підзвітний” для Accountable теж має право на життя — саме такий варіант закріплений в українських перекладах ISO 27000-серії (коли вони ще робились) та GDPR — але в живій розмові про RACI-матрицю він частіше плутає, ніж пояснює, тому в командах я його не рекомендую.
Універсальна порада для політик і посадових інструкцій — не покладатись на одне слово взагалі. Замість “Відповідальний: системний адміністратор” писати конструкціями, які явно показують тип відповідальності:
- “Забезпечує виконання резервного копіювання” — це Responsible.
- “Несе відповідальність за результат резервного копіювання та звітує керівництву” — це Accountable.
Так навіть без знання абревіатури RACI читач політики розуміє, хто саме прийде з поясненнями, якщо бекапи не відновляться.
Міні-приклад
Погана формула, яку можна побачити в політиках:
Відповідальний за резервне копіювання — системний адміністратор.
Після поділу ролей вона перетворюється на щось конкретніше:
| Роль | Хто | Тип |
|---|---|---|
| Виконує резервне копіювання | Системний адміністратор | Responsible |
| Відповідає за результат перед керівництвом | Керівник ІТ-відділу | Accountable |
| Консультується щодо політики зберігання | Юридичний відділ / DPO | Consulted |
| Отримує звіт про виконання | CISO | Informed |
Тепер у момент, коли бекапи не відновились, зрозуміло не лише хто технічно накосячив, а й хто йде пояснювати це на нараду з керівництвом.
Підсумок
В англійській для двох різних понять є два різні слова. В українській природньо просяться в одне — і саме тому ця дрібниця так часто губиться в перекладі політик, стандартів і навіть офіційних текстів регламентів. Responsibility делегується й ділиться, accountability — ні і завжди належить одній ролі. У RACI-матриці на кожен рядок має бути рівно одна А. А в тексті політики краще взагалі уникати одного слова “відповідальний” і писати конструкцією, яка сама пояснює, про яку саме відповідальність йдеться.