Електронний лист приходить на вашу спільну скриньку о 16:47 у п'ятницю: «Згідно з нашою політикою закупівель, нам потрібно буде побачити ваш звіт SOC 2 Type II, перш ніж ми зможемо перейти до підписання контракту». Ваш потенційний клієнт — фінансова команда зі списку Fortune 500. Угода коштує більше в річному повторюваному доході (ARR), ніж ваш останній посівний раунд. А у вас, м'яко кажучи, нуль сторінок звіту SOC 2.
Така сцена розігрується в SaaS-стартапах щотижня. До того часу, як засновник чує слова «SOC 2 Type II», майже завжди вже є прив'язана угода — і майже завжди є нерозуміння того, скільки насправді триває цей процес. SOC 2 Type II — це не документ, який ви замовляєте і отримуєте. Це висновок, який надає незалежний аудитор щодо того, чи ефективно працювали ваші заходи контролю безпеки протягом багатомісячного вікна спостереження. Ви не можете створити це вікно ретроспективно. Ви можете лише розпочати його.
Цей посібник розповідає про те, чим насправді є SOC 2 Type II, як визначити його обсяг, щоб він не поглинув ваш план розробки (engineering roadmap), як виробити звички безперервного моніторингу, яких аудитори очікують у 2026 році, і як підтримувати воронку продажів у русі, поки робота з комплаєнсу йде паралельно.
Що насправді перевіряє SOC 2 Type II
SOC 2 — це система звітності, яку підтримує Американський інститут дипломованих державних бухгалтерів (AICPA). Це не сертифікація. Немає сертифіката, який можна повісити на стіну. Замість цього аудиторська фірма (CPA) вивчає ваше середовище контролю на відповідність Критеріям довірчих послуг (Trust Services Criteria), а потім видає звіт, який клієнти, партнери та відділи корпоративних закупівель використовують для оцінки того, чи є прийнятним аутсорсинг частини їхніх операцій вашому сервісу.
Існує два види:
- Type I — це звіт на певну дату. Він описує ваші заходи контролю та перевіряє їхню структуру станом на конкретне число. Це швидше, дешевше і відповідає на питання «чи існували заходи контролю 1 жовтня?»
- Type II — це звіт за певний період. Він перевіряє як структуру, так і операційну ефективність цих заходів контролю протягом вікна спостереження від 3 до 12 місяців. Він відповідає на набагато складніше питання: «чи справді ці заходи контролю працювали щодня протягом усього періоду?»
Корпоративні покупці майже завжди хочуть Type II. Type I зазвичай розглядається як доказ того, що ви на шляху, а не як доказ того, що ви досягли мети. Якщо команда закупівель просить «SOC 2» без уточнення, вважайте, що вони мають на увазі Type II.
Вікно спостереження — це та частина, яка дивує засновників. Якщо потенційному клієнту потрібно побачити звіт, що охоплює період з 1 січня по 30 червня, а ви впровадили заходи контролю лише 15 березня, ви не зможете надати такий звіт. Прогалина в перші місяці за визначенням є невідповідністю. Терміни аудиту залежать не від того, як швидко працює ваш аудитор, а від того, скільки історії ви вже накопичили.
Критерії довірчих послуг: ретельно обирайте обсяг
Кожен звіт SOC 2 оцінюється за одним або декількома з п'яти Критеріїв довірчих послуг (TSCs):
- Security (Безпека) — єдиний обов'язковий критерій. Іноді його називають «загальними критеріями» (common criteria); він охоплює контроль доступу, управління змінами, управління вразливостями, реагування на інциденти та базову структуру управління програмою інформаційної безпеки.
- Availability (Доступність) — актуально, якщо ваші контракти з клієнтами включають зобов'язання щодо часу безперебійної роботи або SLA. Додає планування потужностей, екологічні заходи безпеки та тестування аварійного відновлення.
- Processing Integrity (Цілісність обробки) — актуально, якщо ваш сервіс виконує транзакції або розрахунки, де важлива коректність (платежі, системи бухгалтерського обліку, білінгові системи). Більшість SaaS-стартапів можуть пропустити це на початку.
- Confidentiality (Конфіденційність) — актуально, якщо ви обробляєте дані клієнтів, які обмежені договором, але не обов'язково є персональними (вихідний код, фінансові дані, бізнес-плани).
- Privacy (Приватність) — актуально, якщо ви збираєте, використовуєте, зберігаєте або видаляєте персональну інформацію фізичних осіб. Часто перетинається із зобов'язаннями за GDPR та CCPA.
Ось помилка у визначенні обсягу, яку роблять стартапи: вони обирають усі п'ять критеріїв, бо думають, що більша кількість критеріїв виглядає солідніше. Це не так. Це робить аудит дорожчим, подовжує терміни, збільшує навантаження зі збору доказів і дає аудитору більше точок для виявлення зауважень. Корпоративні покупці зазвичай дбають про Безпеку плюс те, що безпосередньо стосується конкретної послуги, яку вони купують. Фінансову команду, яка ліцензує ваш аналітичний продукт, цікавить Конфіденційність. Команду, яка покладається на вашу платформу для критично важливих бізнес-процесів, цікавить Доступність.
Почніть лише з Безпеки для вашого першого Type II. Додавайте критерії в наступних циклах аудиту, коли цього вимагатиме попит клієнтів.
Скільки це коштує і скільки часу займає
Для невеликої SaaS-компанії у 2026 році реальні цифри виглядають так:
- Аудиторські збори: від $10,000 до $25,000 за Type II (тільки Безпека) від CPA-фірми середнього рівня або бутікового агентства. Додавання Доступності та Приватності може підняти ціну до $25,000–$30,000. Фірми «Великої четвірки» беруть у рази більше і зазвичай взагалі не працюють з малими стартапами.
- GRC-платформа: від $5,000 до $12,000 на рік за автоматизований збір доказів та управління політиками.
- Оновлення інструментів безпеки: від $3,000 до $8,000 для усунення прогалин у MDM, SIEM, скануванні вразливостей або перевірці контрагентів.
- Внутрішній час: від 100 до 200 годин інженерів та операційного персоналу протягом циклу підготовки та аудиту.
Загалом очікуйте витрати від $20,000 до $35,000 за перший рік для невеликої SaaS-компанії, яка підходить до цього вдумливо. Наступні роки коштуватимуть значно менше, оскільки основна робота над політиками, інструментами та процесами вже виконана.
Терміни залежать від вікна спостереження:
- Фаза підготовки: 1–3 місяці на написання політик, впровадження контролів, налаштування інструментів та усунення прогалин. Формальна оцінка готовності від вашого майбутнього аудитора додасть від $10,000 до $17,000 і кілька тижнів, але суттєво знизить ризики під час самого аудиту.
- Вікно спостереження: мінімум 3 місяці для «короткого» Type II, 6 місяців для більш надійного звіту, 12 місяців для циклу оновлення. Корпоративні покупці мають різні вимоги до вікна спостереження. Багато хто прийме 3-місячний Type II, якщо ви зобов'яжетеся провести 12-місячний повторний аудит.
- Польові роботи та звіт: 2–4 тижні перевірки доказів, опитувань, вибірок та написання звіту після закриття вікна спостереження.
Стартап, який починає підготовку в січні та запускає 3-місячне вікно спостереження, може отримати звіт SOC 2 Type II на руки наприкінці травня або на початку червня. Це найшвидший реальний шлях. Той, хто обіцяє швидше, або продає Type I, або пропонує щось, що згодом змусить вас червоніти.
Контролі, на яких найчастіше "спотикаються" стартапи
Опубліковані Критерії довірчих послуг (Trust Services Criteria) включають десятки загальних критеріїв (від CC1 до CC9) і ще десятки для додаткових категорій. На практиці ж найбільше клопоту завдає лише кілька основних контролів:
Перевірка прав доступу. Ви повинні перевіряти доступ користувачів до виробничих систем і даних клієнтів із визначеною періодичністю — зазвичай щоквартально. Контроль не проходить не тому, що перевірка не проводиться, а тому, що докази є неповними: немає тікета, немає підпису, немає запису про видалені облікові записи. Якщо ви не можете показати підписаний список того, хто, що і в яку дату перевіряв, перевірка не зараховується.
Управління змінами. Кожна зміна коду, яка стосується продакшну, потребує pull request, рецензування колегами (peer review), автоматизованого тестування та задокументованого розгортання. Більшість інженерних команд уже це роблять. Проблема виникає з екстреними виправленнями (hotfixes), які обходять цей конвеєр. Аудитори вибірково перевіряють розгортання, і одне "ковбойське" проштовхування коду у вікні спостереження може стати зауваженням.
Перевірка персоналу (Background checks). Кожен працівник із доступом до продакшну повинен пройти задокументовану перевірку біографічних даних до отримання такого доступу. Стартапи часто надають доступ у перший же день, а перевірку проводять "незабаром після цього". Це порушення. Форлювання контролю звучить як "до отримання доступу", і аудитори перевірятимуть дати.
Управління постачальниками. Вам потрібен список субобробників (subprocessors), докази того, що ви перевірили стан безпеки кожного з них (зазвичай шляхом збору їхніх звітів SOC 2), і задокументований відповідальний за ці відносини. Слабке місце тут — "тіньові" SaaS-інструменти, на які підрозділ підписався за допомогою кредитної картки, нікому про це не повідомивши.
Управління вразливостями. Вам потрібна задокументована періодичність сканування, визначений регламент (SLA) усунення вразливостей залежно від їхньої критичності та докази того, що ви дійсно дотримуєтеся цих термінів. Багато стартапів пишуть політику, де сказано: "критичні вразливості виправляються протягом 7 днів", а потім тихо дозволяють критичним знахідкам висіти по 60 днів, бо випуск нової фічі був терміновішим. Аудитор вибірково перевірить тікети.
Реагування на інциденти. Вам потрібен письмовий план реагування на інциденти та докази того, що ви його протестували. "Настільні" вправи (tabletop exercises) зараховуються. Вправа не обов'язково має бути складною, але зустріч повинна відбутися — з порядком денним, списком присутніх і протоколом.
Логічний доступ — MFA, політика паролів, тайм-аути сесій. З цим зазвичай усе гаразд у сучасних стартапах, що використовують провайдерів ідентифікації, як-от Okta або Google Workspace, але збір доказів є кропітким. Вам знадобляться скріншоти конфігурацій, експорт політик і докази того, що ці контролі діяли протягом усього періоду спостереження.
Безперервний моніторинг: у 2026 році планка вища
Визначальною зміною в очікуваннях SOC 2 за останні три роки став перехід від періодичних вибіркових перевірок до безперервного моніторингу. Аудитори у 2026 році все частіше очікують, що ваше середовище контролів створює докази, які можна перевірити щодня, а не те, що ви поспіхом збираєте їх за тиждень до початку польових робіт.
Конкретно це означає:
- Автоматизований збір доказів. GRC-платформи, такі як Vanta, Drata, Secureframe та Sprinto, інтегруються з вашим провайдером ідентифікації, хмарними акаунтами, репозиторіями коду, системою тікетів та HR-інструментами для безперервного отримання доказів. Вони виявлять недолік контролю — наприклад, доступ до AWS у звільненого працівника, який не був вчасно закритий — протягом годин, а не місяців.
- Дашборди в реальному часі. Ви повинні мати можливість подивитися на один екран і побачити робочий статус кожного контролю. Якщо контроль не спрацьовує, це має бути позначено протягом 48 годин із визначеним шляхом до виправлення.
- Безперервні аудиторські сліди. Аудитори шукають послідовність. Якщо у ваших доказах перевірки доступу є місяці, коли перевірка не проводилася — це зауваження. Якщо ваш лог сканування вразливостей пропустив квартал — це зауваження. Неявний стандарт у 2026 році такий: кожен день періоду спостереження повинен генерувати докази того, що контроль працював.
Культурне зрушення, якого це вимагає, є цілком реальним. Комплаєнс має стати звичкою, вбудованою в те, як ваша інженерна команда випускає код, як ІТ-команда проводить онбординг, а фінансовий відділ обирає постачальників. Розгляд SOC 2 як квартального "штурму" перед аудитом у нинішньому кліматі призведе радше до висновків із зауваженнями (qualified opinions), ніж до чистих звітів — а звіт із зауваженнями часто гірший за його відсутність, коли його читає команда з корпоративних закупівель.
Паралельне ведення аудиту та продажів
Фундаментальна дилема в роботі над SOC 2, орієнтованій на клієнта, полягає в тому, що аудит триває місяцями, а угода не чекає. Ось як підтримувати рух у воронці продажів:
- Почніть зі звіту Type I та плану усунення недоліків. Звіт Type I може бути виданий протягом кількох тижнів після завершення підготовки. Це не те, чого зрештою хочуть корпоративні покупці, але це надійний сигнал про те, що ви налаштували середовище контролів і підготовка до Type II триває. Багато команд із закупівель підпишуть контракт на основі Type I разом із письмовим зобов'язанням надати Type II протягом дев'яти місяців.
- Використовуйте практику супровідних листів (bridge letters). Якщо у вас є попередній звіт Type II, що охоплює період, який уже закінчився, ваш аудитор може видати "супровідний лист" (bridge letter), підтверджуючи, що, наскільки йому відомо, між датою закінчення звіту та сьогоднішнім днем не відбулося суттєвих змін. Такі листи зберігають актуальність вашого старого звіту для нових угод, поки триває наступний аудит.
- Діліться необхідними артефактами під NDA. Деякі потенційні клієнти замість звіту SOC 2 приймуть ваші письмові політики безпеки, резюме тестів на проникнення (pentest) та схеми архітектури для угод про пілотні проєкти (proof-of-concept). Тримайте ці документи готовими, актуальними та скомплектованими, щоб заповнення опитувальника з безпеки не перетворилося на багатотижневе відволікання для вашої інженерної команди.
- Будьте чесними щодо термінів. Обіцянка надати звіт Type II до дати, у яку ви не вкладаєтеся, підриває довіру клієнта, коли термін переноситься. Обіцянка реалістичного графіка, підкріплена підписаним листом-зобов'язанням із відомою аудиторською фірмою, є набагато надійнішою.
Стартапи, які справляються з цим найкраще, ставляться до SOC 2 не як до "пожежної тривоги", спричиненої однією угодою, а як до фундаментальної інфраструктури, що відкриває доступ до цілого сегмента клієнтів. Перший аудит — це дорого і некомфортно. Четвертий — це просто звичайна стаття витрат.
Бухгалтерський облік витрат на комплаєнс
Програма SOC 2 — це також значний центр витрат, і те, як ви ведете її облік, має велике значення наприкінці року. Гонорари аудиторів, підписки на GRC-платформи, консалтинг із підготовки та інструменти безпеки — усе це проходить через різні рахунки головної книги й часто класифікується неправильно. Гонорари аудиторів та консультантів зазвичай належать до професійних послуг, тоді як підписки на інструменти — до витрат на програмне забезпечення. Деякі компанії на ранніх стадіях капіталізують частину робіт із підготовки як розробку ПЗ для внутрішнього використання згідно з ASC 350-40, хоча межа для того, щоб зробити це коректно, є досить вузькою.
Окрім категоризації, програма комплаєнсу створює потік періодичних витрат — щорічне поновлення аудиту, збори GRC-платформ, витрати на перевірку персоналу, послуги з тестування на проникнення — які необхідно відстежувати відповідно до бюджету. Багато стартапів закладають недостатньо коштів на другий рік, тому що пам’ятають «ціновий шок» від підготовки, але забувають, що регулярні операційні витрати — це також реальні гроші. Чиста бухгалтерія з контролем версій із самого початку значно полегшує відповіді на запитання під час дью-ділідженсу для наступного раунду інвесторів та на опитувальники з безпеки від ваших клієнтів — і ті, й інші запитуватимуть про ваше середовище контролю та дисципліну витрат у ньому.
Підтримуйте фінансову звітність у такій же готовності до аудиту, як і заходи безпеки
Незалежно від того, чи ви готуєтеся до SOC 2 Type II, раунду Series A, чи просто намагаєтеся вчасно закривати книги кожного місяця, діє той самий принцип: системи, що піддаються аудиту, щоразу перемагають ручне ведення записів. Beancount.io пропонує текстову бухгалтерію (plain-text accounting), яка є прозорою, підтримує контроль версій та готова до використання з ШІ — надаючи засновникам і фінансовим командам повний аудиторський слід без непрозорості «чорної скриньки» застарілих інструментів обліку. Почніть безкоштовно і дізнайтеся, чому розробники та фінансові фахівці переходять на plain-text accounting.