Модуль 1 · Урок 3 із 34
Операційна модель: доступи, approval і escalation
Стабільний SMM — це не людина з паролем у чаті. Це контрольований workflow: least privilege, named owners, content approval, publishing evidence, moderation SLA, incident severity і revocation.
RACI без бюрократії
| Роль | Питання | Правило |
|---|---|---|
| Accountable | Хто приймає результат і несе відповідальність? | Один named owner на work item |
| Responsible | Хто виконує роботу? | Може бути кілька, але scope явний |
| Consulted | Чия експертиза потрібна до рішення? | Двостороння комунікація |
| Informed | Кому повідомляють результат? | Не перетворювати на прихованого approver |
Доступ — це окремий життєвий цикл
Asset, роль, мінімальний permission, purpose, строк і approver.
Іменний доступ через business tools; не передавати shared passwords у повідомленнях.
Регулярно звіряти active people, roles, partners і recovery owners.
Одразу після зміни ролі, завершення контракту або incident.
Хто погодив, коли переглянуто і хто відповідає за emergency route.
Publishing preflight
Escalation за severity
| Сигнал | Перша дія | Не робити |
|---|---|---|
| Фактична помилка без шкоди | Freeze evidence, notify owner, prepare correction | Тихо переписувати без log |
| PII або account compromise | Pause, security escalation, revoke/rotate, preserve evidence | Продовжувати публікації |
| Threat або safety concern | Застосувати safety policy й emergency route | Сперечатися публічно самостійно |
| Критика/негатив без порушення | Класифікувати, відповісти за tone/SLA або передати owner | Автоматично видаляти незручний feedback |
Практика
- Заповніть `stakeholder-raci.csv` та `access-approval-register.csv`.
- Проведіть tabletop incident: помилковий claim + leaked personal detail.
- Запишіть pause, notification, correction, evidence і recovery sequence.
- Не тестуйте процедуру на live-акаунті.
Офіційне джерело
Закріпіть матеріал уроку
Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.