Чек-лист проверки ТЗ на корпоративный портал

Коротко: Чтобы техническое задание на корпоративный портал соответствовало требованиям 2026 года, необходимо заложить в него архитектуру с учетом обновленного 152-ФЗ (в редакции № 265-ФЗ), механизмы интеграции с ГИС ЭПД и ГИС ЭП, поддержку актуальных сценариев работы с электронной подписью по 315-ФЗ и строгие протоколы трансграничной передачи данных согласно реестру Роскомнадзора.

Кстати, в AmSales мы делаем разработку сайтов под ключ и ИИ-интеграцию и анализ звонков под ключ. Если нужна помощь - напишите нам.

Функциональные требования к архитектуре портала

Когда вы начинаете составлять техническое задание на корпоративный портал, основная ошибка - фокусироваться только на интерфейсе и кнопках. Дизайн важен, но архитектура определяет, развалится ли система под нагрузкой через полгода или станет фундаментом для цифровизации. В 2026 году требования к корпоративному порталу сместились от "просто базы знаний" к сложной экосистеме, которая управляет правами доступа, потоками данных и интеграциями в реальном времени.

Первое, что должно быть в ТЗ - это описание модели данных и логики взаимодействия модулей. Если портал должен стать точкой входа для всех сотрудников, он обязан бесшовно работать с вашей ERP, HRM и системами управления проектами. Архитектура должна поддерживать микросервисный подход. Это позволит обновлять модуль логистики или модуль документооборота, не останавливая работу всего портала. Если в ТЗ прописан монолит, готовьтесь к тому, что любая правка будет стоить космических денег и занимать недели.

Второй критический аспект - масштабируемость и управление ролями. В крупных компаниях структура меняется ежемесячно. Система должна поддерживать динамическое назначение прав не только на основе должностей, но и на основе проектных групп. Проверьте, чтобы в ТЗ была четко прописана иерархия доступов: от администратора системы до рядового сотрудника, имеющего доступ только к своей базе знаний и личным документам. Это напрямую влияет на безопасность персональных данных в ИТ-проектах.

Третий момент - требования к API. Современный портал не живет в вакууме. Вам нужны открытые, документированные API для интеграции со сторонними сервисами. Например, если вы решите внедрить новый сервис аналитики или систему управления складом, портал должен уметь "забирать" оттуда данные без написания кастомного кода с нуля. Без этого требования к корпоративному порталу 2026 года превращаются в пустые слова.

Ключевые компоненты архитектуры

• Модуль управления контентом (CMS) с поддержкой версионности.
• Система управления правами доступа (IAM) на базе современных протоколов аутентификации.
• Слой интеграции (ESB или API Gateway) для связи с внешними системами.
• Модуль отчетности и аналитики, работающий с первичными данными в реальном времени.

Новые правила обработки персональных данных 152-ФЗ

Работа с персональными данными (ПДн) в 2026 году стала значительно жестче. Если вы готовите техническое задание на разработку портала, забудьте про старые шаблоны согласий. С 26 июля 2026 года вступил в силу Федеральный закон № 265-ФЗ, который внес существенные правки в статью 12 Закона № 152-ФЗ. Теперь требования к тому, как портал собирает, хранит и обрабатывает данные сотрудников и контрагентов, изменились коренным образом.

Главное изменение касается целей обработки. Теперь нельзя просто написать "для обеспечения деятельности компании". Отраслевые акты стали требовать более четкого определения состава данных и конкретных действий, которые вы совершаете с ними по каждой отдельной цели. В ТЗ должен быть предусмотрен функционал, позволяющий разделять потоки данных. Например, данные, собранные для расчета зарплаты, не должны автоматически попадать в модуль корпоративного обучения, если это не предусмотрено отдельным согласием.

