Безпека сайту: чек-лист і найкращі практики

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

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

Добра новина в тому, що більшість атак можна попередити базовою послідовною роботою. У статті розбираємо, чому безпека важлива для бізнесу, які загрози трапляються найчастіше (окремо про DDoS), даємо практичний чек-лист, додаткові вимоги для інтернет-магазинів, правила для WordPress та інших CMS, способи перевірки і план дій, якщо сайт зламали. Ми робимо і підтримуємо сайти в межах розробки корпоративних сайтів та інтернет-магазинів, тож чек-лист відображає те, що застосовуємо на реальних проєктах.

Чому безпека сайту важлива для бізнесу

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

Коли безпека дає збій, наслідки цілком конкретні:

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

Витік даних. Імена, телефони, email, адреси й історія замовлень клієнтів можуть потрапити до сторонніх. Витік даних означає прямі витрати (розслідування, повідомлення, юристи) і непрямі (втрачена довіра, скасовані замовлення).

Штрафи. Закон України «Про захист персональних даних» вимагає забезпечити захист персональних даних, а за порушення передбачена відповідальність. Якщо у вас є клієнти з ЄС, діє GDPR, де найсерйозніші порушення можуть коштувати до 20 млн євро або 4 % глобального річного обороту.

Шкода для SEO. Якщо Google виявить на сайті шкідливий код чи фішинг, Google Safe Browsing показуватиме відвідувачам червоне попередження в Chrome та інших браузерах, а в пошуку може з’явитися позначка, що сайт, можливо, зламано. Трафік обвалюється за години. Зламані сайти також використовують для розміщення спам-сторінок і посилань, які шкодять позиціям ще довго після очищення. Як безпека і HTTPS поєднуються з іншими чинниками, ми описали в статті про SEO-фактори ранжування.

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

Тож безпека — це не тема лише для IT. Це частина безперервності бізнесу, як страхування чи бухгалтерія.

Найпоширеніші загрози для сайтів

Щоб захиститися, не обов’язково розуміти механіку атак у деталях. Але знання основних категорій пояснює, навіщо кожен пункт чек-листа.

OWASP Top 10. Спільнота OWASP публікує список найкритичніших ризиків безпеки вебзастосунків. OWASP Top 10 у редакції 2025 року очолюють порушення контролю доступу, помилки конфігурації і атаки через ланцюжок постачання ПЗ, далі — криптографічні помилки, ін’єкції та небезпечна архітектура. Це стандартний орієнтир для розробників і аудиторів.

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

XSS. У сторінки, які бачать інші користувачі, впроваджують шкідливі скрипти, наприклад через коментарі чи поля форм. Вони можуть викрадати сесії або перенаправляти користувачів.

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

Brute-force. Боти перебирають тисячі паролів на сторінках входу, особливо на відомих адресах адмінок.

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

Вразливі плагіни. На сайтах з CMS застарілі або погано написані плагіни й теми — найчастіший вхід для нападників.

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

DDoS. Окремо про загрозу, яка для України особливо актуальна. DDoS-атака — це спроба «покласти» сайт, засипавши його величезною кількістю запитів з тисяч пристроїв одночасно, поки сервер не перестане відповідати справжнім відвідувачам. Це не злам: дані залишаються на місці, але сайт стає недоступним.

Чим DDoS відрізняється від DoS? DoS-атака (denial of service) йде з одного джерела, і її відносно легко заблокувати за адресою. DDoS (distributed denial of service) йде з тисяч заражених комп’ютерів, роутерів і серверів по всьому світу, тож блокування однієї адреси не допомагає. Саме тому від DDoS захищаються на рівні мережі, а не лише сервера.

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

• сайт раптово стає дуже повільним або зовсім недоступним, хоча ви нічого не змінювали

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

• навантаження на процесор і пам’ять сервера впирається в максимум, хостинг надсилає попередження про перевищення ресурсів

• запити мають дивну поведінку: однаковий user-agent, нуль часу на сторінці, сотні звернень до пошуку чи кошика за секунду.

Не кожен стрибок трафіку означає атаку. Розсилка, реклама чи згадка в медіа теж дають сплеск, але такі відвідувачі поводяться як люди: переходять між сторінками, додають товари, заповнюють форми. Якщо бачите ознаки атаки, не намагайтеся «перечекати»: увімкніть захист на рівні WAF і зв’яжіться з хостингом. Про сам захист — нижче, у чек-листі.

Чек-лист безпеки сайту

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

HTTPS і SSL/TLS

Що таке HTTPS простими словами? Це захищена версія протоколу, за яким браузер обмінюється даними із сайтом: усе, що передається, шифрується. Для шифрування потрібен SSL-сертифікат. SSL — історична назва технології, яку сьогодні замінив протокол TLS, але назва «SSL-сертифікат» залишилася. Це цифровий документ, який підтверджує, що сайт справді належить вашому домену, і дозволяє встановити зашифроване з’єднання.

