1. Назначение и область применения #
Программное обеспечение «1ОПД» (далее — платформа) предназначено для ведения учёта, который оператор персональных данных обязан вести в силу Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных», принятых в его исполнение подзаконных актов и требований трудового законодательства к обработке персональных данных работников. Платформа фиксирует факты обработки, исчисляет сроки, установленные нормой, и выпускает документы, которые оператор предъявляет субъекту персональных данных, надзорному органу или суду. Оператором персональных данных остаётся пользователь платформы. Платформа не даёт правовой оценки обработки, не заменяет решений оператора об основаниях обработки и о мерах защиты и не принимает на себя его ответственность перед субъектом персональных данных и Роскомнадзором. Поставщик — ООО «Дисконто» — обрабатывает персональные данные по поручению оператора (ч. 3 ст. 6 152-ФЗ). Перечень действий, цели обработки и требования к защите определяются договором. Перед субъектом персональных данных отвечает оператор (ч. 4 ст. 6, ст. 24 152-ФЗ).
Область применения — обработка персональных данных посетителей сайтов, клиентов, контрагентов и работников оператора. Учёт разделён на четыре контура по тому, чьи данные обрабатываются: клиенты и пользователи, работники, регулятор, подрядчики и партнёры. Платформа поставляется как облачный сервис. Установка на оборудование пользователя не требуется, работа ведётся в браузере.
2. Обозначения и сокращения #
В тексте настоящего документа используются следующие обозначения и сокращения: ● ПДн — персональные данные; ● 152-ФЗ — Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных»; ● субъект — субъект персональных данных, физическое лицо, к которому относятся обрабатываемые данные; ● оператор — организация, определяющая цели и состав обработки персональных данных; пользователь платформы; ● пользователь кабинета — работник оператора, которому предоставлен доступ в кабинет платформы; ● поставщик — ООО «Дисконто», поставщик платформы; ● процесс обработки — совокупность цели, правового основания, категорий субъектов и данных, срока хранения и получателей; в платформе одному процессу соответствует одна форма сбора данных; ● форма согласия — документ, текст которого субъект принимает при заполнении формы сбора данных на сайте оператора; ● ИСПДн — информационная система персональных данных; ● доказательство — документ, выпускаемый платформой с регистрационным номером, подписью и страницей публичной проверки; ● УКЭП — усиленная квалифицированная электронная подпись; ● КЭДО — кадровый электронный документооборот оператора.
3. Состав программного обеспечения #
Платформа состоит из следующих частей: ● кабинет оператора — веб-интерфейс из 21 раздела в пяти группах: «Дашборд», «Данные», «Compliance», «Платформа», «Аккаунт» (рис. 1); ● интерфейс приёма согласий — программный интерфейс (API), к которому обращаются формы сбора данных на сайтах оператора; ● публичные страницы, доступные без авторизации: проверка выпущенного документа по регистрационному номеру, опубликованные редакции документов и их история, форма обращения субъекта, страницы подтверждения ознакомления работника; ● кабинет сотрудника поставщика, из которого ведутся юридические лица, сайты, формы согласия, документы и состав подключённых разделов.
Приём согласий и кабинет работают как два независимых процесса: операции кабинета — поиск, выгрузки, формирование документов — не влияют на приём согласий с сайтов оператора. Разделы группы «Платформа» подключаются по юридическому лицу. Неподключённый раздел закрыт на сервере кодом ответа 402, а не только скрыт в меню. Группы «Данные» и «Compliance» доступны всегда, кроме сверки реестра с фактом: она подключается отдельно.
4. Функциональные возможности. Контур «Клиенты и пользователи» #
Реестр согласий — ст. 9 152-ФЗ. Согласие поступает с сайта оператора через программный интерфейс. В записи фиксируются: значения полей формы, дата и время приёма, дата истечения, идентификатор субъекта, редакция политики и хеш текста согласия, действовавшие на момент приёма, IP-адрес и user-agent отправителя. Запись подписывается кодом HMAC-SHA256; подпись проверяется повторным вычислением на сервере. Единица учёта — одно согласие (рис. 2), состав записи приведён на рис. 3.
Отзыв согласия ведётся отдельным журналом, куда каждый отзыв вносится новой строкой: запись о согласии при этом не переписывается. Повторная отправка одного и того же согласия (совпадение процесса, субъекта и текста согласия в пределах 5 минут) второй записи в реестре не создаёт: отправителю возвращается результат исходной записи, факт повтора вносится в журнал действий. Поиск по реестру выполняется запросом к базе данных, а не фильтрацией открытой страницы. Поиск по адресу электронной почты и номеру телефона идёт по значению целиком и без расшифровки персональных данных: платформа сравнивает вычисленный хеш, перебирая варианты написания.
Доказательство согласия. По каждому согласию платформа выпускает документ в формате PDF с регистрационным номером, датой выпуска, составом зафиксированных сведений и ссылкой на страницу публичной проверки (рис. 4). Документ содержит зафиксированные факты — что, когда, с какого адреса и под какой редакцией политики принято, — и не содержит правовых выводов от имени платформы.
Версии политик — ч. 1 и ч. 3 ст. 9, ч. 2 ст. 18.1 152-ФЗ. Редакция документа заводится из самого файла: платформа вычисляет SHA-256 по его байтам и ведёт цепочку версий с датами действия и указанием на заменённую редакцию. Идентификатор редакции проставляется в запись о согласии в момент приёма, поэтому к согласию привязана редакция, действовавшая на его дату, а не текущая. Повторная загрузка неизменённого файла новой версии не создаёт. Каждая редакция публикуется по постоянному адресу, история редакций доступна в кабинете. Платформа фиксирует редакцию и не оценивает её содержание.
Обращения субъектов — ст. 20, 21 152-ФЗ. Оператор регистрирует обращение датой поступления; источники — публичная форма на сайте оператора, регистрация в кабинете, электронная почта. Срок ответа исчисляется от типа требования: 10 рабочих дней на запрос доступа и на ответ надзорному органу (ч. 1 и ч. 4 ст. 20), 7 рабочих дней на уточнение данных и на уничтожение (ч. 3 ст. 20, срок исчисляется со дня представления субъектом подтверждающих сведений), 3 рабочих дня на прекращение неправомерной обработки (ч. 3 ст. 21; блокирование персональных данных выполняется с момента обращения — ч. 1 ст. 21). По требованию об отзыве согласия платформа применяет срок 7 рабочих дней — более строгий, чем 30 дней по ч. 5 ст. 21 152-ФЗ. У каждого срока своё событие отсчёта; применимость нормы к конкретному обращению определяет оператор. Платформа исчисляет срок от даты регистрации обращения, поэтому расчётный срок наступает не позднее законного. Рабочие дни считаются с учётом нерабочих праздничных дней ст. 112 ТК РФ. Продление срока возможно не более чем на 5 рабочих дней и только действием оператора с указанием причины; платформа срок не продлевает (рис. 7).
По требованию об уничтожении и по отзыву согласия платформа ведёт обращение до исхода: находит след субъекта по процессам, показывает основания продолжения обработки без согласия (ч. 1 ст. 6 152-ФЗ) и завершается исполнением с выпуском акта, мотивированным отказом со ссылкой на норму либо закрытием без исполнения с указанием причины. До исхода требование остаётся открытым. По запросу доступа платформа собирает справку субъекту по составу сведений ч. 7 ст. 14 152-ФЗ: подтверждение факта обработки, цель и основание, перечень обрабатываемых данных, источник, сроки, получатели, порядок реализации прав. Справка не выпускается, пока личность заявителя не подтверждена. Заявителю направляются подтверждение приёма обращения, уведомление о продлении срока и ответ.
Уничтожение и акт — ст. 21 152-ФЗ, Приказ Роскомнадзора от 28.10.2022 № 179. Уничтожение персональных данных субъекта в процессе выполняется по отзыву согласия, по обращению субъекта, по вызову программного интерфейса и по истечении срока хранения. Значения полей уничтожаются, идентификатор и профиль субъекта обнуляются; факт получения согласия, его редакция и факт отзыва сохраняются — они позволяют оператору исполнить обязанность представить доказательство получения согласия (ч. 3 ст. 9 152-ФЗ) и подтвердить дату прекращения обработки. Акт об уничтожении выпускается на всех путях уничтожения, включая автоматические, и содержит субъекта, категории уничтоженных данных, адрес оператора, основание, способ, наименование и версию программного обеспечения, лицо, выполнившее уничтожение, и дату; состав полей ориентирован на пункты «а»–«ж» Приказа Роскомнадзора от 28.10.2022 № 179. Акту присваивается номер вида DA-YYYY-NNNNNN и регистрационный номер доказательства. Выгрузку из журнала регистрации событий информационной системы платформа не выпускает: состав документов, которыми подтверждается уничтожение с использованием средств автоматизации, оператор определяет по требованиям названного приказа. Запись об уничтожении и акт хранятся три года с даты уничтожения.
5. Функциональные возможности. Контур «Работники» #
Ознакомление работников — п. 8 ст. 86, ч. 3 ст. 68, ч. 2 ст. 22 ТК РФ. Платформа ведёт перечень работников с должностью, подразделением, датами приёма и увольнения; фамилия, имя, отчество и адрес электронной почты хранятся в зашифрованном виде. Ознакомление назначается работнику с конкретным документом и конкретной редакцией политики. Работник подтверждает ознакомление по персональной ссылке, направленной на его адрес; фиксируются дата открытия, дата подтверждения, IP-адрес, user-agent и подпись записи (рис. 10). Журнал ознакомления выпускается в формате PDF. Назначения без подтверждения печатаются в нём наравне с подтверждёнными. IP-адрес и user-agent в выдаваемый журнал не выводятся: они хранятся и предъявляются по отдельному запросу. Роспись работника платформа не заменяет — роспись оформляется на бумаге либо в системе КЭДО оператора.
Обучение по ситуациям. В платформе ведётся 12 разборов рабочих ситуаций, собранных в четыре курса: базовый, для продаж, для кадровой службы и для информационных технологий. У каждой ситуации есть редакция и хеш содержания, которые сохраняются вместе с ответом работника, поэтому журнал показывает текст, который работник видел на дату прохождения, а не текущую редакцию. Верным считается ответ с первой попытки; повторные попытки разрешены и сохраняются. Проходной балл платформа не устанавливает и сертификат не выдаёт.
Допуски к обработке — подп. «в» п. 13 ПП РФ № 1119. Платформа ведёт перечень допущенных: работник, процесс, уровень доступа, вид основания, реквизит приказа, кто и когда предоставил и отозвал доступ, причина отзыва. Отзыв датируется, строка перечня не удаляется. Перечень сопоставляется с кадровыми статусами и журналом ознакомления. Показываются три расхождения: доступ сохранён после увольнения, доступ предоставлен при отсутствии ознакомления, доступ предоставлен без указанного основания. Приказ о допуске утверждает оператор; платформа хранит его реквизит.
6. Функциональные возможности. Контур «Регулятор» #
Реестр процессов обработки — локальный акт оператора по п. 2 ч. 1 ст. 18.1 152-ФЗ; состав сведений соотнесён с ч. 3 ст. 22 152-ФЗ. По каждому процессу платформа хранит цель, правовое основание, категории субъектов, категории персональных данных, перечень действий, способ обработки, получателей, страны трансграничной передачи, описание срока хранения, способ уничтожения и меры защиты. Перечень процессов выпускается в формате PDF (рис. 5).
Сверка реестра с фактическими данными. Платформа сравнивает заявленное в реестре с тем, что зафиксировано в её собственных данных, и показывает 14 видов расхождений — в том числе получателя, которому передачи зафиксированы, а в реестре он не назван; поля формы шире заявленных категорий данных; процесс, не отнесённый ни к одной информационной системе; система без назначенного уровня защищённости. По каждому расхождению приводится свидетельство: какое поле, какой процесс, сколько записей. Расхождение названо фактом о данных. Является ли оно нарушением, определяет оператор.
Перечень ИСПДн как способ применения ПП РФ № 1119: уровень защищённости определяется по каждой системе отдельно. Платформа ведёт перечень информационных систем: наименование, назначение, категории персональных данных, чьи субъекты обрабатываются, тип актуальных угроз, связь с процессами. Объём субъектов в системе вычисляется по связанным процессам, категории персональных данных предлагаются по названиям полей форм. Уровень защищённости платформа не назначает. Она фиксирует назначенный уровень вместе с тем, кем и когда он определён, и с примечанием к решению (рис. 6).
Журнал инцидентов — ч. 3.1 ст. 21 152-ФЗ. При регистрации инцидента запускаются два срока от момента выявления: 24 часа на уведомление Роскомнадзора и 72 часа на сведения по результатам внутреннего расследования (рис. 8). Тяжесть определяется по числу затронутых субъектов и виду данных. Описание инцидента, установленная причина и итоговый разбор хранятся в зашифрованном виде. Платформа готовит уведомление и отчёт в формате PDF на одном бланке и выпускает досье инцидента, в котором печатается фактическая задержка, если срок нарушен. Отметка об отправке признак просрочки не снимает.
Сведения по запросу надзорного органа. По обращению типа «проверка Роскомнадзора» платформа собирает документ «Сведения об обработке персональных данных оператором» по составу, соотнесённому с ч. 3 ст. 22 152-ФЗ, из реестра процессов и реестра предоставлений. Объём ответа задаёт сам запрос надзорного органа (ч. 4 ст. 20 152-ФЗ); состав ч. 3 ст. 22 — отправная рамка документа. Незаполненное поле обозначается как незаполненное и за отрицание не выдаётся. По каждому юридическому лицу хранятся реквизиты записи в реестре операторов: регистрационный номер, дата, основание записи, дата последней сверки и сведения об ответственном за организацию обработки персональных данных. Сведения получены из открытого реестра операторов Роскомнадзора и отображаются только самому оператору.
7. Функциональные возможности. Контур «Подрядчики и партнёры» #
Реестр предоставлений — ч. 3 ст. 6, п. 6 ч. 4 ст. 9 152-ФЗ. Платформа ведёт справочник получателей: наименование, ИНН, адрес, вид получателя, правовое основание передачи, реквизит договора или поручения, страна трансграничной передачи, признак действия. Запись о предоставлении вносится в момент фактической передачи данных во внешний сервис: фиксируются получатель, процесс, идентификатор субъекта, число субъектов, перечень переданных полей, цель, канал и время (рис. 9). Передачи вне платформы оператор вносит вручную; такая запись помечается каналом внесения: наблюдённая запись подтверждена данными платформы, внесённая вручную — сведениями оператора.
Значения персональных данных в реестре предоставлений не хранятся: субъект обозначен хешем, состав переданного — названиями полей. Хеш остаётся идентификатором субъекта и обрабатывается в том же режиме, что и персональные данные. Доступна выборка по субъекту — кому передавались его данные; она же используется при подготовке справки субъекту. Получатели, по которым передачи зафиксированы, а правовое основание не заполнено, выделяются отдельно. Поручение обработки платформа не оформляет — она хранит его реквизит.
8. Входные данные #
Платформа принимает следующие виды входных данных: ● персональные данные субъектов и факт принятия текста согласия — из форм сбора данных на сайтах оператора через программный интерфейс; ● обращения субъектов — из публичной формы на сайте оператора и регистрацией в кабинете; ● карточки инцидентов: дата выявления, состав затронутых данных, число субъектов, установленная причина, итоговый разбор; ● перечень работников, назначения ознакомления и ответы работников по ситуациям обучения; ● карта процесса обработки: цель, правовое основание, категории субъектов и данных, перечень действий, срок хранения, получатели, меры защиты; ● справочник получателей и записи о передачах, совершённых вне платформы; ● перечень информационных систем и назначенный по каждой уровень защищённости с указанием автора и даты решения; ● перечень допущенных к обработке с реквизитами приказов; ● документы оператора: политика обработки персональных данных, документ об использовании cookie-файлов, тексты форм согласия. Файлы загружает сотрудник поставщика, редакция заводится из файла: дата действия, хеш содержания и привязка к формам проставляются платформой.
9. Выходные данные #
Выходными данными являются экраны кабинета и выпускаемые документы. Платформа формирует восемь документов в формате PDF и одну выгрузку в формате XLSX; кроме них она публикует редакции документов самого оператора: ● доказательство согласия субъекта персональных данных; ● акт об уничтожении персональных данных; ● журнал ознакомления работников; ● досье инцидента безопасности персональных данных; ● справка по запросу субъекта персональных данных; ● сведения об обработке персональных данных оператором; ● уведомление в Роскомнадзор об инциденте и отчёт по результатам расследования — на одном бланке; ● перечень процессов обработки персональных данных; ● политика обработки, документ об использовании cookie-файлов и текст формы согласия — в редакциях, действовавших на выбранную дату, по постоянному публичному адресу; ● выгрузка реестра согласий в формате XLSX: значения персональных данных отдельными ячейками, даты приёма и истечения, ссылки на редакции согласия и политики, действовавшие при приёме (до 5000 строк на выгрузку).
Шесть первых документов выпускаются через общий слой доказательств. Каждый из них получает: ● регистрационный номер вида 1OPD-…, десять знаков алфавита без визуально схожих символов; ● подпись HMAC от канонического набора полей документа; ● запись SHA-256 файла целиком — тех байтов, которые получает адресат. Страница публичной проверки по номеру доступна без авторизации и сообщает только: документ с таким номером выпущен, дата выпуска, вид документа, отозван документ или нет. Содержание документа, сведения о субъекте и об операторе на ней не раскрываются; проверяющему предлагается вычислить SHA-256 имеющегося у него файла и сравнить значения. Выпущенный документ может быть отозван — публичная проверка покажет это по тому же номеру.
10. Разграничение доступа и роли #
В кабинете оператора действуют три роли: «Владелец», «Администратор», «Просмотр». Раздел «Команда» доступен владельцу, выгрузка реестра согласий — владельцу и администратору. Ограничения проверяются на сервере независимо от интерфейса. Видимость внутри организации ограничивается перечнем юридических лиц, назначенным пользователю. Пользователи кабинета оператора и сотрудники поставщика ведутся в разных хранилищах учётных записей, с разными ролями, разными секретами сессии и разными заголовками. Пароли хранятся в виде хеша Argon2id. При заведении пользователя выдаётся временный пароль сроком 7 дней с обязательной сменой при первом входе. Сотрудник поставщика может войти в кабинет оператора в режиме поддержки. В интерфейсе показывается признак такого входа, в журнале действий фиксируются тип актора и учётная запись сотрудника. Раскрытие персональных данных в реестре согласий — отдельное действие пользователя: значения скрыты, а их раскрытие вносится в журнал действий.
11. Защита данных #
Персональные данные шифруются на уровне поля алгоритмом AES-256-GCM. Ключ хранится в сервисе управления секретами Yandex Lockbox и зашифрован ключом Yandex KMS. К каждому шифруемому значению привязываются дополнительные аутентифицируемые данные вида «организация : раздел : поле», поэтому значение одной организации не расшифровывается в контексте другой, а поля разных разделов не смешиваются. Изменение шифротекста обнаруживается при расшифровке. В зашифрованном виде хранятся: значения полей согласий, идентификатор и профиль субъекта, фамилия, имя, отчество и адрес электронной почты работника, текст обращения и сведения о заявителе, доказательство идентификации, текст ответа, описание инцидента, установленная причина и итоговый разбор, временный пароль пользователя. Шифрование на уровне поля защищает от раскрытия данных при доступе к базе данных и к резервным копиям; от компрометации самого приложения оно не защищает.
Данные организаций разделены в базе данных двумя независимыми механизмами: отдельная схема на организацию и построчная политика доступа, сверяющая организацию в сессии со схемой. Запрос к чужой схеме возвращает ноль строк.
Журнал действий ведётся только на добавление: он пишется отдельной ролью базы данных, у которой есть право на вставку и нет прав на изменение и удаление записей (рис. 11). В журнал вносится каждое обращение к программному интерфейсу: организация, действие, вид и идентификатор ресурса, IP-адрес, идентификатор запроса, SHA-256 от тела запроса, код ответа и длительность. Именованных действий 62, среди них — раскрытие персональных данных оператором, выгрузка реестра, выпуск доказательства, обращение к акту об уничтожении, предоставление и отзыв допуска, назначение уровня защищённости, изменение состава подключённых разделов. Значения персональных данных в журнал не записываются: при изменении настроек фиксируются наименования изменённых полей, а не их содержание. Записи о согласии, об отзыве, о подтверждении ознакомления и о прохождении курса подписываются кодом HMAC-SHA256 на секрете, который хранится вне программного кода. Подпись проверяется повторным вычислением.
Данные размещаются в инфраструктуре Yandex Cloud на территории Российской Федерации: управляемый PostgreSQL, объектное хранилище, сервисы управления ключами и секретами. Инфраструктура предоставляется на основании договора; привлечение третьих лиц к обработке согласовывается с оператором в договоре. Размещение платформы не заменяет исполнение оператором ч. 5 ст. 18 152-ФЗ в отношении его собственных информационных систем. Акт об уничтожении сохраняется в объектном хранилище, при его недоступности — в базе данных, чтобы запись не осталась без документа. Остальные документы формируются по запросу; хранятся их регистрационный номер, подпись и SHA-256. Время в документах, письмах и на страницах подтверждения показывается по московскому времени; хранение и журналирование ведутся в UTC.
12. Интеграция с сайтом оператора #
Согласие передаётся запросом POST /api/v2/create-agreement. Поддерживаются ранее опубликованные методы первой версии интерфейса. Доступ предоставляется по ключам двух видов: публикуемый ключ с префиксом pk_ и серверный ключ с префиксом sk_. Для ключа задаются перечень допустимых IP-адресов, перечень допустимых источников запроса (Origin), обязательная подпись запроса HMAC-SHA256 в заголовках API-TIMESTAMP и API-SIGN, перечень форм и перечень разделов, к которым ключ применим, и срок действия. Значение ключа выдаётся один раз при создании или ротации, в базе данных хранится его хеш, в кабинете виден только префикс. Перечни IP-адресов и источников оператор изменяет самостоятельно, подтверждая изменение собственным паролем.
Коды ответа при передаче согласия: ● 200 — согласие записано, в ответе возвращается его идентификатор; ● 202 — согласие принято в очередь и будет записано; идентификатор в ответе отсутствует и становится доступен после записи. Повторная отправка того же согласия ради получения кода 200 не требуется: в пределах окна дедупликации она возвращает результат исходной записи, за его пределами создаёт в реестре вторую запись; ● 400 — в запросе отсутствует обязательное поле; ● 401 — неверный ключ или подпись запроса; ● 402 — обращение к разделу, не подключённому этому юридическому лицу; ● 403 — источник запроса, IP-адрес или форма вне разрешённых для ключа; ● 503 — приём временно невозможен; это единственный случай, когда требуется повторная отправка.
Помимо приёма согласий интерфейс отдаёт состав полей формы и данные субъекта и уничтожает данные субъекта по запросу. Без авторизации доступны: проверка выпущенного документа по регистрационному номеру, опубликованные редакции документов и их история, форма обращения субъекта для размещения на сайте оператора, страницы подтверждения ознакомления работника и прохождения курса. Инструкция по подключению формируется в кабинете по сайтам, формам и выпущенным ключам конкретного оператора.
13. Сроки и уведомления #
Срок по каждому предмету учёта хранится в карточке вместе с нормой, из которой он взят, и величиной остатка. Величина остатка и признак просрочки выводятся в разделе. Уведомления ответственным сотрудникам оператора по приближению срока и по факту его наступления включаются в подписке на соответствующий раздел; пороги согласуются при подключении. Каждое уведомление отправляется однократно: повторная отправка исключается уникальным ключом в базе данных. Каналы: электронная почта ответственным сотрудникам оператора, уведомление в кабинете и внутренний канал поставщика. Персональные данные в уведомления не попадают — передаются тема и ссылка, содержание доступно после входа в кабинет.
14. Ограничения #
Перечень приведён, чтобы объём поставляемых функций не толковался расширительно. ● Платформа не подтверждает законность обработки и не выдаёт правовых заключений. Выпускаемые документы содержат зафиксированные факты; расхождения в сверке названы фактами о данных, а не нарушениями. ● Уровень защищённости ИСПДн платформа не назначает и состав мер защиты по уровню не определяет. Она фиксирует, кем и когда уровень определён. Акт определения уровня защищённости платформа не формирует. ● Уведомление об обработке персональных данных в Роскомнадзор платформа не подаёт и форму уведомления не воспроизводит. Она выпускает перечень процессов и сведения о фактическом состоянии обработки как материал к подаче. Электронная подача через портал Роскомнадзора, как и подача уведомления об инциденте, требует УКЭП оператора. ● Уведомление о намерении осуществлять трансграничную передачу персональных данных (ч. 3 ст. 12 152-ФЗ) платформа не подаёт: она фиксирует страну получателя. ● Сверка сведений оператора с реестром операторов, который ведёт Роскомнадзор, автоматически не выполняется. Срок уточнения сведений — не позднее 15-го числа месяца, следующего за месяцем изменений, — платформа не отслеживает. ● Модель угроз в платформе не ведётся: она не хранится, её пересмотр не датируется, напоминания о пересмотре после инцидента или изменения инфраструктуры не направляются. ● Роспись работника платформа не заменяет; подписание кадровых документов остаётся в системе КЭДО оператора. Проходной балл по обучению платформа не устанавливает и сертификат не выдаёт. ● Приказ о допуске к обработке и поручение обработки платформа не оформляет — она хранит их реквизиты. ● Расследование инцидента платформа не проводит: причину устанавливает оператор. ● Содержание политики обработки платформа не оценивает; текст из файла в формате PDF не извлекается. ● Поиск по части значения персональных данных невозможен: данные хранятся в зашифрованном виде, поиск по адресу электронной почты и номеру телефона выполняется по значению целиком. ● Акты об уничтожении задним числом не выпускаются. Записи об уничтожении, сделанные до подключения выпуска актов, помечены как не имеющие акта. ● Выгрузку из журнала регистрации событий информационной системы платформа не выпускает — она выпускает акт об уничтожении. Состав документов, которыми подтверждается уничтожение с использованием средств автоматизации, оператор определяет по Приказу Роскомнадзора от 28.10.2022 № 179. ● Справочник получателей, перечень допущенных и перечень информационных систем заполняет оператор; карту процесса по его сведениям заполняет сотрудник поставщика. Платформа вычисляет из имеющихся данных только то, что может подтвердить свидетельством. ● Нерабочие дни, переносимые актами Правительства на конкретный год, в календаре расчёта сроков не учитываются: срок наступает раньше установленного, а не позже. ● Скрытие раздела в меню кабинета прав не ограничивает: права задаются ролью пользователя и составом подключённых разделов.