Также важно учитывать механизмы отзыва согласия. В текущей повестке обсуждается возможность реализации отзыва согласия через портал Госуслуг. Даже если это еще не стало повсеместным стандартом для всех компаний, архитектура портала должна быть готова к интеграции с государственными системами идентификации. Это значит, что в ТЗ нужно заложить возможность автоматизированной обработки запросов субъектов ПДн: "удалить мои данные", "исправить ошибку", "предоставить выписку".

Не забывайте про локализацию. Все первичные базы данных должны находиться на территории РФ. Если ваш портал использует облачные решения, проверьте, чтобы провайдер гарантировал физическое нахождение серверов в России и соответствие всем актуальным требованиям по защите информации. Ошибка в этом вопросе при проектировании может привести к тому, что систему придется переписывать с нуля уже после запуска.

Трансграничная передача данных и реестр Роскомнадзора

Трансграничная передача данных - это "минное поле" для любого ИТ-проекта в 2026 году. Если ваша компания имеет филиалы за рубежом или использует иностранное ПО, интегрированное с порталом, вы обязаны соблюдать новые правила. Согласно изменениям от 26 июля 2026 года (265-ФЗ), участие страны в международных конвенциях (например, Совета Европы) больше не является автоматическим основанием для признания защиты данных адекватной. Теперь единственным ориентиром стал перечень, который ведет Роскомнадзор.

Это означает, что при проектировании системы передачи данных между головным офисом в РФ и зарубежным подразделением, вы не можете полагаться на "старые добрые" договоры. В ТЗ должен быть прописан алгоритм проверки: куда именно уходят данные. Если страна назначения не входит в актуальный реестр Роскомнадзора, процедура передачи усложняется. Вам необходимо предусмотреть в системе логирование всех фактов трансграничной передачи: кто, когда, какой объем данных и в какую страну отправил.

Важный нюанс: если вы планируете передачу данных в страну, не входящую в перечень адекватных, вы должны сначала подать уведомление в Роскомнадзор. И здесь кроется практическая сложность: по правилам, зафиксированным в летних обзорах 2026 года, если страна не в перечне, нужно дождаться истечения 10 рабочих дней с даты подачи уведомления, прежде чем начинать передачу. В ТЗ на автоматизацию процессов это должно быть учтено как бизнес-логика: система не должна позволять отправку данных до момента подтверждения (или истечения срока ожидания) легитимности такой операции.

Для ИТ-директора и юриста это означает, что проверка ТЗ на разработку портала должна включать аудит всех внешних связей. Если портал стучится на зарубежный сервер для проверки лицензии или обновления контента, и через этот канал могут "проскочить" ПДн сотрудников - вы в зоне риска. Необходимо прописать требования к маскированию или обезличиванию данных перед их выходом за пределы контура РФ.

Интеграция с электронной подписью по закону 315-ФЗ

Электронный документооборот (ЭДО) на корпоративном портале - это не просто возможность "прикрепить скан". В 2026 году это сложный процесс, регулируемый Федеральным законом № 315-ФЗ, который внес изменения в базовый закон об электронной подписи (№ 63-ФЗ). Теперь, если ваш портал используется для подписания внутренних приказов, договоров с подрядчиками или актов, требования к сценариям работы с сертификатами стали гораздо строже.

При составлении ТЗ обязательно проверьте, как реализованы следующие сценарии:

1. Авторизация пользователя через усиленную квалифицированную электронную подпись (УКЭП) для критически важных действий.
2. Проверка статуса сертификата в режиме реального времени (не отозван ли он, не истек ли срок действия).
3. Хранение штампов электронной подписи и метаданных, подтверждающих неизменность документа после подписания.
4. Интеграция с облачными сервисами КЭП, если компания не использует физические токены.

Часто разработчики предлагают использовать простую электронную подпись (ПЭП) для всего подряд. Это ошибка. Для юридически значимых документов, например, трудовых договоров или согласий на обработку ПДн, требуется именно квалифицированная подпись. В ТЗ должно быть четко разграничено: какие типы действий требуют ПЭП (например, одобрение заявки на отпуск), а какие - УКЭП (подписание финансового документа). Это критично для легитимности всех процессов, которые автоматизирует портал.