• Переведіть увесь сайт на HTTPS, а не лише сторінки оплати й входу, і налаштуйте переадресацію з HTTP.

• Використовуйте сучасні протоколи: TLS 1.3, де можливо, TLS 1.2 як мінімум, вимкніть застарілі версії.

• Увімкніть HSTS, щоб браузери завжди підключалися по HTTPS.

• Автоматизуйте продовження сертифіката. Безкоштовні сертифікати Let's Encrypt і більшість платних можна продовжувати автоматично. Це важливіше з кожним роком: з березня 2026 року публічні TLS-сертифікати видаються максимум на 200 днів, у 2027 році строк скоротиться до 100 днів, а у 2029 — до 47. Ручне продовження скоро стане непрактичним.

• Перевірте змішаний контент, коли HTTPS-сторінка завантажує зображення чи скрипти по HTTP.

Оновлення та залежності

• Регулярно оновлюйте ядро CMS, плагіни й теми, встановлюйте патчі безпеки одразу після виходу.

• Тримайте актуальним серверне ПЗ: підтримувані версії PHP і Node.js, база даних, вебсервер.

• Перевіряйте залежності. npm audit для JavaScript-проєктів і аудит у Composer для PHP показують відомі вразливості бібліотек. Dependabot і схожі сервіси автоматично пропонують оновлення.

• Видаляйте непотрібні плагіни, теми і бібліотеки. Навіть невикористаний компонент залишається точкою атаки.

• Тестуйте оновлення на тестовій копії перед продакшеном.

Доступи й автентифікація

• Увімкніть двофакторну автентифікацію (2FA) для всіх акаунтів: адмінка, хостинг, реєстратор домену, CMS.

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

• Встановіть політику паролів: довгі унікальні паролі в менеджері паролів, жодних паролів у чатах і документах.

• Захистіть адмінку: змініть стандартні адреси входу, де можливо, обмежте кількість спроб, обмежте доступ за IP для внутрішніх інструментів.

• Раз на квартал переглядайте акаунти і видаляйте зайві.

Окремо про фішинг. Багато зламів починаються не з коду, а з листа «від хостингу» чи «від реєстратора домену» з проханням увійти на підроблену сторінку. З правильним паролем нападника не зупинить жоден фаєрвол, тому 2FA і поінформованість команди так само важливі, як технічні налаштування.

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

Заголовки безпеки

HTTP-заголовки безпеки кажуть браузеру, як поводитися із сайтом. Їх недорого налаштувати, а блокують вони цілі класи атак.

• Content Security Policy (CSP) визначає, з яких джерел браузер може завантажувати скрипти, стилі й зображення. Найсильніший захист від XSS.

• X-Frame-Options (або директива frame-ancestors у CSP) не дає вбудовувати ваші сторінки в чужі сайти для клікджекінгу.

• X-Content-Type-Options: nosniff забороняє браузеру «вгадувати» тип файлів.

• Додайте суворі Referrer-Policy і Permissions-Policy для функцій браузера, які сайту не потрібні.

Резервні копії та відновлення

• Дотримуйтесь правила 3–2–1: три копії даних, на двох різних типах носіїв, одна копія поза основною інфраструктурою.

• Визначте RPO і RTO. RPO (recovery point objective) показує, скільки даних ви можете дозволити собі втратити, наприклад замовлення за останню годину. RTO (recovery time objective) показує, скільки часу сайт може не працювати. Від цих цифр залежить, як часто робити бекапи і як швидко має працювати відновлення.

• Робіть резервні копії і файлів, і бази даних, автоматично, зберігайте кілька версій, а не лише останню.

• Зберігайте бекапи окремо від основного сервера, щоб нападник, який потрапив на сервер, не міг їх видалити.

• Регулярно проводьте тестове відновлення. Бекап, який ніколи не відновлювали, — це надія, а не бекап.

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

WAF, захист від DDoS і моніторинг

• Поставте перед сайтом WAF (web application firewall). WAF фільтрує шкідливі запити, блокує відомі шаблони атак і поглинає більшість DDoS-атак ще до того, як вони дійдуть до вашого сервера. Найпоширеніший варіант для бізнес-сайтів — Cloudflare; також захист від DDoS пропонують багато хостинг-провайдерів.

• Налаштуйте rate limiting на сторінках входу, пошуку, форм і API, щоб зупиняти перебір паролів і зловживання.

• Розумійте, від чого саме захищаєтеся. Одні DDoS-атаки забивають канал зв’язку чи мережеве обладнання величезним обсягом трафіку, інші імітують звичайних відвідувачів і перевантажують «важкі» сторінки: пошук, фільтри каталогу, кошик. Перші зупиняє мережевий захист провайдера, другі потребують правил WAF, лімітів запитів і перевірки підозрілих відвідувачів.

• Для захисту від DDoS заздалегідь продумайте план: як швидко увімкнути посилений режим захисту, хто на зв’язку, як повідомити клієнтів, якщо сайт тимчасово недоступний. Коли атака вже триває, найшвидше допомагає мережевий захист перед сайтом, тому налаштувати його краще до атаки, а не під час.

