Зрозумійте, як Truvoca працює з даними у вашому сценарії дзвінків.
Змістовна перевірка безпеки починається з конкретного процесу, систем, категорій даних, матеріалів дзвінка, користувачів і регіонів. Ця сторінка пояснює, які питання Truvoca документує разом із клієнтом до запуску, та відокремлює підтверджені контролі від інформації, що ще перевіряється.
Truvoca не використовує сертифікаційні бейджі або загальні заяви про відповідність без доказів. Архітектура, постачальники, регіони, строки зберігання, шифрування, доступ і договірні документи мають бути підтверджені технічним або юридичним відповідальним до появи конкретного публічного твердження.
30 хвилин у Google Meet. Час показано за східноєвропейським (GMT+03:00). Планування працює на Google Calendar, тож вибір часу відбувається у сервісі Google.
Почніть із маршруту даних, а не загального чекліста
Покажіть, звідки дані надходять, куди переходять і де залишають процес.
Маршрут даних документується для конкретного впровадження. Типовий телефонний сценарій може починатися з телефонної події або погодженого запису, використовувати Truvoca для опрацювання розмови, обмінюватися обмеженими даними з підключеною системою, створювати погоджені матеріали та передавати виняток людині.
Схема стає офіційною лише після перевірки всіх сервісів, регіонів, меж зберігання, передавання даних і відповідальних. До цього це модель процесу, а не твердження про архітектуру.
- Телефонна подія або погоджений початковий запис
- Опрацювання агентом за правилами сценарію
- Читання або оновлення у підключеній бізнес-системі
- Погоджені журнали, результати, записи, транскрипти або підсумки
- Передача людині, завдання чи сповіщення за потреби
- Зберігання й видалення для кожної категорії даних
Збирайте лише те, що потрібно для дзвінка
Відокремте необхідні дані від необов'язкових матеріалів дзвінка.
Кожен сценарій повинен мати перелік даних на рівні полів. Для підтвердження запису, наприклад, можуть знадобитися погоджений ідентифікатор, дозволені контактні дані, контекст запису, результат розмови та наступна дія. Точний перелік залежить від системи й правил клієнта.
Аудіозаписи, транскрипти, підсумки, довільні нотатки та аналітичні поля є окремими категоріями. Їх не слід подавати як увімкнені за замовчуванням: спочатку потрібно визначити мету, доступ і життєвий цикл.
- Дані абонента або отримувача, потрібні для погодженої мети
- Контекст запису, бронювання, ліда, послуги або підтримки
- Правила розмови та дозволена довідкова інформація
- Результат, дія та поля винятку
- Необов'язкові запис, транскрипт, підсумок і довільні нотатки
- Технічні журнали для роботи, підтримки чи безпеки
Доступ відповідає роботі, яку потрібно виконати
Перевірте ролі, дозволи, дані доступу та видимість аудиту.
Під час перевірки безпеки потрібно зафіксувати, хто має доступ до даних клієнта, коли операційній команді Truvoca потрібен доступ, як автентифікуються користувачі й сервіси, як обробляються секрети та які дані аудиту доступні.
Принцип — надавати лише доступ, потрібний для погодженого сценарію. Конкретний контроль з'являється на публічній сторінці після перевірки його реалізації, застосування, відповідального та винятків.
- Ролі клієнта й адміністративний доступ
- Операційний доступ і підтримка Truvoca
- Автентифікація користувачів і сервісів
- Дані доступу до інтеграцій і робота із секретами
- Дозволи на читання, оновлення, експорт і матеріали дзвінків
- Події аудиту для погоджених перевіряльників
- Перевірка й припинення доступу
Життєвий цикл даних має бути явним
Задокументуйте, де зберігається кожна категорія даних і коли її видаляють.
Зберігання не можна описати одним строком. Початкові записи, результати, журнали, аудіо, транскрипти, підсумки, резервні копії та експорти підтримки можуть мати різні правила.
До публікації або запуску Truvoca й клієнт мають підтвердити сервіси та регіони, стандартні й налаштовувані строки, запити на видалення, резервні копії, юридичні чи операційні винятки та спосіб перевірки завершення. Конкретний регіон або строк не вказується до завершення перевірки.
- Сервіс і місце зберігання
- Стандартний і налаштовуваний строк за категорією даних
- Видалення за запитом клієнта або після закриття облікового запису
- Обсяг і строк резервних копій
- Юридичні, безпекові, платіжні або інцидентні винятки
- Доказ завершеного видалення чи знеособлення
Знайте, які постачальники підтримують процес
Підтримуйте датований перелік постачальників і субпроцесорів.
Корисний перелік називає постачальника, його роль, категорії даних, регіон або контекст передавання, якщо це відомо, і спосіб повідомлення клієнтів про суттєві зміни.
Публікувати можна лише постачальників, підтверджених перевіркою архітектури й договорів. Постачальника телефонії, моделей, хостингу, аналітики, календаря, електронної пошти або підтримки не можна визначати з логотипа, старої конфігурації чи загального опису технології.
- Постачальник і сервіс
- Мета у процесі Truvoca
- Категорії даних
- Регіон або контекст передавання після перевірки
- Відповідальний за договірну й безпекову перевірку
- Дата останнього перегляду
- Спосіб повідомлення клієнтів про зміни
Записи й транскрипти потребують окремого рішення
Налаштуйте матеріали дзвінка відповідно до мети, повідомлення, доступу й строків.
Дзвінок може створювати аудіо, транскрипт, підсумок, результат, структуровані поля дії та технічні журнали. Для кожного матеріалу потрібні мета й відповідальний. Запис або транскрипція також залежать від сценарію, правил повідомлення чи згоди, інструкцій клієнта та протестованої технічної поведінки.
Якщо запис вимкнено, потрібно вказати, які результати чи журнали без аудіо залишаються. Редагування даних, завантаження, експорт, видалення та доступ описуються лише після перевірки функції та контролю.
- Чи ввімкнено запис або транскрипцію
- Потрібне повідомлення, згода й правила дзвінків
- Хто може слухати, читати, шукати, завантажувати або експортувати
- Мета й строк для кожного матеріалу
- Редагування або маскування лише після реалізації й тестів
- Поведінка без запису
- Видалення й обробка винятків
Плануйте збої так само, як успішні дзвінки
Визначте ескалацію, відновлення й комунікацію з клієнтом до запуску.
Операційна надійність включає поведінку при недоступності телефонії, обробки агентом, інтеграції або маршруту до людини. Потрібно визначити сигнали збою, відповідального, безпечну зупинку чи режим без оновлення, звірку, тести відновлення та спосіб комунікації з клієнтом.
Час реагування, показники доступності, цілі відновлення, строки сповіщення та канали підтримки є договірними або операційними фактами. Вони не публікуються до появи процесу й доказів.
- Виявлення збою й відповідальний
- Безпечна зупинка, повторна спроба або режим без оновлення
- Захист від дублів і звірка
- Операційна ескалація й тестування відновлення
- Спосіб комунікації з клієнтом
- Розбір інциденту та коригувальні дії
Спочатку докази, потім бейджі
Запитайте актуальний статус вимоги, важливої саме для вас.
У цій еталонній версії Truvoca не заявляє про сертифікацію SOC 2 або ISO 27001, відповідність HIPAA, можливість укласти BAA, відповідність PCI чи GDPR, фіксований регіон зберігання або універсальне шифрування.
Це не визначає, чи можна підтримати конкретну вимогу. Це означає, що сайт не натякатиме на готовність, доки не підтверджено точний обсяг, докази, договір і відповідального. Перевіряльник має запросити фактичний поточний статус для свого сценарію.
- SOC 2Публічне твердження не перевірено
- ISO 27001Публічне твердження не перевірено
- HIPAA і BAAТвердження та доступність договору не перевірені
- PCIПублічне твердження не перевірено; платіжних даних слід уникати без окремого дизайну
- GDPR та регіональні вимогиОцінюються за фактичними ролями, даними, регіонами й договорами
- Шифрування, розміщення даних, тестування на проникнення й керування вразливостямиЛише на основі погоджених технічних доказів
Безпека залежить від усього процесу
Truvoca і клієнт контролюють різні частини впровадження.
Truvoca може налаштувати продукт і підключення за погодженим обсягом. Клієнт відповідає за правомірність мети дзвінка й списку отримувачів, передану інформацію, користувачів, бізнес-правила, строки зберігання, маршрути ескалації та юридичну чи регуляторну перевірку своєї діяльності.
Відповідальність потрібно зафіксувати у плані впровадження й відповідних договорах. Ця сторінка пояснює операційну модель, але не є юридичною порадою чи гарантією відповідності.
- КлієнтМета дзвінка, правова підстава або згода, список отримувачів і час
- КлієнтПередані дані, доступи до систем, користувачі й бізнес-правила
- СпільноОбсяг сценарію, повідомлення, матеріали, строки, тести й ескалація
- TruvocaРеалізована конфігурація продукту й задокументована поведінка підключення
- СпільноМоніторинг, координація інцидентів, зміни й періодичний перегляд
Перевіряйте безпеку в контексті процесу, який плануєте запустити.
Розкажіть про сценарій, системи, категорії даних, очікувані регіони, матеріали дзвінків, строки зберігання, договірні вимоги та роль перевіряльника. Ми визначимо, які факти вже задокументовані, які потребують технічного чи юридичного підтвердження та що можна передати погодженим способом.
Не надсилайте через публічну форму записи клієнтів чи пацієнтів, дані доступу, звіти з безпеки або конфіденційні файли.
FAQ
FAQ
Які дані дзвінків обробляє Truvoca?
Перелік залежить від погодженого сценарію й підключених систем. Окремо документуються мінімальні дані абонента чи отримувача, бізнес-контекст, дані для розмови, результат і дія, технічні журнали та необов'язкові записи, транскрипти або підсумки.
Чи записуються або транскрибуються дзвінки?
Запис і транскрипція є окремими рішеннями для конфігурації та сценарію. Вони залежать від інструкцій клієнта, правил повідомлення чи згоди, технічної підтримки, доступу, мети, строків і видалення. Сторінка не подає їх як універсально ввімкнені.
Де зберігаються дані?
Еталонний текст не називає сервіси чи регіони до перевірки архітектури й обсягу впровадження. Перевірка безпеки має визначити сервіси, місця, передавання, резервні копії та відповідальних для кожної категорії.
Як довго зберігаються дані?
У цій версії немає універсального строку. Його потрібно підтвердити для результатів, журналів, записів, транскриптів, підсумків, резервних копій, експортів, запитів на видалення та погоджених винятків.
Хто має доступ до даних клієнта?
Доступ документується за ролями клієнта, операційної команди й підтримки Truvoca та сервісних облікових записів. Автентифікація, дозволи, секрети, аудит, перегляд і припинення доступу потребують доказів реалізації.
Які субпроцесори використовуються?
Публічний список має формуватися з актуального переліку архітектури й договорів: постачальник, мета, категорії даних, регіон або передавання, дата перевірки та порядок оновлення. Цей перелік залишається відкритою вимогою до доказів.
Чи відповідає Truvoca HIPAA або має SOC 2?
Цей еталонний текст не робить жодного з цих тверджень. Поточний статус, обсяг доказів, доступність договорів і відповідність конкретному сценарію мають підтвердити технічний та юридичний відповідальні.
Чи можна запросити DPA або перевірку безпеки?
У заявці можна назвати вимогу та роль перевіряльника без конфіденційних матеріалів. Truvoca має підтвердити, які документи й процес перевірки фактично доступні, та за потреби надати погоджений канал обміну.