arrow_backНазад до польових записів
CERTIFICATIONS Опубліковано 6 Aug 2026

Підготовка до аудиту: ISO 27001, SOC 2, Cyber Essentials

Практичний огляд того, що аудитори насправді перевіряють для ISO 27001, SOC 2 та Cyber Essentials, і як підготуватися без паніки.

Більшість команд ставляться до аудиту відповідності як до навчання на екстрених випадках, що з'являється раз на рік. Не обов'язково має бути так, і самі фреймворки не такі таємничі, як говорять продавці. Ось що насправді важливо, коли ви готуєтесь до ISO 27001, SOC 2 або Cyber Essentials.

Знайте, який саме фреймворк вас просять впровадити

Ці три часто змішують, але вони вирішують різні проблеми. ISO 27001 — це стандарт системи управління, який сертифікує, що ви мають функціональну Систему управління інформаційною безпекою (ISMS) з оцінками ризиків, політиками і постійним вдосконаленням. SOC 2 — це звіт про підтвердження, зазвичай Type II, за певний період часу (зазвичай 6-12 місяців) відповідно до критеріїв надійності: безпека, доступність, цілісність обробки, конфіденційність, приватність. Cyber Essentials — це схема, схвалена британським урядом, що фокусується на п'яти базових технічних контролях: брандмауери, безпечна конфігурація, контроль доступу, захист від шкідливого ПО та управління патчами.

Якщо клієнт каже «вам потрібно бути сертифіковані за SOC 2», запитайте, який тип і які критерії їм насправді важливі. Більшість B2B SaaS угод вимагають лише Security та Availability, а не всі п'ять критеріїв.

Побудуйте траєкторію доказів до того, як аудитор запитає

Аудитори не вірять вам на слово — вони хочуть артефактів. Для ISO 27001 це означає Statement of Applicability, що відображає всі 93 контролі в Annex A (редакція 2022) на те, що ви впровадили або виключили, з обґрунтуванням. Для SOC 2 це означає скріншоти, логи та тікети, що доводять послідовну роботу контролів протягом періоду аудиту, а не лише в той день, коли хтось пригадав налаштувати це.

Наладьте збір доказів як постійний процес, а не поспішну роботу:

# Приклад: витягніть дані аудиту доступу IAM щомісяця через AWS CLI
aws iam generate-credential-report
aws iam get-credential-report --output text --query 'Content' | base64 -d > access-report-$(date +%Y%m).csv

Зберігайте ці файли з позначками часу в спеціальному репозиторії доказів (папка Google Drive, Vanta, Drata — що б ви не використовували) упорядковані за ID контролю, а не за місяцем. Аудитори вибірково перевіряють період; вам потрібно довести, що контроль працював у березні і жовтні, а не лише коли ви пригадали.

Контролі, що завжди спіткають людей

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

Управління ризиками постачальників — другий великий розрив. ISO 27001 пункт A.5.19-A.5.23 і критерії управління постачальниками SOC 2 обидва очікують, що ви оцінюватимете підпроцесори — хмарні провайдери, обробники платежів, все, що торкається даних клієнтів. Однієї сторінки анкети ризику постачальника на критичного постачальника, переглянутої щорічно, достатньо для більшості з цього.

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

Для Cyber Essentials питання про технічну область важливіші, ніж люди очікують. Вам потрібно точно описати вашу границю — кожен пристрій, хмарну послугу та політику BYOD в межах масштабу — тому що неправильне представлення масштабу є підставою для відмови, навіть якщо технічні контролі гарні. Управління патчами перевіряється буквально: критичні та high-severity патчі повинні бути застосовані в межах 14 днів після випуску для сервісів, доступних з інтернету.

Реалістична внутрішня графік

Для SOC 2 Type II планує 3-6 місяців збору доказів до початку периоду аудиту, оскільки Type II вимагає доведення того, що контролі працювали протягом периоду спостереження, а не лише в певний момент часу. Сертифікація ISO 27001 зазвичай займає 6-12 місяців від оцінки розриву до сертифіката, включаючи Stage 1 документальний огляд і Stage 2 очне (або дистанційне) оцінювання органом сертифікації. Cyber Essentials швидше — анкети самооцінки можуть бути завершені протягом кількох тижнів, якщо ваші основи вже в порядку, Cyber Essentials Plus додає зовнішню технічну перевірку.

Не дозволяйте аудиту бути єдиною перевіркою вашої роботи

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

Якщо ви хочете глибше вивчити технічні контролі за цими фреймворками — дизайн контролю доступу, логування, реагування на інциденти — перевірте Blue Team та Certifications треки на Korra Studio.

Написано з допомогою штучного інтелекту, перевірено та опубліковано Мішалем Пільчем (CISSP), Korra Studio.

Готові йти далі?

Це одна замітка з бази знань Korra Studio — платформа поєднує кожну тему з 1-на-1 менторингом.

Початок безплатноarrow_forward