Также обратите внимание на работу с сертификатами. В 2026 году требования к безопасности хранения ключей и процедурам их обновления стали жестче. Если портал предполагает использование мобильных устройств для подписания, ТЗ должно включать требования к защищенным средам исполнения на этих устройствах. Иначе вы получите систему, которая формально работает, но не выдержит проверки при любом судебном споре о подлинности документа.

Автоматизация логистики и работа с ГИС ЭПД

Если ваш корпоративный портал выходит за рамки офисного использования и затрагивает операционную деятельность, например, управление цепочками поставок, вы попадаете в поле действия Федерального закона № 140-ФЗ. С 1 сентября 2026 года электронные перевозочные документы (ЭПД) являются обязательными. Это значит, что любая автоматизация логистики на портале должна быть неразрывно связана с ГИС ЭПД.

В ТЗ на автоматизацию корпоративных процессов чек-лист должен содержать пункт о прямой интеграции с государственной информационной системой. Нельзя просто "загружать PDF-файлы". Система должна уметь формировать ЭПД в электронном виде, подписывать их и передавать в ГИС. Это касается транспортных накладных, путевых листов и других документов, которые теперь имеют строго регламентированный цифровой формат. Если портал не умеет работать с ГИС ЭПД "из коробки", он станет обузой, а не инструментом эффективности.

Пример из практики: компания использует портал для управления парком грузовиков. Водитель через мобильное приложение портала получает задание. Если в ТЗ не заложено требование об интеграции с ГИС ЭПД, водителю придется дублировать работу: в портале отметить выполнение, а потом отдельно в стороннем сервисе оформлять электронную накладную. Это убивает всю суть автоматизации. Правильное ТЗ предполагает, что нажатие кнопки "Доставлено" в портале инициирует автоматическую отправку данных в государственную систему.

Кроме того, необходимо учитывать требования к форматам данных. ГИС ЭПД предъявляет жесткие требования к структуре файлов. Разработчики должны использовать актуальные спецификации, иначе интеграция будет постоянно "отваливаться" из-за ошибок валидации. Проверка ТЗ на этот аспект - залог того, что ваша логистика не встанет из-за невозможности легально оформить перевозку.

Обязательная передача сведений в ГИС ЭП

Для компаний, работающих в сфере туризма, требования стали максимально жесткими. С 1 сентября 2026 года передача сведений в ГИС ЭП (Единую информационную систему в сфере туризма) стала обязательной для всех туроператоров без каких-либо исключений. Если ваш корпоративный портал используется для управления турпродуктом, он должен стать шлюзом для передачи данных в эту систему.

В ТЗ должна быть детально прописана логика формирования электронной путевки. Согласно актуальным правилам, туроператор обязан сформировать её в ГИС ЭП не позднее одного рабочего дня со дня заключения договора. Если бронирование происходит менее чем за 30 дней до начала тура, срок сокращается: сведения должны быть переданы не позднее чем за 24 часа до начала оказания услуг. Это крайне жесткий тайминг, который невозможно контролировать вручную. Автоматизация здесь - вопрос выживания бизнеса.

Важно понимать последствия несоблюдения этих сроков. Регулятор в 2026 году действует решительно: за трехкратное нарушение в течение трех последовательных месяцев (включая непередачу данных, нарушение сроков или передачу недостоверных сведений) туроператор подлежит исключению из Единого федерального реестра туроператоров. Это означает фактическую остановку деятельности компании. Поэтому в ТЗ на разработку портала должен быть заложен механизм контроля дедлайнов и автоматических уведомлений для ответственных сотрудников при приближении критических сроков передачи данных.

Интеграция с ГИС ЭП - это не просто передача JSON-пакета. Это проверка полноты данных. Система должна сама валидировать сведения о туристах, отелях и транспортных средствах перед отправкой, чтобы минимизировать риск передачи "недостоверных сведений". Ошибка в одной букве фамилии в портале может привести к тому, что ГИС ЭП отклонит документ, а вы нарушите закон. Проектируйте систему с учетом этой ответственности.

