Технічні та організаційні заходи (Art. 32 GDPR)

B.1 Шифрування

• Дані в русі: TLS 1.2+ для всіх зʼєднань — застосунок, API, сховище файлів, платежі, інтеграції.
• Дані у спокої: AES-256 для бази даних і медіафайлів на рівні інфраструктури (EU-регіон).
• OAuth-токени інтеграцій Zoom і Google Meet додатково шифруються AES-256-GCM на рівні застосунку.

Не заявляється: Керований KMS із задокументованою ротацією ключів.

B.2 Контроль доступу

• Рольова модель у межах workspace: власник / адміністратор / дослідник / переглядач. Ролі зберігаються окремо від профілю користувача.
• Ізоляція тенантів на рівні бази даних: row-level security для всіх таблиць із клієнтським контентом.
• Принцип найменших привілеїв: сервісний ключ використовується лише серверними функціями, клієнт — лише під обмеженим ключем із RLS.
• Двофакторна автентифікація (TOTP) доступна всім користувачам і є обовʼязковою для адміністративного доступу.
• Мінімальна довжина пароля 12 символів із перевіркою за базою скомпрометованих паролів.
• Команда може зробити 2FA обовʼязковою для всіх учасників: після 72-годинного пільгового періоду учасники без 2FA втрачають доступ до проєктів команди, вимога перевіряється на рівні бази даних.
• Єдиний вхід SAML 2.0 (Okta, Microsoft Entra ID, Google Workspace та інші SAML-провайдери) для команд: прив'язка за доменом пошти, автоматичне додавання учасників у межах доступних місць, можливість зробити вхід через SSO обовʼязковим. Підключення провайдера виконується за запитом команди.
• Завершення сесій: при видаленні учасника з команди або зниженні його ролі всі його входи завершуються; після зміни пароля інші пристрої виходять із системи; кожен користувач може вийти з усіх пристроїв, а власник команди — примусово завершити сесії учасника.
• Обмеження кількості запитів до входу, публічних і AI-функцій за IP-адресою та користувачем; перевищення записуються в журнал безпеки.
• Квартальний перегляд production-доступу за задокументованою процедурою.

B.3 Журналювання та моніторинг

• Незмінний журнал безпеки: записи не можна змінити чи видалити, повний журнал доступний лише адміністратору безпеки.
• Логуються вхід і вихід, зміна пароля, увімкнення та вимкнення 2FA, надання й відкликання ролей, надання і відкликання доступу до проєкту, видалення проєкту, експорт даних, запит на видалення та видалення акаунта, кожне звернення до адміністративних даних.
• Кожен запис містить актора, ресурс, IP-адресу, user-agent і час події.
• Строк зберігання журналу — 24 місяці, після чого записи видаляються автоматично.
• Власники та адміністратори команди бачать журнал подій своєї команди (запрошення, зміни ролей і доступів, зміни політик безпеки, експорти) з фільтрами та вивантаженням у CSV; події інших команд їм недоступні.
• Зведений огляд безпеки команди: частка учасників із 2FA, статус SSO, термін збереження, проєкти перед автоматичним переміщенням у кошик, експорти та перевищення лімітів за 30 днів.
• Щогодинна автоматична перевірка журналу на аномалії (входи одного акаунта з нетипової кількості IP-адрес, масовий експорт даних) із сповіщенням адміністратора безпеки.

B.4 Псевдонімізація та мінімізація

• До LLM-провайдерів передається лише текст транскриптів — без email та іншого PII користувача.
• Режим «Конфіденційно» (маскування PII перед AI): вмикається для проєкту або обовʼязково для всієї команди. Номери карток (перевірка Луна), CVV, телефони, email, IBAN (mod-97), паспорти та ІПН, SSN (США), SIN (Канада), NINO (Велика Британія) і національні номери країн ЄС замінюються позначками до передачі в AI; оригінали повертаються у відповідь уже всередині AICI, відповідність «значення — позначка» не зберігається. Якщо налаштування не вдається перевірити, текст маскується за замовчуванням (подія записується в журнал); якщо точні правила не спрацювали, приховуються всі email і числа — текст ніколи не передається без маскування, а процес не зупиняється.
• До провайдера транскрибації передається лише аудіофайл за підписаним посиланням.
• До платіжного провайдера передаються email і білінг-дані; карткові дані в AICI не зберігаються.
• Тестові та девелоперські прогони виконуються лише на виділених тестових акаунтах — автоматизовані тести не запускаються з акаунтами поза списком тестових доменів. Реальний клієнтський контент у тестуванні не використовується.

Не заявляється: Маскування імен, адрес і довільних ідентифікаторів.

B.4a Зберігання та експорт даних

• Команда задає термін зберігання даних (1–3650 днів), окремі проєкти можуть мати власний термін.
• Перед закінченням терміну власник проєкту та адміністратори отримують нагадування (за замовчуванням за 30 днів, 7 днів і 24 години, налаштовується). Прострочений проєкт переміщується в кошик, а не стирається одразу, і лише після надісланого нагадування.
• Власник або адміністратор може завантажити архів усіх даних команди (проєкти, інтервʼю, теги, звіти, CJM, персони, юзабіліті-дослідження); посилання діють 24 години, кожен експорт записується в журнал. Аудіо- і відеофайли до архіву не входять.

B.5 Доступність і відмовостійкість

• Шифровані бекапи бази даних на рівні інфраструктури; відновлення на момент часу (PITR) до 7 днів.
• Обʼєкти сховища реплікуються в межах регіону.
• Задокументована процедура відновлення з цілями RTO ≤ 4 години та RPO ≤ 1 година.

B.6 Організаційні заходи

• Задокументований план реагування на інциденти: повідомлення наглядового органу протягом 72 годин, повідомлення клієнтів згідно з DPA.
• Безпечний цикл розробки: обовʼязковий code review, CI з лінтингом, перевіркою типів, юніт-тестами, e2e-тестами прав доступу та збіркою на кожну зміну.
• Автоматичне сканування залежностей на вразливості (щодня та на кожну зміну).
• Автоматичне сканування репозиторію на витік секретів (щодня та на кожну зміну).
• Оцінка постачальника перед підключенням нового sub-processor; клієнти повідомляються за 30 днів.