• Увімкніть моніторинг доступності зі сповіщеннями в пошту чи месенджер, щоб дізнаватися про проблеми раніше за клієнтів.

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

Хостинг і налаштування сервера

• Для бізнес-сайту обирайте managed-хостинг або професійно налаштований сервер. Дешевий віртуальний хостинг із застарілим ПЗ ставить вас поруч із «сусідами», яких ви не контролюєте.

• Регулярно встановлюйте оновлення сервера, зокрема операційної системи.

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

• Використовуйте ізольовані середовища: окремо продакшн, тестове і середовище розробки. Ніколи не залишайте тестові копії сайту у відкритому доступі.

• Вимкніть сервіси й порти, якими не користуєтеся.

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

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

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

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

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

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

• Перший місяць: оновити CMS, плагіни і серверне ПЗ, поставити WAF перед сайтом, налаштувати моніторинг доступності й додати базові заголовки безпеки.

• Перший квартал: просканувати сайт на вразливості, перевірити повне відновлення з бекапу, переглянути налаштування хостингу і написати план дій на одну сторінку, зокрема на випадок DDoS-атаки.

Такий порядок спочатку закриває найпоширеніші входи: викрадені паролі, застаріле ПЗ і відсутність способу повернутися після інциденту. Складніші пункти, як-от сувора Content Security Policy чи пентест, ідуть після того, як база стабільна.

Додаткові вимоги для інтернет-магазинів

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

PCI DSS. Усі, хто приймає оплату картками, мають відповідати стандарту безпеки платіжних карток. Актуальна версія — 4.0.1, і всі її вимоги обов’язкові з 31 березня 2025 року. Найпростіший спосіб зменшити обсяг вимог: ніколи не пропускати номери карток через власні сервери.

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

3-D Secure. Додаткове підтвердження оплати власником картки, зазвичай у банківському застосунку, зменшує шахрайство.

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

Шифрування. Шифруйте чутливі дані в базі та в бекапах, а не лише під час передачі.

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

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

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

Безпека WordPress та інших CMS

WordPress працює на величезній частині сайтів у світі, тому це найбільш атакована CMS. Саме ядро регулярно оновлюють і латають. Більшість зламів WordPress відбуваються через плагіни, теми, слабкі паролі та застарілі встановлення. Короткий чек-лист:

• Перевірка плагінів. Встановлюйте плагіни лише від надійних розробників з нещодавніми оновленнями і великою кількістю активних встановлень. Менше плагінів означає менше ризиків.

• Автоматичні оновлення для дрібних релізів ядра і патчів безпеки, регулярні оновлення плагінів і тем після тестування.

• Плагін безпеки. Інструменти на кшталт Wordfence додають фаєрвол, сканування на шкідливий код і захист входу на рівні застосунку.

• XML-RPC. Вимкніть, якщо не використовуєте. Це часта ціль для перебору паролів і атак з підсиленням.

• Редагування файлів. Вимкніть вбудований редактор файлів в адмінці.

• Адміністратори. 2FA, жодного стандартного логіна «admin», мінімум адміністраторів.

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

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

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

Тестування та аудит безпеки

Безпека не налаштовується один раз. Її треба регулярно перевіряти.

Сканування вразливостей. Автоматичні сканери перевіряють сайт на відомі вразливості, застаріле ПЗ і помилки конфігурації. Запускайте їх щонайменше щомісяця і після великих змін. OWASP ZAP — безкоштовний і поширений сканер, Burp Suite — стандартний професійний інструмент для глибшого тестування.

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

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

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

Як часто перевіряти? Практичний ритм для більшості бізнес-сайтів: постійний автоматичний моніторинг, щомісячне сканування, щоквартальний перегляд доступів і щорічний зовнішній аудит або пентест. Більшість цих задач входить у регулярну технічну підтримку сайту, про яку ми окремо пишемо в цій серії статей.

Що робити, якщо сайт зламали

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

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

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

3. Змініть усі паролі. Хостинг, адміністратори CMS, база даних, FTP чи SSH, реєстратор домену, платіжний сервіс, підключені сервіси. Увімкніть 2FA там, де її не було.

4. Знайдіть точку входу. Застарілий плагін, слабкий пароль, витік облікових даних, вразливий код. Без усунення причини сайт зламають знову за кілька днів.

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

6. Запросіть перевірку. У Google Search Console перегляньте звіт «Проблеми безпеки» і після очищення надішліть запит на перевірку, щоб попередження зникли з пошуку і браузерів.

7. Повідомте користувачів і CERT-UA. Якщо постраждали персональні дані, повідомте клієнтів і, де вимагає закон, відповідні органи. Про серйозні кіберінциденти, зокрема масштабні DDoS-атаки, варто повідомити CERT-UA, урядову команду реагування на комп’ютерні надзвичайні події України.

8. Зробіть висновки. Оновіть чек-лист, моніторинг і процеси, щоб ситуація не повторилася.

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

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