Безопасность и риски исключения из реестров

Когда мы говорим про безопасность корпоративного портала, мы часто думаем о защите от хакеров. Но в 2026 году существуют риски гораздо более системные - риски исключения из государственных реестров из-за некорректной работы ИТ-систем. Это касается не только туроператоров, но и любых компаний, чья деятельность регулируется государственными информационными системами (ГИС).

Безопасность персональных данных в ИТ-проектах сегодня - это не только шифрование трафика. Это прежде всего комплаенс. Если ваш портал не обеспечивает соблюдение требований 152-ФЗ (в части трансграничной передачи, управления согласиями или локализации), компания рискует получить не только штрафы, но и предписание о приостановке деятельности. В ТЗ должен быть предусмотрен аудит безопасности, который включает проверку соответствия всех бизнес-процессов актуальному законодательству.

Рассмотрим таблицу рисков, которые должны быть учтены при проверке ТЗ:

Для минимизации этих рисков в ТЗ необходимо заложить возможность быстрого изменения логики системы. Законодательство в 2026 году меняется быстро. Сегодня вы работаете по одной редакции 152-ФЗ, а завтра выходит новый подзаконный акт, меняющий состав передаваемых данных. Ваша архитектура должна быть гибкой, чтобы "подкрутить" настройки без переписывания ядра системы. Это и есть настоящая безопасность в современном понимании.

Типичные ошибки при составлении ТЗ на портал

За годы работы с крупными внедрениями я выделил список ошибок, которые превращают перспективный проект в "черную дыру" для бюджета. Если вы проводите проверку ТЗ на разработку портала, будьте предельно внимательны к этим моментам.

Первая и самая частая ошибка - "функциональный вакуум". Это когда в ТЗ описаны возможности (что система делает), но полностью отсутствуют требования к качеству и ограничениям (как она это делает). Например: "Система должна позволять подписывать документы". Это плохая формулировка. Хорошая формулировка: "Система должна поддерживать подписание документов с использованием УКЭП согласно требованиям 315-ФЗ, обеспечивать проверку валидности сертификата через [название сервиса] и логировать факт подписания с указанием временной метки, синхронизированной с NTP-сервером".

Вторая ошибка - игнорирование интеграционных сценариев. Многие пишут: "Интеграция с 1С". Это не требование, это мечта. В ТЗ должно быть четко указано: по какому протоколу (REST, SOAP), с какой периодичностью (real-time или пакетно), какие именно поля передаются и что делать, если интеграция прервалась. Без этого вы получите систему, которая "разваливается" при малейшем сбое в соседнем сервисе.

Третья ошибка - пренебрежение требованиями к безопасности и комплаенсу. Часто разработчики откладывают вопросы ПДн и трансграничной передачи "на потом", считая, что это решит юрист. Но если архитектура не предусматривает разделения баз данных или механизмов маскирования, юрист ничего не сможет сделать. Безопасность должна быть заложена в ТЗ на этапе проектирования, а не "наслаиваться" сверху в конце проекта.

И четвертая ошибка - отсутствие плана миграции данных. Перенос данных из старой системы в новую - это всегда болезненный процесс. Если в ТЗ не прописаны требования к очистке, трансформации и проверке целостности данных при переносе, вы рискуете получить на портале "мусор", который сделает аналитику бесполезной, а работу сотрудников - невыносимой.

Что запомнить:

• Проверяйте ТЗ на соответствие 152-ФЗ в редакции № 265-ФЗ (актуально на октябрь 2026).
• Убедитесь, что интеграции с ГИС (ЭПД, ЭП) прописаны технически детально, а не общими словами.
• Контролируйте требования к электронной подписи согласно 315-ФЗ.
• Архитектура должна поддерживать гибкую настройку прав и сценариев передачи данных.
• Всегда закладывайте механизмы контроля сроков для обязательной государственной отчетности.